Taming unruly apps with open source networking
•Download as PPTX, PDF•
1 like•416 views
LBaaS is a popular sought after service for tenants in service providers and enterprise IT alike. This session will discuss how MidoNet offers open source distributed networking for OpenStack and container environments.
More Related Content
What's hot
What's hot (20)
Similar to Taming unruly apps with open source networking
Similar to Taming unruly apps with open source networking (20)
More from Susan Wu
More from Susan Wu (8)
Recently uploaded
Recently uploaded (20)
Taming unruly apps with open source networking
- 1. Taming unruly apps with open source networking Susan Wu Director of Technical Marketing All Things Open 20
- 2. Cloudstack -> OpenStack -> MidoNet • Took the scenic drive to Open Source from proprietary software like Oracle, Citrix, Sun • Product marketing for container technologies like Solaris Zones, Docker • Plugins/Connectors for Enterprise Manager • Open Source community experience: Ubuntu, Docker, OpenStack, CloudStack, MidoNet
- 3. Open source software network virtualization Global startup with about 54 employees Founders built distributed systems at Amazon and Google Engineering in Barcelona, Tokyo, Tel Aviv Sales and Marketing in San Francisco Network Virtualization for OpenStack and Docker Customers in web scale, enterprise, higher ed and service provider segments
- 4. Applications type drives deployment type Expensive Proprietary Applications Monolithic Custom Applications Cloud Native Applications ContainersCattle VMsPet VMs
- 5. Proprietary applications are old news • Legacy is not going away soon • BUT.. New apps are not being built this way • Let’s move on.. Proprietary Apps Pet
- 6. Monolith applications stifle innovation Data Access Order UI User UI Shipping UI Order Service User Service Shipping Service Monolithic Apps Cattl
- 7. Cloud apps deployed in microservices Users Invites Recovery E-Mailing AdminSalescast Register Billing Detail Shipping Balance Status Reasons • Strong modularization • Best tech for the job (DBs, etc) • Smaller deployment units Cloud Apps
- 8. BUT microservices add network complexity • More components = more endpoints • Security/Policy complexity • Network Scaling Issues
- 9. A service can be deployed in multiple containers Shipping Service Tracking Rates Label Printing Pick List Barcode Scan Packing List
- 10. Why? Containers are lightweight
- 11. Containers are portable. • From your laptop to the cloud – Docker Machine https://github.com/docker/machine
- 12. Containers are easy $> sudo docker run –i –t ubuntu /bin/echo ‘Hello World’
- 13. Containers are not enough.. • Enter microservices frameworks..
- 14. “Docker is like the Holy Grail of development in that you can run an application on your desktop, and the exact same application without any changes can run on the server. That’s never been done before.” Steve Francia, Chief of Operations, Docker Project Most popular container technology is Docker
- 15. • libcontainer (built-in): – NAT Bridge – Host – Container – None (with nothing in its networking namespace) Docker offers built-in networking options
- 16. • Advantages – Isolation from underlay – Simple • Drawbacks – no easy cross-host – no advanced networking NAT Bridge lacks advanced networking libcontain
- 17. • Advantages – Directly on Underlay – Full capabilities • Drawbacks – Lack of isolation Container equals host libcontain
- 18. • Advantages – Isolation from underlay – Full communication containers • Drawbacks – no easy cross-host – no advanced networking Container struggles with cross-host libcontain
- 19. Overlay networks to the rescue it’s in software
- 20. Cloud networking scales better (224)
- 21. Distributed architecture brought by people behind Amazon
- 22. MidoNet is a truly open network overlay • 100% Software Based • API Driven • Distributed L2 to L4 Networking Services – L2/3 Switching – Routing – NAT – Firewall – Load Balancing – DHCP
- 23. Built on open source foundations • Not an SDN Controller • Stores network topology • Updates MidoNet agents with topology change • Apache Zookeeper stores the virtual network topology: bridges, routers, ports • Agents uses Zookeeper Watchers for notification of changes • Apache Cassandra stores virtual network state: MAC tables, ARP tables, Flow States Network State DB
- 24. Optimizing for availability Netw State • Cassandra is chosen for two things Zookeeper is poor at: 1. High Write volumes - Stores stateful connection information 2. Large data store - Stores large data like flow history Bonus: - Apache Spark for analytics
- 25. Mix and Match VMs and Containers with MidoNet
- 26. SDN intelligence at the edge 1. VM 1 sends a packet through the virtual network 2. MN Agent fetches the virtual topology/state 3. It simulates the packet through the virtual network 4. It installs a flow rule in the kernel at the ingress host 5. Tunnel packets to egress host
- 27. Docker Engine
- 28. Docker Engine KURYR 1. Driver.CreateNetwork 2. Create Neutron net and sub 3. Driver.CreateEndpoint 4. Container.create 5. Attach interfaces 6. Driver.join 1 3 5 4 6 2 Container Mapping Docker to OpenStack Networking
- 30. MidoNet a growing community 30,000+ Downloads 4500+ commits 25+ supporting companiesmetrics.midonet.org
- 31. Community site: www.midonet.org MidoNet All-in-one (on Ubuntu 14.04): $> wget -qO- http://midonet.org/midonet- quickstart.sh | sudo bash Join the conversation: slack.midonet.org Try MidoNet with one command
- 32. Questions?
Editor's Notes
- Monoliths couple change cycles together such that independent business capabilities have to be deployed on the same schedule. Something that is moving faster will have to wait for the slower services Services embedded in monoliths cannot be scaled independently, so load is far more difficult to account for efficiently. So what do you do? You size for peak Developers new to the organization must acclimate to a new team, learn a business domain, become familiar with an enormous code base all at once. So ramping up takes several months before you can get real developer productivity Can’t throw more people onto the problem. It just causes overcrowding, too many cooks in the kitchen syndrome, expensive coordination and communication overhead Technical Stacks are committed for the long haul. Introducing new techologies is considered a threat and can adversely affect the monolith
- Strong modularization – each deployable service/app is tracked as one codebase tracked in version control. There can be many deployed instances across multiple environments The service explicity declares and isolates dependencies via appropriate tooling rather than depending on implicitly dependences in its deployment environment Configurations can differ between deployment envrionements (dev/stage/prod) and is injected via OS level environment variables. Backing services database or message brokers are treated as attached resources and consumed identically across all envrironment Build, release, run
- Containers as a standalone is not enough – it requires automation -applications like Mesos, Kubernetes, OpenShift – help with scheduling automation
- None, nothing in its networking namespace, just the loop back device.
- NAT Bridge is the default networking docker option. It provides namespace isolation, communication between containers in the same host and leverage iptables, it allows ports in the address space of the host. Start the docker deamon, set ups network isolation, masquerading, each container would have its own networking address, Access the application from the outside, Port X goes to port Y Containers can talk to each other. Containers can discover each other. To make it cross-host, you have to expose all the services needed. There’s no concept like advanced networking like security group where a container can belong to a group and see the services that the group has allowed it to see.
- Container equals host. In this networking setting, the containers are spawned in the same networking namespace in which the docker daemon is running. This allows the containers to see the same networking as the host. You should trust the container that runs, it is capable of negatively impacting your networking configurations. For network plumbing, Host networking would be useful, as one could make an image of a daemon that has dependences and it becomes the base network namespace.
- Multiple containers can communicate with each other through the loopback device, share the name networking namespace Looks very similar to the pod concept in Kubernetes, second container uses the same IP as the first container (or full container between containers)
- A flat network is a network that does not provide any segmentation options. A traditional L2 ethernet network is a "flat" network. Any servers attached to this network are able to see the same broadcast traffic and can contact each other without requiring a router. flat networks are often used to attach Nova servers to an existing L2 network (this is called a "provider network"). If 2 tenants are sharing the same cluster, tenant 1 can see the traffic from tenant 2. This is not desirable for a cloud because you want to offer tenant isolation. A vlan network is one that uses VLANs for segmentation. When you create a new network in Neutron, it will be assigned a VLAN ID from the range you have configured in your Neutron configuration. Using vlan networks requires that any switches in your environment are configured to trunk the corresponding VLANs. However, VLANS are difficult to set up and configure and creates a unique tunnel ID, but there’s a limitation of 4096 segmentation IDs GRE segmentation and VXLANs works by encapsulating network traffic and provides tenant isolation. It allows for overlapping subnets and IP ranges. Just like VLANS, it also creates a unique tunnel Id, but there’s headroom with 6 million. Unlike VLAN networks, overlay networks does not require you to synchronize our OpenStack configuration with your L2 swtich configuration. In VLAn, any switch in your environment are configured to trunk the corresponding VLANS, which can be troublesome if your
- Fully virtualized Layer 2 to 4 Networking MidoNet helps create switches, routers, DHCP, NAT, load balancers and firewalls among other network services. Open Source Distributed containerizable “controller” Logical Switching Distributed virtual switching, Layer 2 over Layer 3, decoupled from the physical network without limitations of convention VLANs Interconnect with VLAN/VxLAN networks (physical and virtual) via software L2 Gateway Logical Routing Routing between virtual networks without exiting the software container Logical Firewall Distributed Firewall that is integrated with the Linux kernel Enforces security policies at ingress (to keep bad traffic from the private cloud) – Native security groups Layer 4 Load balancing with health monitor Distributed Stateful NAT Bring traffic from an external network to a floating IP address for a tenant router Perform network address translation from the external network's public IP address to a private IP address and in the reverse direction.
- How it works Cross-host networking for containers Advanced networking opportunities Solves these problems that the traditional networking could not address
- Cross-host networking for containers Advanced networking opportunities Today MidoNet uses docker event interface to gather container information Planned integration with Docker libnetwork. MidoNet plugin to Docker to provide advanced networking for cross-host containers (e.g. tunneling, load balancing and more)
- What happens when you launch an instance,
- Source: Google analytics, midonet.org (Nov 2014 to August 31, 2015)