• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Servers I Shouldn't VM?

Carlosinfl

Loves the juice
Joined
Sep 25, 2002
Messages
6,633
I was wondering in general when migrating your servers from physical to virtual, are there servers that I shouldn't virtualize due to performance issues? Obviously hardware and system utilization are main factors here but I'm just trying to see if it's a bad idea to virtualize my companies Linux mail server.

- 500 users
- no database (Oracle, MySQL, PostgreSQL)

It seems like my mail server is very basic and perhaps over kill for specific hardware.
 
Only thing I had an issue with was SQL but I'm not exposed to very large environments. Think most my SQL performance problems were around the shared iSCSI storage from the hosting provider and not ESX itself.
 
No server should explicitly be excluded from virtualizing.

If you have a physical server that is a quad core with 4GB of ram, and you have a VM with 4 virtual cores and 4GB of ram... whats the difference?

As long as you give the VM adequate resources you will be fine.
 
Having the resources on the host is the biggest thing. I tend to stay away from virtualizing databases though that is probably more due to my small environment than anything. (We have 5 hosts and 1 san)

I have also excluded my video trans coding servers but again I'm in a small environment and my trans coding servers have more resources than the VM hosts and are still at almost full load.
 
Virtualizing databases and Exchange works pretty well in vSphere 4.1. VMware has made a lot of improvements in that regard since 3.5.

But you still need to make sure you have the horsepower to handle it, specifically on the datastore side. How much storage do you need? How many IOPs can your SAN handle? What kind of bandwidth do you need? How easily can you expand or upgrade if you discover you've outgrown your SAN?

How you're going to back up these high transaction VMs is important as well. I'd recommend Veeam Backup and Replication.
 
it all depends if you have the hardware, if you do, go nuts.

example, putting DC's with IIS and a say a file sharing server, is fine, but say putting 3-4 database servers with high I/O likely is not a smart thing to do.

also think, if that server goes down, do you have something to replace it?

your putting all your eggs in one basket so to speak, if a motherboard goes out... you loose more then 1 system...
 
You can virtualize almost any workload. It all comes down to your design and architecture. People skip this step. They take shortcuts. They figure "VMware is easy...I can do this myself." without any experience on doing a proper design. Then they move their Tier 1 workloads to virtualization and it fails..and they blame the hypervisor when that's not the problem.

CPU and memory are easy (though I strongly caution against 4 vCPUs). Usually it's storage that people miss. Too often I see people size storage for capacity, not performance and with the size of drives today it's almost always a case of sizing for performance. Do that and usually you have as much or more capacity than you need.

If you're going to use VMware go find a good local partner and ask them to perform a "Capacity Planner" on your environment. They should not charge you for this. We do them for free. It's a tool that runs on a server in your environment (or a workstation..doesn't matter) and it polls Linux and Windows servers every 30 to 60 secs for performance data. We usually run it at least a week, sometimes a month, and it comes back with the data we need to recommend storage and host sizing. Very useful, very easy, very low impact on your environment.

There are some very good benefits to virtualizing those Tier 1 or 2 applications. Take advantage of VMware HA. Take advantage of like Site Recovery Manager for DR failover. VMware FT in some cases. It just goes on...
 
also think, if that server goes down, do you have something to replace it?

your putting all your eggs in one basket so to speak, if a motherboard goes out... you loose more then 1 system...
Well..., no one in their right mind would migrate a number of physical servers to VMs to be run on a single physical host. If you want to go virtual for production you need at least two physical servers, all else is madness.
 
Yeah , clustered hosts is the way to go.

we run thousands of cisco ucs's here in the dc.



what do you run currently and why are you looking to go virtual?
 
Well..., no one in their right mind would migrate a number of physical servers to VMs to be run on a single physical host. If you want to go virtual for production you need at least two physical servers, all else is madness.

Poor small business sector should just close their doors if they cant' do this right!

lol.... while not untrue, sometimes just not realistic for small business space.
 
Poor small business sector should just close their doors if they cant' do this right!

lol.... while not untrue, sometimes just not realistic for small business space.

Even small business can do two servers for failover. I mean, obviously the idea is they are consolidating, right? Servers are cheap. vSphere Essentials Plus is cheap. If you're going to do virtualization you don't do it on one box for anything critical...if you can't do that then you only put utility servers on there that can be down until the system is repaired. No one is saying you need to go all out with Enterprise Plus.
 
Even small business can do two servers for failover. I mean, obviously the idea is they are consolidating, right? Servers are cheap. vSphere Essentials Plus is cheap. If you're going to do virtualization you don't do it on one box for anything critical...if you can't do that then you only put utility servers on there that can be down until the system is repaired. No one is saying you need to go all out with Enterprise Plus.

Please let me know your thoughts NetJunkie, I enjoy reading your blog and am venturing down this VM road myself.

My comment was based on virtualization of Small Business Server (AD/Exchange etc).

Having only one physical server with AD/Exchange on it vs. a VM with this is a wash at worst and in favor on virtualization in my opinion. Your eggs are still all in one basket either way just with VM there are more options in backup/DR/snapshots etc.

vSphere Essentials Plus is "cheap" depending on your budget (now that it's on sale!) but for me the SAN/shared storage is always the killer budget wise. I'm sure I am missing some options but a decent SAN seems to always be $8k+, $12k street price or more with dual controllers.

I know there are some VM appliances which can present DAS as a SAN, they just weird me out. My basic plan is:

1- VM the whole mess up
2. 2nd ESXi box, NAS, using Veeam replicate from ESXi1 to ESXi2 with storage on NAS (NFS share) and also backing up via Veeam to NAS (CIFS share)
3. SAN, VMware Essentials Plus. 3rd ESXi box (needed for FT?)

I'd like to get VMware Essentials Plus in there at step 2 but without vStorage (?) moving the machines from ESXi1/DAS to the NAS/NFS ain't happening with vmotion to my limited understanding. Need the SAN in place for all that luvin.

4. replicate to a cloud ESXi service
5. Take ESXi1 with DAS and move it to a colo for hot spare site, replicate to it removing the cloud service

Basically address HA/FT then DR
 
Essentials Plus doesn't do FT so no worries there:

http://www.vmware.com/products/vsphere/buy/small_business_editions_comparison.html

You need shared storage to do Storage vMotion (or regular vMotion) but you can move systems offline no problem. You just copy the VM files and re-add to inventory with the VM powered down.

I like Veeam backup and replication. It's a very good product and not expensive. That's a very good start. Go find a good local EMC partner and have them price you a VNXe array...or PM me and I'll quote you one and we can do the install remotely. :)
 
I think the issue comes down to management not wanting to spend the money on 2 servers, as cheap as they can be.. often management can be even "cheaper" and think "oh, you can do it all on one server, that is all you need"
 
These are ones I personally would not virtualize:

- File: This is mostly to save on disk i/o, a file server is basically a very large raw piece of storage, why waste expensive SAN space. You want lot of space, more then you want speed. aka standard server drives should be ok.
- Mail: Lot of disk I/O and overall resource usage, best to keep it off the vm environment
- High traffic DB (ex: if you have one DB server for everything) : same as above
- Primary DC (have a backup one virtualized) : This is debatable and may vary per environment. But basically the idea is if you have a highly redundant server as your DC, if your cluster goes down (there are more points of failure) then at least users are still authenticating to the domain. Good idea to have a backup DC virtualized too though but the physical one should be the primary (aka: one with FSMO roles)

Where I work all of these are virtualized but the primary DC, so it's not a crime to do it, just my opinion.
 
Essentials Plus doesn't do FT so no worries there:

http://www.vmware.com/products/vsphere/buy/small_business_editions_comparison.html

You need shared storage to do Storage vMotion (or regular vMotion) but you can move systems offline no problem. You just copy the VM files and re-add to inventory with the VM powered down.

I like Veeam backup and replication. It's a very good product and not expensive. That's a very good start. Go find a good local EMC partner and have them price you a VNXe array...or PM me and I'll quote you one and we can do the install remotely. :)

I use Veeam for our smaller offices (DC, Exch, File/Print). Backup onsite to a physical backup server and replicate them back to the datacenter incase something blows up. Only have one physical ESXi box out at the locations with local disk as it wasn't worth the cost to put a second box out there, especially when we can fire the replicas up should we have any issues.

Also have a 2 box cluster with local disk using SvSAN which allows you to use storage vMotion, haven't had any issues except doing firmware updates for SvSAN you need to take the entire thing offline. It basically mirrors the two guests which have all the local disk and allows you to use it as iSCSI disk. If you have newer hardware, you can use direct i/o for the disk instead of using guests.
 
Same for me with DC's

i have 2 physical DC's boxes running, but i also made a 3rd in a VM just incase the other 2 physical ones ever go down, i know i am still good to go!
 
there are always exceptions to the rule. I know for a fact I've done several standalone esxi installs, for the simple reason of abstracting the OS from the physical hardware. I did this at our branch sites at a previous job, where before, it was a single physical. Now its an esxi standalone server, perhaps with more than one virtual server on it depending on location. In those instances, you don't need failover or redundancy, in fact, we could recover by building a new VM in our prod environment and booting that up + a restore, while someone else hit the road to go replace the physical box. The money wasn't there to justify two servers. A single standalone pushed some of these sites to the brink on their budget. Hell some of these places had less than 20 people doing simple customer facing services ... many of those services didn't require the local branch server to operate. I just don't think you can say there is never a justification for only having one server.
 
These are ones I personally would not virtualize:

- File: This is mostly to save on disk i/o, a file server is basically a very large raw piece of storage, why waste expensive SAN space. You want lot of space, more then you want speed. aka standard server drives should be ok.
- Mail: Lot of disk I/O and overall resource usage, best to keep it off the vm environment
- High traffic DB (ex: if you have one DB server for everything) : same as above
- Primary DC (have a backup one virtualized) : This is debatable and may vary per environment. But basically the idea is if you have a highly redundant server as your DC, if your cluster goes down (there are more points of failure) then at least users are still authenticating to the domain. Good idea to have a backup DC virtualized too though but the physical one should be the primary (aka: one with FSMO roles)

Where I work all of these are virtualized but the primary DC, so it's not a crime to do it, just my opinion.

File...that one I get. But also often we do unified I/O arrays where the NAS/SAN array does CIFS and NFS directly so there are no standalone file servers. Just works better.

High I/O is NOT a reason to keep a box physical. There is no reason you can't do very high I/O workloads in a VM. Mail and DB are easy. It's all about IOPS. They do small transactions..they aren't throughput heavy..and really the key is response time. Just build the proper storage backend like you would ANYWAY with a physical deployment.

No reason not to virtualize all your DCs if you have a multi-host virtualization infrastructure. Nothing should ever take down all your physical hosts outside of a physical site failure.
 
Oh not saying you can't do high I/O, but if you don't have a huge cluster with tons of horse power, then it may be cheaper to get a dedicated box for a high I/O application to avoid bogging down the whole cluster and then have to add more hosts. Of course you can always add limits too. For a large cluster, then yeah it's not really an issue, especialy if you are at the point of teamed gigabit nics and so on.
 
Oh not saying you can't do high I/O, but if you don't have a huge cluster with tons of horse power, then it may be cheaper to get a dedicated box for a high I/O application to avoid bogging down the whole cluster and then have to add more hosts. Of course you can always add limits too. For a large cluster, then yeah it's not really an issue, especialy if you are at the point of teamed gigabit nics and so on.

Eh..well...a high I/O box will only impact the VMs on that same box, not the whole cluster. So be smart, use anti-affinity rules if needed, and just architect it correctly.
 
NetJunkie what is your opinion on high cpu load servers. The applications I have on my servers are video transcoding applications. They will use every bit of cpu power you give them. I have servers with 24 threads and 32 gigs of ram that get run to their limit so they are physical boxes. I'm just wondering your opinion of virtualizing such systems.
 
NetJunkie what is your opinion on high cpu load servers. The applications I have on my servers are video transcoding applications. They will use every bit of cpu power you give them. I have servers with 24 threads and 32 gigs of ram that get run to their limit so they are physical boxes. I'm just wondering your opinion of virtualizing such systems.

Problem here is your limited to 8 vCPUs per VM. I have customers that do 1 VM on a physical host for intense apps they want to virtualize for HA and DR reasons..but usually 8 vCPUs is enough. If you're currently on a quad-socket 6-core setup with 24 cores then you can't match that in a VM.
 
Problem here is your limited to 8 vCPUs per VM. I have customers that do 1 VM on a physical host for intense apps they want to virtualize for HA and DR reasons..but usually 8 vCPUs is enough. If you're currently on a quad-socket 6-core setup with 24 cores then you can't match that in a VM.

Is that a VMware limit?

Edit: Scratch that thought^
 
Problem here is your limited to 8 vCPUs per VM. I have customers that do 1 VM on a physical host for intense apps they want to virtualize for HA and DR reasons..but usually 8 vCPUs is enough. If you're currently on a quad-socket 6-core setup with 24 cores then you can't match that in a VM.

Thanks that was my thought too. I fought the battle and won to keep these apps on physical machines. In fact its staritng to look like I could use a bigger box.
 
Interesting but I think I'll keep my physical clusters for my transcoding

Probably easier that way, at least until the hypervisors get a bit more mature for that many vCPU's; well for "official" support at least. :)

The most I've ever given to a virtual 2003 Server R2 was 16 vCPU's without issue. :)
 
Back
Top