Evolution of Virtualization and Cloud

While the preceding queries are explained with compute resources, these are all applicable for storage and network resources as well. Such CAPEX and OPEX challenges identified and raised by the IT professionals introduced the need for the new virtualization concept.

Basics of Virtualization

The concept of virtualization is the ability to abstract the physical characteristics of the underlying hardware to create a virtual environment and allow the user to instantiate virtual entities such as servers to utilize the available resources efficiently. The evolution of virtualization is as shown in Figure 6-1.

A timeline illustrates the evolution of computing technology. It comprises 1960 had high-cost computing. 1970, minicomputers. 1980, the evolution of client-server. 1990, server consolidation DISCO. 2000, server virtualization. 2015, cloud.

Note

While the concept of virtualization became very popular in the last couple of decades, the technique was explored in the early 1960s by the development of a virtualization hypervisor called Control Program by IBM.

In the early 1990s, Stanford University experts proposed the concept of running multiple operating systems sharing the same underlying hardware resources. In the late 1990s, VMware introduced a fully developed hypervisor that allows users to instantiate virtual machines running any guest operating system. This revolutionary introduction of hypervisor opened the gate for more innovation and development. Architecturally, virtualization can be classified into the following four types:

• Paravirtualization

• Full virtualization

• Hardware-assisted full virtualization

• Nested virtualization

A model diagram features 4 types of virtualization, Full, para, H W Assisted, and Nested Virtualization. The nested Virtualization layer has two layers of App, Guest O S with one Virtualization layer and Physical host.

Paravirtualization is the technique used earlier that requires customizing the operating system to be hosted as virtual machines. The customized operating system is capable of making custom resource requests to the underlying hardware. As it could be noted, this is not a scalable approach as this requires customizing every operating system and making it compatible with different types of underlying hardware resources.

Full virtualization, on the other hand, introduces the hypervisor that acts as a medium between the guest operating system and the underlying hardware resources. Full virtualization eliminates the need for customizing the operating system and drastically improves the types of OS hosted as virtual machines.

The hardware-assisted full virtualization approach introduces the capability of natively supporting the virtualization by the processors that significantly improve the performance of the hosted virtual machines. Most of the recent processors, including the latest Apple processors, support hardware-assisted full virtualization.

Nested virtualization is an approach that allows the installation of a hypervisor layer on top of an existing virtual machine, thereby enabling the users to host virtual machines on a virtual machine.

Note

Some of the processors may require additional firmware upgrades or patches to support hardware-assisted full virtualization. When a virtual machine is instantiated on a host without hardware assistance, the performance is degraded, resulting in a poor user experience.

Hypervisor – Definition and Types

The hypervisor is a layer of software that abstracts the underlying hardware and partitions the resources such as CPU, memory, and storage into an isolated virtual environment and associates the same to different hosted virtual machines. The physical machine where the hypervisor is installed is commonly referred to as the host machine. The virtualization stack comprises multiple components with its unique functionality, such as

• Managing the underlying hardware and emulating virtual instances of CPU (vCPU), memory (vMem), and storage (vStorage)

• Managing the hypercall request for underlying hardware resources from the guest operating system

• Managing and scheduling the work on virtual processors across the host

In short, the hypervisor will emulate the virtual resources and manage the hypercalls from the hosted guest operating system to the underlying hardware to execute the relevant functionalities. There are two different types of hypervisors as follows:

• Type 1 Hypervisor (native)

• Type 2 Hypervisor (hosted)

A stacked block diagram from bottom to top, physical host, virtualization layer, and has 2 sets of layers. 1, App, guest O S, virtualisation layer, and guest O S. 2, app, and guest O S.

Type 1 Hypervisor, also known as the native or bare-metal hypervisor, is a software or firmware that is directly installed on top of the bare metal. As Type 1 Hypervisor does not require any operating system and runs directly on top of bare metal, it offers better performance compared to its counterpart. Linux KVM is one such Type 1 Hypervisor that is open source and so developed and managed by the open community.

Type 2 Hypervisor, also known as hosted hypervisor, is a software installed on a physical or a virtual machine with a guest operating system. This hypervisor leverages the nested virtualization concept and allows to host virtual entities on top of another virtual entity. VirtualBox and VMware Fusion are a few such Type 2 Hypervisors.

Note

There were some discussions to embed the hypervisor within the system BIOS itself. This type of hypervisor is referred to as Type 3.

Virtualization – Virtual Machines and Containers

In this section, we will spruce up the readers’ knowledge about different virtualization by-products, such as virtual machines and containers.

Virtual Machines

The virtual machine (VM) is a type of server virtualization that allows the user to instantiate a server on top of the hypervisor. Multiple virtual machines can be hosted with their own share of underlying hardware resources, as shown in Figure 6-4.

A block diagram of Virtual machines starts from the physical host and hypervisor and has 2 sets of 3 layers, Virtual H W, guest O S, and application.

This introduces the concept of offering Infrastructure as a Service (IaaS) by different cloud service providers (CSP). Each CSP offers different types of hardware resource configuration and a catalog of operating systems to choose and host the VM based on the business and user needs. The IaaS offered by Amazon Web Services (AWS) is referred to as Elastic Compute Cloud (EC2) instances. An example of EC2 instance hosting is shown in Figure 6-5.

A screenshot features E C 2 instance hosting in Amazon Web Services. It illustrates 4 steps. 1, Configuration of the name. 2, Choosing the Operating System. 3, Choose the instance type. 4, Configuration or leaving the rest to default.

Containers

A container is another type of server virtualization that allows the user to host a lightweight compute entity comprising a package of binaries and libraries to host the relevant service. Unlike the virtual machine, containers do not have its own guest operating system. Instead, they share the underlying guest operating system as shown in Figure 6-6.

A stacked block diagram of containers. From bottom to top, physical host, host operation system, and 3 sets of 2 layers, app, and binary.

The container engine or the manager that is responsible for hosting and managing the containers in the user space. The kernel features such as cgroup and namespace are used to provide isolation and privacy between the containers that are sharing the same operating system. Docker and LXC are well-known container platforms used in the industry. While LXC is used only to Linux containers, the Docker platform is OS agnostic and can be used in different types of applications as containers.

Note

Different cloud service providers have different portals to configure and host the virtual machines. This book or chapter does not intend to help the readers learn each such portal and assume that the readers are familiar with the portal to perform the capture in machines hosted in different provider environments.

In the subsequent sections, we will discuss how to capture the traffic in different cloud environments, such as AWS and GCP, and cloud-native environments, such as Docker and Kubernetes.

Traffic Capture in AWS Environment

When one or more EC2 instances are hosted in the AWS environment, there are different options to capture the traffic. While one simple option is to use the native way of logging in to the EC2 instance and leverage the native tools such as tcpdump to capture the traffic, it is not different from how we capture in a physical server. However, such native option requires per-instance configuration to capture the traffic and does not provide a holistic view of the entire network. If the requirement is to capture the traffic to more than one instance in the same virtual private cloud (VPC), this native option is not sufficient.

In this section, we will discuss the traffic mirroring ability introduced in the AWS portal to configure the capture, the source, and the target along with the filters to specifically capture the traffic from one or more instances.

VPC Traffic Mirroring

One of the services offered by AWS is the virtual private cloud (VPC), which allows the user to isolate a group of EC2 instances. This is analogous to a group of physical servers connected to the same layer 2 subnet. In our setup, we have three EC2 instances connected to the same VPC as shown in Figure 6-7.

A screenshot of the A W S cloud with V P C. V P C has an internet gateway with a public subnet. The public subnet has client V M, source V M, and Wireshark target.

The SourceVM is hosted with one interface eth0 with Internet access. This is the interface from which bidirectional traffic is required to be captured. The ClientVM is hosted in the same VPC with one interface eth0, with Internet access. In our example, we use this VM to generate ICMP traffic to the SourceVM. The WiresharkTarget is the target VM to which the traffic from eth0 of SourceVM will be mirrored and captured. This VM is hosted with two interfaces where eth0 is with Internet access, while eth1 is used as the target interface to which the mirrored traffic from SourceVM will be replicated. Let us now look into the configuration and procedure to mirror the traffic in this scenario.

In the AWS console portal, hover over the Services ➤ VPC page, where “Traffic Mirroring” is a configuration option available under VPC as shown in Figure 6-8.

A screenshot of the new V P C experience. V P C dashboard has a virtual private cloud, security, network analysis, D N S firewall, network firewall, virtual private network, A W S cloud W A N, transit gateways, and traffic mirroring.

From this option, configure the “Mirror targets” by specifying the target interface to which the traffic should be mirrored. In our example scenarios, eth1 of WiresharkTarget VM is the interface marked as eni-0ba536f1e8dcf344b. This interface is set to the target as shown in Figure 6-9.

A screenshot of V P C traffic mirroring with 2 steps, target settings, and choose a target. Target settings has tag name and description. Choose target has a target type and target options.

All the traffic mirror targets created are listed in the “Traffic mirror targets” page. In our example scenario, we created the target with a name “WiresharkTarget” as shown in Figure 6-10.

A traffic mirror target has a name, target I D, description, type, and destination with three buttons, refresh, delete, and create traffic mirror target.

The next step is to create the mirror filter to specify the type of traffic to be captured. This allows the user to filter and capture selective traffic if the troubleshooting is focused on a specific TCP or UDP flow. Alternately, the filter can be created to capture all types of traffic as well. An example configuration is shown in Figure 6-11.

A screenshot of the V P C traffic mirroring filter exhibits 3 steps. Filter settings with a name and descriptions. Inbound and Outbound rules optional has number, rule action, protocol, source, and destination port range, source and destination C I D R blocked, and description.

All the traffic mirror filters created are listed in the “Traffic mirror filter” page. In our example scenario, we created the target with a name “TrafficFilter” as shown in Figure 6-12.

A screenshot of the V P C traffic mirroring filter configuration has a name, the filter I D, and description with the search bar, and three buttons refresh, actions, and create traffic mirror filter.

The final configuration step is to configure the mirror session from the “Mirror Session” page. The configuration option is as shown in Figure 6-13.

A screenshot of creating a traffic mirror session with 5 steps. 1, session settings has 3 steps, tag name, mirror source, and mirror targets. 2, additional settings has the fourth step as filter options. 3, create button is the fifth step.

The “Mirror source” field is set to the interface ID of the eth0 of SourceVM. This is the interface from where the traffic should be mirrored and captured. The “Mirror target” field is set to the ID of the WiresharkTarget that we created in the previous step while creating the mirror target. The “Filter” field is set to the ID of the TrafficFilter that we created in the previous step while creating the mirror filter. The output after the configuration is as shown in Figure 6-14.

A screenshot of the Wireshark capture comprises name, session I D, session number, packet length, owner, V N I, target owner, created I d of traffic filter, and Wireshark targe. At the footer, the Manage Tags option is visible.

Now the setup is ready to mirror the traffic from the eth0 interface of SourceVM and mirror the traffic to eth1 of WiresharkTarget VM. By logging in to WiresharkTarget VM and using the tcpdump tool, we will be able to capture the traffic from eth1 which is the mirrored traffic from eth0 of SourceVM.

While the preceding example scenario was explained with one source port, multiple ports can be configured to mirror the traffic to the same target port.

Note

The mirrored traffic from the VPC is encapsulated using UDP port 4789 before forwarding to the target port. So, it is essential to configure the relevant security group rules to allow this UDP port.

Traffic Capture in GCP Environment

To further explain this capability, we created a virtual private cloud (VPC) in the GCP as shown in Figure 6-15.

A screenshot illustrates a virtual private cloud V P C in the Google Cloud Platform. It comprises a Cloud V P C network, Packet mirroring, U D P Load balancer, source v m, and target v m.

There are two Ubuntu-based compute instances created as part of the same VPC as sourcevm and targetvm. The sourcevm is used to generate traffic to the Internet, while the targetvm is used to capture the traffic for analysis. In the GCP portal, choose Compute Engine ➤ Instance group from the navigation menu and click the Create Instance Group option to go to the page as shown in Figure 6-16.

A screenshot of the create instance group contains the new management instance group stateless and stateless, name, location, network and instance, V M instance, and port mapping.

The instance group must be created as unmanaged by choosing the “New unmanaged instance group” option. Now, the targetvm is selected as the VM instance to be part of this group. The next step is to create the UDP load balancer to forward the mirrored traffic to the instance group configured as the backend for the load balancer. The UDP load balancer is created by hovering to Network Services ➤ Load balancing from the navigation menu and clicking the Create Load Balancer to go to the page shown in Figure 6-17.

A screenshot of two pages. 1, choose the U D P load balancing with 3 options, H T T P, T C P, and U D P load balancing. 2, choose the below option that has internet facing or internal only highlights only between my V M s.

Now, select UDP Load Balancing to create the load balancer to which the packet will be mirrored from the source instances. Since this load balancer is not expected to balance any Internet traffic, the Internet facing option is set to “Only between my VMs.” This will take us to the next page to configure the frontend and the backend options as shown in Figure 6-18.

A web page illustrates the virtual private cloud load balancer frontend and backend configuration. It depicts three main headings, Backend configuration, Backened service, and New Backend. Instance group heading and text field Wireshark instance group. At the bottom is Add Backend button heading.

The Instance group field in the backend is used to configure the unmanaged instance group we created and associated the targetvm. It is also essential to enable the Packet Mirroring flag in the frontend configuration. Without this flag, the load balancer will not be listed to be configured in the mirror policy section.

Once the UDP load balancer with packet mirroring is created, the final step is to configure the packet mirroring policy. The mirroring policy is created by hovering over to VPC network ➤ Packet mirroring from the navigation menu and choosing the Create Policy option to go to the page as shown in Figure 6-19.

An illustration of V P C packet mirroring configuration. It contains a define policy overview, select V P C network, select mirrored source, select collector destination, select mirrored traffic with 2 buttons submit and cancel.

In our example scenario, both the source and the target machines are in the same VPC network, and so the respective option is chosen to select the VPC network. The mirror source is set to the instance, and sourcevm is selected to mirror the traffic. The collector destination is set to the frontend created as part of the UDP load balancer, and finally the filter policies are created to choose all the traffic or selective traffic to be mirrored.

The setup is now ready to mirror the traffic from the sourcevm and replicate the traffic to the frontend of the load balancer which in turn will replicate it to the backend instance targetvm. By logging in to the targetvm and using the tcpdump tool, we will be able to capture the traffic from sourcevm.

Traffic Capture in Docker Environment

During the initial installation, Docker by default creates a bridge network as docker0 with a private range subnet used to assign the IP address to each hosted container. Any user can also create a user-defined bridge with its own subnet and policies. Alternately, Docker can host the container with a host network where the host interface will be shared by the containers. An example output of the default docker bridge is shown in Figure 6-20.

A screenshot of docker networks highlights the fourth line, 6596cae657c2 bridge bridge local, and the tenth line, i n e t 172.17.0.1.

This bridge could be considered as a virtual switch that connects the containers to the host interface to reach the external network. An example topology of the docker default bridge network is shown in Figure 6-21.

A block diagram of the docker default bridge. It comprises docker 0 and container, connected by the eth 0 interfaces. Internet output is received through the eth 0 interfaces.

Each container will be assigned with a unique address from the subnet assigned to the docker0 interface. The host network is programmed to perform the Network Address Translation (NAT) operation for any traffic received from the Docker interface. Accordingly, the source address of the traffic will be changed to the host interface address. By simply using the docker0 interface as the capture interface, we will be able to capture all the packets destinated to the containers as shown in Figure 6-22.

An illustration of packet capture in the docker container. Packet information is sent to the docker container block and is sent to the internet. The docker container block comprises a docker 0 interface connected to the container and Internet through eth 0.

Traffic Capture in Kubernetes Environment

While Docker is the popular container platform to host application containers, the use of the command line to instantiate and manage applications on a per-container basis lacks dynamic lifecycle management of the application containers. For example, if one of the containers is stuck or down, manual intervention is required to identify the failed container instance and reinstantiate the application container. However, in a production-grade environment, it is common to run a voluminous number of containers running different applications, and it is humanly impossible to monitor and manually manage all such containers. What we need is a dynamic orchestration platform that can automate the deployment of containers, management, and scaling aspects with minimal or no manual intervention.

Kubernetes is a container orchestration platform that was originally introduced by Google and later opened to the community as an open source platform and now adopted by the Cloud Native Computing Foundation (CNCF). The basic architecture is shown in Figure 6-23.

A model diagram illustrates Kubernetes architecture. The user sends kubectl to the Master node that comprises Kube Controller Manager, e t c d, A P I Server, and Scheduler. The master node is connected to 3 worker nodes.

The Kubernetes architecture comprises a minimum of one master node and one or more worker nodes as control plane components, collectively referred to as a cluster. Within the cluster, any application is hosted as a Pod, which is a group of one or more containers. The init process or other service agents can be hosted as a container along with the application container within the Pod. The master node acts as the control plane component that manages all the worker nodes and then manages the Pod scheduling and scaling. In such container applications hosted as a Pod within the cluster, it is essential to perform traffic capture for various troubleshooting purposes. While one option to capture the traffic is to log in to each worker node and use the tcpdump command with the docker0 interface as input, this is already covered in the previous section. In this section, we will discuss another approach using the ksniff plugin that can be embedded within the kubectl, which is the command-line interface for Kubernetes to host and manage the Pods.

The captured Wireshark file can be offloaded from the master node for analytics purposes.

Summary

In this chapter, we spruced up the knowledge of the readers about virtualization and the evolution of cloud computing that is now offered as a new service by different cloud providers. We explained the different virtualization types and the hypervisor types to realize the benefits of virtualization.

We further discussed about different by-products of virtualization, such as virtual machines and containers, and the ability to orchestrate and manage those virtual entities.

With this background, we explained how to capture the traffic on different cloud providers with examples captured from virtual machines hosted on AWS and Google Cloud environments. We then explained how to capture the traffic from the Docker container platform and Kubernetes cluster.

References for This Chapter