Getting to Unified Network Services
•Télécharger en tant que PPTX, PDF•
3 j'aime•775 vues
Kickoff presentation at OpenStack Diablo design summit explaining process of rationalizing different blueprints and introducing proposed plan for networking in OpenStack.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
Similaire à Getting to Unified Network Services
Similaire à Getting to Unified Network Services (20)
Dernier
Dernier (20)
Getting to Unified Network Services
- 1. Getting to Unified Network Services Erik Carlin erik.carlin@rackspace.com
- 2. The Time for Cloud Networking is NOW The world wants: 1. Security Hypervisor becoming more accepted as a multi-tenant security boundary Now want network isolation Workload Migration and Cloud Bursting Canonical APIs (+ extensions) No lock-in VM image format Network federation
- 3. History NetworkService Rackspace/Nicira NetworkContainers Cisco NetworkService Citrix/Rackspace/Nicira NaaS Core Design Intel NetworkServicePOC NTT/Midokura Unified Plan
- 4. Process & Thoughts Started conversation with people who drafted the blueprints Goal was convergence so we’re not presenting competing blueprints Rationalized conclusions are still proposals Today represents a point in time snapshot, we’re not done This is the beginning, we want and need more involvement
- 5. 14 hours Etherpad Discussion: http://tinyurl.com/osnetwork Wiki Summary: http://wiki.openstack.org/NetworkServiceDiablo
- 6. Participants (I know I missed some – sorry!)
- 7. Conclusions There is no more “NaaS” Networking capabilities are diverse enough that we don’t want a single monolithic network service Decompose into independent OpenStack network projects/services that are individually deployable but can work as a suite e.g. Core L2/L3, IPAM, FW, LB, etc. Assess service granularity over time to ensure not too fine grained Containers are extremely valuable but broader than network and should become it’s own higher level service Start with simple building blocks and add to them over time Experimental in diablo
- 8. Diablo Goals “Quantum” Service Def: The smallest amount of a physical quantity that can exist independently Most basic network building block service Expose an L2 network and enable other services (compute, LB, FW, etc.) to attach to it L2 bridging / federation a latter step that may be in Quantum or a separate VPN service
- 9. Diablo Goals IPAM Service (still need a project name) Provide IP address management capabilities across services including nova, LB, FW, etc. Could evolve into a broader repository of network information
- 10. Diablo Goals “Donabe” Service Def: Japanese clay pot Ability to create “containers” of cross service cloud resources and have them assembled (and potentially managed) Containers can be hierarchical High level orchestration service Think DCaaS or AWS Cloud Formation
- 11. Diablo Goals Nova Refactoring to Support These Services Introduce using a parallel approach to minimize disruption to nova Several potential ways of doing this and need feedback from nova devs
- 12. Questions?
Notes de l'éditeur
- Hypervisor – PCI 2.0 compliance on EC2APIsApps and ecosystem tools still workQueryable endpoint catalog, versions, and extensionsNo lock-inPeople use HA Proxy instead of ELBBut, same SW means you can feel comfortable leveraging and migrating those resourcesVM image formatGlance image conversionNetwork federationFederated zones in nova is coolAlso need federated network
- Successfully aligned on overall approach and target diablo deliverables
- Define the logical networking modelDefine the standard edge interface points between quantum and “interface services”Define a pluggable way in which quantum and interfaces services interact to “plug in”
- Start with network containers