Openstack made easy – Volume Backups

Openstack made easy – Volume Backups

Du willst zusätzliche Backups für Deine Volumes? Natürlich am besten ein einem weiteren unabhängigen Storage? Hier erfährst du in wenigen Minuten wie du tägliche Volume Backups in der NWS-Cloud konfigurierst.

Für die Datensicherung von Volumes bietet NWS eine einfache Backup-Funktionalität an. Dadurch werden ausgewählte Volumes in ein zweites unabhängiges Storage kopiert, um deine wichtigsten Daten vor kleinen Dummheiten und großen Katastrophen zu schützen.

Tägliche Backups automatisch erstellen

Tägliche Backups für Deine Volumes lassen sich mit einem Klick im internen Bereich von nws.netways.de aktivieren. Dort kannst du individuell für jedes Volume entscheiden ob ein automatisches nächtliches Backup erstellt wird. Zudem kannst du die maximale Anzahl festlegen, ist diese erreicht wird mit jedem neuen Backup auch das Älteste gelöscht. Somit hast du auch die Kosten im Griff.

Ansicht zur Verwaltung der Backups auf nws.netways.de

Die Konfiguration von täglichen Backups ist damit ähnlich einfach wie die der Snapshots. Aber worin liegt der Unterschied und wieso kann beides Sinn machen?  

Volume Snapshot vs. Volume Backup

Bei einem Volume Snapshot wird im zentralen Openstack Storage ein Snapshot angelegt. Im Falle eines Falles ist dieser auch schnell verfügbar. Der Snapshot wird dreifach über zwei Standorte repliziert. Durch das Replizieren sind Deine Daten somit gegen tägliche Störungen wie Hardwaredefekte gesichert.  Auch vor größeren Katastrophen wie Feuer oder Hochwasser an einem Standort sichern dich die Snapshots ab.  Wieso ist ein Backup trotzdem sinnvoll? 

Schutz gegen menschliche Fehler:

Wird versehentlich ein falsches Volume gelöscht so werden alle aktuellen Daten und alle dazugehörigen Snapshots gelöscht. Hingegen ist ein vorhandenes Backup davon nicht betroffen und das Volume kann wieder hergestellt werden. Natürlich kannst du hoffen, dass dein Team und Du keine Fehler machen, aber nach ein paar Jahren in der IT, hat vermutlich jeder schon die ein oder andere Panne verursacht.

Schutz gegen Bugs:

Auch wenn aktuelle Storage Systeme eine hohe Qualität aufweisen und über jahrelange Erfahrung zuverlässig und sicher laufen, können Fehler in der Software zu Datenverlust führen. Ein zweites unabhängiges Storage für Ihr Backup vermindert dieses Risiko erheblich. 

 

Beim lesen ist dir sicherlich aufgefallen, dass immer die Rede von Volume Snapshot und Backups war. Aber was ist mit virtuellen Server ohne Volume? 

 

Virtuelle Server ohne Volume

Beim starten eines virtuellen Server in der NWS-Cloud hast du die Möglichkeit die root-Partition auf einem Volume abzulegen oder eben auch nicht. Im ersten Fall werden alle Daten im zentralen Storage gespeichert und dadurch auch dreifach über zwei Standorte repliziert und die Backups kannst du wie oben beschrieben verwalten. 

Verzichtest du auf das Volume liegt die root-Partition des virtuellen Server direkt auf einem Hypervisor. Erstellst du in diesem Fall einen Snapshot werden alle Daten vom Hypervisor in das zentrale Storage kopiert. Dort wird es, wie auch die Volumes, dreifach über zwei Standorte repliziert. Somit sind die Daten bereits in zwei unabhängigen Systemen gespeichert und somit vor kleinen Dummheiten und großen Katastrophen sicher. Wie du automatische tägliche Snapshots für Deine virtuellen Server konfigurierst, erfährst du hier.

Du hast bei alle dem replizieren und kopieren die Übersicht verloren? Bei Fragen helfen gerne weiter!

OpenStack made easy – Corosync Cluster mit Failover IP

OpenStack made easy – Corosync Cluster mit Failover IP

Eine der ersten Kundenanforderungen, welche man zu lesen bekommt lautet meist: Hochverfügbarkeit. Es entspricht schon seit langem eher der Norm, dass das Projekt selbst bei Teilausfällen weiterhin problemlos erreichbar ist und „single points of failure“ vermieden werden. Dabei kommt oftmals ein Corosync / Pacemaker Cluster zum Einsatz, die Technologie dahinter ist mittlerweile seit über einem Jahrzehnt bewährt – der Grundgedanke dahinter ist: Man erstellt virtuelle Ressourcen, welche auf jedem angebundenen Node gestartet werden können.

Im folgenden wird beschrieben, wie ein Corosync / Pacemaker Cluster unter Ubuntu erstellt wird. Wem diese Schritte bereits bekannt sind und nur wissen möchte wie er die Failover IP auch im OpenStack hinterlegen kann, findet entsprechende Informationen weiter unten im Artikel.

Corosync / Pacemaker Cluster erstellen

Installation

Als ersten Schritt werden die nötigen Pakete installiert. crmsh bietet dabei eine Shell, welche zur Steuerung des Clusters genutzt werden kann.

root@test-node-1:~# apt install corosync pacemaker crmsh

Konfiguration

Anschließend wird der authkey erstellt, welcher für die Kommunikation der Nodes untereinander benötigt wird. Ohne diesen kann der Dienst ggf. nicht gestartet werden.

root@test-node-1:~# corosync-keygen

Das kann einige Zeit dauern, je nachdem wieviel auf dem Server los ist. Bei neu erstellten VMs, würde es zu lange dauern und man bedient sich beispielsweise folgendem Snippet, welches zufällige Daten auf die Festplatte schreibt – bitte aber stets im Hinterkopf behalten, dass man sich nicht die Festplatte vollschreiben sollte, also ggf. sollte man den Befehl nochmals an die eigenen Bedürfnisse anpassen!

while /bin/true; do dd if=/dev/urandom of=/tmp/entropy bs=1024 count=10000; for i in {1..50}; 
do cp /tmp/entropy /tmp/tmp_$i_$RANDOM; done; rm -f /tmp/tmp_* /tmp/entropy; done

Ist das passiert, kopiert man den Authkey auf beide Server unter /etc/corosync/authkey

root@test-node-1:~# cp authkey /etc/corosync/authkey
root@test-node-1:~# chown root.root /etc/corosync/authkey
root@test-node-1:~# chmod 0400 /etc/corosync/authkey
root@test-node-1:~# scp /etc/corosync/authkey root@test-node-2:/etc/corosync/authkey

Anschließend wird der Cluster in der Datei /etc/corosync/corosync.conf konfiguriert, in welcher unter anderem die private IPs der Clusternodes definiert werden. Diese Datei ist ebenfalls auf allen Nodes identisch.

totem {
  version: 2
  cluster_name: test-cluster
  transport: udpu
  interface {
    ringnumber: 0
    bindnetaddr: 172.16.0.0
    broadcast: yes
    mcastport: 5407
  }
}

nodelist {
  node {
    ring0_addr: 172.16.0.10
  }
  node {
    ring0_addr: 172.16.0.20
  }
}

quorum {
  provider: corosync_votequorum
}

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  to_syslog: yes
  timestamp: on
}

service {
  name: pacemaker
  ver: 1
}

Anschließend benötigt der Cluster einen Neustart, damit alle Daten übernommen werden. Ab diesem Zeitpunkt sollte der Cluster auch bereits seinen Status ausgeben und alle Nodes erkennen. Initial kann dies einige Sekunden benötigen.

root@test-node-1:~# systemctl restart corosync && systemctl restart pacemaker

root@test-node-1:~# crm status
Stack: corosync
Current DC: test-node-1 (version 1.1.18-2b07d5c5a9) - partition with quorum
Last updated: Mon Dec 7 15:40:20 2020
Last change: Mon Dec 7 15:40:20 2020 by hacluster via crmd on test-node-1

2 nodes configured
0 resource configured

Online: [ test-node-1 test-node-2 ]

Mittels der crm kann der Cluster gesteuert und auf dessen aktuelle Konfiguration zugegriffen werden. Die Konfiguration sollte der folgenden sehr ähnlich sein:

root@test-node-1:~# crm configure show
node 2886729779: test-node-1
node 2886729826: test-node-2
property cib-bootstrap-options: \
  have-watchdog=false \
  dc-version=1.1.18-2b07d5c5a9 \
  cluster-infrastructure=corosync \
  cluster-name=test-cluster \
  stonith-action=reboot \
  no-quorum-policy=stop \
  stonith-enabled=false \
  last-lrm-refresh=1596896556 \
  maintenance-mode=false
rsc_defaults rsc-options: \
  resource-stickiness=1000

Nun kann diese Konfiguration direkt editiert und Ressourcen definiert werden. Dies kann auch mittels „crm configure“ passieren, in diesem Beispiel wird die Konfiguration aber direkt übernommen.

root@test-node-1:~# crm configure edit

node 2886729779: test-node-1
node 2886729826: test-node-2
primitive ha-vip IPaddr2 \
  params ip=172.16.0.100 cidr_netmask=32 arp_count=10 arp_count_refresh=5 \
  op monitor interval=10s \
  meta target-role=Started
property cib-bootstrap-options: \
  have-watchdog=false \
  dc-version=1.1.18-2b07d5c5a9 \
  cluster-infrastructure=corosync \
  cluster-name=test-cluster \
  stonith-action=reboot \
  no-quorum-policy=ignore \
  stonith-enabled=false \
  last-lrm-refresh=1596896556 \
  maintenance-mode=false
rsc_defaults rsc-options: \
  resource-stickiness=1000

Dem aufmerksamen Leser wird auffallen, dass ebenfalls die „no-quorum-policy“ angepasst wurde. Dies ist wichtig für den Betrieb eines Clusters, welcher lediglich aus zwei Nodes besteht, da beim Ausfall eines Nodes kein Quorum gebildet werden könnte.

root@test-node-1:~# crm status
Stack: corosync
Current DC: test-node-1 (version 1.1.18-2b07d5c5a9) - partition with quorum
Last updated: Mon Dec 7 15:40:20 2020
Last change: Mon Dec 7 15:45:21 2020 by hacluster via crmd on test-node-1

2 nodes configured
1 resource configured

Online: [ test-node-1 test-node-2 ]

Full list of resources:

ha-vip (ocf::heartbeat:IPaddr2): Started test-node-1

 

Failover IP in OpenStack konfigurieren

Es gibt an sich zwei Möglichkeiten die IP in OpenStack zu hinterlegen. Zum einen kann man sich im Webinterface über Netzwerk -> Netzwerke -> besagtes Netzwerk -> Ports zum Port der VM navigieren und bei diesem den Reiter „Erlaubte Adressenpaare“ um die gewünschte IP ergänzen. Zum anderen ist dies auch via OpenStack CLI Tool möglich:

openstack port list --server test-node-1
+--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+
| ID                                   | Name | MAC Address       | Fixed IP Addresses                                                         | Status |
+--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+
| 0a7161f5-c2ff-402c-9bf4-976215a95cf3 |      | fa:16:3e:2a:f3:f2 | ip_address='172.16.0.10', subnet_id='9ede2a39-7f99-48c8-a542-85066e30a6f3' | ACTIVE |
+--------------------------------------+------+-------------------+----------------------------------------------------------------------------+--------+

Die zusätzlich erlaubte IP-Adresse wird wie folgt dem Port hinzugefügt. Hierbei kann auch ein komplettes Netzwerk definiert werden, falls mehrere IP Ressourcen erstellt werden sollen.

openstack port set 0a7161f5-c2ff-402c-9bf4-976215a95cf3 --allowed-address ip-address=172.16.0.100

Dieser Schritt muss für beide Server wiederholt werden. Danach ist die IP ebenfalls im OpenStack Projekt erreichbar, sollte das nicht der Fall sein hilft ggf. ein Schwenk der IP Ressource auf den anderen Node, damit die IP dort announced wird. Durch die oben gesetzten ARP Settings der Ressource sollte dies jedoch nicht der Fall sein.

crm resource migrate ha-vip test-node-2

Das ganze funktioniert nicht so wie geplant, oder es gibt noch weitere Fragen? Unsere MyEngineers helfen dir sicher weiter!