Cloud Computing dringt immer tiefer in unser Leben ein und es gibt wohl keinen einzigen Menschen, der nicht schon mindestens einmal Cloud-Dienste genutzt hat. Was genau eine Cloud ist und wie sie funktioniert, wissen jedoch nur wenige Menschen, selbst auf der Ebene einer Idee. 5G wird bereits Realität und die Telekommunikationsinfrastruktur beginnt, von Pole-Lösungen zu Cloud-Lösungen überzugehen, genau wie damals, als sie von vollständig Hardware-Lösungen zu virtualisierten „Säulen“ überging.
Heute werden wir über die innere Welt der Cloud-Infrastruktur sprechen und uns insbesondere mit den Grundlagen des Netzwerkteils befassen.
Was ist eine Wolke? Die gleiche Virtualisierung – Profilansicht?
Mehr als eine logische Frage. Nein – das ist keine Virtualisierung, obwohl es ohne sie nicht möglich wäre. Schauen wir uns zwei Definitionen an:
Cloud Computing (im Folgenden Cloud genannt) ist ein Modell für die Bereitstellung eines benutzerfreundlichen Zugriffs auf verteilte Computerressourcen, die bei Bedarf mit möglichst geringer Latenz und minimalen Kosten für den Dienstanbieter bereitgestellt und gestartet werden müssen.
Virtualisierung - Dies ist die Möglichkeit, eine physische Einheit (z. B. einen Server) in mehrere virtuelle Einheiten aufzuteilen und dadurch die Ressourcenauslastung zu erhöhen (z. B. waren 3 Server zu 25–30 Prozent ausgelastet, nach der Virtualisierung wird 1 Server ausgelastet). bei 80-90 Prozent). Natürlich frisst die Virtualisierung einige 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 zum Beispiel KVM, was ich bevorzuge, aber das ist Geschmackssache.
Wir nutzen Virtualisierung, ohne es zu merken, und selbst Eisenrouter nutzen bereits Virtualisierung – beispielsweise wird in der neuesten Version von JunOS das Betriebssystem als virtuelle Maschine auf einer Echtzeit-Linux-Distribution (Wind River 9) installiert. Aber Virtualisierung ist nicht die Cloud, aber die Cloud kann ohne Virtualisierung nicht existieren.
Virtualisierung ist einer der Bausteine, auf denen die Cloud aufbaut.
Es wird nicht funktionieren, eine Cloud zu erstellen, indem man einfach mehrere Hypervisoren in einer L2-Domäne zusammenfasst, ein paar Yaml-Playbooks für die automatische Registrierung von VLANs über eine Art Ansible hinzufügt und so etwas wie ein Orchestrierungssystem darauf aufbaut, um automatisch virtuelle Maschinen zu erstellen. Es wird genauer sein, aber der resultierende Frankenstein ist nicht die Wolke, die wir brauchen, obwohl es für andere vielleicht der ultimative Traum ist. Wenn Sie außerdem denselben Openstack verwenden, handelt es sich im Wesentlichen immer noch um Frankenstein, aber na ja, darüber reden wir erst einmal nicht.
Ich verstehe jedoch, dass aus der oben dargestellten Definition nicht ganz klar ist, was eigentlich als Cloud bezeichnet werden kann.
Daher nennt ein Dokument des NIST (National Institute of Standards and Technology) fünf Hauptmerkmale, die eine Cloud-Infrastruktur haben sollte:
Erbringung von Dienstleistungen auf Anfrage. Dem Nutzer muss freier Zugriff auf die ihm zugewiesenen Computerressourcen (wie Netzwerke, virtuelle Festplatten, Speicher, Prozessorkerne etc.) gewährt werden und diese Ressourcen müssen automatisch – also ohne Eingreifen des Diensteanbieters – bereitgestellt werden.
Breite Serviceverfügbarkeit. Der Zugriff auf Ressourcen muss über Standardmechanismen erfolgen, um die Nutzung sowohl von Standard-PCs als auch von Thin Clients und mobilen Geräten zu ermöglichen.
Zusammenfassen von Ressourcen in Pools. Ressourcenpools müssen in der Lage sein, mehreren Kunden gleichzeitig Ressourcen zur Verfügung zu stellen, um sicherzustellen, dass die Kunden isoliert und frei von gegenseitiger Beeinflussung und Konkurrenz um Ressourcen sind. In den Pools sind auch Netzwerke enthalten, was auf die Möglichkeit der Verwendung überlappender Adressierung hinweist. Pools müssen bei Bedarf skalierbar sein. Die Verwendung von Pools ermöglicht es, das erforderliche Maß an Ressourcenfehlertoleranz und Abstraktion physischer und virtueller Ressourcen bereitzustellen – dem Empfänger des Dienstes wird lediglich der von ihm angeforderte Satz von Ressourcen bereitgestellt (wo sich diese Ressourcen physisch befinden, auf wie vielen). Server und Switches - für den Client spielt es keine Rolle). Wir müssen jedoch berücksichtigen, dass der Anbieter eine transparente Reservierung dieser Ressourcen sicherstellen muss.
Schnelle Anpassung an unterschiedliche Bedingungen. Dienste müssen flexibel sein – schnelle Bereitstellung von Ressourcen, deren Umverteilung, Hinzufügen oder Reduzieren von Ressourcen auf Wunsch des Kunden, und auf Seiten des Kunden sollte das Gefühl bestehen, dass die Cloud-Ressourcen endlos sind. Um das Verständnis zu erleichtern, wird Ihnen beispielsweise keine Warnung angezeigt, dass ein Teil Ihres Speicherplatzes in Apple iCloud verschwunden ist, weil die Festplatte auf dem Server ausgefallen ist und Laufwerke ausfallen. Darüber hinaus sind die Möglichkeiten dieses Dienstes Ihrerseits nahezu grenzenlos – Sie benötigen 2 TB – kein Problem, Sie haben bezahlt und erhalten. Ein ähnliches Beispiel kann mit Google.Drive oder Yandex.Disk gegeben werden.
Möglichkeit der Messung der erbrachten Leistung. Cloud-Systeme müssen verbrauchte Ressourcen automatisch steuern und optimieren, und diese Mechanismen müssen sowohl für den Benutzer als auch für den Dienstanbieter transparent sein. Das heißt, Sie können jederzeit überprüfen, wie viele Ressourcen Sie und Ihre Kunden verbrauchen.
Es ist zu bedenken, dass es sich bei diesen Anforderungen hauptsächlich um Anforderungen für eine öffentliche Cloud handelt, sodass diese Anforderungen für eine private Cloud (d. h. eine Cloud, die für den internen Bedarf des Unternehmens gestartet wird) leicht angepasst werden können. Sie müssen jedoch noch umgesetzt werden, sonst können wir nicht alle Vorteile des Cloud Computing nutzen.
Warum brauchen wir eine Cloud?
Allerdings wird jede neue oder bestehende Technologie, jedes neue Protokoll für etwas erstellt (außer natürlich RIP-ng). Niemand braucht ein Protokoll um eines Protokolls willen (außer natürlich RIP-ng). Es ist logisch, dass die Cloud geschaffen wird, um dem Benutzer/Kunden irgendeinen Dienst bereitzustellen. Wir alle kennen mindestens einige Cloud-Dienste, zum Beispiel Dropbox oder Google.Docs, und ich glaube, dass die meisten Menschen sie erfolgreich nutzen – dieser Artikel wurde beispielsweise mit dem Cloud-Dienst Google.Docs geschrieben. Aber die uns bekannten Cloud-Dienste sind nur ein Teil der Möglichkeiten der Cloud – genauer gesagt handelt es sich lediglich 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.
Schauen wir uns die einzelnen Elemente der Reihe nach an:
Software as a Service (SaaS) ist ein Modell zur Bereitstellung eines vollwertigen Dienstes für den Kunden, beispielsweise eines E-Mail-Dienstes wie Yandex.Mail oder Gmail. Bei diesem Servicebereitstellungsmodell tun Sie als Kunde eigentlich nichts außer der Nutzung der Dienste – das heißt, Sie müssen sich keine Gedanken über die Einrichtung des Dienstes, seine Fehlertoleranz oder Redundanz machen. Das Wichtigste ist, dass Sie Ihr Passwort nicht gefährden; den Rest erledigt der Anbieter dieses Dienstes für Sie. Aus Sicht des Dienstleisters trägt er die volle Verantwortung für den gesamten Service – von der Server-Hardware über Host-Betriebssysteme bis hin zu Datenbank- und Softwareeinstellungen.
Plattform als Dienstleistung (PaaS) — Bei diesem Modell stellt der Dienstanbieter dem Kunden ein Werkstück für den Dienst zur Verfügung, nehmen wir zum Beispiel einen Webserver. Der Dienstanbieter stellte dem Kunden einen virtuellen Server zur Verfügung (eigentlich eine Reihe von Ressourcen wie RAM/CPU/Speicher/Netzwerke usw.) und installierte sogar das Betriebssystem und die erforderliche Software auf diesem Server, jedoch mit der Konfiguration All diese Dinge werden vom Kunden selbst erledigt und für die Erbringung der Dienstleistung ist der Kunde verantwortlich. Der Dienstanbieter ist wie im vorherigen Fall für die Leistung der physischen Geräte, Hypervisoren, der virtuellen Maschine selbst, deren Netzwerkverfügbarkeit usw. verantwortlich, der Dienst selbst liegt jedoch nicht mehr in seinem Verantwortungsbereich.
Infrastruktur als Dienstleistung (IaaS) - Dieser Ansatz ist bereits interessanter. Tatsächlich stellt der Dienstanbieter dem Kunden eine vollständig virtualisierte Infrastruktur zur Verfügung, d Der Kunde – was der Kunde mit diesen Ressourcen innerhalb des zugewiesenen Pools (Kontingent) machen möchte – ist für den Lieferanten nicht besonders wichtig. Ob der Kunde seinen eigenen vEPC erstellen oder sogar einen Mini-Betreiber gründen und Kommunikationsdienste bereitstellen möchte – keine Frage – tun Sie es. In einem solchen Szenario ist der Dienstanbieter für die Bereitstellung von Ressourcen, deren Fehlertoleranz und Verfügbarkeit sowie für das Betriebssystem verantwortlich, das es ihm ermöglicht, diese Ressourcen zu bündeln und sie dem Kunden zur Verfügung zu stellen, wobei die Ressourcen jederzeit erhöht oder verringert werden können auf Wunsch des Kunden. Der Kunde konfiguriert alle virtuellen Maschinen und andere Elemente selbst über das Self-Service-Portal und die Konsole, einschließlich der Einrichtung von Netzwerken (außer externen Netzwerken).
Was ist OpenStack?
Bei allen drei Optionen benötigt der Dienstanbieter ein Betriebssystem, das den Aufbau einer Cloud-Infrastruktur ermöglicht. Tatsächlich ist bei SaaS mehr als eine Abteilung für den gesamten Technologiestapel 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 SaaS für den Kunden bereit. OpenStack ist eines der Cloud-Betriebssysteme, mit dem Sie eine Reihe von Switches, Servern und Speichersystemen in einem einzigen Ressourcenpool zusammenfassen, diesen gemeinsamen Pool in Subpools (Mandanten) aufteilen und diese Ressourcen Clients über das Netzwerk bereitstellen können.
OpenStack ist ein Cloud-Betriebssystem, mit dem Sie große Pools an Computerressourcen, Datenspeichern und Netzwerkressourcen steuern können, die über eine API mithilfe von Standardauthentifizierungsmechanismen bereitgestellt und verwaltet werden.
Mit anderen Worten handelt es sich hierbei um eine Reihe freier Softwareprojekte, die darauf abzielen, Cloud-Dienste (sowohl öffentliche als auch private) zu erstellen – also eine Reihe von Tools, mit denen Sie Server- und Switching-Geräte in einem einzigen Ressourcenpool kombinieren und verwalten können Diese Ressourcen sorgen für das erforderliche Maß an Fehlertoleranz.
Zum Zeitpunkt des Schreibens dieses Materials sieht die OpenStack-Struktur wie folgt aus:
Bild aufgenommen von
Jede der in OpenStack enthaltenen Komponenten führt eine bestimmte Funktion aus. Diese verteilte Architektur ermöglicht es Ihnen, die von Ihnen benötigten Funktionskomponenten in die Lösung einzubinden. Bei einigen Komponenten handelt es sich jedoch um Root-Komponenten, und ihre Entfernung führt zur vollständigen oder teilweisen Funktionsunfähigkeit der gesamten Lösung. Diese Komponenten werden normalerweise wie folgt klassifiziert:
- Dashboard – Webbasierte GUI zur Verwaltung von OpenStack-Diensten
- Keystone ist ein zentralisierter Identitätsdienst, der Authentifizierungs- und Autorisierungsfunktionen für andere Dienste bereitstellt sowie Benutzeranmeldeinformationen und deren Rollen verwaltet.
- Neutron - ein Netzwerkdienst, der Konnektivität zwischen den Schnittstellen verschiedener OpenStack-Dienste bereitstellt (einschließlich Konnektivität zwischen VMs und deren Zugriff auf die Außenwelt)
- Cinder – Bietet Zugriff auf Blockspeicher für virtuelle Maschinen
- Nova — Lebenszyklusmanagement virtueller Maschinen
- Blick – Repository für Images und Snapshots virtueller Maschinen
- Swift – Bietet Zugriff auf das Speicherobjekt
- Deckenmesser – ein Dienst, der die Möglichkeit bietet, Telemetriedaten zu sammeln und verfügbare und verbrauchte Ressourcen zu messen
- Wärme- — Orchestrierung basierend auf Vorlagen zur automatischen Erstellung und Bereitstellung von Ressourcen
Eine vollständige Liste aller Projekte und deren Zweck können Sie einsehen .
Jede OpenStack-Komponente ist ein Dienst, der eine bestimmte Funktion ausführt und eine API zur Verwaltung dieser Funktion und zur Interaktion mit anderen Cloud-Betriebssystemdiensten bereitstellt, um eine einheitliche Infrastruktur zu schaffen. Nova bietet beispielsweise die Verwaltung von Computerressourcen und eine API für den Zugriff auf die Konfiguration dieser Ressourcen, Glance bietet Bildverwaltung und eine API für deren Verwaltung, Cinder bietet Blockspeicher und eine API für deren Verwaltung usw. Alle Funktionen sind auf sehr enge Weise miteinander verknüpft.
Wenn man es jedoch genauer betrachtet, handelt es sich bei allen in OpenStack ausgeführten Diensten letztendlich um eine Art virtuelle Maschine (oder Container), die mit dem Netzwerk verbunden ist. Es stellt sich die Frage: Warum brauchen wir so viele Elemente?
Lassen Sie uns den Algorithmus zum Erstellen einer virtuellen Maschine und zum Verbinden dieser mit dem Netzwerk und dem dauerhaften Speicher in Openstack durchgehen.
- Wenn Sie eine Anfrage zum Erstellen einer Maschine erstellen, sei es eine Anfrage über Horizon (Dashboard) oder eine Anfrage über die CLI, geschieht als Erstes die Autorisierung Ihrer Anfrage auf Keystone – können Sie eine Maschine erstellen, hat sie das? Recht zur Nutzung dieses Netzwerks, Ihre Draft-Quote usw.
- Keystone authentifiziert Ihre Anfrage und generiert in der Antwortnachricht ein Authentifizierungstoken, das weiter verwendet wird. Nachdem Keystone eine Antwort erhalten hat, wird die Anfrage an Nova (nova api) gesendet.
- Nova-api prüft die Gültigkeit Ihrer Anfrage, indem es Keystone mithilfe des zuvor generierten Authentifizierungstokens kontaktiert
- Keystone führt die Authentifizierung durch und stellt Informationen zu Berechtigungen und Einschränkungen basierend auf diesem Authentifizierungstoken bereit.
- Nova-api erstellt einen Eintrag für die neue VM in der Nova-Datenbank und übergibt die Anfrage zum Erstellen der Maschine an Nova-Scheduler.
- Nova-Scheduler wählt den Host (Computerknoten) aus, auf dem die VM basierend auf den angegebenen Parametern, Gewichtungen und Zonen bereitgestellt wird. Ein Datensatz davon und die VM-ID werden in die Nova-Datenbank geschrieben.
- Als nächstes kontaktiert nova-scheduler nova-compute mit der Bitte, eine Instanz bereitzustellen. Nova-Compute kontaktiert Nova-Conductor, um Informationen über Maschinenparameter zu erhalten (Nova-Conductor ist ein Nova-Element, das als Proxyserver zwischen Nova-Datenbank und Nova-Compute fungiert und die Anzahl der Anfragen an Nova-Datenbank begrenzt, um Probleme mit der Datenbank zu vermeiden Konsistenzlastreduzierung).
- Nova-Conductor erhält die angeforderten Informationen von der Nova-Datenbank und übergibt sie an Nova-Compute.
- Als nächstes ruft nova-compute einen Blick auf, um die Bild-ID zu erhalten. Glace validiert die Anfrage in Keystone und gibt die angeforderten Informationen zurück.
- Nova-compute kontaktiert Neutronen, um Informationen über Netzwerkparameter zu erhalten. Ähnlich wie bei Glance validiert Neutron die Anfrage in Keystone, erstellt anschließend einen Eintrag in der Datenbank (Port-ID usw.), erstellt eine Anfrage zum Erstellen eines Ports und gibt die angeforderten Informationen an nova-compute zurück.
- Nova-Compute kontaktiert Cinder mit der Bitte, der virtuellen Maschine ein Volume zuzuweisen. Ähnlich wie bei Glance validiert Cider die Anfrage in Keystone, erstellt eine Anfrage zur Volumenerstellung und gibt die angeforderten Informationen zurück.
- Nova-compute kontaktiert libvirt mit der Bitte, eine virtuelle Maschine mit den angegebenen Parametern bereitzustellen.
Tatsächlich verwandelt sich ein scheinbar einfacher Vorgang der Erstellung einer einfachen virtuellen Maschine in einen solchen Strudel von API-Aufrufen zwischen Elementen der Cloud-Plattform. Darüber hinaus bestehen, wie Sie sehen, auch die zuvor bezeichneten Dienste aus kleineren Komponenten, zwischen denen eine Interaktion stattfindet. Das Erstellen einer Maschine ist nur ein kleiner Teil dessen, was Ihnen die Cloud-Plattform ermöglicht – es gibt einen Dienst, der für den Ausgleich des Datenverkehrs verantwortlich ist, einen Dienst, der für die Blockspeicherung verantwortlich ist, einen Dienst, der für DNS verantwortlich ist, einen Dienst, der für die Bereitstellung von Bare-Metal-Servern verantwortlich ist usw Die Cloud ermöglicht es Ihnen, Ihre virtuellen Maschinen wie eine Schafherde zu behandeln (im Gegensatz zur Virtualisierung). Wenn Ihrer Maschine in einer virtuellen Umgebung etwas passiert – Sie stellen sie aus Backups usw. wieder her, Cloud-Anwendungen sind jedoch so aufgebaut, dass die virtuelle Maschine keine so wichtige Rolle spielt – die virtuelle Maschine ist „gestorben“ – kein Problem - Es wurde gerade ein neues Fahrzeug erstellt, das auf der Vorlage basiert, und wie es heißt, hat die Truppe den Verlust des Jägers nicht bemerkt. Dies setzt natürlich das Vorhandensein von Orchestrierungsmechanismen voraus – mithilfe von Heat-Vorlagen können Sie problemlos eine komplexe Funktion bereitstellen, die aus Dutzenden von Netzwerken und virtuellen Maschinen besteht.
Es ist immer zu bedenken, dass es keine Cloud-Infrastruktur ohne Netzwerk gibt – jedes Element interagiert auf die eine oder andere Weise über das Netzwerk mit anderen Elementen. Darüber hinaus verfügt die Cloud über ein absolut nicht statisches Netzwerk. Natürlich ist das Underlay-Netzwerk noch mehr oder weniger statisch – neue Knoten und Switches werden nicht jeden Tag hinzugefügt, aber die Overlay-Komponente kann und wird sich zwangsläufig ständig ändern – neue Netzwerke werden hinzugefügt oder gelöscht, neue virtuelle Maschinen werden erscheinen und alte werden es tun sterben. Und wie Sie sich aus der Definition der Cloud ganz am Anfang des Artikels erinnern, sollten Ressourcen dem Benutzer automatisch und mit dem geringsten (oder besser noch ohne) Eingreifen des Dienstanbieters zugewiesen werden. Das heißt, die Art der Bereitstellung von Netzwerkressourcen, die heute in Form eines Frontends in Form Ihres persönlichen Kontos, auf das über http/https zugegriffen werden kann, und des diensthabenden Netzwerktechnikers Vasily als Backend existiert, ist noch nicht einmal eine Cloud wenn Vasily acht Hände hat.
Neutron stellt als Netzwerkdienst eine API zur Verwaltung des Netzwerkteils der Cloud-Infrastruktur bereit. Der Dienst betreibt und verwaltet den Netzwerkteil von Openstack, indem er eine Abstraktionsschicht namens Network-as-a-Service (NaaS) bereitstellt. Das heißt, das Netzwerk ist die gleiche virtuelle messbare Einheit wie beispielsweise virtuelle CPU-Kerne oder die Menge an RAM.
Bevor wir uns jedoch der Architektur des Netzwerkteils von OpenStack zuwenden, betrachten wir, wie dieses Netzwerk in OpenStack funktioniert und warum das Netzwerk ein wichtiger und integraler Bestandteil der Cloud ist.
Wir haben also zwei ROTE Client-VMs und zwei GRÜNE Client-VMs. Nehmen wir an, dass sich diese Maschinen auf folgende Weise auf zwei Hypervisoren befinden:
Im Moment handelt es sich lediglich um die Virtualisierung von 4 Servern und nichts weiter, da wir bisher lediglich 4 Server virtualisiert und sie auf zwei physischen Servern platziert haben. Und bisher sind sie noch nicht einmal mit dem Netzwerk verbunden.
Um eine Cloud zu erstellen, müssen wir mehrere Komponenten hinzufügen. Zuerst virtualisieren wir den Netzwerkteil – wir müssen diese 4 Maschinen paarweise verbinden und die Clients wollen eine L2-Verbindung. Sie können einen Switch verwenden und einen Trunk in seiner Richtung konfigurieren und alles mithilfe einer Linux-Bridge oder, für fortgeschrittenere Benutzer, openvswitch auflösen (wir werden später darauf zurückkommen). Aber es kann viele Netzwerke geben, und es ist nicht die beste Idee, L2 ständig durch einen Switch zu schieben – es gibt verschiedene Abteilungen, einen Service Desk, monatelanges Warten auf die Fertigstellung eines Antrags, wochenlange Fehlerbehebung – in der modernen Welt ist das so Ansatz funktioniert nicht mehr. Und je früher ein Unternehmen dies versteht, desto einfacher kann es vorankommen. Daher wählen wir zwischen den Hypervisoren ein L3-Netzwerk aus, über das unsere virtuellen Maschinen kommunizieren, und bauen auf diesem L3-Netzwerk virtuelle L2-Overlay-Netzwerke auf, über die der Datenverkehr unserer virtuellen Maschinen läuft. Als Kapselung können Sie GRE, Geneve oder VxLAN verwenden. Konzentrieren wir uns vorerst auf Letzteres, obwohl es nicht besonders wichtig ist.
Wir müssen VTEP irgendwo finden (ich hoffe, jeder ist mit der VxLAN-Terminologie vertraut). Da wir über ein L3-Netzwerk verfügen, das direkt von den Servern kommt, hindert uns nichts daran, VTEP auf den Servern selbst zu platzieren, und OVS (OpenvSwitch) ist darin hervorragend. Als Ergebnis haben wir dieses Design erhalten:
Da der Datenverkehr 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 Einkapselung in VxLAN leicht entfernen können, da wir ein VNI haben.
Jetzt können wir problemlos unsere Maschinen und virtuellen Netzwerke für sie erstellen.
Was aber, wenn der Client einen anderen Computer hat, sich aber in einem anderen Netzwerk befindet? Wir brauchen eine Verwurzelung zwischen den Netzwerken. Wir werden uns eine einfache Option ansehen, wenn zentralisiertes Routing verwendet wird – das heißt, der Datenverkehr wird über spezielle dedizierte Netzwerkknoten geleitet (in der Regel werden diese mit Kontrollknoten kombiniert, sodass wir dasselbe haben).
Es scheint nichts Kompliziertes zu sein – wir erstellen eine Bridge-Schnittstelle auf dem Kontrollknoten, leiten den Datenverkehr dorthin und leiten ihn von dort dorthin weiter, wo wir ihn benötigen. Das Problem besteht jedoch darin, dass der ROTE Client das Netzwerk 10.0.0.0/24 verwenden möchte und der GRÜNE Client das Netzwerk 10.0.0.0/24 verwenden möchte. Das heißt, wir beginnen, Adressräume zu überschneiden. Darüber hinaus möchten Clients nicht, dass andere Clients in ihre internen Netzwerke weiterleiten können, was sinnvoll ist. Um die Netzwerke und den Client-Datenverkehr zu trennen, weisen wir ihnen jeweils einen eigenen Namensraum zu. Der Namespace ist in der Tat eine Kopie des Linux-Netzwerkstapels, d. h. Clients im Namespace ROT sind vollständig von Clients im Namespace GRÜN isoliert (nun, Routing zwischen diesen Client-Netzwerken ist entweder über den Standard-Namespace oder über vorgelagerte Transportgeräte zulässig).
Das heißt, wir erhalten das folgende Diagramm:
L2-Tunnel laufen von allen Rechenknoten zum Kontrollknoten zusammen. Knoten, auf dem sich die L3-Schnittstelle für diese Netzwerke befindet, jeweils in einem dedizierten Namespace zur Isolierung.
Allerdings haben wir das Wichtigste vergessen. Die virtuelle Maschine muss dem Client einen Dienst bereitstellen, das heißt, 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. Machen wir die einfachste Option. Wir werden jedem Client ein Netzwerk hinzufügen, das im Netzwerk des Anbieters gültig ist und sich nicht mit anderen Netzwerken überschneidet. Die Netzwerke können sich auch überschneiden und verschiedene VRFs auf der Seite des Anbieternetzwerks betrachten. Die Netzwerkdaten werden auch im Namensraum jedes Clients gespeichert. Sie gelangen jedoch immer noch über eine physische Schnittstelle (oder eine Bindung, was logischer ist) zur Außenwelt. Um den Client-Verkehr zu trennen, wird der nach außen gerichtete Datenverkehr mit einem dem Client zugewiesenen VLAN-Tag gekennzeichnet.
Als Ergebnis haben wir dieses Diagramm erhalten:
Eine berechtigte Frage lautet: Warum nicht Gateways auf den Rechenknoten selbst erstellen? Dies stellt kein großes Problem dar. Wenn Sie außerdem den verteilten Router (DVR) einschalten, funktioniert dies. In diesem Szenario erwägen wir die einfachste Option mit einem zentralen Gateway, das standardmäßig in Openstack verwendet wird. Für Hochlastfunktionen werden sie sowohl einen verteilten Router als auch Beschleunigungstechnologien wie SR-IOV und Passthrough verwenden, aber wie sie sagen, ist das eine ganz andere Geschichte. Befassen wir uns zunächst mit dem grundlegenden Teil und gehen dann auf die Details ein.
Eigentlich ist unser Schema bereits praktikabel, aber es gibt ein paar Nuancen:
- Wir müssen unsere Maschinen irgendwie schützen, das heißt, einen Filter an der Switch-Schnittstelle zum Client anbringen.
- Ermöglichen Sie einer virtuellen Maschine, automatisch eine IP-Adresse zu erhalten, sodass Sie sich nicht jedes Mal über die Konsole anmelden 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, unsere Topologie ist jetzt etwas komplizierter geworden:
Lass uns weitermachen. Wir müssen einen DHCP-Server hinzufügen. Der idealste Ort zum Auffinden von DHCP-Servern für jeden Client wäre der bereits oben erwähnte Kontrollknoten, auf dem sich die Namespaces befinden:
Allerdings gibt es ein kleines Problem. Was passiert, wenn alles neu startet und alle Informationen zum Mieten von Adressen über DHCP verschwinden? Es ist logisch, dass die Maschinen neue Adressen erhalten, was nicht sehr praktisch ist. Hier gibt es zwei Auswege: Entweder Domänennamen verwenden und für jeden Client einen DNS-Server hinzufügen, dann ist die Adresse für uns nicht besonders wichtig (ähnlich dem Netzwerkteil in k8s) – aber da gibt es ein Problem mit externen Netzwerken Adressen können in ihnen auch per DHCP vergeben werden – man braucht dazu eine Synchronisation mit DNS-Servern in der Cloud-Plattform und einem externen DNS-Server, was meiner Meinung nach zwar nicht sehr flexibel, aber durchaus möglich ist. Oder die zweite Möglichkeit besteht darin, Metadaten zu verwenden – also Informationen über die an die Maschine vergebene Adresse zu speichern, damit der DHCP-Server weiß, welche Adresse er an die Maschine vergeben muss, wenn die Maschine bereits eine Adresse erhalten hat. Die zweite Option ist einfacher und flexibler, da Sie damit zusätzliche Informationen zum Auto speichern können. Fügen wir nun Agentenmetadaten zum Diagramm hinzu:
Ein weiteres Thema, das ebenfalls eine Diskussion wert ist, ist die Möglichkeit, ein externes Netzwerk für alle Clients zu nutzen, da externe Netzwerke, wenn sie im gesamten Netzwerk gültig sein müssen, schwierig sein werden – Sie müssen die Zuordnung dieser Netzwerke ständig zuweisen und kontrollieren. Die Möglichkeit, ein einziges externes vorkonfiguriertes Netzwerk für alle Clients zu verwenden, wird beim Erstellen einer öffentlichen Cloud sehr nützlich sein. Dies erleichtert die Bereitstellung von Maschinen, da wir keine Adressdatenbank konsultieren und für das externe Netzwerk jedes Clients keinen eindeutigen Adressraum auswählen müssen. Darüber hinaus können wir ein externes Netzwerk im Voraus registrieren und müssen zum Zeitpunkt der Bereitstellung nur externe Adressen mit Client-Rechnern verknüpfen.
Und hier kommt uns NAT zu Hilfe – wir ermöglichen Clients lediglich den Zugriff auf die Außenwelt über den Standard-Namespace mithilfe der NAT-Übersetzung. Nun, hier ist ein kleines Problem. Das ist dann sinnvoll, wenn der Client-Server als Client und nicht als Server fungiert – das heißt, er initiiert Verbindungen, statt sie zu akzeptieren. Aber bei uns wird es umgekehrt sein. In diesem Fall müssen wir Ziel-NAT durchführen, damit der Kontrollknoten beim Empfang von Datenverkehr versteht, dass dieser Datenverkehr für die virtuelle Maschine A von Client A bestimmt ist, was bedeutet, dass wir eine NAT-Übersetzung von einer externen Adresse, zum Beispiel 100.1.1.1, durchführen müssen .10.0.0.1, an eine interne Adresse 100. In diesem Fall nutzen zwar alle Clients dasselbe Netzwerk, die interne Isolation bleibt jedoch vollständig erhalten. Das heißt, wir müssen dNAT und sNAT auf dem Kontrollknoten durchführen. Ob Sie ein einzelnes Netzwerk mit Floating-Adressen oder externe Netzwerke oder beides gleichzeitig verwenden, hängt davon ab, was Sie in die Cloud bringen möchten. Wir werden dem Diagramm keine Floating-Adressen hinzufügen, sondern die bereits zuvor hinzugefügten externen Netzwerke belassen – jeder Client verfügt über sein eigenes externes Netzwerk (im Diagramm sind sie auf der externen Schnittstelle als VLAN 200 und XNUMX angegeben).
Als Ergebnis haben wir eine interessante und zugleich durchdachte Lösung erhalten, die eine gewisse Flexibilität aufweist, jedoch noch über keine Fehlertoleranzmechanismen verfügt.
Erstens haben wir nur einen Kontrollknoten – sein Ausfall wird zum Zusammenbruch aller Systeme führen. Um dieses Problem zu beheben, müssen Sie ein Quorum von mindestens 3 Knoten schaffen. Fügen wir dies dem Diagramm hinzu:
Natürlich sind alle Knoten synchronisiert und wenn ein aktiver Knoten verlässt, übernimmt ein anderer Knoten seine Verantwortung.
Das nächste Problem sind Festplatten virtueller Maschinen. Im Moment werden sie auf den Hypervisoren selbst gespeichert, und bei Problemen mit dem Hypervisor verlieren wir alle Daten – und das Vorhandensein eines Raids hilft hier nicht weiter, wenn wir nicht die Festplatte, sondern den gesamten Server verlieren. Dazu müssen wir einen Dienst erstellen, der als Frontend für eine Art Speicher fungiert. Welche Art von Speicher es sein wird, ist für uns nicht besonders wichtig, aber er 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 – es gibt natürlich SAN-Netzwerke mit Fibre Channel, aber seien wir ehrlich – FC ist bereits ein Relikt der Vergangenheit – ein Analogon zu 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 im Jahr 2020 nicht freiwillig ein FC-Netzwerk aufbauen, da ich weiß, dass es andere, interessantere Alternativen gibt. Obwohl es für jeden das Richtige ist, gibt es vielleicht diejenigen, die glauben, dass der FC mit all seinen Einschränkungen alles ist, was wir brauchen – ich möchte nicht widersprechen, jeder hat seine eigene Meinung. Die interessanteste Lösung ist meiner Meinung nach jedoch die Verwendung eines Sicherheitsdatenblatts wie Ceph.
Mit Ceph können Sie eine hochverfügbare Datenspeicherlösung mit einer Reihe möglicher Backup-Optionen aufbauen, angefangen bei Codes mit Paritätsprüfung (analog zu Raid 5 oder 6) bis hin zur vollständigen Datenreplikation auf verschiedene Festplatten unter Berücksichtigung des Speicherorts der Festplatten Server und Server in Schränken usw.
Um Ceph zu bauen, benötigen Sie 3 weitere Knoten. Die Interaktion mit dem Speicher erfolgt ebenfalls über das Netzwerk mithilfe von Block-, Objekt- und Dateispeicherdiensten. Fügen wir dem Schema Speicher hinzu:
Hinweis: Sie können auch hyperkonvergente Rechenknoten erstellen – dabei handelt es sich um das Konzept der Kombination mehrerer Funktionen auf einem Knoten – zum Beispiel Speicherung + Rechenleistung – ohne spezielle Knoten für die Ceph-Speicherung bereitzustellen. Wir erhalten das gleiche Fehlertoleranzschema, da SDS Daten mit der von uns angegebenen Reservierungsstufe reserviert. Hyperkonvergente Knoten sind jedoch immer ein Kompromiss – da der Speicherknoten nicht nur die Luft erwärmt, wie es auf den ersten Blick scheint (da es keine virtuellen Maschinen darauf gibt), sondern CPU-Ressourcen für die Wartung von SDS ausgibt (tatsächlich erledigt er alles). die Replikation und Wiederherstellung nach Ausfällen von Knoten, Festplatten usw.). Das heißt, Sie verlieren einen Teil der Leistung eines Rechenknotens, wenn Sie ihn mit Speicher kombinieren.
All diese Dinge müssen irgendwie verwaltet werden – wir brauchen etwas, mit dem wir eine Maschine, ein Netzwerk, einen virtuellen Router usw. erstellen können. Dazu fügen wir dem Kontrollknoten einen Dienst hinzu, der als Dashboard fungiert – den Der Kunde kann sich über http/https mit diesem Portal verbinden und (naja, fast) alles tun, was er braucht.
Dadurch verfügen wir nun über ein fehlertolerantes System. Alle Elemente dieser Infrastruktur müssen irgendwie verwaltet werden. Zuvor wurde beschrieben, dass es sich bei Openstack um eine Reihe von Projekten handelt, von denen jedes eine bestimmte Funktion bereitstellt. Wie wir sehen, gibt es mehr als genug Elemente, die konfiguriert und gesteuert werden müssen. 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, die Weiterleitung des Datenverkehrs zwischen VMs in verschiedenen L2-Netzwerken sicherzustellen, sowie das Routing nach außen und die Bereitstellung von Diensten wie NAT, Floating IP, DHCP usw.
Auf hoher Ebene kann der Betrieb des Netzwerkdienstes (der grundlegende Teil) wie folgt beschrieben werden.
Beim Starten der VM führt der Netzwerkdienst Folgendes aus:
- Erstellt einen Port für eine bestimmte VM (oder Ports) und benachrichtigt den DHCP-Dienst darüber;
- Ein neues virtuelles Netzwerkgerät wird erstellt (über libvirt);
- Die VM stellt eine Verbindung zu den in Schritt 1 erstellten Ports her.
Seltsamerweise basiert Neutrons Arbeit auf Standardmechanismen, die jedem vertraut sind, der jemals in Linux eingetaucht ist – 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-Neutronenserver ist ein Daemon, der über die API mit Benutzeranfragen arbeitet. Dieser Dämon ist nicht an der Registrierung etwaiger Netzwerkverbindungen beteiligt, sondern liefert die dafür notwendigen Informationen an seine Plugins, die dann das gewünschte Netzwerkelement konfigurieren. Neutron-Agenten auf OpenStack-Knoten registrieren sich beim Neutron-Server.
Neutron-Server ist eigentlich eine in Python geschriebene Anwendung, die aus zwei Teilen besteht:
- REST-Dienst
- Neutron Plugin (Kern/Dienst)
Der REST-Dienst ist darauf ausgelegt, API-Aufrufe von anderen Komponenten zu empfangen (z. B. eine Anfrage zur Bereitstellung einiger Informationen usw.).
Plugins sind Plug-in-Softwarekomponenten/Module, die bei API-Anfragen aufgerufen werden, d. h. die Zuordnung eines Dienstes erfolgt über sie. Plugins werden in zwei Typen unterteilt: Service und Root. In der Regel ist das Horse-Plugin hauptsächlich für die Verwaltung des Adressraums und der L2-Verbindungen zwischen VMs zuständig, Service-Plugins stellen bereits zusätzliche Funktionalitäten wie VPN oder FW bereit.
Die Liste der heute verfügbaren Plugins kann beispielsweise eingesehen werden
Es können mehrere Service-Plugins vorhanden sein, es kann jedoch nur ein Horse-Plugin vorhanden sein.
openstack-neutron-ml2 ist das Standard-Openstack-Root-Plugin. Dieses Plugin verfügt über eine modulare Architektur (im Gegensatz zu seinem Vorgänger) und konfiguriert den Netzwerkdienst über damit verbundene Treiber. Wir werden uns das Plugin selbst etwas später ansehen, da es tatsächlich die Flexibilität bietet, die OpenStack im Netzwerkteil bietet. Das Root-Plugin kann ersetzt werden (Contrail Networking führt beispielsweise einen solchen Ersatz durch).
RPC-Dienst (rabbitmq-server) – ein Dienst, der Warteschlangenverwaltung und Interaktion mit anderen OpenStack-Diensten sowie Interaktion zwischen Netzwerkdienstagenten bereitstellt.
Netzwerkagenten – Agenten, die sich in jedem Knoten befinden und über die Netzwerkdienste konfiguriert werden.
Es gibt verschiedene Arten von Agenten.
Der Hauptagent ist L2-Agent. Diese Agenten laufen auf jedem der Hypervisoren, einschließlich der Kontrollknoten (genauer gesagt auf allen Knoten, die Dienste für Mandanten bereitstellen). Ihre Hauptfunktion besteht darin, virtuelle Maschinen mit einem gemeinsamen L2-Netzwerk zu verbinden und außerdem Warnungen zu generieren, wenn Ereignisse auftreten ( zum Beispiel den Port deaktivieren/aktivieren).
Der nächste, nicht weniger wichtige Agent ist L3-Agent. Standardmäßig läuft dieser Agent ausschließlich auf einem Netzwerkknoten (häufig wird der Netzwerkknoten mit einem Kontrollknoten kombiniert) und stellt Routing zwischen Mieternetzwerken bereit (sowohl zwischen seinen Netzwerken als auch den Netzwerken anderer Mieter) und ist für die Außenwelt zugänglich NAT sowie DHCP-Dienst). Bei Verwendung eines DVR (Distributed Router) besteht jedoch auch auf den Rechenknoten die Notwendigkeit eines L3-Plugins.
Der L3-Agent verwendet Linux-Namespaces, um jedem Mandanten eine Reihe eigener isolierter Netzwerke und die Funktionalität virtueller Router zur Verfügung zu stellen, die den Datenverkehr weiterleiten und Gateway-Dienste für Layer-2-Netzwerke bereitstellen.
Datenbase — eine Datenbank mit Identifikatoren von Netzwerken, Subnetzen, Ports, Pools usw.
Tatsächlich akzeptiert Neutron API-Anfragen von der Erstellung beliebiger Netzwerkeinheiten, authentifiziert die Anfrage und überträgt sie über RPC (wenn es auf ein Plugin oder Agent zugreift) oder REST API (wenn es in SDN kommuniziert) an die Agenten (über Plugins). Anweisungen, die zur Organisation der angeforderten Dienstleistung erforderlich sind.
Wenden wir uns nun der Testinstallation zu (wie sie bereitgestellt wird und was darin enthalten ist, werden wir später im praktischen Teil sehen) und sehen, wo sich die einzelnen Komponenten befinden:
(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, etwas Zeit mit dem ML2-Plugin zu verbringen.
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-Plugins hatte eine monolithische Struktur, die beispielsweise den Einsatz mehrerer Technologien in einer Installation nicht zuließ. Sie könnten beispielsweise nicht gleichzeitig openvswitch und linuxbridge verwenden – weder das erste noch das zweite. Aus diesem Grund wurde das ML2-Plugin mit seiner Architektur erstellt.
ML2 besteht aus zwei Komponenten – zwei Arten von Treibern: Typtreiber und Mechanismustreiber.
Geben Sie Treiber ein Bestimmen Sie die Technologien, die zum Organisieren von Netzwerkverbindungen verwendet werden, zum Beispiel VxLAN, VLAN, GRE. Gleichzeitig ermöglicht der Treiber den Einsatz unterschiedlicher Technologien. Die Standardtechnologie ist die VxLAN-Kapselung für Overlay-Netzwerke und externe VLAN-Netzwerke.
Typtreiber umfassen die folgenden Netzwerktypen:
Flache Schaltflächen - Netzwerk ohne Tagging
VLAN - markiertes Netzwerk
Lokale — eine spezielle Art von Netzwerk für All-in-One-Installationen (solche Installationen werden entweder für Entwickler oder für Schulungen benötigt)
GRE – Overlay-Netzwerk mit GRE-Tunneln
VxLAN – Overlay-Netzwerk mit VxLAN-Tunneln
Mechanismustreiber Definieren Sie Tools, die die Organisation der im Typtreiber angegebenen Technologien sicherstellen – zum Beispiel openvswitch, sr-iov, opendaylight, OVN usw.
Abhängig von der Implementierung dieses Treibers werden entweder von Neutron gesteuerte Agenten verwendet oder es werden Verbindungen zu einem externen SDN-Controller verwendet, der sich um alle Probleme im Zusammenhang mit der Organisation von L2-Netzwerken, Routing usw. kümmert.
Beispiel: Wenn wir ML2 zusammen mit OVS verwenden, dann ist auf jedem Rechenknoten, der OVS verwaltet, ein L2-Agent installiert. Wenn wir jedoch beispielsweise OVN oder OpenDayLight verwenden, fällt die Steuerung von OVS in deren Zuständigkeitsbereich – Neutron gibt über das Root-Plugin Befehle an den Controller und führt bereits aus, was ihm gesagt wurde.
Lassen Sie uns Open vSwitch auffrischen
Eine der Schlüsselkomponenten von OpenStack ist derzeit Open vSwitch.
Bei der Installation von OpenStack ohne zusätzliche Anbieter-SDNs wie Juniper Contrail oder Nokia Nuage ist OVS die Hauptnetzwerkkomponente des Cloud-Netzwerks und ermöglicht Ihnen zusammen mit iptables, conntrack und Namespaces die Organisation vollwertiger mandantenfähiger Overlay-Netzwerke. Selbstverständlich kann diese Komponente beispielsweise beim Einsatz von proprietären (Hersteller-)SDN-Lösungen Dritter ersetzt werden.
OVS ist ein Open-Source-Software-Switch, der für den Einsatz in virtualisierten Umgebungen als virtueller Datenverkehrsweiterleiter konzipiert ist.
Derzeit verfügt OVS über eine sehr gute 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 stark ausgelastete Telekommunikationsfunktionen konzipiert, sondern eher für weniger bandbreitenintensive IT-Funktionen wie WEB-Server oder Mail-Server. OVS wird jedoch weiterentwickelt und aktuelle Implementierungen von OVS haben seine Leistung und Fähigkeiten erheblich verbessert, sodass es von Telekommunikationsbetreibern mit stark ausgelasteten Funktionen verwendet werden kann. Beispielsweise gibt es eine OVS-Implementierung mit Unterstützung für DPDK-Beschleunigung.
Es gibt drei wichtige Komponenten von OVS, die Sie kennen müssen:
- Kernel-Modul – eine im Kernelraum befindliche Komponente, die den Datenverkehr basierend auf den vom Steuerelement empfangenen Regeln verarbeitet;
- vSchalter Daemon (ovs-vswitchd) ist ein im Benutzerbereich gestarteter Prozess, der für die Programmierung des Kernelmoduls verantwortlich ist – das heißt, er repräsentiert direkt die Logik der Switch-Operation
- Datenbankserver - eine lokale Datenbank auf jedem Host, auf dem OVS läuft, und in der die Konfiguration gespeichert ist. SDN-Controller können über dieses Modul mithilfe des OVSDB-Protokolls kommunizieren.
All dies wird von einer Reihe von Diagnose- und Verwaltungsdienstprogrammen begleitet, wie z. B. ovs-vsctl, ovs-appctl, ovs-ofctl usw.
Derzeit wird OpenStack häufig von Telekommunikationsbetreibern verwendet, um Netzwerkfunktionen wie EPC, SBC, HLR usw. darauf zu migrieren. Einige Funktionen können ohne Probleme mit OVS so wie sie sind funktionieren, aber EPC verarbeitet beispielsweise den Teilnehmerverkehr – und leitet ihn dann weiter eine riesige Menge an Verkehr (jetzt erreicht das Verkehrsaufkommen mehrere hundert Gigabit pro Sekunde). Natürlich ist es nicht die beste Idee, diesen Datenverkehr über den Kernel-Bereich zu leiten (da sich der Forwarder standardmäßig dort befindet). Daher wird OVS häufig vollständig im Benutzerbereich mithilfe der DPDK-Beschleunigungstechnologie bereitgestellt, um den Datenverkehr von der Netzwerkkarte unter Umgehung des Kernels an den Benutzerbereich weiterzuleiten.
Hinweis: Bei einer Cloud, die für Telekommunikationsfunktionen bereitgestellt wird, ist es möglich, Datenverkehr von einem Rechenknoten unter Umgehung von OVS direkt an Vermittlungsgeräte auszugeben. Zu diesem Zweck werden SR-IOV- und Passthrough-Mechanismen verwendet.
Wie funktioniert das auf einem echten Layout?
Kommen wir nun zum praktischen Teil und sehen, wie das Ganze in der Praxis funktioniert.
Lassen Sie uns zunächst eine einfache Openstack-Installation bereitstellen. Da mir für Experimente kein Serversatz zur Verfügung steht, werden wir den Prototyp auf einem physischen Server aus virtuellen Maschinen zusammenstellen. Ja, für kommerzielle Zwecke ist eine solche Lösung natürlich nicht geeignet, aber um ein Beispiel dafür zu sehen, wie das Netzwerk in OpenStack funktioniert, reicht eine solche Installation für die Augen. Darüber hinaus ist eine solche Installation für Schulungszwecke noch interessanter, da Sie den Verkehr usw. erfassen können.
Da wir nur den grundlegenden Teil sehen müssen, können wir nicht mehrere Netzwerke verwenden, sondern alles mit nur zwei Netzwerken aufbauen, und das zweite Netzwerk in diesem Layout wird ausschließlich für den Zugriff auf die Undercloud und den DNS-Server verwendet. Auf externe Netzwerke gehen wir vorerst nicht ein – dies ist ein Thema für einen separaten großen Artikel.
Beginnen wir also der Reihe nach. Zunächst eine kleine Theorie. Wir werden Openstack mit TripleO (Openstack on Openstack) installieren. Die Essenz von TripleO besteht darin, dass wir Openstack all-in-one installieren (d. h. auf einem Knoten), genannt Undercloud, und dann die Fähigkeiten des bereitgestellten Openstack nutzen, um Openstack zu installieren, das für den Betrieb gedacht ist, genannt Overcloud. Undercloud wird seine inhärente Fähigkeit zur Verwaltung physischer Server (Bare Metal) – das Ironic-Projekt – nutzen, um Hypervisoren bereitzustellen, die die Rollen von Rechen-, Steuerungs- und Speicherknoten übernehmen. Das heißt, wir verwenden keine Tools von Drittanbietern zur Bereitstellung von OpenStack – wir stellen OpenStack mithilfe von OpenStack bereit. Mit fortschreitender Installation wird es viel klarer, daher werden wir hier nicht aufhören und weitermachen.
Hinweis: Der Einfachheit halber habe ich in diesem Artikel keine Netzwerkisolation für interne Openstack-Netzwerke verwendet, sondern alles wird über nur ein Netzwerk bereitgestellt. Das Vorhandensein oder Fehlen einer Netzwerkisolation hat jedoch keinen Einfluss auf die Grundfunktionalität der Lösung – alles funktioniert genauso wie bei Verwendung der Isolation, aber der Datenverkehr fließt im selben Netzwerk. Für eine kommerzielle Installation ist es natürlich notwendig, eine Isolierung über verschiedene VLANs und Schnittstellen zu verwenden. Beispielsweise nutzen der Ceph-Speicherverwaltungsverkehr und der Datenverkehr selbst (Maschinenzugriff auf Festplatten usw.), wenn sie isoliert sind, unterschiedliche Subnetze (Speicherverwaltung und Speicher). Dadurch können Sie die Lösung fehlertoleranter gestalten, indem Sie beispielsweise diesen Datenverkehr aufteilen , über verschiedene Ports hinweg oder mit unterschiedlichen QoS-Profilen für unterschiedlichen Datenverkehr, damit der Datenverkehr den Signalisierungsverkehr nicht verdrängt. In unserem Fall werden sie sich im selben Netzwerk befinden, und das schränkt uns tatsächlich in keiner Weise ein.
Hinweis: Da wir virtuelle Maschinen in einer virtuellen Umgebung ausführen werden, die auf virtuellen Maschinen basiert, müssen wir zunächst die verschachtelte Virtualisierung aktivieren.
Sie können wie folgt ü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 beispielsweise die Unterstützung für verschachtelte Virtualisierung gemäß einer Anleitung, die Sie im Netzwerk finden .
Wir müssen die folgende Schaltung aus virtuellen Maschinen zusammenstellen:
In meinem Fall habe ich OpenvSwitch verwendet, um die virtuellen Maschinen zu verbinden, die Teil der zukünftigen Installation sind (und ich habe sieben davon, aber Sie können mit vier auskommen, wenn Sie nicht über viele Ressourcen verfügen). Ich habe eine Ovs-Brücke erstellt und virtuelle Maschinen über Portgruppen damit verbunden. Dazu habe ich eine XML-Datei wie diese 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 Portgruppen deklariert – zwei Zugangs- und ein Trunk (letzterer wurde für den DNS-Server benötigt, aber Sie können darauf verzichten oder ihn auf dem Host-Rechner installieren – je nachdem, was für Sie bequemer ist). Als nächstes deklarieren wir mithilfe dieser Vorlage unsere über virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Jetzt bearbeiten wir die Hypervisor-Portkonfigurationen:
[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 zugänglich, da sie kein VLAN-Tag hat. Um dies zu beheben, müssen Sie den Befehl sudo ovs-vsctl set port ovs-br1 tag=100 ausgeben. Nach einem Neustart verschwindet dieses Tag jedoch (wenn jemand weiß, wie es an Ort und Stelle bleibt, wäre ich sehr dankbar). Dies ist jedoch nicht so wichtig, da wir diese Adresse nur während der Installation benötigen und nicht, wenn Openstack vollständig bereitgestellt ist.
Als nächstes erstellen wir eine Undercloud-Maschine:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Während der Installation legen Sie alle notwendigen Parameter fest, wie Maschinennamen, Passwörter, Benutzer, NTP-Server usw., Sie können die Ports sofort konfigurieren, aber für mich persönlich ist es nach der Installation einfacher, sich über die Maschine anzumelden die Konsole und korrigieren Sie die erforderlichen Dateien. Wenn Sie bereits über ein fertiges Image verfügen, können Sie es verwenden oder das tun, was ich getan habe: Laden Sie das minimale Centos 7-Image herunter und verwenden Sie es zur Installation der VM.
Nach erfolgreicher Installation sollten Sie über eine virtuelle Maschine verfügen, auf der Sie Undercloud installieren können
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningInstallieren Sie zunächst die für den Installationsprozess erforderlichen Tools:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud-Installation
Wir erstellen einen Stack-Benutzer, legen ein Passwort fest, fügen es zu sudoer hinzu und geben ihm die Möglichkeit, Root-Befehle über sudo auszuführen, ohne ein Passwort 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 Undercloud-Namen 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.localdomain6Als nächstes fügen wir Repositorys hinzu und installieren die benötigte Software:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleHinweis: Wenn Sie nicht vorhaben, Ceph zu installieren, müssen Sie keine Ceph-bezogenen Befehle eingeben. Ich habe die Version von Queens verwendet, Sie können aber auch jede andere verwenden, die Ihnen gefällt.
Kopieren Sie als Nächstes die Undercloud-Konfigurationsdatei in den Home-Verzeichnisstapel des Benutzers:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confJetzt müssen wir diese Datei korrigieren und an unsere Installation anpassen.
Sie müssen diese Zeilen am Anfang der Datei hinzufügen:
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 wir also die Einstellungen durch:
untercloud_hostname – Der vollständige Name des Undercloud-Servers muss mit dem Eintrag auf dem DNS-Server übereinstimmen
lokale_ip – lokale Undercloud-Adresse für die Netzwerkbereitstellung
network_gateway — Dieselbe lokale Adresse, die bei der Installation von Overcloud-Knoten als Gateway für den Zugriff auf die Außenwelt fungiert, stimmt auch mit der lokalen IP überein
undercloud_public_host — externe API-Adresse, jede freie Adresse aus dem Bereitstellungsnetzwerk wird zugewiesen
undercloud_admin_host Interne API-Adresse, jede freie Adresse aus dem Bereitstellungsnetzwerk wird zugewiesen
undercloud_nameservers - DNS Server
generieren_service_zertifikat - Diese Zeile ist im aktuellen Beispiel sehr wichtig, denn wenn Sie sie nicht auf false setzen, erhalten Sie bei der Installation eine Fehlermeldung, das Problem wird im Red Hat Bugtracker beschrieben
local_interface Schnittstelle in der Netzwerkbereitstellung. Diese Schnittstelle wird während der Undercloud-Bereitstellung neu konfiguriert, sodass Sie in Undercloud über zwei Schnittstellen verfügen müssen – eine für den Zugriff und die zweite für die Bereitstellung
local_mtu - MTU. Da wir ein Testlabor haben und ich auf den OVS-Switch-Ports eine MTU von 1500 habe, ist es notwendig, diese auf 1450 zu setzen, damit in VxLAN gekapselte Pakete passieren können
network_cidr — Bereitstellungsnetzwerk
Maskerade — Verwendung von NAT für den Zugriff auf ein externes Netzwerk
masquerade_network - Netzwerk, das NATed sein wird
dhcp_start – die Startadresse des Adresspools, aus dem den Knoten während der Overcloud-Bereitstellung Adressen zugewiesen werden
dhcp_end – die endgültige Adresse des Adresspools, aus dem den Knoten während der Overcloud-Bereitstellung Adressen zugewiesen werden
Inspection_iprange – ein für die Selbstbeobachtung notwendiger Adresspool (sollte sich nicht mit dem oben genannten Pool überschneiden)
Scheduler_max_attempts — 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 erteilen:
openstack undercloud install
Der Vorgang dauert je nach Bügeleisen 10 bis 30 Minuten. Letztendlich sollten Sie eine Ausgabe wie diese 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 und Sie nun den Status von Undercloud überprüfen und mit der Installation von Overcloud fortfahren können.
Wenn Sie sich die Ausgabe von ifconfig ansehen, werden Sie feststellen, dass eine neue Bridge-Schnittstelle erschienen ist
[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 erfolgt nun über diese Schnittstelle.
Aus der folgenden Ausgabe können Sie ersehen, 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 |
+--------------------------+-----------+----------+Nachfolgend finden Sie 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 Undercloud und wir haben nicht genügend Knoten, aus denen Overcloud zusammengestellt werden soll. Stellen wir daher zunächst die benötigten virtuellen Maschinen bereit. Während der Bereitstellung installiert Undercloud selbst das Betriebssystem und die erforderliche Software auf der Overcloud-Maschine – das heißt, wir müssen die Maschine nicht vollständig bereitstellen, sondern nur eine Festplatte (oder Festplatten) dafür erstellen und ihre Parameter bestimmen – das heißt Tatsächlich erhalten wir einen nackten Server, auf dem kein Betriebssystem installiert ist.
Gehen wir in den Ordner mit den Festplatten unserer virtuellen Maschinen und erstellen Sie Festplatten 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 als Root arbeiten, 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 nicht vorhaben, Ceph zu installieren, um es zu studieren, erstellen die Befehle nicht mindestens 3 Knoten mit mindestens zwei Festplatten, sondern geben in der Vorlage an, dass die virtuellen 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 gibt es einen Befehl -print-xml > /tmp/storage-1.xml, der eine XML-Datei mit einer Beschreibung jeder Maschine im Ordner /tmp/ erstellt; wenn Sie sie nicht hinzufügen, wird dies nicht der Fall sein in der Lage, virtuelle Maschinen zu identifizieren.
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 ~]#Nun eine kleine Nuance: TripleO verwendet IPMI, um Server während der Installation und Selbstbeobachtung zu verwalten.
Unter Introspektion versteht man den Prozess der Überprüfung der Hardware, um die für die weitere Bereitstellung von Knoten erforderlichen Parameter zu ermitteln. Die Introspektion erfolgt mithilfe von Ironic, einem Dienst, der für die Arbeit mit Bare-Metal-Servern entwickelt wurde.
Aber hier liegt das Problem: Während Hardware-IPMI-Server über einen separaten Port (oder einen gemeinsam genutzten Port, aber das ist nicht wichtig) verfügen, verfügen virtuelle 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 – ehrlich gesagt weiß ich nicht, ob es ein Analogon zu vbmc gibt, daher lohnt es sich, sich über dieses Problem Gedanken zu machen, bevor man alles bereitstellt .
vbmc installieren:
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 richten wir das Dienstprogramm ein. Hier ist alles banal bis zur Schande. Nun ist es logisch, dass in der vbmc-Liste keine Server vorhanden sind
[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 ohne Erklärung klar. Derzeit befinden sich jedoch alle unsere Sitzungen im Status DOWN. Damit sie in den UP-Status wechseln, 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 (oder sie vollständig 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 nun zu Undercloud und prüfen, ob alles funktioniert. Die Adresse des Host-Computers lautet 192.168.255.200. Auf Undercloud haben wir während der Vorbereitung für die Bereitstellung das erforderliche ipmitool-Paket hinzugefügt:
[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 Kontrollknoten erfolgreich über vbmc gestartet. Jetzt schalten wir es aus und machen weiter:
[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 Introspektion der Knoten, auf denen Overcloud installiert wird. Dazu müssen wir eine JSON-Datei mit einer Beschreibung unserer Knoten vorbereiten. Bitte beachten Sie, dass die Datei im Gegensatz zur Installation auf Bare-Servern für jede Maschine den Port angibt, auf dem vbmc 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: Der Kontrollknoten verfügt über zwei Schnittstellen, aber in diesem Fall ist das nicht wichtig, in dieser Installation reicht uns eine.
Jetzt bereiten wir die 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 man zu ipmi gelangt:
{
"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 ~]$Bilder in Undercloud hochladen:
(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 wurden
(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 etwas: 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 geben:
(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, wurde alles ohne Fehler abgeschlossen. Überprüfen wir, ob sich alle Knoten im verfügbaren Status befinden:
(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, normalerweise beherrschbaren Zustand befinden, ist ein Fehler aufgetreten und Sie müssen sich das Protokoll ansehen und herausfinden, warum das passiert ist. Bedenken Sie, dass wir in diesem Szenario Virtualisierung verwenden und es möglicherweise Fehler im Zusammenhang mit der Verwendung virtueller Maschinen oder vbmc gibt.
Als nächstes müssen wir angeben, welcher Knoten welche Funktion ausführen soll – das heißt, 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 ~]$Geben Sie 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-d9afb69d1167Überprüfen wir, 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 qemuBei einer realen Installation werden selbstverständlich benutzerdefinierte Vorlagen verwendet, was in unserem Fall den Vorgang erheblich verkompliziert, da jede Änderung in der Vorlage erklärt werden muss. Wie bereits geschrieben, reicht bereits eine einfache Installation aus, um zu sehen, wie es funktioniert.
Hinweis: In diesem Fall ist die qemu-Variable --libvirt-type erforderlich, da wir eine verschachtelte Virtualisierung verwenden. Andernfalls können Sie keine virtuellen Maschinen ausführen.
Jetzt haben Sie etwa eine Stunde Zeit, oder vielleicht auch mehr (abhängig von den Fähigkeiten der Hardware) und können nur hoffen, dass Sie nach dieser Zeit die folgende Meldung 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 von OpenStack, auf der Sie lernen, experimentieren usw. können.
Lassen Sie uns überprüfen, ob alles ordnungsgemäß funktioniert. Im Home-Verzeichnisstapel des Benutzers befinden sich zwei Dateien – eine stackrc (zur Verwaltung von Undercloud) und eine zweite overcloudrc (zur Verwaltung von Overcloud). Diese Dateien müssen als Quelle angegeben werden, da sie die für die Authentifizierung notwendigen Informationen enthalten.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | 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 – das Hinzufügen einer Route auf dem Controller, da sich der Computer, mit dem ich arbeite, in einem anderen Netzwerk befindet. Gehen Sie dazu unter dem Heat-Admin-Konto auf Control-1 und registrieren Sie die Route
(undercloud) [stack@undercloud ~]$ ssh [email protected]
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 in den Horizont gehen. Alle Informationen – Adressen, Login und Passwort – befinden sich in der Datei /home/stack/overcloudrc. Das endgültige Diagramm sieht folgendermaßen aus:
Bei unserer Installation wurden die Maschinenadressen übrigens per DHCP vergeben und wie man sieht, erfolgt die Vergabe „nach dem Zufallsprinzip“. Sie können in der Vorlage genau festlegen, welche Adresse bei der Bereitstellung an welche Maschine angehängt werden soll, wenn Sie dies benötigen.
Wie fließt der Datenverkehr zwischen virtuellen Maschinen?
In diesem Artikel betrachten wir drei Möglichkeiten, den Verkehr weiterzuleiten
- Zwei Maschinen auf einem Hypervisor in einem L2-Netzwerk
- Zwei Maschinen auf unterschiedlichen Hypervisoren im selben L2-Netzwerk
- Zwei Maschinen in unterschiedlichen Netzwerken (netzwerkübergreifendes Rooten)
Fälle mit Zugriff auf die Außenwelt über ein externes Netzwerk, Verwendung von Floating-Adressen sowie verteiltem Routing werden wir beim nächsten Mal berücksichtigen, vorerst konzentrieren wir uns auf den internen Datenverkehr.
Um dies zu überprüfen, stellen wir das folgende Diagramm zusammen:
Wir haben 4 virtuelle Maschinen erstellt – 3 in einem L2-Netzwerk – Net-1, und eine weitere im Net-1-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 ~]$ Sehen wir uns an, 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 Knoten Compute-1.
Darüber hinaus wurde ein virtueller Router erstellt, der das Routing zwischen den angegebenen Netzwerken ermöglicht:
(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 fungieren:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Aber bevor wir uns ansehen, wie der Datenverkehr fließt, schauen wir uns an, was wir derzeit auf dem Kontrollknoten (der auch ein Netzwerkknoten ist) und auf dem Rechenknoten haben. Beginnen wir mit dem 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 verfügt der Knoten über drei Ovs-Brücken – br-int, br-tun, br-ex. Wie wir sehen, gibt es zwischen ihnen eine Reihe von Schnittstellen. Um das Verständnis zu erleichtern, zeichnen wir alle diese Schnittstellen im Diagramm ein und sehen, was passiert.
Wenn man sich die Adressen ansieht, zu denen VxLAN-Tunnel hochgezogen werden, erkennt man, dass ein Tunnel auf „compute-1“ (192.168.255.26) hochgestuft wird, der zweite Tunnel auf „control-1“ (192.168.255.15). Aber das Interessanteste ist, dass br-ex keine physischen Schnittstellen hat, und wenn man sich anschaut, welche Flows konfiguriert sind, sieht man, dass diese Bridge derzeit nur Datenverkehr abwerfen 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 der Ausgabe entnehmen 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 ~]$
Gemäß der ersten Regel muss alles, was vom Phy-Br-Ex-Port kam, verworfen werden.
Tatsächlich kann der Verkehr derzeit nirgendwo anders auf diese Brücke gelangen als über diese Schnittstelle (die Schnittstelle mit br-int), und den Verlusten nach zu urteilen, ist BUM-Verkehr bereits in die Brücke geflossen.
Das heißt, der Datenverkehr kann diesen Knoten nur über den VxLAN-Tunnel verlassen und sonst nichts. Wenn Sie jedoch den DVR einschalten, ändert sich die Situation, aber darauf gehen wir ein anderes Mal ein. Wenn Sie Netzwerkisolation verwenden, beispielsweise mit VLANs, verfügen Sie in VLAN 3 nicht über eine L0-Schnittstelle, sondern über mehrere Schnittstellen. Der VxLAN-Verkehr verlässt den Knoten jedoch auf die gleiche Weise, allerdings auch gekapselt in einer Art dediziertem VLAN.
Wir haben den Rechenknoten aussortiert, gehen wir zum Kontrollknoten über.
[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 beim Alten ist, aber die IP-Adresse liegt nicht mehr auf der physischen Schnittstelle, sondern auf der virtuellen Brücke. Dies geschieht, weil dieser Port der Port ist, über den der Datenverkehr 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 an die BR-EX-Brücke gebunden und da es keine VLAN-Tags darauf gibt, ist dieser Port ein Trunk-Port, auf dem alle VLANs erlaubt sind. Jetzt geht der Datenverkehr ohne Tag nach draußen, wie durch VLAN-ID 0 im angegeben Ausgabe oben.
Alles andere ähnelt im Moment dem Rechenknoten – die gleichen Brücken, die gleichen Tunnel, die zu zwei Rechenknoten führen.
Wir werden in diesem Artikel nicht auf Speicherknoten eingehen, aber zum Verständnis muss man sagen, dass der Netzwerkteil dieser Knoten bis zur Schande banal ist. In unserem Fall gibt es nur einen physischen Port (eth0), dem eine IP-Adresse zugewiesen ist, 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, Bodny oder nur zwei VLANs – egal – es kommt darauf an, was Sie wollen) – eine für die Verwaltung, die zweite für den Datenverkehr (Schreiben auf die VM-Festplatte). , Lesen von der Festplatte usw.)
Wir haben herausgefunden, was wir auf den Knoten haben, wenn keine Dienste vorhanden sind. Lassen Sie uns nun 4 virtuelle Maschinen starten und sehen, wie sich das oben beschriebene Schema ändert – wir sollten Ports, virtuelle Router usw. haben.
Bisher sieht unser Netzwerk so aus:
Wir haben auf jedem Computerknoten zwei virtuelle Maschinen. Lassen Sie uns am Beispiel von „compute-0“ sehen, wie alles 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 verfügt nur über 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 sieht in der Linux-Bridge aus:
[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 Bridge nur zwei Schnittstellen – tap95d96a75-a0 und qvb95d96a75-a0.
Hier lohnt es sich, ein wenig auf die Arten virtueller Netzwerkgeräte in OpenStack einzugehen:
vtap – virtuelle Schnittstelle, die an eine Instanz (VM) angeschlossen ist
qbr – Linux-Brücke
qvb und qvo – vEth-Paar, verbunden mit der Linux-Bridge und der Open vSwitch-Bridge
br-int, br-tun, br-vlan – Offene vSwitch-Brücken
patch-, int-br-, phy-br- – Offene vSwitch-Patchschnittstellen, die Bridges verbinden
qg, qr, ha, fg, sg – Offene vSwitch-Ports, die von virtuellen Geräten zum Herstellen einer Verbindung mit OVS verwendet werden
Wie Sie wissen, gibt es, wenn wir einen qvb95d96a75-a0-Port in der Bridge haben, der ein vEth-Paar ist, irgendwo sein Gegenstück, das logischerweise qvo95d96a75-a0 heißen sollte. Schauen wir uns an, welche Ports es auf OVS gibt.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Wie wir sehen können, ist der Port in br-int. Br-int fungiert als Switch, der die Ports virtueller Maschinen beendet. Zusätzlich zu qvo95d96a75-a0 ist in der Ausgabe der Port qvo5bd37136-47 sichtbar. Dies ist der Port zur zweiten virtuellen Maschine. Als Ergebnis sieht unser Diagramm nun so aus:
Eine Frage, die den aufmerksamen Leser sofort interessieren dürfte: Was ist die Linux-Brücke zwischen dem Port der virtuellen Maschine und dem OVS-Port? Tatsache ist, dass zum Schutz der Maschine Sicherheitsgruppen verwendet werden, die nichts anderes als iptables sind. OVS funktioniert nicht mit iptables, daher wurde diese „Krücke“ erfunden. Es ist jedoch veraltet – es wird in neuen Versionen durch conntrack ersetzt.
Das heißt, letztendlich sieht das Schema so aus:
Zwei Maschinen auf einem Hypervisor in einem L2-Netzwerk
Da sich diese beiden VMs im selben L2-Netzwerk und im selben Hypervisor befinden, fließt der Datenverkehr zwischen ihnen logischerweise lokal über br-int, da sich beide Maschinen im selben VLAN befinden:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Zwei Maschinen auf unterschiedlichen Hypervisoren im selben L2-Netzwerk
Sehen wir uns nun an, wie der Datenverkehr zwischen zwei Maschinen im selben L2-Netzwerk verläuft, die sich jedoch auf unterschiedlichen Hypervisoren befinden. Um ehrlich zu sein, wird sich nicht viel ändern, nur der Verkehr zwischen Hypervisoren wird durch den VXLAN-Tunnel laufen. Schauen wir uns ein Beispiel an.
Adressen virtueller Maschinen, zwischen denen wir den Datenverkehr überwachen:
[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 schauen uns die Weiterleitungstabelle in br-int auf Compute-0 an:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Der Verkehr sollte zu Port 2 gehen – mal sehen, um welche Art von Port es sich handelt:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Dies ist Patch-Tun, also die Schnittstelle in 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 verpackt 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 wir zu „compute-1“ und sehen, 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 ~]$ Mac befindet sich in der br-int-Weiterleitungstabelle auf Compute-1, und wie aus der obigen Ausgabe ersichtlich ist, ist er über Port 2 sichtbar, der der Port zu br-tun ist:
[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 br-int auf Compute-1 einen Ziel-Poppy 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 bereits die Instanz der virtuellen Maschine 00000003 befindet.
Das Schöne an der Bereitstellung von OpenStack für das Lernen in einer virtuellen Infrastruktur ist, dass wir den Datenverkehr zwischen Hypervisoren problemlos erfassen und sehen können, was damit passiert. Folgendes werden wir jetzt tun: Führen Sie tcpdump auf dem VNET-Port in Richtung Compute-0 aus:
[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 Patek von der Adresse 10.0.1.85 zur Adresse 10.0.1.88 geht (ICMP-Verkehr), und es wird in ein VxLAN-Paket mit VNI 22 verpackt und das Paket geht von Host 192.168.255.19 (Compute-0) zu Host 192.168.255.26 .1 (Berechnen-XNUMX). Wir können überprüfen, ob der VNI mit dem in 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 vni im hexadezimalen Zahlensystem. Lassen Sie uns diese Zahl in das 16. System umwandeln:
16 = 6*16^0+1*16^1 = 6+16 = 22Das heißt, vni entspricht der Realität.
Die zweite Zeile zeigt den Rückverkehr, naja, es hat keinen Sinn, das zu erklären, da ist alles klar.
Zwei Maschinen in unterschiedlichen Netzwerken (Inter-Netzwerk-Routing)
Der letzte Fall für heute ist das Routing zwischen Netzwerken innerhalb eines Projekts mithilfe eines virtuellen Routers. Wir erwägen einen Fall ohne DVR (wir werden ihn in einem anderen Artikel betrachten), sodass das Routing auf dem Netzwerkknoten erfolgt. In unserem Fall wird der Netzwerkknoten nicht in einer separaten Einheit platziert, sondern befindet sich auf dem Kontrollknoten.
Sehen wir uns zunächst an, ob 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 Poppy-Adresse des Gateways herausfinden, wofür wir uns die ARP-Tabelle in der Instanz ansehen:
$ 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 eth0Schauen wir uns nun an, wohin der Datenverkehr mit dem Ziel (10.0.1.254) fa:16:3e:c4:64:70 gesendet werden soll:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Schauen wir uns an, wohin Port 2 führt:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Alles ist logisch, der Verkehr geht nach Br-Tun. Mal sehen, in welchen VXLAN-Tunnel es eingebunden wird:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Der dritte Port ist ein VXLAN-Tunnel:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Was sich den Kontrollknoten ansieht:
[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 Datenverkehr hat den Kontrollknoten erreicht, also müssen wir dorthin gehen und sehen, wie das Routing abläuft.
Wie Sie sich erinnern, sah der Kontrollknoten 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. Durch die Erstellung von Instanzen änderte sich die Konfiguration auf den Rechenknoten – Linux Bridge, Iptables und Schnittstellen wurden zu den Knoten hinzugefügt. Die Schaffung von Netzwerken und eines virtuellen Routers hinterließ auch ihre Spuren in der Konfiguration des Kontrollknotens.
Daher ist es offensichtlich, dass die Gateway-MAC-Adresse in der br-int-Weiterleitungstabelle auf dem Steuerknoten enthalten sein muss. Überprüfen wir, ob es da ist und wo es hinschaut:
[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.
Sehen wir uns an, welche Namespaces auf dem Server vorhanden sind:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Bis zu drei Exemplare. Aber anhand der Namen zu urteilen, kann man den Zweck jedes einzelnen davon erraten. Wir werden später auf Instanzen mit ID 0 und 1 zurückkommen, jetzt interessiert uns der Namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Dieser Namespace enthält zwei interne Namensräume, die wir zuvor erstellt haben. Beide virtuellen Ports wurden zu br-int hinzugefügt. Überprüfen wir die Mac-Adresse des Ports qr-0c52b15f-8f, da der Datenverkehr, gemessen an der Ziel-Mac-Adresse, an diese 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 nach den Gesetzen des Standard-Routings. Da der Datenverkehr für Host 10.0.2.8 bestimmt ist, muss er über die zweite Schnittstelle qr-92fa49b5-54 ausgehen und durch den VXLAN-Tunnel zum Rechenknoten gelangen:
[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. Mal sehen, wo die Poppy-Adresse von Host 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 gelangt:
[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 Datenverkehr gelangt in den Tunnel zu Compute-1. 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 ~]$ Überprüfen wir, 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 das Paket komplett durchgesehen. Ich glaube, Ihnen ist aufgefallen, dass der Datenverkehr durch verschiedene VXLAN-Tunnel ging und mit unterschiedlichen VNIs ausstieg. Schauen wir uns an, um welche Art von VNI es sich dabei handelt. Anschließend sammeln wir einen Dump auf dem Kontrollport des Knotens und stellen sicher, dass der Datenverkehr genau wie oben beschrieben fließt.
Der Tunnel zu Compute-0 hat also die folgenden Aktionen=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Lassen Sie uns 0x16 in das Dezimalzahlensystem umwandeln:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Der Tunnel zu Compute-1 hat das folgende VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Lassen Sie uns 0x63 in das Dezimalzahlensystem umwandeln:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Schauen wir uns nun 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 dem ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 verpackt ist. Wie wir oben berechnet haben, stimmt vni mit dem überein, was wir in der Ausgabe 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 dem ein ICMP-Paket von Host 10.0.1.85 zu Host 10.0.2.8 verpackt ist. Wie wir oben berechnet haben, stimmt vni mit dem überein, was wir in der Ausgabe gesehen haben.
Bei den nächsten beiden Paketen handelt es sich um Rückverkehr von 10.0.2.8, nicht von 10.0.1.85.
Das heißt, am Ende haben wir das folgende Kontrollknotenschema erhalten:
Sieht so aus, als wäre es das? Wir haben zwei Namensräume 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 gut, wenn Maschinen automatisch Adressen von einem DHCP-Server erhalten würden. 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 wahr 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 0Schauen wir uns an, ob sich auf dem Kontrollknoten Prozesse befinden, die qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 in ihrem Namen 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 anhand der in der obigen Ausgabe dargestellten Informationen können wir beispielsweise sehen, was wir derzeit zur Miete haben:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Als Ergebnis erhalten wir den folgenden Satz von Diensten auf dem Kontrollknoten:
Denken Sie daran – das sind nur 4 Maschinen, 2 interne Netzwerke und ein virtueller Router … Wir haben hier jetzt keine externen Netzwerke, sondern eine Reihe verschiedener Projekte, jedes mit seinen eigenen Netzwerken (überlappend), und das haben wir Ein verteilter Router wurde ausgeschaltet, und am Ende befand sich schließlich nur ein Kontrollknoten im Prüfstand (aus Gründen der Fehlertoleranz muss ein Quorum von drei Knoten vorhanden sein). Es ist logisch, dass im Handel alles „etwas“ komplizierter ist, aber in diesem einfachen Beispiel verstehen wir, wie es funktionieren sollte – ob Sie 3 oder 300 Namensräume haben, ist natürlich wichtig, aber aus Sicht der Funktionsweise des Ganzen In der Struktur wird sich nicht viel ändern, bis Sie jedoch ein SDN eines Anbieters einbinden. Aber das ist eine ganz andere Geschichte.
Ich hoffe, es war interessant. Wenn Sie irgendwelche Kommentare/Ergänzungen haben oder irgendwo, wo ich völlig gelogen habe (ich bin ein Mensch und meine Meinung wird immer subjektiv sein) – schreiben Sie, was korrigiert/hinzugefügt werden muss – wir werden alles korrigieren/hinzufügen.
Abschließend möchte ich noch ein paar Worte zum Vergleich von Openstack (sowohl Vanilla als auch Vendor) mit der Cloud-Lösung von VMWare sagen – diese Frage wurde mir in den letzten Jahren zu oft gestellt, und ehrlich gesagt wird sie mir auch gestellt Ich habe es schon satt, aber trotzdem. Meiner Meinung nach ist es sehr schwierig, diese beiden Lösungen zu vergleichen, aber wir können definitiv sagen, dass beide Lösungen Nachteile haben und man bei der Auswahl einer Lösung die Vor- und Nachteile abwägen muss.
Wenn OpenStack eine Community-gesteuerte Lösung ist, dann hat VMWare das Recht, nur das zu tun, was es will (lesen Sie – was für es profitabel ist), und das ist logisch – denn es ist ein kommerzielles Unternehmen, das es gewohnt ist, mit seinen Kunden Geld zu verdienen. Aber es gibt ein großes und fettes ABER – man kann von OpenStack, zum Beispiel von Nokia, absteigen und mit geringem Aufwand auf eine Lösung, zum Beispiel von Juniper (Contrail Cloud), umsteigen, von VMWare wird man aber wahrscheinlich nicht wegkommen . Für mich sehen diese beiden Lösungen so aus: Openstack (Anbieter) ist ein einfacher Käfig, in den man gesteckt wird, aber einen Schlüssel hat und den man jederzeit verlassen kann. VMWare ist ein goldener Käfig, der Besitzer hat den Schlüssel zum Käfig und es wird Sie viel kosten.
Ich bewerbe weder das erste noch das zweite Produkt – Sie wählen, was Sie brauchen. Aber wenn ich eine solche Wahl hätte, würde ich beide Lösungen wählen – VMWare für die IT-Cloud (geringe Auslastung, einfache Verwaltung), OpenStack von irgendeinem Anbieter (Nokia und Juniper bieten sehr gute schlüsselfertige Lösungen) – für die Telekommunikations-Cloud. Ich würde Openstack nicht für die reine IT verwenden – es ist, als würde man mit einer Kanone auf Spatzen schießen, aber ich sehe keine Kontraindikationen für die Verwendung außer der Redundanz. Der Einsatz von VMWare in der Telekommunikation ist jedoch wie das Transportieren von Schotter in einem Ford Raptor – von außen sieht es schön aus, aber der Fahrer muss 10 Fahrten statt einer machen.
Meiner Meinung nach ist der größte Nachteil von VMWare seine völlige Geschlossenheit – das Unternehmen wird Ihnen keine Informationen darüber geben, wie es funktioniert, z. B. vSAN oder was im Hypervisor-Kernel enthalten ist – es ist einfach nicht rentabel für es – das heißt, Sie werden es tun Werden Sie niemals ein Experte für VMWare – ohne Herstellerunterstützung sind Sie dem Untergang geweiht (sehr oft treffe ich VMWare-Experten, die durch triviale Fragen verwirrt sind). Für mich bedeutet VMWare den Kauf eines Autos mit verriegelter Motorhaube – ja, Sie haben vielleicht Spezialisten, die den Zahnriemen wechseln können, aber nur derjenige, der Ihnen diese Lösung verkauft hat, kann die Motorhaube öffnen. Ich persönlich mag keine Lösungen, in die ich nicht hineinpasse. Sie werden sagen, dass Sie möglicherweise nicht unter die Haube gehen müssen. Ja, das ist möglich, aber ich sehe Sie an, wenn Sie eine große Funktion in der Cloud aus 20 bis 30 virtuellen Maschinen und 40 bis 50 Netzwerken zusammenstellen müssen, von denen die Hälfte nach draußen gehen möchte und die andere Hälfte darum bittet SR-IOV-Beschleunigung, sonst braucht man mehr als ein paar Dutzend dieser Autos – sonst reicht die Leistung nicht aus.
Es gibt andere Standpunkte, sodass nur Sie entscheiden können, was Sie wählen möchten, und, was am wichtigsten ist, Sie sind dann 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 zum Vergleichen.
Source: habr.com