Cloudstack collab talk
Upcoming SlideShare
Loading in...5
×
 

Cloudstack collab talk

on

  • 1,374 views

Making a case for network virtualization

Making a case for network virtualization

Statistics

Views

Total Views
1,374
Views on SlideShare
1,374
Embed Views
0

Actions

Likes
4
Downloads
34
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Cloud ManagementComputeStorageNetworking
  • The CMS (cloud management system) integration is critically importantWe have built a deep integration with OpenStackL2 isolation is a given!L2 isolation is not enoughL3 isolation (inter-network routing), scalable NAT, scalable security groups are also needed for a complete solution

Cloudstack collab talk Cloudstack collab talk Presentation Transcript

  • Making a case fordistributed overlay-based network virtualization Ben Cherian Chief Strategy Officer @bencherian Midokura
  • So, you’re building a cloud?
  • Requirements
  • 1 2 3 4 5 vs 1 New 1Horizontal scaling
  • Building blocks of an IaaS cloud
  • Cloud management system
  • Compute
  • Storage
  • Networking
  • Traditional networking devices scale up
  • Service interruptions
  • High churn, micro granularity
  • Limitations of VLANs
  • Traffic trombones
  • Human costs don’t scale
  • AdditionalRequirements
  • IaaS Cloud Networking Requirements• Multi-tenancy • ACLs• L2 isolation • Stateful (L4) Firewall  Security Groups• L3 routing isolation  VPC • VPN  Like VRF (virtual  IPSec routing and forwarding) • BGP gateway• Scalable control • REST API plane • Integration with CMS  ARP, DHCP, ICMP  CloudStack• NAT (Floating IP)  OpenStack
  • IaaS Cloud Networking Requirements Typical Network Topology uplink- Creat e one provider rout er upon deployment - Link to uplink- Creat e a rout er f or a t enant - BGP multi-homing- M ap a bridge f or a quant um net work - Global NAT/route settings, e.g. for floating ip Provider Virtual Router (L3) - Tenant router for FW, LB, DHCP and NAT Tenant/Project A Tenant/Project B Tenant B Tenant A Virtual Router Virtual Router Network A1 Network A2 Network B1 TenantB office Virtual L2 Virtual L2 Virtual L2 Switch A1 Switch A2 Switch B1 Tenant B VPN Router VM1 VM3 VM5 VM2 VM4 VM6 Office Network
  • Solution: Distributed overlay-based network virtualization
  • Use encapsulation tobuild a virtual network
  • Handle network intelligence / network state at the edge
  • Require less of the physical network
  • Edge to Edge IP Overlays• Isolation not using VLANs  IP encapsulation• Decouple from physical network• Provisioning VM doesn’t change underlay state• Underlay delivers to destination host IP• Use scalable IGP (iBGP, OSPF) to build multi-path underlay• Inspired by VL2 from MSR
  • Market trends supporting overlay model• Packet processing on x86 CPUs (at edge) – Intel DPDK facilitates packet processing – Number of cores in servers increasing fast• Clos Networks (for underlay) – Spine and Leaf architecture with IP – Economical and high E-W bandwidth• Merchant silicon (cheap IP switches) – Broadcom, Intel (Fulcrum Micro), Marvell – ODMs (Quanta, Accton) starting to sell directly – Switches are becoming just like Linux servers• Optical intra-DC Networks
  • The MidoNet Solution• Virtual L2 Distributed Switching• Virtual L2 Isolation• Virtual L3 Distributed Routing• Virtual L3 Isolation• L4 Services (Load Balancing, Firewall)• NAT• Access Control Lists (ACLs)• Virtual port and device monitoring• Restful API• Web based management control panel
  • The MidoNet Solution Logical Topology vPort Virtual Tenant A Switch A1 Virtual vPort Router vPort Provider Virtual Virtual Switch A2 vPort Router Tenant B vPort Virtual Virtual Router Switch B1 vPort VM MN MN VM BGP BGP Multi To ISP1 HomingInternet Private IP VM MN Network MN VM BGP To ISP2 Tunnel BGP To ISP3 VM MN MN VM MN MN MN Network State Database Physical Topology
  • The MidoNet Solution• Distributed and scalable control plane  Handle all control packets at local MidoNet agent adjacent to VM• Scalable and fault tolerant central database  Stores virtual network configuration  Dynamic network state  MAC learning, ARP cache, etc  Cached at edges on demand• All packet modifications at ingress Packet Tunnel Ingress  One virtual hop MN  No travel through middle boxes Encapsulated  Drop at ingress Drop/Block
  • Scale out model
  • The MidoNet Solution• Scalable edge gateway interface to external networks – Multihomed BGP to ISP• REST API and GUI• Integration with popular open source cloud stacks – OpenStack • Removes SPOF of network node • Scalable and fault tolerant NAT for floating IP • Implements security groups efficiently – CloudStack (in progress)
  • CloudStack integration• Currently have L2 integration• Full integration is slated for Q1, 2013 – L3 isolation (without VM / appliance) – Security groups (stateful firewall) – Floating IP (NAT) – Load balancing (L4)
  • Questions?Slides: http://www.slideshare.net/midokura
  • Backup slides
  • Candidate Models• Traditional network• Centrally controlled OpenFlow based hop- by-hop switching fabric• Edge to edge overlays
  • Traditional Netowrk• Ethernet VLANs for L2 isolation  4096 limit  VLANs will have large spanning trees terminating on many hosts  High churn in switch control planes doing MAC learning non-stop  Need MLAG for L2 multi-path  Vendor specific• MPLS VPN?• VRFs for L3 isolation  Not scalable to cloud scale  Expensive hardware  Not fault tolerant
  • OpenFlow Fabric• State in switches  Proportional to virtual network state  Need to update all switches in path when provisioning  Not scalable, not fast enough to update, no atomicity of updates• Not good for IaaS cloud virtual networking
  • Spine and Leaf Network Architecture
  • Deep OpenStack Integration• Quantum Plugin – L2 isolation, of course• Also… – L3 isolation (without VM / appliance) – Security groups (stateful firewall) – Floating IP (NAT) – Load balancing (L4)37