pooling."/>
FIGURE 1.14 Shared resource pooling
The hypervisor's job is to virtualize the host's CPUs, memory, network interfaces, and—if applicable—storage (more on storage in a moment). Let's briefly go over how the hypervisor virtualizes CPU, memory, and network interfaces.
On any given host, there's a good chance that the number of VMs will greatly outnumber the host's physical CPU cores. Therefore, the hypervisor must coordinate or schedule the various threads run by each VM on the host. If the VMs all need to use the processor simultaneously, the hypervisor will figure out how to dole out the scarce CPU resources to the VMs contending for it. This process is automatic, and you'll probably never have to think about it. But you should know about another “affinity” term that's easy to confuse with hypervisor affinity: CPU affinity. CPU affinity is the ability to assign a processing thread to a core instead of having the hypervisor dynamically allocate it. A VM can have CPU affinity enabled, and when a processing thread is received by the hypervisor, it will be assigned to the CPU it originally ran on. You're not likely to see it come up on the exam, but just be aware that CPU affinity can and often does result in suboptimal performance, so it's generally best to disable it. A particular CPU assigned to a VM can have a very high utilization rate while another CPU might be sitting idle; affinity will override the hypervisor's CPU selection algorithms and be forced to use the saturated CPU instead of the underutilized one.
Now let's talk about random access memory (RAM). Just as there are a limited number of CPU cores, so there is a finite amount of RAM installed in the physical server. This RAM is virtualized by the hypervisor software into memory pools and allocated to virtual machines. When you provision a VM, you choose the amount of RAM to allocate to it. Unlike the CPU, which is shared, RAM is not. Whatever RAM you allocate to a VM is dedicated to that VM, and no other VM can access it. When a VM consumes all of its allocated RAM, it will begin to swap the contents of some of its RAM to storage. This swap file, as it is called, will be used as virtual RAM. When configuring a VM, be sure to allocate enough storage space for the swap file, and keep in mind that the storage latency of the swap file will have a negative impact on the performance of the VM.
Thus far, we've discussed compute pools from the perspective of an IaaS model. But how do compute pools work with PaaS or SaaS models? Behind the scenes, almost everything's the same. What's different is that in the PaaS and SaaS models, the cloud provider runs a user-friendly interface atop the underlying compute infrastructure. For example, if the cloud provider is offering hosted email as a service, that email system gets its computing power from the same compute pools that power the IaaS infrastructure. In fact, every service under the PaaS or SaaS model that the provider offers probably runs directly on the same IaaS infrastructure that we've been discussing. In other words, cloud providers don't reinvent the wheel for every service that they provide. They build the compute infrastructure to provide the compute pools, and everything else uses those.
Network Pools
Cloud providers also virtualize and pool network resources. If you're not familiar with the details of networking, what happens behind the scenes can be a bit difficult to grasp, so we'll start in familiar territory.
The term network is a loaded term because its meaning varies with context. Generally, a network is the infrastructure that allows communication between computing resources, such as two servers or an end user and a server. That much you already know, but here's where it gets complicated. In the cloud, there are two different levels of networking:
The Underlay The underlying network (or underlay) consists of the physical network infrastructure that the cloud provider completely manages. This is transparent to you, and you have no visibility into it whatsoever.
The Overlay The cloud provider allows customers to create and manage virtual networks that run atop the provider's underlying network. These are sometimes called overlay networks or virtual private clouds (VPCs). Virtual networks are what you'll actually work with and connect your cloud resources to. In simple terms, a VPC is a private, software-defined network that exists in the cloud.
A virtual network consists of, at a minimum, a block of private IP addresses to be assigned to VMs and other network resources, such as DNS and DHCP servers. A virtual network can span multiple physical hosts—a VM running on one host can communicate with another VM running on a different host, as if they were on the same subnet. Naturally, you can connect a virtual network to an external network such as the Internet or a corporate network via a VPN.
It's important to understand that networking in the cloud operates quite differently than what you'll find in a traditional data center. In a data center, a VM's virtual network interface card (vNIC) typically connects to a virtual switch (vSwitch) that's associated with one or more physical network interfaces on the host. Each VM can be connected to a different virtual LAN (VLAN) for traffic segmentation. In this virtual switching paradigm, configuring VM networks is a mostly manual task, so the network configuration remains relatively fixed. Without getting into too many details, this inflexibility is due to the limitations of Ethernet. Additionally, such networks are limited to a maximum of about 1 million devices, which is more than enough for a data center but woefully lacking for a cloud provider that may need to support hundreds of millions of VMs.
If you have an application that depends on Ethernet broadcast functionality, it probably won't work in the cloud. Ethernet broadcasts pose a hindrance to scalability in the cloud, so cloud providers generally don't support them.
When you create a virtual network in the cloud, the cloud provider's orchestration platform handles the details of the behind-the-scenes connectivity. For example, suppose that you're running two VMs connected to the same virtual network. These VMs may be on different physical hosts and even in different geographic locations, but they can still communicate. The important point here is that you don't need to know anything about the underlying network infrastructure. All you have to do is to create and configure a virtual network and connect your resources to it, and you're good to go. Just as the provider's proprietary orchestration software automatically picks what server to run your VMs on, so too it dynamically handles connectivity among devices on your virtual networks. This is another example of that “minimal management effort or service provider interaction” qualification that defines cloud computing.
Storage Pools
When you think of the term storage, you might think of files on a drive. That's one example of storage that most people are familiar with because it's how our daily-use computers store files. But in the cloud, you'll encounter three different types of storage:
Block storage
Object/file storage
Filesystem storage
Regardless of the storage type, in the cloud data is redundantly replicated across multiple physical devices that compose a storage pool. Having data distributed across a storage pool allows the cloud provider to achieve exceptionally high read and write speeds.
Block Storage Block storage is designed to mimic a drive by storing data in the same way that a drive does. The virtual disks' (vDisks) VMs used to store data are backed up by block storage. In the data center, a storage area network (SAN) device is what provides block storage. A SAN consists of a collection of redundant drives (either spinning disks or SSDs) that store data in blocks, hence the term
