Information Systems:Server Virtualization Planning

Overview

This article is a drawing board or "pinterest" for the server virtualization project. The phases loosely represent periods of time where there was concentrated effort put into the project i.e. ~2015-2016 for initial discussions prior to training, 2017 for discussion throughout training etc.

Discussion

Phase 1 Planning

This was written before VMware training. -norwizzle (talk)

Windows Server licensing

• Datacenter is very expensive, but entitles us to unlimited virtual instances on a single machine with two processors.
• Standard edition allows for 2 virtual instances
  • Worth checking to see if our Standard licenses can each convert to two virtual licenses.

Hardware

• 2 hosts
• 10-14 core processors most ideal
• SAN - this will be a major decision
  • Shared storage is not required for vMotion - which is being able to migrate a virtual machine to another server.
  • Shared storage, however, is required for high availability i.e. seamless machine failover
    • This would be a nice thing to have, but our servers don't need this kind of 100% uptime. Or rather, the ones that do will not be virtualized.
  • SANs are very expensive, but if we do consider one, there is a little relief in the fact that we won't need a huge amount of GB for each virtual machine.

VMware vSphere

For clarity:

• vSphere is the virtualization software package
  • ESX/ESXi is the hypervisor
  • vMotion, vCenter are features of vSphere

• There are two main licensing categories: Essentials and Operations Management

This is another major decision that has a significant impact going forward

• • Essentials entitles you to three hosts, or 6 CPUs, but you will not be able to expand beyond this without practically purchasing a new license altogether.
  • Essentials Plus (which is what we would consider if we went the Essentials route), entitles us to vMotion.

Phase 2 Planning

Ideas throughout VMware training:

• It is apparent that this project still carries the potential to be very expensive. That is my main concern halfway through the training - that the expense of implementation might exceed the value savings of virtualization. Scale needs to be a major factor during implementation planning, otherwise it will make more sense to not virtualize, and just replace physical servers at the current rate of replacement. -norwizzle (talk)

• The areas that need to be scrutinized for cost are:

1. Storage: Shared or local storage? If shared, fibre channel can be ruled out - it makes sense with an existing FC infrastructure, but it's too expensive to get going from scratch. Right now it's shared SAS or iSCSI. Being a networking guy, I'd love to do iSCSI. Ipso facto, I'd hate to deal with the mess of downtime that's network-related crippling the entire server infrastructure at the same time.
   • There is actually a big case here for scrapping the idea of shared storage, and just using local storage i.e. redundant arrays on each host. The new-ish vSphere feature that makes local storage a feasible idea is cross-host vMotion. Along with cold-migration, this may be all we need to meet or even exceed the current level of service provided by our current infrastructure.

1. vSphere license: Essentials Plus still appears to be the right flavor for us. No DRS, no FT, no Distributed Switch, but it does have vMotion (although no storage vMotion). This license allows for 3 hosts.

1. Host configuration: We definitely want two hosts for redundancy, but with 12-core CPUs, I'm not sure if we'll need dual CPUs per host. RAM can be scaled back too. Perhaps 64GB per host. Overprovisioning resources to VMs seems to be a standard practice anyways, and our compute needs are consistent (not fluctuating).

• Deploying VMware vSphere (actually, doing virtualization in general) raises the baseline for high-availability/redundancy i.e. virtualizing an entire infrastructure immediately makes it more redundant and better able to cope with downtime (planned or disaster-related). However, HA/DR has many faces, and it will be important to weed out the features that either are not feasible or not ideal in our infrastructure, so we can establish that "baseline". For example, the following features are likely not a good fit:

1. vSphere HA: This feature is a maybe, or fits under "would be nice". But 'compute HA' is not something we currently have anyway. Requires shared storage.
2. vSphere FT: Requires multiple copies of the virtual machine. High computer overhead. We do not require the level of uptime afforded by this feature.
3. vSphere Replication/Data Protection: These are separate products, and may be better considered down the road, if we feel the need to backup virtual machines off-site.