von Martin Scholz | Nov 30, 2021 | OpenStack, Tutorial
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.
von Martin Scholz | Nov 30, 2021 | OpenStack, Tutorial
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!
von Martin Scholz | Nov 30, 2021 | OpenStack, Tutorial
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.
Recent Comments