virtualize all the things... ?
-
@bj said in virtualize all the things... ?:
@wirestyle22 At what point do you consider a server not "under utilized"?
That is actually my point
-
@bj said in virtualize all the things... ?:
@wirestyle22 At what point do you consider a server not "under utilized"?
When the CPU is 100%
Sounds silly, but that's really kind of the answer.
-
@scottalanmiller said in virtualize all the things... ?:
@bj said in virtualize all the things... ?:
@wirestyle22 At what point do you consider a server not "under utilized"?
When the CPU is 100%
Sounds silly, but that's really kind of the answer.
Right
-
If you are hitting 100%, I presume you then back off a little? That seems... unhealthy in the long term.
-
@bj said in virtualize all the things... ?:
If you are hitting 100%, I presume you then back off a little? That seems... unhealthy in the long term.
Any unused resource is not being utilized, making a server underutilized. That's the point we are making.
-
I understand the point, and on that point you are absolutely correct. My question is in practice, are you actually trying to hit that 100% mark? It seems like the services would do well to have a little buffer room in there, considering spikes in load and all. But maybe we're talking apples and oranges here. I'm thing production web / database servers, where speed is a priority. Maybe you are considering a less sensitive work load?
-
@bj said in virtualize all the things... ?:
I understand the point, and on that point you are absolutely correct. My question is in practice, are you actually trying to hit that 100% mark? It seems like the services would do well to have a little buffer room in there, considering spikes in load and all. But maybe we're talking apples and oranges here. I'm thing production web / database servers, where speed is a priority. Maybe you are considering a less sensitive work load?
There are reasons to not virtualize which @scottalanmiller has mentioned here, but they are very few and far between. Typically you are wasting more resources in a non-virtualized server than you are in a physical server. They can be telling the truth, but I seriously doubt they are.
-
@bj said in virtualize all the things... ?:
If you are hitting 100%, I presume you then back off a little? That seems... unhealthy in the long term.
If you MAINTAIN 100%, there is nothing to do but buy more gear!
-
@bj said in virtualize all the things... ?:
I understand the point, and on that point you are absolutely correct. My question is in practice, are you actually trying to hit that 100% mark?
For maximum throughput, yes you are. You only ever go below that point for latency reasons.
-
@bj said in virtualize all the things... ?:
It seems like the services would do well to have a little buffer room in there, considering spikes in load and all.
That's why you virtualize and consolidate. It helps to even out the spikes.
-
@wirestyle22 said in virtualize all the things... ?:
@bj said in virtualize all the things... ?:
I understand the point, and on that point you are absolutely correct. My question is in practice, are you actually trying to hit that 100% mark? It seems like the services would do well to have a little buffer room in there, considering spikes in load and all. But maybe we're talking apples and oranges here. I'm thing production web / database servers, where speed is a priority. Maybe you are considering a less sensitive work load?
There are reasons to not virtualize which @scottalanmiller has mentioned here, but they are very few and far between. Typically you are wasting more resources in a non-virtualized server than you are in a physical server. They can be telling the truth, but I seriously doubt they are.
It's really not that you run servers at 100%. It's that you don't use excuses like being fully utilized until you are. Because it makes no sense. If your servers are sized to be maxed out, then consolidation would improve that.
-
The only thing I can think of you may not want to virtualize is VPN server.
cause if you want to reboot the Host hypervisor for whatever reason (maybe shutdown by disaster and not choice), it is bit tricky to diagnose and running when you cant connect especially if your working from home.I reckon the AMD AM1 platform is an excellent platform for VPN server, especially if you get motherboard that gets charged using laptop charger (AM1H-ITX) you are free to experiment and deploy whatever VPN solution you want , or purchase a commercial VPN box.
-
@emad-r said in virtualize all the things... ?:
The only thing I can think of you may not want to virtualize is VPN server.
That would be a reason to consider doing a one to one deployment (e.g. not consolidating) but not a reason to not virtualize.
-
@emad-r said in virtualize all the things... ?:
... it is bit tricky to diagnose and running when you cant connect especially if your working from home.
That just exposes the fragility of LAN-based security.
-
@emad-r said in virtualize all the things... ?:
The only thing I can think of you may not want to virtualize is VPN server.
cause if you want to reboot the Host hypervisor for whatever reason (maybe shutdown by disaster and not choice), it is bit tricky to diagnose and running when you cant connect especially if your working from home.I reckon the AMD AM1 platform is an excellent platform for VPN server, especially if you get motherboard that gets charged using laptop charger (AM1H-ITX) you are free to experiment and deploy whatever VPN solution you want , or purchase a commercial VPN box.
That doesn't really make much sense either. If you can move the VM to another machine... if not you'd want to have tested this prior to going remote. In reality it seems very rare for a simple system, like a VPN, to go not come back up when a hypervisor reboots.
-
@coliver said in virtualize all the things... ?:
@emad-r said in virtualize all the things... ?:
The only thing I can think of you may not want to virtualize is VPN server.
cause if you want to reboot the Host hypervisor for whatever reason (maybe shutdown by disaster and not choice), it is bit tricky to diagnose and running when you cant connect especially if your working from home.I reckon the AMD AM1 platform is an excellent platform for VPN server, especially if you get motherboard that gets charged using laptop charger (AM1H-ITX) you are free to experiment and deploy whatever VPN solution you want , or purchase a commercial VPN box.
That doesn't really make much sense either. If you can move the VM to another machine... if not you'd want to have tested this prior to going remote. In reality it seems very rare for a simple system, like a VPN, to go not come back up when a hypervisor reboots.
True it is very simple, but still there is risk like when power outages occurs and stuff like that. If you lost the VPN you no longer can access, thus in my mind separating it, seems like good idea. And will make my work on Hosts and updating the servers much easier, especially since its not VM and I dont have to worry about it (shutting down). But yes I understand what you mean with careful operation there shouldn't be any issues of it being an VM machine after all.
Imagine you want to patch ESXi, and you are connected via VPN VM running in that same ESXi host. And we dont have like 300 servers, more like 1-2 server per site. so you understand how difficult it can become.
-
@emad-r said in virtualize all the things... ?:
@coliver said in virtualize all the things... ?:
@emad-r said in virtualize all the things... ?:
The only thing I can think of you may not want to virtualize is VPN server.
cause if you want to reboot the Host hypervisor for whatever reason (maybe shutdown by disaster and not choice), it is bit tricky to diagnose and running when you cant connect especially if your working from home.I reckon the AMD AM1 platform is an excellent platform for VPN server, especially if you get motherboard that gets charged using laptop charger (AM1H-ITX) you are free to experiment and deploy whatever VPN solution you want , or purchase a commercial VPN box.
That doesn't really make much sense either. If you can move the VM to another machine... if not you'd want to have tested this prior to going remote. In reality it seems very rare for a simple system, like a VPN, to go not come back up when a hypervisor reboots.
True it is very simple, but still there is risk like when power outages occurs and stuff like that. If you lost the VPN you no longer can access, thus in my mind separating it, seems like good idea. And will make my work on Hosts and updating the servers much easier, especially since its not VM and I dont have to worry about it. But yes I understand what you mean with careful operation there shouldn't be any issues of it being an VM machine after all.
Virtualization should improve all of these things, not make them worse. That's part of the critical point as to why we always virtualize without exception - because it is free and improves our safety / reliability. It provides protection. Don't think of it as virtualiation, think of it as hardware abstraction and driver containment. It's a key provider of system stability - something that is exactly what you are trying to create here.
-
@emad-r said in virtualize all the things... ?:
Imagine you want to patch ESXi, and you are connected via VPN VM running in that same ESXi host. And we dont have like 300 servers, more like 1-2 server per site. so you understand how difficult it can become.
No, I still don't understand. You are talking about adding another server to accommodate the VPN. So you are talking purely about consolidation as a concern, which it is, and not at all about virtualization as a concern (which it is not.)
-
@scottalanmiller said in virtualize all the things... ?:
@emad-r said in virtualize all the things... ?:
... it is bit tricky to diagnose and running when you cant connect especially if your working from home.
That just exposes the fragility of LAN-based security.
Hehe, true but what to say it is simple.
-
@scottalanmiller said in virtualize all the things... ?:
@emad-r said in virtualize all the things... ?:
Imagine you want to patch ESXi, and you are connected via VPN VM running in that same ESXi host. And we dont have like 300 servers, more like 1-2 server per site. so you understand how difficult it can become.
No, I still don't understand. You are talking about adding another server to accommodate the VPN. So you are talking purely about consolidation as a concern, which it is, and not at all about virtualization as a concern (which it is not.)
Agree. Makes no sense. Move the VPN VM to another host before updating the original.
