130 likes | 148 Views
Enhancing Dynamic Cloud-based Services using Network Virtualization. F. Hao, T.V. Lakshman, Sarit Mukherjee , H. Song Bell Labs. Dynamic Cloud-based Services: An Example. Users will leverage cloud computing services to “outsource” their computing needs Thin client/Virtual desktop
E N D
Enhancing Dynamic Cloud-based Services using Network Virtualization F. Hao, T.V. Lakshman, Sarit Mukherjee, H. SongBell Labs
Dynamic Cloud-based Services: An Example Users will leverage cloud computing services to “outsource” their computing needs • Thin client/Virtual desktop • Proxy for handheld devices Cloud Service Providers will • Create a VM for the service • Allocate VM closest to user Data Center 2 Data Center 1 VM User attaches to cloud to get service Data Center 3 Cloud service provider creates VM to serve user VM
Dynamic Cloud-based Services: An Example • As the user population for a service changes, the best location for the VM changes • Cloud Service Providers should • Migrate the VM to the new location closest to the user • VM migration over a LAN is supported by most virtualization software Data Center 2 Data Center 1 VM VM should be moved to Data Center 2 Data Center 3 VM User attaches to cloud from a different location Migrate VM across WAN in an efficient manner without losing service continuity
Benefits of migration of VM across multiple networks/data centers For Cloud Service Provider • Service migration across data centers • Load balancing within and across data centers • Performance optimization • Green computing For Cloud Users • Faster access • Efficient data delivery
Why Mobile IP is not a good solution All traffic anchored at home agent Triangular routing increase delay and burdens the network Fine for end user device with low traffic volume, but not for servers MIPv6 requires correspondent nodes to support MIP • Transition from IPv4 to IPv6?? • End users will be mixture of IPv4 and IPv6 clients All traffic goes through the anchor point User 1 User 2 HA VM 1 VM 2
Why Mobile IP is not a good solution All traffic anchored at home agent Triangular routing increase delay and burdens the network Fine for end user device with low traffic volume, but not for servers MIPv6 requires correspondent nodes to support MIP • Transition from IPv4 to IPv6?? • End users will be mixture of IPv4 and IPv6 clients All traffic goes through the anchor point User 2 User 1 HA VM 2 VM 1
Our Approach: Virtually Clustered Open Router (VICTOR) Traditional virtualization approach • Slice and isolate resources in a physical router • Each slice acts as a different router Virtually Clustered Open Router (VICTOR) • Logically combine multiple physical devices to form a virtual router • A physical device mimics a virtual line card with multiple virtual ports • Virtual line cards are interconnected to mimic a virtual backplane • Dedicated facilities (e.g.,for data centers of a cloud service provider) • MPLS bandwidth-guaranteed paths • Tunnels through the public Internet • Virtual router with distributed forwarding elements managed by logically centralized controller • Similar in concept to [SoftRouter/Openflow/RCP/4D]
VICTOR Architecture Forwarding Element (FE) • Handles all data plane functions • Sets up a virtual backplane between each other as necessary • Can be distributed across WAN • A data forwarding device or a VICTOR enabled router Centralized Controller (CC) • Controls routing and signaling for mobile VM IP prefixes • Computes and installs forwarding table for each FE FE is the first layer-3 access and aggregation point for mobile VM Acts as a loosely coupled router with FEs as line cards, and CCs as control plane
Routing in VICTOR External Routing • Each FE advertises all the mobile VM addresses that VICTOR handles • FE or CC calculates and maintains the best routes to the external IP addresses • FE does not announce FE-FE links to external routers • packets for non-mobile VMs are not routed by VICTOR Internal Routing • An active VM discovers an adjacent FE and registers itself with it • The FE forwards the binding to the CC • The CC authenticates the binding and configures all the other FEs with the binding • Only one active binding for each VM is allowed at a time • Binding changes when the VM moves to another FE • Each FE maintains a forwarding table • local bindings for locally registered VMs • foreign bindings for remotely registered VMs
Packet Forwarding in VICTOR External Packet Forwarding • FE receives a packet destined to an external IP address • Packet is directly sent out by looking up external forwarding table Internal Packet Forwarding • FE receives a packet destined to a VM • Tunnel header, if any, is stripped off • Packets for VM with local binding are directly forwarded • Packets for VM with foreign binding are forwarded to the current FE • Packet discarded if no binding is found VM 2 VM 1
VM Migration across Data Centers • VM sends an ARP • Local FE receives the ARP and sends the message to CC • CC installs new routing entry in local FE for the VM • CC installs new routing entry in the old FE Data Center 2 4 Data Center 1 2 3 VM VM 1 Old location New location Data Center 3 Mobile VMs must have IP addresses that do not conflict with any other hosts in the cloud VMs with destination NAT-ed addresses are moved by allocating non-conflicting private addresses to the mobile VMs VM migration within a data center is similar in principle but simpler
Experimental Prototype of VICTOR Prototype based on Linux (FC 9) • All FEs are controlled by CC • FE2 and FE3 have 4-port NetFPGA GbE card • Developed new Openflow controller to support • Mobile node registration • Layer 3 routing VM Migration • VM migrated from Server1 to Server2 • Ping VM from Server3 at 0.01 sec interval • Packet loss = 350 3.5 sec connectivity interruption • Same downtime over LAN migration negligible overhead Physical Host Migration • Mobile PC changed attachment from AP1 to AP2 • Ping mobile PC from Server3 at 0.01 sec interval • Packet loss = 1—2 0.01—0.02 sec connectivity interruption
Conclusion • Enabling wide-area VM mobility in an efficient manner is of significant value to many cloud-based applications • Proposed solution based on distributed forwarding and centralized control • More efficient data forwarding and more flexible control unlike mobile IP solution • Triangular routing is significantly reduced • No modification to virtualization software or TCP/IP stack is needed • No new requirement on correspondent node • Connectivity is not affected during and after migration • Several open issues remain for future research • Use of this architecture for enabling new applications • Simplifying implementation of current features