Guillaume Morini @GuillaumeMorini
Systems Engineer
November 2016
Openstack Day France
SDN dans OpenStack
Retour d’expérien...
Agenda
• Cisco & OpenStack
• Customers’ OpenStack projects
• And the network part ?
• Cisco SDN solutions for OpenStack
• ...
Cisco’s Commitment to OpenStack
• Cisco Validated Designs
for production deployments
• Work closely and jointly
with custo...
Fast Data Project – FD.io
Open Source VPP – Vector Packet Processor
VPP vs OVS performance
https://fd.io/technology
• VPP ...
OpenStack & Cisco technologies
Nexus switches &
Application-Centric Infrastructure (ACI)
MDS SAN switches
ASR 1000 routers...
OpenStack projects
Deployment Class
2X Prod
Growth
April 2016 Openstack User Survey
April 2016 Openstack User Survey
“For Neutron, they wanted the networking
service to be less complicated to use, with
more...
Is SDN the solution ?
Cisco SDN Solution
for OpenStack
Broad and Deep Networking Capabilities
OpenStack – SDN options
Programmable SDN Model
(Cisco APIC/ACI)
Underlay/Overlay In...
Application-Centric Infrastructure
Logical Network Provisioning of Stateless Hardware
ACI Fabric
Outside
Web App DB
QoS
Fi...
Programmability & Open Ecosystem Framework
Open Source Open Standards
Published
Data Model
Open and
Standard APIs
ACI + OpenStack – With OpFlex Support
Full Policy Based Network Automation Extended to the Linux Hypervisor
Group-based Po...
Customers’ use cases
Deploy a fully
software-defined
Cloud solution,
based on
OpenStack.
First step,
IaaS platform
Then,
add services
on top
Ex...
Network requirements for this use case
• Communication with existing network
• Existing network tools
• Service chaining f...
Spine3
Leaf3
Spine1 Spine2
Leaf2Leaf1
Typical architecture for this use case
Control1
Apic1
Apic2
Apic3
OpenStack SDN envi...
APIC driver directly creates
application network profiles
OpenStack ACI Plugin - Details
ACI fabric offers
distributed L2,...
Customers’ feedbacks
Customers’ benefits of OpenStack and ACI
Distributed, Scalable
Virtual Networking
• Fully distributed L2, anycast
gateway,...
Full visibility of Openstack in the network console
OpenStack
VMM Domain
KVM Hypervisor
Operational Data
Per
Hypervisor /
...
Automatic creation of ACI objects based on
Openstack ones
Neutron Object ACI
(Neutron Instance) Tenant
Project Application...
Conclusion
Next steps for customer
Reuse/Extend SDN for other use cases
ESX1 ESX2 ESX3HyperV
BareMetal
Docker
Docker
LxC
KVMKVM
RKT1
...
OpenStack Day France - Retour d'expérience sur le SDN avec OpenStack
Prochain SlideShare
Chargement dans…5
×

OpenStack Day France - Retour d'expérience sur le SDN avec OpenStack

156 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
156
Sur SlideShare
0
Issues des intégrations
0
Intégrations
0
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Bonjour, je m'appelle Guillaume Morini et je suis Systems Engineer chez Cisco spécialisé sur l'automatisation, l'orchestration et les environnements Cloud de tout type.
    Aujourd'hui je vais partager avec vous un retour d'expérience sur le SDN dans OpenStack. Initialement je devais coprésenté avec un client, grand industriel européen, mais malheureusement, suite à des contraintes légales, vous allez devoir me supporter pendant les 30 prochaines minutes
    Cette présentation est tirée des échanges que j'ai pu avoir avec ce client ainsi qu'avec d'autres également
  • Tout d'abord je partagerai avec vous l’implication de Cisco auprès de la communauté OpenStack
    Ensuite, je détaillerai ma vision du marché sur les projets OpenStack chez nos clients, ainsi que le statut de la partie réseau dans ces projets
    J'expliciterai par la suite les solutions dont Cisco dispose pour simplifier la notion de réseau dans OpenStack, en en prenant une en exemple
    Enfin, je détaillerai les cas clients que j'ai pu rencontrer ainsi que leurs retours sur cette solution
    Merci de réserver vos questions pour la fin de la session, où je garderai du temps pour y répondre
  • Cisco participe activement à la communauté depuis 2011 (5 ans) . Membre du comité directeur d’OpenStack, très impliqué sur des projets comme Kolla ou Magnum
    Cisco est également un utilisateur très actif d’OpenStack comme pour notre offre de web conferencing Webex, entièrement basé sur OpenStack

    En tant que constructeur, nous certifions et validons des architectures pour le deploiement d’Openstack basé sur nos produits et ceux de nos partenaires

    How Cisco is embracing Open standard and Openstack
  • Nous avons également des projets connexes à OpenStack comme FD.io, qui permet de rendre plus efficace le traitement des paquets par les serveurs de compute afin d’accroitre les performances software
    Ce développement est basé sur le code utilisé à l’intérieur des routeurs physiques qui a été porté sur du x86 et rendu OpenSource depuis cette année pour une intégration, par exemple dans OpenStack au travers d’un plugin ML2 pour les environnements type opérateur nécessitant une très haute performance du virtual forwarder
  • Globalement Cisco travaille à intégrer au mieux l’ensemble de ces gammes produits qui ont un sens à être intégrer à OpenStack pour simplifier l’expérience cliente, tout en apportant le maximum de fonctionnalités de ces produits au sein d’OpenStack
  • Aujourd'hui sur le marché on voit un fort engouement des grandes entreprises Françaises pour OpenStack. Certains sont encore sous forme exploratoire, j’assiste à de nombreux POC, expérimentations, mais aussi de plus en plus de vrais projets allant jusqu’à la production pour permettre de fournir aux développeurs des entreprises de vrais solutions innovantes et agiles, permettant de disposer de ressources lorsqu’on en a besoin, sans délai
  • Sur ces différents projets, un des points bloquants est l’intégration d’OpenStack avec l’environnement réseau existant,
    Il est complexe pour les organisations actuelles d’aboutir à une solution simple et efficace de déploiement et surtout d’exploitation d’un projet OpenStack de grande envergure (> à 50 noeuds)

    L’utilisation d’OpenVswitch fourni en standard dans la plupart des distributions est complexe à appréhender, aussi bien pour les équipes systèmes que les équipes réseaux.
    Même avec des améliorations telles que le DVR, cela ne suffit pas
    La solution globale apparait aux utilisateurs comme complexes, non optimisées et peu intégrées

  • Du coup, pour les entreprises, SDN apparait comme une solution logique pour aider au déploiement d’Openstack. Cela est totalement pertinent, du fait que le terme “software defined” peut signifier “defined by Openstack”

    Pour autant SDN est un terme très générique, qui ne signifie pas la même chose pour toutes les personnes et dont la définition est encore floue.
    Chaque constructeur a sa propre définition ainsi que sa propre solution.
    Je vais vous présenter les solutions SDN de Cisco
  • Cisco has a SDN solution which integrate with Openstack but brings a lot more
  • Cisco ajoute aux solutions standards d'OpenStack, 2 grands types de solutions, une solution basée sur BGP-EVPN, pour les très gros déploiements de type opérateurs et une solution intégrée nommée ACI, plutot orientée entreprise. Je vais vous détailler cette dernière, qui est la plus représentée chez mes clients
  • ACI est une solution de type fabric, composée de deux étages de switches, pour améliorer les performances entre serveurs et simplifier la croissance de l’infrastructure, qui permet de traiter nativement en hardware du VLAN ainsi que du VxLAN.

    Cette fabric est opéré par un cluster de controleurs nommée APIC, pour fournir un point d’administration et d’exploitation unique, évitant les configurations unitaires switche par switches et permettant de simplifier la programmation par API

    Au dessus de cela, ACI définit un modèle de fonctionnement (policy model en anglais), permettant de définir le réseau comme un moyen de communiquer entre des groupes de machines au travers de contrat de service, ceci permet de s’abstraire de la terminologie réseau et de se rapprocher de la terminologie applicative
  • Cette solution est partie prenante d’un virage chez Cisco pour favoriser l’ouverture de nos solutions, aussi bien pour l’intégration avec des composants d’autres vendeurs que vers la communauté OpenSource.
    Ainsi le modèle de données utilisé par ACI a été publié sur GitHub, Le fonctionnement interne à la fabric ACI est basé sur des standards de l’IEEE ou de l’IETF, beaucoup de composants et d’outils autour d’ACI sont OpenSource et les API pour interagir avec l’APIC sont standards et ouvertes
  • L’intégration que nous avons développé avec OpenStack est une des intégrations la plus poussée du marché, en effet la création des objets dans Openstack, déclenche la configuration automatique dans la fabric ACI, sans sacrifier la rapidité de mise en oeuvre, la performance ou la visibilité permettant de déployer cette solution en production
    Il existe 2 configuration sur cette intégration, soit au travers d’un driver ML2 dans Neutron, soit au travers de l’implémentation GBP que nous avons poussé et qui a été normalisé par la communauté OpenStack

    Notre solution est désormais supportée sur l’ensemble des distributions OpenStack commerciale du marché
  • Je voudrais maintenant passé du temps sur les différents cas clients auxquels j’ai été confronté
  • Souvent, cela commence par la volonté de disposer d’un cloud privé compétitif
    On arrive très vite sur la solution OpenStack qui est mise en place en 2 étapes, une première pour l’établissement d’un catalogue de services de type IaaS
    Ceci permet d’avoir un premier jalon qui peut commencer à étre utilisé par l’IT ou les développeurs de l’entreprise
    Dans un deuxième temps il est envisagé d’offrir des services plus évolués de type PaaS sur la base de la même plateforme

    Même si ceci peut vous sembler simple, cela peut vite devenir un vrai casse tête pour des organisations très silotées et peu automatisées
    En effet, il faut que les équipes systèmes, stockage, réseau et sécurité collaborent de concert pour arriver à une solution qui satisfassent tout le monde
    Ceci peut amener à une vrai révolution
  • En particulier pour l’équipe réseau, qui même si elle est automatisée, ce qui n’est pas toujours le cas, l’ait en général avec des outils spécifiques
    L’arrivée d’un nouvel environnement OpenStack peut bouleverser le travail réalisé et complexifier son intégration avec l’existant.
    Pour autant, il faut absolument que cette bulle puisse communiquer avec le reste du réseau, de façon simple, robuste et performante
    Cette bulle est souvent petite au départ et va grossir au fur et à mesure du succès de cet environnement, elle doit donc s’intégrer à l’exploitation réseau et à ses outils sans pour autant tout révolutionner juste pour ce cas d’usage
    Enfin, l’automatisation va également souvent s’étendre aux services réseaux , comme les parefeux ainsi que les répartiteurs de charges

    Tout ceci, sans sacrifier la performance, car souvent les environnement de ce type, utilisent du stockage distribués de type ceph par exemple, qui ont des contraintes sur les I/O réseaux et qui nécessitent de la connectique 10G sur les serveurs

  • Mieux qu’un long discours , je vais illustrer ces besoins par une architecture typique qui répond à ces problèmatiques et que j’ai vu déployée chez plusieurs clients
    Il s’agit de connecter le réseau existant, aux serveurs OpenStack et surtout à leurs instances, au travers de la bulle SDN qui a été défini pour cela
    Cette bulle est basé sur notre solution ACI

    Si on fait un zoom à l’intérieur on retrouve une architecture de type fabric ainsi que le cluster de controleur
    Cette architecture permet de facilement évoluer, lorsqu’on a besoin de rajouter de la capacite en nombre de ports, on ajoute un switch de type leaf
    Si on a besoin de plus de bande passante, on ajoute un switch de type spine

    Vous allez me dire que la solution semble magique, zoomons alors sur l’intégration entre ACI et OpenStack et sur son fonctionnement
  • Les controleurs ont un plugin leur permettant de parler entre OpenStack et les controleurs ACI, pour relayer les ordres de création d’objets et savoir quand ils sont créés
    Les controleurs APIC traduisent les ordres pour les relayer aux switches mais également jusqu’au noeud de compute, qui grace à un agent comprenne le même protocole que les switches à savoir Opflex, et sont donc vus comme une extension de la fabric, permettant d’avoir les même regles portés par tous les éléments
  • Maintenant que vous avez bien compris les cas clients et la solution ACI, je voudrais partager avec vous les retours et les bénéfices constatés par nos clients
  • De leur propre bouche, cette intégration permet de disposer d’une vrai solution distribuée pour le traitement des flux réseaux, évitant les points sensibles ou de congestion.
    En effet le routage des paquets peut donc se faire au plus près des instances, à savoir directement sur le serveur de compute ou sur le switch Top of Rack, en fonction des besoins

    Le dimensionnement de la solution est également grandement facilité par l’utilsation naturelle de VxLAN puisque la création des tunnels est complètement automatisé par la solution, en mode à la demande lors de la définition des objets dans OpenStack

    De plus, la solution permet de gérer très facilement l’insertion, voire la configuration, de pare feux ou de load balanceurs lorsque cela est nécessaire

    Enfin, l’exploitation de la solution est grandement facilitée comme nous allons le voir sur le slide suivant
  • La solution grace à son intégration forte avec OpenStack, permet d’amener à l’intérieur même de la console réseau, une visibilité sur les informations de virtualisation, comme les noms des instances, sur quel noeud de compute elles s’éxécutent, ainsi que toutes les informations réseaux associés
    Ces informations sont mises à jour en temps réel permettant d’avoir toujours une information à jour pour le troubleshooting
  • Enfin la mise en parallèle des objets OpenStack avec les objets ACI, permet d’amener une création automatique de ces derniers, à la demande lors de la création d’une ressource dans OpenStack, n’introduisant pas de délai entre la demande et le provisioning, permettant un usage au plus près du besoin client
  • En conclusion, ACI est une des solutions de Cisco pour simplifier la mise en place d’OpenStack dans les entreprises et pour permettre le rapprochement entre les équipes avec un vocabulaire commun et un objectif commun
    Je l’ai vu déployé avec succès chez plusieurs clients et en plus …
  • … les clients qui l’ont déployés ont comme prochains projets, d’étendre cette solution SDN, à d’autres environnements aussi bien sur le réseau existant, que sur les nouveaux types de réseaux comme ceux des conteneurs pour automatiser le réseau et simplifier son usage quelle que soit la technologie d’accès
  • Merci de m'avoir écouter, j'écoute maintenant vos questions
  • OpenStack Day France - Retour d'expérience sur le SDN avec OpenStack

    1. 1. Guillaume Morini @GuillaumeMorini Systems Engineer November 2016 Openstack Day France SDN dans OpenStack Retour d’expérience
    2. 2. Agenda • Cisco & OpenStack • Customers’ OpenStack projects • And the network part ? • Cisco SDN solutions for OpenStack • Customers’ use cases • Customers’ feedbacks
    3. 3. Cisco’s Commitment to OpenStack • Cisco Validated Designs for production deployments • Work closely and jointly with customers to design and build their OpenStack environment • OpenStack based Global Intercloud hosted across Cisco and partner data centers • Cisco Webex Service running on OpenStack • Automation (Puppet) and architectures (HA) for production deployment and operational support • Neutron/Nova Plug-ins for Cisco product lines – Nexus, CSR, ACI, UCS • Code contributions across several services – Network Compute, Dashboard, Storage • Foundation Board member • PTL Kolla and Major Architect Magnum Community Participation Engineering/ Automation Partners/ Customers Cloud Services
    4. 4. Fast Data Project – FD.io Open Source VPP – Vector Packet Processor VPP vs OVS performance https://fd.io/technology • VPP is a rapid packet processing development platform for highly performing network applications. • It runs on commodity CPUs and leverages DPDK • It creates a vector of packet indices and processes them using a directed graph of nodes – resulting in a highly performant solution. • Runs as a Linux user-space application • Ships as part of both embedded & server products, in volume • Active development since 2002 • Open Source since 2016 VPP technology in a nutshell
    5. 5. OpenStack & Cisco technologies Nexus switches & Application-Centric Infrastructure (ACI) MDS SAN switches ASR 1000 routers & CSR 1000V ASA/Firepower firewalls Software UCS servers https://developer.cisco.com/site/openstack/downloads/openstack-integration/
    6. 6. OpenStack projects Deployment Class 2X Prod Growth April 2016 Openstack User Survey
    7. 7. April 2016 Openstack User Survey “For Neutron, they wanted the networking service to be less complicated to use, with more substantial documentation and better integration with compute functions and PaaS layer integration.” And the network part ?
    8. 8. Is SDN the solution ?
    9. 9. Cisco SDN Solution for OpenStack
    10. 10. Broad and Deep Networking Capabilities OpenStack – SDN options Programmable SDN Model (Cisco APIC/ACI) Underlay/Overlay Integration application-centric policy model Ecosystem integration Targeted for Enterprise customers Programmable SDN Overlay Model (Cisco VTS) VTS Overlay provisioning and management based on VxLAN and BGP-EVPN Targeted for Service Providers No Network/SDN Controller (Basic Openstack/Neutron) Basic Networking (OVS, Linux Bridge) Focus of today presentation
    11. 11. Application-Centric Infrastructure Logical Network Provisioning of Stateless Hardware ACI Fabric Outside Web App DB QoS Filter QoS Service QoS Filter Scale-out penalty-free Overlay
    12. 12. Programmability & Open Ecosystem Framework Open Source Open Standards Published Data Model Open and Standard APIs
    13. 13. ACI + OpenStack – With OpFlex Support Full Policy Based Network Automation Extended to the Linux Hypervisor Group-based Policy • Open Source OpFlex agent extends ACI into Linux hypervisor • OpFlex Proxy exposes new open API in ACI fabric • Fully distributed Neutron network functions, including NAT • Integrated, centrally managed overlay and underlay fabric • Operational visibility integrating OpenStack, Linux, and APIC • Choice of virtual network (standard Neutron ML2) or Group-based Policy driven networkingHypervisor OVS OpFlex for OVS OpenStack Feature Highlights APIC Ml2 Driver Solutions with Major OpenStack DistributionsAvailable Now! OpFlex Agent OpFlex Proxy OpenStack Controller
    14. 14. Customers’ use cases
    15. 15. Deploy a fully software-defined Cloud solution, based on OpenStack. First step, IaaS platform Then, add services on top Example of a customer use case
    16. 16. Network requirements for this use case • Communication with existing network • Existing network tools • Service chaining for Firewall and Load Balancers • Capability to scale to 10 Gbit/s and more • Existing infrastructure do not support intensive I/O like Ceph storage Network integration Scalability
    17. 17. Spine3 Leaf3 Spine1 Spine2 Leaf2Leaf1 Typical architecture for this use case Control1 Apic1 Apic2 Apic3 OpenStack SDN environment Control2 Control3 Compute2 ComputeNCompute1 Existing network
    18. 18. APIC driver directly creates application network profiles OpenStack ACI Plugin - Details ACI fabric offers distributed L2, L3 (w/o L3 agent), and security policy. Tunneling applied at ToR. OPFLEX Host OVS OpFlex Agent Network A V(X)LAN 100 Host OVS OpFlex Agent Network A V(X)LAN 100 Host OVS OpFlex Agent Network B V(X)LAN 101 Host OVS OpFlex Agent Network B V(X)LAN 101 OVS enforces security policy, applies VLAN / VXLAN tag per network OpFlex agent receives policy from ACI fabric APIC ACI Plugin Neutron Networking Controller Node
    19. 19. Customers’ feedbacks
    20. 20. Customers’ benefits of OpenStack and ACI Distributed, Scalable Virtual Networking • Fully distributed L2, anycast gateway, DHCP, metadata • Distributed NAT / Floating IP • Choice of Group Policy or Neutron API • Fully managed underlay network through APIC controller • Ability to connect physical servers and multiple hypervisors to overlay networks Integrated Overlay and Underlay Hardware Performance • Automatic VXLAN tunnels at top- of-rack • No wasted CPU cycles for tunneling • Support for L3 or L2 service insertion and chaining • Device package ecosystem for 3rd party devices or Group-Based Policy service chaining Service Chaining Operations and Telemetry • Troubleshooting across physical and virtual environments • Health scores, atomic counters, capacity planning per tenant network • Virtual network isolation is maintained even when a hypervisor is compromised Secure Multi- tenancy
    21. 21. Full visibility of Openstack in the network console OpenStack VMM Domain KVM Hypervisor Operational Data Per Hypervisor / Per Group View Per EP stats, Health scores, faults
    22. 22. Automatic creation of ACI objects based on Openstack ones Neutron Object ACI (Neutron Instance) Tenant Project Application Network Profile Network EPG + BD Subnet Subnet Security Group + Rule N / A (Iptables rules maintained per host) Router Contract Network:external L3Out / Outside EPG
    23. 23. Conclusion
    24. 24. Next steps for customer Reuse/Extend SDN for other use cases ESX1 ESX2 ESX3HyperV BareMetal Docker Docker LxC KVMKVM RKT1 Hyper Convergence / Software Defined Storage

    ×