cloudstack collab talk

Download Cloudstack collab talk

Post on 12-May-2015




0 download

Embed Size (px)


Making a case for network virtualization


  • 1.Making a case fordistributed overlay-basednetwork virtualizationBen CherianChief Strategy Officer@bencherianMidokura

2. So, youre building acloud? 3. Requirements 4. 12 3 4 5 vs1 New 1Horizontal scaling 5. Building blocks of an IaaS cloud 6. Cloud managementsystem 7. Compute 8. Storage 9. Networking 10. Traditional networkingdevices scale up 11. Service interruptions 12. High churn, micro granularity 13. Limitations of VLANs 14. Traffic trombones 15. Human costs dont scale 16. AdditionalRequirements 17. 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 APIplane Integration with CMS ARP, DHCP, ICMP CloudStack NAT (Floating IP) OpenStack 18. IaaS Cloud Networking Requirements Typical Network Topologyuplink- 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 oating ipProvider VirtualRouter (L3)- Tenant router forFW, LB, DHCP and NATTenant/Project A Tenant/Project B Tenant B Tenant AVirtual RouterVirtual Router Network A1Network A2Network B1 TenantB ofceVirtual L2 Virtual L2Virtual L2Switch A1Switch A2 Switch B1 Tenant BVPN Router VM1VM3VM5VM2 VM4VM6Ofce Network 19. Solution: Distributed overlay-based network virtualization 20. Use encapsulation tobuild a virtual network 21. Handle network intelligence / network state at the edge 22. Require less of the physical network 23. Edge to Edge IP Overlays Isolation not using VLANs IP encapsulation Decouple from physical network Provisioning VM doesnt change underlay state Underlay delivers to destination host IP Use scalable IGP (iBGP, OSPF) to build multi-pathunderlay Inspired by VL2 from MSR 24. 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 25. 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 26. The MidoNet SolutionLogical TopologyvPortVirtual Tenant ASwitch A1VirtualvPortRoutervPort Provider Virtual VirtualSwitch A2vPort RouterTenant B vPort Virtual Virtual Router Switch B1 vPortVMMN MN VMBGPBGPMulti To ISP1 HomingInternet Private IPVMMN NetworkMN VMBGP To ISP2 TunnelBGP To ISP3 VM MN MN VM MN MNMNNetwork State Database Physical Topology 27. 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 ingressPacketTunnel Ingress One virtual hopMN No travel through middle boxes Encapsulated Drop at ingressDrop/Block 28. Scale out model 29. 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) 30. 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) 31. Questions?Slides: 32. Backup slides 33. Candidate Models Traditional network Centrally controlled OpenFlow based hop-by-hop switching fabric Edge to edge overlays 34. 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 35. 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 36. Spine and Leaf Network Architecture 37. Deep OpenStack IntegrationQuantum Plugin L2 isolation, of courseAlso L3 isolation (without VM / appliance) Security groups (stateful firewall) Floating IP (NAT) Load balancing (L4)37