Cloud-Computing durchdringt unser Leben immer mehr, und es gibt wahrscheinlich keine Person, die nicht zumindest einmal irgendwelche Cloud-Dienste genutzt hat. Doch was genau ist die Cloud und wie funktioniert sie? Das wissen die meisten Menschen nicht einmal im Ansatz. 5G wird immer mehr zur RealitĂ€t, und die Telekommunikationsinfrastruktur beginnt, von feststehenden Lösungen auf Cloud-Lösungen umzusteigen, so wie sie einst von vollstĂ€ndig stationĂ€ren Lösungen zu virtualisierten âSĂ€ulenâ ĂŒbergegangen ist.
Heute sprechen wir ĂŒber die innere Welt der Cloud-Infrastruktur, insbesondere ĂŒber die Grundlagen des Netzwerkbereichs.
Was ist die Cloud? Ist das nicht einfach Virtualisierung â von der Seite betrachtet?
Eine völlig berechtigte Frage. Nein, das ist keine Virtualisierung, obwohl sie nicht ausgeschlossen ist. Lassen Sie uns zwei Definitionen betrachten:
Cloud-Computing (im Folgenden die Cloud) â ist ein Modell zur Bereitstellung benutzerfreundlichen Zugangs zu verteilten Rechenressourcen, die auf Anfrage mit minimaler Verzögerung und minimalen Kosten fĂŒr den Dienstleister bereitgestellt und gestartet werden mĂŒssen.
Virtualisierung â ist die Möglichkeit, eine physische EntitĂ€t (zum Beispiel einen Server) in mehrere virtuelle aufzuteilen, wodurch die Ressourcennutzung maximiert wird (zum Beispiel hatten Sie frĂŒher 3 Server, die zu 25-30 Prozent ausgelastet waren, nach der Virtualisierung erhalten Sie 1 Server, der zu 80-90 Prozent ausgelastet ist). NatĂŒrlich benötigt die Virtualisierung einen Teil der Ressourcen â Sie mĂŒssen den Hypervisor unterstĂŒtzen, jedoch hat die Praxis gezeigt, dass sich der Aufwand lohnt. Ein ideales Beispiel fĂŒr Virtualisierung ist VMWare, das hervorragend virtuelle Maschinen bereitstellt, oder KVM, das mir mehr zusagt, aber das ist Geschmackssache.
Wir nutzen Virtualisierung, ohne es zu merken; sogar physische Router verwenden bereits Virtualisierung â zum Beispiel wird in den neuesten Versionen des JunOS-Betriebssystems die Software als virtuelle Maschine ĂŒber einem Echtzeit-Linux-Distribution (Wind River 9) bereitgestellt. Aber Virtualisierung ist nicht die Cloud, dennoch kann die Cloud ohne Virtualisierung nicht existieren.
Virtualisierung ist einer der Bausteine, auf denen die Cloud aufgebaut ist.
Ein Cloud-System aufzubauen, indem man mehrere Hypervisoren in eine L2-DomĂ€ne zusammenfĂŒhrt, ein paar YAML-Playbooks fĂŒr die automatische Konfiguration von VLANs ĂŒber irgendein Ansible hinzufĂŒgt und darauf noch ein Orchestrierungssystem zur automatischen Erstellung virtueller Maschinen draufpackt â wird nicht funktionieren. Genauer gesagt, es wird funktionieren, aber der entstandene Frankenstein ist nicht die Art von Cloud, die wir brauchen; obwohl, fĂŒr manche könnte es das Nonplusultra sein. Wenn wir das gleiche OpenStack betrachten â im Grunde auch ein gewisser Frankenstein, aber lassen wir das erstmal beiseite.
Ich verstehe jedoch, dass aus der obigen Definition nicht ganz klar wird, was tatsÀchlich als Cloud bezeichnet werden kann.
Deshalb werden im Dokument des NIST (National Institute of Standards and Technology) fĂŒnf grundlegende Merkmale aufgefĂŒhrt, die eine Cloud-Infrastruktur aufweisen sollte:
Bereitstellung von Diensten auf Anfrage. Die Nutzer mĂŒssen freien Zugang zu den ihnen zugewiesenen Computerressourcen (wie Netzwerken, virtuellen Festplatten, Speicher, Prozessorkernen usw.) erhalten; diese Ressourcen sollten automatisch bereitgestellt werden â das heiĂt, ohne Eingreifen des Dienstanbieters.
Hohe VerfĂŒgbarkeit des Dienstes. Der Zugriff auf die Ressourcen sollte mithilfe standardisierter Mechanismen erfolgen, um sowohl die Nutzung auf Standard-PCs, als auch auf Thin Clients und mobilen GerĂ€ten zu ermöglichen.
Konsolidierung der Ressourcen in Pools. Ressourcenpools sollten die gleichzeitige Bereitstellung von Ressourcen fĂŒr mehrere Kunden gewĂ€hrleisten, wobei die Isolierung der Kunden und das Fehlen gegenseitiger Beeinflussung sowie Konkurrenz um Ressourcen gewĂ€hrleistet sind. Zu den Pools gehören auch Netzwerke, was die Möglichkeit der Verwendung ĂŒberlappender Adressierung bedeutet. Die Pools sollten skalierbar auf Anfrage sein. Die Verwendung von Pools ermöglicht es, ein notwendiges MaĂ an Ausfallsicherheit der Ressourcen und eine Abstraktion physischer und virtueller Ressourcen sicherzustellen â dem ServicesempfĂ€nger wird einfach der angeforderte Ressourcenstamm zur VerfĂŒgung gestellt (wo sich diese Ressourcen physisch befinden, auf wie vielen Servern und Switches â das ist fĂŒr den Kunden irrelevant). Es ist jedoch zu beachten, dass der Anbieter ein transparentes Backup dieser Ressourcen bereitstellen muss.
Schnelle Anpassung an unterschiedliche Bedingungen. Die Dienste mĂŒssen flexibel sein â schnelle Bereitstellung von Ressourcen, deren Umverteilung, HinzufĂŒgen oder KĂŒrzen von Ressourcen auf Anfrage des Kunden, wobei der Kunde den Eindruck haben sollte, dass die Ressourcen der Cloud unendlich sind. Zum besseren VerstĂ€ndnis: Sie sehen beispielsweise keine Warnung, dass Ihnen im Apple iCloud Speicherplatz fehlt, weil auf dem Server die Festplatte kaputt ging â und Festplatten gehen kaputt. Zudem sind die Möglichkeiten dieses Dienstes von Ihrer Seite aus praktisch unbegrenzt â benötigen Sie 2 TB, kein Problem, bezahlen und erhalten Sie. Ein Ă€hnliches Beispiel kann mit Google.Drive oder Yandex.Disk angefĂŒhrt werden.
Die Möglichkeit, den bereitgestellten Dienst zu messen. Cloud-Systeme sollten automatisch die genutzten Ressourcen ĂŒberwachen und optimieren, wobei diese Mechanismen sowohl fĂŒr den Benutzer als auch fĂŒr den Dienstanbieter transparent sein mĂŒssen. Das bedeutet, dass Sie jederzeit ĂŒberprĂŒfen können, wie viele Ressourcen Sie und Ihre Kunden nutzen.
Es sollte berĂŒcksichtigt werden, dass diese Anforderungen gröĂtenteils Anforderungen an öffentliche Clouds sind. Daher können diese Anforderungen fĂŒr private Clouds (also Clouds, die fĂŒr die internen BedĂŒrfnisse eines Unternehmens betrieben werden) etwas angepasst werden. Sie mĂŒssen jedoch weiterhin erfĂŒllt werden, sonst erhalten wir nicht alle Vorteile des Cloud-Computing.
Warum brauchen wir eine Cloud?
Allerdings wird jede neue oder bereits bestehende Technologie, jedes neue Protokoll aus einem bestimmten Grund geschaffen (auĂer RIP-ng, natĂŒrlich). Ein Protokoll um des Protokolls willen â niemand braucht das (auĂer RIP-ng, natĂŒrlich). Es ist logisch, dass eine Cloud geschaffen wird, um dem Benutzer/Kunden einen bestimmten Dienst bereitzustellen. Wir sind alle zumindest mit ein paar Cloud-Diensten wie Dropbox oder Google.Docs vertraut, und ich nehme an, dass die meisten sie erfolgreich nutzen â beispielsweise wurde dieser Artikel mit dem Cloud-Dienst Google.Docs verfasst. Aber die bekannten Cloud-Dienste sind nur ein Teil der Möglichkeiten, die eine Cloud bietet â genauer gesagt, das ist nur ein Diensttyp wie SaaS. Wir können einen Cloud-Dienst auf drei Arten bereitstellen: als SaaS, PaaS oder IaaS. Welcher Dienst genau fĂŒr Sie benötigt wird, hĂ€ngt von Ihren WĂŒnschen und Möglichkeiten ab.
Lassen Sie uns jeden der Punkte der Reihe nach betrachten:
Software as a Service (SaaS) â ist ein Modell zur Bereitstellung eines umfassenden Services fĂŒr den Kunden, wie zum Beispiel ein Mailservice wie Yandex.Mail oder Gmail. In einem solchen Service-Modell tun Sie als Kunde im Grunde nichts anderes, als den Service zu nutzen â das heiĂt, Sie mĂŒssen nicht ĂŒber die Einrichtung des Services, dessen Ausfallsicherheit oder Backup nachdenken. Das Wichtigste ist, Ihr Passwort nicht zu kompromittieren, alles andere erledigt der Anbieter des Services fĂŒr Sie. Aus der Sicht des Serviceanbieters ist er voll verantwortlich fĂŒr den gesamten Service â beginnend mit der Serverhardware und den Host-Betriebssystemen bis hin zu den Einstellungen der Datenbanken und Software.
Platform as a Service (PaaS) â bei Verwendung dieses Modells stellt der Dienstanbieter dem Kunden eine Vorlage fĂŒr den Service zur VerfĂŒgung, zum Beispiel einen Webserver. Der Dienstanbieter hat dem Kunden einen virtuellen Server bereitgestellt (faktisch einen Satz von Ressourcen wie RAM/CPU/Speicher/Netz usw.) und sogar das Betriebssystem und die erforderliche Software auf diesen Server installiert, allerdings erfolgt die Konfiguration all dieser Ressourcen durch den Kunden selbst und der Kunde ist bereits fĂŒr die FunktionsfĂ€higkeit des Services verantwortlich. Der Dienstanbieter ist, wie im vorherigen Fall, fĂŒr die FunktionsfĂ€higkeit der physikalischen Hardware, Hypervisoren, der virtuellen Maschine selbst, ihrer NetzverfĂŒgbarkeit usw. verantwortlich, aber der Service selbst fĂ€llt nicht mehr in seinen Verantwortungsbereich.
Infrastructure as a Service (IaaS) â dieser Ansatz ist bereits interessanter, denn der Dienstanbieter stellt dem Kunden eine vollstĂ€ndige virtualisierte Infrastruktur zur VerfĂŒgung â das heiĂt, eine Art Satz (Pool) von Ressourcen wie CPU-Kerne, RAM, Netzwerke usw. Alles Weitere liegt in der Verantwortung des Kunden â was der Kunde mit diesen Ressourcen innerhalb des ihm zugewiesenen Pools (Quoten) tun möchte, ist fĂŒr den Anbieter nicht von groĂer Bedeutung. Möchte der Kunde sein eigenes vEPC erstellen oder sogar einen Mini-Operator grĂŒnden und Telekommunikationsdienstleistungen anbieten â kein Problem â tun Sie es. In solch einem Szenario ist der Anbieter verantwortlich fĂŒr die Bereitstellung der Ressourcen, deren Ausfallsicherheit und VerfĂŒgbarkeit, sowie fĂŒr das Betriebssystem, das es ermöglicht, diese Ressourcen in Pools zusammenzufassen und sie dem Kunden mit der Möglichkeit zur VerfĂŒgung zu stellen, jederzeit die Ressourcen auf Anfrage des Kunden zu erhöhen oder zu verringern. Alle virtuellen Maschinen und sonstigen Kleinigkeiten konfiguriert der Kunde selbst ĂŒber ein Self-Service-Portal und Konsolen, einschlieĂlich der Netzwerkkonfiguration (auĂer fĂŒr externe Netzwerke).
Was ist OpenStack?
In allen drei Varianten benötigt der Dienstleister ein Betriebssystem, das es ermöglicht, eine Cloud-Infrastruktur zu schaffen. TatsĂ€chlich ist jedoch bei SaaS nicht nur eine Abteilung fĂŒr den gesamten Technologie-Stack verantwortlich â es gibt eine Abteilung, die fĂŒr die Infrastruktur verantwortlich ist â das heiĂt, sie stellt IaaS einer anderen Abteilung zur VerfĂŒgung, die dem Kunden SaaS bereitstellt. OpenStack ist eines der Cloud-Betriebssysteme, das es ermöglicht, eine Reihe von Switches, Servern und Speichersystemen zu einem gemeinsamen Ressourcenpool zusammenzufassen, diesen gemeinsamen Pool in Sub-Pools (Tenants) zu unterteilen und diese Ressourcen ĂŒber das Netzwerk den Kunden bereitzustellen.
OpenStack ist ein Cloud-Betriebssystem, das es ermöglicht, groĂe Pools von Rechenressourcen, Datenspeichern und Netzwerkressourcen zu steuern, deren Provisionierung und Verwaltung ĂŒber APIs mit standardisierten Authentifizierungsmechanismen erfolgt.
Anders ausgedrĂŒckt, handelt es sich dabei um ein System von Open-Source-Projekten, das zur Erstellung von Cloud-Diensten (sowohl öffentlichen als auch privaten) gedacht ist â also eine Sammlung von Werkzeugen, die es ermöglichen, Server- und NetzwerkausrĂŒstung in einem gemeinsamen Ressourcenpool zu vereinen, diese Ressourcen zu verwalten und die erforderliche VerfĂŒgbarkeit zu gewĂ€hrleisten.
Zum Zeitpunkt der Erstellung dieses Materials sieht die Struktur von OpenStack wie folgt aus:
Das Bild stammt von
Jede der Komponenten, die in OpenStack integriert sind, erfĂŒllt eine spezifische Funktion. Diese verteilte Architektur ermöglicht es, die benötigten funktionalen Komponenten in die Lösung aufzunehmen. Allerdings sind einige Komponenten essentielle und deren Entfernung fĂŒhrt zu einer vollstĂ€ndigen oder teilweisen FunktionsunfĂ€higkeit der Lösung insgesamt. Zu diesen Komponenten zĂ€hlen:
- Dashboard â Eine webbasierte GUI zur Verwaltung der OpenStack-Dienste
- Keystone â ein zentralisierter Identifikationsdienst, der Authentifizierungs- und Autorisierungsfunktionen fĂŒr andere Dienste bereitstellt sowie Benutzerdaten und deren Rollen verwaltet.
- Neutron â ein Netzwerkdienst, der die KonnektivitĂ€t zwischen den Schnittstellen verschiedener OpenStack-Dienste gewĂ€hrleistet (einschlieĂlich der KonnektivitĂ€t zwischen VMs und deren Zugang zur AuĂenwelt)
- Cinder â gewĂ€hrt Zugang zu blockbasiertem Speicher fĂŒr virtuelle Maschinen
- Nova â Verwaltung des Lebenszyklus virtueller Maschinen
- Glance â Repository fĂŒr Abbilder virtueller Maschinen und Snapshots
- Swift â ermöglicht den Zugang zum Objektspeicher
- Ceilometer â Dienst, der die Möglichkeit zur Sammlung von Telemetriedaten und zur Messung von vorhandenen und verbrauchenden Ressourcen bietet
- Heat â Orchestrierung auf Basis von Templates fĂŒr die automatische Erstellung und Bereitstellung von Ressourcen
Eine vollstÀndige Liste aller Projekte und deren Zweck kann eingesehen werden .
Jede der OpenStack-Komponenten ist ein Dienst, der fĂŒr eine bestimmte Funktion zustĂ€ndig ist und eine API zur Verwaltung dieser Funktion sowie zur Interaktion mit anderen Diensten des Cloud-Betriebssystems bietet, um eine einheitliche Infrastruktur zu schaffen. Beispielsweise verwaltet Nova die Rechenressourcen und bietet eine API fĂŒr den Zugriff auf die Konfiguration dieser Ressourcen, Glance â das Management von Abbildern und eine API zu deren Verwaltung, Cinder â Blockspeicher und eine API zu dessen Verwaltung usw. Alle Funktionen sind sehr eng miteinander verbunden.
Wenn man jedoch darĂŒber nachdenkt, stellt sich die Frage, warum wir so viele Elemente benötigen, da letztlich jeder Dienst, der in OpenStack ausgefĂŒhrt wird, eine Art virtuelle Maschine (oder Container) ist, die mit dem Netzwerk verbunden ist.
Lassen Sie uns den Algorithmus zur Erstellung einer virtuellen Maschine und deren Anschluss an das Netzwerk und den persistenten Speicher in OpenStack durchgehen.
- Wenn Sie eine Anfrage zur Erstellung einer Maschine stellen, sei es ĂŒber Horizon (Dashboard) oder ĂŒber CLI, geschieht zunĂ€chst Folgendes: Ihr Antrag wird bei Keystone authorisiert â dĂŒrfen Sie eine Maschine erstellen, haben Sie das Recht, dieses Netzwerk zu nutzen, hat Ihr Projekt genĂŒgend Kontingent usw.
- Keystone fĂŒhrt die Authentifizierung Ihrer Anfrage durch und generiert ein Auth-Token in der Antwort, das spĂ€ter verwendet wird. Nach Erhalt der Antwort von Keystone wird die Anfrage an Nova (nova api) gesendet.
- Die Nova-API ĂŒberprĂŒft die GĂŒltigkeit Ihrer Anfrage, indem sie sich an Keystone wendet und das zuvor generierte Auth-Token verwendet.
- Keystone fĂŒhrt die Authentifizierung durch und stellt auf Basis des Auth-Tokens Informationen zu Berechtigungen und EinschrĂ€nkungen zur VerfĂŒgung.
- Die Nova-API erstellt im nova-database einen Eintrag ĂŒber die neue VM und leitet die Anfrage zur Erstellung der Maschine an den nova-scheduler weiter.
- Der Nova-Scheduler wÀhlt den Host (Rechnerknoten) aus, auf dem die VM basierend auf festgelegten Parametern, Gewichten und Zonen bereitgestellt wird. Ein Eintrag dazu und die VM-ID werden in der nova-Datenbank gespeichert.
- AnschlieĂend kontaktiert der Nova-Scheduler nova-compute mit der Anfrage zur Bereitstellung einer Instanz. Nova-compute wendet sich an nova-conductor, um Informationen zu den Maschinenparametern zu erhalten (nova-conductor ist ein Element von nova, das als Proxy-Server zwischen nova-datenbank und nova-compute fungiert, um die Anzahl der Anfragen an die nova-datenbank zu begrenzen und Probleme mit der Datenbankkonsistenz zu vermeiden).
- Nova-conductor erhĂ€lt die angeforderten Informationen aus der nova-datenbank und ĂŒbergibt sie an nova-compute.
- Danach wendet sich nova-compute an glance, um die ID des Abbilds zu erhalten. Glance validiert die Anfrage in Keystone und gibt die angeforderten Informationen zurĂŒck.
- Nova-compute kontaktiert neutron, um Informationen zu den Netzparametern zu erhalten. Ăhnlich wie glance validiert neutron die Anfrage in Keystone, erstellt dann einen Eintrag in der Datenbank (Port-ID usw.), fordert die Erstellung eines Ports an und gibt die angeforderten Informationen an nova-compute zurĂŒck.
- Nova-compute wendet sich an cinder mit der Anfrage zur Bereitstellung eines Volumes fĂŒr die virtuelle Maschine. Ăhnlich wie glance validiert cinder die Anfrage in Keystone, erstellt einen Antrag zur Erstellung eines Volumes und gibt die angeforderten Informationen zurĂŒck.
- Nova-compute kontaktiert libvirt mit der Anfrage zur Bereitstellung der virtuellen Maschine mit den angegebenen Parametern.
TatsĂ€chlich verwandelt sich eine scheinbar einfache Operation zur Erstellung einer einfachen virtuellen Maschine in einen solchen Wirbelwind von API-Calls zwischen den Elementen der Cloud-Plattform. Wie Sie sehen können, bestehen selbst die zuvor benannten Dienste aus kleineren Komponenten, die miteinander interagieren. Die Erstellung einer Maschine ist nur ein kleiner Teil dessen, was die Cloud-Plattform ermöglicht â es gibt Dienste fĂŒr die Lastverteilung, fĂŒr den Blockspeicher, fĂŒr DNS, fĂŒr die Bereitstellung von Bare-Metal-Servern usw. Die Cloud erlaubt es Ihnen, Ihre virtuellen Maschinen wie eine Herde Schafe zu behandeln (im Gegensatz zur Virtualisierung). Wenn in einer virtuellen Umgebung etwas mit der Maschine passiert, stellen Sie sie aus Backups wieder her usw., sind Cloud-Anwendungen so aufgebaut, dass die virtuellen Maschinen nicht so eine wichtige Rolle spielen â wenn die virtuelle Maschine âgestorbenâ ist, ist das kein Problem â es wird einfach eine neue Maschine basierend auf einer Vorlage erstellt und, wie man so sagt, die Gruppe hat den Verlust eines KĂ€mpfers nicht bemerkt. NatĂŒrlich setzt dies das Vorhandensein von Orchestrierungsmechanismen voraus â mit Heat-Vorlagen können Sie ohne gröĂere Probleme eine komplexe Funktion bereitstellen, die aus Dutzenden von Netzwerken und virtuellen Maschinen besteht.
Es ist immer wichtig zu bedenken, dass es ohne Netzwerk keine Cloud-Infrastruktur gibt â jedes Element interagiert auf die eine oder andere Weise ĂŒber das Netzwerk mit anderen Elementen. AuĂerdem hat die Cloud ein absolut nicht statisches Netzwerk. NatĂŒrlich ist das Underlay-Netzwerk mehr oder weniger statisch â nicht jeden Tag werden neue Knoten und Switches hinzugefĂŒgt, aber die Overlay-Komponente wird sich unweigerlich stĂ€ndig Ă€ndern â es werden neue Netzwerke hinzugefĂŒgt oder alte ausgegliedert, neue virtuelle Maschinen werden erstellt und alte verschwinden. Und wie Sie sich aus der ursprĂŒnglichen Definition der Cloud erinnern, die zu Beginn des Artikels gegeben wurde â Ressourcen mĂŒssen automatisch und mit minimalem (oder besser ohne) Eingreifen des Dienstanbieters dem Benutzer zugewiesen werden. Das heiĂt, die Art der Bereitstellung von Netzwerkressourcen, wie sie jetzt in Form eines Frontends in Ihrem persönlichen Bereich ĂŒber http/https und dem Callcenter-Netzwerktechniker Alexei als Backend vorliegt â das ist keine Cloud, selbst wenn Alexei acht HĂ€nde hĂ€tte.
Neutron ist ein Netzwerkdienst, der eine API fĂŒr die Verwaltung des Netzwerkbereichs der Cloud-Infrastruktur bereitstellt. Der Dienst gewĂ€hrleistet die FunktionsfĂ€higkeit und Verwaltung des Netzwerkbereichs von OpenStack und bietet ein Abstraktionsniveau, das als Network-as-a-Service (NaaS) bezeichnet wird. Das bedeutet, dass das Netzwerk eine ebenso virtuelle, messbare Einheit ist wie zum Beispiel virtuelle CPU-Kerne oder RAM-GröĂe.
Bevor wir zur Architektur des Netzwerkbereichs von OpenStack ĂŒbergehen, betrachten wir, wie das Netzwerk in OpenStack funktioniert und warum es ein wichtiger und unverzichtbarer Bestandteil der Cloud ist.
Wir haben also zwei virtuelle Maschinen des Kunden RED und zwei virtuelle Maschinen des Kunden GREEN. Stellen wir uns vor, dass diese Maschinen auf zwei Hypervisoren folgendermaĂen angeordnet sind:
Momentan handelt es sich einfach um die Virtualisierung von vier Servern und nicht mehr, da wir bisher lediglich vier Server virtualisiert haben, die auf zwei physischen Servern verteilt sind. Zudem sind sie derzeit noch nicht mit dem Netzwerk verbunden.
Um eine Cloud zu schaffen, mĂŒssen wir einige Komponenten hinzufĂŒgen. ZunĂ€chst virtualisieren wir den Netzwerkbereich â wir mĂŒssen diese vier Maschinen paarweise verbinden, wobei die Kunden eine L2-Verbindung wĂŒnschen. Man könnte einen Switch verwenden und ihn auf Trunk einstellen sowie alles mit einem Linux-BrĂŒcke abwickeln oder, fĂŒr fortgeschrittene Benutzer, openvswitch (darauf werden wir spĂ€ter zurĂŒckkommen). Aber es könnte sehr viele Netzwerke geben, und stĂ€ndig L2 durch den Switch zu schieben ist nicht die beste Idee â unterschiedliche Abteilungen, Servicedesk, Monate Wartezeit auf die Erledigung eines Antrags, Wochen des Troubleshootings â in der modernen Welt funktioniert dieser Ansatz nicht mehr. Je frĂŒher das Unternehmen dies versteht, desto leichter wird es, voranzukommen. Daher werden wir zwischen den Hypervisoren ein L3-Netzwerk bereitstellen, ĂŒber das unsere virtuellen Maschinen miteinander kommunizieren. Auf diesem L3-Netzwerk werden wir dann virtuelle ĂŒberlagerte L2-Netzwerke (Overlay) aufbauen, ĂŒber die der Traffic unserer virtuellen Maschinen lĂ€uft. FĂŒr die Kapselung können GRE, Geneve oder VxLAN verwendet werden. Momentan bleiben wir bei Letzterem, auch wenn das nicht allzu wichtig ist.
Wir mĂŒssen irgendwo ein VTEP (ich hoffe, alle sind mit der Terminologie von VxLAN vertraut) platzieren. Da wir sofort ein L3-Netzwerk von den Servern erhalten, steht nichts im Weg, den VTEP direkt auf den Servern zu platzieren, was OVS (OpenvSwitch) hervorragend beherrscht. Am Ende haben wir eine solche Konstruktion erhalten:
Da der Verkehr zwischen den VMs getrennt werden muss, werden die Ports in Richtung der virtuellen Maschinen unterschiedliche VLAN-Nummern haben. Die Tag-Nummer spielt nur innerhalb eines virtuellen Switches eine Rolle, da wir sie bei der Kapselung in VxLAN problemlos entfernen können, da wir eine VNI haben werden.
Jetzt können wir unsere Maschinen und virtuellen Netzwerke fĂŒr sie ohne Probleme erstellen.
Was ist jedoch, wenn der Kunde eine weitere Maschine hat, die sich in einem anderen Netzwerk befindet? Wir benötigen Routing zwischen den Netzwerken. Wir betrachten eine einfache Variante, bei der zentrales Routing verwendet wird â das heiĂt, der Verkehr wird ĂŒber spezielle dedizierte Netzwerk-Knoten geroutet (normalerweise mit Control-Knoten kombiniert, also haben wir dasselbe).
Es scheint nichts Schwieriges zu sein â wir erstellen ein Bridge-Interface auf dem Control-Knoten, leiten den Verkehr dorthin und routen ihn von dort aus, wo wir ihn benötigen. Aber das Problem ist, dass der Kunde ROT das Netzwerk 10.0.0.0/24 verwenden möchte, und der Kunde GRĂN das Netzwerk 10.0.0.0/24 nutzen möchte. Das bedeutet, dass wir Ăberschneidungen der AdressrĂ€ume haben. AuĂerdem möchten die Kunden nicht, dass sich andere Kunden in ihre internen Netzwerke routen können, was auch sinnvoll ist. Um die Netzwerke und den Datenverkehr der Kunden zu trennen, werden wir fĂŒr jeden von ihnen einen eigenen Namespace zuweisen. Ein Namespace ist faktisch eine Kopie des Linux-Netzwerk-Stacks, das heiĂt, die Kunden im Namespace ROT sind vollstĂ€ndig isoliert von den Kunden im Namespace GRĂN (auĂer das Routing zwischen diesen Kunden-Netzwerken ist ĂŒber den Default-Namespace oder bereits auf der nĂ€chsthöheren Transporteinrichtung erlaubt).
Das heiĂt, wir erhalten ein solches Schema:
L2-Tunnel kommen von allen Compute-Knoten zu dem Control-Knoten, an dem sich das L3-Interface fĂŒr diese Netzwerke befindet, jedes in einem zugewiesenen Namespace zur Isolierung.
Wir haben jedoch das Wichtigste vergessen. Die virtuelle Maschine muss dem Kunden einen Service bieten, das heiĂt, sie muss mindestens eine externe Schnittstelle haben, ĂŒber die man sie erreichen kann. Das bedeutet, wir mĂŒssen in die AuĂenwelt gehen. Es gibt verschiedene Möglichkeiten. Wir werden die einfachste Variante wĂ€hlen. Wir fĂŒgen den Kunden jeweils ein Netzwerk hinzu, das im Netzwerk des Providers gĂŒltig ist und sich nicht mit anderen Netzwerken ĂŒberschneidet. Die Netzwerke können sich ebenfalls ĂŒberschneiden und auf verschiedene VRFs im Netzwerk des Providers verweisen. Diese Netzwerke werden auch im Namespace jedes Kunden existieren. Der Zugang zur AuĂenwelt erfolgt jedoch nach wie vor ĂŒber eine physische (oder besser gesagt, eine Bonding-) Schnittstelle. Um den Datenverkehr der Kunden zu trennen, wird der nach auĂen gehende Datenverkehr mit einem VLAN-Tag gekennzeichnet, der dem Kunden zugewiesen ist.
Am Ende erhielten wir folgendes Schema:
Die berechtigte Frage lautet: Warum nicht Gateways auf den Compute-Knoten selbst einrichten? Es gibt damit keine groĂen Probleme; vielmehr wird es mit aktiviertem Distributed Router (DVR) so funktionieren. In diesem Szenario betrachten wir die einfachste Variante mit einem zentralisierten Gateway, das in OpenStack standardmĂ€Ăig verwendet wird. FĂŒr hochbelastete Funktionen werden sowohl verteilter Router als auch Beschleunigungstechnologien wie SR-IOV und Passthrough verwendet, aber wie gesagt, das ist eine ganz andere Geschichte. ZunĂ€chst kĂŒmmern wir uns um den grundlegenden Teil und gehen dann zu den Details ĂŒber.
Unsere Skizze ist bereits funktionsfÀhig, es gibt jedoch einige Feinheiten:
- Wir mĂŒssen unsere Maschinen irgendwie schĂŒtzen, d. h. einen Filter an die Schnittstelle des Switches zur Client-Seite anbringen.
- Wir mĂŒssen die Möglichkeit schaffen, dass die virtuelle Maschine automatisch eine IP-Adresse erhĂ€lt, damit wir nicht jedes Mal ĂŒber die Konsole darauf zugreifen und die Adresse manuell eingeben mĂŒssen.
Beginnen wir mit dem Schutz der Maschinen. DafĂŒr können wir die einfachen iptables verwenden, warum nicht.
Das heiĂt, unsere Topologie hat sich nun etwas komplizierter gestaltet:
Lassen Sie uns weitermachen. Wir mĂŒssen einen DHCP-Server hinzufĂŒgen. Der ideale Ort fĂŒr die Platzierung der DHCP-Server fĂŒr jeden der Kunden wird die bereits erwĂ€hnte Kontrollknoten sein, an der die Namespaces untergebracht sind.
Es gibt jedoch ein kleines Problem. Was passiert, wenn alles neu gestartet wird und alle Informationen zur Adressmiete im DHCP verloren gehen? Es ist logisch, dass den Maschinen neue Adressen zugewiesen werden, was nicht besonders praktisch ist. Es gibt zwei Möglichkeiten â entweder man verwendet Domainnamen und fĂŒgt fĂŒr jeden Client einen DNS-Server hinzu, dann ist die Adresse fĂŒr uns nicht so wichtig (Ă€hnlich wie der Netzwerkteil in k8s) â aber hier gibt es ein Problem mit externen Netzwerken, da die Adressen dort ebenfalls per DHCP zugewiesen werden können â es ist eine Synchronisation zwischen den DNS-Servern auf der Cloud-Plattform und dem externen DNS-Server erforderlich, was meiner Meinung nach nicht sehr flexibel ist, aber durchaus möglich. Oder die zweite Variante â Metadaten verwenden â das heiĂt, Informationen ĂŒber die zugewiesene Adressmaschine zu speichern, damit der DHCP-Server weiĂ, welche Adresse er der Maschine zuweisen soll, wenn die Maschine bereits eine Adresse erhalten hat. Die zweite Variante ist einfacher und flexibler, da sie es ermöglicht, zusĂ€tzliche Informationen ĂŒber die Maschine zu speichern. Nun fĂŒgen wir dem Schema den Metadata-Agenten hinzu:
Eine weitere Frage, die ebenfalls beleuchtet werden sollte, ist die Möglichkeit, dass alle Clients ein und dasselbe externe Netzwerk nutzen, da externe Netzwerke, wenn sie in dem gesamten Netzwerk gĂŒltig sein sollen, kompliziert sein können â man muss diese Netzwerke stĂ€ndig zuweisen und die Zuweisung kontrollieren. Die Möglichkeit, ein einheitliches, vorgefertigtes externes Netzwerk fĂŒr alle Clients zu nutzen, wĂ€re sehr nĂŒtzlich beim Aufbau einer öffentlichen Cloud. Das wĂŒrde die Bereitstellung von Maschinen vereinfachen, da wir uns nicht mit einer Datenbank von Adressen abgleichen und einen einzigartigen Adressraum fĂŒr das externe Netzwerk jedes Clients auswĂ€hlen mĂŒssen. AuĂerdem können wir das externe Netzwerk im Voraus festlegen und zum Zeitpunkt der Bereitstellung mĂŒssen wir lediglich die externen Adressen den Client-Maschinen zuordnen.
Und hier kommt NAT ins Spiel â wir ermöglichen es den Kunden, ĂŒber den Standard-Namespace mit NAT-Ăbersetzung in die AuĂenwelt zu gelangen. Allerdings gibt es ein kleines Problem. Das funktioniert gut, wenn der Client-Server als Client und nicht als Server agiert â das heiĂt, er initiiert Verbindungen statt sie anzunehmen. Aber bei uns wird es umgekehrt sein. In diesem Fall mĂŒssen wir Destination NAT einrichten, damit die Kontrollknoten beim Erhalt des Traffics verstehen, dass dieser Traffic fĂŒr die virtuelle Maschine A des Clients A bestimmt ist, und somit eine NAT-Ăbersetzung von der externen Adresse, beispielsweise 100.1.1.1, zur internen Adresse 10.0.0.1 durchgefĂŒhrt werden muss. In diesem Fall, obwohl alle Clients dasselbe Netzwerk nutzen, bleibt die interne Isolation vollstĂ€ndig erhalten. Das heiĂt, wir mĂŒssen an der Kontrollknoten dNAT und sNAT implementieren. Die Verwendung eines einheitlichen Netzwerks mit Zuteilung von Floating-Adressen oder externen Netzwerken oder beidem gleichzeitig hĂ€ngt davon ab, was Sie in die Cloud ziehen möchten. Wir werden keine Floating-Adressen in das Schema einfĂŒgen, sondern die bereits zuvor hinzugefĂŒgten externen Netzwerke beibehalten â jeder Kunde hat sein eigenes externes Netzwerk (im Schema als VLAN 100 und 200 am externen Interface gekennzeichnet).
Insgesamt haben wir eine interessante und gleichzeitig durchdachte Lösung erzielt, die ĂŒber eine gewisse FlexibilitĂ€t verfĂŒgt, jedoch bisher keine Mechanismen zur Fehlertoleranz aufweist.
Erstens haben wir nur einen Kontrollknoten â dessen Ausfall wĂŒrde zu einem Zusammenbruch aller Systeme fĂŒhren. Um dieses Problem zu lösen, mĂŒssen wir mindestens ein Quorum aus drei Knoten bilden. Lassen Sie uns das ins Schema einfĂŒgen:
NatĂŒrlich synchronisieren sich alle Knoten, und bei Ausfall der aktiven Knoten ĂŒbernimmt eine andere Knoten deren Aufgaben.
Das nĂ€chste Problem sind die Festplatten der virtuellen Maschinen. Momentan sind sie auf den Hypervisoren gespeichert, und bei Problemen mit dem Hypervisor verlieren wir alle Daten â und ein RAID hilft hier nicht, wenn wir nicht nur eine Festplatte, sondern den gesamten Server verlieren. DafĂŒr mĂŒssen wir einen Dienst einrichten, der als Frontend fĂŒr irgendeinen Speicher dient. Welcher Speicher es sein wird, ist uns nicht besonders wichtig, aber er sollte unsere Daten vor dem Ausfall sowohl der Festplatte als auch des Nodes, eventuell sogar des gesamten Schranks, schĂŒtzen. Hier gibt es mehrere Optionen â es gibt natĂŒrlich SAN-Netzwerke mit Fibre Channel, aber um ehrlich zu sein â FC ist bereits ein Relikt der Vergangenheit â das Ăquivalent zu E1 im Transport â ja, ich stimme zu, es wird noch verwendet, aber nur dort, wo es einfach nicht anders geht. Daher wĂŒrde ich 2020 nicht freiwillig ein FC-Netzwerk aufbauen, da es andere interessantere Alternativen gibt. Obwohl jeder seine Meinung hat und es vielleicht Leute gibt, die glauben, dass FC mit all seinen EinschrĂ€nkungen alles ist, was wir brauchen â ich werde nicht streiten, jeder hat seine eigene Auffassung. Dennoch halte ich die Verwendung von SDS, zum Beispiel Ceph, fĂŒr die interessanteste Lösung.
Ceph ermöglicht die Erstellung einer hochverfĂŒgbaren Lösung zur Datenspeicherung mit vielen verschiedenen Sicherungsoptionen, beginnend mit ParitĂ€tsprĂŒfcodes (analog zu RAID 5 oder 6), bis hin zu vollstĂ€ndiger Datenreplikation auf verschiedene Festplatten unter BerĂŒcksichtigung der Lage der Festplatten in den Servern und der Server in den SchrĂ€nken usw.
FĂŒr den Aufbau von Ceph werden noch 3 Nodes benötigt. Die Interaktion mit dem Speicher erfolgt ebenfalls ĂŒber das Netzwerk unter Verwendung von Diensten fĂŒr blockbasiertes, objektbasiertes und Dateispeichern. FĂŒgen wir dem Schema den Speicher hinzu:
Hinweis: Hyperkonvergente Compute-Knoten sind ebenfalls möglich â dies ist das Konzept, mehrere Funktionen auf einem Knoten zu vereinen â zum Beispiel Storage+Compute â ohne spezielle Knoten fĂŒr Ceph-Storage zuzuweisen. Wir erhalten ein ebenso fehlertolerantes Setup, da SDS die Daten mit dem von uns angegebenen Reservierungsgrad sichert. Hyperkonvergente Knoten sind jedoch immer ein Kompromiss â da der Storage-Knoten nicht nur die Luft heizt, wie es auf den ersten Blick scheint (da keine virtuellen Maschinen auf ihm laufen) â er verbraucht CPU-Ressourcen fĂŒr die Verwaltung von SDS (tatsĂ€chlich fĂŒhrt er im Hintergrund alle Replikationen, Wiederherstellungen nach Knoten- und FestplattenausfĂ€llen usw. durch). Das heiĂt, Sie verlieren einen Teil der Leistung des Compute-Knotens, wenn Sie ihn mit Storage kombinieren.
All diese Ressourcen mĂŒssen irgendwie verwaltet werden â wir brauchen etwas, ĂŒber das wir Maschinen, Netzwerke, virtuelle Router usw. erstellen können. DafĂŒr fĂŒgen wir auf dem Steuerknoten einen Dienst hinzu, der die Rolle eines Dashboards ĂŒbernimmt â der Client kann sich ĂŒber http/https mit diesem Portal verbinden und alles tun, was er benötigt (na ja, fast alles).
SchlieĂlich haben wir jetzt ein fehlertolerantes System. Alle Elemente dieser Infrastruktur mĂŒssen irgendwie verwaltet werden. Zuvor wurde beschrieben, dass OpenStack eine Sammlung von Projekten ist, von denen jedes eine bestimmte Funktion bereitstellt. Wie wir sehen, gibt es mehr als genug Elemente, die konfiguriert und ĂŒberwacht werden mĂŒssen. Heute werden wir ĂŒber den Netzwerkbereich sprechen.
Neutron-Architektur
In OpenStack ist Neutron verantwortlich fĂŒr den Anschluss von Ports virtueller Maschinen an das gemeinsame L2-Netzwerk, die Bereitstellung der Datenverkehrsroute zwischen VMs in verschiedenen L2-Netzwerken sowie die externe RoutenfĂŒhrung und Dienstleistungen wie NAT, Floating IP, DHCP usw.
Die hochgradige Funktion des Netzwerksdienstes (Basisfunktion) kann wie folgt beschrieben werden.
Bei der Bereitstellung einer VM erledigt der Netzwerkdienst:
- Er erstellt einen Port fĂŒr diese VM (oder Ports) und benachrichtigt den DHCP-Dienst darĂŒber;
- Ein neues virtuelles NetzwerkgerĂ€t wird erstellt (ĂŒber libvirt);
- Die VM wird mit dem im ersten Schritt erstellten Port (Ports) verbunden;
Es mag seltsam erscheinen, aber die Funktionsweise von Neutron basiert auf standardmĂ€Ăigen Mechanismen, die allen bekannt sind, die jemals in Linux eingetaucht sind â das sind Namespaces, iptables, Linux-Bridges, Open vSwitch, conntrack usw.
Es sollte sofort klargestellt werden, dass Neutron kein SDN-Controller ist.
Neutron besteht aus mehreren miteinander verbundenen Komponenten:
Openstack-neutron-server â dies ist ein DĂ€mon, der ĂŒber die API mit Benutzeranfragen arbeitet. Dieser DĂ€mon beschĂ€ftigt sich nicht mit der Definition von Netzwerkkonfigurationen, sondern liefert die dafĂŒr erforderlichen Informationen an seine Plugins, die dann das benötigte Netzwerkelement konfigurieren. Neutron-Agenten auf den Knoten von OpenStack werden beim Neutron-Server registriert.
Der Neutron-Server ist im Grunde genommen eine Anwendung, die in Python geschrieben ist und aus zwei Teilen besteht:
- REST-Dienst
- Neutron-Plugin (core/service)
Der REST-Dienst ist zum Empfang von API-Aufrufen von anderen Komponenten vorgesehen (zum Beispiel Anfragen zur Bereitstellung von Informationen usw.).
Plugins sind anpassbare Softwarekomponenten/module, die bei API-Anfragen aufgerufen werden â das heiĂt, die Zuweisung eines bestimmten Dienstes erfolgt ĂŒber sie. Plugins werden in zwei Typen unterteilt â Dienst- und Kern-Plugins. In der Regel ist das Kern-Plugin hauptsĂ€chlich fĂŒr die Verwaltung des Adressraums und der L2-Verbindungen zwischen VMs verantwortlich, wĂ€hrend die Dienst-Plugins zusĂ€tzliche Funktionen wie VPN oder FW bereitstellen.
Die Liste der heute verfĂŒgbaren Plugins kann beispielsweise hier eingesehen werden:
Es kann mehrere Dienst-Plugins geben, jedoch nur ein Kern-Plugin.
Openstack-neutron-ml2 â ist das standardmĂ€Ăige Kern-Plugin von Openstack. Dieses Plugin hat eine modulare Architektur (im Gegensatz zu seinem VorgĂ€nger) und konfiguriert den Netzwerkdienst ĂŒber angeschlossene Treiber. Wir werden das Plugin spĂ€ter nĂ€her betrachten, da es tatsĂ€chlich die FlexibilitĂ€t bietet, ĂŒber die OpenStack im Netzwerkbereich verfĂŒgt. Das Kern-Plugin kann ersetzt werden (zum Beispiel fĂŒhrt Contrail Networking einen solchen Austausch durch).
RPC-Dienst (rabbitmq-server) â ist ein Dienst, der das Management von Warteschlangen und die Interaktion mit anderen OpenStack-Diensten sowie die Interaktion zwischen den Agenten des Netzwerkdienstes gewĂ€hrleistet.
Netzwerkagenten â sind Agenten, die in jedem Knoten platziert sind und ĂŒber die die Konfiguration der Netzwerkdienste erfolgt.
Es gibt mehrere Arten von Agenten.
Der Hauptagent ist der L2-Agent.. Diese Agenten werden auf jedem Hypervisor, einschlieĂlich der Kontrollknoten (genauer gesagt auf allen Knoten, die irgendeinen Service fĂŒr die Tenants bereitstellen), gestartet. Ihre Hauptfunktion besteht darin, virtuelle Maschinen mit dem gemeinsamen L2-Netzwerk zu verbinden und Benachrichtigungen zu generieren, wenn irgendwelche Ereignisse auftreten (zum Beispiel bei Deaktivierung/Aktivierung eines Ports).
Der nĂ€chste, nicht weniger wichtige Agent ist L3-Agent. StandardmĂ€Ăig wird dieser Agent ausschlieĂlich auf dem Netzwerk-Knoten gestartet (hĂ€ufig wird der Netzwerk-Knoten mit dem Kontrollknoten kombiniert) und sorgt fĂŒr die Routing-Funktion zwischen den Netzwerken der Tenants (sowohl zwischen deren Netzwerken als auch den Netzwerken anderer Tenants, und er ist auch fĂŒr die externe Welt verfĂŒgbar, indem er NAT und auch den DHCP-Service bereitstellt). Bei der Verwendung von DVR (Distributed Virtual Router) entsteht jedoch auch auf den Compute-Knoten die Notwendigkeit eines L3-Plugins.
Der L3-Agent verwendet Linux-Namespace, um jedem Tenant eine eigene isolierte Netzwerkinfrastruktur und die FunktionalitĂ€t virtueller Router bereitzustellen, die den Datenverkehr routieren und Gateway-Dienste fĂŒr Layer-2-Netzwerke anbieten.
Datenbank â eine Datenbank von Identifikatoren fĂŒr Netzwerke, Subnetze, Ports, Pools usw.
TatsĂ€chlich akzeptiert Neutron API-Anfragen zur Erstellung irgendetwas von Netzwerkinfrastrukturen, authentifiziert die Anfrage und ĂŒbertrĂ€gt ĂŒber RPC (wenn sie sich an ein Plugin oder einen Agenten wendet) oder REST-API (wenn sie mit SDN kommuniziert) den Agenten (ĂŒber Plugins) die erforderlichen Anweisungen zur Bereitstellung des angeforderten Dienstes.
Jetzt wenden wir uns der Testinstallation zu (wie sie eingerichtet ist und was sie umfasst, sehen wir spÀter im praktischen Teil) und schauen, wo sich welche Komponente befindet:
(overcloud) [stack@undercloud ~]$ openstack netzwerkanbieter auflisten
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Typ | Host | VerfĂŒgbarkeitszone | Aktiv | Status| Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch Agent | overcloud-novacompute-1.localdomain | Keine | :-) | Hoch | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3-Agent | overcloud-controller-0.localdomain | nova | :-) | Hoch | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP-Agent | overcloud-controller-0.localdomain | nova | :-) | Hoch | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch Agent | overcloud-novacompute-0.localdomain | Keine | :-) | Hoch | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch Agent | overcloud-controller-0.localdomain | Keine | :-) | Hoch | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadaten-Agent | overcloud-controller-0.localdomain | Keine | :-) | Hoch | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Das ist tatsÀchlich die gesamte Struktur von Neutron. Jetzt sollten wir etwas Zeit dem ML2-Plugin widmen.
Modular Layer 2
Wie bereits erwÀhnt, ist das Plugin der Standard-Wurzel-Plugin von OpenStack und hat eine modulare Architektur.
Der VorgĂ€nger des ML2-Plugins hatte eine monolithische Struktur, die es zum Beispiel nicht erlaubte, mehrere Technologien in einer Installation zu mischen. Beispielsweise konnten Sie Open vSwitch und Linuxbridge nicht gleichzeitig verwenden â entweder das eine oder das andere. Aus diesem Grund wurde das ML2-Plugin mit seiner Architektur entwickelt.
ML2 hat zwei Komponenten â zwei Arten von Treibern: Typ-Treiber und Mechanismus-Treiber.
Typ-Treiber definieren die Technologien, die verwendet werden, um Netzwerkverbindungen zu organisieren, wie VxLAN, VLAN, GRE. Dabei ermöglicht der Treiber die Verwendung unterschiedlicher Technologien. Die Standardtechnologie ist die VxLAN-Kapselung fĂŒr Overlay-Netzwerke und VLAN fĂŒr externe Netzwerke.
Zu den Typ-Treibern gehören die folgenden Netztypen:
Flat â ungetaggtes Netzwerk
VLAN â getaggtes Netzwerk
Local â spezieller Netzwerktyp fĂŒr All-in-One-Installationen (solche Installationen sind entweder fĂŒr Entwickler oder fĂŒr Schulungszwecke notwendig)
GRE â Overlay-Netzwerk, das GRE-Tunnel verwendet
VxLAN â Overlay-Netzwerk, das VxLAN-Tunnel verwendet
Mechanismus-Treiber bestimmen die Mittel, die die Organisation der im type driver angegebenen Technologien sicherstellen â zum Beispiel openvswitch, sr-iov, opendaylight, OVN usw.
Je nach Umsetzung dieses Treibers werden entweder von Neutron verwaltete Agenten verwendet oder es werden Verbindungen zu einem externen SDN-Controller genutzt, der alle Fragen zur Organisation von L2-Netzen, Routing usw. ĂŒbernimmt.
Ein Beispiel: Wenn wir ML2 zusammen mit OVS verwenden, wird auf jedem Rechenknoten ein L2-Agent installiert, der OVS verwaltet. Wenn wir jedoch beispielsweise OVN oder OpenDayLight verwenden, geht die Verwaltung von OVS in deren ZustĂ€ndigkeitsbereich ĂŒber â Neutron gibt ĂŒber das Root-Plugin Befehle an den Controller, und dieser fĂŒhrt die ihm gegebenen Anweisungen aus.
Erinnern wir uns an Open vSwitch
Derzeit ist Open vSwitch eine der SchlĂŒsselkomponenten von OpenStack.
Beim Installieren von OpenStack ohne zusÀtzliche vendor-spezifische SDNs wie Juniper Contrail oder Nokia Nuage ist OVS die Hauptnetzwerkkomponente des Cloudnetzwerks und ermöglicht in Kombination mit iptables, conntrack und Namespaces die Schaffung eines vollwertigen Overlay-Netzes mit Multi-Tenancy. SelbstverstÀndlich kann diese Komponente durch andere proprietÀre (vendor-spezifische) SDN-Lösungen ersetzt werden.
OVS ist ein Open-Source-Software-Switch, der fĂŒr den Einsatz in virtualisierten Umgebungen als virtueller Traffic-Forwarder entwickelt wurde.
Derzeit verfĂŒgt OVS ĂŒber eine sehr gute FunktionalitĂ€t, zu der Technologien wie QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK usw. gehören.
Hinweis: UrsprĂŒnglich wurde OVS nicht als Software-Switch fĂŒr stark belastete Telekommunikationsfunktionen konzipiert und war eher fĂŒr weniger anspruchsvolle IT-Funktionen wie Web- oder Mailserver ausgelegt. OVS wird jedoch weiterentwickelt, und die aktuellen Umsetzungen von OVS haben die Leistung und Möglichkeiten stark verbessert, sodass er von Telekommunikationsanbietern mit stark belasteten Funktionen genutzt werden kann; beispielsweise gibt es eine OVS-Implementierung mit DPDK-BeschleunigungsunterstĂŒtzung.
Es gibt drei wichtige Komponenten von OVS, die Sie kennen sollten:
- Kernel-Modul â eine Komponente, die im Kernel-Space angesiedelt ist und den Verkehr auf der Grundlage der vom Steuerungselement erhaltenen Regeln verarbeitet;
- vSwitch Der Daemon (ovs-vswitchd) ist ein Prozess, der im User Space ausgefĂŒhrt wird und fĂŒr die Programmierung des Kernelmoduls verantwortlich ist â das bedeutet, dass er direkt die Logik des Switches reprĂ€sentiert.
- Datenbankserver eine lokale Datenbank, die auf jedem Host, auf dem OVS ausgefĂŒhrt wird, gespeichert ist und die Konfiguration speichert. Ăber dieses Modul können SDN-Controller ĂŒber das OVSDB-Protokoll kommunizieren.
DarĂŒber hinaus wird eine Reihe von Diagnose- und Verwaltungswerkzeugen geliefert, wie ovs-vsctl, ovs-appctl, ovs-ofctl usw.
Derzeit wird OpenStack umfassend von Telekommunikationsanbietern genutzt, um Netzwerkfunktionen wie EPC, SBC, HLR usw. zu migrieren. Einige Funktionen können problemlos mit OVS in seiner jetzigen Form leben, aber beispielsweise verarbeitet EPC den Datenverkehr von Benutzern â das bedeutet, dass er eine enorme Datenmenge durchlĂ€sst (derzeit erreichen die Datenmengen mehrere Hundert Gigabit pro Sekunde). Es ist natĂŒrlich keine gute Idee, diesen Datenverkehr durch den Kernel Space zu leiten (da der Forwarder standardmĂ€Ăig dort angesiedelt ist). Daher wird OVS hĂ€ufig vollstĂ€ndig im User Space mit der DPDK-Beschleunigungstechnologie implementiert, um den Datenverkehr von der NIC in den User Space zu leiten, ohne den Kernel zu verwenden.
Hinweis: FĂŒr eine Cloud, die fĂŒr Telekommunikationsfunktionen bereitgestellt wird, besteht die Möglichkeit, den Datenverkehr direkt von der Compute-Node ohne OVS in die Switching-Hardware zu leiten. FĂŒr diesen Zweck werden die Mechanismen SR-IOV und Passthrough verwendet.
Wie funktioniert das in einem realen Modell?
Nun, jetzt kommen wir zum praktischen Teil und schauen uns an, wie das alles in der Praxis funktioniert.
ZunĂ€chst werden wir eine einfache OpenStack-Installation aufbauen. Da ich zur DurchfĂŒhrung von Experimenten kein Server-Set zur VerfĂŒgung habe, werden wir das Modell auf einem physischen Server mit virtuellen Maschinen aufbauen. Ja, natĂŒrlich ist diese Lösung fĂŒr kommerzielle Zwecke nicht geeignet, aber um zu sehen, wie das Netzwerk in einer OpenStack-Installation funktioniert, reicht es vollkommen aus. AuĂerdem ist eine solche Installation fĂŒr Schulungszwecke sogar interessanter â da man den Datenverkehr verfolgen kann usw.
Da wir nur den grundlegenden Teil sehen möchten, können wir mehrere Netzwerke weglassen und alles mit nur zwei Netzwerken aufbauen, wobei das zweite Netzwerk in diesem Modell ausschlieĂlich fĂŒr den Zugriff auf den Undercloud und den DNS-Server verwendet wird. Externe Netzwerke werden wir vorerst nicht behandeln â das ist ein Thema fĂŒr einen eigenen, umfangreichen Artikel.
Lassen Sie uns also der Reihe nach beginnen. ZunĂ€chst ein wenig Theorie. Wir werden OpenStack mit Hilfe von TripleO (OpenStack auf OpenStack) installieren. Der Kern von TripleO ist, dass wir OpenStack als All-in-One (das heiĂt auf einem Knoten) installieren, genannt Undercloud, und dann die Möglichkeiten des bereitgestellten OpenStacks nutzen, um OpenStack zu installieren, das fĂŒr den Betrieb vorgesehen ist, genannt Overcloud. Undercloud wird die in ihm integrierte FĂ€higkeit nutzen, physische Server (Bare Metal) zu verwalten â das Projekt Ironic â um Hypervisoren bereitzustellen, die die Rollen von Compute-, Control-, und Storage-Knoten ĂŒbernehmen. Das heiĂt, wir verwenden keine externen Mittel zur Bereitstellung von OpenStack â wir implementieren OpenStack mit Mitteln von OpenStack. Im Verlauf der Installation wird alles viel klarer werden, also lassen Sie uns nicht auf diesem Punkt verweilen und vorankommen.
Hinweis: In diesem Artikel habe ich zum Zweck der Vereinfachung keine Netzwerkisolierung fĂŒr die internen Netzwerke von OpenStack verwendet und alles mit nur einem Netzwerk implementiert. Das Vorhandensein oder Fehlen von Netzwerkisolierung hat jedoch keinen Einfluss auf die grundlegende FunktionalitĂ€t der Lösung â alles wird genau so funktionieren, wie es bei der Verwendung von Isolierung der Fall ist, aber der Datenverkehr wird in einem Netzwerk laufen. FĂŒr eine kommerzielle Installation ist es natĂŒrlich notwendig, Isolierung mit unterschiedlichen VLANs und Schnittstellen zu verwenden. Zum Beispiel verwenden der Verwaltungsdatenverkehr von Ceph-Speicher und der Datenverkehr von Maschinen zu den Festplatten (usw.) bei Isolierung unterschiedliche Subnetze (Storage Management und Storage), was es ermöglicht, die Lösung fehlertoleranter zu gestalten, indem dieser Datenverkehr beispielsweise auf unterschiedliche Ports aufgeteilt wird oder unterschiedliche QoS-Profile fĂŒr unterschiedliche Datenströme verwendet werden, um zu verhindern, dass Datenverkehr das Signal ĂŒberlagert. In unserem Fall werden sie jedoch im selben Netzwerk laufen, was uns faktisch nicht einschrĂ€nkt.
Hinweis: Da wir vorhaben, virtuelle Maschinen in einer virtuellen Umgebung zu betreiben, die auf virtuellen Maschinen basiert, mĂŒssen wir zunĂ€chst die Nested-Virtualisierung aktivieren.
So können Sie ĂŒberprĂŒfen, ob die Nested-Virtualisierung aktiviert ist oder nicht:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Wenn Sie den Buchstaben N sehen, aktivieren Sie die UnterstĂŒtzung der Nested-Virtualisierung gemÀà irgendeinem Leitfaden, den Sie im Internet finden, zum Beispiel .
Wir mĂŒssen ein solches Schema aus virtuellen Maschinen zusammenstellen:
In meinem Fall habe ich fĂŒr die Vernetzung der virtuellen Maschinen, die Teil der zukĂŒnftigen Installation sind (ich habe insgesamt 7, aber Sie können auch mit 4 auskommen, wenn Sie nicht viele Ressourcen haben), OpenvSwitch verwendet. Ich habe einen OVS-BrĂŒcke erstellt und die virtuellen Maschinen ĂŒber Port-Gruppen angeschlossen. Dazu habe ich eine XML-Datei folgender Art erstellt:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Hier sind drei Portgruppen deklariert â zwei Access und eine Trunk (die letzte wurde fĂŒr den DNS-Server benötigt, aber man kann auch darauf verzichten oder ihn auf der Host-Maschine einrichten â es bleibt Ihnen ĂŒberlassen, was fĂŒr Sie am praktischsten ist). Weiterhin definieren wir unser Netzwerk mit diesem Template ĂŒber virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Jetzt bearbeiten wir die Konfigurationen der Ports des Hypervisors:
[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 ~]# Hinweis: In diesem Szenario wird die Adresse am Port ovs-br1 nicht verfĂŒgbar sein, da sie kein VLAN-Tag hat. Um dies zu korrigieren, muss der Befehl sudo ovs-vsctl set port ovs-br1 tag=100 ausgefĂŒhrt werden. Allerdings wird dieses Tag nach einem Neustart verschwinden (wenn jemand weiĂ, wie man es dauerhaft macht â ich wĂ€re sehr dankbar). Aber das ist nicht so wichtig, da wir diese Adresse nur wĂ€hrend der Installation benötigen und sie nicht mehr benötigt wird, wenn OpenStack vollstĂ€ndig bereitgestellt ist.
Als nÀchstes erstellen wir die Undercloud-Maschine:
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=ttyS0Bei der Installation stellen Sie alle erforderlichen Parameter ein, wie z. B. den Namen der Maschine, Passwörter, Benutzer, NTP-Server usw. Es ist auch möglich, die Ports sofort zu konfigurieren, aber persönlich ist es fĂŒr mich einfacher, nach der Installation ĂŒber die Konsole auf die Maschine zuzugreifen und die benötigten Dateien anzupassen. Wenn Sie bereits ein fertiges Image haben, können Sie dieses verwenden oder es wie ich machen â das minimale Image von Centos 7 herunterladen und es zur Installation der VM nutzen.
Nach erfolgreicher Installation sollte eine virtuelle Maschine erscheinen, auf der Sie untercloud installieren können.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningZuerst installieren wir die notwendigen Werkzeuge fĂŒr den Installationsprozess:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installation von Undercloud
Wir erstellen den Benutzer stack, setzen ein Passwort, fĂŒgen ihn zu den sudoers hinzu und ermöglichen ihm, Root-Befehle ĂŒber sudo ohne Eingabe eines Passworts auszufĂŒhren:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackJetzt geben wir im Hosts-Datei den vollstÀndigen Namen von undercloud an:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6AnschlieĂend fĂŒgen wir die Repositories hinzu und installieren die benötigte Software:
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-ansibleHinweis: Wenn Sie nicht planen, Ceph zu installieren, mĂŒssen Sie die Befehle, die sich auf Ceph beziehen, nicht eingeben. Ich habe die Queens-Version verwendet, aber Sie können jede andere verwenden, die Ihnen gefĂ€llt.
AnschlieĂend kopieren wir die Konfigurationsdatei von undercloud in das Home-Verzeichnis des Benutzers stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confJetzt mĂŒssen wir diese Datei anpassen, um sie an unsere Installation anzupassen.
Am Anfang der Datei mĂŒssen folgende Zeilen hinzugefĂŒgt werden:
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 = 10Lassen Sie uns also die Einstellungen durchgehen:
undercloud_hostname â der vollstĂ€ndige Name des undercloud-Servers, sollte mit dem Eintrag auf dem DNS-Server ĂŒbereinstimmen.
local_ip â lokale Adresse des Undercloud in Richtung des Provisioning-Netzwerks
network_gateway â dieselbe lokale Adresse, die als Gateway fĂŒr den Zugriff auf die AuĂenwelt wĂ€hrend der Installation der Overcloud-Nodes fungiert, stimmt ebenfalls mit der lokalen IP ĂŒberein
undercloud_public_host â Adresse der externen API, kann jede freie Adresse aus dem Provisioning-Netzwerk zugewiesen werden
undercloud_admin_host Adresse der internen API, kann jede freie Adresse aus dem Provisioning-Netzwerk zugewiesen werden
undercloud_nameservers â DNS-Server
generate_service_certificate â diese Zeile ist in diesem Beispiel sehr wichtig, da Sie andernfalls bei der Installation einen Fehler erhalten, das Problem ist im Bugtracker von Red Hat beschrieben
local_interface Schnittstelle im Provisioning-Netzwerk. Diese Schnittstelle wird wĂ€hrend des Rollouts der Undercloud neu konfiguriert, daher muss die Undercloud ĂŒber zwei Schnittstellen verfĂŒgen â eine fĂŒr den Zugriff auf sie, die andere fĂŒr das Provisioning
local_mtu â MTU. Da wir ein Testlabor haben und die MTU bei meinen OVS-Switch-Ports 1500 betrĂ€gt, muss sie auf 1450 eingestellt werden, damit die in VxLAN eingekapselten Pakete durchkommen.
network_cidr â Provisioning-Netzwerk
masquerade â Verwendung von NAT fĂŒr den Zugriff auf das externe Netzwerk
masquerade_network â Netzwerk, das NAT-ed wird
dhcp_start â Startadresse des Pools, aus dem Adressen wĂ€hrend der Bereitstellung der Overcloud an die Nodes zugewiesen werden
dhcp_end â Endadresse des Pools, aus dem Adressen wĂ€hrend der Bereitstellung der Overcloud an die Nodes zugewiesen werden
inspection_iprange â Adresspool, der fĂŒr die DurchfĂŒhrung von Introspektionen benötigt wird (darf sich nicht mit dem oben genannten Pool ĂŒberschneiden)
scheduler_max_attempts â maximale Anzahl der Versuche zur Installation der Overcloud (sollte gröĂer oder gleich der Anzahl der Nodes sein)
Nachdem die Datei beschrieben wurde, können Sie den Befehl zum Deployen der Undercloud ausfĂŒhren:
openstack undercloud install
Der Vorgang dauert je nach Hardware zwischen 10 und 30 Minuten. Am Ende sollten Sie folgende Ausgabe sehen:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud-Installation abgeschlossen.
Die Datei mit den Passwörtern dieser Installation befindet sich unter
/home/stack/undercloud-passwords.conf.
Es gibt auch eine stackrc-Datei unter /home/stack/stackrc.
Diese Dateien sind erforderlich, um mit den OpenStack-Diensten zu interagieren, und sollten
gesichert werden.
#############################################################################Diese Ausgabe zeigt, dass Sie die Undercloud erfolgreich installiert haben und jetzt den Status der Undercloud ĂŒberprĂŒfen und mit der Installation der Overcloud fortfahren können.
Wenn Sie die Ausgabe von ifconfig betrachten, werden Sie sehen, dass eine neue Bridge-Schnittstelle erschienen ist.
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 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
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Ăber dieses Interface wird jetzt die Arbeit am Deployment des Overclouds durchgefĂŒhrt.
Aus der folgenden Ausgabe ist ersichtlich, dass alle Dienste auf einem Knoten laufen:
(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 |
+--------------------------+-----------+----------+Nachfolgend ist die Konfiguration des Netzwerks der Undercloud dargestellt:
(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 des Overclouds
Momentan haben wir nur die Undercloud, und uns fehlen die Knoten, aus denen der Overcloud zusammengesetzt wird. Deshalb werden wir zunĂ€chst die benötigten virtuellen Maschinen bereitstellen. WĂ€hrend des Deployments wird die Undercloud das Betriebssystem und die notwendige Software auf den Overcloud-Maschinen installieren â das bedeutet, dass wir die Maschine nicht vollstĂ€ndig einrichten mĂŒssen, sondern lediglich eine oder mehrere Festplatten erstellen und ihre Parameter definieren â also erhalten wir faktisch einen nackten Server ohne installierte Betriebssysteme.
Wechseln wir in das Verzeichnis der Festplatten unserer virtuellen Maschinen und erstellen die benötigten Festplatten:
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 160GDa wir als Root handeln, mĂŒssen wir den Besitzer dieser Festplatten Ă€ndern, um Probleme mit den Rechten zu vermeiden:
[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]# Hinweis: Wenn Sie Ceph nicht zum Lernen installieren möchten, erstellen Sie mindestens 3 Knoten mit mindestens zwei Festplatten und geben Sie im Template an, dass virtuelle Festplatten vda, vdb usw. verwendet werden.
Gut, jetzt mĂŒssen wir all diese Maschinen definieren:
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 Am Ende gibt es die Befehle âprint-xml > /tmp/storage-1.xml, die eine XML-Datei mit der Beschreibung jeder Maschine im Ordner /tmp/ erzeugen. Wenn Sie das nicht hinzufĂŒgen, können Sie die virtuellen Maschinen nicht definieren.
Jetzt mĂŒssen wir all diese Maschinen in virsh definieren:
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 Zustand
----------------------------------------------------
6 dns-server lÀuft
64 undercloud lÀuft
- compute-1 ausgeschaltet
- compute-2 ausgeschaltet
- control-1 ausgeschaltet
- storage-1 ausgeschaltet
- storage-2 ausgeschaltet
[root@hp-gen9 ~]#Jetzt ein kleiner Hinweis â tripleO verwendet IPMI, um die Server wĂ€hrend der Installation und Introspektion zu verwalten.
Die Introspektion ist der Prozess der Inspektion der Hardware, um ihre Parameter zu erhalten, die fĂŒr die weitere Provisionierung der Knoten erforderlich sind. Die Introspektion erfolgt mithilfe von ironic â einem Dienst, der fĂŒr die Arbeit mit Bare-Metal-Servern entwickelt wurde.
Hier ist allerdings das Problem â wĂ€hrend IPMI bei physischen Servern einen separaten Port (oder einen gemeinsamen Port, was nicht entscheidend ist) hat, haben virtuelle Maschinen solche Ports nicht. Hier kommt ein workaround namens vbmc ins Spiel â ein Tool, das es ermöglicht, einen IPMI-Port zu emulieren. Auf diesen Aspekt sollte man besonders achten, wenn man ein solches Labor auf dem ESXi-Hypervisor einrichten möchte â ich weiĂ ehrlich gesagt nicht, ob es darin eine Entsprechung zu vbmc gibt, daher sollte man sich vor der vollstĂ€ndigen Bereitstellung Gedanken darĂŒber machen.
Wir installieren vbmc:
yum install python2-virtualbmcWenn Ihr Betriebssystem das Paket nicht finden kann, fĂŒgen Sie das Repository hinzu:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmJetzt konfigurieren wir das Tool. Es ist alles ganz einfach. Derzeit ist es logisch, dass in der vbmc-Liste keine Server vorhanden sind.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Um sie erscheinen zu lassen, mĂŒssen sie manuell wie folgt deklariert werden:
[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
+-------------+--------+---------+------+
| Domainname | Status | Adresse | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Ich denke, die Syntax des Befehls ist ohne ErklĂ€rungen verstĂ€ndlich. Aktuell sind jedoch alle unsere Sitzungen im Status DOWN. Um sie in den Status UP zu versetzen, mĂŒssen sie eingeschaltet werden:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] vBMC-Instanz fĂŒr das Domain control-1 gestartet
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] vBMC-Instanz fĂŒr das Domain storage-1 gestartet
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] vBMC-Instanz fĂŒr das Domain storage-2 gestartet
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] vBMC-Instanz fĂŒr das Domain compute-1 gestartet
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] vBMC-Instanz fĂŒr das Domain compute-2 gestartet
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | lÀuft | :: | 7004 |
| compute-2 | lÀuft | :: | 7005 |
| control-1 | lÀuft | :: | 7001 |
| storage-1 | lÀuft | :: | 7002 |
| storage-2 | lÀuft | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Und der letzte Schliff â die Firewall-Regeln mĂŒssen angepasst werden (oder sie ganz deaktiviert werden):
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
Jetzt gehen wir zur undercloud und prĂŒfen, ob alles funktioniert. Die Adresse des Hostsystems ist 192.168.255.200, auf der undercloud haben wir wĂ€hrend der Vorbereitungen fĂŒr das Deployment das notwendige Paket ipmitool hinzugefĂŒgt:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis-Strom ist aus
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis-Stromsteuerung: Hoch/Eins
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name Status
----------------------------------------------------
6 dns-server lÀuft
64 undercloud lÀuft
65 control-1 lĂ€uftWie Sie sehen, haben wir die Control-Node erfolgreich ĂŒber vbmc gestartet. Jetzt schalten wir sie aus und machen weiter:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis-Stromsteuerung: Niedrig/Aus
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis-Strom ist aus
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name Status
----------------------------------------------------
6 dns-server lÀuft
64 undercloud lÀuft
- compute-1 ausgeschaltet
- compute-2 ausgeschaltet
- control-1 ausgeschaltet
- storage-1 ausgeschaltet
- storage-2 ausgeschaltet
[root@hp-gen9 ~]#Der nĂ€chste Schritt besteht darin, die Nodes zu inspizieren, auf denen das Overcloud installiert werden soll. Dazu mĂŒssen wir eine JSON-Datei mit einer Beschreibung unserer Nodes vorbereiten. Beachten Sie, dass im Gegensatz zur Installation auf nackten Servern in der Datei der Port angegeben ist, auf dem vbmc fĂŒr jede der Maschinen lĂ€uft.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
- netzwerk ovs-network-1 virtio 52:54:00:20:a2:2f
- netzwerk ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
- netzwerk ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
- netzwerk ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
- netzwerk ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
- netzwerk ovs-network-1 virtio 52:54:00:a7:fe:27Hinweis: Auf dem Kontrollknoten gibt es zwei Schnittstellen, aber in diesem Fall ist das unwichtig; in dieser Installation reicht uns eine.
Jetzt bereiten wir die JSON-Datei vor. Wir mĂŒssen die MAC-Adresse des Ports angeben, ĂŒber den das Provisioning erfolgt, die Knotendaten festlegen, Namen zuweisen und angeben, wie man auf das IPMI zugreift:
{
"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"
}
]
}Jetzt mĂŒssen wir die Images fĂŒr Ironic vorbereiten. Dazu laden wir sie ĂŒber wget herunter und installieren sie:
(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 ~]$Laden der Images in den Undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Bild "overcloud-full-vmlinuz" wurde hochgeladen.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | GröĂe | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktiv |
+--------------------------------------+------------------------+-------------+---------+--------+
Bild "overcloud-full-initrd" wurde hochgeladen.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | GröĂe | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktiv |
+--------------------------------------+-----------------------+-------------+----------+--------+
Bild "overcloud-full" wurde hochgeladen.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | GröĂe | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktiv |
+--------------------------------------+----------------+-------------+------------+--------+
Bild "bm-deploy-kernel" wurde hochgeladen.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | GröĂe | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktiv |
+--------------------------------------+------------------+-------------+---------+--------+
Bild "bm-deploy-ramdisk" wurde hochgeladen.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | GröĂe | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktiv |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Wir ĂŒberprĂŒfen, ob alle Bilder hochgeladen wurden.
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktiv |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktiv |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktiv |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktiv |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktiv |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Ein weiterer Schritt â wir mĂŒssen den DNS-Server hinzufĂŒgen:
(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 ist veraltet und wird in Zukunft entfernt. Verwenden Sie stattdessen die openstack CLI.
Aktualisiertes Subnetz: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Jetzt können wir den Befehl zur Inspektion geben:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Mistral Workflow tripleo.baremetal.v1.register_or_update gestartet. AusfĂŒhrungs-ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Warte auf Nachrichten in der Warteschlange 'tripleo' ohne ZeitĂŒberschreitung.
5 Knoten erfolgreich in den "verwaltbaren" Zustand verschoben.
Knoten UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 erfolgreich registriert
Knoten UUID b89a72a3-6bb7-429a-93bc-48393d225838 erfolgreich registriert
Knoten UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e erfolgreich registriert
Knoten UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 erfolgreich registriert
Knoten UUID 766ab623-464c-423d-a529-d9afb69d1167 erfolgreich registriert
Warte auf Abschluss der Introspektion...
Mistral Workflow tripleo.baremetal.v1.introspect gestartet. AusfĂŒhrungs-ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Warte auf Nachrichten in der Warteschlange 'tripleo' ohne ZeitĂŒberschreitung.
Introspektion des Knotens b89a72a3-6bb7-429a-93bc-48393d225838 abgeschlossen. Status: ERFOLG. Fehler: Keine
Introspektion des Knotens 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e abgeschlossen. Status: ERFOLG. Fehler: Keine
Introspektion des Knotens bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 abgeschlossen. Status: ERFOLG. Fehler: Keine
Introspektion des Knotens 766ab623-464c-423d-a529-d9afb69d1167 abgeschlossen. Status: ERFOLG. Fehler: Keine
Introspektion des Knotens b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 abgeschlossen. Status: ERFOLG. Fehler: Keine
5 Knoten erfolgreich introspektiert.
Mistral Workflow tripleo.baremetal.v1.provide gestartet. AusfĂŒhrungs-ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Warte auf Nachrichten in der Warteschlange 'tripleo' ohne ZeitĂŒberschreitung.
5 Knoten erfolgreich in den "verfĂŒgbaren" Zustand verschoben.
(undercloud) [stack@undercloud ~]$Wie aus der Ausgabe hervorgeht, wurde alles ohne Fehler abgeschlossen. Lass uns ĂŒberprĂŒfen, ob alle Knoten im Zustand verfĂŒgbar sind:
(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 | verfĂŒgbar | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | verfĂŒgbar | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | verfĂŒgbar | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | verfĂŒgbar | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | verfĂŒgbar | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Wenn die Knoten in einem anderen Zustand sind, typischerweise verwaltbar, ist etwas schiefgelaufen und es muss im Protokoll nachgesehen werden, um herauszufinden, warum das so ist. Bitte beachten Sie, dass wir in diesem Szenario Virtualisierung verwenden und es Bugs geben kann, die mit der Nutzung von virtuellen Maschinen oder vbmc zusammenhÀngen.
Als NĂ€chstes mĂŒssen wir angeben, welche Funktion jeder Knoten ausfĂŒhren wird â das heiĂt, wir mĂŒssen das Profil angeben, mit dem der Knoten bereitgestellt werden soll:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | verfĂŒgbar | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | verfĂŒgbar | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | verfĂŒgbar | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | verfĂŒgbar | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | verfĂŒgbar | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Ist Ăffentlich |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | Wahr |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | Wahr |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | Wahr |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | Wahr |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | Wahr |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | Wahr |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Wir weisen jedem Knoten ein Profil zu:
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-d9afb69d1167Wir ĂŒberprĂŒfen, ob wir alles korrekt gemacht haben:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | verfĂŒgbar | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | verfĂŒgbar | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | verfĂŒgbar | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | verfĂŒgbar | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | verfĂŒgbar | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Wenn alles korrekt ist, geben wir den Befehl zum Deployen des Overclouds ein:
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 qemuIn einer realen Installation wĂŒrden natĂŒrlich angepasste Templates verwendet werden, was in unserem Fall den Prozess erheblich komplizierter machen wĂŒrde, da jede Ănderung im Template erklĂ€rt werden mĂŒsste. Wie bereits erwĂ€hnt, wird eine einfache Installation ausreichen, um zu sehen, wie es funktioniert.
Hinweis: Die Variable âlibvirt-type qemu ist in diesem Fall notwendig, da wir die verschachtelte Virtualisierung verwenden werden. Andernfalls können keine virtuellen Maschinen gestartet werden.
Nun haben Sie etwa eine Stunde, vielleicht auch mehr (abhĂ€ngig von der Hardware), und Sie mĂŒssen hoffen, dass Sie nach dieser Zeit die folgende Meldung sehen:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE erfolgreich abgeschlossen
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 nicht in /home/stack/.ssh/known_hosts gefunden
Startete Mistral Workflow tripleo.deployment.v1.get_horizon_url. AusfĂŒhrungs-ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Ăbercloud Horizon Dashboard-URL: http://192.168.255.21:80/dashboard
Ăbercloud rc-Datei: /home/stack/overcloudrc
Ăbercloud bereitgestellt
(undercloud) [stack@undercloud ~]$Jetzt haben Sie eine fast vollstÀndige Version von OpenStack, auf der Sie lernen, experimentieren usw. können.
ĂberprĂŒfen wir, ob alles normal funktioniert. Im Home-Verzeichnis des Benutzers stack gibt es zwei Dateien â eine stackrc (fĂŒr die Verwaltung des Undercloud) und eine zweite overcloudrc (fĂŒr die Verwaltung des Overcloud). Diese Dateien mĂŒssen als Quelle angegeben werden, da sie die fĂŒr die Authentifizierung notwendigen Informationen enthalten.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Netzwerke | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | AKTIV | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | AKTIV | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | AKTIV | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | AKTIV | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | AKTIV | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack projektliste
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | dienst |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack netzwerk agentenliste
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | VerfĂŒgbarkeitszone | Aktiv | Zustand | BinĂ€r |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 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 | Metadaten-Agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$In meiner Installation muss noch ein kleiner Schritt erfolgen â eine Route auf dem Controller hinzufĂŒgen, da sich die Maschine, mit der ich arbeite, in einem anderen Netzwerk befindet. DafĂŒr werden wir uns unter dem Benutzer heat-admin bei control-1 anmelden und die Route hinzufĂŒgen.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Letzte Anmeldung: Fr Aug 14 09:47:40 2020 von 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.254Nun können Sie in Horizon gehen. Alle Informationen â Adressen, Login und Passwort â befinden sich in der Datei /home/stack/overcloudrc. Das endgĂŒltige Schema sieht folgendermaĂen aus:
Ăbrigens, in unserer Installation wurden die IP-Adressen der Maschinen ĂŒber DHCP zugewiesen, und wie Sie sehen können, werden sie âwillkĂŒrlichâ vergeben. Sie können im Template festlegen, welche Adresse welcher Maschine wĂ€hrend des Deployments zugewiesen werden soll, wenn dies erforderlich ist.
Wie verlÀuft der Datenverkehr zwischen virtuellen Maschinen?
In diesem Artikel betrachten wir drei Varianten des Datenverkehrs.
- Zwei Maschinen auf einem Hypervisor im selben L2-Netzwerk.
- Zwei Maschinen auf unterschiedlichen Hypervisors im selben L2-Netzwerk.
- Zwei Maschinen in verschiedenen Netzwerken (Routing zwischen den Netzwerken).
Die FĂ€lle mit Zugang zur AuĂenwelt ĂŒber das externe Netzwerk, unter Verwendung von Floating IPs sowie verteiltem Routing, werden wir beim nĂ€chsten Mal betrachten; fĂŒr jetzt konzentrieren wir uns auf den internen Datenverkehr.
Zur ĂberprĂŒfung erstellen wir folgendes Schema:
Wir haben 4 virtuelle Maschinen erstellt â 3 in demselben L2-Netzwerk â net-1, und eine weitere im Netzwerk 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 | AKTIV | - | Laufend | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Laufend | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Laufend | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Laufend | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Schauen wir uns an, auf welchen Hypervisors die erstellten Maschinen untergebracht sind:
(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 ~]$
Die Maschinen vm-1 und vm-3 befinden sich auf compute-0, die Maschinen vm-2 und vm-4 befinden sich auf der Node compute-1.
AuĂerdem wurde ein virtueller Router erstellt, um die Routing-Möglichkeiten zwischen den angegebenen Netzwerken zu ermöglichen:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Projekt |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | AKTIV | OBEN | Falsch | Falsch| 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Der Router hat zwei virtuelle Ports, die als Gateways fĂŒr die Netzwerke fungieren:
(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 ~]$ Aber bevor wir sehen, wie der Datenverkehr verlÀuft, schauen wir uns an, was wir derzeit auf der Steuerknoten haben (der gleichzeitig auch die Network-Node ist) und auf der Compute-Node. Lassen Sie uns mit der Compute-Node beginnen.
[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: (intern)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (intern)
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 ~]$Momentan gibt es auf dem Knoten drei OVS-Bridges â br-int, br-tun, br-ex. Zwischen ihnen gibt es, wie wir sehen, eine Reihe von Schnittstellen. Zur besseren VerstĂ€ndlichkeit werden wir alle diese Schnittstellen auf einem Diagramm darstellen und schauen, was dabei herauskommt.
An den Adressen, auf denen die VxLAN-Tunnel eingerichtet sind, ist zu sehen, dass ein Tunnel auf compute-1 (192.168.255.26) aktiv ist, wÀhrend der zweite Tunnel auf control-1 (192.168.255.15) zeigt. Interessant ist jedoch, dass br-ex keine physischen Schnittstellen hat, und wenn wir uns die konfigurierten Flows ansehen, wird deutlich, dass diese Bridge momentan nur den Traffic verwerfen kann.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
a: flags=4163 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
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 ~]$ Wie aus der Ausgabe ersichtlich ist, ist die Adresse direkt an den physischen Port angeschlossen und nicht an die virtuelle Bridge-Schnittstelle.
[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 ~]$ GemÀà der ersten Regel muss alles, was aus dem Port phy-br-ex kommt, verworfen werden.
TatsĂ€chlich kann es fĂŒr diese Bridge momentan keinen anderen Traffic geben, als ĂŒber diese Schnittstelle (Verbindung mit br-int), und judging by the drops hat die Bridge bereits BUM-Traffic erhalten.
Das heiĂt, der Verkehr kann von diesem Knoten nur ĂŒber das VxLAN-Tunnel flieĂen und auf keine andere Weise. Wenn jedoch DVR aktiviert ist, Ă€ndert sich die Situation, damit werden wir uns spĂ€ter befassen. Bei der Verwendung von Netzwerkisolierung, beispielsweise durch Vlans, haben Sie nicht nur eine L3-Schnittstelle im VLAN-0, sondern mehrere Schnittstellen. Der VxLAN-Verkehr wird jedoch genauso wie zuvor vom Knoten ausgehen, nur zusĂ€tzlich in ein bestimmtes VLAN gekapselt.
Wir haben uns mit dem Compute-Knoten beschÀftigt, jetzt kommen wir zum Control-Knoten.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (intern)
eth0 1/2: (System)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (intern)
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 ~]$Im Grunde kann man sagen, dass alles gleich geblieben ist, jedoch befindet sich die IP-Adresse nicht mehr an der physischen Schnittstelle, sondern an dem virtuellen Bridge. Dies ist darauf zurĂŒckzufĂŒhren, dass dieser Port der Port ist, ĂŒber den der Verkehr in die AuĂenwelt flieĂen wird.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 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
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 ~]$ Dieser Port ist mit dem Bridge br-ex verbunden und da keine VLAN-Tags vorhanden sind, ist dieser Port ein Trunk-Port, an dem alle VLANs erlaubt sind. Der Verkehr lÀuft jetzt ohne Tag aus, was durch die VLAN-ID 0 in der oben genannten Ausgabe angezeigt wird.
Ansonsten ist im Moment alles Ă€hnlich wie beim Compute-Knoten â dieselben Bridges, dieselben Tunnel, die zu den zwei Compute-Knoten fĂŒhren.
Die Storage-Knoten werden in diesem Artikel nicht betrachtet, aber zum VerstĂ€ndnis ist es notwendig zu erwĂ€hnen, dass der Netzwerkanteil dieser Knoten zu banal ist. In unserem Fall gibt es nur einen physischen Port (eth0) mit einer darauf gemappten IP-Adresse und das war's. Es gibt keine VxLAN-Tunnel, Tunnel-Bridges usw. â es gibt ĂŒberhaupt kein OVS, da es keinen Sinn macht. Bei der Verwendung von Netzwerkisolierung wird dieser Knoten zwei Schnittstellen haben (physische Ports, Bonding oder einfach zwei VLANs â das ist unwichtig â es hĂ€ngt davon ab, was Sie wollen) â eine fĂŒr das Management, die andere fĂŒr den Datenverkehr (Schreiben auf die VM-Disk, Lesen von der Disk usw.).
Wir haben verstanden, was wir ohne irgendwelche Dienste auf den Knoten haben. Jetzt starten wir 4 virtuelle Maschinen und sehen, wie sich das oben beschriebene Diagramm verĂ€ndert â wir sollten Ports, virtuelle Router usw. sehen.
Bis jetzt sieht unser Netzwerk so aus:
Wir haben zwei virtuelle Maschinen auf jedem Rechenknoten. Am Beispiel von compute-0 schauen wir uns an, wie alles angeschlossen ist.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Die Maschine hat nur eine virtuelle Schnittstelle â tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Typ Quelle Modell MAC
-------------------------------------------------------
tap95d96a75-a0 Bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Diese Schnittstelle zeigt auf den Linux-Bridge:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
Bridge-Name Bridge-ID STP aktiviert Schnittstellen
docker0 8000.0242904c92a8 nein
qbr5bd37136-47 8000.5e4e05841423 nein qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 nein qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Wie aus der Ausgabe des Bridges hervorgeht, gibt es insgesamt zwei Schnittstellen â tap95d96a75-a0 und qvb95d96a75-a0.
Hier sollte man einen Moment innehalten und die Typen der virtuellen NetzwerkgerÀte in OpenStack betrachten:
vtap â virtuelle Schnittstelle, die an eine Instanz (VM) angeschlossen ist
qbr â Linux Bridge
qvb und qvo â vEth-Paar, das an die Linux Bridge und die Open vSwitch Bridge angeschlossen ist
br-int, br-tun, br-vlan â Open vSwitch Bridges
patch-, int-br-, phy-br- â Open vSwitch Patch-Schnittstellen, die Bridges verbinden
qg, qr, ha, fg, sg â Open vSwitch-Ports, die von virtuellen GerĂ€ten zur Verbindung mit OVS verwendet werden
Wie Sie verstehen, wenn wir im Bridge einen Port haben, der eine vEth-Paar ist, gibt es irgendwo die Gegenstelle, die logisch als qvo95d96a75-a0 bezeichnet werden sollte. Schauen wir uns an, welche Ports es auf OVS gibt.
[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 ~]$ Wie wir sehen, befindet sich der Port im br-int. Br-int fungiert als Switch, der die Ports von virtuellen Maschinen terminiert. Neben qvo95d96a75-a0 ist im Output auch der Port qvo5bd37136-47 sichtbar. Dies ist der Port zur zweiten virtuellen Maschine. Somit sieht unser Schema jetzt so aus:
Die Frage, die sofort das Interesse des aufmerksamen Lesers wecken sollte â warum gibt es einen Linux Bridge zwischen dem Port der virtuellen Maschine und dem Port OVS? Der Grund liegt darin, dass fĂŒr den Schutz der Maschine Sicherheitsgruppen verwendet werden, die nichts anderes als iptables sind. OVS arbeitet nicht mit iptables, daher wurde ein solcher "Workaround" erfunden. Allerdings ist dies nicht mehr zeitgemÀà â conntrack tritt in den neuen Versionen an seine Stelle.
Das heiĂt, letztendlich sieht das Schema so aus:
Zwei Maschinen auf einem Hypervisor im selben L2-Netzwerk.
Da sich die beiden VMs im selben L2-Netzwerk und auf demselben Hypervisor befinden, wird der Verkehr zwischen ihnen lokal ĂŒber br-int flieĂen, da sich beide Maschinen im selben VLAN befinden:
[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 ~]$ Zwei Maschinen auf unterschiedlichen Hypervisors im selben L2-Netzwerk.
Jetzt schauen wir uns an, wie der Verkehr zwischen zwei Maschinen im selben L2-Netzwerk flieĂt, die sich aber auf unterschiedlichen Hypervisoren befinden. Um ehrlich zu sein, wird sich nicht viel Ă€ndern, einfach der Verkehr zwischen den Hypervisoren wird durch ein vxlan-Tunnel geleitet. Schauen wir uns das am Beispiel an.
Adressen der virtuellen Maschinen, zwischen denen wir den Verkehr ĂŒberwachen werden:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Typ Quelle Modell 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
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Wir schauen uns die Forwarding-Tabelle in br-int auf compute-0 an:
[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 ~]Der Verkehr sollte in Port 2 gehen â schauen wir, um welchen Port es sich handelt:
[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 ~]$Dies ist patch-tun â das heiĂt, ein Interface in br-tun. Schauen wir, was mit dem Paket auf br-tun passiert:
[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 ~]$ Das Paket wird in VxLAN verpackt und an Port 2 gesendet. Schauen wir, wohin Port 2 fĂŒhrt:
[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 ~]$Das ist der vxlan Tunnel auf 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 ~]$Wir gehen nach compute-1 und sehen, was weiter mit dem Paket passiert:
[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 ~]$ Die MAC-Adresse ist in der Forwarding-Tabelle br-int auf compute-1 vorhanden, und wie aus der obigen Ausgabe ersichtlich, wird sie ĂŒber Port 2 angezeigt, der zum br-tun fĂŒhrt:
[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:46Nun schauen wir weiter, dass es in br-int auf compute-1 eine Ziel-MAC gibt:
[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 ~]$ Das bedeutet, dass das empfangene Paket an Port 3 gesendet wird, hinter dem sich bereits die virtuelle Maschine instance-00000003 befindet.
Der gesamte Reiz der Bereitstellung von OpenStack zum Lernen auf virtueller Infrastruktur besteht darin, dass wir den Datenverkehr zwischen Hypervisoren problemlos erfassen und beobachten können, was damit geschieht. Das werden wir jetzt tun, indem wir tcpdump am vnet-Port in Richtung compute-0 starten:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: hört auf vnet3, linktype EN10MB (Ethernet), ErfassungsgröĂe 262144 Bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), LĂ€nge 134)
192.168.255.19.39096 > 192.168.255.26.4789: [kein cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), LĂ€nge 84)
10.0.1.85 > 10.0.1.88: ICMP Echo-Anforderung, id 5634, sequenz 16, LĂ€nge 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), LĂ€nge 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [kein cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), LĂ€nge 84)
10.0.1.88 > 10.0.1.85: ICMP Echo-Antwort, id 5634, sequenz 16, LĂ€nge 64
*****************omitted*******************Die erste Zeile zeigt, dass das Paket von der Adresse 10.0.1.85 zur Adresse 10.0.1.88 (ICMP-Verkehr) geht, wobei es in ein VxLAN-Paket mit vni 22 eingekapselt ist und das Paket vom Host 192.168.255.19 (compute-0) zum Host 192.168.255.26 (compute-1) lĂ€uft. Wir können ĂŒberprĂŒfen, dass die VNI demjenigen entspricht, der im OVS angegeben ist.
Kehren wir zu dieser Zeile zurĂŒck: actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 ist die vni im hexadezimalen Zahlensystem. Lassen Sie uns diese Zahl in das Dezimalsystem umwandeln:
16 = 6*16^0+1*16^1 = 6+16 = 22Das heiĂt, die vni entspricht der RealitĂ€t.
Die zweite Zeile zeigt den zurĂŒckkehrenden Verkehr; es macht wenig Sinn, darĂŒber zu erlĂ€utern, da es ohnehin klar ist.
Zwei Maschinen in verschiedenen Netzwerken (Routing zwischen Netzwerken)
Der letzte Fall fĂŒr heute ist das Routing zwischen Netzwerken innerhalb eines Projekts unter Verwendung eines virtuellen Routers. Wir betrachten den Fall ohne DVR (diesen behandeln wir in einem anderen Artikel), daher erfolgt das Routing auf dem Netzwerk-Knoten. In unserem Fall ist der Netzwerk-Knoten nicht in eine separate EntitĂ€t ausgelagert und befindet sich auf dem Steuerknoten.
Als Erstes ĂŒberprĂŒfen wir, ob das Routing funktioniert:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 Datenbytes
64 Bytes von 10.0.2.8: seq=0 ttl=63 Zeit=7.727 ms
64 Bytes von 10.0.2.8: seq=1 ttl=63 Zeit=3.832 ms
^C
--- 10.0.2.8 Ping-Statistik ---
2 Pakete gesendet, 2 Pakete empfangen, 0% Paketverlust
Rundlaufzeit min/avg/max = 3.832/5.779/7.727 msDa in diesem Fall das Paket zum Gateway geschickt und dort geroutet werden muss, mĂŒssen wir die MAC-Adresse des Gateways herausfinden. Dazu werfen wir einen Blick auf die ARP-Tabelle in der Instanz:
$ 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 eth0Jetzt schauen wir uns an, wohin der Traffic mit der Zieladresse (10.0.1.254) fa:16:3e:c4:64:70 gesendet werden soll.
[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 ~]$ Wir schauen uns an, wohin Port 2 fĂŒhrt:
[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 ~]$ Alles logisch, der Traffic geht zu br-tun. Lassen Sie uns sehen, in welchen vxlan-Tunnel er eingewickelt wird:
[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 ~]$ Der dritte Port ist ein vxlan-Tunnel:
[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 ~]$ Der schaut auf die Kontrollknoten:
[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 ~]$ Der Traffic hat die Kontrollknoten erreicht, daher mĂŒssen wir zu ihm wechseln und sehen, wie die Routing erfolgen wird.
Wie Sie sich erinnern, sah die Kontrollknoten von innen genau so aus wie die Compute-Nodes â dieselben drei BrĂŒcken, nur hatte br-ex einen physischen Port, ĂŒber den die Knoten Traffic nach auĂen senden konnten. Die Erstellung von Instanzen Ă€nderte die Konfiguration auf den Compute-Nodes â es kamen Linux-Bridges, iptables und Schnittstellen zu den Knoten hinzu. Auch die Erstellung von Netzwerken und einem virtuellen Router hinterlieĂ ihre Spuren in der Konfiguration der Kontrollknoten.
Es ist also offensichtlich, dass die MAC-Adresse des Gateways in der Forwarding-Tabelle von br-int auf der Kontrollknoten sein muss. ĂberprĂŒfen wir, ob er dort ist und wohin er zeigt:
[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 ~]$ Die MAC-Adresse ist aus dem Port qr-0c52b15f-8f sichtbar. Wenn wir zum virtuellen Portverzeichnis in Openstack zurĂŒckkehren, wird dieser Porttyp verwendet, um verschiedene virtuelle GerĂ€te mit OVS zu verbinden. Genauer gesagt, qr ist der Port zum virtuellen Router, der in Form eines Namespace dargestellt wird.
Lassen Sie uns ansehen, welche Namespaces auf dem Server vorhanden sind:
[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 ~]$ Insgesamt gibt es drei Instanzen. Aber schon anhand der Namen kann man auf ihre jeweilige Funktion schlieĂen. Auf die Instanzen mit ID 0 und 1 kommen wir spĂ€ter zurĂŒck, jetzt interessiert uns der Namespace 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 ~]$ In diesem Namespace gibt es zwei interne, die wir zuvor erstellt haben. Beide virtuellen Ports sind in br-int hinzugefĂŒgt worden. ĂberprĂŒfen wir die MAC-Adresse des Ports qr-0c52b15f-8f, da der Verkehr, laut MAC-Zieladresse, genau ĂŒber diese Schnittstelle lief.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163 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
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 ~]$ Das bedeutet, dass hier alles nach den Gesetzen der Standard-Routing funktioniert. Da der Verkehr fĂŒr den Host 10.0.2.8 bestimmt ist, sollte er ĂŒber die zweite Schnittstelle qr-92fa49b5-54 geleitet werden und ĂŒber den VXLAN-Tunnel auf den Compute-Knoten gehen:
[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 ~]$ Alles logisch, keine Ăberraschungen. Schauen wir, wo die MAC-Adresse des Hosts 10.0.2.8 in br-int sichtbar ist:
[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 ~]$ Wie es sich gehört, geht der Verkehr in br-tun. Schauen wir, in welchem Tunnel der Verkehr weitergeleitet wird:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, dauer=5346.829s, tabelle=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, prioritÀt=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c aktionen=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 ~]$ Der Traffic geht durch den Tunnel zu compute-1. Und auf compute-1 ist alles einfach â aus br-tun gelangt das Paket in br-int und von dort in die Schnittstelle der virtuellen Maschine:
[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 ~]$ Lassen Sie uns ĂŒberprĂŒfen, ob dies tatsĂ€chlich die richtige Schnittstelle ist:
[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
Schnittstelle Typ Quelle Modell MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$ Wir haben also den gesamten Weg des Pakets durchlaufen. Ich denke, Sie haben bemerkt, dass der Traffic durch verschiedene vxlan-Tunnel ging und mit unterschiedlichen VNIs herauskam. Lassen Sie uns sehen, welche das sind, und danach sammeln wir einen Dump am Control-Node-Port und stellen sicher, dass der Traffic tatsÀchlich so verlÀuft, wie oben beschrieben.
Der Tunnel zu compute-0 hat folgende Aktionen: actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Lassen Sie uns 0x16 in den Dezimalwert umrechnen:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Der Tunnel zu compute-1 hat folgenden VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Lassen Sie uns 0x63 in den Dezimalwert umrechnen:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Und jetzt schauen wir uns den Dump an:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: hört auf vnet4, Linktyp EN10MB (Ethernet), Erfassungsgeschwindigkeit 262144 Bytes
*****************ausgelassen*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), LĂ€nge 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), LĂ€nge 84)
10.0.1.85 > 10.0.2.8: ICMP Echo-Anfrage, id 5378, seq 9, LĂ€nge 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), LĂ€nge 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), LĂ€nge 84)
10.0.1.85 > 10.0.2.8: ICMP Echo-Anfrage, id 5378, seq 9, LĂ€nge 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), LĂ€nge 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), LĂ€nge 84)
10.0.2.8 > 10.0.1.85: ICMP Echo-Antwort, id 5378, seq 9, LĂ€nge 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), LĂ€nge 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), LĂ€nge 84)
10.0.2.8 > 10.0.1.85: ICMP Echo-Antwort, id 5378, seq 9, LĂ€nge 64
*****************ausgelassen*******************Das erste Paket ist ein VXLAN-Paket von Host 192.168.255.19 (compute-0) zu Host 192.168.255.15 (control-1) mit vni 22, innerhalb dessen ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 verpackt ist. Wie wir oben berechnet haben, entspricht vni dem, was wir in den Ausgaben gesehen haben.
Das zweite Paket ist ein VXLAN-Paket von Host 192.168.255.15 (control-1) zu Host 192.168.255.26 (compute-1) mit vni 99, innerhalb dessen ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 verpackt ist. Wie wir oben berechnet haben, entspricht vni dem, was wir in den Ausgaben gesehen haben.
Die nĂ€chsten beiden Pakete sind RĂŒckverkehr von 10.0.2.8 an 10.0.1.85.
Das heiĂt, letztendlich haben wir ein Schema der Kontrollknoten erhalten:
Scheint alles zu sein? Wir haben zwei Namespaces vergessen:
[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 ~]$ Wie wir ĂŒber die Architektur der Cloud-Plattform gesprochen haben â es wĂ€re gut, wenn die Maschinen automatisch Adressen vom DHCP-Server erhalten. Das sind die zwei DHCP-Server fĂŒr unsere beiden Netzwerke 10.0.1.0/24 und 10.0.2.0/24.
Lass uns ĂŒberprĂŒfen, ob dem so ist. In diesem Namespace gibt es nur eine Adresse â 10.0.1.1 â die Adresse des DHCP-Servers selbst, und sie ist ebenfalls in br-int eingebunden:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
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 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
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 0Lassen Sie uns prĂŒfen, ob Prozesse mit dem Namen qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 auf dem Control-Node existieren:
[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 ~]$ Es gibt diesen Prozess und basierend auf den Informationen, die in der obigen Ausgabe prĂ€sentiert werden, können wir zum Beispiel prĂŒfen, was wir im Moment im Leihwesen haben:
[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 ~]$Insgesamt erhalten wir dieses Set von Diensten auf dem Control-Node:
Bitte beachten Sie, dass dies nur 4 Maschinen, 2 interne Netzwerke und einen virtuellen Router sind... Wir haben hier momentan keine externen Netzwerke, keine verschiedenen Projekte, von denen jedes eigene (ĂŒberlappende) Netzwerke hat, und unser verteilte Router ist ausgeschaltet. SchlieĂlich gab es im Teststand nur einen Control-Node (fĂŒr die Ausfallsicherheit sollte ein Quorum aus drei Knoten vorhanden sein). Es ist logisch, dass es im kommerziellen Bereich âein wenigâ komplizierter ist, aber an diesem einfachen Beispiel verstehen wir, wie es funktionieren sollte â ob Sie 3 oder 300 Namespaces haben, ist zwar wichtig, aber aus Sicht des gesamten Systems Ă€ndert sich nicht viel... zumindest bis Sie irgendein vendor-basiertes SDN anschlieĂen. Aber das ist eine ganz andere Geschichte.
Ich hoffe, es war interessant. Wenn Sie Anmerkungen / ErgĂ€nzungen haben oder wenn ich irgendwo offensichtlich gelogen habe (ich bin ein Mensch und meine Meinung wird immer subjektiv sein) â lassen Sie es mich wissen, was korrigiert / hinzugefĂŒgt werden muss â wir werden alles anpassen / hinzufĂŒgen.
AbschlieĂend möchte ich ein paar Worte ĂŒber den Vergleich von OpenStack (sowohl Vanilla- als auch vendor-basierten Versionen) mit der Cloud-Lösung von VMWare sagen â mir wurde diese Frage in den letzten Jahren zu oft gestellt, und ehrlich gesagt bin ich schon etwas mĂŒde davon, aber dennoch. Meiner Meinung nach ist es sehr schwierig, diese beiden Lösungen zu vergleichen, aber es kann unmissverstĂ€ndlich gesagt werden, dass es sowohl in der einen als auch in der anderen Lösung Nachteile gibt und man bei der Auswahl einer Lösung alle Vor- und Nachteile abwĂ€gen sollte.
Wenn OpenStack eine community-driven Lösung ist, hat VMWare das Recht, nur das zu tun, was sie will (lesen Sie: was fĂŒr sie profitabel ist), und das ist logisch â denn es ist ein kommerzielles Unternehmen, das daran gewöhnt ist, Geld mit seinen Kunden zu verdienen. Aber es gibt ein groĂes und fettes ABER â Sie können von OpenStack, sagen wir, von Nokia, mit minimalem Aufwand auf eine Lösung von Juniper (Contrail Cloud) umsteigen, aber mit VMWare wird Ihnen das wahrscheinlich nicht gelingen. FĂŒr mich sehen diese beiden Lösungen so aus â OpenStack (vendor-basiert) ist ein einfacher KĂ€fig, in den Sie gesetzt werden, aber Sie haben einen SchlĂŒssel und können jederzeit herauskommen. VMWare ist ein goldener KĂ€fig, der SchlĂŒssel gehört dem EigentĂŒmer und er wird Ihnen sehr teuer zu stehen kommen.
Ich werbe weder fĂŒr das erste Produkt noch fĂŒr das zweite â Sie wĂ€hlen das, was Sie benötigen. Aber wenn ich eine solche Wahl zu treffen hĂ€tte, wĂŒrde ich beide Lösungen wĂ€hlen â VMWare fĂŒr die IT-Cloud (geringe Lasten, einfache Verwaltung), OpenStack von einem beliebigen Anbieter (Nokia und Juniper bieten sehr anstĂ€ndige schlĂŒsselfertige Lösungen) â fĂŒr die Telekom-Cloud. Ich wĂŒrde OpenStack nicht fĂŒr reine IT verwenden â das ist wie mit einer Kanone auf Spatzen zu schieĂen, aber ich sehe keine EinwĂ€nde gegen seine Verwendung, auĂer dass es ĂŒberflĂŒssig ist. Allerdings VMWare im Telekom-Bereich zu verwenden â das ist wie Schotter mit einem Ford Raptor zu transportieren â sieht schön aus, aber der Fahrer muss 10 Fahrten statt einer machen.
Meiner Meinung nach ist das gröĂte Manko von VMWare ihre vollstĂ€ndige Intransparenz â das Unternehmen gibt Ihnen keine Informationen darĂŒber, wie zum Beispiel vSAN funktioniert oder was im Kernel des Hypervisors vor sich geht â das ist fĂŒr sie einfach nicht rentabel â das heiĂt, Sie werden niemals ein Experte fĂŒr VMWare werden â ohne UnterstĂŒtzung des Anbieters sind Sie verloren (sehr oft treffe ich Experten fĂŒr VMWare, die bei banalen Fragen ins Stocken geraten). FĂŒr mich ist VMWare der Kauf eines Autos mit einem verschlossenen Motorhaube â ja, vielleicht haben Sie Spezialisten, die den Zahnriemen wechseln können, aber die Motorhaube öffnen kann nur der, der Ihnen diese Lösung verkauft hat. Persönlich mag ich Lösungen nicht, in die ich nicht eingreifen kann. Sie werden sagen, dass es möglicherweise nicht notwendig ist, unter die Motorhaube zu schauen. Ja, das könnte sein, aber ich werde Sie ansehen, wenn Sie eine groĂe Funktion mit 20-30 virtuellen Maschinen, 40-50 Netzwerken in der Cloud aufbauen mĂŒssen, von denen die eine HĂ€lfte nach auĂen will und die andere HĂ€lfte nach SR-IOV-Beschleunigung fragt, sonst benötigen Sie noch ein paar Dutzend solcher Maschinen â sonst reicht die Leistung nicht aus.
Es gibt auch andere Meinungen, deshalb liegt es ganz bei Ihnen, was Sie wĂ€hlen, und vor allem â Sie mĂŒssen spĂ€ter fĂŒr Ihre Wahl gerade stehen. Das ist nur meine Meinung â die Meinung eines Menschen, der mindestens vier Produkte angefasst hat â Nokia, Juniper, Red Hat und VMWare. Das heiĂt, ich habe etwas, womit ich vergleichen kann.
Quelle: habr.com
