Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization Overlay
-
Upload
dan-mihai-dumitriu -
Category
Software
-
view
391 -
download
2
Transcript of Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization Overlay
Agenda
What is Driving Network Change
Cloud Network Requirements
Why Not Traditional Networking
Network Virtualization Overlays
Neutron?
MidoNet
1
Forces are Reshaping Networking…
Big Web Cloud Computing
Big Data
Customer Focus – $ / Node & Port
Azure
Mobile
2
IoT and Big
Data
Networking is Experiencing Rapid Change
Services and applications are moving to the Cloud; workloads are moving to a virtualization environment; DevOps networking adoption
Hardware is commoditized; many players delivering high-throughput switching at extremely low prices
Open Source and Service Orientation supports flexibility, innovation, vendor agnostic design, self-service, shorter
development times and faster time to market
Cloud
ComputingWhite-box
Hardware
IoT and Big Data impact networks requiring distributed datacenters and agility to enable
real-time event responses
Open
Source and
Service
Orientation
Network Virtualization Requirements
•Speed of Provisioning
•Scale
•Multi-tenancy
•Performance
•Elasticity
•Simplicity of Deployment
•Security
Requirements for NV
6
Requirements
6
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual Router (L3)
Tenant AVirtual Router
Tenant BVirtual Router
VM6
Virtual L2 Switch B1
Virtual L2 Switch A1
Virtual L2 Switch A2
TenantB office
Tenant BVPN Router
Office Network
Requirements for NV
7
Requirements
7
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual Router (L3)
Tenant AVirtual Router
Tenant BVirtual Router
VM6
Virtual L2 Switch B1
Virtual L2 Switch A1
Virtual L2 Switch A2
TenantB office
Tenant BVPN Router
Office Network
Isolated tenant
networks
(virtual data center)
Requirements for NV
8
Requirements
8
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual Router (L3)
Tenant AVirtual Router
Tenant BVirtual Router
VM6
Virtual L2 Switch B1
Virtual L2 Switch A1
Virtual L2 Switch A2
TenantB office
Tenant BVPN Router
Office Network
L3 Isolation
(similar to VPC and VRF)
Requirements for NV
9
Requirements
9
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual Router (L3)
Tenant AVirtual Router
Tenant BVirtual Router
VM6
Virtual L2 Switch B1
Virtual L2 Switch A1
Virtual L2 Switch A2
TenantB office
Tenant BVPN Router
Office Network
Fault-tolerant devices and links
Redundant, optimized, and
fault tolerant paths to
to/from external networks
(e.g. via eBGP)
Requirements for NV
1010
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual Router (L3)
Tenant AVirtual Router
Tenant BVirtual Router
VM6
Virtual L2 Switch B1
Virtual L2 Switch A1
Virtual L2 Switch A2
TenantB office
Tenant BVPN Router
Office Network
Fault-tolerant devices and links
Fault tolerant
devices and links
Requirements for NV
11
Device-agnostic networking services:
• Load Balancing
• Firewalls
• Stateful NAT
• VPN
Networks and services must be fault
tolerant and scalable
Bonus Requirements for NV
13
Integration with cloud or
virtualization management
systems.
Optimize network by exploiting
management configuration.
Single virtual hop for networking
services
Fully distributed control plane
(ARP, DHCP, ICMP)
Checklist for Network Virtualization
14
Multi-tenancy
Scalable, fault-tolerant devices
(or device-agnostic network
services).
L2 isolation
L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
Scalable gateways
Scalable control plane
• ARP, DHCP, ICMP
Floating/Elastic Ips
Stateful NAT
• Port masquerading
• DNAT
ACLs
Stateful (L4) Firewalls
• Security Groups
Load Balancing with health checks
Single Pane of Glass (API, CLI, GUI)
Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, System Center
Decoupled from Physical Network
Why Traditional Networking Doesn’t Work
•For example
•VLANs for L2 isolation
•VRFs for L3 isolation
•Not Designed For Speedy Provisioning
•Not Designed For Scale
•Consider virtual endpoints
•Not Designed For Multi-tenancy
•Services are not elastic
15
Using NV Overlays for Cloud Network
25
Multi-tenancy
Scalable, fault-tolerant devices
(or device-agnostic network
services).
L2 isolation
L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
Scalable Gateways
Scalable control plane
• ARP, DHCP, ICMP
Floating/Elastic IPs
Stateful NAT
• Port masquerading
• DNAT
ACLs
Stateful (L4) Firewalls
• Security Groups
Load Balancing with health checks
Single Pane of Glass (API, CLI, GUI)
Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, Docker
Decoupled from Physical Network
Neutron
•Default Implementation Is Not Scalable
•L4 services (NAT) are still bottlenecks
•Using namespaces
•Agents have serious fault tolerance issues
•DHCP, MetaData, DNS
•Fundamentally hard to fix
28
30
MidoNet Network Virtualization Platform
Logical L2 Switching - L2 isolation and path optimization with distributed virtual switchingInterconnect with VLAN enabled network via L2 Gateway
Logical L3 Routing – L3 isolation and routing between virtual networksNo need to exit the software container - no hardware required
Distributed Firewall – Provides ACLs, high performance kernel integrated firewall via a flexible rule chain system
Logical Layer 4 Load Balancer – Provides application load balancing in software form - no need for hardware based firewalls
VxLAN/GRE – Provides VxLAN and GRE tunnelingProvides L2 connectivity across L3 transport. This is useful when L2 fabric doesn’t reach all the way from the racks hosting the VMs to the physical L2 segment of interest.
MidoNet/Neutron API– Alignment with OpenStack Neutron’s API for integration into compatible cloud management software
v
Any Application
MidoNet Network Virtualization Platform
Any Network Hardware
OpenStack/Cloud Management System
Distributed Firewall
Layer 4Load Balancer
VxLAN/GRE
Any Hypervisor
Logical L2 Logical L3 NAT
MidoNet/
Neutron API
NAT – Provides Dynamic NAT, Port masquerading
MidoNet
31
Logical Topology
MidoNet Solution
15
Private IP Network
MN
MN
MN
Internet
BGP Multi
Homing
Physical Topology
MN VM
VM
MN VM
VM
MN VM
VM
BGP To ISP3
BGP To ISP2
BGP To ISP1
vPort
Provider Virtual Router
Tenant A
Virtual Router
Tenant B Virtual Router
Virtual
Switch A1
Virtual Switch A2
Virtual
Switch B1
vPort
vPort
vPort
vPort
vPort
Network State Database
MN MN MN
Tunnel
35
Mid
oN
et
Gate
way
Yo
ur E
xis
ting
Infra
stru
ctu
re
Provider Router
TenantRouter
TenantNetwork
192.168.5.2 192.168.5.3
Subnet 192.168.5.0/24
Address: 192.168.5.1Allow incoming tcp/22
NAT 192.168.5.2 <-> 112.140.32.94
VM to VM Communication
Mid
oN
et
Gate
way
Yo
ur E
xis
ting
Infra
stru
ctu
re
Now MidoNet can create a VXLAN tunnel between the required nodes, and send the packet on its way
36
VXLAN Tunnel
Distributed StateOn-demand
state
propagation
Virtual Networking at the Edge
Leverage ZK
RPC over TCP
Distributed State- VM sends first packet
- Kernel flow miss occurs; queues packet for
processing via Netlink
- MidoNet receives Netlink message for processing
Virtual Networking at the Edge
user space
kernel space
Distributed State
Virtual Networking at the Edge
user space
kernel space
MidoNet agent may query the
NSDB; then
- Locally processes packet
(virtual layer simulation)
- Installs local flow (drop/mod/fwd)
Virtual Networking at the Edge
user space
kernel space
Possible actions on flow table entry match:
- Set src/dst MAC to routerMAC/dstMAC
- Modify TTL
- Encapsulation with GRE or VXLAN + IP.
Key or ID tells dest host the destination vPort.
Virtual Networking at the Edge
Packet is delivered with overlay networking.
Destination host owns vport, identified by the
GRE key or VxLAN VNI.
40Gb VxLAN Offloading: virtualized environments require highthroughput infrastructure
• Integration with Mellanox provides 40 Gbps saturation
• VxLAN offloading improves CPU utilization levels• Scale with performance through HW interconnect• Increase throughput with offloading where no
offloading would otherwise have flat results• High bandwidth can now be achieved in software
Performance
OpenStack Integration
5
Easy integration with OpenStack:MidoNet provides a plugin for Neutron.
MidoNet Plugin
Open Source
•MidoNet was Open Sourced in November 2014
•www.midonet.org
•www.github.com/midonet/
•OpenStack and Docker need a high quality Open Source NVO solution!
50
Network Operating System
•Linux is everywhere
•ONIE & Cumulus Linux
•We can run our software on it!
•Fabric Monitoring and Control
•Resource Monitoring
•Traffic Engineering
•ECMP enhancement
52
Cannot ignore the physical network
54
Dynamic changes to logical
network are not dependent on the
physical network configuration.
Sharing state to and from the
physical network can be
supplementary.
- Monitoring
- Traffic Engineering
Big Data
56
NOS centralizes information on
your network
We can start taking advantage of
this information
- Security
- Compliance
- Optimizing Networks
57
It’s Open Source
http://www.midonet.org
Check out our blog:http://blog.midonet.org
Follow us on Twitter:@midonet
Distributed Flow-State
60
• MidoNet’s distributed architecture enables statefulnetwork functions at the edge
• Given the forward and return flows could have several ingress and egress nodes, “interested sets” get hints
• Advantages include:
• Lower latency to process flows
• Independence from a centralized transaction, like a database query
Distributed Flow-State
61
• For a new ingress flow, perform flow computation when flow state is created and store locally
• Prior to packet forwarding, the ingress node determines the interested set and then pushes the flow state
Distributed Flow-State
62
• Flow state is leveraged by flow computation and tunnel encapsulation
• Flow states are pushed between agents using Tunnel packets with special tunnel key values indicating “flow state”
Distributed Flow-State
63
• “Fire and forget” flow state propagation allows the “interested set” nodes to be informed without packet delay
• As ymmetrical data flow paths are easily handled given the flow state is propagated to the “interested set” of nodes
Stateful port groups
64
• Create port-group for the stateful ingress port group
midonet-cli> port-group create name SPG stateful true
• Add the ports to be load balanced e.g. all uplinks on Provider Router
midonet> port-group pgroup0 add member port router0:port0
midonet> port-group pgroup0 add member port router0:port1