Meditech Magic originally written in the 1990's is one of those things that you would never think to virtualize. Why would you? It runs well on a Dell 2U server with a direct attached Power Vault and a direct attached tape drive. Sure that is early 1990's technology and it is probably time to replace your old servers with something made in the modern era to run this program from the 90's; but this is healthcare and margins are tight. So here is a rough how to guide on doing this...
Meditech will 'support' virtualizing their application on VMware ESX, but that support can be limiting to say the least. They will give it a best effort, meaning if you got a real puzzle and they are truly scratching their head they will ask you to 'un-virtualize' it and then they will continue. But really isn't that everyone's stance on a technology that first they don't really understand and one that they are scared of? Especially Dell/Perot/JJ Wild, they are afraid that you won't need their experience and help anymore, or that every 4 years you won't be dropping $200k for your 10 server deployment in hardware plus the countless hours of professional services to move your installation to that new hardware. While I am not giving you the blue prints to go and do this here are some gotchas and pointers.
First, Magic is network traffic HEAVY period; it is a network nightmare, UDP multi-cast with packet sizes ranging from 16 bytes to 400 bytes coming out at 4,000 to 6,000 a second on a lightly used machine. Attempt to put that in a TCP optimized vSwitch with a TCP optimized NIC driver, you can see the problem waiting to happen. Oh and not to mention that 90% of switches out there (including default vSwitches) are designed to block this traffic. So first of all you need to set the Magic vSwitches to Promiscuous Mode. Now since this turns the vSwitch into a vHub, you can only have Magic on this vSwitch; forget VLAN tagging, vHub will not obey that and will spill the traffic to everything on it; also anything on this vHub has to listen to everyone else on the vHub. This means if you have 2 Magic servers with 5,000 packets a second, each machine has to listen to 10,000 packets every second PLUS the real traffic that it actually needs to listen too. So promiscuous mode and a near 1 to 1 ratio of virtual guest to vHub/Physical NIC.
Second, Magic likes to have 2 vCPU's; yes best practice says fewer vCPU's will make a guest work better and be a better steward of the resources, but this is the 90's we are talking about and more is better. So 2 vCPU's and the SMP version of OSAL (9.0.43 is the latest as of this posting). Now there is no need to do resource scheduling or limiting on the Magic hosts, they are decent on the usage.
Third, density do not think that you are going to get a 10 to 1 or even a 8 to 1 consolidation; due to the networking traffic that the vmKernel has to deal with (remember 5,000 per second per machine) you will realistically get something around 4 to 1 or even a 5 to 1 if you have a light module count and don’t really hammer the system all day long.
If you have questions, feel free to email me with your questions.
Bookmark/Search this post with:
