[ English | Indonesia | Deutsch | 日本語 ]
Sicherung und Wiederherstellung¶
Bei der Erstellung Ihrer OpenStack-Backup-Richtlinie gelten die üblichen Backup-Best Practices. Zum Beispiel hängt die Häufigkeit der Sicherung Ihrer Daten eng damit zusammen, wie schnell Sie nach einem Datenverlust wiederherstellen müssen.
Bemerkung
Wenn Sie überhaupt keinen Datenverlust erleiden können, sollten Sie sich auch auf eine hochverfügbare Bereitstellung konzentrieren. Der OpenStack High Availability Guide bietet Vorschläge zur Beseitigung eines einzelnen Fehlers, der zu Systemausfällen führen kann. Es ist zwar kein vollständig normatives Dokument, bietet aber Methoden und Techniken zur Vermeidung von Ausfallzeiten und Datenverlust.
Andere Überlegungen zur Sicherung beinhalten:
Wie viele Backups müssen aufbewahrt werden?
Sollten Backups extern aufbewahrt werden?
Wie oft sollten Backups getestet werden?
Genauso wichtig wie eine Backup-Richtlinie ist eine Wiederherstellungsrichtlinie (oder zumindest ein Wiederherstellungstest).
Was zu sichern ist¶
Während OpenStack aus vielen Komponenten und beweglichen Teilen besteht, ist die Sicherung der kritischen Daten recht einfach.
In diesem Kapitel wird nur beschrieben, wie Sie Konfigurationsdateien und Datenbanken sichern, die von den verschiedenen OpenStack-Komponenten ausgeführt werden müssen. Dieses Kapitel beschreibt nicht, wie Sie Objekte im Objektspeicher oder Daten im Blockspeicher sichern können. Im Allgemeinen bleiben diese Bereiche den Benutzern überlassen, um selbstständig zu sichern.
Datenbank Backups¶
Die exemplarische OpenStack-Architektur bezeichnet den Cloud-Controller als MySQL-Server. Dieser MySQL-Server hostet die Datenbanken für nova, glance, cinder und keystone. Mit all diesen Datenbanken an einem Ort ist es sehr einfach, ein Datenbank-Backup zu erstellen:
# mysqldump --opt --all-databases > openstack.sql
Wenn Sie nur eine einzelne Datenbank sichern möchten, können Sie stattdessen ausführen:
# mysqldump --opt nova > nova.sql
wobei nova die Datenbank ist, die Sie sichern möchten.
Sie können diesen Prozess einfach automatisieren, indem Sie einen Cron-Job erstellen, der das folgende Skript einmal täglich ausführt:
#!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip > $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete
Dieses Skript sichert die gesamte MySQL-Datenbank und löscht alle Backups, die älter als sieben Tage sind.
Dateisystem-Backups¶
In diesem Abschnitt wird besprochen, welche Dateien und Verzeichnisse regelmäßig gesichert werden sollten, organisiert nach Diensten.
Compute¶
Das Verzeichnis /etc/nova sowohl auf dem Cloud Controller als auch auf den Compute-Knoten sollte regelmäßig gesichert werden.
/var/log/nova braucht nicht gesichert zu werden, wenn alle Protokolle in einen zentralen Bereich gehen. Es wird dringend empfohlen, einen zentralen Protokollierungsserver zu verwenden oder das Protokollverzeichnis zu sichern.
/var/lib/nova ist ein weiteres wichtiges Verzeichnis für die Sicherung. Die Ausnahme bildet das Unterverzeichnis /var/lib/nova/instances auf Compute-Knoten. Dieses Unterverzeichnis enthält die KVM-Images der laufenden Instanzen. Sie möchten dieses Verzeichnis nur sichern, wenn Sie Sicherungskopien aller Instanzen pflegen müssen. In den meisten Fällen müssen Sie dies nicht tun, aber dies kann von Cloud zu Cloud und Ihren Service Levels variieren. Beachten Sie auch, dass die Erstellung eines Backups einer aktiven KVM-Instanz dazu führen kann, dass diese Instanz nicht richtig startet, wenn sie jemals aus einem Backup wiederhergestellt wird.
Abbildkatalog und Lieferung¶
/etc/glance und /var/log/glance folgen den gleichen Regeln wie ihre nova-Pendants.
/var/lib/glance sollte ebenfalls gesichert werden. Beachten Sie besonders /var/lib/glance/images. Wenn Sie ein dateibasiertes Backend von glance verwenden, ist /var/lib/glance/images der Ort, an dem die Abilder gespeichert werden, und es sollte mit Sorgfalt vorgegangen werden.
Es gibt zwei Möglichkeiten, die Stabilität mit diesem Verzeichnis zu gewährleisten. Das erste ist, sicherzustellen, dass dieses Verzeichnis auf einem RAID-Array ausgeführt wird. Wenn eine Festplatte ausfällt, ist das Verzeichnis verfügbar. Der zweite Weg ist die Verwendung eines Tools wie rsync, um die Abbilder auf einen anderen Server zu replizieren:
# rsync -az --progress /var/lib/glance/images backup-server:/var/lib/glance/images/
Identität¶
/etc/keystone und /var/log/keystone folgen den gleichen Regeln wie andere Komponenten.
/var/lib/keystone, obwohl es keine zu verwendenden Daten enthalten sollte, kann für alle Fälle auch eine Sicherung durchgeführt werden.
Block Speicher¶
/etc/cinder und /var/log/cinder folgen den gleichen Regeln wie andere Komponenten.
/var/lib/cinder sollte ebenfalls gesichert werden.
Netzwerk¶
/etc/neutron und /var/log/neutron folgen den gleichen Regeln wie andere Komponenten.
/var/lib/neutron sollte ebenfalls gesichert werden.
Objekt Speicher¶
/etc/swift ist sehr wichtig, um ein Backup erstellt zu haben. Dieses Verzeichnis enthält die swift Konfigurationsdateien sowie die Ringdateien und Ring builder files, die bei Verlust die Daten auf Ihrem Cluster unzugänglich machen. Eine bewährte Vorgehensweise ist es, die Builder-Dateien zusammen mit den Ringdateien auf alle Speicherknoten zu kopieren. Mehrere Sicherungskopien sind über Ihren Speichercluster verteilt.
Telemetrie¶
Sichern Sie das Verzeichnis /etc/ceilometer mit den Konfigurationsdateien der Telemetrie.
Orchestrierung¶
Sichern Sie die HOT-Template-Dateien yaml und das Verzeichnis /etc/heat/ mit den Orchestrierungs-Konfigurationsdateien.
Wiederherstellen von Backups¶
Die Wiederherstellung von Backups ist ein ziemlich einfacher Prozess. Stellen Sie zunächst sicher, dass der wiederherzustellende Dienst nicht ausgeführt wird. Um beispielsweise eine vollständige Wiederherstellung von nova auf dem Cloud-Controller durchzuführen, stoppen Sie zunächst alle nova Dienste:
# stop nova-api
# stop nova-consoleauth
# stop nova-novncproxy
# stop nova-objectstore
# stop nova-scheduler
Jetzt können Sie eine zuvor gesicherte Datenbank importieren:
# mysql nova < nova.sql
Sie können auch gesicherte nova-Verzeichnisse wiederherstellen:
# mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/
Sobald die Dateien wiederhergestellt sind, starten Sie die Sicherung:
# start mysql
# for i in nova-api nova-consoleauth nova-novncproxy \
nova-objectstore nova-scheduler
> do
> start $i
> done
Andere Dienste folgen dem gleichen Prozess, mit ihren jeweiligen Verzeichnissen und Datenbanken.
Zusammenfassung¶
Backup und anschließende Wiederherstellung ist eine der ersten Aufgaben, die Systemadministratoren lernen. Allerdings hat jedes System unterschiedliche Elemente, die Aufmerksamkeit erfordern. Indem Sie sich um Ihre Datenbank, Ihren Bildservice und die entsprechenden Dateisystemstandorte kümmern, können Sie sicher sein, dass Sie mit jedem Ereignis umgehen können, das eine Wiederherstellung erfordert.
