Cloud Computing dringt immer tiefer in unser Leben ein, und es gibt wahrscheinlich keine einzige Person, die mindestens einmal keine Cloud-Dienste genutzt hat. Was eine Cloud ist und wie sie größtenteils funktioniert, wissen nur wenige Menschen selbst auf der Ebene einer Idee. 5G wird bereits Realität und die Telekommunikationsinfrastruktur beginnt sich von Säulenlösungen zu Cloud-Lösungen zu bewegen, wie damals, als sie von vollständig eisernen Lösungen zu virtualisierten „Säulen“ überging.
Heute werden wir über die innere Welt der Cloud-Infrastruktur sprechen, insbesondere werden wir die Grundlagen des Netzwerkteils analysieren.
Was ist eine Wolke? Die gleiche Virtualisierung - Profilansicht?
Mehr als eine logische Frage. Nein - dies ist keine Virtualisierung, obwohl sie nicht ohne war. Betrachten Sie zwei Definitionen:
Cloud Computing (im Folgenden: Cloud) ist ein Modell für den benutzerfreundlichen Zugriff auf verteilte Computerressourcen, die bei Bedarf mit der geringstmöglichen Latenz und minimalen Kosten des Dienstanbieters bereitgestellt und gestartet werden müssen (Übersetzung der Definition aus NIST).
Virtualisierung- Dies ist die Möglichkeit, eine physische Entität (z. B. einen Server) in mehrere virtuelle zu unterteilen, wodurch die Ressourcennutzung erhöht wird (z. B. wurden 3 Server um 25 bis 30 Prozent geladen, nach der Virtualisierung wird 1 Server um 80 bis 90 Prozent geladen). Natürlich verbraucht die Virtualisierung einen Teil der Ressourcen - Sie müssen den Hypervisor füttern, aber wie die Praxis gezeigt hat, ist das Spiel die Kerze wert. Ein ideales Beispiel für Virtualisierung ist VMWare, das virtuelle Maschinen perfekt vorbereitet, oder beispielsweise KVM, das ich bevorzuge, aber dies ist bereits Geschmackssache.
Wir verwenden die Virtualisierung selbst, ohne dies zu bemerken, und selbst Eisenrouter verwenden bereits die Virtualisierung. In den neuesten Versionen von JunOS wird das Betriebssystem beispielsweise als virtuelle Maschine auf dem Echtzeit-Linux-Verteilungskit (Wind River 9) installiert. Virtualisierung ist jedoch nicht die Cloud, aber die Cloud kann ohne Virtualisierung nicht existieren.
Virtualisierung ist einer der Bausteine, auf denen die Cloud basiert.
Es wird nicht funktionieren, eine Cloud zu erstellen, indem einfach mehrere Hypervisoren in einer L2-Domäne gesammelt werden, ein paar Yaml-Playbooks hinzugefügt werden, um Vlans automatisch über ein Ansible zu registrieren, und sie mit einem Orchestrierungssystem zum automatischen Erstellen virtueller Maschinen gefüllt werden. Genauer gesagt wird es sich herausstellen, aber der resultierende Frankenstein ist nicht die Wolke, die wir brauchen, obwohl dies als jemand anderes vielleicht für jemanden der ultimative Traum ist. Wenn Sie denselben Openstack nehmen - tatsächlich ist es immer noch Frankenstein, aber na ja, lassen Sie uns noch nicht darüber sprechen.
Aber ich verstehe, dass aus der obigen Definition nicht ganz klar ist, was man eigentlich als Wolke bezeichnen kann.
Daher listet das Dokument des NIST (Nationales Institut für Standards und Technologie) 5 Hauptmerkmale auf, die eine Cloud-Infrastruktur aufweisen sollte:
Servicebereitstellung auf Anfrage. Der Benutzer sollte freien Zugriff auf die ihm zugewiesenen Computerressourcen (wie Netzwerke, virtuelle Festplatten, Speicher, Prozessorkerne usw.) erhalten, und diese Ressourcen sollten automatisch bereitgestellt werden, dh ohne Eingreifen des Dienstanbieters.
Breite Serviceverfügbarkeit. Der Zugriff auf Ressourcen sollte über Standardmechanismen erfolgen, um sowohl Standard-PCs als auch Thin Clients und mobile Geräte verwenden zu können.
Bündelung von Ressourcen.Ressourcenpools sollten in der Lage sein, mehreren Clients gleichzeitig Ressourcen bereitzustellen, um die Isolation der Clients und das Fehlen gegenseitiger Beeinflussung und Konkurrenz um Ressourcen sicherzustellen. In den Pools sind auch Netzwerke enthalten, was auf die Möglichkeit hinweist, überlappende Adressen zu verwenden. Pools müssen nach Bedarf skaliert werden. Die Verwendung von Pools ermöglicht die Bereitstellung des erforderlichen Maßes an Ressourcenstabilität und Abstraktion von physischen und virtuellen Ressourcen. Dem Empfänger des Dienstes werden lediglich die von ihm angeforderten Ressourcen bereitgestellt (wo sich diese Ressourcen physisch befinden, auf wie vielen Servern und Switches - der Client kümmert sich nicht darum). Es muss jedoch berücksichtigt werden, dass der Anbieter eine transparente Reservierung dieser Ressourcen sicherstellen muss.
Schnelle Anpassung an verschiedene Bedingungen.Services sollten flexibel sein - schnelle Bereitstellung von Ressourcen, deren Neuzuweisung, Hinzufügung oder Reduzierung von Ressourcen auf Anfrage des Kunden, und der Kunde sollte das Gefühl haben, dass die Cloud-Ressourcen endlos sind. Zum besseren Verständnis wird beispielsweise keine Warnung angezeigt, dass Sie einen Teil des Speicherplatzes in Apple iCloud verloren haben, weil die Festplatte auf dem Server defekt ist und die Datenträger defekt sind. Darüber hinaus sind die Möglichkeiten dieses Dienstes von Ihrer Seite nahezu unbegrenzt - Sie benötigen 2 TB - kein Problem, Sie haben bezahlt und erhalten. Ebenso können Sie ein Beispiel mit Google.Drive oder Yandex.Disk geben.
Die Fähigkeit, den bereitgestellten Service zu messen.Cloud-Systeme sollten verbrauchte Ressourcen automatisch steuern und optimieren, während diese Mechanismen sowohl für den Benutzer als auch für den Dienstanbieter transparent sein sollten. Das heißt, Sie können jederzeit überprüfen, wie viel Ressourcen Sie und Ihre Kunden verbrauchen.
Es ist zu berücksichtigen, dass diese Anforderungen hauptsächlich Anforderungen für eine öffentliche Cloud sind. Daher können diese Anforderungen für eine private Cloud (dh eine Cloud, die für die internen Anforderungen eines Unternehmens gestartet wurde) leicht angepasst werden. Sie müssen jedoch noch ausgeführt werden, da wir sonst nicht alle Vorteile des Cloud Computing nutzen können.
Warum brauchen wir eine Wolke?
Jede neue oder vorhandene Technologie, jedes neue Protokoll wird für etwas erstellt (naja, außer natürlich für RIP-ng). Protokoll aus Gründen des Protokolls - niemand braucht es (naja, außer natürlich RIP-ng). Es ist logisch, dass die Cloud erstellt wird, um dem Benutzer / Client einen Dienst bereitzustellen. Wir alle kennen mindestens einige Cloud-Dienste, zum Beispiel Dropbox oder Google.Docs, und ich glaube, die meisten von ihnen verwenden sie erfolgreich. Dieser Artikel wurde beispielsweise mit dem Cloud-Dienst Google.Docs verfasst. Die uns bekannten Cloud-Dienste sind jedoch nur ein Teil der Funktionen der Cloud - genauer gesagt handelt es sich nur um einen SaaS-Dienst. Wir können einen Cloud-Service auf drei Arten bereitstellen: in Form von SaaS, PaaS oder IaaS. Welchen Service Sie benötigen, hängt von Ihren Wünschen und Fähigkeiten ab.
Betrachten wir jedes in der Reihenfolge:
Software as a Service (SaaS) ist ein Modell für die Bereitstellung eines vollständigen Dienstes für einen Client, z. B. einen Mail-Dienst wie Yandex.Mail oder Gmail. In einem solchen Servicebereitstellungsmodell tun Sie als Kunde tatsächlich nichts anderes, als die Services zu nutzen - das heißt, Sie müssen nicht über das Einrichten eines Service, dessen Fehlertoleranz oder Reservierung nachdenken. Die Hauptsache ist, Ihr Passwort nicht zu gefährden, der Anbieter dieses Dienstes erledigt den Rest für Sie. Aus Sicht des Dienstanbieters ist er voll verantwortlich für den gesamten Dienst - von Serverhardware und Hostbetriebssystemen bis hin zu Datenbank- und Softwareeinstellungen.
Plattform als Service (PaaS)- Wenn Sie dieses Modell verwenden, stellt der Dienstanbieter dem Client eine Vorlage für den Dienst zur Verfügung. Nehmen wir beispielsweise einen Webserver. Der Dienstanbieter stellte dem Client einen virtuellen Server zur Verfügung (tatsächlich eine Reihe von Ressourcen wie RAM / CPU / Speicher / Netze usw.) und installierte sogar das Betriebssystem und die erforderliche Software auf diesem Server, aber der Client konfiguriert all diese Dinge selbst und für die Leistung des Dienstes bereits Der Kunde antwortet. Der Dienstanbieter ist wie in der Vergangenheit für die Funktionsfähigkeit von physischen Geräten, Hypervisoren, der virtuellen Maschine selbst, deren Netzwerkverfügbarkeit usw. verantwortlich, aber der Dienst selbst liegt bereits außerhalb seines Verantwortungsbereichs.
Infrastruktur als Service (IaaS)- Dieser Ansatz ist bereits interessanter. Tatsächlich stellt der Dienstanbieter dem Client eine vollständige virtualisierte Infrastruktur zur Verfügung, dh eine Art Satz (Pool) von Ressourcen wie CPU-Kerne, RAM, Netzwerke usw. Alles andere liegt beim Client - was der Client damit tun möchte Ressourcen innerhalb des zugewiesenen Pools (Kontingent) - der Lieferant ist nicht besonders wichtig. Der Kunde möchte seinen eigenen vEPC erstellen oder sogar einen Mini-Operator erstellen und Kommunikationsdienste bereitstellen - keine Frage - tun Sie dies. In einem solchen Szenario ist der Dienstanbieter für die Bereitstellung von Ressourcen, deren Fehlertoleranz und Verfügbarkeit sowie für das Betriebssystem verantwortlich, mit dem Sie diese Ressourcen zu Pools zusammenfassen und dem Client die Möglichkeit geben können, Ressourcen jederzeit auf Anforderung des Clients zu erhöhen oder zu verringern. Der Client konfiguriert alle virtuellen Maschinen und andere Lametta selbst über das Self-Service-Portal und die Konsolen.einschließlich der Registrierung von Netzwerken (außer für externe Netzwerke).
Was ist OpenStack?
In allen drei Optionen benötigt der Dienstanbieter ein Betriebssystem, das die Cloud-Infrastruktur aktiviert. In SaaS ist nicht eine Abteilung für den gesamten Stapel dieses Technologie-Stacks verantwortlich - es gibt eine Abteilung, die für die Infrastruktur verantwortlich ist - das heißt, sie stellt IaaS für eine andere Abteilung bereit, diese Abteilung stellt den SaaS-Client bereit. OpenStack ist eines der Cloud-Betriebssysteme, mit denen Sie eine Reihe von Switches, Servern und Speichersystemen in einem einzigen Ressourcenpool zusammenfassen, diesen gemeinsamen Pool in Unterpools (Mandanten) aufteilen und diese Ressourcen Clients über das Netzwerk bereitstellen können.
OpenstackIst ein Cloud-Betriebssystem, mit dem Sie große Pools von Computerressourcen, Datenspeicher- und Netzwerkressourcen steuern können, deren Bereitstellung und Verwaltung über eine API mithilfe von Standardauthentifizierungsmechanismen erfolgt.
Mit anderen Worten, dies ist eine Reihe von kostenlosen Softwareprojekten, mit denen Cloud-Dienste (sowohl öffentliche als auch private) erstellt werden sollen. Dies ist eine Reihe von Tools, mit denen Sie Server- und Switching-Geräte in einem einzigen Ressourcenpool kombinieren, diese Ressourcen verwalten und das erforderliche Maß an Fehlertoleranz bereitstellen können ...
Zum Zeitpunkt dieses Schreibens sieht die OpenStack-Struktur folgendermaßen aus:
Bild von openstack.org
Jede der Komponenten, aus denen OpenStack besteht, führt eine bestimmte Funktion aus. Mit dieser verteilten Architektur können Sie die benötigten Funktionskomponenten in die Lösung aufnehmen. Einige der Komponenten sind jedoch Stammkomponenten, und ihre Entfernung führt zu einer vollständigen oder teilweisen Inoperabilität der gesamten Lösung. Es ist üblich, sich auf solche Komponenten zu beziehen:
- Dashboard - webbasierte Benutzeroberfläche zum Verwalten von OpenStack-Diensten
- Keystone ist ein zentraler Identitätsdienst, der Authentifizierungs- und Autorisierungsfunktionen für andere Dienste bereitstellt sowie Benutzeranmeldeinformationen und -rollen verwaltet.
- Neutron — , OpenStack ( VM )
- Cinder —
- Nova —
- Glance —
- Swift —
- Ceilometer — ,
- Heat —
Eine vollständige Liste aller Projekte und ihres Zwecks finden Sie hier .
Jede der OpenStack-Komponenten ist ein Dienst, der für eine bestimmte Funktion verantwortlich ist und eine API zum Verwalten dieser Funktion und zum Kommunizieren dieses Dienstes mit anderen Cloud-Betriebssystemdiensten bereitstellt, um eine einheitliche Infrastruktur zu erstellen. Beispielsweise bietet Nova Rechenressourcenverwaltung und APIs für den Zugriff auf die Konfiguration dieser Ressourcen, Glance bietet Bildverwaltung und APIs für deren Verwaltung, Cinder Blockspeicher und APIs für deren Verwaltung usw. Alle Funktionen sind sehr eng miteinander verbunden.
Wenn Sie jedoch beurteilen, sind alle in OpenStack ausgeführten Dienste letztendlich eine Art virtuelle Maschine (oder Container), die mit dem Netzwerk verbunden ist. Es stellt sich die Frage, warum wir so viele Elemente brauchen.
Lassen Sie uns den Algorithmus zum Erstellen einer virtuellen Maschine und zum Verbinden mit dem Netzwerk und dem dauerhaften Speicher in Openstack durchgehen.
- Wenn Sie eine Anforderung zum Erstellen eines Computers erstellen, sei es eine Anforderung über Horizon (Dashboard) oder eine Anforderung über die CLI, geschieht als Erstes Ihre Anforderungsautorisierung für Keystone. Können Sie einen Computer erstellen, haben oder das Recht, dieses Netzwerk zu verwenden, haben Sie genug? Entwurf von Quoten usw.
- Keystone authentifiziert Ihre Anfrage und generiert in der Antwortnachricht ein Authentifizierungstoken, das später verwendet wird. Nach Erhalt einer Antwort von Keystone wird die Anfrage an Nova (nova api) gesendet.
- Nova-api , Keystone, auth-
- Keystone auth- .
- Nova-api nova-database VM nova-scheduler.
- Nova-scheduler ( ), VM , . VM nova-database.
- nova-scheduler nova-compute . Nova-compute nova-conductor (nova-conductor nova, nova-database nova-compute, nova-database ).
- Nova-conductor nova-database nova-compute.
- nova-compute glance ID . Glace Keystone .
- Nova-compute neutron . glance, neutron Keystone, database ( ), nova-compute.
- Nova-compute cinder volume. glance, cider Keystone, volume .
- Nova-compute libvirt .
Tatsächlich wird eine scheinbar einfache Operation zum Erstellen einer einfachen virtuellen Maschine zu einem solchen Strudel von API-Aufrufen zwischen Elementen der Cloud-Plattform. Darüber hinaus bestehen, wie Sie sehen, auch die zuvor festgelegten Dienste aus kleineren Komponenten, zwischen denen eine Interaktion stattfindet. Das Erstellen eines Computers ist nur ein kleiner Teil dessen, was die Cloud-Plattform Ihnen bietet. Es gibt einen Dienst, der für den Datenausgleich zuständig ist, einen Dienst, der für die Blockspeicherung zuständig ist, einen Dienst, der für DNS zuständig ist, einen Dienst, der für die Bereitstellung von Bare-Metal-Servern zuständig ist usw. Die Cloud ermöglicht dies Sie behandeln Ihre virtuellen Maschinen wie eine Schafherde (im Gegensatz zur Virtualisierung). Wenn in einer virtuellen Umgebung etwas mit Ihrem Computer passiert ist - Sie stellen es aus Sicherungen usw. wieder her -, werden Cloud-Anwendungen auf diese Weise erstellt:Damit die virtuelle Maschine keine so wichtige Rolle spielt - die virtuelle Maschine "starb" - spielt es keine Rolle - wird einfach eine neue Maschine basierend auf der Vorlage erstellt, und wie sie sagen, hat der Trupp den Verlust eines Soldaten nicht bemerkt. Dies sorgt natürlich für das Vorhandensein von Orchestrierungsmechanismen. Mithilfe von Heat-Vorlagen können Sie problemlos eine komplexe Funktion aus Dutzenden von Netzwerken und virtuellen Maschinen bereitstellen.
Es ist immer zu beachten, dass es keine Cloud-Infrastruktur ohne Netzwerk gibt - jedes Element interagiert auf die eine oder andere Weise mit anderen Elementen über das Netzwerk. Darüber hinaus verfügt die Cloud über ein vollständig nicht statisches Netzwerk. Natürlich ist das Unterlagennetzwerk noch mehr oder weniger statisch - neue Knoten und Switches werden nicht jeden Tag hinzugefügt, die Überlagerungskomponente kann und wird sich jedoch ständig ändern - neue Netzwerke werden hinzugefügt oder entfernt, neue virtuelle Maschinen werden angezeigt und alte sterben ab. Und wie Sie sich aus der Definition der Cloud am Anfang des Artikels erinnern, sollten Ressourcen dem Benutzer automatisch und mit dem geringsten (oder besser ohne) Eingreifen des Dienstanbieters zugewiesen werden. Das heißt, die Art der Bereitstellung von Netzwerkressourcen,Dies ist jetzt ein Frontend in Form Ihres persönlichen Kontos, auf das über http / https zugegriffen werden kann, und der diensthabende Netzwerktechniker Vasily als Backend - dies ist keine Cloud, selbst wenn Vasily acht Hände hat.
Als Netzwerkdienst bietet Neutron eine API zur Verwaltung des Netzwerkteils der Cloud-Infrastruktur. Der Dienst stellt den Zustand und die Verwaltung des Openstack-Netzwerkabschnitts bereit, indem eine Abstraktionsschicht namens Network-as-a-Service (NaaS) bereitgestellt wird. Das heißt, das Netzwerk ist dieselbe virtuelle messbare Einheit wie beispielsweise virtuelle CPU-Kerne oder RAM.
Bevor wir jedoch zur OpenStack-Netzwerkarchitektur übergehen, werfen wir einen Blick darauf, wie OpenStack-Netzwerke funktionieren und warum das Netzwerk ein wichtiger und integraler Bestandteil der Cloud ist.
Wir haben also zwei virtuelle RED-Client-Maschinen und zwei virtuelle GREEN-Client-Maschinen. Angenommen, diese Maschinen befinden sich auf zwei Hypervisoren wie folgt:
Im Moment ist dies nur die Virtualisierung von 4 Servern und nichts weiter, da wir bisher nur 4 Server virtualisiert und auf zwei physischen Servern platziert haben. Und bis jetzt sind sie noch nicht einmal mit dem Netzwerk verbunden.
Um eine Cloud zu erhalten, müssen mehrere Komponenten hinzugefügt werden. Zuerst virtualisieren wir den Netzwerkteil - wir müssen diese 4 Maschinen paarweise verbinden, und die Clients möchten genau die L2-Verbindung. Sie können den Switch verwenden und einen Trunk in seine Richtung einrichten und alles über die Linux-Bridge oder für fortgeschrittenere OpenVswitch-Benutzer verwalten (wir werden darauf zurückkommen). Es kann jedoch viele Netzwerke geben, und es ist nicht die beste Idee, L2 ständig durch einen Switch zu schieben. Unterschiedliche Abteilungen, Service Desk, monatelanges Warten auf die Ausführung einer Anwendung, wochenlange Fehlerbehebung - dieser Ansatz funktioniert in der modernen Welt nicht. Und je früher das Unternehmen dies erkennt, desto einfacher ist es, voranzukommen. Daher wählen wir zwischen den Hypervisoren ein L3-Netzwerk aus, über das unsere virtuellen Maschinen kommunizieren, und bauen bereits über diesem L3-Netzwerk virtuelle überlagerte L2-Netzwerke (Overlay-Netzwerke) auf.wo der Verkehr unserer virtuellen Maschinen laufen wird. GRE, Geneve oder VxLAN können als Kapselung verwendet werden. Lassen Sie uns vorerst auf Letzteres eingehen, obwohl es nicht besonders wichtig ist.
Wir müssen VTEP irgendwo lokalisieren (ich hoffe, jeder kennt die VxLAN-Terminologie). Da das L3-Netzwerk die Server sofort verlässt, hindert uns nichts daran, VTEP auf den Servern selbst zu platzieren, und OVS (OpenvSwitch) kann dies perfekt. Als Ergebnis haben wir die folgende Konstruktion erhalten:
Da der Verkehr zwischen VMs aufgeteilt werden muss, haben die Ports zu den virtuellen Maschinen unterschiedliche VLAN-Nummern. 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.
Jetzt können wir unsere Maschinen und virtuellen Netzwerke problemlos für sie produzieren.
Was ist jedoch, wenn der Client über einen anderen Computer verfügt, sich jedoch in einem anderen Netzwerk befindet? Wir müssen zwischen Netzwerken verwurzeln. Wir werden eine einfache Option analysieren, wenn zentrales Rooting verwendet wird - das heißt, der Datenverkehr wird über spezielle dedizierte Netzwerkknoten geleitet (in der Regel werden sie mit Steuerknoten kombiniert, sodass wir dasselbe haben).
Es scheint nichts Kompliziertes zu sein - wir erstellen eine Bridge-Schnittstelle auf dem Steuerknoten, leiten den Verkehr dorthin und leiten ihn von dort dorthin, wo wir ihn benötigen. Das Problem ist jedoch, dass der RED-Client das 10.0.0.0/24-Netzwerk und der GREEN-Client das 10.0.0.0/24-Netzwerk verwenden möchte. Das heißt, der Schnittpunkt von Adressräumen beginnt. Darüber hinaus möchten Clients nicht, dass andere Clients an ihre internen Netzwerke weitergeleitet werden, was logisch ist. Um die Netzwerke und den Datenverkehr von Kundendaten zu trennen, weisen wir jedem von ihnen einen eigenen Namespace zu. Der Namespace ist in der Tat eine Kopie des Linux-Netzwerkstapels, dh Clients im Namespace RED sind vollständig von Clients aus dem Namespace GREEN isoliert (entweder ist das Routing zwischen diesen Client-Netzwerken über den Standard-Namespace oder bereits auf dem Upstream-Transportgerät zulässig).
Das heißt, wir erhalten das folgende Schema:
L2-Tunnel konvergieren von allen Rechenknoten zum Steuerknoten. Der Knoten, an dem sich die L3-Schnittstelle für diese Netzwerke befindet, jeweils in einem dedizierten Namespace zur Isolierung.
Das Wichtigste haben wir jedoch vergessen. Die virtuelle Maschine muss dem Client einen Dienst bereitstellen, dh sie muss über mindestens eine externe Schnittstelle verfügen, über die sie erreichbar ist. Das heißt, wir müssen in die Außenwelt hinausgehen. Hier gibt es verschiedene Möglichkeiten. Lassen Sie uns die einfachste Option machen. Fügen wir Clients in einem Netzwerk hinzu, die im Netzwerk des Anbieters gültig sind und sich nicht mit anderen Netzwerken überschneiden. Die Netzwerke können sich auch überschneiden und verschiedene VRFs auf der Seite des Anbieternetzwerks betrachten. Diese Netzwerke befinden sich auch im Namespace jedes Clients. Sie werden jedoch weiterhin über eine physische (oder logischere) Schnittstelle in die Außenwelt eintreten. Um den Client-Verkehr zu trennen, wird der nach außen gerichtete Verkehr mit einem dem Client zugewiesenen VLAN-Tag gekennzeichnet.
Als Ergebnis haben wir das folgende Schema erhalten:
Eine vernünftige Frage - warum nicht Gateways auf den Rechenknoten selbst erstellen? Dies ist kein großes Problem. Wenn Sie den Distributed Router (DVR) einschalten, funktioniert dies außerdem. In diesem Szenario betrachten wir die einfachste Option mit einem zentralisierten Gateway, die in Openstack die Standardeinstellung ist. Für Hochlastfunktionen werden sie sowohl einen verteilten Router als auch Beschleunigungstechnologien wie SR-IOV und Passthrough verwenden, aber wie sie sagen, ist dies eine ganz andere Geschichte. Lassen Sie uns zuerst den grundlegenden Teil behandeln und dann auf Details eingehen.
Eigentlich ist unser System bereits in Betrieb, aber es gibt einige Nuancen:
- Wir müssen unsere Maschinen irgendwie schützen, dh einen Filter an der Switch-Schnittstelle in Richtung Client aufhängen.
- Ermöglichen Sie einer virtuellen Maschine, automatisch eine IP-Adresse abzurufen, damit Sie diese nicht jedes Mal über die Konsole eingeben und die Adresse registrieren müssen.
Beginnen wir mit dem Schutz der Maschinen. Dafür können Sie banale iptables verwenden, warum nicht.
Das heißt, jetzt ist unsere Topologie etwas komplizierter geworden:
Gehen wir weiter. Wir müssen einen DHCP-Server hinzufügen. Der idealste Ort für den Standort von DHCP-Servern für jeden der Clients ist der bereits oben erwähnte Steuerknoten, an dem sich die Namespaces befinden:
Es gibt jedoch ein kleines Problem. Was passiert, wenn alles neu gestartet wird und alle Informationen zum Leasing von DHCP-Adressen verschwinden? Es ist logisch, dass neue Adressen an Maschinen vergeben werden, was nicht sehr praktisch ist. Hier gibt es zwei Möglichkeiten: Verwenden Sie entweder Domänennamen und fügen Sie für jeden Client einen DNS-Server hinzu. Dann ist die Adresse für uns nicht sehr wichtig (analog zum Netzwerkteil in k8s). Es gibt jedoch ein Problem mit externen Netzwerken, da in diesen auch Adressen vergeben werden können über DHCP - Sie müssen mit DNS-Servern in der Cloud-Plattform und einem externen DNS-Server synchronisieren, was meiner Meinung nach nicht sehr flexibel, aber durchaus möglich ist. Oder die zweite Option besteht darin, Metadaten zu verwenden, dh Informationen über die an den Computer ausgegebene Adresse zu speichern, damit der DHCP-Server weiß, welche Adresse an den Computer ausgegeben werden soll, wenn der Computer bereits eine Adresse erhalten hat. Die zweite Option ist einfacher und flexibler, da Sie zusätzliche Informationen zum Auto speichern können.Fügen Sie nun die Agentenmetadaten zum Schema hinzu:
Ein weiteres Problem, das ebenfalls geheiligt werden sollte, ist die Möglichkeit, ein externes Netzwerk für alle Clients zu verwenden, da externe Netzwerke, wenn sie im gesamten Netzwerk gültig sein sollen, komplex sind - Sie müssen die Zuweisung dieser Netzwerke ständig zuweisen und steuern. Die Möglichkeit, ein einziges externes vorkonfiguriertes Netzwerk für alle Clients zu verwenden, ist beim Erstellen einer öffentlichen Cloud sehr nützlich. Dies erleichtert die Bereitstellung von Computern, da wir die Adressdatenbank nicht überprüfen und einen eindeutigen Adressraum für das externe Netzwerk jedes Clients auswählen müssen. Darüber hinaus können wir ein externes Netzwerk im Voraus registrieren und zum Zeitpunkt der Bereitstellung müssen wir nur externe Adressen mit Clientcomputern verknüpfen.
Und hier kommt NAT zur Rettung - wir ermöglichen es Clients lediglich, mithilfe der NAT-Übersetzung über den Standard-Namespace nach außen zu gelangen. Hier ist ein kleines Problem. Es ist gut, wenn der Client-Server als Client und nicht als Server fungiert - das heißt, er initiiert Verbindungen, anstatt sie zu akzeptieren. Aber bei uns wird es umgekehrt sein. In diesem Fall müssen wir Ziel-NAT ausführen, damit der Steuerknoten beim Empfang von Datenverkehr versteht, dass dieser Datenverkehr für die virtuelle Maschine A von Client A bestimmt ist. Dies bedeutet, dass wir eine NAT-Übersetzung von einer externen Adresse, z. B. 100.1.1.1, in eine interne Adresse 10.0.0.1 durchführen müssen. In diesem Fall bleibt die interne Isolation vollständig erhalten, obwohl alle Clients dasselbe Netzwerk verwenden. Das heißt, wir müssen dNAT und sNAT auf dem Steuerknoten erstellen.Verwenden Sie ein einzelnes Netzwerk mit der Zuweisung von schwebenden Adressen oder externen Netzwerken oder beiden gleichzeitig - aufgrund der Tatsache, dass Sie in die Cloud ziehen möchten. Wir werden dem Diagramm keine schwebenden Adressen hinzufügen, aber wir werden die bereits zuvor hinzugefügten externen Netzwerke belassen - jeder Client hat sein eigenes externes Netzwerk (im Diagramm werden sie auf der externen Schnittstelle als vlan 100 und 200 bezeichnet).
Als Ergebnis haben wir eine interessante und gleichzeitig gut durchdachte Lösung erhalten, die eine gewisse Flexibilität aufweist, aber bisher keine Fehlertoleranzmechanismen aufweist.
Erstens haben wir nur einen Steuerknoten - sein Ausfall führt zum Zusammenbruch aller Systeme. Um dieses Problem zu beheben, müssen Sie mindestens 3 Knoten beschließen. Fügen wir dies dem Diagramm hinzu:
Natürlich sind alle Knoten synchronisiert, und wenn der aktive Knoten beendet wird, übernimmt ein anderer Knoten seine Verantwortung.
Das nächste Problem sind Festplatten der virtuellen Maschine. Im Moment werden sie auf den Hypervisoren selbst gespeichert, und bei Problemen mit dem Hypervisor verlieren wir alle Daten - und das Vorhandensein eines Überfalls hilft hier in keiner Weise, wenn wir nicht die Festplatte, sondern den gesamten Server verlieren. Dazu müssen wir einen Service erstellen, der als Frontend für einige Speicher dient. Welche Art von Speicher es sein wird, ist für uns nicht besonders wichtig, aber es sollte unsere Daten vor einem Ausfall sowohl der Festplatte als auch des Knotens und möglicherweise des gesamten Schranks schützen. Hier gibt es mehrere Möglichkeiten - natürlich gibt es SAN-Netzwerke mit Fibre Channel, aber seien wir ehrlich - FC ist bereits ein Relikt der Vergangenheit - ein Analogon von E1 im Transportwesen - ja, ich stimme zu, es wird immer noch verwendet, aber nur dort, wo es ohne es absolut unmöglich ist. Daher würde ich das FC-Netzwerk 2020 nicht freiwillig bereitstellen, da ich weiß, dass es andere interessantere Alternativen gibt.Obwohl für jeden sein eigenes und vielleicht auch für diejenigen, die glauben, dass der FC mit all seinen Einschränkungen alles ist, was wir brauchen - ich werde nicht argumentieren, jeder hat seine eigene Meinung. Die meiner Meinung nach interessanteste Lösung ist jedoch die Verwendung von Sicherheitsdatenblättern, zum Beispiel Ceph.
Ceph kann Sie bauen vyskodostupnoe Speicherlösung mit einer Reihe von Optionen für Redundanz, da die Codeparität (analog RAID 5 oder 6) mit einer vollständigen Replikation von Daten über mehrere Festplatten basierten Disk - Standort - Server beenden und Server in den Schränken und so weiter.
Für Die Ceph-Assembly benötigt 3 weitere Knoten. Die Interaktion mit dem Speicher erfolgt auch über das Netzwerk mithilfe von Block-, Objekt- und Dateispeicherdiensten. Fügen Sie dem Schema Speicher hinzu:
: compute — — storage+compute — ceph storage. — SDS . — — storage ( ) — CPU SDS ( , , ). compute storage.All dies muss irgendwie verwaltet werden - wir brauchen etwas, über das wir eine Maschine, ein Netzwerk, einen virtuellen Router usw. erstellen können. Fügen Sie dazu dem Steuerknoten einen Dienst hinzu, der als Dashboard fungiert. Der Client kann über http / eine Verbindung zu diesem Portal herstellen. https und mach was es braucht (na ja, fast).
Als Ergebnis haben wir jetzt ein fehlertolerantes System. Alle Elemente dieser Infrastruktur müssen irgendwie verwaltet werden. Es wurde bereits beschrieben, dass Openstack eine Reihe von Projekten ist, von denen jedes eine bestimmte Funktion bietet. Wie wir sehen können, müssen mehr als genug Elemente konfiguriert und gesteuert werden. Heute werden wir über den Netzwerkteil sprechen.
Neutronenarchitektur
In OpenStack ist Neutron dafür verantwortlich, die Ports virtueller Maschinen mit einem gemeinsamen L2-Netzwerk zu verbinden, das Routing des Datenverkehrs zwischen VMs in verschiedenen L2-Netzwerken sicherzustellen sowie nach außen zu routen und Dienste wie NAT, Floating IP, DHCP usw. bereitzustellen. Der
Betrieb des Netzwerkdienstes auf hoher Ebene ( Basisteil) kann wie folgt beschrieben werden.
Beim Starten der VM wird der Netzwerkdienst:
- 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).
- VM stellt eine Verbindung zu dem in Schritt 1 erstellten Port (den Ports) her.
Seltsamerweise, aber im Zentrum von Neutrons Arbeit stehen Standardmechanismen, die jedem bekannt sind, der jemals in Linux eingestiegen ist - dies sind Namespaces, Iptables, Linux-Bridges, OpenVswitch, Conntrack usw.
Es sollte sofort klargestellt werden, dass Neutron kein SDN-Controller ist.
Neutron besteht aus mehreren miteinander verbundenen Komponenten:
Openstack-Neutron-Server ist ein Daemon, der mit Benutzeranforderungen über eine API arbeitet. Dieser Daemon schreibt keine Netzwerkkonnektivität vor, gibt jedoch die erforderlichen Informationen an seine Plugins weiter, die dann das erforderliche Netzwerkelement konfigurieren. Neutronenagenten auf OpenStack-Knoten registrieren sich beim Neutronenserver.
Neutron-Server ist eigentlich eine in Python geschriebene Anwendung, die aus zwei Teilen besteht:
- REST-Service
- Neutronen-Plugin (Kern / Service)
Ein REST-Service ist so konzipiert, dass er API-Aufrufe von anderen Komponenten empfängt (z. B. eine Anforderung zur Bereitstellung einiger Informationen usw.).
Plugins sind Plug-in-Softwarekomponenten / -module, die auf API-Anforderungen aufgerufen werden, dh über diese wird ein Service zugewiesen. Plugins werden in zwei Typen unterteilt - Service und Root. In der Regel ist das Horse-Plug-In hauptsächlich für die Verwaltung des Adressraums und der L2-Verbindungen zwischen VMs verantwortlich, und die Service-Plug-Ins bieten bereits zusätzliche Funktionen wie VPN oder FW.
Die Liste der heute verfügbaren Plugins kann zum Beispiel hier eingesehen werden. Es gibt
möglicherweise mehrere Service-Plugins, aber nur ein Pferde-Plugin.
Openstack-Neutron-ml2Ist das Standard-Openstack-Root-Plugin. Dieses Plug-In hat eine modulare Architektur (im Gegensatz zu seinem Vorgänger) und konfiguriert den Netzwerkdienst über die mit ihm verbundenen Treiber. Wir werden das Plugin selbst etwas später betrachten, da es tatsächlich die Flexibilität bietet, die OpenStack im Netzwerkteil hat. Das Root-Plugin kann ersetzt werden (z. B. macht Contrail Networking einen solchen Ersatz).
RPC-Dienst (rabbitmq-server) - Ein Dienst, der die Verwaltung von Warteschlangen und die Kommunikation mit anderen OpenStack-Diensten sowie die Kommunikation zwischen Netzwerkdienstagenten ermöglicht.
Netzwerkagenten - Agenten, die sich in jedem Knoten befinden, über den Netzwerkdienste konfiguriert werden.
Es gibt verschiedene Arten von Agenten.
Der Hauptagent istL2-Agent . Diese Agenten werden auf jedem der Hypervisoren ausgeführt, einschließlich der Steuerknoten (genauer gesagt auf allen Knoten, die einen Dienst für Mandanten bereitstellen). Ihre Hauptfunktion besteht darin, virtuelle Maschinen mit einem gemeinsamen L2-Netzwerk zu verbinden und Warnungen zu generieren, wenn Ereignisse auftreten (z. B.) Port deaktivieren / aktivieren).
Der nächste, nicht weniger wichtige Agent ist der L3-Agent... Standardmäßig wird dieser Agent ausschließlich auf einem Netzwerkknoten ausgeführt (häufig wird ein Netzwerkknoten mit einem Steuerknoten kombiniert) und bietet Routing zwischen Mandantennetzwerken (sowohl zwischen seinen Netzwerken als auch Netzwerken anderer Mandanten). Er steht der Außenwelt zur Verfügung und stellt NAT- und DHCP-Dienste bereit. Bei Verwendung eines DVR (Distributed Router) wird die Notwendigkeit eines L3-Plugins jedoch auch auf Rechenknoten angezeigt.
Der L3-Agent verwendet Linux-Namespaces, um jedem Mandanten eine Reihe eigener isolierter Netzwerke und die Funktionalität virtueller Router bereitzustellen, die den Datenverkehr weiterleiten und Gateway-Dienste für Layer 2-Netzwerke bereitstellen.
Datenbank - Eine Datenbank mit Kennungen von Netzwerken, Subnetzen, Ports, Pools usw.
Tatsächlich akzeptiert Neutron API-Anforderungen aus der Erstellung von Netzwerkeinheiten, authentifiziert die Anforderung und sendet über RPC (wenn es an ein Plugin oder einen Agenten adressiert) oder die REST-API (wenn in SDN kommuniziert) Agenten (über Plugins) die Anweisungen, die zum Organisieren des angeforderten Dienstes erforderlich sind ...
Wenden wir uns nun der Testinstallation zu (wie sie bereitgestellt wird und was sie später im praktischen Teil enthält) und sehen, wo sich welche Komponente befindet:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Eigentlich ist das die gesamte Struktur von Neutron. Jetzt lohnt es sich, sich etwas Zeit für das ML2-Plugin zu nehmen.
Modulare Schicht 2
Wie oben erwähnt, ist das Plugin ein Standard-OpenStack-Root-Plugin und verfügt über eine modulare Architektur.
Der Vorgänger des ML2-Plug-Ins hatte eine monolithische Struktur, die es beispielsweise nicht erlaubte, mehrere Technologien in einer Installation zu mischen. Beispielsweise könnten Sie nicht sowohl openvswitch als auch linuxbridge gleichzeitig verwenden - weder die erste noch die zweite. Aus diesem Grund wurde das ML2-Plugin mit seiner Architektur erstellt.
ML2 besteht aus zwei Komponenten - zwei Arten von Treibern: Typentreibern und Mechanismus-Treibern.
Typ Treiber definiert die Technologien , die verwendet werden , Netzwerkkonnektivität zu organisieren, wie VXLAN, VLAN, GRE. In diesem Fall können Sie mit dem Treiber verschiedene Technologien verwenden. Die Standardtechnologie ist die VxLAN-Kapselung für Overlay-Netzwerke und externe VLAN-Netzwerke.
Zu den Typentreibern gehören die folgenden Netzwerktypen:
Flat - ein Netzwerk ohne Tagging-
VLAN - ein getaggtes Netzwerk
Local - ein spezieller Netzwerktyp für All-in-One-Installationen (solche Installationen werden entweder für Entwickler oder für Schulungen benötigt)
GRE - Overlay-Netzwerk mit GRE
VxLAN- Tunneln - Overlay-Netzwerk mit VxLAN-Tunneln
Mechanism-Treiber definieren die Mittel, die die Organisation der im Typentreiber angegebenen Technologien ermöglichen - z. B. openvswitch, sr-iov, opendaylight, OVN usw.
Abhängig von der Implementierung dieses Treibers werden entweder von Neutron gesteuerte Agenten verwendet oder Verbindungen mit einem externen SDN-Controller verwendet, der sich um alle Probleme beim Organisieren von L2-Netzwerken, beim Routing usw. kümmert.
Beispiel Wenn wir ML2 zusammen mit OVS verwenden, dann weiter Jeder Rechenknoten ist mit einem L2-Agenten eingerichtet, der das OVS verwaltet. Wenn wir jedoch beispielsweise OVN oder OpenDayLight verwenden, fällt die OVS-Steuerung in ihre Zuständigkeit - Neutron gibt dem Controller Befehle über das Root-Plugin und er tut bereits, was ihm gesagt wurde.
Lassen Sie uns unser Gedächtnis auffrischen Open vSwitch
Derzeit ist Open vSwitch eine der Schlüsselkomponenten von OpenStack.
Wenn Sie OpenStack ohne SDN eines zusätzlichen Anbieters wie Juniper Contrail oder Nokia Nuage installieren, ist OVS die Hauptnetzwerkkomponente des Cloud-Netzwerks und ermöglicht Ihnen zusammen mit iptables, conntrack und Namespaces die Organisation eines vollwertigen Overlay-Netzwerks mit Mandantenfähigkeit. Natürlich kann diese Komponente beispielsweise ersetzt werden, wenn proprietäre (Hersteller-) SDN-Lösungen von Drittanbietern verwendet werden.
OVS ist ein Open Source-Software-Switch, der für die Verwendung in virtualisierten Umgebungen als Weiterleitung für den virtuellen Datenverkehr entwickelt wurde.
Derzeit verfügt OVS über eine sehr anständige Funktionalität, die Technologien wie QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK usw. umfasst.
Hinweis: OVS war ursprünglich nicht als Soft-Switch für Telekommunikationsfunktionen mit hoher Last konzipiert und wurde eher für weniger bandbreitenintensive IT-Funktionen wie einen WEB-Server oder einen Mailserver entwickelt. OVS wird jedoch fertiggestellt, und die aktuellen OVS-Implementierungen haben seine Leistung und Funktionen erheblich verbessert, sodass es von Telekommunikationsbetreibern mit Hochlastfunktionen verwendet werden kann. Beispielsweise gibt es eine OVS-Implementierung mit DPDK-Beschleunigungsunterstützung.
Es sind drei wichtige OVS-Komponenten zu beachten:
- Kernel - Modul - eine Komponente im KernelSpace befindetdie TrafficProzesse basierend auf den Regeln von der Steuer empfangen;
- vSwitch daemon (ovs-vswitchd) — , user space, kernel —
- Database server — , , OVS, . OVSDB SDN .
All dies wird auch von einer Reihe von Diagnose- und Verwaltungsdienstprogrammen begleitet, wie z. B. ovs-vsctl, ovs-appctl, ovs-ofctl usw.
Derzeit wird Openstack von Telekommunikationsbetreibern häufig verwendet, um Netzwerkfunktionen wie EPC, SBC, HLR darauf zu migrieren usw. Einige Funktionen können problemlos mit OVS in der Form arbeiten, in der es sich befindet. Beispielsweise verarbeitet EPC den Teilnehmerverkehr - das heißt, es leitet eine große Menge an Verkehr durch sich selbst (jetzt erreichen die Verkehrsmengen mehrere hundert Gigabit pro Sekunde). Natürlich ist es nicht die beste Idee, solchen Datenverkehr durch den Kernelbereich zu leiten (da sich die Weiterleitung standardmäßig dort befindet). Daher wird OVS häufig mithilfe der DPDK-Beschleunigungstechnologie vollständig im Benutzerbereich bereitgestellt, um Datenverkehr von der Netzwerkkarte unter Umgehung des Kernels an den Benutzerbereich weiterzuleiten.
Hinweis: Für eine Cloud, die für Telekommunikationsfunktionen bereitgestellt wird, ist es möglich, Datenverkehr vom Rechenknoten unter Umgehung von OVS direkt an die Vermittlungsausrüstung auszugeben. Zu diesem Zweck werden die Mechanismen SR-IOV und Passthrough verwendet.
Wie funktioniert es in einem realen Layout?
Nun gehen wir zum praktischen Teil über und sehen, wie das alles in der Praxis funktioniert.
Beginnen wir mit der Bereitstellung einer einfachen Openstack-Installation. Da ich keine Reihe von Servern für Experimente zur Verfügung habe, werden wir das Layout auf einem physischen Server aus virtuellen Maschinen zusammenstellen. Ja, natürlich ist eine solche Lösung nicht für kommerzielle Zwecke geeignet. Um jedoch ein Beispiel für die Funktionsweise des Netzwerks in Openstack zu betrachten, reicht eine solche Installation für die Augen aus. Darüber hinaus ist eine solche Installation zu Schulungszwecken noch interessanter - da Sie Verkehr usw. auffangen können.
Da wir nur den grundlegenden Teil sehen müssen, können wir nicht mehrere Netzwerke verwenden, sondern alles mit nur zwei Netzwerken erhöhen, und das zweite Netzwerk in diesem Layout wird ausschließlich für den Zugriff auf den Undercloud- und DNS-Server verwendet. Wir werden vorerst nicht auf externe Netzwerke eingehen - dies ist ein Thema für einen separaten großen Artikel.
Fangen wir also in der richtigen Reihenfolge an. Zunächst eine kleine Theorie. Wir werden Openstack mit TripleO (Openstack on Openstack) installieren. Das Wesentliche von TripleO ist, dass wir einen Openstack All-in-One (dh auf einem Knoten) installieren, der als undercloud bezeichnet wird, und dann die Funktionen des bereitgestellten Openstacks verwenden, um einen zur Ausnutzung bestimmten Openstack zu installieren, der als overcloud bezeichnet wird. Undercloud wird die inhärente Fähigkeit zur Verwaltung physischer Server (Bare Metal) - das Ironic-Projekt - zur Bereitstellung von Hypervisoren nutzen, die als Rechen-, Steuerungs- und Speicherknoten fungieren. Das heißt, wir verwenden keine Tools von Drittanbietern, um Openstack bereitzustellen - wir stellen Openstack mit Openstack bereit. Weiter entlang der Installation wird es viel klarer, so dass wir dort nicht anhalten und weitermachen werden.
: Openstack, . — , , . . ceph ( ) (Storage management Storage) , , QoS , . .
Hinweis: Da wir virtuelle Maschinen in einer virtuellen Umgebung ausführen, die auf virtuellen Maschinen basiert, müssen wir zuerst die verschachtelte Virtualisierung aktivieren.
Sie können überprüfen, ob die verschachtelte 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 wir die Unterstützung für verschachtelte Virtualisierung gemäß einer Anleitung, die Sie im Netzwerk finden, zum Beispiel dieser .
Wir müssen das folgende Schema aus virtuellen Maschinen zusammenstellen:
In meinem Fall habe ich OpenvSwitch für die Konnektivität der virtuellen Maschinen verwendet, die Teil der zukünftigen Installation sind (und ich habe 7 davon, aber Sie können mit 4 auskommen, wenn Sie nicht viele Ressourcen haben). Ich habe eine Ovs-Bridge erstellt und virtuelle Maschinen über Portgruppen damit verbunden. Zu diesem Zweck habe ich eine XML-Datei in der folgenden Form erstellt:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Hier werden drei Ports der Gruppe deklariert - zwei Zugriffs- und ein Trunk (letzterer wurde für einen DNS-Server benötigt, aber Sie können darauf verzichten oder ihn auf dem Host-Computer auslösen - das ist alles, was für Sie bequemer ist). Als nächstes erklären wir anhand dieser Vorlage, dass unsere über virsh net-define ist:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Bearbeiten wir nun die Konfiguration 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 ist die Adresse am Port ovs-br1 nicht verfügbar, da kein vlan-Tag vorhanden ist. Um dies zu beheben, geben Sie den Befehl sudo ovs-vsctl set port ovs-br1 tag = 100 ein. Nach einem Neustart verschwindet dieses Tag jedoch (wenn jemand weiß, wie er an Ort und Stelle bleibt, bin ich sehr dankbar). Dies ist jedoch nicht so wichtig, da diese Adresse nur für die Installationszeit benötigt wird und nicht benötigt wird, wenn Openstack vollständig bereitgestellt ist.Als nächstes erstellen wir ein Unterwolkenauto:
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=ttyS0Während der Installation stellen Sie alle erforderlichen Parameter ein, wie z. B. den Computernamen, Kennwörter, Benutzer, NTP-Server usw. Sie können die Ports sofort konfigurieren. Nach der Installation ist es für mich jedoch einfacher, über die Konsole auf den Computer zuzugreifen und die erforderlichen Dateien zu korrigieren. Wenn Sie bereits ein fertiges Image haben, können Sie es verwenden oder wie ich es tun - laden Sie das minimale Centos 7-Image herunter und installieren Sie die VM damit.
Nach erfolgreicher Installation sollten Sie über eine virtuelle Maschine verfügen, auf die Sie eine Unterwolke setzen können
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningZunächst installieren wir die während des Installationsvorgangs erforderlichen Tools:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud installieren
Erstellen Sie einen Stack-Benutzer, legen Sie ein Kennwort fest, fügen Sie es sudoer hinzu und geben Sie ihm die Möglichkeit, Root-Befehle über sudo auszuführen, ohne ein Kennwort eingeben zu müssen:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackJetzt geben wir den vollständigen Namen undercloud in der Hosts-Datei an:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Fügen Sie als Nächstes die Repositorys hinzu und installieren Sie 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 vorhaben, ceph zu installieren, müssen Sie keine ceph-bezogenen Befehle eingeben. Ich habe die Queens-Version verwendet, aber Sie können verwenden, was Sie möchten.Kopieren Sie als Nächstes die Undercloud-Konfigurationsdatei in das Stack-Home-Verzeichnis des Benutzers:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confJetzt müssen wir diese Datei reparieren, indem wir sie an unsere Installation anpassen.
Fügen Sie am Anfang der Datei die folgenden Zeilen hinzu:
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 = 10Gehen Sie also die Einstellungen durch:
undercloud_hostname - vollständiger undercloud-Servername muss mit dem Eintrag im DNS-Server
local_ip übereinstimmen - lokale Adresse undercloud zur Bereitstellung des Netzwerks
network_gateway - dieselbe lokale Adresse, die während der Installation als Gateway für den Zugriff auf die Außenwelt dient zuziehen Knoten, passt auch lokale IP
undercloud_public_host - externe API - Adresse, der jede freie Adresse aus dem Provisioning - Netzwerk zugewiesen
undercloud_admin_host interne API - Adresse, der jede freie Adresse aus den Provisioning - Netzwerk zugewiesen
undercloud_nameservers - DNS - Server
generate_service_certificate- Diese Zeile ist im aktuellen Beispiel sehr wichtig, da das Problem auf der Red Hat Bug Tracker- Schnittstelle
local_interface in der Netzwerkbereitstellung beschrieben wird, wenn sie nicht auf false gesetzt ist. Während der Installation wird ein Fehler angezeigt . Diese Schnittstelle wird während der Bereitstellung von undercloud neu konfiguriert, sodass Sie zwei Schnittstellen in
undercloud benötigen - eine für den Zugriff und eine für die Bereitstellung von local_mtu - MTU. Da wir ein Testlabor und eine MTU haben, habe ich 1.500 Ports OVS Svicha, ist es notwendig, 1450 einen Wert einzugeben, der in VxLAN-Paketen gekapselt wäre.
Network_cidr - Provisioning Network
Masquerade - die Verwendung von NAT für den Zugriff auf das externe Netzwerk
masquerade_network - ein Netzwerk, das NAT wird -sya
dhcp_start - Die Startadresse des Adresspools, aus dem Adressen während der Bereitstellungs-Overcloud den Knoten zugewiesen werden.
dhcp_end - Die endgültige Adresse des Adresspools, aus dem den Knoten während der Bereitstellungs-Overcloud
Inspection_iprange Adressen zugewiesen werden )
scheduler_max_attempts - Die maximale Anzahl von Versuchen, Overcloud zu installieren (muss größer oder gleich der Anzahl der Knoten sein).
Nachdem die Datei beschrieben wurde, können Sie den Befehl zum Bereitstellen von Undercloud eingeben :
openstack undercloud install
Der Vorgang dauert je nach Bügeleisen 10 bis 30 Minuten. Letztendlich sollten Sie folgende Ausgabe sehen:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Diese Ausgabe besagt, dass Sie undercloud erfolgreich installiert haben. Jetzt können Sie den Status von undercloud überprüfen und mit der Installation von overcloud fortfahren.
Wenn Sie sich die Ausgabe von ifconfig ansehen, werden Sie feststellen, dass eine neue Bridge-Schnittstelle angezeigt wurde
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Die Overcloud-Bereitstellung wird jetzt über diese Schnittstelle durchgeführt.
Aus der folgenden Ausgabe ist ersichtlich, dass wir alle Dienste auf einem Knoten haben:
(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 |
+--------------------------+-----------+----------+Unten ist die Konfiguration des Undercloud-Netzwerkteils:
(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 ~]$Overcloud-Installation
Im Moment haben wir nur eine Unterwolke und wir haben nicht genügend Knoten, aus denen eine Überwolke aufgebaut wird. Daher werden wir zunächst die benötigten virtuellen Maschinen bereitstellen. Während der Bereitstellung installiert undercloud selbst das Betriebssystem und die erforderliche Software auf dem Overcloud-Computer. Das heißt, wir müssen den Computer nicht vollständig bereitstellen, sondern nur eine Festplatte (oder Festplatten) für ihn erstellen und seine Parameter bestimmen. Das heißt, wir erhalten einen nackten Server ohne installiertes Betriebssystem ...
Wechseln Sie in den Ordner mit den Festplatten unserer virtuellen Maschinen und erstellen Sie Festplatten mit der erforderlichen Größe:
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 von root aus handeln, müssen wir den Besitzer dieser Festplatten ändern, um kein Problem mit den Rechten zu bekommen:
[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 planen, ceph zu installieren, um es zu untersuchen, erstellen Sie mindestens 3 Knoten mit mindestens zwei Festplatten und geben Sie in der Vorlage an, dass virtuelle Festplatten vda, vdb usw. verwendet werden.Großartig, jetzt müssen wir alle 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 stehen die Befehle --print-xml> /tmp/storage-1.xml, mit denen eine XML-Datei mit einer Beschreibung der einzelnen Maschinen im Ordner / tmp / erstellt wird. Wenn Sie diese nicht hinzufügen, können Sie keine virtuellen Maschinen definieren.
Jetzt müssen wir alle 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 State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Jetzt eine kleine Nuance - TripleO verwendet IPMI, um die Server während der Installation und Selbstbeobachtung zu verwalten.
Introspektion ist der Prozess der Inspektion der Hardware, um ihre Parameter zu erhalten, die für die weitere Bereitstellung von Knoten erforderlich sind. Die Selbstbeobachtung erfolgt mit Ironie - einem Dienst, der für die Arbeit mit Bare-Metal-Servern entwickelt wurde.
Hier ist jedoch das Problem: Wenn die IPMI-Eisenserver über einen separaten Port (oder einen gemeinsam genutzten Port, dies ist jedoch nicht wichtig) verfügen, verfügen die virtuellen Maschinen nicht über solche Ports. Hier hilft uns eine Krücke namens vbmc - ein Dienstprogramm, mit dem Sie einen IPMI-Port emulieren können. Diese Nuance ist besonders für diejenigen zu beachten, die ein solches Labor auf einem ESXI-Hypervisor einrichten möchten. Wenn ich natürlich nicht weiß, ob es ein Analogon zu vbmc enthält, sollten Sie sich vor dem Bereitstellen aller Informationen über diese Frage wundern.
Installieren Sie vbmc:
yum install 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 Dienstprogramm. Hier ist alles eine Schande. Jetzt ist es logisch, dass die vbmc-Liste keine Server enthält
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Damit sie angezeigt werden, 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
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Ich denke, die Befehlssyntax ist klar und ohne Erklärung. Derzeit befinden sich jedoch alle unsere Sitzungen im Status AB. Damit sie in den UP-Status wechseln können, müssen Sie sie aktivieren:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Und der letzte Schliff: Sie müssen die Firewall-Regeln korrigieren (gut oder ganz deaktivieren):
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
Gehen wir jetzt zur Unterwolke und überprüfen, ob alles funktioniert. Die Adresse des Hostcomputers lautet 192.168.255.200. Wir haben das erforderliche ipmitool-Paket hinzugefügt, um es während der Vorbereitung für die Bereitstellung zu unterdecken:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningWie Sie sehen, haben wir den Steuerknoten erfolgreich über vbmc gestartet. Schalten Sie es jetzt aus und fahren Sie fort:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Der nächste Schritt ist die Selbstbeobachtung der Knoten, auf denen die Overcloud installiert wird. Dazu müssen wir eine JSON-Datei mit einer Beschreibung unserer Knoten vorbereiten. Beachten Sie, dass die Datei im Gegensatz zur Installation auf Bare-Servern den Port angibt, auf dem vbmc für jeden Computer ausgeführt wird.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Hinweis: Es gibt zwei Schnittstellen auf dem Steuerknoten, aber in diesem Fall spielt es keine Rolle, in dieser Installation reicht eine für uns aus.Jetzt bereiten wir eine JSON-Datei vor. Wir müssen die Mohnadresse des Ports angeben, über den die Bereitstellung durchgeführt wird, die Parameter der Knoten, ihnen Namen geben und angeben, wie sie zu ipmi gelangen:
{
"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 Bilder für die Ironie vorbereiten. Laden Sie sie dazu ü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 ~]$Hochladen von Bildern in die Unterwolke:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Überprüfen Sie, ob alle Bilder geladen sind
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Noch eine Berührung - Sie müssen einen 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 is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Jetzt können wir den Befehl zur Selbstbeobachtung ausgeben:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Wie Sie der Ausgabe entnehmen können, endete alles fehlerfrei. Überprüfen wir, ob alle Knoten 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 | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Wenn sich die Knoten in einem anderen Zustand befinden, der in der Regel verwaltbar ist, ist ein Fehler aufgetreten, und Sie müssen sich das Protokoll ansehen und herausfinden, warum es passiert ist. Beachten Sie, dass in diesem Szenario die Virtualisierung verwendet wird und möglicherweise Fehler im Zusammenhang mit der Verwendung von virtuellen Maschinen oder vbmc auftreten.
Als Nächstes müssen wir angeben, welcher Knoten welche Funktion ausführen soll, dh das Profil angeben, mit dem der Knoten bereitgestellt wird:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Wir geben das Profil für jeden Knoten an:
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 richtig 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 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Wenn alles korrekt ist, geben wir den Befehl zum Bereitstellen von Overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuIn einer realen Installation werden natürlich benutzerdefinierte Vorlagen verwendet. In unserem Fall wird dies den Prozess erheblich verkomplizieren, da jede Änderung in der Vorlage erläutert werden muss. Wie bereits geschrieben, reicht bereits eine einfache Installation aus, um zu sehen, wie es funktioniert.
Hinweis: In diesem Fall ist die Variable --libvirt-type qemu erforderlich, da wir verschachtelte Virtualisierung verwenden. Andernfalls werden keine virtuellen Maschinen ausgeführt.
Jetzt haben Sie ungefähr eine Stunde oder mehr (abhängig von den Fähigkeiten der Hardware) und können nur hoffen, dass Sie nach dieser Zeit die folgende Inschrift sehen:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Jetzt haben Sie eine fast vollwertige Version des Openstacks, mit der Sie studieren, Experimente durchführen usw. können
. Überprüfen Sie, ob alles einwandfrei funktioniert. Im Home-Verzeichnis-Stack des Benutzers befinden sich zwei Dateien - eine stackrc (zum Verwalten von undercloud) und die andere overcloudrc (zum Verwalten von overcloud). Diese Dateien müssen als Quelle angegeben werden, da sie die für die Authentifizierung erforderlichen Informationen enthalten.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Meine Installation erfordert noch eine kleine Berührung - um eine Route auf dem Controller hinzuzufügen, da sich der Computer, mit dem ich arbeite, in einem anderen Netzwerk befindet. Gehen Sie dazu unter dem Heat-Admin-Konto zu control-1 und schreiben Sie die Route
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Nun können Sie zum Horizont gehen. Alle Informationen - Adressen, Benutzername und Passwort - befinden sich in der Datei / home / stack / overcloudrc. Das endgültige Schema sieht folgendermaßen aus:
Übrigens wurden in unserer Installation die Adressen der Maschinen über DHCP ausgegeben, und wie Sie sehen können, werden sie "zufällig" ausgegeben. Sie können in der Vorlage fest codieren, welche Adresse während der Bereitstellung an welchen Computer angehängt werden soll, falls dies erforderlich ist.
Wie fließt der Verkehr zwischen virtuellen Maschinen?
In diesem Artikel werden drei Optionen für das Weiterleiten von Datenverkehr betrachtet
- Zwei Computer auf einem Hypervisor in einem L2-Netzwerk
- Zwei Maschinen auf verschiedenen Hypervisoren in einem L2-Netzwerk
- Zwei Maschinen in unterschiedlichen Netzwerken (Rooting zwischen Netzwerken)
Fälle mit Zugang zur Außenwelt über ein externes Netzwerk, unter Verwendung von Floating-Adressen sowie verteiltem Routing werden beim nächsten Mal berücksichtigt. Derzeit konzentrieren wir uns auf den internen Datenverkehr.
Zum Testen stellen wir das folgende Schema zusammen:
Wir haben 4 virtuelle Maschinen erstellt - 3 in einem L2-Netzwerk - net-1 und eine weitere 1 im net-2-Netzwerk
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Mal sehen, auf welchen Hypervisoren sich die erstellten Maschinen befinden:
(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 dem Knoten compute-1.
Darüber hinaus wurde ein virtueller Router erstellt, um das Routing zwischen den angegebenen Netzwerken zu ermöglichen:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Der Router verfügt über zwei virtuelle Ports, die als Gateways für Netzwerke dienen:
(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 ~]$ Bevor wir uns jedoch ansehen, wie der Verkehr fließt, schauen wir uns an, was wir derzeit auf dem Steuerknoten (der auch ein Netzwerkknoten ist) und auf dem Rechenknoten haben. Beginnen wir mit einem Rechenknoten.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Im Moment hat der Knoten drei Ovs-Brücken - br-int, br-tun, br-ex. Wie wir sehen können, gibt es zwischen ihnen eine Reihe von Schnittstellen. Zur Vereinfachung der Wahrnehmung werden wir alle diese Schnittstellen in das Diagramm aufnehmen und sehen, was passiert.
An den Adressen, zu denen die VxLAN-Tunnel ausgelöst werden, können Sie erkennen, dass ein Tunnel bei Berechnung 1 (192.168.255.26) ausgelöst wird, der zweite Tunnel bei Steuerung 1 (192.168.255.15). Das Interessanteste ist jedoch, dass br-ex keine physischen Schnittstellen hat. Wenn Sie sich ansehen, welche Flows konfiguriert sind, können Sie feststellen, dass diese Bridge derzeit nur den Datenverkehr beeinträchtigen kann.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Wie Sie an der Ausgabe sehen können, wird die Adresse direkt an den physischen Port und nicht an die virtuelle Bridge-Schnittstelle geschraubt.
[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 ~]$ Nach der ersten Regel muss alles, was vom phy-br-ex-Port kommt, verworfen werden.
Tatsächlich kann der Verkehr nirgendwo anders zu dieser Brücke gelangen, außer über diese Schnittstelle (Kreuzung mit br-int). Gemessen an den Einbrüchen ist der BUM-Verkehr bereits auf der Brücke angekommen.
Das heißt, der Datenverkehr von diesem Knoten kann nur durch den VxLAN-Tunnel und sonst nichts geleitet werden. Wenn Sie jedoch den DVR einschalten, ändert sich die Situation, aber wir werden uns ein anderes Mal darum kümmern. Wenn Sie die Netzwerkisolation verwenden, z. B. vlans, haben Sie nicht eine L3-Schnittstelle im 0. vlan, sondern mehrere Schnittstellen. Der VxLAN-Verkehr wird jedoch auf die gleiche Weise vom Knoten ausgehen, aber auch in eine Art dediziertes VLAN eingekapselt.
Wir haben den Rechenknoten herausgefunden und sind zum Steuerknoten gegangen.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Tatsächlich können wir sagen, dass alles gleich ist, aber die IP-Adresse befindet sich nicht mehr auf der physischen Schnittstelle, sondern auf der virtuellen Brücke. Dies geschieht aufgrund der Tatsache, dass dieser Port ein Port ist, über den der Verkehr nach außen geleitet wird.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Dieser Port ist mit der br-ex-Brücke verbunden. Da sich keine vlan-Tags darauf befinden, ist dieser Port ein Trunk-Port, an dem alle vlans zulässig sind. Jetzt wird der Datenverkehr ohne Tag nach draußen geleitet, wie in der obigen Ausgabe durch vlan-id 0 angegeben.
Alles andere im Moment ähnelt dem Rechenknoten - dieselben Brücken, dieselben Tunnel, die zu zwei Rechenknoten führen.
Wir werden in diesem Artikel keine Speicherknoten betrachten, aber zum Verständnis muss gesagt werden, dass der Netzwerkteil dieser Knoten bis zur Schande banal ist. In unserem Fall gibt es nur einen physischen Port (eth0), an dem eine IP-Adresse hängt, und das war's. Es gibt keine VxLAN-Tunnel, Tunnelbrücken usw. - es gibt überhaupt keine Ovs, da es keinen Sinn macht. Bei Verwendung der Netzwerkisolation verfügt dieser Knoten über zwei Schnittstellen (physische Ports, Baud oder nur zwei VLANs - es spielt keine Rolle - es hängt davon ab, was Sie möchten) - eine für die Verwaltung, die zweite für den Datenverkehr (Schreiben auf die VM-Festplatte, Lesen von Scheibe usw.).
Wir haben herausgefunden, was wir auf den Knoten haben, wenn keine Dienste verfügbar sind. Starten wir nun 4 virtuelle Maschinen und sehen, wie sich das oben beschriebene Schema ändert - wir sollten Ports, virtuelle Router usw. haben.
Bisher sieht unser Netzwerk folgendermaßen aus:
Auf jedem Computer befinden sich zwei virtuelle Maschinen. Mal sehen, wie alles in compute-0 enthalten 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 Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Diese Schnittstelle befasst sich mit der Linux-Brücke:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Wie Sie der Ausgabe entnehmen können, gibt es in der Brigade nur zwei Schnittstellen - tap95d96a75-a0 und qvb95d96a75-a0.
Es lohnt sichWie Sie verstehen, wenn wir einen qvb95d96a75-a0-Port in der Brigade haben, der ein vEth-Paar ist, wo ist dann sein Gegenstück, das logischerweise qvo95d96a75-a0 heißen sollte? Mal sehen, welche Ports sich auf dem OVS befinden.
, ein wenig auf die Arten von virtuellen Netzwerkgeräten in OpenStack einzugehen : vtap - eine virtuelle Schnittstelle, die mit einer Instanz (VM) verbunden ist
qbr - Linux-Brücke
qvb und qvo - vEth-Paar, das mit einer Linux-Brücke verbunden ist, und Open vSwitch-Brücke
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 für die Verbindung mit OVS verwendet werden
[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 können, ist der Port in br-int. Br-int fungiert als Switch, der die Ports virtueller Maschinen beendet. Zusätzlich zu qvo95d96a75-a0 zeigt die Ausgabe den Port qvo5bd37136-47. Dies ist der Port zur zweiten virtuellen Maschine. Infolgedessen sieht unser Schema jetzt folgendermaßen aus: Die
Frage, die den aufmerksamen Leser sofort interessieren sollte - warum ist die Linux-Brücke zwischen dem Port der virtuellen Maschine und dem OVS-Port? Tatsache ist, dass Sicherheitsgruppen zum Schutz des Computers verwendet werden, die nichts anderes als iptables sind. OVS funktioniert nicht mit Iptables, daher wurde diese "Krücke" erfunden. Es überlebt jedoch sein eigenes - es wird in neuen Releases durch conntrack ersetzt.
Das heißt, letztendlich sieht das Schema so aus:
Zwei Computer auf einem Hypervisor in einem L2-Netzwerk
Da sich diese beiden VMs im selben L2-Netzwerk und auf demselben Hypervisor befinden, wird der Datenverkehr zwischen ihnen logischerweise lokal über br-int geleitet, da sich beide Computer 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 Computer auf verschiedenen Hypervisoren im selben L2-Netzwerk
Nun wollen wir sehen, wie der Datenverkehr zwischen zwei Computern im selben L2-Netzwerk verläuft, die sich jedoch auf verschiedenen Hypervisoren befinden. Um ehrlich zu sein, wird sich nicht viel ändern, nur der Verkehr zwischen den Hypervisoren wird durch den vxlan-Tunnel gehen. Sehen wir uns ein Beispiel an.
Die Adressen der virtuellen Maschinen, zwischen denen wir den Verkehr beobachten werden:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Wir betrachten die Weiterleitungstabelle in br-int bei compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Der Datenverkehr sollte zu Port 2 gehen - mal sehen, was dieser Port ist:
[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, die Schnittstelle zu Br-Tun. Mal sehen, 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 gepackt und an Port 2 gesendet. Mal sehen, 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 ~]$Dies ist ein 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 ~]$Gehen Sie zu compute-1 und sehen Sie, was als nächstes 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 ~]$ Der Mac befindet sich in der br-int-Weiterleitungstabelle auf compute-1, und wie Sie aus der obigen Ausgabe ersehen können, ist er über Port 2 sichtbar, bei dem es sich um Ports in Richtung br-tun handelt:
[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, dann sehen wir, dass es in comp-1 einen Ziel-Mac in br-int 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 heißt, das empfangene Paket fliegt zu Port 3, hinter dem sich die virtuelle Maschine der Instanz 00000003 bereits befindet.
Das Schöne an der Bereitstellung von Openstack für das Lernen in einer virtuellen Infrastruktur ist, dass wir den Datenverkehr zwischen Hypervisoren leicht erfassen und sehen können, was damit passiert. Wir werden dies jetzt tun, tcpdump auf dem vnet-Port in Richtung compute-0 ausführen:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Die erste Zeile zeigt, dass der Patch mit der Adresse 10.0.1.85 an die Adresse 10.0.1.88 (ICMP-Verkehr) gesendet wird und in ein VxLAN-Paket mit vni 22 eingeschlossen ist und das Paket vom Host 192.168.255.19 (compute-0) zum Host 192.168.255.26 ( rechne-1). Wir können überprüfen, ob der VNI mit dem in den OVs angegebenen übereinstimmt.
Kehren wir zu dieser Zeile zurück. Actions = load: 0-> NXM_OF_VLAN_TCI [], load: 0x16-> NXM_NX_TUN_ID [], output: 2. 0x16 ist hexadezimal vni. Lassen Sie uns diese Zahl in das 10. System übersetzen:
16 = 6*16^0+1*16^1 = 6+16 = 22Das heißt, vni entspricht der Realität.
Die zweite Zeile zeigt den Rückverkehr. Nun, es macht keinen Sinn, ihn dort zu erklären, und alles ist klar.
Zwei Maschinen in unterschiedlichen Netzwerken (Routing zwischen Netzwerken)
Der letzte Fall für heute ist das Routing zwischen Netzwerken innerhalb eines Projekts mithilfe eines virtuellen Routers. Wir betrachten einen Fall ohne DVR (wir werden ihn in einem anderen Artikel betrachten), sodass das Routing auf dem Netzwerkknoten erfolgt. In unserem Fall ist der Netzwerkknoten keine separate Entität und befindet sich auf dem Steuerknoten.
Lassen Sie uns zunächst sehen, dass das Routing funktioniert:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msDa in diesem Fall das Paket zum Gateway gehen und dort weitergeleitet werden muss, müssen wir die MAC-Adresse des Gateways ermitteln, für die wir uns die ARP-Tabelle in der Instanz ansehen werden:
$ 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 eth0Nun wollen wir sehen, wohin der Verkehr mit dem Ziel (10.0.1.254) gesendet werden soll. Fa: 16: 3e: c4: 64: 70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Wir schauen, 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 ist logisch, der Verkehr geht zu br-tun. Mal sehen, in welchen vxlan-Tunnel es 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 der 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 ~]$ Welches sieht auf den Steuerknoten:
[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 Verkehr hat den Kontrollknoten erreicht, also müssen wir dorthin gehen und sehen, wie das Routing stattfinden wird.
Wie Sie sich erinnern, sah der Steuerknoten im Inneren genauso aus wie der Rechenknoten - dieselben drei Brücken, nur br-ex hatte einen physischen Port, über den der Knoten Datenverkehr nach außen senden konnte. Die Instanzerstellung hat die Konfiguration auf Rechenknoten geändert - Linux Bridge, Iptables und Interfaces wurden den Knoten hinzugefügt. Die Erstellung von Netzwerken und eines virtuellen Routers hat auch die Konfiguration des Steuerknotens geprägt.
Es ist also offensichtlich, dass sich die Gateway-Poppy-Adresse in der br-int-Weiterleitungstabelle auf dem Steuerknoten befinden sollte. Lassen Sie uns überprüfen, ob es dort ist und wo es aussieht:
[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 ~]$ Der Mac ist vom Port qr-0c52b15f-8f aus sichtbar. Wenn wir zur Liste der virtuellen Ports in Openstack zurückkehren, wird dieser Porttyp verwendet, um verschiedene virtuelle Geräte mit OVS zu verbinden. Genauer gesagt ist qr ein Port zum virtuellen Router, der als Namespace dargestellt wird.
Mal sehen, welche Namespaces sich auf dem Server befinden:
[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 ~]$ Bis zu drei Exemplare. Aber nach den Namen zu urteilen, können Sie den Zweck jedes einzelnen erraten. Wir werden später zu Instanzen mit den IDs 0 und 1 zurückkehren. Jetzt interessieren wir uns für den 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 ~]$ Dieser Namespace hat zwei interne, die wir zuvor erstellt haben. Beide virtuellen Ports werden zu br-int hinzugefügt. Lassen Sie uns die Massenadresse des Ports qr-0c52b15f-8f überprüfen, da der Verkehr, gemessen an der Ziel-Mohn-Adresse, genau zu dieser Schnittstelle ging.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Das heißt, in diesem Fall funktioniert alles gemäß den Gesetzen des Standard-Routings. Da der Datenverkehr für den Host 10.0.2.8 bestimmt ist, muss er über die zweite Schnittstelle qr-92fa49b5-54 und über den vxlan-Tunnel zum Rechenknoten geleitet werden:
[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 ist logisch, keine Überraschungen. Wir schauen, von wo aus die Mohnadresse 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 erwartet geht der Verkehr nach br-tun. Mal sehen, in welchen Tunnel der Verkehr als nächstes geht:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Der Verkehr geht in den Tunnel, um 1 zu berechnen. Nun, auf Compute-1 ist alles einfach - von br-tun geht das Paket zu br-int und von dort zur 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
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$Eigentlich haben wir den ganzen Weg durch das Paket gegangen. Ich denke, Sie haben bemerkt, dass der Verkehr durch verschiedene VXLAN-Tunnel ging und mit verschiedenen VNIs beendet wurde. Lassen Sie uns sehen, um welche Art von VNI es sich handelt, und dann einen Speicherauszug auf dem Steuerport des Knotens sammeln und sicherstellen, dass der Datenverkehr genau wie oben beschrieben verläuft.
Der zu berechnende Tunnel hat also die folgenden Aktionen = Laden: 0-> NXM_OF_VLAN_TCI [], Laden: 0x16-> NXM_NX_TUN_ID [], Ausgabe: 3. Konvertieren von 0x16 in Dezimalschreibweise:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Der zu berechnende Tunnel 1 hat die folgende VNI: Aktionen = Laden: 0-> NXM_OF_VLAN_TCI [], Laden: 0x63-> NXM_NX_TUN_ID [], Ausgabe: 2. Konvertieren von 0x63 in Dezimalschreibweise:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nun sehen wir uns die Müllkippe an:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************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, in das ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 gepackt wird. 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, in das ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 gepackt wird. 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 und nicht von 10.0.1.85.
Das heißt, am Ende haben wir das folgende Steuerknotenschema:
Wie alles? 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 ~]$ Da wir über die Architektur der Cloud-Plattform gesprochen haben, wäre es schön, wenn Computer automatisch Adressen von einem DHCP-Server erhalten. Dies sind zwei DHCP-Server für unsere beiden Netzwerke 10.0.1.0/24 und 10.0.2.0/24.
Lassen Sie uns überprüfen, ob dies so ist. In diesem Namespace gibt es nur eine Adresse - 10.0.1.1 - die Adresse des DHCP-Servers selbst, und sie ist auch in br-int enthalten:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Mal sehen, ob die Prozesse qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 in ihren Namen auf dem Steuerknoten enthalten:
[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 einen solchen Prozess, und basierend auf den Informationen in der obigen Ausgabe können wir zum Beispiel sehen, was wir gerade vermieten:
[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 ~]$Als Ergebnis erhalten wir eine solche Reihe von Diensten auf dem Steuerknoten:
Denken Sie daran - es sind nur - 4 Maschinen, 2 interne Netzwerke und ein virtueller Router ... Wir haben hier jetzt keine externen Netzwerke, jede Menge verschiedener Projekte, jedes mit seinen eigenen Netzwerken (überlappend) ), und wir haben den verteilten Router ausgeschaltet, aber am Ende befand sich nur ein Steuerknoten im Prüfstand (für die Fehlertoleranz muss ein Quorum von drei Knoten vorhanden sein). Es ist logisch, dass im Handel alles "ein wenig" komplizierter ist, aber in diesem einfachen Beispiel verstehen wir, wie dies funktionieren sollte - wenn Sie 3 oder 300 Namespaces haben, ist das natürlich wichtig, aber aus Sicht der Funktionsweise der gesamten Struktur wird sich nicht viel ändern ... aber im Moment Kleben Sie keine Art von Hersteller-SDN. Aber das ist eine ganz andere Geschichte.
Ich hoffe es war interessant. Wenn es Kommentare / Ergänzungen gut gibt oder ich irgendwo offen gelogen habe (ich bin ein Mensch und meine Meinung wird immer subjektiv sein) - schreibe, was korrigiert / hinzugefügt werden muss - wir werden alles korrigieren / hinzufügen.
Abschließend möchte ich ein paar Worte zum Vergleich von Openstack (sowohl Vanille als auch Anbieter) mit einer Cloud-Lösung von VMWare sagen - zu oft wurde mir diese Frage in den letzten Jahren gestellt, und um ehrlich zu sein, ich bin es leid, aber immer noch. Meiner Meinung nach sind diese beiden Lösungen sehr schwer zu vergleichen, aber wir können eindeutig sagen, dass beide Lösungen Nachteile aufweisen. Wenn Sie eine Lösung auswählen, müssen Sie die Vor- und Nachteile abwägen.
Wenn OpenStack eine Community-gesteuerte Lösung ist, hat VMWare das Recht, nur das zu tun, was es will (lesen - was für es rentabel ist), und dies ist logisch, da es ein kommerzielles Unternehmen ist, das es gewohnt ist, mit seinen Kunden Geld zu verdienen. Aber es gibt einen großen und fetten ABER - Sie können beispielsweise OpenStack von Nokia verlassen und zu einer Lösung von beispielsweise Juniper (Contrail Cloud) wechseln, aber Sie werden VMWare kaum verlassen können. Für mich sehen diese beiden Lösungen folgendermaßen aus: Openstack (Anbieter) ist ein einfacher Käfig, in den Sie eingesetzt werden, aber Sie haben den Schlüssel und können ihn jederzeit beenden. VMWare ist ein goldener Käfig, der Besitzer hat den Schlüssel zum Käfig und es wird Sie teuer kosten.
Ich werbe weder für das erste noch für das zweite Produkt - Sie wählen, was Sie brauchen. Wenn ich jedoch eine solche Wahl hätte, würde ich beide Lösungen - VMWare für die IT-Cloud (geringe Auslastung, bequeme Verwaltung), OpenStack von einem Anbieter (Nokia und Juniper bieten sehr schöne schlüsselfertige Lösungen) - für Telekommunikations-Clouds auswählen. Ich würde Openstack nicht für reine IT verwenden - es ist wie das Schießen eines Spatzen mit einer Kanone, aber ich sehe keine Kontraindikationen für die Verwendung, außer Redundanz. Die Verwendung von VMWare in der Telekommunikation - wie man Trümmer auf einem Ford Raptor transportiert - ist von außen wunderschön, aber der Fahrer muss 10 Fahrten anstelle von einer machen.
Meiner Meinung nach ist der größte Nachteil von VMWare die völlige Schließung - das Unternehmen gibt Ihnen keine Informationen darüber, wie es funktioniert, z. B. vSAN oder was sich im Hypervisor-Kern befindet - es ist einfach nicht rentabel - das heißt, Sie werden niemals ein Experte für VMWare - Ohne Lieferantenunterstützung sind Sie zum Scheitern verurteilt (sehr oft treffe ich VMWare-Experten, die von banalen Fragen verwirrt sind). Für mich kauft VMWare ein Auto mit verriegelter Motorhaube - ja, vielleicht haben Sie Spezialisten, die den Zahnriemen wechseln können, aber nur derjenige, der Ihnen diese Lösung verkauft hat, kann die Motorhaube öffnen. Persönlich mag ich keine Lösungen, in die ich nicht passen kann. Sie werden sagen, dass Sie möglicherweise nicht unter die Haube gehen müssen. Ja, das ist möglich, aber ich werde Sie ansehen, wenn Sie eine große Funktion in der Cloud aus 20 bis 30 virtuellen Maschinen, 40 bis 50 Netzwerken zusammenstellen müssen.Die Hälfte davon möchte nach draußen und die andere Hälfte fragt nach einer SR-IOV-Beschleunigung. Andernfalls benötigen Sie ein paar Dutzend weitere dieser Maschinen. Andernfalls reicht die Leistung nicht aus.
Es gibt andere Gesichtspunkte, daher liegt es an Ihnen, zu entscheiden, was Sie wählen möchten, und vor allem sind Sie später für Ihre Wahl verantwortlich. Dies ist nur meine Meinung - eine Person, die mindestens 4 Produkte gesehen und berührt hat - Nokia, Juniper, Red Hat und VMWare. Das heißt, ich habe etwas zu vergleichen.