OpenStack made easy – Snapshots erstellen, rotieren, einspielen

OpenStack made easy – Snapshots erstellen, rotieren, einspielen

This entry is part 4 of 4 in the series OpenStack made easy

Früher oder später gelangt wohl jede/r, die / der einen Server am Laufen hat einmal an den Punkt, dass es ihr / ihm die VM (oder Teile davon) irreversibel “zerreißt” – wodurch auch immer.
Wer sich im Vorfeld der Sicherung seiner Daten gewidmet hat, ist jetzt klar im Vorteil und hat signifikant niedrigere Adrenalinpegel zu erwarten – besonders, wenn die letzte Sicherung keine 24 Stunden her ist. Unsere OpenStack-Plattform bietet für die Sicherung Ihrer virtuellen Maschine(n) Funktionalität zum automatischen oder auch manuellen Erstellen von Schattenkopien (im Folgenden Snapshots genannt) an.

 > Automatischen Snapshot einrichten

Man wähle den Reiter Snapshots und setze ein Häkchen bei der automatisch zu sichernden VM und die Einstellung wird übernommen.

Et voilà! Ab sofort kümmert sich die OpenStack-App jede Nacht nach 00:00 Uhr darum, dass ein Snapshot dieser virtuellen Maschine erstellt wird. Wie im Bild erwähnt macht sie sieben Stück, beim achten Mal Snapshot-Erstellen löscht sie den ältesten, also den ersten, usw.
Ergo ist “7” ist der Rotations-Standardwert. Wer diesen gerne verändern möchte, d. h. weniger als eine Woche täglicher Snapshots vorhalten will, beispielsweise nur deren drei, kann das wie folgt tun: Zurück zum Reiter “LiveView” > Compute > Instanzen > Drop-down-Menü (ganz rechts neben der Instanz, die modifiziert werden soll) > “Aktualisiere Metadaten”.
Hier sieht man nun, dass unter “Existing Metadata” “nws_backup” existiert und auf “true” gesetzt ist.

Man schreibe unter “Available Metadata” neben das Feld “Custom” “rotation” hinein, füge es mit dem Pluszeichen der “Existing Metadata” hinzu, trage dort den Wert “3” ein und klicke auf “Speichern”.
Fertig.

¡¡¡ Im Fall von Datenbanken auf der zu sichernden VM !!!
Da Snapshots im laufenden Betrieb genommen werden, ist die Konsistenz der Datenbanken darin nicht garantiert. Ich empfehle die Einrichtung eines Cronjobs, der einen Dump der laufenden DBs oder anderer nicht-persistenter Daten anlegt. Gut wäre, wenn dieser vor 24:00 Uhr fertig ist und somit nahtlos mitgebackupt werden kann.

 > Manuellen Snapshot erstellen

Wer hingegen nur einen bestimmten Zustand – beispielsweise nach Durchführung aller Installationshandgriffe seiner Software-Landschaft – gesichert haben möchte, kann das manuell tun: Compute > Instanzen > Schattenkopie erstellen (neben der zu sichernden VM). Es ist dann noch ein aussagekräftiger Schattenkopiename zuzuteilen und Schattenkopie erstellen zu klicken.

Eine grüne Erfolgsmeldung wird hierauf oben rechts aufpoppen.
Hier sollte – wie oben beschrieben – ebenfalls auf Datenbanken geachtet werden.

 > Snapshot einspielen

Sollte es dann eben zur Havarie oder einem sonstigen Fall notwendiger Zurücksetzung kommen, läuft das Einspielen der Sicherung so ab, als würde man eine neue VM starten.
Compute > Instanzen > Instanz starten.

Details > Instanzname setzen

Quelle > Bootquelle auswählen:
Hier gibt es zwei Möglichkeiten, wo sich Ihr Snapshot befindet:

  • entweder > “Datenträger Snapshot” (i. F. v. VMs “mit Datenträger” bzw. “mit Volume”: Systemdatenträger in unserem Ceph-Storage, insgesamt dreifache Replikation an zwei Standorten)
  • oder > “Abbild” oder “Instanz Snapshot” (i. F. v. VMs “ohne Datenträger” bzw. “ohne Volume”: Systemdatenträger lediglich auf dem Hypervisor)

Variante, Netzwerke, Sicherheitsgruppen und Schlüsselpaar sind wie gehabt zu setzen.

Als Ergebnis wird man jetzt zwei ähnliche VMs haben:

Um den neuen Sollzustand zu verkomplettieren, bleibt, der zu verwerfenden Instanz die Floating-IP abzutrennen (Drop-down-Menü ganz rechts neben der Instanz) und diese der neuen zuzuweisen. Wenn sicher ist, dass die alte nicht mehr benötigt wird, kann diese dann auch gelöscht werden, um nicht weiterhin nutzlos Kosten zu verursachen.

Dieses Vorgehen eignet sich nicht nur zur Desaster-Recovery. Auch das Aufsetzen einer baugleichen VM oder das Testen größerer Patches abseits der produktiven Areale kann so bewerkstelligt werden.

> Snapshot als Datenträger einbinden

Für den Fall, dass man nur an die enthaltenen Daten heranwill, existiert auch die Möglichkeit, aus dem Snapshot einen Datenträger zu erstellen und diesen einer anderen laufenden VM anzuhängen.
Dies ist möglich über zwei Schritte:
Compute > Abbilder > Drop-down-Menü (ganz rechts neben dem zu benutzenden Abbild) > Datenträger erstellen > Datenträger erstellen.
Weiter über Datenträger > Datenträger > Drop-down-Menü (ganz rechts neben dem zu benutzenden Datenträger) > Anhänge verwalten.

Es ist noch die Instanz, mit der das Laufwerk verbunden werden soll auszuwählen und zu bestätigen.
Jetzt steht die Platte zur Verfügung, auf Ubuntu beispielsweise als /dev/sdb1 .

Martin Scholz
Martin Scholz
Systems Engineer

Martin sattelte unlängst vom sozialen Bereich auf die IT um und ist im Managed-Services-Support tätig. Praktischerweise nutzt ihm hier, dass er sich bereits vor geraumer Zeit Linux als User zugewandt hat. Privat ist er bekennende Couch-Potatoe. Es sei denn, er fühlt sich einmal wieder gedrängt, einen Marathon-Marsch zu unternehmen. Kein feliner oder kanider Passant ist vor seiner Kontaktaufnahme sicher.

NWS OpenStack – automatisierte Snapshots

Unser Ziel war und ist es, eine Plattform zu schaffen, die sehr hohe Flexibilität, Sicherheit und Komfort bietet. Unsere Kunden sollen in eigenen, isolierten Projekten ihrer Kreativität freien Lauf lassen und nahezu uneingeschränkt sein, ohne sich um essenzielle Dinge Gedanken machen zu müssen.

In genau diesem Zuge, haben wir diese Woche ein neues Feature für unsere OpenStack Cloud veröffentlicht – automatisierte Snapshots für virtuelle Maschinen und Volumes! Mit diesem neuen Feature können sich unsere “IaaS” (Infrastructure as a Service) Kunden zurücklehnen, entspannen und die Verantwortung der zuverlässigen Sicherung an uns abgeben. Wir stellen sicher, dass ausgewählte Instanzen ordnungsgemäß gesichert werden und dieser Prozess überwacht wird.

Doch wie genau funktioniert das nun? Wir haben in unserer Plattform einen Menüpunkt eingebaut, der als Schaltzentrale fungiert. Eingesehen werden kann dieser von jedem Nutzer in der Übersicht seiner OpenStack Instanz. Es werden hier alle VMs sowie Volumes aufgelistet und gegebenenfalls mit Notizen versehen. Beispielsweise in welcher VM ein Volume unter welchem Pfad eingehängt ist.

In dieser Liste kann nach belieben, durch setzen eines Hakens, der Sicherungsprozess aktiviert oder deaktiviert werden.
Neben dem Erstellen von Backups werden nach einer gewissen Retention, Snapshots natürlich auch vollkommen automatisch wieder gelöscht. Per Default alle Sicherungen, welche älter als 7 Tage sind.

Eine Übersicht über die aktuellen Sicherungen gibt es im OpenStack selbst:
Compute -> Images / Volumes -> Snapshots 

Erweiterungen zu dieser Sicht sind geplant. Ebenso weitere neue spannende Features, welche aktuell noch in der Entwicklung sind.
Wir haben zum Snapshot/Backup Release auf unserem Twitter Account ein kurzes Video mit einer Live Demo dazu für euch vorbereitet. Lasst uns auf Twitter gerne wissen, was ihr davon haltet!

Noch kein NWS IaaS Kunde? – Hier geht’s zu unserer Platform

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Ceph Mimic | Using loop devices as OSD

For quite some time we have been using ceph-deploy to deploy OSD in folders during the Ceph trainings held by Netways. This worked perfectly with jewel, but newer versions don’t allow this behaviour anymore.
There are several reasons for this, however, as we have a quite regulated setup for our training notebooks, we had to come up with some kind of workaround. This approach is, while working fine in our training setup, not recommended for production!
The following steps apply to a current CentOS 7 system.
As stated before, we will deploy an OSD on a block device. Though you could use a separate partition for this, we will use a loop device. For this, the first step is to create a file:
For this, create an OSD directory
 

$ mkdir -p /home/training/my-cluster/osd-$HOSTNAME
$ cd /home/training/my-cluster/osd-$HOSTNAME/

in this folder, create a file for later use

$ fallocate -l 30G 30GB.img

test it

# losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"
# wipefs -a /dev/loop1
# lsblk

This should then display your new loopdevice.
As loop devices are not reboot safe, you need to go some steps further. If you like to use rc.local for this, you’re free to do so.
We’re going to create a service, which will essentially execute the prior mentioned losetup command. For this, we need a script with the command and a .service file, which will execute the script:

rebloop.sh
#!/bin/bash
sudo losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"

and the service file:

rebloop.service
[Unit]
Description=Reattach loop device after reboot
[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/rebloop.sh
[Install]
WantedBy=multi-user.target

These files have to be executable and be copied to the correct folders. Afterwards, the service must be enabled and can be started.

# chmod +x rebloop.*
# cp rebloop.sh /usr/bin/rebloop.sh
# cp rebloop.service /etc/systemd/system
# systemctl enable rebloop.service
# systemctl start rebloop.service

Ceph, however, will still not want to create an OSD on this device, instead give you following error message:

-->  RuntimeError: Cannot use device (/dev/mapper/<name>). A vg/lv path or an existing device is needed 

You have to make changes to /usr/lib/python2.7/site-packages/ceph_volume/util/disk.py on the OSD host:
in line 201, add “or TYPE==’loop'”:

# use lsblk first, fall back to using stat
TYPE = lsblk(dev).get('TYPE')
if TYPE:
return TYPE == 'disk' or TYPE == 'loop'

and in line 286, change the “skip_loop” switch from “True” to “False”:

 def get_block_devs(sys_block_path="/sys/block", skip_loop=False): 

For testing purposes, simply reboot your system and verify if the loop device gets reattached correctly.
If yes, you can deploy an OSD. We’re using ceph-deploy here:

$ ceph-deploy osd create --data /dev/loop1 $HOSTNAME

When the command was successfully executed on your hosts, you can create your first pool

# ceph osd pool create rbd 100 100 replicated

examine ceph status

# ceph status

tag the pool with an application

# ceph osd pool application enable rbd rbd

As you can see, there are quite some changes to be made, and each of it is failure-prone.
Best practice is to simply use a real block device and for production you really should stick to this.
If, however, there are certain needs to be fulfilled, ceph can be convinced to comply.
 
Sources:
http://tracker.ceph.com/issues/36603
https://tracker.ceph.com/issues/23337
https://github.com/NETWAYS/ceph-training
 
 
 

Tim Albert
Tim Albert
Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Lokale Time Machine Snapshots blockieren Speicherplatz

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.
Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?
Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.
Warum Snapshots?
Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.
Habe ich auch Snapshots?
Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den “purgeamount” also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die “urgency”, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.
Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Why you shouldn't miss OSBConf 2018 – #6

Being too busy to worry about backup, is like being too busy driving a car to put on the seatbelt. — T.E. Ronneberg
Don’t miss the latest Backup Solutions! This year’s conference program includes wellknown Backup specialists and their latest findings, such as:
Toshaan Bharvani (VanTosh): „Schroedingers Backup“
Gratien D’haese (IT3 Consultants): „Relax-and-Recover Automated Testing with Bareos“
Daniel Neuberger (NETWAYS): „Restore and Backup Elasticsearch Indices“
Maik Außendorf & Philipp Storz (Bareos): „What’s new in Bareos 18“
To see the whole conference program visit: osbconf.org
 
In 2017 Josef Weingand talked about why Tape is essential for your Backup environment!
Check out his talk!
 

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

OSBConf Countdown: 7, 6, 5, 4, 3, ….


 

Only one more week till OSBConf!

Only one more week till the great re-defining of software solutions for data backup starts.
Only one more week till Open Source Enthusiasts will sit together in the restaurant DÜX for the opening dinner.
Only one more week till international Backup specialists will meet and exchange great research work for future implementation.
Register now and be part of one inspirational day full of backup and a relaxed dinner and drinks event the evening prior to the lecture day.
Get your ticket here.
 

Open Source Backup Conference | September 26, 2018 | Cologne

 

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.