[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | français ]
Speicherarchitektur¶
OpenStack muss mehrere Speicherbereiche berücksichtigen:
Blockspeicher (cinder)
Objektspeicher (swift)
Abbildspeicher (glance)
Ephemer Speicher (Nova)
Datei Storage (manila)
Blockspeicher (cinder)¶
Der Blockspeicherdienst (Cinder) verwaltet Datenträger auf Speichergeräten in einer Umgebung. In einer Produktionsumgebung präsentiert das Gerät Speicher über ein Speicherprotokoll (z.B. NFS, iSCSI oder Ceph RBD) für ein Speichernetzwerk (br-Speicher) und eine Speicherverwaltungs-API für das Verwaltungsnetzwerk (`` br-mgmt``). Instanzen werden vom Hypervisor auf dem Compute-Host über das Speichernetzwerk mit den Datenträger verbunden.
Das folgende Diagramm zeigt, wie der Blockspeicher mit Instanzen verbunden ist.
Das Diagramm zeigt die folgenden Schritte.¶
Ein Datenträger wird vom zugewiesenen Dienst |
|
Nachdem der Datenträger erstellt wurde, verbindet der Dienst |
|
Nachdem der Hypervisor mit dem Datenträger verbunden ist, stellt er den Datenträger als lokales Hardwaregerät für die Instanz bereit. |
Wichtig
Der LVMVolumeDriver ist als eine Referenztreiberimplementierung konzipiert, die wir für die Produktionsnutzung nicht empfehlen. Das LVM-Speicher-Back-End ist eine Einzelserverlösung, die keine Hochverfügbarkeitsoptionen bietet. Wenn der Server nicht mehr verfügbar ist, sind alle Datenträger, die vom auf dieser Server ausgeführten Dienst cinder-volume verwaltet werden, nicht mehr verfügbar. Das Aktualisieren der Betriebssystempakete (z. B. Kernel oder iSCSI) auf dem Server führt zu Speicherkonnektivitätsausfällen, da der iSCSI-Dienst (oder der Host) neu gestartet wird.
Wegen limitation with container iSCSI connectivity müssen Sie den Dienst cinder-volume direkt auf einem physischen Host (nicht in einem Container) bereitstellen, wenn Speicherbackends verwendet werden, die über iSCSI verbunden sind. Dazu gehören der LVMVolumeDriver und viele der Treiber für kommerzielle Speichergeräte.
Bemerkung
Der Dienst cinder-volume wird nicht in einer hoch verfügbaren Konfiguration ausgeführt. Wenn der Dienst cinder-volume konfiguriert ist, um Datenträger auf demselben Back-End von mehreren Hosts oder Containern zu verwalten, wird ein Dienst so geplant, dass er den Lebenszyklus des Volumes verwaltet, bis ein alternativer Service zugewiesen wird. Diese Zuweisung kann über das cinder-manage CLI tool erfolgen. Diese Konfiguration kann sich ändern, wenn cinder volume active-active support spec für den Datenträger aktiv ist.
Objektspeicher (swift)¶
Der Objektspeicherdienst (swift) implementiert einen hoch verfügbaren, verteilten, möglicherweise konsistenten Objekt-/Blob-Speicher, auf den über HTTP/HTTPS zugegriffen werden kann.
Das folgende Diagramm zeigt, wie auf Daten zugegriffen wird und wie sie repliziert werden.
Der Dienst swift-proxy wird von Clients über den Load Balancer im Verwaltungsnetzwerk (br-mgmt) aufgerufen. Der Dienst swift-proxy kommuniziert mit den Diensten Account, Container und Object auf den Object Storage-Hosts über das Speichernetzwerk (`` br-storage``). Die Replikation zwischen den Object Storage-Hosts erfolgt über das Replikationsnetzwerk (`` br-repl``).¶
Abbildspeicher (glance)¶
Der Abbild-Dienst (glance) kann so konfiguriert werden, dass er Abbilder auf verschiedenen Speicher-Back-Ends speichert, die von den glance_store drivers unterstützt werden.
Wichtig
Wenn der Dateisystemspeicher verwendet wird, hat der Abbild-Dienst keinen eigenen Mechanismus, um das Abbild zwischen Abbild-Service-Hosts zu replizieren. Wir empfehlen die Verwendung eines gemeinsamen Speicher-Backends (über ein Dateisystem-Mount), um sicherzustellen, dass alle glance-api-Dienste Zugriff auf alle Abbilder haben. Dadurch wird verhindert, dass der Zugriff auf Abbilder verloren geht, wenn ein Host der Infrastruktur (Kontrollebene) verloren geht.
Das folgende Diagramm veranschaulicht die Interaktionen zwischen dem Abbild-Dienst, dem Speichergerät und dem Dienst nova-compute, wenn eine Instanz erstellt wird.
Das Diagramm zeigt die folgenden Schritte.¶
1 |
Wenn ein Client ein Abbild anfordert, greift der |
2 |
Wenn eine Instanz für die Erstellung auf einem Compute-Host geplant ist, fordert der Dienst |
3 |
Nachdem das Abbild abgerufen wurde, speichert der |
Ephemer Speicher (Nova)¶
Wenn die Flavors im Compute-Dienst so konfiguriert sind, dass Instanzen mit Root- oder Ephemeral-Festplatten bereitgestellt werden, verwaltet der Dienst nova-compute diese Zuweisungen unter Verwendung seines temporären Speicherplatzes.
In vielen Umgebungen werden die ephemeren Festplatten auf den lokalen Festplatten des Compute-Hosts gespeichert. In Produktionsumgebungen wird jedoch empfohlen, dass die Compute-Hosts so konfiguriert werden, dass sie stattdessen ein gemeinsam genutztes Speichersubsystem verwenden. Ein gemeinsam genutztes Speichersubsystem ermöglicht eine schnelle, dynamische Instanzmigration zwischen Compute-Hosts. Dies ist nützlich, wenn der Administrator Wartungsarbeiten am Compute-Host durchführen und diesen leeren muss. Die Verwendung eines gemeinsam genutzten Speichersubsystems ermöglicht auch die Wiederherstellung von Instanzen, wenn ein Compute-Host offline geht. Der Administrator kann die Instanz auf einen anderen Compute-Host verschieben und erneut starten. Das folgende Diagramm veranschaulicht die Interaktionen zwischen dem Speichergerät, dem Compute-Host, dem Hypervisor und der Instanz.
Das Diagramm zeigt die folgenden Schritte.¶
1 |
Der Compute-Host ist mit Zugriff auf das Speichergerät konfiguriert. Der Compute-Host greift über das Speichernetzwerk ( |
2 |
Der Dienst |
3 |
Der Hypervisor präsentiert die Festplatte als ein Gerät für die Instanz. |
Datei Storage (manila)¶
The shared filesystem service (manila) can be configured to provide file systems on a variety of storage back ends as supported by the manila_store drivers.
The diagram shows a basic overview of the manila service.¶
