OpenStack made easy – Creating and Using S3 Object Storage

OpenStack made easy – Creating and Using S3 Object Storage

In times of high availability and multiple web servers, the balancing act between central data storage, data security and fast access times must somehow be achieved. This is precisely why more and more users are now using technologies that entice them with buzzwords such as S3, buckets, object storage and Swift. We at NETWAYS Web Services have been offering this for some time, but we have noticed that it is apparently not documented enough for our customers. To shed some light on this, we have created this article. This explanation is therefore given piece by piece:

  • Why Object Storage
  • Creating S3-Credentials via Openstack-API
  • Configuration of s3cmd
  • Create a New Bucket
  • Place Files in the Bucket
  • List Contents of Bucket
  • Download Files from a Bucket
  • Further s3cmd Application Uses
  • Conclusion

Why Object Storage?

Object storage offers many advantages over locally stored data or classic NFS storage because an NFS setup often consists of only one server and thus represents the single point of failure. The administrator must also always be concerned about the performance of the storage and the operating web servers. Another advantage of object storage is the size and number of data to be stored. This is because, in the case of object storage, the data is unlimited. The provider of the object storage (i.e. in the current case NWS) ensures that the space here never runs out. With your own NFS, the size must be taken into account in the planning from the beginning and the customer pays for the planned reserve in the long run. With object storage, only the volume that is used is paid for. Also worth mentioning is the relief of the web server, especially with regard to locally stored data. Imagine the following architecture: The application is run on several web servers, images and other objects are stored in the object storage and delivered directly to the website visitor through intelligent integration without burdening the own web servers or their bandwidth. In short, you tell your application not to deliver this image, but the application only passes on the path of the stored image to the visitor. The image is ultimately delivered directly from the Rados gateway behind it and was never delivered from the app server. This means that it reaches the website visitor quickly, saves bandwidth and reduces the load on one’s own web server, and is nevertheless kept centralised. By the way, the object storage uses our Ceph, where all the data is distributed over a large number of systems and naturally also has corresponding replica sets.

Creating S3-Credentials via Openstack-API

To be able to use an object storage at NWS, an OpenStack account is required. Once this is ready, the process can begin. In OpenStack, go to the menu item “API Access” and download the OpenStack RC file (top right). The script that has just been downloaded is now started on the local machine. All that is required is the OpenStack password. But beware, an OpenStack client is required.

Please enter your OpenStack Password for project 9231-openstack-4707c as user 9231-openstack-4707c:

Now the EC2 credentials for the S3 access must be created, for this purpose the command

openstack ec2 credentials create

The result provides output similar to the following

| Field      | Value                                                                                                                                   |
| access     | aceab8b6b85c51f8d3b305aec1af39c2                                                                                                        |
| links      | {'self': ''} |
| project_id | a40c737aaf3027d87e98f309f9f671d4                                                                                                        |
| secret     | e5d312a7627cdf2a87ac4322a6d7716b                                                                                                        |
| trust_id   | None                                                                                                                                    |
| user_id    | 24c527b4929f10bd6c6ee09af4b30be2                                                                                                        |

Configuration of s3cmd

For further use, s3cmd is now configured. This requires an installed s3cmd. The setup starts by means of

s3cmd --configure

In the following wizard, the previously created data is entered, which then looks something like this (relevant entries in bold)

s3cmd --configure

Enter new values or accept defaults in brackets with Enter.
Refer to the user manual for a detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables.
Access Key: aceab8b6b85c51f8d3b305aec1af39c2
Secret Key: e5d312a7627cdf2a87ac4322a6d7716b
Default Region [US]:

Use "" for S3 Endpoint and not modify it to the target Amazon S3.
S3 Endpoint []:

Use "%(bucket)" to the target Amazon S3. "%(bucket)s" and "%(location)s" vars can be used
if the target S3 system supports dns based buckets.
DNS-style bucket+hostname:port template for accessing a bucket [%(bucket)]:

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password:
Path to GPG program:

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP, and can only be proxied with Python 2.7 or newer
Use HTTPS protocol [Yes]:

On some networks all internet access must go through a HTTP proxy.
Try setting it here if you can't connect to S3 directly
HTTP Proxy server name:

New settings:
Access Key: aceab8b6b85c51f8d3b305aec1af39c2
Secret Key: e5d312a7627cdf2a87ac4322a6d7716b
Default Region: US
S3 Endpoint:
DNS-style bucket+hostname:port template for accessing a bucket:
Encryption password:
Path to GPG program: None
Use HTTPS protocol: True
HTTP Proxy server name:
HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] n

Save settings? [y/N] y
Configuration saved to '/Users/gmimietz/.s3cfg'

In order for the S3 commands to work as desired, a small adjustment has to be made to the config that was just created

vim ~/.s3cfg

There the line

signature_v2 = False

is adapted to

signature_v2 = True

. After saving, the application can now begin.

Creating a new Bucket

A new bucket is created using the following command

s3cmd mb s3://myfirstbucket

To check the creation of the bucket, it is listed with the command

s3cmd ls

Place Files in the Bucket

Time to upload the first files. The put parameter is used for this

s3cmd put /Users/gmimietz/Downloads/water.liquid s3://myfirstbucket/

List Contents of Bucket

To see what is in the bucket that has just been filled, the ls command lists the contents. However, this is now expanded by the bucket name

s3cmd ls s3://myfirstbucket 
2021-02-02 11:04 402088862 s3://myfirstbucket/water.liquid

Download files from a Bucket

The file that has just been uploaded can now be downloaded using the get parameter.

s3cmd get s3://myfirstbucket/water.liquid

Further s3cmd Application Uses

Below are some helpful commands: Move an object from one bucket to another:

s3cmd mv s3://myfirstbucket/water.liquid s3://mysecondbucket

. Store an object encrypted in the bucket (requires a predefined passphrase). (s3cmd –configure)

s3cmd put fire.element s3://myfirstbucket -e

A very valuable command is the sync to synchronise a local directory with a bucket (everything below /important-data is synced to s3://myfirstbucket/backup/)

s3cmd sync /important-data/ s3://myfirstbucket/backup/

. To conserve bandwidth in certain use cases, the –limit-rate option helps, this defaults to bytes but the option also recognises a k or m suffix (kilo/megabyte) per second

s3cmd put myfile s3://myfirstbucket --limit-rate=1k


Of course, there are many more parameters for the s3cmd, all of which can be listed using –help. When using s3, however, modern and elegant procedures can also be included, e.g. the lifetime of a file with a predefined deletion date. In OpenStack you can also see what the object storage is doing by navigating to the corresponding menu via Project>Object Storage. By the way, our object storage also works with swift – so it is also addressed by OpenStack itself. So a mixed operation of S3 and swift is possible at your discretion. We have not yet documented swift further, but our friendly MyEngineers will be happy to provide information on request. The prices for our object storage and everything else we offer at NWS can be found here at any time.

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 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

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


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


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
    broadcast: yes
    mcastport: 5407

nodelist {
  node {
  node {

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 \
rsc_defaults rsc-options: \

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= 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 \
rsc_defaults rsc-options: \

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='', 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=

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!

OpenStack made easy – Autoscaling on Demand

OpenStack made easy – Autoscaling on Demand

Je nach Art der eigenen Produktion kann es für manche/n ServerbetreiberInnen lohnenswert sein, virtuelle Maschinen für einen gewissen Zeitraum per Skript automatisch zu erstellen und – nach getaner Arbeit – genauso automatisch wieder zu löschen; beispielsweise wenn ein Computing-Job mit eigener Hardware länger dauern würde, als akzeptabel ist. Unsere Cloud nimmt sich dem gerne für Sie an – auch wenn es um andere Ressourcen als Prozessoren geht.

In diesem Beispiel gehe ich auf die ersten Schritte dieses Szenario betreffend ein, wie gegen die API unserer OpenStack-Plattform mittels Linux-CLI gesprochen werden kann.
Hierzu braucht man einen OpenStack-Client auf dem die Skalierung betreibenden Host. Unter Ubuntu wäre das beispielsweise das Paket python-openstackclient .
Als nächstes ist das projektbezogene “OpenStack RC File v3” aus der OpenStack-WebUI notwendig. Diese Datei lässt sich nach Anmeldung im Projekt über das Drop-down-Menü mit der eigenen Projekt-ID rechts oben herunterladen.

Man source die Datei, damit der Client auch weiß, mit welchem Projekt er gegen die API sprechen soll – erfordert Passworteingabe:

Um für den Start einer neuen Instanz, die zu übergebenden Optionen setzen zu können, darf jetzt nach Werten (UUID; außer beim Schlüsselpaar) für diese gesucht, für die richtigen entschieden und gemerkt werden:

  • Source, das zu verwendende Installations-Image:
        openstack image list
  • Flavor, also welche Dimensionen die zu bauende VM haben soll:
        openstack flavor list
  • Networks, hier empfehle ich das projekteigene, nach außen abgesicherte Subnet:
        openstack network list
  • Security Groups, hier wird mindestens die Default-Sicherheitsgruppe empfohlen, damit zumindest innerhalb des Projekts alle VMs vollumfänglich miteinander sprechen können:
        openstack security group list
  • Key Pair, zum Verbinden via SSH:
        openstack keypair list

Dann kann die Instanz auch schon gestartet werden – bei mehr als einem zu übergebenden Wert pro Option, die Option mehrmals mit jeweils einem Wert aufführen, zuletzt der Instanz- bzw. Servername:
    openstack server create --image $imID --flavor $flID --network $nID --security-group $sgID --key-name $Name $Servername

Sodala, die VM steht und ist bereit, ihren Beitrag zum Tagesgeschäft zu leisten.
Wer gerne mehr als eine Maschine haben möchte, z. B. drei, gebe noch zusätzlich diese Optionen vor dem Servernamen mit:
    --min 3 --max 3

Geldbeutelschonenderweise, dürfen die Server nach getaner Arbeit auch wieder gelöscht werden:
    openstack server list
    openstack server delete $deID

Automatisch, also ohne nach der ID der Instanz zu schauen, ginge das auch so:
    deID=`openstack server list | grep Instanzname | cut -d ' ' -f 2` ; openstack server delete $deID

Wie gesagt bietet sich das Einbinden des Create-, des Computing- und des Delete-Befehls in ein Skript an. Wem die eigenen Bash-Künste dafür nicht ausreichen, kann sich gerne an unsere MyEngineers wenden. Hier ist die Zwischenschaltung eines Loadbalancers auch kein Problem.

OpenStack made easy – Snapshots erstellen, rotieren, einspielen

OpenStack made easy – Snapshots erstellen, rotieren, einspielen

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”.

¡¡¡ 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 .

OpenStack made easy… Mit Icinga 2-Master Maschinen überwachen

OpenStack made easy… Mit Icinga 2-Master Maschinen überwachen

Mit unserer OpenStack Cloud ist es kinderleicht seine eigene Umgebung nach eigenen Vorstellungen aufzubauen. Schnell und einfach mittels Terraform einige Maschinen starten, per angehängter Floating IP und zugehöriger Security Group den Dienst für die Außenwelt verfügbar machen und schon läuft das Projekt.

Aber keine Umgebung läuft fehlerfrei und Monitoring ist ein großes Thema – man merkt gerne vor seinen eigenen Benutzern, oder Kunden, wenn einmal etwas nicht ganz so funktioniert wie es soll. Ich denke jedem Leser dieses Blogs ist zum einen die Wichtigkeit eines Monitorings bewusst aber auch die Auswertung von Performancedaten wichtig. Wie überwache ich nun unkompliziert meine OpenStack Umgebung, vor allem wenn meine Server von der Außenwelt gar nicht erreichbar sind? Wir haben da mal etwas vorbereitet!

Neben unserem IaaS Angebot stellen wir – wie sicherlich bekannt – auch diverse SaaS Lösungen bereit. Darunter auch die App Icinga 2 Master, mit welcher man binnen weniger Minuten einen vollständigen Icinga 2 Master, mitsamt Graphite und Grafana erhält.

Ist dieser erstmal gestartet, findet man nach dem Login unter dem Reiter “Agenten hinzufügen” – oder je nach Browsersprache auch “Add Agent” – diverse Integrationsskripte für unterschiedliche Betriebssysteme.

Diese lädt man einfach nach Anleitung auf den Server, führt es aus und schon ist der Server an den Icinga2 Master angebunden.

server01:~# chmod +x; ./

Alles wichtige wird hier automatisiert. Per default werden einige Checks direkt mit angelegt und mithilfe des Directors ist es auch einfach weitere Checks für seine Hosts zu verteilen. Auch die API des Directors kann direkt angesprochen werden, es sind einem fast keine Grenzen gesetzt. Zusätzlich findet man noch einige Graphen zu den Performancedaten des angebundenen Agents direkt beim jeweiligen Check. Damit können nicht nur Probleme erkannt werden, sondern auch Trends werden direkt visualisiert. Diese Daten werden wohlgemerkt bei unseren Paketen ein Jahr vorgehalten um auch eine Langzeitübersicht zu gewährleisten.

Der erste Monat des Icinga 2 Masters ist außerdem kostenlos – ein Test lohnt sich. Unser MyEngineer hilft auch gerne bei der Einrichtung!