Mit Hardware-Beschleunigung und schnellem Netz hilft Desktop-Virtualisierung, Administrationsaufwand und Kosten sparen, ADMIN 04/2013 verrät, wie die ... (mehr)

Gateway-Benutzer anlegen

Damit ist das RADOS-Gateway einsatzbereit, allein es gibt noch keinen User, der es tatsächlich nutzen könnte. Der Befehl

radosgw-admin user create --uid=adminmagazin --display-name="Admin Magazin Test"--email=test@example.com

schafft Abhilfe. Außerdem gibt er die Credentials auf der Konsole aus (Abbildung 1), die der neue Nutzer für die Verbindung benötigt: Der »Access-Key« und der »Secret-Key« entsprechen ihren Amazon-S3-Gegenstücken. Mit den Werten ist anschließend die Verbindung zum RADOS-Gateway mittels S3-Client möglich (Abbildung 2) – auf Windows- oder OS-X-Systemen kann beispielsweise Cyberduck [4] (Abbildung 3) zum Einsatz kommen. Linux-Systeme haben in Form von »s3cmd« [5] auch ein Werkzeug für die Kommandozeile.

Abbildung 1: Beim Anlegen des Benutzers entsteht ein Access-Key sowie ein Secret-Key – beide Werte sind für den Login am RADOS-Gateway notwendig.
Abbildung 2: Kein Anschluss unter dieser Nummer: RGW spricht zwar HTTP, aber für den Zugriff braucht es einen Client, der S3 kann. Ein normaler Browser genügt nicht.
Abbildung 3: Mittels eines Clients wie Cyberduck lässt sich zu einem RADOS-Gateway über das Amazon-S3-Protokoll eine Verbindung aufbauen.

Übrigens: Der gesamte Vorgang funktioniert natürlich auch, wenn für den Webserver die Verschlüsselung per SSL-Zertifikat aktiviert ist (Abbildung 4). Die meisten S3-Clients setzen das sogar voraus.

Abbildung 4: Das Beispiel enthält eine Verbindung, die neben Plaintext auch die SSL-verschlüsselte Verbindung ermöglicht.

ReSTful-APIs

Am besten lässt sich die Funktion des RADOS-Gateways mit einem einzigen Satz beschreiben: Das RADOS-Gateway erweitert RADOS um ein ReSTful-API. Der Begriff ReSTful geistert in letzer Zeit immer häufiger durch die Welt der IT, insbesondere in Cloud-Computing-Umgebungen spielt ReST eine wichtige Rolle. Grund genug also, sich mit den Prinzipien hinter ReST einmal genauer zu befassen.

HTTP, die Triebfeder des Webs

Das Hypertext Transfer Protocol, kurz HTTP, ist das Rückgrat des Teils des Internets, der gemeinhin als World Word Web gilt. Seit der Veröffentlichung der ersten HTTP-Version (0.9) im Jahre 1991 erlebt das Protokoll einen echten Boom, der dank einer gewissen Eigendynamik im Laufe der Zeit immer noch größer wurde. Heute ist HTTP nicht mehr wegzudenken: Jeder Computer, quer über Geräte- und Betriebssystemgrenzen hinweg, hat mindestens einen HTTP-fähigen Client an Bord, einen Browser. Serverseitig ist HTTP vor allem deshalb überaus beliebt, weil es für das Protokoll zahllose Einsatzmöglichkeiten und bereits implementierte Funktionen gibt.

Hochverfügbarkeit auf Serverseite lässt sich problemlos per Fail-Over-Setup oder – und das ist die deutlich beliebtere Variante – über einen Loadbalancer realisieren. Loadbalancer gibt es diverse; sie zeichnen sich dadurch aus, dass sie für unterschiedliche Einsatzszenarien entwickelt wurden und genau diese besonders gut unterstützen. Dass HTTP im Laufe der Jahre an Beliebtheit zugenommen hat, verwundert also nicht.

Der Aufbau von HTTP ist dabei denkbar simpel. Das Protokoll ist stateless, ursprünglich war es dafür vorgesehen, dass der Client per GET-Befehl eine ganz bestimmte Seite anfordert und der Server ihm diese liefert. Der Upload war ebenso Teil des Prinzips, der PUT-Befehl legt davon Zeugnis ab. Durch die immer weiter verbreitete Nutzung des World Wide Webs entstanden aber auch so manche Begehrlichkeiten, die HTTP scheinbar an seine Grenzen brachten. Denn GET- und PUT reichen nicht, um beispielsweise Clients einen Weg zu bieten, per HTTP-Request bestimmte Aktionen auszulösen. So entwickelten sich im Laufe der Zeit verschiedene APIs, die die Limitationen umgehen: Indem ein Client bestimmte URLs aufruft und spezifische Parameter beim Aufruf mit an den Server sendet, leiten die am Server hinterlegten Dienste entsprechende Maßnahmen ein.

ReST: Standardisierte APIs

Genau hier kommt ReST ins Spiel – es handelt sich um eine Abkürzung, die für »Representational State Transfer« steht. Per Definition ist ReST gar nicht HTTP-spezifisch, doch hat es sich in den letzten Jahren insbesondere im HTTP-Umfeld durchgesetzt: Als Standard-Architektur für Web-APIs. Wichtig ist die Erkenntnis, dass ReST kein vordefinierter Standard ist. Stattdessen beschreibt der Begriff lediglich das Design einer Software, bei der Server und Client über den Aufruf bestimmter URIs standardisiert kommunizieren und bestimmte Vorgänge starten. Ein bekanntes Beispiel ist OpenStack; wie fast alle anderen Cloud-Computing-Umgebungen bietet auch in OpenStack jedem Dienst ein per HTTP ansprechbares Interface mit ReSTful-API an, das die Clients im weiteren Verlauf nutzen, um Aktionen auszulösen – so sorgt der Aufruf einer spezifischen URL samt Parametern beispielsweise dafür, dass der Server eine virtuelle Maschine startet. Auch im Bereich der Online-Speicherdienste hat ReSTful seinen Siegeszug schon begonnen: Amazons S3 bietet beispielsweise die Möglichkeit, externe Clients per ReSTful-API anzubieten. OpenStack Swift kann entweder eine eigene ReSTful-Implementation verstehen oder dank »Swift3« mit Amazon-S3-Kompatibilität aufwarten.

Das RADOS-Gateway schlägt in diese Kerbe: Es bietet eben die Möglichkeit, auf einen RADOS-Speicher per ReSTful-Protokoll zuzugreifen. Dabei versteht es wahlweise ebenfalls Amazons S3-Protokoll oder OpenStack Swift. Eine für RADOS spezifische ReSTful-Implementierung gibt es übrigens nicht, zumindest im Augenblick reichen den Ceph-Entwicklern offenbar die gegebenen Methoden.

Logging beim RADOS-Gateway

In der Default-Konfiguration loggt das RADOS-Gateway jede Operation – und zwar nicht ins Syslog, sondern in Form eines einzelnen binären Objektes, das im Anschluss ebenfalls Teil des Objectstores ist. Gerade wenn viele Requests auf das RADOS-Gateway niederprasseln, kann das die Performance negativ beeinflussen. Der Konfigurationseintrag

rgw enable ops log = false

im Gateway-Teil von »ceph.conf« schafft Abhilfe.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019