Sicherung und Wiederherstellung

[ English | 日本語 | Deutsch | Indonesia ]

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.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.