Sichern Ihrer virtuellen Maschinen in OpenStack

Die Datensicherung ist ein wesentlicher Bestandteil der IT-Infrastrukturverwaltung. HA-Lösungen, RAIDs usw. befreien Sie nicht von der Notwendigkeit eines Backups. Im Falle eines menschlichen Fehlers können all diese Techniken Sie nicht retten, sondern nur das Backup.

Aber wie das Sprichwort sagt: "Ihre Backups sind nur so gut wie Ihre Wiederherstellungen", also müssen wir darüber nachdenken, unsere Backups regelmäßig auf Konsistenz zu überprüfen. In OpenStack ist es sehr empfehlenswert, Cinder als Hauptspeicheranbieter zu verwenden. Cinder gibt Ihnen die Möglichkeit, Block-Volumes zu erstellen und diese mit Ihren virtuellen Maschinen zu verbinden. Die beste Praxis ist, dass Sie alle Ihre Anwendungsdaten auf Volumes und nicht auf der Instanzplatte speichern. Diese Platte sollte nur für die Betriebssystemdateien verwendet werden, die aus dem Betriebssystem-Image stammen (natürlich werden auch Pakete, die aus Repositories installiert wurden, dort abgelegt). In diesem Artikel werden wir Ihnen weitere Gründe für diese Vorgehensweise nennen. Was Sie sich von einer guten Backup-Lösung wünschen, ist eine Online-Backup-Möglichkeit, einfache Wiederherstellung, Konsistenz und einfache Verwaltung, um so wenig Speicherplatz wie möglich zu benötigen. Obwohl es möglich ist, eine herkömmliche Backup-Lösung auf jeder virtuellen Maschine zu installieren, bietet OpenStack uns andere Möglichkeiten, unsere Daten mithilfe von Snapshots zu sichern. Der Nachteil ist, dass man noch keine "inkrementelle" Snapshot-Kopie erstellen kann, sondern bei jedem Backup die volle Größe der Snapshots speichern muss. Die Einfachheit von Backups und vor allem von Wiederherstellungen ist jedoch weitaus größer als die Unterstützung einer "in-VM"-Backup-Lösung, die inkrementelle Backups unterstützt. 27JULT Die OpenStack Kilo-Umgebung, für die wir diese Backup-Strategie entwickelt haben, ist ein 2-Hypervisor-Setup, mit NFS als Cinder-Backend. Fragen Sie mich nicht, warum wir NFS gewählt haben, das war damals die Situation 🙂 .

OpenStack bietet den Befehl "cinder backup-create" genau für den Zweck von Backups an, dieser Befehl erstellt tatsächlich eine Kopie des Volumes und sendet sie an den Objektspeicher (swift). Leider müssen wir bis zu den Liberty-Releases warten, um die Force-Option zu erhalten, die Online-Backups ermöglicht, derzeit funktioniert das Backup nur bei nicht angeschlossenen Volumes.

cinder backup-create bata-mysqlsflr02_app
 ERROR: Invalid volume: Volume to be backed up must be available (HTTP 400) (Request-ID: req-6aeb81f1-c415-45ed-8d58-20f466055f03)

In Liberty sieht der Befehl wie folgt aus und ermöglicht inkrementelle Backups und die Option force, die auch Online-Backups ermöglicht.

 cinder backup-create [--incremental] [--force] VOLUME

Toll, stimmt!!! Allerdings müssen wir uns noch gedulden.
Bis dahin werden wir einen anderen Ansatz verwenden. Es gibt die Cinder Snapshot Funktion, leider unterstützt sie nicht das NFS Speicher-Backend.

Sehen Sie hier nach

Als ich schon alle Hoffnung verloren glaubte, kam mir die Cinder Upload-to-Image Option in den Sinn. Wir haben tatsächlich die Möglichkeit, ein Abbild von einem Cinder-Volume zu erstellen und dieses Abbild dann in eine externe Datei herunterzuladen, die an einem sicheren Ort gespeichert ist. Das Schöne daran ist, dass wir das alles online und mit konsistenten Daten machen können, außerdem ist die Größe bei Verwendung des qcow2-Formats nur der belegte Speicherplatz des Volumes.
Um die Konsistenz zu gewährleisten, haben wir den folgenden Test gemacht: Wir erstellen eine Datei im Volume, bevor wir mit dem Image-Upload beginnen, und dann zwei Dateien, während das Image erstellt wird, eine zu Beginn der Image-Erstellung und eine ungefähr am Ende.
Auf dem Quellrechner erstellen wir die Testdatei.

# touch beforeimage.tst

Wir lösen die Bilderstellung aus

cinder upload-to-image svnsfphp03_app SVN_app-volume-backup --disk-format qcow2 --container-format bare --force True
 glance image-list
 ..
 | 57e460f3-4674-435d-b92a-b18f126850a3 | SVN_app-volume-backup              | qcow2       | bare             |             | queued |

Dann erstellen wir zwei weitere Dateien auf dem Quellcomputer, die erste unmittelbar nach dem Auslösen, die zweite kurz vor dem Ende des Vorgangs.

 touch afterimagestart.tst
 touch afterimagestart-2.tst

Um auf den Punkt zurückzukommen, dass Ihre Sicherungen nur so gut sind wie Ihre Wiederherstellungen, testen wir die Wiederherstellung auf diese Weise. Das Ergebnis zeigt, dass wir nur die Datei sehen, die wir erstellt haben, bevor wir das Image gestartet haben, also funktioniert das Snapshotten, wir erhalten den Zustand, als wir den Image-Upload gestartet haben. 

cinder create --display-name SVN_app-volume-backup-restore-test --availability-zone nova  --image-id 57e460f3-4674-435d-b92a-b18f126850a3  5

Beim Einbinden sehen wir nur die Datei, die vor dem Auslösen des Bild-Uploads erstellt wurde.

 # mount /dev/vdr /mnt/
 # ls -la /mnt/
 total 32
 drwxr-xr-x.  4 root root  4096 Jul 27 09:31 .
 drwxr-xr-x. 18 root root  4096 Jun 29 07:19 ..
 -rw-r--r--.  1 root root     0 Jul 27 09:31 beforeimage.tst
 drwxr-xr-x.  7   48   48  4096 Jul 27 09:30 bis
 drwx------.  2 root root 16384 Apr 20 11:01 lost+found
 -rw-r--r--.  1 root root    10 Jul  6 11:58 test.txt

Um die vollständige Sicherung abzuschließen, sollten wir das Bild aus glance in eine Datei exportieren, die an einem sicheren Ort, idealerweise außerhalb Ihres Rechenzentrums, gespeichert wird. Der knifflige Teil ist, dass der Befehl "Upload-to-Image" asynchron ist, was bedeutet, dass der Befehl nicht wirklich wartet, bis das Bild in Glance hochgeladen ist, bevor er beendet wird. Sie müssen also entweder die API in Ihrem Backup-Skript ständig abfragen, um zu sehen, wann es fertig ist, damit Sie es herunterladen können, oder Ihr Skript in zwei Phasen aufteilen, sobald Sie alle Bilder erstellt haben, und sie dann herunterladen.

glance image-download SVN_app-volume-backup --file /mnt/remote-nfs/SVN-volume-backup-${DATE}.qcow2

Wenn dann eine Wiederherstellung erforderlich ist, können wir dies tun, indem wir ein Image in einem Blick von dieser Datei erstellen und dann wiederum ein Volume von diesem Image erstellen.
In unserem Setup wollten wir auch die Betriebssystem-Images sichern, leider scheint es immer noch keine Online-Lösung zu geben, um dies zu tun. Dies ist der Hauptgrund dafür, dass die beste Praxis darin besteht, Ihre wertvollen Daten auf Cinder-Volumes zu speichern, wie zu Beginn des Artikels beschrieben. Die Ziel-VM ist für die Zeit, in der der Snapshot der Maschine erstellt wird, immer eingefroren. nova erstellt während des Einfrierens eine Kopie des Datenträgers im Verzeichnis /var/lib/nova/instances/snapshots/, hebt dann das Einfrieren des Rechners auf und startet den Upload auf glance, der zumindest während des vollen Betriebs des Rechners erfolgt. Ich hoffe, dass wir bald Live-Snapshots haben werden. Das Gute ist, dass in unserem Fall die Maschinen, die wir auf diese Weise sichern, nicht geschäftskritisch sind, so dass eine Pausenzeit von einer Minute während der Nacht akzeptabel ist.
Hier ist das Skript, das wir verwenden. Bei großen und vielen Rechnern dauert es in der Regel eine Weile, bis es abgeschlossen ist. Es hängt auch von der Geschwindigkeit Ihres Speichers ab. Wenn Sie es also in Ihrer Einrichtung verwenden, sollten Sie die Zeit messen, um zu wissen, wie lange es dauert, und es entsprechend planen. 

#!/bin/bash
 DATE=`date +%y%m%d`
 VOLSUFFIX="_app"
 BACKUPDIR=/mnt/usbdisk/backup
 
 declare -a VMS=(
 vm1
 vm2
 vm3
 )
 
 source /root/keystonerc_admin
 
 echo $DATE `date` Starting Backup process of images
 
 for vmname in "${VMS[@]}"
 
 do
  echo Backing up $vmname
  echo cinder upload-to-image ${vmname}${VOLSUFFIX} ${vmname}${VOLSUFFIX}-volume-backup --disk-format qcow2 --container-format bare --force True
  cinder upload-to-image ${vmname}${VOLSUFFIX} ${vmname}${VOLSUFFIX}-volume-backup --disk-format qcow2 --container-format bare --force True
  echo nova image-create --poll $vmname ${vmname}-backup
  nova image-create --poll $vmname ${vmname}-backup
  echo NO support for NFS volume snapshot yet
  date
  echo glance image-download ${vmname}-backup --file $BACKUPDIR/${vmname}-backup-${DATE}.qcow2
  glance image-download  ${vmname}-backup --file $BACKUPDIR/${vmname}-backup-${DATE}.qcow2
  echo nova image-delete ${vmname}-backup
  nova image-delete ${vmname}-backup
  date
  echo glance image-download ${vmname}${VOLSUFFIX}-volume-backup --file $BACKUPDIR/${vmname}${VOLSUFFIX}-volume-backup-${DATE}.qcow2
  glance image-download ${vmname}${VOLSUFFIX}-volume-backup --file $BACKUPDIR/${vmname}${VOLSUFFIX}-volume-backup-${DATE}.qcow2
  echo glance image-delete ${vmname}${VOLSUFFIX}-volume-backup
  glance image-delete ${vmname}${VOLSUFFIX}-volume-backup
 done

Bitte senden Sie uns Ihre Kommentare und Fragen. Ich würde mich freuen, wenn jemand einen Weg findet, echte Online-Snapshots der Haupt-OS-Disk-Images ohne Einfrierzeit zu erstellen.
In unserem nächsten Blog zu diesem Thema werde ich Ihnen zeigen, wie wir die OpenStack-Komponenten selbst sichern.