IN THIS CHAPTER

check Examining the basics of virtualization

check Looking at what a hypervisor does

check Considering how disks and networks are virtualized

check Weighing the benefits of virtualization

check Choosing host servers

check Considering how virtualization affects Microsoft licensing for Windows Server

Virtualization is one of the hottest trends in networking today. According to some industry pundits, virtualization is the best thing to happen to computers since the invention of the transistor. If you haven’t already begun to virtualize your network, you’re standing on the platform watching as the train is pulling out.

This chapter introduces you to the basic concepts of virtualization, with an emphasis on using it to leverage your network server hardware to provide more servers using less hardware. Virtualization can dramatically simplify the design of your network — you can support more servers on less hardware, and with less hardware, your network will have fewer interconnects that link servers to the private network. Win, win!

Mastering a virtualization environment calls for a book of its own. I recommend two titles, both from John Wiley & Sons, Inc.: Virtualization For Dummies, by Bernard Golden, and VMware Infrastructure 3 For Dummies, by William Lowe (no relation, honest).

Understanding Virtualization

The basic idea behind virtualization is to use software to simulate the existence of hardware. This powerful idea enables you to run more than one independent computer system on a single physical computer system. Suppose that your organization requires a total of 12 servers to meet its needs. You could run each of these 12 servers on a separate computer, in which case you would have 12 computers in your server room. Or, you could use virtualization to run these 12 servers on just two computers. In effect, each of those computers would simulate six separate computer systems, each running one of your servers.

Each of the simulated computers is called a virtual machine (VM). For all intents and purposes, each VM appears to be a complete, self-contained computer system with its own processor (or, more likely, processors), memory, disk drives, CD-ROM/DVD drives, keyboard, mouse, monitor, network interfaces, USB ports, and so on.

Like a real computer, each virtual machine requires an operating system to do productive work. In a typical network server environment, each virtual machine runs its own copy of Windows Server. The operating system has no idea that it’s running on a virtual machine rather than on a real machine.

Here are a few terms you need to be familiar with if you expect to discuss virtualization intelligently:

Host: The actual physical computer on which one or more virtual machines run. Admittedly, this term is kind of confusing, because it’s also used to refer to any device that is connected to the network, such as an end-user computer. Context is everything — when discussing servers, host usually means the physical computer that virtual servers run on.
Bare metal: Another term for the host computer that runs one or more virtual machines.
Guest: Another term for a virtual machine running on a host.
Guest operating system: An operating system that runs within a virtual machine. By itself, a guest is just a machine; it requires an operating system to run. The guest operating system is what brings the guest to life.

As far as licensing is concerned, Microsoft treats each virtual machine as a separate computer. Thus, if you run six guests on a single host, and each guest runs Windows Server, you need licenses to run six servers. Unfortunately, figuring out how to ensure that you have the right number of licenses can be a bit complicated; see the section “Understanding Windows Server 2016 Licensing” later in this chapter for an explanation.
Hypervisor: The virtualization operating system that creates and runs virtual machines. For more information about hypervisors, read the next section, “Understanding Hypervisors.”
Hardware Abstraction Layer (HAL): A layer of software that acts as a go-between to separate actual hardware from the software that interacts with it. An operating system provides a hardware abstraction layer, because it uses device drivers to communicate with actual hardware devices so that software running in the operating system doesn’t have to know the details of the specific device it’s interacting with. A hypervisor also provides a hardware abstraction layer that enables the guest operating systems in virtual machines to interact with virtualized hardware.

Understanding Hypervisors

At the core of virtualization is a hypervisor, a layer of software that manages the creation and execution of virtual machines. A hypervisor provides several core functions:

It provides a HAL, which virtualizes all the hardware resources of the host computer on which it runs. This includes processor cores, RAM, and I/O devices such as disk drives, keyboards, mice, monitors, USB devices, and so on.
It creates pools of these abstracted hardware resources that can be allocated to virtual machines.
It creates virtual machines, which are complete implementations of an idealized computer system that has the hardware resources of the host available to it. The hardware for each virtual machine is drawn from the pools of available hardware resources managed by the hypervisor.
It manages the execution of its virtual machines, allocating host hardware resources as needed to each virtual machine and starting and stopping virtual machines when requested by users.
It ensures that each virtual machine is completely isolated from all other virtual machines, so that if a problem develops in one virtual machine, none of the other virtual machines is affected.
It manages communication among the virtual machines over virtual networks, enabling the virtual machines to connect with each other and with a physical network that reaches beyond the host.

There are two basic types of hypervisors you should know about:

Type-1: A type-1 hypervisor runs directly on the host computer, with no intervening operating system. This is the most efficient type of hypervisor because it has direct access to the hardware resources of the host system.

The two best-known examples of type-1 hypervisors are VMware’s ESXi and Microsoft’s Hyper-V. ESXi is part of a suite of popular virtualization products from VMware, and Hyper-V is the built-in virtualization platform that is included with recent versions of Windows Server.
Type-2: A type-2 hypervisor runs as an application within an operating system that runs directly on the host computer. Type-2 hypervisors are less efficient than type-1 hypervisors because when you use a type-2 hypervisor, you add an additional layer of hardware abstraction: the first provided by the operating system that runs natively on the host, and the second by the hypervisor that runs as an application on the host operating system.

For production use, you should always use type-1 hypervisors because they’re much more efficient than type-2 hypervisors. Type-1 hypervisors are considerably more expensive than type-2 hypervisors, however. As a result, many people use inexpensive or free type-2 hypervisors to experiment with virtualization before making a commitment to purchase an expensive type-1 hypervisor.

THE LONG TREK OF VIRTUALIZATION

Kids these days think they invented everything, including virtualization.

Little do they know.

Virtualization was developed for PC-based computers in the early 1990s, around the time Captain Picard was flying the Enterprise around in Star Trek: The Next Generation.

But the idea is much older than that.

The first virtualized server computers predate Captain Picard by about 20 years. In 1972, IBM released an operating system called simply VM, which had nearly all the basic features found in today’s virtualization products.

VM allowed the administrators of IBM’s System/370 mainframe computers to create multiple independent virtual machines, each of which was called (you guessed it) a virtual machine, or VM. This terminology is still in use today.

Each VM could run one of the various guest operating systems that were compatible with the System/370 and appeared to this guest operating system to be a complete, independent System/370 computer with its own processor cores, virtual memory, disk partitions, and input/output devices.

The core of the VM system itself was called the hypervisor — another term that persists to this day.

The VM product that IBM released in 1972 was actually based on an experimental product that IBM released on a limited basis in 1967.

So whenever someone tells you about this new technology called virtualization, you can tell him or her that it was invented when Star Trek was on TV. When someone asks, “You mean the one with Picard?” you can say, “No, the one with Kirk.”

Understanding Virtual Disks

Computers aren’t the only things that are virtualized in a virtual environment. In addition to creating virtual computers, virtualization also creates virtual disk storage. Disk virtualization lets you combine a variety of physical disk storage devices to create pools of disk storage that you can then parcel out to your virtual machines as needed.

Virtualization of disk storage is nothing new. In fact, there are actually several layers of virtualization involved in any disk storage environment. At the lowest level are the actual physical disk drives. Physical disk drives are usually bundled together in arrays of individual drives. This bundling is a type of virtualization in that it creates the image of a single large disk drive that isn’t really there. For example, four 2TB disk drives might be combined in an array to create a single 8TB disk drive.

Note that disk arrays are usually used to provide data protection through redundancy. This is commonly called RAID, which stands for Redundant Array of Inexpensive Disks.

One common form of RAID, called RAID-10, lets you create mirrored pairs of disk drives so that data is always written to both of the drives in a mirror pair. So, if one of the drives in a mirror pair fails, the other drive can carry the load. With RAID-10, the usable capacity of the complete array is equal to one-half of the total capacity of the drives in the array. For example, a RAID-10 array consisting of four 2TB drives contains two pairs of mirrored 2TB disk drives, for a total usable capacity of 4TB.

Another common form of RAID is RAID-5, in which disk drives are combined and one of the drives in the group is used for redundancy. Then, if any one of the drives in the array fails, the remaining drives can be used to re-create the data that was on the drive that failed. The total capacity of a RAID-5 array is equal to the sum of the capacities of the individual drives, minus one of the drives. For example, an array of four 2TB drives in a RAID-5 configuration has a total usable capacity of 6TB.

In a typical virtual environment, the host computers can be connected to disk storage in several distinct ways:

Local disk storage: In local disk storage, disk drives are mounted directly into the host computer and are connected to the host computer via its internal disk drive controllers. For example, a host computer might include four 1TB disk drives mounted within the same chassis as the computer itself. These four drives might be used to form a RAID-10 array with a usable capacity of 2TB.

The main drawbacks of local disk storage is that it’s limited to the physical capacity of the host computers and is available only to the host computer that it’s installed in.
Storage Area Network (SAN): In a SAN, disk drives are contained in a separate device that is connected to the host via a high-speed controller. The difference between a SAN and local storage is that the SAN is a separate device. Its high-speed connection to the host is often just as fast as the internal connection of local disk storage, but the SAN includes a separate storage controller that is responsible for managing the disk drives.

A typical SAN can hold a dozen or more disk drives and can allow high-speed connections to more than one host. A SAN can often be expanded by adding one or more expansion chassis, which can contain a dozen or more disk drives each. Thus, a single SAN can manage hundreds of terabytes of disk data.
Network Accessible Storage (NAS): This type of storage is similar to a SAN, but instead of connecting to the hosts via a high-speed controller, a NAS connects to the host computers via standard Ethernet connections and TCP/IP. NAS is the least expensive of all forms of disk storage, but it’s also the slowest.

Regardless of the way the storage is attached to the host, the hypervisor consolidates its storage and creates virtual pools of disk storage typically called data stores. For example, a hypervisor that has access to three 2TB RAID-5 disk arrays might consolidate them to create a single 6TB data store.

From this data store, you can create volumes, which are essentially virtual disk drives that can be allocated to a particular virtual machine. Then, when an operating system is installed in a virtual machine, the operating system can mount the virtual machine’s volumes to create drives that the operating system can access.

For example, let’s consider a virtual machine that runs Windows Server. If you were to connect to the virtual machine, log in, and use Windows Explorer to look at the disk storage that’s available to the machine, you might see a C: drive with a capacity of 100GB. That C: drive is actually a 100GB volume that is created by the hypervisor and attached to the virtual machine. The 100GB volume, in turn, is allocated from a data store, which might be 4TB in size. The data store is created from disk storage contained in a SAN attached to the host, which might be made up of a RAID-10 array consisting of four 2TB physical disk drives.

So, you can see that there are at least four layers of virtualization required to make the raw storage available on the physical disk drives available to the guest operating system:

Physical disk drives are aggregated using RAID-10 to create a unified disk image that has built-in redundancy. RAID-10 is, in effect, the first layer of virtualization. This layer is managed entirely by the SAN.
The storage available on the SAN is abstracted by the hypervisor to create data stores. This is, effectively, a second level of virtualization.
Portions of a data store are used to create volumes that are then presented to virtual machines. Volumes represent a third layer of virtualization.
The guest operating system sees the volumes as if they’re physical devices, which can be mounted and then formatted to create usable disk storage accessible to the user. This is the fourth layer of virtualization.

Although it may seem overly complicated, these layers of virtualization give you a lot of flexibility when it comes to storage management. New disk arrays can be added to a SAN, or a new NAS can be added to the network, and then new data stores can be created from them without disrupting existing data stores. Volumes can be moved from one data store to another without disrupting the virtual machines they’re attached to. In fact, you can increase the size of a volume on the fly, and the virtual machine will immediately see the increased storage capacity of its disk drives, without even requiring so much as a reboot.

Considering the Benefits of Virtualization

You might suspect that virtualization is inefficient because a real computer is inherently faster than a simulated computer. Although it’s true that real computers are faster than simulated computers, virtualization technology has become so advanced that the performance penalty for running on a virtualized machine rather than a real machine is only a few percent.

The small amount of overhead imposed by virtualization is usually more than made up for by the simple fact that even the most heavily used servers spend most of their time twiddling their digital thumbs, waiting for something to do. In fact, many servers spend nearly all their time doing nothing. As computers get faster and faster, they spend even more of their time with nothing to do.

Virtualization is a great way to put all this unused processing power to good use.

Besides this basic efficiency benefit, virtualization has several compelling benefits:

Hardware cost: You typically can save a lot of money by reducing hardware costs when you use virtualization. Suppose that you replace ten servers that cost $4,000 each with one host server. Granted, you’ll probably spend more than $4,000 on that server, because it needs to be maxed out with memory, processor cores, network interfaces, and so on. So you’ll probably end up spending $15,000 or $20,000 for the host server. Also, you’ll end up spending something like $5,000 for the hypervisor software. But that’s still a lot less than the $40,000 you would have spent on ten separate computers at $4,000 each.
Energy costs: Many organizations have found that going virtual has reduced their overall electricity consumption for server computers by 80 percent. This savings is a direct result of using less computer hardware to do more work. One host computer running ten virtual servers uses approximately one-tenth the energy that would be used if each of the ten servers ran on separate hardware.
Reduced downtime: Virtual environments typically have less downtime than nonvirtual environments. For example, suppose you need to upgrade the BIOS on one of your server computers. With physical servers, this type of upgrade will ordinarily require that you shut down the operating system that runs on the server, upgrade the BIOS, and then restart the server. During the upgrade, the server will be unavailable.

In a virtual environment, you don’t need to shut down the servers to upgrade the BIOS on the host computer that runs the server. Instead, all you do is move the servers that run on the host that needs the upgrade to another host. When the servers are moved (an operation that can be done without shutting them down), you can shut down the host and upgrade its BIOS. Then, after you restart the host, you can move the servers back to the host — again, without shutting down the servers.
Recoverability: One of the biggest benefits of virtualization isn’t the cost savings, but the ability to recover quickly from hardware failures. Suppose that your organization has ten servers, each running on separate hardware. If any one of those servers goes down due to a hardware failure — say, a bad motherboard — that server will remain down until you can fix the computer. On the other hand, if those ten servers are running as virtual machines on two different hosts, and one of the hosts fails, the virtual machines that were running on the failed host can be brought up on the other host in a matter of minutes.

Granted, the servers will run less efficiently on a single host than they would have on two hosts, but the point is that they’ll all be running after only a short downtime.

In fact, with the most advanced hypervisors available, the transfer from a failing host to another host can be done automatically and instantaneously, so downtime is all but eliminated.
Disaster recovery: Besides the benefit of recoverability when hardware failures occur, an even bigger benefit of virtualization comes into play in a true disaster-recovery situation. Suppose that your organization’s server infrastructure consists of 20 separate servers. In the case of a devastating disaster, such as a fire in the server room that destroys all hardware, how long will it take you to get all 20 of those servers back up and running on new hardware? Quite possibly, the recovery time will be measured in weeks.

By contrast, virtual machines are actually nothing more than files that can be backed up onto tape. As a result, in a disaster-recovery situation, all you have to do is rebuild a single host computer and reinstall the hypervisor software. Then you can restore the virtual-machine backups from tape, restart the virtual machines, and get back up and running in a matter of days instead of weeks.

Choosing Virtualization Hosts

Having made the decision to virtualize your servers, you’re next faced with the task of selecting the host computers on which you’ll run your virtual servers. The good news is that you need to purchase fewer servers than if you use physical servers. The not-so-good news is that you need to purchase really good servers to act as hosts, because each host will support multiple virtual servers. Here are some tips to get you started:

If possible, purchase at least two hosts, and make sure that each host is independently capable of running all your virtual servers. That way, if one of the hosts goes down, you can temporarily move all your servers to the good host while the bad one is being repaired. When both hosts are up, you can spread the workload across the two hosts for better performance.
Add up the amount of memory you intend to allocate for each server to determine the amount of RAM for each host. Then give yourself plenty of cushion. If your servers will require a total of 50GB of RAM, get 72GB on each host, for a total of 144GB if you have two hosts. That will give you plenty of room to grow.
Do a similar calculation for processor cores. It’s easier to oversubscribe processor cores on hosts than it is to oversubscribe memory. Like most computers, servers spend an enormous percentage of their time idling. Virtualization makes very efficient use of processor cores for a large number of servers.
Get the best network connections you can afford. Ideally, each host should have a pair of small form-factor pluggable (SFP) ports that you can run 10 Gb fiber over. That way, your hosts can communicate with the core switches at top speed.
Provide redundancy in the host’s subcomponents. Most hosts support two processors, two memory banks, two network interfaces, and two power supplies. That provides for a maximum of uptime.

Understanding Windows Server 2016 Licensing

When planning your server architecture, you’ll need to account for the fact that you must purchase sufficient licenses of Windows Server to cover all the servers you’re running. Before virtualization, this was easy: Each server required its own license. With virtualization, things get tricky — and Microsoft doesn’t make it easier by trying to simplify things.

Windows Server 2016 comes in three editions. These editions are as follows:

Standard Edition: Ideal for customers who aren’t virtualized or who are virtualized but have a relatively small number of servers (approximately 12 per host). Standard Edition costs $882 per license. Each license entitles you run two virtual machines, which seems like a heck of a deal. However, a major drawback is that the license is also limited to hosts that have a maximum of 8 cores per processor and two processors, for a total of 16 cores. If your host has more than 8 cores per processor or more than two processors, you’ll need additional licenses.
Datacenter Edition: Ideal for customers who are virtualized and have a large number of servers. Datacenter Edition costs $6,155 per license. Each license lets you run an unlimited number of virtual machines on a single host. Again, each host is limited to 8 cores per processor and two processors, for a total of 16 cores. If your host has more than 8 cores per processor or more than two processors, you’ll need additional licenses.
Essentials Edition: Designed for small businesses setting up their first server. It’s limited to just 25 users. I won’t consider this edition further here.

So, you’ve got to do some real math to figure out which licenses you’ll need. Let’s say you need to run a total of 16 servers on two hosts. Here are two licensing scenarios that would be permissible:

Purchase eight Standard Edition licenses, for a total of $7,056. That works out to just $441 per server. These licenses will allow you to run 16 virtual machines (two per license), as long as your hosts have fewer than 8 processors per core and two processors per host. If your hosts have more than that — say, 12 processors per core, you’ll need to purchase 16 Standard Edition licenses, for a total of $14,112, or $882 per server.
Purchase two Datacenter Edition licenses, for a total of $12,310. That works out to about $769 per server. This is more than the Standard Edition licenses would cost, but it allows you to run an unlimited number of servers. In contrast, additional Standard Edition servers will require additional licenses. As with Standard Edition, if your hosts have more than 8 cores per processor or two processors per host, you’ll have to purchase an additional license for each host, bringing the total to $24,620. That works out to about $1,539 per server.

It’s obvious that Microsoft charges more to run Windows Server on more powerful hosts, which makes for an interesting pricing strategy. As it turns out, over the next few years, you’ll be hard pressed to purchase hosts that fall below the single-license core limit of 8 cores per processor or two processors per host. That’s because Intel’s dual-socket Xeon processors are getting more and more cores with each successive generation. The current generation of Xeon processors sports up to 18 cores per processor. While Intel still makes 4-, 6-, and 8-core versions of the Xeon processor, who knows what the future will bring.

In any event, the per-core nature of Microsoft’s licensing encourages you to purchase host processors with cores as close to but below 8 per processor increments. In other words, use 8- or 16-core processors in your hosts; avoid 10- or 18-core processors, because they nudge you just over the core limits for licensing.