IaaS mit OpenStack - ?· 15 2Infrastruktur OpenStack setzt sich aus einer Reihe einzelner Komponenten…

Embed Size (px)

Text of IaaS mit OpenStack - ?· 15 2Infrastruktur OpenStack setzt sich aus einer Reihe einzelner...

  • 15

    2 Infrastruktur

    OpenStack setzt sich aus einer Reihe einzelner Komponenten zusam-men, die zwar als eigenstndige Projekte gefhrt werden, aber ineinan-der greifen und aufeinander abgestimmt sind.

    Anfnglich verwirrend mag die Namensgebung der Komponentensein: Zum einen gibt es einen Namen, der die Funktion beschreibt, undzum anderen einen Codenamen, den die Entwickler dem Projekt ga-ben oft mit leicht spielerisch-ironischer Anspielung (z. B. Ironic,das sich doppeldeutig auf das eiserne Bare Metal bezieht, oder Neu-tron, das aus lizenzrechtlichen Grnden umbenannt werden musste).Zur Entwirrung eine kleine bersichtstabelle:

    Tab. 2-1OpenStack bersichtder Komponenten undCodenamen

    Komponente Codename

    Identity Service Keystone

    Image Service Glance

    Compute Service Nova

    Block Storage Cinder

    Object Storage Swift

    Network Service Neutron (vormals Quantum)

    Dashboard Horizon

    Metering Ceilometer

    Orchestration Heat

    Database Service Trove

    Bare Metal Ironic

    Queue Service Marconi

    Data Processing Sahara

    Common Libraries Oslo

    Die Codenamen spiegeln sich auch in den Konfigurationsdateien undden Kommandozeilenbefehlen der Komponenten wider; z. B. konfigu-riert die Datei nova.conf den Compute Service.

    Tilman Beitter / Thomas Krgel / Andr Nhring / Andreas Steil / Sebastian Zielenski, IaaS mit OpenStack, dpunkt.verlag, ISBN 978-3-86490-038-9

    D3kjd3Di38lk323nnm

  • 16 2 Infrastruktur

    Jede Komponente deckt einen bestimmten Bereich einer IaaS-Umge-bung ab. Alle Komponenten im Zusammenspiel ergeben eine vollstn-dige IaaS-Umgebung. Teilweise ist der Einsatz einer Komponente auchunabhngig von der OpenStack-Umgebung sinnvoll: So kann zum Bei-spiel der OpenStack Object Storage als performante und skalierbareStorage-Lsung dienen.

    Unterschieden wird zwischen den eigentlichen OpenStack-Projek-ten, die von der OpenStack-Community aktiv entwickelt werden, undweiteren Projekten wie der Datenbank MySQL oder dem MessagingService RabbitMQ, die zwar kein Teil von OpenStack selbst sind, dieaber fr den Betrieb einer OpenStack-Umgebung notwendig oder hilf-reich sind und daher in der OpenStack-Umgebung Verwendung finden.

    Neue Projekte werden, bevor sie in ein kommendes Release ber-nommen werden, zunchst im sogenannten Incubator aufgenommen,in dem sie fr eine geweisse Zeit auf ihre Verwendbarkeit und Inte-grierbarkeit berprft werden. Sie befinden sich so lange im Status in-cubated.1

    Das Grizzly-Release besteht aus sieben integrated Projekten (Key-stone, Nova, Glance, Cinder, Swift, Neutron und Horizon) und zweiincubated Projekten (Ceilometer und Heat). Mit dem aktuellen Ha-vana-Release kommen weitere Inkubatoren-Projekte hinzu, wie Data-base Service (Trove), Bare Metal (Ironic), Queue Service (Marco-ni), Data Processing (Sahara) und die Common Libraries (Oslo).Die vielen neuen Projekte zeigen auch die enorme Dynamik, mit dersich OpenStack entwickelt . . .

    Abb. 2-1OpenStack Infrastruktur

    1Die offizielle Beschreibung dieses Prozesses ist im OpenStack-Wiki beschrie-ben: https://wiki.openstack.org/wiki/Governance/NewProjects.

    https://wiki.openstack.org/wiki/Governance/NewProjects

  • 2.1 Messaging Service 17

    Im Nachfolgenden werden die derzeit wichtigsten bzw. am hufigsteneingesetzten Projekte beschrieben.

    2.1 Messaging Service

    Ein Messaging Service sorgt fr die Kommunikation zwischen einzel-nen Diensten einer Komponente.2 Ein eigener Messaging Service ent-lastet die einzelnen Dienste beim Umgang mit den Aufrufen, indem ersich um die Entgegennahme, die Aufbewahrung und die Weiterleitungvon Nachrichten kmmert. Eine direkte Kommunikation zwischen deneinzelnen Diensten und ihren Hosts ist somit nicht mehr unbedingt not-wendig, da Jobs und Anfragen ber diesen Messaging Service einge-stellt und von anderen Komponenten zur Verarbeitung abgeholt wer-den knnen.

    2.1.1 AMQP

    Das Advanced Message Queuing Protocol (AMQP) ist ein offenes Pro-tokoll der Anwendungsschicht fr das zuverlssige Senden und Emp-fangen von Nachrichten. Es nutzt dazu das verbindungsorientierteTransmission Control Protocoll (TCP). Ursprnglich aus der Finanz-welt kommend, hat es sich zu einem Standard fr Messaging Ser-vices entwickelt. So halten sich die in einer OpenStack-Umgebung ein-setzbaren Messaging Services RabbitMQ und Apache Qpid an denAMQP-Standard. AMQP-Verbindungen nutzen eine Authentifizierungund knnen mittels Transport Layer Security (TLS) (vormals SSL) ge-schtzt werden.

    Der Server, Broker genannt, schickt Nachrichten in sogenannteChannels, wo sie gespeichert werden und von der Clientanwendungabgeholt werden knnen. Da eine AMQP-Verbindung normalerweiselanglebig ist, werden mgliche Probleme, wie z. B. der Verlust einerNachricht durch zu groe Latenzzeiten, vermieden.

    AMQP ist fr mehrere gleichzeitige Verbindungen ausgelegt, dieentweder mittels Multiplexing ber eine einzige TCP-Verbindung her-gestellt werden knnen, oder aber meist blich ber einen jeweilseigenen Channel mit jeweils eigener TCP-Verbindung fr jeden Prozess/Thread. Zur Identifizierung wird jeder Channel nummeriert, sodass je-de AMQP-Methode mit einer Channel-Nummer versehen wird.

    Mehr zu AMQP finden Sie im Abschnitt 12.2 auf S. 305.

    2Die Komponenten selbst kommunzieren untereinander ber ihre APIs.

    Tilman Beitter / Thomas Krgel / Andr Nhring / Andreas Steil / Sebastian Zielenski, IaaS mit OpenStack, dpunkt.verlag, ISBN 978-3-86490-038-9

  • 18 2 Infrastruktur

    2.1.2 RabbitMQ

    RabbitMQ ist eine vollstndige Enterprise-taugliche Implementierungdes AMQP-Standards. RabbitMQ wird wegen seiner Schnelligkeit, Sta-bilitt und vielen Funktionen und Client Libraries (fr Java, .NET undErlang) in OpenStack bisher bevorzugt eingesetzt. Neue OpenStack-Projekte werden blicherweise zuerst mit RabbitMQ getestet und auchdie meisten Installationsleitungen in den offiziellen Dokumentationenarbeiten mit RabbitMQ.

    Der RabbitMQ-Server ist in Erlang geschrieben und unter der Mo-zilla Public License verffentlicht.

    Mehr zu RabbitMQ finden Sie im Abschnitt 12.2.1 auf S. 307.

    2.1.3 Apache Qpid

    Qpid ist der Enterprise Messaging Service der Apache Foundation. Erist ebenfalls eine vollstndig kompatible Implementierung des AMQP-Standards und wird unter der Apache License entwickelt.

    Homepage: https://qpid.apache.org

    2.1.4 ZeroMQ

    Im Unterschied zu den anderen Messaging Services ist ZeroMQ (auch:MQ) kein zentraler Dienst mit dediziertem Message Broker, sonderneine Library fr verteilte Anwendungen, ber deren API Sockets bereit-gestellt und angesprochen werden.

    ZeroMQ ist in C++ geschrieben und wird hauptschlich unter demCollective Code Construction Contract (C4) und der Lesser GeneralPublic License (LGPL) entwickelt.

    Homepage: http://www.zeromq.org

    2.1.5 Marconi

    Zuknftig soll eine eigene OpenStack-Komponente als Messaging as aService (Codename: Marconi), das Messaging in OpenStack-Umge-bungen bernehmen. Diese Komponente ist derzeit im Inkubator.

    Mehr zu Marconi finden Sie im Abschnitt 12.7 auf S. 319.

    2.2 Datenbank

    Die meisten OpenStack-Komponenten, unter anderem Keystone, Nova,Glance und Cinder, bentigen einen Ort, an dem sie fr den Betrieb not-wendige Daten ablegen knnen. Dies kann in flachen Dateien gesche-hen, besser ist jedoch die Nutzung eines zentralen Datenbankservers

    https://qpid.apache.orghttp://www.zeromq.org

  • 2.2 Datenbank 19

    mit einem relationalen Datenbanksystem, da dies eine bessere Verwal-tung der Daten ermglicht. Auch Sicherheitsaspekte, Mglichkeiten zurSicherung und Replikation sowie Geschwindigkeit spielen eine Rolle.

    OpenStack wird im Wesentlichen mit drei Datenbanksystemen ent-wickelt:

    SQLite MySQL PostgreSQL

    Auf alle diese Datenbanken kann mittels SQL3 zugegriffen werden.SQL ist eine standardisierte Datenbanksprache in relationalen Daten-banken fr das Definieren von Datenstrukturen sowie das Einfgen,Verndern, Lschen und Abfragen von Daten.

    Eine Ausnahme bildet der Telemetry Service Ceilometer, der stan-dardmig MongoDB einsetzt. Mehr zu MongoDB finden Sie im Ab-schnitt 12.1.4 auf S. 304.

    2.2.1 SQLite

    Zum Speicher der Daten einer OpenStack-Umgebung wird per DefaultSQLite eingesetzt. Der groe Vorteil von SQLite ist seine Einfachheit:SQLite ist ein einfaches relationales Datenbanksystem, dessen Biblio-thek nur wenige hundert Kilobyte gro ist. Durch das Einbinden der Bi-bliothek knnen Anwendungen um Datenbankfunktionalitten erwei-tert werden, ohne dass eine weitere Server-Software installiert werdenmsste. Es gibt ein einfaches Frontend, das in der Konsole und in Shell-Skripten eingesetzt werden kann sowie mit sqlitebrowser ein grafischesFrontend. Es gibt keine Client-Server-Architektur. Die gesamte Daten-bank (Tabellen, Indizes, Views, Trigger usw.) wird in einer einzigenflachen Datei gespeichert.

    Neben einigen fr OpenStack irrelevanten Einschrnkungen (be-schrnkte nderungsmglichkeiten von Tabellen, die Verwaltung vonBenutzer- und Zugriffsberechtigungen auf Datenbankebene, u. a.) sttSQLite in Multi-Node-Umgebungen jedoch schnell an seine Grenzen,etwa wenn mehrere Keystone-Zugriffe auf die gleiche Datenbank erfol-gen sollen. Schreiboperationen unterschiedlicher Prozesse in derselbenDatenbankdatei knnen bei SQLite nur nacheinander ausgefhrt wer-den. Weiterhin bietet SQLite keine eingebauten Redundanz- und Repli-kationsmechanismen oder Hochverfgbarkeitsfunktionen.

    3SQL wird oft als Structured Query Language verstanden, leitet sich abervon dem Vorgnger SEQUEL ab.

    Tilman Beitter / Thomas Krgel / Andr Nhring / Andreas Steil / Sebastian Zielenski, IaaS mit OpenStack, dpunkt.verlag, ISBN 978-3-86490-038-9

  • 20 2 Infrastruktur

    Deswegen wird fr produktive OpenStack-Umgebungen MySQL/MariaDB oder