Enhancing VM Mobility with VxLAN, OVSDB and EVPN

Organizations are increasingly using virtual machine mobility to optimize server resources, ensure application performance and to aid in disaster avoidance. Typically VM live migration has relied on increasing the scale of the L2 broadcast domain to ensure that the VMs can be reached after migrations using their current addressing. This has resulted in the increasing use of VLANs and the need for L2 extension over the WAN.  As a result organizations are looking for ways overcome the limitations with VLAN scale and for methods to extend the L2 domain over the WAN that ensure the best performance. VxLAN has emerged as an alternative technology to VLANs, and EVPN has emerged at a better way to transport VMs over the WAN. Together these technologies can enable VM live migration over the WAN, or long distance vMotion in VMware parlance, but they need to all work together effectively and this is where OSVDB, VxLAN routing and a new technology from Juniper called ORE come in to play.

VxLAN Increases VLAN Scale
Organizations are increasingly looking to VxLAN as a solution. The primary goals behind this network architecture is to increase traditional VLAN limits from 4,094 and to enable VM mobility across Layer 3 subnets. VxLAN is a tunneling technology and is used to create an overlay network so that virtual machines can communicate with each other and to enable the migration of VMs both within a data center and between data centers. VxLAN enables multi-tenant networks at scale, as a component of these logical, software-based networks that can be created on-demand. VxLAN enables enterprises to leverage capacity wherever it’s available by supporting VM live migration. VxLAN implements a Layer 2 network isolation technology using MAC in IP encapsulation that uses a 24-bit segment identifier to scale beyond the 4K limitations of VLANs.

Optimizing EVPN for Virtual Machine Mobility over the WAN

Organizations need to insure that their applications are available and performing. Server virtualization helps by enabling virtual machine mobility.  If a server is overworked or will be unavailable vMotion can be used to migrate live workloads to another server in the current data center or in another data center. This requires that the addressing including the MAC, IP address and VLAN ID remain the same so that sessions are not dropped when the VM move happens. This is done by extending the L2 domain to the new location, know as Layer 2 stretch. Within a subnet this is easy to do. Across subnets in the data center it becomes more difficult. Doing live migration over the WAN introduces considerable challenges. Juniper has introduced a number of technologies to make virtual machine live migration possible.

The challenge with VM mobility is how to do the Layer 2 stretch in a way that ensures that the VM can be reached after it is moved. There are a number of issues that need to be dealt with. The MAC and IP address no longer pinned to a site or to an interface as they have moved with the VM. You need fast convergence of network paths as VM moves so that traffic will reach it quickly. You need ingress and egress traffic convergence and optimization to avoid having traffic go through the former default gateway after the VM has moved. You need learning of the effects of the live motion event and information distribution control so that the network isn’t impacted by signaling traffic. You need proper L2 & L3 interaction so that everything happens in a timely manner to ensure the best experience for the users of the applications that are affected by the VM move. VPLS has been the traditional methods of doing this, and now Juniper is supporting EVPN to provide enhancements to the solution.

Inter Data Center Workload Mobility with VMware

Server virtualization has increasing become implemented in the data center because it enables higher utilization of physical servers increasing their value to the organization. By abstracting the server operating system from the server hardware, virtualization allows physical resources to be shared among many virtual machines. The capabilities of cloning, suspending, and migrating live VMs among a cluster of physical hosts enhances resiliency and performance of applications. Advancements in networking technology allow servers within a single cluster to be located across the entire data center, or in another data center some distance away, further enhancing application availability, but making this technology work isn’t simple.

The Case for Live Migration
There are may use cases put forward for live workload migration and they are covered in the document, and were also covered in my previous blog “Making the Case for Long Distance Virtual Machine Mobility.” These use cases include optimizing server resource utilization, optimizing resource consumption at various locations, hybrid cloud where overflow workloads move to another data center, and disaster avoidance were workloads are moved to saftey, as well as a follow the sun model where workloads move according to the time zone of users. Some scenarios for data center migration for live workloads can be accomplished without implementing complicated first-hop-responder and route-optimization techniques. Other scenarios are possible however, they require implementing protocols that share state and fate, thereby increasing the complexity and reducing the reliability of the connected data centers. As a result of these considerations the network is a critical factor.

Making the Case for Long Distance Virtual Machine Mobility

With VMWorld coming up I’m reminded of a top of mind subject, virtual machine mobility. The reason for moving virtual machines is to better allocate server resources and maintain application performance. It’s a useful technology that works great in the data center. We also hear a lot about the need to move virtual machines across the WAN, live, without losing sessions. This is known as Long Distance vMotion or generically as long distance live migration. This might sound like a good idea, but it gets a bit complicated when you think outside the data center walls and across the WAN. It creates complexity in the network, as maintaining sessions requires keeping the same IP address and MAC address after the move.  There are many proposed use cases for it, but is it such a good idea?

Limitations of Live Migration
Long distance live migration over the WAN has limitations due to latency and bandwidth requirements and the complexity of extending layer 2 which is required to maintain the same MAC address. Issues include the potential for traffic coming first to the original data center where the gateway is, and then looping to the new data center where the VM has moved.  Traffic can also loop back over the WAN to reach the storage that stayed behind. There are also bandwidth requirements to handle the large scale movement, as well as issues with storage pooling and storage replication as well as the complexity of implementing the L2 bridging architecture. If we are going to deal with all of this complexity of moving virtual machines over the WAN there had better be a good reason to do it. But is there? Here is a look at the various use cases for long live migration that I have found.