Le cloud computing pĂ©nĂštre de plus en plus profondĂ©ment dans nos vies et il n'y a probablement pas une seule personne qui n'ait utilisĂ© aucun service cloud au moins une fois. Cependant, ce qu'est un cloud et comment il fonctionne pour la plupart, peu de gens le savent mĂȘme au niveau d'une idĂ©e. La 5G est dĂ©jĂ en train de devenir une rĂ©alitĂ© et l'infrastructure des tĂ©lĂ©communications commence Ă passer des solutions piliers aux solutions cloud, comme lorsqu'elle passait de solutions entiĂšrement ferreuses Ă des «piliers» virtualisĂ©s.
Aujourd'hui, nous allons parler du monde intérieur de l'infrastructure cloud, en particulier, nous analyserons les bases de la partie réseau.
Qu'est-ce qu'un cloud? La mĂȘme virtualisation - vue de profil?
Plus qu'une question logique. Non - ce n'est pas de la virtualisation, mĂȘme si ce n'Ă©tait pas sans elle. ConsidĂ©rez deux dĂ©finitions: le
cloud computing (ci-aprĂšs dĂ©nommĂ© le Cloud) est un modĂšle permettant de fournir un accĂšs convivial aux ressources informatiques distribuĂ©es qui doivent ĂȘtre dĂ©ployĂ©es et lancĂ©es Ă la demande avec la latence la plus faible possible et un coĂ»t minimal de la part du fournisseur de services (traduction de la dĂ©finition du NIST).
Virtualisation- il s'agit de la possibilité de diviser une entité physique (par exemple, un serveur) en plusieurs entités virtuelles, augmentant ainsi l'utilisation des ressources (par exemple, vous aviez 3 serveurs chargés de 25 à 30%, aprÚs la virtualisation, 1 serveur était chargé de 80 à 90%). Naturellement, la virtualisation consomme une partie des ressources - vous devez alimenter l'hyperviseur, cependant, comme la pratique l'a montré, le jeu en vaut la chandelle. Un exemple idéal de virtualisation est VMWare, qui prépare parfaitement les machines virtuelles, ou par exemple KVM, que je préfÚre, mais c'est déjà une question de goût.
Nous utilisons nous-mĂȘmes la virtualisation sans nous en rendre compte, et mĂȘme les routeurs de fer utilisent dĂ©jĂ la virtualisation - par exemple, dans les derniĂšres versions de JunOS, le systĂšme d'exploitation est installĂ© en tant que machine virtuelle en plus du kit de distribution Linux en temps rĂ©el (Wind River 9). Mais la virtualisation n'est pas le cloud, mais le cloud ne peut exister sans virtualisation.
La virtualisation est l'un des éléments de base sur lesquels le cloud est construit.
Cela ne fonctionnera pas pour crĂ©er un cloud en rassemblant simplement plusieurs hyperviseurs dans un domaine L2, en ajoutant quelques playbooks yaml pour enregistrer automatiquement des vlans via certains ansible et en le remplissant de quelque chose comme un systĂšme d'orchestration pour crĂ©er automatiquement des machines virtuelles. Plus prĂ©cisĂ©ment, cela se rĂ©vĂ©lera, mais le Frankenstein qui en rĂ©sulte n'est pas le nuage dont nous avons besoin, bien qu'en tant que quelqu'un d'autre, peut-ĂȘtre pour quelqu'un, c'est le rĂȘve ultime. De plus, si vous prenez le mĂȘme Openstack - en fait, c'est toujours Frankenstein, mais bon, n'en parlons pas encore.
Mais je comprends que d'aprÚs la définition ci-dessus, ce que l'on peut appeler un cloud n'est pas tout à fait clair.
Par conséquent, le document du NIST (National Institute of Standards and Technology) énumÚre 5 caractéristiques principales qu'une infrastructure cloud devrait avoir:
Prestation de service sur demande. L'utilisateur doit avoir libre accĂšs aux ressources informatiques qui lui sont allouĂ©es (telles que les rĂ©seaux, les disques virtuels, la mĂ©moire, les cĆurs de processeur, etc.), et ces ressources doivent ĂȘtre fournies automatiquement - c'est-Ă -dire sans intervention du fournisseur de services.
Large disponibilitĂ© de service. L'accĂšs aux ressources doit ĂȘtre assurĂ© par des mĂ©canismes standard pour pouvoir utiliser Ă la fois des PC standard, des clients lĂ©gers et des appareils mobiles.
Mise en commun des ressources.Les pools de ressources doivent ĂȘtre en mesure de fournir des ressources Ă plusieurs clients en mĂȘme temps, en garantissant l'isolement des clients et l'absence d'influence mutuelle et de conflits pour les ressources. Les rĂ©seaux sont Ă©galement inclus dans les pools, ce qui indique la possibilitĂ© d'utiliser l'adressage se chevauchant. Les piscines doivent Ă©voluer Ă la demande. L'utilisation de pools vous permet de fournir le niveau nĂ©cessaire de rĂ©silience des ressources et d'abstraction des ressources physiques et virtuelles - le destinataire du service est simplement fourni avec l'ensemble des ressources demandĂ©es par lui (oĂč ces ressources sont physiquement situĂ©es, sur combien de serveurs et de commutateurs - le client s'en fiche). Cependant, il faut tenir compte du fait que le fournisseur doit assurer une rĂ©servation transparente de ces ressources.
Adaptation rapide Ă diverses conditions.Les services doivent ĂȘtre flexibles - fourniture rapide des ressources, leur rĂ©allocation, ajout ou rĂ©duction de ressources Ă la demande du client, et le client doit sentir que les ressources du cloud sont infinies. Pour faciliter la comprĂ©hension, par exemple, vous ne voyez pas d'avertissement indiquant que vous avez perdu une partie de l'espace disque dans Apple iCloud en raison du fait que le disque dur du serveur est cassĂ© et que les disques se cassent. De plus, de votre cĂŽtĂ©, les possibilitĂ©s de ce service sont presque infinies - il vous faut 2 To - pas de problĂšme, vous avez payĂ© et reçu. De mĂȘme, vous pouvez donner un exemple avec Google.Drive ou Yandex.Disk.
La capacitĂ© de mesurer le service fourni.Les systĂšmes cloud devraient automatiquement contrĂŽler et optimiser les ressources consommĂ©es, tandis que ces mĂ©canismes devraient ĂȘtre transparents Ă la fois pour l'utilisateur et le fournisseur de services. Autrement dit, vous pouvez toujours vĂ©rifier la quantitĂ© de ressources que vous et vos clients consommez.
Il convient de considĂ©rer le fait que ces exigences sont principalement des exigences pour un cloud public.Par consĂ©quent, pour un cloud privĂ© (c'est-Ă -dire un cloud lancĂ© pour les besoins internes d'une entreprise), ces exigences peuvent ĂȘtre lĂ©gĂšrement ajustĂ©es. Cependant, ils doivent encore ĂȘtre exĂ©cutĂ©s, sinon nous n'obtiendrons pas tous les avantages du cloud computing.
Pourquoi avons-nous besoin d'un cloud?
Cependant, toute technologie nouvelle ou existante, tout nouveau protocole est créé pour quelque chose (enfin, sauf pour RIP-ng, bien sûr). Protocole pour des raisons de protocole - personne n'en a besoin (enfin, sauf pour RIP-ng, bien sûr). Il est logique que le Cloud soit créé pour fournir une sorte de service à l'utilisateur / client. Nous connaissons tous au moins quelques services cloud, tels que Dropbox ou Google.Docs, et je pense que la plupart d'entre eux les utilisent avec succÚs - par exemple, cet article a été rédigé à l'aide du service cloud Google.Docs. Mais les services cloud que nous connaissons ne sont qu'une partie des capacités du cloud - plus précisément, il ne s'agit que d'un service de type SaaS. Nous pouvons fournir un service cloud de trois maniÚres: sous forme de SaaS, PaaS ou IaaS. Le service dont vous avez besoin dépend de vos désirs et de vos capacités.
Considérons chacun dans l'ordre:
Le logiciel en tant que service (SaaS) est un modÚle pour fournir un service complet à un client, par exemple, un service de messagerie comme Yandex.Mail ou Gmail. Dans un tel modÚle de prestation de services, vous, en tant que client, ne faites en fait rien d'autre que d'utiliser les services - c'est-à -dire que vous n'avez pas besoin de penser à la mise en place d'un service, à sa tolérance aux pannes ou à sa réservation. L'essentiel est de ne pas compromettre votre mot de passe, le fournisseur de ce service fera le reste à votre place. Du point de vue du fournisseur de services, il est entiÚrement responsable de l'ensemble du service - du matériel du serveur et des systÚmes d'exploitation hÎtes aux paramÚtres de base de données et de logiciel.
Plateforme en tant que service (PaaS)- lors de l'utilisation de ce modĂšle, le fournisseur de services fournit au client un modĂšle pour le service, par exemple, prenons un serveur Web. Le fournisseur de services a fourni au client un serveur virtuel (en fait, un ensemble de ressources, telles que RAM / CPU / Stockage / Nets, etc.), et a mĂȘme installĂ© le systĂšme d'exploitation et les logiciels nĂ©cessaires sur ce serveur, mais le client configure lui-mĂȘme tout cela et pour les performances du service dĂ©jĂ le client rĂ©pond. Le fournisseur de services, comme dans le cas prĂ©cĂ©dent, est responsable de l'opĂ©rabilitĂ© des Ă©quipements physiques, des hyperviseurs, de la machine virtuelle elle-mĂȘme, de sa disponibilitĂ© rĂ©seau, etc., mais le service lui-mĂȘme est dĂ©jĂ en dehors de sa zone de responsabilitĂ©.
Infrastructure en tant que service (IaaS)- cette approche est dĂ©jĂ plus intĂ©ressante, en fait, le fournisseur de services fournit au client une infrastructure virtualisĂ©e complĂšte - c'est-Ă -dire une sorte d'ensemble (pool) de ressources, telles que les cĆurs de processeur, la RAM, les rĂ©seaux, etc. Tout le reste appartient au client - ce que le client veut en faire ressources dans le pool allouĂ© (quota) - le fournisseur n'est pas particuliĂšrement important. Le client souhaite crĂ©er son propre vEPC ou mĂȘme faire un mini opĂ©rateur et fournir des services de communication - pas de doute - faites-le. Dans un tel scĂ©nario, le fournisseur de services est responsable de la fourniture des ressources, de leur tolĂ©rance aux pannes et de leur disponibilitĂ©, ainsi que du systĂšme d'exploitation qui vous permet de combiner ces ressources dans des pools et de les fournir au client avec la possibilitĂ© d'augmenter ou de rĂ©duire les ressources Ă tout moment Ă la demande du client. Le client configure lui-mĂȘme toutes les machines virtuelles et autres tinsel via le portail en libre-service et les consoles,y compris l'enregistrement des rĂ©seaux (Ă l'exception des rĂ©seaux externes).
Qu'est-ce qu'OpenStack?
Dans les trois options, le fournisseur de services a besoin d'un systÚme d'exploitation qui activera l'infrastructure cloud. En fait, en SaaS, aucun département n'est responsable de l'ensemble de la pile de cette pile technologique - il y a un département qui est responsable de l'infrastructure - c'est-à -dire qu'il fournit l'IaaS à un autre département, ce département fournit le client SaaS. OpenStack est l'un des systÚmes d'exploitation cloud qui vous permet de rassembler un ensemble de commutateurs, de serveurs et de systÚmes de stockage en un seul pool de ressources, de diviser ce pool commun en sous-pools (locataires) et de fournir ces ressources aux clients sur le réseau.
Pile ouverteEst un systÚme d'exploitation cloud qui vous permet de contrÎler de grands pools de ressources informatiques, de stockage de données et de ressources réseau, dont le provisionnement et la gestion sont effectués via une API utilisant des mécanismes d'authentification standard.
En d'autres termes, il s'agit d'un ensemble de projets de logiciels libres conçus pour créer des services cloud (publics et privés) - c'est-à -dire un ensemble d'outils qui vous permettent de combiner le serveur et l'équipement de commutation en un seul pool de ressources, de gérer ces ressources, en fournissant le niveau de tolérance aux pannes nécessaire. ...
Au moment d'Ă©crire ces lignes, la structure d'OpenStack ressemble Ă ceci:
Photo prise depuis openstack.org
Chacun des composants qui composent OpenStack remplit une fonction spécifique. Cette architecture distribuée vous permet d'inclure dans la solution l'ensemble des composants fonctionnels dont vous avez besoin. Cependant, certains des composants sont des composants racines et leur suppression entraßnera une inopérabilité totale ou partielle de la solution dans son ensemble. Il est d'usage de se référer à de tels composants:
- Tableau de bord - interface graphique Web pour la gestion des services OpenStack
- Keystone est un service d'identité centralisé qui fournit des fonctionnalités d'authentification et d'autorisation pour d'autres services, ainsi que de gérer les informations d'identification et les rÎles des utilisateurs.
- Neutron â , OpenStack ( VM )
- Cinder â
- Nova â
- Glance â
- Swift â
- Ceilometer â ,
- Heat â
Une liste complĂšte de tous les projets et de leur objectif est disponible ici .
Chacun des composants OpenStack est un service qui est responsable d'une fonction spécifique et fournit une API pour gérer cette fonction et pour communiquer ce service avec d'autres services du systÚme d'exploitation cloud afin de créer une infrastructure unifiée. Par exemple, Nova fournit une gestion des ressources de calcul et des API pour accéder à la configuration de ces ressources, Glance fournit une gestion des images et des API pour les gérer, Cinder fournit un stockage en bloc et des API pour les gérer, etc. Toutes les fonctions sont interconnectées de maniÚre trÚs étroite.
Cependant, si vous jugez, tous les services exécutés dans OpenStack sont finalement une sorte de machine virtuelle (ou de conteneur) connectée au réseau. La question se pose: pourquoi avons-nous besoin de tant d'éléments?
Passons en revue l'algorithme pour créer une machine virtuelle et la connecter au réseau et au stockage persistant dans Openstack.
- Lorsque vous créez une demande pour créer une machine, que ce soit une demande via Horizon (Dashboard) ou une demande via l'interface de ligne de commande, la premiÚre chose qui se produit est votre demande d'autorisation pour Keystone - pouvez-vous créer une machine, posséder ou avoir le droit d'utiliser ce réseau, en avez-vous assez? projet de quotas, etc.
- Keystone authentifie votre demande et gĂ©nĂšre un jeton d'authentification dans le message de rĂ©ponse, qui sera utilisĂ© ultĂ©rieurement. AprĂšs avoir reçu une rĂ©ponse de Keystone, la requĂȘte est envoyĂ©e vers Nova (nova api).
- Nova-api , Keystone, auth-
- Keystone auth- .
- Nova-api nova-database VM nova-scheduler.
- Nova-scheduler ( ), VM , . VM nova-database.
- nova-scheduler nova-compute . Nova-compute nova-conductor (nova-conductor nova, nova-database nova-compute, nova-database ).
- Nova-conductor nova-database nova-compute.
- nova-compute glance ID . Glace Keystone .
- Nova-compute neutron . glance, neutron Keystone, database ( ), nova-compute.
- Nova-compute cinder volume. glance, cider Keystone, volume .
- Nova-compute libvirt .
En fait, une opĂ©ration apparemment simple pour crĂ©er une machine virtuelle simple se transforme en un tel tourbillon d'appels API entre les Ă©lĂ©ments de la plate-forme cloud. De plus, comme vous pouvez le voir, mĂȘme les services prĂ©cĂ©demment dĂ©signĂ©s se composent Ă©galement de composants plus petits, entre lesquels une interaction a lieu. La crĂ©ation d'une machine n'est qu'une petite partie de ce que la plate-forme cloud vous offre - il existe un service responsable de l'Ă©quilibrage du trafic, un service responsable du stockage en bloc, un service responsable du DNS, un service chargĂ© de l'approvisionnement des serveurs bare metal, etc. vous traitez vos machines virtuelles comme un troupeau de moutons (par opposition Ă la virtualisation). Si quelque chose arrive Ă votre machine dans un environnement virtuel - vous le restaurez Ă partir de sauvegardes, etc., les applications cloud sont construites de cette maniĂšre,pour que la machine virtuelle ne joue pas un rĂŽle aussi important - la machine virtuelle "est morte" - peu importe - une nouvelle machine est simplement crĂ©Ă©e sur la base du modĂšle et, comme on dit, l'escouade n'a pas remarquĂ© la perte d'un soldat. Naturellement, cela permet la prĂ©sence de mĂ©canismes d'orchestration - en utilisant les modĂšles Heat, vous pouvez facilement dĂ©ployer une fonction complexe composĂ©e de dizaines de rĂ©seaux et de machines virtuelles sans aucun problĂšme.
Il convient toujours de garder Ă l'esprit qu'il n'y a pas d'infrastructure cloud sans rĂ©seau - chaque Ă©lĂ©ment interagit d'une maniĂšre ou d'une autre avec d'autres Ă©lĂ©ments via le rĂ©seau. De plus, le cloud dispose d'un rĂ©seau totalement non statique. Naturellement, le rĂ©seau sous-jacent est encore plus ou moins statique - de nouveaux nĆuds et commutateurs ne sont pas ajoutĂ©s tous les jours, cependant, le composant de superposition peut et sera inĂ©vitablement changer constamment - de nouveaux rĂ©seaux seront ajoutĂ©s ou supprimĂ©s, de nouvelles machines virtuelles apparaissent et les anciennes meurent. Et comme vous vous en souvenez d'aprĂšs la dĂ©finition du cloud, donnĂ©e au tout dĂ©but de l'article, les ressources doivent ĂȘtre allouĂ©es Ă l'utilisateur automatiquement et avec le moins (ou mieux sans) intervention du fournisseur de services. Autrement dit, le type de fourniture de ressources rĂ©seau,qui se prĂ©sente dĂ©sormais sous la forme d'un frontend sous la forme de votre compte personnel accessible via http / https et de l'ingĂ©nieur rĂ©seau de service Vasily en tant que backend - ce n'est pas un cloud, mĂȘme si Vasily a huit mains.
Neutron, en tant que service rĂ©seau, fournit une API pour gĂ©rer la partie rĂ©seau de l'infrastructure cloud. Le service assure l'intĂ©gritĂ© et la gestion de la partie rĂ©seau Openstack en fournissant une couche d'abstraction appelĂ©e Network-as-a-Service (NaaS). Autrement dit, le rĂ©seau est la mĂȘme unitĂ© virtuelle mesurable que, par exemple, les cĆurs virtuels de CPU ou la RAM.
Mais avant de passer à l'architecture réseau OpenStack, examinons le fonctionnement du réseau OpenStack et pourquoi le réseau est une partie importante et intégrale du cloud.
Nous avons donc deux machines virtuelles clientes RED et deux machines virtuelles clientes VERTES. Supposons que ces machines soient situées sur deux hyperviseurs comme celui-ci:
Pour le moment, il ne s'agit que de virtualisation de 4 serveurs et rien de plus, puisque jusqu'Ă prĂ©sent, tout ce que nous avons fait est de virtualiser 4 serveurs, en les plaçant sur deux serveurs physiques. Et jusqu'Ă prĂ©sent, ils ne sont mĂȘme pas connectĂ©s au rĂ©seau.
Pour obtenir un cloud, nous devons ajouter plusieurs composants. Tout d'abord, nous virtualisons la partie rĂ©seau - nous devons connecter ces 4 machines par paires, et les clients veulent exactement la connexion L2. Vous pouvez utiliser le commutateur et configurer une jonction dans sa direction et tout gĂ©rer en utilisant le pont Linux, ou pour les utilisateurs d'openvswitch plus avancĂ©s (nous y reviendrons). Mais il peut y avoir beaucoup de rĂ©seaux, et pousser constamment L2 Ă travers un commutateur n'est pas la meilleure idĂ©e - donc diffĂ©rentes divisions, service desk, des mois d'attente pour l'exĂ©cution d'une application, des semaines de dĂ©pannage - cette approche ne fonctionne plus dans le monde moderne. Et plus vite l'entreprise s'en rend compte, plus il est facile d'avancer. Par consĂ©quent, entre les hyperviseurs, nous sĂ©lectionnerons un rĂ©seau L3 Ă travers lequel nos machines virtuelles communiqueront, et dĂ©jĂ au-dessus de ce rĂ©seau L3, nous construirons des rĂ©seaux L2 virtuels superposĂ©s (overlay),oĂč le trafic de nos machines virtuelles s'exĂ©cutera. GRE, Geneve ou VxLAN peuvent ĂȘtre utilisĂ©s comme encapsulation. Attardons-nous sur ce dernier pour l'instant, mĂȘme si ce n'est pas particuliĂšrement important.
Nous devons localiser VTEP quelque part (j'espĂšre que tout le monde connaĂźt la terminologie VxLAN). Puisque le rĂ©seau L3 quitte immĂ©diatement les serveurs, rien ne nous empĂȘche de placer VTEP sur les serveurs eux-mĂȘmes, et OVS (OpenvSwitch) peut le faire parfaitement. En consĂ©quence, nous avons obtenu la construction suivante: Ă©tant
donnĂ© que le trafic entre les VM doit ĂȘtre divisĂ©, les ports vers les machines virtuelles auront des numĂ©ros de vlan diffĂ©rents. Le numĂ©ro de balise ne joue un rĂŽle qu'au sein d'un seul commutateur virtuel, car lors de l'encapsulation dans VxLAN, nous pouvons le supprimer sans aucun problĂšme, car nous aurons un VNI.
Désormais, nous pouvons créer sans problÚme nos machines et nos réseaux virtuels.
Cependant, que se passe-t-il si le client possĂšde une autre machine, mais se trouve sur un rĂ©seau diffĂ©rent? Nous avons besoin d'un enracinement entre les rĂ©seaux. Nous analyserons une option simple lorsque l'enracinement centralisĂ© est utilisĂ© - c'est-Ă -dire que le trafic est acheminĂ© via des nĆuds de rĂ©seau dĂ©diĂ©s spĂ©ciaux (enfin, en rĂšgle gĂ©nĂ©rale, ils sont combinĂ©s avec des nĆuds de contrĂŽle, nous aurons donc la mĂȘme chose).
Cela ne semble rien de compliquĂ© - nous crĂ©ons une interface de pont sur le nĆud de contrĂŽle, y dirigons le trafic et de lĂ , nous l'acheminons lĂ oĂč nous en avons besoin. Mais le problĂšme est que le client RED veut utiliser le rĂ©seau 10.0.0.0/24 et le client GREEN veut utiliser le rĂ©seau 10.0.0.0/24. Autrement dit, l'intersection des espaces d'adressage commence. De plus, les clients ne souhaitent pas que d'autres clients soient acheminĂ©s vers leurs rĂ©seaux internes, ce qui est logique. Pour sĂ©parer les rĂ©seaux et le trafic des donnĂ©es clients, nous allouerons un espace de noms distinct pour chacun d'entre eux. L'espace de noms est, en fait, une copie de la pile rĂ©seau Linux, c'est-Ă -dire que les clients dans l'espace de noms RED sont complĂštement isolĂ©s des clients de l'espace de noms VERT (enfin, le routage entre ces rĂ©seaux clients est autorisĂ© via l'espace de noms par dĂ©faut ou dĂ©jĂ sur l'Ă©quipement de transport en amont).
Autrement dit, nous obtenons le schéma suivant:
Les tunnels L2 convergent de tous les nĆuds de calcul vers celui de contrĂŽle. le nĆud oĂč se trouve l'interface L3 de ces rĂ©seaux, chacun dans un espace de noms dĂ©diĂ© pour l'isolation.
Cependant, nous avons oubliĂ© la chose la plus importante. La machine virtuelle doit fournir un service au client, c'est-Ă -dire qu'elle doit avoir au moins une interface externe Ă travers laquelle elle peut ĂȘtre atteinte. Autrement dit, nous devons aller dans le monde extĂ©rieur. Il existe diffĂ©rentes options ici. Faisons l'option la plus simple. Ajoutons des clients sur un rĂ©seau, qui seront valides dans le rĂ©seau du fournisseur et ne chevaucheront pas d'autres rĂ©seaux. Les rĂ©seaux peuvent Ă©galement se croiser et examiner diffĂ©rents VRF du cĂŽtĂ© du rĂ©seau du fournisseur. Ces rĂ©seaux vivront Ă©galement dans l'espace de noms de chaque client. Cependant, ils iront toujours dans le monde extĂ©rieur via une interface physique (ou lien, ce qui est plus logique). Pour sĂ©parer le trafic client, le trafic sortant sera Ă©tiquetĂ© avec une balise VLAN attribuĂ©e au client.
En conséquence, nous avons obtenu le schéma suivant:
Une question raisonnable - pourquoi ne pas crĂ©er des passerelles sur les nĆuds de calcul eux-mĂȘmes? Ce n'est pas un gros problĂšme, de plus, lorsque vous allumez le routeur distribuĂ© (DVR), cela fonctionnera comme ça. Dans ce scĂ©nario, nous considĂ©rons l'option la plus simple avec une passerelle centralisĂ©e, qui est la valeur par dĂ©faut dans Openstack. Pour les fonctions Ă forte charge, ils utiliseront Ă la fois un routeur distribuĂ© et des technologies d'accĂ©lĂ©ration telles que SR-IOV et Passthrough, mais comme on dit, c'est une histoire complĂštement diffĂ©rente. Commençons par la partie de base, puis entrons dans les dĂ©tails.
En fait, notre systÚme est déjà opérationnel, mais il y a quelques nuances:
- Nous devons d'une maniÚre ou d'une autre protéger nos machines, c'est-à -dire accrocher un filtre sur l'interface du commutateur vers le client.
- Permettez Ă une machine virtuelle d'obtenir automatiquement une adresse IP afin que vous n'ayez pas Ă la saisir Ă chaque fois via la console et Ă enregistrer l'adresse.
Commençons par protéger les machines. Pour cela, vous pouvez utiliser des iptables banals, pourquoi pas.
Autrement dit, maintenant notre topologie est devenue un peu plus compliquée:
allons plus loin. Nous devons ajouter un serveur DHCP. L'endroit le plus idĂ©al pour l'emplacement des serveurs DHCP pour chacun des clients sera le nĆud de contrĂŽle dĂ©jĂ mentionnĂ© ci-dessus, oĂč se trouvent les espaces de noms:
Cependant, il y a un petit problĂšme. Que faire si tout redĂ©marre et que toutes les informations de bail d'adresse DHCP disparaissent. Il est logique que de nouvelles adresses soient fournies aux machines, ce qui n'est pas trĂšs pratique. Il y a deux façons de sortir ici - soit utiliser des noms de domaine et ajouter un serveur DNS pour chaque client, puis l'adresse ne sera pas trĂšs importante pour nous (par analogie avec la partie rĂ©seau dans k8s) - mais il y a un problĂšme avec les rĂ©seaux externes, car des adresses peuvent Ă©galement y ĂȘtre Ă©mises via DHCP - vous devez vous synchroniser avec les serveurs DNS de la plate-forme cloud et un serveur DNS externe, ce qui, Ă mon avis, n'est pas trĂšs flexible, mais tout Ă fait possible. Ou la deuxiĂšme option consiste Ă utiliser des mĂ©tadonnĂ©es, c'est-Ă -dire Ă enregistrer des informations sur l'adresse Ă©mise sur la machine afin que le serveur DHCP sache quelle adresse envoyer Ă la machine si la machine a dĂ©jĂ reçu une adresse. La deuxiĂšme option est plus simple et plus flexible, car elle vous permet d'enregistrer des informations supplĂ©mentaires sur la voiture.Ajoutez maintenant les mĂ©tadonnĂ©es de l'agent au schĂ©ma:
Un autre problĂšme qui devrait Ă©galement ĂȘtre sanctifiĂ© est la possibilitĂ© d'utiliser un rĂ©seau externe pour tous les clients, car les rĂ©seaux externes, s'ils doivent ĂȘtre valides dans tout le rĂ©seau, il y aura de la complexitĂ© - vous devez constamment allouer et contrĂŽler l'allocation de ces rĂ©seaux. La possibilitĂ© d'utiliser un seul rĂ©seau externe prĂ©configurĂ© pour tous les clients sera trĂšs utile lors de la crĂ©ation d'un cloud public. Cela facilitera le dĂ©ploiement des machines, car nous n'avons pas Ă vĂ©rifier la base de donnĂ©es d'adresses et Ă choisir un espace d'adressage unique pour le rĂ©seau externe de chaque client. De plus, nous pouvons enregistrer un rĂ©seau externe Ă l'avance et au moment du dĂ©ploiement, nous n'aurons qu'Ă associer des adresses externes aux machines clientes.
Et ici, NAT vient Ă la rescousse - nous permettons simplement aux clients d'accĂ©der au monde extĂ©rieur via l'espace de noms par dĂ©faut en utilisant la traduction NAT. Eh bien, voici un petit problĂšme. Il est bon que le serveur client agisse en tant que client et non en tant que serveur, c'est-Ă -dire qu'il initie plutĂŽt qu'accepte les connexions. Mais avec nous, ce sera l'inverse. Dans ce cas, nous devons faire un NAT de destination afin que lors de la rĂ©ception du trafic, le nĆud de contrĂŽle comprenne que ce trafic est destinĂ© Ă la machine virtuelle A du client A, ce qui signifie que nous devons effectuer une traduction NAT d'une adresse externe, par exemple 100.1.1.1 vers une adresse interne 10.0.0.1. Dans ce cas, bien que tous les clients utilisent le mĂȘme rĂ©seau, l'isolation interne est complĂštement prĂ©servĂ©e. Autrement dit, nous devons crĂ©er dNAT et sNAT sur le nĆud de contrĂŽle.Utilisez un seul rĂ©seau avec l'attribution d'adresses flottantes ou de rĂ©seaux externes, ou les deux Ă la fois, car vous souhaitez vous glisser dans le cloud. Nous n'ajouterons pas d'adresses flottantes au diagramme, mais nous laisserons les rĂ©seaux externes dĂ©jĂ ajoutĂ©s prĂ©cĂ©demment - chaque client a son propre rĂ©seau externe (dans le diagramme, ils sont dĂ©signĂ©s comme vlan 100 et 200 sur l'interface externe).
En consĂ©quence, nous avons obtenu une solution intĂ©ressante et en mĂȘme temps bien pensĂ©e qui a une certaine flexibilitĂ©, mais pour l'instant ne dispose pas de mĂ©canismes de tolĂ©rance aux pannes.
PremiĂšrement, nous n'avons qu'un seul nĆud de contrĂŽle - sa dĂ©faillance entraĂźnera l'effondrement de tous les systĂšmes. Pour rĂ©soudre ce problĂšme, vous devez crĂ©er au moins un quorum de 3 nĆuds. Ajoutons ceci au diagramme:
Naturellement, tous les nĆuds sont synchronisĂ©s et lorsque le nĆud actif se termine, un autre nĆud prendra ses responsabilitĂ©s.
Le problĂšme suivant concerne les disques de machine virtuelle. Pour le moment, ils sont stockĂ©s sur les hyperviseurs eux-mĂȘmes, et en cas de problĂšmes avec l'hyperviseur, nous perdons toutes les donnĂ©es - et la prĂ©sence d'un raid n'aidera en rien si nous perdons non pas le disque, mais le serveur entier. Pour ce faire, nous devons crĂ©er un service qui servira d'interface pour un certain stockage. Le type de stockage qu'il s'agira n'est pas particuliĂšrement important pour nous, mais il devrait protĂ©ger nos donnĂ©es contre les pannes du disque et du nĆud, et Ă©ventuellement de toute l'armoire. Il y a plusieurs options ici - bien sĂ»r, il y a des rĂ©seaux SAN avec Fibre Channel, mais soyons honnĂȘtes - FC est dĂ©jĂ une relique du passĂ© - un analogue de E1 dans les transports - oui, je suis d'accord, il est toujours utilisĂ©, mais seulement lĂ oĂč c'est absolument impossible sans lui. Par consĂ©quent, je ne dĂ©ploierais pas volontairement le rĂ©seau FC en 2020, sachant qu'il existe d'autres alternatives plus intĂ©ressantes.Bien que chacun sienne et peut-ĂȘtre qu'il y aura ceux qui croient que FC avec toutes ses limitations est tout ce dont nous avons besoin - je ne discuterai pas, chacun a sa propre opinion. Cependant, la solution la plus intĂ©ressante Ă mon avis est l'utilisation du SDS, par exemple Ceph.
Ceph vous permet de construire une solution de stockage de vyskodostupnoe avec un tas d'options pour la redondance, puisque la parité de code (raid analogique 5 ou 6) se terminant par une réplication complÚte des données sur plusieurs disques à base de serveurs d'emplacement de disque et les serveurs dans les armoires et ainsi de suite.
Pour L'assemblage Ceph a besoin de 3 nĆuds supplĂ©mentaires. L'interaction avec le stockage se fera Ă©galement via le rĂ©seau en utilisant les services de stockage de blocs, d'objets et de fichiers. Ajoutez du stockage au schĂ©ma:
: compute â â storage+compute â ceph storage. â SDS . â â storage ( ) â CPU SDS ( , , ). compute storage.Tout cela doit ĂȘtre gĂ©rĂ© d'une maniĂšre ou d'une autre - nous avons besoin de quelque chose par lequel nous pouvons crĂ©er une machine, un rĂ©seau, un routeur virtuel, etc. Pour ce faire, ajoutez un service au nĆud de contrĂŽle qui fera office de tableau de bord - le client pourra se connecter Ă ce portail via http / https et faites tout ce dont vous avez besoin (enfin, presque).
En consĂ©quence, nous avons maintenant un systĂšme tolĂ©rant aux pannes. Tous les Ă©lĂ©ments de cette infrastructure doivent ĂȘtre gĂ©rĂ©s d'une maniĂšre ou d'une autre. Il a Ă©tĂ© prĂ©cĂ©demment dĂ©crit qu'Openstack est un ensemble de projets, dont chacun fournit une fonction spĂ©cifique. Comme nous pouvons le voir, il y a plus qu'assez d'Ă©lĂ©ments qui doivent ĂȘtre configurĂ©s et contrĂŽlĂ©s. Aujourd'hui, nous allons parler de la partie mise en rĂ©seau.
Architecture neutronique
Dans OpenStack, c'est Neutron qui est responsable de la connexion des ports des machines virtuelles à un réseau L2 commun, assurant le routage du trafic entre les VM situées dans différents réseaux L2, ainsi que le routage vers l'extérieur, fournissant des services tels que NAT, Floating IP, DHCP, etc. Le fonctionnement de
haut niveau du service rĂ©seau ( partie de base) peut ĂȘtre dĂ©crite comme suit.
Lors du démarrage de la VM, le service réseau:
- Crée un port pour cette VM (ou ces ports) et en informe le service DHCP;
- Un nouveau périphérique réseau virtuel est créé (via libvirt);
- La VM se connecte au port (ports) créé à l'étape 1;
Curieusement, mais au cĆur du travail de Neutron se trouvent des mĂ©canismes standards familiers Ă tous ceux qui ont dĂ©jĂ plongĂ© dans Linux - espaces de noms, iptables, ponts Linux, openvswitch, conntrack, etc.
Il convient de préciser immédiatement que Neutron n'est pas un contrÎleur SDN.
Neutron se compose de plusieurs composants interconnectés:
Openstack-neutron-server est un dĂ©mon qui fonctionne avec les demandes des utilisateurs via une API. Ce dĂ©mon ne prescrit aucune connectivitĂ© rĂ©seau, mais donne les informations nĂ©cessaires pour cela Ă ses plugins, qui configurent ensuite l'Ă©lĂ©ment rĂ©seau requis. Les agents Neutron sur les nĆuds OpenStack s'enregistrent auprĂšs du serveur Neutron.
Neutron-server est en fait une application écrite en python, composée de deux parties:
- Service REST
- Plugin Neutron (noyau / service)
Un service REST est conçu pour recevoir des appels d'API d'autres composants (par exemple, une demande de fourniture d'informations, etc.) Les
plugins sont des composants / modules logiciels de plug-in qui sont appelés à la suite de demandes d'API - c'est-à -dire qu'un service est attribué via eux. Les plugins sont divisés en deux types - service et racine. En rÚgle générale, le plug-in horse est principalement responsable de la gestion de l'espace d'adressage et des connexions L2 entre les machines virtuelles, et les plug-ins de service fournissent déjà des fonctionnalités supplémentaires, telles que VPN ou FW.
La liste des plugins disponibles pour aujourd'hui peut ĂȘtre consultĂ©e par exemple ici. Il
peut y avoir plusieurs plugins de service, mais il ne peut y avoir qu'un seul plugin horse.
Openstack-neutron-ml2Est le plugin racine standard d'Openstack. Ce plug-in a une architecture modulaire (contrairement Ă son prĂ©dĂ©cesseur) et configure le service rĂ©seau via les drivers qui lui sont connectĂ©s. Nous examinerons le plugin lui-mĂȘme un peu plus tard, car il donne en fait la flexibilitĂ© qu'OpenStack a dans la partie rĂ©seau. Le plugin racine peut ĂȘtre remplacĂ© (par exemple, Contrail Networking effectue un tel remplacement).
Service RPC (rabbitmq-server) - Un service qui fournit la gestion des files d'attente et la communication avec d'autres services OpenStack, ainsi que la communication entre les agents de service réseau.
Agents de rĂ©seau - agents situĂ©s dans chaque nĆud via lequel les services rĂ©seau sont configurĂ©s.
Les agents sont de plusieurs types.
L'agent principal estAgent L2 . Ces agents s'exĂ©cutent sur chacun des hyperviseurs, y compris les nĆuds de contrĂŽle (plus prĂ©cisĂ©ment, sur tous les nĆuds qui fournissent un service aux locataires) et leur fonction principale est de connecter des machines virtuelles Ă un rĂ©seau L2 commun, ainsi que de gĂ©nĂ©rer des alertes lorsque des Ă©vĂ©nements se produisent (par exemple dĂ©sactiver / activer le port).
L'agent suivant, non moins important, est l' agent L3... Par dĂ©faut, cet agent s'exĂ©cute exclusivement sur le nĆud de rĂ©seau (souvent un nĆud de rĂ©seau est combinĂ© avec un nĆud de contrĂŽle) et assure le routage entre les rĂ©seaux de locataires (Ă la fois entre ses rĂ©seaux et les rĂ©seaux d'autres locataires, et est disponible pour le monde extĂ©rieur, fournissant des services NAT et DHCP). Cependant, lors de l'utilisation d'un DVR (routeur distribuĂ©), le besoin d'un plugin L3 apparaĂźt Ă©galement sur les nĆuds de calcul.
L'agent L3 utilise des espaces de noms Linux pour fournir à chaque client un ensemble de ses propres réseaux isolés et les fonctionnalités de routeurs virtuels qui acheminent le trafic et fournissent des services de passerelle pour les réseaux de couche 2.
Base de données - une base de données d'identificateurs de réseaux, de sous-réseaux, de ports, de pools, etc.
En fait, Neutron accepte les requĂȘtes API dĂšs la crĂ©ation de toute entitĂ© rĂ©seau, authentifie la requĂȘte, et via RPC (s'il s'adresse Ă un plugin ou agent) ou l'API REST (s'il communique en SDN) envoie aux agents (via des plugins) les instructions nĂ©cessaires pour organiser le service demandĂ© ...
Passons maintenant Ă l'installation de test (comment elle est dĂ©ployĂ©e et ce qu'elle contient plus loin dans la partie pratique) et voyons oĂč se trouve quel composant:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
En fait, c'est toute la structure de Neutron. Maintenant, cela vaut la peine de prendre un peu de temps pour le plugin ML2.
Couche modulaire 2
Comme indiqué ci-dessus, le plugin est un plugin racine OpenStack standard et a une architecture modulaire.
Le prĂ©dĂ©cesseur du plug-in ML2 avait une structure monolithique qui ne permettait pas, par exemple, d'utiliser un mĂ©lange de plusieurs technologies dans une seule installation. Par exemple, vous ne pouvez pas utiliser Ă la fois openvswitch et linuxbridge en mĂȘme temps - que ce soit le premier ou le second. Pour cette raison, le plugin ML2 avec son architecture a Ă©tĂ© crĂ©Ă©.
ML2 a deux composants - deux types de pilotes: les pilotes de type et les pilotes de mécanisme.
Les pilotes de type définissent les technologies qui seront utilisées pour organiser la connectivité réseau, par exemple VxLAN, VLAN, GRE. Dans ce cas, le pilote vous permet d'utiliser différentes technologies. La technologie standard est l'encapsulation VxLAN pour les réseaux de superposition et les réseaux externes vlan.
Les pilotes de type incluent les types de réseaux suivants:
Plat - un réseau sans balisage
VLAN - un réseau balisé
Local - un type spécial de réseau pour les installations tout-en-un (de telles installations sont nécessaires soit pour les développeurs soit pour la formation)
GRE - réseau de superposition utilisant des tunnels GRE
VxLAN - réseau de superposition utilisant des tunnels VxLAN
Les pilotes de mécanisme définissent les moyens qui assurent l'organisation des technologies spécifiées dans le pilote de type - par exemple, openvswitch, sr-iov, opendaylight, OVN, etc.
En fonction de l'implémentation de ce pilote, soit des agents contrÎlés par Neutron seront utilisés, soit des connexions avec un contrÎleur SDN externe seront utilisées, qui prend en charge toutes les questions d'organisation des réseaux L2, de routage, etc.
Exemple Si nous utilisons ML2 avec OVS, alors sur chaque nĆud de calcul est configurĂ© avec un agent L2 qui contrĂŽle OVS. Cependant, si nous utilisons, par exemple, OVN ou OpenDayLight, alors le contrĂŽle OVS relĂšve de leur juridiction - Neutron donne des commandes au contrĂŽleur via le plugin racine, et il fait dĂ©jĂ ce qu'on lui a dit.
Rafraßchissons notre mémoire Open vSwitch
Pour le moment, l'un des composants clés d'OpenStack est Open vSwitch.
Lors de l'installation d'OpenStack sans aucun SDN de fournisseur supplĂ©mentaire tel que Juniper Contrail ou Nokia Nuage, OVS est le principal composant rĂ©seau du rĂ©seau cloud et, avec iptables, conntrack, les espaces de noms, vous permet d'organiser un rĂ©seau de superposition Ă part entiĂšre avec la multi-location. Naturellement, ce composant peut ĂȘtre remplacĂ©, par exemple, lors de l'utilisation de solutions SDN propriĂ©taires tierces (fournisseur).
OVS est un commutateur logiciel open source conçu pour ĂȘtre utilisĂ© dans des environnements virtualisĂ©s en tant que transitaire de trafic virtuel.
Pour le moment, OVS a des fonctionnalités trÚs décentes, qui incluent des technologies telles que QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etc.
Remarque: Ă l'origine, OVS n'a pas Ă©tĂ© conçu comme un commutateur logiciel pour les fonctions de tĂ©lĂ©communications Ă forte charge et a plutĂŽt Ă©tĂ© conçu pour des fonctions informatiques moins gourmandes en bande passante telles qu'un serveur WEB ou un serveur de messagerie. Cependant, OVS est en cours de finalisation et les implĂ©mentations actuelles d'OVS ont considĂ©rablement amĂ©liorĂ© ses performances et ses capacitĂ©s, ce qui lui permet d'ĂȘtre utilisĂ© par les opĂ©rateurs de tĂ©lĂ©communications avec des fonctions trĂšs chargĂ©es, par exemple, il existe une implĂ©mentation OVS avec prise en charge de l'accĂ©lĂ©ration DPDK.
Il y a trois composants OVS importants Ă connaĂźtre:
- Module noyau - un composant situé dans l'espace noyau qui traite le trafic en fonction des rÚgles reçues du contrÎle;
- vSwitch daemon (ovs-vswitchd) â , user space, kernel â
- Database server â , , OVS, . OVSDB SDN .
Tout cela est également accompagné d'un ensemble d'utilitaires de diagnostic et de gestion, tels que ovs-vsctl, ovs-appctl, ovs-ofctl, etc.
Actuellement, Openstack est largement utilisĂ© par les opĂ©rateurs de tĂ©lĂ©communications pour y migrer des fonctions rĂ©seau, telles que EPC, SBC, HLR et ainsi de suite. Certaines fonctions peuvent vivre sans problĂšme avec OVS sous la forme dans laquelle il se trouve, mais par exemple, EPC traite le trafic des abonnĂ©s - c'est-Ă -dire qu'il fait passer une Ă©norme quantitĂ© de trafic Ă travers lui-mĂȘme (maintenant les volumes de trafic atteignent plusieurs centaines de gigabits par seconde). Naturellement, conduire un tel trafic Ă travers l'espace du noyau (puisque le transitaire y est localisĂ© par dĂ©faut) n'est pas une bonne idĂ©e. Par consĂ©quent, OVS est souvent dĂ©ployĂ© entiĂšrement dans l'espace utilisateur Ă l'aide de la technologie d'accĂ©lĂ©ration DPDK pour transfĂ©rer le trafic de la carte rĂ©seau vers l'espace utilisateur en contournant le noyau.
Remarque: pour un cloud dĂ©ployĂ© pour les fonctions tĂ©lĂ©coms, il est possible de sortir le trafic du nĆud de calcul en contournant OVS directement vers l'Ă©quipement de commutation. Les mĂ©canismes SR-IOV et Passthrough sont utilisĂ©s Ă cet effet.
Comment ça marche sur une vraie mise en page?
Eh bien, passons maintenant Ă la partie pratique et voyons comment tout cela fonctionne dans la pratique.
Commençons par déployer une installation Openstack simple. Comme je n'ai pas un ensemble de serveurs sous la main pour des expériences, nous assemblerons la mise en page sur un serveur physique à partir de machines virtuelles. Oui, bien sûr, une telle solution ne convient pas à des fins commerciales, mais pour regarder un exemple du fonctionnement du réseau dans Openstack, une telle installation suffira aux yeux. De plus, une telle installation à des fins de formation est encore plus intéressante - car vous pouvez attraper du trafic, etc.
Comme nous n'avons besoin de voir que la partie de base, nous ne pouvons pas utiliser plusieurs réseaux, mais tout lever en utilisant seulement deux réseaux, et le deuxiÚme réseau de cette disposition sera utilisé exclusivement pour accéder au serveur undercloud et dns. Nous n'allons pas aborder les réseaux externes pour le moment - c'est un sujet pour un grand article séparé.
Alors commençons dans l'ordre. Tout d'abord, une petite thĂ©orie. Nous installerons Openstack en utilisant TripleO (Openstack sur Openstack). L'essence de TripleO est que nous installons un tout-en-un Openstack (c'est-Ă -dire sur un nĆud), appelĂ© undercloud, puis utilisons les capacitĂ©s de l'Openstack dĂ©ployĂ© pour installer un Openstack destinĂ© Ă l'exploitation, appelĂ© overcloud. Undercloud utilisera la capacitĂ© inhĂ©rente Ă gĂ©rer des serveurs physiques (bare metal) - le projet Ironic - pour provisionner des hyperviseurs qui serviront de nĆuds de calcul, de contrĂŽle et de stockage. Autrement dit, nous n'utilisons aucun outil tiers pour dĂ©ployer Openstack - nous dĂ©ployons Openstack avec Openstack. Plus loin dans l'installation, cela deviendra beaucoup plus clair, nous ne nous arrĂȘterons donc pas lĂ et continuerons.
: Openstack, . â , , . . ceph ( ) (Storage management Storage) , , QoS , . .
Remarque: puisque nous allons exécuter des machines virtuelles dans un environnement virtuel basé sur des machines virtuelles, nous devons d'abord activer la virtualisation imbriquée.
Vous pouvez vérifier si la virtualisation imbriquée est activée ou non comme ceci:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#
Si vous voyez la lettre N, nous activons la prise en charge de la virtualisation imbriquée en fonction de n'importe quel guide que vous trouvez sur le réseau, par exemple celui-ci .
Nous devons assembler le schéma suivant à partir de machines virtuelles:
Dans mon cas, pour la connectivité des machines virtuelles qui font partie de la future installation (et j'en ai 7, mais vous pouvez vous en tirer avec 4 si vous n'avez pas beaucoup de ressources), j'ai utilisé OpenvSwitch. J'ai créé un pont ovs et y ai connecté des machines virtuelles via des groupes de ports. Pour ce faire, j'ai créé un fichier xml de la forme suivante:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>
Trois ports du groupe sont déclarés ici - deux accÚs et un trunk (ce dernier était nécessaire pour un serveur DNS, mais vous pouvez vous en passer, ou le monter sur la machine hÎte - c'est ce qui vous convient le mieux). Ensuite, en utilisant ce modÚle, nous déclarons notre est via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1
Modifions maintenant la configuration des ports de l'hyperviseur:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]#
Remarque: dans ce scénario, l'adresse sur le port ovs-br1 ne sera pas disponible, car elle ne possÚde pas de balise vlan. Pour résoudre ce problÚme, exécutez la commande sudo ovs-vsctl set port ovs-br1 tag = 100. Cependant, aprÚs un redémarrage, cette balise disparaßtra (si quelqu'un sait comment la faire rester en place, je vous en serai trÚs reconnaissant). Mais ce n'est pas si important, car nous n'aurons besoin de cette adresse que pour le moment de l'installation et ne seront pas nécessaires lorsque Openstack sera entiÚrement déployé.Ensuite, nous créons une voiture sous le nuage:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0
Lors de l'installation, vous dĂ©finissez tous les paramĂštres nĂ©cessaires, tels que le nom de la machine, les mots de passe, les utilisateurs, les serveurs ntp, etc., vous pouvez immĂ©diatement configurer les ports, mais aprĂšs l'installation, il m'est plus facile d'entrer dans la machine via la console et de corriger les fichiers nĂ©cessaires. Si vous avez dĂ©jĂ une image prĂȘte Ă l'emploi, vous pouvez l'utiliser ou faire comme moi - tĂ©lĂ©charger l'image minimale de Centos 7 et l'utiliser pour installer la VM.
AprÚs une installation réussie, vous devriez avoir une machine virtuelle sur laquelle vous pouvez installer undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud running
Tout d'abord, nous installons les outils nécessaires lors du processus d'installation:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installation d'Undercloud
Créez un utilisateur de pile, définissez un mot de passe, ajoutez-le à sudoer et donnez-lui la possibilité d'exécuter des commandes root via sudo sans avoir à entrer de mot de passe:
useradd stack
passwd stack
echo âstack ALL=(root) NOPASSWD:ALLâ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack
Maintenant, nous spécifions le nom complet undercloud dans le fichier hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Ensuite, ajoutez les référentiels et installez les logiciels dont nous avons besoin:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible
Remarque: si vous ne prévoyez pas d'installer ceph, vous n'avez pas besoin d'entrer les commandes liées à ceph. J'ai utilisé la version Queens, mais vous pouvez utiliser ce que vous voulez.Ensuite, copiez le fichier de configuration undercloud dans le répertoire de base de la pile de l'utilisateur:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
Nous devons maintenant corriger ce fichier en l'ajustant Ă notre installation.
Au début du fichier, ajoutez ces lignes:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10
Alors, passez par les paramĂštres:
undercloud_hostname - le nom complet du serveur
undercloud doit correspondre à l'entrée du serveur DNS local_ip - l'adresse locale undercloud vers le réseau de
provizhening network_gateway - la mĂȘme adresse locale, qui servira de passerelle pour l'accĂšs au monde extĂ©rieur lors de l'installation overcloud node, correspond Ă©galement Ă l' adresse IP locale
undercloud_public_host - adresse d'API externe, affectée de toute adresse gratuite du réseau d'approvisionnement
sous l'adresse API interne de undercloud_admin_host, affectée de n'importe quelle adresse libre du réseau d'approvisionnement
undercloud_nameservers - serveur DNS
generate_service_certificate- cette ligne est trÚs importante dans l'exemple actuel, car si elle n'est pas définie sur false vous recevrez une erreur lors de l'installation, le problÚme est décrit sur l' interface
local_interface du traqueur de bogues Red Hat dans le provisionnement du réseau. Cette interface sera reconfigurée lors du déploiement de undercloud, vous devez donc avoir deux interfaces sur undercloud - une pour y accéder, la seconde pour provisionner
local_mtu - MTU. Puisque nous avons un laboratoire de test et MTU j'ai 1500 ports OVS Svicha, il faut mettre en valeur en 1450, qui auraient été encapsulés dans des packages
VxLAN network_cidr - provisioning network
masquerade - l'utilisation du NAT pour accéder au réseau externe
masquerade_network - un réseau qui va NAT -sya
dhcp_start - l'adresse de dĂ©part du pool d'adresses Ă partir de laquelle les adresses seront attribuĂ©es aux nĆuds lors du dĂ©ploiement overcloud
dhcp_end - l'adresse finale du pool d'adresses Ă partir de laquelle les adresses seront attribuĂ©es aux nĆuds lors du dĂ©ploiement overcloud
inspection_iprange - le pool d'adresses requises pour l'introspection (ne doit pas croiser le pool mentionné ci-dessus )
scheduler_max_attempts - le nombre maximum de tentatives d'installation d'overcloud (doit ĂȘtre supĂ©rieur ou Ă©gal au nombre de nĆuds) Une
fois le fichier décrit, vous pouvez donner la commande pour déployer undercloud:
openstack undercloud install
La procédure prend 10 à 30 minutes, selon votre fer. En fin de compte, vous devriez voir une sortie comme celle-ci:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################
Cette sortie indique que vous avez installé avec succÚs undercloud et que vous pouvez maintenant vérifier l'état de undercloud et procéder à l'installation d'overcloud.
Si vous regardez la sortie d'ifconfig, vous verrez qu'une nouvelle interface de pont est apparue
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Le déploiement d'Overcloud sera désormais effectué via cette interface.
Ă partir de la sortie ci-dessous, on peut voir que nous avons tous les services sur un nĆud:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+
Voici la configuration de la partie réseau undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$
Installation Overcloud
Pour le moment, nous n'avons que undercloud, et nous n'avons pas assez de nĆuds Ă partir desquels l'overcloud sera construit. Par consĂ©quent, tout d'abord, nous dĂ©ploierons les machines virtuelles dont nous avons besoin. Pendant le dĂ©ploiement, undercloud lui-mĂȘme installera le systĂšme d'exploitation et les logiciels nĂ©cessaires sur la machine overcloud - c'est-Ă -dire que nous n'avons pas besoin de dĂ©ployer complĂštement la machine, mais seulement de crĂ©er un disque (ou des disques) pour elle et de dĂ©terminer ses paramĂštres - c'est-Ă -dire que nous obtenons un serveur nu sans systĂšme d'exploitation installĂ© dessus ...
Accédez au dossier contenant les disques de nos machines virtuelles et créez des disques de la taille requise:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G
Puisque nous agissons à partir de la racine, nous devons changer le propriétaire de ces disques afin de ne pas avoir de problÚme avec les droits:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]#
Remarque: si vous prĂ©voyez d'installer ceph pour l'Ă©tudier, crĂ©ez au moins 3 nĆuds avec au moins deux disques, et dans le modĂšle indiquez que les disques virtuels vda, vdb, etc. seront utilisĂ©s.GĂ©nial, maintenant nous devons dĂ©finir toutes ces machines:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml
à la fin, il y a les commandes --print-xml> /tmp/storage-1.xml, qui crée un fichier xml avec une description de chaque machine dans le dossier / tmp /, si vous ne l'ajoutez pas, vous ne pourrez pas définir de machines virtuelles.
Nous devons maintenant définir toutes ces machines dans virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#
Maintenant une petite nuance - tripleO utilise IPMI afin de gérer les serveurs pendant l'installation et l'introspection.
L'introspection est le processus d'inspection du matĂ©riel afin d'obtenir ses paramĂštres nĂ©cessaires Ă l'approvisionnement ultĂ©rieur des nĆuds. L'introspection est effectuĂ©e en utilisant ironic - un service conçu pour fonctionner avec des serveurs bare metal.
Mais voici le problĂšme - si les serveurs de fer IPMI ont un port sĂ©parĂ© (ou un port partagĂ©, mais ce n'est pas important), alors les machines virtuelles n'ont pas de tels ports. Ici, une bĂ©quille appelĂ©e vbmc vient Ă notre secours - un utilitaire qui vous permet d'Ă©muler un port IPMI. Cette nuance mĂ©rite une attention particuliĂšre, en particulier pour ceux qui veulent soulever un tel laboratoire sur un hyperviseur ESXI - si, bien sĂ»r, je ne sais pas s'il a un analogue de vbmc, vous devriez donc ĂȘtre intriguĂ© par cette question avant de tout dĂ©ployer.
Installez vbmc:
yum install yum install python2-virtualbmc
Si votre systÚme d'exploitation ne trouve pas le package, ajoutez le référentiel:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
Maintenant, nous configurons l'utilitaire. Tout est banal de disgrĂące ici. Maintenant, il est logique qu'il n'y ait pas de serveurs dans la liste vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]#
Pour qu'ils apparaissent, ils doivent ĂȘtre dĂ©clarĂ©s manuellement de cette maniĂšre:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#
Je pense que la syntaxe de la commande est claire et sans explication. Cependant, pour l'instant, toutes nos sessions sont Ă l'Ă©tat DOWN. Pour qu'ils passent Ă l'Ă©tat UP, vous devez les activer:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#
Et la touche finale - vous devez corriger les rÚgles du pare-feu (enfin, ou le désactiver complÚtement):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Passons maintenant à undercloud et vérifions que tout fonctionne. L'adresse de la machine hÎte est 192.168.255.200, nous avons ajouté le package ipmitool nécessaire à undercloud lors de la préparation du déploiement:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 running
Comme vous pouvez le voir, nous avons lancĂ© avec succĂšs le nĆud de contrĂŽle via vbmc. Maintenant, dĂ©sactivez-le et continuez:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#
L'Ă©tape suivante est l'introspection des nĆuds sur lesquels l'overcloud sera installĂ©. Pour ce faire, nous devons prĂ©parer un fichier json avec une description de nos nĆuds. Veuillez noter que, contrairement Ă l'installation sur des serveurs nus, le fichier spĂ©cifie le port sur lequel vbmc s'exĂ©cute pour chacune des machines.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27
Remarque: il y a deux interfaces sur le nĆud de contrĂŽle, mais dans ce cas, cela n'a pas d'importance, dans cette installation, une nous suffira.Nous prĂ©parons maintenant un fichier json. Nous devons spĂ©cifier l'adresse poppy du port via lequel l'approvisionnement sera effectuĂ©, les paramĂštres du nĆud, leur donner des noms et indiquer comment accĂ©der Ă ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}
Maintenant, nous devons préparer des images pour ironique. Pour ce faire, téléchargez-les via wget et installez:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
Téléchargement d'images vers undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$
Vérifiez que toutes les images sont chargées
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$
Encore une touche - vous devez ajouter un serveur DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$
Nous pouvons maintenant Ă©mettre la commande pour l'introspection:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$
Comme vous pouvez le voir sur la sortie, tout s'est terminĂ© sans erreur. VĂ©rifions que tous les nĆuds sont disponibles:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$
Si les nĆuds sont dans un Ă©tat diffĂ©rent, gĂ©nĂ©ralement gĂ©rable, alors quelque chose s'est mal passĂ© et vous devez consulter le journal pour comprendre pourquoi cela s'est produit. Gardez Ă l'esprit que dans ce scĂ©nario, nous utilisons la virtualisation et qu'il peut y avoir des bogues associĂ©s Ă l'utilisation de machines virtuelles ou de vbmc.
Ensuite, nous devons spĂ©cifier quel nĆud exĂ©cutera quelle fonction, c'est-Ă -dire indiquer le profil avec lequel le nĆud se dĂ©ploiera:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$
Nous indiquons le profil de chaque nĆud:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167
Nous vérifions que nous avons tout fait correctement:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$
Si tout est correct, nous donnons la commande de déployer overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemu
Dans une vraie installation, des modĂšles personnalisĂ©s seront naturellement utilisĂ©s, dans notre cas cela compliquera grandement le processus, puisqu'il sera nĂ©cessaire d'expliquer chaque modification dans le modĂšle. Comme il a Ă©tĂ© Ă©crit plus tĂŽt, mĂȘme une simple installation nous suffira pour voir comment cela fonctionne.
Remarque: la variable --libvirt-type qemu est requise dans ce cas, car nous utiliserons la virtualisation imbriquée. Sinon, vous n'aurez pas de machines virtuelles en cours d'exécution.
Vous avez maintenant environ une heure, ou peut-ĂȘtre plus (selon les capacitĂ©s du matĂ©riel) et vous ne pouvez qu'espĂ©rer qu'aprĂšs ce dĂ©lai, vous verrez l'inscription suivante:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$
Vous avez maintenant une version presque complÚte de l'openstack, sur laquelle vous pouvez étudier, faire des expériences, etc.
VĂ©rifions que tout fonctionne bien. Dans la pile du rĂ©pertoire personnel de l'utilisateur, il y a deux fichiers - un stackrc (pour gĂ©rer undercloud) et l'autre overcloudrc (pour gĂ©rer overcloud). Ces fichiers doivent ĂȘtre spĂ©cifiĂ©s comme source, car ils contiennent les informations requises pour l'authentification.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Dans mon installation, une petite touche supplémentaire est nécessaire - pour ajouter une route sur le contrÎleur, car la machine avec laquelle je travaille est sur un réseau différent. Pour ce faire, allez dans control-1 sous le compte heat-admin et écrivez l'itinéraire
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254
Eh bien, maintenant vous pouvez aller à l'horizon. Toutes les informations - adresses, nom d'utilisateur et mot de passe - se trouvent dans le fichier / home / stack / overcloudrc. Le schéma final ressemble à ceci:
Au fait, dans notre installation, les adresses des machines ont Ă©tĂ© Ă©mises via DHCP et, comme vous pouvez le voir, elles sont Ă©mises «au hasard». Vous pouvez coder en dur dans le modĂšle quelle adresse doit ĂȘtre associĂ©e Ă quelle machine pendant le dĂ©ploiement, si vous en avez besoin.
Comment le trafic circule-t-il entre les machines virtuelles?
Dans cet article, nous examinerons trois options pour faire passer le trafic
- Deux machines sur un hyperviseur dans un réseau L2
- Deux machines sur diffĂ©rents hyperviseurs dans un mĂȘme rĂ©seau L2
- Deux machines sur des réseaux différents (enracinement entre réseaux)
Les cas d'accÚs au monde extérieur via un réseau externe, utilisant des adresses flottantes, ainsi que le routage distribué, seront examinés la prochaine fois, pour l'instant nous nous concentrerons sur le trafic interne.
Pour tester, mettons ensemble le schéma suivant:
Nous avons créé 4 machines virtuelles - 3 dans un réseau L2 - net-1, et une autre dans le réseau net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$
Voyons sur quels hyperviseurs se trouvent les machines créées:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |
(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |
(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |
(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack @ undercloud ~] $ Les
machines vm-1 et vm-3 sont situĂ©es sur compute-0, les machines vm-2 et vm-4 sont situĂ©es sur le nĆud compute-1.
De plus, un routeur virtuel a été créé pour permettre le routage entre les réseaux spécifiés:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$
Le routeur dispose de deux ports virtuels qui agissent comme des passerelles pour les réseaux:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$
Mais avant de regarder comment se passe le trafic, regardons ce que nous avons pour le moment sur le nĆud de contrĂŽle (qui est Ă©galement un nĆud de rĂ©seau) et sur le nĆud de calcul. Commençons par un nĆud de calcul.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$
Pour le moment, le nĆud a trois ponts ovs - br-int, br-tun, br-ex. Entre eux, comme on peut le voir, il y a un ensemble d'interfaces. Pour faciliter la perception, nous allons mettre toutes ces interfaces sur le diagramme et voir ce qui se passe.
à partir des adresses auxquelles les tunnels VxLAN sont soulevés, vous pouvez voir qu'un tunnel est soulevé sur compute-1 (192.168.255.26), le deuxiÚme tunnel regarde control-1 (192.168.255.15). Mais le plus intéressant est que br-ex n'a pas d'interfaces physiques, et si vous regardez quels flux sont configurés, vous pouvez voir que ce pont ne peut abandonner que du trafic pour le moment.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$
Comme vous pouvez le voir sur la sortie, l'adresse est vissée directement sur le port physique, et non sur l'interface du pont virtuel.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Selon la premiĂšre rĂšgle, tout ce qui provient du port phy-br-ex doit ĂȘtre jetĂ©.
En fait, il n'y a nulle part d'autre pour que le trafic se rende à ce pont, sauf depuis cette interface (jonction avec br-int), et à en juger par les gouttes, le trafic BUM est déjà arrivé sur le pont.
Autrement dit, le trafic de ce nĆud ne peut passer que par le tunnel VxLAN et rien d'autre. Cependant, si vous allumez le DVR, la situation changera, mais nous y reviendrons une autre fois. Lorsque vous utilisez l'isolation de rĂ©seau, par exemple en utilisant des vlans, vous n'aurez pas une interface L3 dans le 0Ăšme vlan, mais plusieurs interfaces. Cependant, le trafic VxLAN sortira du nĆud de la mĂȘme maniĂšre, mais Ă©galement encapsulĂ© dans une sorte de vlan dĂ©diĂ©.
Nous avons compris le nĆud de calcul, allez au nĆud de contrĂŽle.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
En fait, on peut dire que tout est pareil, mais l'adresse IP n'est plus sur l'interface physique, mais sur le pont virtuel. Cela est dû au fait que ce port est un port par lequel le trafic ira vers le monde extérieur.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$
Ce port est lié au pont br-ex et comme il n'y a pas de balises vlan, ce port est un port trunk sur lequel tous les vlans sont autorisés, maintenant le trafic sort sans balise, comme indiqué par vlan-id 0 dans la sortie ci-dessus.
Tout le reste pour le moment est similaire au nĆud de calcul - les mĂȘmes ponts, les mĂȘmes tunnels allant Ă deux nĆuds de calcul.
Nous ne considĂ©rerons pas les nĆuds de stockage dans cet article, mais pour comprendre il faut dire que la partie rĂ©seau de ces nĆuds est banale au point de disgrĂące. Dans notre cas, il n'y a qu'un seul port physique (eth0) avec une adresse IP accrochĂ©e dessus et c'est tout. Il n'y a pas de tunnels VxLAN, de ponts de tunnel, etc. - il n'y a pas du tout d'ov, car cela ne sert Ă rien. Lors de l'utilisation de l'isolation rĂ©seau - ce nĆud aura deux interfaces (ports physiques, bauds, ou juste deux vlans - cela n'a pas d'importance - cela dĂ©pend de ce que vous voulez) - une pour la gestion, la seconde pour le trafic (Ă©criture sur le disque VM, lecture Ă partir de disque, etc.).
Nous avons compris ce que nous avons sur les nĆuds en l'absence de services. Maintenant, commençons 4 machines virtuelles et voyons comment le schĂ©ma dĂ©crit ci-dessus change - nous devrions avoir des ports, des routeurs virtuels, etc.
Jusqu'à présent, notre réseau ressemble à ceci:
Nous avons deux machines virtuelles sur chaque ordinateur. Voyons comment tout est inclus avec compute-0.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$
La machine n'a qu'une seule interface virtuelle - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Cette interface regarde le pont Linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$
Comme vous pouvez le voir dans la sortie, il n'y a que deux interfaces dans la brigade - tap95d96a75-a0 et qvb95d96a75-a0.
Il vaut la peine deComme vous le comprenez, si nous avons un port qvb95d96a75-a0 dans la brigade, qui est une vEth paire, alors oĂč est son homologue, qui devrait logiquement ĂȘtre appelĂ© qvo95d96a75-a0. Voyons quels sont les ports sur l'OVS.
s'attarder un peu sur les types de périphériques réseau virtuels dans OpenStack: vtap - une interface virtuelle connectée à une instance (VM)
qbr - Linux bridge
qvb and qvo - vEth pair connecté à un pont Linux et Open vSwitch bridge
br-int, br-tun, br-vlan - Open vSwitch bridges
patch-, int-br-, phy-br- - Open vSwitch patch-interfaces reliant les ponts
qg, qr, ha, fg, sg - Ouvrez les ports vSwitch utilisés par les périphériques virtuels pour se connecter à OVS
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$
Comme nous pouvons le voir, le port est en br-int. Br-int agit comme un commutateur qui termine les ports des machines virtuelles. En plus de qvo95d96a75-a0, la sortie affiche le port qvo5bd37136-47. Il s'agit du port vers la deuxiÚme machine virtuelle. En conséquence, notre schéma ressemble maintenant à ceci: La
question qui devrait immédiatement intéresser un lecteur attentif - pourquoi le pont Linux entre le port de la machine virtuelle et le port OVS? Le fait est que les groupes de sécurité sont utilisés pour protéger la machine, qui ne sont rien de plus que des iptables. OVS ne fonctionne pas avec les iptables, donc cette "béquille" a été inventée. Cependant, il survit au sien - il est remplacé par conntrack dans les nouvelles versions.
Autrement dit, finalement, le schéma ressemble à ceci:
Deux machines sur un hyperviseur dans un réseau L2
Ătant donnĂ© que ces deux machines virtuelles sont dans le mĂȘme rĂ©seau L2 et sur le mĂȘme hyperviseur, le trafic entre elles passera logiquement localement via br-int, puisque les deux machines seront dans le mĂȘme VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$
Deux machines sur diffĂ©rents hyperviseurs dans le mĂȘme rĂ©seau L2
Voyons maintenant comment le trafic passe entre deux machines dans le mĂȘme rĂ©seau L2, mais situĂ©es sur des hyperviseurs diffĂ©rents. Pour ĂȘtre honnĂȘte, rien ne changera beaucoup, seul le trafic entre les hyperviseurs passera par le tunnel vxlan. Voyons un exemple.
Les adresses des machines virtuelles entre lesquelles nous surveillerons le trafic:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$
Nous regardons la table de transfert dans br-int Ă compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]
Le trafic devrait aller au port 2 - voyons ce qu'est ce port:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$
Ceci est patch-tun - c'est-Ă -dire l'interface avec br-tun. Voyons ce qui arrive au paquet sur br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$
Le paquet est emballĂ© dans VxLAN et envoyĂ© au port 2. Voyons oĂč le port 2 mĂšne:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$
Ceci est un tunnel vxlan sur compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$
Accédez à compute-1 et voyez ce qui se passe ensuite avec le package:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$
Le Mac est dans la table de transfert br-int sur compute-1, et comme vous pouvez le voir dans la sortie ci-dessus, il est visible via le port 2, qui est les ports vers br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
Eh bien, alors nous regardons qu'il y a un mac de destination dans br-int sur compute-1:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$
Autrement dit, le paquet reçu volera vers le port 3, derriÚre lequel la machine virtuelle instance-00000003 se trouve déjà .
La beauté du déploiement d'Openstack pour l'apprentissage sur une infrastructure virtuelle est que nous pouvons facilement attraper le trafic entre les hyperviseurs et voir ce qui lui arrive. C'est ce que nous allons faire maintenant, exécutez tcpdump sur le port vnet vers compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************
La premiÚre ligne montre que le correctif avec l'adresse 10.0.1.85 va à l'adresse 10.0.1.88 (trafic ICMP), et il est enveloppé dans un paquet VxLAN avec vni 22 et le paquet va de l'hÎte 192.168.255.19 (compute-0) à l'hÎte 192.168.255.26 ( compute-1). Nous pouvons vérifier que le VNI correspond à celui spécifié dans les ovs.
Revenons à cette ligne actions = load: 0-> NXM_OF_VLAN_TCI [], load: 0x16-> NXM_NX_TUN_ID [], output: 2. 0x16 est un vni hexadécimal. Traduisons ce nombre dans le 10e systÚme:
16 = 6*16^0+1*16^1 = 6+16 = 22
Autrement dit, vni correspond à la réalité.
La deuxiĂšme ligne montre le trafic de retour, eh bien, cela n'a aucun sens de l'expliquer lĂ -bas, et donc tout est clair.
Deux machines sur des réseaux différents (routage entre réseaux)
Le dernier cas pour aujourd'hui est le routage entre les rĂ©seaux au sein d'un projet Ă l'aide d'un routeur virtuel. Nous considĂ©rons un cas sans DVR (nous le considĂ©rerons dans un autre article), donc le routage se produit sur le nĆud du rĂ©seau. Dans notre cas, le nĆud de rĂ©seau n'est pas une entitĂ© distincte et est situĂ© sur le nĆud de contrĂŽle.
Tout d'abord, voyons que le routage fonctionne:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms
Puisque dans ce cas le paquet doit aller Ă la passerelle et y ĂȘtre acheminĂ©, nous devons trouver l'adresse MAC de la passerelle, pour laquelle nous regarderons la table ARP dans l'instance:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0
Voyons maintenant oĂč le trafic doit ĂȘtre envoyĂ© avec la destination (10.0.1.254) fa: 16: 3e: c4: 64: 70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$
Nous regardons oĂč mĂšne le port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$
Tout est logique, le trafic va à br-tun. Voyons dans quel tunnel vxlan il sera enveloppé:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$
Le troisiĂšme port est le tunnel vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
Qui regarde le nĆud de contrĂŽle:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
Le trafic a atteint le nĆud de contrĂŽle, nous devons donc y aller et voir comment le routage se dĂ©roulera.
Comme vous vous en souvenez, le nĆud de contrĂŽle Ă l'intĂ©rieur ressemblait exactement au nĆud de calcul - les trois mĂȘmes ponts, seul br-ex avait un port physique Ă travers lequel le nĆud pouvait envoyer du trafic Ă l'extĂ©rieur. La crĂ©ation de l'instance a changĂ© la configuration sur les nĆuds de calcul - le pont Linux, les iptables et les interfaces ont Ă©tĂ© ajoutĂ©s aux nĆuds. La crĂ©ation de rĂ©seaux et d'un routeur virtuel a Ă©galement laissĂ© sa marque sur la configuration du nĆud de contrĂŽle.
Ainsi, il est Ă©vident que l'adresse de pavot de passerelle doit ĂȘtre dans la table de transfert br-int sur le nĆud de contrĂŽle. VĂ©rifions qu'il est lĂ et oĂč il se trouve:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$
Mac est visible depuis le port qr-0c52b15f-8f. Si nous revenons Ă la liste des ports virtuels dans Openstack, alors ce type de port est utilisĂ© pour connecter divers pĂ©riphĂ©riques virtuels Ă OVS. Pour ĂȘtre plus prĂ©cis, qr est un port vers le routeur virtuel, qui est reprĂ©sentĂ© comme un espace de noms.
Voyons quels sont les espaces de noms sur le serveur:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$
Jusqu'à trois exemplaires. Mais à en juger par les noms, vous pouvez deviner le but de chacun d'eux. Nous reviendrons sur les instances avec les ID 0 et 1 plus tard, maintenant nous sommes intéressés par l'espace de noms qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$
Cet espace de noms a deux espaces internes que nous avons créés précédemment. Les deux ports virtuels sont ajoutés à br-int. Vérifions l'adresse de masse du port qr-0c52b15f-8f, car le trafic, à en juger par l'adresse du pavot de destination, allait exactement vers cette interface.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
Autrement dit, dans ce cas, tout fonctionne selon les lois du routage standard. Ătant donnĂ© que le trafic est destinĂ© Ă l'hĂŽte 10.0.2.8, il doit sortir via la deuxiĂšme interface qr-92fa49b5-54 et passer par le tunnel vxlan jusqu'au nĆud de calcul:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$
Tout est logique, pas de surprises. Nous regardons d'oĂč l'adresse coquelicot de l'hĂŽte 10.0.2.8 dans br-int est visible:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$
Comme prévu, le trafic va à br-tun, voyons dans quel tunnel le trafic va ensuite:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
Le trafic entre dans le tunnel pour calculer-1. Eh bien, sur compute-1, tout est simple - de br-tun le paquet va Ă br-int et de lĂ Ă l'interface de la machine virtuelle:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$
VĂ©rifions que c'est bien la bonne interface:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
En fait, nous avons parcouru tout le paquet. Je pense que vous avez remarquĂ© que le trafic passait par diffĂ©rents tunnels vxlan et sortait avec diffĂ©rents VNI. Voyons de quel type de VNI il s'agit, puis collectons un vidage sur le port de contrĂŽle du nĆud et assurez-vous que le trafic se dĂ©roule exactement comme dĂ©crit ci-dessus.
Ainsi, le tunnel pour calculer-0 a les actions suivantes = charge: 0-> NXM_OF_VLAN_TCI [], charge: 0x16-> NXM_NX_TUN_ID [], sortie: 3. Conversion de 0x16 en notation décimale:
0x16 = 6*16^0+1*16^1 = 6+16 = 22
Le tunnel pour calculer-1 a le VNI suivant: actions = charge: 0-> NXM_OF_VLAN_TCI [], charge: 0x63-> NXM_NX_TUN_ID [], sortie: 2. Conversion de 0x63 en notation décimale:
0x63 = 3*16^0+6*16^1 = 3+96 = 99
Eh bien, voyons maintenant la décharge:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************
Le premier paquet est un paquet vxlan de l'hÎte 192.168.255.19 (calcul-0) à l'hÎte 192.168.255.15 (contrÎle-1) avec vni 22, à l'intérieur duquel un paquet ICMP est emballé de l'hÎte 10.0.1.85 à l'hÎte 10.0.2.8. Comme nous l'avons calculé ci-dessus, vni correspond à ce que nous avons vu dans les sorties.
Le deuxiÚme paquet est un paquet vxlan de l'hÎte 192.168.255.15 (contrÎle-1) à l'hÎte 192.168.255.26 (calcul-1) avec vni 99, à l'intérieur duquel un paquet ICMP est emballé de l'hÎte 10.0.1.85 à l'hÎte 10.0.2.8. Comme nous l'avons calculé ci-dessus, vni correspond à ce que nous avons vu dans les sorties.
Les deux paquets suivants sont le trafic de retour de 10.0.2.8 et non de 10.0.1.85.
Autrement dit, Ă la fin, nous avons le schĂ©ma de nĆud de contrĂŽle suivant:
Comme tout? Nous avons oublié deux espaces de noms:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$
Comme nous avons parlé de l'architecture de la plate-forme cloud, ce serait bien si les machines reçoivent automatiquement les adresses d'un serveur DHCP. Ce sont deux serveurs DHCP pour nos deux réseaux 10.0.1.0/24 et 10.0.2.0/24.
VĂ©rifions qu'il en est bien ainsi. Cet espace de noms contient une seule adresse - 10.0.1.1 - l'adresse du serveur DHCP lui-mĂȘme, et il est Ă©galement inclus dans br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Voyons si les processus contenant qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 dans leurs noms sur le nĆud de contrĂŽle:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$
Il existe un tel processus, et sur la base des informations présentées dans la sortie ci-dessus, nous pouvons, par exemple, voir ce que nous avons en loyer pour le moment:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$
En consĂ©quence, nous obtenons un tel ensemble de services sur le nĆud de contrĂŽle:
Eh bien, gardez Ă l'esprit - ce n'est que - 4 machines, 2 rĂ©seaux internes et un routeur virtuel ... Nous n'avons pas de rĂ©seaux externes ici maintenant, des tas de projets diffĂ©rents, chacun avec ses propres rĂ©seaux (se chevauchant ), et nous avons dĂ©sactivĂ© le routeur distribuĂ©, mais Ă la fin il n'y avait qu'un seul nĆud de contrĂŽle dans le banc de test (pour la tolĂ©rance aux pannes, il doit y avoir un quorum de trois nĆuds). Il est logique que dans le commerce, tout soit "un peu" plus compliquĂ©, mais dans cet exemple simple, nous comprenons comment cela devrait fonctionner - si vous avez 3 ou 300 espaces de noms, bien sĂ»r, c'est important, mais du point de vue du fonctionnement de toute la structure, rien ne changera beaucoup ... mais pour l'instant ne collez pas une sorte de fournisseur SDN. Mais c'est une histoire complĂštement diffĂ©rente.
J'espĂšre que c'Ă©tait intĂ©ressant. S'il y a bien des commentaires / ajouts, ou quelque part oĂč j'ai menti ouvertement (je suis un ĂȘtre humain et mon opinion sera toujours subjective) - Ă©crivez ce qui doit ĂȘtre corrigĂ© / ajoutĂ© - nous corrigerons / ajouterons tout.
En conclusion, je voudrais dire quelques mots sur la comparaison d'Openstack (Ă la fois vanille et fournisseur) avec une solution cloud de VMWare - trop souvent, on me pose cette question depuis quelques annĂ©es et, pour ĂȘtre honnĂȘte, j'en ai marre, mais quand mĂȘme. Ă mon avis, ces deux solutions sont trĂšs difficiles Ă comparer, mais nous pouvons dire sans Ă©quivoque qu'il y a des inconvĂ©nients dans les deux solutions, et lors du choix d'une solution, il faut peser le pour et le contre.
Si OpenStack est une solution communautaire, alors VMWare a le droit de ne faire que ce qu'il veut (lire - ce qui est rentable pour lui) et c'est logique - car c'est une entreprise commerciale qui est habituĂ©e Ă gagner de l'argent avec ses clients. Mais il y a un gros et gros MAIS - vous pouvez quitter OpenStack de Nokia, par exemple, et passer Ă une solution de, par exemple, Juniper (Contrail Cloud), mais vous pourrez difficilement quitter VMWare. Pour moi, ces deux solutions ressemblent Ă ceci - Openstack (fournisseur) est une simple cage dans laquelle vous ĂȘtes mis, mais vous avez la clĂ© et vous pouvez quitter Ă tout moment. VMWare est une cage dorĂ©e, le propriĂ©taire a la clĂ© de la cage et cela vous coĂ»tera cher.
Je ne fais campagne ni pour le premier produit ni pour le second - vous choisissez ce dont vous avez besoin. Mais si j'avais un tel choix, je choisirais les deux solutions - VMWare pour le cloud informatique (faibles charges, gestion pratique), OpenStack de certains fournisseurs (Nokia et Juniper fournissent de trÚs belles solutions clé en main) - pour les clouds Telecom. Je n'utiliserais pas Openstack pour de l'informatique pure - c'est comme tirer sur un moineau avec un canon, mais je ne vois aucune contre-indication à son utilisation, à l'exception de la redondance. Cependant, utiliser VMWare dans les télécommunications - comment transporter des gravats sur un Ford Raptor - est beau de l'extérieur, mais le conducteur doit effectuer 10 trajets au lieu d'un.
Ă mon avis, le plus gros inconvĂ©nient de VMWare est sa fermeture complĂšte - l'entreprise ne vous donnera aucune information sur son fonctionnement, par exemple, vSAN ou ce qui se trouve dans le noyau de l'hyperviseur - ce n'est tout simplement pas rentable pour cela - c'est-Ă -dire que vous ne deviendrez jamais un expert de VMWare - sans le support du fournisseur, vous ĂȘtes condamnĂ© (trĂšs souvent je rencontre des experts VMWare qui sont dĂ©concertĂ©s par des questions banales). Pour moi, VMWare achĂšte une voiture avec un capot verrouillĂ© - oui, vous avez peut-ĂȘtre des spĂ©cialistes qui peuvent changer la courroie de distribution, mais seul celui qui vous a vendu cette solution peut ouvrir le capot. Personnellement, je n'aime pas les solutions dans lesquelles je ne peux pas m'intĂ©grer. Vous direz que vous n'aurez peut-ĂȘtre pas Ă passer sous le capot. Oui, c'est possible, mais je vous regarderai lorsque vous aurez besoin d'assembler une grande fonction dans le cloud Ă partir de 20-30 machines virtuelles, 40-50 rĂ©seaux,dont la moitiĂ© veut aller Ă l'extĂ©rieur et l'autre moitiĂ© demande une accĂ©lĂ©ration SR-IOV, sinon vous aurez besoin de quelques douzaines de plus de ces machines - sinon les performances ne seront pas suffisantes.
Il y a d'autres points de vue, c'est donc Ă vous de dĂ©cider quoi choisir et, surtout, vous ĂȘtes responsable de votre choix plus tard. Ce n'est que mon avis - une personne qui a vu et touchĂ© au moins 4 produits - Nokia, Juniper, Red Hat et VMWare. Autrement dit, j'ai quelque chose Ă comparer.