Citrix App Layering

Zielgruppe

Dieses Dokument richtet sich an technische Fachleute, IT-Entscheidungsträger, Partner und Systemintegratoren. Auf diese Weise kann der Administrator Citrix App Layering erkunden und anwenden, um die Bereitstellung von Images und Anwendungen an die Endbenutzer zu erleichtern. Der Leser muss grundlegende Kenntnisse über Citrix Produkte, Image-Management-Services und Anwendungsvirtualisierungskonzepte haben. Weitere Informationen zur Imageverwaltung finden Sie in der Referenzarchitektur auf CitrixTech Zone.

Ziel dieses Dokuments

Dieses Dokument bietet einen technischen Überblick, Architekturkonzepte für die Verwaltung und Bereitstellung von Anwendungen mit Citrix App Layering Technologien. Dieses Dokument enthält sowohl die Funktionsweise von App Layering als auch die Integration mit Citrix Virtual Apps and Desktops auf verschiedenen Plattformen.

Citrix App Layering — Übersicht

Citrix App Layering ist eine flexible Lösung, um einen komplexen Satz von Windows-Anwendungen für eine Vielzahl von Benutzern auf jeder nicht persistenten unterstützten Plattform bereitzustellen.

Citrix App Layering führt das Image-Management 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 Bereitstellungssystem 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. Damit kann der Administrator Unternehmensanwendungen unabhängig von den zugrunde liegenden Hypervisoren oder der Cloud-Infrastruktur erstellen und verwalten.

Betriebssystem und Anwendungen sind in diskrete verwaltbare Einheiten unterteilt. Selbst wenn viele Images zur ordnungsgemäßen Steuerung des Anwendungszugriffs erforderlich sind, 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 virtuelles Laufwerk gespeichert, das Dateien und Registrierungseinträge für einen bestimmter Layer enthält. Es gibt zwei Möglichkeiten, Anwendungen in virtuelle Maschinen einzuschließen:

  • Veröffentlichtes Image: Bei dieser Methode werden der Betriebssystemlayer, ein Plattformlayer und eine Reihe von Anwendungslayer kombiniert, um ein Image für Bereitstellungssysteme 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 Imageverwaltung 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 für standardisierte Images.

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

Warum Citrix App Layering

Citrix App Layering bietet eine kostengünstige Lösung zur Verwaltung komplexer Anwendungen in mehreren Umgebungen mit unterschiedlichen Paketanforderungen. Fast alle Anwendungen, die mit Kerneltreibern, Betriebssystem- und Systemdienstabhängigkeiten eingebettet sind, sind mit der App Layering Technologie kompatibel.

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

  • Vereinfachtes Masterimage-Management für PVS und MCS: Citrix App Layering ist eine einzige Image-Management-Lösung, die Provisioningmodelle unterstützt, die mit Hypervisoren von Citrix und Drittanbietern verwendet werden. Mit App Layering wird sowohl die Verwaltung als auch Upgrades für Images vereinfacht, ohne direkte Bearbeitung oder Reverse Imaging von Images.

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

  • Entkoppeln Sie die Apps und Provisioningsysteme vom Image: Citrix App Layering trennt die Verpackung vom Image. In der normalen Imageverwaltung werden Aktualisierungen für ein Image für jedes Image separat durchgeführt. Mit App Layering kann ein Layer Teil vieler Images sein. Um alle Images zu aktualisieren, wird der Layer einmal aktualisiert und die Images regeneriert. 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 App-Layer-Bereitstellung sind fast alle Anwendungen kompatibel.

  • Desktopbenutzerlayer ohne Persistenz: Der Benutzerlayer ist ein beschreibbarer Elastic Layer. Ein Benutzer meldet sich bei einem Desktop an. Die meisten Schreibvorgänge gehen in den Benutzerlayer. Es ermöglicht Benutzern, Anwendungen zu installieren und Konfigurationseinstellungen zu speichern, die außerhalb des Benutzerprofils liegen. Außerdem speichert werden die Datendateien des Benutzers gespeichert. Der Desktop scheint persistent zu sein, nutzt aber die Vorteile eines gemeinsam genutzten Desktopmodells.

  • Reduziert die Anzahl der erforderlichen Images: Elastic Layering kann die Anzahl der erforderlichen Images erheblich reduzieren, indem Anwendungen dynamisch nur für zugewiesene Benutzer bereitgestellt werden. Elastic Layer sind sowohl mit Citrix Virtual Apps als auch mit Citrix Virtual Desktops kompatibel.

Citrix App Layering Anwendungsfälle

App Layering ist eine wichtige Ergänzung des Citrix Technologieportfolios, die viele oben 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 zu zeigen.

1-Zu viele Images zu verwalten

Viele Citrix Kunden müssen eine beträchtliche 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 von Anwendungen mit Konflikten unterstützen. Oft gibt es einige Überschneidungen in den Anwendungen, die auch 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 mithilfe von Layern verwalten. Muss beispielsweise Windows gepatcht werden, wird der Patch einmal auf den Betriebssystemlayer angewendet und alle Images, die den Betriebssystemlayer verwenden, werden von der App Layering-Appliance aktualisiert. Wenn Microsoft Office in 10 Images verwendet wird, ist die Aktualisierung dieses Office einfacher, indem eine Version dem Office-Layer hinzugefügt wird. Schließlich werden alle diese 10 Images automatisch aktualisiert.

Wenn Elastic Layering hinzukommt, ist es auch möglich, die Anzahl der benötigten Images deutlich zu verringern. Mit Elastic Layer können Administratoren Anwendungen während der Anmeldung dynamisch bereitstellen. Für Anwendungen, die nicht von jedem Benutzer verwendet werden, ermöglichen Elastic Layer das Image genereller zu erstellen und gleichzeitig Anpassungen für jeden Benutzer bereitzustellen.

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

Viele Organisationen wechseln zu einer hybriden Multi-Cloud-Umgebung, die lokale und Cloud-Ressourcen miteinander verbindet, 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 würde eine gemischte Hypervisor und Hybrid-Cloud-Konfiguration die Administratoren dazu zwingen, mehrere verschiedene Sätze von Images und Anwendungen auf mehreren verschiedenen Verwaltungsplattformen zu verwalten. Mit der App Layering Technologie können die gleichen Betriebssysteme und Anwendungen, die lokal verwendet werden, ohne zusätzliche Arbeit in die Cloud oder auf einen anderen Hypervisor übertragen werden.

Informationen zu den plattformübergreifenden Funktionen 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 “stecken” fest, nur weil es unerschwinglich wäre, auf neue Technologien zu migrieren. Außerdem verschmelzen Unternehmen oft 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 freigegebene VDI-Desktops

Viele Organisationen verfügen über mehrere Benutzer, die eine hohe Persistenz auf Desktops erfordern. Einschließlich Poweruser in jeder Gruppe, Entwickler, Ingenieure, Architekten usw. App Layering-Benutzerlayer bieten zusätzlich zu einer gepoolten Desktoparchitektur einen erheblichen Anteil an Persistenz.

Der Benutzerlayer wird bei der Anmeldung eingehängt 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 die Funktionsweise im Benutzerlayer 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 User Layer möglicherweise nicht die beste Wahl. Der User Layer 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 handhaben den Outlook-OST und die Indizes viel gezielter, sodass die Menge der vom Container gehandhabten E/A viel 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.

Technische Übersicht über Citrix App Layering

Layertypen

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 des Betriebssystemlayers werden Layer von der App Layering Appliance erstellt, die mit dem Hypervisor integriert ist. Ein Administrator erstellt einen Layer, die Appliance stellt eine Verpackungsmaschine dynamisch mit einem Start- und einem Layerdatenträger bereit. Wenn die Verpackungsmaschine startet, werden alle Änderungen an der Verpackungsmaschine in 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 die folgenden Arten von Layern:

  • Betriebssystemlayer
  • Plattformlayer
  • Anwendungslayer
  • 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. Der Plattformlayer ist auch der Layer mit der höchsten Priorität und manchmal wird hier Software installiert, so dass sie mit höchster Priorität kompiliert wird.

App-Layer: Der Hauptlayertyp. Wird für die meisten Anwendungssoftware verwendet.

Benutzerlayer: Ein elastischer (siehe nächster Abschnitt) beschreibbarer Layer. Benutzlayer werden bei der Anmeldung gemountet und sobald dies abgeschlossen ist, gehen fast alle Schreibvorgänge des Desktops in den Benutzlayer. Dieser Layer bietet Benutzern die Möglichkeit, ihre VDI-Erfahrung erheblich anzupassen, obwohl sie ein freigegebenes Desktopmodell verwenden.

Citrix App Layering-Appliance

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

Die App Layering Appliance wird als virtuelle Maschine in das Rechenzentrum bereitgestellt, in dem Anwendungspakete und Image-Veröffentlichung stattfinden. Die App Layering Appliance basiert auf CentOS, konfiguriert mit 4 vCPUs und 8 GB RAM. Diese Einstellungen dürfen nicht geändert werden, da die Appliance in dieser Konfiguration funktioniert.

Die Appliance wird mit zwei Datenträgern erstellt. Der erste Datenträger ist ein 30-GB-Startdatenträ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 Erstellung von Layern und der Veröffentlichung von Images speichert die Citrix App Layering-Appliance virtuelle Datenträgerdateien im VHD-Format in ihrem Layerrepository innerhalb der Appliance. Die Appliance ist mit einer SMB-Freigabe verbunden, um den Appliance-Upgrade-Prozess zu unterstützen und Elastic Layer zu speichern.

Die Appliance wird nur zum Verwalten von Layern, Images und Elastic Layer-Zuweisungen verwendet. Virtual Desktops und virtuelle App-Server werden 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 die Layer-Zuweisungen für Benutzer 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 zum Installieren der Citrix App Layering Appliance finden Sie imProduktdokumentation.

AL-Image-6

Die Citrix App Layering-Verwaltungskonsole ist eine webbasierte Anwendung, die auf der App Layering-Appliance gehostet wird. Die App Layering-Verwaltungskonsole bietet die Oberfläche für:

  • Erstellen und Verwalten von Betriebssystem-, Plattform- und Anwendungslayer
  • Erstellen von veröffentlichten Imagevorlagen
  • Veröffentlichen und Verwalten von Layerimages
  • App Layering der Administratorrollen Benutzern zuweisen
  • Verwalten der Appliance- und Systemeinstellungen wie Task- 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 Verlagerung dieser Aufgaben skalieren die Verpackungs- und Publishing-Prozesse viel besser und aufgrund der Vorteile der verwendeten Technologien wird auch die Leistung des Prozesses erheblich gesteigert.

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
  • Selbst-Compositing
  • Kontrolliert über REST API
  • Unterstützte Hypervisor-Disk-Formate (VHD, VHDX und VMDK)
  • UEFI-Unterstützung (Gen2)
  • Sicheres Booten auf veröffentlichten Images (nur wenn keine Elastic Layering oder User Layers 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.

Layer-Bereitstellung

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 bei der Anmeldung Layer bereitgestellt werden und den Benutzern dynamisch zur Verfügung gestellt werden.

Veröffentlichtes Image: Hier werden Betriebssystem-, Plattform- und Anwendungs-Layer zu einer einzigen Datenträgerdatei zusammengefasst, die in einem Bereitstellungssystem wie Citrix Provisioning oder Maschinenerstellungsdienste veröffentlicht wird. Der Prozess beginnt mit dem Klonen des OS-Layers, dann in die Dateien von Anwendungslayern nacheinander in der Prioritätsreihenfolge, in der je neuer der Layer desto höher ist seine Priorität und zuletzt in den Plattformlayer geschrieben wird. Der Zusammenführungsprozess zum Erstellen von veröffentlichten Images ist fortgeschritten. Beim Erstellen eines Images werden die Dateisysteme, die Registrierung und die Umgebungsvariablen zusammengeführt, der Windows-Treiberspeicher neu erstellt und alle Treiber von Drittanbietern aus verschiedenen Layern zusammenführt.

Elastische Layer: Bei diesen Layern 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, sodass Administratoren die Benutzererfahrung anpassen und gleichzeitig die Anzahl der Images minimieren können.

Connector und Connector-Konfigurationen

Die App Layering Appliance lässt sich mit Hypervisoren und Provisioningsystemen über Connectors 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.

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

Eine einzelne Appliance kann eine Verbindung zu einer beliebigen Anzahl von Hypervisoren oder Provisioningsystemen herstellen, indem mehr Connectors definiert werden. Connector-Konfigurationen definieren die Einstellungen, die für die Integration in den Hypervisor oder das Provisioning -System 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. Connectors werden verwendet für:

  • Importieren eines Gold-Images beim Erstellen eines Betriebssystemlayers
  • Erstellen von Layern und Layerversionen
  • Veröffentlichen Sie Layerimages in 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

Connector-Typen

In diesem Abschnitt werden die Connectortypen definiert, die in Citrix App Layering verfügbar sind.

Hypervisor-Connectors

Hypervisor-Connectors werden beim Erstellen von Layern oder beim Importieren eines Gold-Images zum Erstellen des Betriebssystem-Layers 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 mit einem App Layering Agent auf einem Citrix Provisioning -Server integrieren, um ein Image direkt auf dem Provisioning-Server als virtuelles Laufwerk zu veröffentlichen. Die Voraussetzungen für die Citrix Provisioning sind:

  1. Das Connectordienstkonto muss ein Domänenkonto mit der Administratorberechtigung in PVS sein.
  2. Das Connectordienstkonto muss auch ein lokaler Administrator auf dem Citrix Provisioning -Server sein.
  3. Auf jedem Citrix Provisioning-Server, der in einem Connector definiert ist, 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 Layering-Images direkt als virtuelle Maschinen bereitstellen und veröffentlichen, die als Masterimage für MCS verwendet werden. Mit Connectors können Images mit mehreren Layern direkt auf dem Hypervisor veröffentlicht werden. 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 Herunterfahren des Masterimages und ein VM-Snapshot, der im Rahmen dieses Prozesses erstellt wurde.

Connectorskripte

Dieser Schritt ist eine optionale und erweiterte Funktion, die beim Erstellen einer Connectorkonfiguration verfügbar ist. Um dieses Feature zu verwenden, konfigurieren Sie ein optionales PowerShell -Skript, das auf dem definierten Agent-Server 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 Skripte auf den Computer, auf dem der Agent installiert ist. Dieses Skript wird nach einer erfolgreichen Bereitstellung eines Layered Image ausgeführt. Um diese Funktionalität nutzen zu können, muss das Skript bei einem Masterimage auf einem Hypervisor auch mit der Verwaltungsplattform des Hypervisors interagieren. Beispiel: Für vSphere müsste das Skript PowerCLI gegen vCenter verwenden, um Code auf der virtuellen Masterimagemaschine 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 Beispielskripten finden Sie in den folgenden Supportartikeln 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 für das Zielprovisioningsystem erforderlichen Format erstellt. 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 legt fest, welche Betriebssystem-, Plattform- und Anwendungslayer im Image enthalten sind. Es definiert auch den Connector, der zum Veröffentlichen des Images verwendet wird, wie groß das resultierende Image in GB ist, ob Elastic Layering für das Image aktiviert ist oder einen der verschiedenen Typen von Benutzerlayer. Die Imagevorlagen sind ein Point-in-Time-Snapshot der Imagekonfiguration, sie unterstützen keine Versionierung. Imagevorlagen können jedoch geklont und geändert werden, wenn geringfügig unterschiedliche Versionen desselben Images erforderlich sind.

App Layering Agent

Der Citrix App Layering Agent stellt die Kommunikation zwischen der App Layering Appliance und 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 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 mit 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 sowohl Authentifizierungen für die Appliance als auch die Zuweisung von Elastic Layern zu erhalten. Wenn sich ein Administrator bei der Appliance anmeldet, versucht er, sich mit denselben Anmeldeinformationen bei Active Directory anzumelden. Wenn diese Anmeldung funktioniert, ist der Benutzer in die Appliance zugelassen.

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

  • Rollenbasierte Zugriffssteuerung (RBAC)
  • Zuordnung von Elastic und User Layer

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 eines Verzeichnisknotens finden Sie unterProduktdokumentation.

Layer

Im folgenden Abschnitt werden die Verwendungszwecke für jeden Layertyp genauer beschrieben.

OS-Layer

Ein Betriebssystemlayer enthält das Windows-Betriebssystem. Es ist eine führende Praxis, alle Komponenten, die mit Windows Update aktualisiert werden würden, in dem Betriebssystemlayer aufzunehmen, damit alle von Windows Update aktualisiert werden. Alle Betriebssystemrollen und -komponenten wie .NET und Visual C++-Laufzeitbibliotheken sind aus diesem Grund als Teil des Betriebssystemimages enthalten.

Es ist vorzuziehen, keine Endbenutzeranwendungen auf dem Betriebssystemlayer zu installieren, da alle mit einer bestimmten Betriebssystemschicht erstellten Anwendungsebenen an diesen Betriebssystemlayer gebunden sind. Wenn eine Anwendung auf dem Betriebssystemlayer installiert ist, führt jedes Image, das diesen Layer verwendet, um diese Anwendung einzuschließen, zu einem Problem, wenn die Strategie darin besteht, den Betriebssystemlayer universell zu machen. Die Trennung der Anwendungen vom Betriebssystem ist der Schlüssel zur Begrenzung der Anzahl der zu verwaltenden Betriebssystemimages. Sogar Anwendungen mit Treibern, Diensten und Kernelgeräten werden in Anwendungslayern unterstützt und müssen nicht in den Betriebssystemlayer aufgenommen werden.

Während der Erstellung des OS-Layers gibt es ein paar Punkte zu beachten:

  • Überprüfen Sie die unterstützten Betriebssysteme über den Link
  • Der Betriebssystemlayer ist nicht mit der Domäne verbunden. Der Domänenbeitritt ist Teil des Plattformlayers
  • Die Hypervisor-Tools für den primären Hypervisor sind auf dem Betriebssystemlayer installiert. Der Hypervisor, bei dem die meisten Verpackungen durchgeführt werden
  • Die Hypervisor-Tools für alternative Hypervisoren werden im Plattformlayer für diesen Hypervisor installiert.
  • Installieren von .NET-Komponenten (von Microsoft) und Updates auf dem Betriebssystemlayer
  • Wenn Microsoft Runtimes erforderlich sind, werden sie auf dem Betriebssystemlayer installiert
  • Windows-Rollen und -Features, z. B. die auf dem Betriebssystemlayer installierten RDS-Rollen, sodass sie mit Windows Update aktualisiert werden können
  • Wenn lokalen Benutzer oder Gruppen zu den virtuellen Maschinen hinzugefügt werden müssen, kann diese Aufgabe nur auf dem Betriebssystemlayer ausgeführt werden, da der Windows-Sicherheitskonto-Manager (SAM) von dem Betriebssystemlayer erfasst wurde.

Referenz: Erstellen eines Betriebssystemlayers

Plattformlayer

Ein Plattformlayer ist ein Layer, der Konfigurationseinstellungen, Tools und andere Software enthält, die erforderlich ist, um ein veröffentlichtes Image auf einer bestimmten Plattform auszuführen. Es können zwei Plattformlayer-Typen erstellt werden:

Publishing Platform Layer: Dieser Plattformlayer wird verwendet, um die Software einzuschließen, die für ein Zielprovisioningsystem, einen Broker und einen Hypervisor erforderlich ist. Ein Publishing-Plattformlayer zur Unterstützung von Provisioning Services auf vSphere für Citrix Virtual Apps ist beispielsweise Citrix VDA und PVS-Gerätetreiber installiert. Wenn vSphere nicht derselbe Hypervisor ist, auf dem die Verpackung ausgeführt wird, ist auf diesem Layer auch VMware Tools installiert.

Packaging Platform Layer: Packaging Platform Layer 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 sie notwendig sind, einschließlich:

  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 eine Verpackungsplattformlayer mit VMware Tools verwendet, um die Verpackungsmaschine auf vSphere zu unterstützen.

  2. Wenn der Zugriff auf die Verpackungsmaschine über die VDA-Software erforderlich ist. Dieser Layer wird am häufigsten benötigt, wenn Treiber für USB-Peripheriegeräte installiert werden, die das Gerät ordnungsgemäß installieren müssen. Durch das Erstellen eines Verpackungsplattformlayers mit installierter VDA-Software und das 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 ohne Ausführen des Imaging-Assistenten installiert und dann neu gestartet
  • Die Installation von Citrix VDA- und Citrix Provisioning Gerätetreibern erfolgt im Plattformlayer
  • Domänenbeitritt wird im Plattformlayer durchgeführt, d. h. mehrere Plattformlayer können erstellt werden, 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 zum Erstellen von Plattformlayern 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 Gruppe von Anwendungen. Beim Erstellen oder Bearbeiten eines Layers wird eine Verpackungsmaschine dynamisch erstellt und alle Dateisystem- und Registrierungsänderungen werden auf diesem Computer erfasst. Die Verpackungsmaschine enthält den Betriebssystemlayer und alle enthaltenen erforderlichen App-Layer. Ein zweites virtuelles Laufwerk namens Package Disk wird als beschreibbares Volume an die Verpackungsmaschine angehängt. Dieser Datenträger erfasst alle Dateisystemänderungen während des Pakets, und er enthält auch eine Registrierungsstruktur (RSD-Struktur genannt), die verwendet wird, um alle Registrierungsänderungen zu erfassen. 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.

Die meisten Anwendungen werden mit der gleichen Konfiguration installiert, die der Administrator normalerweise für das unterstützte Provisioningsystem verwenden würde. Beim Erstellen von App-Layern ist es immer wichtig, die automatischen Updates zu deaktivieren. Da 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 während der Benutzeranmeldung in einer virtuellen Sitzung, indem Layer, die als VHD-Dateien auf einer SMB-Freigabe gespeichert sind, bereitgestellt und diese 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 VHD-Layer-Dateien als auch JSON-Konfigurationsdateien enthält, die zum Definieren von Layer-Zuweisungen für den Layering-Dienst verwendet werden. Der Layering-Dienst liest die Konfigurationsdateien und stellt dann Layer-VHD-Dateien über einen Windows SDK-Aufruf bereit.

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

  1. Anwendungen mit Kerneltreibern
  2. Anwendungen mit Diensten, die Abhängigkeiten für andere Boot-Zeitdienste sind
  3. Anwendungen, die den Windows Treiberspeicher wie Druckertreiber von Drittanbietern ändern

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

Konfigurationsdateien (JSON)

Wie oben beschrieben, werden Elastic Layer-Zuweisungen in einer Gruppe 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, die Anwendungen zugewiesen hat, 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 erhalten, der zum Bereitstellen der virtuellen Festplatte verwendet wird.

  • MachineAsSociations.json: Wie der Name andeutet, dass die Computerzuordnung mit einer beliebigen AD-Gruppe definiert wird, verwendet das Format Computernamenmuster mit Platzhaltern, um eine Gruppe von Computern einer definierten AD-Gruppe zuzuordnen. Wenn sich ein Benutzer an einem Computer anmeldet, der dem Muster entspricht, erhält er die Elastic Layer, die dieser Gruppe zugewiesen sind. Diese Einstellungen werden in der App Layering Management Console im Abschnitt Benutzer > Gruppendefiniert.

Benutzerebene

Benutzerlayer bieten Benutzern eine beständigere Benutzererfahrung und unterstützen dennoch ein gemeinsam genutztes Desktop-Computermodell. Danach wird ein Benutzerlayer eingehängt, die meisten Systemschreibvorgänge werden auf den Benutzerlayer umgeleitet. Dieser Layer ermöglicht die Unterstützung für Folgendes:

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

Benutzerlayer werden eins zu eins zugewiesen. Ein Benutzer kann nur einen beschreibbare Layer pro Betriebssystemlayer pro Domäne haben. Benutzer können sich daher nur bei einer Bereitstellungsgruppe oder einem Pool mit einem Desktop anmelden, wobei die gleiche Betriebssystem- und Plattformlayer-Kombination verwendet wird, wenn 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 des “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 von Standardwerten, die in das Basisimage integriert sind, können aber auch von den elastischen Layer und den Persistenzschicht-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-Dienst 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\ Program Files\ Unidesk\ Etc\ UserLayer.json-Datei 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.

Folgende 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 Standardgröße eines Benutzerlayers ist 10 GB. Diese Größe kann geändert werden, indem ein Kontingent für die Benutzerlayerfreigabe definiert wird. Es ist auch möglich, die Standardgröße des Benutzerlayers mit einem Registrierungseintrag auf den VDAs außer Kraft zu setzen. Um die Standardgröße der maximalen Größe zu ändern, fügen Sie die folgende Registrierungsüberschreibung hinzu:

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE: <Size in GB>

Elastic Layer-Freigabe und Benutzer-Layer-Freigaben

Elastic Layers sind VHD-Dateien, die vom Client- oder Server-Betriebssystem über das VM-Netzwerk bereitgestellt werden. Elastic Layer werden schreibgeschützt bereitgestellt, und viele Maschinen können genau dieselbe VHD-Datei mounten. Der für Elastic Layer verwendete Dateiserver oder die Freigabe sind für die Lese-E/A optimiert.

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

Die Architektur für Elastic Layer ist weitgehend skalierbar. Der Elastic Layer-Freigabe-Repository-Pfad ist 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 User Layer 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 ArtikelCTX222107.

Der für Benutzerlayer verwendete Standort wird von der Active Directory Gruppe zugewiesen und ist daher auch sehr skalierbar, da beliebig viele Freigaben verwendet werden können. Diese Zuordnungen werden unter System>Lagerortedefiniert.

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

Dateifreigabe auf Benutzerlayer

Während des Anmeldevorgangs, wenn ein Image für Benutzerlayer konfiguriert wird, wird die VHD-Datei des Benutzerlayers erstellt, wenn sich der Benutzer nach der Zuweisung des Image zum ersten Mal anmeldet. Die Freigabeeinstellungen für den Benutzerlayer werden in der Appliance von der Active Directory Gruppe definiert. Wenn sich ein Benutzer in mehreren Gruppen mit zugewiesenen Benutzer-Layer-Freigaben befindet, gibt es eine Prioritätsreihenfolge für die Freigabe und ihre Benutzerlayer-Datei, die auf der Freigabe mit höchster Priorität erstellt wurde. User Layer-Datenträger können jeweils nur auf einem Computer verwendet werden.

Benutzerlayer sind sowohl an die Domäne als auch an den Betriebssystemlayer für den Desktop gebunden, bei dem angemeldet wird. Der Pfad zu einem bestimmten Benutzerlayer ist 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 Gruppe ein, die der Freigabe zugeordnet ist.

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

Integration von App Layering Anwendungen

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

Citrix App Layering und Citrix Provisioning Services

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

AL-Image-10

Im vorhergehenden Diagramm wird das Veröffentlichen von Layered-Images mithilfe von 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 Connector PowerShell -Skripte so konfiguriert werden, dass sie nach dem Hochladen des Images für das Image ausgeführt werden. Wenn Sie diese Funktion verwenden und die Skripte prozessorintensiv sind, ist es ratsam, einen “Pre-Staging” -Provisioning Server zu verwenden, der nicht zur Durchführung des Streamings verwendet wird. Auf diese Weise werden die Veröffentlichungs- und Skriptverarbeitung Streaming-Funktionen in der Provisioning Services Farm nicht beeinträchtigt. Um dieses Design zu unterstützen, ist es am einfachsten, eine “DEV” Citrix Provisioning-Farm mit einem einzigen Server zu erstellen. Dieser “DEV” -Server kann auch zum Streamen von Testimages verwendet werden. Nach dem Testen des Images kann das virtuelle Laufwerk zur Production Citrix Provisioning Farm für weitere Tests und Bereitstellung repliziert werden.

Weitere Informationen zu diesem Skripttyp 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 Image-Vorlage mit einem Datums- und Zeitstempel für die Versionierung benannt. Virtuelle Laufwerke werden in Provisioning Services auf die gleiche Weise verwaltet, wie sie ohne App Layering verwaltet werden. Die 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 die gleiche Änderung dem 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. Wenn eine Datei geöffnet wird, wird für den Schreibvorgang mit App Layering die gesamte Datei in das beschreibbare Volume der virtuellen Maschine kopiert, sodass sie bearbeitet werden kann. Bewirkt, dass die gesamte Datei auch in den Datenträgercache kopiert wird, wenn 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 Benutzer-Layer 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 Bereitstellungscache keine E/A mehr auf der beschreibbaren Partition sieht.

Citrix App Layering und Maschinenerstellungsdienste

Um Layered Images in Maschinenerstellungsdienste zu veröffentlichen, wird ein Maschinenerstellungsdienste-Connector erstellt, der für den Hypervisor erstellt wurde, in dem veröffentlicht wird. Die Connector-Konfiguration umfasst neben Hosts, Speicherorten, Vorlagen usw. auch die Anmeldeinformationen für das Dienstkonto, 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 Layer-Skripte 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 Vorgang abgeschlossen ist, kann das Masterimage mithilfe von Maschinenerstellungsdiensten bereitgestellt werden. Die Benennung der virtuellen Maschine ähnelt der Citrix Provisioning. Die virtuelle Maschine wird als Name der veröffentlichten Imagevorlage, gefolgt von einem Datums- und Zeitstempel benannt. 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 einzustellen. Bei der Verwendung von MCS ist es wichtig, dass die zum Erstellen der Masterimages verwendete Vorlage von einer echten virtuellen Maschine erstellt worden sein muss. Der Computer wurde in Windows gestartet und hat 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 gebootete Image seine Zeitabschaltung um einige Stunden basierend auf UTC. Die beste Möglichkeit, die Vorlage zu erstellen, besteht darin, einen Klon des ursprünglichen Golden Images zu verwenden, das zum Erstellen des OS-Layers verwendet wird. Dieser Schritt stellt sicher, dass die Einstellungen der virtuellen Hardware vom Betriebssystemlayer bis zum Masterimage übereinstimmen.

Plattformübergreifende Citrix App Layering-Unterstützung

Die Citrix App Layering Architektur wurde entwickelt, um viele Hypervisoren und Provisioningsysteme zu unterstützen, ohne Layer für eine Plattform zu erstellen. 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 ausgeführt. Die Connectors bieten die Integration in alle unterstützten Plattformen, einschließlich Hypervisoren und Provisioning -Systeme.

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 VDA-Software und PVS-Software beide im Plattformlayer 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 zur Bereitstellung von Cloudplattformen 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 zur Kommunikation 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 Verwaltungs-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 an 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-Provisioning für ein lokales Administratorkonto aufgefordert.

Beim Exportieren von Protokollen aus der Verwaltungskonsole wird ein Downloadlink generiert und in den Taskdetails 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 über die App Layering-Appliance verfügbar.

Optional kann die App Layering Appliance nach Upgrades suchen und sie von Citrix x-Servern über das Internet über HTTPS/443 oder HTTP/80 herunterladen. www.citrix.com und cdn.citrix.com werden aufgerufen, wenn eine Internetverbindung verfügbar ist.

Connectorkonfiguration

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

Connector HTTP-Port HTTPS-Port Interne Anschlüsse
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 in der Verwaltungskonsole als separate Webseite geöffnet. Jeder Connector verfügt über einen HTTP- und HTTPS-Listening-Port. 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.

Verschiedene Ports

Die App Layering Appliance spricht mit verschiedenen Netzwerkservern und -diensten auf 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
Netzwerkzeitserver NTP 123
DHCP-Server DHCP UDP/67
App Layering-Appliance DHCP UDP/68

Der Agent-Service

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

  • Integration mit Citrix Provisioning
  • Integration mit Hyper-V
  • Integration mit einem allgemeinen Scripting Server

Auf den Agentendienst wird über die folgenden Ports zugegriffen.

Agent-Server Ziel Funktion oder Protokoll Port
Alle App Layering-Appliance Registrierung oder HTTPS 443
Alle Agent-Server Befehle von App Layering Appliance oder SOAP 8016
Alle App Layering-Appliance Protokollexport 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 Agent-Server zu registrieren. Die App Layering Appliance speichert den FQDN und den Kurznamen für den Agent-Service-Host, und die Registrierung auf dem Agent-Server 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 am Port 8016. Die meisten Kommunikationen zwischen der Appliance und dem Agenten funktionieren 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 die Antwort auf App Layering-Appliance auf vorhandenem Anforderungskanal
Agent Auf Wiedersehen

Die Besonderheiten des tatsächlich gesendeten Befehls können häufig im Connectorprotokoll 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, der Protokolle vom Agenten anfordert. Jeder Agent-Dienst generiert sein eigenes Protokollpaket und sendet es an die App Layering-Appliance an Port 8787 zurück.

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.

Der Prozess der Übertragung 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 an Port 3009 der App Layering-Appliance
BITS Lädt die Datei an den angegebenen Repository-Speicherort herunter
App Layering-Appliance Befehl zum Abrufen des Übertragungsstatus
Agent Abfragt BITS nach Status und Reports 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 Performance-Gründen — der Overhead der Ausführung auf 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, stellt er BITS zwei Dinge bereit: die URL für den Dateidownload und den Zieldateipfad. BITS wird als 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

Diese Ports sind dieselben Ports, die auch von den browserbasierten Hypervisor Verwaltungskonsolen verwendet werden. App Layering verwendet klar definierte API-Aufrufe über den normalen Webservice des Hypervisors für die Kommunikation mit dem Hypervisor.

Für vSphere-Dateiuploads und Downloads werden nicht durch die Kommunikation mit vCenter durchgeführt. Und durch direkte Kommunikation mit einem ESXi-Host. Aus diesem Grund muss 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 an Port 443 ermöglicht wird.

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, Sicherung und Wiederherstellung

App Layering kann mehrere Komponenten enthalten, in denen Backups geeignet sind. Einschließlich Appliance, Elastic Layer Shares und User Layer Shares.

Appliance-Backups

Die App Layering-Appliance ist, wie bereits erwähnt, nicht erforderlich, damit Endbenutzer das App Layering vollständig nutzen können. Daher ist es nicht erforderlich, die Appliance hochverfügbar zu machen. Es muss jedoch als Anforderung angesehen werden, die Appliance 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 jedoch jetzt ein manueller Prozess.

Verfügbarkeit und Disaster Recovery für elastische Layer

Elastic Layer sind Dateien, die während der Anmeldung mithilfe einer Windows-In-Gast-Bereitstellung von einer SMB-Freigabe auf Virtual Desktops Agents (VDAs) bereitgestellt werden. Der Layering-Dienst verbindet die Layer bei der Anmeldung, stellt jedoch nie eine getrennte VHD-Datei wieder her. Daher ist es wichtig sicherzustellen, dass der für Elastic Layer verwendete Dateiserver mithilfe eines Typs von Clusterdateisystemen hoch verfügbar ist. Die Verwendung mehrerer DFS-R-Ziele ist für diesen Anwendungsfall nicht ausreichend. Wenn ein Ziel fehlschlägt, können die bereitgestellten VHD-Dateien erst dann einem anderen Ziel zugeordnet werden, wenn eine erneute Anmeldung stattfindet.

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.

Referenz: Leitfaden zur Verfügbarkeits- und Wiederherstellungskonzepte für App Layering 4.x

Replikationsmodell

In diesem Modell können Elastic Layer-Freigaben mit einer beliebigen Dateisystem-Replikationstechnologie 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 Gruppenrichtlinienobjekt-Vorlage zum Konfigurieren des Repository-Speicherorts finden Sie hier:CTX222107.

Dual-Appliance-Modell

In diesem Modell wird 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. Sie 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 die gewünschten 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 Exportprozess 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. Wenn es sich beispielsweise um ein aktives Standortszenario handelt.

Verfügbarkeit und Notfallwiederherstellung für Benutzerlayer

Benutzerlayer ähneln Elastic Layers, da es sich um VHD-Dateien handelt, die von Windows bei der Anmeldung mit einer In-Gast-Bereitstellung bereitgestellt werden. Sie werden jedoch als 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 Robokopie-Skript der Synchronisationsprozess außerhalb von Stunden durchgeführt werden (wenn Zeiten außerhalb von Stunden berücksichtigt werden). Der Prozess muss ständig überprüfen, ob die Dateien synchronisiert werden können. Bei Benutzerlayern, bei denen es sich um große Dateien handelt, funktioniert robocopy nicht gut, da es immer die gesamte Datei und nicht die geänderten Blöcke kopieren würde. DFS-R wäre eine bessere Wahl, da es nur modifizierte Blöcke kopiert. Die Replikation auf Speicherebene wäre jedoch noch besser, da sie gleichmäßiger synchronisiert würde, wenn Änderungen vorgenommen werden, 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 VHD-Dateien des Benutzerlayers ausgewählt wurde. Wenn der Dateiserver den Volume Shadow Copy Service (VSS) unterstützt, werden VSS-Snapshots erstellt, um Backup und Replikation der Benutzerlayer zu ermöglichen. Durch Variieren der Häufigkeit des Prozesses können User Layers dann auch auf frühere Zeitpunkte zurückgesetzt werden, wenn Korruption oder Fehler gemacht werden, die sich negativ auf den Benutzer auswirken.

Wenn ein Speichercontroller NDMP unterstützt, kann diese Funktion auch für Backups von User Layer 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. Provisioning der Benutzer mit einer separaten Bereitstellungsgruppe in der DR-Site, die auch für Benutzerlayer aktiviert ist. Sie können sich dann am DR-Site anmelden und diesen Layer mit dem vorab konfigurieren, was sie benötigen. 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 User Layer zu mischen, damit Benutzereinstellungen auf die DR-Site repliziert werden können.

Referenz: Citrix App Layering Backup und Recovery

Quellen

Ziel dieser Referenzarchitektur ist es, Sie bei der Planung Ihrer eigenen Implementierung zu unterstützen. Um diese Aufgabe zu erleichtern, stellen wir Ihnen Quelldiagramme zur Verfügung, die Sie in Ihren eigenen detaillierten Entwürfen und Implementierungshandbüchern anpassen können:Quelldiagramme.

Referenzen

Für ein besseres Verständnis der Citrix App Layering werden die folgenden Ressourcen referenziert:

App Layering Produktdokumentation

So erstellen Sie einen Plattformlayer

Grundlegendes zu Elastic Layering

App Layering — Verfügbarkeits- und Wiederherstellungskonzepte

Optimierungen der Windows- und App Layering Optimierung

Antivirushandbuch für App Layering

Verstehen des Office-Rezepts

Best Practices für App Layering

Citrix App Layering

In diesem Artikel