Referenzarchitektur für Citrix Virtual Apps and Desktops unter 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. Es ist keine “How-To” -Referenz gedacht - Citrix berücksichtigt diese Bereitstellungshandbücher, und sie werden jetzt getrennt von geliefert und gewartet Referenzarchitekturen. 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 Beratungspartnernverwendet 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. Wir teilen das Komponenten eines Citrix Virtualisierungssystems dann in mehrere Subsysteme auf und kategorisieren sie nach Adoptionsmodell:

Adoptionsmodell/ Teilsystemfunktion Kundenverwaltet (installiert aus heruntergeladenen Binärdateien) Clouddienst (bereitgestellt über Citrix Cloud)
Session Brokering und Administration Citrix Virtual Apps and Desktops (CVAD) Citrix Virtual Apps and Desktops Service (CVADS)
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 CVADS für die Session Brokering und Administration, sowohl mit vom Kunden verwalteten als auch mit Clouddienst-Optionen für die übrigen Subsysteme.
  • 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 Technologie von Citrix Virtual Apps and Desktops kann auf viele verschiedene Arten “konsumiert” 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ößtste Kontrolle über jede Komponentebietet, 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% kundenverwaltete Lift/Shift-Bereitstellung mit AWS nur mit AWS als IaaS Schema 1:100% kundenverwaltete Lift/Shift-Bereitstellung mit AWS nur 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% Cloud Services auf AWS mit AWS Managed Services Diagramm 2:100% Cloud Services 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, das Geschäft mit der IT-Verwaltung auszuschaffen, 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. CVADS - Citrix Virtual Apps and Desktops Service, 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 verwalten/vermittelten Umgebungen (CVAD) als auch aus verwalten/vermittelten Citrix Cloud-Umgebungen (CVADS) 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 verwalten/vermittelten Umgebungen (CVAD) als auch aus verwalten/vermittelten Citrix Cloud-Umgebungen (CVADS) 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/CVADS bereitgestellten Apps und Desktops auf der Innenseite 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 Service und den von Citrix Cloud verwalteten und vom Kunden verwalteten Session Brokering-Optionen (CVAD und CVADS).

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. Alles, was Sie für diese Art der Bereitstellung benötigen, ist ein aktives AWS-Konto und entweder ein Test- oder ein kostenpflichtiges Abonnement für Citrix Cloud und den Virtual Apps and Desktops Service. Mit diesen beiden Ressourcen können Sie die QuickStart CloudFormation-Vorlagen von AWS verwenden, um eine Referenzbereitstellung zu erstellen. Citrix und AWS haben an der Citrix Virtual Apps and Desktops Service auf AWS Schnellstart-Vorlage zusammengearbeitet, mit der Sie entweder ein ganzes Citrix Virtualisierungssystem von Grund auf neu erstellen oder einen Citrix Cloud “Resource Location” 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:

Diagramm 3: Details zur Systemarchitektur unter Verwendung der CVADS on AWS QuickStart-Vorlage und der Standardparameter bereitgestellt. Citrix Cloud Services werden nicht angezeigt Diagramm 3: Details zur Systemarchitektur unter Verwendung der CVADS on AWS QuickStart-Vorlage und der Standardparameter bereitgestellt. Citrix Cloud Services werden nicht angezeigt.

Diagramm 4: Konzeptionelle Architektur der Greenfield/Cloud On-Bereitstellung mit optionalen AWS-Services und Citrix Cloud Services Diagramm 4: Greenfield/Cloud Eine konzeptionelle Architektur für die Bereitstellung mit optionalen AWS-Services und Citrix Cloud Services.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell (eigentlich alle drei Bereitstellungsmodelle) verwendet wird, Availability Zones um ein hochverfügbares Design bereitzustellen. Siehe Verfügbarkeitsz später in diesem Dokument für mehr Kontext.

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 Virtual Apps and Desktops Service (“CVADS,” via Citrix Cloud)
UI-Dienste Citrix Workspace-Dienst (über Citrix Cloud)
Authentifizierung Citrix Workspace-Dienst (über Citrix Cloud)
HDX-Sitzungsproxy Citrix Gateway-Dienst (ü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 einen Teil des Komponenten des Citrix Virtualisierungssystems selbst installieren/konfigurieren/verwalten, jedoch nicht das Subsystem für Sitzungsvermittlung und Administration. In einem hybriden Bereitstellungsmodell wird dieses Subsystem als Clouddienst namens “Citrix Virtual Apps and Desktops Service” (kurz CVADS) 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-Dienst (CVADS) von Citrix umfasst den Citrix Autoscale-Funktion, der integrierte VDA-Kapazitäts- und Kostenverwaltungsfunktionen 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 Citrix Cloud-Kunden (CVADS) zur Verfügung. Es ist NICHT für die von Kunden verwaltete Brokering-Infrastruktur (CVAD LTSR- oder CR-Releases) verfügbar. - Einsparungen bei der Verwaltung - Mit Clouddiensten übernimmt Citrix die Verantwortung dafür, die Services hochverfügbar, performant, sicher und auf dem neuesten Stand zu halten. 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 CVADS als Grundlage dieses Bereitstellungsmodells können Kunden von Kunden verwaltete oder Clouddienst-Komponenten des Citrix Virtualisierungssystems kombinieren und abgleichen. 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 Virtual Apps and Desktops Service (“CVADS,” via 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 Muster, das von der Citrix Virtual Apps and Desktops Service auf AWS QuickStart-Vorlage erstellt wurde, und es ähnelt dem folgenden Architekturdiagramm:

Diagramm 5: Konzeptionelle Architektur, CVADS - Hybrid-Bereitstellungsmodell auf AWS Diagramm 5: Konzeptionelle Architektur, CVADS - Hybrid-Bereitstellungsmodell auf AWS.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell auch Availability Zones ein hochverfügbares Design bietet. Siehe Verfügbarkeitsz später in diesem Dokument für mehr Kontext.

Es ist auch erwähnenswert, dass das hybride Bereitstellungsmodell (ein CVADS-Ressourcenstandort in AWS) mit einem hybriden Cloud-Modell kombiniert werden kann, das von Kunden verwaltete Datenzentren/Ressourcen mithilfe von AWS Direct Connect, AWS, Citrix SD-WAN oder anderen Netzwerkwerkzeugen 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 daraus resultierende konzeptionelle Architektur sieht ungefähr wie das folgende Diagramm aus: Diagramm 6: Konzeptionelle Architektur, CVADS: Hybrid-Bereitstellung/Hybrid-Cloud-Modell Diagramm 6: Conceptual Architecture, CVADS: Hybrid Deployment/Hybrid Cloud Model.

Heben und verschieben

In Bezug auf unsere Definition des Komponenten des Citrix Virtualisierungssystems, wenn wir über ein Lift- und Shift-Bereitstellungsszenario sprechen, ist die Schlüsselkomponente das Session Brokering- und Administrationssubsystem 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. Per CTX270373 wird die Verwendung von Public Clouds einschließlich AWS nur von 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 Vom Kunden verwaltete Windows Server-Instanzen auf EC2 AWS Directory Service für Microsoft Active Directory und Amazons 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: Aufhebung und Verschiebung des Bereitstellungsmodells in AWS Diagramm 1: Conceptual Architecture, CVAD: Lift and Shift Deployment Model in AWS.

Es ist erwähnenswert, dass dieses Bereitstellungsmodell auch Availability Zones ein hochverfügbares Design bietet. Siehe Verfügbarkeitsz später in diesem Dokument für mehr Kontext.

Ein Lift- und Shift-Deployment-Modell wird häufig mit einem hybriden Cloud-Infrastrukturmodell kombiniert, wobei AWS Direct Connect, AWS VPN, Citrix SD-WAN oder eine ähnliche Netzwerktechnologie verwendet werden, 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 von Citrix Licensing benötigt, aber wir haben mehrere zur Darstellung verfügbarer Optionen gezeigt: Diagramm 8: Konzeptionelle Architektur, CVAD: Lift and Shift Deployment Model mit Hybrid Cloud-Infrastrukturmodell und von AWS Managed Clouddienste Diagramm 8: Conceptual Architecture, CVAD: Lift and Shift Deployment Model mit Hybrid Cloud-Infrastrukturmodell und AWS Managed Clouddienste.

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 von Komponenten des Citrix Virtualisierungssystemsist das Subsystem “ Session Brokering- und Administration “ die kritischste Komponente, die Sie als NICHT heben und verschieben in Betracht ziehen möchten. 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-Dienst (CVADS) von Citrix umfasst den Citrix Autoscale-Funktion, der integrierte VDA-Kapazitäts- und Kostenverwaltungsfunktionen 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 Clouddienstes (Citrix Virtual Apps and Desktops Service) zur Verfügung - sie steht von Kunden verwaltete Brokering-Infrastruktur (Citrix Virtual Apps and Desktops LTSR- oder CR-Releases) nicht zur Verfügung. - Einsparungen beim Management - Mit Clouddiensten übernimmt Citrix (in diesem Fall AWS) die Verantwortung dafür, die Services hochverfügbar, performant, sicher und auf dem neuesten Stand zu halten. 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 kompletten digitalen Workspace Angebots. Mit diesem Angebot können Citrix Benutzer unabhängig vom Betriebssystem und der Schnittstelle ihres Geräts auf Anwendungen und Desktops zugreifen.

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 Ebenen werden im folgenden konzeptionellen Diagramm dargestellt: Diagramm 9: Konzeptionelle Architektur, Citrix Virtual Apps and Desktops Service Diagramm 9: Conceptual Architecture, Citrix Virtual Apps and Desktops Service.

  • Benutzerebene - Diese Ebene 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 zu Benutzerebene

Im Citrix Architectural Design Framework beschreibt die Benutzerebene 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.

Glücklicherweise sind diese Überlegungen bereits gut dokumentiert und unterscheiden sich nicht wesentlich zwischen Systemen, die auf AWS und anderen Hardware-/Cloud-Plattformen bereitgestellt werden. Weitere Informationen zu den Überlegungen zum Design dieser Ebene finden Sie im Dokument Citrix VDI-Handbuch und Best Practices für XenApp und XenDesktop 7.15 LTSR und insbesondere auf der Seite Designmethodik: Benutzerebene.

Ü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 Kontext der von Komponenten des Citrix Virtualisierungssystems uns definierten enthält die Zugriffsebene die folgenden Komponenten und Wahlmö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 — Beide Legacy-Umgebungen (XenApp und XenDesktop 6.5/7.x, Citrix Virtual Apps and Desktops CR/LTSR) und Citrix Virtual Apps and Desktops Service. JA — Beide Legacy-Umgebungen (XenApp und XenDesktop 6.5/7.x, Citrix Virtual Apps and Desktops CR/LTSR) und Citrix Virtual Apps and Desktops Service. Weitere Informationen hierzu finden Sie unter hier.
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 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 Konfigurieren und Verwalten von Stores. 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 zum Aufzählen, Starten und SSO in SaaS und Web-Apps mit dem Citrix Secure Workspace Access-Dienst, unter Nutzung der Vorteile von Webfilterung und erweiterten Sicherheitskontrollrichtlinien sowie erweiterten, verbesserten ML-Analysen. 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, mithilfe der Citrix Remote-PC-Zugriff Funktion Verbindungen zu physischen Desktops zu präsentieren und zu starten. JA - Unabhängig davon, ob das Vermitteln von CVAD oder CVADS abgewickelt wird. JA - Unabhängig davon, ob das Vermitteln von CVAD oder CVADS abgewickelt wird.
Möglichkeit, die Arbeit der Benutzer zu leiten und sich wiederholende Aufgaben zu automatisieren, indem Mikroapps verwendet werden, die in verschiedene SaaS und benutzerdefinierte Anwendungen integriert sind. NEIN - Die Mikroappen-Funktion ist derzeit in Citrix StoreFront nicht verfügbar. JA - Bietet Benutzern einen “Feed” in der Workspace-Benutzeroberfläche, der Benachrichtigungen, Aufgaben und Workflows intelligent aufzeigt, die durch Inbox- und benutzerdefinierte Mikroapps und die Microapp Builder-Konsole mit niedrigem Code definiert sind. Weitere Informationen finden Sie unter Intelligente Workspace-Funktionen - Mikroapps und Mikroapps auf Citrix Docs.
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 CVAD Zones Dokumentation. 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. Details hierzu finden Sie unter CVADS Zones Dokumentation.
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 (CVADS).
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 Workspaces werden von der Domain cloud.com bereitgestellt, obwohl Kunden dies können Konfigurieren Sie ihr eigenes benutzerdefiniertes Präfix (customername.cloud.com).
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 Netzwerkstandortdienstes.
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 Workspace Access umfassen Web-Filter und Richtlinienkontrollen.
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 Authentifizierungsdiensts. 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 Workspaces. 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 - Citrix Verbundauthentifizierungsdienst (FAS) ermöglicht SSO zu VDAs bei Verwendung eines föderierten Identitätsanbieters wie SAML (Security Assertion Markup Language). Demnächst — Durch die Verwendung von Citrix Verbundauthentifizierungsdienst (FAS) mit Citrix Workspace. Diese Funktion ist zum Zeitpunkt des Schreibens in der Vorschau. Weitere Informationen finden Sie unter Aktivieren von SSO für Workspaces mit Citrix FAS.

Ü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) Clouddienst (Citrix Gateway Service bereitgestellt von Citrix Cloud)
Einfacher, vorkonfigurierter Service, der HDX-Proxy ohne administrativen Overhead bereitstellt NEIN - Als kundenverwaltete Komponente erfordern diese Appliances eine Lizenzierung, Installation, Konfiguration und Wartung. JA - Citrix Gateway Service ist eine vollständige HDX-Proxy-Lösung, die von Citrix verwaltet wird und als Clouddienst bereitgestellt wird.
Möglichkeit, das EDT (UDP) -basierte Transportprotokoll von Citrix HDX zu verwenden. Weitere Informationen finden Sie unter Adaptive Transport und So konfigurieren Sie das HDX Enlightened Data Transport Datentransport-Protokoll. 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 CVADS vermittelte Umgebungen bietet der Gateway Service einfachen, sicheren Zugriff auf virtualisierte Anwendungen, die entweder in AWS- oder On-Pre-Umgebungen 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 -… aber es besteht keine wirkliche Notwendigkeit dafür: Der Gateway-Dienst stellt sicher, dass Benutzer die bestmögliche Sitzungsleistung erzielen, unabhängig davon, wo auf der Welt sie sich befinden. 14 oder mehr POP’s weltweit plus integrierte GSLB
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 proxiert 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. Weitere Informationen hierzu finden Sie unter hier. 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 dazu beitragen, die Entscheidungen Ihres Kunden im Vergleich zum Clouddienst für die Zugriffsebenen-Subsysteme zu fördern, untersuchen wir die Entscheidungen der obersten Ebene im Kontext der zuvor definierten Bereitstellungsmodelle.

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 Nutzungsfähigkeit profitieren Citrix Gateway als Identitätsanbieter für Workspace.

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. Berücksichtigen Sie das Startsequenz für Citrix Virtual Apps and Desktops beim Entwerfen Ihrer Hybridbereitstellung 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 Leitfaden zur Schnellstart-Bereitstellung von Citrix ADC for Web Applications) eine Citrix HA-Paarbereitstellung mit Multi-AZ, wie sie von der Quick Start-Vorlage bereitgestellt wird (mit Standardsubnets/CIDR-Blöcken):

Diagramm 10: Konzeptionelle Architektur, Citrix ADC/Gateway VPX auf AWS mit HA in allen Availability Zones Diagramm 10: Konzeptionelle Architektur, Citrix ADC/Gateway VPX auf AWS mit HA in allen Availability Zones.

Wie in Citrix ADC VPX auf AWS Citrix Docs erläutert, 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 eingesetzte Modell für Produktionsumgebungen: Paare von Citrix ADC/Gateway VPX-Instanzen können im nativen Citrix HA-Modus bereitgestellt werden AWS. Bei älteren Firmware-Versionen wird das Paar in derselben AWS Availability Zone bereitgestellt. Beginnend mit Citrix ADC 12.1 Firmware können hochverfügbare Paare von VPX-Appliances in Availability Zones (AZ) bereitgestellt werden. Funktionsweise der Hochverfügbarkeit in AWS erklärt den Unterschied zwischen der Bereitstellung eines ADC-Paares 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):

Diagramm 11: Citrix ADC VPX Instanzschnittstellenzuordnung für CVAD/CVADS-Bereitstellungen Diagramm 11: Citrix ADC VPX Instanz-Interface-Mapping für CVAD/CVADS-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 im Vertrauten enthalten Pod-Infrastruktur, um einfach zu verwaltende Updates, Patches und Skalierbarkeit für die Erweiterung zu ermöglichen. Detaillierte Informationen zum Einrichten von GSLB zwischen AWS AZs finden Sie unter Citrix Dokumentation.

Abbildung 12: Verkehrsfluss vor und nach HA-Failover bei Multi-AZ HA-Bereitstellung Abbildung 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 einen 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. Der NSIP ist für jeden ADC in dieser Konfiguration unterschiedlich, während SNIPs und Load Balancing-VIPs einen speziellen Citrix ADC Funktion namens IPSetoder virtuellen Multi-IP-Server verwenden, der für Clients in verschiedenen Subnetzen verwendet werden kann, um eine Verbindung mit demselben Satz von Servern herzustellen. 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-Paares finden Sie Citrix Dokumentation im Citrix YouTube-Kanal. dieses Video

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. Unter finden Sie allgemeine Überlegungen, die Planen der StoreFront-Bereitstellung für alle Bereitstellungen gelten, einschließlich StoreFront in AWS. 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. Per werden StoreFront-Servergruppenbereitstellungen nur unterstützt Planen Sie Ihre StoreFront-Bereitstellung/Skalierbarkeit, wenn Verbindungen zwischen Servern in einer Servergruppe eine Latenz von weniger als 40 ms (bei deaktivierten Abonnements) oder weniger als 3 ms (mit 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 früher in diesem Dokument in der Überlegungen zu UI-Diensten und - Tabelle beschrieben, aber es lohnt sich, noch einmal darauf hinzuweisen: Für Citrix Virtual Apps and Desktops Service-Umgebungen mit umfassenden Ausfallanforderungen empfiehlt Citrix dringend eine StoreFront-Implementierung, um in vollem Umfang vom lokalen Host zu profitieren Cache-Funktion (verfügbar sowohl in CVAD- als auch in CVADS-Sitzungsbroker-Infrastrukturtypen). Für CVAD bietet dies Ausfallsicherheit bei einem Datenbankausfall. Für CVADS bietet diese Architektur Ausfallsicherheit für den Fall, dass Cloud Connectors Citrix Cloud nicht erreichen kann. In beiden Fällen können getrennte Benutzer während eines Ausfallszenarios weiterhin eine Verbindung zu neuen und bestehenden Sitzungen herstellen. Weitere Details, Einschränkungen und Auswirkungen der Aktivierung des lokalen Hostcache finden Sie unter Lokaler Hostcache (CVADS) 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 kann StoreFront-Redundanz eingebaut werden Citrix Zonen, indem Satellitenzonen auf zwei oder mehr AZs in einer VPC mit einem einzigen Standort 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 Erwägung ziehen, sollten die Verwendung von DFS-R und DFS-N für Roaming-Profilfreigaben und Freigaben zur Ordnerumleitung überprüfen Microsofts Support-Erklärung. 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 Möglichkeit, die Verwendung eines Clouddienstes für Windows-Dateiservices zu bewerten, anstatt einen eigenen 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

Amazons FSx für Windows File Server ist ein Clouddienst, 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 FSx ein Windows-Dateiserver ist, sollten Kunden, die diese Option in Betracht ziehen, die Verwendung von DFS-R und DFS-N für Roaming-Profilfreigaben und Ordnerumleitungsfreigaben überprüfen Microsofts Support-Erklärung.

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 Ort, um mit der Erkundung von Optionen zu beginnen, ist auf 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 Session Brokering- und Management-Subsystem (sowohl CVADS 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 besprechen MCS on AWS in den Überlegungen zu Steuerungsebene Abschnitten dieses Dokuments 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 Hosting 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, wird der folgende Entscheidungsbaum verglichen Gehostete Shared Desktops (Server OS Mehrbenutzer-Desktops) auf VDI-Desktops. 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 Instanz-Fakturierungs

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 müssen so viele VDAs wie möglich stundenweise mit dem On-Demand-Abrechnungsmodell bezahlt werden, und die Citrix Autoscale Funktion zur Kostenkontrolle nutzen. Durch die Verwendung von Citrix Autoscale (eine exklusive Funktion des CVADS Cloud Service Brokering-Subsystems) werden VMs bei Bedarf mit Vorfreude 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 Avail

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 gehostete 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 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 und Preisgestaltung von Instanz-Typen finden Sie im Abschnitt Präsentation zur Kostenschätzung von Citrix on AWS (im Quellenbereich).

Weitere Informationen zur Instanz-Auswahl (insbesondere für das gehostete Shared Delivery -Modell) finden Sie unter Citrix Skalierbarkeit in einer Cloud-Welt 2018 Edition. 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-Instanz-Typen werden nicht standardmäßig im Assistenten zur Erstellung von Maschinenkatalogen in Studio angezeigt (entweder CVAD oder CVADS). Die Benutzeroberfläche wird mit Instanz-Typen aus einer statischen XML-Datei gefüllt, die sich auf Delivery Controllers (CVAD) oder Cloud Connectors (CVADS) 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 CTX139707 zum Aktualisieren der Liste der verfügbaren AWS-Instanz-Typen finden Sie unter. Um eine bessere Vorstellung davon zu bekommen, wie Instanzen auf AWS (oder einer anderen Plattform) üblicherweise bemessen werden, sehen Sie sich dies an ausführlicher AWS LoginVSI Blog. Während dieser Testrunde (eine Point-in-Time-Referenz) erwies sich der Instanz-Typ M5.2Xlarge (8 vCPU, 32 GB RAM) als Gewinner in Bezug auf $/Benutzer/Stunde (mit einer Probenarbeitslast 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 die Nutzung von Diensten in Betracht ziehen, wie zum Beispiel Citrix Analytics für Leistung - die Informationen, die solche Dienste bereitstellen, können eine Schlüsselrolle 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 Entscheidungsmatrix der Tech Zone vergleicht die verschiedenen Gehostete Methoden für gemeinsame Zu, darunter Hosted Shared Applications (Single und Multiuse) und Hosted Shared Desktops. 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 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 unter Produktdokumentation und Referenzarchitektur von App Layering.

Ü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 auf AWS können Kunden ihre eigenen Active Directory-Domänencontroller mithilfe von Windows Server-Instanzen AWS Directory Service für Microsoft Active Directory, Verwendung oder einer Kombination aus beiden erstellen oder verwalten. 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 für den Aufbau und die Wartung funktionaler Active Directory-Dienste erforderlichen Verwaltungsaufwand minimieren möchten, ist die AWS Directory Service für Microsoft Active Directory (auch bekannt als AWS Managed Microsoft AD) eine Option, die in Betracht gezogen werden sollte. 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 Unternehmen zu unterstützen szenarien.

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 für 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. Dieser AWS-Service hat einige Einschränkungen, die ihm auferlegt werden müssen, um ihn als Service im großen Maßstab bereitzustellen, und die derzeit bekannten/wirkungsvollsten Einschränkungen für eine Citrix-Umgebung sind hier aufgeführt. Weitere Informationen zu den Active Directory-Anforderungen für Green-Field- und Hybridbereitstellungen (Umgebungen, die Citrix Cloud und den CVAD-Dienst für die Vermittlung und Verwaltung von Sitzungen verwenden) finden Sie unter Technische Daten zu Citrix Cloud Connector. Neben der Abdeckung unterstützte Active Directory Funktionsebenenbehandelt dieser Artikel auch Bereitstellungsszenarien für Cloud Connectors in Active Directory.

Weitere Informationen zu den Active Directory-Anforderungen für Aufhebungs- und Verlagerungsbereitstellungen (Umgebungen, in denen durch Kunden verwaltete Sitzungsvermittlung und Verwaltung über Citrix Virtual Apps and Desktops LTSR- oder CR-Versionen verwendet werden) finden Sie unter CVAD Technischer Überblick, Active Directory und 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 Clouddienstes (CVADS) für diese kritische Komponente, aber für bestimmte Anforderungen und Szenarien kann die Bereitstellung eines von Kunden verwalteten Session Brokering- und Administrationssubsystems (über CVAD LTSR- oder CR-Versionen) erforderlich oder empfohlen sein. 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 CVADS (Citrix Virtual Apps and Desktops Service, 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-Proxy-Verbindung hergestellt werden können. Weitere Informationen hierzu finden Sie unter So richten Sie einen Proxy-Server für Citrix Cloud Connector ein. 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 - CVADS verlangt nicht, dass Kunden den SQL-Server 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 zur Nutzung erweiterter Dienste, die von Citrix Cloud bereitgestellt werden, 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 - CVADS ist so konzipiert, dass es mit anderen Citrix Clouddiensten “out of the box” funktioniert, und diese Dienste sind in der Regel vorkonfiguriert, sodass der Kunde sie einfach einschaltet. Die Autoscale-Funktion, die die Möglichkeit bietet, den Mengen- und Energiezustand von VDAs granular zu steuern, wirkt sich auf VDA-Bereitstellungen in der Public Cloud aus. 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 CVADS geben Kunden ein gewisses Maß an Kontrolle auf, gewinnen jedoch an Einfachheit, geringeren Infrastrukturkosten und erheblich reduzierten 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. Details hierzu finden Sie unter dieser Blog.

Cloud Connectors, Delivery Controller und Ressourcenstandorte

Da sowohl Green-Field- als auch Hybridmodelle Clouddienste (CVADS) für die Session Brokering und Administration verwenden, stellen Sie Cloud Connectors bereit, um Ressourcenstandort in jeder Region eine zu erstellen, in der Sie VDAs hosten möchten. 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.

Diagramm 13: CVADS Resource Location-Entwurfsmuster mit separaten Subnetzen für VDAs und Cloud Connectors Diagramm 13: Entwurfsmuster von CVADS Resource Location 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. Weitere Informationen hier zur Größenbestimmung von Cloud Connector-Instanzen finden Sie unter.

Überlegungen zum Site-Design Citrix Virtual Apps and Desktops

Ressourcenstandorte und Zonen

Die Verwendung Citrix-Zonen (nicht zu verwechseln mit Availability Zones) kann Benutzern in abgelegenen Regionen helfen, sich mit Ressourcen zu verbinden, ohne notwendigerweise ihre Verbindungen dazu zu zwingen, große Segmente des WAN zu durchqueren. In einer Citrix Virtual Apps and Desktops Service-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 im 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 Was ist eine Amazon VPC? Informationen finden Sie unter. 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 verwendet werden MCS-Bereitstellung in AWS. 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 mit rollenbasierter Authentifizierung zu konfigurieren, erstellen Sie zuerst eine IAM-Rolle mit den unter beschriebenen Berechtigungen CTX140429. Verknüpfen Sie diese Rolle mit einer EC2-Instanz mit einem CVAD 1811+ Delivery Controller oder einem Cloud Connector. 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. Im Folgenden diesem Artikel wird beschrieben, wie Sie eine Host-Verbindung auf diese Weise konfigurieren.

Erstellen Sie nach dem Erstellen der Hostverbindung einen Maschinenkatalog wie beschrieben hier 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 auf AWS Deep Dive 1 und Wie MCS funktioniert, nachdem gepoolte VMs in AWS erstellt wurden.

Ein weiterer Punkt, der bei der Bereitstellung von VDAs in AWS mit MCS in Betracht gezogen werden sollte, ist EBS Volume-Initialisierung (auch bekannt als Vorwärmung oder Hydratation). 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. Informationen zu Initialisieren von Amazon EBS Volumes unter Windows den von AWS empfohlenen Schritte zur Initialisierung von Amazon EBS Volumes auf Windows-Instanzen finden Sie unter Initialisieren von Amazon EBS Volumes unter Linux für Linux-Instanzen

Einzelheiten Überlegungen zu Infrastruktur (oder Plattform) zum VPC-Design in Bezug auf MCS finden Sie unter.

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 CVADS-Ressourcenstandort in AWS darstellt:

Diagramm 14: Bereitgestelltes Architektur-/Entwurfsmuster “Ressourcenstandort” aus der Vorlage “Citrix Virtual Apps and Desktops Service on AWS Quick Start CloudFormation” Diagramm 14: Bereitgestelltes Architektur-/Entwurfsmuster “Resource Location” aus der Vorlage Citrix Virtual Apps and Desktops Service on AWS Quick Start CloudFormation.

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, Schnellstart-Vorlagen die so ausgeführt werden kann, wie sie mit anderen Vorlagen zusammengefügt (verschachtelt) und sogar für Ihre eigenen spezifischen Anforderungen dupliziert und angepasst werden kann. 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.

Für einen Moment zurück zum AWS-Objektmodell: Das Top-Level-Objekt in Diagramm 14 ist das Region AWS. Sie können sich AWS-Regionen als Cluster von gut vernetzten, aber strategisch getrennten Rechenzentren vorstellen Verfügbarkeitsz. 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 CVADS-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.

Der ausgehende Internetzugang von jedem Subnetz in einer VPC (ein regionales Konstrukt) kann auf viele verschiedene Arten gehandhabt werden, aber eine gängige Methode wird verwendet, NAT-Gateways um private Subnetze mit Internetkonnektivität zu versorgen. Öffentliche Subnetze werden häufig von bereitgestellt Internet-Gateways, die das Routing von eingehenden 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 proxieren.

Es gibt viele Möglichkeiten, Netzwerke in AWS aufzubauen, mit vielen innovativen Funktionen und Techniken, die Sie anderswo nicht erreichen können. Wir werden Sie hier nicht alle vorstellen, sondern zwei Werkzeuge/Techniken, die es wert sind, untersucht zu werden, sind VPC-Peering und Transit-Gateways. Diese beiden Konstrukte helfen Ihnen dabei, den Datenverkehr zwischen VPCs einfach (VPC-Peering) oder in einem unternehmensbereiten, 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 CloudFormationhaben Kunden einen leistungsstarken Rahmen für das Lernen, Anpassen, Bereitstellen und Verwalten von IT-Systemen. Das Konzept von Infrastruktur als Code kann für viele traditionelle, auf Unternehmen fokussierte Technologen neu oder verwirrend sein, aber es kann transformativ sein, sobald es angenommen und praktiziert wird.

Wie bereits erwähnt, bietet AWS eine CloudFormation-basierte Bibliothek, Schnellstart-Vorlagen die unverändert ausgeführt werden kann, zusammen (“verschachtelt”) mit anderen Vorlagen und sogar dupliziert und an Ihre eigenen spezifischen Anforderungen angepasst werden kann. 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 Virtual Apps and Desktops Service auf AWS - stellt einen hochverfügbaren Citrix Cloud Virtual Apps and Desktops Service “Ressourcenstandort” auf AWS bereit.
  • Citrix ADC für Web-Anwendungen - stellt hochverfügbare Citrix ADC VPX Instanzen auf AWS bereit. Während sich der Anwendungsfallschwerpunkt geringfügig unterscheidet, ist dieses Entwurfsmuster auch für Citrix Gateway-Bereitstellungen mit CVAD/CVADS funktional und relevant. Citrix und AWS arbeiten an einem zusätzlichen Quick Start für diesen speziellen Anwendungsfall.

Wir haben bereits diskutiert, wie sich das Entwurfsmuster “Citrix ADC for Web Applications” auf das CVADS-Ressourcenstandortdesignmuster in der Vorlage “Citrix Virtual Apps and Desktops Service on AWS” bezieht. Lassen Sie uns daher einige grundlegende Vorlagen aufschlüsseln, die beiden zugrunde liegen. Der Einfachheit halber nennen wir es die Vorlage “CVADS”.

Wenn wir die CVADS QuickStart-Vorlage im CloudFormation Designer öffnen, erhalten wir eine visuelle Darstellung dieser Vorlage. Aus diesem Bild können wir sehen, dass diese Vorlage drei separate “verschachtelte” Stapel oder Vorlagen verwendet:

Diagramm 15: Vorlage CVADS in CloudFormation Designer mit verschachtelten Stacks Diagramm 15: CVADS Vorlage in CloudFormation Designer mit verschachtelten Stacks.

In Diagramm 15 ist CitrixResourceLocationStack “nach oben”, und die anderen drei darunter verschachtelten Stacks sind grundlegende Stacks, die von AWS verwaltet und verwaltet werden.

Die Vorlage “vpcStack” legt den Großteil der Networking Foundation unterhalb der CVADS-Vorlage fest. VPCStack ist für den Aufbau der folgenden Komponenten des CVADS-Stackdiagramms verantwortlich. Alle anderen Stacks bauen auf diesen Ressourcen und Parametern auf: Diagramm 16: VPCStack-Beispiel-Buildergebnisse Diagramm 16: VPCStack-Beispielergebnisse.

Zusätzlich zu vpcStack kommen RdgwStack und AdStack. Der RdgwStack-Vorlage legt die Infrastruktur fest, um administrativen Remote-Konsolenzugriff auf das von vPCStack erstellte Netzwerk zu ermöglichen. Es ist in Diagramm 17 in Orange dargestellt. Die AdStack-Vorlage, die parallel zu RdgwStack läuft, erstellt die Active Directory-Infrastruktur für ein System. Es enthält Optionen zum Erstellen von AD auf IaaS-Instanzen und zur Verwendung des AWS Active Directory-Dienstes. Für unser Beispiel-Entwurfsmuster wird das AD DS Service-Objekt in Rot erstellt: Diagramm 17: VpStack+rdgwStack +AdStack-Beispiel-Build-Ergebnisse Diagramm 17: VpStack + RdGWStack Proben-Build-Ergebnisse.

Schließlich wird CitrixResourceLocationStack (der “Master” -Stack, der die drei verschachtelten Stacks aufruft) und baut auf den drei Fundamentstapeln auf. Es ist für die Erstellung der Cloud Connectors und des VDA auf AWS verantwortlich und verwendet die Citrix Cloud-APIs, um den Ressourcenstandort, die Hosting-Verbindung, den Maschinenkatalog und die Bereitstellungsgruppe in Ihrem Citrix Cloud-Mandanten zu erstellen. Das Endergebnis? Ein voll funktionsfähiger Citrix Cloud-Ressourcenstandort, der auf AWS ausgeführt wird: Diagramm 18: Beispiel-Buildergebnisse von CitrixResourceLocationStack (plus verschachtelte Stacks) Diagramm 18: CitrixResourceLocationStack (plus verschachtelte Stacks), um die Buildergebnisse zu erstellen.

Zusammenfassung - Verstehen von Entwurfsmustern für Citrix auf AWS

Noch 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, um komplette Systeme (wie z. B. einen voll funktionsfähigen CVADS-Ressourcenstandort in AWS) aus den einzelnen Entwurfsmustern (Vorlagen) zu erstellen.
  • Die Citrix Virtual Apps and Desktops Service auf AWS Quick Start-Vorlage basiert auf drei von AWS verwalteten/verwalteten Foundation-Vorlagen, die gut dokumentiert sind. Beginnen Sie mit den folgenden Links, um mehr über die einzelnen Links zu erfahren:

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 können auf die Thema überwachen in Citrix Produktdokumentation verweisen, um weitere Informationen zu erhalten.

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 Virtual Apps and Desktops 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 Virtual Apps and Desktops 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 Virtual Apps and Desktops 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 Virtual Apps and Desktops 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. Die Überwachungsempfehlungen für Citrix Virtual Apps and Desktops finden Sie im Überwachen Abschnitt des Best Practices-Leitfadens für Virtual Apps and Desktops.
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 Datensicherungen 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 Issue-Resolutionsskripts 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ändigen Datensicherungen 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 finden Sie Entscheidung: Kapazitätsverwaltung im Abschnitt Überwachung des Citrix Virtual Apps and Desktop Best Practices Guide.
Generisch Überprüfen des erhöhten Zugriffs auf Privile Ü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 Sicherungsdaten 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 diese Arbeit zu erleichtern, möchten wir Ihnen Quelldiagramme zur Verfügung stellen, die Sie in Ihren eigenen detaillierten Entwürfen und Implementierungshandbüchern anpassen können: Quelldiagramme.

Referenzarchitektur für Citrix Virtual Apps and Desktops unter AWS