S3-Object-Storage anlegen und nutzen

S3-Object-Storage anlegen und nutzen

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. Es ist wichtig zu beachten, dass die Credentials für S3 unter Verwendung des OpenStack Project User Accounts erstellt werden sollten. Details zu den Gründen, warum man nicht den eigenen NWS-ID-Benutzer verwenden sollte, findet man hier. Eine Anleitung, wie man den OpenStack Project User aktiviert, findet man in dieser Dokumentation. 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 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 "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. 

Projekt starten und den ersten Server anlegen

Projekt starten und den ersten Server anlegen

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 Standard-Konto handelt. Kurze Zeit später kommt ein E-Mail-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 über die Accountkachel->“Zahlungsmethode bearbeiten“ die gewünschte Zahlungsweise (Kreditkarte/Rechnung/PayPal) zu hinterlegen.

Ebenfalls über die Accountkachel ->“Konto bearbeiten“ können wir nun unsere gewünschten Rechnungsdaten, Mailadresse für den Rechnungsversand etc. angeben und validieren unser Konto via Anruf oder SMS.

Final bringt uns der Klick auf „App starten“ 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.
Seit wir ein neues NWS-Frontend haben, könnte man den „Servers“-Knopf benutzen, um eine VM sehr einfach in nur einem Schritt zu erstellen. Da es bei diesem Artikel jedoch um OpenStack geht, machen wir so weiter.

Nach einem Klick auf den Link zum Web-Interface erscheint das OpenStack-Anmeldefenster. Die Anmeldedaten hier unterscheiden sich von denen, die Zugang zum NWS gewähren, sind aber ebenfalls in den App-Details OpenStack zu entnehmen.

Also fügen wir die erspähten Daten nun ein.

Das wärs dann auch schon – unser OpenStack ist betriebsbereit und wartet darauf, dass der erste Server angelegt wird.

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 aus (ganz rechts der Pfeil zum Auswählen). Dann bliebe hier noch die Frage: „Create New Volume“?
Klickt man hier „Yes“ bekommt man eine VM mit Ceph-Netzwerk-Storage-System-Volume.
Dieses wird dreifach über zwei Standorte repliziert. Stirbt der Hypervisor, starten wir die betroffenen VMs auf anderen Hosts erneut an.
„No“ würde dazu führen, dass die zu erstellende VM ihre Systemdaten direkt auf einer SSD auf dem Hypervisor hat.
Dies ist zwar schneller, hat jedoch den Nachteil, dass die Daten komplett auf nur einem physischen Host (RAID 1) liegen. Des Weiteren lassen sich diese VMs – sollte der Hypervisor in die Knie gehen – erst wieder starten, wenn dieser gefixt ist.
Windows-Server-Liebhaber mögen aus Performanz-Gründen diese Option wählen.

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-Group 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-Groups und Zuweisung dieser zu Maschinen ein, aber das würde in diesem Artikel jetzt den Rahmen sprengen.

In diesem Artikel gehen wir genauer auf die Sicherheitsgruppen ein.

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.