Wenn Sie ein Administrator von virtualisierten Umgebungen sind, haben Sie bestimmt schon einmal Probleme mit der IO-Leistung gehabt. IO ist der erste Engpass, auf den man stößt. Glücklicherweise hat sich die persistente Speicherung im Laufe der Jahre weiterentwickelt und in letzter Zeit sehen wir hochleistungsfähige SSDs zu einem vernünftigen Preis, der immer noch weit höher ist, als dass Unternehmen vollständig auf SSD migrieren könnten.
Hybride Umgebungen werden immer beliebter, da sie die niedrigen Kosten traditioneller Festplatten mit den hochleistungsfähigen Solid-State-Laufwerken kombinieren. Eines der Hauptmerkmale der Cinder Storage-Backend-Komponente von OpenStack ist die Flexibilität, die es uns ermöglicht, mehr als ein Storage-Backend auf unserem Storage Node zu haben. Dies gibt uns die Flexibilität, die IO-lastigen Anwendungen von den mehr computerorientierten Anwendungen zu unterscheiden, die eine höhere CPU-Auslastung haben. Ein typisches Beispiel ist die Konfiguration einer Datenbank-VM für die Ausführung auf einem SSD-Laufwerk und des Anwendungsserver-Clusters auf normalem Speicher, der beim Start stark schreibgeschützt ist.
Wie man das mit OpenStack und Cinder erreicht
In unserer Umgebung verwenden wir den NFS-Volumentreiber, der einfach zu konfigurierende verteilte Volumes ermöglicht, die über alle Rechenknoten hinweg gemountet werden können. Ob dies die geeignetste und stabilste Lösung ist, steht auf einem anderen Blatt, wenn man bedenkt, dass es eine Vielzahl von Speicher-Backends gibt - ceph, glusterfs, iSCSI-basierte. Sie können die Unterscheidung von SSD und HDD mit jedem von ihnen anwenden.
Unsere erste Aufgabe besteht darin, verschiedene Einhängepunkte auf unserem Server einzurichten, die sich auf LVM oder direkt auf einer physischen Partition (nicht empfohlen) befinden, und zwar sowohl auf unserem SSD-Speicherarray oder unserer Festplatte als auch auf unseren einfachen alten Festplatten. Wir müssen diese Einhängepunkte als verschiedene Exporte in /etc/exports definieren.
/exporthdd 192.168.0.0/24(rw,no_subtree_check,sync,no_root_squash) # this is a mountpoint of plain hard disk physical devices
/exportssd 192.168.0.0/24(rw,no_subtree_check,sync,no_root_squash) # this is a mountpoint for the SSD physical disksStellen Sie sicher, dass die NFS-Exporte mit dem Befehl exportsfs geladen sind.
Wie in der RedHat-Dokumentation von OpenStack beschrieben, haben wir die Möglichkeit, mehrere Konfigurationsblöcke in der Datei cinder.conf zu definieren. Es wird jedoch der Eindruck erweckt, dass diese für die Definition verschiedener Speichertreiber gedacht sind. Während dies tatsächlich der typischste Anwendungsfall ist, schränkt cinder Sie nicht ein, mehrere Blöcke mit demselben Treiber zu definieren.
[NAME]
volume_group=GROUP
volume_driver=DRIVER
volume_backend_name=BACKENDBearbeiten Sie nun die Hauptkonfigurationsdatei:
[nfsssd]
nfs_used_ratio=0.95
nfs_oversub_ratio=1.0
volume_driver=cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config=/etc/cinder/nfs_shares_ssd.conf
volume_backend_name=nfsssdEs ist sehr wichtig, einen volume_backend_name zu definieren. Dies ermöglicht, dass dieses Backend in der Horizon-GUI erscheint und auch auswählbar ist, wenn ein Volume über die Kommandozeile erstellt wird. Um dieses Backend zu aktivieren, müssen wir es auch in der gleichen Konfigurationsdatei /etc/cinder/cinder.conf im obersten Abschnitt in einer kommaseparierten Liste angeben.
enabled_backends=XXX,XXX,nfs,nfsssdWie im Abschnitt nfsssd gesehen, definieren wir eine andere Konfigurationsdatei für nfs-Freigaben, die die Einhängepunkte und Pfade zu den
Damit Benutzer angeben können, auf welchem Backend ihre Volumes erstellt werden, anstatt sich auf die automatische Auswahl durch den Scheduler zu verlassen, muss ein Volume-Typ in der Datenbank definiert werden. Sobald die Dienste neu gestartet sind und laufen, kann dies mit diesen Befehlen erfolgen:
cinder type-create nfsssd
cinder type-key <the id returned from the create command> set volume_backend_name='nfsssd'Dies ist die Beziehung zum Namen des Volume-Backends, der in der Konfiguration angegeben wurde, und ermöglicht es uns, bei der Erstellung eines Volumes zu wählen, welcher Typ es sein soll, oder mit anderen Worten, auf welchem Backend es sich befinden soll.
Um die Erstellung zu testen, können Sie das Befehlszeilentool unter Angabe des Volume-Typs verwenden.
cinder create --display-name test1 --volume-type nfsssd 2Jetzt kann dieses Volume in jede unserer virtuellen Maschinen eingebunden werden.
Ich hoffe, dieser Artikel hat Ihnen geholfen. Ich würde mich freuen, wenn Sie Kommentare dazu hinterlassen, wie man das SSD-Backend weiter optimieren kann, ob es besser für die Leistung ist, wenn es nicht auf LVM, sondern direkt auf der Festplatte liegt.
Außerdem würde ich gerne Ihre Erfahrungen hören: Wann mussten Sie verschiedene Volume-Backends verwenden und was würden Sie anstelle von NFS bevorzugen?
