- 12 iPhones Apps That Will Make You a Networking Star
- 10 Careers Robots Are Taking From You
- Big Data Gold Isn't Always Where You Would Expect It
- 6 Tips to Build Your Social Media Strategy
Network World - This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
Virtual Ethernet Port Aggregator (VEPA), which is part of the emerging IEEE 802.1Qbg standardization effort, is designed to reduce the complexities associated with highly virtualized deployments. A closer examination of the traditional approach using virtual switches and contrasting that to the VEPA approach will provide some insights into the deployment challenges and considerations around virtualization and networking.
When you have multiple virtual machines (each consisting of an operating system and applications) sitting on a hypervisor on a physical host, the VMs communicate with each other and to the outside world using a virtual switch or vswitch. The vswitch is, in effect, a Layer 2 switch, typically running within the hypervisor as software. Every hypervisor typically has a virtual switch built in. The capabilities of the virtual switch vary from hypervisor to hypervisor.
The virtual switch moves networking into the server realm, bringing with it the need to re-test, re-qualify and re-deploy traditional network based tools and solutions for the virtualized environment. This change can in some ways actually serve as an impediment to the rapid scaling and adoption of virtualization.
For example, traditional network and server operations teams have been distinct, each with their own processes, tools and realm of control. With networking moving into the server by way of the virtual switch, a simple task such as provisioning virtual machines can now require additional co-ordination between these teams to ensure that the virtual switch configuration stays consistent with the physical network configuration.
Troubleshooting and monitoring inter-VM communications becomes a challenge due to lack of visibility of inter-VM traffic in the network. And as the number of virtual machines on a single server scales from 8-12 VMs today to say 32-64 in the near future, the need to secure virtual machines within the server from each other, and from external threats, becomes a serious consideration.
From firewalls to IDS/IPS, traditional network based appliances and tools need to be re-developed, re-certified and re-deployed for these types of highly virtualized environments to ensure that inter-VM communication via the vswitch can meet compliance and security considerations.
The lack of standards around virtual switches further compounds this challenge adding to the overhead of training, interoperability,
and management across different hypervisor technologies. In effect the physical server is becoming a full blown network environment
with its own set of interoperability, deployment, certification and test considerations.
Interestingly, this trend runs counter to one of the premises of virtualization which is to efficiently utilize excess capacity within the servers for applications. The “network within the server” now risks becoming a significant consumer of that very same excess capacity, taxing CPU and memory resources.