Architecture de référence : Citrix DaaS - AWS

Public et objectif

Ce document est destiné à aider les partenaires et les clients Citrix à comprendre les décisions de conception les plus critiques nécessaires pour déployer avec succès les technologies de virtualisation Citrix sur le cloud public d’Amazon. Il ne s’agit pas d’une référence pratique. Citrix prend en compte ces guides de déploiement, et ils sont désormais fournis et gérés séparément des architectures de référence. Dans ce document, nous utilisons Citrix Architectural Design Framework pour organiser et présenter les principales pratiques, recommandations et modèles de conception utilisés par Citrix et certains partenaires de conseil Citrix.

Vue d’ensemble et résumé

Les technologies de virtualisation et de mise en réseau Citrix répondent avec succès aux besoins des petites et grandes entreprises depuis près de trois décennies. Ces technologies peuvent être sous licence, déployées, intégrées et gérées de plusieurs façons. Cette flexibilité permet aux technologies Citrix de répondre à différents cas d’utilisation, types d’entreprise, exigences d’intégration et modèles opérationnels différents. Ce document est rédigé à l’intention du client ou du partenaire Citrix qui envisage ou envisage de déployer ces technologies sur l’infrastructure de cloud public d’AWS.

Pour les clients existants qui souhaitent moderniser leur infrastructure et les nouveaux clients qui souhaitent déployer les technologies de virtualisation et de mise en réseau Citrix, plusieurs décisions clés de haut et de bas niveau doivent être prises en cours de route pour faciliter un déploiement réussi. Pour aider les clients et les partenaires à comprendre ces points de décision, nous avons introduit et défini une terminologie spécifique pour définir le contexte approprié, puis nous avons utilisé ce contexte pour mettre en évidence les décisions critiques et les implications à prendre en compte dans la planification de votre déploiement.

Nous commençons par définir deux modèles d’adoption technologique principaux : Customer Managed et Cloud Services. Nous décomposons ensuite les composants d’un système de virtualisation Citrix en plusieurs sous-systèmes et les classons par modèle d’adoption :

Modèle d’adoption/ Fonction de sous-système	Gestion du client (installé à partir des fichiers binaires téléchargés)	Service Cloud (fourni via Citrix Cloud)
Courtage et administration des sessions	Citrix Virtual Apps and Desktops (CVAD)	Citrix DaaS (DaaS)
Services d’interface utilisateur	Citrix StoreFront	Citrix Workspace (le service, consommé via l’application Citrix Workspace ou le navigateur Web)
Authentification	Citrix StoreFront (plus NetScaler ADC/Gateway pour la plupart des cas d’utilisation)	Citrix Workspace (plus NetScaler ADC/Gateway pour certains cas d’utilisation)
Proxy de session HDX	NetScaler ADC/passerelle	Citrix Gateway Service

Nous prenons position pour les services cloud, en recommandant que la plupart des organisations utilisent ou prévoient d’utiliser les services cloud lorsque cela est possible. Nous n’offrons pas ce stand aveuglément - même si nous croyons que les services cloud, en fin de compte, offrent des avantages extrêmement positifs pour nos clients, nous reconnaissons que toutes les organisations/déploiements ne sont pas en mesure d’utiliser les services cloud pour tous les sous-systèmes aujourd’hui. Parfois, les exigences relatives aux cas d’utilisation (avec des attributs techniques ou des lacunes dans un service cloud actuellement disponible/spécifique) nécessitent l’adoption d’une combinaison de services cloud et d’un composant géré par le client : nous nous concentrons sur ces éléments dans ce document. Dans d’autres cas, des éléments non techniques (stratégies, considérations budgétaires et contractuelles, insuffisances de préparation au cloud, considérations de réglementation et de conformité, etc.) peuvent décourager l’utilisation des services cloud. Dans ces cas, nous vous recommandons de travailler avec votre partenaire Citrix, les ventes/équipe d’ingénierie pour les surmonter. Dans le reste de ce document, nous mettons tout en œuvre pour identifier les capacités, fonctionnalités ou attributs clés qui aident les clients à choisir le modèle d’adoption à utiliser pour quel sous-système et quand.

Ensuite, nous définissons et examinons trois scénarios de déploiement communs, en soulignant quel modèle d’adoption est utilisé pour chaque sous-système :

• Greenfield/Cloud uniquement  : utilise les services cloud pour tous les sous-systèmes de virtualisation Citrix, ainsi que les services de cloud public AWS.
• Hybride (à ne pas confondre avec un « cloud hybride ») - le modèle de déploiement le plus courant, le modèle hybride utilise le DaaS pour le courtage et l’administration de sessions, avec des options de service cloud et gérées par le client pour les sous-systèmes restants.
• Lift and Shift  : comme son nom l’indique, ce modèle utilise CVAD, StoreFront et ADC/Gateway existants gérés par le client et migre ces composants vers AWS en l’état ou les installe dans AWS dans le cadre d’une migration de charge de travail vers les services de cloud public AWS. Bien qu’il s’agit d’un modèle de déploiement valide pour certains cas d’utilisation spécifiques, il comporte des mises en garde importantes.

Enfin, nous utilisons le Citrix Architectural Design Framework bien documenté pour organiser et présenter les principales décisions de conception à prendre en compte lors du déploiement de la technologie de virtualisation Citrix sur AWS. Pour plus de clarté, nous nous concentrons sur « ce qui est différent de Citrix sur AWS », en fournissant des liens vers d’autres ressources pour obtenir des informations plus détaillées si nécessaire.

Nous recommandons finalement à la plupart des clients d’utiliser le modèle de déploiement hybride dès le premier jour, en utilisant le service CVAD pour le courtage et l’administration des sessions. Cela fournit au client les fonctionnalités clés nécessaires pour exécuter à moindre coût un système de virtualisation Citrix sur AWS, réduit considérablement le coût et la complexité, fournit l’accès aux dernières fonctionnalités et fonctionnalités disponibles et simplifie la migration et l’utilisation d’autres services cloud dans le l’avenir. Les services cloud OU les composants gérés par le client peuvent être utilisés pour les sous-systèmes restants (en fonction des besoins spécifiques des clients), bien que nous recommandons aux clients d’indiquer clairement pourquoi ils utilisent des composants gérés par le client et d’avoir un plan pour passer à des services cloud à l’avenir une fois les services cloud répondre à leurs besoins spécifiques.

Pour plus d’informations sur les pratiques de pointe pour Citrix sur AWS, les lecteurs peuvent consulter les articles suivants du Guide Cloud :

• Pratiques de pointe pour Citrix Cloud sur AWS - Partie 1
• Pratiques leaders pour Citrix Cloud sur AWS - Partie 2
• Pratiques leaders pour Citrix Cloud sur AWS - Partie 3

Concepts clés et scénarios de déploiement

Dans cette section, nous décrivons certains concepts clés et scénarios de déploiement avant de nous plonger dans des considérations spécifiques pour chaque couche de Citrix Architectural Design Framework.

Modèles d’adoption des technologies

La technologie Citrix DaaS peut être « consommée » ou mise en œuvre de différentes manières. Les méthodes les plus courantes peuvent être décrites en général comme Services gérés par le client et Cloud. Il convient également de mentionner un troisième modèle - Partner Managed. Nous décrivons ce modèle ici pour plus de clarté, mais du point de vue de la conception architecturale, les deux premiers sont les plus pertinents.

Pourquoi discuterons-nous des modèles d’adoption technologique dans une architecture de référence ? Le choix du modèle d’adoption ou de consommation a un impact considérable sur la conception du système, les capacités, le coût et la délimitation des responsabilités de gestion. Cette section définit et explore ces modèles et fournit des conseils généraux pour aider les clients à faire des choix éclairés lors de la conception d’un système de virtualisation Citrix.

Géré par le client

Pendant de nombreuses années, les entreprises souhaitant consommer la technologie n’avaient pas d’autre choix que d’acheter, d’installer, de configurer et de maintenir l’ensemble de la pile technologique nécessaire à la création d’un système de virtualisation Citrix. Le logiciel de virtualisation de Citrix n’était disponible qu’en tant que fichiers binaires installables. Les clients qui ont acheté le logiciel de virtualisation Citrix téléchargeaient ces fichiers binaires (souvent sous la forme d’une image disque ISO téléchargeable ou d’exécutables auto-extractibles) puis installent, configurent et maintiennent eux-mêmes le logiciel. Le logiciel Citrix (et le matériel de mise en réseau) a été le plus couramment installé dans/sur l’infrastructure que le client possédait et maintenait, dans les centres de données qu’ils possédaient et maintenaient.

Conceptuellement parlant, un système de virtualisation Citrix est composé de différents composants Citrix, dont beaucoup sont décrits en détail dans cet article. Ils nécessitent également différentes couches de composants tiers qui doivent être fournis avant de pouvoir faire quoi que ce soit avec les bits Citrix. En fin de compte, ils se réunissent pour créer un système de virtualisation Citrix fonctionnel. Par souci de clarté, ce document désigne ce modèle d’adoption technologique sous le nom de Customer Managed. Nous utilisons ce terme pour décrire différents composants d’un système de virtualisation Citrix, y compris les composants tiers requis dans les couches situées sous, à côté et « au-dessus » des composants Citrix. Ce modèle peut également être appelé « Autogéré. »

Aujourd’hui, les clients ont des alternatives convaincantes à un modèle d’adoption géré par le client, mais certains adoptent encore des éléments de leur pile technologique en utilisant ce modèle pour diverses raisons. Bien que ce modèle offre aux clients le plus de contrôle sur chaque composant, il a un coût : le client assume la responsabilité de gérer et de maintenir le composant, y compris la sécurisation, l’exploitation, l’application des correctifs, la mise à niveau et le maintien d’une haute disponibilité. Ce modèle est également couramment déployé pour les systèmes « air gapped » (ceux qui n’ont pas accès à Internet et sont donc limités dans leur capacité à utiliser les services cloud, auxquels on accède couramment et en toute sécurité sur les réseaux publics).

Voici un exemple de l’architecture d’un système de virtualisation Citrix qui utilise des composants 100% gérés par le client déployés sur AWS à l’aide de services IaaS de base AWS tels que Elastic Compute Cloud (EC2) et Virtual Private Cloud (VPC) Networking. Nous discutons de certains détails de cette architecture dans les sections ultérieures de ce document, bien que vous puissiez immédiatement remarquer les similitudes avec le modèle de déploiement vert/cloud, beaucoup plus simple :

Schéma 1 : Déploiement Lift/Shift 100% géré par le client utilisant AWS en tant que

Services cloud

Au cours des 15 dernières années, les progrès technologiques dans de nombreux domaines ont donné naissance à des clouds publics à grande échelle, à des services cloud sophistiqués, à des architectures de microservices, à des cadres de livraison DevOps et agiles, à des modèles de licence par abonnement et à des logiciels et systèmes « persistants ». Ces progrès ont révolutionné la façon dont la technologie est acquise, adoptée, livrée et maintenue dans presque toutes les industries du monde.

Aujourd’hui, de nombreux composants ou couches qui composent un système de virtualisation Citrix sont disponibles « en tant que service. » Contrairement au modèle d’adoption géré par le client (où les clients achètent la technologie en tant qu’actif de l’entreprise et construisent ou entretiennent eux-mêmes des systèmes), les clients « s’abonnent » à divers services, et le fournisseur de services assume la responsabilité de la prestation et de la gestion de ces services. Ces services sont souvent consommés sur des réseaux publics (c’est-à-dire Internet), ce qui conduit certains à appeler ce modèle d’adoption de « Service Cloud » ou de « Service Web ». Dans cet article, nous allons parler de ce type de modèle d’adoption sous le nom de « Services gérés dans le cloud », ou simplement de modèle de « Cloud Service ».

Citrix propose un grand nombre de ses produits traditionnels « en tant que service », en utilisant les dernières avancées technologiques de ses partenaires de plateforme pour simplifier et rationaliser l’adoption, accélérer le rythme de l’innovation, améliorer la qualité et offrir plus de valeur ajoutée à ses clients au fil du temps. Citrix appelle cette plateforme de prestation de services « Citrix Cloud », et elle représente l’état actuel et futur de Citrix.

Voici un exemple de l’architecture d’un système qui utilise des composants de service 100% cloud pour un système de virtualisation Citrix sur AWS. Nous discutons des détails de cette conception dans une section ultérieure de ce document :

Schéma 2 : 100 % des services cloud sur AWS avec AWS Managed Services

Géré par les partenaires

Alors que de nombreuses entreprises choisissent de créer leur propre système de virtualisation Citrix, certains clients cherchent à se retirer de la gestion informatique afin qu’ils puissent concentrer leurs ressources et leur attention sur le service de leurs propres clients et marchés. Pour servir ces clients, Citrix travaille avec des partenaires d’intégration qui utilisent les technologies Citrix pour fournir un service de « produits finis » à leurs clients.

La définition et la différenciation des différents partenaires/types et offres d’intégration disponibles sont hors du champ d’application du présent document. Toutefois, les partenaires Citrix font face aux mêmes choix que les clients lorsqu’ils conçoivent un système de virtualisation Citrix. Le partenaire Citrix peut choisir d’utiliser un ou plusieurs services de Citrix Cloud, ou choisir de créer et de gérer certains composants du système en fonction des besoins spécifiques de ses clients. Ainsi, les conseils fournis dans ce document sont pertinents à la fois pour le partenaire Citrix et ses clients, pour différentes raisons.

Composants du système de virtualisation Citrix

Pour comprendre les implications des décisions de conception que nous détaillons plus loin dans ce document, nous allons placer les composants d’un système de virtualisation Citrix dans des « compartiments » de niveau supérieur que nous utiliserons ensuite pour guider votre processus décisionnel. Chaque système de virtualisation Citrix, quelle que soit la façon dont il est déployé et sous licence, a besoin de ces composants disponibles pour fonctionner et offrir la meilleure expérience utilisateur et la plus sécurisée. Il n’est pas rare que les clients combinent et combinent des composants autogérés et des services cloud, en particulier s’ils ont des exigences complexes en matière de cas d’utilisation, des exigences d’intégration de tiers ou des besoins extrêmes de contrôle ou de disponibilité.

Le tableau suivant met en lumière ces éléments clés pour plus de clarté. Les détails et recommandations sur l’endroit où vous utiliseriez une option par rapport à une autre sont abordés plus loin dans ce document :

Modèle d’adoption/ Fonction de sous-système	Gestion du client (installé à partir des fichiers binaires téléchargés)	Service Cloud (fourni via Citrix Cloud)
Brokering et administration de session - Le cœur de tout système de virtualisation Citrix : sans ce sous-système principal, vous n’avez pas d’application ou de bureau, et vous ne pouvez pas les gérer ! Ce sous-système est l’endroit où vous définissez, provisionnez et mettez à jour les catalogues de machines (collections d’instances Citrix Virtual Delivery Agent ou VDA VM). C’est également là que vous créez des groupes de mise à disposition, attribuez des applications/postes de travail aux utilisateurs et administrez l’environnement et les sessions utilisateur.	CVAD - Citrix Virtual Apps and Desktops, version LTSR (LTSR) ou version actuelle (CR). Si vous installez et configurez un Delivery Controller dans votre environnement, c’est ce que vous exécutez. Cela signifie également que vous installez et gérez votre propre infrastructure Microsoft SQL Server. Les fonctions administratives d’un déploiement CVAD (géré par le client) incluent Citrix Director et Citrix Studio. Vous pouvez les installer, les configurer et les gérer vous-même à l’aide de binaires LTSR/CR. Director nécessite également l’infrastructure Microsoft SQL Server. Les licences Citrix font également partie de ce sous-système, avec les clients installation/configuration/gestion des serveurs de licences Citrix et des fichiers de licences.	DaaS : Citrix DaaS, fourni via Citrix Cloud. Si vous vous connectez à Citrix Cloud et que vous installez et enregistrez Cloud Connector dans votre environnement, vous utilisez ce service Citrix Cloud. Vous installez et enregistrez Cloud Connector sur une instance Windows que vous gérez, puis Citrix les conserve en permanence et disponibles. Citrix Cloud fournit et gère également la plupart des fonctionnalités administratives via un navigateur Web via la console Citrix Cloud. Cela inclut les versions de service cloud de Citrix Studio et Citrix Director. Il n’y a pas d’infrastructure supplémentaire pour le client à gérer, à maintenir à haute disponibilité ou à mettre à jour les correctifs et les mettre à jour : Citrix est responsable de cette responsabilité administrative.
Services d’interface utilisateur (interface utilisateur)  : les applications Citrix Workspace natives (et les navigateurs Web pour un accès sans client) se connectent finalement à une URL. Le sous-système derrière l’URL est configuré par les administrateurs informatiques pour répondre aux exigences de l’entreprise en matière d’authentification et pour présenter des applications/postes de travail virtualisés, des applications SaaS et peut-être bien plus encore pour les utilisateurs.	Citrix Storefront. Également installé/configuré à partir de binaires CVAD LTSR ou CR, ce rôle offre une flexibilité extrême pour les scénarios de déploiement les plus complexes. Généralement déployé par paires, avec des instances NetScaler ADC/Gateway devant elles pour une haute disponibilité. Peut agréger et présenter des applications et des bureaux à partir d’environnements gérés/négociés par le client (CVAD) et d’environnements gérés/négociés (DaaS) Citrix Cloud.	Citrix Workspace (le service, pas l’application Citrix Workspace). Fait sous la forme d’un service cloud via Citrix Cloud, et inclut de nombreuses fonctionnalités de nouvelle génération uniquement disponibles avec ce service. Peut agréger et présenter des applications et des bureaux à partir d’environnements gérés/négociés par le client (CVAD) et d’environnements gérés/négociés (DaaS) Citrix Cloud.
Authentification - Dans ce contexte, nous faisons référence à la façon dont les utilisateurs s’authentifient avant d’accéder aux applications/postes de travail virtualisés Citrix, aux fichiers, aux applications SaaS, etc. L’authentification dans un environnement Citrix est généralement configurée au niveau de la couche de services d’interface utilisateur, bien que NetScaler ADC/Gateway puisse également être utilisée pour l’authentification dans tous les modèles de déploiement. Chacune des options du fournisseur de services d’interface utilisateur (Citrix StoreFront ou Citrix Workspace) dispose de différentes options d’authentification disponibles, certaines nécessitant un NetScaler ADC/Gateway géré par le client.	Citrix StoreFront (plus NetScaler ADC/Gateway pour la plupart des cas d’utilisation). Les services d’authentification utilisateur peuvent être fournis de différentes manières, mais nécessitent finalement une instance Active Directory et des comptes utilisateur valides. Le client gère généralement l’instance AD. Les instances NetScaler ADC/Gateway peuvent également être utilisées pour fournir des services d’authentification et fournir une tonne de fonctionnalités avancées couramment utilisées pour les environnements plus complexes. Citrix Federated Authentication Services (FAS) peut également être installé et utilisé pour fournir l’authentification unique de session pour les cas d’utilisation complexes.	Citrix Workspace (plus NetScaler ADC/Gateway pour certains cas d’utilisation). Avec Citrix Workspace (le service), les sources d’authentification utilisateur et les exigences sont configurées une fois pour le client Citrix Cloud et utilisées par tous les utilisateurs utilisant cette URL. Il est configuré pour Active Directory prêt à l’emploi, mais pour les cas d’utilisation avancés, peut être configuré pour prendre en charge d’autres fournisseurs d’authentification. Par exemple, Azure AD, Okta, NetScaler Gateway géré par le client, Google Cloud ID ou d’autres fournisseurs SAML/OpenID/RADIUS. Certains scénarios nécessitent NetScaler ADC/Gateways gérés par le client et Citrix Federated Authentication Services (FAS) pour une expérience utilisateur optimale.
Proxy de session HDX - La capacité de connecter de manière sécurisée et transparente des utilisateurs/appareils en dehors du réseau privé de l’entreprise aux applications et bureaux fournis par CVAD/DaaS à l’intérieur.	AppliancesNetScaler ADC/Gateway : ces appliances (ou instances) fournissent souvent une tonne de fonctionnalités supplémentaires pour un système de virtualisation Citrix. Leur tâche principale, cependant, consiste à proxy sécurisé des sessions HDX à vos VDA lorsque les clients sont sur des réseaux publics. Nécessite l’installation, la configuration, les certificats SSL, etc. Compatible avec StoreFront (services d’interface utilisateur gérés par le client) et le service cloud Workspace. Également compatible avec les options de courtage de session gérée Citrix et de session gérée par le client.	Service NetScaler Gateway - fourni par Citrix Cloud, ce service fournit le trafic de session HDX vers vos VDA et utilise l’infrastructure managée Citrix pour réaliser le travail. Ne nécessite pas d’adresses IP publiques, de certificats SSL ou de règles de pare-feu d’entrée pour fonctionner. Compatible avec le service Citrix Workspace et les options de courtage de session gérées par Citrix Cloud et gérées par le client (CVAD et DaaS).

Pratiques exemplaires et recommandations

Que vous gériez vous-même le système de virtualisation Citrix ou que vous utilisiez Citrix ou un partenaire autorisé pour le faire, envisagez d’utiliser les services cloud dans la mesure du possible. Pour les cas d’utilisation/environnements où le service cloud ne répond pas à vos besoins, des composants gérés par le client peuvent être utilisés. Cela dit - Citrix encourage les clients à expliquer clairement pourquoi ils déploient des composants autogérés et à être prêts à migrer vers des services cloud une fois que le service cloud répond à leurs besoins spécifiques. Les services cloud fournis par Citrix via Citrix Cloud évoluent rapidement. Au fil du temps, vous pouvez vous attendre à ce qu’ils fournissent toutes les fonctionnalités nécessaires pour servir tous les cas d’utilisation sauf les plus complexes. Les services Citrix Cloud réduisent finalement la quantité d’infrastructure dont le client est responsable de la gestion et de la maintenance. Citrix Cloud fournit également des services préintégrés hautement disponibles et garantit aux clients un accès toujours aux services les plus récents, les plus sécurisés et riches en fonctionnalités.

Modèles de déploiement communs pour Citrix Virtualization sur AWS

En tant que fournisseur de cloud doté du plus grand nombre de fonctionnalités, d’une plus grande communauté de clients, d’une expérience inégalée et d’une maturité inégalées, AWS voit un large éventail de clients de différents secteurs déplaçant des systèmes et des infrastructures vers leurs clouds. Au fil du temps, ils ont vu se développer des scénarios de déploiement/des schémas de migration courants. Dans cette section, nous explorons ces modèles/scénarios, expliquons quand et où vous pouvez envisager de les utiliser pour apporter une charge de travail Citrix Virtual Apps and Desktops à AWS, et nous fournissons quelques recommandations concernant les modèles à prendre en compte pour les scénarios de migration courants.

Les trois scénarios les plus courants pour la fourniture de Citrix Apps and Desktops sur AWS sont les suivants :

• DéploiementGreenfield/Cloud uniquement, à l’aide des services Citrix Cloud avec des « emplacements de ressources » sur le service Amazon EC2 (Amazon Elastic Compute Cloud). Ce scénario est couramment utilisé lorsque les clients préfèrent passer à un modèle d’abonnement et externaliser l’infrastructure et la responsabilité de gestion du plan de contrôle à Citrix, ou lorsqu’ils cherchent à expérience/évaluer les fonctionnalités fournies par les services Citrix Cloud.
• Déploiementhybride/migration de charge de travail vers AWS, à l’aide des services Citrix Cloud pour le courtage et l’administration de sessions, l’interface utilisateur Workspace ou StoreFront pour l’agrégation de contenu/la présentation de session et le lancement de session, et peut également utiliser NetScaler ADC/Gateways gérés par le client pour le proxy de session HDX, complexe scénarios d’authentification, ou les deux.
• Soulevez et déplacez. Avec ce scénario, les clients déplacent ou redéployent essentiellement leur infrastructure Citrix autogérée dans AWS, traitant le déploiement sur AWS comme leur déploiement géré par le client existant. Avec ce scénario, les clients utilisent NetScaler ADC/Gateway et Citrix StoreFront pour agréger des ressources à partir de sites hébergés sur site et AWS. Cela facilite la migration des charges de travail vers AWS, bien que les clients puissent conserver leurs charges de travail sur site et simplement ajouter un autre site dans AWS. Le nouveau site peut être utilisé pour de nouvelles charges de travail ou pour prendre en charge les cas d’utilisation de reprise après sinistre et de basculement. Ce modèle est caractérisé par l’utilisation de composants gérés par le client pour le courtage et l’administration de session, les services d’interface utilisateur, l’authentification et le proxy de session HDX.

Cette section définit ces scénarios plus en détail, y compris des aperçus architecturaux de la façon dont chaque scénario est généralement conçu. Vous trouvez que la pratique de pointe consiste à utiliser les services Citrix Cloudet, à ce titre, ce document se concentre sur les modèles de déploiement négociés Citrix Cloud (« Greenfield » et « Hybrid »).

Déploiement de nouveaux champs

L’exemple le plus courant du modèle de déploiement en champ vert est les déploiements d’essai ou de validation de concept de la technologie de virtualisation Citrix sur le cloud AWS. Puisque vous commencez essentiellement à partir de zéro, la puissance de « l’infrastructure en tant que code » peut être expérimentée puisque vous n’essayez pas d’intégrer un tas de « trucs » existants. C’est également une occasion fantastique de « jouer avec » divers services cloud et d’évaluer leur adéquation aux besoins de vos clients ou de ceux de vos clients.

Un déploiement en champ vert est également le système de virtualisation Citrix le plus rapide et le plus simple que vous puissiez créer. Vous pouvez simplement l’arracher lorsque le système n’est plus nécessaire, et vous arrêtez de payer pour les ressources qu’il consomme. Pour ce type de déploiement, vous n’avez besoin que d’un compte AWS actif et d’un abonnement d’essai ou payant à Citrix Cloud et Citrix DaaS. Avec ces deux ressources, vous pouvez utiliser les modèles QuickStart CloudFormation d’AWS pour créer un déploiement de référence. Citrix et AWS ont collaboré sur le modèle de démarrage rapide Citrix DaaS sur AWS, qui vous aide soit à créer un système de virtualisation Citrix complet à partir de zéro, soit à créer un « emplacement de ressources » Citrix Cloud dans un VPC existant avec un Active Directory existant. Lors du déploiement de l’ensemble du système de virtualisation Citrix à partir de zéro, le système résultant sur AWS est construit étroitement en correspondance avec les diagrammes d’architecture de référence suivants :

Diagramme 3 : détail de l’architecture système déployée à l’aide du modèle Citrix DaaS on AWS QuickStart et des paramètres par défaut. Les services Citrix Cloud ne sont pas affichés.

Schéma 4 : Architecture conceptuelle de déploiement Greenfield/Cloud Only avec services AWS en option et services Citrix Cloud.

Il convient de noter que ce modèle de déploiement (en fait, les trois modèles de déploiement) utilise les zones de disponibilité AWS pour fournir une conception hautement disponible. Voir Zones de disponibilité plus loin dans ce document pour plus de contexte.

Comme mentionné précédemment, il s’agit d’un excellent point de départ lorsque vous apprenez sur les services cloud AWS et Citrix. La plupart des modèles de conception décrits dans le diagramme précédent sont utilisés pour les types de déploiement hybride et même de levage et de décalage. L’apprentissage de ces modèles de conception convient donc bien à un architecte Citrix sur AWS, quel que soit le modèle de déploiement.

Pour résumer, le modèle de déploiement en champ vert utilise tous les services cloud, au moins comme point de départ :

Composant système de virtualisation Citrix	Fait par :
Courtage et administration des sessions	Citrix DaaS (« DaaS », via Citrix Cloud)
Services d’interface utilisateur	Service Citrix Workspace (via Citrix Cloud)
Authentification	Service Citrix Workspace (via Citrix Cloud)
Proxy de session HDX	Service NetScaler Gateway (via Citrix Cloud)
Calcul, mise en réseau et stockage de VM	Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory et systèmes de fichiers	AWS Directory Service pour Microsoft Active Directory et Amazon FSx pour le serveur de fichiers Windows (facultatif)

Nous avons mentionné précédemment que le modèle de déploiement sur le terrain vert est souvent utilisé comme point de départ pour les systèmes de validation de concept et d’essai technologique. Si vous commencez avec ce modèle et que vous déposez ensuite StoreFront ou NetScaler ADC/Gateway VPX dans, vous créez apparemment notre prochain type de modèle de déploiement : hybride.

déploiement hybride

Avec le modèle de déploiement hybride, les clients peuvent choisir d’installer/configurer/gérer eux-mêmes certains composants du système de virtualisation Citrix, mais pas le sous-système de négociation de session et d’administration. Dans un modèle de déploiement hybride, ce sous-système est fourni sous la forme d’un service cloud appelé « Citrix DaaS », et il est fourni sous forme d’abonnement à partir de Citrix Cloud.

Le modèle de déploiement hybride est le déploiement le plus courant aujourd’hui, et il est le modèle recommandé par Citrix pour la plupart des clients. Voici quelques-unes des principales raisons pour lesquelles nous prenons cette position :

• Simplicité - Avec les services Citrix Cloud, la simplicité est un principe fondamental de conception. Lorsque plusieurs services cloud sont utilisés, ils sont préconfigurés pour fonctionner ensemble, et lorsque la configuration est nécessaire, les flux de travail et les options sont considérablement simplifiés.
• Réduction descoûts liés à l’infrastructure et aux licences  : les services de virtualisation Citrix gérés par le client nécessitent souvent du matériel et des logiciels supplémentaires pour les prendre en charge, et ces coûts sont associés. Un bon exemple est Microsoft SQL Server : les services de courtage et d’administration gérés par les clients nécessitent des bases de données, et si vous allez construire ou gérer les vôtres, vous devez les fournir. Une alternative consiste à utiliser AWS Relational Database Service (Amazon RDS) pour SQL Server.
• Autoscaling  : le service de courtage géré (DaaS) de Citrix inclut la fonctionnalité Citrix Autoscale, qui fournit une capacité VDA intégrée et une fonctionnalité de gestion des coûts. Cette fonctionnalité permet aux clients d’économiser beaucoup d’argent sur l’infrastructure lorsqu’ils ne paient que pour ce qu’ils utilisent. Lorsque vous exécutez une charge de travail de virtualisation Citrix sur AWS, cela signifie souvent la différence entre payer des remises pour utilisation engagée ou payer l’utilisation des machines virtuelles au fur et à mesure. Les économies de coûts peuvent être considérables pour de nombreux cas d’utilisation, et la fonctionnalité Citrix Autoscale vous permet de ne consommer que ce dont vous avez besoin.
• Économies de gestion : avec les services cloud, Citrix a la responsabilité de maintenir la haute disponibilité, les performances, la sécurité et la mise à jour des services. Vous continuez de créer et de gérer vos VDA quel que soit, mais ne sous-estimez pas la valeur de la délégation de ces responsabilités. Les services cloud aident à libérer des ressources informatiques, ce qui leur permet de se concentrer sur la fourniture d’une valeur unique à leur entreprise au lieu de ces tâches critiques mais fastidieuses (et souvent longues).
• Mises à niveau « gratuites » et innovation continue - avec l’infrastructure gérée par le client, il incombe au client de mettre à niveau et de corriger les composants dont il a la charge. Avec les services Cloud, la plupart de ces efforts de travail disparaissent. Les fournisseurs de services (Citrix ou AWS par exemple) ont tendance à innover constamment, et ils apportent ces innovations aux clients qui consomment les services, souvent sans nécessiter de travail pour le compte du client.
• Accès à davantage de fonctionnalités, de fonctionnalités et de services  : les plates-formes modernes de prestation de services (telles que Citrix Cloud et AWS EC2) offrent aux fournisseurs de technologie un moyen puissant et rentable de mettre sur le marché de nouvelles fonctionnalités, fonctionnalités et services qui ne seraient pas possibles autrement. Des fournisseurs tels que Citrix s’engagent à rencontrer les clients où qu’ils se trouvent dans leur parcours de transformation numérique, mais parfois la seule façon de fournir de nouvelles fonctionnalités de manière rentable est de les fournir en tant que service cloud.
• Flexibilité  : avec le DaaS comme base de ce modèle de déploiement, les clients peuvent combiner des composants de services cloud ou gérés par le client du système de virtualisation Citrix. Cela permet au système de répondre à différents cas d’utilisation et de prendre en charge les exigences complexes de l’entreprise pour un système de virtualisation Citrix. Nous explorons ces choix en profondeur dans une section ultérieure du présent document.

Pour résumer, le modèle de déploiement hybride utilise les éléments suivants :

Composant système de virtualisation Citrix	Fait par :
Courtage et administration des sessions	Citrix DaaS (« DaaS », via Citrix Cloud)
Services d’interface utilisateur	Service Citrix Workspace (via Citrix Cloud) OU Citrix StoreFront sur Amazon EC2 (géré par le client)
Authentification	Service Citrix Workspace (via Citrix Cloud) OU Citrix StoreFront sur EC2 (NetScaler ADC/Gateway facultatif mais commun)
Proxy de session HDX	Service NetScaler Gateway (via Citrix Cloud) OU NetScaler ADC/Gateway VPX sur Amazon EC2 (NetScaler ADC/Gateway facultatif mais commun)
Calcul, mise en réseau et stockage de VM	Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory et systèmes de fichiers	AWS Directory Service pour Microsoft Active Directory et Amazon FSx pour le serveur de fichiers Windows (facultatif)

Compte tenu des options qu’un client peut choisir dans le modèle de déploiement hybride et de la flexibilité offerte par les composants gérés par le client, il n’existe pas une architecture succincte qui convienne à tous les clients. Il existe cependant des modèles de conception communs qui peuvent également être combinés pour répondre aux besoins des clients. Le modèle de base, cependant, est le modèle pour un Citrix Cloud « Resource Location » sur AWS. Il s’agit également du modèle créé par le modèle QuickStart Citrix DaaS sur AWS, et il ressemble au schéma architectural suivant :

Diagramme 5 : Architecture conceptuelle, Citrix DaaS - Modèle de déploiement hybride sur AWS.

Il convient de noter que ce modèle de déploiement utilise également les zones de disponibilité AWS pour fournir une conception hautement disponible. Voir Zones de disponibilité plus loin dans ce document pour plus de contexte.

Il convient également de noter que le modèle de déploiement hybride (un emplacement de ressources DaaS sur AWS) peut être combiné avec un modèle de cloud hybride, connectant des centres de données/ressources gérés par le client à AWS à l’aide d’AWS Direct Connect, d’AWS VPN, de Citrix SD-WAN ou d’autres outils de mise en réseau. Avec ce modèle, Active Directory existant des clients est souvent étendu à AWS, et les clients créent davantage d’ « emplacements de ressources » Citrix Cloud qui fournissent des applications, des postes de travail et des ressources à partir du centre de données géré par le client. L’architecture conceptuelle qui en résulte ressemble un peu au schéma suivant : Diagramme 6 : Architecture conceptuelle, Citrix DaaS : déploiement hybride/modèle de cloud hybride.

Soulever et Shift

En se référant à notre définition des composants du système de virtualisation Citrix, lorsque nous parlons d’un scénario de déploiement évolutif, le composant clé est le sous-système de courtage et d’administration de sessions et l’infrastructure associée. Si vous utilisez une infrastructure de courtage autogérée (vous déployez des Delivery Controller au lieu de Cloud Connector), pour les besoins de ce document, vous levez et déplacez vos déplacements.

Lift and Shift - pourquoi

Malgré les conseils de Citrix concernant ce modèle, certains clients choisissent toujours d’utiliser ce modèle et de déployer et de gérer eux-mêmes les composants du système de virtualisation Citrix. Conformément à la norme CTX270373, l’utilisation de clouds publics, y compris AWS, n’est prise en charge qu’avec les versions des produits LTSR. Pour les clients qui choisissent le modèle de déploiement de lift and shift (autogéré), nous constatons souvent que des raisons non techniques sont derrière ce modèle. La stratégie, les contraintes de temps, la peur de l’inconnu, les déficits perçus en matière de compétences, la perte de contrôle et l’acquisition de permis entrent dans cette catégorie. Il y a cependant quelques raisons techniques pour lesquelles ce modèle est attrayant. Ces informations incluent :

• Isolation du système - certains cas d’utilisation, tels que les systèmes à air gap sans accès Internet, rendent souvent le modèle lift-and-shift attrayant. Étant donné que les services cloud nécessitent un accès Internet sortant pour fonctionner, dans un déploiement strictement gonflé, les services cloud ne fonctionneront pas. Cela s’applique principalement aux Cloud Connector (composant principal des services de courtage de session managée) car ils ont besoin d’une connectivité Internet sortante pour communiquer avec les services Citrix Cloud et les utiliser. Certains clients peuvent envisager d’utiliser un proxy sortant sécurisé pour Cloud Connector (tout en gardant toutes les autres infrastructures strictement gonflées). Il s’agit souvent d’une concession appropriée qui permet d’utiliser les services de courtage gérés, mais même cela peut ne pas être une option pour certains clients et cas d’utilisation.
• Flexibilité de configuration  : le « complexe » d’une personne est « flexible » d’une autre personne, et la flexibilité est une suite solide d’infrastructure de virtualisation Citrix gérée par le client depuis plus de deux décennies. Au fil des ans, la technologie a acquis une tonne de fonctionnalités qui prennent en charge des cas d’utilisation très créneaux et des intégrations tierces. Les services Citrix Cloud se concentrent sur la simplicité et la pré-intégration. Ce faisant, certaines de ces fonctionnalités et intégrations de niche ne sont pas disponibles. Par conséquent, certains cas de périphérie sont toujours mieux servis par une pile gérée par le client. Cela dit, étant donné le rythme rapide de l’innovation à l’arrivée des services Citrix Cloud, ces cas de périphérie deviennent de plus en plus rares.
• Contrôle - certaines organisations, cultures et modèles d’affaires exigent autant de contrôle que possible. Grâce aux composants de virtualisation Citrix gérés par le client, les clients peuvent posséder complètement leur destin. Ce contrôle a un coût (infrastructure, complexité, personnel, etc.) mais le « contrôle à tout prix » est une chose pour certains clients.

Pour résumer, le modèle de déploiement de levage et de décalage utilise les éléments suivants :

Composant système de virtualisation Citrix	Fait par :
Courtage et administration des sessions	Citrix Virtual Apps and Desktops (géré par le client à l’aide de LTSR ou CR téléchargeable) sur Amazon EC2
Services d’interface utilisateur	Citrix StoreFront sur Amazon EC2 (géré par le client)
Authentification	Citrix StoreFront sur EC2 (NetScaler ADC/Gateway facultatif mais commun)
Proxy de session HDX	NetScaler ADC/Gateway VPX sur Amazon EC2 (géré par le client)
Calcul, mise en réseau et stockage de VM	Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Block Store (Amazon EBS)
Active Directory et systèmes de fichiers	Instances Windows Server gérées par le client sur EC2 ; AWS Directory Service pour Microsoft Active Directory et Amazon FSx pour Windows File Server (facultatif)

Dans sa forme la plus simple, un déploiement de la technologie de virtualisation Citrix sur AWS ressemble à un déploiement géré par le client traditionnel sur site. Il utilise un « site » CVAD déployé dans une région AWS et utilise au minimum les services IaaS AWS de base tels que les machines virtuelles EC2 et la mise en réseau VPC. Comme mentionné précédemment, le client doit construire/configurer/maintenir tous les composants système, ainsi que les services de prise en charge tels que les bases de données SQL. Le schéma suivant décrit ce modèle de déploiement : Schéma 1 : Architecture conceptuelle, CVAD : Modèle de déploiement Lift and Shift sur AWS Schéma 1 : Architecture conceptuelle, CVAD : Modèle de déploiement Lift and Shift sur AWS.

Il convient de noter que ce modèle de déploiement utilise également les zones de disponibilité AWS pour fournir une conception hautement disponible. Voir Zones de disponibilité plus loin dans ce document pour plus de contexte.

Un modèle de déploiement de levage et de transfert est souvent associé à un modèle d’infrastructure de cloud hybride, utilisant AWS Direct Connect, AWS VPN, Citrix SD-WAN ou une technologie de mise en réseau similaire pour connecter un centre de données géré par le client et des ressources à AWS. Les clients peuvent éventuellement adopter certains des services cloud les plus avancés d’AWS (pour fournir une certaine simplification avec la transition), et ils peuvent également choisir d’héberger certains services (comme les bases de données SQL, les licences Citrix, Citrix StoreFront et NetScaler ADC/Gateway) soit sur AWS, dans des données gérées par le client centre, ou les deux en fonction de leurs investissements existants, les exigences de cas d’utilisation, etc. Une architecture conceptuelle de ce modèle de déploiement (à l’aide d’AWS RDS pour SQL Server ou SQL Server local) est illustrée dans le diagramme suivant. Une seule instance active du système de licences Citrix est nécessaire, mais nous en avons montré plusieurs pour illustrer les options disponibles : Schéma 8 : Architecture conceptuelle, CVAD : modèle de déploiement Lift and Shift avec modèle d’infrastructure de cloud hybride et services cloud gérés par AWS Schéma 8 : Architecture conceptuelle, CVAD : modèle de déploiement Lift and Shift avec un modèle d’infrastructure de cloud hybride et des services cloud gérés par AWS.

Lift and Shift - pourquoi pas

À présent, vous avez compris que la pratique/recommandation principale de Citrix est de NE PAS faire un levage complet et un changement. Vous pouvez vous demander pourquoi, ou d’où cela vient. En se référant à notre ventilation des composants du système de virtualisation Citrix, le sous-système de courtage et d’administration de session est le composant le plus critique que vous ne souhaitez PAS supprimer et déplacer. Nous recommandons vivement aux clients d’envisager d’utiliser les services cloud de Citrix pour le courtage et l’administration de sessions (déployer Cloud Connector uniquement, par opposition au déploiement de Delivery Controllers + bases de données SQL + serveurs Director + serveurs de licences Citrix). Voici quelques-unes des principales raisons pour lesquelles nous prenons cette position (et elles peuvent sembler familières) :

• Simplicité - Bien que les services de courtage de session gérés par le client offrent la flexibilité ultime en matière de contrôle et de configuration, ils se font au détriment de la complexité et des exigences de maintenance continue. Avec les services Citrix Cloud, la simplicité est un principe fondamental de conception. Lorsque plusieurs services cloud sont utilisés, ils sont préconfigurés pour fonctionner ensemble, et lorsque la configuration est nécessaire, les flux de travail et les options sont considérablement simplifiés.
• Réduction descoûts liés à l’infrastructure et aux licences  : les services de virtualisation Citrix gérés par le client nécessitent souvent du matériel et des logiciels supplémentaires pour les prendre en charge, et ces coûts sont associés. Un bon exemple est Microsoft SQL Server : les services de courtage gérés par les clients nécessitent des bases de données, et si vous allez créer ou gérer les vôtres, vous devez les fournir.
• En parlant d’économies de coûts d’infrastructure, cela crée une différenciation critique entre les deux options de courtage de session : Autoscaling. Le service de courtage géré (DaaS) de Citrix inclut la fonctionnalité Citrix Autoscale, qui fournit une capacité VDA intégrée et une fonctionnalité de gestion des coûts. Cette fonctionnalité permet aux clients d’économiser beaucoup d’argent sur l’infrastructure lorsqu’ils ne paient que pour ce qu’ils utilisent. Lorsque vous exécutez une charge de travail de virtualisation Citrix sur AWS, cela signifie souvent la différence entre payer des remises pour utilisation engagée ou payer l’utilisation des machines virtuelles au fur et à mesure. Les économies de coûts peuvent être considérables pour de nombreux cas d’utilisation, et la fonctionnalité Citrix Autoscale vous permet de ne consommer que ce dont vous avez besoin. Remarque importante : cette fonctionnalité n’est disponible que pour les clients du service Citrix Cloud (Citrix DaaS). Elle n’est pas disponible pour l’infrastructure de courtage gérée par le client (versions LTSR ou CR de Citrix Virtual Apps and Desktops). - Économies de gestion - Avec les services cloud, Citrix (et AWS dans ce cas) assume la responsabilité de maintenir les services hautement disponibles, performants, sécurisés et à jour. Vous continuez de créer et de gérer vos VDA quel que soit, mais ne sous-estimez pas la valeur de la délégation de ces responsabilités. Les services cloud aident à libérer des ressources informatiques, ce qui leur permet de se concentrer sur la valeur unique à leur entreprise au lieu de ces tâches critiques mais fastidieuses et souvent fastidieuses.
• Mises à niveau « gratuites » et innovation continue - avec l’infrastructure gérée par le client, il incombe au client de mettre à niveau et de corriger les composants dont il a la charge. Avec les services cloud, la plupart de ces efforts de travail disparaissent. Les fournisseurs de services (Citrix et AWS dans ce cas) ont tendance à innover constamment, et ils apportent ces innovations aux clients qui consomment les services, souvent sans nécessiter de travail pour le compte du client.
• Accès à davantage de fonctionnalités, de fonctionnalités et de services  : les plateformes modernes de prestation de services (telles que Citrix Cloud et Amazon EC2) offrent aux fournisseurs de technologie un moyen puissant et économique de mettre sur le marché de nouvelles fonctionnalités, fonctionnalités et services qui ne seraient pas possibles autrement. Des fournisseurs tels que Citrix s’engagent à rencontrer les clients où qu’ils se trouvent dans leur parcours de transformation numérique, mais parfois la seule façon de fournir de nouvelles fonctionnalités de manière rentable est de les fournir en tant que service cloud.

Lift and Shift - plus de ressources

Avant la naissance des services Citrix Cloud, les clients déployaient déjà avec succès les technologies de virtualisation Citrix sur AWS. Dans ces jours, Citrix a appelé les produits Virtual Apps and Desktops XenApp et XenDesktop. Des travaux importants ont été consacrés à la création et à la publication d’architectures de référence et de guides de déploiement pour ce scénario de déploiement. Une bonne partie des détails de ces ressources vieillissantes s’applique toujours aux déploiements qui doivent suivre cette voie aujourd’hui.

Pour les clients qui DOIVENT emprunter cette voie, les ressources publiées suivantes vous fournissent des informations d’arrière-plan utiles que vous pouvez utiliser pour vous aider à réussir. Nous vous recommandons d’examiner ces documents avant de poursuivre le présent document, car nous soulignons les décisions importantes de conception qui ont changé depuis la fin de ces travaux :

• Utilisation d’AWS Directory Service et d’Amazon RDS avec Citrix Virtual Apps and Desktops (blog)
• Déploiement de Citrix Virtual Apps and Desktop avec AWS Directory Service et Amazon RDS Version 1.0 (guide de déploiement)

Décisions de conception

Cette section explore les principales décisions de conception à prendre en compte lors de l’architecture de votre système de virtualisation Citrix sur AWS. Nous parcourons chaque couche du Citrix Architectural Design Framework, en explorant les domaines clés à prendre en compte.

À propos de Citrix Architectural Design Framework

La solution Virtual Apps and Desktops de Citrix (le nom de famille de produits faisant référence collectivement aux technologies de virtualisation de Citrix) permet aux entreprises de créer, de contrôler et de gérer des machines virtuelles, de fournir des applications et des postes de travail et d’implémenter des stratégies de sécurité granulaires. La solution Citrix Virtual Apps and Desktops fournit un cadre unifié pour le développement d’une offre complète d’espace de travail numérique. Cette offre permet aux utilisateurs de Citrix d’accéder aux applications et aux bureaux indépendamment du système d’exploitation et de l’interface de leur appareil.

Le cadre de conception architecturale Citrix est basé sur un modèle de couche unifié et standardisé. Il fournit un cadre cohérent et facilement accessible pour comprendre l’architecture technique de la plupart des scénarios courants de déploiement d’Virtual Apps and Desktops. Ces couches sont représentées dans le diagramme conceptuel suivant : Diagramme 9 : Architecture conceptuelle, Citrix Virtual Apps and Desktops Diagramme 9 : Architecture conceptuelle, Citrix Virtual Apps and Desktops.

• Couche utilisateur - Cette couche définit les groupes d’utilisateurs et les emplacements de l’environnement Citrix.
• Couche d’accès - Cette couche définit la façon dont les utilisateurs accèdent aux ressources.
• Couche de contrôle  : cette couche définit les composants qui contrôlent la solution Citrix.
• Couche de ressources - Cette couche définit le provisionnement des charges de travail Citrix et la manière dont les ressources sont affectées aux utilisateurs donnés.
• Couche de plate-forme - Cette couche définit les éléments physiques dans lesquels les composants de l’hyperviseur et la structure du fournisseur de services cloud s’exécutent pour héberger les charges de travail Citrix.
• Couche Opérations - Cette couche définit les outils qui prennent en charge la livraison des solutions principales.

Considérations relatives aux couches utilisateur

Dans Citrix Architectural Design Framework, la couche User décrit les groupes d’utilisateurs, leurs emplacements, leurs exigences spécifiques, etc. La couche utilisateur définit correctement la direction générale de l’environnement de chaque groupe d’utilisateurs. Cette couche intègre les critères d’évaluation des priorités métier et des besoins des groupes d’utilisateurs afin de définir des stratégies efficaces pour les terminaux et l’application Citrix Workspace. Ces décisions de conception affectent la flexibilité et la fonctionnalité de chaque groupe d’utilisateurs.

Lors de la conception et du déploiement d’un système de virtualisation Citrix sur n’importe quelle plate-forme, les décisions et stratégies adoptées après une évaluation minutieuse ont jeté les bases de nombreuses autres décisions que les clients devraient prendre en compte lorsqu’ils passent par les autres couches de Citrix Architectural Design Framework. En tant que tel, il s’agit d’une couche critique pour bien comprendre et obtenir le droit.

Considérations relatives à la couche

Dans Citrix Architectural Design Framework, la couche Access définit la façon dont les utilisateurs accèdent aux ressources AWS. La conception de votre couche d’accès est essentielle à la fonctionnalité fournie par tout système de virtualisation Citrix. Il contrôle la façon dont les utilisateurs s’authentifient auprès du système. Il contrôle également la façon dont les utilisateurs visualisent et lancent des applications et des postes de travail virtualisés, ainsi que le type d’applications et de contenu disponibles. En outre, la couche Access contrôle comment et quand les sessions sont connectées en toute sécurité par proxy ou directement.

Dans le contexte des composants du système de virtualisation Citrix que nous avons définis précédemment, la couche d’accès contient les composants et les choix suivants :

Composant système de virtualisation Citrix	Fait par :
Services d’interface utilisateur	Citrix Workspace (fourni par Citrix Cloud) OU Citrix StoreFront sur Amazon EC2 (géré par le client)
Authentification	Service Citrix Workspace (NetScaler ADC/Gateway en option) OU Citrix StoreFront sur EC2 (NetScaler ADC/Gateway facultatif mais commun)
Proxy de session HDX	Service NetScaler Gateway (fourni par Citrix Cloud) OU NetScaler ADC/Gateway VPX sur Amazon EC2 (géré par le client)

Le tableau suivant contient les points de décision critiques lors de la détermination du composant de couche d’accès à déployer, mais le choix n’est pas binaire. Citrix prend en charge différentes méthodes d’accès qui peuvent être personnalisées en fonction de vos besoins.

Service d’interface utilisateur et considérations d’authentification

Tenez compte des éléments suivants lorsque vous choisissez la façon dont vous souhaitez fournir des services d’interface utilisateur pour votre système de virtualisation Citrix sur AWS :

Attribut/Capacité	Gestion du client (installé à partir des fichiers binaires téléchargés)	Service Cloud (fourni via Citrix Cloud)
Possibilité de présenter et de lancer des applications virtualisées et des postes de travail à partir de plusieurs « batteries Citrix. »	OUI : les environnements existants (XenApp et XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) et Citrix DaaS.	OUI : les environnements existants (XenApp et XenDesktop 7.x, Citrix Virtual Apps and Desktops CR/LTSR) et Citrix DaaS. Consultez cet article pour plus de détails.
Possibilité de créer plusieurs « magasins » avec des paramètres différents pour différents cas d’utilisation, y compris les exigences d’authentification.	OUI - StoreFront peut être configuré avec plusieurs magasins différents et, lorsqu’il est combiné avec NetScaler ADC/Gateway VPX, peut appliquer des règles sophistiquées pour diriger certains appareils ou groupes d’utilisateurs vers différents magasins. Pour plus d’informations, consultez Comment fonctionne SmartAccess pour Citrix Virtual Apps and Desktops. Un scénario courant nécessitant deux magasins StoreFront serait lorsque les utilisateurs ont besoin d’applications publiées à partir d’un poste de travail publié. Un autre scénario courant serait l’exigence d’avoir un magasin interne uniquement (pas d’accès NetScaler Gateway) pour un cas d’utilisation spécifique et un autre magasin configuré pour l’accès interne et distant. Consultez Configurer et gérer les magasins pour plus d’informations.	NON - le service Workspace est essentiellement un magasin unique, sur une seule URL. Tous les utilisateurs utilisent les mêmes paramètres de magasin et d’espace de travail. Les exigences d’authentification sont configurées une fois et s’appliquent à tous les utilisateurs du locataire Workspace.
Possibilité d’énumérer, de lancer et de créer une authentification unique dans des applications SaaS et Web à l’aide du service Citrix Secure Private Access, en tirant parti du filtrage Web et des stratégies de contrôle de sécurité améliorées, ainsi que des analyses avancées améliorées de ML.	NON - Nécessite l’utilisation de Citrix Workspace.	OUI - Avec le service NetScaler Gateway, il est aussi simple que d’activer l’intégration dans Citrix Cloud Console. Les applications SaaS sont définies simplement à partir d’un assistant basé sur le Web, et les administrateurs peuvent utiliser une liste substantielle d’applications prédéfinies comme point de départ.
Possibilité d’accèder/indexer/rechercher du contenu Citrix Files (anciennement ShareFile) via l’application Citrix Workspace et les navigateurs Web (HTML).	NON - StoreFront n’a pas la possibilité d’intégrer du contenu basé sur des fichiers dans l’application Workspace ou dans les UI HTML StoreFront.	OUI - Activé par défaut en fonction de l’abonnement à Citrix Cloud. Inclut le contenu basé sur des fichiers des utilisateurs provenant de diverses sources (y compris les partages de fichiers locaux) dans l’interface utilisateur de l’espace de travail, à la fois HTML et Workspace App.
Possibilité de présenter et de lancer des connexions vers des postes de travail physiques à l’aide de la fonctionnalité Citrix Remote PC Access .	OUI - Que le courtage soit géré par CVAD ou DaaS.	OUI - Que le courtage soit géré par CVAD ou DaaS.
Pour les cas d’utilisation multisite et de reprise après sinistre, possibilité de contrôler de manière granulaire le comportement de lancement de session à l’aide des préférences de zone et de basculement.	OUI - L’utilisation de Citrix Zones pour des déploiements dans plusieurs régions et zones de disponibilité AWS est un excellent moyen d’étendre l’est-ouest et de limiter la base d’utilisateurs affectée en cas de panne, et permet la préférence régionale et le basculement vers la zone principale de manière transparente. Consultez la documentation sur les zones CVAD.	Partiel - Le service Workspace n’inclut pas la préférence de zone complète et la fonctionnalité de basculement, mais un effet similaire peut être implémenté à l’aide des zones d’accueil pour les utilisateurs ou les applications. Consultez la documentation Citrix DaaS Zones pour plus de détails.
Possibilité de négocier des connexions nouvelles et existantes lorsqu’une connexion entre un localisation/zone de ressources et Citrix Cloud échoue, ou lorsque les bases de données situées sous Citrix Delivery Controller ne sont pas disponibles.	OUI - Utilise la fonctionnalité Local Host Cache sur Cloud Connector et Delivery Controller pour fournir une résilience pour ces deux scénarios de défaillance potentiels. Pour les environnements exigeant une résilience étendue, Citrix recommande de déployer StoreFront avec le cache d’hôte local. Pour plus d’informations, consultez la section CVAD (Local Host Cache).	OUI - Cloud Connector utilise la fonctionnalité Local Host Cache pour broker les connexions de ressources en cas d’échec de communication Citrix Cloud. Cela nécessite des serveurs StoreFront passifs accessibles par vos emplacements de ressources pour gérer les scénarios de basculement. Pour plus d’informations, consultez la section Cache d’hôte local (DaaS).
Possibilité de configurer et d’utiliser une « URL de vanité » personnalisée pour la consommation de l’utilisateur final.	OUI - Le client a le contrôle total des URL et certificats utilisés et présentés aux utilisateurs. Nécessitent des certificats SSL, de la création/gestion d’alias DNS et des instances NetScaler ADC/Gateway pour l’entrée sur les réseaux publics.	Partiel  : tous les espaces de travail sont fournis à partir du domaine cloud.com, bien que les clients puissent configurer leur propre préfixe personnalisé (customername.cloud.com).
Possibilité d’acheminer intelligemment les utilisateurs sur le réseau directement vers les VDA et les utilisateurs hors réseau via NetScaler ADC/Gateway VPX ou NetScaler Gateway Service.	OUI - StoreFront utilise des « balises » définies par l’administrateur, que l’application Citrix Workspace utilise pour déterminer si un utilisateur est sur ou hors réseau.	Bientôt disponible : cette fonctionnalité devrait être disponible sur Citrix Workspace avec la version du service de localisation réseau une fois qu’elle est généralement disponible. Pour plus d’informations, voir Aperçu du service de localisation réseau.
Possibilité d’utiliser NetScaler Gateway Service pour des services proxy de session HDX simples et préconfigurés.	NON - Si l’accès hors réseau aux applications virtualisées Citrix est requis (et qu’il est dans 99 % des déploiements), StoreFront nécessite l’utilisation de la fonctionnalité proxy de session NetScaler ADC/Gateway for HDX gérée par le client.	OUI - Cette fonctionnalité est provisionnée et activée par défaut pour tous les nouveaux locataires Citrix Workspace.
Inclut l’authentification multifacteur intégrée via Active Directory et TOTP.	OUI - NetScaler ADC inclut la fonctionnalité TOTP intégrée à utiliser avec des authentificateurs tiers, et prend également en charge les applications/périphériques/services tiers.	OUI - Citrix Workspace inclut cette fonctionnalité, y compris la récupération de périphérique OTP en libre-service et les notifications push automatiques aux utilisateurs finaux. Prend en charge les applications Citrix et les applications d’authentification tierces.
Fonctionnalités SSO (applications virtualisées, SaaS et Web)	Partiel - SSO vers des applications virtualisées à l’état de la boîte.	OUI : l’interface SSO vers les applications virtualisées, SaaS et Web disponibles en natif avec Citrix Workspace. Le service de passerelle et l’accès privé sécurisé incluent le filtrage Web et les contrôles de stratégie.
Possibilité de choisir parmi plusieurs méthodes d’authentification prédéfinies et d’appliquer la méthode choisie à tous les utilisateurs du système.	OUI - avec plus d’options et de flexibilité. Citrix StoreFront vous permet de créer plusieurs magasins, et les méthodes d’authentification sont configurées par magasin. Une ou plusieurs options peuvent être configurées par magasin, et les administrateurs peuvent sélectionner parmi les options Nom d’utilisateur/mot de passe Active Directory, authentification SAML, transfert de domaine, carte à puce, HTTP Basic et Pass-through à partir de NetScaler Gateway. La réinitialisation du mot de passe en libre-service peut également être activée. Consultez la section Configurer le service d’authentification pour plus d’informations. Lorsque NetScaler ADC/Gateway (géré par le client) est déployé et utilisé avec StoreFront, plusieurs options d’authentification peuvent être configurées, ainsi qu’une logique supplémentaire pour diriger les utilisateurs vers un magasin spécifique en fonction des besoins pour prendre en charge presque tous les cas d’utilisation. Citrix StoreFront et NetScaler ADC/Gateway sont recommandés lorsque des intégrations complexes et des méthodes d’authentification différentes sont requises pour différents cas d’utilisation.	OUI - Actuellement, Active Directory, Azure AD, Active Directory + TOKEN, Azure AD et NetScaler Gateway sont actuellement pris en charge. Les options Okta et Google Cloud ID sont en prévisualisation ou à venir bientôt. Voir Espaces de travail sécurisés pour plus d’informations. À l’exception de NetScaler Gateway, votre choix d’authentification s’applique à tous les utilisateurs et à tous les services fournis via le locataire/l’URL Citrix Workspace. Avec l’option NetScaler Gateway, les clients peuvent prendre en charge diverses options d’authentification (RADIUS MFA, carte à puce, fédération, stratégies d’accès conditionnel, etc.) et les appliquer de manière flexible à différents groupes d’utilisateurs et cas d’utilisation. Pour plus d’informations, consultez Connecter une passerelle NetScaler Gateway locale en tant que fournisseur d’identité à Citrix Cloud.
Possibilité d’authentification SSO aux sessions sur VDA lors du lancement d’applications/postes de travail Windows virtualisés à l’aide de fournisseurs d’identité fédérés	OUI - Citrix Federated Authentication Service (FAS) active l’authentification unique pour les VDA lors de l’utilisation d’un fournisseur d’identité fédéré tel que SAML (Security Assertion Markup Language).	Prochainement - En utilisant Citrix Federated Authentication Service (FAS) avec Citrix Workspace. Cette fonctionnalité est en prévisualisation au moment de cet écrit. Consultez Activer l’authentification unique pour les espaces de travail avec Citrix FAS pour plus d’informations.

Considérations relatives au proxy de session HDX

Tenez compte des éléments suivants lorsque vous choisissez la façon dont vous souhaitez fournir la fonctionnalité proxy de session HDX pour votre système de virtualisation Citrix sur AWS :

Attribut/Capacité	Géré par le client (NetScaler ADC/Gateway VPX sur AWS)	Service Cloud (service NetScaler Gateway fourni par Citrix Cloud)
Service simple et préconfiguré, fournissant un proxy HDX sans frais administratifs	NON - En tant que composant géré par le client, ces appliances nécessitent des licences, une installation, une configuration et une maintenance.	OUI - NetScaler Gateway Service est une solution proxy HDX complète, gérée par Citrix, fournie sous forme de service cloud.
Possibilité d’utiliser le protocole de transport EDT (UDP) de Citrix HDX. Pour plus d’informations, consultez Adaptive Transport et How to Configure HDX Enlightened Data Transport Protocol.	OUI - Cette fonctionnalité optimise le trafic des sites à latence élevée et est disponible pour les instances ADC/passerelle gérées par le client.	Pas encore - Cette fonctionnalité est en prévisualisation à ce moment. Actuellement, le service de passerelle prend en charge uniquement les connexions basées sur TCP aux VDA.
Possibilité de fournir l’équilibrage de charge, la vérification de l’état, le déchargement SSL et divers autres services avancés de mise en réseau et de fourniture d’applications pour l’infrastructure gérée par le client.	OUI - Les appliances NetScaler ADC/Gateway VPX offrent des fonctionnalités sophistiquées de pointe, dont beaucoup peuvent être activées en appliquant simplement le type de licence approprié à l’appliance.	NON - Pour les environnements négociés Citrix CVAD et Citrix DaaS, Gateway Service fournit un accès simple et sécurisé aux applications virtualisées s’exécutant dans les environnements AWS ou sur site du client.
Prise en charge de la GSLB (Global Server Load Balancing) configurable par le client entre les centres de données, les zones et les régions.	OUI - Les instances NetScaler ADC/Gateway gérées par le client peuvent être configurées pour GSLB, bien que le client soit responsable de la configuration et de la gestion.	NON -… mais cela n’est pas vraiment nécessaire : le service Gateway utilise 14 points de présence ou plus dans le monde, ainsi que GSLB intégré pour garantir aux utilisateurs les meilleures performances de session possibles, où qu’ils se trouvent dans le monde.
Nécessite l’utilisation de l’interface utilisateur Citrix Workspace pour la présentation et le lancement de session HDX.	NON - Il est possible d’utiliser les instances VPX NetScaler ADC/Gateway gérées par le client avec l’interface utilisateur Workspace et StoreFront.	OUI - Le service de passerelle est configurable uniquement via le proxy Citrix Workspace UI pour HDX - il ne fournit PAS de fonctionnalités proxy HDX pour Citrix StoreFront.
Nécessite des ressources supplémentaires sur les instances Cloud Connector pour les sessions de proxy vers des réseaux sécurisés.	NON - Alors que Cloud Connector effectue la validation des tickets STA pour les instances NetScaler ADC/Gateway VPX gérées par le client, aucune ressource supplémentaire n’est nécessaire puisque toutes les sessions HDX sont transmises par proxy via les VPX.	OUI - Aujourd’hui, le service de passerelle utilise des connexions TCP sortantes de longue durée des instances Cloud Connector vers Citrix Cloud pour rediriger le trafic HDX vers des réseaux privés. Cela nécessite des considérations supplémentaires en matière de ressources lors du dimensionnement et de la configuration des instances Cloud Connector. Consultez cet article pour plus de détails. Remarque - cette exigence est sans objet pour la plupart des cas d’utilisation une fois que le service de passerelle et les VDA peuvent utiliser le protocole/fonctionnalité Rendezvous. Cela nécessite Citrix VDA 1912 ou plus récent.
Possibilité d’être utilisé avec les locataires Citrix Cloud Government.	OUI - Les déploiements ADC/Gateway/StoreFront sur site et AWS EC2 sont pris en charge.	OUI - Citrix Workspace est disponible dans Citrix Cloud Government.
Capacité à prendre en charge les clouds/environnements AWS gonflés sans connexion Internet sortante.	OUI - Les déploiements gérés par le client d’ADC/Gateway (et StoreFront) sont pris en charge pour les instances sur site et AWS EC2.	NON - Les environnements AWS à air gap n’ont pas accès à Citrix Cloud ou Citrix Cloud Government. Par conséquent, Gateway Service et Workspace Service ne sont pas disponibles pour le moment.

Résumé, recommandations et pratiques exemplaires

Maintenant que nous avons passé en revue certains des attributs/fonctionnalités/capacités qui vous aident à prendre des décisions relatives aux services gérés par le client par rapport aux services cloud pour les sous-systèmes de la couche d’accès, examinons les décisions de premier niveau dans le contexte des modèles de déploiement que nous avons définis précédemment.

Couche d’accès : Déploiement Greenfield/Cloud uniquement

Étant donné que le modèle de déploiement en champ vert ou cloud uniquement utilise des services cloud à tous les niveaux, les implications spécifiques d’AWS sur la conception de votre système de virtualisation Citrix sont simples : il n’y en a pas. Il n’est pas nécessaire de construire ou de configurer quoi que ce soit sur AWS car tout ce qui est nécessaire pour les services proxy UI et HDX est fourni pour vous, configuré et prêt à être mis à l’emploi.

La couche d’accès d’un déploiement Citrix est une exigence essentielle pour fournir des applications virtuelles et des postes de travail aux utilisateurs. Si un point d’accès est inaccessible ou échoue, les utilisateurs ne peuvent pas accéder à leurs ressources. La conception et la mise en œuvre du réseau peuvent être compliquées, mais avec NetScaler Gateway Service et Citrix Workspace, la redondance, le basculement, la maintenance et la présence globale font tous partie du package - sans aucune connaissance de la mise en réseau requise. L’utilisation de NetScaler Gateway Service et Citrix Workspace peut réduire votre l’empreinte de l’infrastructure substantielle. En déplaçant la couche d’accès vers un modèle de services cloud, les utilisateurs peuvent accéder en toute sécurité aux ressources réseau depuis n’importe où dans le monde. Cette approche requiert le moins d’efforts de déploiement et de maintenance. C’est pourquoi il s’agit d’une excellente option si vous voulez vous lancer rapidement, disposer d’un personnel informatique limité ou si l’infrastructure n’est pas votre objectif. Avec tout ce qui est préconfiguré, ce modèle de déploiement est le moins personnalisable, mais pour déployer un système simple, sécurisé, entièrement fonctionnel et accessible à l’échelle mondiale, l’utilisation de Citrix Workspace et Gateway Service pour votre couche d’accès est la solution à faire.

Couche d’accès : déploiement hybride

Avec le modèle de déploiement hybride, vous allez construire/gérer certains composants du système de virtualisation Citrix, sinon il s’agit d’un déploiement en champ vert ou cloud uniquement par définition. Avec le modèle hybride, vous déployez peut-être des VPX NetScaler ADC/Gateway sur AWS ou même sur site, et selon vos besoins, vous pouvez également déployer Citrix StoreFront sur AWS ou sur site. Les clients qui ont réalisé des investissements importants dans leurs solutions de passerelle et d’identité sur site peuvent bénéficier de la possibilité d’utiliser NetScaler Gateway comme fournisseur d’identité pour Workspace.

Ce modèle de déploiement est courant pour les déploiements axés sur la sécurité, les déploiements avec une infrastructure sur site actuelle (ADC ou StoreFront) et pour les sites DR/basculement pour les centres de données gérés par les clients existants. L’une des principales considérations de ce modèle est de garder vos utilisateurs, vos ressources et vos points d’accès aussi proches que possible. Choisissez les régions AWS situées à proximité des emplacements de ressources sur site dans lesquels déployer votre couche d’accès. Dans la mesure du possible, gardez vos ADC et vos serveurs StoreFront le plus près possible les uns des autres. C’est là que les choses peuvent devenir délicates. Tenez compte de la séquence de lancement de Citrix Virtual Apps and Desktops lors de la conception de votre déploiement hybride, en notant en particulier que tout le trafic est acheminé via NetScaler ADC.

Avec NetScaler ADC/Gateway et StoreFront comme instances EC2 dans AWS, il existe également beaucoup plus de possibilités de personnalisation. Outre les nombreux magasins StoreFront, l’authentification multifacteur et diverses fonctionnalités ADC de pointe, les déploiements hybrides peuvent également utiliser des services AWS natifs tels que RDS (Relational Database Service) et AWS Directory Services. Les déploiements hybrides se prêtent bien à une transition plus progressive dans le cloud et laissent de la place aux ajustements de l’architecture en cours de route, par opposition aux méthodes de levage et de décalage.

L’approche hybride exige un niveau d’expertise plus élevé et un délai de déploiement plus élevé que le modèle « Greenfield/Cloud uniquement », mais peut servir de solide état de transition entre un déploiement traditionnel géré par le client ou sur site et un état cloud uniquement.

Couche Access : Déploiement de levage et de déplacement

Avec le modèle de déploiement de levage et de transfert hérité, vous déployez à la fois NetScaler ADC/Gateway VPX et Citrix StoreFront sur AWS, ou réutilisez potentiellement des déploiements locaux existants de ces technologies dans le même but. Ce type de déploiement a tendance à avoir le moins de temps d’exécution pour les clients disposant d’environnements de virtualisation Citrix sur site existants, et constitue également la transition la plus facile du point de vue des opérations et de la maintenance. Le personnel ayant de l’expérience dans la gestion d’un environnement sur site a un temps de montée en puissance plus court avec le modèle de déploiement de levage et de changement de poste, l’infrastructure Citrix demeurant largement inchangée. Pour la couche d’accès en particulier, cette méthode est simple et permet de nombreuses personnalisations. Le lift-and-shift constitue une première étape formidable pour les déploiements existants qui entrent dans le cloud ou pour les régions AWS nouvelles ou à air gap, mais peut constituer un obstacle à l’adoption d’une architecture cloud forward à l’avenir.

NetScaler ADC/Gateway VPX sur AWS

Le déploiement de NetScaler ADC/Gateway sur AWS diffère du déploiement local, bien que vous les gérez vous-même. Heureusement, le déploiement de NetScaler ADC/Gateway sur AWS est entièrement documenté. Nous vous recommandons donc d’examiner les ressources suivantes avant de consolider votre conception et de commencer l’implémentation :

• NetScaler ADC VPX on AWS dans Citrix Docs : fournit une vue d’ensemble complète de NetScaler ADC sur AWS, y compris les modèles VPX pris en charge, les régions AWS, les types d’instances EC2 et des références de ressources supplémentaires.
• Conception de référence validée par NetScaler ADC et Amazon Web Services dans Citrix Docs/Advanced Concepts - inclut plus de détails et des conseils de déploiement.

Bien qu’il existe des variantes potentielles pour une architecture NetScaler ADC/Gateway VPX sur AWS, le schéma suivant (tiré du Guide de déploiement rapide de NetScaler ADC for Web Applications) décrit un déploiementde paires Citrix HA multi-AZ tel que déployé par le modèle Quick Start (avec des sous-réseaux par défaut/blocs d’adresse CIDR) :

Schéma 10 : Architecture conceptuelle, NetScaler ADC/Gateway VPX sur AWS avec HA dans les zones de disponibilité Schéma 10 : Architecture conceptuelle, NetScaler ADC/Gateway VPX sur AWS avec HA dans les zones de disponibilité.

Comme indiqué dans NetScaler ADC VPX on AWS sur Citrix Docs, deux options de déploiement principales sont disponibles. Ils sont :

• Autonome : les instances individuelles de NetScaler ADC/Gateway peuvent être déployées et gérées en tant qu’entités distinctes. Ceci est couramment utilisé pour les déploiements à petite échelle ou POC où la haute disponibilité n’est pas une exigence.

• Haute disponibilité : il s’agit du modèle le plus couramment déployé pour les environnements de production : des paires d’instances NetScaler ADC/Gateway VPX peuvent être déployées à l’aide du mode Citrix HA natif sur AWS. Avec les anciennes versions de microprogramme, la paire est déployée dans la même zone de disponibilité AWS. À partir du microprogramme NetScaler ADC 12.1, des paires d’appliances VPX hautement disponibles peuvent être déployées dans les zones de disponibilité (AZ). Lefonctionnement de la haute disponibilité sur AWS explique la différence entre le déploiement d’une paire d’ADC dans la même zone de disponibilité et entre zones de disponibilité. Nous creusons dans cette option plus loin dans cette section.

Alors que NetScaler ADC VPX prend généralement en charge des types de déploiement de cartes réseau uniques, doubles ou multiples, Citrix recommande d’utiliser au moins trois sous-réseaux pour chaque ADC lors du déploiement sur AWS, avec une interface réseau dans chaque sous-réseau pour un débit optimal et une séparation des données. Lorsqu’il est déployé pour prendre en charge Citrix Virtual Apps and Desktops, le NSIP est généralement attaché au « Private Citrix Infrastructure Subnet », le SNIP est attaché au « sous-réseau privé Citrix VDA », et le VIP NetScaler Gateway au « sous-réseau public. » Le diagramme conceptuel simplifié suivant illustre cette configuration. Il montre une seule instance VPX dans une seule AZ - ce modèle de conception serait dupliqué (probablement dans une seconde AZ) pour une configuration haute disponibilité :

Schéma 11 : Mappage de l’interface d’instance NetScaler ADC VPX pour les déploiements CVAD/DaaS Schéma 11 : Mappage de l’interface d’instance NetScaler ADC VPX pour les déploiements CVAD/DaaS.

Haute disponibilité ADC dans toutes les zones de disponibilité

Comme mentionné précédemment, il s’agit du modèle de déploiement le plus courant pour les systèmes de virtualisation Citrix. Ce modèle utilise une paire de VPX NetScaler ADC déployées dans les zones de disponibilité à l’aide de la fonctionnalité HA (actif/passive) native de NetScaler ADC ou d’une combinaison des fonctionnalités GSLB (Global Service Load Balancing) et IPset natives de NetScaler ADC. Cette dernière option (qui est devenue réalisable au début de 2020) permet une configuration active/active à travers les AZ, et des fonctions en permettant à l’ADC d’agir comme une source DNS faisant autorité. Cette nouvelle option/architecture devrait être populaire pour les déploiements de cloud public. Nous nous concentrons donc sur cela ici.

Les services basés sur le domaine pour les équilibreurs de charge cloud permettent la découverte automatique des services cloud dynamiques. En déployant NetScaler ADC sur plusieurs AZ dans une configuration active-active, vous pouvez utiliser des ressources cloud dans différents ZA pour optimiser la haute disponibilité et la reprise après sinistre. Chaque zone de disponibilité peut contenir des ressources cloud dans l’ infrastructure d’espacefamilière, afin de permettre une gestion facile des mises à jour, des correctifs et une évolutivité pour l’extension. Pour plus d’informations sur la configuration de GSLB entre les zones AWS, consultez la documentation Citrix.

Schéma 12 : Flux de trafic avant et après le basculement HA dans le déploiement HA multi-AZ Schéma 12 : Flux de trafic avant et après le basculement HA dans le déploiement multi-AZ HA.

Dans le diagramme précédent, nous pouvons voir que chaque ADC a une IP virtuelle de passerelle différente (VIP). Ceci est caractéristique d’une configuration réseau indépendante (INC). Lorsque les VPX d’une paire HA résident dans différentes zones de disponibilité, l’ADC secondaire doit avoir un INC, car ils ne peuvent pas partager des adresses IP mappées, des réseaux locaux virtuels ou des routes réseau. Le NSIP est différent pour chaque ADC dans cette configuration, tandis que les SNIP et les VIP d’équilibrage de charge utilisent une fonctionnalité spéciale de NetScaler ADC appelée IPSet, ou serveurs virtuels multi-IP, qui peuvent être utilisés pour que les clients de différents sous-réseaux se connectent au même ensemble de serveurs. Avec IPSet, vous pouvez associer une adresse IP privée à chacune des instances primaires et secondaires. Une adresse IP publique peut ensuite être mappée au ADC principal de la paire. En cas de basculement, le mappage IP public passe dynamiquement au nouveau serveur principal. Pour les déploiements GSLB dans AWS, l’adresse IP du service peut faire partie de l’IPset pour le trafic IPv4 et IPv6.

Pour plus d’informations sur l’ajout d’un nœud distant à un ADC afin de créer une paire HA basée sur INC, consultez la documentation Citrix.

Citrix StoreFront sur AWS

Le déploiement de Citrix StoreFront sur AWS n’est pas très différent du déploiement local. En fin de compte, vous gérez également tous les composants de StoreFront vous-même. Consultez Planifier votre déploiement StoreFront pour connaître les considérations générales qui s’appliquent à tous les déploiements, y compris StoreFront sur AWS. La principale différence réside dans le fait que vous déployez généralement plusieurs instances StoreFront dans un groupe de serveurs StoreFront sur plusieurs zones de disponibilité AWS. Il est important de noter que les fonctionnalités activées avec cette conception dépendent de la latence entre les AZ. Selon Planifier votre déploiement/évolutivité StoreFront, les déploiements de groupes de serveurs StoreFront ne sont pris en charge que lorsque les liens entre les serveurs d’un groupe de serveurs ont une latence inférieure à 40 ms (avec les abonnements désactivés) ou inférieure à 3 ms (avec les abonnements activés). Assurez-vous de mesurer les latences entre les instances de tous les AZs que vous prévoyez d’héberger StoreFront et activer/désactiver les abonnements en conséquence.

Nous l’avons déjà mentionné dans le tableau Considérations relatives au service d’interface utilisateur et à l’authentification plus haut dans ce document, mais cela vaut la peine de le rappeler à nouveau : pour les environnements Citrix DaaS avec des exigences de résilience étendues, Citrix recommande vivement une implémentation de StoreFront pour en tirer pleinement parti de la fonctionnalité Local Host Cache (disponible dans les types d’infrastructure de courtage de session CVAD et DaaS). Pour CVAD, cela fournit une résilience en cas de panne de base de données. Pour DaaS, cette architecture assure la résilience au cas où les Cloud Connector ne pourraient pas atteindre Citrix Cloud. Dans les deux cas, les utilisateurs déconnectés pourront toujours se connecter aux sessions nouvelles et existantes lors d’un scénario de panne. Pour plus de détails, les limites et les implications de l’activation du cache d’hôte local, consultez Cache d’hôte local (DaaS) et Cache d’hôte local (CVAD).

Bien que nous soyons sur le sujet de la résilience, Citrix recommande également que votre implémentation StoreFront couvre plusieurs AZ (si la région AWS inclut plusieurs AZ), mais n’oubliez pas de prendre en compte la conception ADC. NetScaler ADC est souvent utilisé devant les instances StoreFront pour fournir un équilibrage de charge et une résilience de service supplémentaire.

En utilisant Citrix Zones, la redondance StoreFront peut être intégrée en répartissant les zones satellites sur deux zones de disponibilité ou plus dans un VPC avec un seul site. L’utilisation de Zones est un excellent moyen d’avoir des ressources aussi proches que possible des utilisateurs et hautement disponibles. Les zones satellites contiennent des serveurs StoreFront, des Delivery Controller et des ressources application/poste de travail, laissant la zone principale avec la configuration complète de l’infrastructure, y compris le serveur de licences et SQL. Cela permet l’évolutivité de l’interface utilisateur Web StoreFront et la création/destruction de zone peut être orchestrée. Le fait de réduire les zones permettra une évolutivité est-ouest optimale et réduira l’impact en cas de panne.

StoreFront sur AWS est entièrement personnalisable, y compris les groupes d’applications en vedette, la page d’accueil, le coloriage et le logo, et les applications et les postes de travail peuvent être organisés de la meilleure façon pour vos besoins spécifiques. StoreFront sur AWS nécessite également une administration et une ingénierie expérimentées, mais peut fournir une interface utilisateur Web puissante, en particulier lorsqu’elle est intégrée à NetScaler ADC.

Considérations relatives à la couche

La conception de la couche de ressources se concentre sur la personnalisation, les applications et la conception d’images. La couche de ressources est l’endroit où les utilisateurs interagissent avec les postes de travail et les applications. Lors du déploiement d’un système de virtualisation Citrix sur AWS, les éléments clés à garder à l’esprit (mis à part tous les éléments « normaux » que nous ne couvrirons pas ici) sont les suivants :

• Stockage CIFS et réplication de données - Quel que soit l’outil que vous utilisez pour gérer les paramètres de personnalisation utilisateur (profil Windows des utilisateurs et dossiers redirigés), vous devez disposer de partages de fichiers Windows pour les stocker. Si vous avez des VDA dans plusieurs régions (et que les utilisateurs peuvent accéder à des applications/postes de travail dans plusieurs régions), vous devez également gérer la réplication des données. De nombreuses applications utilisent également des partages de fichiers Windows, de sorte que le stockage CIFS et la réplication de données sont également importants pour ceux-ci.
• Conception d’images - Citrix App Layering et Citrix Provisioning Services (PVS) ne prennent pas en charge Amazon EC2. Les clients hébergeant un emplacement de ressources dans AWS utilisent Machine Creation Services pour la création, la gestion et la mise à jour de flotte de VDA.

Stockage CIFS et réplication de données

La plupart des systèmes de virtualisation Citrix sur AWS nécessitent au moins un accès de base à un partage de fichiers compatible Windows pour conserver les paramètres utilisateur, les données utilisateur et les données d’application. Lorsque ces partages ne sont pas disponibles, l’expérience utilisateur et les fonctionnalités de l’application en souffrent. Il est donc important de s’assurer que la solution que vous choisissez de fournir des partages de fichiers compatibles avec Windows est hautement disponible et que les données sont régulièrement sauvegardées.

Pour les déploiements multi-sites, une réplication fiable et performante des données peut également être nécessaire pour répondre aux besoins de disponibilité, de RPO et de RTO. Cela est particulièrement vrai pour les environnements où les utilisateurs peuvent se connecter à des bureaux/applications dans 2 régions ou plus, et les données d’application/paramètres utilisateur doivent être disponibles dans la région où les applications/postes de travail s’exécutent. La section suivante décrit certaines solutions à envisager pour fournir des services de stockage et de réplication de données CIFS sur AWS.

Bien qu’il existe des solutions autres que Windows pour fournir des partages de fichiers Windows, la plupart de ces solutions ne peuvent pas fournir les fonctionnalités d’indexation requises pour la fonctionnalité de recherche dans un bureau Windows ou dans des applications telles que Microsoft Outlook s’exécutant sous Windows. Ainsi, la plupart des clients se tournent vers des solutions de serveur de fichiers Windows, au moins pour stocker des profils utilisateur et des données d’application persistantes. Heureusement, les options de service géré par le client et de service cloud sont disponibles lorsque les systèmes de virtualisation Citrix sont exécutés sur AWS.

Géré par le client : Serveurs de fichiers Windows sur Amazon EC2

La première solution envisagée par de nombreux clients pour fournir des services de fichiers compatibles avec Windows sur AWS consiste à construire leurs propres serveurs de fichiers Windows sur EC2 pour servir chaque emplacement de ressources sur AWS. Étant donné que les serveurs de fichiers Windows sont nécessaires pour différents types d’applications et de charges de travail, de nombreux ateliers informatiques peuvent se tourner vers la création et la gestion des leurs propres, car c’est quelque chose qu’ils savent faire. Au niveau le plus élémentaire, le client active une ou plusieurs instances Windows EC2, attache un volume supplémentaire Amazon Elastic Block Store (EBS), joint l’instance à son Active Directory et se charge de configurer et de configurer les services de fichiers Windows.

Cette option, comme vous pouvez l’imaginer, offre aux clients le plus de contrôle et de flexibilité. Bien que cela soit très attrayant pour certains types de clients et certains secteurs verticaux, cela a également un coût : la responsabilité de dimensionner, de mettre à l’échelle, de construire, de gérer, de corriger, de sécuriser et de maintenir tout, depuis le système d’exploitation Windows jusqu’à. Les clients qui choisissent d’emprunter cette voie devraient également s’assurer que ces serveurs de fichiers sont hautement disponibles. Cela se fait souvent en utilisant des serveurs de fichiers dans plusieurs zones de disponibilité et en utilisant Windows DFS-N/DFS-R, bien qu’il soit facile de se retrouver dans une configuration non prise en charge (selon Microsoft) si vous ne faites pas attention.

Remarque : les clients qui envisagent cette option doivent consulter la déclaration de support de Microsoft concernant l’utilisation de DFS-R et DFS-N pour les partages de profils itinérants et les partages de redirection de dossiers. Un point supplémentaire à prendre en compte étant donné que le système de virtualisation Citrix sera exécuté sur AWS : un nouvel événement de déploiement ou de migration peut être une excellente occasion d’évaluer l’utilisation d’un service cloud pour les services de fichiers Windows au lieu de créer le vôtre. Heureusement, Amazon a quelques options de service cloud qui méritent d’être envisagées. On touche à certains d’entre eux maintenant.

Service Cloud : Serveur de fichiers Amazon FSX pour Windows

Leserveur de fichiers FSx pour Windows d’Amazon est un service cloud que les clients peuvent utiliser sur AWS. FSx for Windows File Server fournit un système de fichiers Windows natif entièrement géré et un stockage SSD avec des performances en sous-milliseconde cohérentes. Étant donné que FsX est construit sur Windows Server, il fournit un système de fichiers entièrement natif et compatible Windows qui fournit un stockage et une protection pour les systèmes de virtualisation Citrix sur AWS. FsX pour Windows File Server est également Citrix Ready Verified, ce qui signifie que cette solution prise en charge par AWS a été validée par Citrix pour être compatible avec Citrix Virtual Apps and Desktops. Bien qu’il ne soit pas officiellement pris en charge par Citrix, le service est fondamentalement natif serveur de fichiers Microsoft Windows - il est simplement géré par AWS au lieu du client. Pour plus d’informations, consultez Amazon FSX pour Windows File Server sur Citrix Ready.

Pour les équipes informatiques, il s’agit d’une excellente option qui supprime la plupart des tâches les plus banales ou de faible valeur liées au déploiement et à la gestion du stockage. Plus important encore, l’utilisation de FSx décharge les tâches de sécurité, de protection et de sauvegarde des données, de conformité, de mise à jour logicielle et de mise à jour logicielle et de surveillance de l’infrastructure de stockage pour s’assurer qu’elle répond aux niveaux de service requis. Les équipes informatiques peuvent traiter l’ensemble du service de fichiers FSx comme une plate-forme opérationnelle unique au lieu de gérer un serveur de fichiers du système d’exploitation Windows, le stockage, la mise en réseau, etc. En outre, FSx prend en charge tous les outils de gestion courants qu’il utilise déjà, tels que l’intégration Active Directory (AD), les espaces de noms Windows DFS, la réplication DFS, etc.

Chaque système de fichiers géré par FSx que vous créez devient essentiellement un serveur de fichiers hautement disponible et durable dans une zone de disponibilité spécifique. Pour la maintenance d’un système de virtualisation Citrix, les clients doivent s’assurer que ces « systèmes de fichiers » sont hautement disponibles. Cela peut être réalisé en provisionnant des systèmes de fichiers gérés FSx dans plusieurs zones de disponibilité et en utilisant Windows DFS-N/DFS-R pour créer des partages de fichiers Windows hautement disponibles, bien qu’il soit facile de se retrouver dans une configuration non prise en charge (selon Microsoft) si vous ne faites pas attention.

Remarque : étant donné que FSx est un serveur de fichiers Windows, les clients qui envisagent cette option doivent consulter la déclaration de support de Microsoft concernant l’utilisation de DFS-R et DFS-N pour les partages de profils itinérants et les partages de redirection de dossiers.

Plus d’options de service cloud

Outre le service de fichiers Windows géré par Amazon, AWS prend en charge de nombreuses options étendues et riches en fonctionnalités, dont certaines s’intègrent aux technologies de stockage sur site traditionnelles. Bien que ces autres options ne soient pas couvertes par le présent document, il existe de nombreuses options à choisir. L’ AWS Marketplaceconstitue un bon point de départ pour explorer les options. Ces types de solutions peuvent être particulièrement pertinents pour des cas d’utilisation plus complexes et multirégions où une réplication fiable et résiliente des données est nécessaire.

Stockage CIFS et réplication des données : résumé et conclusions

Les clients peuvent gérer leur propre partage de fichiers DFS hautement disponible, en bénéficier en tant que service AWS (FSx) pour économiser sur les efforts de gestion ou utiliser des solutions d’appliance de stockage tierces pour étendre leurs activités sur un environnement local. Citrix recommande aux clients d’analyser les avantages et les inconvénients de chacun afin de déterminer la solution qui leur convient.

Conception et gestion d’images

Dans un système de virtualisation Citrix sur AWS, les applications et les postes de travail sont fournis via des instances EC2 appelées « VDA » (nommé d’après le logiciel Virtual Delivery Agent de Citrix, qui est installé dans des instances Windows ou Linux contenant les applications fournies par le système de virtualisation Citrix). Un groupe de VDA identiques est provisionné et maintenu dans des « catalogues de machines », une structure de gestion définie et maintenue via le sous-système de négociation et de gestion de session (DaaS et CVAD). La création, le dimensionnement et la gestion de ces instances sont essentielles, car de nombreux systèmes ont un grand nombre de VDA et la pile logicielle d’un VDA change fréquemment au fur et à mesure que les correctifs, les Service Packs et les mises à jour logicielles sont appliqués. Nous discutons de certaines des considérations de niveau supérieur dans cette section.

Provisioning VDA et gestion des images

Sur AWS EC2, les systèmes de virtualisation Citrix utilisent la technologie de provisionnement Machine Creation Services (MCS) de Citrix pour le déploiement VDA et la gestion des images. MCS utilise un compte de service IAM sur EC2 pour orchestrer le processus de mastering (transformation d’un instantané du disque système d’une machine virtuelle modèle en AMI généralisée), le processus de clonage (création et gestion d’un parc d’instances VDA basées sur l’AMI créée à partir de l’instantané de la machine virtuelle modèle), mise à l’échelle automatique de la distribution Groupes, mise à jour des images déployées, etc. Nous aborderons MCS sur AWS de manière beaucoup plus détaillée dans les sections Considérations relatives à la couche de contrôle de ce document.

Remarque : les clients qui utilisent déjà MCS pour leurs environnements locaux peuvent remarquer certaines différences entre les options qui leur sont offertes lors du provisionnement de machines dans AWS. Les instances VDA gérées par MCS sur EC2 sont reliées à deux disques : le disque système (une copie en lecture/écriture de l’AMI d’image modèle créée au cours du processus de mastering) et un disque de personnalité de 1 Go. Selon le type de catalogue de machines et les options de connexion d’hébergement configurées, le disque système (et parfois l’instance de machine virtuelle) sera supprimé à l’arrêt et recréé à la mise sous tension (pour les catalogues groupés ou partagés) ou conservés (pour les types de catalogue persistants). Voir CTX234562 pour plus d’informations.

Modèles de livraison et de persistance

Le choix des bons modèles de prestation est essentiel et a de vastes implications au-delà du simple coût. La technologie de virtualisation Citrix prend en charge trois modèles de livraison principaux, qui peuvent être mélangés et appariés et utilisés en combinaison pour prendre en charge de nombreux cas d’utilisation différents. Les trois modèles de prestation sont les suivants :

• Hébergé partagé : le modèle partagé hébergé utilise le plus souvent un système d’exploitation Windows Server avec le rôle RDSH installé, bien que les instances Linux puissent fournir les mêmes fonctionnalités pour les applications compatibles. Avec ce modèle, une seule instance VDA peut prendre en charge plusieurs utilisateurs simultanés, exécutant chacun un poste de travail complet ou se connectant à une ou plusieurs applications publiées. Lorsque vous utilisez Windows Server OS/RDSH avec l’Expérience de bureau et les composants associés installés, les postes de travail et les applications semblent s’exécuter sur un système d’exploitation de bureau Windows. Étant donné que chaque utilisateur d’une instance donnée partage une instance de système d’exploitation, les administrateurs préinstallent et configurent généralement la combinaison d’applications sur les instances partagées hébergées, et les utilisateurs ne disposent pas des droits d’administrateur local sur le système d’exploitation. Les instances partagées hébergées peuvent également s’exécuter sur une infrastructure partagée et peuvent être consommées à l’aide de modèles de tarification des instances réservées et à la demande. Les administrateurs déploient généralement une flotte d’instances pour prendre en charge le modèle partagé hébergé, et les types de services gérés par le client et de services cloud de sous-systèmes Citrix Brokering fournissent des fonctionnalités sophistiquées d’équilibrage de charge pour garantir à chaque utilisateur des performances adéquates. Les instances partagées hébergées peuvent également utiliser des types d’instance sauvegardés par GPU sur AWS pour augmenter les performances des charges de travail à forte intensité graphique qui peuvent bénéficier d’un GPU, bien que le fournisseur de GPU puisse exiger des licences supplémentaires. Les licences d’OS Windows Server et de licence d’accès client RDS peuvent être « louées » sous le modèle de licence SPLA de Microsoft, bien que les clients puissent éviter ces coûts supplémentaires en utilisant Linux comme système d’exploitation. Ce modèle est, mains vers le bas, le plus rentable à exécuter sur AWS.
• Serveur VDI : Le modèle « Serveur VDI » (Virtual Desktop Infrastructure) utilise également un système d’exploitation Windows Server, et avec l’expérience de bureau et les composants associés installés, il ressemble à l’utilisateur comme un OS de bureau Windows. Le rôle RDSH n’est pas installé avec ce modèle, donc une instance prend en charge un utilisateur à la fois, et les utilisateurs disposent parfois de droits élevés sur le système d’exploitation du serveur afin qu’ils puissent installer leurs propres applications. Comme les instances partagées hébergées, les instances VDI serveur peuvent également s’exécuter sur une infrastructure partagée, être consommées en utilisant des modèles de tarification des instances réservées et à la demande, peuvent utiliser des types d’instance sauvegardés par GPU, et les licences d’accès client Microsoft OS et RDS peuvent être « louées » sous le modèle de licence SPLA de Microsoft. Compte tenu des outils disponibles aujourd’hui, 99+% des applications Windows peuvent être installées et exécutées sur le système d’exploitation Windows Server, et bien que les fournisseurs de logiciels ne prennent pas en charge explicitement leurs applications sur Windows Server, la plupart des applications Windows fonctionnent aussi bien sur Windows Server que sur un OS de bureau Windows. Il est également intéressant de noter que les instances VDI serveur peuvent également utiliser des types d’instance sauvegardés par GPU sur AWS pour augmenter les performances des charges de travail graphiques intensives qui peuvent bénéficier d’un GPU, bien que le fournisseur du GPU puisse exiger d’autres licences. Il s’agit du deuxième modèle de livraison le plus rentable à exécuter sur AWS.
• VDI client : le modèle de livraison VDI client utilise généralement un système d’exploitation de bureau Windows tel que Windows 10 ou Windows 7, bien qu’une version du système d’exploitation Linux prise en charge puisse également être utilisée. Client VDI est un modèle 1:1, ce qui signifie que chaque utilisateur unique a besoin de sa propre instance de système d’exploitation. Les clients qui sont nouveaux dans la technologie de virtualisation Citrix se livrent souvent à ce type de projets demandant un VDI client, même si des modèles plus rentables sont disponibles. Leur version vernaculaire peut également avoir été influencée par d’autres fournisseurs de virtualisation dont les piles technologiques ne prennent pas en charge les modèles de déploiement VDI partagé ou serveur hébergé. Le modèle VDI client, tout en étant « simple » à la surface, devient beaucoup plus compliqué à mesure que vous y pénétrez, bien que la plupart de la complexité puisse être évitée en utilisant Linux comme système d’exploitation. La plupart de cette complication est due aux exigences de licence de Microsoft pour le système d’exploitation de bureau Windows qui, contrairement à Windows Server, n’est pas disponible via le programme de licences SPLA de Microsoft. En tant que tel, les clients doivent apporter leur propre licence pour ces produits. En outre, les instances VDI client basées sur le bureau Windows ne peuvent pas s’exécuter sur une infrastructure partagée. Cela signifie que les instances VDI client doivent s’exécuter dans des instances dédiées AWS ou sur des hôtes dédiés AWS. Cela augmente considérablement le coût et la complexité de la gestion de l’infrastructure requise, réduit la flexibilité et les options de contrôle des coûts et devient rapidement coûteuse. Comme vous pouvez vous y attendre, les instances VDI client peuvent également utiliser des types d’instance sauvegardés par GPU sur AWS pour augmenter les performances des charges de travail graphiques intensives qui peuvent bénéficier d’un GPU, bien que le fournisseur du GPU puisse exiger davantage de licences. Le VDI client est le modèle de livraison le plus coûteux à exécuter sur AWS. Pour les deux modèles VDI, un autre facteur important est le modèle de persistance. Les instances VDI peuvent être attribuées de manière aléatoire à des utilisateurs sans persistance (regroupées) ou les utilisateurs peuvent avoir des machines affectées qui persistent et sont personnalisées (dédiées). Les instances groupées peuvent être plus faciles à gérer au fil du temps car toutes les instances d’un pool donné sont identiques. Le MCS de Citrix peut mettre à jour les disques système attachés aux instances groupées en quelques clics, et la gestion des capacités/coûts est plus efficace car un pool d’instances inactives peut servir de nombreux utilisateurs. Les instances groupées sont un peu moins flexibles que les instances dédiées, car les modifications apportées par l’utilisateur final aux instances groupées ne persistent généralement pas entre les redémarrages, bien que des technologies telles que la couche utilisateur de Citrix App Layering ou la couche de personnalisation publiées dans CVAD 1912 peuvent être utilisées pour minimiser l’impact sur l’expérience utilisateur. Les instances dédiées peuvent également être plus difficiles à gérer du point de vue des coûts - car il est souvent difficile de prédire quand un utilisateur se connectera, l’utilisateur doit soit attendre le démarrage de son instance, soit les administrateurs doivent les maintenir en cours d’exécution pendant les fenêtres temporelles où chaque utilisateur est censé ouvrir une session.

Bien que nous l’ayons déjà mentionné, nous allons le mentionner ici pour plus de clarté : différentes saveurs de Linux peuvent être utilisées dans un système de virtualisation Citrix, tant qu’une ou plusieurs applications fonctionnent sous Linux. La technologie de virtualisation de Citrix prend en charge les modèles de livraison partagés et VDI hébergés, les modèles persistants et groupés et les types d’instance sauvegardés par GPU. Les expériences utilisateur et administrateur sont différentes de celles des instances Windows, mais les VDA basés sur Linux sont souvent beaucoup moins chers à exécuter car ils ne nécessitent pas de licences Microsoft.

Enfin, revoyons la prise en compte de l’accélération GPU. Les trois modèles de distribution (Linux et Windows) peuvent utiliser des instances GPU accélérées NVIDIA sur AWS. Les instances de la série G peuvent être utilisées pour des cas d’utilisation accélérés graphiques, mais ne sont pas encore commercialement viables pour une utilisation générale. Notez que Citrix ne prend pas en charge le GPU AWS Elastic aujourd’hui, mais comme Elastic GPU ne fonctionne que pour OpenGL, son impact sur les charges de travail graphiques typiques dans l’entreprise est minime.

Alors - quels modèles de livraison utilisez-vous ? Il est à noter que vous pouvez combiner et associer des modèles de livraison dans le même système pour répondre aux besoins de différents groupes d’utilisateurs ou cas d’utilisation. Le modèle de prestation le plus rentable du point de vue de l’infrastructure est partagé par l’hôte. La combinaison du système d’exploitation serveur et de la simultanéité multi-utilisateurs est extrêmement efficace, et le nombre d’utilisateurs par machine virtuelle peut être dimensionné en conséquence en fonction du type d’utilisateur (par exemple - travailleur de tâches par rapport au travailleur de la connaissance par rapport à l’utilisateur avec puissance) pour garantir une expérience optimale. Pour les situations où les utilisateurs et les applications nécessitent des fonctionnalités supplémentaires qui ne sont pas satisfaites par le partage d’hôte, VDI est la solution à suivre. Le VDI serveur doit être évalué en premier : il est nettement plus rentable à exécuter que Windows 10 VDI pour les charges de travail Windows, et Server VDI peut fournir un bureau qui ressemble et se sent similaire à Windows 10. En outre, le serveur VDI n’a pas l’exigence du CLUF Microsoft pour utiliser des instances/hôtes dédiés - le VDI client (déploiement de Windows 10 ou parfois Windows 7) le fait. Pour les charges de travail basées sur Windows sur AWS, le VDI client doit être considéré comme un dernier recours et déployé uniquement lorsque les modèles de livraison VDI partagés hébergés et Server ne sont pas possibles.

Pour faciliter le processus de prise de décision, l’arbre de décision suivant compare les bureaux partagés hébergés (postes de travail multi-utilisateurs avec OS de serveur) et les postes de travail VDI. L’arborescence ne fait pas de distinction explicite entre les modèles VDI client et VDI serveur. Lorsqu’un cas d’utilisation suggère que VDI est le modèle de livraison approprié pour votre charge de travail, le VDI serveur doit être pris en compte dans la mesure du possible pour s’exécuter sur AWS, car il est beaucoup plus rentable et plus facile à gérer.

Modèle de facturation d’instance AWS

Une fois que vous avez choisi le modèle de livraison à utiliser (partagé par l’hôte, VDI serveur ou VDI client), l’étape suivante consiste à planifier un modèle de facturation horaire à la demande ou un modèle de facturation réservé. Idéalement, le plus grand nombre possible de VDA doivent être payés à l’heure avec le modèle de facturation à la demande et utiliser la fonctionnalité Citrix Autoscale pour contrôler les coûts. En utilisant Citrix Autoscale (une fonctionnalité exclusive au sous-système de courtage de services cloud DaaS), les machines virtuelles sont mises sous tension selon les besoins avec anticipation des heures de pointe. Cependant, pendant les heures de pointe, les machines virtuelles sont arrêtées. Il est donc important de consolider les charges avec le modèle partagé par l’hôte et, pour tous les modèles, veiller à ce que les utilisateurs enregistrent leur travail et, idéalement, se déconnectent gracieusement de leurs sessions. La capacité d’instance réservée peut être utilisée pour des composants d’infrastructure tels que les Cloud Connector (qui restent sur 24/7) et un nombre prédéterminé de VDA qui resteront toujours actifs (par exemple, 10% des pics). En plus d’offrir une réduction significative par rapport à la tarification à la demande, les instances de réserve fournissent également une réservation de capacité lorsqu’elles sont utilisées dans une zone de disponibilité spécifique.

Dimensionnement des instances VDA et gestion des coûts

Lors de l’exécution d’un parc de VDA sur AWS, le choix du type d’instance approprié pour vos différentes charges de travail (VDA) est une décision clé, avec des considérations importantes en termes de performances, de facilité de gestion et de coûts. Choisissez une instance trop petite et les performances peuvent en souffrir. Choisissez une instance trop grande et vous payez pour des ressources que vous n’utilisez pas. Choisir le bon type d’instance finit par être un acte d’équilibrage et nécessite souvent un réglage précis pour chaque charge de travail spécifique.

Le type d’instance AWS EC2 à choisir pour vos VDA dépend fortement de la charge de travail et du type de livraison spécifiques. Cependant, en règle générale, les instances de la série « M » conviennent souvent le mieux aux instances partagées par hôte, alors que les instances de la série « T » conviennent à VDI. La série « M » dispose d’un processeur et d’une RAM équilibrés conçus pour une consommation de ressources prévisible sur plusieurs sessions sur un hôte. Les séries « T » sont « extensibles » et conçues pour les caractéristiques principalement imprévisibles de VDI (par exemple - une minute un utilisateur est au ralenti et la suivante ils exécutent un calcul macro). Pour plus de détails sur la sélection du type d’instance et la tarification, les lecteurs peuvent consulter la présentation sur l’estimation des coûts Citrix on AWS (dans la section sources).

Pour plus d’informations sur la sélection d’instance (en particulier en ce qui concerne le modèle de mise à disposition partagée hébergée), consultez Citrix Scalability in a Cloud World - 2018 Edition. Cet article, bien qu’il soit légèrement daté, traite des pratiques de pointe concernant la sélection des instances en fonction des performances, de la facilité de gestion, du coût, des modèles de tarification réservés par rapport aux modèles de tarification à la demande et des tests d’évolutivité LogInVSI. Ces concepts et considérations sont toujours valables aujourd’hui, même si le choix des instances et la tarification ont probablement changé depuis sa publication initiale.

Remarque : certains nouveaux types d’instances AWS n’apparaîtront pas par défaut dans l’assistant de création de catalogue de machines de Studio (CVAD ou DaaS). L’interface utilisateur est remplie de types d’instances provenant d’un fichier XML statique résidant sur des Delivery Controller (CVAD) ou des Cloud Connector (DaaS). Ce fichier XML peut être modifié pour inclure des types d’instance plus récents, mais ce fichier est remplacé par des valeurs par défaut lors des mises à niveau (mises à jour Cloud Connector initiées par Citrix ou mises à niveau de Delivery Controller initiées par le client). Consultez le document CTX139707 pour plus de détails sur la façon de mettre à jour la liste des types d’instances AWS disponibles. Au cours de cette série de tests (référence ponctuelle), le type d’instance M5.2Xlarge (8 vCPU, 32 Go de RAM) s’est révélé le gagnant en termes de $/utilisateur/heure (avec une charge de travail d’échantillon standard). Vos chiffres - compte tenu de vos caractéristiques de charge de travail spécifiques et de la tarification AWS disponible - peuvent varier, mais le processus et l’outillage peuvent être utilisés pour estimer plus précisément vos coûts IaaS mensuels. Quelle que soit la façon dont vous déterminez les types d’instance que vous commencez, il est important de surveiller l’utilisation dans le temps et de les ajuster au besoin afin de maintenir l’équilibre entre la disponibilité des ressources, la consommation et le coût. Les clients doivent envisager d’utiliser des services tels que Citrix Analytics for Performance. Les informations fournies par ces services peuvent jouer un rôle clé dans le maintien des performances et de la réduction des coûts.

Conception de l’application

Une considération supplémentaire inclut la conception de l’application. Alors que les clients prévoient de migrer leurs charges de travail vers une plate-forme cloud telle qu’AWS, ils doivent veiller à ce que les performances de l’application ne soient pas affectées. Une règle générale qui s’applique depuis plus de 20 ans est que les données doivent se situer le plus près possible de la charge de travail. Cela signifie que les architectures d’applications plus complexes devraient respecter cette règle. Un exemple de ceci inclut des applications avec un front-end et un back-end (base de données). Pour éviter d’ajouter de la latence qui aura un impact sur les performances de l’application, les deux front-end et back-end doivent être migrés. Une autre solution serait une approche hybride utilisant un mélange de charges de travail sur site (pour les applications complexes) et hébergées dans le cloud (pour les applications simples). Il est important de toujours consulter les fournisseurs d’applications pour la compatibilité. La matrice décisionnelle liée Tech Zone compare les différentes méthodes de diffusion hébergées partagées, notamment les applications partagées hébergées (uniques et multi-usages) et les bureaux partagés hébergés. Le processus décisionnel de segmentation de la charge de travail décrit dans cet article peut être utilisé comme guide pour le processus de conception de la charge de travail.

Dernier mot sur la conception des applications, l’appliance Enterprise Layer Manager ne s’exécute pas actuellement sur AWS et ne prend pas en charge actuellement l’exportation d’images en couches dans un format de disque immédiatement consommable pour une utilisation sur AWS. Si la prise en charge d’App Layering sur AWS est essentielle pour votre migration ou votre déploiement, envoyez un e-mail à aws@citrix.com avec des informations sur votre projet. Vous serez ajouté à la liste pour être un candidat à l’adoption précoce pour les prochaines versions, et votre voix sera entendue. Pour plus d’informations sur Citrix App Layering, consultez la documentation produit et l’ architecture de référence App Layering.

Considérations relatives à la couche

Dans Citrix Architectural Design Framework, la couche Control définit les composants qui contrôlent la solution Citrix. Cela inclut des composants tels que Active Directory (forêt/domaine, unité d’organisation et structure de groupe d’utilisateurs, stratégies de groupe, etc.), l’utilisation de la base de données Microsoft SQL, les licences Citrix, le courtage et l’administration de sessions, la gestion de la charge et le provisionnement VDA et la gestion des images. Comme pour les sections précédentes de ce document, nous nous concentrons ici sur les considérations les plus importantes pour les systèmes de virtualisation Citrix sur AWS et fournissons des liens vers des documents/conseils existants sur d’autres.

L’une des décisions les plus importantes que vous prenez pour les composants de la couche de contrôle est le choix du courtage de session et de l’administration. Cette décision est cruciale, avec des répercussions importantes sur les coûts, la complexité, la disponibilité et les efforts de maintenance continus. Nous commençons par passer en revue les modèles de déploiement que nous avons introduits plus haut dans ce document, puis approfondissons les considérations spécifiques à AWS.

Couche de contrôle : Déploiement Greenfield/Cloud uniquement

Le modèle de déploiement en champ vert ou cloud uniquement utilise des services cloud à l’échelle de la société. n). Les implications spécifiques d’AWS sur la conception de votre système de virtualisation Citrix sont minimes, mais nous vous les présentons quand même. Étant donné que Citrix Cloud fournit la plupart des composants d’infrastructure et d’administration en tant que service, vous n’aurez pas à vous soucier des bases de données SQL, des serveurs de licences Citrix, des serveurs Citrix Director et plus encore.

Couche de contrôle : déploiement hybride

N’oubliez pas qu’avec le modèle de déploiement hybride, vous allez construire/gérer certains composants du système de virtualisation Citrix, sinon il s’agit d’un déploiement en champ vert ou cloud uniquement par définition. Ce qui est intéressant ici, c’est que, dans le contexte de la couche Control, ils sont presque identiques.

Couche de contrôle : Déploiement de levage et changement

Avec le modèle de déploiement de levage et de décalage hérité, vous déployez tous les composants de couche de contrôle clés (y compris Active Directory et tous les composants de courtage et de gestion de session Citrix) sur AWS. Si vous devez descendre le chemin « soulever et déplacer », c’est à la fois une bénédiction et une malédiction. C’est une bénédiction en ce que la plupart de ces considérations ont été documentées en profondeur dans divers ouvrages publiés qui sont déjà disponibles. C’est une malédiction en ce sens que vous aurez beaucoup plus de travail à faire à la fois à l’avance et au fil du temps pour construire, gérer, sécuriser et entretenir ces composants.

Si vous êtes un « lifter et shifter », vous souhaitez examiner et référencer les éléments suivants avant de continuer : collectivement, ils couvrent la plupart des décisions de conception que vous devez considérer pour réussir le déploiement de Citrix sur AWS à l’aide du modèle de déploiement lift and shift :

• Utilisation d’AWS Directory Service et d’Amazon RDS avec Citrix Virtual Apps and Desktops (blog)
• Déploiement de Citrix Virtual Apps and Desktop avec AWS Directory Service et Amazon RDS - Version 1.0 (guide de déploiement)

Considérations sur Active Directory

Tous les modèles de déploiement pour les systèmes de virtualisation Citrix sur AWS nécessitent Microsoft Active Directory. Pour une expérience utilisateur convaincante, les services Active Directory fonctionnels doivent être disponibles dans toutes les régions AWS où vous avez déployé des VDA. La structure et la complexité de votre implémentation Active Directory doivent être soigneusement prises en compte, mais heureusement, la virtualisation Citrix peut s’intégrer de manière flexible à différents modèles et modèles de maintenance AD.

Lors du déploiement d’Active Directory sur AWS, les clients peuvent créer/gérer leurs propres contrôleurs de domaine Active Directory à l’aide d’instances Windows Server, utiliser AWS Directory Service for Microsoft Active Directoryou une combinaison des deux. Les approbations Active Directory peuvent également être utilisées pour connecter au moins deux forêts/domaines AD selon les besoins du client.

Pour les clients qui cherchent à minimiser les frais administratifs nécessaires pour créer et maintenir des services Active Directory fonctionnels, AWS Directory Service for Microsoft Active Directory (également connu sous le nom d’AWS Managed Microsoft AD) est une option qui mérite d’être envisagée. Ce service vous fournit une forêt/domaine Active Directory entièrement fonctionnelle sans avoir à créer et à entretenir des instances de machine virtuelle Windows Server. AWS Managed Microsoft AD s’appuie sur une infrastructure gérée par AWS hautement disponible. Chaque répertoire est déployé sur plusieurs zones de disponibilité, et la surveillance détecte et remplace automatiquement les contrôleurs de domaine qui échouent. En outre, la réplication des données et les instantanés quotidiens automatisés sont configurés pour vous. Vous n’avez pas besoin d’installer le logiciel, et AWS gère tous les correctifs et les mises à jour logicielles. Avec AWS Managed Microsoft AD, vous pouvez utiliser des outils d’administration Microsoft natifs, gérer les machines Windows et les utilisateurs avec la stratégie de groupe Microsoft, y joindre des instances EC2 et AWS RDS pour SQL Server, et même configurer des approbations Active Directory avec des instances AD existantes pour prendre en charge diverses entreprises complexes scénarios.

Les clients qui choisissent d’utiliser le service AWS Managed Microsoft AD avec les technologies de virtualisation Citrix peuvent s’attendre à ce que ces technologies fonctionnent avec ce service AWS, bien qu’il y ait quelques considérations importantes à prendre en compte avant de le faire. Pour commencer, vous n’aurez pas accès à l’administrateur de domaine, à l’administrateur d’entreprise ou à un autre type « super utilisateur » à l’instance AD. Vous avez toutefois le contrôle total de votre propre conteneur à la racine du répertoire où vous pouvez créer des utilisateurs, des ordinateurs, des groupes, des unités d’organisation et des stratégies de groupe.

Quelques autres choses que vous NE POUVEZ PAS faire :

• Créez des objets AD dans l’un des conteneurs par défaut (tels que /Ordinateurs) : ils sont en lecture seule. Cela fait apparaître une erreur courante commise par certains clients lors de l’utilisation de la technologie de provisioning MCS de Citrix : vous devez choisir de créer les comptes de machine pour vos VDA gérés MCS dans un conteneur/unité d’organisation accessible en écriture - si vous ne choisissez pas un tel emplacement, MCS ne pourra pas créer les comptes de machine.
• Installez et configurez certaines fonctionnalités intégrées AD telles que les services de certificats. En tant que tel, cela affecte les clients qui utiliseront la technologie FAS (Federated Authentication Services) de Citrix (qui nécessite des services de certificats intégrés AD) : ces clients doivent créer et gérer leur propre Active Directory sur AWS à l’aide d’instances Windows Server EC2.
• Avoir l’équivalence de l’administrateur de serveur local par défaut. Dans une installation Active Directory « Out of the box », le groupe Administrateurs de domaine est ajouté au groupe Administrateurs de serveur local par défaut. Si vous utilisez le service AWS Managed Microsoft AD, vous devez créer votre propre groupe d’administrateurs de serveur, y ajouter vos propres utilisateurs, créer et appliquer une stratégie de groupe pour ajouter votre groupe au groupe Administrateurs de serveur intégré sur les serveurs/stations de travail membres.

Bien que les relations d’approbation, la configuration du site/service, la réplication et d’autres rubriques liées à AD ne soient pas abordées dans ce document, Citrix a fourni une documentation détaillée sur ces sujets applicables aux trois modèles de déploiement.

**Remarque : ** AWS Directory Service for Microsoft Active Directory est une offre « Citrix Ready Verified ». Bien qu’il ne soit pas officiellement pris en charge par Citrix, le service est fondamentalement natif Microsoft Active Directory - il est simplement géré par AWS au lieu du client. Ce service AWS est soumis à certaines restrictions pour le fournir en tant que service à grande échelle, et les limitations actuellement connues/les plus importantes pour un environnement Citrix sont répertoriées ici. Pour plus d’informations sur les exigences d’Active Directory pour les déploiements hybrides et verts (environnements utilisant Citrix Cloud et le service CVAD pour le courtage et l’administration de sessions), consultez les détails techniques de Citrix Cloud Connector. Outre les niveaux fonctionnels d’Active Directory pris en charge, cet article traite également des scénarios de déploiement pour les Cloud Connector dans Active Directory.

Pour plus d’informations sur les exigences d’Active Directory pour les déploiements Lift and Shift (environnements utilisant le courtage de sessions gérées par le client et l’administration via les versions Citrix Virtual Apps and Desktops LTSR ou CR), consultez la section Configuration système requise pour CVAD, niveaux fonctionnels Active Directory.

Considérations relatives au courtage de session et à l’administration

Comme vous l’avez probablement déjà compris, le choix de la façon dont vous fournissez les services de courtage et d’administration des sessions est essentiel et a des implications générales sur le coût global, la gérabilité, la maintenance et les capacités disponibles pour votre système de virtualisation Citrix. Comme nous l’avons déjà vu, Citrix recommande l’utilisation du service Citrix Cloud (DaaS) pour ce composant critique, mais pour certaines exigences et certains scénarios, le déploiement d’un sous-système de négociation et d’administration de sessions géré par le client (via les versions CVAD LTSR ou CR) peut être nécessaire ou recommandé. Le tableau suivant présente certains de ces critères et scénarios à prendre en considération :

Attribut/Capacité	CVAD géré par le client (Citrix Virtual Apps and Desktops, LTSR ou versions CR)	Cloud Service DaaS (Citrix DaaS, fourni par Citrix Cloud)
Nécessite une connectivité Internet sortante vers Citrix Cloud.	NON - Les Delivery Controller ne nécessitent pas de connectivité Internet sortante, mais ils doivent pouvoir communiquer avec l’infrastructure AWS pour que le provisionnement MCS fonctionne.	OUI - Cloud Connector communique via Internet à Citrix Cloud, bien que ces connexions puissent être transmises par proxy. Consultez Comment configurer un serveur proxy pour Citrix Cloud Connector pour plus de détails. Pour les déploiements strictement aériens, il s’agit souvent d’un bouchon de spectacle.
Nécessite que le client fournisse des services de base de données Microsoft SQL hautement disponibles.	OUI - CVAD (dans les versions LTSR et CR) exige que le client fournisse des services de base de données Microsoft SQL hautement disponibles. Ceux-ci peuvent être fournis en construisant des serveurs SQL sur des instances EC2 ou en utilisant le service AWS RDS for SQL Server.	NON - Le DaaS n’oblige pas les clients à utiliser SQL Server : les services de base de données hautement disponibles sont fournis par la plate-forme de mise à disposition Citrix Cloud et sont transparents pour les clients.
Nécessite que le client applique des correctifs et des mises à niveau au logiciel Citrix au fil du temps afin de maintenir la sécurité et la prise en charge et d’accéder à de nouvelles fonctionnalités et fonctionnalités.	OUI : les clients sont responsables de l’installation, de la configuration, de l’application des correctifs, de la sécurisation et de la mise à niveau du logiciel Citrix et du système d’exploitation sous-jacent pour tous les composants d’un système d’administration et de courtage de session basé sur CVAD. Ils sont également responsables du maintien d’une haute disponibilité de chaque composant, y compris Citrix Delivery Controller, les installations Studio, Director et Citrix Licensing.	NON - Cloud Connector (le seul composant d’administration et de courtage de session qui réside dans le VPC du client) sont automatiquement mis à jour et gérés par Citrix. Les clients sont responsables de l’application des correctifs et de la maintenance du système d’exploitation Windows Server sur les instances EC2 Cloud Connector. De nouvelles fonctionnalités et fonctionnalités sont disponibles immédiatement, sans que le client soit tenu de mettre à jour manuellement les Cloud Connector.
Possibilité d’utiliser les services avancés fournis par Citrix Cloud, y compris la fonctionnalité Citrix Autoscale.	Parfois, tous les services avancés ne sont pas disponibles pour les déploiements CVAD gérés par le client et, lorsqu’ils le sont, peuvent nécessiter l’installation et la configuration de composants supplémentaires. La fonctionnalité Autoscale n’est pas disponible pour les environnements CVAD.	OUI - Le DaaS est conçu pour fonctionner « prêt à l’emploi » avec d’autres services Citrix Cloud, et ces services sont généralement préconfigurés afin que le client les active simplement. La fonction Autoscale, qui permet de contrôler de manière granulaire la quantité et l’état d’alimentation des VDA, a un impact sur les déploiements de VDA sur le cloud public. Il peut vous permettre de réaliser des économies substantielles sur les coûts d’infrastructure dans des scénarios où vous ne payez que la capacité dont vous avez besoin.
Capacité d’avoir un contrôle complet sur tous les composants du sous-système, y compris le calendrier des activités de mise à niveau et de maintenance.	OUI - étant donné que chaque composant est installé, configuré et maintenu par le client, le client a un contrôle total sur la version, la configuration et la disponibilité de chaque composant (bien que ce soit à un coût substantiel de l’infrastructure, de la complexité et des frais administratifs).	NON - avec le DaaS, les clients abandonnent une certaine mesure de contrôle, mais gagnent en simplicité, en réduisant les coûts d’infrastructure et en réduisant considérablement les frais administratifs.
Possibilité de licence en fonction des utilisateurs simultanés par rapport aux utilisateurs nommés.	OUI - CVAD peut être autorisé par CCU.	OUI - Une licence de CCU est disponible. Consultez ce blog pour plus de détails.

Cloud Connector, Delivery Controller et Emplacements des ressources

Étant donné que les modèles Green Field et hybrides utilisent des services cloud (DaaS) pour le courtage et l’administration de sessions, vous déployez des Cloud Connector pour créer un emplacement de ressources dans chaque région où vous prévoyez d’héberger des VDA. Lorsque vous créez un emplacement de ressources dans une région, vous créez une configuration hautement disponible en déployant des instances n+1 Cloud Connector et en répartissant les Cloud Connector dans les zones de disponibilité de cette région. Les connecteurs Cloud sont généralement placés dans des sous-réseaux privés distincts des VDA afin de simplifier l’application de stratégie de sécurité, et les instances Cloud Connector doivent disposer d’un accès Internet sortant pour faciliter la connexion à Citrix Cloud. Les placer dans un sous-réseau distinct des VDA permet aux administrateurs d’appliquer des stratégies de routage différentes aux deux types de ressources différents.

Schéma 13 : Modèle de conception de l’emplacement des ressources Citrix DaaS avec sous-réseaux distincts pour les VDA et les Cloud Connector Schéma 13 : Modèle de conception de l’emplacement des ressources Citrix DaaS avec des sous-réseaux distincts pour les VDA et les Cloud Connector.

Les mêmes concepts généraux s’appliquent lorsque nous parlons de Delivery Controller (CVAD), bien que nous utilisons le terme zone par rapport à l’emplacement des ressources dans le sous-système de courtage géré par le client. Notez également que les instances Cloud Connector sur EC2 sont d’excellents candidats à la tarification réservée, car elles s’exécutent chaque fois que le système doit être opérationnel. Consultez cet article pour plus d’informations sur le dimensionnement des instances Cloud Connector.

Considérations relatives à la conception d’un site Citrix DaaS

Emplacements et zones de ressources

L’utilisation de zones Citrix (à ne pas confondre avec les zones de disponibilité) peut aider les utilisateurs des régions distantes à se connecter aux ressources sans nécessairement forcer leurs connexions à traverser de grands segments du WAN. Dans un environnement Citrix DaaS, chaque emplacement de ressources est considéré comme une zone. Lorsque vous créez un emplacement de ressources et installez un Cloud Connector, une zone est automatiquement créée pour vous. Chaque zone peut contenir différents types de ressources, en fonction de vos besoins et de votre environnement. Pour plus d’informations sur les zones, consultez le liensuivant.

Catalogues de machines, groupes de mise à disposition et emplacements de ressources

Les administrateurs Citrix doivent s’assurer que les VDA sont également répartis entre les zones de disponibilité (AZ). Une zone de disponibilité AWS (AZ) est un ou plusieurs datacenters discrets dotés d’une puissance, d’une mise en réseau et d’une connectivité redondantes dans une région AWS - un emplacement physique dans le monde où AWS cluse des datacenters. Un cloud privé virtuel (VPC) est un réseau virtuel qui couvre les zones de disponibilité de la région. Les sous-réseaux sont un sous-composant obligatoire d’un VPC, et les interfaces réseau virtuelles sont chacune attachées à un seul sous-réseau. Chaque sous-réseau doit résider entièrement dans une zone de disponibilité et ne peut pas s’étendre sur des zones. En lançant des VDA dans des zones de disponibilité distinctes, vous pouvez protéger vos applications contre la défaillance d’un seul emplacement. Consultez Qu’est-ce qu’un Amazon VPC ? pour plus d’informations. Pour vous assurer que les VDA sont répartis entre les ZA, vous pouvez créer un catalogue de machines par AZ (à l’aide d’une connexion hôte par AZ) qui peut ensuite mapper à un seul groupe de mise à disposition.

Provisioning dans AWS : Services de création de machines

À partir de la version de CVAD 1811, l’authentification basée sur les rôles peut être utilisée lors de la création d’une connexion hôte pour le provisionnement MCS dans AWS. Un rôle IAM ou un compte d’utilisateur IAM associé à un Delivery Controller ou Cloud Connector sur une instance EC2 peut être utilisé à la place de la clé secrète et de la clé API d’un utilisateur, ce qui permet une sécurité accrue, des droits administratifs délégués et des environnements basés sur PKI avec informations d’identification temporaires et jetons de session. Pour configurer une connexion hôte à l’aide de l’authentification basée sur les rôles, créez d’abord un rôle IAM avec les autorisations décrites dans CTX140429. Associez ce rôle à une instance EC2 avec un Delivery Controller CVAD 1811+ ou un Cloud Connector. Sur les versions de CVAD antérieures à 1811, les administrateurs doivent fournir la clé API (clé d’accès) et la clé secrète d’un utilisateur IAM pour créer une connexion hôte.

Après avoir créé la connexion hôte, créez un catalogue de machines comme décrit ici à l’aide d’une AMI créée à partir de l’image VDA principale dans AWS. Pour plus de détails sur MCS dans AWS, consultez les articles suivants : Citrix MCS sur AWS Deep Dive 1 et How MCS works after pooled VMs are created in AWS.

Un autre élément à prendre en compte lors du déploiement de VDA dans AWS à l’aide de MCS est l’ initialisation du volume EBS (également appelée préchauffage ou hydratation). Pour les volumes restaurés à partir d’instantanés, les blocs de stockage doivent être retirés d’Amazon S3 et écrits sur le volume avant de pouvoir y accéder. Cette action préliminaire prend du temps et peut entraîner une augmentation significative de la latence des opérations d’E/S la première fois que chaque bloc est accessible. Les performances du volume sont obtenues après que tous les blocs ont été téléchargés et écrits sur le volume. Consultez Initialization Amazon EBS Volumes on Windows for AWS Recommended steps to Initialize Amazon EBS Volumes on Windows instances and see Initializing Amazon EBS Volumes on Linux for Linux instances Linux.

Voir Considérations relatives à la couche d’infrastructure (ou de plate-forme) pour plus de détails sur la conception d’un VPC en relation avec MCS.

Dépannage des services de création de machines

Cette section énumère quelques problèmes courants ainsi que les liens de recommandations et de résolution connexes.

• Certains nouveaux types d’instances AWS n’apparaîtront pas par défaut dans l’assistant de création de catalogue de machines de Studio (CVAD ou DaaS). L’interface utilisateur est remplie de types d’instances provenant d’un fichier XML statique résidant sur des Delivery Controller (CVAD) ou des Cloud Connector (DaaS). Ce fichier XML peut être modifié pour inclure des types d’instance plus récents, mais ce fichier est remplacé par des valeurs par défaut lors des mises à niveau (mises à jour Cloud Connector initiées par Citrix ou mises à niveau de Delivery Controller initiées par le client). Consultez Mise à jour des types d’instances AWS pour XenDesktop pour plus de détails sur la façon de mettre à jour la liste des types d’instances AWS disponibles.
• Le provisionnement MCS échoue sur AWS EC2 lors de l’utilisation d’instances dédiées
• Impossible de créer une connexion d’hébergement AWS sur Citrix Cloud DDC lorsque le proxy est configuré sur le serveur de connecteur
• Lors de la création de machines avec MCS et AWS, une erreur « XDDS:2367399E » se produit
• Configurer l’instance de Volume Worker pour utiliser le VPC de catalogue de machines et non le VPC par défaut
• Comment faire pour garantir la compatibilité des régions lors de l’utilisation de XenApp et XenDesktop MCS dans AWS
• Conseils de dépannage sur le terrain pour les services de création de machines dans AWS

Considérations relatives aux couches d’infrastructure (ou de plate-forme)

Dans Citrix Architectural Design Framework, la couche Infrastructure (ou Platform) définit les éléments physiques sur lesquels les charges de travail Citrix s’exécutent. Dans ce document, cela fait bien sûr référence à AWS. AWS fournit de nombreux services cloud (165 +) et est à la fois le plus ancien et le plus grand des fournisseurs de cloud Hyperscale existant aujourd’hui. Il s’agit également du premier cloud public pris en charge par la technologie de virtualisation Citrix. Il s’agit d’une option convaincante pour les clients Citrix nouveaux ou existants qui cherchent à déplacer des charges de travail de virtualisation Citrix existantes ou à exécuter de nouvelles charges de travail de virtualisation Citrix dans le Cloud.

Infrastructure en tant que code et modèle objet AWS

Pour comprendre comment les technologies de virtualisation Citrix sont intégrées et exécutées sur AWS, il est utile de commencer par une compréhension de base du modèle objet derrière certains de leurs services clés/pertinents. Cela nous permet également de décrire la plate-forme AWS en termes familiers à la plupart des professionnels de l’informatique. Pour faciliter cette compréhension, nous nous référons au schéma suivant qui représente le modèle de conception d’un emplacement de ressources DaaS sur AWS :

Schéma 14 : Architecture/modèle de conception « Emplacement des ressources » déployé pour Citrix DaaS etschéma AWS 14 : Architecture/modèle de conception « Emplacement des ressources » déployé pour Citrix DaaS sur AWS.

Ce modèle de conception constitue la base de la plupart des architectures de système de virtualisation Citrix sur AWS. Il ne s’agit pas non plus d’un modèle massif - il est construit sur différents modèles de conception différents, bien entretenus et documentés pour l’informatique d’entreprise sur AWS. Ces modèles sont représentés, documentés et reproduits à l’aide de modèles AWS CloudFormation . AWS fournit une bibliothèque de modèles de démarrage rapide qui peuvent être exécutés tels quels, superposés ensemble (« imbriqués ») avec d’autres modèles, et même dupliqués et personnalisés en fonction de vos besoins spécifiques. Cela met en évidence quelques autres avantages majeurs de l’infrastructure de cloud public : l’infrastructure en tant que code et la nature « payez comme vous » de nombreux services cloud. Nous approfondissons bientôt l’infrastructure en tant que code dans le monde de la virtualisation Citrix, mais nous insistons sur ce point avec un point de contact rapide qui résonnera probablement pour les lecteurs attendus de cet article : pour de nombreux architectes informatiques d’entreprise, avoir accès à une si vaste bibliothèque de services, de modèles de conception et outils technologiques à portée de main est génial. Combiné à la capacité de payer pour les ressources que vous consommez et simplement de les supprimer lorsque vous avez terminé ? Il s’agit d’un moyen puissant d’apprendre ou d’évaluer les nouveaux éléments, et il rend le ROI des investissements à grande échelle beaucoup plus facile à comprendre et à communiquer.

Revenons un instant au modèle d’objet AWS : l’objet de premier niveau dans le diagramme 14 est la région AWS. Vous pouvez considérer les régions AWS comme des clusters de centres de données bien connectés mais stratégiquement séparés, appelés zones de disponibilité. Chaque région comprend généralement 2 zones de disponibilité ou plus, qui consistent en un ou plusieurs bâtiments physiques dotés d’une alimentation, d’une mise en réseau et d’une connectivité redondantes. Au moment de la rédaction du présent document, AWS compte 23 régions dans le monde, qui se composent de 69 zones de disponibilité, mais il est important de noter qu’ils investissent constamment dans de nouvelles régions et AZ. Ces chiffres, bien qu’ils soient stupéfiants pour la plupart d’entre nous, sont probablement déjà obsolètes au moment où vous lisez ceci. Cela met en évidence l’un des autres avantages du passage à une infrastructure de cloud public sur AWS : vous continuez de bénéficier des investissements qu’ils réalisent (à une échelle bien au-delà de la portée de la plupart des organisations informatiques ou même des gouvernements) au fil du temps. Cette évolution/amélioration continue, tout en étant redoutable pour les organisations informatiques et les cultures métiers hostiles au changement, offre un large éventail d’avantages pour l’informatique d’entreprise lorsqu’elle s’adapte à ce « nouveau » modèle.

Les choix d’adoption des régions AWS sont souvent basés sur la proximité, les services disponibles, le coût, la conformité ou les SLA. Bien que le choix d’une ou plusieurs régions appropriées pour votre système de virtualisation Citrix dépasse le cadre de ce document, tenez compte au moins des points suivants lorsque vous faites vos choix :

• Si vous avez déjà un ou plusieurs datacenters gérés par le client que vous connectez à AWS, envisagez une ou plusieurs régions offrant la connectivité réseau la plus faible latence à vos centres de données et bureaux principaux.
• Toutes les régions ne peuvent pas avoir les services AWS ou les types d’instance que vous recherchez. AWS déploie de nouveaux services ou types d’instance dans quelques régions principales, puis s’étend aux autres au fil du temps. En outre, les régions plus récentes ne peuvent pas avoir de types d’instance plus anciens - effectuez vos recherches avant de construire autant que possible.
• Les sites CVAD et les emplacements de ressources DaaS sont liés à une région spécifique. La haute disponibilité des composants individuels d’un site ou d’un emplacement de ressource (tels que les connecteurs cloud, les serveurs StoreFront et les instances VPX ADC/Gateway) est assurée en plaçant des ressources dans plusieurs zones de disponibilité dans une région donnée.
• Ne passez pas à la mer en répandant votre infrastructure entre les régions : bien qu’il soit facile à faire sur AWS, tenez compte du coût et de la complexité par rapport au gain que vous attendez avant de mettre à l’échelle un système. Vous finissez par payer pour le trafic réseau et le trafic de stockage aussi parfois. Les coûts peuvent être négligeables pour le trafic alors qu’il est local à une région, mais augmente lorsque le trafic traverse des régions ou Internet.

En intensifiant une couche dans le diagramme 14 maintenant, regardons quelques-unes des constructions de mise en réseau dans ce modèle de conception. La construction de réseau principale sur AWS est le VPC ou « Virtual Private Cloud. » Les VPC sont une construction régionale (ils couvrent des AZ) - vous disposez d’au moins un VPC dans chaque région dans laquelle vous déployez la technologie de virtualisation Citrix. Les VPC ont un bloc CIDR d’adresses IP défini, qui doit être unique si votre conception réseau achemine le trafic entre plusieurs VPC. Les VPC sont subdivisés en sous-réseaux, et les sous-réseaux sont liés à un AZ (c’est-à-dire qu’ils ne couvrent PAS les AZ dans une région).

Les sous-réseaux ont également différents attributs et objets qui leur sont associés, notamment des stratégies de routage et des stratégies de sécurité. C’est pourquoi les modèles de conception mis en évidence dans ce document (et d’autres documents Citrix) recommandent de placer des VDA dans des sous-réseaux distincts de Cloud Connector, de sorte que vous pouvez attribuer différentes stratégies de routage et de sécurité aux VDA et Cloud Connector.

L’accès Internet sortant à partir de n’importe quel sous-réseau d’un VPC (une construction régionale) peut être géré de différentes manières, mais une méthode courante consiste à utiliser des passerelles NAT pour fournir une connectivité Internet à des sous-réseaux privés. Les sous-réseaux publics sont souvent desservis par des passerelles Internet, qui facilitent le routage des connexions entrantes vers les services que vous rendez accessibles depuis Internet.

Les sous-réseaux sont également couramment étiquetés comme « public » et « privé ». Un sous-réseau public est un sous-réseau avec des adresses IP routables Internet affectées (en plus des adresses IP privées) et est associé à une table de routage qui a un itinéraire vers une passerelle Internet (IGW) pour le trafic Internet entrant et sortant. Un sous-réseau privé est un sous-réseau avec uniquement des adresses IP privées affectées et est associé à une table de routage qui a un itinéraire pour l’accès Internet sortant via une passerelle NAT ou des instances NAT résidant dans un sous-réseau public. Dans un système de virtualisation Citrix, le serveur virtuel (VIP) Gateway réside généralement dans un sous-réseau public car il accepte les connexions entrantes à partir de machines clientes sur Internet et est utilisé pour proxy en toute sécurité le trafic de virtualisation Citrix vers des sous-réseaux privés dans un VPC.

Il existe de nombreuses façons de créer des réseaux sur AWS, avec de nombreuses fonctionnalités et techniques innovantes que vous ne pouvez pas obtenir ailleurs. Nous n’allons pas tous vous les présenter ici, mais deux outils/techniques qui méritent d’être étudiés sont l’ appairage de VPC et les passerelles de transit. Ces deux concepts vous permettent de vous initier au routage du trafic entre lesVPC simplement (appairagede VPC) ou dans un modèle de cloud hybride plus adapté aux entreprises (passerelles de transit).

Il y a beaucoup plus que nous pouvons creuser ici, et pour les curieux et motivés, il y a une montagne de connaissances du domaine public à portée de main pour en savoir plus. Pour l’instant, ramenons cela pour concevoir des motifs sous tous les diagrammes que vous avez vus dans cet article.

L’un des attributs convaincants de la plate-forme AWS est qu’elle a été construite sur des API consommables publiquement. Pourquoi est-ce convaincant ? D’une part, cela signifie que beaucoup n’importe quel type de composant d’infrastructure que vous pouvez exécuter sur AWS peut être construit de manière reproductible à partir du code. Lorsqu’il est associé à un service de déploiement puissant et complet tel qu’ AWS CloudFormation, les clients disposent d’une infrastructure puissante pour apprendre, personnaliser, déployer et gérer les systèmes informatiques. Le concept d’ infrastructure en tant que code peut être nouveau ou déroutant pour de nombreux technologues traditionnels axés sur les entreprises, mais il peut être transformationnel une fois adopté et mis en pratique.

Comme nous l’avons mentionné précédemment, AWS fournit une bibliothèque de modèles Quick Start basés sur CloudFormation qui peuvent être exécutés tels quels, superposés (« imbriqués ») avec d’autres modèles, et même dupliqués et personnalisés pour vos besoins spécifiques. Cette bibliothèque de modèles est gérée et gérée par AWS, en coopération avec des partenaires technologiques tels que Citrix, et ces modèles sont souvent open source (ce qui signifie qu’ils peuvent être dupliqués et modifiés au besoin). Au moment de la rédaction du présent document, les modèles de démarrage rapide suivants sont disponibles pour les technologies Citrix sur AWS :

• NetScaler ADC pour applications Web : déploie des instances NetScaler ADC VPX hautement disponibles sur AWS. Bien que l’objectif des cas d’utilisation diffère légèrement, ce modèle de conception est également fonctionnel et pertinent pour les déploiements de Citrix Gateway avec CVAD/DaaS.

Résumé - Présentation des modèles de conception pour Citrix sur AWS

Confus encore ? Si c’est le cas, ne vous inquiétez pas : cela peut bien être le début de votre parcours dans le cloud public Citrix on AWS, et nous avons simplement écrémé la surface de nombreux sujets profonds ici. Espérons toutefois que nous ayons réussi à illustrer les points saillants suivants :

• Infrastructure as Code est un concept puissant qui peut révolutionner la façon dont les systèmes complets sont conçus, construits et entretenus.
• Lors du déploiement de systèmes sur le cloud public d’AWS, différents composants d’une solution donnée peuvent être représentés par du code et créés à la demande à l’aide d’AWS CloudFormation et d’autres technologies.
• Ces composants sont représentés par des modèles de pile lors de l’utilisation d’AWS CloudFormation, et les modèles peuvent être copiés et modifiés, selon les besoins, pour obtenir les résultats souhaités.
• Les modèles peuvent être imbriqués, créant des systèmes complets (tels qu’un emplacement de ressources DaaS entièrement fonctionnel sur AWS) à partir des modèles de conception individuels (modèles).
• Le modèle Citrix DaaS sur AWS Quick Start repose sur trois modèles de base gérés et maintenus par AWS, qui sont bien documentés. Commencez par les liens suivants pour en savoir plus sur chacun :
• En utilisant des modèles et en réalisant des versions d’essai, un technologue Enterprise peut en apprendre davantage sur, évaluer et concevoir des systèmes qui répondent aux besoins spécifiques de son organisation ou de son client.

AWS Infrastructure Layer - ressources supplémentaires

Les ressources suivantes peuvent être utilisées pour en savoir plus sur la virtualisation Citrix sur les exigences et les meilleures pratiques AWS :

• Ports de communication utilisés par Citrix Technologies : une bonne référence globale pour les ports de communication utilisés par les différents composants de la pile de virtualisation Citrix.

Considérations relatives à la couche

Cette section définit les activités opérationnelles que les administrateurs effectuent périodiquement. Beaucoup d’entre eux ne sont pas spécifiques à AWS et sont détaillés dans la documentation publiée existante. Dans les tableaux suivants, nous avons résumé certaines des tâches les plus importantes ou spécifiques à AWS. Les lecteurs peuvent consulter la rubrique Surveiller dans la documentation produit Citrix pour plus d’informations.

tâches à la demande

Le tableau suivant décrit les tâches qui doivent être exécutées à la demande en fonction des exigences des applications et des efforts de dépannage.

Composant	Tâche	Description
Générique	Mise à jour de la base	Lorsque l’équipe Citrix dépannage des problèmes liés à l’environnement, elle doit identifier les solutions aux problèmes. Des KBA doivent être créés pour chaque problème afin de prendre en charge les futures activités de dépannage.
Citrix DaaS	Modifier l’image	Les images doivent être mises à jour au besoin pour prendre en charge les demandes. Les mises à jour seront probablement mensuelles, mais des mises à jour plus fréquentes peuvent être nécessaires pour les tests.
Citrix DaaS	Publier une image	Lorsque les images sont modifiées, elles sont testées et publiées.
AWS	Vérifier le lancement de l’instance	Lorsqu’une nouvelle instance est lancée via MCS, vérifiez que l’instance a été créée dans la console AWS et qu’il existe des adresses IP disponibles dans le pool pour le VPC donné. Les machines provisionnées par MCS ne seront pas créées s’il n’y a pas d’adresses IP disponibles dans le pool de VPC.
AWS	Vérifier l’efficacité de l’image sur site	Une instance créée à partir de n’importe quelle image sur site doit être testée pour sa capacité de lancement et sa viabilité avant d’être utilisée pour mettre à jour des instances de production.
AWS	Modifier les autorisations d’utilisateur/groupe IAM	Au besoin, les autorisations des utilisateurs et des groupes IAM devraient être revues afin de réduire le nombre d’utilisateurs disposant d’un accès administratif et d’implémenter la méthodologie du « minimum privilège ».
AWS	Modifier les groupes de sécurité	Au besoin, les groupes de sécurité doivent être examinés afin d’accorder ou de supprimer l’accès à différents protocoles de trafic de diverses adresses IP ou plages IP. Les règles d’entrée et de sortie doivent être modifiées pour mettre en œuvre des verrouillages du trafic réseau.
AWS et Citrix DaaS	Mettre à jour des machines dans un catalogue de machines	Au besoin, mettez à jour les images de la machine pour y inclure les modifications nécessaires. Une nouvelle AMI doit être créée à partir de l’image modifiée et utilisée pour mettre à jour le catalogue de machines. Pour plus de détails, reportez-vous à la section Processus de mise à jour et de mise à niveau de ce document.
AWS et Citrix DaaS	Annualiser les mises à jour d’un catalogue de machines	Si nécessaire, dans le cas où une image machine doit être restaurée, une AMI précédente avec la dernière configuration de travail connue peut être utilisée pour mettre à jour des machines dans le catalogue de machines.

Tâches périodiques quotidiennes

Le tableau suivant décrit les tâches qui doivent être exécutées quotidiennement.

Composant	Tâche	Description
Générique	Passer en revue Citrix Director, l’Analyseur de performances Windows, le journal d’événements et d’autres alertes logicielles de surveillance	Rechercher des avertissements ou des alertes dans Citrix Director, les journaux d’événements ou d’autres logiciels de surveillance. Identifier la cause principale de l’alerte, le cas échéant. Remarque : un ordinateur et un moniteur peuvent être configurés pour afficher le tableau de bord Citrix Director afin de créer un affichage tête haute pour le service Citrix afin que l’état de l’environnement soit clairement visible. Les recommandations de surveillance pour Citrix Virtual Apps and Desktops sont incluses dans la section Monitoring du guide Virtual Apps and Desktops Best Practices.
Générique	Vérifier que les sauvegardes sont terminées correctement	Vérifier que toutes les sauvegardes planifiées ont bien été effectuées. Cela peut inclure, mais sans s’y limiter, les données utilisateur (profils utilisateur/dossiers personnels), les données d’application, les bases de données Citrix, la configuration Citrix StoreFront, les fichiers de licence Citrix.
Générique	Tester l’accès à l’environnement	Simulez une connexion à la fois en interne et en externe pour vérifier que les ressources de bureau et d’application sont disponibles avant que la plupart des utilisateurs ne se connectent pour la journée. Cette connexion doit être testée tout au long de la journée et peut même être automatisée.
Citrix Virtual Apps and Desktops	Vérifier l’alimentation des machines virtuelles	Vérifiez que le nombre approprié de postes de travail inactifs et de serveurs d’applications sont sous tension et enregistrés auprès des Delivery Controller pour confirmer la disponibilité des charges de travail utilisateur.
AWS	Effectuer des vérifications de l’état de	Vérifiez la console AWS pour vérifier l’état des instances et du matériel sous-jacent. Toutes les instances doivent passer les deux vérifications de santé lorsqu’elles sont sous tension.
Citrix Virtual Apps and Desktops	Effectuer une sauvegarde incrémentielle des bases de données Citrix	Effectuer des sauvegardes incrémentielles des bases de données Citrix suivantes : Base de données de site, base de données de journalisation de la configuration, base de données de surveillance

Tâches périodiques hebdomadaires

Le tableau suivant présente les tâches qui doivent être exécutées sur une base hebdomadaire.

Composant	Tâche	Description
Générique	Passez en revue les derniers correctifs et correctifs	Examiner, tester et déployer les correctifs Citrix les plus récents et vérifier si les Delivery Controller et les machines virtuelles avec OS de serveur/OS de bureau en ont besoin. Pour les mises à jour Microsoft déployées via SCCM ou WSUS sur des machines dans AWS, toutes les machines reçoivent ces mises à jour lorsqu’elles sont sous tension. Si Citrix Power Management est utilisé, il peut y avoir des machines dans le catalogue de machines qui ne sont pas activées régulièrement. Lors de l’exécution de mises à jour d’image, il est préférable d’utiliser une instance maître dynamique qui est mise sous tension pendant tous les cycles de mise à jour. Les AMI peuvent ensuite être créées à partir de cette instance et inclure tous les correctifs nécessaires. Remarque : Tous les correctifs requis doivent être testés à l’aide du processus de test recommandé avant l’implémentation dans Production.
Générique	Créer un rapport d’état sur l’environnement Citrix	Créez un rapport sur les performances globales de l’environnement (intégrité du serveur, utilisation des ressources, expérience utilisateur) et le nombre de problèmes Citrix (taux de fermeture, problèmes ouverts, etc.).
Générique	Passer en revue le rapport d’état	Consultez le rapport d’état Citrix pour identifier les tendances ou les problèmes courants.
Générique	Tenir à jour la base de connaissances du support interne	Créez des scripts KBA et de résolution de problèmes pour répondre aux demandes de support de niveau 1 et 2. Vérifiez l’exactitude, la conformité et la faisabilité des scripts KBA et de résolution de problèmes.
Citrix Virtual Apps and Desktops	Vérifier les rapports d’enregistrement de la configuration	Confirmez que les modifications apportées à l’échelle du site Citrix au cours de la semaine précédente ont été approuvées via le contrôle des modifications.
Citrix Virtual Apps and Desktops	Effectuer une sauvegarde complète des bases de données Citrix	Effectuez des sauvegardes complètes des bases de données Citrix suivantes : Base de données de site, Base de données de journalisation de la configuration, base de données de surveillance.
AWS	Effectuer des instantanés de tous les volumes EBS	Tous les volumes Elastic Block Storage doivent être instantanés périodiquement. Les instantanés peuvent être gérés et soignés dans la console AWS EC2.

Tâches périodiques mensuelles

Le tableau suivant décrit les tâches qui doivent être exécutées sur une base mensuelle.

Composant	Tâche	Description
Générique	Effectuer une évaluation de la capacité	Effectuez une évaluation des performances de l’environnement et de la capacité de l’environnement Citrix afin de déterminer l’utilisation de l’environnement et les exigences d’évolutivité. Passez en revue les rapports mensuels des outils de surveillance pour évaluer les performances et la capacité de l’environnement, y compris, mais sans s’y limiter : l’allocation de calcul du serveur virtuel (CPU et RAM), les licences, la bande passante réseau. Procurez-vous des logiciels ou des licences et construisez des serveurs supplémentaires au besoin. Remarque : Les recommandations pour effectuer une évaluation des capacités sont incluses dans la décision de conception : évolutivité d’un serveur unique
Générique	Examiner l’accès à privilèges élevés	Vérifiez quels utilisateurs et groupes disposent d’autorisations élevées sur l’environnement et évaluez si un accès élevé continu est requis. Supprimez tous les comptes qui ne nécessitent plus ces droits administratifs. Principalement uniquement les utilisateurs et les rôles IAM qui doivent être utilisés pour attribuer des privilèges élevés, avec un accès strictement restreint aux comptes utilisateur individuels, locaux ou root.

Tâches périodiques annuelles

Le tableau suivant décrit les tâches qui doivent être exécutées sur une base annuelle.

Composant	Tâche	Description
Générique	Effectuer une évaluation de la stratégie Citrix	Passez en revue les stratégies Citrix et déterminez si de nouvelles stratégies sont requises et que les stratégies existantes doivent être mises à jour.
Générique	Passer en revue les mises à niveau logicielles	Examiner et évaluer la nécessité de nouvelles versions logicielles Citrix.
Générique	Effectuer un test de plan de continuité d’activité (BCP) /reprise après sinistre (DR)	Effectuer un test de continuité des activités/de récupération d’urgence fonctionnel pour confirmer l’état de préparation à la récupération d’urgence. Ce plan comprend un test de restauration annuel pour valider le bon fonctionnement du processus de restauration à partir des données de sauvegarde.
Générique	Effectuer l’évaluation des applications	Vérifier l’utilisation des applications en dehors et au sein de l’environnement Citrix. Évaluez la validité de l’ajout d’applications supplémentaires au site Citrix, de la suppression d’applications qui ne sont plus nécessaires ou de la mise à niveau des applications vers la dernière version.
AWS	Évaluer les accès aux groupes de sécurité réseau	Lorsque des fonctionnalités ou des applications sont ajoutées ou supprimées des serveurs d’infrastructure Citrix ou des serveurs d’applications, les groupes de sécurité réseau associés à ces instances doivent également être évalués et modifiés si nécessaire, afin d’ajouter ou de supprimer des ports ou des protocoles.

Sources

L’objectif de cette architecture de référence est de vous aider à planifier votre propre implémentation. Pour faciliter ce travail, nous aimerions vous fournir des diagrammes sources que vous pouvez adapter dans vos propres conceptions détaillées et guides d’implémentation : diagrammes source.