Architecture de référence : App Layering

Audience

Ce document est destiné aux professionnels techniques, aux décideurs informatiques, aux partenaires et aux intégrateurs de systèmes. Cela permet à l’administrateur d’explorer et d’adopter Citrix App Layering pour faciliter la gestion de la fourniture d’images et d’applications à ses utilisateurs finaux. Le lecteur doit avoir une compréhension de base des produits Citrix, des services de gestion d’images et des concepts de virtualisation d’applications. Pour plus d’informations sur la gestion des images, consultez l’architecture de référence sur Citrix Tech Zone.

Objectif du présent document

Ce document fournit une présentation technique et des concepts architecturaux pour la gestion et la mise à disposition d’applications à l’aide des technologies Citrix App Layering. Ce document explique à la fois le fonctionnement d’App Layering et l’intégration avec Citrix Virtual Apps and Desktops sur différentes plateformes.

Présentation de Citrix App Layering

Citrix App Layering est une solution flexible qui fournit un ensemble complexe d’applications Windows à un ensemble diversifié d’utilisateurs sur n’importe quelle plate-forme prise en charge non persistante.

Citrix App Layering effectue la gestion des images d’une manière unique. Le système d’exploitation et les applications sont divisés en différents conteneurs appelés « couches ». Les couches sont créées et mises à jour indépendamment, puis compilées en « images publiées » à distribuer à l’aide de n’importe quel système de provisioning pris en charge.

Une fois les bibliothèques d’applications créées, différents ensembles d’images sont déployés sur de nombreuses plates-formes en utilisant n’importe quelle combinaison de couches.

AL-Image-1

L’objectif principal de Citrix App Layering est de simplifier la gestion des applications Windows à l’aide d’une interface unique. Il permet à l’administrateur de créer et de gérer des applications d’entreprise quels que soient les hyperviseurs sous-jacents ou l’infrastructure cloud.

Le système d’exploitation et les applications sont séparés en unités gérables distinctes. Même si de nombreuses images sont nécessaires pour contrôler correctement l’accès aux applications, chaque système d’exploitation et ses applications sont gérés comme une seule instance. Dans cette approche, il n’est pas nécessaire d’effectuer des mises à jour sur toutes les images de l’environnement. Simplifie l’environnement tout en réduisant le temps de gestion, la complexité et les coûts associés aux systèmes d’exploitation et à la gestion des applications.

Le système d’exploitation et les applications sont stockés sous forme de disque virtuel contenant des fichiers et des entrées de registre pour une couche spécifique. Il existe deux manières d’inclure des applications dans des machines virtuelles :

  • Image publiée : cette méthode combine la couche du système d’exploitation, une couche de plate-forme et un ensemble de couches d’application pour créer une image pour le provisionnement de systèmes tels que Citrix Provisioning ou Citrix Machine Creation Services. App Layering peut publier des images sur plusieurs systèmes de Provisioning et plusieurs hyperviseurs à partir d’un même ensemble de couches.

Pour en savoir plus sur la gestion des images Citrix, consultez le document sur l’architecture de référence .

  • Couches élastiques : peu de couches d’application sont attachées à une machine virtuelle pendant l’ouverture de session en fonction de l’appartenance à un groupe AD et de l’attribution d’applications. Permet une plus grande flexibilité dans l’attribution des applications en permettant la livraison dynamique des applications sur des images standardisées.

La séparation des applications et de la personnalisation du système d’exploitation fournit une solution flexible et gérable pour la gestion non persistante des images.

Pourquoi choisir Citrix App Layering

Citrix App Layering fournit une solution rentable pour gérer un ensemble complexe d’applications dans plusieurs environnements avec des exigences de mise en packaging différentes. Presque toutes les applications intégrées avec des pilotes de noyau, des systèmes d’exploitation et des dépendances de service système sont compatibles avec la technologie App Layering.

L’adoption de l’approche Citrix App Layering pour la gestion des images présente de nombreux avantages :

  • Simplifie la gestion des images principales pour PVS et MCS : Citrix App Layering est une solution de gestion d’image unique qui prend en charge les modèles de provisionnement utilisés avec Citrix et les hyperviseurs tiers. Grâce à App Layering, la gestion et les mises à niveau des images sont simplifiées, sans modification directe ni imagerie inversée des images.

  • Prise en charge d’Azure : Citrix App Layering prend en charge Microsoft Azure et simplifie la migration des clients App Layering vers une plate-forme Azure.

  • Dissociez les applications et les systèmes de provisionnement de l’image : Citrix App Layering sépare le packaging de l’image. Dans la gestion normale des images, les mises à jour d’une image sont effectuées séparément pour chaque image. En utilisant App Layering, un calque peut faire partie de nombreuses images. Pour mettre à jour toutes les images, il est possible que la couche soit mise à jour une seule fois et que les images soient régénérées. Les mises à niveau de composants tels que les outils d’hyperviseur, les Virtual Delivery Agents (VDA) et les outils Citrix Provisioning deviennent faciles.

  • Prend en charge les cas d’utilisation complexes : les applications complexes avec des pilotes de noyau, des services système, des pilotes tiers et un accès à la console peuvent toutes être prises en charge à l’aide de Citrix App Layering. Grâce aux deux modes de déploiement de la couche d’applications d’App Layering, presque toutes les applications sont compatibles.

  • Couche utilisateur de bureau non persistant : La couche utilisateur est une couche élastique accessible en écriture. Un utilisateur se connecte à un poste de travail. La plupart des opérations d’écriture sont effectuées dans la couche utilisateur. Il permet à un utilisateur d’installer des applications et d’enregistrer des paramètres de configuration qui ne figurent pas dans le profil utilisateur. En outre, il stocke les fichiers de données des utilisateurs en faisant en sorte que leur bureau semble persistant avec les avantages d’un modèle de bureau partagé.

  • Réduit le nombre d’images requises : Elastic Layering peut réduire considérablement le nombre d’images requises en fournissant dynamiquement des applications uniquement aux utilisateurs assignés lors de l’ouverture de session. Les couches élastiques sont compatibles avec Citrix Virtual Apps et Citrix Virtual Desktops.

Cas d’utilisation de Citrix App Layering

L’App Layering est un ajout important au portefeuille technologique de Citrix qui offre de nombreux avantages répertoriés précédemment. Bien qu’il offre des avantages, App Layering ne signifie pas l’utiliser pour tous les cas d’utilisation. Dans cette section, plusieurs des cas d’utilisation les plus pertinents sont présentés pour montrer les avantages de la technologie App Layering.

1-Trop d’images à gérer

De nombreux clients Citrix doivent prendre en charge un nombre important d’applications et un ensemble complexe d’exigences utilisateur. Lors de l’utilisation d’une technologie de provisionnement basée sur l’image, le respect de ces exigences nécessite souvent la gestion d’un grand nombre d’images. Ces images doivent prendre en charge différents groupes d’utilisateurs ou différents ensembles d’applications conflictuelles. Il y a souvent un certain chevauchement entre les applications déployées sur chaque image.

Citrix App Layering simplifie la gestion de ce scénario complexe.

AL-Image-2

App Layering permet aux administrateurs de gérer le système d’exploitation et les applications en tant qu’entités individuelles à l’aide de couches. Par exemple, Windows doit être patché, le correctif est appliqué une seule fois à la couche du système d’exploitation et toutes les images utilisant la couche du système d’exploitation sont mises à jour par l’appliance App Layering. Si Microsoft Office est utilisé dans 10 images, la mise à niveau de cet Office est plus simple en ajoutant une version à la couche Office. Finalement, toutes ces 10 images sont mises à jour automatiquement.

Lorsque Elastic Layering est ajouté, il est également possible de réduire considérablement le nombre d’images requises. Elastic Layer permet aux administrateurs de fournir des applications de manière dynamique lors de l’ouverture de session. Pour les applications qui ne sont pas utilisées par tout le monde, Elastic Layers permet de créer l’image de manière plus générique tout en fournissant une personnalisation pour chaque utilisateur.

2-Prise en charge de plusieurs hyperviseurs et d’Azure

De nombreuses entreprises optent pour un environnement multicloud hybride combinant des ressources sur site et cloud pour améliorer l’expérience utilisateur. Citrix App Layering fournit la portabilité des images en prenant en charge la plupart des hyperviseurs et Microsoft Azure simplement en créant une couche de plate-forme différente pour chaque environnement souhaité.

AL-Image-3

Normalement, une configuration mixte d’hyperviseur et de cloud hybride oblige les administrateurs à gérer plusieurs ensembles d’images et d’applications sur différentes plateformes de gestion. Grâce à la technologie App Layering, le même système d’exploitation et les mêmes applications utilisés sur site peuvent être transférés vers le cloud ou vers un autre hyperviseur avec peu ou pas de travail supplémentaire.

Pour en savoir plus sur les fonctionnalités multiplateformes d’App Layering, consultez la section Assistance multiplateforme Citrix App Layering ci-dessous.

3- Portabilité de l’hyperviseur pour la migration

Les entreprises se retrouvent souvent « bloquées » avec la technologie d’un fournisseur simplement parce que le coût de la migration vers une nouvelle technologie est prohibitif. De plus, les entreprises fusionnent souvent avec d’autres organisations qui ont fait des choix technologiques différents. L’un des principaux avantages de l’App Layering est la possibilité de passer d’une plate-forme à une autre simplement en créant une couche de plate-forme différente et en migrant l’application Layering à l’aide de l’exportation d’importation vers la nouvelle plate-forme.

AL-Image-4

Permet une migration transparente, par exemple, de vSphere vers Citrix Hypervisor ou d’un Hypervisor local vers Azure.

4-Persistance pour les postes de travail VDI partagés

De nombreuses entreprises comptent plusieurs utilisateurs qui ont besoin d’un haut niveau de persistance sur les ordinateurs de bureau. Y compris les utilisateurs avancés de n’importe quel groupe, les développeurs, les ingénieurs, les architectes, etc. Les couches utilisateur App Layering offrent une persistance importante en plus d’une architecture de bureau groupée.

La couche utilisateur est montée lors de l’ouverture de session et toutes les écritures ultérieures sur le bureau sont écrites sur la couche utilisateur. La plupart des applications peuvent être installées dans la couche utilisateur. Les règles relatives à ce qui fonctionne dans la couche utilisateur sont les mêmes que pour Elastic Layering. Tant que l’application n’installe pas les pilotes du noyau, les pilotes tiers et les services qui sont des dépendances à d’autres services pendant le démarrage, ils sont les plus susceptibles de fonctionner dans la couche utilisateur.

AL-Image-5

Pour les cas d’utilisation nécessitant une persistance, la couche utilisateur est le meilleur choix. Pour les cas d’utilisation pour prendre en charge uniquement les fichiers OST Microsoft Outlook et les fichiers d’index, la couche utilisateur peut ne pas être le meilleur choix. La couche utilisateur est destinée à gérer toutes les écritures sur le bureau VDI une fois que l’utilisateur ouvre une session. D’autres technologies telles que Citrix Profile Management Outlook Container ou FSLogix Profile ou Office 365 Container gèrent l’OST Outlook et indexent de manière beaucoup plus ciblée afin de réduire la quantité d’E/S gérée par le conteneur. Toutes ces solutions gèrent désormais la gestion des fichiers Outlook OST, Outlook streaming et les fichiers d’index Outlook, de sorte que la prise en charge de l’indexation n’est plus une raison de choisir une technologie plutôt qu’une autre.

Présentation technique de Citrix App Layering

Types de couches

Une couche est un disque virtuel contenant les fichiers et les entrées de registre qui sont modifiés ou ajoutés lors de l’packaging. À l’exception de la première version de la couche Operating System, les couches sont créées par l’appliance App Layering intégrée à l’hyperviseur. Un administrateur crée une couche, l’appliance provisionne dynamiquement une machine packaging avec un disque de démarrage et un disque de couche. Lorsque la machine d’packaging démarre, toutes les modifications apportées à la machine d’packaging sont écrites sur le disque de couche. Une fois l’packaging terminé, ce disque est copié de nouveau sur l’appliance et tous les fichiers et modifications du registre sont écrits dans la nouvelle couche et stockés dans le référentiel de couches au format VHD.

App Layering utilise ces différents types de couches :

  • couches du système d’exploitation
  • Couches de plateforme
  • Couches d’application
  • Couches utilisateur complètes

AL-Image-7

Couche OS : Système d’exploitation comme Windows 10 ou Windows Server 2019. Construit à partir d’une machine virtuelle « Gold Image » dans l’hyperviseur.

Couche de plate-forme : La couche de plate-forme comprend le logiciel requis pour prendre en charge une plate-forme particulière. Y compris l’agent broker, le système de Provisioning et les outils de l’hyperviseur si l’hyperviseur est différent de l’hyperviseur par défaut. La couche plate-forme est également la couche la plus prioritaire et parfois un logiciel est installé ici pour être compilé avec la plus haute priorité.

Calques d’application : type de calque principal. Utilisé pour la plupart des logiciels d’application.

Couches utilisateur : couche inscriptible élastique (voir section suivante). Les couches utilisateur sont montées lors de l’ouverture de session et une fois montées, presque toutes les écritures du bureau sont placées sur la couche utilisateur. Cette couche permet aux utilisateurs de personnaliser de manière significative leur expérience VDI, même s’ils utilisent un modèle de bureau partagé.

Appliance Citrix App Layering

L’appliance Citrix App Layering (appliance) fournit à la fois l’interface d’administration pour App Layering et le moteur pour tous les processus App Layering.

L’appliance App Layering est déployée en tant que machine virtuelle dans le centre de données où s’effectuent le packaging des applications et la publication d’images. L’appliance App Layering est basée sur CentOS, configurée avec 4 processeurs virtuels et 8 Go de RAM. Ces paramètres ne doivent pas être modifiés car l’appliance est conçue pour fonctionner dans cette configuration.

L’appliance est construite avec deux disques. Le premier disque est un disque de démarrage de 30 Go pour le système d’exploitation. Le deuxième disque est le référentiel de couches de 300 Go. Ce disque peut être étendu ou étendu selon les besoins si davantage d’espace est requis.

Au cours du processus de création de couches et de publication d’images, l’appliance Citrix App Layering enregistre les fichiers de disque virtuel au format VHD dans son référentiel de couches au sein de l’appliance. L’appliance s’interface avec un partage SMB pour prendre en charge le processus de mise à niveau de l’appliance et stocker Elastic Layers.

L’appliance est utilisée uniquement pour gérer les calques, les images et les affectations de couche élastique. Les serveurs Virtual Desktops et Virtual App ne s’interfacent pas directement avec l’appliance. Lorsqu’une couche est affectée de manière élastique, l’appliance copie la couche dans le partage Elastic Layer. Le partage contient ces fichiers VHD ainsi qu’un ensemble de fichiers JSON qui fournissent les attributions de couches aux utilisateurs.

L’appliance Citrix App Layering héberge également la console de gestion App Layering. Le déploiement de l’appliance App Layering est la première étape du processus d’installation. Après l’installation de l’appliance, la console de gestion est accessible pour effectuer les étapes d’installation.

Pour en savoir plus sur l’installation de l’appliance Citrix App Layering, consultez la documentation produit.

AL-Image-6

La console de gestion Citrix App Layering est une application Web hébergée sur l’appliance App Layering. La console de gestion App Layering fournit l’interface pour :

  • Création et gestion des couches du système d’exploitation, de la plate-forme et des applications
  • Création de modèles d’images publiés
  • Publier et gérer des images en couches
  • Attribuer aux utilisateurs les rôles d’administrateur App Layering
  • Gérer les paramètres de l’appliance et du système, tels que la rétention des tâches et des journaux, les paramètres de sécurité et les partages de fichiers réseau

Moteurs de composition

Nouveauté de la version 1910 et ultérieure est une fonctionnalité appelée Compositing Engines. Les moteurs de composition déchargent la plupart des tâches d’packaging et de publication qui peuvent également être effectuées par l’appliance de App Layering. En déchargeant ces tâches, les processus de packaging et de publication évoluent mieux et, grâce aux avantages des technologies utilisées, les performances du processus sont également améliorées.

Un moteur de composition est créé par un connecteur hyperviseur en tant que machine virtuelle Windows PE qui effectue un ensemble de tâches de publication, puis se redémarre en une machine de packaging ou une image publiée. Le moteur de composition est utilisé pour créer des disques de calques mis en cache, créer des machines de packaging et publier des images. Au moment de la rédaction de cette architecture de référence, il existe des moteurs de composition pour HyperV et vSphere introduits respectivement dans les versions 1910 et 1911.

Les moteurs de composition ont les caractéristiques suivantes :

  • Appliance légère et éphémère exécutant Windows PE
  • Auto-composition
  • Contrôlé via l’API REST
  • Formats de disque d’hyperviseur pris en charge (VHD, VHDX et VMDK)
  • Prise en charge de l’UEFI (Gen2)
  • Démarrage sécurisé sur les images publiées (uniquement si aucun Elastic Layering ou User Layering n’est utilisé)
  • iSCSI est utilisé pour attacher des disques hébergés sur l’App Layering Appliance
  • Pas de limite sur le nombre de travaux de publication simultanée (il y a une limite pratique)

Avantages des moteurs de composition

L’utilisation des moteurs de composition est un choix. Dans le Connecteur HyperV et vSphere Connector, une case à cocher permet d’activer « Déchargement Compositing ». Ce paramètre est également disponible dans les connecteurs Machine Creation for vSphere et VMware Horizon View. L’avantage significatif du moteur de composition est qu’il s’exécute sur un périphérique Windows avec un accès direct aux disques de l’hyperviseur. Cela fournit les mécanismes permettant de prendre en charge les machines GEN2 dans HyperV, les formats VMDK ESX natifs avec provisionnement léger dans vSphere et UEFI dans les deux. Les performances d’emballage et de publication sont améliorées car les fichiers de couche volumineux sont moins traités et écrits directement dans les disques de l’hyperviseur par le moteur de composition qui se rattache à l’App Layering Appliance pour accéder aux couches à l’aide de connexions iSCSI.

Remarque : la publication PVS ne peut pas encore être effectuée à l’aide d’un moteur de composition. Par conséquent, il n’est toujours pas possible de publier directement un fichier VHDX ou une machine virtuelle GEN2 sur PVS.

Livraison de couches

Les couches peuvent être livrées de deux manières. Dans le cadre d’une image publiée dans laquelle l’appliance App Layering combine toutes les couches en un seul fichier disque et télécharge ce fichier sur le système de provisionnement ou où les couches sont montées lors de l’ouverture de session et mises à la disposition des utilisateurs de manière dynamique.

Image publiée : Ici, un système d’exploitation, une plate-forme et un ensemble de couches d’application sont combinés dans un fichier disque unique publié sur un système de provisioning tel que Citrix Provisioning ou Machine Creation Services. Le processus commence par cloner la couche du système d’exploitation, puis écrire les fichiers à partir des couches Application un par un dans l’ordre de priorité, où plus la couche est récente, plus sa priorité est élevée et enfin écrire dans la couche de plate-forme. Le processus de fusion pour créer des images publiées est avancé. Lorsqu’une image est créée, les systèmes de fichiers, le registre et les variables d’environnement sont fusionnés, le magasin de pilotes Windows est recréé en fusionnant tous les pilotes tiers de différentes couches.

Couche élastique : ces couches sont des couches d’application qui sont attribuées aux utilisateurs par appartenance à un groupe Active Directory et attachées pendant ou peu après l’ouverture de session. Les couches élastiques sont dynamiques, ce qui permet aux administrateurs de personnaliser l’expérience utilisateur tout en minimisant le nombre d’images.

Connecteurs et configurations de connecteurs

L’appliance App Layering s’intègre aux hyperviseurs et aux systèmes de provisionnement à l’aide de connecteurs.

Il existe deux types de connecteurs : l’hyperviseur et le provisionnement :

  • Les connecteurs d’hyperviseur fournissent le mécanisme d’interface avec un hyperviseur. Il existe actuellement des connecteurs d’hyperviseur pour Citrix Hypervisor, vSphere, Hyper-V, Nutanix AHV, Azure et Azure Gov.

  • Lesconnecteurs système de Provisioning permettent à l’administrateur de publier une image sur le système de provisioning. Il existe actuellement un connecteur de système de provisioning pour Citrix Provisioning, Citrix Machine Creation Services sur chaque hyperviseur et Horizon View.

Une seule appliance peut se connecter à un nombre quelconque d’hyperviseurs ou de systèmes de Provisioning en disposant d’un plus grand nombre de connecteurs définis. Les configurations du connecteur définissent les paramètres requis pour l’intégration à l’hyperviseur ou au système de provisionnement. Une configuration inclut généralement des informations d’identification pour l’authentification, un emplacement de stockage, un modèle de machine virtuelle et toute autre information requise pour s’interfacer avec l’environnement dans lequel les administrateurs créent des couches ou publient des images. L’administrateur peut créer plusieurs configurations de connecteurs, chacune étant configurée pour accéder à un emplacement unique dans l’environnement. Les connecteurs sont utilisés pour :

  • Importation d’une image Gold lors de la création d’une couche OS
  • Création de calques et de versions de calques
  • Publiez des images en couches sur un hyperviseur ou Provisioning Service. Une configuration de connecteur peut également inclure un script PowerShell à exécuter sur un serveur Provisioning Server ou un système avec un agent hôte pour effectuer le post-traitement d’une image publiée

Référence : Configurations de connecteurs

Types de connecteurs

Cette section définit les types de connecteurs disponibles dans Citrix App Layering.

Connecteurs d’hyperviseur

Les connecteurs d’hyperviseur sont utilisés lors de la création de couches ou de l’importation d’une image Gold pour créer la couche OS. Lors de l’packaging dynamique, les connecteurs d’hyperviseur créent une machine de packaging sur le stockage et l’hôte définis par la configuration du connecteur. Une connexion à un hyperviseur peut également être utilisée pour créer une machine virtuelle dans l’hyperviseur.

Citrix Provisioning

Citrix Provisioning Connector s’intègre à un agent App Layering sur un serveur Citrix Provisioning pour publier une image directement sur le serveur Provisioning en tant que disque virtuel. Les conditions préalables pour Citrix Provisioning sont les suivantes :

  1. Le compte de service du connecteur doit être un compte de domaine avec l’autorisation d’administrateur dans PVS.
  2. Le compte de service du connecteur doit également être un administrateur local sur le serveur Citrix Provisioning.
  3. Un agent Citrix App Layering doit être installé sur chaque serveur Citrix Provisioning défini dans un connecteur. Un seul agent peut être défini par connecteur.

Référence : Citrix Provisioning

Machine Creation Services

L’appliance Citrix App Layering peut provisionner et publier directement des images en couches sur des hyperviseurs en tant que machines virtuelles utilisées comme image principale pour MCS. Les connecteurs permettent aux images en couches de publier directement sur l’hyperviseur. Le connecteur MCS est presque identique aux connecteurs d’hyperviseur, sauf que le connecteur MCS démarre la machine virtuelle publiée, ce qui permet à tous les scripts définis dans les couches de s’exécuter sur l’image principale avant son déploiement par MCS. L’arrêt de l’image principale et un instantané de machine virtuelle pris dans le cadre de ce processus.

Scripts de connecteur

Cette étape est une fonctionnalité optionnelle et avancée disponible lors de la création d’une configuration de connecteur. Pour utiliser cette fonctionnalité, configurez un script PowerShell facultatif pour qu’il s’exécute sur le serveur d’agent défini dans la configuration du connecteur. Cette étape est le plus souvent utilisée avec Citrix Provisioning, mais elle peut être utilisée avec tout autre connecteur de publication en installant l’agent App Layering sur un système Windows pour exécuter des scripts sur une image publiée. Copiez les scripts sur la machine sur laquelle l’agent est installé. Ce script s’exécute après le déploiement réussi d’une image en couches. Pour utiliser cette fonctionnalité, avec une image principale sur un hyperviseur, le script doit également s’interfacer avec la plate-forme de gestion de l’hyperviseur. Par exemple, pour vSphere, le script peut avoir besoin d’utiliser PowerCLI contre vCenter pour exécuter du code sur la machine virtuelle Master Image.

Certaines variables prédéfinies sont disponibles pour permettre la réutilisation des scripts avec différentes images de modèle et différentes configurations de connecteur. Les variables contiennent également des informations qui identifient la machine virtuelle dans le cadre de l’image publiée.

Pour en savoir plus sur les exemples de scripts, consultez les articles d’assistance suivants CTX226060 et CTX226062.

Modèles d’image publiés

Lors de l’utilisation d’App Layering, les couches OS, Platform et Application sont fusionnées par l’appliance App Layering pour créer des images publiées. Les images sont publiées puis créées dans un format requis par le système de provisionnement cible. Par exemple, si les administrateurs publient sur Citrix Provisioning, l’appliance crée un disque dur virtuel et le télécharge sur le serveur Provisioning défini en tant que disque virtuel. Si la solution utilise Machine Creation Services sur Citrix Hypervisor, l’appliance crée un disque dur virtuel, le télécharge sur Citrix Hypervisor et crée une VM d’image principale à l’aide du disque dur virtuel.

Pour définir la configuration d’une image publiée, un modèle d’image est utilisé. Le modèle d’image définit les couches OS, Platform et Application incluses dans l’image. Il définit également le connecteur utilisé pour publier l’image, la taille de l’image résultante en Go, si Elastic Layering est activé sur l’image ou l’un des différents types de couches utilisateur. Les modèles d’image sont un instantané instantané de la configuration de l’image, ils ne prennent pas en charge la gestion des versions. Toutefois, les modèles d’image peuvent être clonés et modifiés si des versions légèrement différentes de la même image sont requises.

Agent App Layering

L’agent Citrix App Layering assure les communications entre l’appliance App Layering et un serveur Citrix Provisioning, un serveur Hyper-V ou simplement une machine Windows utilisée comme serveur de script. App Layering Agent peut également être utilisé pour automatiser l’écriture de scripts après la publication d’images vers d’autres hyperviseurs tels que Citrix Hypervisor ou vSphere. Pour Citrix Provisioning et Hyper-V, App Layering Connector contacte l’agent de App Layering et lui demande de transférer le disque dur virtuel compilé par l’appliance sur le serveur de l’agent. Ce transfert est initié depuis l’agent à l’aide de BITS et le fichier est téléchargé depuis l’appliance.

Les détails de l’agent de couche Citrix App se trouvent dans la documentation Citrix.

Référence : Install Agent

Active Directory

L’appliance App Layering se connecte à Active Directory à la fois pour s’authentifier auprès de l’appliance et pour attribuer des Elastic Layers. Lorsqu’un administrateur se connecte à l’appliance, il tente de se connecter à Active Directory avec les mêmes informations d’identification. Si cette ouverture de session fonctionne, l’utilisateur est autorisé à accéder à l’appliance.

L’accès aux services d’annuaire est requis aux fins suivantes :

  • Contrôle d’accès basé sur les rôles (RBAC)
  • Attribution de la couche Elastic et User

Lors de la liaison initiale avec le service d’annuaire, l’appliance App Layering est compatible avec la couche SSL 3.0 Secure Socket Layer et la sécurité des couches de transport TLS 1.1 et 1.2.

Pour créer une jonction d’annuaires, consultez la documentation du produit.

Couches

La section suivante décrit plus en détail les utilisations de chaque type de couche.

Couche OS

Une couche du système d’exploitation contient le système d’exploitation Windows. Il est recommandé d’inclure tous les composants susceptibles d’être mis à jour avec Windows Update dans la couche du système d’exploitation afin qu’ils soient tous mis à jour par Windows Update. Pour cette raison, tous les rôles et composants du système d’exploitation tels que les bibliothèques d’exécution .NET et Visual C++ sont inclus dans l’image du système d’exploitation.

Il est préférable de ne pas installer les applications de l’utilisateur final dans la couche OS, car toutes les couches d’application créées avec une couche de système d’exploitation particulière sont liées à cette couche de système d’exploitation. Si une application est installée dans la couche du système d’exploitation, chaque image utilisant cette couche pour que cette application soit incluse dans ce processus pose un problème lorsque la stratégie consiste à rendre la couche du système d’exploitation universelle. La séparation des applications du système d’exploitation est essentielle pour limiter le nombre d’images du système d’exploitation à gérer. Même les applications dotées de pilotes, de services et de périphériques noyau sont prises en charge dans les couches applicatives et n’ont pas besoin d’être incluses dans la couche OS.

Lors de la création de la couche OS, il y a quelques points à retenir :

  • Vérifiez les systèmes d’exploitation pris en charge à partir du lien
  • La couche OS n’est pas connectée au domaine. La jointure de domaine fait partie de la couche de plate-forme
  • Les outils d’hyperviseur de l’hyperviseur principal sont installés dans la couche du système d’exploitation. L’hyperviseur sur lequel la plupart des packaging sont effectués
  • Les outils d’hyperviseur pour les autres hyperviseurs sont installés dans la couche de plate-forme de cet hyperviseur.
  • Installation des composants .NET (de Microsoft) et des mises à jour dans la couche du système d’exploitation
  • Si Microsoft Runtimes est requis, ils sont installés dans la couche du système d’exploitation
  • Rôles et fonctionnalités Windows tels que les rôles RDS installés dans la couche du système d’exploitation afin qu’elle puisse être mise à jour avec Windows Update
  • Si un utilisateur ou un groupe local doit être ajouté aux machines virtuelles, cette tâche ne peut être effectuée que dans la couche du système d’exploitation car le gestionnaire de comptes de sécurité Windows (SAM) a été capturé à partir de la couche du système d’exploitation

Référence : Création d’une couche de système d’exploitation

Couche plate-forme

Une couche de plate-forme est une couche qui contient les paramètres de configuration, les outils et les autres logiciels nécessaires pour exécuter une image publiée sur une plate-forme particulière. Deux types de couches de plate-forme peuvent être créés :

Publishing Platform Layer : Ce type de Platform Layer permet d’inclure le logiciel requis par un système de Provisioning cible, un broker et un hyperviseur. Par exemple, une couche Platform Layer de publication destinée à prendre en charge Provisioning Services on vSphere for Citrix Virtual Apps possède le VDA Citrix et les pilotes de périphériques PVS installés. Si vSphere n’est pas l’hyperviseur où le packaging est effectué, VMware Tools est également installé sur cette couche.

Couche de plate-forme d’packaging : Les couches de plate-forme d’packaging sont utilisées si une couche d’emballage est requise pour supporter les machines d’emballage. Ces couches ne sont pas souvent nécessaires, mais il existe plusieurs cas où l’une d’elles doit être nécessaire, notamment :

  1. Si une couche doit être empaquetée sur un hyperviseur différent de celui de la norme. Par exemple, si la plupart des couches sont créées sur Hyper-V, mais que pour une raison quelconque, une couche particulière créée dans vSphere, une couche de plate-forme de packaging en package avec VMware Tools est utilisée pour prendre en charge la machine de mise en packaging sur vSphere.

  2. Si l’accès à la machine d’packaging est requis à l’aide du logiciel VDA. Cette couche est le plus souvent requise lors de l’installation de pilotes pour périphériques USB qui doivent voir le périphérique pour s’installer correctement. En créant une couche de plate-forme de mise en package avec le logiciel VDA installé et en ajoutant la machine de mise en package à un catalogue provisionné manuellement dans Studio, ce type d’accès peut être pris en charge.

Création d’une couche de plate-forme

Pour la création de la couche de plate-forme, il faut se souvenir de quelques points :

  • Pour Citrix Provisioning, le logiciel de la machine cible est installé sans exécuter l’assistant de création d’image, puis redémarré
  • L’installation des pilotes de périphériques Citrix VDA et Citrix Provisioning se fait dans la couche Platform
  • La jointure de domaine est effectuée dans la couche de plate-forme, ce qui signifie que plusieurs couches de plate-forme peuvent être créées pour prendre en charge différents domaines
  • La couche de plate-forme est également la couche de priorité la plus élevée, de sorte que certains composants facultatifs peuvent être installés, y compris les logiciels SSO tels que Imprivata, les outils d’Hypervisor pour les hyperviseurs alternatifs et Citrix Workspace Environment Management Agent.

Pour en savoir plus sur la création de la couche de plate-forme, consultez l’article CTX225997.

Couche d’application

Les couches d’application sont utilisées pour mettre en package la plupart des applications Les couches d’application contiennent des objets de système de fichiers et de registre pour une application ou un groupe d’applications. Lors de la création ou de la modification d’une couche, une machine d’packaging est créée dynamiquement et toutes les modifications apportées au système de fichiers et au registre sont capturées sur cette machine. La machine d’emballage contient la couche OS et toutes les couches d’application prérequises incluses. Un deuxième disque virtuel appelé disque de package est attaché à la machine packaging en tant que volume inscriptible. Ce disque capture toutes les modifications du système de fichiers lors de l’packaging, et il contient également une ruche de registre (appelée ruche RSD) utilisée pour capturer toutes les modifications du registre. Lorsque la machine d’packaging est finalisée, seul le disque du package est téléchargé. La disquette de démarrage est supprimée.

Pour en savoir plus sur la création et la modification des couches d’application, consultez la documentation du produit.

La plupart du temps, les applications sont installées avec la même configuration que celle que l’administrateur pourrait normalement utiliser pour le système d’approvisionnement pris en charge. Lors de la création de couches d’application, il est toujours important de s’efforcer de désactiver les mises à jour automatiques. Parce que l’administrateur ne souhaite généralement pas que les applications soient mises à jour automatiquement après le déploiement. Citrix a documenté le processus de superposition pour quelques applications courantes. Ces « Recettes » App Layering peuvent être trouvées sur le lien suivant.

Référence : Recettes App Layering

Couches élastiques

Elastic Layering est une méthode permettant de déployer dynamiquement l’application sur une session virtuelle lors de l’ouverture de session de l’utilisateur en montant des couches stockées en tant que fichiers VHD sur un partage SMB et en les intégrant dans le système de fichiers à l’aide du système de fichiers composite Citrix (CFS). Elastic Layering est géré sur le VDA par Citrix Layering Service. Elastic Layer Repository est un partage SMB qui contient à la fois les fichiers VHD de couches et les fichiers de configuration JSON utilisés pour définir les attributions de couches pour le Layering Service. Le Layering Service lit les fichiers de configuration, puis monte les fichiers VHD des couches à l’aide d’un appel SDKWindows.

Toutes les applications ne sont pas prises en charge par la technologie Elastic Layering car les couches élastiques sont montées lors de l’ouverture de session. Les exigences d’application suivantes excluent l’utilisation des applications dans Elastic Layers :

  1. Applications dotées de pilotes du noyau
  2. Applications dont les services sont dépendants d’autres services de démarrage
  3. Applications qui modifient le magasin de pilotes Windows comme les pilotes d’imprimante tiers

Les applications répondant à ces exigences peuvent être superposées, mais les couches doivent être incluses dans l’image publiée.

Fichiers de configuration (JSON)

Comme indiqué précédemment, les attributions Elastic Layer sont définies dans un ensemble de fichiers .JSON stockés dans le référentiel Elastic Layer. Ces fichiers sont définis comme suit :

  • ElasticLayerAssignment.json : ce fichier contient des informations sur le mappage des utilisateurs et des groupes avec les couches d’application. Ce fichier contient une entrée pour chaque ID de groupe ou d’utilisateur auquel des applications ont été attribuées et, sous le SID de cet objet AD, les attributions de couches sont répertoriées.

  • Layers.json : ce fichier définit les couches du référentiel et les métadonnées relatives à la couche. Ce fichier est utilisé pour obtenir le chemin utilisé pour monter le disque dur virtuel.

  • MachineAssociations.json : comme son nom l’indique, il définit l’association de machines avec n’importe quel groupe AD, le format utilise des modèles de nom de machine contenant des caractères génériques pour associer un ensemble d’ordinateurs à un groupe AD défini. Lorsqu’un utilisateur ouvre une session sur une machine qui correspond au modèle, il reçoit les couches élastiques attribuées à ce groupe. Ces paramètres sont définis dans la console de gestion App Layering, dans la section Utilisateurs>Groupes.

Couche utilisateur

Les couches utilisateur offrent une expérience plus persistante aux utilisateurs tout en prenant en charge un modèle informatique de bureau partagé. Après le montage d’une couche utilisateur, la plupart des écritures système sont redirigées vers la couche utilisateur. Cette couche permet de prendre en charge les éléments suivants :

  • Les paramètres de profil et de données de chaque utilisateur sont stockés dans la couche utilisateur
  • Les applications installées par l’utilisateur sont prises en charge dans la couche utilisateur tant que les applications sont conformes aux règles autorisées par Elastic Layers

Les couches utilisateur sont attribuées une à une. Un utilisateur ne peut avoir qu’une seule couche inscriptible par couche de système d’exploitation et par domaine. L’utilisateur ne peut donc se connecter qu’à un seul groupe de mise à disposition ou pool avec un poste de travail utilisant la même combinaison de couche OS et de couche de plate-forme avec la couche utilisateur activée. Cette couche est créée en tant que disque virtuel sur un partage de fichiers lorsque l’utilisateur ouvre une session pour la première fois.

À partir de la version 1910, la couche utilisateur complète prend en charge la persistance de l’index de recherche entre les sessions. Pour ce faire, le service de recherche Windows est défini sur DISABLED (4) sur les VDA lorsqu’ils démarrent. Lorsque l’utilisateur ouvre une session sur le service Ulayer change le type de démarrage du service Windows Search par START_ON_DEMAND (3). Avant d’activer WSearch, le service ULayer doit également s’assurer que les paramètres de registre « crawl-scope » de l’indexeur sont corrects. L’étendue d’analyse est un ensemble de clés de Registre qui déterminent les zones des données de l’utilisateur à indexer. Les entrées dans le crawl-scope proviennent des valeurs par défaut intégrées à l’image de base, mais peuvent également provenir des couches élastiques et des paramètres de couche de persistance de l’utilisateur. Ces entrées sont traitées au moment de l’ouverture de session pour fournir l’ensemble complet des emplacements de portée d’analyse, et il y a des frais généraux modestes mais mesurables à construire pour chaque ouverture de session. Pour éviter cette surcharge, le service ULayer génère une chaîne de hachage pour représenter le déploiement de l’image de base (par exemple, l’instance BIC) et les attributions de couches élastiques, et stocke cette chaîne dans le fichier \ Program Files \ Unidesk \ Etc \ UserLayer.json de l’utilisateur sous le nom « IndexerHash ». Lors des ouvertures de session suivantes, cette chaîne est comparée à l’indexERhash recalculé et seulement quand elles diffèrent est la portée d’exploration reconstruite.

Les types de couches utilisateur suivants peuvent être utilisés :

  • Complet : toutes les données, paramètres et applications installées localement d’un utilisateur sont stockés dans leur couche utilisateur
  • Office 365 : seuls les données et paramètres Outlook de l’utilisateur sont stockés sur leur couche utilisateur. Les index de recherche sont recréés à chaque ouverture de session.
  • Session Office 365 : Seuls les données et paramètres Outlook de l’utilisateur sont stockés sur leur couche utilisateur. Les index de recherche sont recréés à chaque ouverture de session.

Remarque : En cas d’utilisation de la couche Office 365, il est recommandé d’utiliser Citrix Profile Management pour conserver les paramètres Outlook.

La taille maximale par défaut d’une couche utilisateur est de 10 Go. Cette taille peut être modifiée en définissant un quota pour le partage de la couche utilisateur. Il est également possible de remplacer la taille maximale de la couche utilisateur par défaut à l’aide d’une entrée de registre sur les VDA. Pour modifier la taille maximale par défaut, ajoutez le remplacement de registre suivant,

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE: <Size in GB>

Partage de couches élastique et partages de couches utilisateur

Les couches élastiques sont des fichiers VHD montés par un système d’exploitation client ou serveur sur le réseau de machines virtuelles. Les couches élastiques sont montées en lecture seule et de nombreuses machines peuvent monter le même fichier VHD. Le serveur de fichiers ou le partage utilisé pour Elastic Layers est optimisé pour les E/S de lecture.

Les couches utilisateur sont des couches élastiques inscriptibles. La couche utilisateur est montée en lecture/écriture par un seul bureau. Le serveur de fichiers ou le partage utilisé pour les couches utilisateur sont optimisés pour les E/S en écriture. Lors de l’utilisation des couches utilisateur, les performances du stockage sont essentielles à l’expérience utilisateur. Les baies de stockage Flash sont fortement recommandées pour le partage de la couche utilisateur.

L’architecture des couches élastiques est largement évolutive. Le chemin du référentiel de partage Elastic Layer est défini dans le registre HKLM de la machine virtuelle pour les charges de travail VDI et RDS. Cette conception permet d’avoir un nombre illimité de réplicas pour répartir la charge.

AL-Image-8

Le référentiel Elastic Layer et les partages de couches utilisateur sont définis dans l’appliance. Le partage Elastic Layer est défini dans la section Système > Paramètres et configuration. Ce chemin d’accès peut être modifié sur les VDA à l’aide de la stratégie de groupe en modifiant les valeurs de registre suivantes :

HKLM\SOFTWARE\Unidesk\ULayer\RepositoryPath

Value = \\Server\Share

Pour les implémentations VDI volumineuses, cette valeur de Registre permet d’utiliser plusieurs référentiels Elastic Layer pour différents ensembles de bureaux. Pour en savoir plus sur la modification du référentiel Elastic Layer dans le registre sans créer de nouvelle image, consultez l’article CTX222107de Citrix.

L’emplacement utilisé pour les couches utilisateur est attribué par le groupe Active Directory et est donc également très évolutif car autant de partages que vous le souhaitez peuvent être utilisés. Ces affectations sont définies sous Système>Emplacements de stockage.

Pour plus d’informations sur l’architecture du partage Elastic Layers, consultez la section Disponibilité, sauvegarde et récupération.

Partage de fichiers de couche utilisateur

Lors du processus de connexion, lorsqu’une image est configurée pour les couches utilisateur, le fichier VHD de la couche utilisateur est créé lors de la première connexion de l’utilisateur après avoir été affecté à l’image. Les paramètres de partage de la couche utilisateur sont définis dans l’appliance par le groupe Active Directory. Si un utilisateur fait partie de plusieurs groupes avec des partages de couche utilisateur attribués, il existe un ordre de priorité pour le partage et son fichier de couche utilisateur créé sur le partage de priorité la plus élevée. Les disques User Layer ne peuvent être utilisés que sur une seule machine à la fois.

Les couches utilisateur sont liées à la fois au domaine et à la couche OS du bureau auquel vous êtes connecté. Le chemin d’accès à une couche utilisateur particulière comme suit :

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

Les couches utilisateur sont gourmandes en écriture. Il est recommandé d’utiliser un partage de fichiers optimisé pour les écritures. Si le partage de couche utilisateur est différent du partage de couche élastique, l’affectation des utilisateurs définie par les groupes d’utilisateurs AD.

AL-Image-9

L’attribution de couche utilisateur est définie dans la section System>Storage Emplacements dans la console App Layering. Saisissez le partage et le groupe associé au partage.

Pour plus d’informations sur l’architecture du partage Elastic Layers, consultez la section Disponibilité, sauvegarde et récupération.

Intégration d’App Layering

La section suivante décrit l’intégration de Citrix App Layering aux systèmes de provisionnement et aux hyperviseurs.

Citrix App Layering et Citrix Provisioning Services

App Layering est facile à intégrer à Citrix Provisioning (PVS). L’intégration est facilitée par l’installation de l’agent App Layering sur un ou plusieurs serveurs PVS. L’agent fournit la connectivité entre l’appliance et Provisioning Services.

AL-Image-10

Le diagramme précédent illustre la publication d’images en couches à l’aide de Citrix Provisioning. Les images sont gérées et distribuées de manière centralisée pour le déploiement en les publiant à partir de l’appliance App Layering sur un serveur Citrix Provisioning. Plusieurs architectures peuvent être créées pour prendre en charge Citrix Provisioning. L’architecture la plus utilisée consiste à intégrer un seul serveur PVS de production utilisé comme point d’intégration. Les disques virtuels sont ensuite téléchargés sur le magasin du serveur PVS par l’agent App Layering lors de la publication de l’image. L’agent utilise le service Windows BITS pour effectuer le transfert.

Lorsque des images sont publiées, il est possible de configurer les scripts Connector PowerShell pour qu’ils s’exécutent sur l’image après le téléchargement de l’image. Lors de l’utilisation de cette fonctionnalité, si les scripts nécessitent beaucoup de processeur, il est conseillé d’utiliser un serveur Provisioning Server « pré-intermédiaire » qui n’est pas utilisé pour effectuer la diffusion en continu. De cette façon, la publication et le traitement des scripts n’affectent pas négativement les fonctions de streaming de la batterie de services de Provisioning. Pour prendre en charge cette conception, il s’agit du moyen le plus simple de créer une ferme Citrix Provisioning « DEV » avec un seul serveur. Ce serveur « DEV » peut également être utilisé pour diffuser des images de test. Une fois l’image testée, le disque virtuel peut être répliqué sur la batterie de production Citrix Provisioning pour des tests et un déploiement supplémentaires.

Pour en savoir plus sur ce type de script, consultez l’exemple de script suivant de l’article CTX226060du support Citrix.

Lorsqu’une image est publiée dans Citrix Provisioning, elle est nommée en fonction du nom du modèle d’image avec une date et un horodatage pour la gestion des versions. Les disques virtuels sont gérés dans Provisioning Services de la même manière qu’ils pourraient être gérés sans App Layering. Le versionnement n’est pas utilisé lorsque App Layering est utilisé. Au lieu de cela, chaque fois qu’une nouvelle image est publiée, un disque virtuel complet est créé avec un nouvel horodatage. Si une modification urgente de l’image est nécessaire, la gestion des versions de Citrix Provisioning peut être utilisée pour modifier rapidement l’image. Ensuite, le même changement peut être ajouté à la couche appropriée après que le problème a été rapidement résolu.

Impact d’Elastic Layering sur les disques de cache Citrix Provisioning

Citrix Provisioning utilise de la mémoire réservée et un disque cache attaché localement pour stocker temporairement les modifications du système de fichiers local au cours d’une session. Lors de l’utilisation d’App Layering et de Citrix Provisioning, la taille des disques de cache doit être plus importante que sans App Layering. Chaque fois qu’un fichier est ouvert, pour une opération d’écriture à l’aide d’App Layering, le fichier entier est copié dans le volume inscriptible de la machine virtuelle afin de pouvoir être modifié. Fait également copier l’intégralité du fichier dans le cache disque alors que Citrix Provisioning ne copie normalement que les blocs modifiés dans le cache.

AL-Image-11

Le diagramme ci-dessus illustre les écritures sur le disque cache avec et sans le pilote de filtre de App Layering installé dans les cibles Provisioning Server. Pour en savoir plus sur la mise en cache avec Elastic Layers, consultez l’article CTX227454.

Couche utilisateur et disque cache de Citrix Provisioning

Lorsque les couches utilisateur sont utilisées, seul le disque cache Provisioning est utilisé avant qu’un utilisateur ouvre une session.

AL-Image-12

Dans ce cas, le disque de partition accessible en écriture local n’est utilisé que pendant le démarrage. Une fois qu’un utilisateur s’est connecté, toutes les nouvelles modifications de fichiers sont redirigées vers le disque de la couche utilisateur sur le partage de fichiers et non vers le disque virtuel diffusé en continu, ce qui signifie que le cache Provisioning ne voit plus les E/S sur la partition inscriptible.

Services de création de machines et de Citrix App Layering

Pour publier des images en couches sur Machine Creation Services, un connecteur Machine Creation Services créé pour l’hyperviseur sur lequel est publié. La configuration Connector inclut les informations d’identification du compte de service utilisées pour accéder à l’Hypervisor, en plus des hôtes, des emplacements de stockage, des modèles, etc.

Le connecteur est ensuite utilisé pour publier une image en couches en tant que machine virtuelle « Image principale » sur l’hyperviseur.

AL-Image-13

Le connecteur MCS démarre l’image principale après sa publication et exécute tous les scripts de couche définis dans n’importe quel calque. Une fois tous les scripts exécutés, l’image principale doit être arrêtée et l’hyperviseur prend un instantané de la machine virtuelle. Une fois ce processus terminé, l’image principale peut être déployée à l’aide de Machine Creation Services. Le nom de la machine virtuelle est similaire à celui de Citrix Provisioning. La machine virtuelle est nommée en tant que nom du modèle d’image publié suivi d’un horodatage. Lorsqu’une nouvelle version de l’image est publiée, il s’agit d’une nouvelle machine virtuelle. La nouvelle machine virtuelle est ensuite utilisée pour mettre à jour le catalogue existant afin de déployer les modifications. Lors de l’utilisation de MCS, il est important que le modèle utilisé pour créer les images principales ait été créé à partir d’une véritable machine virtuelle. La machine a été démarrée sous Windows et le fuseau horaire est réglé correctement. Cette tâche permet de s’assurer que le BIOS virtuel est correctement configuré. Si cette tâche n’est pas effectuée, l’image démarrée résultante est décalée de quelques heures en fonction de l’UTC. La meilleure façon de créer le modèle est d’utiliser un clone de l’image Gold originale utilisée pour créer la couche OS. Cette étape garantit que les paramètres du matériel virtuel correspondent de la couche du système d’exploitation à l’image principale.

Prise en charge multiplateforme de Citrix App Layering

L’architecture Citrix App Layering est conçue pour prendre en charge de nombreux hyperviseurs et systèmes de provisionnement sans créer de couches spécifiques à une plate-forme. Au fur et à mesure que de nombreuses entreprises évoluent vers des environnements cloud multicloud ou hybrides, Citrix App Layering facilite cette migration.

AL-Image-14

App Layering prend en charge plusieurs plates-formes sur plusieurs hyperviseurs avec la combinaison de connecteurs et de Platform Layers.

Connecteur App Layering - Les connecteurs App Layering sont développés dans node.js et exécutés à partir de l’appliance App Layering. Les connecteurs offrent une intégration à toutes les plates-formes prises en charge, y compris les hyperviseurs et les systèmes de Provisioning.

Couche de plate-forme — Cette couche est similaire à une couche d’application, sauf qu’elle a toujours la priorité la plus élevée et, lors de la publication d’images, les « recettes » de nettoyage sont exécutées différemment par rapport aux couches de plate-forme que les couches d’application. Les couches de plate-forme sont là où les pilotes logiciels sont installés pour une « Plateforme » définie. Par exemple, lors de l’utilisation de Citrix Provisioning, le logiciel VDA et le logiciel PVS sont tous deux installés dans la couche Platform Layer.

Les connecteurs App Layering et les couches de plate-forme sont combinés pour prendre en charge les plates-formes disponibles. Pour en savoir plus sur les détails et les configurations du déploiement des multiples hyperviseurs et des plateformes cloud, consultez la documentation du produit.

Flux de communication de couches d’applications

App Layering utilise peu de connexions et de ports. Ces flux de communication sont documentés ci-dessous. Pour plus d’informations sur les communications et les exigences, consultez la documentation du produit .

Appliance App Layering

La console de gestion App Layering est une console Microsoft Silverlight accessible via TCP/IP sur le port 80 (HTTP) ou 443 (HTTPS).

Accès aux appareils de gestion

Protocole Port
HTTP 80
HTTPS 443
SSH 22
Téléchargement du journal 8888

Outre HTTP et HTTPS, les administrateurs peuvent accéder à la machine virtuelle de l’appliance App Layering directement à l’aide de SSH sur le port 22. L’accès n’est pas autorisé sur les ports Telnet ou FTP non sécurisés. SSH est utilisé pour ouvrir une session à l’appliance en tant que « root » pour un accès complet et un compte « administrateur » est utilisé pour accéder à un menu limité permettant de configurer les paramètres réseau. Dans Azure, « root » et « administrateur » sont tous les deux désactivés. Au lieu de cela, les administrateurs sont invités lors de la mise en service de l’appliance pour un compte d’utilisateur administratif local.

Lors de l’exportation des journaux depuis la console de gestion, un lien de téléchargement est généré et présenté dans les détails de la tâche. Le port 8888 est utilisé pour télécharger les journaux.

Le port 8161 est utilisé pour la gestion et la configuration d’ActiveMQ, mais l’accès à ce port n’est disponible qu’à partir de l’appliance App Layering.

L’appliance App Layering peut éventuellement vérifier les mises à niveau et les télécharger depuis les serveurs Citrix via Internet via HTTPS/443 ou HTTP/80. Les sites www.citrix.com et cdn.citrix.com sont accessibles si une connexion Internet est disponible.

Configuration du Connector

Chaque type de connecteur utilise un port différent. La liste actuelle des connecteurs est la suivante :

Connecteur port HTTP Port HTTPS Ports internes
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

Les connecteurs s’ouvrent sur une page Web distincte dans la console de gestion. Chaque connecteur possède un port d’écoute HTTP et HTTPS. Lorsqu’un connecteur est ouvert, l’administrateur est redirigé vers une interface HTML5 dans un nouvel onglet. Le navigateur de l’administrateur doit pouvoir accéder à l’appliance App Layering sur les ports répertoriés ci-dessus pour chaque connecteur.

Ports divers

L’appliance App Layering communique avec divers serveurs et services réseau sur leurs ports respectifs. L’appliance App Layering se connecte aux services suivants sur les ports TCP suivants :

Destination Protocole Port
Serveur Active Directory LDAPS (LDAP sur SSL) 636
Serveur Active Directory LDAP 389
Serveur Active Directory DNS 53
Serveurs de fichiers Windows SMB 445
Serveurs de temps réseau NTP 123
Serveur DHCP DHCP UDP/67
Appliance App Layering DHCP UDP/68

Le service d’agent

Le service d’agent peut être utilisé pour trois fonctions distinctes :

  • Intégration avec Citrix Provisioning
  • Intégration avec Hyper-V
  • Intégration avec un serveur de script général

Le service d’agent est accessible sur les ports suivants.

Serveur de l’agent Destination Fonction ou protocole Port
Tous Appliance App Layering Enregistrement ou HTTPS 443
Tous Serveur de l’agent Commandes de l’appliance App Layering ou de SOAP 8016
Tous Appliance App Layering Exportation du journal 8787
Citrix Provisioning Appliance App Layering Téléchargement sur disque ou HTTP 3009
Citrix Provisioning Appliance App Layering Téléchargement sur disque ou HTTPS 3509

Lors de l’installation initiale de l’agent App Layering, le programme d’installation ouvre une connexion sur le port 443 à l’appliance App Layering pour enregistrer le serveur d’agent. L’appliance App Layering stocke le nom de domaine complet et le nom abrégé de l’hôte du service d’agent, et le registre sur le serveur d’agent contient un enregistrement de l’appliance App Layering.

Une fois que l’agent et l’appliance App Layering ont échangé des identités, l’appliance App Layering communique directement avec le service de l’agent sur un canal SOAP sécurisé sur le port 8016. La plupart des communications entre l’appliance et l’agent fonctionnent comme suit :

Hôte Action
Appliance App Layering Bonjour à l’agent sur le port 8016
Appliance App Layering Demande de commande à l’agent ouverte
Agent Exécute une commande PowerShell en tant que compte d’utilisateur configuré
Agent Transmet la réponse à l’appliance App Layering sur le canal de demande existant
Agent Au revoir

Les détails de la commande envoyée sont souvent visibles dans le journal Connector de l’appliance App Layering ou dans le fichier applayering.agent.log sur le serveur Agent Service.

Lorsque l’appliance est invitée à générer un ensemble de journaux, elle transmet une demande à tous les services d’agent qui ont déjà été enregistrés sur l’appliance demandant des journaux à l’agent. Chaque service d’agent génère son propre ensemble de journaux et le transmet à l’appliance App Layering sur le port 8787.

La fonction principale du service Agent est de transférer des fichiers vers Citrix Provisioning ou Hyper-V. Lors du transfert de fichiers, l’agent utilise le service BITS (Background Intelligent Transfer Service) sur le serveur du service de l’agent pour extraire le disque virtuel vers le serveur et le placer dans le magasin ou charger ou télécharger un disque dur virtuel à partir d’Hyper-V.

Le processus de transfert d’un fichier fonctionne comme suit :

Hôte Action
Appliance App Layering Bonjour à l’agent sur le port 8016
Appliance App Layering Demande de commande pour le téléchargement de fichiers
Agent Exécute BITS en tant que compte utilisateur configuré
MÈCHES Ouvre une connexion au connecteur Citrix Provisioning sur le port 3009 de l’appliance App Layering
MÈCHES Télécharge le fichier vers l’emplacement de référentiel spécifié
Appliance App Layering Commande pour obtenir l’état du transfert
Agent Interroge BITS pour connaître l’état et en fait rapport à l’appliance App Layering
MÈCHES Finitions
Agent Signale l’état complet à l’appliance App Layering

Normalement, le transfert de fichiers s’exécute sur le port 3009, qui n’est pas crypté. Cette communication est effectuée pour des raisons de performances : les frais liés à l’exécution d’une connexion HTTPS ont un impact significatif sur le débit. Toutefois, l’agent peut être configuré pour forcer HTTPS et utiliser 3509 à la place.

Lorsque l’agent exécute BITS, il fournit deux éléments BITS : l’URL pour le téléchargement du fichier et le chemin du fichier de destination. BITS est exécuté en tant que compte utilisateur configuré dans le connecteur. Par conséquent, cet utilisateur a besoin d’autorisations pour établir une connexion sortante du serveur Provisioning vers le port 3009 de l’appliance App Layering, ainsi que des droits pour écrire un fichier dans le magasin de disques virtuels.

Hyperviseurs

Les connecteurs d’hyperviseur utilisent les ports suivants.

Connecteur Destination Port
Azure et Hyper-V Gestion Azure 443
Citrix Hypervisor Citrix Hypervisor 5900
vSphere Centre virtuel 443
vSphere Hôtes ESX pour les transferts de disques 443
Nutanix Nutanix CVM 9440

Ces ports sont les mêmes que les consoles de gestion basées sur le navigateur de l’Hypervisor utilisent également. App Layering utilise des appels d’API bien définis via le service Web normal de l’hyperviseur pour les communications avec l’hyperviseur.

Pour les téléchargements de fichiers vSphere et les téléchargements ne sont pas effectués en communiquant avec vCenter. Et géré par une communication directe avec un hôte ESXi. Pour cette raison, les connecteurs vSphere nécessitent la définition d’un hôte et le pare-feu hôte doit être configuré pour autoriser l’accès à partir de l’appliance de App Layering sur le port 443.

Moteurs de composition

Les moteurs de composition se connectent à l’App Layering Appliance pour les connexions iSCSI sur le port 3260 et effectuent des appels d’API vers l’appliance sur le port 443. L’App Layering Appliance effectue des appels d’API aux moteurs de composition également sur le port 443.

Disponibilité, sauvegarde et restauration

App Layering peut comporter plusieurs composants pour lesquels les sauvegardes sont appropriées, notamment l’appliance, Elastic Layer Shares et User Layer Shares.

Remarque :

Bien que cette section décrit la disponibilité des agents de connexion, la récupération et la disponibilité de votre infrastructure VDI Broker ne sont pas abordées ici. Reportez-vous à la documentation et à l’équipe d’assistance de votre logiciel broker de connexion de bureau pour plus d’informations sur leurs options de récupération.

Toute stratégie de disponibilité pour App Layering doit s’intégrer à la conception globale de la disponibilité et de la récupération de l’ensemble de votre solution Workspace. Les pools et les groupes de mise à disposition sont déjà hautement disponibles car ils sont répartis entre les hôtes et les pools de stockage.

Le stockage peut être rendu hautement disponible de différentes manières. Une méthode courante consiste à utiliser une baie de stockage avec un degré élevé de redondance, y compris plusieurs processeurs ou têtes de stockage et la technologie RAID. Cependant, il est également possible d’obtenir une plus grande disponibilité en utilisant le stockage local basé sur un contrôleur RAID local et des disques flash sur chaque hôte, et en répartissant les machines gérées entre les hôtes. Si un hôte tombe en panne pour quelque raison que ce soit, d’autres hôtes s’exécutent avec des machines gérées issues du pool de postes de travail disponibles pour récupérer les sessions utilisateur.

Les réseaux peuvent également être facilement disponibles car les hyperviseurs sont conçus en tenant compte de la disponibilité. Mais il est important de s’assurer que vous disposez d’au moins deux chemins réseau disponibles pour chaque machine gérée de votre environnement.

Les composants spécifiques à App Layering sont l’appliance, Elastic Layers et User Layers.

Sauvegardes d’appareils

Comme indiqué précédemment, l’appliance App Layering n’est pas requise pour que les utilisateurs finaux puissent utiliser pleinement App Layering. Par conséquent, il n’est pas nécessaire de rendre l’appliance hautement disponible. Cependant, il doit être considéré comme une obligation de sauvegarder régulièrement l’appareil. Les sauvegardes de l’appliance garantissent que toutes les couches sont disponibles même si l’appliance est détruite ou endommagée. Toute technologie de sauvegarde de machine virtuelle peut être utilisée pour l’appliance App Layering. Il est également possible d’utiliser deux appliances et la fonction d’importation et d’exportation pour les synchroniser. Cependant, cette étape est désormais un processus manuel.

Disponibilité et reprise après sinistre pour les couches élastiques

Les couches Elastic sont des fichiers montés sur des agents de bureau virtuel (VDA) lors de l’ouverture de session à l’aide d’un montage invité Windows à partir d’un partage SMB. Le service de couches connecte les couches lors de l’ouverture de session, mais il ne reconnecte jamais un fichier VHD déconnecté. Par conséquent, il est essentiel de s’assurer que le serveur de fichiers utilisé pour Elastic Layers est hautement disponible en utilisant un certain type de système de fichiers en cluster. L’utilisation de plusieurs cibles DFS-R n’est pas suffisante pour ce cas d’utilisation, car si une cible tombe en panne, les fichiers VHD montés ne peuvent pas être remappés sur une autre cible tant qu’une autre ouverture de session n’a pas eu lieu.

Pour la récupération après sinistre, il existe deux modèles qui peuvent être utilisés pour gérer les couches élastiques : un modèle de réplication ou un modèle de double appliance.

Modèle de réplication

Dans ce modèle, les partages Elastic Layer peuvent être répliqués en utilisant n’importe quelle technologie de réplication de système de fichiers. Ce modèle peut inclure des technologies telles que DFS-R, Microsoft Storage Replica, Veeam, la réplication des fournisseurs NAS, Zerto, VMware vSphere Replication et même robocopy.

AL-Image-15

Ensuite, les VDA du centre de données de reprise après sinistre peuvent être pointés vers le partage Elastic Layer dans ce centre de données via l’objet de stratégie de groupe. Un modèle d’objet de stratégie de groupe pour configurer l’emplacement du référentiel peut être trouvé ici : CTX222107.

Modèle de double appliance

Dans ce modèle, une appliance est installée dans chaque centre de données. La fonctionnalité d’importation et d’exportation fournie par l’appliance est utilisée pour maintenir la synchronisation des deux appliances du point de vue de la couche. Ici, les administrateurs gèrent les couches de reprise après sinistre séparément et créent des images en reprise après sinistre à partir d’une appliance locale.

AL-Image-16

Si cette option est sélectionnée, la synchronisation transfère sur le WAN à partir du partage SMB défini lors de l’importation et de l’exportation. Ensuite, les couches doivent être attribuées sur l’appliance DR pour les copier sur le partage Elastic Layer dans DR. Dans ce modèle, il est également possible de développer une solution qui ne synchronise pas toutes les couches mais uniquement les couches souhaitées. Étant donné que les couches sont sélectionnées pour l’exportation manuellement, seules les couches sélectionnées peuvent être incluses dans le processus. Actuellement, le processus d’importation et d’exportation doit être lancé manuellement.

Dans le modèle à double appliance, les connecteurs et les autorisations pour les partages Elastic doivent être créés de chaque côté. Les seuls objets importés sont les calques eux-mêmes. Cependant, il est possible dans ce modèle d’avoir différentes couches sur chaque site selon les besoins. Par exemple, s’il s’agit vraiment d’un scénario de site actif-actif.

Disponibilité et reprise après sinistre pour les couches utilisateur

Les couches utilisateur sont similaires aux couches Elastic en ce sens qu’il s’agit de fichiers VHD montés par Windows lors de l’ouverture de session à l’aide d’un montage en invité. Cependant, ils sont montés en écriture et les fichiers sont verrouillés par le bureau Windows. Cette tâche rend les options de sauvegarde et de réplication de ces disques beaucoup plus difficiles que les couches élastiques normales.

En raison de cette limitation, en cas d’utilisation du DFS-R ou d’un script robocopy, le processus de synchronisation doit être effectué en dehors des heures de travail (s’il y a des heures considérées comme des heures creuses). Le processus doit constamment vérifier si les fichiers sont disponibles pour la synchronisation. Pour les couches utilisateur, qui peuvent être des fichiers volumineux, Robocopy peut ne pas fonctionner correctement car il peut toujours copier le fichier entier plutôt que les blocs qui ont été modifiés. Le DFS-R est peut-être un meilleur choix car il copie uniquement les blocs modifiés. Cependant, la réplication au niveau du stockage peut être encore meilleure car elle peut se synchroniser de manière plus uniforme à mesure que des modifications sont apportées au lieu d’attendre la suppression des verrous de fichiers.

D’autres options sont également prises en charge ici en fonction de la technologie choisie pour stocker les fichiers VHD de la couche utilisateur. Si le serveur de fichiers prend en charge le service VSS (Volume Shadow Copy Service), des snapshots VSS sont créés pour permettre la sauvegarde et la réplication des couches utilisateur. En faisant varier la fréquence du processus, les couches utilisateur peuvent également être restaurées à des points antérieurs si une corruption ou une erreur est commise qui nuit à l’utilisateur.

Si un contrôleur de stockage prend en charge NDMP, cette fonctionnalité peut également être utilisée pour les sauvegardes de la couche utilisateur. NDMP fonctionne au niveau du stockage pour sauvegarder le stockage NAS directement sur disque ou sur bande à l’aide de snapshots NAS.

En raison de la difficulté de répliquer des disques volumineux et des dépenses liées à la bande passante, de nombreux clients choisissent de fournir des postes de travail DR aux utilisateurs ne disposant pas d’une couche utilisateur répliquée. Dans ce modèle, il existe deux options. Les utilisateurs peuvent être approvisionnés dans un groupe de mise à disposition distinct dans le site de reprise après sinistre qui est également activé pour la couche utilisateur. Ils peuvent ensuite se connecter au site de reprise après sinistre et préconfigurer cette couche avec ce dont ils ont besoin. Les utilisateurs peuvent également être approvisionnés à l’aide d’un bureau de reprise après sinistre normal non persistant. Dans ce dernier cas, il est souvent avantageux de mélanger Citrix Profile Management avec la couche utilisateur afin que les paramètres utilisateur puissent être répliqués sur le site de reprise après sinistre.

Reprise après sinistre multisite par composants

L’approche de la reprise après sinistre multisite est similaire à celle de la reprise locale. Pour les images, vous devez utiliser un processus de réplication. Si vous utilisez Citrix Provisioning, vous pouvez utiliser Robocopy pour copier vos vDisks sur le site secondaire. Si vous utilisez Machine Creation Services ou Horizon View sur vSphere, vous avez besoin d’un processus de réplication des machines virtuelles telles que Veeam, Zerto, VMware vSphere Replication ou Site Recovery Manager. Cela permet également de protéger l’ELM.

Pour les couches Elastic, la réplication SAN ou une copie scriptée fonctionnent toutes deux. Si vous utilisez des couches utilisateur, vous devez répliquer au niveau du SAN/NAS afin que les blocs modifiés puissent être répliqués sous le système de fichiers en cluster utilisé pour le partage.

Cette approche est préférable à la définition de plusieurs connecteurs dans l’ELM et à la publication directe sur les deux sites car, lors de la publication, vous devez à la fois composer l’image et la télécharger dans le magasin. Si vous utilisez un processus qui réplique l’image déjà créée, cela ignore le processus de composition et est plus efficace.

Remarque :

si vous souhaitez une configuration différente pour les images déployées pour la reprise après sinistre, il est préférable de publier directement à partir de l’ELM. Cela vous permet de définir différents calques dans les modèles d’image pour la récupération.

Il est également possible d’utiliser deux appareils ELM, un sur chaque site. Ensuite, vous pouvez utiliser la fonctionnalité d’exportation/importation pour garder ces ELM synchronisés du point de vue de la couche. Vous pouvez ensuite traiter la récupération séparément et y créer des images à partir d’un ELM local.

AL-Image-17

Si vous choisissez cette option, la synchronisation est transférée via le WAN vers le partage SMB défini dans Paramètres. Les couches peuvent ensuite être synchronisées avec le partage SMB utilisé dans le second site, à l’aide de Robocopy avec le commutateur /MIR. Actuellement, le processus d’importation et d’exportation doit être lancé manuellement.

Vous pouvez également synchroniser uniquement les calques souhaités plutôt que tous les calques. Si cette option peut vous intéresser, contactez l’architecte de votre solution App Layering pour plus de détails.

Dans le modèle Dual ELM, les connecteurs et les autorisations pour Elastic Shares doivent être créés de chaque côté. Les seuls objets importés sont les calques réels. Cependant, il est possible dans ce modèle d’avoir différentes couches sur chaque site selon les besoins.

Sources

L’objectif de cette architecture de référence est de vous aider à planifier votre propre implémentation. Pour faciliter cette tâche, nous aimerions peut-être vous fournir des diagrammes sources que vous pouvez adapter dans vos propres conceptions détaillées et guides de mise en œuvre : diagrammes sources .

Références

Les ressources suivantes sont référencées pour une meilleure compréhension de Citrix App Layering :

Documentation produit App Layering

Comment créer une couche de plate-forme

Comprendre la superposition élastique

Optimisations de Windows et de la App Layering

Guide de l’antivirus App Layering

Comprendre la recette Office

Meilleures pratiques pour la App Layering

Architecture de référence : App Layering

Dans cet article