Referenzarchitektur: App Layering

Zielgruppe

Dieses Dokument richtet sich an technische Fachkräfte, IT-Entscheidungsträger, Partner und Systemintegratoren. Auf diese Weise kann der Administrator Citrix App Layering erkunden und einsetzen, um die Bereitstellung von Images und Anwendungen für seine Endbenutzer zu verwalten. Der Leser muss grundlegende Kenntnisse über Citrix Produkte, Image-Management-Services und Anwendungsvirtualisierungskonzepte haben. Weitere Informationen zur Image-Verwaltung finden Sie in der Referenzarchitektur in der Citrix Tech Zone.

Ziel dieses Dokuments

Dieses Dokument bietet einen technischen Überblick und architektonische Konzepte für die Verwaltung und Bereitstellung von Anwendungen mit Citrix App Layering-Technologien. Dieses Dokument beschreibt sowohl die Funktionsweise von App Layering als auch die Integration mit Citrix Virtual Apps and Desktops auf verschiedenen Plattformen.

Übersicht über Citrix App Layering

Citrix App Layering ist eine flexible Lösung zur Bereitstellung eines komplexen Satzes von Windows-Anwendungen für eine Vielzahl von Benutzern auf einer nicht persistenten unterstützten Plattform.

Citrix App Layering führt die Image-Verwaltung auf einzigartige Weise durch. Das Betriebssystem und die Anwendungen sind in verschiedene Container unterteilt, die “Layers” genannt werden. Layer werden unabhängig voneinander erstellt und aktualisiert und dann in “veröffentlichte Images” kompiliert, die mit einem unterstützten Provisioningsystem verteilt werden.

Sobald die Bibliotheken von Anwendungen erstellt wurden, werden verschiedene Sätze von Images auf vielen Plattformen mit einer beliebigen Kombination von Layern bereitgestellt.

AL-Image-1

Das Hauptziel von Citrix App Layering ist die Vereinfachung der Windows-Anwendungsverwaltung über eine einzige Schnittstelle. Es ermöglicht dem Administrator, Unternehmensanwendungen unabhängig von den zugrunde liegenden Hypervisoren oder der Cloud-Infrastruktur zu erstellen und zu verwalten.

Das Betriebssystem und die Anwendungen sind in separate verwaltbare Einheiten unterteilt. Selbst wenn viele Images erforderlich sind, um den Anwendungszugriff ordnungsgemäß zu steuern, werden jedes Betriebssystem und seine Anwendungen als eine einzige Instanz verwaltet. Bei diesem Ansatz müssen Aktualisierungen nicht für jedes Image in der Umgebung durchgeführt werden. Vereinfacht die Umgebung und reduziert gleichzeitig Verwaltungszeit, Komplexität und Kosten im Zusammenhang mit Betriebssystemen und App-Management.

Das Betriebssystem und die Anwendungen werden als virtueller Datenträger gespeichert, die Dateien und Registrierungseinträge für einen bestimmten Layer enthält. Es gibt zwei Möglichkeiten, Anwendungen in virtuelle Maschinen einzubeziehen:

  • Veröffentlichtes Image: Bei dieser Methode werden die OS-Layer, eine Plattformlayer und eine Reihe von Anwendungslayer kombiniert, um ein Image für Provisioningsysteme wie Citrix Provisioning oder Citrix Maschinenerstellungsdienste zu erstellen. App Layering kann Images auf mehreren Provisioningsystemen und mehreren Hypervisoren aus demselben Layer veröffentlichen.

Weitere Informationen zur Citrix Image-Verwaltung finden Sie im Dokument Referenzarchitektur .

  • Elastische Layer: Nur wenige Anwendungslayer werden während der Anmeldung auf Basis der AD-Gruppenmitgliedschaft und der Anwendungszuweisung an eine virtuelle Maschine angehängt. Ermöglicht eine größere Flexibilität bei der Anwendungszuweisung durch die dynamische Bereitstellung von Anwendungen an standardisierte Images.

Die Trennung der Anwendungen und Personalisierung vom Betriebssystem bietet eine flexible und verwaltbare Lösung für die nicht persistente Image-Verwaltung.

Warum Citrix App Layering

Citrix App Layering bietet eine kostengünstige Lösung zur Verwaltung einer komplexen Gruppe von Anwendungen in mehreren Umgebungen mit unterschiedlichen Verpackungsanforderungen. Fast alle Anwendungen, die in Kerneltreiber, Betriebssystem und Systemdienstabhängigkeiten eingebettet sind, sind mit der App Layering-Technologie kompatibel.

Die Verwendung des Citrix App Layering-Ansatzes für die Image-Verwaltung bietet viele Vorteile:

  • Vereinfacht die Verwaltung von Masterimages für PVS und MCS: Citrix App Layering ist eine Lösung zur Verwaltung einzelner Images, die sowohl Bereitstellungsmodelle unterstützt, die mit Citrix als auch mit Hypervisoren von Drittanbietern verwendet werden. Mit App Layering werden sowohl die Verwaltung als auch Upgrades für Images vereinfacht, ohne dass Images direkt bearbeitet werden müssen oder Reverse Imaging erforderlich ist.

  • Azure-Unterstützung: Citrix App Layering unterstützt Microsoft Azure und erleichtert App Layering-Kunden die Migration auf eine Azure-Plattform.

  • Entkoppeln der Apps und Provisioningsysteme vom Image: Citrix App Layering trennt die Paketerstellung vom Image. Bei der normalen Image-Verwaltung werden Updates an einem Image für jedes Image separat durchgeführt. Mit App Layering kann eine Layer Teil vieler Images sein. Um alle Images zu aktualisieren, kann die Layer einmal aktualisiert und die Images neu generiert werden. Upgrades auf Komponenten wie Hypervisor-Tools, Virtual Delivery Agents (VDA) und Citrix Provisioning-Tools werden einfach.

  • Unterstützt komplexe Anwendungsfälle: Komplexe Anwendungen mit Kerneltreibern, Systemdiensten, Treibern von Drittanbietern und Konsolenzugriff können mit Citrix App Layering unterstützt werden. Aufgrund der beiden Modi von App Layering für die Bereitstellung von App-Layern sind fast alle Anwendungen kompatibel.

  • Nicht-Persistenz-Desktop-Benutzerlayer: Der Benutzerlayer ist ein beschreibbarer Elastic Layer. Ein Benutzer meldet sich an einem Desktop an, der meiste Schreibvorgang erfolgt in der Benutzerebene. Es ermöglicht einem Benutzer, Anwendungen zu installieren und Konfigurationseinstellungen zu speichern, die sich außerhalb des Benutzerprofils befinden. Außerdem werden die Datendateien der Benutzer gespeichert, indem der Desktop persistent erscheint und die Vorteile eines gemeinsam genutzten Desktops bietet.

  • Reduziert die Anzahl der erforderlichen Images: Elastic Layering kann die Anzahl der erforderlichen Images erheblich reduzieren, indem Anwendungen dynamisch nur zugewiesenen Benutzern bei der Anmeldung bereitgestellt werden. Elastic Layers sind sowohl mit Citrix Virtual Apps als auch mit Citrix Virtual Desktops kompatibel.

Anwendungsfälle für Citrix App Layering

App Layering ist eine wichtige Ergänzung des Citrix-Technologieportfolios, das viele der zuvor aufgeführten Vorteile bietet. Obwohl es Vorteile bietet, bedeutet App Layering nicht, es für alle Anwendungsfälle zu verwenden. In diesem Abschnitt werden einige der wichtigsten Anwendungsfälle beschrieben, um die Vorteile der App Layering-Technologie aufzuzeigen.

1-Zu viele Images zum Verwalten

Viele Citrix-Kunden müssen eine erhebliche Anzahl von Anwendungen und komplexe Benutzeranforderungen unterstützen. Wenn Sie eine imagebasierte Provisioningtechnologie verwenden, erfordert die Erfüllung dieser Anforderungen häufig eine hohe Anzahl von Images. Diese Images müssen verschiedene Benutzergruppen oder verschiedene Gruppen widersprüchlicher Anwendungen unterstützen. Oft gibt es auch einige Überschneidungen bei den Anwendungen, die für jedes Image bereitgestellt werden.

Citrix App Layering vereinfacht die Verwaltung dieses komplexen Szenarios.

AL-Image-2

Mit der App Layering können Administratoren das Betriebssystem und die Anwendungen als einzelne Entitäten mit Layern verwalten. Beispielsweise muss Windows gepatcht werden, der Patch wird einmal auf dem Betriebssystemlayer erstellt und alle Images, die den Betriebssystemlayer verwenden, werden von der App Layering-Appliance aktualisiert. Wenn Microsoft Office in 10 Images verwendet wird, ist das Aktualisieren dieses Office einfacher, indem Sie dem Office-Layer eine Version hinzufügen. Schließlich werden all diese 10 Images automatisch aktualisiert.

Wenn Elastic Layering hinzugefügt wird, ist es auch möglich, die Anzahl der erforderlichen Images erheblich zu verringern. Elastic Layer ermöglicht es den Administratoren, Anwendungen während der Anmeldung dynamisch bereitzustellen. Für Anwendungen, die nicht von allen Benutzern verwendet werden, ermöglicht Elastic Layers eine generischere Erstellung des Images und bietet gleichzeitig eine Anpassung für jeden Benutzer.

2-Unterstützung für mehrere Hypervisoren und Azure

Viele Unternehmen wechseln zu einer hybriden Multi-Cloud-Umgebung, in der on-premises und Cloud-Ressourcen kombiniert werden, um die Benutzererfahrung zu verbessern. Citrix App Layering bietet Image-Portabilität, indem die meisten Hypervisoren und Microsoft Azure unterstützt werden, indem einfach eine andere Platform Layer für jede gewünschte Umgebung erstellt wird.

AL-Image-3

Normalerweise zwingt eine gemischte Hypervisor- und Hybrid-Cloud-Konfiguration die Administratoren dazu, mehrere verschiedene Gruppen von Images und Anwendungen auf mehreren verschiedenen Managementplattformen zu verwalten. Mit der App Layering-Technologie können dasselbe Betriebssystem und dieselben Anwendungen, die on-premises verwendet werden, mit wenig bis gar keinem zusätzlichen Aufwand in die Cloud oder auf einen anderen Hypervisor übertragen werden.

Informationen zur plattformübergreifenden Funktionalität von App Layering finden Sie im Abschnitt Citrix App Layering Cross-Platform Support weiter unten.

3- Hypervisor-Portabilität für Migration

Unternehmen bleiben oft mit der Technologie eines Anbieters „hängen“, nur weil die Migration auf neue Technologien unerschwinglich teuer ist. Außerdem fusionieren Unternehmen häufig mit anderen Organisationen, die unterschiedliche Technologieentscheidungen getroffen haben. Einer der besonderen Vorteile von App Layering ist die Möglichkeit, von einer Plattform zur anderen zu wechseln, indem Sie einfach einen anderen Plattformlayer erstellen und die App Layering-Appliance mit Import/Export auf die neue Plattform migrieren.

AL-Image-4

Ermöglicht eine nahtlose Migration, beispielsweise von vSphere zu Citrix Hypervisor oder von einem lokalen Hypervisor zu Azure.

4-Persistenz für gemeinsam genutzte VDI-Desktops

Viele Organisationen haben mehrere Benutzer, die ein hohes Maß an Persistenz auf Desktops benötigen. Einschließlich Power-User in jeder Gruppe, Entwickler, Ingenieure, Architekten und so weiter. App Layering Benutzerlayers bieten zusätzlich zu einer gepoolten Desktop-Architektur ein erhebliches Maß an Persistenz.

Der Benutzerlayer wird bei der Anmeldung bereitgestellt, und alle nachfolgenden Schreibvorgänge auf dem Desktop werden in den Benutzerlayer geschrieben. Die meisten Anwendungen können im Benutzerlayer installiert werden. Die Regeln für das, was in der Benutzerebene funktioniert, sind dieselben wie für Elastic Layering. Solange die Anwendung keine Kerneltreiber, Treiber von Drittanbietern und Dienste installiert, die während des Boots Abhängigkeiten zu anderen Diensten sind, funktionieren sie höchstwahrscheinlich in dem Benutzerlayer.

AL-Image-5

Für Anwendungsfälle, die Persistenz erfordern, ist der Benutzerlayer die beste Wahl. Für Anwendungsfälle, die nur Microsoft Outlook OST-Dateien und Indexdateien unterstützen, ist der Benutzerlayer möglicherweise nicht die beste Wahl. Der Benutzerlayer soll alle Schreibvorgänge auf den VDI-Desktop verarbeiten, nachdem sich der Benutzer angemeldet hat. Andere Technologien wie der Citrix Profile Management Outlook Container oder FSLogix Profile oder Office 365 Container behandeln die Outlook-OST und -Indizes viel gezielter, sodass die Menge der vom Container verarbeiteten I/O geringer ist. Alle diese Lösungen verwalten jetzt die Verwaltung der Outlook-OST-, Outlook-Streaming-Dateien und Outlook-Indexdateien, sodass die Unterstützung der Indizierung kein Grund mehr ist, sich für eine andere Technologie zu entscheiden.

Technischer Überblick über Citrix App Layering

Arten von Layern

Ein Layer ist ein virtuelles Laufwerk, das die Dateien und Registrierungseinträge enthält, die beim Packen geändert oder hinzugefügt werden. Mit Ausnahme der ersten Version der Betriebssystemschicht werden Layer von der App Layering-Appliance erstellt, die in den Hypervisor integriert ist. Ein Administrator erstellt einen Layer, und die Appliance stellt dynamisch eine Verpackungsmaschine mit einem Startdatenträger und einem Layerdatenträger bereit. Beim Booten der Verpackungsmaschine werden alle Änderungen an der Verpackungsmaschine auf den Layerdatenträger geschrieben. Wenn die Verpackung abgeschlossen ist, wird dieser Datenträger zurück in die Appliance kopiert, und alle Dateien und Registrierungsänderungen werden in den neuen Layer geschrieben und im Layerrepository im VHD-Format gespeichert.

App Layering verwendet diese verschiedenen Arten von Layer:

  • Betriebssystemlayer
  • Plattformlayer
  • Andwendungslayer
  • Vollständige Benutzerlayer

AL-Image-7

OS-Layer: Das Betriebssystem wie Windows 10 oder Windows Server 2019. Gebaut aus einer “Gold Image”-VM im Hypervisor.

Plattformlayer: Der Plattformlayer enthält die Software, die zur Unterstützung einer bestimmten Plattform erforderlich ist. Einschließlich des Brokeragents, des Provisioningsystems und der Hypervisor-Tools, wenn sich der Hypervisor vom Standardhypervisor unterscheidet. Die Plattformlayer ist auch der Layer mit der höchsten Priorität und manchmal wird hier Software installiert, so dass sie mit der höchsten Priorität kompiliert wird.

App-Layer: Der Haupttyp für Layertyp. Wird für die meiste Anwendungssoftware verwendet.

Benutzerlayer: Ein elastischer (siehe nächsten Abschnitt) beschreibbarer Layer. Benutzerlayer werden bei der Anmeldung bereitgestellt und nach der Bereitstellung werden fast alle Desktopschreibvorgänge auf den Benutzerlayer übertragen. Diese Layer bietet Benutzern die Möglichkeit, ihre VDI-Erfahrung erheblich anzupassen, obwohl sie in dem Modell ein gemeinsam genutzten Desktop verwenden.

Citrix App Layering-Appliance

Die Citrix App Layering-Appliance (Appliance) bietet sowohl die Verwaltungsschnittstelle für App Layering als auch die Engine für alle App Layering-Prozesse.

Die App Layering-Appliance wird als virtuelle Maschine in dem Rechenzentrum bereitgestellt, in dem die Anwendungspaketierung und die Veröffentlichung von Images stattfinden. Die App Layering-Appliance basiert auf CentOS und ist mit 4 vCPUs und 8 GB RAM konfiguriert. Diese Einstellungen dürfen nicht geändert werden, da die Appliance für die Verwendung in dieser Konfiguration ausgelegt ist.

Die Appliance wird mit zwei Datenträgern erstellt. Der erste Datenträger ist ein 30-GB-Bootdatenträger für das Betriebssystem. Der zweite Datenträger ist das 300 GB Layerrepository. Dieser Datenträger kann bei Bedarf erweitert oder erweitert werden, wenn mehr Speicherplatz benötigt wird.

Während der Layer-Erstellung und Image-Veröffentlichung speichert die Citrix App Layering Appliance virtuelle Festplattendateien im VHD-Format in ihrem Layer-Repository innerhalb der Appliance. Die Appliance ist mit einem SMB-Share verbunden, um den Upgrade-Prozess der Appliance zu unterstützen und Elastic Layers zu speichern.

Die Appliance wird nur zum Verwalten von Layer, Images und Elastic Layer-Zuweisungen verwendet. Virtuelle Desktops und Server für virtuelle Apps sind nicht direkt mit der Appliance verbunden. Wenn ein Layer elastisch zugewiesen wird, kopiert die Appliance den Layer in die Elastic Layer-Freigabe. Die Freigabe enthält diese VHD-Dateien sowie eine Reihe von JSON-Dateien, die Benutzern die Layerzuweisungen bereitstellen.

Die Citrix App Layering-Appliance hostet auch die App Layering-Verwaltungskonsole. Die Bereitstellung der App Layering-Appliance ist der erste Schritt im Installationsprozess. Nach der Installation der Appliance wird auf die Verwaltungskonsole zugegriffen, um die Installationsschritte abzuschließen.

Weitere Informationen zur Installation der Citrix App Layering-Appliance finden Sie in der Produktdokumentation.

AL-Image-6

Die Citrix App Layering-Verwaltungskonsole ist eine webbasierte Anwendung, die auf der App Layering-Appliance gehostet wird. Die App Layering Management Console bietet die Schnittstelle zu:

  • Erstellen und Verwalten von Betriebssystem-, Plattform- und Andwendungslayer
  • Erstellen veröffentlichter Imagevorlagen
  • Layerimages veröffentlichen und verwalten
  • App Layering - Benutzern Administratorrollen zuweisen
  • Verwalten Sie die Appliance- und Systemeinstellungen wie Aufgaben- und Protokollaufbewahrung, Sicherheitseinstellungen und Netzwerkdateifreigaben

Compositing Engines

Neu in Version 1910 und höher ist sind Compositing Engines. Compositing Engines entlasten die meisten Paketerstellungs- und Publishing-Aufgaben, die auch von der App Layering-Appliance ausgeführt werden können. Durch die Auslagerung dieser Aufgaben lassen sich die Verpackungs- und Veröffentlichungsprozesse besser skalieren, und aufgrund der Vorteile der verwendeten Technologien wird auch die Leistung des Prozesses verbessert.

Eine Compositing Engine wird von einem Hypervisor-Connector als virtuelle Windows-PE-Maschine erstellt, die eine Reihe von Veröffentlichungsaufgaben ausführt und sich dann in eine Verpackungsmaschine oder ein veröffentlichtes Image neu startet. Die Compositing Engine wird verwendet, um zwischengespeicherte Layerdatenträger zu erstellen, Verpackungsmaschinen zu erstellen und Images zu veröffentlichen. Zum Zeitpunkt des Schreibens dieser Referenzarchitektur gibt es Compositing Engines for HyperV und vSphere, die in den Versionen 1910 bzw. 1911 eingeführt wurden.

Compositing Engines haben folgende Eigenschaften:

  • Leichte, kurzlebige Appliance mit Windows PE
  • Selbstkomponierend
  • Kontrolliert über REST API
  • Unterstützte Hypervisor-Festplattenformate (VHD, VHDX und VMDK)
  • UEFI-Unterstützung (Gen2)
  • Sicheres Booten auf veröffentlichten Images (nur wenn keine Elastic Layering oder Benutzerlayers verwendet werden)
  • iSCSI wird zum Anhängen von Datenträgern verwendet, die auf der App Layering-Appliance gehostet werden
  • Keine Begrenzung der Anzahl gleichzeitiger Veröffentlichungsjobs (es gibt ein praktisches Limit)

Vorteile von Compositing Engines

Die Verwendung von Compositing Engines ist eine Wahl. Im HyperV Connector und im vSphere Connector gibt es ein Kontrollkästchen, um “Offload Compositing” zu aktivieren. Diese Einstellung ist auch in der Machine Creation for vSphere und den VMware Horizon View-Connectors verfügbar. Der wesentliche Vorteil der Compositing Engine besteht darin, dass sie auf einem Windows-Gerät mit direktem Zugriff auf Hypervisor-Datenträger läuft. Dies bietet die Mechanismen zur Unterstützung von GEN2-Maschinen in HyperV, nativen ESX VMDK-Formaten mit Thin Provisioning in vSphere und UEFI in beiden Bereichen. Die Paket- und Publishing-Leistung wird verbessert, da die Large-Layer-Dateien weniger verarbeitet und von der Compositing Engine direkt in Datenträgern auf dem Hypervisor geschrieben werden, die an die App Layering-Appliance zurückgesetzt werden, um über iSCSI-Verbindungen auf die Layer zuzugreifen.

Hinweis: PVS Publishing kann noch nicht mit einer Compositing Engine durchgeführt werden, daher ist es immer noch nicht möglich, eine VHDX-Datei oder eine virtuelle GEN2-Maschine direkt auf PVS zu veröffentlichen.

Layerbereitstellung

Layer können auf zwei Arten geliefert werden. Als Teil eines veröffentlichten Images, bei dem die App Layering-Appliance alle Layer zu einer einzigen Datenträgerdatei zusammenfasst und diese Datei in das Provisioningsystem hochlädt oder wo Layer bei der Anmeldung bereitgestellt und Benutzern dynamisch zur Verfügung gestellt werden.

Veröffentlichtes Image: Hier werden ein Betriebssystem, eine Plattform und ein Satz Andwendungslayer zu einer einzigen Datenträgerdatei kombiniert, die auf einem Provisioningsystem wie Citrix Provisioning oder Maschinenerstellungsdienste veröffentlicht wird. Der Prozess beginnt mit dem Klonen der OS-Layer und dem anschließenden Einschreiben der Dateien aus den Anwendungsschichten nacheinander in der Prioritätsreihenfolge, wobei je neuer der Layer, desto höher seine Priorität ist, und schließlich das Schreiben in die Plattformlayer. Der Zusammenführungsprozess zum Erstellen veröffentlichter Images ist fortgeschritten. Beim Erstellen eines Images werden die Dateisysteme, Registrierungs- und Umgebungsvariablen zusammengeführt. Der Windows-Treiberspeicher wird neu erstellt, wobei alle Drittanbietertreiber aus verschiedenen Layern zusammengeführt werden.

Elastischer Layer: Bei diesen Layer handelt es sich um App-Layer, die Benutzern durch die Active Directory-Gruppenmitgliedschaft zugewiesen und während oder kurz nach der Anmeldung angehängt werden. Elastische Layer sind dynamisch und ermöglichen es den Administratoren, die Benutzererfahrung anzupassen und gleichzeitig die Anzahl der Images zu minimieren.

Connectors und Connectorkonfigurationen

Die App Layering-Appliance lässt sich mit Connectors in Hypervisors und Provisioningsysteme integrieren.

Es gibt zwei Arten von Connectors — Hypervisor und Provisioning:

  • Hypervisor-Connectors bieten den Mechanismus für die Schnittstelle mit einem Hypervisor. Derzeit gibt es Hypervisor-Connectors für Citrix Hypervisor, vSphere, Hyper-V, Nutanix AHV, Azure und Azure Gov.

  • Provisioningsystemconnectors ermöglichen es dem Administrator, ein Image im Provisioningsystem zu veröffentlichen. Derzeit gibt es auf jedem Hypervisor und Horizon View einen Provisioning System Connector für Citrix Provisioning, Citrix Machine Creation Services.

Eine einzelne Appliance kann eine Verbindung zu einer beliebigen Anzahl von Hypervisors oder Provisioningsystemen herstellen, indem mehr Connectors definiert werden. Connectorkonfigurationen definieren die Einstellungen, die für die Integration in den Hypervisor oder das Provisioningsystem erforderlich sind. Eine Konfiguration umfasst in der Regel Anmeldeinformationen für die Authentifizierung, einen Speicherort, eine VM-Vorlage und alle anderen Informationen, die für die Schnittstelle mit der Umgebung erforderlich sind, in der die Administratoren Layer erstellen oder Images veröffentlichen. Der Administrator kann mehrere Connectorkonfigurationen erstellen, die jeweils für den Zugriff auf einen eindeutigen Speicherort in der Umgebung konfiguriert sind. Connector werden verwendet für:

  • Importieren eines Golden Image beim Erstellen eines OS-Layers
  • Erstellen von Layer und Layerversionen
  • Veröffentlichen Sie Layerimages auf einem Hypervisor oder Provisioning Service. Eine Connectorkonfiguration kann auch ein PowerShell-Skript für die Ausführung auf einem Provisioningserver oder ein System mit einem Hostagent enthalten, um die Nachbearbeitung eines veröffentlichten Images durchzuführen.

Referenz: Connectorkonfigurationen

Connectortypen

In diesem Abschnitt werden die in Citrix App Layering verfügbaren Connectortypen definiert.

Hypervisor-Connectors

Hypervisor-Connectors werden beim Erstellen von Layern oder beim Importieren eines Gold-Images zum Erstellen des Betriebssystemlayers verwendet. Hypervisor-Connectors erstellen beim Verpacken dynamisch eine Verpackungsmaschine auf dem durch die Connectorkonfiguration definierten Speicher und Host. Eine Hypervisorverbindung kann auch verwendet werden, um eine virtuelle Maschine im Hypervisor zu erstellen.

Citrix Provisioning

Citrix Provisioning Connector lässt sich in einen App Layering Agent auf einem Citrix Provisioning-Server integrieren, um ein Image als virtuelles Laufwerk direkt auf dem Provisioningserver zu veröffentlichen. Die Voraussetzungen für Citrix Provisioning sind:

  1. Das Connector-Dienstkonto muss ein Domänenkonto mit der Administratorberechtigung in PVS sein.
  2. Das Connectordienstkonto muss außerdem ein lokaler Administrator auf dem Citrix Provisioning-Server sein.
  3. Auf jedem in einem Connector definierten Citrix Provisioning-Server muss ein Citrix App Layering Agent installiert sein. Pro Connector kann nur ein Agent definiert werden.

Referenz: Citrix Provisioning

Maschinenerstellungsdienste

Die Citrix App Layering Appliance kann Layerimages direkt als virtuelle Maschinen bereitstellen und auf Hypervisoren veröffentlichen, die als Masterimage für MCS verwendet werden. Connectors ermöglichen die direkte Veröffentlichung von Layerimages auf dem Hypervisor. Der MCS-Connector ist fast identisch mit den Hypervisor-Connectors, mit der Ausnahme, dass der MCS-Connector die veröffentlichte virtuelle Maschine startet, wodurch alle in Layern definierten Skripts auf dem Masterimage ausgeführt werden können, bevor er von MCS bereitgestellt wird. Das Masterimage wird heruntergefahren und ein VM-Snapshot wurde als Teil dieses Prozesses erstellt.

Connectorskripts

Dieser Schritt ist eine optionale und erweiterte Funktion, die beim Erstellen einer Connectorkonfiguration verfügbar ist. Um diese Funktion zu verwenden, konfigurieren Sie ein optionales PowerShell-Skript, das auf dem definierten Agentserver in der Connectorkonfiguration ausgeführt wird. Dieser Schritt wird am häufigsten mit Citrix Provisioning verwendet, kann jedoch mit jedem anderen Publishing-Connector verwendet werden, indem der App Layering Agent auf einem Windows-System installiert wird, um Skripts für ein veröffentlichtes Image auszuführen. Kopieren Sie die Skripts auf den Computer, auf dem der Agent installiert ist. Dieses Skript wird nach einer erfolgreichen Bereitstellung eines Layerimage ausgeführt. Um diese Funktionalität nutzen zu können, muss das Skript bei einem Masterimage auf einem Hypervisor auch eine Schnittstelle zur Verwaltungsplattform des Hypervisors haben. Für vSphere muss das Skript beispielsweise möglicherweise PowerCLI gegen vCenter verwenden, um Code für die virtuelle Master-Image-Maschine auszuführen.

Einige voreingestellte Variablen sind verfügbar, damit Skripts mit verschiedenen Vorlagenimages und unterschiedlichen Connectorkonfigurationen wiederverwendet werden können. Die Variablen enthalten auch Informationen, die die virtuelle Maschine als Teil des veröffentlichten Images identifizieren.

Weitere Informationen zu den Beispielskripts finden Sie in den folgenden Support-Artikeln CTX226060 und CTX226062.

Veröffentlichte Imagevorlagen

Bei Verwendung von App Layering werden Betriebssystem-, Plattform- und Anwendungslayer von der App Layering-Appliance zusammengeführt, um veröffentlichte Images zu erstellen. Images werden veröffentlicht und dann in einem Format erstellt, das vom Zielprovisioningsystem benötigt wird. Wenn die Administratoren beispielsweise in Citrix Provisioning veröffentlichen, erstellt die Appliance einen virtuellen Datenträger und lädt ihn als virtuelles Laufwerk auf den definierten Provisioningserver hoch. Falls die Lösung Maschinenerstellungsdienste auf Citrix Hypervisor verwendet, erstellt die Appliance einen virtuellen Datenträger, lädt ihn in Citrix Hypervisor hoch und erstellt mithilfe der virtuellen Festplatte eine Masterimage-VM.

Um die Konfiguration eines veröffentlichten Images zu definieren, wird eine Imagevorlage verwendet. Die Imagevorlage definiert, welche Betriebssystem-, Plattform- und Anwendungslayer im Image enthalten sind. Außerdem wird der Connector definiert, der zum Veröffentlichen des Images verwendet wird, wie groß das resultierende Image ist (in GB), ob für das Image Elastic Layering aktiviert ist oder ob einer der verschiedenen Arten von Benutzerlayern verwendet wird. Die Imagevorlagen sind ein Point-in-Time-Snapshot der Image-Konfiguration, sie unterstützen keine Versionsverwaltung. Imagevorlagen können jedoch geklont und geändert werden, wenn leicht unterschiedliche Versionen desselben Images erforderlich sind.

App Layering-Agent

Der Citrix App Layering-Agent stellt die Kommunikation zwischen der App Layering-Appliance und entweder einem Citrix Provisioning-Server, einem Hyper-V-Server oder nur einem Windows-Computer bereit, der als Skriptserver verwendet wird. Der App Layering Agent kann auch verwendet werden, um die Skripterstellung nach der Veröffentlichung von Images auf anderen Hypervisoren wie Citrix Hypervisor oder vSphere zu automatisieren. Für Citrix Provisioning und Hyper-V kontaktiert der App Layering Connector den App Layering Agent und fordert ihn auf, die VHD, die die Appliance auf den Server des Agenten kompiliert hat, zu übertragen. Diese Übertragung wird vom Agenten mithilfe von BITS initiiert und die Datei wird von der Appliance heruntergeladen.

Die Details des Citrix App Layering-Agents finden Sie in der Citrix Dokumentation.

Referenz: Agent installieren

Active Directory

Die App Layering-Appliance stellt eine Verbindung zu Active Directory her, um sich sowohl bei der Appliance als auch bei der Zuweisung von Elastic Layers zu authentifizieren. Wenn sich ein Administrator bei der Appliance anmeldet, versucht er, sich mit denselben Anmeldeinformationen bei Active Directory anzumelden. Wenn diese Anmeldung funktioniert, darf der Benutzer die Appliance betreten.

Der Zugriff auf Verzeichnisdienste ist für folgende Zwecke erforderlich:

  • Rollenbasierte Zugriffskontrolle (RBAC)
  • Zuweisung von Elastic und Benutzerlayer

Während der anfänglichen Bindung mit dem Verzeichnisdienst ist die App Layering-Appliance mit der SSL 3.0 Secure Socket Layer und der TLS 1.1 und 1.2 Transportschichtsicherheit kompatibel.

Informationen zum Erstellen einer Verzeichnisverbindung finden Sie in der Produktdokumentation.

Layer

Im folgenden Abschnitt werden die Verwendungen für jeden Layertyp ausführlicher beschrieben.

OS-Layer

Ein OS-Layer ist ein Layer, der das Windows-Betriebssystem enthält. Es ist eine gängige Praxis, alle Komponenten, die möglicherweise mit Windows Update aktualisiert werden, in die Betriebssystemlayer aufzunehmen, sodass alle von Windows Update aktualisiert werden. Aus diesem Grund sind alle Betriebssystemrollen und -komponenten wie .NET- und Visual C++-Laufzeitbibliotheken als Teil des Betriebssystemimages enthalten.

Es ist vorzuziehen, keine Endbenutzeranwendungen in der OS-Layer zu installieren, da alle Anwendungslayers, die mit einer bestimmten OS-Layer erstellt wurden, an diese OS-Layer gebunden sind. Wenn eine Anwendung in der OS-Layer installiert ist, führt jedes Image, das diesen Layer verwendet, um diese Anwendung in diesen Prozess einzubeziehen, zu einem Problem, wenn die Strategie darin besteht, die OS-Layer universell zu machen. Die Trennung von Anwendungen vom Betriebssystem ist der Schlüssel zur Begrenzung der Anzahl der zu verwaltenden Betriebssystemimages. Selbst Anwendungen mit Treibern, Diensten und Kernelgeräten werden in Anwendungsebenen unterstützt und müssen nicht in die OS-Layer aufgenommen werden.

Bei der Erstellung des Betriebssystemlayer sind einige Punkte zu beachten:

  • Überprüfen Sie die unterstützten Betriebssysteme über den Link
  • Die OS-Layer ist nicht mit der Domäne verbunden. Der Domain-Join ist Teil des Plattformlayer
  • Die Hypervisor-Tools für den primären Hypervisor werden in der OS-Layer installiert. Der Hypervisor, in dem die meisten Pakete ausgeführt werden
  • Die Hypervisor-Tools für alternative Hypervisoren werden in der Plattformlayer für diesen Hypervisor installiert.
  • Installieren Sie .NET-Komponenten (von Microsoft) und Updates in der OS-Layer
  • Wenn Microsoft Runtimes erforderlich sind, werden sie in der OS-Layer installiert
  • Windows-Rollen und -Features wie die RDS-Rollen, die im OS-Layer installiert sind, sodass sie mit Windows Update aktualisiert werden können
  • Falls ein lokaler Benutzer oder eine lokale Gruppe zu den virtuellen Maschinen hinzugefügt werden muss, kann diese Aufgabe nur auf der Betriebssystemlayer ausgeführt werden, da der Windows Security Account Manager (SAM) von der Betriebssystemlayer erfasst wurde

Referenz: Erstellen einer OS-Layer

Plattformlayer

Ein Plattformlayer ist ein Layer, der Konfigurationseinstellungen, Werkzeuge und andere Software enthält, die zum Ausführen eines veröffentlichten Images auf einer bestimmten Plattform erforderlich sind. Zwei Plattform-Layer-Typen können erstellt werden:

Plattformlayer veröffentlichen: Dieser Plattformlayertyp wird verwendet, um die von einem Zielprovisioningsystem, einem Broker und einem Hypervisor erforderliche Software einzuschließen. Beispielsweise sind auf einem Publishing-Plattform-Layer zur Unterstützung von Provisioning Services auf vSphere für Citrix Virtual Apps der Citrix VDA und die PVS-Gerätetreiber installiert. Wenn vSphere nicht derselbe Hypervisor ist, auf dem die Verpackung durchgeführt wird, ist auf diesem Layer auch VMware Tools installiert.

Verpackungsplattformlayer: Verpackungsplattformlayer werden verwendet, wenn ein Verpackungslayer zur Unterstützung von Verpackungsmaschinen erforderlich ist. Diese Layer werden nicht oft benötigt, aber es gibt mehrere Fälle, in denen eine erforderlich sein muss, darunter:

  1. Wenn ein Layer auf einem anderen Hypervisor als dem Standard verpackt werden muss. Wenn beispielsweise die meisten Layer auf Hyper-V erstellt werden, aber aus irgendeinem Grund ein bestimmter Layer in vSphere erstellt wurde, wird ein Verpackungsplattformlayer mit VMware Tools verwendet, um die Verpackungsmaschine auf vSphere zu unterstützen.

  2. Wenn der Zugriff auf die Verpackungsmaschine mithilfe der VDA-Software erforderlich ist. Diese Layer wird am häufigsten bei der Installation von Treibern für USB-Peripheriegeräte benötigt, bei denen das Gerät ordnungsgemäß installiert werden muss. Durch Erstellen eines Verpackungsplattformlayers mit installierter VDA-Software und Hinzufügen der Verpackungsmaschine zu einem manuell bereitgestellten Katalog in Studio kann dieser Zugriffstyp unterstützt werden.

Erstellen eines Plattformlayers

Für die Erstellung der Plattformlayer sind einige Punkte zu beachten:

  • Bei Citrix Provisioning wird die Zielgerätesoftware installiert, ohne den Imaging-Assistenten auszuführen, und anschließend neu gestartet.
  • Die Installation der Citrix VDA- und Citrix Provisioning-Gerätetreiber erfolgt im Plattformlayer
  • Der Domänenbeitritt erfolgt in der Plattformebene. Das bedeutet, dass mehrere Plattformebenen erstellt werden können, um verschiedene Domänen zu unterstützen
  • Der Plattformlayer ist auch die höchste Priorität. Daher können einige optionale Komponenten installiert werden, einschließlich SSO-Software wie Imprivata, Hypervisor Tools für alternative Hypervisoren und Citrix Workspace Environment Management Agent.

Weitere Informationen zur Erstellung von Platform Layer finden Sie im Artikel CTX225997.

App-Layer

App-Layer werden verwendet, um die meisten Anwendungen zu verpacken. App-Layer enthalten Dateisystem- und Registrierungsobjekte für eine Anwendung oder eine Gruppe von Anwendungen. Beim Erstellen oder Bearbeiten eines Layer wird eine Verpackungsmaschine dynamisch erstellt, und alle Dateisystem- und Registrierungsänderungen werden auf diesem Computer erfasst. Die Packaging Machine enthält den Betriebssystemlayer und alle enthaltenen vorausgesetzten App-Layer. Ein zweites virtuelles Laufwerk, Package Disk genannt, wird als beschreibbares Volume an die Verpackungsmaschine angehängt. Dieser Datenträger erfasst alle Dateisystemänderungen während des Paketierens und enthält auch eine Registrierungsstruktur (RSD-Hive genannt), mit der alle Registrierungsänderungen erfasst werden. Wenn die Verpackungsmaschine fertiggestellt ist, wird nur die Package Disk heruntergeladen. Der Startdatenträger wird gelöscht.

Weitere Informationen zum Erstellen und Bearbeiten von App-Layern finden Sie in der Produktdokumentation.

In den meisten Fällen werden Anwendungen mit derselben Konfiguration installiert, die der Administrator normalerweise für das unterstützte Provisioning-System verwendet. Beim Erstellen von App-Layern ist es immer wichtig, automatische Updates zu deaktivieren. Weil der Administrator normalerweise nicht möchte, dass Anwendungen nach der Bereitstellung automatisch aktualisiert werden. Citrix hat den Layering-Prozess für einige gängige Anwendungen dokumentiert. Thesen App Layering “Rezepte” finden Sie unter folgendem Link.

Referenz: App Layering Rezepte

Elastic Layering

Elastic Layering ist eine Methode zum dynamischen Bereitstellen der Anwendung in einer virtuellen Sitzung während der Benutzeranmeldung, indem als VHD-Dateien gespeicherte Layer auf einer SMB-Freigabe bereitgestellt und mithilfe des Citrix Composite File System (CFS) in das Dateisystem integriert werden. Elastic Layering wird auf dem VDA vom Citrix Layering Service verwaltet. Das Elastic Layer Repository ist eine SMB-Freigabe, die sowohl die Layer-VHD-Dateien als auch die JSON-Konfigurationsdateien enthält, die zum Definieren von Layer-Zuweisungen für den Layering-Service verwendet werden. Der Layering-Dienst liest die Konfigurationsdateien und mountet dann Layer-VHD-Dateien mithilfe eines Windows SDK-Aufrufs.

Alle Anwendungen werden nicht von der Elastic Layering-Technologie unterstützt, da Elastic Layers während der Anmeldung bereitgestellt werden. Die folgenden Anwendungsanforderungen schließen die Verwendung von Anwendungen in Elastic Layers aus:

  1. Anwendungen mit Kerneltreibern
  2. Anwendungen mit Diensten, die von anderen Boot-Time-Diensten abhängig sind
  3. Anwendungen, die den Windows Driver Store ändern, wie Druckertreiber von Drittanbietern

Anwendungen mit diesen Anforderungen können geschichtet werden, die Layer müssen jedoch in das veröffentlichte Image aufgenommen werden.

Konfigurationsdateien (JSON)

Wie bereits erwähnt, werden Elastic Layer-Zuweisungen in einer Reihe von.JSON-Dateien definiert, die im Elastic Layer Repository gespeichert sind. Diese Dateien sind wie folgt definiert:

  • ElasticLayerAssignment.json: Diese Datei enthält Informationen über die Benutzer- und Gruppenzuordnung zu Anwendungsebenen. Diese Datei enthält einen Eintrag für jede Gruppe oder Benutzer-ID, der Anwendungen zugewiesen wurden, und unter der SID für dieses AD-Objekt werden die Layer-Zuweisungen aufgelistet.

  • Layers.json: Diese Datei definiert die Layer im Repository und Metadaten über den Layer. Diese Datei wird verwendet, um den Pfad zu ermitteln, der zum Mounten der VHD verwendet wird.

  • MachineAssociations.json: Wie der Name schon sagt, definiert er die Maschinenzuordnung mit einer beliebigen AD-Gruppe. Das Format verwendet Computernamenmuster, die Platzhalter enthalten, um eine Gruppe von Computern mit einer definierten AD-Gruppe zu verknüpfen. Wenn sich ein Benutzer bei einem Computer anmeldet, der dem Muster entspricht, erhält er die Elastic Layers, die dieser Gruppe zugewiesen sind. Diese Einstellungen werden in der App Layering Management Console im Abschnitt Benutzer>Gruppendefiniert.

Benutzerlayer

Benutzerlayer bieten Benutzern eine persistentere Benutzererfahrung und unterstützen gleichzeitig ein Computeringmodell mit gemeinsam genutzten Desktops. Nachdem ein User Layer gemountet wurde, werden die meisten Systemschreibvorgänge auf den User Layer umgeleitet. Diese Layer ermöglicht die Unterstützung für Folgendes:

  • Die Profil- und Dateneinstellungen jedes Benutzers werden im Benutzerlayer gespeichert
  • Benutzerinstallierte Anwendungen werden in der Benutzerlayer unterstützt, sofern die Anwendungen den von Elastic Layers zugelassenen Regeln entsprechen.

Benutzerlayer werden eins zu eins zugewiesen. Ein Benutzer kann nur einen vom Benutzer beschreibbaren Layer pro OS-Layer pro Domäne haben. Der Benutzer kann sich daher nur bei einer Bereitstellungsgruppe oder einem Pool mit einem Desktop anmelden, der dieselbe Kombination aus OS-Layer und Plattformlayer verwendet, wobei der Benutzerlayer aktiviert ist. Dieser Layer wird als virtuelles Laufwerk auf einer Dateifreigabe erstellt, wenn sich der Benutzer zum ersten Mal anmeldet.

Ab Version 1910 unterstützt die vollständige Benutzerlayer die Persistenz des Suchindex zwischen Sitzungen. Um dies zu unterstützen, ist der Windows-Suchdienst beim Booten auf DEAKTIVIERT (4) auf VDAs eingestellt. Wenn sich der Benutzer am Ulayer-Dienst anmeldet, ändert sich der Starttyp des Windows-Suchdienstes in START_ON_DEMAND (3). Vor der Aktivierung von WSearch muss der ULayer-Dienst auch sicherstellen, dass die Registrierungseinstellungen für den „Crawl-Scope“ des Indexers korrekt sind. Der Crawl-Bereich ist eine Reihe von Registrierungsschlüsseln, die die zu indizierenden Bereiche der zu indizierenden Daten des Benutzers bestimmen. Die Eingabe in den Crawl-Scope erfolgt über die in das Basisimage integrierten Standardeinstellungen, kann aber auch aus den Elastic Layer und den Persistenz-Layer-Einstellungen des Benutzers stammen. Diese Eingaben werden zum Zeitpunkt der Anmeldung verarbeitet, um den vollständigen Satz von Crawl-Scope-Standorten bereitzustellen, und es gibt einen bescheidenen, aber messbaren Aufwand, um dies für jede Anmeldung zu erstellen. Um diesen Overhead zu vermeiden, generiert der ULayer-Service eine Hash-Zeichenfolge, die die Basis-Image-Bereitstellung (z. B. die BIC-Instanz) und die Elastic-Layer-Zuweisungen darstellt, und speichert diese Zeichenfolge in der Datei\ Program Files\ Unidesk\ Etc\ UserLayer.json des Benutzers als „IndexerHash“. Bei nachfolgenden Anmeldungen wird diese Zeichenfolge mit dem neu berechneten IndexerHash verglichen und nur wenn sie sich unterscheiden, wird der Crawl-Scope neu aufgebaut.

Die folgenden Typen von Benutzerlayern können verwendet werden:

  • Voll: Alle Daten, Einstellungen und lokal installierten Apps eines Benutzers werden in seiner Benutzerlayer gespeichert
  • Office 365: Nur die Outlook-Daten und -Einstellungen des Benutzers werden auf seinem Benutzerlayer gespeichert. Suchindizes werden bei jeder Anmeldung neu erstellt.
  • Session Office 365: Nur die Outlook-Daten und -Einstellungen des Benutzers werden auf seinem Benutzerlayer gespeichert. Suchindizes werden bei jeder Anmeldung neu erstellt.

Hinweis: Bei Verwendung des Office 365-Layers wird empfohlen, die Citrix Profilverwaltung zu verwenden, um Outlook-Einstellungen zu speichern.

Die standardmäßige maximale Größe eines Benutzerlayers beträgt 10 GB. Diese Größe kann geändert werden, indem ein Kontingent für die Benutzerlayer-Freigabe definiert wird. Es ist auch möglich, die standardmäßige maximale Größe des Benutzerlayers mithilfe eines Registrierungseintrags auf den VDAs zu überschreiben. Um die maximale Standardgröße zu ändern, fügen Sie die folgende Registrierungsüberschreibung hinzu:

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE: <Size in GB>

Elastic Layer Share und Benutzerlayer Shares

Elastic Layers sind VHD-Dateien, die von einem Client- oder Serverbetriebssystem über das VM-Netzwerk gemountet werden. Elastic Layers werden schreibgeschützt gemountet, und viele Maschinen können dieselbe VHD-Datei mounten. Der für Elastic Layers verwendete Dateiserver oder die Freigabe ist für die Lese-I/O optimiert.

Benutzerlayer sind beschreibbare elastische Layer. Der Benutzerlayer wird mit Lese-/Schreibzugriff nur von einem einzigen Desktop bereitgestellt. Der Dateiserver oder die Freigabe, die für Benutzerlayers verwendet wird, sind für Schreib-E/A optimiert. Bei Verwendung von Benutzerlayers ist die Leistung des Speichers entscheidend für die Benutzererfahrung. Flash-Speicher-Arrays werden für die Benutzerlayer-Freigabe dringend empfohlen.

Die Architektur für Elastic Layers ist weitgehend skalierbar. Der Elastic Layer-Freigabe-Repository-Pfad wird in der VM-HKLM-Registrierung für VDI- und RDS-Workloads definiert. Dieses Design ermöglicht es, eine unbegrenzte Anzahl von Replikaten zu haben, um die Last zu verteilen.

AL-Image-8

Das Elastic Layer Repository und die Benutzerlayer Shares sind in der Appliance definiert. Die Elastic Layer-Freigabe wird im Abschnitt System>Einstellungen und Konfiguration definiert. Dieser Pfad kann auf VDAs mithilfe von Gruppenrichtlinien geändert werden, indem die folgenden Registrierungswerte geändert werden:

HKLM\SOFTWARE\Unidesk\ULayer\RepositoryPath

Value = \\Server\Share

Bei großen VDI-Implementierungen ermöglicht dieser Registrierungswert die Verwendung mehrerer Elastic Layer-Repositories für verschiedene Gruppen von Desktops. Weitere Informationen zum Ändern des Elastic Layer-Repositorys in der Registrierung ohne Reimaging finden Sie im Citrix-Artikel CTX222107.

Der für Benutzerlayer verwendete Standort wird von der Active Directory-Gruppe zugewiesen und ist daher auch hochgradig skalierbar, da beliebig viele Shares verwendet werden können. Diese Zuweisungen sind unter System > Speicherortedefiniert.

Weitere Informationen zur Architektur der Elastic Layer-Freigabe finden Sie im Abschnitt Verfügbarkeit, Backup und Wiederherstellung.

Dateifreigabe auf Benutzerlayer

Während des Anmeldevorgangs, wenn ein Image für Benutzerebenen konfiguriert wird, wird die Benutzerlayer-VHD-Datei erstellt, wenn sich der Benutzer zum ersten Mal anmeldet, nachdem er dem Image zugewiesen wurde. Die Share-Einstellungen für den Benutzerlayer werden in der Appliance von der Active Directory-Gruppe definiert. Wenn sich ein Benutzer in mehreren Gruppen mit zugewiesenen Benutzerlayerfreigaben befindet, gibt es eine Prioritätsreihenfolge für die Freigabe und ihre Benutzerlayerdatei, die auf der Freigabe mit der höchsten Priorität erstellt Benutzerlayerdatenträger können jeweils nur auf einer Maschine verwendet werden.

Benutzerlayer sind sowohl an die Domäne als auch an den Betriebssystemlayer für den angemeldeten Desktop gebunden. Der Pfad zu einem bestimmten Benutzerlayer lautet wie folgt:

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

Benutzerlayer sind schreibintensiv. Es wird empfohlen, eine Dateifreigabe zu verwenden, die für Schreibvorgänge optimiert ist. Wenn sich die Benutzerlayer-Freigabe von der Elastic Layer-Freigabe unterscheidet, dann wird die von AD-Benutzergruppen definierte Benutzerzuweisung.

AL-Image-9

Die Zuweisung des Benutzerlayers ist im Abschnitt System > Speicherorte in der App Layering Console definiert. Geben Sie die Freigabe und die mit der Freigabe verknüpfte Gruppe ein.

Weitere Informationen zur Architektur der Elastic Layer-Freigabe finden Sie im Abschnitt Verfügbarkeit, Backup und Wiederherstellung.

Integration von App Layering

Im folgenden Abschnitt wird die Integration von Citrix App Layering mit Provisioningsystemen und Hypervisors beschrieben.

Citrix App Layering und Citrix Provisioning Services

App Layering lässt sich einfach in Citrix Provisioning (PVS) integrieren. Die Integration wird durch die Installation des App Layering Agent auf einem oder mehreren PVS-Servern erleichtert. Der Agent stellt die Verbindung zwischen der Appliance und den Provisioning Services bereit.

AL-Image-10

Im vorhergehenden Diagramm wird das Veröffentlichen von Layerimages mit Citrix Provisioning dargestellt. Images werden zentral verwaltet und für die Bereitstellung verteilt, indem sie von der App Layering-Appliance auf einem Citrix Provisioning-Server veröffentlicht werden. Es gibt mehrere Architekturen, die zur Unterstützung von Citrix Provisioning erstellt werden können. Die am häufigsten verwendete Architektur ist die Integration eines einzelnen Produktions-PVS-Servers, der als Integrationspunkt verwendet wird. Virtuelle Datenträger werden dann vom App Layering Agent in den PVS-Serverspeicher heruntergeladen, wenn das Image veröffentlicht wird. Der Agent verwendet den Windows BITS-Dienst, um die Übertragung durchzuführen.

Wenn Images veröffentlicht werden, können Sie Connector-PowerShell-Skripts so konfigurieren, dass sie nach dem Hochladen des Images für das Image ausgeführt werden. Wenn Sie diese Funktion verwenden und die Skripts prozessorintensiv sind, ist es ratsam, einen “Pre-Staging” -Provisioning Server zu verwenden, der nicht zur Durchführung des Streamings verwendet wird. Auf diese Weise wirken sich die Veröffentlichung und die Skriptverarbeitung nicht negativ auf die Streaming-Funktionen in der Provisioning Services-Farm aus. Um dieses Design zu unterstützen, ist es am einfachsten, eine Citrix Provisioning-Farm „DEV“ mit einem einzigen Server zu erstellen. Dieser “DEV” -Server kann auch zum Streamen von Testimages verwendet werden. Sobald das Image getestet wurde, kann das virtuelle Laufwerk für weitere Tests und Bereitstellungen auf die Citrix Provisioning-Produktionsfarm repliziert werden.

Weitere Informationen zu dieser Art von Skripting finden Sie im folgenden Beispielskript aus dem Citrix Support-Artikel CTX226060.

Wenn ein Image in Citrix Provisioning veröffentlicht wird, wird das Image nach dem Namen der Imagevorlage mit einem Datums- und Zeitstempel für die Versionierung benannt. Virtuelle Festplatten werden in Provisioning Services genauso verwaltet, wie sie möglicherweise ohne App Layering verwaltet werden. Versionierung wird nicht verwendet, wenn App Layering verwendet wird. Stattdessen wird jedes Mal, wenn ein neues Image veröffentlicht wird, einen vollständigen virtuellen Datenträger mit einem neuen Datums- und Zeitstempel erstellt. Wenn eine Notfalländerung am Image erforderlich ist, kann die Citrix Provisioning-Versionierung verwendet werden, um das Image schnell zu ändern. Dann kann dieselbe Änderung zum entsprechenden Layer hinzugefügt werden, nachdem das Problem schnell behoben wurde.

Auswirkungen von Elastic Layering auf die Citrix Provisioning-Cachedatenträger

Citrix Provisioning verwendet reservierten Speicher und einen lokal angeschlossenen Cachedatenträger, um lokale Dateisystemänderungen während einer Sitzung vorübergehend zu speichern. Bei der Verwendung von App Layering und Citrix Provisioning muss die Größe des Cachedatenträgers größer sein als ohne App Layering. Bei jedem Öffnen einer Datei wird für den Schreibvorgang mit App Layering die gesamte Datei in das beschreibbare Volume der virtuellen Maschine kopiert, damit sie bearbeitet werden kann. Bewirkt, dass die gesamte Datei ebenfalls in den Festplattencache kopiert wird, obwohl Citrix Provisioning normalerweise nur die geänderten Blöcke in den Cache kopiert.

AL-Image-11

Das obige Diagramm zeigt Schreibvorgänge auf dem Cachedatenträger mit und ohne den App Layering Filtertreiber, der in den Provisioning-Server-Zielen installiert ist. Weitere Informationen zum Caching mit Elastic Layers finden Sie im Artikel CTX227454.

Benutzerlayer und Citrix Provisioning Cachedatenträger

Wenn Benutzerlayer verwendet werden, wird nur der Provisioning-Cachedatenträger verwendet, bevor sich ein Benutzer anmeldet.

AL-Image-12

In diesem Fall wird der lokale beschreibbare Partitionsdatenträger nur während des Boots verwendet. Sobald sich ein Benutzer angemeldet hat, werden alle neuen Dateiänderungen auf den Benutzerlayerdatenträger auf der Dateifreigabe und nicht auf das gestreamte virtuelle Laufwerk umgeleitet, was bedeutet, dass der Provisioningcache keine E/A mehr auf der beschreibbaren Partition sieht.

Citrix App Layering und Maschinenerstellung Services

Zum Veröffentlichen von Layerimages mit Maschinenerstellungsdiensten wird ein Maschinenerstellungsdienstconnector für den Hypervisor erstellt, auf dem veröffentlicht wird. Die Connectorkonfiguration umfasst neben Hosts, Speicherorten, Vorlagen usw. auch die Anmeldeinformationen des Dienstkontos, die für den Zugriff auf den Hypervisor verwendet werden.

Der Connector wird dann verwendet, um ein Layerimage als “Master Image” der virtuellen Maschine auf dem Hypervisor zu veröffentlichen.

AL-Image-13

Der MCS-Connector startet das Masterimage nach der Veröffentlichung und führt alle Layerskripts aus, die in beliebigen Layern definiert wurden. Nachdem alle Skripts ausgeführt wurden, muss das Masterimage heruntergefahren werden und der Hypervisor erstellt einen Snapshot der virtuellen Maschine. Sobald dieser Prozess abgeschlossen ist, kann das Masterimage mit den Maschinenerstellungsdiensten bereitgestellt werden. Die Benennung der virtuellen Maschine ähnelt der von Citrix Provisioning. Die virtuelle Maschine wird als Name der veröffentlichten Imagevorlage benannt, gefolgt von einem Datums- und Zeitstempel. Wenn eine neue Version des Images veröffentlicht wird, handelt es sich um eine neue virtuelle Maschine. Die neue virtuelle Maschine wird dann verwendet, um den vorhandenen Katalog zu aktualisieren, um Änderungen bereitzustellen. Bei der Verwendung von MCS ist es wichtig, dass die Vorlage, die zum Erstellen der Master Images verwendet wird, aus einer realen virtuellen Maschine erstellt worden sein muss. Der Computer wurde in Windows gestartet und die richtige Zeitzone eingestellt. Diese Aufgabe stellt sicher, dass das virtuelle BIOS ordnungsgemäß konfiguriert ist. Wenn diese Aufgabe nicht ausgeführt wird, hat das resultierende gestartete Image seine Auszeit um einige Stunden basierend auf UTC. Die beste Methode zum Erstellen der Vorlage besteht darin, einen Klon des ursprünglichen Gold-Images zu verwenden, das zum Erstellen des OS-Layer verwendet wurde. Dieser Schritt stellt sicher, dass die Einstellungen der virtuellen Hardware von der OS-Layer bis zum Masterimage übereinstimmen.

Plattformübergreifende Unterstützung von Citrix App Layering

Die Citrix App Layering-Architektur wurde entwickelt, um viele Hypervisors und Provisioningsysteme zu unterstützen, ohne dass plattformspezifische Layer erstellt werden müssen. Da viele Unternehmen sich in Multi-Cloud- oder Hybrid-Cloud-Umgebungen bewegen, erleichtert Citrix App Layering diese Migration.

AL-Image-14

App Layering unterstützt mehrere Plattformen auf mehreren Hypervisoren mit der Kombination von Connectors und Plattformlayern.

App Layering Connector — Die App Layering Connectors werden in node.js entwickelt und von der App Layering-Appliance aus ausgeführt. Die Connectors ermöglichen die Integration in alle unterstützten Plattformen, einschließlich Hypervisors und Provisioningsystemen.

Plattformlayer — Diese Layer ähnelt einer Anwendungslayer, mit der Ausnahme, dass sie immer die höchste Priorität hat und bei der Veröffentlichung von Images Cleanup “Rezepte” für Plattformlayer unterschiedlich ausgeführt werden als App-Layer. Plattformlayer sind der Ort, an dem Softwaretreiber für eine definierte “Plattform” installiert werden. Wenn Sie beispielsweise Citrix Provisioning verwenden, werden sowohl die VDA-Software als auch die PVS-Software in der Platform Layer installiert.

App Layering Connectors und Plattformlayer werden kombiniert, um verfügbare Plattformen zu unterstützen. Weitere Informationen zu den verschiedenen Hypervisoren und Details und Konfigurationen der Cloud-Plattformbereitstellung finden Sie in der Produktdokumentation.

Kommunikationsfluss für App Layering

App Layering verwendet nur wenige Verbindungen und Ports. Diese Kommunikationsflüsse werden nachfolgend dokumentiert. Weitere Informationen zu den Mitteilungen und Anforderungen finden Sie in der Produktdokumentation .

App Layering-Appliance

Die App Layering Management Console ist eine Microsoft Silverlight-basierte Konsole, auf die über TCP/IP auf Port 80 (HTTP) oder 443 (HTTPS) zugegriffen wird.

Zugriff auf Management-Appliance

Protokoll Port
HTTP 80
HTTPS 443
SSH 22
Log-Download 8888

Zusätzlich zu HTTP und HTTPS können die Administratoren direkt über SSH auf Port 22 auf die virtuelle Maschine der App Layering-Appliance zugreifen. Der Zugriff auf ungesicherte Telnet- oder FTP-Ports ist nicht gestattet. SSH wird verwendet, um sich bei der Appliance als “root” für vollen Zugriff anzumelden, und ein “Administrator” -Konto wird verwendet, um auf ein eingeschränktes Menü zur Konfiguration der Netzwerkeinstellungen zuzugreifen. In Azure sind “root” und “administrator” beide deaktiviert. Stattdessen werden die Administratoren während der Appliance-Bereitstellung nach einem lokalen Administratorbenutzerkonto gefragt.

Beim Exportieren von Protokollen aus der Managementkonsole wird ein Download-Link generiert und in den Aufgabendetails angezeigt. Port 8888 wird zum Herunterladen von Protokollen verwendet.

Port 8161 wird für die Verwaltung und Konfiguration von ActiveMQ verwendet, der Zugriff auf diesen Port ist jedoch nur innerhalb der App Layering-Appliance möglich.

Optional kann die App Layering-Appliance nach Upgrades suchen und diese mithilfe von HTTPS/443 oder HTTP/80 von Citrix-Servern über das Internet herunterladen. Auf www.citrix.com und cdn.citrix.com wird zugegriffen, sofern eine Internetverbindung verfügbar ist.

Connectorkonfiguration

Jeder Connectortyp verwendet einen anderen Port. Die aktuelle Liste der Connectors ist:

Connector HTTP-Port HTTPS-Port Interne Ports
Azure 3000 3500 3001/3501
Citrix Hypervisor 3002 3502 3003/3501
vSphere 3004 3504 3005/3505
Nutanix 3006 3506 3007/3507
Citrix Provisioning 3009 3509 3010/3510
Hyper-V 3012 3512 3011/3511

Connectors werden als separate Webseite in der Management Console geöffnet. Jeder Connector verfügt sowohl über einen HTTP- als auch einen HTTPS-Listening Wenn ein Connector geöffnet wird, wird der Administrator auf eine HTML5-basierte Schnittstelle in einer neuen Registerkarte umgeleitet. Der Browser des Administrators muss auf die App Layering-Appliance auf den oben aufgeführten Ports für jeden Connector zugreifen können.

Diverse Ports

Die App Layering-Appliance kommuniziert mit verschiedenen Netzwerkservern und Diensten an ihren jeweiligen Ports. Die App Layering-Appliance stellt eine Verbindung zu den folgenden Diensten auf den folgenden TCP-Ports her:

Ziel Protokoll Port
Active Directory-Server LDAPS (LDAP über SSL) 636
Active Directory-Server LDAP 389
Active Directory-Server DNS 53
Windows-Dateiserver SMB 445
Netzwerk-Zeitserver NTP 123
DHCP-Server DHCP UDP/67
App Layering-Appliance DHCP UDP/68

Der Agentenservice

Der Agent-Dienst kann für drei separate Funktionen verwendet werden:

  • Integration mit Citrix Provisioning
  • Integration mit Hyper-V
  • Integration mit einem allgemeinen Skriptserver

Auf den Agent-Dienst wird über die folgenden Ports zugegriffen.

Agentenserver Ziel Funktion oder Protokoll Port
Alle App Layering-Appliance Registrierung oder HTTPS 443
Alle Agentenserver Befehle von App Layering-Appliance oder SOAP 8016
Alle App Layering-Appliance Log-Export 8787
Citrix Provisioning App Layering-Appliance Datenträgerupload oder HTTP 3009
Citrix Provisioning App Layering-Appliance Datenträgerupload oder HTTPS 3509

Bei der Erstinstallation des App Layering Agents öffnet das Installationsprogramm eine Verbindung an Port 443 zur App Layering-Appliance, um den Agentserver zu registrieren. Die App Layering-Appliance speichert den FQDN und den Kurznamen für den Agentdiensthost, und die Registrierung auf dem Agentserver enthält einen Datensatz der App Layering-Appliance.

Nachdem der Agent und die App Layering-Appliance Identitäten ausgetauscht haben, kommuniziert die App Layering-Appliance direkt mit dem Agent-Dienst auf einem sicheren SOAP-Kanal an Port 8016. Die meiste Kommunikation zwischen der Appliance und dem Agenten funktioniert wie folgt:

Host Aktion
App Layering-Appliance Hallo an Agent auf Port 8016
App Layering-Appliance Befehlsanforderung an Agent geöffnet
Agent Führt einen PowerShell-Befehl als konfiguriertes Benutzerkonto aus
Agent Überträgt Antwort an App Layering-Appliance auf einem vorhandenen Anforderungskanal
Agent Goodbye

Die Einzelheiten des tatsächlich gesendeten Befehls können häufig im Connector-Protokoll auf der App Layering-Appliance oder in der Datei applayering.agent.log auf dem Agent-Service-Server angezeigt werden.

Wenn die Appliance aufgefordert wird, ein Protokollpaket zu generieren, sendet sie eine Anforderung an jeden Agent-Dienst, der jemals auf der Appliance registriert wurde, und fordert Protokolle vom Agenten an. Jeder Agentendienst generiert sein eigenes Protokollpaket und überträgt es an Port 8787 zurück an die App Layering-Appliance.

Die Hauptfunktion des Agent-Dienstes besteht darin, Dateien an Citrix Provisioning oder Hyper-V zu übertragen. Beim Übertragen von Dateien verwendet der Agent den Windows-Hintergrundübertragungsdienst (Intelligent Transfer Service, BITS) auf dem Agentendienstserver, um die virtuelle Festplatte auf den Server zu ziehen und sie in den Store zu platzieren oder einen virtuellen Datenträger von Hyper-V hochzuladen oder herunterzuladen.

Das Übertragen einer Datei funktioniert wie folgt:

Host Aktion
App Layering-Appliance Hallo an Agent auf Port 8016
App Layering-Appliance Befehlsanforderung für Datei-Upload
Agent Führt BITS als konfiguriertes Benutzerkonto aus
BITS Öffnet eine Verbindung zum Citrix Provisioning Connector auf Port 3009 der App Layering-Appliance
BITS Lädt die Datei zum angegebenen Repository-Speicherort
App Layering-Appliance Befehl zum Abrufen des Übertragungsstatus
Agent Ruft BITS auf Status ab und meldet sich zurück an die App Layering-Appliance
BITS Ausführungen
Agent Meldet den vollständigen Status an die App Layering-Appliance

Normalerweise läuft die Dateiübertragung auf Port 3009, der unverschlüsselt ist. Diese Kommunikation erfolgt aus Leistungsgründen — der Aufwand beim Betrieb über eine HTTPS-Verbindung wirkt sich erheblich auf den Durchsatz aus. Der Agent kann jedoch so konfiguriert werden, dass er HTTPS erzwingt und stattdessen 3509 verwendet.

Wenn der Agent BITS ausführt, bietet er BITS zwei Dinge: die URL für den Dateidownload und den Zieldateipfad. BITS wird als das Benutzerkonto ausgeführt, das im Connector konfiguriert ist. Daher benötigt dieser Benutzer Berechtigungen, um eine ausgehende Verbindung vom Provisioning-Server zu Port 3009 der App Layering-Appliance herzustellen, und auch Rechte zum Schreiben einer Datei in den virtuellen Datenträgerspeicher.

Hypervisors

Hypervisor Connectors verwenden die folgenden Ports.

Connector Ziel Port
Azure und Hyper-V Azure-Verwaltung 443
Citrix Hypervisor Citrix Hypervisor 5900
vSphere Virtuelles Zentrum 443
vSphere ESX-Hosts für Datenträgerübertragungen 443
Nutanix Nutanix CVM 9440

Bei diesen Ports handelt es sich um dieselben Ports, die auch die browserbasierten Hypervisor-Managementkonsolen verwenden. App Layering verwendet klar definierte API-Aufrufe über den normalen Webservice des Hypervisors für die Kommunikation mit dem Hypervisor.

Bei vSphere werden Datei-Uploads und Downloads nicht durch die Kommunikation mit vCenter durchgeführt. Und wird durch direkte Kommunikation mit einem ESXi-Host abgewickelt. Aus diesem Grund müssen für die vSphere Connectors ein Host definiert werden, und die Host-Firewall muss so konfiguriert sein, dass der Zugriff von der App Layering-Appliance auf Port 443 zulässig ist.

Compositing Engines

Compositing Engines stellen eine Verbindung zur App Layering-Appliance für iSCSI-Verbindungen auf Port 3260 her und führen API-Aufrufe an die Appliance an Port 443 durch. Die App Layering-Appliance führt API-Aufrufe an die Compositing Engines auch an Port 443 durch.

Verfügbarkeit, Backup und Wiederherstellung

App Layering kann aus mehreren Komponenten bestehen, für die Backups geeignet sind, darunter die Appliance, Elastic Layer-Freigaben und Benutzerlayer-Freigaben.

Hinweis:

Während in diesem Abschnitt die Verfügbarkeit von Verbindungsbrokern beschrieben wird, wird die Wiederherstellung und Verfügbarkeit Ihrer VDI-Broker-Infrastruktur hier nicht behandelt. Weitere Informationen zu den Wiederherstellungsoptionen finden Sie in der Dokumentation und im Support-Team für Ihre Desktop Connection Broker-Software.

Jede Verfügbarkeitsstrategie für App Layering muss in das Gesamtverfügbarkeits- und Wiederherstellungsdesign für Ihre gesamte Workspace-Lösung passen. Pools und Bereitstellungsgruppen sind bereits hochverfügbar, da sie auf Hosts und Speicherpools verteilt sind.

Speicher kann auf verschiedene Arten hochverfügbar gemacht werden. Eine gängige Methode ist die Verwendung eines Storage-Arrays mit einem hohen Redundanzgrad, einschließlich mehrerer Speicherprozessoren oder -köpfe und RAID-Technologie. Es ist jedoch auch möglich, eine höhere Verfügbarkeit zu erzielen, indem Sie lokalen Speicher verwenden, der auf einem lokalen RAID-Controller und Flask-Disks auf jedem Host basiert, und verwaltete Maschinen auf mehrere Hosts verteilen. Wenn ein Host aus irgendeinem Grund ausfällt, werden andere Hosts mit verwalteten Maschinen aus dem Pool verfügbarer Desktops ausgeführt, um die Benutzersitzungen aufzunehmen.

Netzwerke können auch leicht verfügbar gemacht werden, da Hypervisoren unter Berücksichtigung der Verfügbarkeit entwickelt wurden. Es ist jedoch wichtig sicherzustellen, dass für jeden verwalteten Computer in Ihrer Umgebung mindestens zwei Netzwerkpfade verfügbar sind.

Die spezifischen Komponenten für App Layering sind die Appliance, Elastic Layers und Benutzerlayers.

Appliance-Backups

Wie bereits erwähnt, ist die App Layering-Appliance nicht erforderlich, damit Endbenutzer App Layering in vollem Umfang nutzen können. Daher ist es nicht erforderlich, die Appliance hochverfügbar zu machen. Es muss jedoch als Voraussetzung angesehen werden, das Gerät regelmäßig zu sichern. Appliance-Backups stellen sicher, dass alle Layer verfügbar sind, auch wenn die Appliance irgendwie zerstört oder beschädigt ist. Jede Backup-Technologie für virtuelle Maschinen kann für die App Layering-Appliance verwendet werden. Es ist auch möglich, zwei Appliances und die Import- und Exportfunktion zu verwenden, um sie synchron zu halten. Dieser Schritt ist jetzt jedoch ein manueller Vorgang.

Verfügbarkeit und Disaster Recovery für Elastic Layers

Elastic Layers sind Dateien, die während der Anmeldung mit einem integrierten Windows-Mount von einer SMB-Freigabe auf Virtual Desktops Agents (VDAs) bereitgestellt werden. Der Layering-Dienst verbindet die Layer bei der Anmeldung, verbindet jedoch nie wieder eine getrennte VHD-Datei. Daher ist es wichtig sicherzustellen, dass der für Elastic Layers verwendete Dateiserver durch die Verwendung eines Clusterdateisystems hochverfügbar ist. Die Verwendung mehrerer DFS-R-Ziele ist für diesen Anwendungsfall nicht ausreichend, da bei einem Ausfall eines Ziels die bereitgestellten VHD-Dateien erst dann einem anderen Ziel zugeordnet werden können, wenn eine erneute Anmeldung erfolgt.

Bei Disaster Recovery gibt es zwei Modelle, die für die Verarbeitung von Elastic Layers verwendet werden können: ein Replikationsmodell oder ein Dual-Appliance-Modell.

Replikationsmodell

In diesem Modell können Elastic Layer-Freigaben mithilfe einer beliebigen Dateisystemreplikationstechnologie repliziert werden. Dieses Modell kann Technologien wie DFS-R, Microsoft Storage Replica, Veeam, NAS-Herstellerreplikation, Zerto, VMware vSphere Replication und sogar Robocopy enthalten.

AL-Image-15

Anschließend können die VDAs im DR-Rechenzentrum über das Gruppenrichtlinienobjekt auf die Elastic Layer-Freigabe in diesem Rechenzentrum verwiesen werden. Eine GPO-Vorlage zum Konfigurieren des Repository-Speicherorts finden Sie hier: CTX222107.

Dual-Appliance-Modell

Bei diesem Modell ist in jedem Rechenzentrum eine Appliance installiert. Die von der Appliance bereitgestellte Import- und Exportfunktion wird verwendet, um die beiden Appliances aus Layerperspektive synchron zu halten. Hier verwalten die Administratoren DR-Layer getrennt und erstellen Images in der Notfall-Wiederherstellung von einer lokalen Appliance.

AL-Image-16

Wenn diese Option ausgewählt ist, wird die Synchronisierung über das WAN von der SMB-Freigabe übertragen, die während des Import- und Exportvorgangs definiert wurde. Dann müssen Layer auf der DR-Appliance zugewiesen werden, kopiert sie in die Elastic Layer-Freigabe in DR. In diesem Modell ist es auch möglich, eine Lösung zu entwickeln, die nicht alle Layer, sondern nur gewünschte Layer synchronisiert. Da Layer manuell für den Export ausgewählt werden, können nur ausgewählte Layer in den Prozess einbezogen werden. Derzeit muss der Import- und Exportvorgang manuell gestartet werden.

Im Dual-Appliance-Modell müssen auf jeder Seite Connectors und Berechtigungen für elastische Freigaben erstellt werden. Die einzigen Objekte, die importiert werden, sind die tatsächlichen Layer selbst. In diesem Modell ist es jedoch möglich, je nach Bedarf unterschiedliche Layer an jedem Standort zu haben. Zum Beispiel, wenn es sich wirklich um ein aktiv-aktives Site-Szenario handelt.

Verfügbarkeit und Disaster Recovery für Benutzerlayer

Benutzerlayer ähneln Elastic Layers insofern, als es sich um VHD-Dateien handelt, die von Windows bei der Anmeldung mithilfe eines In-Guest-Mounts bereitgestellt werden. Sie sind jedoch beschreibbar eingehängt, und die Dateien werden vom Windows-Desktop gesperrt. Diese Aufgabe macht die Optionen zum Backup und Replizieren dieser Datenträger viel schwieriger als normale Elastic Layer.

Aufgrund dieser Einschränkung muss bei Verwendung von DFS-R oder einem Robocopy-Skript der Synchronisierungsprozess außerhalb der Geschäftszeiten durchgeführt werden (wenn Zeiten außerhalb der Geschäftszeiten gelten). Der Prozess muss ständig überprüfen, ob die Dateien für die Synchronisierung verfügbar sind. Bei Benutzerebenen, bei denen es sich um große Dateien handeln kann, funktioniert Robocopy möglicherweise nicht gut, da es möglicherweise immer die gesamte Datei kopiert und nicht die Blöcke, die sich geändert haben. DFS-R ist möglicherweise die bessere Wahl, da es nur modifizierte Blöcke kopiert. Die Replikation auf Speicherebene ist jedoch möglicherweise noch besser, da sie bei Änderungen möglicherweise gleichmäßiger synchronisiert wird, anstatt darauf zu warten, dass die Dateisperren entfernt werden.

Es gibt auch andere Optionen, die hier unterstützt werden, abhängig von der Technologie, die zum Speichern der Benutzerlayer-VHD-Dateien ausgewählt wurde. Wenn der Dateiserver den Volume Shadow Copy Service (VSS) unterstützt, werden VSS-Snapshots erstellt, um die Backup und Replikation der Benutzerlayer zu ermöglichen. Durch Variation der Prozesshäufigkeit können Benutzerlayers dann auch auf frühere Zeitpunkte zurückgesetzt werden, wenn eine Beschädigung oder ein Fehler gemacht wird, der sich nachteilig auf den Benutzer auswirkt.

Wenn ein Speichercontroller NDMP unterstützt, kann diese Funktion auch für Benutzerlayerbackups verwendet werden. NDMP arbeitet auf Speicherebene, um NAS-Speicher mithilfe von NAS-Snapshots direkt auf Datenträger oder Band zu sichern.

Aufgrund der Schwierigkeiten bei der Replikation großer Datenträger und der Kosten für die dafür erforderliche Bandbreite entscheiden sich viele Kunden dafür, DR-Desktops für Benutzer ohne replizierte Benutzerlayer bereitzustellen. In diesem Modell gibt es zwei Optionen. Benutzern kann eine separate Bereitstellungsgruppe am DR-Standort bereitgestellt werden, die ebenfalls für den Benutzerlayer aktiviert ist. Sie können sich dann am DR-Standort anmelden und diesen Layer mit dem, was sie benötigen, vorkonfigurieren. Oder Benutzer können mit einem normalen, nicht persistenten DR-Desktop bereitgestellt werden. Im letzteren Fall ist es häufig vorteilhaft, Citrix Profile Management mit der Benutzerlayer zu mischen, damit Benutzereinstellungen auf die DR-Site repliziert werden können.

Komponenten-Disaster Recovery an mehreren Standorten

Der Ansatz für die Notfallwiederherstellung an mehreren Standorten ähnelt der lokalen Wiederherstellung. Für Images müssen Sie einen Replikationsprozess verwenden. Wenn Sie Citrix Provisioning verwenden, können Sie Robocopy verwenden, um Ihre vDisks auf den sekundären Standort zu kopieren. Wenn Sie Maschinenerstellungsdienste oder Horizon View auf vSphere verwenden, benötigen Sie einen Prozess, um virtuelle Maschinen wie Veeam, Zerto, VMware vSphere Replication oder Site Recovery Manager zu replizieren. Dies dient auch dem Schutz der ELM.

Bei Elastic Layers funktionieren sowohl die SAN-Replikation als auch eine skriptbasierte Kopie. Wenn Sie Benutzerlayers verwenden, müssen Sie auf SAN/NAS-Ebene replizieren, damit geänderte Blöcke unter dem für die Freigabe verwendeten Cluster-Dateisystem repliziert werden können.

Dieser Ansatz ist besser, als mehrere Connectors im ELM zu definieren und direkt auf beiden Websites zu veröffentlichen, da Sie beim Veröffentlichen das Image sowohl zusammenstellen als auch in den Store hochladen müssen. Wenn Sie einen Prozess verwenden, der das bereits erstellte Image repliziert, überspringt dies den Kompositionsprozess und ist effizienter.

Hinweis:

Wenn Sie eine andere Konfiguration für die Images wünschen, die für die Notfallwiederherstellung bereitgestellt werden, ist es besser, sie direkt aus dem ELM zu veröffentlichen. Auf diese Weise können Sie verschiedene Layer in den Imagevorlagen für die Wiederherstellung definieren.

Es ist auch möglich, zwei ELM-Appliances zu verwenden, eine an jedem Standort. Anschließend können Sie die Export-/Importfunktion verwenden, um diese ELMs aus Layerperspektive synchron zu halten. Sie können die Wiederherstellung dann separat behandeln und dort Images von einem lokalen ELM erstellen.

AL-Image-17

Wenn Sie diese Option wählen, wird die Synchronisierung über das WAN an die in den Einstellungen definierte SMB-Freigabe übertragen. Die Layer können dann mit der am zweiten Standort verwendeten SMB-Freigabe synchronisiert werden, indem Robocopy mit dem Schalter /MIR verwendet wird. Derzeit muss der Import- und Exportvorgang manuell initiiert werden.

Sie können auch nur die gewünschten Layer und nicht alle Layer synchronisieren. Wenn Ihnen diese Option gefallen könnte, wenden Sie sich an Ihren App Layering-Lösungsarchitekten, um weitere Informationen zu erhalten.

Im Dual-ELM-Modell müssen Connectors und Berechtigungen für Elastic Shares auf jeder Seite erstellt werden. Die einzigen Objekte, die importiert werden, sind die tatsächlichen Layer. In diesem Modell ist es jedoch möglich, je nach Bedarf unterschiedliche Layer an jedem Standort zu haben.

Quellen

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

Referenzen

Die folgenden Ressourcen werden zum besseren Verständnis von Citrix App Layering referenziert:

App Layering-Produktdokumentation

Erstellen eines Plattformlayers

Elastisches Layering verstehen

Optimierungen für Windows- und App Layering

Anti-Virus-Handbuch für App Layering

Das Office-Rezept verstehen

Best Practices für App Layering

Referenzarchitektur: App Layering

In diesem Artikel