Download Slide 1

Diverter: A New Approach to
Networking Within Virtualized
Infrastructures
Aled Edwards, Anna Fischer, Antonio Lain
HP Labs
© 2008 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
Outline
•
Data Center Networks for Cloud Computing
•
Our Approach: Diverter
•
Evaluation
•
Future Work
2
25 May, 2017
Data Center
Networks for
Cloud Computing
Data Center Networks
for Cloud Computing
Goals (and Challenges!)
•
Multi-tenancy and Security
− Host multiple customers on a single shared infrastructure
− Allow each customer to configure their own network topology
to suit application needs
− Data and performance isolation between customers, and the
utility
− Allow controlled and efficient inter-communication between
customers if required and permitted
• “provide rich ecosystem of interacting services”
•
•
•
•
4
Large scale
Automation
Flexibility / Programmability
Performance
25 May, 2017
Data Center Networks
for Cloud Computing
Problems with Traditional Approaches
•
Traditional L2
− Flat network: isolation, scalability
− VLANs: configuration, management
− Encapsulation, Tunneling
− Explicit routing entities required, e.g. routing VMs
•
Traditional L3
− Mobility
− Routing bottlenecks
5
25 May, 2017
Our Approach:
Diverter
Our Approach: Diverter
High-level Overview
•
Isolate customer resources into Cells
− Cell is a collection of virtual resources
− Cell has a single owner
•
Each Cell can have its own virtual network
topology
− Cells consist of several Subnets
− Cell owner can define network policies
• Security: define who can communicate with VMs
• QoS: define bandwidth limits for VMs
7
25 May, 2017
Our Approach: Diverter
Virtual Network Topology
Subnet
Subnet A1
Subnet A2
Subnet B1
Cell B
Virtual Router
C3
Subnet C1
Cell A
Virtual
Router
Subnet C2
Subnet B2
Cell C
Virtual Router
Globally managed virtual IP address space representing virtual network
topologies
IP address format: 10.<CELL>.<SUBNET>.<HOST> (for example)
8
25 May, 2017
Our Approach: Diverter
Realisation as a Distributed Virtual Router
•
Virtual routers are realised as Distributed Virtual
Router implementation (“VNET”)
As virtual routing functionality is distributed
− VNET component running on each server
across all servers rather than implemented
intercepts
packets to/from
VMs,
processes them,
by− VNET
particular,
traditional
routing
entities,
eventually forwards them, or discards them
•communication
VNET takes carebetween
of
any endpoints in the
infrastructure
always
involves
a single
− Simulating routing
across
subnets, just
or Cells
network
“hop”.
− Multicast/broadcast
distribution
− Address discovery
9
25 May, 2017
Our Approach: Diverter
How Does It Work? MAC Rewriting!
•
VNET rewrites packets to simulate routing hop
− Packets are sent to / received from virtual router
interface when crossing subnets
− Important to emulate behaviour of traditional network
topology
•
VNET uses (modified) ARP to discover physical
machines hosting a particular VM
• VNET rewrites packets to send directly to physical
machines hosting destination VM
• VNET rewrites packets to limit VM
broadcast/multicast traffic to particular Cell/subnet
10
25 May, 2017
MAC Rewriting Simplified
Virtual machines
1. Packet TX
sVMAC dVMAC
7. Packet RX
Virtual machines
•Direct
network
sVMAC
dVMAChop between any
endpoint
•No virtual
MACs
6. Packet
RWleaking onto the
physical wire
2. Packet
intercept
Physical host B
Physical host A
3. Packet RW
4. Packet TX
5. Packet RX
sPMAC dPMAC
sPMAC dPMAC
Physical network
11
25 May, 2017
Virtual Router Simulation
3. Packet TX
sVMAC RVMAC
Virtual machines
9. Packet RX
Virtual machines
1. DHCP
2. ARPResponse
Request /
with Virtual
Reply
for
4.Router
Packet
RouterIPIP
RVMAC dVMAC
8. Packet RW
Virtual MACs do not
intercept
leak across subnets!
Physical host B
Physical host A
5. Packet RW
6. Packet TX
7. Packet RX
sPMAC dPMAC
sPMAC dPMAC
Physical network
12
25 May, 2017
Our Approach: Diverter
Further Benefits
•
Efficiency
−
−
−
−
•
Use of multicast/unicast ARP instead of broadcast
Local DHCP response generation
No packet encapsulation
Fast tracking of moving VMs/addresses
Security
− Integrated network policy framework
• Enforcement of fine-grained packet filtering
• Allow frequent changes of network policies
•
Manageability
− No programming of physical infrastructure required
• No synchronization between physical switches and servers
• Only rely on underlying flat L2 network
• Separation of concerns: network administrators vs. server administrators
− Communication possible with non-VNET servers
− No programming of explicit routing entities required
− No specific hardware (or hardware modifications) required
13
25 May, 2017
Evaluation
Traditional L2 vs. Diverter
Intra-subnet vs. Inter-subnet Communication
Routing VM
Subnet A
Traditional L2
Diverter
Physical network
15
25 May, 2017
Subnet B
Subnet A
Performance Evaluation
VM Network Throughput
800
700
600
MAC RW
500
EtherIP
400
300
200
100
0
16
25 May, 2017
Intra-subnet
Inter-subnet (single VM TX)
Inter-subnet (double VM TX)
Future Work
Future Work
•
Direct Network I/O
− Integrate with virtualization-aware HW on server-side,
e.g. SR-IOV NICs, blade server networking
− Integration with new I/O virtualization approaches
developed around KVM/Xen
•
QoS
•
Virtual Network Cloning
•
Data Center Network Federation
•
L2 Scalable Data Center Ethernet
18
25 May, 2017