Openstack Nova and Quantum
Download as PPTX, PDF5 likes3,773 views
The document discusses the integration of OpenStack Nova and Quantum for managing and networking virtual machines in large data centers, highlighting challenges and solutions provided by this technology. It contrasts OpenStack with AWS's Virtual Private Cloud (VPC), emphasizing OpenStack's open and scalable platform and its plug-in architecture for enhanced network management. Future directions for Quantum include seeking core project status, adding new plugins, and improving integration with other services.
Openstack Nova and Quantum
- 1. OpenStack Nova and Quantum Dave Lapsley dlapsley@nicira.com
- 2. Outline • What is the challenge? • How do Nova + Quantum meet the challenge? • What about AWS VPC? • Quantum Architecture • Where is Quantum headed?
- 3. Nova/Quantum Architecture http Dashboard EC2/Openstack API EC2/Admin API Glance API Glance API Nova API Nova Compute Nova Glance Image Nova Network/ Nova Registry Store Queue Quantum Database (swift,etc) Manager Glance Database Volume Nova Nova Storage Volume Schedule Adapted from http://ken.pepple.info/openstack/2011/04/22/openstack-nova-architecture/
- 4. Large data centers today can have around 2.4 million Virtual Machines How do we manage and network these virtual machines and the services built around them?
- 5. OpenStack provides an open-source, innovation-enabling platform for doing just this Open, scalable, secure, and manageable computing and networking in the cloud* * Storage too! But that’s an entire presentation in itself.
- 6. OpenStack Nova Virtualize Computation Hypervisor 1 Hypervisor 32 VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM to Public Network Physical Network Hypervisor 992 Hypervisor 1024 VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM
- 7. How do we manage connectivity? Tenant VM VM Tenant VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Public Network Accesss VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Tenant VM VM Tenant
- 8. Quantum Virtualize Network Tenant A Tenant B Tenant C S S S S S WS WS S S IDS IPS S IPS FW WS WS FW Public Network Access Tenant D FW FW WS WS IDS IPS IPS S IDS S S S S S S S S S S
- 9. Quantum • A standalone OpenStack service • Provides network connectivity between a set of network interfaces from other services • Exposes API of logical abstractions for describing network connectivity + policy between interfaces. • Uses a plug-in architecture, so multiple technologies can implement the logical abstractions • Provides a technology agnostic platform for sophisticated cloud network topologies
- 10. AWS VPC • Amazon Web Service Virtual Private Cloud – “…lets you provision a private, isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define.” – Similar goals and functionality to OpenStack Quantum • But… different ecosystem – Closed system – Provided API and that’s it – Must use AWS • Compare with Nova + Quantum
- 11. Quantum: Single Service OpenStack Dashboard Quantum Plugin nova-api Tenant API Quantum Service Nova Service nova-api quantum-plugin nova-scheduler Internal plugin communication VM VM VM nova-compute VM VM VM VM VM Hypervisor VM VM VM VM VM VM VM VM vswitch
- 12. Quantum: Two Services OpenStack Dashboard firewall service Quantum Plugin nova-api Tenant API Quantum Service Nova Service nova-api quantum-plugin nova-scheduler Internal plugin communication VM firewall service VM VM VM VM VM VM nova-compute VM VM VM VM VM Hypervisor FW FW FW FW VM VM VM VM VM VM VM VM physical switch vswitch
- 13. Quantum Architecture Tenant API Admin API Auth (via Keystone) Plugin might manage just the API Access Control network edge Plugin interface maps to (e.g., a vswitch), “core” tenant API + or all network admin API. Plugin devices. External Devices Plugin communicates with external devices to “Network agents” running on nova implement logical abstractions from the tenant hypervisor fit within this model. API
- 14. Virtual Network Abstractions (1) • Interface IDs: – Services (e.g., nova, atlas) expose interface-IDs via their own tenant APIs to represent any device from that service that can be “plugged” into a virtual network. – Example: nova.foo.com/<tenant-id>/server/<server-id>/eth0 • Networks: – Tenants use Quantum API to create networks, get back UUID: – Example: quantum.foo.com/<tenant-id>/network/<network-id> • Ports: – Tenants can create ports on a network, get a UUID, and associate config with those ports (APIs for advanced port config are TBD, initially ports give L2 connectivity): – Example: quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id> • Attachments: – Tenants can “plug” an interface into a port by setting the attachment of a port to be the appropriate interface-id. – Example: set quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>/attach to value “nova.foo.com/<tenant-id>/server/<server-id>/eth0” .
- 15. Virtual Network Abstractions (2) • Implementation Abstraction: – At no time does the customer see details of how a network is implemented (e.g., VLANs). • Explicit Association: – Association of interfaces with network is an explicit step more control. • API Extensions: – Plugins can expose API extensions to introduce more complex functionality (e.g., QoS). Extension support is queriable, so a customer can “discover” capabilities. • Extension Refactoring: – API extensions that represent common functionality across many plug-ins can become part of the core API. • API Evolution: – Core API is currently simple, focused on connectivity. Core API will evolve.
- 16. Example Scenario Nova i-23 Nova i-26 Nova i-22 Nova i-24 GW instance 10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 10.0.0.1 Tenant View Private Private Net #1 Net #2 Hypervisor 1 Nova i-23 Nova i-22 10.0.0.23 10.0.0.22 Provider View Data GW instance Center 10.0.0.1 Hypervisor 2 Nework Nova i-26 Nova i-24 10.0.0.26 10.0.0.24 Compute Service NAT Gateway Service
- 17. Example Scenario w/ VLAN Plugin Nova i-23 Nova i-26 Nova i-22 Nova i-24 GW instance Tenant View 10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 10.0.0.1 Private Private Net #1 Net #2 Hypervisor 1 Nova i-23 Nova i-22 10.0.0.23 10.0.0.22 Provider View Data GW instance Center 10.0.0.1 Hypervisor 2 Nework Nova i-26 Nova i-24 10.0.0.26 10.0.0.24 Compute Service NAT Gateway Service
- 18. VLAN Plugin • One VLAN per “network” • Hypervisor NIC is VLAN trunk, all switches are trunked. • When an interface-ID is associated with a network, plugin uses the edge binding to find the interface-location (a port on a vswitch) and puts that port on the correct VLAN.
- 19. Future Directions • Applying for core project status for Folsom • Expect 5-10 new plugins in next 6 months. • Support for new overlay technologies like NVGRE + VXLAN • L3 routing + Firewall capabilities via new Quantum API • VPN, data-center-interconnect technologies. • Closer integration with Melange (IP address management) • Improved Horizon integration.
- 20. Summary • What is the challenge? – Managing and networking data centers and their services • How do Nova + Quantum meet the challenge? – Open, scalable, secure, and manageable computing and networking in the cloud* • What about AWS VPC? – Great goals! Not open. • Quantum Architecture – Network connectivity as a service, API of logical abstractions, plug-in architecture, service pluggability. • Where is Quantum headed? – Core status, new plugins, new technologies, L3/FW + new API, VPN DCI technologies, closer integration with IPAM and Horizon
- 21. Thank you dlapsley@nicira.com http://wiki.openstack.org/Quantum