Citrix App Layering

Public

Ce document s’adresse aux professionnels techniques, aux décideurs informatiques, aux partenaires et aux intégrateurs de systèmes. Cela permettra à l’administrateur d’explorer et d’adopter Citrix App Layering pour faciliter la gestion des images et des applications à leurs 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, reportez-vous à l’architecture de référence sur CitrixTech Zone.

Objectif du présent document

Ce document fournit une vue d’ensemble technique, des concepts architecturaux pour la gestion et la fourniture d’applications à l’aide des technologies Citrix App Layering. Ce document inclut à la fois le fonctionnement App Layering et l’intégration avec Citrix Virtual Apps and Desktops sur différentes plates-formes.

Vue d’ensemble des Citrix App Layering

Citrix App Layering est une solution flexible pour fournir 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.

L目的是主要de Citrix应用程序分层desimplifier 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 indépendamment des hyperviseurs sous-jacents ou de l’infrastructure cloud.

Le système d’exploitation et les applications sont séparés en unités gérables discrètes. 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 en tant que disque virtuel contenant des fichiers et des entrées de Registre pour une couche spécifique. Il existe deux façons 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 des systèmes de provisionnement 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, reportez-vous aul’architecture de référencedocument.

• 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 à des images standardisées.

Séparer les applications et la personnalisation du système d’exploitation fournit une solution flexible et facile à gérer pour la gestion des images non persistantes.

Pourquoi Citrix App Layering

Citrix App Layering fournit une solution économique pour gérer un ensemble complexe d’applications dans plusieurs environnements avec des exigences d’emballage différentes. Presque toutes les applications incorporées avec des pilotes de noyau, des systèmes d’exploitation et des dépendances de services 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 des images unique qui prend en charge les modèles de Provisioning utilisés avec Citrix et les hyperviseurs tiers. La gestion et les mises à niveau des applications pour les images sont simplifiées sans modification directe ni imagerie inversée des images.

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

• Découple les applications et les systèmes de Provisioning de l’image :Citrix App Layering sépare l’emballage de l’image. Dans la gestion d’image normale, les mises à jour d’une image sont effectuées séparément pour chaque image. L’utilisation de App Layering d’un calque peut faire partie de nombreuses images. Pour mettre à jour toutes les images, le calque sera mis à jour une fois et les images seront régénérées. Les mises à niveau vers des composants tels que les outils d’Hypervisor, les Virtual Delivery Agents (VDA) et les outils de 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. En raison de, les deux modes App Layering pour le déploiement de la couche d’application 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 à une opération d’écriture de bureau la plupart passe dans la couche utilisateur. Il permet à un utilisateur d’installer des applications et d’enregistrer les paramètres de configuration qui sont en dehors du profil utilisateur. En outre, il stocke les fichiers de données de l’utilisateur en rendant leur bureau semble être persistant avec les avantages d’un modèle de bureau partagé.

• Réduit le nombre d’images requises :弹性分层可以reduire considerablement勒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 couches d’application Citrix

App Layering est un ajout important à la gamme de technologies Citrix qui offre de nombreux avantages énumérés ci-dessus. 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 de besoins des utilisateurs. Lors de l’utilisation d’une technologie de Provisioning basée sur des images, le respect de ces exigences nécessite souvent un grand nombre d’images à gérer. Ces images doivent prendre en charge différents groupes d’utilisateurs ou différents ensembles d’applications conflictuelles. Souvent, il y a aussi un certain chevauchement dans les applications déployées sur chaque image.

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

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 corrigé, le patch est créé sur la couche du système d’exploitation une fois et toutes les images qui utilisent la couche du système d’exploitation mises à jour par l’appliance de 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.

当弹性分层ajoute, il egalement possible de réduire considérablement le nombre d’images requises. Elastic Layer permet aux administrateurs de fournir dynamiquement des applications lors de la connexion. Pour les applications qui ne sont pas utilisées par tout le monde, les couches élastiques permettent 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 Azure

De nombreuses entreprises se déplacent vers un environnement multicloud hybride mélangeant des ressources locales et infonuagiques 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é.

Normalement, une configuration mixte d’Hypervisor et de cloud hybride obligerait les administrateurs à maintenir plusieurs ensembles d’images et d’applications différents sur plusieurs plates-formes de gestion différentes. Avec la technologie App Layering, le même système d’exploitation et les mêmes applications utilisés sur site peuvent être poussés vers le cloud ou vers un autre Hypervisor avec peu ou pas de travail supplémentaire.

Pour comprendre, sur la fonctionnalité multiplateforme de couches d’applications, reportez-vous à la sectionSupport multiplateforme Citrix App Layeringci-dessous.

3- Portabilité de l’hyperviseur pour la migration

Les entreprises sont souvent « coincées » avec la technologie d’un fournisseur simplement parce qu’il serait extrêmement coûteux de migrer vers une nouvelle technologie. 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.

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 organisations ont plusieurs utilisateurs qui nécessitent un niveau élevé de persistance sur les postes de travail. Y compris les utilisateurs de puissance dans n’importe quel groupe, développeurs, ingénieurs, architectes, etc. Les couches utilisateur de couches d’applications offrent une grande persistance sur une architecture de bureau groupée.

La couche utilisateur est montée à l’ouverture de session et toutes les écritures ultérieures sur le bureau sont écrites dans 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.

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 comme Citrix Profile Management Outlook Container ou FSlogix Profile ou Office 365 Container gèrent l’OST Outlook et les index d’une manière beaucoup plus ciblée afin que la quantité d’E/S gérée par le conteneur soit beaucoup plus petite. 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

一个尿布是联合国disque virtuel contenant les膜集成电路hiers et les entrées de Registre qui sont modifiés ou ajoutés pendant l’empaquetage. À l’exception de la première version de la couche Système d’exploitation, les couches sont créées par l’appliance App Layering intégrée à l’Hypervisor. Un administrateur crée une couche, l’appliance provisionne dynamiquement une machine de conditionnement avec un disque de démarrage et un disque de couche. Lorsque la machine d’emballage démarre, toutes les modifications sur la machine d’emballage sont écrites dans le disque de la couche. Une fois l’empaquetage terminé, ce disque est copié 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 les différents types de couches suivants :

• Couches du système d’exploitation
• Couches de plate-forme
• Couches d’application
• Couches utilisateur complètes

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 courtier, le système de Provisioning et les outils de l’Hypervisor si l’Hypervisor est différent de l’Hypervisor par défaut. La couche de plate-forme est également la couche de priorité la plus élevée et parfois le logiciel est installé ici afin qu’il soit compilé à la plus haute priorité.

Couches d’application :type de couche principal. Utilisé pour la plupart des logiciels d’application.

Couches utilisateur :couche élastique (voir section suivante) accessible en écriture. Les couches utilisateur sont montées à l’ouverture de session et une fois montées, presque toutes les écritures de bureau vont à la couche utilisateur. Cette couche permet aux utilisateurs de personnaliser considérablement leur expérience VDI même s’ils utilisent un modèle de bureau partagé.

Appliance de Citrix App Layering

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

L’appliance App Layering est déployée en tant que machine virtuelle dans le centre de données où l’empaquetage des applications et la publication des images ont lieu. L’appliance App Layering est construite sur CentOS, configurée avec 4 vCPU et 8 Go de RAM. Ces paramètres ne doivent pas être modifiés car la solution matérielle-logicielle est conçue pour fonctionner dans cette configuration.

La solution matérielle-logicielle 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 si nécessaire si plus d’espace est nécessaire.

盟课程du突起de创建de尿布et depublication 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 le stockage des couches élastiques.

La solution matérielle-logicielle est utilisée uniquement pour gérer les calques, les images et les affectations de couche élastique. Les Virtual Desktops de travail virtuels et les serveurs d’applications virtuelles n’interfacent pas directement avec l’appliance. Lorsqu’une couche est affectée de manière élastique, la solution matérielle-logicielle copie la couche dans le partage Elastic Layer. Le partage contient ces fichiers VHD ainsi qu’un ensemble de fichiers JSON qui fournissent les affectations de couche aux utilisateurs.

L’appliance Citrix App Layering héberge également la console de gestion App Layering. Le déploiement de l’appliance App Layering constitue la première étape du processus d’installation. Après l’installation de la solution matérielle-logicielle, 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, reportez-vous à la sectiondocumentation produit.

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

• Créer et gérer des couches Système d’exploitation, Plateforme et Application
• Créer des modèles d’image publiés
• Publier et蒙古包les图像en couches
• Attribuer une App Layering aux rôles d’administrateur aux utilisateurs
• 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 d’packaging et de publication évoluent bien mieux et grâce aux avantages des technologies utilisées, les performances du processus sont également significativement 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 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 façons. Dans le cadre d’une image publiée où l’appliance App Layering combine toutes les couches en un seul fichier disque et télécharge ce fichier vers le système de Provisioning ou où les couches sont montées lors de l’ouverture de session et mises à la disposition des utilisateurs dynamiquement.

Image publiée :Ici, un système d’exploitation, une plate-forme et un ensemble de couches Application sont combinés en un seul fichier disque qui est publié dans 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 dans les fichiers à partir des couches Application un à la fois dans l’ordre de priorité où plus la couche est récente, plus sa priorité est élevée et enfin écrire dans la couche 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 affectées aux utilisateurs par l’appartenance à un groupe Active Directory et attachées pendant ou légèrement après l’ouverture de session. Les couches élastiques sont dynamiques, ce qui permet aux administrateurs de personnaliser l’expérience utilisateur tout en réduisant le nombre d’images.

Connecteurs et configurations de connecteurs

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

Il existe deux types de connecteurs : Hypervisor et Provisioning :

• Lesconnecteurs d’Hypervisorfournissent le mécanisme d’interface avec un hyperviseur. Actuellement, il existe des connecteurs d’hyperviseur pour Citrix Hypervisor, vSphere, Hyper-V, Nutanix AHV, Azure et Azure Gov.

• Lesconnecteurs système de Provisioningpermettent à l’administrateur de publier une image sur le système de provisioning. Actuellement, il existe Provisioning System Connector pour Citrix Provisioning, Citrix Machine Creation Services sur chaque hyperviseur et Horizon View.

一个单独的解决方案materielle-logicielle我们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 de connecteur définissent les paramètres nécessaires à l’intégration avec l’Hypervisor ou le système de Provisioning. 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 nécessaire à l’interface 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 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 de système d’exploitation
• Création de calques et de versions de calques
• Publiez des images en couches dans un Hypervisor 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 des connecteurs

Types de connecteurs

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

Connecteurs hyperviseur

Les connecteurs d’hyperviseur sont utilisés lors de la création de calques ou de l’importation d’une image Gold pour créer le calque du système d’exploitation. Les connecteurs hyperviseurs lors de l’empaquetage créent dynamiquement une machine de conditionnement sur le stockage et l’hôte définis par la configuration du connecteur. Une connexion Hypervisor peut également être utilisée pour créer une machine virtuelle dans l’Hypervisor.

Citrix Provisioning

Le connecteur Citrix Provisioning s’intègre à un agent de 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 de connecteur doit être un compte de domaine avec l’autorisation d’administrateur dans PVS.
2. Le compte de service de connecteur doit également être un administrateur local sur le serveur Citrix Provisioning.
3. Un agent de 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 vers les 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’Hypervisor. Le connecteur MCS est presque identique aux connecteurs de l’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 qu’elle ne soit déployée par MCS. L’arrêt de l’image principale et un instantané de la 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 Agent défini sur la configuration du connecteur. Cette étape est le plus souvent utilisée avec Citrix Provisioning, mais elle peut être utilisée avec n’importe quel autre connecteur de publication en installant l’Agent de couche d’application sur un système Windows pour exécuter des scripts sur une image publiée. Copiez les scripts sur l’ordinateur sur lequel l’agent est installé. Ce script s’exécute après un déploiement réussi d’une image en couches. Pour utiliser cette fonctionnalité, avec une image principale sur un Hypervisor, le script doit également interfacer avec la plate-forme de gestion de l’Hypervisor. Par exemple, pour vSphere, le script doit 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, reportez-vous aux articles de support suivantsCTX226060etCTX226062.

Modèles d’image publiés

Lors de l’utilisation de App Layering, les couches du système d’exploitation, de la plate-forme et de l’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 Provisioning cible. Par exemple, dans le cas où les administrateurs publient sur Citrix Provisioning, l’appliance crée un disque dur virtuel et le télécharge sur le serveur de Provisioning défini en tant que disque virtuel. Dans le cas où 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 machine virtuelle 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, Plateforme 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 l’image a Elastic Layering activé 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 le versioning. Cependant, 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 de App Layering

L’agent Citrix App Layering fournit des 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 la solution matérielle-logicielle sur le serveur de l’agent. Ce transfert est initié à partir de l’agent à l’aide de BITS et le fichier est téléchargé à partir de l’appliance.

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

Référence :Installer l’agent

Active Directory

L’appliance de App Layering se connecte à Active Directory pour les authentifications à l’appliance et l’attribution d’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)
• Affectation de la couche élastique et utilisateur

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 de répertoire, reportez-vous à la sectiondocumentation produit.

Couches

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

Couche OS

Une couche de système d’exploitation est une couche qui contient le système d’exploitation Windows. Il est une pratique de référence d’inclure tous les composants qui seraient mis à jour avec Windows Update dans la couche du système d’exploitation afin que tous soient mis à jour par Windows Update. 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 pour cette raison.

Il est préférable de ne pas installer d’applications utilisateur final dans la couche OS car toutes les couches d’application réalisées avec une couche OS particulière sont liées à cette couche OS. Si une application est installée dans la couche du système d’exploitation, chaque image utilisant cette couche pour inclure cette application entraîne 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 la clé pour limiter le nombre d’images du système d’exploitation à gérer. Même les applications avec des pilotes, des services et des périphériques noyau sont prises en charge dans les couches d’application et n’ont pas besoin d’être incluses dans la couche du système d’exploitation.

Pendant, 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’Hypervisor de l’Hypervisor principal sont installés dans la couche du système d’exploitation. L’Hypervisor où la plupart des emballages sont effectués
• Les outils d’Hypervisor pour les hyperviseurs alternatifs sont installés dans la couche de plate-forme pour cet Hypervisor
• Installer les composants .NET (à partir de Microsoft) et les mises à jour dans la couche du système d’exploitation
• Si Microsoft Runtimes sont 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’il puisse être mis à jour avec Windows Update
• Dans le cas où un utilisateur local ou un groupe 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) capturé à partir de la couche du système d’exploitation

Référence :Créer 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 couche de plate-forme peuvent être créés :

Publishing Platform Layer :Ce类型de平台层允许d通过罗技ciel requis par un système de Provisioning cible, un courtier et un Hypervisor. Par exemple, une couche de plate-forme de publication pour prendre en charge Provisioning Services sur vSphere for Citrix Virtual Apps possède le VDA Citrix et les pilotes de périphérique PVS installés. Si vSphere n’est pas le même Hypervisor où l’empaquetage est effectué, VMware Tools est également installé sur cette couche.

Couche de plate-forme d’emballage :莱斯沙发de plate-forme d 'emballage是utilisées si une couche d’emballage est nécessaire pour prendre en charge les machines d’emballage. Ces couches ne sont pas souvent nécessaires, mais il y a plusieurs cas où il faut être nécessaire, y compris :

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

2. Si l’accès à la machine d’emballage est requis à l’aide du logiciel VDA. Cette couche est le plus souvent requise lors de l’installation de pilotes pour les périphériques USB qui doivent voir le périphérique à installer correctement. En créant une couche de plate-forme de conditionnement avec le logiciel VDA installé et en ajoutant la machine de conditionnement à 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 quelques points à retenir :

• Pour Citrix Provisioning, le logiciel de la machine cible est installé sans exécuter l’Assistant Imaging, puis redémarré
• L 'installation des pilotes de périphériques Citrix VDA et Citrix Provisioning se fait dans la couche Platform Layer
• 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, reportez-vous à l’articleCTX225997.

Couche d’application

Les couches d’application sont utilisées pour empaqueter 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 de conditionnement 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 requises incluses. Un deuxième disque virtuel appelé Package Disk est attaché à la machine de conditionnement en tant que volume accessible en écriture. Ce disque capture toutes les modifications du système de fichiers pendant l’empaquetage, et il contient également une ruche de registre (appelée ruche RSD) utilisée pour capturer toutes les modifications du registre. Lorsque la machine de conditionnement est finalisée, seul le disque de 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’applications, reportez-vous à la sectiondocumentation produit.

La plupart du temps, les applications sont installées avec la même configuration que celle que l’administrateur utiliserait normalement pour le système de Provisioning qui prend en charge. Lors de la création de couches d’applications, il est toujours important de travailler pour 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. Theses App Layering « Recettes » peut être trouvé sur le lien suivant.

Référence :Solutions App Layering

Couches élastiques

弹性是一个分层方法permettant de deployer dynamiquement l’application sur une session virtuelle pendant l’ouverture de session de l’utilisateur en montant des couches stockées sous forme de 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 le service de couches Citrix. Le référentiel Elastic Layer est un partage SMB qui contient à la fois les fichiers VHD de couche et les fichiers de configuration JSON qui sont utilisés pour définir les affectations de couche pour le service de couches. Le service de couches lit les fichiers de configuration, puis monte les fichiers VHD de couche à l’aide d’unappel du SDKWindows.

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

1. 应用程序用des飞行员du果仁酒
2. Applications avec des services qui sont des dépendances pour d’autres services de démarrage
3. Applications qui modifient le magasin de pilotes Windows comme les pilotes d’imprimante tiers

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

Fichiers de configuration (JSON)

Comme indiqué ci-dessus, les affectations de couche élastique 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 utilisateur et groupe vers les couches d’application. Ce fichier contient une entrée pour chaque groupe ou ID utilisateur qui a affecté des applications et sous le SID de cet objet AD, les affectations de couche 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 d’accès utilisé pour monter le disque dur virtuel.

• MachineAssociations.json : Comme sonnom l’indique, il définit l’association de machine 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 affectées à ce groupe. Ces paramètres sont définis dans la console de gestion des App Layering dans lasection Utilisateurs > Groupes.

Couche utilisateur

Les couches utilisateur offrent une expérience plus persistante aux utilisateurs tout en prenant en charge un modèle d’informatique de bureau partagé. Après, une couche utilisateur est montée, 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 affectées un à un. Un utilisateur ne peut avoir qu’une seule couche accessible en écriture 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 en utilisant la même couche de système d’exploitation et la même combinaison de couche de plate-forme avec la couche d’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 « étendue d’analyse » 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. L’entrée dans le scope d’analyse provient des valeurs par défaut intégrées à l’image de base, mais peut également provenir des calques é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 ce surcoût, 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 affectations de couches élastiques, et stocke cette chaîne dans le fichier \ Program Files \ Unidesk \ Etc \ UserLayer.json de l’utilisateur en tant que « IndexHash ». 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 couche utilisateur. Il est également possible de remplacer la taille maximale par défaut de la couche utilisateur à 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:

Partage de couches Elastic Layer et Partage de couches utilisateur

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

Les couches utilisateur sont des couches élastiques accessibles en écriture. 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 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 VM HKLM pour les charges de travail VDI et RDS. Cette conception permet d’avoir un nombre illimité de réplicas pour répartir la charge.

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 sectionSystem>Settingsand Configuration. Ce chemin 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 recréation d’image, reportez-vous à l’article CitrixCTX222107.

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

Pour plus d’informations sur l’architecture du partage Elastic Layers, voir lasection Disponibilité, Sauvegarde et récupération.

Partage de fichiers de couche utilisateur

Au cours du processus de connexion, lorsqu’une image est configurée pour les couches utilisateur, le fichier VHD de couche utilisateur est créé lors de la première ouverture de session de l’utilisateur après avoir été affecté à l’image. Les paramètres de partage de couche utilisateur sont définis dans l’appliance par le groupe Active Directory. Si un utilisateur se trouve dans 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 machine à la fois.

Les couches utilisateur sont liées à la fois au domaine et à la couche OS du bureau 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.

L’attribution de couche utilisateur est définie dans la sectionSystem>Storage Emplacements在控制台应用程序分层。Entrez le分配等le groupe associé au partage.

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

Intégration App Layering

La section suivante décrit l’intégration de Citrix App Layering avec Provisioning Systems et Hyperviseurs.

Citrix App Layering et Citrix Provisioning Services

App Layering est facile à intégrer avec 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.

Le diagramme précédent illustre la publication d’images en couches à l’aide de Citrix Provisioning. Les images sont gérées de manière centralisée et distribuées pour le déploiement en les publiant à partir de l’appliance App Layering vers un serveur Citrix Provisioning. Plusieurs architectures peuvent être créées pour prendre en charge Citrix Provisioning. L’architecture la plus souvent utilisée consiste à intégrer un serveur PVS de production unique utilisé comme point d’intégration. Les disques virtuels sont ensuite téléchargés dans le magasin du serveur PVS par l’agent de App Layering lorsque l’image est publiée. L’agent utilise le service BITS Windows 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 les fonctions de diffusion en continu dans la batterie de serveurs Provisioning Services. Pour prendre en charge cette conception, il est le moyen le plus simple de créer une batterie de serveurs Citrix Provisioning « DEV » avec un seul serveur. Ce serveur « DEV » peut également être utilisé pour diffuser des images de test. Une fois que l’image a été testée, le disque virtuel peut être répliqué vers la batterie de serveurs Production Citrix Provisioning pour des tests et un déploiement ultérieurs.

Pour en savoir plus sur ce type de script, reportez-vous à l’exemple de script suivant de l’article de support CitrixCTX226060.

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 le seraient sans App Layering. La gestion des versions n’est pas utilisée lorsque App Layering est utilisée. À la place, chaque fois qu’une nouvelle image est publiée, un disque virtuel complet est créé avec un nouvel horodatage. Si une modification d’urgence de l’image est nécessaire, Citrix Provisioning versioning peut être utilisé 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 de App Layering et du Citrix Provisioning, la taille des disques de cache doit être supérieure à celle sans App Layering. Chaque fois qu’un fichier est ouvert, pour une opération d’écriture à l’aide de la couche d’application, le fichier entier est copié dans le volume accessible en écriture de la machine virtuelle afin qu’il puisse être modifié. Provoque le fichier entier est également copié dans le cache disque lorsque Citrix Provisioning copierait normalement uniquement les blocs modifiés dans le cache.

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 les couches élastiques, reportez-vous à l’articleCTX227454.

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.

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 fichier sont redirigées vers le disque User Layer sur le partage de fichiers et non vers le disque virtuel en continu, ce qui signifie que le cache Provisioning ne voit plus les E/S sur la partition accessible en écriture.

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

Pour publier des images en couches dans Machine Creation Services un connecteur Machine Creation Services créé pour l’Hypervisor en cours de publication. 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.

Le connecteur MCS学习'image主要以后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’Hypervisor prendra 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. La dénomination de la machine virtuelle est similaire à Citrix Provisioning. La machine virtuelle est nommée comme 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 pour 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 machine virtuelle réelle. La machine a été démarrée sous Windows et a le bon fuseau horaire défini. Cette tâche garantit que le BIOS virtuel est correctement configuré. Si cette tâche n’est pas effectuée, l’image amorçée obtenue a son temps d’arrêt 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 or originale utilisée pour créer la couche du système d’exploitation. 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 Citrix App Layering

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

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

App Layering Connector -Les App Layering Connectors sont développés dans node.js et exécutés à partir de l’application 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 multiples hyperviseurs et les détails et configurations de déploiement de plates-formes cloud, consultez ladocumentation 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, consultez ladocumentation produit.

Appliance App Layering

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

Accès à l’appliance de gestion

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

荒诞的HTTP和HTTPS, les administrateurs peuventccéder directement à la machine virtuelle de l’appliance App Layering à 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 du Provisioning de l’appliance pour un compte d’utilisateur administrateur local.

Lors de l’exportation de journaux à partir de 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 ActiveMQ, mais l’accès à ce port n’est disponible qu’à partir de l’appliance App Layering.

En option, l’appliance App Layering peut vérifier les mises à niveau et les télécharger à partir de serveurs Citrix via Internet à l’aide de HTTP/443 ou HTTP/80. m.giftsix.com et cdn.citrix.com sont accessibles si une connexion Internet est disponible.

Configuration du connecteur

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

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 en tant que page Web distincte dans la console de gestion. Chaque connecteur dispose à la fois d’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 s’adresse à 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 de l’agent

Le service 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 Agent est accessible sur les ports suivants.

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

Lors de l’installation initiale de l’agent de App Layering, le programme d’installation ouvre une connexion sur le port 443 à l’appliance de couches d’applications pour enregistrer le serveur d’agents. L’appliance de App Layering stocke le nom de domaine complet et le nom abrégé de l’hôte de service de l’agent, et le Registre sur le serveur de l’agent contient un enregistrement de l’appliance de 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 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	Hello à 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 requête existant
Agent	Au revoir

Les spécificités de la commande en cours d’envoi sont souvent visibles dans le journal du connecteur de l’appliance de App Layering ou dans le fichier applayering.agent.log sur le serveur de service de l’agent.

当materielle-logicielle est invi la解决方案té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 la solution matérielle-logicielle demandant des journaux à l’agent. Chaque service Agent génère son propre lot 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 Service Service Service Service Service de l’Agent pour extraire le disque virtuel vers le serveur et le placer dans le magasin ou télécharger ou télécharger un disque dur virtuel à partir d’Hyper-V.

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

Hôte	Action
Appliance App Layering	Hello à l’agent sur le port 8016
Appliance App Layering	Demande de commande pour le téléchargement de fichier
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 de App Layering
MÈCHES	Télécharge le fichier à l’emplacement du référentiel spécifié
Appliance App Layering	Commande pour obtenir l’état du transfert
Agent	interroge les BITS pour l’état et les rapports à l’appliance App Layering
MÈCHES	Finitions
Agent	Rapporte l’état complet à l’appliance App Layering

Normalement, le transfert de fichiers s’exécute sur le port 3009, qui n’est pas chiffré. Cette communication est effectuée pour des raisons de performances — la surcharge de l’exécution sur une connexion HTTPS a 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 du téléchargement du fichier et le chemin d’accès du fichier de destination. BITS est exécuté en tant que compte d’utilisateur configuré dans le connecteur. Par conséquent, cet utilisateur a besoin des autorisations pour établir une connexion sortante à partir du serveur Provisioning vers le port 3009 de l’appliance de App Layering, ainsi que des droits pour écrire un fichier dans le magasin de disques virtuels.

Hyperviseurs

Les connecteurs 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 disque	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 avoir plusieurs composants où les sauvegardes sont appropriées. Y compris la solution matérielle-logicielle, Elastic Layer Shares et User Layer Shares.

Sauvegardes de matériel

Comme indiqué précédemment, l’appliance de App Layering n’est pas requise pour que les utilisateurs finaux puissent utiliser pleinement les couches d’applications. Par conséquent, il n’est pas nécessaire de rendre l’appliance hautement disponible. Cependant, il doit être considéré comme une exigence de sauvegarde régulière de l’appareil. Les sauvegardes de l’appliance garantissent que toutes les couches sont disponibles même si la solution matérielle-logicielle 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 maintenant un processus manuel.

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

Les couches élastiques sont des fichiers montés sur des agents de bureaux virtuels (VDA) lors de la connexion à l’aide d’un montage in-guest 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 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 échoue, les fichiers VHD montés ne peuvent pas être remappés vers une autre cible tant qu’une autre ouverture de session n’aura pas 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.

Référence :Guide des concepts de disponibilité et de récupération de l’App Layering 4.x

Modèle de réplication

Dans ce modèle, les partages Elastic Layer peuvent être répliqués à l’aide de 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.

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 se trouve 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 permet de synchroniser les 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.

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 affectées à l’appliance DR les copie vers 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 être exportées 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, des connecteurs et des autorisations pour les partages élastiques doivent être créés de chaque côté. Les seuls objets importés sont les couches réelles elles-mêmes. Cependant, dans ce modèle, il est possible d’avoir différentes couches dans chaque site selon les besoins. Par exemple, s’il s’agit vraiment d’un scénario de site actif.

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

Les couches utilisateur sont similaires à Elastic Layers en ce qu’il s’agit de fichiers VHD montés par Windows lors de l’ouverture de session à l’aide d’un montage in-guest. 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, dans le cas où DFS-R ou un script robocopy est utilisé, le processus de synchronisation doit être effectué pendant les périodes creuses (si des heures sont considérées comme périodes creuses). Le processus doit constamment vérifier si les fichiers sont disponibles à synchroniser. Pour les couches utilisateur, qui peuvent être des fichiers volumineux, la robocopy ne fonctionnerait pas bien car elle copierait toujours le fichier entier plutôt que les blocs qui ont changé. DFS-R serait un meilleur choix car il ne copie que les blocs modifiés. Cependant, la réplication au niveau du stockage serait encore meilleure car elle se synchroniserait plus uniformément à mesure que des modifications sont apportées plutôt que d’attendre la suppression des verrous de fichiers.

Il existe d’autres options qui sont prises en charge ici, en fonction de la technologie choisie pour stocker les fichiers VHD User Layer. Si le serveur de fichiers prend en charge le service VSS (Volume Shadow Copy Service), les instantanés VSS sont créés pour permettre la sauvegarde et la réplication des couches utilisateur. En variant la fréquence du processus, les couches utilisateur peuvent ensuite être annulées à des points antérieurs dans le temps si une corruption ou une erreur est faite qui affecte négativement l’utilisateur.

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

En raison de la difficulté de répliquer des disques volumineux et du coût de la bande passante, de nombreux clients choisissent de fournir des postes de travail de reprise après sinistre pour les utilisateurs sans couche utilisateur répliquée. Dans ce modèle, il y a deux options. Les utilisateurs peuvent bénéficier d’un groupe de mise à disposition distinct dans le site de reprise après sinistre qui est également activé par 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. Ou les utilisateurs peuvent être provisionnés avec l’utilisation d’un poste de travail 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.

Référence :Sauvegarde et restauration Citrix App Layering

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 vous fournir des diagrammes source que vous pouvez adapter dans vos propres conceptions détaillées et guides de mise en œuvre :diagrammes source.

Références

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

Documentation du produit App Layering

Comment créer une couche de plate-forme

Présentation des couches élastiques

Guide des concepts de disponibilité et de récupération des couches d’applications

Optimisations des couches Windows et des applications

Guide antivirus App Layering

Comprendre la recette Office

Meilleures pratiques en matière App Layering