Open vSwitch, le commutateur virtuel bientôt sur votre serveur

Posté par  (site web personnel) . Modéré par Xavier Teyssier.
Étiquettes :
19
21
mai
2010
Internet
Le 17 mai, la version 1.0.0 d'Open vSwitch a été rendue publique. Comme son nom l'indique, ce logiciel permet de créer des commutateurs (switches) virtuels.

Avec les services qui se virtualisent de plus en plus, la gestion des interconnexions entre les machines virtuelles (et les machines réelles) nécessite une solution performante pour manipuler ce transit de paquet IP, d'où l'idée de faire des commutateurs virtuels. Actuellement, on utilise le plus souvent le mode pont (bridge) intégré dans Linux, via la commande brctl, ou le projet vde. Mais on en voit les limites lorsque l'architecture réseau devient complexe.

L'objectif d'Open vSwitch est d'obtenir un commutateur ayant les mêmes fonctionnalités qu'un vrai switch administrable (NetFlow, RSPAN, ERSPAN, interface en ligne de commande à la IOS, etc.) et pouvant s'étendre sur plusieurs serveurs physiques dans le cadre de la virtualisation ! C'est le pendant libre des produits comme le Distributed vSwitch de VMware ou le Nexus 1000V de Cisco.

Le code source d'Open vSwitch est distribué sous licence Apache 2, sauf la partie spécifique au noyau Linux qui est sous GPL. Il est écrit en langage C, avec le soucis d'être le plus indépendant possible de la plate-forme sous-jacente. Pour le moment, il supporte par défaut l'environnement de virtualisation Xen Cloud Platform, mais fonctionne aussi avec Xen, KVM, et VirtualBox. Cette version 1.0 apporte les fonctionnalités suivantes :
  • Pile 802.1Q (VLAN) avec le trunking ;
  • Règle de gestion par machine virtuelle ;
  • Possibilité de voir le trafic réseau entre machines virtuelles via NetFlow, sFlow(R), SPAN, et RSPAN ;
  • Agrégation de lien (bonding) avec équilibrage de charge basé sur l'adresse MAC source ;
  • Support pour OpenFlow ;
  • Ethernet au dessus de GRE ;
  • Couche de compatibilité avec le mode pont intégré au noyau Linux (brctl).
L'objectif à court terme est d'offrir aussi les fonctionnalités suivantes :
Enfin, à plus longue échéance, on pourrait avoir une interface administrable via SNMP, la gestion de l'authentification RADIUS (802.1x), la gestion du NAT, etc.

Aller plus loin

  • # juste pour info !

    Posté par  . Évalué à 4.

    Le Distributed vSwitch de VMware est justement basé sur le Nexus 1000V de Cisco !!

    my 2 cts.

    Nicolas

    • [^] # Re: juste pour info !

      Posté par  (site web personnel) . Évalué à 4.

      Très bien, je ne connais pas à vrai dire ces produits. Pour écrire la nouvelle, j'ai fait une petite recherche et j'étais tombé la dessus

      http://www.cisco.com/en/US/prod/collateral/switches/ps9441/p(...)

      Du coup, je me suis dis que c'était aussi intéressant de replacer Open vSwitch dans ce contexte de << bataille >> vmware / cisco.

    • [^] # Re: juste pour info !

      Posté par  . Évalué à 2.

      non, le cisco nexus 1000V s'appuie sur le distributed vswitch, nuance.
      En fait, c'est une initiative de VMWare pour permettre à des partenaires tiers de développer et d'intégrer leur propre switch dans un cluster ESX.
      OK, aujourd'hui, il n'y a que cisco qui propose ca. Mais dans le futur, j'espère que d'autres vont se lancer sur ce terrain, pourquoi pas openvswitch ??

      My 2 cents aussi ...

  • # switch virtuel

    Posté par  . Évalué à 0.

    encore un pas de plus vers le cloud.....

  • # Pour info aussi...

    Posté par  . Évalué à 2.

    Il existe aussi VDE (Virtual Distributed Ethernet): [http://wiki.virtualsquare.org/index.php/VDE]

    Mes 2 euro-cents.

  • # Lapin Compris

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    J'ai pas bien compris ce que c'est ni à quoi ça sert. Est-ce qu'il est possible d'avoir un tout petit exemple ?

    • [^] # Re: Lapin Compris

      Posté par  . Évalué à 8.

      M'enfin! C'est clair, et puis si tu as du mal, fais comme moi, fie-toi aux photos d'écran:

      http://openvswitch.org/wordpress/wp-content/uploads/2010/05/(...)

    • [^] # Re: Lapin Compris

      Posté par  . Évalué à -10.

      Si tu ne sais pas ce qu'est un switch, un hub, un RJ(45|11), un BNC, un RS232, etc. arrêtes l'informatique.

      • [^] # Re: Lapin Compris

        Posté par  . Évalué à 9.

        Tu es au courant que dans les utilisateurs et amateurs de Linux, il n'y a pas que des informaticiens de métier ?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Lapin Compris

          Posté par  . Évalué à -8.

          Linux c'est un noyau. Quel utilisateur lambda d'un système d'exploitation connaît le nom de son noyau ?
          Et s'il s'agit d'amateur il ne s'agit pas "d'informaticien de métier", qui est un pléonasme d'après Wikipédia, seule source d'information reconnue avec man.
          Ton propos est donc contrairement au mien un troll du dredi, CQFD.

      • [^] # Re: Lapin Compris

        Posté par  (site web personnel) . Évalué à 8.

        Et puis je pense que l'on peut connaitre swtich, hub, et tout le reste et ne pas avoir saisi toute la portée de ce projet.

        Ça a l'air sympa cela dit comme projet. Des exemples concrets d'utilisations/d'utilisateurs ?

    • [^] # Re: Lapin Compris

      Posté par  . Évalué à 10.

      Salut,

      Ben quand on a des machines et qu'on veut les connecter en réseau, en général on passe par un switch ethernet. Ce switch peut être tout simple (c'est ce que l'on trouve an général chez les particuliers pour pouvoir connecter quelques machines à un modem ADSL), mais peut aussi avec des possibilités de paramétrage que tu ne soupçonnes même pas : c(est le type de matériel que l'on trouve en entreprise et qui permet de faire pleins de choses : paramétrage particulier sur chacun des ports, QOS, gestion de plusieurs réseaux (VLAN), ... et tout ça est administrable à distance (soit en SNMP soit avec des outils dédiés).

      Dans un cas classique (machines physiques) ces switchs sont des boitiers rackables avec pleins de câbles ethernet les reliant aux différentes machines ou à d'autres switchs

      De plus en plus, on utilise des serveurs virtuels,mais la problématique est la même : ces serveurs doivent être reliés au réseau et pour cela on utilise des switchs... virtuels. Jusqu'à présent, les switchs virtuels Open Source étaient plutôt limités en terme de fonctionnalités et/ou compliqués à configurer, surtout comparé aux solutions proposés par des entreprises comme Cisco ou VMWare. Open vSwitch vise à combler ce manque.

      C'est plus clair comme ça ?

      A+
      JJD

      • [^] # Re: Lapin Compris

        Posté par  . Évalué à 2.

        Je peux comprendre que l'on veuille virtualiser le réseau pour connecter des serveurs virtuels sans sortir de la machine. Je vois l'intérêt d'établir une connectivité entre ces serveurs.

        J'ai plus de mal à comprendre ce qu'apporte la gestion des VLAN, de la QoS et du port security par Open vSwitch vu que cela est déjà proposé par le noyau. Mais bon, passons ...

        Là où par contre je ne vois pas du tout l'intérêt, c'est le support du (R)STP et de l'agrégation de liens. Vouloir redonder et faire de la répartition de charges pour des liens virtuels d'équipements virtuels ... tout ça sur une même machine physique. A part pour faire de la simulation réseau, je ne vois pas à quoi ça peut servir. L'agrégation de liens, c'est pour avoir plus de bande-passante que ne peut fournir 1 seul lien physique. Le bus de la carte mère du PC lui ne va pas se multiplier quel que soit le nombre de liens redondés que l'on pourrait configurer. A part la beauté du geste de faire un switch virtuel qui a toutes les fonctionnalités d'un switch réel, je ne vois pas l'intérêt.

        La commutation étant de plus gérée par des composants dédiés sur les switchs réels, je ne suis pas sûr que l'on ait des performances supérieures à faire tout en soft (et sur la même machine où tournent les serveurs) que de faire transiter le trafic sur un switch externe.

        • [^] # Re: Lapin Compris

          Posté par  . Évalué à 1.

          C'est quoi que tu ne comprends pas dans "mêmes fonctionnalités qu'un vrai switch administrable [...] et pouvant s'étendre sur plusieurs serveurs physiques"?

          • [^] # Re: Lapin Compris

            Posté par  . Évalué à 3.

            Il ne suffit pas de dire que ça existe pour que cela devienne la solution du siècle. Ce que je ne comprends pas, c'est en quoi l'agrégation de lien et le STP apporte plus de fiabilité dans ce type d'architecture virtualisée.

            VLAN, QoS, monitoring ... OK.

            Agrégation de lien : c'est du point à point donc ca ne s'étend pas sur plusieurs serveurs physiques et virtuels. Si c'est pour augmenter la BP, cf mon précédent post.

            STP :
            - Au sein d'une archi virtuelle, si c'est pour de la redondance d'équipement, voir mon précédent post. Si c'est pour parer les boucles réseaux (virtuelles), c'est que l'on a merdé dans son archi. Le pb est donc en amont.
            - Entre des serveurs physiques : Quel est l'intérêt de propager l'arborescence STP jusqu'aux sein des serveurs virtuels ? En archi réseau, on ne met du STP qu'entre les équipements où cela peut être utile, pas partout. Si on fait une archi pourrie où l'on ne maîtrise plus rien jusqu'à finalement ne plus savoir si en rajoutant un switch (virtuel) on ne risque pas de tout planter, c'est que l'on devrait peut-être commencer à reprendre en main son réseau.

            Bref, j'ai creusé un peu avant de revenir ici et ma position a un peu évolué. Ce que j'en déduis, c'est que la QoS, les VLAN et tout ce qui est monitoring peuvent effectivement être utiles. L'intérêt de Open vSwitch est d'apporter une interface commune à différentes fonctionnalités existantes par ailleurs mais se configurant avec des outils différents. En revanche, l'agrégation de lien et le STP dans des réseaux virtuels maîtrisés, mis à part les cas dont je parlais dans mon précédent post, j'attends toujours de voir l'intérêt.

            • [^] # Re: Lapin Compris

              Posté par  . Évalué à 2.

              Je vais peut-être dire une connerie car je n'ai pas l'occasion de tester ce genre d'outils et j'ignore si c'est un des objectifs de ce projet. Mais est-il possible que ce projet puisse également avoir une vocation pédagogique ? Dans ce cas ça expliquerait pourquoi certaines fonctions sont disponibles même si elles ne sont pas utiles a priori. On peut ainsi se faire la main sur un commutateur virtuel avant de passer à la pratique sur un commutateur physique.

              • [^] # Re: Lapin Compris

                Posté par  (site web personnel) . Évalué à 3.

                Comme tout projet, celui-ci peut être utilisé à d'autres fin que celui pour lequel il a été conçu initialement. Je ne pense pas qu'il y ai le moindre soucis pédagogique dans ce projet. Celui-ci est fortement lié par les nécessités de la virtualisation sur les grosses fermes de serveurs.

                Mais tout ce qui touche à la virtualisation est un formidable laboratoire pédagogique. Tant mieux !

        • [^] # Re: Lapin Compris

          Posté par  (site web personnel) . Évalué à 6.

          Pour l'agrégation de lien, je ne sais pas trop... Pour le spanning tree, cela permet d'éviter des erreurs si tu a par exemple 50 machines virtuelles !

          Sinon, ce genre de switch virtuel est censé pouvoir se positionner au dessus d'une ferme d'hyperviseur Xen par exemple. La gestion des VLAN est donc importante car les domU sont connectés sur ce switch virtuel, dans le bon VLAN et la migration de cette machine d'un dom0 vers un autre est complètement transparente.

          Donc, je ne pense pas que l'idée est d'éliminer le noyau mais d'avoir une couche au dessus permettant plus de souplesse.

          Par exemple, pouvoir mettre une sonde NetFlow et ré-utiliser tous les outils que l'on a déjà pour analyser les flux, c'est bien. Le but est aussi un peu là, connecter les machines virtuels sur ce genre de switch comme si tout cela était vrai afin de ré-utiliser au maximum tous les outils existant.

          J'ai un outil maison qui me dis sur quel switch est branché une machine. Je récupère tout cela par SNMP. Je ne sais pas faire cela avec les bridge linux alors que j'ai bon espoir que cela marche à terme que ce genre de switch.

          Pour les fermes de calcul, plutôt que de charger des batch via un outil de type qsub (sge, pbs...), tu pourras (projet XCP si j'ai compris) charger ta machine virtuelle sur le cluster et ton calcul se fera dedans sur ton environnement ! Avec des fermes à 20000 coeurs, si tu n'as pas un outil pour gérer les connexions des machines virtuelles sur les différents noeuds, je pense que c'est vite l'enfer.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.