Getting to Unified Network Services
Download as PPTX, PDF3 likes779 views
The document discusses the shift towards unified network services for cloud networking, emphasizing the need for security, network isolation, and workload migration. It proposes breaking down monolithic network services into independent, deployable OpenStack projects while introducing concepts like IP address management and orchestration services. The goals outlined reflect ongoing discussions and experimentation, seeking further involvement and feedback from the community.
Getting to Unified Network Services
- 1. Getting to Unified Network ServicesErik Carlinerik.carlin@rackspace.com
- 2. The Time for Cloud Networking is NOWThe world wants:1. SecurityHypervisor becoming more accepted as a multi-tenant security boundaryNow want network isolationWorkload Migration and Cloud BurstingCanonical APIs (+ extensions)No lock-in VM image formatNetwork federation
- 4. Process & ThoughtsStarted conversation with people who drafted the blueprintsGoal was convergence so we’re not presenting competing blueprintsRationalized conclusions are still proposalsToday represents a point in time snapshot, we’re not doneThis is the beginning, we want and need more involvement
- 5. 14 hoursEtherpad Discussion:http://tinyurl.com/osnetworkWiki Summary:http://wiki.openstack.org/NetworkServiceDiablo
- 6. Participants (I know I missed some – sorry!)
- 7. ConclusionsThere is no more “NaaS”Networking capabilities are diverse enough that we don’t want a single monolithic network serviceDecompose into independent OpenStack network projects/services that are individually deployable but can work as a suitee.g. Core L2/L3, IPAM, FW, LB, etc. Assess service granularity over time to ensure not too fine grainedContainers are extremely valuable but broader than network and should become it’s own higher level serviceStart with simple building blocks and add to them over timeExperimental in diablo
- 8. Diablo Goals “Quantum” ServiceDef: The smallest amount of a physical quantity that can exist independentlyMost basic network building block serviceExpose an L2 network and enable other services (compute, LB, FW, etc.) to attach to itL2 bridging / federation a latter step that may be in Quantum or a separate VPN service
- 9. Diablo GoalsIPAM 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” ServiceDef: Japanese clay potAbility to create “containers” of cross service cloud resources and have them assembled (and potentially managed)Containers can be hierarchicalHigh level orchestration serviceThink DCaaS or AWS Cloud Formation
- 11. Diablo GoalsNova Refactoring to Support These Services Introduce using a parallel approach to minimize disruption to novaSeveral potential ways of doing this and need feedback from nova devs
- 12. Questions?
Editor's Notes
- #3: 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
- #8: Successfully aligned on overall approach and target diablo deliverables
- #9: 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”
- #11: Start with network containers