Referenzarchitektur: Microservices-basierte Anwendungsbereitstellung mit Citrix und Red Hat OpenShift

Übersicht

CompanyA hat immer monolithische Architekturen verwendet, um Systemanwendungen zu entwickeln, die überwiegend vor on-premises gehostet werden. Sie litten unter Problemen mit der Betriebszeit und inkonsistenter Leistung, insbesondere für Remote-Benutzer, die sich während der Pandemie verschärften. Im Rahmen ihrer Bemühungen, in die Cloud umzusteigen, beabsichtigen sie, eine Microservices-Architektur zu verwenden. Diese Architektur ermöglicht es ihnen, neue Anwendungen mit größerer Ausfallsicherheit und Skalierbarkeit zu entwickeln.

CompanyA entschied sich für den Aufbau eines Paares redundanter Multi-Cloud-Red Hat OpenShift (RHOS) -Cluster. Sie werden in Microsoft Azure und Amazon AWS gehostet, wobei Citrix den Lastenausgleich für Microservice-Instanzen bereitstellt. Auf diese Weise können sie eine belastbare Umgebung bereitstellen, in der Remote-Benutzer mit konstant guter Leistung auf wichtige Unternehmenswebdienste zugreifen können.

Diese Referenzarchitektur erklärt, wie CompanyA seine Umgebung plant, um eine Cloud-native Plattform zu hosten, um neue Anwendungen zu entwickeln oder ältere zu migrieren.

Einführung

Unternehmen A entschied sich, seine cloudnative Microservices-basierte Anwendungsbereitstellung mit Citrix und RHOS zu entwickeln, um seinem Unternehmen mehrere Vorteile zu bieten und letztendlich die Produktivität zu steigern.

Cloud-Nativ

Cloud-native Anwendungen wurden entwickelt, um die verteilte und skalierbare Natur der Cloud zu nutzen. Es beinhaltet viele Vorteile in Bezug auf Unternehmensproduktivität, betriebliche Effizienz und Benutzererfahrung.

Vorteile von Cloud-Native

  • Containerisierte Anwendungen sind zwischen Host-Infrastrukturen portierbar
  • Ermöglicht agile, kontinuierliche Entwicklung und Bereitstellung
  • Skaliert mit Cloud-Host-Infrastrukturen
  • Unterstützt einen effizienten Softwareentwicklungsprozess

Red Hat OpenShift

Red Hat OpenShift ist eine Kubernetes-Containerplattform für Unternehmen, die Unternehmen dabei unterstützt, Microservice-Anwendungen in Hybrid Clouds bereitzustellen, zu betreiben und zu sichern.

Vorteile von Red Hat OpenShift (RHOS)

  • Verwaltet effizient Cloud-native Kubernetes-Umgebungen für die Entwicklung und den Betrieb geschäftskritischer Unternehmensanwendungen
  • Verbessert die Produktivität von Entwicklungsteams
  • Steigert den Umsatz durch die zeitnahe Einführung neuer Services für Bestandskunden
  • Reduziert die Betriebskosten durch weniger Zeitaufwand für Verwaltung und Support

Weitere Informationen finden Sie unter Was ist Red Hat OpenShift?

Citrix

Citrix bietet flexible Topologien für das Verkehrsmanagement in Microservices-Umgebungen, abhängig von den Anforderungen, einschließlich Full Mesh, ServiceMesh Lite, Single-Tier und Dual-Tier.

Topologien:

  • Full Mesh — Full-Mesh-Cluster unterstützen verschiedene Microservices, die eine Ost-West-Kommunikation zwischen Microservices innerhalb des Clusters und Nord-Süd-Kommunikation (N-S) außerhalb des Clusters benötigen.
  • Service Mesh Lite — eine Ingress-Lösung führt in der Regel L7-Proxy-Funktionen für den Nord-Süd-Verkehr aus. Die Service Mesh Lite-Architektur verwendet dieselbe Ingress-Lösung, um den Ost-West-Verkehr (E-W) zu verwalten und die Einschränkungen des in Kubernetes integrierten Dienstes zu überwinden.
  • Ein-Tier — einstufige Cluster enthalten Microservices, die als redundante Replikate ausgeführt werden und über Nord-Süd-Datenverkehr verfügen, der von externen Load Balancern bereitgestellt wird.
  • Dual-Tier — Dual-Tier-Architekturen haben auch Nord-Süd-Verkehr, der von externen Load Balancern bereitgestellt wird. Microservices verfügen jedoch auch über eine Netzwerkkomponente, die die Kommunikation mithilfe zusätzlicher Netzwerkprotokolle und Optimierungen unterstützt, die nicht von nativen Clusterdiensten bereitgestellt werden.

Weitere Informationen finden Sie unter: So beschleunigen Sie Ihren Weg zu Microservice-basierten Anwendungen

Vorteile von Citrix Ingress Controller (CIC)

  • Standard-Kubernetes Ingress-Lösungen bieten Load Balancing nur auf Layer 7 (HTTP- oder HTTPS-Verkehr), während der CIC auch TCP-, TCP-SSL- und UDP-Verkehr unterstützt
  • Das CIC funktioniert nahtlos über mehrere Clouds oder on-premises Rechenzentren hinweg

Vorteile von Citrix ADC VPX

  • Citrix ADC VPX bietet Traffic-Management-Richtlinien für Unternehmen wie Rewrite- und Responder-Richtlinien für einen effizienten Lastausgleich des Datenverkehrs auf Layer 7, den Kubernetes nicht bietet
  • Citrix ADC VPX unterstützt auch Global Server Load Balancing (GSLB)

Vorteile von Citrix CPX

  • Mit Citrix CPX kann ein Citrix ADC als Datenebenen-Proxy entweder als Ingress-Gateway oder Sidecar im XDS-basierten Service Mesh bereitgestellt werden.
  • Es bietet Layer-7-Verkehrsmanagement zwischen Microservices innerhalb des Kubernetes-Clusters, wohingegen Kubernetes nur Layer 4 unterstützt.

Weitere Informationen finden Sie in den Citrix Developer Docs

Erfolgskriterien

Unternehmen A hat eine Liste von Erfolgskriterien definiert, die die Grundlage für das übergreifende Design bildeten.

Hinweis: Unternehmen A stellt einen Apache-Webdienst in einem Produktionspilotprojekt zur Remote-Benutzervalidierung bereit.

Erfolgskriterien

Konzeptarchitektur

Basierend auf den vorherigen Anforderungen hat CompanyA die folgende konzeptionelle Architektur auf hoher Ebene erstellt. Diese Architektur erfüllt alle anfänglichen Anforderungen und gibt CompanyA gleichzeitig die Grundlage, um in Zukunft auf weitere Anwendungsfälle zu expandieren.

Konzeptarchitektur

Das Architektur-Framework ist in mehrere Layer unterteilt. Das Framework bietet eine Grundlage für das Verständnis der technischen Architektur der Microservices-Infrastruktur. Alle Ebenen fließen zusammen, um eine vollständige End-to-End-Lösung zu schaffen.

Auf hohem Niveau:

Benutzerebene: Die Benutzerebene beschreibt die Endbenutzerumgebung und Endpunktgeräte, die für die Verbindung mit Ressourcen verwendet werden.

Benutzer können sich mit der Citrix Workspace-App sicher mit dem Webdienst verbinden. Alternativ können Benutzer mithilfe eines Standardbrowsers mit HTTP/HTTPS-Transport eine Verbindung zum Webservice herstellen.

Zugriffsebene: Die Zugriffsebene beschreibt, wie Benutzer auf Webdienste zugreifen und Nord-Süd-Ströme bereitgestellt werden.

  • Der primäre FQDN des Webdienstes wird in Nameserver aufgelöst, die auf dem Citrix ADC VPX gehostet werden.
  • Citrix ADC VPXes, auf denen GSLB ausgeführt wird, antworten auf DNS (Domain Name Service) -Abfragen mit einer öffentlichen IP-Adresse des Content Switch Virtual Servers mit den wenigsten Verbindungen.
  • Der virtuelle Server wird vom Citrix Ingress Controller konfiguriert, um Verbindungen an den Cluster weiterzuleiten, der mit den wenigsten Verbindungen gehosteten Citrix CPX gehostet wird.
  • Das Cluster-gehostete Citrix CPX akzeptiert die Verbindungen und reagiert auf den Citrix ADC VPX. Es stellt einen Fluss zum Webdienst her, über den die Nutzlast geliefert wird.

Ressourcenebene: Die Ressourcenebene gibt die Anwendungen an, die Benutzern in Form von Microservices in dieser Referenzarchitektur bereitgestellt werden.

  • Vier Apache Webservices werden als RHOS Pods gehostet. Sie werden über den RHOS Operator Hub bereitgestellt.

Steuerungsebene: Die Steuerungsebene definiert, wie die Ressourcen verwaltet und überwacht werden.

  • Red Hat OpenShift wird verwendet, um den Cluster zu erstellen und die Microservice-Ressourcen bereitzustellen, zu verwalten und zu überwachen.

Hostingebene: Die Hostingebene definiert die zugrunde liegende Infrastruktur, die die Ressourcen hostet, einschließlich Speicher, Speicher und Rechenleistung.

  • Microsoft Azure und Amazon AWS sind die öffentlichen IaaS, die zum Hosten des RHOS-Clusters und der Microservices verwendet werden.

In den nächsten Abschnitten werden spezifische Entwurfsentscheidungen für die Microservices-basierte Anwendungsbereitstellung von CompanyAs mit Citrix und Red Hat OpenShift näher erläutert.

Benutzerebene

Die Benutzerebene ist der Ort, an dem Benutzer Zielressourcen auf unterstützten Endpunkten anfordern und darauf zugreifen.

Benutzerebene

Benutzer können sich mit der Citrix Workspace-App sicher mit dem Webdienst verbinden.

  • Citrix Workspace — der Webdienst wird als Anwendung in Citrix Workspace veröffentlicht. Die auf dem Endpunkt des Benutzers installierte Citrix Workspace App startet eine Proxyverbindung zur veröffentlichten Anwendung in Citrix Cloud.
  • Citrix Secure Internet Access — Die Verbindung zum in der Cloud gehosteten Citrix ADC VPX wird von Citrix Secure Internet Access zur vollständigen Stack-Inspektion, einschließlich SWG, DLP, CASB und NGFW,
  • Citrix Webanwendung und API-Schutz — Die Verbindung zum in der Cloud gehosteten Citrix ADC VPX wird durch Firewallsignaturen der Citrix Web Application und API Protection Web Application Web Application Web Application und API Protection überprüft.

Zugriffsebene

In der Zugriffsebene werden Netzwerkbereitstellungskomponenten gehostet, um Benutzersitzungsanfragen zu koordinieren und an die Control- und Resource-Komponenten weiterzuleiten.

Übersicht

Citrix CPX

CompanyA entschied sich, eine 2-Tier-Architektur zu implementieren und die Citrix CPX zu verwenden, um die Bereitstellung des Servicedatenverkehrs innerhalb des Clusters zu verwalten. Der CPX empfängt Benutzerverkehrsanforderungen von der in der Cloud gehosteten Citrix ADC VPX und gleicht die Verkehrslast zwischen Microservice-Instanzen aus. Das Citrix CPX wird vom Clusteradministrator über die YAML-Dateikonfiguration mithilfe von RHOS-Steuerelementen bereitgestellt. Das Citrix CPX wird sowohl in den AWS- als auch in den Azure-Clustern auf dieselbe Weise bereitgestellt.

Citrix Ingress Controller

CompanyA entschied sich, den Citrix Ingress Controller (CIC) zu verwenden, um das Cloud-native Citrix-Netzwerk innerhalb seines RHOS-Clusters zu verwalten. Der Citrix Ingress Controller wird verwendet, um den eingehenden Cluster-Verkehrsfluss zu verwalten. Es verwendet globale Cluster Custom Resource Domains (CRDs), um Citrix CPX und den Dienststatus abzurufen und zu überwachen. Basierend auf diesen Informationen konfiguriert es den Citrix ADC VPX dynamisch für den Lastausgleich und die Weiterleitung des Datenverkehrs an Citrix CPXes innerhalb des Clusters.

Citrix ADC VPX

CompanyA entschied sich, den Citrix ADC VPX zu verwenden, um den Nord-Süd-Verkehrsfluss zu verwalten und Global Server Load Balancing (GSLB) zwischen Azure- und AWS-Clustern zu implementieren.

Der Nord-Süd-Verkehr wird von Citrix ADC VPXes verwaltet, die an den AWS- bzw. Azure-Clusterstandorten gehostet werden. IP-Adressierungsinformationen und Zugriffsgeheimnisse werden im CIC-Setup bereitgestellt, sodass das CIC-Setup Richtlinien für den Lastausgleich und den Content Switching

Der GSLB-Verkehr wird auch von Citrix ADC VPXes verwaltet, die an den AWS- bzw. Azure-Clusterstandorten gehostet werden.

  • DNS für den Apache Microservice wird über den globalen DNS-Service des Unternehmens, AWS Route 53, konfiguriert.
  • CNAME-Datensätze sind den jeweiligen autoritativen DNS (ADNS)-Diensten zugeordnet, die auf Citrix ADC VPXes in Azure bzw. AWS gehostet werden.
    • apacheservice.CompanyA.com
    • apacheservice.AWS.CompanyA.com
    • apacheservice.Azure.CompanyA.com
  • GSLB-Lastenausgleichsmethode — Citrix ADC GSLB unterstützt verschiedene Load Balancing-Methoden. CompanyA hat beschlossen, die Canary-Methode in erster Linie zu verwenden, um eine hohe Verfügbarkeit mit ihrem kontinuierlichen Entwicklungszyklus zu unterstützen. Methoden-Optionen:
    • Lokal zuerst: Wenn eine Anwendung in einer lokalen Erstbereitstellung mit einer anderen Anwendung kommunizieren möchte, bevorzugt sie eine lokale Anwendung im selben Cluster. Wenn die Anwendung lokal nicht verfügbar ist, wird die Anfrage an andere Cluster oder Regionen gerichtet
    • Canary: Canary Release ist eine Technik, um das Risiko der Einführung einer neuen Softwareversion in der Produktion zu verringern, indem die Änderung zunächst für eine kleine Untergruppe von Benutzern eingeführt wird. In dieser Lösung kann die Canary-Bereitstellung verwendet werden, wenn Sie neue Versionen der Anwendung in ausgewählten Clustern ausrollen möchten, bevor Sie sie in die Produktion verschieben.
    • Failover: Eine Failover-Bereitstellung wird verwendet, um Anwendungen in einer aktiven/passiven Konfiguration bereitzustellen, wenn sie nicht im Aktiv/Aktiv-Modus bereitgestellt werden können
    • Roundtrip-Zeit (RTT): In einer RTT-Bereitstellung wird der Echtzeitstatus des Netzwerks überwacht und leitet die Kundenanfrage dynamisch an das Rechenzentrum mit dem niedrigsten RTT-Wert weiter
    • Statische Nähe: In einer statischen Proximity-Bereitstellung wird eine auf IP-Adressen basierende statische Proximity-Datenbank verwendet, um die Nähe zwischen dem lokalen DNS-Server des Clients und den GSLB-Sites zu bestimmen. Die Anfragen werden an die Site gesendet, die den Nachbarschaftskriterien am besten entspricht
    • Roundrobin: In einer Round-Robin-Bereitstellung rotiert das GSLB-Gerät kontinuierlich eine Liste der an es gebundenen Dienste. Wenn er eine Anfrage erhält, weist er die Verbindung dem ersten Dienst in der Liste zu und verschiebt diesen Dienst dann an das Ende der Liste.
  • GSLB-Dienste — Der Citrix ADC VPX überwacht und verwaltet an jedem Standort die Verkehrsverteilung an die Citrix CPX-Instanzen, die in den jeweiligen Clustern gehostet werden.

Weitere Informationen finden Sie unter Multi-Cluster-Ingress- und Load-Balancing-Lösung mit dem Citrix Ingress Controller

Ressourcenebene

Zu den Ressourcen gehören verschiedene Microservice-Anwendungen, die über den RHOS Operator Hub verfügbar sind und je nach Anforderung intern entwickelt oder über einen Drittanbieter bezogen werden können. CompanyA hat beschlossen, die Apache-Webanwendung bereitzustellen.

Weitere Informationen finden Sie unter Grundlegendes zu RHOS Operator Hub

Steuerungsebene

Die Steuerungsebene umfasst wichtige Verwaltungskomponenten, um die Bereitstellung von Microservices zu koordinieren.

Red Hat OpenShift CompanyA hat sich für die Verwendung von Red Hat OpenShift, Version 4.7, entschieden, um ihren Kubernetes-Cluster bereitzustellen und zu verwalten.

Hostebene

RHOS-Cluster werden auf verschiedenen Hosting-Plattformen On-Premises, Cloud oder Hybrid Cloud unterstützt.

Azure

CompanyA hat beschlossen, eine ihrer RHOS-Umgebungen in einem Microsoft Azure-Mandanten zu hosten. Der RHOS-Cluster verwendete die Azure CLI, um den Cluster zu erstellen.

Die wichtigsten Anforderungen:

  • Azure Red Hat OpenShift benötigt mindestens 40 Kerne, um einen OpenShift-Cluster zu erstellen und auszuführen
  • Ein Azure Red Hat OpenShift-Cluster besteht aus 3 Masterknoten und drei oder mehr Worker-Knoten.
  • Azure CLI Version 2.6.0 oder höher

Weitere Informationen finden Sie unter Azure Openshift-Cluster

AWS

CompanyA hat beschlossen, eine zweite RHOS-Umgebung in einem AWS-Mandanten zu hosten. Der RHOS-Cluster verwendete den AWS-Schnellstartprozess, um den Cluster zu erstellen.

Die wichtigsten Anforderungen:

  • Für den Schnellstart-Prozess ist ein Red Hat-Abonnement erforderlich. Der Mandant muss die Bereitstellung der Amazon EC2 M4.xlarge-Instanz zulassen
  • Red Hat Berechtigungslimits und AWS-Instanzlimits wurden festgelegt, um die Bereitstellung von 3 Master-Instanzen und 3 Worker-Knoten zu unterstützen

Weitere Informationen finden Sie unter Red Hat OpenShift on AWS — Referenzbereitstellung

Referenzen

Viele Dokumentlinks sind verfügbar, um die Cloud-nativen Netzwerkkonzepte von Citrix, Kubernetes-Microservices und die Red Hat OpenShift-Plattform besser zu verstehen.

Links zu passenden Red Hat Referenzen finden Sie hier:

Links zu relevanten Citrix-Referenzen finden Sie hier:

Anhang

Terminologie

Hier finden Sie Beschreibungen gängiger RHOS- und Microservice-Terminologie. RHOS-Referenzen

Referenzarchitektur: Microservices-basierte Anwendungsbereitstellung mit Citrix und Red Hat OpenShift