S3-Object-Storage anlegen und nutzen

S3-Object-Storage anlegen und nutzen

von | Apr 21, 2022 | OpenStack

In Zeiten der Hochverfügbarkeit und mehreren Webservern muss irgendwie die Grätsche zwischen der zentralen Datenhaltung, Datensicherheit und schnellen Zugriffszeiten geschafft werden. Genau dafür nutzen immer mehr Anwender nun Technologien, die mit Schlagwörtern wie S3, Buckets, Objectstorage und Swift locken. Das bieten wir von NETWAYS Web Services auch schon seit einiger Zeit an, aber wie uns aufgefallen ist, scheinbar zu wenig präsent für unsere Kunden dokumentiert. Um etwas Licht ins Dunkel zu bringen, haben wir diesen Artikel erstellt.

In diesem erklären wird daher Stück für Stück erklärt:

  • Warum Objectstorage
  • Erzeugen von S3-Credentials via OpenStack-API
  • Konfiguration von s3cmd
  • Anlegen eines neuen Buckets
  • Dateien im Bucket ablegen
  • Bucketinhalte listen
  • Datei aus Bucket herunterladen
  • weitere s3cmd Anwendungsbeispiele
  • Abschließendes

Warum Objectstorage?

Der S3-Object-Storage bietet viele Vorteile gegenüber lokal abgelegter Daten bzw. einem klassischen NFS-Storage, denn ein NFS-Setup besteht oftmals nur aus einem einzigen Server und stellt somit den single point of failure dar. Auch muss der Admin stets Sorge um die Performance des Storages und der bedienenden Webserver tragen. Ein weiterer Vorteil von Object-Storages ist die Größe und Anzahl für die zu speichernden Daten. Denn diese ist bei einem Object-Storage so gesehen unbegrenzt. Der Anbieter des Object-Storage (also im aktuellen Fall NWS) trägt dafür Sorge, dass hier niemals der Platz ausgeht. Bei dem eigenen NFS muss entsprechend die Größe von Anfang an in der Planung berücksichtigen und der Kunde zahlt auf Dauer die eingeplante Reserve mit. Bei einem Object-Storage wird nur das Volumen gezahlt, welches belegt ist. Erwähnenswert ist auch die Entlastung der Webserver, gerade im Hinblick auf lokal abgelegte Daten. Stellt man sich folgende Architektur vor: Die Anwendung wird auf mehreren Webservern betrieben, Bilder und andere Objekte werden im Object Storage aufbewahrt und durch eine intelligente Einbindung direkt an den Websitebesucher ausgeliefert, ohne die eigenen Webserver oder deren Bandbreite zu belasten. Kurzum, man gibt seiner Anwendung zu verstehen nicht konkret dieses Bild auszuliefern, sondern Anwendung gibt wiederum nur den Pfad des gespeicherten Bildes an den Besucher weiter. Das Bild wird letztlich direkt von dem dahinter liegenden Rados-Gateway ausgeliefert und wurde niemals vom App-Server ausgeliefert. Somit kommt es schnell beim Webseitenbesucher an, spart Bandbreite und mindert die Last auf dem eigenen Webserver und ist dennoch zentral gehalten. Übrigens bedient sich der Objectstorage an unserem Ceph, dort sind alle Daten über eine Vielzahl von Systemen verteilt und weisen auch selbstverständlich entsprechende Replica-Sets auf.

Erzeugen von S3-Credentials via OpenStack-API

Um bei NWS einen Object-Storage nutzen zu können, wird ein OpenStack-Account benötigt. Nachdem dieser bereit steht, kann es auch schon losgehen. Im OpenStack wird zum Menüpunkt „API Zugriff“ gewechselt und die OpenStack RC Datei heruntergeladen (oben rechts). Dieses soeben heruntergeladene Script wird nun auf der lokalen Maschine gestartet. Dabei wird lediglich das OpenStack-Passwort abgefragt. Aber Achtung, es wird ein OpenStack-Client benötigt.

source 9231-openstack-4707c-openrc.sh 
Please enter your OpenStack Password for project 9231-openstack-4707c as user 9231-openstack-4707c:

Nun müssen noch die EC2-Credentials für den S3-Zugriff erzeugt werden, hierzu dient das Kommando

openstack ec2 credentials create

Das Ergebnis liefert eine vergleichbare Ausgabe, wie die Folgende

+------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Field      | Value                                                                                                                                   |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| access     | aceab8b6b85c51f8d3b305aec1af39c2                                                                                                        |
| links      | {'self': 'https://cloud.netways.de:5000/v3/users/24c527b4929f10bd6c6ee09af4b30be2/credentials/OS-EC2/aceab8b6b85c51f8d3b305aec1af39c2'} |
| project_id | a40c737aaf3027d87e98f309f9f671d4                                                                                                        |
| secret     | e5d312a7627cdf2a87ac4322a6d7716b                                                                                                        |
| trust_id   | None                                                                                                                                    |
| user_id    | 24c527b4929f10bd6c6ee09af4b30be2                                                                                                        |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------+

Konfiguration von s3cmd

Für die weitere Verwendung wird nun s3cmd konfiguriert. Dafür ist ein installiertes s3cmd die Voraussetzung.

Die Einrichtung startet mittels

s3cmd --configure

Im folgenden Wizard werden die zuvor erstellten Daten eingetragen, dies sieht dann in etwa so aus (relevante Eintragungen in Fettdruck)

s3cmd --configure

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for 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 "s3.amazonaws.com" for S3 Endpoint and not modify it to the target Amazon S3.
S3 Endpoint [s3.amazonaws.com]: rgw1.netways.de

Use "%(bucket)s.s3.amazonaws.com" 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)s.s3.amazonaws.com]: rgw1.netways.de/%(bucket)s

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: rgw1.netways.de
DNS-style bucket+hostname:port template for accessing a bucket: rgw1.netways.de/%(bucket)s
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'

Damit die S3-Kommandos nun wie gewünscht funktionieren, muss an der soeben erzeugten Config noch eine Kleinigkeit angepasst werden

vim ~/.s3cfg

Dort wird die Zeile

signature_v2 = False

angepasst auf

signature_v2 = True

Nachdem gespeichert ist, kann die Verwendung auch schon beginnen.

Anlegen eines neuen Buckets

Mittels des folgenden Kommandos wird ein neuer Bucket erstellt

s3cmd mb s3://myfirstbucket

Um die Anlage des Buckets zu überprüfen, wird dieser aufgelistet mittels

s3cmd ls

Dateien im Bucket ablegen

Zeit, die ersten Dateien hochzuladen. Dafür wird der put Parameter genutzt

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

Bucketinhalte listen

Um zu sehen, was in dem soeben befüllten Bucket alles liegt, listet der ls-Befehl die Inhalte auf. Dieser wird nun jedoch um den Bucketnamen ergänzt

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

Datei aus Bucket herunterladen

Die soeben hochgeladene Datei kann nun mittels get Parameter herunter geladen werden.

s3cmd get s3://myfirstbucket/water.liquid

weitere s3cmd Anwendungsbeispiele

Nachfolgend einige hilfreiche Kommandos:

Ein Objekt von einem Bucket in einen anderen verschieben:

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

Ein Object verschlüsselt im Bucket ablegen (Bedarf einer vordefinierten Passphrase (s3cmd –configure)

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

Ein sehr wertvolles Kommando ist der Sync, um ein lokales Verzeichnis mit einem Bucket zu synchronisieren (alles unterhalb /important-data wird nach s3://myfirstbucket/backup/ gesynct)

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

Um in gewissen Anwendungsfällen Bandbreiten zu schonen, hilft die –limit-rate Option, diese wird standardmäßig mit bytes angegeben, aber die Option erkennt auch einen k bzw. m Suffix (Kilo-/Megabyte) pro Sekunde

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

Abschließendes

Natürlich gibt es noch sehr viel mehr Parameter für den s3cmd, all diese lassen sich mittels –help auflisten. Bei der Verwendung von s3 lassen sich aber auch moderne und elegante Verfahrensweisen gleich mit einbauen, z. B. die Lebensdauer einer Datei mit vorab festgelegtem Löschdatum. Im OpenStack kann man sich auch ansehen, was das Objectstorage so tut, dafür navigiert man über Projekt>Objektspeicher zum entsprechenden Menü. Unserer Objektspeicher funktioniert übrigens auch mit swift – so wird er auch von OpenStack selbst angesprochen. Also ein Mischbetrieb von S3 und swift ist nach Belieben möglich. Aktuell haben wir swift noch nicht weiter dokumentiert, aber unseren freundlichen MyEngineers geben hier gern auf Anfrage Auskunft.

Die Preise für unseren Objectstorage und alles andere was wir so bei NWS anbieten, kann man übrigens hier jederzeit nachlesen.

Corosync Cluster mit Failover IP

Corosync Cluster mit Failover IP

von | Nov 30, 2021 | OpenStack

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!

Scaling on Demand

Scaling on Demand

von | Nov 30, 2021 | OpenStack

Je nach Art der eigenen Produktion kann es für manche:n Serverbetreiber:innen 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 das Scaling 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:
source XXXX-openstack-XXXXX-openrc.sh

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.

Backup und Snapshot

Backup und Snapshot

von | Nov 30, 2021 | OpenStack

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. In unserem NWS sind Backups und Snapshots schnell und einfach eingerichtet, sodass allnächtlich automatische Sicherungen deiner VMs angefertigt werden.

Setzen wir die Aufbewahrungsdauer bspw. auf eine Woche und bestätigen:

Die NWS-Server-Liste wird für die folgenden drei Fälle eine Übersicht ähnlich zu dieser liefern:
VM Example: SSD: Backup
VM Example2: Ceph-Volume: Backup
VM Example3: Ceph-Volume: Snapshot

Nach deren nächtlicher automatischer Anfertigung durch uns werden diese dann unter deren jeweiligen Menüpunkten sichtbar.

Um genomme Sicherungen verwenden zu können, müsste man spätestens dann ins Horizon (OpenStack-WebUI)  wechseln.
Fünf Tage nach Einrichtung der Sicherungen fände man für unsere drei Server bspw. dort vor:

Backup (von SSDs; auffindbar unter: Compute > Images)

Volume-Backup (von Ceph-Volumes; auffindbar unter: Volumes > Backups)

Volume-Snapshot (von Ceph-Volumes; auffindbar unter Volumes > Snapshots)

Die letztgenannten Snapshots basieren auf Inkrementen des zugrunde liegenden Volumes und sind güngstiger im Vergleich zu Backups; mehr dazu gleich.

Sollte man diese Sicherungseinstellungen manuell über die Metadaten eingeben wollen:

was modifizieren:

VM auf SSD

Backup

VM
(Compute > Instances)

nws_backup=true

rotation=7

VM mit
Ceph-Volume

Backup

Volume
(Volumes > Backups)

cinder-backup=true

cinder-backup-rotation=7

VM mit
Ceph-Volume

Snapshot

Volume
(Volume > Snapshots)

nws_snapshot=true

rotation=7

Wer nun ihre/seine Backups/Snapshots wieder verfügbar machen möchte, kann bspw.

  • ein Volume daraus erstellen und dieses einer bestehenden VM hinzufügen
  • (die gecrashte VM löschen und) eine neue VM daraus starten (VMs mit Ceph-Volume) oder
  • die Machine mit dem bestimmten Backup/Snapshot rebuilden (VMs auf SSD)

Snapshot vs. 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 wiederhergestellt werden.

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.

Du hast bei all dem Replizieren und Kopieren die Übersicht verloren? Bei Fragen helfen wir gerne weiter!

Monitoring für Maschinen mit Icinga 2 Master

Monitoring für Maschinen mit Icinga 2 Master

von | Nov 30, 2021 | OpenStack

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.

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!

Sicherheitsgruppen verwalten und zuweisen

Sicherheitsgruppen verwalten und zuweisen

von | Nov 30, 2021 | OpenStack

Nachdem man sich in unserer OpenStack-Weboberfläche die erste neue Instanz zurecht geklickt und dabei einen SSH-Public-Key, mit dem man sich auf diese VM verbinden möchte, zugewiesen hat, steht die:der frischgebackene Administrator:in vor dem kleinen Problem, dass sie:er von außen nicht auf die Instanz kommt; das „verdanken“ wir der „default“-Sicherheitsgruppe.

Sie beinhaltet die Regeln:


– Erlaube  eingehende Verbindungen mit jedem Protokoll, auf jedem Port, aber nur von Hosts im internen Netzwerk, die auch die „default“-Sicherheitsgruppe nutzen (IPv4 und IPv6)
– Erlaube ausgehende Verbindungen mit jedem Protokoll, auf jedem Port und nach überallhin (IPv4 und IPv6)

Auf diese Weise wird der Schutz der neuen VM sichergestellt. Jeder Verbindende von außen kommt nur wirklich durch die Zugangsöffnung, die dafür vorgesehen und geschaffen wurde. Um eine solche zu kreieren gibt es zwei Wege: Es kann eine neue Sicherheitsgruppe angelegt und mit einer Regel versehen oder die default-Sicherheitsgruppe um eine Regel ergänzt werden. Zweites bietet den Nachteil, dass die einzugebende Regel künftig für alle neuen Instanzen mit der default-Sicherheitsgruppe angewandt wird, was nicht immer auf allen VMs sinnvoll sein wird.

Neue OpenStack-Sicherheitsgruppe erstellen

Man klicke: Netzwerk > Sicherheitsgruppen > „+ Sicherheitsgruppe erstellen“.

Ein Dialogfeld erscheint, in dem, zwar nach Gusto, jedoch obligatorisch ein Name eingegeben werden muss (und optional eine Beschreibung eingegeben werden kann). Hier nenne ich die neue Gruppe „Beispiel“, aber jeder andere Name, der z. B. eigene Gruppierungsstrategien verfolgt, wird es tun. Dann noch Sicherheitsgruppe erstellen.

Dann erscheint in der Liste:

SSH-Erreichbarkeit von extern als Regel einer Sicherheitsgruppe hinzufügen

Man mause: Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll).

In einer neuen, noch unbearbeiteten Sicherheitsgruppe wird man nur jeweils eine Regel zum Austritt (IPv4 und IPv6) finden. Weiter geht es mit: „+ Regel hinzufügen“. Hier wähle man im Drop-down-Menü Regel den Unterpunkt SSH und „Hinzufügen“.

– Wenn eine bereits der VM zugewiesene Sicherheitsgruppe (z. B. default) mit dieser Regel versehen wurde, findet die Regel sofort Anwendung und die VM kann über die CLI kontaktiert werden.

– Falls eine Regel in einer neuen Sicherheitsgruppe erstellt wurde, die noch nicht der VM zugewiesen wurde:

Der VM eine neue Sicherheitsgruppe zuweisen

Navigiere: Compute > Instanzen > Drop-down-Pfeil (ganz rechts neben der Instanz, die modifiziert werden soll) > Sicherheitsgruppen bearbeiten. Unter „Alle Sicherheitsgruppen“ findet sich die neue, mit dem weiß-auf-blauen Plus füge man die neue Sicherheitsgruppe den „Instanz-Sicherheitsgruppen“ hinzu und „Speichern“.

ICMP-Erreichbarkeit von extern als Regel erstellen

Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll) > „+ Regel hinzufügen“ > Regel = „Alle ICMP“ > Hinzufügen.

Genauso funktioniert auch z. B. eine Regel für HTTP / HTTPS oder die folgenden

Regelbeispiel mit mehr Schikanen
Erreichbarkeit von extern mit TCP im Portbereich 65530-65535 nur von IP 200.135.41.125 aus

Netzwerk > Sicherheitsgruppen > Regeln verwalten (bei der Sicherheitsgruppe, die editiert werden soll) > „+ Regel hinzufügen“ > Regel = „Angepasste TCP-Regel > Port öffnen = Port-Bereich >
„Von-Port“ = 65530 > „Bis-Port“ = 65535 > CIDR = 200.135.41.125/32 > „Hinzufügen“

Für alle, denen das Aufsetzen und Konfigurieren neuer VMs zu umfangreich oder schwierig erscheint, übernimmt gerne MyEngineer das Erstellen jedes gewünschten Setups.

Das erste Projekt kann in unserer NWS-Cloud gestartet werden.