So fügen Sie F5 Application Delivery Services zu OpenStack hinzu
Einleitung
OpenStack entwickelt sich rasch zur führenden Cloud-Plattform für die Bereitstellung von Infrastructure as a Service (IaaS) und bildet inzwischen die Grundlage für Private Clouds, Public Clouds und verwaltete Private Clouds. Da in OpenStack-Clouds zunehmend geschäftskritische Produktionsanwendungen betrieben werden, gewinnen fortschrittliche Application-Delivery-Services für die Schichten 4 bis 7 entscheidend an Bedeutung. Diese Services bieten zusätzliche Sicherheit, Skalierbarkeit und Optimierung, damit geschäftskritische Anwendungen sicher, schnell und verfügbar bleiben. F5 ist der führende Anbieter fortschrittlicher Application-Delivery-Services für Rechenzentren sowie Public und Private Clouds – einschließlich solcher, die auf OpenStack basieren. Application-Delivery-Services von F5 können in eine OpenStack-Cloud integriert werden. Eine frühzeitige Prüfung der verfügbaren Optionen erleichtert die effiziente Planung einer OpenStack-Architektur und ihrer Bereitstellung.
Was ist OpenStack?
OpenStack ist eine Open-Source-Softwareplattform zur Bereitstellung von Cloud-Computing-Diensten. OpenStack entstand als gemeinsames Projekt der NASA und Rackspace Hosting und wird derzeit von der OpenStack Foundation verwaltet, deren Aufgabe es ist, die Software und die OpenStack-Community zu fördern.
Mehrere kommerzielle Unternehmen bieten inzwischen entweder eigene OpenStack-Distributionen oder zusätzliche Dienstleistungen wie Support und Beratung sowie vorkonfigurierte Appliances an.
OpenStack besteht aus einer Reihe von Komponenten, die die verschiedenen Dienste bereitstellen, die zum Aufbau einer Cloud-Computing-Umgebung erforderlich sind. Diese Komponenten sind an anderer Stelle ausführlich dokumentiert. Es gibt jedoch eine Reihe von Modulen, die für eine F5-OpenStack-Bereitstellung unmittelbar relevant sind.
Ein grundlegendes Element von OpenStack ist die RESTful API, über die Infrastrukturkomponenten konfiguriert und automatisiert werden können. In vielen OpenStack-Anwendungsfällen – etwa beim Aufbau einer mandantenfähigen Self-Service-Cloud oder einer Infrastruktur zur Unterstützung von DevOps-Praktiken – ist eine API-gesteuerte Orchestrierung unerlässlich. Die Möglichkeit, Bereitstellungszeiten von Wochen auf Minuten zu verkürzen oder täglich Hunderte von Diensten bereitzustellen, ist häufig der ausschlaggebende Grund für den Wechsel zu einer Cloud-Plattform. Damit dies effektiv funktioniert, müssen alle Komponenten der Infrastruktur in das Automatisierungs-Framework eingebunden sein. Viele Anwendungen benötigen erweiterte Application-Delivery-Dienste (wie Anwendungssicherheit oder Zugriffskontrolle), um tatsächlich produktionsreif zu sein. Daher ist es entscheidend, dass sich Application-Delivery-Dienste in die Orchestrierungs- und Bereitstellungstools von OpenStack integrieren lassen.
Projekte, Mandanten und Netzwerke
Mandantenfähigkeit ist ein wichtiges Konzept in OpenStack. Innerhalb von OpenStack wird eine Gruppe von Benutzern als Projekt oder Mandant bezeichnet. (Die beiden Begriffe sind austauschbar.) Projekten können Kontingente für Ressourcen wie Rechenleistung, Speicher oder Images zugewiesen werden. Eine der wichtigsten Entscheidungen bei der Konzeption einer mandantenfähigen Architektur betrifft die Gestaltung der Netzwerke für Mandanten. F5® BIG-IP® Plattformen bieten eine Reihe von Optionen für Mandantenfähigkeit und Netzwerksegmentierung zur Gewährleistung der Interoperabilität mit der Mandantenfähigkeit von OpenStack.
Provider-Netzwerk
Provider-Netzwerke verwenden in der Regel entweder flache (nicht getaggte) oder – häufiger – VLAN-Netzwerke (mit 802.1Q-Tagging). Diese entsprechen weitgehend der herkömmlichen Netzwerkstruktur von Rechenzentren. OpenStack-Netzwerke werden vom Administrator definiert und erstellt und von mehreren Mandanten gemeinsam genutzt.
In einigen Fällen verfügen die Compute-Instanzen eines Mandanten über Schnittstellen, die direkt mit dem Providernetzwerk verbunden sind. Mandanten definieren keine eigenen Netzwerke, sondern stellen lediglich eine Verbindung zu den konfigurierten Providernetzwerken her und verwenden dabei die vom Administrator des Providers festgelegten IP-Adressbereiche. In anderen Fällen erstellen Mandanten virtuelle Netzwerkkonfigurationen innerhalb der Providernetzwerke.
Mandantennetzwerke
Administratoren können Mandanten die Möglichkeit geben, eigene spezifische Netzwerkarchitekturen zu erstellen. Diese werden meist von OpenStack Neutron mithilfe von Open-vSwitch-Instanzen auf Compute-Knoten gesteuert, es können jedoch auch andere SDN-Lösungen (Software-Defined Networking) verwendet werden. Entweder VLANs oder transparente Ethernet-Tunnel mit GRE- oder VXLAN-Technologie ermöglichen die Kommunikation zwischen den Compute-Instanzen eines Mandanten und isolieren sie von anderen Mandanten. Anfang 2016 war GRE-Tunneling die am häufigsten verwendete Bereitstellungsmethode. Mandanten können eigene Netzwerke und IP-Adressbereiche erstellen, die sich zwischen verschiedenen Mandanten durchaus überschneiden können. Jeder Mandant kann über einen OpenStack-Router verfügen, der die Kommunikation außerhalb seiner Netzwerke ermöglicht. Dazu werden dem Mandanten eine oder mehrere Floating-IP-Adressen zugewiesen, die der Mandantenrouter in die konfigurierte private IP-Adresse des Mandanten übersetzt. (Beachten Sie, dass Floating-IP-Adressen von OpenStack Neutron und BIG-IP unterschiedliche Dinge sind. Wie die BIG-IP-Plattform die Mandantenisolierung verwaltet, wird später erläutert.)
F5 Application-Delivery-Services
F5-Produkte bieten ein Spektrum fortschrittlicher Application-Delivery-Services, die auf Skalierbarkeit, Verfügbarkeit und mehrschichtige Sicherheit ausgelegt sind. Zu den wichtigsten Beispielen zählen unter anderem:
Die BIG-IP-Plattform
Die BIG-IP Plattform ist als physische, virtuelle und Cloud-Edition erhältlich. Die Plattform stellt Anwendungsdienste über BIG-IP Softwaremodule bereit. Eine BIG-IP Plattform kann je nach Anforderungen der Anwendungen ein oder mehrere Softwaremodule ausführen und als eigenständige Einheit oder in hochverfügbaren Clustern bereitgestellt werden.
Die BIG-IP-Plattform ist ein äußerst leistungsfähiger, zustandsbehafteter, bidirektionaler Zero-Copy-Proxy. Das Verständnis dieses grundlegenden Architekturprinzips kann verdeutlichen, wie die BIG-IP-Plattform Dienste bereitstellt, und zur Klärung von Architekturentscheidungen beitragen.
Clients stellen eine Verbindung zum BIG-IP-Gerät oder zur BIG-IP-Instanz her, das bzw. die wiederum eine Verbindung zu den Back-End-Servern herstellt (oder in einigen Fällen, etwa bei DNS-Diensten, den Anwendungsdatenverkehr verarbeitet und direkt auf die Clientanfrage antwortet). Dadurch entsteht eine TCP-„Luftbrücke“, wobei die TCP-Sitzung zwischen Client und Server vollständig neu aufgebaut wird. Innerhalb dieser logischen Lücke stellt die BIG-IP-Plattform Dienste zur Anwendungsbereitstellung bereit. Während der Anwendungsdatenverkehr die Plattform durchläuft, kann er überprüft, verändert und gesteuert werden. Somit ermöglicht die BIG-IP-Plattform die vollständige Kontrolle über den ein- und ausgehenden Anwendungsdatenverkehr.
Die BIG-IP-Plattform verfügt außerdem über eine ICSA-Labs-Zertifizierung sowohl für Netzwerk- als auch für Webanwendungs-Firewalls. Dabei werden die Trennung des Datenverkehrs und die Plattformsicherheit strengen Tests unterzogen, was zusätzliche Sicherheit für die Plattform gewährleistet.
Alles zusammenführen: F5 und OpenStack
OpenStack und die Anwendungsbereitstellungsdienste und -plattformen von F5 ergänzen sich und stellen produktionsreife Dienste für auf OpenStack gehostete Anwendungen bereit. Innerhalb von OpenStack kann auf zwei Arten auf die Anwendungsbereitstellungsdienste von F5 zugegriffen werden: über Neutron Load Balancing as a Service (LBaaS) Version 2 und über die Heat-Orchestrierung. (F5 unterstützt auch die Integration von LBaaS Version 1 in Neutron, doch die OpenStack-Community hat die API der Version 1 mit der Liberty-Version von OpenStack als veraltet eingestuft.)
LBaaS
Neutron LBaaS stellt grundlegende Lastverteilungsdienste für Compute-Instanzen (und damit für Anwendungsinstanzen) bereit. Diese Dienste sind auf einen zentralen Teil der Funktionen und Merkmale beschränkt, die bei einer Vielzahl von Lastverteilungsplattformen üblich sind.
Das LBaaS-Dienstbereitstellungsmodell abstrahiert die Ressourcen, die den Dienst bereitstellen, von den Diensten selbst. Die Ressourcen zur Bereitstellung der Dienste sind Teil der OpenStack-Infrastruktur und nicht der Ressourcen des OpenStack-Mandanten. Dieses Modell wird gelegentlich als „unter der Cloud“ bezeichnet.
OpenStack LBaaS verwendet eine Reihe logischer Objekte, um eine Lastverteilungskonfiguration zu erstellen.
Das Objektmodell ist in Abbildung 3 dargestellt.
Wie bei allen OpenStack-Vorgängen wird LBaaS über eine RESTful API verwaltet. Über die API können Mandanten REST-Aufrufe ausführen, um LBaaS-Objekte zu erstellen, zu aktualisieren und zu löschen. Zwischen dem API-Aufruf eines Mandanten und einer Konfigurationsänderung auf einer BIG-IP-Instanz liegen dabei mehrere Schritte.
Die Zuordnung zwischen LBaaS-Objekten und den API-Aufrufen, mit denen diese in einer Konfiguration auf einer BIG-IP-Instanz erstellt oder aktualisiert werden, übernimmt der F5 OpenStack LBaaS-Treiber. Der LBaaS-Treiber ermöglicht es einer BIG-IP-Instanz, als Anbieter von Lastausgleichsdiensten innerhalb einer OpenStack-basierten Cloud zu fungieren.
Der F5 LBaaS-Treiber besteht eigentlich aus zwei separaten Komponenten:
- Das F5-LBaaS-Plug-in, das auf einem Server installiert wird, auf dem der Neutron-API-Dienst ausgeführt wird
- Der F5-LBaaS-Agent-Prozess (einschließlich des Treibers), der auf dem Host installiert wird, auf dem der Agent-Prozess ausgeführt werden soll. Jede Geräteservicegruppe (eine Sammlung von BIG-IP-Geräten in einem Cluster) benötigt einen separaten Agent-Prozess.
Der LBaaS-Treiber empfängt Aufgaben, die sich aus den vom Mandanten ausgeführten LBaaS-API-Aufrufen ergeben, und übersetzt sie in F5-iControl®-API-Aufrufe, um Konfigurationsobjekte auf dem BIG-IP-Gerät oder der virtuellen Edition zu erstellen oder zu aktualisieren. Wenn Mandanten isolierte Mandantennetzwerke und Netzwerk-Overlay-Tunnel oder VLANs verwenden, ermöglicht der LBaaS-Treiber die Bereitstellung von Diensten für mehrere Mandanten über eine einzelne BIG-IP-Instanz oder eine Hochverfügbarkeitskonfiguration (HA). Das F5-LBaaS-Plug-in erstellt die erforderlichen API-Aufrufe an die BIG-IP-Instanz und an Nova, um sicherzustellen, dass der Mandantendatenverkehr an das mandantenisolierte Listener-Objekt (in der BIG-IP-Terminologie VIP) auf der gemeinsam genutzten BIG-IP-Instanz weitergeleitet wird.
Mandantenisolierung
In mandantenfähigen Umgebungen besteht eine zentrale Aufgabe von Nova darin, sicherzustellen, dass die Mandanten voneinander isoliert sind. Die BIG-IP-LBaaS-Komponenten nutzen verschiedene BIG-IP-Funktionen für die Mandantenfähigkeit, um den Datenverkehr der Mandanten voneinander zu trennen.
Weitere Einzelheiten dazu, wie und wann diese Mandantenfähigkeitsfunktionen verwendet werden, finden Sie in der README-Datei für F5 OpenStack LBaaS Driver and Agent.
LBaaS bietet ein einfaches, API-gesteuertes System zur Bereitstellung von Lastverteilungsdiensten innerhalb von OpenStack und ermöglicht so eine grundlegende Lastverteilung für eine große Anzahl von Clients. Die API stellt jedoch nur einen Teil der Funktionen eines umfassenden Application Delivery Controllers (ADC) bereit. Diese Tabelle vergleicht LBaaS und native BIG-IP-Dienste anhand einiger wichtiger Eigenschaften der Anwendungsbereitstellung, darunter Protokollunterstützung, zusätzliche Dienste und Systemzustandsmonitore.
Wenn die erweiterten Funktionen eines vollwertigen Proxys auf Anwendungsebene erforderlich sind, lassen sich durch die Bereitstellung von F5 Application Delivery Services mithilfe des OpenStack Heat-Orchestrierungsdienstes und der zugehörigen Vorlagen eine einfache, automatisierte Diensterstellung mit komplexeren Dienstkonfigurationen kombinieren.
Heat-Orchestrierungsdienst und Vorlagen
OpenStack Heat ist ein Orchestrierungsdienst, der auf Grundlage von Vorlagen lauffähige Anwendungen erzeugt. Die Heat-Vorlage beschreibt die Infrastruktur in einer oder mehreren Textdateien, und der Heat-Dienst führt die entsprechenden API-Aufrufe aus, um die erforderlichen Komponenten zu erstellen. Der Heat-Dienst kann mithilfe benutzerdefinierter Plug-ins über die Kernmodule hinaus erweitert werden.
Das F5 Heat-Plug-in ermöglicht es, mit Heat-Vorlagen erweiterte Konfigurationen für die Anwendungsbereitstellung auf jedem BIG-IP-Gerät oder jeder virtuellen Edition zu erstellen, das bzw. die über das Netzwerk von dem Server aus erreichbar ist, auf dem der Heat-Dienst ausgeführt wird. Die BIG-IP-Instanz benötigt außerdem Konnektivität und Routing zu den Mandanteninstanzen, da diese Konnektivität nicht vom Heat-Plug-in konfiguriert wird.
Heat-Vorlagen verwenden die einfache Auszeichnungssprache YAML, die so konzipiert ist, dass sie für Menschen lesbar und leicht zu handhaben ist. Heat-Vorlagen sind deklarativ. Das bedeutet, dass Sie lediglich die gewünschten Infrastrukturkomponenten definieren und sich darauf verlassen, dass die zugrunde liegenden Anbieter die von Ihnen festgelegte Konfiguration erstellen.
Heat-Vorlagen ermöglichen die Erstellung anspruchsvollerer Szenarien für die Anwendungsbereitstellung, insbesondere in Kombination mit dem F5 iApps®-Vorlagensystem. Mit iApps-Vorlagen lassen sich Konfigurationen für die Anwendungsbereitstellung wiederholt erstellen, indem einfach die erforderliche Vorlage und die instanzspezifischen Werte übergeben werden. Komplexe Bereitstellungskonfigurationen mit erweiterten Funktionen wie Web Application Firewall-Diensten, Anwendungsbeschleunigung und fortschrittlichen Lastausgleichsalgorithmen können mit einfachen API-Aufrufen implementiert werden.
Heat-Vorlagen funktionieren sowohl mit Instanzen virtueller BIG-IP-Editionen innerhalb der Netzwerkumgebung des jeweiligen Mandanten („über die Cloud“) als auch mit BIG-IP-Appliances, die im zugrunde liegenden physischen Netzwerk bereitgestellt werden. Das BIG-IP-Gerät muss nicht an Neutron-Netzwerk-API-Aufrufen beteiligt sein, da es innerhalb des Mandanten wie jeder andere Compute-Knoten behandelt wird.
Das F5 Heat-Plug-in ist im F5 Github-Repository verfügbar. Dieses Repository enthält sowohl das Heat-Plug-in, das auf dem Server installiert wird, auf dem die Heat-Engine ausgeführt wird, als auch Beispiel-Heat-Vorlagen.
Flexible Plattformoptionen
Die Anwendungsbereitstellungsdienste von F5 sind auf verschiedenen Plattformen verfügbar, die alle dieselben Funktionen zur Anwendungsbereitstellung bieten, da sie auf demselben Kernbetriebssystem und F5-Mikrokernel basieren.
F5 Appliances und F5 VIPRION® Chassis
F5-Hardwareplattformen bieten hohe Leistung und enorme Skalierbarkeit für Umgebungen, die eine große Anzahl von Clients oder Mandanten unterstützen oder Anwendungsfälle mit hohem Durchsatz bewältigen müssen. Ein einzelnes HA-Paar kann viele Hundert Mandanten und Millionen von Clients bedienen. F5-Hardwaregeräte bieten Service Level Agreements (SLAs) für die Verbindungsrate und entlasten die zugrunde liegende Computing-Umgebung erheblich, indem sie spezialisierte Hardware für die SSL- und TCP-Verarbeitung einsetzen. Wenn Netzwerksicherheitsdienste und die Abwehr von Distributed-Denial-of-Service-Angriffen (DDoS) erforderlich sind, bieten F5-Hardwareplattformen hervorragende Leistung und ein hohes Schutzniveau. Durch die Unterstützung mehrerer sich überschneidender Adressräume und Netzwerk-Overlay-Protokolle können Hardwaregeräte in den meisten mandantenfähigen Umgebungen eingesetzt werden.
Virtuelle Editionen von F5 BIG-IP
Virtuelle Editionen von F5 BIG-IP sind für die meisten Hypervisoren (einschließlich KVM) sowie für die Nutzung bei Public-Cloud-Anbietern von Infrastructure as a Service (IaaS) wie Amazon AWS und Microsoft Azure verfügbar. Virtuelle Editionen (VEs) von BIG-IP sind außerdem mit unterschiedlichen Kapazitäten erhältlich – von einer Lab-Edition bis hin zu produktionsreifen Versionen mit bedarfsgerechten Upgrades für Durchsatzraten von 25 Mbit/s bis 10 Gbit/s. Volumenlizenzen und flexible Lizenzpools ermöglichen ein dynamisches Lebenszyklusmanagement von BIG-IP-Instanzen in Test- und Entwicklungsumgebungen. In Public-Cloud-Umgebungen ist zudem eine nutzungsabhängige Abrechnung verfügbar. Virtuelle Editionen von BIG-IP bieten dieselben Anwendungsbereitstellungsdienste wie die Hardwareplattformen, verfügen jedoch nicht über die spezialisierte Hardware und Skalierbarkeit der Appliances.
Virtuelle BIG-IP-Editionen können vollständig innerhalb eines Mandantennetzwerks betrieben werden. Da OpenStack sie lediglich als weitere Compute-Instanz betrachtet, werden sie mithilfe von Heat-Vorlagen konfiguriert oder können als Anbieter für LBaaS eingesetzt werden.
1Ausführliche Informationen finden Sie im Integrationsleitfaden für F5 und OpenStack.
Da das F5-LBaaS-Plug-in mehrere F5-Agent- und -Treiberinstanzen unterstützen kann, ist es möglich, Hardwaregeräte und virtuelle BIG-IP-Editionen innerhalb derselben LBaaS-Konfiguration zu kombinieren.
Wie bei allen Architekturentscheidungen ist die richtige Option diejenige, die den individuellen Anforderungen der Lösung am besten entspricht. Leistungsstarke, skalierbare Lösungen können mit BIG-IP Hardware oder virtuellen Editionen realisiert werden. Die Gesamtanforderungen an Skalierbarkeit und Dienste sollten Infrastrukturarchitekten bei der Entscheidung für Hardware, Software oder eine Kombination aus beidem unterstützen. Für einen Kunden oder Mandanten, der lediglich Dienste bereitstellen möchte, ist die Wahl zwischen LBaaS und Heat wichtiger als die Bereitstellungsplattform selbst.
Hochverfügbarkeit
Hochverfügbarkeit ist für geschäftskritische Netzwerk- und Anwendungsstacks von entscheidender Bedeutung. Erwartungsgemäß verfügt die BIG-IP Plattform über eine robuste Hochverfügbarkeitsarchitektur. BIG-IP Geräte und virtuelle Editionen können als eigenständige Geräte (beispielsweise für Test- und Entwicklungsumgebungen), als hochverfügbare Paare oder in aktiven N-Wege-Gerätegruppen mit bis zu vier Geräten bereitgestellt werden. Alle diese Bereitstellungsarten werden auf OpenStack-Plattformen unterstützt.
Skalierbarkeit
Die Möglichkeit, die Kapazität von LBaaS- oder mandantenspezifischen BIG-IP-Ressourcen zu erweitern, versetzt Administratoren oder Mandanten in die Lage, einen Anstieg des Anwendungsdurchsatzes oder der Mandantenzahl zu bewältigen. Eine vertikale oder horizontale Skalierung ohne Unterbrechung der Dienste ist für den Aufbau einer agilen und skalierbaren Cloud unerlässlich.
Die BIG-IP Plattform kann sowohl vertikal als auch horizontal skaliert werden: Appliances und virtuelle Editionen lassen sich durch Lizenz-Upgrades vertikal skalieren, während das VIPRION-Chassis durch das Hinzufügen weiterer Hardware-Blades vertikal skaliert werden kann. Das BIG-IP LBaaS-Plug-in verwaltet mehrere Agents und Treiber (die jeweils eine einzelne BIG-IP Instanz oder einen einzelnen Cluster verwalten) und ermöglicht so eine horizontale Skalierung. Wenn mehrere Agents verwendet werden, weist das F5 LBaaS-Plug-in standardmäßig alle LBaaS-Load-Balancer-Objekte eines bestimmten Mandanten einem BIG-IP Gerät (oder Cluster) zu.
Bei der Verwendung von BIP-IP-VE-Instanzen innerhalb eines Mandanten können die Instanzen durch eine Lizenz erneut hochskaliert oder zusätzliche Instanzen hinzugefügt werden, um neue Workloads abzudecken.
Fazit
Da OpenStack-Bereitstellungen zunehmend geschäftskritische Produktionsanwendungen hosten, wächst der Bedarf an robusten, hochwertigen Application-Delivery-Diensten innerhalb von OpenStack. Die Application-Delivery-Dienste von F5 bieten die Kapazität, Sicherheit und erweiterten Funktionen, die diese kritischen Anwendungen benötigen, kombiniert mit der Agilität und dem geringen Betriebsaufwand einer OpenStack-basierten Cloud.
VERÖFFENTLICHT AM 19. APRIL 2016