Fujitsu K5 Technology Shared Service Design Pattern – Hochverfügbar

2017-01-13

Machine-translated — the English original is authoritative.

Das folgende Design Pattern ist ein Beispiel dafür, wie eine Technologie-Shared-Service-Plattform auf K5 implementiert werden könnte. Der Unterschied zwischen dieser Architektur und dem vorherigen Blogbeitrag zu Shared Services besteht darin, dass ich unsere Inter-Availability-Zone-Connectors eingebunden habe, um eine interne Hochgeschwindigkeitsverbindung zwischen den Subnetzen in den verschiedenen Availability Zones (AZs) bereitzustellen. Es ist nun möglich, sicherzustellen, dass Ihre traditionell gestalteten Anwendungen oder Cloud-Native-Apps problemlos über die beiden AZs verteilt werden können. Der Netzwerkverkehr durchläuft nicht das Internet. Die gesamte unten gezeigte Architektur kann dank HEAT-Stacks, dem Infrastruktur-Orchestrierungsprojekt von K5/OpenStack, mit minimalem Aufwand automatisch bereitgestellt werden.

Hinweis für Native OpenStack-Benutzer : Sowohl die InterProject- als auch die InterAvailability-Zone-Verbindungen, die hier diskutiert werden, sind Erweiterungen, die Fujitsu an der OpenStack Neutron API vorgenommen hat, um sie in der Public Cloud zu nutzen.

DMZ

Das DMZ-Projekt wird verwendet, um Datenverkehr in die Lösung hinein und aus ihr heraus zu routen. Ein Proxy-Server könnte verwendet werden, um den Zugriff auf das Internet für die anderen Projekte bereitzustellen/zu steuern. Ein HTTPS-Terminalserver wie Guacamole könnte in jeder DMZ installiert werden, um einen redundanten Zugriff auf die Server-Konsolen bereitzustellen.

In jeder AZ sind zwei virtuelle Router installiert. Einer verwaltet das gesamte inter-project-Routing und der zweite wird in Verbindung mit FWaaS verwendet, um den Zugriff an der Internet-Grenze zu steuern. Eine optionale, öffentlich zugängliche LBaaS-Instanz könnte hier verwendet werden, um HA für den Guacamole-Dienst bereitzustellen.

Shared Services

Dieses Projekt würde verwendet werden, um alle Shared Services zu hosten, die Sie Ihren anderen Projekten bereitstellen möchten, wie z. B. E-Mail (vergessen Sie nicht, dass K5 dies auch als PaaS-Angebot anbietet), Dateifreigabe, Git-Repos usw. Ein Netzwerk-Connector wird verwendet, um die Shared-Services-Subnetze zwischen den Availability Zones zu verbinden, was eine schnelle Synchronisierung von Daten zwischen kritischen Diensten ermöglicht. Ein intern zugänglicher LBaaS könnte hier ebenfalls verwendet werden, falls erforderlich. Aus Designgründen verfügen diese Subnetze weder über DNAT- noch über SNAT-Fähigkeiten. Es wäre notwendig, einen Proxy-Dienst in der DMZ (nicht Teil von K5) zu nutzen, um dies zu erreichen. Die Alternative wäre, dieses Subnetz direkt über einen weiteren virtuellen Router mit dem Internet zu verbinden, wodurch das erforderliche Modell durchbrochen würde 🙂

Abteilung A/B/C…usw.

Dies sind die Projekte, die die Endbenutzer konsumieren würden. Sie können dieselben HA-Funktionen nutzen, die im Shared-Services-Projekt verfügbar sind. Dieses Modell ermöglicht eine schnelle und einfache Bereitstellung, Zerstörung und Wiederbereitstellung, um Anforderungen zu erfüllen, während die Kernservices intakt bleiben.

Sicherheitsgruppen werden durchgängig verwendet, um eine zusätzliche Ebene der Netzwerksicherheit für alle Hosts bereitzustellen.

Zusammenfassung

Das vollständige Shared-Services-Modell kann schnell und konsistent wiederholt mit K5s Infrastructure as Code (IaC) HEAT-Vorlagen bereitgestellt werden. Immer mehr Kunden nutzen Modelle wie dieses, um sie auf ihren Continuous Integration und Continuous Deployment (CI/CD)-Reisen zu unterstützen. Wenn Sie daran interessiert sind, empfehle ich Ihnen, sich auch mit Cloud Foundry für die schnelle Anwendungsentwicklung zu beschäftigen – K5 bietet ebenfalls eine Cloud Foundry-Plattform an.

Happy Stacking.

withk5youcan

Originally published on allthingscloud.eu (2017-01-13).