Referenzarchitektur: Citrix DaaS — AWS

Zielgruppe und Ziel

Dieses Dokument soll Citrix Partnern und Kunden helfen, die wichtigsten Designentscheidungen zu verstehen, die für die erfolgreiche Bereitstellung von Citrix Virtualisierungstechnologien in der Public Cloud von Amazon erforderlich sind. Sie ist nicht als “How-To” -Referenz gedacht — Citrix berücksichtigt diese Bereitstellungshandbücher und sie werden jetzt getrennt von Referenzarchitekturen bereitgestellt und gewartet. In diesem Dokument verwenden wir das Citrix Architectural Design Framework, um die führenden Praktiken, Empfehlungen und Entwurfsmuster zu organisieren und zu präsentieren, die von Citrix und ausgewählten Citrix Beratungspartnern verwendet werden.

Übersicht und Zusammenfassung

Citrix Virtualisierungs- und Netzwerktechnologien erfüllen seit fast drei Jahrzehnten erfolgreich die Anforderungen großer und kleiner Unternehmen. Es gibt viele Möglichkeiten, wie diese Technologien lizenziert, bereitgestellt, integriert und verwaltet werden können. Diese Flexibilität ermöglicht es Citrix Technologien, verschiedene Anwendungsfälle, Geschäftstypen, Integrationsanforderungen und Betriebsmodelle zu bedienen. Dieses Papier wurde für den Citrix Kunden oder Partner geschrieben, der erwägt oder plant, diese Technologien in der Public Cloud-Infrastruktur von AWS einzusetzen.

Sowohl für Bestandskunden, die ihre Infrastruktur modernisieren möchten, als auch für Neukunden, die Citrix Virtualisierungs- und Netzwerktechnologien einsetzen möchten, gibt es mehrere wichtige Entscheidungen auf hoher und niedriger Ebene, die auf dem Weg getroffen werden müssen, um eine erfolgreiche Bereitstellung zu ermöglichen. Um Kunden und Partnern zu helfen, diese Entscheidungspunkte zu verstehen, haben wir eine spezifische Terminologie eingeführt und definiert, um den geeigneten Kontext festzulegen, und dann diesen Kontext verwendet, um die kritischen Entscheidungen und Implikationen hervorzuheben, die bei der Planung Ihrer Bereitstellung zu berücksichtigen sind.

Wir definieren zunächst zwei Modelle zur Einführung von primären Technologien: Customer Managed und Cloud Services. Anschließend teilen wir die Komponenten eines Citrix-Virtualisierungssystems in mehrere Subsysteme auf und kategorisieren sie nach Übernahmemodell:

Adoptionsmodell/Teilsystemfunktion Kundenverwaltet (installiert aus heruntergeladenen Binärdateien) Clouddienst (bereitgestellt über Citrix Cloud)
Session Brokering und Administration Citrix Virtual Apps and Desktops (CVAD) Citrix DaaS (DaaS)
Dienste der Benutzeroberfläche (UI) Citrix StoreFront Citrix Workspace (der Dienst, der über die Citrix Workspace-App oder den Webbrowser genutzt wird)
Authentifizierung Citrix StoreFront (plus Citrix ADC/Gateway für die meisten Anwendungsfälle) Citrix Workspace (plus Citrix ADC/Gateway für bestimmte Anwendungsfälle)
HDX-Sitzungsproxy Citrix ADC/Gateway Citrix Gateway Service

Wir setzen uns für Clouddiensteein und empfehlen, dass die meisten Unternehmen Clouddienste nutzen oder planen, wo dies möglich ist. Wir bieten diesen Stand nicht blind an - obwohl wir glauben, dass Clouddienste letztendlich unseren Kunden überwältigend positive Vorteile bieten, erkennen wir, dass nicht alle Organisationen/Bereitstellungen heute Clouddienste für alle Subsysteme nutzen können. Manchmal müssen Anwendungsfallanforderungen (mit technischen Attributen oder Unzulänglichkeiten in einem derzeit verfügbaren/spezifischen Clouddienst) eine Kombination aus Clouddiensten und einer vom Kunden verwalteten Komponente übernehmen: Wir konzentrieren uns in diesem Papier auf diese. In anderen Fällen können nichttechnische Punkte (Richtlinien, Budget-/vertragliche Überlegungen, Mängel bei der Cloud-Bereitschaft, Überlegungen zu regulatorischer und Compliance usw.) die Nutzung von Clouddiensten verhindern. In diesen Fällen empfehlen wir, mit Ihrem Citrix Partner/Verkaufs-/Engineering-Team zusammenzuarbeiten, um diese zu überwinden. Mit dem Rest dieses Papiers unternehmen wir große Anstrengungen, um wichtige Funktionen, Merkmale oder Attribute zu identifizieren, die Kunden bei der Entscheidung helfen, welches Adoptionsmodell für welches Subsystem und wann verwendet werden soll.

Als Nächstes definieren und untersuchen wir drei allgemeine Bereitstellungsszenarien, in denen hervorgehoben wird, welches Annahmemodell für jedes Subsystem verwendet wird:

  • NurGreenfield/Cloud** - verwendet Clouddienste für alle Subsysteme von Citrix Virtualisierungssysteme sowie öffentliche AWS-Services.
  • Hybrid (nicht zu verwechseln mit einer “Hybrid Cloud”) - das gebräuchlichste Bereitstellungsmodell. Das Hybridmodell verwendet DaaS für die Sitzungsvermittlung und -verwaltung, wobei sowohl vom Kunden verwaltete als auch Cloud-Service-Optionen für die verbleibenden Subsysteme verwendet werden.
  • Lift and Shift - wie der Name sagt, verwendet dieses Modell vorhandenes, vom Kunden verwaltetes CVAD, StoreFront und ADC/Gateway und migriert diese Komponenten entweder wie sie sind zu AWS oder installiert sie im Rahmen einer Workload-Migration zu AWS Public Services in AWS. Während dies ein gültiges Bereitstellungsmodell für bestimmte Anwendungsfälle ist, kommt es mit erheblichen Vorbehalten.

Schließlich verwenden wir das gut dokumentierte Citrix Architectural Design Framework, um die wichtigsten Designentscheidungen zu organisieren und zu präsentieren, die bei der Bereitstellung von Citrix Virtualisierungstechnologie in AWS berücksichtigt werden müssen. Wir konzentrieren uns auf “was ist anders an Citrix on AWS” für Klarheit und stellen Links zu anderen Ressourcen für detailliertere Informationen bereit, um bei Bedarf detailliertere Informationen zu erhalten.

Wir empfehlen letztendlich, dass die meisten Kunden das Hybrid-Bereitstellungsmodell vom ersten Tag an verwenden und den CVAD-Dienst für die Vermittlung und Verwaltung von Sitzungenverwenden. Dies bietet dem Kunden die wichtigsten Funktionen, die für den kostengünstigen Betrieb eines Citrix Virtualisierungssystems in AWS erforderlich sind, senkt die Kosten und die Komplexität erheblich, bietet Zugriff auf die neuesten verfügbaren Funktionen und Funktionen und vereinfacht die Migration zu und Nutzung anderer Clouddienste in der die Zukunft. Entweder Clouddienste ODER kundenverwaltete Komponenten können für die verbleibenden Subsysteme verwendet werden (abhängig von den spezifischen Bedürfnissen der Kunden), obwohl wir empfehlen, dass Kunden klar sind, warum sie von Kunden verwaltete Komponenten verwenden und planen, in Zukunft zu Clouddiensten zu wechseln erfüllen ihre spezifischen Bedürfnisse.

Für weitere Einblicke in führende Praktiken für Citrix on AWS können Leser auf die folgenden Artikel von Cloud Guidepost verweisen:

Wichtige Konzepte und Einsatzszenarien

In diesem Abschnitt beschreiben wir einige Schlüsselkonzepte und Bereitstellungsszenarien, bevor wir uns mit spezifischen Überlegungen für jede Ebene des Citrix Architectural Design Framework befassen.

Modelle zur Technologieübernahme

Die Citrix DaaS-Technologie kann auf viele verschiedene Arten “genutzt” oder implementiert werden. Die gebräuchlichsten Methoden können allgemein als Customer Managed und Cloud Services bezeichnet werden. Erwähnenswert ist auch ein drittes Modell - Partner Managed. Wir beschreiben dieses Modell hier aus Gründen der Übersichtlichkeit, aber aus Sicht der architektonischen Gestaltung sind die ersten beiden am relevantesten.

Warum diskutieren wir Technologie-Adoptionsmodelle in einer Referenzarchitektur? Die Wahl des Übernahme- oder “Verbrauchsmodells” hat erhebliche Auswirkungen auf das Systemdesign, die Fähigkeiten, die Kosten und die Abgrenzung der Managementverantwortung. In diesem Abschnitt werden diese Modelle definiert und untersucht und einige allgemeine Anleitungen bereitgestellt, die Kunden bei der Entwicklung eines Citrix Virtualisierungssystems fundierte Entscheidungen treffen können.

Vom Kunden verwaltet

Viele Jahre lang hatten Unternehmen, die Technologie nutzen wollten, keine andere Wahl, als den gesamten Technologie-Stack zu kaufen, zu installieren, zu konfigurieren und zu warten, der für den Aufbau eines Citrix Virtualisierungssystems erforderlich ist. Die Virtualisierungssoftware von Citrix war nur als installierbare Binärdateien verfügbar. Kunden, die die Virtualisierungssoftware von Citrix gekauft haben, würden diese Binärdateien herunterladen (häufig in Form eines herunterladbaren ISO-Disk-Images oder selbstextrahierenden ausführbaren Dateien) und installieren, konfigurieren und warten die Software dann selbst. Die Citrix Software (und Netzwerkhardware) wurde am häufigsten in/on Infrastructure installiert, die der Kunde besaß und wartete, in Rechenzentren, die er ebenfalls besaß und wartete.

Konzeptionell gesehen besteht ein Citrix Virtualisierungssystem aus verschiedenen Citrix Komponenten, von denen wir viele in diesem Whitepaper ausführlich beschreiben. Sie erfordern auch verschiedene Ebenen von Komponenten von Drittanbietern, die bereitgestellt werden müssen, bevor Sie irgendetwas mit den Citrix-Teilen tun können. Letztendlich kommen sie alle zusammen, um ein funktionales Citrix Virtualisierungssystem zu schaffen. Aus Gründen der Übersichtlichkeit bezeichnet dieses Dokument dieses Technologie-Einführungsmodell als “Customer Managed”. Wir verwenden diesen Begriff, um verschiedene Komponenten in einem Citrix Virtualisierungssystem zu beschreiben, einschließlich der erforderlichen Komponenten von Drittanbietern, die unter, neben und über den Citrix Komponenten liegen. Dieses Modell kann auch als “Self-Managed” bezeichnet werden.

Heutzutage haben Kunden überzeugende Alternativen zu einem von Kunden verwalteten Akzeptanzmodell, doch einige verwenden immer noch Elemente ihres Technologie-Stacks, die dieses Modell aus verschiedenen Gründen verwenden. Während dieses Modell den Kunden die größte Kontrolle über jede Komponente bietet, sind es mit Kosten verbunden: Der Kunde übernimmt die Verantwortung für die Verwaltung und Wartung der Komponente, einschließlich Sicherung, Betrieb, Patching, Upgraden und Aufrechterhaltung der Hochverfügbarkeit. Dieses Modell wird üblicherweise auch für “Air Gapped-Systeme” eingesetzt (solche ohne Internetzugriff und sind daher in ihrer Fähigkeit, Clouddienste zu nutzen, auf die üblicherweise und sicher über öffentliche Netzwerke zugegriffen wird) beschränkt.

Hier ist ein Beispiel für die Architektur eines Citrix Virtualisierungssystems, das 100% kundenverwaltete Komponenten verwendet, die in AWS unter Verwendung grundlegender AWS IaaS-Services wie Elastic Compute Cloud (EC2) und Virtual Private Cloud (VPC) -Netzwerken bereitgestellt werden. Wir diskutieren einige Details dieser Architektur in späteren Abschnitten dieses Dokuments, obwohl Sie sofort die Ähnlichkeiten mit dem viel einfacheren Greenfield/Cloud-Bereitstellungsmodell feststellen können:

Diagramm 1: 100% vom Kunden verwaltete Lift/Shift-Bereitstellung mit AWS nur als IaaS Diagramm 1: 100% vom Kunden verwaltet, Lift/Shift-Bereitstellung nur mit AWS als IaaS.

Cloudservices

In den letzten 15 Jahren haben technologische Fortschritte in vielen verschiedenen Bereichen zu hypergroßen Public Clouds, anspruchsvollen Clouddiensten, Microservice-Architekturen, DevOps/AGILE Delivery-Frameworks, Abonnementlizenzmodellen und “immergrünen” Software und Systemen geführt. Diese Fortschritte haben die Art und Weise, wie Technologie in fast jeder Branche der Welt erworben, eingeführt, geliefert und gewartet wird, revolutioniert.

Heutzutage stehen viele der Komponenten oder Ebenen, aus denen ein Citrix Virtualisierungssystem besteht, “as a Service” zur Verfügung. Im Gegensatz zum Customer Managed Adoptionsmodell (bei dem Kunden Technologie als Unternehmenswert kaufen und selbst Systeme erstellen/pflegen) “abonnieren” Kunden verschiedene Dienste, und der Dienstleister übernimmt die Verantwortung für die Bereitstellung und Verwaltung dieser Dienste. Diese Dienste werden häufig über öffentliche Netzwerke (dh das Internet) verbraucht, was dazu führt, dass einige dieses “Cloud Service” - oder “Web Service” -Einführungsmodell nennen. In diesem Papier werden wir diese Art von Adoptionsmodell als “Cloud Managed Services” oder einfach als Cloud Service -Modell bezeichnen.

Citrix bietet viele seiner traditionellen Produkte “als Service” an und nutzt die neuesten technologischen Fortschritte seiner Plattformpartner, um die Akzeptanz zu vereinfachen und zu rationalisieren, das Innovationstempo zu beschleunigen, die Qualität zu verbessern und ihren Kunden im Laufe der Zeit einen höheren Mehrwert zu bieten. Citrix nennt diese Plattform für die Servicebereitstellung “Citrix Cloud” und repräsentiert den aktuellen und zukünftigen Stand der Technik von Citrix.

Hier ist ein Beispiel für die Architektur eines Systems, das 100% Clouddienst-Komponenten für ein Citrix Virtualisierungssystem in AWS verwendet. In einem späteren Abschnitt dieses Dokuments besprechen wir die Details dieses Entwurfs:

Diagramm 2: 100% Cloudservices auf AWS mit AWS Managed Services Diagramm 2: 100% Cloudservices auf AWS mit AWS Managed Services

Von Partnern verwaltet

Während sich viele Unternehmen dafür entscheiden, ihr eigenes Citrix Virtualisierungssystem zu entwickeln, versuchen einige Kunden, die IT-Verwaltung auszulagern, damit sie Ressourcen und Aufmerksamkeit auf die Bedienung ihrer eigenen Kunden und Märkte konzentrieren können. Um diese Kunden zu bedienen, arbeitet Citrix mit Integrationspartnern zusammen, die Citrix-Technologien nutzen, um ihren Kunden einen Service für Endprodukte zu bieten.

Die Definition und Differenzierung der verschiedenen verfügbaren Integrationspartner/ -arten und -angebote liegt außerhalb des Anwendungsbereichs dieses Dokuments. Citrix Partner stehen jedoch vor den gleichen Entscheidungen, mit denen Kunden beim Entwerfen eines Citrix Virtualisierungssystems konfrontiert sind. Der Citrix Partner kann sich dafür entscheiden, einen oder mehrere Dienste von Citrix Cloud zu verwenden, oder er kann einige Komponenten des Systems für die spezifischen Anforderungen seiner Kunden erstellen und verwalten. Daher sind die in diesem Dokument enthaltenen Leitlinien sowohl für den Citrix-Partner als auch für seine Kunden relevant, nur aus verschiedenen Gründen.

Komponenten des Citrix Virtualisierungssystems

Um die Auswirkungen der Designentscheidungen zu verstehen, die wir später in diesem Dokument beschreiben, werden wir die Komponenten eines Citrix Virtualisierungssystems in “Buckets” auf höherer Ebene versetzen, die wir dann verwenden werden, um Ihren Entscheidungsprozess zu leiten. Jedes Citrix Virtualisierungssystem, unabhängig davon, wie es bereitgestellt und lizenziert wird, benötigt diese Komponenten, um zu funktionieren und die beste und sicherste Benutzererfahrung zu bieten. Es ist nicht ungewöhnlich, dass Kunden selbstverwaltete Komponenten und Clouddienste kombinieren und abgleichen, insbesondere wenn sie komplexe Anwendungsfallanforderungen, Integrationsanforderungen von Drittanbietern oder extreme Kontroll- oder Verfügbarkeitsanforderungen haben.

In der folgenden Tabelle werden diese wichtigsten Komponenten zur besseren Übersichtlichkeit hervorgehoben. Details und Empfehlungen, wann und wo Sie eine Option gegen eine andere verwenden würden, werden später in diesem Dokument behandelt:

Adoptionsmodell/Teilsystemfunktion Kundenverwaltet (installiert aus heruntergeladenen Binärdateien) Clouddienst (bereitgestellt über Citrix Cloud)
Session Brokering und Administration - Der Kern jedes Citrix Virtualisierungssystems: Ohne dieses Kernsubsystem haben Sie keine Apps oder Desktops und können sie nicht verwalten! In diesem Subsystem definieren, stellen und aktualisieren Sie Maschinenkataloge (Sammlungen von Citrix Virtual Delivery Agent oder “VDA” -VM-Instanzen). Hier erstellen Sie auch Bereitstellungsgruppen, weisen Benutzern Apps/Desktops zu und verwalten die Umgebung und Benutzersitzungen. CVAD - Citrix Virtual Apps and Desktops, entweder Long Term Service Release (LTSR) oder Versionen von Current Release (CR). Wenn Sie einen Delivery Controller in Ihrer Umgebung installieren und konfigurieren, ist dies das, was Sie ausführen. Es bedeutet auch, dass Sie Ihre eigene Microsoft SQL Server-Infrastruktur installieren und verwalten. Zu den administrativen Funktionen in einer vom Kunden verwalteten (CVAD) Bereitstellung gehören Citrix Director und Citrix Studio. Sie installieren, konfigurieren und verwalten diese selbst mit LTSR/CR-Binärdateien. Director benötigt auch Microsoft SQL Server-Infrastruktur. Die Citrix Lizenzierung ist ebenfalls Teil dieses Subsystems, wobei Kunden Citrix Lizenzserver und Lizenzdateien installieren/konfigurieren/verwalten. DaaS — Citrix DaaS, bereitgestellt über Citrix Cloud. Wenn Sie sich bei Citrix Cloud anmelden und Cloud-Connectors in Ihrer Umgebung installieren und registrieren, verwenden Sie diesen Citrix Clouddienst. Sie installieren und registrieren Cloud Connectors auf einer von Ihnen verwalteten Windows-Instanzen, und Citrix hält sie dann immergrün und verfügbar. Citrix Cloud bietet und verwaltet auch die meisten administrativen Funktionen über einen Webbrowser über die Citrix Cloud-Konsole. Dies umfasst Clouddienstversionen von Citrix Studio und Citrix Director. Es gibt keine zusätzliche Infrastruktur, die der Kunde pflegen, hochverfügbar halten oder patchen/aktualisieren kann: Citrix besitzt diese administrative Verantwortung.
UI-Services (Benutzeroberfläche) - Native Citrix Workspace-Apps (und Webbrowser für den clientlosen Zugriff) verbinden sich letztendlich mit einer URL. Das Subsystem hinter der URL wird von IT-Administratoren so konfiguriert, dass es die Unternehmensanforderungen für die Authentifizierung erfüllt und virtualisierte Apps/Desktops, SaaS-Apps und möglicherweise viel mehr für Benutzer zum Zugriff bietet. Citrix Storefront. Diese Rolle wurde ebenfalls aus CVAD LTSR- oder CR-Binärdateien installiert/konfiguriert und bietet extreme Flexibilität für die komplexesten Bereitstellungsszenarien. In der Regel paarweise bereitgestellt, wobei Citrix ADC/Gateway-Instanzen für hohe Verfügbarkeit davor stehen. Kann Apps und Desktops sowohl aus vom Kunden verwalteten/vermittelten Umgebungen (CVAD) als auch aus verwalteten/vermittelten Citrix Cloud-Umgebungen (DaaS) aggregieren und präsentieren. Citrix Workspace (der Dienst, nicht die Citrix Workspace-App). Es wird über Citrix Cloud als Clouddienst bereitgestellt und umfasst viele Funktionen der nächsten Generation, die nur mit diesem Service verfügbar sind. Kann Apps und Desktops sowohl aus vom Kunden verwalteten/vermittelten Umgebungen (CVAD) als auch aus verwalteten/vermittelten Citrix Cloud-Umgebungen (DaaS) aggregieren und präsentieren.
Authentifizierung - In diesem Zusammenhang beziehen wir uns darauf, wie sich Benutzer authentifizieren, bevor sie auf virtualisierte Citrix Apps/Desktops, Dateien, SaaS-Apps und mehr zugreifen. Die Authentifizierung in einer Citrix Umgebung wird in der Regel auf der der UI-Dienstebene konfiguriert, obwohl Citrix ADC/Gateway auch für die Authentifizierung in allen Bereitstellungsmodellen verwendet werden kann. Für jede der UI-Dienstanbieteroptionen (Citrix StoreFront oder Citrix Workspace) stehen verschiedene Authentifizierungsoptionen zur Verfügung, von denen einige ein vom Kunden verwaltetes Citrix ADC/Gateway erforderlich sind. Citrix StoreFront (plus Citrix ADC/Gateway für die meisten Anwendungsfälle). Benutzerauthentifizierungsdienste können auf verschiedene Arten bereitgestellt werden, erfordern jedoch letztendlich eine Active Directory-Instanz und gültige Benutzerkonten. Der Kunde verwaltet in der Regel die AD-Instanz. Citrix ADC/Gateway-Instanzen können auch zur Bereitstellung von Authentifizierungsdiensten verwendet werden und bieten eine Menge erweiterter Funktionen, die üblicherweise für komplexere Umgebungen verwendet werden. Citrix Federated Authentication Services (FAS) kann auch installiert und verwendet werden, um Sitzungs-SSO für komplexe Anwendungsfälle bereitzustellen. Citrix Workspace (plus Citrix ADC/Gateway für bestimmte Anwendungsfälle). Mit Citrix Workspace (dem Dienst) werden die Quellen und Anforderungen der Benutzerauthentifizierung einmalig für den Citrix Cloud-Mandanten konfiguriert und von allen Benutzern verwendet, die diese URL verwenden. Es ist standardmäßig für Active Directory konfiguriert, kann jedoch für erweiterte Anwendungsfälle zur Unterstützung anderer Authentifizierungsanbieter konfiguriert werden. Beispiele hierfür sind Azure AD, Okta, vom Kunden verwaltetes Citrix Gateway, Google Cloud ID oder andere SAML/OpenID/Radius-Anbieter. Einige Szenarien erfordern von Kunden verwaltete Citrix ADC/Gateways und Citrix Federated Authentication Services (FAS) für die beste Benutzererfahrung.
HDX-Sitzungsproxy — Die Möglichkeit, Benutzer/Geräte außerhalb des privaten Unternehmensnetzwerks sicher und nahtlos mit von CVAD/DaaS bereitgestellten Apps und Desktops im Inneren zu verbinden. Citrix ADC/Gateway-Appliances - Diese Appliances (oder Instanzen) bieten häufig eine Menge zusätzlicher Funktionen für ein Citrix Virtualisierungssystem. Ihre Hauptaufgabe besteht jedoch darin, HDX-Sitzungen sicher an Ihre VDAs zu binden, wenn sich Clients in öffentlichen Netzwerken befinden. Erfordert Installation, Konfiguration, SSL-Zertifikate und derartige. Kompatibel mit StoreFront (Customer Managed UI Services) und Workspace Cloud Service. Auch kompatibel mit Citrix verwalteten und vom Kunden verwalteten Session Broker-Optionen. Citrix Gateway Service - Dieser Dienst, der von Citrix Cloud bereitgestellt wird, stellt den HDX-Sitzungsverkehr auf Ihre VDAs aus und verwendet die von Citrix verwaltete Infrastruktur, um die Arbeit zu erledigen. Erfordert keine öffentlichen IP-Adressen, SSL-Zertifikate oder eingehende Firewall-Regeln für den Betrieb. Kompatibel mit dem Citrix Workspace-Dienst und den von Citrix Cloud verwalteten und vom Kunden verwalteten Sitzungsvermittlungsoptionen (CVAD und DaaS).

Führende Praktiken und Empfehlungen

Unabhängig davon, ob Sie das Citrix Virtualisierungssystem selbst verwalten oder Citrix oder einen autorisierten Partner dafür verwenden, sollten Sie nach Möglichkeit die Verwendung von Clouddiensten in Betracht ziehen. Für Anwendungsfallen/Umgebungen, in denen der Clouddienst nicht Ihren Anforderungen entspricht, können von Kunden verwaltete Komponenten verwendet werden. Das heißt, Citrix ermutigt Kunden, sich darüber im Klaren zu sein, warum sie selbstverwaltete Komponenten bereitstellen, und bereit zu sein, zu Clouddiensten zu migrieren, sobald der Clouddienst ihre spezifischen Anforderungen erfüllt. Die von Citrix über Citrix Cloud bereitgestellten Clouddienste entwickeln sich rasant weiter. Im Laufe der Zeit können Sie davon ausgehen, dass sie alle Funktionen bereitstellen, die für alle außer den komplexesten Anwendungsfällen erforderlich sind. Citrix Clouddienste minimieren letztendlich die Menge an Infrastruktur, für die der Kunde für die Verwaltung und Wartung verantwortlich ist. Citrix Cloud bietet auch hochverfügbare, vorintegrierte Services und stellt sicher, dass Kunden immer Zugriff auf die neuesten, sichersten und funktionsreichsten Services haben.

Allgemeine Bereitstellungsmodelle für Citrix Virtualisierung auf AWS

Als Cloud-Anbieter mit der größten Funktionalität, der größten Kundengemeinschaft, unübertroffener Erfahrung und Reife sieht AWS eine Vielzahl von Kunden aus verschiedenen Branchen, die Systeme und Infrastrukturen in ihre Clouds verlagern. Im Laufe der Zeit haben sie gemeinsame Einsatzszenarien/Migrationsmuster entwickelt. In diesem Abschnitt untersuchen wir diese Muster/Szenarien, besprechen, wann und wo Sie möglicherweise in Betracht ziehen sollten, sie zu verwenden, um eine Citrix Virtual Apps and Desktops Desktop-Workload für AWS zu bringen, und geben einige Empfehlungen, welche Muster für allgemeine Migrationsszenarien zu berücksichtigen sind.

Die drei häufigsten Szenarien für die Bereitstellung von Citrix Apps und Desktops in AWS sind:

  • Greenfield/Cloud Only-Bereitstellung unter Verwendung von Citrix Clouddiensten mit “Ressourcenstandorten” im Amazon EC2-Dienst (Amazon Elastic Compute Cloud). Dieses Szenario wird häufig verwendet, wenn Kunden es vorziehen, zu einem Abonnementmodell zu wechseln und die Infrastruktur und Verwaltungsverantwortung für die Steuerungsebene an Citrix auszulagern, oder dass sie die Funktionen von Citrix Clouddiensten erfahren/bewerten möchten.
  • Hybride Bereitstellung/Workload-Migration zu AWS unter Verwendung von Citrix Clouddiensten für die Session Brokering und -verwaltung, Workspace UI oder StoreFront für die Inhaltsaggregation/Sitzungspräsentation/Sitzungsstart und kann auch vom Kunden verwaltetes Citrix ADC/Gateways für HDX-Sitzungsproxy verwenden, komplex Authentifizierungsszenarien oder beides.
  • Heben und verschieben. In diesem Szenario verschieben oder implementieren Kunden ihre selbstverwaltete Citrix Infrastruktur im Wesentlichen in AWS und behandeln die Bereitstellung auf AWS genau wie ihre bestehende, von Kunden verwaltete Bereitstellung. In diesem Szenario verwenden Kunden Citrix ADC/Gateway und Citrix StoreFront, um Ressourcen von on-premises und von AWS gehosteten Sites zu aggregieren. Dies erleichtert die Migration von Workloads zu AWS, obwohl Kunden ihre on-premises Workloads beibehalten und einfach eine weitere Site in AWS hinzufügen können. Die neue Site kann für neue Workloads oder zur Unterstützung von Disaster Recovery (DR) und Failover-Anwendungsfällen verwendet werden. Dieses Modell ist durch die Verwendung von kundenverwalteten Komponenten für die Session Brokering und Administration, UI-Dienste, Authentifizierung und HDX-Sitzungsproxy gekennzeichnet.

In diesem Abschnitt werden diese Szenarien detaillierter definiert, einschließlich Architekturübersichten darüber, wie die einzelnen Szenarien üblich gestaltet werden. Sie stellen fest, dass die führende Praxis darin besteht, Citrix Clouddienste zu verwenden, und dieses Dokument wird sich daher auf die von Citrix Cloud vermittelten Bereitstellungsmodelle (“Greenfield” und “Hybrid”) konzentrieren.

Greenfield-Einsatz

Das gebräuchlichste Beispiel für das Grünfeld-Bereitstellungsmodell ist die Test- oder Proof-of-Concept-Bereitstellung von Citrix Virtualisierungstechnologie in der AWS-Cloud. Da Sie im Wesentlichen bei Null anfangen, kann die Leistungsfähigkeit von “Infrastruktur als Code” erlebt werden, da Sie nicht versuchen, sich in eine Reihe bestehender “Dinge” zu integrieren. Es ist auch eine fantastische Gelegenheit, verschiedene Clouddienste zu “spielen” und ihre Eignung für die Bedürfnisse Ihrer Kunden zu bewerten.

Eine Green-Field-Bereitstellung ist auch das schnellste und einfachste Citrix Virtualisierungssystem, das Sie aufbauen können. Sie können es einfach abreißen, wenn das System nicht mehr benötigt wird, und Sie zahlen nicht mehr für die verbrauchten Ressourcen. Für diese Art der Bereitstellung benötigen Sie lediglich ein aktives AWS-Konto und entweder eine Testversion oder ein kostenpflichtiges Abonnement für Citrix Cloud und Citrix DaaS. Mit diesen beiden Ressourcen können Sie die QuickStart CloudFormation-Vorlagen von AWS verwenden, um eine Referenzbereitstellung zu erstellen. Citrix und AWS haben gemeinsam an der Citrix DaaS on AWS-Schnellstartvorlage gearbeitet, mit der Sie entweder ein komplettes Citrix Virtualisierungssystem von Grund auf neu erstellen oder einen Citrix Cloud- “Ressourcenstandort” in einer vorhandenen VPC mit einem vorhandenen Active Directory erstellen können. Wenn Sie das gesamte Citrix Virtualisierungssystem von Grund auf bereitstellen, ist das resultierende System in AWS genau auf die folgenden Referenzarchitekturdiagramme aufgebaut:

Abbildung 3: Detaillierte Standardparameter der bereitgestellten Systemarchitektur. Citrix Cloud Services nicht dargestellt Diagramm 3: Details zur bereitgestellten Systemarchitektur unter Verwendung der Citrix DaaS auf AWS QuickStart-Vorlage und Standardparametern. Citrix Cloud Services werden nicht angezeigt.

Diagramm 4: Konzeptuelle Greenfield/Cloud-Only-Bereitstellungsarchitektur mit optionalen AWS-Services und Citrix Cloud Services Diagramm 4: Konzeptionelle Greenfield/Cloud-Only-Bereitstellungsarchitektur mit optionalen AWS-Services und Citrix Cloud Services.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell (eigentlich alle drei Bereitstellungsmodelle) AWS Availability Zones verwendet, um ein hochverfügbares Design bereitzustellen. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Availability Zones .

Wie bereits erwähnt, ist dies ein guter Ausgangspunkt, um mehr über AWS und Citrix Clouddienste zu erfahren. Viele der im vorhergehenden Diagramm dargestellten Entwurfsmuster werden für Hybrid- und sogar Lift- und Shift-Deployment-Typen verwendet, sodass das Erlernen dieser Entwurfsmuster unabhängig vom Bereitstellungsmodell für einen Citrix auf AWS-Architekten geeignet ist.

Zusammenfassend lässt sich sagen, dass das Grünfeld-Bereitstellungsmodell alle Clouddienste verwendet, zumindest als Ausgangspunkt:

Citrix Virtualisierungssystemkomponente Zur Verfügung gestellt von
Session Brokering und Administration Citrix DaaS (“DaaS”, über Citrix Cloud)
UI-Dienste Citrix Workspace-Dienst (über Citrix Cloud)
Authentifizierung Citrix Workspace-Dienst (über Citrix Cloud)
HDX-Sitzungsproxy Citrix Gateway Service (über Citrix Cloud)
VMs Computing, Netzwerke und Speicher Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory und Dateisysteme AWS Directory Service für Microsoft Active Directory und Amazons FSx für Windows File Server (optional)

Wir haben bereits erwähnt, dass das Grünfeld-Bereitstellungsmodell häufig als Ausgangspunkt für Proof-of-Concept- und Technologie-Versuchssysteme verwendet wird. Wenn Sie mit diesem Modell beginnen und dann StoreFront oder Citrix ADC/Gateway VPXs eingehen, erstellen Sie angeblich unsere nächste Art von Bereitstellungsmodell: Hybrid.

Hybrid-Einsatz

Mit dem hybriden Bereitstellungsmodell können Kunden einige der Komponenten des Citrix-Virtualisierungssystems selbst installieren/konfigurieren/verwalten, jedoch nicht das Sitzungsbroker- und Verwaltungssubsystem. In einem hybriden Bereitstellungsmodell wird dieses Subsystem als Clouddienst namens “Citrix DaaS” bereitgestellt und als Abonnement von Citrix Cloud bereitgestellt.

Das hybride Bereitstellungsmodell ist die häufigste Bereitstellung, die heute zu sehen ist, und ist das Modell, das Citrix für die meisten Kunden empfiehlt. Hier sind einige der Hauptgründe, warum wir diese Position einnehmen:

  • Einfachheit - Bei Citrix Clouddiensten ist Einfachheit ein grundlegender Designgrundsatz. Wenn mehrere Clouddienste verwendet werden, sind sie für die Zusammenarbeit vorkonfiguriert, und wenn eine Konfiguration erforderlich ist, werden Workflows und Optionen erheblich vereinfacht.
  • Einsparungen bei Infrastruktur- und Lizenzkosten - Kundenverwaltete Citrix Virtualisierungsdienste benötigen häufig zusätzliche Hardware und Software, um sie zu unterstützen, und diese sind damit verbundene Kosten. Ein gutes Beispiel ist Microsoft SQL Server: Kundenverwaltete Brokering- und Administrationsdienste erfordern Datenbanken, und wenn Sie Ihre eigenen erstellen oder verwalten möchten, müssen Sie diese bereitstellen. Eine Alternative ist die Verwendung des AWS Relational Database Service (Amazon RDS) für SQL Server.
  • Autoscaling — Der Managed Brokering-Service (DaaS) von Citrix umfasst die Citrix Autoscale-Funktion, die integrierte VDA-Kapazitäts- und Kostenmanagementfunktionen bietet. Diese Funktion kann Kunden eine beträchtliche Menge an Geld für die Infrastruktur einsparen, wenn sie nur für das bezahlen, was sie nutzen. Wenn Sie eine Citrix Virtualisierungs-Workload auf AWS ausführen, bedeutet dies häufig den Unterschied zwischen der Bezahlung von Rabatten für festgefahrene Nutzung oder der Bezahlung der VM-Nutzung. Die Kosteneinsparungen können für viele Anwendungsfälle dramatisch sein, und die Citrix Autoscale-Funktion hilft sicherzustellen, dass Sie nur das konsumieren, was Sie benötigen.
  • Einsparungen bei der Verwaltung — Bei Cloud-Diensten trägt Citrix die Verantwortung dafür, dass die Dienste hochverfügbar, leistungsstark, sicher und aktuell bleiben. Sie bauen und verwalten Ihre VDAs trotzdem, unterschätzen jedoch nicht den Wert der Delegierung dieser Verantwortlichkeiten. Clouddienste helfen dabei, IT-Ressourcen freizulassen, sodass sie sich darauf konzentrieren können, ihren Unternehmen einen einzigartigen Mehrwert zu bieten, anstatt diesen kritischen, aber langwierigen (und oft zeitaufwändigen) Aufgaben.
  • ” Kostenlose” Upgrades und kontinuierliche Innovation - bei der vom Kunden verwalteten Infrastruktur liegt es am Kunden, die Komponenten in seiner Obhut zu aktualisieren und zu patchen. Mit Clouddiensten gehen die meisten dieser Arbeitsbemühungen weg. Die Dienstleister (z. B. Citrix oder AWS) neigen dazu, ständig innovativ zu sein, und sie bringen diese Innovationen zu den Kunden, die die Dienste in Anspruch nehmen, oft ohne Arbeit im Namen des Kunden.
  • Zugriff auf mehr Funktionen, Funktionen und Services - moderne Service-Bereitstellungsplattformen (wie Citrix Cloud und AWS EC2) bieten Technologieanbietern eine leistungsstarke und kostengünstige Möglichkeit, neue Funktionen, Funktionen und Services auf den Markt zu bringen, die sonst nicht möglich wären. Anbieter wie Citrix sind bestrebt, den Kunden zu treffen, wo immer er sich auf seinem Weg zur digitalen Transformation befindet. Manchmal besteht die einzige Möglichkeit, neue Funktionen kostengünstig bereitzustellen, darin, sie als Clouddienst bereitzustellen.
  • Flexibilität : Mit DaaS als Grundlage dieses Bereitstellungsmodells können Kunden vom Kunden verwaltete Komponenten oder Cloud-Service-Komponenten des Citrix Virtualisierungssystems kombinieren. Dadurch kann das System verschiedene Anwendungsfälle erfüllen und komplexe Unternehmensanforderungen für ein Citrix Virtualisierungssystem unterstützen. Wir untersuchen diese Entscheidungen in einem späteren Abschnitt dieses Papiers ausführlich.

Zusammenfassend lässt sich sagen, dass das Hybridbereitstellungsmodell Folgendes verwendet:

Citrix Virtualisierungssystemkomponente Zur Verfügung gestellt von
Session Brokering und Administration Citrix DaaS (“DaaS”, über Citrix Cloud)
UI-Dienste Citrix Workspace Service (über Citrix Cloud) ODER Citrix StoreFront auf Amazon EC2 (vom Kunden verwaltet)
Authentifizierung Citrix Workspace-Dienst (über Citrix Cloud) ODER Citrix StoreFront auf EC2 (Citrix ADC/Gateway optional, aber häufig)
HDX-Sitzungsproxy Citrix Gateway Service (über Citrix Cloud) ODER Citrix ADC/Gateway VPX auf Amazon EC2 (Citrix ADC/Gateway optional aber häufig)
VMs Computing, Netzwerke und Speicher Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory und Dateisysteme AWS Directory Service für Microsoft Active Directory und Amazons FSx für Windows File Server (optional)

Angesichts der Optionen, die ein Kunde im hybriden Bereitstellungsmodell auswählen kann, und der Flexibilität, die von vom Kunden verwalteten Komponenten geboten wird, gibt es keine einzige, prägnente Architektur, die für alle Kunden geeignet ist. Es gibt jedoch einige gängige Designmuster, die auch an die Bedürfnisse der Kunden angepasst werden können. Das grundlegende Muster ist jedoch das Muster für einen Citrix Cloud “Resource Location” in AWS. Es ist auch das von der Citrix DaaS on AWS QuickStart-Vorlage erstellte Muster und ähnelt dem folgenden Architekturdiagramm:

Abbildung 5: Konzeptarchitektur, Citrix DaaS — Hybrides Bereitstellungsmodell auf AWS Diagramm 5: Konzeptarchitektur, Citrix DaaS — Hybrides Bereitstellungsmodell auf AWS.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell auch AWS Availability Zones verwendet, um ein hochverfügbares Design bereitzustellen. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Availability Zones .

Es ist auch erwähnenswert, dass das hybride Bereitstellungsmodell (ein DaaS-Ressourcenstandort auf AWS) mit einem Hybrid-Cloud-Modell kombiniert werden kann, das vom Kunden verwaltete Rechenzentren/Ressourcen mithilfe von AWS Direct Connect, AWS VPN oder anderen Netzwerktools mit AWS verbindet. Mit diesem Modell wird das vorhandene Active Directory der Kunden häufig auf AWS ausgedehnt, und Kunden erstellen mehr “Ressourcenstandorte” von Citrix Cloud, die Apps, Desktops und Ressourcen aus dem vom Kunden verwalteten Rechenzentrum bereitstellen. Die resultierende konzeptionelle Architektur sieht in etwa wie das folgende Diagramm aus: Diagramm 6: Konzeptarchitektur, Citrix DaaS: Hybrid Deployment/Hybrid Cloud-Modell Diagramm 6: Konzeptarchitektur, Citrix DaaS: Hybrid Deployment/Hybrid Cloud-Modell.

Heben und verschieben

Wenn wir über ein Lift-and-Shift-Bereitstellungsszenario sprechen, ist die Schlüsselkomponente in Bezug auf unsere Definition der Komponenten des Citrix Virtualisierungssystemsdas Sitzungsvermittlungs- und Verwaltungssubsystem und die zugehörige Infrastruktur. Wenn Sie eine selbstverwaltete Brokeringinfrastruktur verwenden (Sie stellen Delivery Controller anstelle von Cloud Connectors bereit), heben und verschieben Sie für die Zwecke dieses Artikels.

Heben und verschieben - warum

Trotz der Citrix-Empfehlung gegen dieses Modell entscheiden sich einige Kunden immer noch für dieses Modell und stellen die Komponenten des Citrix Virtualisierungssystems selbst bereit und verwalten sie selbst. Gemäß CTX270373wird die Verwendung von Public Clouds einschließlich AWS nur mit LTSR-Produktversionen unterstützt. Für Kunden, die sich für das Aufzugs- (selbstverwaltete) Bereitstellungsmodell entscheiden, stellen wir häufig fest, dass nicht-technische Gründe dahinter stehen. Politik, Zeitdruck, Angst vor dem Unbekannten, wahrgenommene Kompetenzdefizite, Kontrollverlust und Lizenzerwerb fallen in diese Kategorie. Es gibt jedoch einige technische Gründe, warum dieses Modell ansprechend ist. Dazu gehören:

  • Systemisolierung - einige Anwendungsfälle, wie z. B. Luftgesäumte Systeme ohne Internetzugang, machen das Hebe- und Shift-Modell oft attraktiv. Da Clouddienste einen ausgehenden Internetzugang erfordern, um zu funktionieren, funktionieren Clouddienste in einer streng luftübergreifenden Bereitstellung nicht. Dies gilt hauptsächlich für die Cloud Connectors (Hauptkomponente von Managed Session Brokering-Dienste), da sie ausgehende Internetkonnektivität benötigen, um mit den Citrix Clouddiensten zu kommunizieren und diese zu nutzen. Einige Kunden können erwägen, einen sicheren, ausgehenden Proxy für Cloud Connectors zu verwenden (während alle anderen Infrastrukturen strikt in der Luft gehalten werden). Dies ist oft eine geeignete Konzession, die die Nutzung der Managed Brokering-Dienste ermöglicht, aber selbst dies ist für einige Kunden und Anwendungsfälle möglicherweise keine Option.
  • Flexibilität bei der Konfiguration - der “Komplex” einer Person ist “flexibel” einer anderen Person, und die Flexibilität ist seit mehr als zwei Jahrzehnten eine starke Suite von kundenverwalteter Citrix Virtualisierungsinfrastruktur. Im Laufe der Jahre hat die Technologie eine Menge Funktionen gewonnen, die einige sehr Nischen-Anwendungsfälle und Integrationen von Drittanbietern unterstützen. Die Citrix Clouddienste konzentrieren sich auf Einfachheit und Vorintegration. Dabei sind einige dieser Nischenfunktionen und -integrationen nicht verfügbar. Daher werden einige Edge-Fälle immer noch am besten von einem vom Kunden verwalteten Stack bedient. Angesichts des rasanten Innovationstempos der Citrix Clouddienste werden diese Randfälle jedoch immer seltener.
  • Kontrolle - einige Organisationen, Kulturen und Geschäftsmodelle erfordern so viel Kontrolle wie möglich. Mit vom Kunden verwalteten Citrix Virtualisierungskomponenten können Kunden ihr Schicksal vollständig besitzen. Diese Kontrolle hat Kosten (Infrastruktur, Komplexität, Personal usw.), aber “Kontrolle um jeden Preis” ist für einige Kunden eine Sache.

Zusammenfassend lässt sich sagen, dass das Lift- und Shift-Bereitstellungsmodell Folgendes verwendet:

Citrix Virtualisierungssystemkomponente Zur Verfügung gestellt von
Session Brokering und Administration Citrix Virtual Apps and Desktops (Kunde verwaltet mit LTSR oder CR herunterladbar) auf Amazon EC2
UI-Dienste Citrix StoreFront auf Amazon EC2 (vom Kunden verwaltet)
Authentifizierung Citrix StoreFront auf EC2 (Citrix ADC/Gateway optional aber häufig)
HDX-Sitzungsproxy Citrix ADC/Gateway VPX auf Amazon EC2 (vom Kunden verwaltet)
VMs Computing, Netzwerke und Speicher Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory und Dateisysteme Kundenverwaltete Windows Server-Instanzen auf EC2; AWS Directory Service für Microsoft Active Directory und Amazon FSx für Windows File Server (optional)

In seiner einfachsten Form ähnelt eine Auf- und Verlagerung der Citrix Virtualisierungstechnologie auf AWS einer herkömmlichen, von Kunden verwalteten Bereitstellung on-premises. Es verwendet einen CVAD-Standort, der in einer AWS-Region bereitgestellt wird, und verwendet mindestens grundlegende AWS-IaaS-Services wie virtuelle EC2-Maschinen und VPC-Netzwerke. Wie bereits erwähnt, muss der Kunde alle Systemkomponenten sowie unterstützende Dienste wie SQL-Datenbanken erstellen/konfigurieren/pflegen. Das folgende Diagramm zeigt dieses Bereitstellungsmodell: Diagramm 1: Konzeptionelle Architektur, CVAD: Lift and Shift-Bereitstellungsmodell in AWS Diagramm 1: Konzeptionelle Architektur, CVAD: Lift and Shift-Bereitstellungsmodell auf AWS.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell auch AWS Availability Zones verwendet, um ein hochverfügbares Design bereitzustellen. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Availability Zones .

Ein Lift-and-Shift-Bereitstellungsmodell wird häufig mit einem Hybrid-Cloud-Infrastrukturmodell kombiniert. Dabei werden AWS Direct Connect, AWS VPN oder eine ähnliche Netzwerktechnologie verwendet, um ein vom Kunden verwaltetes Rechenzentrum und Ressourcen mit AWS zu verbinden. Kunden können optional einige der fortschrittlicheren Clouddienste von AWS übernehmen (um eine Vereinfachung bei der Umstellung zu bieten), und sie können auch einige Dienste (wie SQL-Datenbanken, Citrix Lizenzierung, Citrix StoreFront und Citrix ADC/Gateway) entweder auf AWS in einem vom Kunden verwalteten Daten hosten Zentrum oder beides in Abhängigkeit von ihren bestehenden Investitionen, Anwendungsfallanforderungen und derart. Eine konzeptionelle Architektur dieses Bereitstellungsmodells (unter Verwendung von AWS RDS for SQL Server oder on-premises SQL Server) wird im folgenden Diagramm dargestellt. Es wird nur eine aktive Instanz der Citrix Lizenzierung benötigt, aber wir haben mehrere gezeigt, um die verfügbaren Optionen darzustellen: Abbildung 8: Konzeptarchitektur, CVAD: Lift and Shift Deployment Model with Hybrid Cloud Infrastructure Model und AWS Managed Cloud Services Diagramm 8: Konzeptarchitektur, CVAD: Lift and Shift-Bereitstellungsmodell mit Hybrid Cloud-Infrastrukturmodell und von AWS verwalteten Cloud-Services.

Heben und verschieben - warum nicht

Inzwischen haben Sie sich versammelt, dass die führende Praxis/Empfehlung von Citrix darin besteht, KEINE volle Anhebung und Schicht zu machen. Sie können sich fragen, warum oder woher das kommt. In Bezug auf unsere Aufschlüsselung der Komponenten des Citrix-Virtualisierungssystemsist das Sitzungsbroker- und Verwaltungssubsystem die wichtigste Komponente, die Sie in Betracht ziehen sollten, NICHT zu heben und zu verschieben. Wir empfehlen Kunden dringend, die Clouddienste von Citrix für die Session Brokering und Administration zu verwenden (nur Cloud Connectors bereitstellen, im Gegensatz zur Bereitstellung von Delivery Controllers + SQL-Datenbanken + Director-Servern + Citrix Lizenzierungsserver). Hier sind einige der Hauptgründe, warum wir diese Position einnehmen (und sie könnten sich vertraut anhören):

  • Einfachheit - Während vom Kunden verwaltete Session Brokering-Dienste die ultimative Flexibilität bei der Kontrolle und Konfiguration bieten, geht dies auf Kosten der Komplexität und der laufenden Wartungsanforderungen. Bei Citrix Clouddiensten ist Einfachheit ein grundlegender Designgrundsatz. Wenn mehrere Clouddienste verwendet werden, sind sie für die Zusammenarbeit vorkonfiguriert, und wenn eine Konfiguration erforderlich ist, werden Workflows und Optionen erheblich vereinfacht.
  • Einsparungen bei Infrastruktur- und Lizenzkosten - Kundenverwaltete Citrix Virtualisierungsdienste benötigen häufig zusätzliche Hardware und Software, um sie zu unterstützen, und diese sind damit verbundene Kosten. Ein gutes Beispiel ist Microsoft SQL Server: Kundenverwaltete Brokering-Dienste erfordern Datenbanken, und wenn Sie Ihre eigenen erstellen oder verwalten möchten, müssen Sie diese bereitstellen.
  • Apropos Einsparungen bei den Infrastrukturkosten - dies schafft ein entscheidendes Unterscheidungsmerkmal zwischen den beiden Optionen für die Sitzungsvermittlung: Autoscaling. Der Managed Brokering-Service (DaaS) von Citrix umfasst die Citrix Autoscale-Funktion, die integrierte VDA-Kapazitäts- und Kostenmanagementfunktionen bietet. Diese Funktion kann Kunden eine beträchtliche Menge an Geld für die Infrastruktur einsparen, wenn sie nur für das bezahlen, was sie nutzen. Wenn Sie eine Citrix Virtualisierungs-Workload auf AWS ausführen, bedeutet dies häufig den Unterschied zwischen der Bezahlung von Rabatten für festgefahrene Nutzung oder der Bezahlung der VM-Nutzung. Die Kosteneinsparungen können für viele Anwendungsfälle dramatisch sein, und die Citrix Autoscale-Funktion hilft sicherzustellen, dass Sie nur das konsumieren, was Sie benötigen. Wichtiger Hinweis: Diese Funktion steht nur Kunden des Citrix Cloud-Dienstes (Citrix DaaS) zur Verfügung. Sie steht nicht für die vom Kunden verwaltete Brokering-Infrastruktur (Citrix Virtual Apps and Desktops LTSR- oder CR-Versionen) zur Verfügung. - Einsparungen bei der Verwaltung — Bei Cloud-Services trägt Citrix (und in diesem Fall AWS) die Verantwortung dafür, dass die Services hochverfügbar, performant, sicher und aktuell bleiben. Sie bauen und verwalten Ihre VDAs trotzdem, unterschätzen jedoch nicht den Wert der Delegierung dieser Verantwortlichkeiten. Clouddienste helfen dabei, IT-Ressourcen freizugeben, sodass sie sich darauf konzentrieren können, ihren Unternehmen einen einzigartigen Mehrwert zu bieten, anstatt diesen kritischen, aber langwierigen und oft zeitaufwändigen Aufgaben.
  • ” Kostenlose” Upgrades und kontinuierliche Innovation - bei der vom Kunden verwalteten Infrastruktur liegt es am Kunden, die Komponenten in seiner Obhut zu aktualisieren und zu patchen. Bei Clouddiensten gehen die meisten dieser Arbeitsbemühungen weg. Die Dienstleister (in diesem Fall Citrix und AWS) neigen dazu, ständig innovativ zu sein, und sie bringen diese Innovationen zu den Kunden, die die Dienstleistungen in Anspruch nehmen, oft ohne Arbeit im Namen des Kunden zu benötigen.
  • Zugriff auf mehr Funktionen und Services - moderne Service-Bereitstellungsplattformen (wie Citrix Cloud und Amazon EC2) bieten Technologieanbietern eine leistungsstarke und kostengünstige Möglichkeit, neue Funktionen, Funktionen und Services auf den Markt zu bringen, die sonst nicht möglich wären. Anbieter wie Citrix sind bestrebt, den Kunden zu treffen, wo immer er sich auf seinem Weg zur digitalen Transformation befindet. Manchmal besteht die einzige Möglichkeit, neue Funktionen kostengünstig bereitzustellen, darin, sie als Clouddienst bereitzustellen.

Heben und verschieben - mehr Ressourcen

Vor der Entfaltung von Citrix Clouddiensten haben Kunden bereits erfolgreich Citrix Virtualisierungstechnologien auf AWS implementiert. In diesen Tagen nannte Citrix die Virtual Apps and Desktops-Produkte XenApp und XenDesktop. Umfangreiche Arbeiten zur Erstellung und Veröffentlichung von Referenzarchitekturen und Bereitstellungsleitfäden für dieses Bereitstellungsszenario wurden berücksichtigt. Ein Großteil der Details dieser alternden Ressourcen gilt immer noch für Bereitstellungen, die heute diesen Weg gehen müssen.

Für Kunden, die diesen Weg gehen MÜSSEN, bieten Ihnen die folgenden veröffentlichten Ressourcen nützliche Hintergrunddetails, mit denen Sie erfolgreich sein können. Wir empfehlen, diese Materialien zu überprüfen, bevor Sie mit diesem Dokument fortfahren, da wir wichtige Designentscheidungen hervorheben, die sich seit Abschluss dieser Arbeiten geändert haben:

Designentscheidungen

In diesem Abschnitt werden die wichtigsten Designentscheidungen untersucht, die Sie bei der Entwicklung Ihres Citrix Virtualisierungssystems in AWS berücksichtigen sollten. Wir gehen durch jede Ebene des Citrix Architectural Design Framework und untersuchen wichtige Bereiche, die Sie berücksichtigen sollten.

Informationen zum Citrix Architectural Design Framework

Die Virtual Apps and Desktops-Lösung von Citrix (der Produktfamilienname, der sich zusammen auf die Virtualisierungstechnologien von Citrix bezieht) ermöglicht es Unternehmen, virtuelle Maschinen zu erstellen, zu steuern und zu verwalten, Anwendungen und Desktops bereitzustellen und granulare Sicherheitsrichtlinien zu implementieren. Die Citrix Virtual Apps and Desktops-Lösung bietet ein einheitliches Framework für die Entwicklung eines vollständigen Angebots an Workspace Arbeitsplätzen. Dieses Angebot ermöglicht Citrix-Benutzern den Zugriff auf Anwendungen und Desktops unabhängig vom Betriebssystem und der Benutzeroberfläche ihres Geräts.

Das Citrix Architekturentwurfsframework basiert auf einem einheitlichen und standardisierten Ebenenmodell. Es bietet einen konsistenten und leicht zugänglichen Rahmen zum Verständnis der technischen Architektur für die meisten gängigen Bereitstellungsszenarien für Virtual Apps and Desktops. Diese Layer sind im folgenden Konzeptdiagramm dargestellt: Abbildung 9: Konzeptarchitektur, Citrix Virtual Apps and Desktops Diagramm 9: Konzeptarchitektur, Citrix Virtual Apps and Desktops.

  • Benutzerlayer - Dieser Layer definiert Benutzergruppen und Standorte der Citrix Umgebung.
  • Zugriffsebene - Diese Ebene definiert, wie Benutzer auf die Ressourcen zugreifen.
  • Steuerungebene - Diese Ebene definiert die Komponenten, die die Citrix Lösung steuern.
  • Ressourcenebene - Diese Ebene definiert die Provisioning von Citrix Workloads und wie Ressourcen den angegebenen Benutzern zugewiesen werden.
  • Plattformebene - Diese Ebene definiert die physischen Elemente, in denen die Hypervisor-Komponenten und das Cloud Service Provider-Framework ausgeführt werden, um die Citrix Workloads zu hosten.
  • Operationsebene - Diese Ebene definiert die Tools, die die Bereitstellung der Kernlösungen unterstützen.

Überlegungen zum Benutzerlayer

Im Citrix Architectural Design Framework beschreibt der Benutzerlayer die Benutzergruppen, ihre Standorte, spezifische Anforderungen und mehr. Die Benutzerebene legt die Gesamtrichtung für die Umgebung jeder Benutzergruppe entsprechend fest. Diese Ebene enthält die Bewertungskriterien für Geschäftsprioritäten und Benutzergruppenanforderungen, um effektive Strategien für Endpunkte und Citrix Workspace App zu definieren. Die entsprechenden Designentscheidungen beeinflussen Flexibilität und Funktionalität für jede Benutzergruppe.

Beim Entwurf und der Bereitstellung eines Citrix Virtualisierungssystems auf einer beliebigen Plattform bilden die nach sorgfältiger Bewertung getroffenen Entscheidungen und Strategien die Grundlage für viele andere Entscheidungen, die Kunden berücksichtigen sollten, wenn sie sich durch die anderen Ebenen im Citrix Architectural Design Framework arbeiten. Daher ist dies eine wichtige Ebene, um sie gründlich zu verstehen und richtig zu machen.

Überlegungen zu Zugriffsebene

Im Citrix Architectural Design Framework definiert die Zugriffsebene, wie Benutzer auf AWS-Ressourcen zugreifen. Das Design Ihrer Zugriffsebene ist entscheidend für die Funktionalität eines Citrix Virtualisierungssystems. Es steuert, wie sich Benutzer beim System authentifizieren. Es steuert auch, wie Benutzer virtualisierte Anwendungen und Desktops anzeigen und starten und welche Arten von Anwendungen und Inhalten ihnen zur Verfügung stehen. Außerdem steuert die Zugriffsebene, wie und wann Sitzungen sicher zur Verfügung gestellt oder direkt verbunden werden.

Im Zusammenhang mit den zuvor definierten Komponenten des Citrix-Virtualisierungssystems enthält die Zugriffsebene die folgenden Komponenten und Auswahlmöglichkeiten:

Citrix Virtualisierungssystemkomponente Zur Verfügung gestellt von
UI-Dienste Citrix Workspace (bereitgestellt von Citrix Cloud) ODER Citrix StoreFront auf Amazon EC2 (vom Kunden verwaltet)
Authentifizierung Citrix Workspace Service (Citrix ADC/Gateway optional) ODER Citrix StoreFront auf EC2 (Citrix ADC/Gateway optional aber häufig)
HDX-Sitzungsproxy Citrix Gateway Service (bereitgestellt von Citrix Cloud) ODER Citrix ADC/Gateway VPX auf Amazon EC2 (vom Kunden verwaltet)

Die folgende Tabelle enthält kritische Entscheidungspunkte bei der Bestimmung, welche Komponente der Zugriffsebene bereitgestellt werden soll, die Auswahl jedoch nicht binär ist. Citrix unterstützt verschiedene Zugriffsmethoden, die an Ihre Anforderungen angepasst werden können.

Überlegungen zu UI-Diensten und -

Berücksichtigen Sie Folgendes, wenn Sie auswählen, wie Sie UI-Services für Ihr Citrix Virtualisierungssystem in AWS bereitstellen möchten:

Attribut/Capability Kundenverwaltet (installiert aus heruntergeladenen Binärdateien) Clouddienst (bereitgestellt über Citrix Cloud)
Möglichkeit, virtualisierte Apps und Desktops von mehreren “Citrix Farms” aus zu präsentieren und zu starten. JA — Sowohl ältere Umgebungen (XenApp und XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) als auch Citrix DaaS. JA — Sowohl ältere Umgebungen (XenApp und XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) als auch Citrix DaaS. In diesem Artikel finden Sie weitere Informationen.
Möglichkeit, mehrere “Stores” mit unterschiedlichen Einstellungen für verschiedene Anwendungsfälle zu erstellen, einschließlich der Authentifizierungsanforderungen. JA - StoreFront kann mit mehreren verschiedenen Stores konfiguriert werden und kann in Kombination mit Citrix ADC/Gateway VPX ausgefeilte Regeln anwenden, um bestimmte Geräte oder Benutzergruppen in verschiedene Stores zu leiten. Weitere Informationen finden Sie unter Funktionsweise von SmartAccess für Citrix Virtual Apps and Desktops. Ein häufiges Szenario, in dem zwei StoreFront-Stores erforderlich sind, wäre, wenn Benutzer veröffentlichte Anwendungen von einem veröffentlichten Desktop benötigen. Ein anderes häufiges Szenario wäre die Anforderung, einen internen reinen Store (kein Citrix Gateway-Zugriff) für einen bestimmten Anwendungsfall und einen anderen Store zu haben, der sowohl für den internen als auch für den Remotezugriff konfiguriert ist. Weitere Informationen finden Sie unter Stores konfigurieren und verwalten . NEIN - Der Workspace Service ist im Wesentlichen ein einzelner Store mit einer einzelnen URL. Alle Benutzer verwenden die gleichen Store- und Workspace-Einstellungen. Die Authentifizierungsanforderungen werden einmal eingerichtet und gelten für alle Benutzer des Workspace-Mandanten.
Möglichkeit, SaaS- und Web-Apps mithilfe des Citrix Secure Private Access Services aufzulisten, zu starten und SSO zu nutzen, wobei die Vorteile der Webfilterung und der erweiterten Sicherheitskontrollrichtlinien sowie erweiterte ML-erweiterte Analysen genutzt werden. NEIN - Erfordert die Verwendung von Citrix Workspace. JA - Mit dem Citrix Gateway Service ist es so einfach wie das “Einschalten” der Integration in die Citrix Cloud Console. SaaS-Apps werden einfach von einem webbasierten Assistenten definiert, und Administratoren können eine umfangreiche Liste vordefinierter Apps als Ausgangspunkt verwenden.
Möglichkeit, über die Citrix Workspace-App und Webbrowser (HTML) auf Inhalte von Citrix Files (ehemals ShareFile) zuzugreifen, sie zu indizieren/zu durchsuchen. NEIN - StoreFront ist nicht in der Lage, dateibasierte Inhalte in Workspace App- oder StoreFront-HTML-UIs zu integrieren. JA - Standardmäßig aktiviert, abhängig vom Abonnement für Citrix Cloud. Bringt den dateibasierten Inhalt von Benutzern aus verschiedenen Quellen (einschließlich lokaler Dateifreigaben) in die Workspace-Benutzeroberfläche, sowohl HTML als auch Workspace App.
Möglichkeit, Verbindungen zu physischen Desktops mithilfe der Funktion Citrix Remote PC Access zu präsentieren und zu starten. JA - Unabhängig davon, ob die Vermittlung von CVAD oder DaaS abgewickelt wird. JA - Unabhängig davon, ob die Vermittlung von CVAD oder DaaS abgewickelt wird.
Bei Anwendungsfällen an mehreren Standorten und DR können Sie das Verhalten des Sitzungsstarts mithilfe von Zonenpräferenz und Failover granuliert steuern. JA - Die Verwendung von Citrix Zones für Bereitstellungen in mehreren AWS-Regionen und Availability Zones ist eine großartige Möglichkeit, Ost-West zu erweitern und die betroffene Benutzerbasis im Falle eines Ausfalls einzuschränken, und ermöglicht eine regionale Präferenz und ein nahtloses Failover in die primäre Zone. Siehe Dokumentation zu CVAD Zones. Teilweise - Der Arbeitsbereichsdienst enthält nicht die voll funktionsfähige Zonenpräferenz- und Failover-Funktionalität, aber ein ähnlicher Effekt kann mithilfe von Home-Zonen für Benutzer oder Apps implementiert werden. Einzelheiten finden Sie in der Dokumentation Citrix DaaS-Zonen .
Möglichkeit, neue und vorhandene Verbindungen zu vermitteln, wenn eine Verbindung zwischen einem Ressourcenstandort/einer Zone und Citrix Cloud ausfällt oder wenn die Datenbanken unter Citrix Delivery Controllern nicht verfügbar sind. JA - Verwendet die lokale Hostcache-Funktion sowohl für Cloud Connectors als auch für Delivery Controller, um die Ausfallsänderung für diese beiden potenziellen Ausfallszenarien bereitzustellen. Für Umgebungen mit umfassenden Ausfallanforderungen empfiehlt Citrix die Bereitstellung von StoreFront mit Local Host Cache. Weitere Informationen finden Sie unter Lokaler Hostcache (CVAD). JA - Cloud Connectors verwenden die Local Host Cache-Funktion, um Ressourcenverbindungen bei Ausfällen der Citrix Cloud-Kommunikation zu vermitteln. Dies erfordert passive StoreFront-Server, auf die Ihre Ressourcenstandorte zugreifen können, um Failover-Szenarien zu Weitere Informationen finden Sie unter Lokaler Hostcache (DaaS).
Möglichkeit, eine angepasste “Vanity-URL” für den Endbenutzerverbrauch zu konfigurieren und zu verwenden. JA - Der Kunde hat die volle Kontrolle über die verwendeten und den Benutzern vorgelegten Zertifikate. Erfordert SSL-Zertifikate, DNS-Aliaserstellung/-Verwaltung und Citrix ADC/Gateway-Instanzen für den Eingang über öffentliche Netzwerke. Teilweise — Alle Arbeitsbereiche werden von der cloud.com-Domäne bereitgestellt, obwohl Kunden ihr eigenes benutzerdefiniertes Präfix (Kundenname.cloud.com) konfigurieren können.
Möglichkeit, Benutzer im Netzwerk über Citrix ADC/Gateway VPX oder Citrix Gateway Service intelligent an VDAs und Benutzer außerhalb des Netzwerks weiterzuleiten. JA - StoreFront verwendet vom Administrator definierte “Beacons”, mit denen die Citrix Workspace-App ermittelt, ob sich ein Benutzer im oder außerhalb des Netzwerks befindet. Demnächst - Diese Funktion wird voraussichtlich mit der Veröffentlichung des Netzwerkstandortdienstes in Citrix Workspace verfügbar sein, sobald sie allgemein verfügbar ist. Weitere Informationen finden Sie unter Vorschau des Network Location Service.
Möglichkeit, Citrix Gateway Service für einfache, vorkonfigurierte HDX-Sitzungsproxydienste zu verwenden. NEIN - Wenn der Zugriff außerhalb des Netzwerks auf virtualisierte Citrix Apps erforderlich ist (und in 99% der Bereitstellungen enthalten ist), erfordert StoreFront die Verwendung der vom Kunden verwalteten Citrix ADC/Gateway für HDX-Sitzungsproxy-Funktionalität. JA - Diese Funktion wird standardmäßig für alle neuen Citrix Workspace-Mandanten bereitgestellt und aktiviert.
Beinhaltet integrierte Multifaktor-Authentifizierung über Active Directory und TOTP. JA - Citrix ADC enthält integrierte TOTP-Funktionen für die Verwendung mit Authentifikatoren von Drittanbietern und unterstützt auch Apps/Geräte/Dienste von Drittanbietern. JA - Citrix Workspace enthält diese Funktion, einschließlich Self-Service-OTP-Gerätewiederherstellung und automatischen Push-Benachrichtigungen an Endbenutzer. Unterstützt sowohl Citrix als auch Authentifikator-Apps von Drittanbietern.
SSO-Funktionen (virtualisierte, SaaS- und Web-Apps) Teilweise - SSO für virtualisierte Apps aus der Box. JA — SSO zu virtualisierten, SaaS- und Web-Apps, die nativ in Citrix Workspace verfügbar sind. Gateway Service und Secure Private Access beinhalten Webfilterung und Richtliniensteuerung.
Möglichkeit, aus mehreren vordefinierten Authentifizierungsmethoden zu wählen und die gewählte Methode für alle Benutzer im System anzuwenden. JA - mit mehr Optionen und Flexibilität. Citrix StoreFront ermöglicht es Ihnen, mehrere Stores zu erstellen, und Authentifizierungsmethoden werden pro Store konfiguriert. Eine oder mehrere Optionen können pro Store konfiguriert werden, und Administratoren können aus den Citrix Gateway-Optionen aus Active Directory-Benutzername/Kennwort, SAML-Authentifizierung, Domänen-Passthrough, Smart Card, HTTP Basic und Passthrough auswählen. Selbstbedienungs-Kennwort-Reset kann ebenfalls aktiviert werden. Weitere Informationen finden Sie unter Konfigurieren des Authentifizierungsdienstes . Wenn Citrix ADC/Gateway (kundenverwaltet) bereitgestellt und mit StoreFront verwendet wird, können verschiedene Authentifizierungsoptionen konfiguriert werden, zusammen mit zusätzlicher Logik, um Benutzer bei Bedarf zu einem bestimmten Store zu leiten, um fast jeden Anwendungsfall zu unterstützen. Citrix StoreFront und Citrix ADC/Gateway werden empfohlen, wenn komplexe Integrationen und verschiedene Authentifizierungsmethoden für verschiedene Anwendungsfälle erforderlich sind. JA — Derzeit sind Active Directory, Azure AD, Active Directory+TOTP-Token, Azure AD und Citrix Gateway derzeit unterstützte Optionen. Okta- und Google Cloud ID-Optionen sind in der Vorschau verfügbar oder bald verfügbar. Weitere Informationen finden Sie unter Sichere Arbeitsbereiche . Mit Ausnahme von Citrix Gateway gilt Ihre Authentifizierungsoption für alle Benutzer und alle Dienste, die über den Citrix Workspace Mandant/URL bereitgestellt werden. Mit der Citrix Gateway-Option können Kunden verschiedene Authentifizierungsoptionen (RADIUS MFA, Smart Card, Federation, Richtlinien für bedingten Zugriff und mehr) unterstützen und sie flexibel auf verschiedene Gruppen von Benutzern und Anwendungsfällen anwenden. Weitere Informationen finden Sie unter Verbinden eines on-premises Citrix Gateway als Identitätsanbieter mit Citrix Cloud.
Möglichkeit zum SSO zu Sitzungen auf VDAs beim Starten virtualisierter Windows-Apps/Desktops mit föderierten Identitätsanbietern JA — Der Citrix Federated Authentication Service (FAS) ermöglicht SSO für VDAs, wenn ein föderierter Identitätsanbieter wie SAML (Security Assertion Markup Language) verwendet wird. Demnächst — Mithilfe des Citrix Federated Authentication Service (FAS) mit Citrix Workspace. Diese Funktion ist zum Zeitpunkt des Schreibens in der Vorschau. Weitere Informationen finden Sie unter SSO für Workspaces mit Citrix FAS aktivieren .

Überlegungen zum HDX-Sitzungsproxy

Berücksichtigen Sie Folgendes, wenn Sie auswählen, wie Sie HDX-Sitzungsproxy-Funktionen für Ihr Citrix Virtualisierungssystem in AWS bereitstellen möchten:

Attribut/Capability Kundenverwaltet (Citrix ADC/Gateway VPX auf AWS) Cloud-Dienst (Citrix Gateway Service von Citrix Cloud bereitgestellt)
Einfacher, vorkonfigurierter Service, der HDX-Proxy ohne administrativen Overhead bereitstellt NEIN - Als kundenverwaltete Komponente erfordern diese Appliances eine Lizenzierung, Installation, Konfiguration und Wartung. JACitrix Gateway Service ist eine vollständige HDX-Proxy-Lösung, die von Citrix verwaltet wird und als Cloud-Service bereitgestellt wird.
Möglichkeit, das EDT (UDP) -basierte Transportprotokoll von Citrix HDX zu verwenden. Weitere Informationen finden Sie unter Adaptiver Transport und How to Configure HDX Enlightened Data Transport Protocol. JA - Diese Funktion optimiert den Datenverkehr von Standorten mit hoher Latenz und ist für kundenverwaltete ADC/Gateway-Instanzen verfügbar. Noch nicht - Diese Funktion ist zum Zeitpunkt dieses Schreibens in der Vorschau. Der Gateway-Dienst unterstützt derzeit nur TCP-basierte Verbindungen mit VDAs.
Möglichkeit zur Bereitstellung von Lastenausgleich, Zustandsprüfung, SSL-Offload und verschiedenen anderen erweiterten Netzwerk- und Anwendungsbereitstellungsdiensten für die von Kunden verwaltete Infrastruktur. JA - Citrix ADC/Gateway VPX-Appliances bieten ausgefeilte, branchenführende Funktionen, von denen viele durch einfaches Anwenden der entsprechenden Lizenzart auf die Appliance aktiviert werden können. NEIN — Für von Citrix CVAD und Citrix DaaS vermittelte Umgebungen bietet der Gateway Service einfachen, sicheren Zugriff auf virtualisierte Anwendungen, die entweder in der AWS- oder lokalen Umgebung des Kunden ausgeführt werden.
Unterstützung für vom Kunden konfigurierbares Global Server Load Balancing (GSLB) zwischen Rechenzentren, Zonen und Regionen. JA - Kundenverwaltete Citrix ADC/Gateway-Instanzen können für GSLB eingerichtet werden, obwohl der Kunde für die Einrichtung und Verwaltung verantwortlich ist. NEIN -… es besteht jedoch keine wirkliche Notwendigkeit dafür: Der Gateway Service verwendet 14 oder mehr POPs weltweit sowie integrierte GSLB, um sicherzustellen, dass Benutzer die bestmögliche Sitzungsleistung erhalten, unabhängig davon, wo auf der Welt sie sich befinden.
Erfordert die Verwendung von Citrix Workspace UI für die Präsentation und den Start von HDX-Sitzungen. NEIN - Es ist möglich, von Kunden verwaltete Citrix ADC/Gateway VPX-Instanzen sowohl mit Workspace UI als auch mit StoreFront zu verwenden. JA - Der Gateway Service ist nur über die Citrix Workspace UI für HDX konfigurierbar - er bietet KEINE HDX-Proxy-Funktionen für Citrix StoreFront.
Erfordert zusätzliche Ressourcen für Cloud Connector-Instanzen für Proxysitzungen in gesicherte Netzwerke. NEIN - Während Cloud Connectors STA-Ticket-Validierung für kundenverwaltete Citrix ADC/Gateway VPX-Instanzen durchführt, sind keine zusätzlichen Ressourcen erforderlich, da alle HDX-Sitzungen über die VPXs vermittelt werden. JA - Heute verwendet der Gateway Service langlebige, ausgehende TCP-Verbindungen von den Cloud Connector-Instanzen zu Citrix Cloud, um HDX-Datenverkehr wieder in private Netzwerke zu führen. Dies erfordert zusätzliche Überlegungen zu Ressourcen bei der Dimensionierung und Konfiguration von Cloud Connector-Instanzen. In diesem Artikel finden Sie weitere Informationen. Hinweis: Diese Anforderung ist für die meisten Anwendungsfälle umstritten, sobald der Gateway-Dienst und die VDAs das Rendezvous-Protokoll/die Funktion verwenden können. Dies erfordert Citrix VDA 1912 oder neuer.
Möglichkeit zur Verwendung mit Citrix Cloud Government-Mandanten. JA - Sowohl lokale als auch AWS EC2-basierte ADC/Gateway/StoreFront-Bereitstellungen werden unterstützt. JA — Citrix Workspace ist in Citrix Cloud Government verfügbar.
Möglichkeit zur Unterstützung von Air-Gapped AWS-Clouds/-Umgebungen ohne ausgehende Internetverbindung. JA - Kundenverwaltete Bereitstellungen von ADC/Gateway (und StoreFront) werden sowohl für On-Prem- als auch für AWS EC2-basierte Instanzen unterstützt. NEIN - Air-Gapped AWS-Umgebungen haben keinen Zugriff auf Citrix Cloud oder Citrix Cloud Government, daher sind Gateway Service und Workspace Service derzeit nicht verfügbar.

Zusammenfassung, Empfehlungen und führende Praktiken

Nachdem wir nun einige der Attribute/Funktionen/Funktionen überprüft haben, die Ihnen helfen, von Kunden verwaltete und Cloud-Service-Entscheidungen für die Access Layer-Subsysteme zu treffen, lassen Sie uns die Entscheidungen auf oberster Ebene im Kontext der zuvor definierten Bereitstellungsmodelle untersuchen.

Zugriffsebene: Greenfield/Cloud Only Deployment

Da das Green-Field- oder Nur-Cloud-Bereitstellungsmodell Clouddienste auf der ganzen Linie verwendet, sind die AWS-spezifischen Auswirkungen auf das Design Ihres Citrix Virtualisierungssystems einfach: Es gibt keine. Es ist nicht notwendig, irgendetwas auf AWS zu erstellen oder zu konfigurieren, da alles, was sowohl für UI- als auch für HDX-Proxydienste erforderlich ist, für Sie bereitgestellt, konfiguriert und einsatzbereit ist.

Die Zugriffsebene einer Citrix-Bereitstellung ist eine wichtige Voraussetzung für die Bereitstellung virtueller Apps und Desktops für Benutzer. Wenn ein Access Point nicht erreichbar ist oder ausfällt, können Benutzer nicht auf ihre Ressourcen zugreifen. Netzwerkdesign und -implementierung können kompliziert sein, aber mit Citrix Gateway Service und Citrix Workspace sind Redundanz, Failover, Wartung und globale Präsenz Teil des Pakets - ohne Netzwerkkenntnisse erforderlich.Die Verwendung von Citrix Gateway Service und Citrix Workspace kann Ihre Infrastruktur-Fußabdruck im Wesentlichen. Durch das Verschieben der Zugriffsebene auf ein Clouddienste-Modell können Benutzer von überall auf der Welt sicher auf Netzwerkressourcen zugreifen. Dieser Ansatz erfordert den geringsten Bereitstellungs- und Wartungsaufwand. Daher ist er eine großartige Option, wenn Sie schnell einsatzbereit sein, ein begrenztes IT-Personal haben oder wenn die Infrastruktur nicht Ihr Fokus ist. Da alles vorkonfiguriert ist, ist dieses Bereitstellungsmodell am wenigsten anpassbar, aber für die Bereitstellung eines einfachen, sicheren, voll funktionsfähigen, global zugänglichen Systems ist die Verwendung von Citrix Workspace und Gateway Service für Ihre Zugriffsebene der richtige Weg.

Zugriffsebene: Hybrid-Bereitstellung

Mit dem hybriden Bereitstellungsmodell werden Sie einige der Komponenten des Citrix Virtualisierungssystems erstellen/verwalten, ansonsten handelt es sich per Definition um eine Green-Field- oder Cloud-Bereitstellung. Mit dem Hybridmodell stellen Sie möglicherweise Citrix ADC/Gateway VPXs auf AWS oder sogar on-premises bereit, und je nach Ihren Anforderungen stellen Sie Citrix StoreFront möglicherweise auch in AWS oder vor on-premises bereit. Kunden, die erhebliche Investitionen in ihre on-premises Gateway- und Identitätslösungen getätigt haben, können von der Möglichkeit profitieren, Citrix Gateway als Identitätsanbieter für Workspacezu verwenden.

Dieses Bereitstellungsmodell ist für sicherheitsorientierte Bereitstellungen, Bereitstellungen mit aktueller On-Prem-Infrastruktur (ADC oder StoreFront) und für DR/Failover-Standorte für vorhandene kundenverwaltete Rechenzentren üblich. Eine der wichtigsten Überlegungen für dieses Modell besteht darin, Ihre Benutzer, Ressourcen und Zugriffspunkte so nah wie möglich zusammenzuhalten. Wählen Sie AWS-Regionen in der Nähe der lokalen Ressourcenstandorte, an denen Sie Ihre Zugriffsebene bereitstellen möchten. Halten Sie Ihre ADCs und StoreFront-Server nach Möglichkeit so nah wie möglich beieinander. Dies ist, wo die Dinge schwierig werden können. Beachten Sie beim Entwerfen Ihrer Hybridbereitstellung die Startsequenz von Citrix Virtual Apps and Desktops und beachten Sie insbesondere, dass der gesamte Datenverkehr über den Citrix ADC geleitet wird.

Mit Citrix ADC/Gateway und StoreFront als EC2-basierten Instanzen in AWS besteht auch viel mehr Potenzial für Anpassungen. Zusätzlich zu den mehreren StoreFront-Stores, der Multifaktor-Authentifizierung und verschiedenen branchenführenden ADC-Funktionen können Hybridbereitstellungen auch native AWS-Services wie den Relational Database Service (RDS) und AWS Directory Services nutzen. Hybride Bereitstellungen bieten einen allmählicheren Cloud-Übergang und lassen Raum für Anpassungen der Architektur auf dem Weg, im Gegensatz zu Aufhebungs- und Verlagerungsmethoden.

Der hybride Ansatz erfordert ein höheres Maß an Fachwissen und eine erhöhte Vorlaufzeit für die Bereitstellung als das Nur-Greenfield/Cloud-Modell, kann jedoch als solider Übergang zwischen einer herkömmlichen Customer-Managed/On-Prem-Bereitstellung und einem reinen Cloud-Status dienen.

Zugriffsebene: Bereitstellung heben und verschieben

Mit dem Legacy-Lift-and-Shift-Bereitstellungsmodell stellen Sie sowohl Citrix ADC/Gateway VPXs als auch Citrix StoreFront auf AWS bereit oder verwenden möglicherweise vorhandene on-premises Bereitstellungen dieser Technologien für denselben Zweck wieder. Diese Art der Bereitstellung hat tendenziell die geringste Vorlaufzeit für Kunden mit vorhandenen Citrix Virtualisierungsumgebungen vor Ort und ist auch der einfachste Übergang aus Sicht des Betriebs und der Wartung. Mitarbeiter mit Erfahrung in der Verwaltung einer lokalen Umgebung haben eine kürzere Anlaufzeit mit dem Lift- und Shift-Deployment-Modell, da die Citrix Infrastruktur weitgehend unverändert bleibt. Speziell für die Zugriffsebene ist diese Methode unkompliziert und ermöglicht viele Anpassungen. Der Aufschwung und der Wandel ist ein großartiger erster Schritt für bestehende Bereitstellungen, die in die Cloud oder für neue oder in die Luft geschaltete AWS-Regionen gehen, kann jedoch in Zukunft ein Hindernis für die Einführung einer Cloud-Vorwärts-Architektur sein.

Citrix ADC/Gateway VPX auf AWS

Die Bereitstellung des Citrix ADC/Gateway in AWS unterscheidet sich von der on-premises Bereitstellung, obwohl Sie sie letztendlich selbst verwalten. Glücklicherweise ist die Bereitstellung von Citrix ADC/Gateway in AWS ausführlich dokumentiert. Wir empfehlen daher, die folgenden Ressourcen zu überprüfen, bevor Sie Ihr Design festigen und mit der Implementierung beginnen:

Während es potenzielle Varianten für eine Citrix ADC/Gateway VPX-Architektur in AWS gibt, zeigt das folgende Diagramm (aus dem Citrix ADC for Web Applications Quick Start Deployment Guide) eine Multi-AZ Citrix HA-Paar-Bereitstellung, wie sie von der Schnellstart-Vorlage bereitgestellt wird (mit Standard-Subnetzen/CIDR-Blöcken):

Diagramm 10: Konzeptionelle Architektur, Citrix ADC/Gateway VPX auf AWS mit HA über Availability Zones hinweg Diagramm 10: Konzeptionelle Architektur, Citrix ADC/Gateway VPX auf AWS mit HA über Availability Zones hinweg.

Wie in Citrix ADC VPX on AWS in Citrix Docs beschrieben, stehen zwei primäre Bereitstellungsoptionen zur Verfügung. Sie sind:

  • Standalone: Einzelne Instanzen von Citrix ADC/Gateway können als separate Entitäten bereitgestellt und verwaltet werden. Dies wird häufig für kleinere oder POC-Bereitstellungen verwendet, bei denen eine hohe Verfügbarkeit nicht erforderlich ist.

  • Hochverfügbarkeit: Dies ist das am häufigsten bereitgestellte Modell für Produktionsumgebungen: Paare von Citrix ADC/Gateway VPX-Instanzen können im nativen Citrix HA-Modus in AWS bereitgestellt werden. Bei älteren Firmware-Versionen wird das Paar in derselben AWS Availability Zone bereitgestellt. Beginnend mit der Citrix ADC 12.1-Firmware können hochverfügbare Paare von VPX-Appliances über Availability Zones (AZ) hinweg bereitgestellt werden. DieFunktionsweise von Hochverfügbarkeit in AWS erklärt den Unterschied zwischen der Bereitstellung eines ADC-Paars innerhalb derselben AZ und über AZs hinweg. Wir beschäftigen uns später in diesem Abschnitt eingehender mit dieser Option.

Während Citrix ADC VPX im Allgemeinen einzelne, duale oder mehrere NIC-Bereitstellungstypen unterstützt, empfiehlt Citrix, mindestens drei Subnetze für jeden ADC zu verwenden, wenn er in AWS bereitgestellt wird, mit einer Netzwerkschnittstelle in jedem Subnetz für optimalen Durchsatz und Datentrennung. Bei der Bereitstellung zur Unterstützung von Citrix Virtual Apps and Desktops ist der NSIP in der Regel mit dem “Private Citrix Infrastructure Subnet” verbunden, der SNIP ist an das “Private Citrix VDA-Subnetz” und das Citrix Gateway an das “Public Subnet” angeschlossen. Das folgende vereinfachte konzeptionelle Diagramm zeigt diese Konfiguration. Es zeigt eine einzelne VPX-Instanz in einer einzigen AZ - dieses Entwurfsmuster würde für eine Hochverfügbarkeitskonfiguration dupliziert (wahrscheinlich in einer zweiten AZ):

Abbildung 11: Citrix ADC VPX-Instanzschnittstellenzuordnung für CVAD/DaaS-Bereitstellungen Diagramm 11: Citrix ADC VPX-Instanzschnittstellenzuordnung für CVAD/DaaS-Bereitstellungen.

ADC Hochverfügbarkeit über Availability Zones

Wie bereits erwähnt, ist dies das gängigste Bereitstellungsmodell für Citrix Virtualisierungssysteme. Dieses Modell verwendet ein Paar Citrix ADC VPXs, die in Availability Zones bereitgestellt werden, indem entweder die native HA-Funktion (aktiv/passiv) von Citrix ADC oder eine Kombination der nativen Global Service Load Balancing (GSLB) - und IPSet-Features von Citrix ADC verwendet wird. Die letztere Option (die Anfang 2020 möglich wurde) ermöglicht eine aktive/aktive Konfiguration über AZs hinweg und Funktionen, indem sie es dem ADC ermöglicht, als autoritative DNS-Quelle zu fungieren. Diese neue Option/Architektur wird voraussichtlich für Public Cloud-Bereitstellungen beliebt sein, daher konzentrieren wir uns hier darauf.

Die domänenbasierten Dienste für Cloud-Load Balancer ermöglichen AutoDiscovery von dynamischen Clouddiensten. Durch die Bereitstellung von Citrix ADCs über mehrere AZs in einer aktiv-aktiven Konfiguration können Sie Cloud-Ressourcen in verschiedenen AZs verwenden, um High Availability/Disaster Recovery zu optimieren. Jede AZ kann Cloud-Ressourcen in der vertrauten Pod-Infrastrukturenthalten, um einfach verwaltete Updates, Patches und Skalierbarkeit für Erweiterungen zu ermöglichen. Detaillierte Informationen zum Einrichten von GSLB zwischen AWS AZs finden Sie in der Citrix-Dokumentation.

Diagramm 12: Verkehrsfluss vor und nach HA-Failover in Multi-AZ-HA-Bereitstellung Diagramm 12: Verkehrsfluss vor und nach HA-Failover bei Multi-AZ-HA-Bereitstellung.

Im vorherigen Diagramm können wir sehen, dass jeder ADC eine andere virtuelle Gateway-IP (VIP) hat. Dies ist charakteristisch für eine unabhängige Netzwerkkonfiguration (INC). Wenn sich VPXs in einem HA-Paar in verschiedenen Availability Zones befinden, muss der sekundäre ADC über einen INC verfügen, da er keine zugeordneten IP-Adressen, virtuellen LANs oder Netzwerkrouten gemeinsam nutzen kann. Das NSIP ist für jeden ADC in dieser Konfiguration unterschiedlich, während SNIPs und Load Balancing-VIPs eine spezielle Citrix ADC-Funktion namens IPSetoder virtuelle Multi-IP-Server verwenden, mit der Clients in verschiedenen Subnetzen eine Verbindung zu derselben Gruppe von Servern herstellen können. Mit IPSet können Sie jeder der primären und sekundären Instanzen eine private IP zuordnen. Eine öffentliche IP kann dann dem primären ADC des Paares zugeordnet werden. Im Falle eines Failovers ändert sich das öffentliche IP-Mapping dynamisch auf das neue Primäre. Bei GSLB-Bereitstellungen in AWS kann die Service-IP Teil des IPSets sowohl für IPv4- als auch für IPv6-Verkehr sein.

Weitere Informationen zum Hinzufügen eines Remote-Knotens zu einem ADC zum Erstellen eines INC-basierten HA-Paars finden Sie in den Citrix Dokumenten.

Citrix StoreFront auf AWS

Die Bereitstellung von Citrix StoreFront auf AWS unterscheidet sich nicht wesentlich von der on-premises Bereitstellung, und am Ende verwalten Sie auch alle Komponenten von StoreFront selbst. Allgemeine Überlegungen, die für alle Bereitstellungen gelten, einschließlich StoreFront on AWS, finden Sie unter Planen Ihrer StoreFront-Bereitstellung. Der Hauptunterschied besteht darin, dass Sie in der Regel mehrere StoreFront-Instanzen in einer StoreFront-Servergruppe in mehreren AWS-Verfügbarkeitszonen bereitstellen. Es ist wichtig zu beachten, dass die mit diesem Design aktivierten Funktionen von der Latenz zwischen AZs abhängen. Gemäß Plan your StoreFront Deployment/Scalabilitywerden StoreFront-Servergruppenbereitstellungen nur unterstützt, wenn Verbindungen zwischen Servern in einer Servergruppe eine Latenz von weniger als 40 ms (bei deaktivierten Abonnements) oder weniger als 3 ms (bei aktivierten Abonnements) aufweisen. Stellen Sie sicher, dass Sie die Latenzzeiten zwischen Instanzen in allen AZs messen, die Sie StoreFront hosten möchten, und Abonnements entsprechend aktivieren/deaktivieren.

Wir haben dies bereits in der Tabelle zu Benutzeroberflächendiensten und Authentifizierungsüberlegungen weiter oben in diesem Dokument erwähnt, aber es lohnt sich, noch einmal darauf hinzuweisen: Für Citrix DaaS-Umgebungen mit umfangreichen Anforderungen an die Ausfallsicherheit empfiehlt Citrix dringend, eine StoreFront-Implementierung in vollem Umfang nutzen zu können. über die Funktion Local Host Cache (verfügbar sowohl in CVAD- als auch in DaaS-Sitzungsvermittlungsinfrastrukturtypen). Für CVAD bietet dies Ausfallsicherheit bei einem Datenbankausfall. Für DaaS bietet diese Architektur Ausfallsicherheit für den Fall, dass Cloud Connectors die Citrix Cloud nicht erreichen können. In beiden Fällen können getrennte Benutzer während eines Ausfallszenarios weiterhin eine Verbindung zu neuen und bestehenden Sitzungen herstellen. Weitere Informationen, Einschränkungen und Auswirkungen der Aktivierung des lokalen Hostcache finden Sie unter Lokaler Hostcache (DaaS) und Lokaler Hostcache (CVAD).

Während wir uns mit dem Thema Resilienz befassen, empfiehlt Citrix auch, dass Ihre StoreFront-Implementierung mehrere AZs umfasst (wenn die AWS-Region mehrere AZs enthält), aber denken Sie daran, das ADC-Design zu berücksichtigen. Citrix ADC wird häufig vor StoreFront-Instanzen verwendet, um Lastenausgleich und zusätzliche Service-Ausfallsicherheit zu bieten.

Durch die Verwendung von Citrix Zoneskann StoreFront-Redundanz integriert werden, indem Satellitenzonen auf zwei oder mehr AZs in einer VPC mit einer einzigen Site verteilt werden. Die Verwendung von Zones ist eine großartige Möglichkeit, Ressourcen so nah wie möglich an den Benutzern zu haben und hochverfügbar zu sein. Satellite-Zonen enthalten StoreFront-Server, Delivery Controller und App/Desktop-Ressourcen und belassen der Primary Zone das vollständige Infrastruktur-Setup, einschließlich des Lizenzservers und von SQL. Dies ermöglicht die Skalierbarkeit der StoreFront-Web-Benutzeroberfläche und die Erstellung/Zerstörung von Zonen kann orchestriert werden. Wenn Sie die Zonen kleiner halten, ist eine optimale Ost-West-Skalierbarkeit möglich und reduziert die Auswirkungen im Falle eines Ausfalls.

StoreFront in AWS ist vollständig anpassbar, einschließlich vorgestellter App-Gruppen, Splash-Seite, Farbgebung und Logo sowie Apps und Desktops können am besten für Ihre spezifischen Anforderungen arrangiert werden. StoreFront in AWS erfordert auch die Aufrechterhaltung sachkundiger Administration und des Engineerings, kann jedoch eine leistungsstarke Web-Benutzeroberfläche bereitstellen, insbesondere wenn sie in den Citrix ADC integriert ist.

Überlegungen zur Ressourcenebene

Das Ressourcenebenendesign konzentriert sich auf Personalisierung, Anwendungen und Image-Design. In der Ressourcenebene interagieren Benutzer mit Desktops und Anwendungen. Bei der Bereitstellung eines Citrix Virtualisierungssystems auf AWS sind die wichtigsten Dinge zu beachten (abgesehen von all den “normalen” Dingen, die wir hier nicht behandeln werden):

  • CIFS-Speicherung und Datenreplikation - Unabhängig von den Tools, die Sie für die Verwaltung von Benutzerpersonalisierungseinstellungen (das Windows-Profil und die umgeleiteten Ordner der Benutzer) verwenden, müssen Sie über Windows-Dateifreigaben verfügen, auf denen sie gespeichert werden. Wenn Sie VDAs in mehreren Regionen haben (und Benutzer können auf Apps/Desktops in mehr als einer zugreifen), müssen Sie sich auch mit der Datenreplikation befassen. Viele Anwendungen verwenden auch Windows-Dateifreigaben, daher sind CIFS-Speicherung und Datenreplikation auch für diese wichtig.
  • Imagedesign - Citrix App Layering und Citrix Provisioning Services (PVS) unterstützen Amazon EC2 derzeit nicht - Kunden, die einen Ressourcenstandort in AWS hosten, verwenden Machine Creation Services für die Erstellung, Verwaltung und Aktualisierung von VDA-Flotten.

CIFS-Speicherung und Datenreplikation

Die meisten Citrix Virtualisierungssysteme in AWS benötigen mindestens grundlegenden Zugriff auf eine Windows-kompatible Dateifreigabe, um Benutzereinstellungen, Benutzerdaten und Anwendungsdaten zu speichern. Wenn diese Freigaben nicht verfügbar sind, leiden die Benutzererfahrung und die Anwendungsfunktionalität. Daher ist es wichtig sicherzustellen, dass jede Lösung, die Sie für die Bereitstellung von Windows-kompatiblen Dateifreigaben auswählen, hochverfügbar ist und die Daten regelmäßig gesichert werden.

Für Bereitstellungen an mehreren Standorten kann auch eine zuverlässige und performante Datenreplikation erforderlich sein, um die Verfügbarkeits-, RPO- und RTO-Anforderungen zu erfüllen. Dies gilt insbesondere für Umgebungen, in denen Benutzer in zwei oder mehr Regionen eine Verbindung zu Desktops/Apps herstellen können und Anwendungsdaten/Benutzereinstellungen in der Region verfügbar sein müssen, in der die Apps/Desktops ausgeführt werden. Im folgenden Abschnitt werden einige Lösungen beschrieben, die für die Bereitstellung von CIFS-Speicher- und Datenreplikationsdiensten in AWS in Betracht gezogen

Während Nicht-Windows-Lösungen für die Bereitstellung von Windows-Dateifreigaben existieren, können die meisten dieser Lösungen nicht die Indizierungsfunktionen bereitstellen, die für die Suchfunktion in einem Windows-Desktop oder Anwendungen wie Microsoft Outlook unter Windows erforderlich sind. Daher wenden sich die meisten Kunden an Windows-basierte Dateiserver-Lösungen, zumindest um Benutzerprofile und persistente Anwendungsdaten zu speichern. Glücklicherweise stehen sowohl von Kunden verwaltete als auch Clouddienst-Optionen zur Verfügung, wenn Citrix Virtualisierungssysteme auf AWS ausgeführt werden.

Kundenverwaltet: Windows-Dateiserver auf Amazon EC2

Die erste Lösung, die viele Kunden für die Bereitstellung von Windows-kompatiblen Dateiservices auf AWS in Betracht ziehen, besteht darin, ihre eigenen Windows-Dateiserver auf EC2 zu erstellen, um jeden Ressourcenstandort auf Da Windows-Dateiserver von verschiedenen Arten von Anwendungen und Workloads benötigt werden, können viele IT-Shops dazu tendieren, eigene zu erstellen und zu verwalten, da sie dies wissen. Auf der grundlegendsten Ebene stellt der Kunde eine oder mehrere Windows EC2-Instanzen zusammen, fügt zusätzliches Amazon Elastic Block Store (EBS) -Volume an, schließt die Instanz mit seinem Active Directory an und beschäftigt sich mit der Konfiguration und Einrichtung von Windows-Dateidiensten.

Diese Option bietet Kunden, wie Sie sich vorstellen können, die größte Kontrolle und Flexibilität. Dies ist zwar für bestimmte Arten von Kunden und bestimmten Branchen sehr attraktiv, aber auch mit Kosten verbunden: die Verantwortung für Größe, Skalierung, Aufbau, Verwaltung, Patch, Sicherung und Wartung von Windows aus. Kunden, die sich für diesen Weg entscheiden, sollten auch sicherstellen, dass diese Dateiserver hochverfügbar sind. Dies wird häufig durch Dateiserver in mehreren Availability Zones und unter Verwendung von Windows DFS-N/DFS-R erreicht, obwohl es einfach ist, in einer nicht unterstützten Konfiguration (per Microsoft) zu landen, wenn Sie nicht vorsichtig sind.

Hinweis: Kunden, die diese Option in Betracht ziehen, sollten die Support-Erklärung von Microsoft bezüglich der Verwendung von DFS-R und DFS-N für Roaming-Profilfreigaben und Ordnerumleitungsfreigaben lesen. Ein weiterer Punkt, den Sie berücksichtigen sollten, da das Citrix Virtualisierungssystem auf AWS ausgeführt wird: Ein neues Bereitstellungs- oder Migrationsereignis bietet möglicherweise eine hervorragende Gelegenheit, die Verwendung eines Clouddienstes für Windows-Dateidienste zu bewerten, anstatt eigene zu erstellen. Glücklicherweise hat Amazon einige Clouddienstoptionen, die in Betracht gezogen werden sollten. Wir gehen jetzt auf einige davon ein.

Cloud Service: Amazon FSx für Windows File Server

Der FSx für Windows File Server von Amazon ist ein Cloud-Service, den Kunden auf AWS nutzen können. FSx für Windows File Server bietet ein vollständig verwaltetes, natives Windows-Dateisystem und einen SSD-basierten Speicher mit konsistenter Leistung in einer Zwischenlandung. Da FSx auf Windows Server basiert, bietet es ein vollständig natives, Windows-kompatibles Dateisystem, das Speicher und Schutz für Citrix Virtualisierungssysteme auf AWS bietet. FSx für Windows File Server ist auch Citrix Ready Verified, was bedeutet, dass diese von AWS unterstützte Lösung von Citrix als kompatibel mit Citrix Virtual Apps and Desktops validiert wurde. Obwohl es nicht offiziell von Citrix unterstützt wird, ist der Dienst im grundsätzlich nativen Microsoft Windows-Dateiserver - er wird nur von AWS anstelle des Kunden verwaltet. Weitere Informationen finden Sie unter Amazon FSX für Windows File Server auf Citrix Ready.

Für IT-Teams ist dies eine hervorragende Option, die viele der alltäglicheren oder niedrigwertigen Aufgaben im Zusammenhang mit der Bereitstellung und Verwaltung von Speicher entfernt. Am wichtigsten ist, dass die Verwendung von FSx Sicherheits-, Datenschutz-/Backup-, Compliance-, Softwareupdate-/Patching-Aufgaben und die Überwachung der Speicherinfrastruktur auslagert, um sicherzustellen, dass sie die erforderlichen Service-Level erfüllt. IT-Teams können den gesamten FSx-Dateidienst als eine einzige Betriebsplattform behandeln, anstatt einen Dateiserver, Speicher, Networking und derart des Windows-Betriebssystems zu verwalten. Außerdem unterstützt FSx alle gängigen Verwaltungstools, die es bereits verwendet, wie die Integration von Active Directory (AD), Windows DFS-Namespaces, DFS-Replikation und andere.

Jedes FSx verwaltete Dateisystem, das Sie erstellen, wird im Wesentlichen zu einem hochverfügbaren und langlebigen Dateiserver in einer bestimmten Availability Zone. Für die Wartung eines Citrix Virtualisierungssystems sollten Kunden sicherstellen, dass diese “Dateisysteme” hochverfügbar sind. Dies kann erreicht werden, indem Sie von FSx verwaltete Dateisysteme in mehreren Availability Zones Provisioning und Windows DFS-N/DFS-R verwenden, um hochverfügbare Windows-Dateifreigaben zu erstellen, obwohl es einfach ist, in einer nicht unterstützten Konfiguration zu landen (per Microsoft), wenn Sie nicht vorsichtig sind.

Hinweis: Da es sich bei FSx um einen Windows-Dateiserver handelt, sollten Kunden, die diese Option in Betracht ziehen, die Support-Erklärung von Microsoft bezüglich der Verwendung von DFS-R und DFS-N für Roaming-Profilfreigaben und Ordnerumleitungsfreigaben lesen.

Weitere Clouddienst-Optionen

Neben dem von Amazon verwalteten Windows-Dateidienst von Drittanbietern unterstützt AWS viele umfangreichere und funktionsreichere Optionen, von denen einige in traditionelle on-premises Speichertechnologien integriert werden können. Während diese anderen Optionen außerhalb des Rahmens dieses Dokuments liegen, stehen viele Optionen zur Auswahl. Ein guter Ausgangspunkt, um Optionen zu erkunden, ist der AWS Marketplace. Diese Arten von Lösungen können besonders für komplexere Anwendungsfälle in mehreren Regionen relevant sein, in denen eine zuverlässige und belastbare Datenreplikation erforderlich ist.

CIFS-Speicherung und Datenreplikation: Zusammenfassung und Schlussfolgerungen

Kunden können ihre eigene hochverfügbare DFS-Dateifreigabe verwalten, davon als AWS-Service (FSx) profitieren, um Verwaltungsaufwand zu sparen, oder Speichergerätelösungen von Drittanbietern verwenden, um eine on-premises Umgebung zu erweitern. Citrix empfiehlt Kunden, die Vor- und Nachteile der einzelnen Kunden zu analysieren, um eine für sie richtige Lösung zu ermitteln.

Imagedesign und -management

In einem Citrix Virtualisierungssystem auf AWS werden Anwendungen und Desktops über EC2-Instanzen namens “VDAs” bereitgestellt (benannt nach der Virtual Delivery Agent-Software von Citrix, die in Windows- oder Linux-Instanzen installiert wird und die vom Citrix Virtualisierungssystem bereitgestellten Anwendungen enthalten). Eine Gruppe identischer VDAs wird in “Maschinenkatalogen” bereitgestellt und verwaltet, einem Managementkonstrukt, das über das Subsystem für Sitzungsvermittlung und -verwaltung (sowohl DaaS als auch CVAD) definiert und verwaltet wird. Die Erstellung, Dimensionierung und Verwaltung dieser Instanzen ist entscheidend, da viele Systeme eine große Anzahl von VDAs haben und sich der Software-Stack in einem VDA häufig ändert, wenn Hotfixes, Service Packs und Softwareupdates angewendet werden. Wir besprechen einige der übergeordneten Überlegungen in diesem Abschnitt.

VDA-Provisioning und Image-Management

Auf AWS EC2 verwenden Citrix Virtualisierungssysteme die Machine Creation Services (MCS) -Provisioning-Technologie von Citrix für die Bereitstellung und das Image-Management von VDA. MCS verwendet ein IAM-Dienstkonto auf EC2, um den Mastering-Prozess (Umwandlung eines Snapshots des Systemdatenträgers einer Vorlagen-VM in ein generalisiertes AMI), den Cloning-Prozess (Erstellen und Verwalten einer Flotte von VDA-Instanzen basierend auf dem AMI, das aus dem Snapshot der Vorlage VM erstellt wurde), Autoscaling Delivery Gruppen, Aktualisierung von bereitgestellten Images und mehr. Wir behandeln MCS in AWS in den Abschnitten zu Überlegungen zur Control Layer in diesem Dokument viel ausführlicher.

Hinweis: Kunden, die MCS bereits für ihre on-premises Umgebungen verwenden, können einige Unterschiede zwischen den Optionen feststellen, die ihnen bei der Provisioning von Maschinen in AWS zur Verfügung stehen. Von MCS verwaltete VDA-Instanzen auf EC2 haben zwei Datenträger: der Systemdatenträger (eine Lese-/Schreibkopie des während des Mastering-Prozesses erstellten Vorlagenimage) und eine 1-GB-Personalitydatenträger. Abhängig vom Maschinenkatalogtyp und den konfigurierten Hosting-Verbindungsoptionen wird der Systemdatenträger (und manchmal die VM-Instanz) beim Herunterfahren gelöscht und beim Einschalten neu erstellt (für gepoolte oder gemeinsam genutzte Kataloge) oder sie werden beibehalten (für persistente Katalogtypen). Weitere Informationen finden Sie unter CTX234562 .

Liefer- und Persistenzmodelle

Die Wahl der richtigen Bereitstellungsmodelle ist entscheidend und hat weitreichende Auswirkungen, die über die Kosten hinausgehen. Die Citrix Virtualisierungstechnologie unterstützt drei Hauptbereitstellungsmodelle, die gemischt und angepasst werden können und in Kombination zur Unterstützung vieler verschiedener Anwendungsfälle verwendet werden können. Die drei Bereitstellungsmodelle sind:

  • Gehostet geteilt: Das gehostete freigegebene Modell verwendet am häufigsten ein Windows Server-Betriebssystem mit der installierten RDSH-Rolle, obwohl Linux-Instanzen die gleiche Funktionalität für kompatible Apps bereitstellen können. Mit diesem Modell kann eine einzelne VDA-Instanz mehrere gleichzeitige Benutzer unterstützen, von denen jeder entweder einen vollständigen Desktop ausführt oder eine Verbindung zu einer oder mehreren veröffentlichten Anwendungen herstellt. Bei der Verwendung von Windows Server OS/RDSH mit dem Desktop Experience und den zugehörigen Komponenten sehen Desktops und Apps das Gefühl aus, als würden sie auf einem Windows-Desktop-Betriebssystem ausgeführt. Da jeder Benutzer auf einer bestimmten Instanz die Betriebssysteminstanz gemeinsam nutzt, installieren und konfigurieren Administratoren in der Regel die Mischung aus Anwendungen auf gehosteten gemeinsam genutzten Instanzen, und Benutzer haben keine lokalen Administratorrechte für das Betriebssystem. Gehostete freigegebene Instanzen können auch auf gemeinsam genutzter Infrastruktur ausgeführt werden und sowohl mit On-Demand- als auch Reserved Instanz-Preismodellen verwendet Administratoren stellen in der Regel eine Flotte von Instanzen bereit, um das gehostete freigegebene Modell zu unterstützen, und sowohl vom Kunden verwaltete als auch Clouddienst-Typen von Citrix Brokering-Subsystemen bieten ausgefeilte Lastenausgleichsfunktionen, um sicherzustellen, dass jeder Benutzer Gehostete freigegebene Instanzen können auch GPU-gestützte Instanz-Typen in AWS verwenden, um die Leistung für grafikintensive Workloads zu erhöhen, die von einer GPU profitieren können, obwohl der GPU-Anbieter zusätzliche Lizenzen benötigen kann. Sowohl Windows Server-Betriebssystem- als auch RDS-CAL-Lizenzen können unter dem SPLA-Lizenzierungsmodell von Microsoft “gemietet” werden, obwohl Kunden diese zusätzlichen Kosten vermeiden können, indem sie Linux als Betriebssystem verwenden. Dieses Modell ist zweifellos das kostengünstigste für die Ausführung auf AWS.
  • Server-VDI: Das Modell “Server VDI” (Virtual Desktop Infrastructure) verwendet auch ein Windows-Server-Betriebssystem, und wenn Desktop Experience und zugehörige Komponenten installiert sind, sieht es für den Benutzer wie ein Windows-Desktop-Betriebssystem aus und fühlt es sich an. Die RDSH-Rolle wird nicht mit diesem Modell installiert, daher unterstützt eine Instanz jeweils einen Benutzer, und Benutzern werden manchmal erweiterte Rechte für das Serverbetriebssystem bereitgestellt, damit sie ihre eigenen Anwendungen installieren können. Wie gehostete freigegebene Instanzen können Server-VDI-Instanzen auch auf gemeinsam genutzter Infrastruktur ausgeführt werden, können sowohl On-Demand- als auch Reserved Instanz-Preismodelle verwendet werden, mit GPU gesicherte Instanz-Typen verwenden, und Microsoft OS- und RDS-CALs können unter dem SPLA-Lizenzmodell von Microsoft “vermietet” werden. Angesichts der heute verfügbaren Tools können 99+% der Windows-Anwendungen auf dem Windows-Serverbetriebssystem installiert und ausgeführt werden, und obwohl Softwarehersteller ihre Anwendungen auf Windows Server manchmal nicht explizit unterstützen, laufen die meisten Windows-Apps genauso gut auf Windows Server wie auf einem Windows-Desktop-Betriebssystem. Es ist auch erwähnenswert, dass Server-VDI-Instanzen auch GPU-gestützte Instanz-Typen in AWS verwenden können, um die Leistung für grafikintensive Workloads zu steigern, die von einer GPU profitieren können, obwohl der GPU-Anbieter möglicherweise eine andere Lizenz benötigt. Dies ist das zweiteffektivste Bereitstellungsmodell, das auf AWS läuft.
  • Client-VDI: Das Client-VDI-Bereitstellungsmodell verwendet normalerweise ein Windows-Desktopbetriebssystem wie Windows 10 oder Windows 7, obwohl auch eine unterstützte Linux-Betriebssystemversion verwendet werden kann. Client-VDI ist ein 1:1 -Modell, was bedeutet, dass jeder einzelne Benutzer seine eigene Betriebssysteminstanz benötigt. Kunden, die mit der Citrix Virtualisierungstechnologie noch nicht eingesteckt sind, kommen häufig in diese Art von Projekten, die nach Client-VDI fragen, obwohl kostengünstigere Modelle verfügbar sind. Ihre Umgangssprache kann auch von anderen Virtualisierungsanbietern beeinflusst worden sein, deren Technologie-Stacks keine gehosteten Shared- oder Server-VDI-Bereitstellungsmodelle unterstützen. Das Client-VDI-Modell sieht zwar oberflächlich “einfacher” aus, wird jedoch viel komplizierter, je tiefer Sie damit einsteigen, obwohl der größte Teil der Komplexität durch die Verwendung von Linux als Betriebssystem vermieden werden kann. Die meisten dieser Komplikationen beruhen auf den Lizenzanforderungen von Microsoft für das Windows-Desktopbetriebssystem, das im Gegensatz zu Windows Server nicht über das SPLA-Lizenzierungsprogramm von Microsoft verfügbar ist. Daher müssen Kunden ihre eigene Lizenz für diese Produkte mitbringen. Außerdem können Desktop-basierte Client-VDI-Instanzen auf einer gemeinsam genutzten Infrastruktur nicht ausgeführt werden. Dies bedeutet, dass Client-VDI-Instanzen entweder in dedizierten AWS-Instanzen oder auf dedizierten AWS-Hosts Dies erhöht die Kosten und die Komplexität der Verwaltung der erforderlichen Infrastruktur erheblich, reduziert die Flexibilität und die Kostensteuerungsoptionen und wird schnell teuer. Wie zu erwarten, können Client-VDI-Instanzen auch GPU-gestützte Instanz-Typen in AWS verwenden, um die Leistung für grafikintensive Workloads zu erhöhen, die von einer GPU profitieren können, obwohl der GPU-Anbieter mehr Lizenzen benötigen kann. Client-VDI ist das teuerste Bereitstellungsmodell für die Ausführung auf AWS. Für beide VDI-Modelle ist das Persistenzmodell eine weitere wichtige Überlegung. VDI-Instanzen können nach dem Zufallsprinzip Benutzern ohne Persistenz (gepoolt) zugewiesen werden, oder Benutzer können Maschinen zugewiesen haben, die bestehen bleiben und personalisiert (dediziert) sind. Gepoolte Instanzen können im Laufe der Zeit einfacher zu verwalten sein, da alle Instanzen in einem bestimmten Pool identisch sind. Der MCS von Citrix kann die an gepoolten Instanzen angeschlossenen Systemdatenträger mit wenigen Klicks aktualisieren, und das Kapazitäts-/Kostenmanagement ist effektiver, da ein ungenutzter Instanz-Pool vielen Benutzern dienen kann. Gepoolte Instanzen sind etwas weniger flexibel als dedizierte, da Endbenutzer-Änderungen an gepoolten Instanzen normalerweise zwischen Neustarts nicht bestehen, obwohl Technologien wie die Benutzerlayer von Citrix App Layering oder der in CVAD 1912 veröffentlichte Personalisierungslayer verwendet werden können, um die Auswirkungen auf die Benutzererfahrung zu minimieren. Dedizierte Instanzen können auch aus Kostensicht schwieriger zu verwalten sein - da es oft schwierig ist, vorherzusagen, wann sich ein Benutzer anmelden wird, muss der Benutzer entweder warten, während seine Instanz gestartet wird, oder Administratoren müssen sie in Zeitfenstern laufen lassen, in denen jeder Benutzer sich anmelden soll.

Obwohl wir es bereits erwähnt haben, werden wir es hier aus Gründen der Übersichtlichkeit noch einmal erwähnen: Verschiedene Arten von Linux können in einem Citrix Virtualisierungssystem verwendet werden, solange eine oder mehrere Anwendungen unter Linux laufen. Die Virtualisierungstechnologie von Citrix unterstützt sowohl gehostete Shared- und VDI-Bereitstellungsmodelle, persistente und gepoolte Modelle als auch GPU-gestützte Instanz-Typen. Die Benutzer- und Administratorerfahrungen unterscheiden sich von den auf Windows-basierten Instanzen, aber Linux-basierte VDAs sind oft viel kostengünstiger in der Ausführung, da sie keine Microsoft-Lizenzen benötigen.

Lassen Sie uns abschließend die Überlegungen zur GPU-Beschleunigung noch einmal überdenken. Alle drei Bereitstellungsmodelle (sowohl für Linux als auch für Windows) können NVIDIA-beschleunigte GPU-Instanzen in AWS verwenden. Instanzen der G-Serie können für grafikbeschleunigte Anwendungsfälle verwendet werden, sind jedoch noch nicht für den allgemeinen Gebrauch geeignet. Beachten Sie, dass Citrix die AWS Elastic GPU heute nicht unterstützt, aber da Elastic GPU nur für OpenGL funktioniert, sind ihre Auswirkungen auf typische Grafik-Workloads im Unternehmen minimal.

Also - welche Liefermodelle verwenden Sie? Es ist erwähnenswert, dass Sie Bereitstellungsmodelle im selben System kombinieren und abgleichen können, um die Anforderungen verschiedener Benutzergruppen oder Anwendungsfälle zu erfüllen. Das kostengünstigste Bereitstellungsmodell aus Sicht der Infrastruktur ist Hosted-Shared. Die Kombination von Serverbetriebssystem mit Multi-User-Parallelität ist hocheffizient, und die Anzahl der Benutzer pro virtueller Maschine kann je nach Benutzertyp (z. B. Sachbearbeiter vs. Wissensarbeiter vs. Power User) für eine gute Benutzererfahrung dimensioniert werden. In Situationen, in denen Benutzer und Apps zusätzliche Funktionen benötigen, die durch gehostetes Shared nicht zufrieden sind, ist VDI der richtige Weg. Server-VDI sollte zuerst bewertet werden: Die Ausführung ist wesentlich kostengünstiger als Windows 10 VDI für Windows-Arbeitslasten, und Server VDI kann einen Desktop bereitstellen, der Windows 10 ähnlich sieht und sich anfühlt. Außerdem hat der Server-VDI nicht die Microsoft EULA-Anforderung, dedizierte Instanzen/Hosts zu verwenden - Client VDI (Bereitstellung von Windows 10 oder manchmal Windows 7). Bei Windows-basierten Workloads auf AWS sollte der Client-VDI als letztes Mittel betrachtet und nur bereitgestellt werden, wenn gehostete Shared- und Server-VDI-Bereitstellungsmodelle nicht möglich sind.

Um den Entscheidungsprozess zu unterstützen, werden in der folgenden Entscheidungsstruktur Hosted Shared Desktops (Server OS Mehrbenutzer-Desktops) mit VDI-Desktopsverglichen. Die Struktur unterscheidet nicht explizit zwischen Client-VDI- und Server-VDI-Modellen. Wenn ein Anwendungsfall darauf hindeutet, dass VDI das geeignete Bereitstellungsmodell für Ihre Arbeitslast ist, sollte Server VDI nach Möglichkeit für die Ausführung auf AWS in Betracht gezogen werden, da es wesentlich kostengünstiger und einfacher zu verwalten ist.

AWS-Instanzabrechnungsmodell

Sobald Sie sich entschieden haben, welches Bereitstellungsmodell verwendet werden soll (Hosting Shared, Server VDI oder Client VDI), besteht der nächste Schritt darin, ein stündliches On-Demand-Abrechnungsmodell oder ein reserviertes Abrechnungsmodell zu planen. Idealerweise sind so viele VDAs wie möglich stundenweise mit dem On-Demand-Abrechnungsmodell zu bezahlen und die Citrix Autoscale-Funktion zur Kostenkontrolle zu verwenden. Durch die Verwendung von Citrix Autoscale (einer Funktion, die exklusiv für das DaaS-Cloudservice-Brokering-Subsystem verfügbar ist) werden VMs bei Bedarf mit Vorwegnahme auf Spitzenzeiten eingeschaltet. Zu Stoßzeiten werden VMs jedoch heruntergefahren, daher ist es wichtig, Lasten mit dem Hosted-Shared-Modell zu konsolidieren und für alle Modelle sicherzustellen, dass Benutzer ihre Arbeit speichern und sich idealerweise ordnungsgemäß von ihren Sitzungen abmelden. Reservierte Instanz-Kapazität kann für Infrastrukturkomponenten wie die Cloud Connectors (die rund um die Uhr verbleiben) und eine vorbestimmte Anzahl von VDAs verwendet werden, die immer eingeschaltet bleiben (z. B. 10% der Spitzenkapazität). Neben der Bereitstellung eines erheblichen Rabatts im Vergleich zu On-Demand-Preisen bieten Reserve Instanzen auch eine Kapazitätsreservierung, wenn sie in einer bestimmten Verfügbarkeitszone.

VDA Instanzdimensionierung und Kostenmanagement

Wenn Sie eine Flotte von VDAs in AWS ausführen, ist die Auswahl des richtigen Instanz-Typs für Ihre verschiedenen Workloads (VDAs) eine wichtige Entscheidung mit erheblichen Überlegungen zu Leistung, Verwaltbarkeit und Kosten. Wählen Sie eine zu kleine Instanz und die Leistung kann darunter leiden. Wählen Sie eine zu große Instanz, und Sie zahlen für Ressourcen, die Sie nicht verwenden. Die Wahl des richtigen Instanztyps ist letztendlich ein Balanceakt und erfordert häufig eine Feinabstimmung für jede spezifische Arbeitslast.

Welcher AWS EC2-Instanz-Typ für Ihre VDAs zu wählen ist, hängt stark von der jeweiligen Arbeitslast und der Art der Bereitstellung ab. Als allgemeine Richtlinie eignen sich “M”-Serien-Instanzen jedoch häufig am besten für Hosted-Shared, während Instanzen der T-Serie für VDI geeignet sind. Die “M” -Serie verfügt über eine ausgewogene CPU und einen ausgewogenen Arbeitsspeicher, die für den größtenteils vorhersehbaren Ressourcenverbrauch in mehreren Sitzungen auf einem Host vorgesehen sind. Die “T” -Serien sind in der Natur “belastbar”, die auf die meist unvorhersehbaren Eigenschaften von VDI ausgelegt ist (zum Beispiel - eine Minute läuft ein Benutzer im Leerlauf und in der nächsten führt er eine Makroberechnung durch). Weitere Informationen zur Auswahl des Instanztyps und zur Preisgestaltung finden Leser in der Präsentation zur Kostenschätzung von Citrix on AWS (im Abschnitt Quellen).

Weitere Informationen zur Instanzauswahl (insbesondere in Bezug auf das Modell der gehosteten gemeinsamen Bereitstellung) finden Sie unter Citrix Scalability in a Cloud World — Edition 2018. In diesem Artikel werden zwar etwas veraltet, werden jedoch führende Praktiken in Bezug auf die Instanz-Auswahl auf der Grundlage von Leistung, Verwaltbarkeit, Kosten, reservierten vs. On-Demand-Preismodellen und LoginVSI-Skalierbarkeitstests beschrieben. Diese Konzepte und Überlegungen sind auch heute noch gültig, obwohl sich die Auswahl und die Preisgestaltung der Instanzen seit ihrer ersten Veröffentlichung wahrscheinlich geändert haben.

Hinweis: Einige neuere AWS-Instanztypen werden standardmäßig nicht im Assistenten zur Erstellung von Maschinenkatalogen in Studio angezeigt (entweder CVAD oder DaaS). Die Benutzeroberfläche wird mit Instanztypen aus einer statischen XML-Datei gefüllt, die sich auf Delivery Controllern (CVAD) oder Cloud Connectors (DaaS) befindet. Dieses XML kann geändert werden, um neuere Instanz-Typen aufzunehmen, aber diese Datei wird bei Upgrades mit Standardwerten überschrieben (sowohl von Citrix initiierte Cloud Connector-Updates als auch vom Kunden initiierte Delivery Controller-Upgrades). Weitere Informationen zur Aktualisierung der Liste der verfügbaren AWS-Instance-Typen finden Sie unter CTX139707. In dieser Testrunde (ein Referenzzeitpunkt) erwies sich der Instance-Typ M5.2Xlarge (8 vCPU, 32 GB RAM) als Sieger in Bezug auf $/Benutzer/Stunde (mit einer Beispielarbeitslast nach Industriestandard). Ihre Zahlen können - angesichts Ihrer spezifischen Arbeitslasteigenschaften und der verfügbaren AWS-Preise - variieren, aber der Prozess und die Werkzeuge können verwendet werden, um Ihre monatlichen IaaS-Kosten genauer anzunähern. Unabhängig davon, wie Sie die Instanz-Typen bestimmen, mit denen Sie beginnen, ist es wichtig, die Nutzung im Laufe der Zeit zu überwachen und nach Bedarf anzupassen, um das Gleichgewicht zwischen Ressourcenverfügbarkeit, Verbrauch und Kosten zu erhalten. Kunden sollten in Betracht ziehen, Dienste wie Citrix Analytics for Performance zu verwenden - die Informationen, die diese Dienste liefern, können eine wichtige Rolle dabei spielen, die Leistung zu steigern und die Kosten zu senken.

Anwendungs-Design

Eine zusätzliche Überlegung umfasst das Anwendungsdesign. Da Kunden beabsichtigen, Workloads auf eine Cloud-Plattform wie AWS zu migrieren, müssen sie sicherstellen, dass die App-Leistung nicht beeinträchtigt wird. Eine Faustregel, die seit über 20 Jahren gilt, ist, dass sich die Daten so nahe wie möglich an der Arbeitsbelastung befinden sollten. Dies bedeutet, dass komplexere Anwendungsarchitekturen diese Regel einhalten sollten. Ein Beispiel hierfür sind Apps mit einem Front-End und Back-End (Datenbank). Um eine zusätzliche Latenz zu vermeiden, die sich auf die Anwendungsleistung auswirkt, müssen sowohl das Front-End als auch das Back-End migriert werden. Eine Alternative wäre ein hybrider Ansatz, der eine Mischung aus on-premises (für komplexe Apps) und Cloud-gehosteten Workloads (für einfache Anwendungen) verwendet. Es ist wichtig, sich immer mit Anwendungsanbietern in Verbindung zu setzen, um die Kompatibilität zu erhalten. Die verknüpfte Tech Zone-Entscheidungsmatrix vergleicht die verschiedenen Hosted Shared Delivery-Methoden, die Hosted Shared Applications (Single- und Multiuse) und Hosted Shared Desktops umfassen Der Entscheidungsfindungsprozess für die Workload-Segmentierung in diesen Artikelskizzen kann als Leitfaden für den Workload-Designprozess verwendet werden.

Ein letztes Wort zum Anwendungsdesign: Die Enterprise Layer Manager-Appliance wird derzeit nicht auf AWS ausgeführt und unterstützt derzeit nicht das Exportieren von Layerimages in ein sofort verbrauchbares Datenträgerformat für die Verwendung in AWS. Wenn die Unterstützung von App Layering in AWS für Ihre Migration oder Bereitstellung von entscheidender Bedeutung ist, senden Sie eine E-Mail an aws@citrix.com mit Informationen zu Ihrem Projekt. Sie werden der Liste hinzugefügt, um ein Early Adopter Kandidatin für zukünftige Veröffentlichungen zu sein, und Ihre Stimme wird gehört. Weitere Informationen zu Citrix App Layering finden Sie in der Produktdokumentation und in der App Layering-Referenzarchitektur.

Überlegungen zu Steuerungsebene

Im Citrix Architectural Design Framework definiert die Steuerungsebene die Komponenten, die die Citrix Lösung steuern. Dies umfasst Komponenten wie Active Directory (Forst/Domäne, Organisationseinheit und Benutzergruppenstruktur, Gruppenrichtlinien usw.), Microsoft SQL-Datenbank-Nutzung, Citrix Lizenzierung, Session Brokering und Administration, Load Management und VDA-Bereitstellung/Image-Management. Wie in den vorherigen Abschnitten dieses Dokuments konzentrieren wir uns hier auf die Überlegungen, die für Citrix Virtualisierungssysteme in AWS am wichtigsten sind, und stellen Links zu bestehenden Dokumentationen/Anleitungen zu anderen bereit.

Eine der wirkungsvollsten Entscheidungen, die Sie für Komponenten der Steuerungsebene treffen, ist die Wahl des Sitzungsbrokerings und der Administration. Diese Entscheidung ist von entscheidender Bedeutung, mit erheblichen Auswirkungen auf Kosten, Komplexität, Verfügbarkeit und laufende Wartungsarbeiten. Wir beginnen mit der Überprüfung der Bereitstellungsmodelle, die wir zuvor in diesem Dokument eingeführt haben, und gehen dann tiefer auf die spezifischen Überlegungen von AWS ein.

Steuerungsebene: Greenfield/Cloud Only Bereitstellung

Das Grünfeld- oder Nur-Cloud-Bereitstellungsmodell verwendet Clouddienste auf breiter Bauteil. n). Die AWS-spezifischen Auswirkungen auf das Design Ihres Citrix Virtualisierungssystems sind minimal, aber wir führen Sie trotzdem durch sie. Da Citrix Cloud die meisten Infrastruktur- und Verwaltungskomponenten als Service bereitstellt, müssen Sie sich keine Gedanken über SQL-Datenbanken, Citrix Lizenzserver, Citrix Director-Server und mehr machen.

Steuerungsebene: Hybrid-Bereitstellung

Denken Sie daran, dass Sie mit dem hybriden Bereitstellungsmodell einige der Komponenten des Citrix Virtualisierungssystems erstellen/verwalten werden, andernfalls handelt es sich per Definition um eine Green Field- oder Cloud-Bereitstellung. Das Interessante hier ist, dass sie im Kontext der Steuerungsebene fast identisch sind.

Steuerungsebene: Lift and Shift-Bereitstellung

Mit dem Legacy-Lift-and Shift-Bereitstellungsmodell stellen Sie alle wichtigen Komponenten der Steuerungsebene (einschließlich Active Directory und aller Komponenten Citrix Sitzungsvermittlung und -verwaltung) auf AWS bereit. Wenn Sie den Weg “Heben und Verschieben” hinuntergehen müssen, ist dies sowohl ein Segen als auch ein Fluch. Es ist ein Segen, da die meisten dieser Überlegungen in verschiedenen veröffentlichten Arbeiten, die bereits verfügbar sind, gründlich dokumentiert wurden. Es ist ein Fluch darin, dass Sie viel mehr Arbeit haben werden, sowohl im Voraus als auch im Laufe der Zeit zu tun, um diese Komponenten zu erstellen, zu verwalten, zu sichern und zu warten.

Wenn Sie ein “Lift and Shift” -Er sind, möchten Sie Folgendes überprüfen und referenzieren: Gemeinsam decken sie die meisten Designentscheidungen ab, die Sie für die erfolgreiche Bereitstellung von Citrix in AWS mit dem Lift and Shift-Deployment Modell berücksichtigen müssen:

Überlegungen zu Active Directory

Alle Bereitstellungsmodelle für Citrix Virtualisierungssysteme in AWS erfordern Microsoft Active Directory. Für eine überzeugende Benutzererfahrung müssen funktionale Active Directory-Dienste in jeder AWS-Region verfügbar sein, in der VDAs bereitgestellt werden. Die Struktur und Komplexität Ihrer Active Directory-Implementierung muss sorgfältig abgewogen werden, aber glücklicherweise kann sich die Citrix Virtualisierung flexibel in verschiedene AD-Designs und Wartungsmodelle integrieren.

Bei der Bereitstellung von Active Directory in AWS können Kunden ihre eigenen Active Directory-Domänencontroller mithilfe von Windows Server-Instanzen erstellen/warten, den AWS Directory Service for Microsoft Active Directoryoder eine Kombination aus beiden verwenden. Active Directory-Trusts können je nach Kundenwunsch auch verwendet werden, um zwei oder mehr AD-Wälder/Domains zu verbinden.

Für Kunden, die den Verwaltungsaufwand für den Aufbau und die Wartung funktionaler Active Directory-Dienste minimieren möchten, ist der AWS Directory Service for Microsoft Active Directory (auch bekannt als AWS Managed Microsoft AD) eine Option, die eine Überlegung wert ist. Dieser Service bietet Ihnen eine voll funktionsfähige Active Directory-Forst-/Domäne ohne den Aufwand für die Erstellung und Wartung von Windows Server-VM-Instanzen. AWS Managed Microsoft AD basiert auf einer hochverfügbaren, von AWS verwalteten Infrastruktur. Jedes Verzeichnis wird in mehreren Availability Zones bereitgestellt, und die Überwachung erkennt und ersetzt automatisch Domänencontroller, die ausfallen. Darüber hinaus werden Datenreplikation und automatisierte tägliche Snapshots für Sie konfiguriert. Sie müssen keine Software installieren, und AWS wickelt alle Patches und Softwareupdates ab. Mit AWS Managed Microsoft AD können Sie native Microsoft-Verwaltungstools verwenden, Windows-Maschinen und Benutzer mit Microsoft Group Policy verwalten, EC2-Instanzen und AWS RDS für SQL Server-Instanzen beitreten und sogar Active Directory-Vertrauenswürdigen mit vorhandenen AD-Instanzen einrichten, um verschiedene komplexe Unternehmensszenarios zu unterstützen.

Kunden, die sich dafür entscheiden, den AWS Managed Microsoft AD-Service mit Citrix Virtualisierungstechnologien zu nutzen, können davon ausgehen, dass diese Technologien mit diesem AWS-Service funktionieren, obwohl zuvor einige wichtige Überlegungen zu berücksichtigen sind. Für den Anfang - Sie haben keinen Zugriff auf die AD-Instanz vom Typ Domain Administrator, Enterprise Administrator oder anderen “Superuser”. Sie haben jedoch die volle Kontrolle über Ihren eigenen Container im Stammverzeichnis, in dem Sie Benutzer, Computer, Gruppen, Organisationseinheiten und Gruppenrichtlinien erstellen können.

Ein paar andere Dinge, die Sie NICHT können:

  • Erstellen Sie AD-Objekte in einem der Standardcontainer (z. B. /Computers): sie sind schreibgeschützt. Dies führt zu einem häufigen Fehler, den einige Kunden machen, wenn sie die MCS-Provisioning-Technologie von Citrix verwenden: Sie müssen sich dafür entscheiden, die Maschinenkonten für Ihre von MCS-verwalteten VDAs in einem beschreibbaren Container/OU zu erstellen. Wenn Sie sich nicht für einen solchen Standort entscheiden, kann MCS die Maschinenkonten nicht erstellen.
  • Installieren und konfigurieren Sie einige integrierte AD-Funktionen wie Zertifikatdienste. Dies wirkt sich auf Kunden aus, die die Federated Authentication Services (“FAS”) -Technologie von Citrix verwenden werden (für die integrierte AD Certificate Services erforderlich sind): Diese Kunden müssen ihr eigenes Active Directory auf AWS mit EC2-Windows Server-Instanzen erstellen und verwalten.
  • Haben Sie standardmäßig die Äquivalenz des lokalen Serveradministrators. In einer Active Directory-Installation “out of the box” wird die Gruppe Domänenadministratoren standardmäßig zur lokalen Gruppe Serveradministratoren hinzugefügt. Wenn Sie den AWS Managed Microsoft AD-Dienst verwenden, müssen Sie Ihre eigene Serveradministratorengruppe erstellen, Ihre eigenen Benutzer hinzufügen, eine Gruppenrichtlinie erstellen und anwenden, um Ihre Gruppe zur integrierten Serveradministratorengruppe auf Mitgliedsserver/Workstations hinzuzufügen.

Während Vertrauensbeziehungen, Standort-/Dienstkonfiguration, Replikation und andere AD-bezogene Themen in diesem Papier nicht behandelt werden, hat Citrix eine umfassende Dokumentation zu diesen Themen für alle drei Bereitstellungsmodelle bereitgestellt.

**Hinweis: ** AWS Directory Service for Microsoft Active Directory ist ein “Citrix Ready Verified” -Angebot. Obwohl der Service nicht offiziell von Citrix unterstützt wird, ist er grundsätzlich natives Microsoft Active Directory - er wird nur von AWS anstelle des Kunden verwaltet. Für diesen AWS-Service gelten einige Einschränkungen, um ihn als Service in großem Maßstab bereitzustellen, und die derzeit bekannten/wirkungsvollsten Einschränkungen für eine Citrix-Umgebung sind hier aufgeführt. Weitere Informationen zu den Anforderungen von Active Directory für Green Field- und Hybridbereitstellungen (Umgebungen mit Citrix Cloud und dem CVAD-Dienst für Sitzungsvermittlung und -verwaltung) finden Sie in den technischen Details zu Citrix Cloud Connector. In diesem Artikel werden nicht nur die unterstützten Active Directory-Funktionsebenenbehandelt, sondern auch Bereitstellungsszenarien für Cloud Connectors in Active Directorybehandelt.

Weitere Informationen zu den Active Directory-Anforderungen für Lift-and-Shift-Bereitstellungen (Umgebungen mit kundenverwalteter Sitzungsvermittlung und Verwaltung über Citrix Virtual Apps and Desktops LTSR- oder CR-Versionen) finden Sie unter CVAD-Systemanforderungen, Active Directory-Funktionsebenen.

Überlegungen zur Session Brokering und Administration

Wie Sie wahrscheinlich bereits gesammelt haben, ist die Wahl, wie Sie Session Brokering- und Administrationsdienste anbieten, von entscheidender Bedeutung und hat weitreichende Auswirkungen auf die Gesamtkosten, Verwaltbarkeit, Wartung und verfügbaren Funktionen für Ihr Citrix Virtualisierungssystem. Wie bereits erwähnt, empfiehlt Citrix die Verwendung des Citrix Cloud-Dienstes (DaaS) für diese wichtige Komponente. Für bestimmte Anforderungen und Szenarien kann jedoch die Bereitstellung eines vom Kunden verwalteten Subsystems für Sitzungsvermittlung und -verwaltung (über CVAD LTSR- oder CR-Versionen) erforderlich oder empfohlen werden. In der folgenden Tabelle werden einige dieser Anforderungen und Szenarien für Sie aufgeführt:

Attribut/Capability Kundenverwaltetes CVAD (Citrix Virtual Apps and Desktops, LTSR oder CR-Versionen) Cloud Service DaaS (Citrix DaaS, bereitgestellt von Citrix Cloud)
Erfordert ausgehende Internetverbindung zu Citrix Cloud. NEIN - Delivery Controller benötigen keine ausgehende Internetverbindung, obwohl sie in der Lage sein müssen, mit der AWS-Infrastruktur zu kommunizieren, damit die MCS-Bereitstellung funktioniert. JA — Cloud Connectors kommunizieren über das Internet mit Citrix Cloud, obwohl diese Verbindungen über die Proxy-Proxyverbindung hergestellt werden können. Weitere Informationen finden Sie unter Einrichten eines Proxyservers für Citrix Cloud Connector . Bei streng luftgedeckten Bereitstellungen ist dies oft ein Show-Stopper.
Erfordert, dass der Kunde hochverfügbare Microsoft SQL-Datenbankdienste bereitstellt. JA - CVAD (sowohl bei LTSR- als auch bei CR-Release-Typen) erfordert, dass der Kunde hochverfügbare Microsoft SQL-Datenbankdienste bereitstellt. Diese können durch den Aufbau von SQL Servern auf EC2-Instanzen oder durch die Verwendung des AWS RDS for SQL Server-Dienstes bereitgestellt werden. NEIN — Bei DaaS müssen Kunden den SQL-Server nicht berühren: Hochverfügbare Datenbankdienste werden von der Citrix Cloud-Bereitstellungsplattform bereitgestellt und sind für Kunden transparent.
Erfordert, dass der Kunde im Laufe der Zeit Patches und Upgrades auf Citrix Software anwenden muss, um die Sicherheit und Supportfähigkeit aufrechtzuerhalten und Zugriff auf neue Funktionen und Funktionen zu erhalten. JA - Kunden sind verantwortlich für die Installation, Konfiguration, Patches, Sicherung und das Upgrade von Citrix Software und dem zugrunde liegenden Betriebssystem für alle Komponenten in einem CVAD-basierten Session Brokering- und Administrationssystem. Sie sind auch dafür verantwortlich, die hohe Verfügbarkeit jeder Komponente aufrechtzuerhalten, einschließlich Citrix Delivery Controllers, Studio-Installationen, Director und Citrix Licensing. NEIN - Cloud Connectors (die einzige Session Brokering- und administrative Komponente, die sich in der VPC des Kunden befindet) werden von Citrix automatisch aktualisiert und verwaltet. Kunden sind für das Patchen und die Wartung des Windows Server-Betriebssystems auf den EC2 Cloud Connector-Instanzen verantwortlich, und neue Funktionen und Funktionen sind sofort verfügbar, ohne dass der Kunde die Cloud Connectors manuell aktualisieren muss.
Möglichkeit, erweiterte Dienste von Citrix Cloud zu nutzen, einschließlich der Citrix Autoscale-Funktion. Manchmal - nicht alle erweiterten Dienste stehen kundenverwalteten CVAD-Bereitstellungen zur Verfügung und können, wenn dies der Fall ist, die Installation und Konfiguration zusätzlicher Komponenten erfordern. Die Autoscale-Funktion ist für CVAD-Umgebungen nicht verfügbar. JA - DaaS ist so konzipiert, dass es sofort mit anderen Citrix Cloud-Diensten funktioniert. Diese Dienste sind in der Regel vorkonfiguriert, sodass der Kunde sie einfach einschaltet. Die Autoscale-Funktion, die die Möglichkeit bietet, die Menge und den Betriebszustand von VDAs granular zu steuern, ist für VDA-Bereitstellungen in der Public Cloud von großer Bedeutung. Es kann erhebliche Einsparungen bei den Infrastrukturkosten in Szenarien bieten, in denen Sie nur für die Kapazität bezahlen, die Sie benötigen.
Möglichkeit, die vollständige Kontrolle über alle Subsystemkomponenten zu haben, einschließlich des Zeitpunkts für Upgrade- und Wartungsaktivitäten. JA - da jede Komponente vom Kunden installiert, konfiguriert und gewartet wird, hat der Kunde die vollständige Kontrolle über die Versionierung, Konfiguration und Verfügbarkeit jeder Komponente (wenn auch bei erheblich erhöhten Kosten für Infrastruktur, Komplexität und Verwaltungsaufwand). NEIN — mit DaaS geben Kunden ein gewisses Maß an Kontrolle auf, profitieren aber von Einfachheit, geringeren Infrastrukturkosten und erheblich reduziertem Verwaltungsaufwand.
Möglichkeit zur Lizenzierung basierend auf gleichzeitigen Benutzern gegenüber benannten Benutzern. JA - CVAD kann von CCU lizenziert werden. JA - CCU-Lizenzierung ist verfügbar. Einzelheiten finden Sie in diesem Blog .

Cloud Connectors, Delivery Controller und Ressourcenstandorte

Da sowohl grüne Felder- als auch Hybridmodelle Clouddienste (DaaS) für die Sitzungsvermittlung und -verwaltung verwenden, stellen Sie Cloud Connectors bereit, um in jeder Region, in der Sie VDAs hosten möchten, einen Ressourcenstandort zu erstellen. Wenn Sie einen Ressourcenstandort in einer Region erstellen, erstellen Sie eine hochverfügbare Konfiguration, indem Sie n+1 Cloud Connector-Instanzen bereitstellen und die Cloud Connectors über Availability Zones in dieser Region verteilen. Cloud Connectors werden in der Regel in separaten privaten Subnetzen der VDAs platziert, um die Sicherheitsrichtlinienanwendung zu vereinfachen, und die Cloud Connector-Instanzen müssen über ausgehenden Internetzugriff verfügen, um die Verbindung mit Citrix Cloud zu erleichtern. Wenn Sie sie in einem separaten Subnetz von VDAs platzieren, können Administratoren verschiedene Routing-Richtlinien auf die beiden verschiedenen Ressourcentypen anwenden.

Abbildung 13: Entwurfsmuster für den Citrix DaaS-Ressourcenstandort mit separaten Subnetzen für VDAs und Cloud Connectors Diagramm 13: Entwurfsmuster für den Citrix DaaS-Ressourcenstandort mit separaten Subnetzen für VDAs und Cloud Connectors.

Die gleichen allgemeinen Konzepte gelten, wenn es sich um Delivery Controller (CVAD) handelt, obwohl wir die Term-Zone vs. Ressourcenstandort im kundenverwalteten Brokering-Subsystem verwenden. Beachten Sie auch, dass Cloud Connector-Instanzen auf EC2 großartige Kandidaten für reservierte Preise sind, da sie immer ausgeführt werden, wenn das System auf dem Laufenden ist. In diesem Artikel finden Sie weitere Informationen zur Größenbestimmung von Cloud Connector-Instanzen.

Überlegungen zum Entwurf einer Citrix DaaS-Website

Ressourcenstandorte und Zonen

Die Verwendung von Citrix-Zonen (nicht zu verwechseln mit Availability Zones) kann Benutzern in Remote-Regionen helfen, sich mit Ressourcen zu verbinden, ohne dass ihre Verbindungen unbedingt große Segmente des WAN durchqueren müssen. In einer Citrix DaaS-Umgebung wird jeder Ressourcenstandort als Zone betrachtet. Wenn Sie einen Ressourcenstandort erstellen und einen Cloud Connector installieren, wird automatisch eine Zone für Sie erstellt. Jede Zone kann, basierend auf Ihren Anforderungen und Ihrer Umgebung, verschiedene Arten von Ressourcen enthalten. Weitere Informationen zu Zonen finden Sie unter dem folgenden Link.

Maschinenkataloge, Bereitstellungsgruppen und Ressourcenstandorte

Citrix Administratoren sollten sicherstellen, dass VDAs auch auf Availability Zones (AZ) verteilt sind. Eine AWS Availability Zone (AZ) ist ein oder mehrere diskrete Rechenzentren mit redundanter Stromversorgung, Vernetzung und Konnektivität in einer AWS-Region - einem physischen Standort auf der ganzen Welt, an dem AWS-Cluster-Rechenzentren sind. Eine Virtual Private Cloud (VPC) ist ein virtuelles Netzwerk, das sich über Availability Zones in der Region erstreckt. Subnetze sind eine erforderliche Unterkomponente einer VPC, und virtuelle Netzwerkschnittstellen sind jeweils mit einem einzigen Subnetz verbunden. Jedes Subnetz muss sich vollständig in einer Availability Zone befinden und kann sich nicht über Zonen erstrecken. Durch das Starten von VDAs in separaten Availability Zones können Sie Ihre Anwendungen vor dem Ausfall eines einzelnen Standorts schützen. Weitere Informationen finden Sie unter Was ist eine Amazon VPC? für weitere Informationen. Um sicherzustellen, dass VDAs auf AZs verteilt sind, können Sie einen Maschinenkatalog pro AZ (mit einer Hostverbindung pro AZ) erstellen, der dann einer einzelnen Bereitstellungsgruppe zugeordnet werden kann.

Provisioning in AWS: Services zur maschinellen Erstellung

Ab der Veröffentlichung von CVAD 1811 kann die rollenbasierte Authentifizierung beim Erstellen einer Hostverbindung für die MCS-Bereitstellung in AWSverwendet werden. Eine IAM-Rolle oder ein IAM-Benutzerkonto, das mit einem Delivery Controller oder Cloud Connector auf einer EC2-Instanz verknüpft ist, kann anstelle des geheimen Schlüssels und API-Schlüssels eines Benutzers verwendet werden, wodurch erhöhte Sicherheit, delegierte Administratorrechte und PKI-basierte Umgebungen mit temporären Anmeldeinformationen und Sitzungstoken ermöglicht werden. Um eine Hostverbindung mithilfe der rollenbasierten Authentifizierung zu konfigurieren, erstellen Sie zunächst eine IAM-Rolle mit den in CTX140429beschriebenen Berechtigungen. Ordnen Sie diese Rolle einer EC2-Instanz mit einem CVAD 1811+ Delivery Controller oder einem Cloud Connector zu. Bei Versionen von CVAD vor 1811 müssen Administratoren den API-Schlüssel (Access Key) und den Secret Key eines IAM-Benutzers bereitstellen, um eine Hostverbindung herzustellen.

Erstellen Sie nach dem Erstellen der Hostverbindung einen Maschinenkatalog wie hier beschrieben mit einem AMI, das aus dem Master-VDA-Image in AWS erstellt wurde. Weitere Informationen zu MCS in AWS finden Sie in den folgenden Artikeln: Citrix MCS in AWS Deep Dive 1 und Funktionsweise von MCS, nachdem gepoolte VMs in AWS erstellt wurden.

Ein weiterer Punkt, der bei der Bereitstellung von VDAs in AWS mithilfe von MCS berücksichtigt werden sollte, ist die EBS Volume-Initialisierung (auch bekannt als Pre-Warming oder Hydration). Bei Volumes, die aus Snapshots wiederhergestellt wurden, müssen die Speicherblöcke von Amazon S3 heruntergezogen und auf das Volume geschrieben werden, bevor Sie darauf zugreifen können. Diese vorläufige Maßnahme benötigt Zeit und kann beim ersten Zugriff auf jeden Block zu einer signifikanten Erhöhung der Latenz von E/A-Vorgängen führen. Die Volume-Performance wird erreicht, nachdem alle Blöcke heruntergeladen und auf das Volume geschrieben wurden. Weitere Informationen finden Sie unter Initialisierung von Amazon EBS-Volumes unter Windows für AWS empfohlene Schritte zur Initialisierung von Amazon EBS-Volumes auf Windows-Instanzen und unter Initialisieren von Amazon EBS Volumes auf Linux für Linux-Instanzen.

Weitere Informationen zum VPC-Design in Bezug auf MCS finden Sie unter Überlegungen zur Infrastruktur- (oder Plattformschicht) .

Problembehandlung bei Maschinenerstellungsdien

Dieser Abschnitt listet einige allgemeine Probleme und die damit verbundenen Empfehlungen/Lösungslinks auf.

Überlegungen zu Infrastruktur (oder Plattform)

Im Citrix Architectural Design Framework definiert die Infrastruktur- (oder Plattform-) Ebene die physischen Elemente, in denen die Citrix Workloads ausgeführt werden. In diesem Dokument bezieht sich das natürlich auf AWS. AWS bietet viele Clouddienste (über 165) und ist sowohl der älteste als auch der größte der Hyperscale Cloud-Anbieter, den es heute gibt. Es war auch die erste Public Cloud, die von der Citrix Virtualisierungstechnologie unterstützt wurde, und ist eine überzeugende Option für neue oder bestehende Citrix Kunden, die bestehende oder neue Citrix Virtualisierungs-Workloads in der “Cloud” verschieben möchten.

Infrastruktur als Code und das AWS-Objektmodell

Um zu verstehen, wie Citrix Virtualisierungstechnologien in AWS integriert und auf diesem ausgeführt werden, ist es sinnvoll, mit einem grundlegenden Verständnis des Objektmodells zu beginnen, das hinter einigen ihrer Schlüssel/relevanten Services steht. Dies ermöglicht es uns auch, die AWS-Plattform in Begriffen zu beschreiben, die den meisten IT-Experten vertraut sind. Um dieses Verständnis zu erleichtern, verweisen wir auf das folgende Diagramm, das das Entwurfsmuster für einen DaaS-Ressourcenstandort in AWS darstellt:

Abbildung 14: Bereitgestelltes Architektur-/Entwurfsmuster „Ressourcenstandort“ für Citrix DaaS und AWS-Diagramm 14: Bereitgestelltes Architektur-/Entwurfsmuster „Ressourcenstandort“für Citrix DaaS auf AWS.

Dieses Entwurfsmuster ist die Grundlage der meisten Citrix Virtualisierungssystemarchitekturen in AWS. Es ist auch nicht nur ein massives Muster - es basiert auf verschiedenen, gut gepflegten und dokumentierten Designmustern für Enterprise IT in AWS. Diese Muster werden mithilfe von AWS CloudFormation-Vorlagen dargestellt, dokumentiert und reproduziert. AWS bietet eine Bibliothek mit Schnellstart-Vorlagen, die unverändert ausgeführt, zusammen mit anderen Vorlagen (“verschachtelt”) und sogar dupliziert und an Ihre eigenen spezifischen Bedürfnisse angepasst werden können. Dies hebt einige der anderen Hauptvorteile der Public Cloud-Infrastruktur hervor: Infrastruktur als Code und die “Pay As you go” -Natur vieler Clouddienste. Wir gehen in Kürze tiefer in die Infrastruktur als Code in der Citrix Virtualisierungswelt ein, aber wir betonen den Punkt mit einem schnellen Touchpoint, der wahrscheinlich für die erwarteten Leser dieses Papiers Anklang finden wird: für viele IT-Entwickler haben Zugriff auf eine so große Bibliothek von Dienstleistungen, Entwurfsmustern und Technologie-Tools auf Knopfdruck ist großartig. Kombiniert mit der Möglichkeit, Ressourcen zu bezahlen, während Sie sie verbrauchen, und sie einfach zu entfernen, wenn Sie fertig sind? Dies ist eine leistungsstarke Möglichkeit, neue Dinge kennenzulernen oder zu bewerten, und macht den ROI für Investitionen im großen Maßstab viel einfacher zu verstehen und zu kommunizieren.

Zurück zum AWS-Objektmodell für einen Moment: Das Objekt der obersten Ebene in Diagramm 14 ist die AWS-Region. Sie können sich AWS-Regionen als Cluster gut verbundener, aber strategisch getrennter Rechenzentren vorstellen, die als Availability Zonesbezeichnet werden. Jede Region umfasst in der Regel 2 oder mehr Availability Zones, die aus einem oder mehreren physischen Gebäuden mit redundanter Stromversorgung, Vernetzung und Konnektivität bestehen. Zum Zeitpunkt dieses Schreibens verfügt AWS weltweit über 23 Regionen, die aus 69 Verfügbarkeitszonen bestehen. Es ist jedoch wichtig zu beachten, dass sie ständig in neue Regionen und AZs investieren. Diese Zahlen sind zwar für die meisten von uns erstaunlich, aber wahrscheinlich bereits veraltet, als Sie dies lesen. Dies hebt einen der anderen Vorteile des Umstieges auf eine Public Cloud-Infrastruktur in AWS hervor: Sie profitieren weiterhin von den Investitionen, die sie im Laufe der Zeit tätigen (in einer Größenordnung, die weit außerhalb der Reichweite der meisten IT-Organisationen oder sogar Regierungen liegt). Diese kontinuierliche Evolution/Verbesserung, die für wechselansehnliche IT-Organisationen und Geschäftskulturen entmutigend ist, bietet eine breit angelegte Reihe von leistungsstarken Vorteilen für die Unternehmens-IT, da sie sich an dieses “neue” Modell anpasst.

Die Optionen für die Einführung von AWS-Regionen basieren häufig auf Nähe, verfügbaren Services, Kosten, Compliance oder SLA. Während die Auswahl einer oder mehrerer richtiger Regionen für Ihr Citrix Virtualisierungssystem den Rahmen dieses Dokuments sprengt, sollten Sie bei der Auswahl mindestens Folgendes berücksichtigen:

  • Wenn Sie ein oder mehrere bestehende, vom Kunden verwaltete Rechenzentren haben, die Sie mit AWS verbinden, sollten Sie eine oder mehrere Regionen in Betracht ziehen, die Ihren Rechenzentren und großen Büros die niedrigste Latenznetzwerkkonnektivität bieten.
  • Alle Regionen können nicht die von Ihnen gesuchten AWS-Services oder Instanz-Typen haben. AWS stellt neue Services oder Instanz-Typen zunächst in einigen wichtigen Regionen bereit und expandiert dann im Laufe der Zeit auf den Rest. Außerdem können neuere Regionen keine älteren Instanz-Typen haben - recherchieren Sie, bevor Sie sie erstellen, wann immer dies möglich ist.
  • CVAD-Standorte und DaaS-Ressourcenstandorte sind an eine bestimmte Region gebunden. Die hohe Verfügbarkeit für einzelne Komponenten eines Standort-/Ressourcenstandorts (wie Cloud-Connectors, StoreFront-Server und ADC/Gateway VPX-Instanzen) wird erreicht, indem Ressourcen in mehreren Availability Zones in einer bestimmten Region platziert werden.
  • Verteilen Sie Ihre Infrastruktur nicht über alle Regionen hinweg: Während dies auf AWS einfach ist, sollten Sie die Kosten und die Komplexität in Bezug auf die von Ihnen erwartete Auszahlung berücksichtigen, bevor Sie ein System skalieren. Am Ende zahlen Sie manchmal auch für den Netzwerkverkehr und den Speicherverkehr. Die Kosten können für den Verkehr trivial sein, während er in einer Region lokal ist, steigen aber, wenn der Verkehr Regionen oder das Internet durchquert.

Verarbeiten wir jetzt einen Layer in Diagramm 14 und schauen wir uns einige der Netzwerkkonstrukte in diesem Entwurfsmuster an. Das primäre Netzwerkkonstrukt in AWS ist die VPC oder “Virtual Private Cloud”. VPCs sind ein regionales Konstrukt (sie umfassen AZs) - Sie haben mindestens eine VPC in jeder Region, in der Sie Citrix Virtualisierungstechnologie bereitstellen. VPCs haben einen CIDR-Block von IP-Adressen definiert, der eindeutig sein muss, wenn Ihr Netzwerkdesign den Datenverkehr zwischen mehreren VPCs leitet. VPCs werden weiter in Subnetze unterteilt, und Subnetze sind an eine AZ gebunden (das heißt, sie umfassen KEINE AZs in einer Region).

Subnetze haben auch verschiedene Attribute und Objekte, einschließlich Routing-Richtlinien und Sicherheitsrichtlinien. Aus diesem Grund empfehlen die in diesem Dokument (und anderer Citrix Dokumentation) hervorgehobenen Entwurfsmuster, VDAs in separate Subnetze von Cloud Connectors einzufügen, damit Sie VDAs und Cloud Connectors unterschiedliche Routing- und Sicherheitsrichtlinien zuweisen können.

Ausgehender Internetzugriff von einem beliebigen Subnetz in einer VPC (ein regionales Konstrukt) kann auf viele verschiedene Arten gehandhabt werden, aber eine gängige Methode ist die Verwendung von NAT-Gateways, um Internetkonnektivität zu privaten Subnetzen bereitzustellen. Öffentliche Subnetze werden häufig von Internet-Gatewaysbedient, die das Routing eingehender Verbindungen zu Diensten erleichtern, die Sie über das Internet zugänglich machen.

Subnetze werden üblicherweise auch als “öffentlich” und “privat” bezeichnet. Ein öffentliches Subnetz ist ein Subnetz mit routingfähigen Internet-IP-Adressen (zusätzlich zu den privaten IP-Adressen) und ist mit einer Routing-Tabelle verknüpft, die eine Route zu einem Internet-Gateway (IGW) für eingehenden und ausgehenden Internetverkehr hat. Ein privates Subnetz ist ein Subnetz, dessen nur private IP-Adressen zugewiesen sind, und ist mit einer Routing-Tabelle verknüpft, die über eine Route für den ausgehenden Internetzugriff über ein NAT-Gateway oder NAT-Instanzen verfügt, die sich in einem öffentlichen Subnetz befinden. In einem Citrix Virtualisierungssystem befindet sich der virtuelle Gateway-Server (VIP) normalerweise in einem öffentlichen Subnetz, da er eingehende Verbindungen von Clientgeräten über das Internet akzeptiert und verwendet wird, um Citrix Virtualisierungsverkehr sicher in private Subnetze in einer VPC zu vermitteln.

Es gibt viele Möglichkeiten, Netzwerke in AWS aufzubauen, mit vielen innovativen Funktionen und Techniken, die Sie anderswo nicht erreichen können. Wir werden Ihnen hier nicht alle vorstellen, aber zwei Tools/Techniken, die einen Blick wert sind, sind VPC-Peering und Transit-Gateways. Diese beiden Konstrukte helfen Ihnen dabei, den Datenverkehr zwischen VPCs einfach (VPC-Peering) oder in einem unternehmensfähigeren, hybriden Cloud-freundlichen Modell (Transit-Gateways) zu leiten.

Hier gibt es noch viel mehr, auf das wir uns einlassen können, und für Neugierige und Motivierte steht Ihnen ein Berg gemeinfreien Wissens zur Verfügung, um mehr zu erfahren. Lassen Sie uns dies vorerst wieder auf Designmuster unter allen Diagrammen bringen, die Sie in diesem Papier gesehen haben.

Eine der überzeugenden Eigenschaften der AWS-Plattform besteht darin, dass sie auf öffentlich verbrauchbaren APIs aufgebaut ist. Warum ist das überzeugend? Zum einen bedeutet dies, dass viele Infrastrukturkomponenten, die Sie auf AWS ausführen können, reproduzierbar aus Code erstelltwerden kann. In Kombination mit einem leistungsstarken und umfassenden Bereitstellungsservice wie AWS CloudFormationerhalten Kunden ein leistungsstarkes Framework für das Erlernen, Anpassen, Bereitstellen und Verwalten von IT-Systemen. Das Konzept von Infrastructure as Code kann für viele traditionelle Enterprise-fokussierte Technologen neu oder verwirrend sein, aber es kann transformativ sein, wenn es einmal übernommen und praktiziert wird.

Wie bereits erwähnt, bietet AWS eine Bibliothek mit CloudFormation-basierten Quick Start-Vorlagen, die unverändert ausgeführt, mit anderen Vorlagen überlagert (“verschachtelt”) und sogar dupliziert und an Ihre eigenen spezifischen Bedürfnisse angepasst werden können. Diese Vorlagenbibliothek wird von AWS in Zusammenarbeit mit Technologiepartnern wie Citrix verwaltet und verwaltet, und diese Vorlagen werden häufig Open Source (dh sie können bei Bedarf dupliziert und geändert werden). Zum Zeitpunkt des Schreibens sind die folgenden Quick Start-Vorlagen für Citrix-Technologien in AWS verfügbar:

  • Citrix ADC for Web Applications - stellt hochverfügbare Citrix ADC VPX-Instanzen in AWS bereit. Der Anwendungsfallfokus unterscheidet sich zwar geringfügig, aber dieses Entwurfsmuster ist funktional und auch für Citrix Gateway-Bereitstellungen mit Cvad/DaaS relevant.

Zusammenfassung - Verstehen von Entwurfsmustern für Citrix auf AWS

Verwirrt? Wenn ja, seien Sie nicht beunruhigt: Dies kann durchaus der Beginn Ihrer Citrix on AWS Public Cloud-Reise sein, und wir haben hier nur die Oberfläche vieler tiefer Themen überflutet. Hoffentlich haben wir jedoch die folgenden hervorstechenden Punkte erfolgreich veranschaulicht:

  • Infrastructure as Code ist ein leistungsfähiges Konzept, das die Art und Weise, wie komplette Systeme entworfen, gebaut und gewartet werden, revolutionieren kann.
  • Bei der Bereitstellung von Systemen in der Public Cloud von AWS können verschiedene Komponenten einer bestimmten Lösung durch Code dargestellt und mit AWS CloudFormation und anderen Technologien auf Abruf erstellt werden.
  • Diese Komponenten werden bei Verwendung von AWS CloudFormation durch Stack-Vorlagen dargestellt, und Vorlagen können bei Bedarf kopiert und geändert werden, um die gewünschten Ergebnisse zu erzielen.
  • Vorlagen können verschachtelt werden, sodass komplette Systeme (z. B. ein voll funktionsfähiger DaaS-Ressourcenstandort in AWS) aus den einzelnen Entwurfsmustern (Vorlagen) erstellt werden.
  • Die Quick Start-Vorlage für Citrix DaaS auf AWS basiert auf drei von AWS verwalteten/verwalteten Foundation-Vorlagen, die ausführlich dokumentiert sind. Beginnen Sie mit den folgenden Links, um mehr über die einzelnen Links zu erfahren:
  • Durch die Verwendung von Vorlagen und die Durchführung von Test-Builds kann ein Enterprise-Technologe Systeme kennenlernen, bewerten und entwerfen, die den spezifischen Anforderungen seines Unternehmens oder Kunden entsprechen.

AWS Infrastructure Layer - zusätzliche Ressourcen

Die folgenden Ressourcen können verwendet werden, um mehr über die Citrix Virtualisierung bei AWS-Anforderungen und führenden Praktiken zu helfen:

Überlegungen zu Betriebsschichten

In diesem Abschnitt werden die operativen Aktivitäten definiert, die Administratoren regelmäßig ausführen. Viele davon sind nicht spezifisch für AWS und werden in der vorhandenen veröffentlichten Dokumentation detailliert beschrieben. In den folgenden Tabellen haben wir einige der wichtigeren oder AWS-spezifischen Aufgaben zusammengefasst. Leser finden weitere Informationen im Thema Monitor in der Citrix-Produktdokumentation.

Aufgaben auf Abruf

In der folgenden Tabelle werden die Aufgaben beschrieben, die voraussichtlich auf der Grundlage von Anwendungsanforderungen und den Bemühungen zur Fehlerbehebung bei Bedarf ausgeführt werden.

Komponente Aufgabe Beschreibung
Generisch Wissensdatenbank aktualisieren Wenn das Citrix Team Probleme im Zusammenhang mit der Umgebung behebt, soll es Lösungen für Probleme identifizieren. Für jedes Problem sollte KBA erstellt werden, um zukünftige Fehlerbehebungsmaßnahmen zu unterstützen.
Citrix DaaS Image modifizieren Image müssen bei Bedarf für Supportanfragen aktualisiert werden. Die Updates werden wahrscheinlich monatlich sein, aber häufigere Aktualisierungen sind möglicherweise zum Testen erforderlich.
Citrix DaaS Image veröffentlichen Wenn Image geändert werden, werden sie getestet und veröffentlicht.
AWS Überprüfen des Instanzstarts Wenn eine neue Instanz über MCS gestartet wird, stellen Sie sicher, dass die Instanz in der AWS-Konsole erstellt wurde und dass im Pool für die gegebene VPC verfügbare IPs vorhanden sind. Von MCS bereitgestellte Maschinen werden nicht erstellt, wenn es keine verfügbaren IPs im VPC-Pool gibt.
AWS Überprüfen Sie die Wirksamkeit von On-Premises-Images Eine Instanz, die aus einem On-Prem-Image erstellt wurde, sollte auf Startfähigkeit und Durchführbarkeit getestet werden, bevor sie zur Aktualisierung von Produktionsinstanzen verwendet wird.
AWS Ändern der IAM-Benutzer-/Gruppenberechtigungen Bei Bedarf sollten IAM-Benutzer- und Gruppenberechtigungen überprüft werden, um die Anzahl der Benutzer mit Administratorzugriff zu reduzieren und die Methodik der “geringsten Rechte” zu implementieren.
AWS Ändern von Sicherheitsgruppen Bei Bedarf müssen Sicherheitsgruppen überprüft werden, um den Zugriff für verschiedene Verkehrsprotokolle aus verschiedenen IPs oder IP-Bereichen zu gewähren oder zu entfernen. Ingress- und Egress-Regeln müssen geändert werden, um Netzwerkverkehrssperrungen zu implementieren.
AWS und Citrix DaaS Aktualisieren von Maschinen in einem Maschinenkatalog Aktualisieren Sie bei Bedarf Maschinenimages, um alle erforderlichen Änderungen aufzunehmen. Für das geänderte Image muss ein neues AMI erstellt und zum Aktualisieren des Maschinenkatalogs verwendet werden. Weitere Informationen finden Sie im Abschnitt Aktualisierungs- und Upgrade-Prozess dieses Dokuments.
AWS und Citrix DaaS Rollback von Updates für einen Maschinenkatalog Für den Fall, dass ein Maschinen-Image zurückgesetzt werden muss, kann bei Bedarf ein früheres AMI mit der letzten bekannten Arbeitskonfiguration verwendet werden, um Maschinen im Maschinenkatalog zu aktualisieren.

Tägliche Aufgaben

In der folgenden Tabelle werden die Aufgaben beschrieben, die täglich ausgeführt werden sollen.

Komponente Aufgabe Beschreibung
Generisch Citrix Director, Windows-Systemmonitor, Ereignisprotokoll und andere Überwachungssoftware auf Warnungen prüfen Überprüfen von Citrix Director, Ereignisprotokollen oder anderer Überwachungssoftware auf Warnungen oder andere Meldungen. Suche nach dem Auslöser von Warnungen (falls vorhanden). Hinweis: Ein Computer und ein Monitor können so eingerichtet werden, dass das Citrix Director-Dashboard angezeigt wird, um eine Head-up-Anzeige für die Citrix Abteilung zu erstellen, sodass der Status der Umgebung deutlich sichtbar ist. Empfehlungen zur Überwachung von Citrix Virtual Apps and Desktops sind im Abschnitt Monitoring des Best Practices-Handbuchs für virtuelle Apps and Desktops enthalten.
Generisch Überprüfen, dass Backups erfolgreich abgeschlossen wurden Überprüfen, ob alle geplanten Backups erfolgreich abgeschlossen wurden. Dies kann Benutzerdaten (Benutzerprofile/Home-Ordner), Anwendungsdaten, Citrix Datenbanken, Citrix StoreFront-Konfiguration und Citrix Lizenzdateien umfassen, ist jedoch nicht darauf beschränkt.
Generisch Zugriff auf Umgebung testen Simulieren Sie eine Verbindung sowohl intern als auch extern, um zu überprüfen, ob Desktop- und Anwendungsressourcen verfügbar sind, bevor sich die meisten Benutzer für den Tag anmelden. Diese Verbindung ist den ganzen Tag über zu testen und kann sogar automatisiert werden.
Citrix Virtual Apps and Desktops Stromversorgung virtueller Maschinen prüfen Stellen Sie sicher, dass die entsprechende Anzahl von Desktops und Anwendungsservern im Leerlauf eingeschaltet und bei den Delivery Controllern registriert ist, um die Verfügbarkeit für Benutzerarbeitslasten zu bestätigen.
AWS Durchführen von Prüfungen, z. B. Instanzintegrität Überprüfen Sie die AWS-Konsole, um den Status der Instanzen und der zugrunde liegenden Hardware zu überprüfen. Alle Instanzen sollten die beiden Systemintegritätsprüfungen bestehen, wenn sie eingeschaltet sind.
Citrix Virtual Apps and Desktops Durchführen eines inkrementellen Backup von Citrix-bezogenen Datenbanken Durchführen inkrementeller Datenbackups der folgenden Citrix Datenbanken: Standortdatenbank, Configuration Logging Database, Monitoring Database

Wöchentliche Aufgaben

In der folgenden Tabelle werden die Aufgaben beschrieben, die wöchentlich ausgeführt werden sollen.

Komponente Aufgabe Beschreibung
Generisch Überprüfen Sie die neuesten Hotfixes und Patches Suche, Testen und Bereitstellen der aktuellen Citrix Hotfixes und Prüfen, ob die Delivery Controller und virtuellen Server- bzw. Desktop-OS-Maschinen diese benötigen. Bei Microsoft-Updates, die über SCCM oder WSUS auf Maschinen in AWS bereitgestellt werden, erhalten alle Maschinen diese Updates, wenn sie eingeschaltet werden. Wenn Citrix Power Management eingesetzt wird, kann es im Maschinenkatalog Computer geben, die nicht regelmäßig eingeschaltet sind. Wenn Sie Image-Updates durchführen, verwenden Sie am besten eine dynamische Master-Instanz, die während aller Aktualisierungszyklen eingeschaltet wird. AMIs können dann aus dieser Instanz erstellt werden und alle notwendigen Patches enthalten. Hinweis: Alle erforderlichen Hotfixes müssen vor der Implementierung in der Produktion mit dem empfohlenen Testprozess getestet werden.
Generisch Statusbericht zur Citrix Umgebung erstellen Erstellen Sie einen Bericht über die Gesamtumgebungsleistung (Serverzustand, Ressourcennutzung, Benutzererfahrung) und die Anzahl der Citrix-Probleme (Schließungsrate, offene Probleme usw.).
Generisch Statusbericht prüfen Lesen Sie den Citrix Statusbericht, um Trends oder allgemeine Probleme zu identifizieren.
Generisch Pflege der internen Support-Knowledge Base Erstellen Sie KBA- und erstellen Sie Lösungsskripte, um Supportanfragen der Stufen 1 und Level-2 zu beantworten. Überprüfen Sie KBA- und Problemlösungsskripts auf Genauigkeit, Compliance und Machbarkeit.
Citrix Virtual Apps and Desktops Berichte zur Konfigurationsprotokollierungüberprüfen Bestätigen Sie, dass die in der Vorwoche implementierten standortweiten Änderungen von Citrix durch Änderungskontrolle genehmigt wurden.
Citrix Virtual Apps and Desktops Vollständige Backup von Citrix-bezogenen Datenbanken durchführen Durchführen von vollständigem Datenbackup der folgenden Citrix Datenbanken: Standortdatenbank, Konfigurationsprotokollierungsdatenbank, Monitoring-Datenbank.
AWS Durchführen von Schnappschüssen aller EBS-Volumes Alle Elastic Block Storage-Volumes müssen regelmäßig abgebrochen werden. Snapshots können in der AWS EC2-Konsole verwaltet und gepflegt werden.

Monatliche Aufgaben

In der folgenden Tabelle werden die Aufgaben beschrieben, die monatlich ausgeführt werden sollen.

Komponente Aufgabe Beschreibung
Generisch Kapazitätsbewertung durchführen Führen Sie die Bewertung der Umgebungsleistung und der Kapazität der Citrix Umgebung durch, um die Umgebungsauslastung und alle Skalierbarkeitsanforderungen zu bestimmen. Überprüfen Sie monatliche Berichte von Überwachungstools, um die Leistung und Kapazität der Umgebung zu bewerten, einschließlich, aber nicht beschränkt auf: Zuweisung von virtuellen Server-Computings (CPU und RAM), Lizenzierung, Netzwerkbandbreite. Beschaffen Sie Software und/oder Lizenzen und richten Sie bei Bedarf zusätzliche Server ein. Hinweis: Empfehlungen für die Durchführung einer Kapazitätsbewertung sind in Design Decision: Single Server Scalability enthalten
Generisch Überprüfen des Zugriffs mit erhöhte Rechten Überprüfen Sie, welche Benutzer und Gruppen über erhöhte Berechtigungen für die Umgebung verfügen, und bewerten Sie, ob ein kontinuierlicher erhöhter Zugriff erforderlich ist. Entfernen Sie alle Konten, für die diese administrativen Rechte nicht mehr erforderlich sind. In erster Linie nur IAM-Benutzer und -Rollen, die verwendet werden sollen, um erhöhte Berechtigungen zuzuweisen, mit einem eng eingeschränkten Zugriff auf einzelne Benutzer-, lokale oder Root-Konten.

Jährliche Aufgaben

In der folgenden Tabelle werden die Aufgaben beschrieben, die jährlich ausgeführt werden sollen.

Komponente Aufgabe Beschreibung
Generisch Citrix Richtlinienbewertung durchführen Überprüfen Sie Citrix Richtlinien und legen Sie fest, ob neue Richtlinien erforderlich sind und vorhandene Richtlinien aktualisiert werden müssen.
Generisch Software-Upgrades überprüfen Überprüfen der Citrix-Software auf neue erforderliche Releases oder Versionen.
Generisch Durchführen eines Business Continuity Plans (BCP)/Disaster Recovery (DR) Tests Durchführen funktioneller Tests zu BCP/Notfallwiederherstellung, um Einsatzfähigkeit der Notfallwiederherstellung zu bestätigen. Dieser Plan soll einen jährlichen Wiederherstellungstest enthalten, um zu überprüfen, ob der tatsächliche Wiederherstellungsprozess aus Backupdaten ordnungsgemäß funktioniert.
Generisch Anwendungsprüfung durchführen Überprüfen der Verwendung von Anwendungen außerhalb und innerhalb der Citrix Umgebung. Bewerten Sie die Gültigkeit des Hinzufügens weiterer Anwendungen zur Citrix Site, des Entfernens von nicht mehr benötigten Anwendungen oder des Upgrades der Anwendungen auf die neueste Version.
AWS Bewerten der Zugriffe auf Netzwerksicherheitsgruppen Wenn Funktionen oder Anwendungen zu den Citrix Infrastrukturservern oder Anwendungsservern hinzugefügt oder daraus entfernt werden, müssen die mit diesen Instanzen verknüpften Network Security Groups bei Bedarf ebenfalls bewertet und geändert werden, um Ports oder Protokolle hinzuzufügen oder zu entfernen.

Quellen

Ziel dieser Referenzarchitektur ist es, Sie bei der Planung Ihrer eigenen Implementierung zu unterstützen. Um Ihnen diese Arbeit zu erleichtern, möchten wir Ihnen Quelldiagramme zur Verfügung stellen, die Sie in Ihren eigenen detaillierten Designs und Implementierungsleitfäden anpassen können: Quelldiagramme.

Referenzarchitektur: Citrix DaaS — AWS