Fujitsu K5 Shared Services-Modelle
2016-12-01
Machine-translated — the English original is authoritative.
In der IaaS-Plattform von Fujitsu K5 gibt es viele verschiedene Möglichkeiten, eine Shared-Services-Architektur für Technologien zu implementieren, abhängig von Ihren Anforderungen.
[Update: 09/03/2017] : Bevor wir jedoch fortfahren, lassen Sie mich kurz erklären, was ich mit den folgenden beiden Begriffen – Control Plane und Data Plane – im Kontext von OpenStack und der K5 IaaS-Plattform von Fujitsu meine. Stellen Sie sich vor, Sie werden gebeten, einen neuen Exchange-Service für ein Unternehmen auf K5 aufzubauen. Dieser Service erfordert die folgenden Infrastrukturkomponenten: ein Netzwerk, einen Router, eine Firewall und einen Server zur Hostung der Anwendung.
Control Plane, verwendet von K5-Infrastrukturadministratoren: Um diese Infrastruktur aufzubauen, benötigen Sie Zugriff auf die Control-Plane-Dienste von K5 – die API-Endpunkte, die mit den Keystone-, Neutron- und Nova-Diensten kommunizieren können. Regelmäßige Benutzer des finalen Exchange-Services müssen nicht auf diese Control Plane zugreifen.
Data Plane, verwendet von den Endbenutzern des Services: Sobald die Infrastruktur aufgebaut ist, greifen der Exchange-Administrator und die Endbenutzer über die Data Plane auf den neuen Server/die neuen Dienste zu – im Wesentlichen kommunizieren sie direkt über die virtualisierte Schnittstelle mit dem neuen Server.
K5 Shared Services Model – Ohne Isolation der Control Plane für Benutzer
Das einfachste Design besteht darin, alle Ihre Instanzen in ein einzelnes Projekt zu stellen und Security Groups sowie optional mehrere Subnetze zu verwenden, um eine Isolation der Data Plane oder, korrekter ausgedrückt, eine Traffic-Segmentierung bereitzustellen. Offensichtlich können Sie weiterhin auch die Standard-Authentifizierungsmechanismen des Betriebssystems verwenden, um den Zugriff auf die virtuellen Instanzen selbst zu steuern.
Security Groups
Einer der wichtigsten Komponenten der oben genannten Lösung sind Security Groups. Eine Security Group in OpenStack ist ein Mechanismus zur Steuerung aller ein- und ausgehenden Traffic-Flüsse auf einer Schnittstelle (Port) auf Port-Basis. Eine Security Group kann mehrere Regeln enthalten, die jeweils den IP-Adressbereich, die Protokolle und die Richtung des erlaubten Netzwerkverkehrs definieren. In einem Shared-Service-Modell, in dem Server A und Server B isoliert sein sollen, aber beide mit einem dritten Server C kommunizieren können, bieten Security Groups diese Isolation. Mehrere Security Groups können auch an einer einzelnen Schnittstelle angehängt werden, um den Regelsatz aufzubauen.
Der Nachteil dieses Modells ist jedoch, dass der Administrator des Control-Plane-Projekts Zugriff auf alle Ressourcen hat.
K5 Shared Services Model – Mit Isolation der Data Plane & Control Plane für Benutzer
Wenn Sie eine Isolation auf beiden Schichten, der Control Plane und der Data Plane, für Ihre Ressourcen sicherstellen möchten, kann dies durch die Kombination der oben genannten Architektur mit rollenbasierter Zugriffskontrolle, mehreren Projekten und einer weiteren Funktion von Fujitsu K5, dem Inter-Project Routing, erreicht werden.
Rollenbasierte Zugriffskontrolle (RBAC)
Die Fujitsu K5-Plattform nutzt das Keystone-Projekt von OpenStack, um eine rollenbasierte Zugriffskontrolle für Benutzer innerhalb eines Vertrags (oder einer Domain in den nativen OpenStack-Begriffen) bereitzustellen. Sie können Control-Plane-Administratoren projektweise definieren. Dies gibt Ihnen die Möglichkeit, Ihre Ressourcen (virtuelle Maschinen, Netzwerke usw.) auf mehrere Projekte zu verteilen und zu definieren, welche Benutzer administrativen Zugriff auf diese Ressourcen in der Control Plane haben.
Inter-Project Routing
Der Titel gibt hier den Hinweis: Diese Funktion von K5 ermöglicht das Routing zwischen Netzwerken in verschiedenen Projekten innerhalb desselben Vertrags.
Die Kombination all dieser K5-Funktionen ermöglicht es uns, K5-Domain-Administratoren die Fähigkeit zu geben, die Isolation von Ressourcen auf beiden Schichten, der Control Plane und der Data Plane, zu steuern.
Beispielsweise können wir mit dem folgenden Modell einen Benutzer definieren, der die IaaS-Ressourcen in Projekt A verwalten kann, und einen anderen Benutzer, der die Ressourcen in Projekt B verwalten kann. Keiner dieser Administratoren benötigt direkten Zugriff auf die Ressourcen in den Projekten des jeweils anderen oder im Shared-Services-Projekt. Beide können jedoch zu den Diensten routen, die im Shared-Services-Projekt verfügbar sind, vorausgesetzt, die richtigen Security Group-Regeln wurden angewendet.
Die beiden oben genannten Modelle befinden sich innerhalb einer einzelnen K5-Verfügbarkeitszone, aber diese Modelle können auch leicht über die beiden Verfügbarkeitszonen verteilt werden, indem eine weitere K5-Komponente, der Network Connector, verwendet wird.
K5 Network Connector
Der Network Connector hat zwei grundlegende Anwendungsfälle –
- Routing von Netzwerkverkehr von externen Kundennetzwerken direkt in ein K5-Projekt.
- Routing von Netzwerkverkehr zwischen Netzwerken in verschiedenen Verfügbarkeitszonen innerhalb desselben Projekts.
Dieser Connector vermeidet die Notwendigkeit, dass der Netzwerkverkehr der Kunden die Internetverbindung durchlaufen muss, wenn er Verfügbarkeitszonen durchquert.
Das folgende LAMP-Stack-Beispiel veranschaulicht die Verwendung eines Network Connectors mit zwei Verfügbarkeitszonen.
Happy Stacking!
Originally published on allthingscloud.eu (2016-12-01).