Types of Server Virtualization

Types of Server Virtualization in 2018

Since virtualization was well on it’s way to being one of the major items on most IT manager’s (and engineer’s) radar for past few years and this year looking to be more of the same but there are a lot of managers who do not even know about Types of Server Virtualization that actually exist. I have been conducting my own research into Types of Server Virtualization, what products and technologies do what, and how can I make use of this in my own environments. After about 5 months casual testing, and lots of personal time using different Types of Server Virtualization products for personal use, I have discovered some interesting factoids that might just save you some considerable time in your own virtualization research.

1. VMware is not the only vendor making quality virtualization products.

Vendors such as Oracle, Sun, VirtualBox, Parallels, Open Source (Xen) all have great solutions. If you have been either researching virtualization or have already integrated a virtualization solution into your 2018 IT planning you might think this is just common sense but I was surprised to discover how many folks were not aware that other vendors have been implementing both server and desktop virtualization solutions that perform just as well as VMware. I even had one self-proclaimed IT professional tell me that VMware “owns” the patent on virtualization….<not true>!

2. Server virtualization will not cure all your server consolidation & data centre problems.

I know, silly to think that anyone who even knows the tiniest bit of facts about virtualization would think this way but you would be surprised. Lots of managers and top-level executives simply just read the propaganda and think all will be cured by simply virtualizing everything in sight. The same kind of management trend was seen when “blade” servers were en vogue (you know who you are). Claims that blade servers would shrink and revolutionize the data centre went (as expected) unfulfilled for the vast majority of IT shops who tried to migrate to them. Virtualization is similar in that you need to understand what it can and cannot do before you consider integrating it into your data centre management strategy. Good example: Virtualizing your Windows Active Directory controllers that control your network access is not only wasteful but can actually be dangerous to your environment since it can remove the distributed and redundant nature of these systems (not to mention you might not get back into your systems if the host server goes down).

3. The performance of many applications will change when virtualized.

Don’t believe the hype, sometimes applications see a performance hit under virtualization. At the end of the day, you need to test (and test again) your applications in a good test environment before moving forward with any attempt to virtualize a platform or application. In my own testing, I found that disk intensive applications and high memory usage applications tended to not perform anywhere near-native performance while more mainstream applications such as Microsoft Sharepoint, Oracle (light to medium loads), MySQL, and many others performed close to or even slightly better under virtualization. One interesting side effect of virtualization is that most guest (the OS that has been “virtualized”) operating systems reboot in significantly less time, likely due to disk caching on the host OS.

4. Virtualization WILL significantly increase your storage requirements unless you tightly control things.

One of the really nice features of virtualization is the ability to rapidly create “test” or on-demand copies of a virtualized environments. The unfortunate side effect of this process is you can quickly end up with lots of copies eating up local disk space on the host machine. I recommend a two-fold approach in dealing with this; make users go through the same server request process for virtual machines that you would for physical hardware, and force users to store application data off local systems onto remote storage systems such as a SAN or NAS. One good technical strategy I found so far is to only allow your users (or whoever is generating the environments) to create virtual machines that have local disk images for the boot OS only. Have them map the data storage out to a SAN or NAS (or DAS for that matter) using ISCSI. VMware natively supports this and just about any product will allow for using this approach in the guest OS. What this does is eliminate the bad habit of storing application data locally inside each VM (virtual machine) wasting local storage and creating a backup nightmare.

5. Keeping usable backups of virtual machines is not as easy as you might think.

In order to implement a safe and dependable disaster recovery process for virtualized environments, you should follow some basic advice. Never rely on just snapshots, while useful they are not always 100% reliable and are prone to human error while inconvenient full backups can take systems offline during the backup they will more often result in easier restores later. Like I stated in #4, a good strategy is to keep your data on your SAN and the VMs on your host server and then develop a separate backup strategy for each.

Well, that’s enough on server virtualization, check back soon for my next post which will deal with virtualization on the desktop.

Leave a Reply

Your email address will not be published. Required fields are marked *