As virtualized servers become more prevalent in the datacenter, networking components such as switches must adapt to become more aware of virtualization. Most switches were originally designed for physical networks, in which LAN configurations were more or less static. When a new node was added or an existing node was moved to a new subnet, it often required a network administrator to make manual changes to the network configuration to ensure that requirements such as SLAs and security were maintained. As a result, changes to the network topology needed to be carefully planned in advance. With the rise of virtual infrastructure, in which virtual machines (VMs) migrate frequently from one host to another, it becomes nearly impossible for network administrators to keep up by making manual changes. IBM is now directly addressing this problem with the VMready technology that it acquired with Blade Network Technologies.
Server virtualization makes network management more complex, because VMs are hidden from the physical network switches by the hypervisor. VMs forward packets from the virtual network interface controller (vNICs) in the hypervisor to a virtual switch (vSwitch), and then to a physical NIC that forwards the packets on to the physical switch, which can only see the physical NIC. This setup works adequately until a VM needs to be migrated across multiple subnets to a new host. Although such a move is possible, it is not without issues and a network administrator must carefully plan out the move in advance so that the network policies associated with that VM, such as ACLs, QoS, and VLANs, follow the VM to the new switch.
To solve this problem, developers of server and network technologies have come up with various solutions to help networks bridge the physical and virtual domains in a way that allows them to adapt quickly and easily to changes on either side. IBM is now starting to promote one such technology, called VMready, which it obtained with the acquisition of Blade Network Technologies in 2010. Switches that use VMready allow VMs to be managed at the level of virtual ports in addition to physical ports. VMready switches sniff the network traffic between the hypervisors and management tools in order to determine the location and identification of each VM (alternately, the switch can send a query to a VM management console to determine the network attributes of VMs, such as UUIDs, MAC addresses, IP addresses, and VM names).
VMready management tools store the relevant data about all of the VMs they discover in a central policy database that contains information on every VM in the datacenter. For customers who need to set up the network in advance, a network administrator can populate the central VMready database manually. Once the database is populated, VMready allows VMs to be moved to any VMready switch on the network, and the defined policy profiles will follow the VM.
One of the nice features of VMready is the ability to create groups of VMs based on common Layer 2 or Layer 3 networking policies. For instance, VMs hosting databases can be assigned a higher quality of service (QoS) policy with Layer 2 redundancies, and web servers can be assigned a lower QoS without these redundancies. Once these groups are set up, detailed profiles can be assigned to each group, and these profiles will follow a VM wherever it may go on the network. When new VMs are created, they can be added to a group in which the relevant attributes will automatically be assigned to the VMs.
Standards for VM-aware networking are now being introduced, including Edge Virtual Bridging (802.1Qbg), which IBM helped to develop and champion. IBM’s VMready 4.0 incorporates EVB, and, unlike some competing approaches, IBM’s VMready can be used with hypervisors from multiple vendors, and VMready switches do not require a separate management station or any special software to be installed on the hypervisor. Essentially, they function like normal switches, but at the virtual port level. IDEAS feels VMready will thus appeal to network administrators who have to manage increasingly virtualized datacenters, but also value compatibility with their existing physical infrastructure and heterogeneous virtualization software.
Comments