by Detlef Drewanz
Published January 2013 (reprinted from eStep blog)
Part 8 - Oracle Enterprise Manager Ops Center as a Management Tool for Virtualization
Part 7 - The Role of Oracle Virtual Desktop Infrastructure in a Virtualization Strategy
Part 6 - Oracle VM VirtualBox - Personal Desktop Virtualization
Part 5 - Network Virtualization and Network Resource Management
Part 4 - Resource Management as an Enabling Technology for Virtualization
Part 3 - The Role of Oracle Solaris Zones and Linux Containers in a Virtualization Strategy
Part 2 - The Role of Oracle VM Server for x86 in a Virtualization Strategy
Part 1 - The Role of Oracle VM Server for SPARC in a Virtualization Strategy
Features of Internal Network Virtualization
After discussing Oracle VM, OS virtualization, and some aspects of resource management in the previous articles of this series, this article will now cover a special area of resource management and virtualization of resources: network virtualization and network resource management.
The network is a special shared resource that glues all the virtual machines (VMs), zones, and systems together and provides a communication channel with the world. Thus, the network is a very important layer of the virtualization stack.
Network virtualization is categorized as external or internal.
Because a shared-resource network is highly used by many consumers—such as processes, VMs, zones, and containers—network resource management is very important for network virtualization. Network resource management helps to deliver powerful, stable network connections to virtualized environments, and the available network bandwidth can be better spread among multiple virtualized environments to meet service level agreements. Extensive use of network virtualization should be considered only with well-implemented network resource management.
Using hypervisor-based virtualization and Oracle Solaris Zones with network virtualization and network resource management enables a whole range of new capabilities for creating network-based architectures. Figure 1 shows one example, in which physical systems and network components have been replaced by Oracle Solaris Zones and virtual switches.
Figure 1. Example Network-Based Architecture
In this article, we concentrate on the functionalities and side effects of internal network virtualization and network resource management in conjunction with hypervisors, containers, and zones in one system.
The following base features are common across various type of hypervisors and zone technologies; however, specific implementations differ.
Figure 2 shows an example of how VNICs are built in Oracle Solaris on top of physical interfaces and then are used by Oracle Solaris Zones. In this example, we also use bandwidth limitations assigned to VNICs.
Figure 2. VNICs Built on Top of PNIC
Figure 3. Oracle VM Server for x86 and a Network Bridge
For Oracle VM Server for SPARC, a virtual switch has to be created by the administrator in the service domain to which the network interfaces of the guest domains connect. The logical domain channels (LDC) establish the link between the virtual switch and the guest domains. Oracle Solaris creates a switch above the physical interface when the first VNIC is created. Oracle VM VirtualBox creates virtual PCIe cards and assigns them to VMs as network interfaces. There are different ways these interfaces communicate with the host operating system or the outside world (for example, NAT, bridged networking, internal networking, and host-only networking).
Figure 4. Oracle VM Server for SPARC and the Virtual Switch
Figure 5. Oracle Solaris Etherstubs
With a shared-IP instance, the zones share one IP stack infrastructure in the kernel, including its ARP cache, routing table, and IP configuration flags (but not the IP address). A zone with an exclusive-IP instance has its own IP stack. To use an exclusive-IP instance, a dedicated physical interface or VNIC is needed. Using a shared-IP instance does not require a dedicated network interface.
Figure 6. Shared-IP and Exclusive-IP Instances
The network is always a shared resource, either outside the server chassis—by using central cables, switches, or routers—or inside the chassis—by sharing physical ports, network stacks, or just the CPUs that are handling the traffic by doing check-summing or handling the network adapter interrupts. To meet the different service level agreements of the network consumers in one chassis, network resource management is needed. The requirements can be based on available network bandwidth, the network latency, or the network data loss rate. While network latency and data loss rate are typically based on the network technology that is used and the OS- or hypervisor-specific implementation, the available bandwidth can be controlled by resource management. Various product-specific implementations exist that are related to internal network virtualization:
In Figure 7, a configured flow for the network data type "network backup" can be used to give the green and the blue traffic more available bandwidth in critical load situations. We discussed this functionality as resource scheduling in the previous article, because if "green" and "blue" do not have bandwidth needs, "network backup" can get the maximum available bandwidth.
Figure 7. Example of Configured Flow
Virtual network interfaces, virtual bridges, virtual switches, and virtual PCIe cards are basic internal network virtualization features that are part of virtualization products. These networking features "glue" all the VMs, zones, and containers together and enable them to communicate among themselves and with the outside world. To enable stable communication for all of them on a shared-resource network, the use of network resource management features is recommended. We have also seen that for networks, various types of resource management, such as constraints, scheduling, and partitioning, are used.
Detlef is a Principal Sales Consultant and is located in Potsdam, Germany. He acts as server and Oracle Solaris specialist on Oracle's Northern Europe Server Architects team. He joined Sun Microsystems in 1998 and is now part of Oracle. Prior to that, Detlef worked at Hitachi Internetworking Frankfurt in network support and as member of scientific staff in the Department of Computer Science of the University of Rostock. Detlef holds a master's degree in computer science.
|Revision 1.0, 01/02/2013|