Local SSD Storage

Übersicht

Standard Shared Storage auf Basis von Ceph hat ein ausgewogenes Leistungsprofil, das nicht für alle Anwendungsfälle geeignet ist. Insbesondere Etcd und transaktionale Datenbanken wie Postgres sind dafür bekannt, dass es hier zu Performance-Problemen kommt.

pluscloud open bietet Local SSD Storage als Option für die Speicherung von Daten auf Instanzen an. Local SSD Storage ist ein nicht gemeinsam genutzter Speicher, der physisch mit der Instanz verbunden ist und hohe Input/Output-Operationen pro Sekunde (IOPS) und geringe Latenzzeiten bietet. Er ist ideal für Anwendungen, die eine hohe Leistung und eine geringe Latenzzeit erfordern.

Local SSD Storage ist ideal für flüchtige oder temporäre Arbeitslasten wie Caches. Ebenfalls gute Kandidaten für Local SSD Storage sind hochautomatisierte replizierte Datenbanken oder Key-Value-Stores wie Patroni oder Etcd, bei denen automatische Replikation und Failover in den Software-Stack integriert sind.

Vergleich der Eigenschaften von Ceph-Volumes Local SSD Storage

Es gibt grundlegende Unterschiede zwischen Ceph-Volumes und Local SSD Storage.

Bei Shared Storage sorgt das zugrundeliegende Speichersystem für Redundanz und Verfügbarkeit. Ihre Anwendung kann sich auf den dreifach replizierten hochverfügbaren Speicher verlassen.

Bei Local SSD Storage können Sie auf die lokale Festplatte im Rohzustand zugreifen und nahezu 1:1-Leistung erzielen. Allerdings ist Ihr Software-Stack für die Handhabung der Redundanz und Verfügbarkeit verantwortlich.

Anwendungsfälle für Local SSD Storage:

• Kubernetes
• Etcd-Cluster mit 3 oder 5 Instanzen
• Postgres-Patroni-Cluster

Anti-Patterns für Local SSD Storage:

• Traditionelle Einzelserver-Einrichtung
• VMs werden ohne Configuration Management eingerichtet
• VMs ohne Snapshots

In der folgenden Tabelle werden die Merkmale von Ceph-Volumes mit denen von Local SSD Storage verglichen:

Verfügbarkeit

Es gibt zwei Fälle, in denen bei VMs, die auf Local SSD Storage laufen, Ausfallzeiten auftreten können

Regelmäßige Wartungsarbeiten

Hardware-Ausfall

Im Falle eines vollständigen Hardwareausfalls oder einer Neukonfiguration müssen Sie mit Datenverlust rechnen.

In diesen Fällen gehen die Boot-Volumes verloren. Das bedeutet, dass beim Wiederanlauf des Hypervisors beschädigte VMs vorhanden sind.

Es wird von Ihnen erwartet, dass Sie diese VMs selbst löschen. Wir sind der Meinung, dass es besser ist, defekte VM-Definitionen aufzubewahren, damit Sie diese Instanzen zuverlässiger aus einer Sicherung oder einem Snapshot wiederherstellen können. Sie müssen für defekte VMs bezahlen.

Apropos Backups: Sie sollten regelmäßig Snapshots erstellen, um im Falle eines Hardwareausfalls des zugrundeliegenden Hypervisors eine ausgefallene VM wiederherstellen zu können.

Server-Gruppen und Anti-Affinität zur Erzielung von Fehlertoleranz

Bei der Verwendung von Local SSD Storage ist es wichtig, Fehlertoleranz gegen Hypervisor-Ausfälle vorzusehen.

Eine Möglichkeit ist die Verwendung von Server-Gruppen, um Ihre VMs auf mehrere Hypervisoren zu verteilen.

Local SSD Storage verwenden

Um Local SSD Storage zu verwenden, erstellen Sie einfach eine VM mit einem bestimmten Flavor für Local SSD Storage. Alle Flavors, die mit einem “s” enden, stehen für Local SSD Storage. Konfigurieren Sie die VM so, dass sie ohne Volume bootet. Dies ist wichtig, wenn Sie möchten, dass die VM von einem lokalen Datenträger und nicht von einem Remote-Volume bootet.

Nachdem Sie die VM erstellt haben, bootet sie mit einer lokalen Festplatte vom Blockgerät /dev/sda1. Sie können zusätzliche Datenträger an Ihre VM anhängen. Diese Volumes stammen jedoch aus dem gemeinsam genutzten Ceph-Speicher.

Beispiele für Varianten von Local SSD Storage:

Erstellen einer VM mit Horizon

Gehen Sie folgendermaßen vor, um eine VM zu erstellen, die Local SSD Storage verwendet:

Navigieren Sie zum Dialogfeld “Launch Instance” (Instanz starten). Stellen Sie unter “Details” den “Instanzname” ein.

Wählen Sie unter “Quelle” Ihr bevorzugtes Cloud-Image aus. Belassen Sie die Voreinstellung, von einem Image zu booten und kein Volume zu erstellen.

Wählen Sie unter “Flavor” einen der Flavor aus, die auf “s” enden.

Konfigurieren Sie die übrigen Einstellungen nach Belieben. Zum Schluss starten Sie die Instanz.

Erstellen einer VM mit der CLI

Um eine identische VM mit der OpenStack CLI zu erstellen, verwenden Sie den folgenden Befehl:

openstack server create --flavor SCS-2V-4-20s --image "Ubuntu 22.04" demo-cli

Die Ausgabe sollte wie folgt aussehen:

+-----------------------------+-----------------------------------------------------+
| Field                       | Value                                               |
+-----------------------------+-----------------------------------------------------+
| OS-DCF:diskConfig           | MANUAL                                              |
| OS-EXT-AZ:availability_zone |                                                     |
| OS-EXT-STS:power_state      | NOSTATE                                             |
| OS-EXT-STS:task_state       | scheduling                                          |
| OS-EXT-STS:vm_state         | building                                            |
| OS-SRV-USG:launched_at      | None                                                |
| OS-SRV-USG:terminated_at    | None                                                |
| accessIPv4                  |                                                     |
| accessIPv6                  |                                                     |
| addresses                   |                                                     |
| adminPass                   |                                                     |
| config_drive                |                                                     |
| created                     | 2024-02-09T13:21:50Z                                |
| flavor                      | SCS-2V-4-20s                                        |
| hostId                      |                                                     |
| id                          | abcdef08-bf2a-4375-bfe3-0f48755df3db                |
| image                       | Ubuntu 22.04                                        |
| key_name                    | None                                                |
| name                        | demo-cli                                            |
| progress                    | 0                                                   |
| project_id                  | abcdef05fd7d49c2bdbf9bc66f5b6ed4                    |
| properties                  |                                                     |
| security_groups             | name='default'                                      |
| status                      | BUILD                                               |
| updated                     | 2024-02-09T13:21:50Z                                |
| user_id                     | abcdef07436c4f15a4eb77ed737c3206                    |
| volumes_attached            |                                                     |
+-----------------------------+-----------------------------------------------------+