OpenStack made easy – OpenStack Projekt starten und die erste Maschine anlegen

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

Mit unserer neuen OpenStack-Umgebung feiern wir Erfolge – Performance, Stabilität, Flexibilität und günstige Preise überzeugen unsere Kunden. Die Vielzahl von Funktionen überfordert aber den ein oder anderen Anwender bei der ersten Nutzung. Wir helfen aber auch hier sehr gern Licht ins Dunkel zu bringen und zeigen auf, wie einfach es eigentlich ist.

Zu Beginn benötigen wir einen NWS-Account. Dieser lässt sich kostenfrei unter https://nws.netways.de anlegen. Hier gibt man lediglich eine Mailadresse und das gewünschte Passwort an, sowie ob es sich um ein Business oder Stanard-Konto handelt. Kurze Zeit später kommt ein Validierungslink per Mail. Nach der Bestätigung des Kontos kann man sich bereits einloggen. Für den Quick-Start ist eine Demo-Kreditkarte hinterlegt, es empfiehlt sich hier aber direkt über den Menüpunkt “Konto”->”Zahlungsmethode bearbeiten” die gewünschte Zahlungsweise (Kreditkarte/Rechnung/PayPal) zu hinterlegen.

Nun geben wir im Menüpunkt “Konto”->”Konto bearbeiten” unsere gewünschten Rechnungsdaten, Mailadresse für den Rechnungsversand etc. an und validieren unser Konto via Anruf oder SMS.

Jetzt ist es an der Zeit unser OpenStack zu starten. Hierzu reicht ein kurzer Klick auf “Ihre Apps” in der oberen rechten Ecke.

Final bringt uns der Klick auf “Start your first app now” zum Ziel – hier folgt man nur noch dem OpenStack-Button und bestätigt die ungeliebten Klauseln zu AGB und Datenschutz – aber was sein muss, muss sein.

Nun taucht in unserer App-Übersicht unser OpenStack auf. Nur einen Klick entfernt warten hinter der unscheinbaren Kachel schon alle wichtigen Informationen zum Start.

Auch erscheint bereits das OpenStack Anmeldefenster. Die Anmeldedaten hier unterscheiden sich von denen, die im NWS ausgewählt wurden, sind aber im Tab “Zugang” einfach zu entnehmen.

Also fügen wir die erspähten Daten nun im Tab “LiveView” ein. Alternativ steht die OpenStack-Anwendung natürlich auch Fullscreen unter https://cloud.netways.de zur Verfügung.

Das wärs dann auch schon – unser OpenStack ist betriebsbereit und wartet auf den Einsatz der ersten Maschine.

Die erste Maschine starten

Keine Sorge – auch das geht fast genauso einfach.

Navigieren wir zu “Compute”->”Instances” und starten im oberen rechten Eck eine neue Instanz

Im ersten Schritt vergeben wir einen Namen für unsere Instanz

Nun arbeiten wir die weiteren Register auf der linken Seite durch und besuchen den Punkt “Source”

Hier wählen wir als Boot-Source “Image” aus und suchen uns unten aus der Liste das gewünschte Betriebssystem (ganz rechts der Pfeil zum auswählen). Die anderen Buttons lassen wir unangetastet – eine Erklärung hierzu folgt in späteren Posts. Einzig beim Start von Windows-Maschinen klicken wir bei “Create New Volume” auf “No” – warum? Dazu in einem späteren Artikel mehr!

Der Menüpunkt Flavor bietet verschiedene Presets für die gewünschten Größen der Maschinen. Hier wählt man aus, was man benötigt. Fehlt ein gewünschtes Flavor? Einfach eine kurze Mail schreiben und wir kümmern uns drum!

Im nächsten Register dreht sich alles um Netzwerk, dort wird unser OpenStack-Netzwerk ausgewählt, was gleichlautend mit unserem OpenStack-Projekt ist.

Für den Moment ignorieren wir vorerst ein paar Menüpunkte und widmen unsere Aufmerksamkeit dem Menüpunkt Key-Pair.

Über den Button “Import Key Pair” importieren wir unseren SSH-Pubkey in seiner ungekürzten Schönheit und vergeben einen beliebigen Namen. Auch dieser wird wieder “nach oben” reingeklickt.

Final kann die Instanz gestartet werden – schon wenige Sekunden später steht diese bereit.

Für die erste Nutzung müssen jedoch noch 2 Dinge erledigt werden.

Floating-IP zuweisen

Hierzu klicken wir in der Maschinenübersicht rechts bei der gewünschten Maschine auf den kleinen Pfeil nach unten auf “Associate Floating IP”, beziehen mittels “+” eine Neue IP aus dem Pool und weisen Sie der Maschine zu.

Nun sehen wir, dass die Maschine eine IP im internen Netz hat, sowie die gerade zugewiesene Floating-IP – diese brauchen wir später, um uns auf die Maschine zu verbinden.

Security-Groups bearbeiten

Unser OpenStack bring bereits eine Firewall mit. Deshalb funktioniert der Zugang via SSH oder RDP noch nicht. Dies ist jedoch mit wenigen Klicks ebenfalls erledigt.

In der Hauptnavigation von OpenStack besuchen wir Network->Security Groups. Hier “Managen” wir die “Rules” unserer default Security-Gruppe via “Manage Rules” und fügen mittels “Add Rule” eine neue Regel für SSH hinzu und geben vorerst alle Netze für den Zugriff frei.

Da alle angelegten Maschinen die “default” Regel bereits enthalten, funktioniert ab jetzt der Zugriff auf die Maschine via SSH. In späteren Artikeln gehen wir näher auf die Handhabung mit Security-Gruppen und Zuweisung dieser zu Maschinen ein, aber das würde in diesem Artikel jetzt den Rahmen sprengen.

Mit Maschine verbinden

Wenn alle Schritte wie beschrieben durchgeführt wurden, kann man sich jetzt via SSH mit der Maschine via Floating-IP verbinden. Für Ubuntu-Systeme verbindet man sich als User ubuntu, bei Debian als debian usw. Bei Windows-Maschinen kann man das Passwort beim ersten Starten eingeben, hierzu muss man sich etwas durch die Details in der Instance-Übersicht der Maschine klicken.

Kosten

Zeit ist Geld – auch bei uns! Deshalb werden alle Maschinen bzw. die einzeln genutzten Ressourcen stundengenau abgerechnet (Preise hier) und zwar zu fairen und transparenten Preisen. Damit man alles im Auge behält, haben wir die aktuell aufgelaufenen Kosten und den Forecast für den laufenden Monat (bei gleichbleibender Nutzung) in unserem Kosten Rechner festgehalten.

Need more?

Kein Problem. Mit etwas Geduld kommen hier mehr und mehr Artikel. Wer nicht warten kann oder sich nicht kümmern will, kann bei uns eine Remote-Schulung buchen, unser Webinar ansehen oder unsere kompetenten MyEngineers buchen.

 

In diesem Artikel gehen wir genauer auf die Sicherheitsgruppen ein.

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.

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

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

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 createHost.sh; ./createHost.sh

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!

Fabian Rothlauf
Fabian Rothlauf
Senior Systems Engineer

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen...
OpenStack made easy – Sicherheitsgruppen verwalten und zuweisen

OpenStack made easy – Sicherheitsgruppen verwalten und zuweisen

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

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 der/die frisch gebackene AdministratorIn vor dem kleinen Problem, dass er/sie 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 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 in unserer NWS-Cloud kann hier gestartet werden.

Wie man sich die erste Maschine aufsetzt, ist in diesem Artikel beschrieben.

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