Download Slide 1

Enhancing Dynamic Cloud-based Services
using Network Virtualization
F. Hao, T.V. Lakshman, Sarit Mukherjee, H. Song
Bell Labs
All Rights Reserved © Alcatel-Lucent 2009
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
2
VM
All Rights Reserved © Alcatel-Lucent 2009
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
3
All Rights Reserved © Alcatel-Lucent 2009
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
4
All Rights Reserved © Alcatel-Lucent 2009
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
All traffic goes through
the anchor point
User 1
HA
User 2
VM 1
VM 2
MIPv6 requires correspondent
nodes to support MIP
 Transition from IPv4 to IPv6??
 End users will be mixture of
IPv4 and IPv6 clients
5
All Rights Reserved © Alcatel-Lucent 2009
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
All traffic goes through
the anchor point
User 2
User 1
HA
VM 2
VM 1
MIPv6 requires correspondent
nodes to support MIP
 Transition from IPv4 to IPv6??
 End users will be mixture of
IPv4 and IPv6 clients
6
All Rights Reserved © Alcatel-Lucent 2009
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]
7
All Rights Reserved © Alcatel-Lucent 2009
VICTOR Architecture
Forwarding Element (FE)
CC
 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
Client
han
nel
VM
ntr
ol C
FE1
Co
Tun
n
el T
hru
Inte
rne
t
FE2
FE5
FE4
Centralized Controller (CC)
 Controls routing and signaling for
mobile VM IP prefixes
 Computes and installs forwarding
table for each FE
FE3
VICTOR
VM1
VM
VM2
VM
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
8
All Rights Reserved © Alcatel-Lucent 2009
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
9
All Rights Reserved © Alcatel-Lucent 2009
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
10
VM 2
VM 1
All Rights Reserved © Alcatel-Lucent 2009
VM Migration across Data Centers
Data Center 2
Data Center 1
4
2
2) Local FE receives the ARP and
sends the message to CC
3
3) CC installs new routing entry in
local FE for the VM
VM
VM
1
New location
1) VM sends an ARP
Old location
4) CC installs new routing entry in
the old FE
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
11
All Rights Reserved © Alcatel-Lucent 2009
Experimental Prototype of VICTOR
10.6.7.1
Server3
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




Controller
1
0
10.2.3.1
Server1
VM
10.10.0.11
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
FE1 2
1
2
1
10.4.5.1
Server2
FE2 0 4-port 0 FE3 2
3
3
NetFPGA
AP1
AP2
Mobile PC
10.10.0.36
Forwarding Table at FE2
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
12
All Rights Reserved © Alcatel-Lucent 2009
Flow
Action
nw_dst=10.2.3.1
mod_dl_dst,out:2
nw_dst=10.10.0.11
mod_dl_dst,out:2
nw_dst=10.10.0.36
mod_dl_dst,out:3
nw_dst=10.4.5.1
out:0
nw_dst=10.6.7.1
out:1
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
13
All Rights Reserved © Alcatel-Lucent 2009