Architecture de référence - Virtualisation Citrix sur Google Cloud

Remarque :

Le contenu de ce document est en cours de restructuration et intégré dans le centre de solutions pour Citrix DaaS sur Google Cloud. Le contenu original du document est laissé ici pendant la transition par souci d’exhaustivité et de référencement.

Introduction

Dans ce guide, nous vous expliquons tout au long de la conception d’un système de virtualisation Citrix sur GCP. Au fur et à mesure que le parcours progresse, nous discutons des implications des décisions que vous devez prendre et de créer plus de ressources de référence en cours de route. Ce guide est un document vivant. Assurez-vous de le mettre en signet et vérifiez périodiquement pour voir comment les choses changent au fil du temps.

Nous commençons par passer en revue les modèles de conception courants pour les technologies de virtualisation Citrix sur Google Cloud. Certains considèrent ces « modèles de conception » comme des « architectures de référence », mais lorsque nous travaillons avec l’infrastructure en tant que code et services cloud, les « modèles de conception » ont beaucoup plus de sens.

Ensuite, nous explorons les composants et les exigences de la solution. Nous présentons les conditions préalables de la solution et vous donnons un aperçu des services/composants nécessaires pour créer un « emplacement de ressources » Citrix Cloud.

Nous revoyons ensuite et approfondissons les modèles de conception, en nous appuyant sur une meilleure compréhension des services/composants d’un système de virtualisation Citrix sur Google Cloud. Enfin, nous approfondissons des sujets spécifiques, notamment la conception et la gestion de Virtual Delivery Agent (VDA), Citrix ADC/Gateway sur Google Cloudet Citrix StoreFront sur Google Cloud.

Au fur et à mesure que vous effectuez ce voyage avec nous, nous vous encourageons à partager vos commentaires, contributions, questions, suggestions et commentaires en cours de route. Envoyez-nous un e-mail au groupe de travail PME Citrix sur Google.

Modèles de conception pour la virtualisation Citrix sur Google Cloud

Nous reconnaissons que différents clients sont à différentes étapes de leur parcours vers le « cloud ». Ainsi, nous décrivons trois modèles de conception qui représentent un spectre allant de « nous sommes tous dans » à « nous y arriverons, mais cela peut nous prendre du temps ». Les technologues observants voient les éléments communs entre les trois. Ils commencent à voir comment ils peuvent combiner les services gérés par les clients et les services cloud pour répondre aux différents besoins de l’entreprise et aux influences environnementales. Nous explorerons cette modularité des sous-systèmes lorsque nous reviendrons sur ces trois modèles de conception plus loin dans ce guide.

Le modèle de conception de l’avant du cloud

Les organisations de toutes tailles et formes passent au « cloud » et à des services gérés basés sur abonnement. Pour les clients qui sont tous dans « le cloud » (ou intéressés à découvrir le meilleur de ce que le cloud a à offrir), le modèle de conception Cloud Forward est un modèle de conception parfait. Le modèle de conception Cloud Forward :

  • Utilise les services de pointe fournis dans le cloud de Citrix et Google.
  • Il est couramment utilisé pour les nouveaux déploiements, en plus de l’évaluation technologique, de la vérification, de la formation et d’autres cas d’utilisation qui valorise la simplicité, la flexibilité et la rapidité de déploiement.
  • Ne nécessite aucune infrastructure ni licence existante, et peut être créé en moins de 30 minutes à l’aide de modèles Google Deployment Manager tels que le projet GitHub Citrix on GCP.
  • Offre une haute disponibilité de tous les services critiques.
  • Crée un « emplacement de ressources » Citrix Cloud, qui est la base des deux autres modèles décrits ici.

Tout ce dont vous avez besoin pour démarrer est un projet GCP et l’accès à un abonnement Citrix Cloud DaaS (DaaS). Les abonnements d’évaluation à Citrix Cloud sont disponibles auprès des revendeurs agréés Citrix et Citrix. Google propose également aux nouveaux clients un essai gratuit qui inclut 300$ de crédit Google Cloud.

Remarque :

L’essai gratuit de GCP n’inclut pas l’utilisation d’images Windows Server, comme indiqué dans le document relatif à l’offre gratuite de Google Cloud. Pour utiliser les images Windows Server, vous devez effectuer une mise à niveau vers un compte payant dans GCP. Vos crédits gratuits s’appliquent toujours lorsque vous passez à un compte payant, comme indiqué dans la section Mise à niveau vers un compte payant document relatif à l’offre gratuite de Google Cloud.

Modèle de conception vers l'avant du cloud

Ce modèle de conception utilise plus d’une de toutes les ressources clés (➊) déployées dans des zones distinctes dans une région Google Cloud donnée pour une haute disponibilité.

Citrix Cloud Connector (❷) est responsable des communications vers et en provenance de Citrix Cloud (❻), en utilisant les connexions TLS sortantes vers les services Citrix Cloud sur Internet. Une fois installé sur des instances de machine virtuelle Windows Server jointes au domaine, le logiciel Cloud Connector est automatiquement mis à jour et géré par Citrix Cloud.

Les applications et les postes de travail sont fournis par des instances de machine virtuelle Windows ou Linux, ou les deux exécutant le logiciel Virtual Delivery Agent (VDA) de Citrix (❸). Le logiciel Citrix VDA utilise la technologie HDX sophistiquée de Citrix pour fournir la meilleure expérience utilisateur possible avec des applications et des bureaux virtualisés. Les VDA s’enregistrent auprès de Citrix Cloud Connector, qui sont responsables du courtage des connexions de session HDX aux VDA. Les sessions HDX sont transmises par proxy dans le VPC via Cloud Connector par défaut, ou éventuellement via le service Citrix Gateway en configurant la stratégie de « rendez-vous ». Les instances de VM peuvent être prises en charge par des GPU Google Cloud pour créer des postes de travail virtuels, accélérant ainsi les applications gourmandes en ressources graphiques.

Les VDA Citrix sont le plus souvent déployés à proximité de l’infrastructure requise par les applications mises à disposition (❹). En tant que telle, l’infrastructure applicative est généralement déployée ou migrée dans la même région que les VDA Citrix.

Les utilisateurs finaux utilisent l’ application Citrix Workspace (❺) (CWA) pour se connecter et interagir avec des applications et des bureaux virtualisés à l’aide du protocole innovant de session HDX deCitrix. Le CWA est disponible pour presque tous les appareils ou systèmes d’exploitation, y compris Chrome OS, Windows, OSX, iOS, Android et Linux.

Ce modèle utilise les services cloud (❻) suivants de Citrix, qui sont sécurisés et hautement disponibles par conception :

  • Citrix Virtual Apps and Desktop Service : fournit des services de courtage de session, de gestion de la charge, de gestion d’images d’instance unique, de surveillance et de gestion des coûts/capacités.
  • Service Citrix Workspace : interface utilisateur de la solution. Ce service Web fournit des services d’authentification multifacteur, de présentation de contenu et de lancement pour l’application Citrix Workspace. Ce service consolide l’accès aux applications virtualisées et aux postes de travail, aux applications Web et SaaS, en plus des magasins de fichiers Enterprise.
  • Citrix Gateway Service : fournit un accès sécurisé aux applications et bureaux virtualisés, en plus des applications Web d’entreprise, aux appareils des réseaux publics.
  • Citrix Analytics Service : utilise des technologies avancées d’apprentissage automatique pour fournir des analyses et des rapports de sécurité, de performance et de comportement des utilisateurs de niveau professionnel.

Ce modèle de conception peut également être associé à un Google Cloud VPN/Interconnect ou à une solution conçue comme Citrix SD-WAN (❼) pour étendre les investissements Active Directory existants (❽) dans Google Cloud ou pour fournir un accès à des applications et à une infrastructure traditionnelles, locales et gérées par le client.

Le modèle de conception hybride

Le modèle de conception hybride s’appuie sur le modèle de conception Cloud Forward. Il introduit les composants de couche d’accès gérés par le client de Citrix (➊) pour répondre de manière flexible aux besoins des données démographiques et des cas d’utilisation spécifiques des clients. Ces composants gérés par le client comprennent les éléments suivants :

  • Citrix ADC/Gateway(❷) : déployé en tant qu’appliances virtuelles sur GCP, ce composant est souvent utilisé pour les cas d’utilisation nécessitant un ou plusieurs des éléments suivants :
    • Scénarios d’authentification avancés, tels que SAML/OAUTH 2/OpenID fédération, RADIUS, carte à puce et conditions d’accès conditionnel.
    • Accès aux sessions hautement optimisé et flexible pour les périphériques des utilisateurs finaux sur les réseaux publics.
    • Services de mise en réseau avancés tels que la commutation de contenu, le pare-feu d’application Web, la mise en cache Web intégrée, l’atténuation des attaques, l’équilibrage de la charge des applications et le déchargement SSL.
    • Possibilité de diriger des utilisateurs/appareils spécifiques vers des « magasins » spécifiques en fonction de stratégies avancées, hautement flexibles et contextuelles. Les décisions de stratégie peuvent être basées sur les attributs du profil utilisateur, l’emplacement, le type d’appareil, l’intégrité de l’appareil, les résultats d’authentification, et bien plus encore.
  • Citrix StoreFront(❸) : prédécesseur du service Citrix Workspace, StoreFront est le fournisseur « classique » de services d’interface utilisateur de Citrix. Installé sur des instances Windows Server gérées par le client, StoreFront est souvent utilisé pour les cas d’utilisation nécessitant un ou plusieurs des éléments suivants :
    • Haute disponibilité, capable de survivre à un plus large éventail de scénarios de défaillance, en particulier lorsqu’il est déployé dans une configuration hautement disponible.
    • Routage de session flexible, avec possibilité d’acheminer le trafic de session utilisateur interne directement vers les VDA lors de l’envoi d’utilisateurs externes via Citrix Gateways.
    • Sign-on unique à partir d’appareils locaux gérés par le client.
    • La nécessité de fournir plusieurs « magasins » avec des propriétés de configuration différentes pour prendre en charge divers cas d’utilisation sur le même système.
    • La nécessité d’interfaces utilisateur HTML hautement personnalisées ou de marque.

modèle hybride-conception-modèle

Avec le modèle de conception hybride, les composants de la couche d’accès Citrix sont déployés dans l’environnement Google Cloud (➊) du client. Les composants sont généralement déployés par paires réparties sur plusieurs zones pour une haute disponibilité.

Ce modèle utilise les appliances ADC/Gateway VPX (virtuelles) de Citrix pour proxy en toute sécurité des sessions HDX vers les VDA dans l’environnement du client (❷). Les appliances Citrix ADC/Gateway peuvent être utilisées avec le service Citrix Workspace pour des services proxy de session simples ou des scénarios d’authentification complexes, ou les deux (option d’interface utilisateur A). Il peut également être jumelé avec Citrix StoreFront (option B de l’interface utilisateur).

Ce modèle utilise éventuellement Citrix StoreFront (❸) pour les services d’interface utilisateur, ce qui permet au système de répondre aux exigences pour les cas d’utilisation plus complexes, comme indiqué ci-dessus. Il s’associe à Citrix ADC/Gateway, qui gère l’authentification en plus des services proxy de session UI et HDX.

Le modèle de conception de migration dans le cloud

Le modèle de conception de migration cloud s’appuie davantage sur le modèle de conception hybride. Il permet aux clients ayant des investissements existants dans les technologies Citrix de moderniser systématiquement leur infrastructure, tout en migrant de manière transparente les charges de travail vers le cloud. Cette migration peut se faire à un rythme qui ne perturbe pas les systèmes et les cas d’utilisation existants ou critiques. Il permet aux clients technologiquement conservateurs de « passer » dans le Cloud, charge de travail par charge de travail, réduisant les risques tout au long du chemin selon les conditions du client. Il permet également au client de requalifier systématiquement le personnel sur les technologies les plus récentes et les plus performantes de Citrix et de Google, et de développer son niveau de préparation au cloud organisationnel à un rythme gérable tout en utilisant ses investissements existants dans la technologie, l’infrastructure, les connaissances, les processus et les procédures d’opérationnalisation.

Le modèle de conception de migration cloud commence par le modèle hybride décrit dans la section précédente. Le système construit avec le modèle hybride devient le nouvel environnement de pointe où de nouvelles charges de travail sont déployées. Le modèle de migration cloud utilise l’interface utilisateur Citrix StoreFront (➊) ou Citrix Workspace (❷), ou les deux pour connecter les environnements Citrix hérités (❸) au nouvel environnement, car les deux interfaces utilisateur peuvent présenter plusieurs environnements de courtage dans une seule vue avec une seule connexion. Cela fournit aux utilisateurs une seule interface utilisateur (❹) qu’ils peuvent utiliser pour accéder aux deux environnements. Cela permet au client de déployer de nouvelles charges de travail sur Google Cloud (❺), tout en migrant systématiquement les charges de travail existantes vers Google Cloud en fonction des opportunités et contraintes de l’entreprise.

cloud-migration-design-pattern

Maintenant que vous avez examiné les motifs de conception, nous allons reculer un peu les calques. Examinons ce qu’il faut pour créer un système de virtualisation Citrix sur Google Cloud.

Composants et exigences de la solution

Conditions préalables du système de virtualisation

Pour créer un système de virtualisation Citrix sur Google Cloud, vous avez besoin d’au moins deux éléments pour commencer :

  • Un projet Google Cloud
  • Un abonnement Citrix DaaS

Remarque :

L’essai gratuit de GCP n’inclut pas l’utilisation d’images Windows Server, comme indiqué dans le document relatif à l’offre gratuite de Google Cloud. Pour utiliser les images Windows Server, vous devez effectuer une mise à niveau vers un compte payant dans GCP. Vos crédits gratuits s’appliquent toujours lors de la mise à niveau vers un compte payant, comme indiqué dans la section Mettre à niveau vers un compte payant du document relatif à l’offre gratuite de Google Cloud.

Vous avez vos pré-requis alignés ? Bien ! Maintenant, nous allons vous présenter ce que vous construisez.

Conseil :

La documentation Citrix DaaS est pertinente car ce service est au cœur de la solution. Assurez-vous de le lire avant de commencer à construire, et gardez-le à portée de main lorsque vous avez besoin de plus d’informations. Il se trouve sur le site de documentation Citrix.

Emplacement des ressources Citrix Cloud

Le fondement d’un système de virtualisation Citrix sur Google Cloud est une construction Citrix Cloud appelée « emplacement des ressources ». Un emplacement de ressource, dans Citrix parle, est à peu près analogue à une région sur GCP. Il s’agit d’un regroupement de ressources bien connecté, sur un réseau privé avec Active Directory, de sortie Internet (pour utiliser les services cloud sécurisés de Citrix et Google) et de certaines applications et données que vous souhaitez virtualiser et fournir en toute sécurité sur n’importe quel appareil dans le monde. Les applications et postes de travail virtualisés sont fournis à partir d’instances de machine virtuelle sur GCP appelés « VDA ». Il s’agit d’instances de machine virtuelle Windows ou Linux exécutant le logiciel VDA de Citrix qui permet aux interfaces utilisateur de bureau ou d’application d’être distantes vers les machines clientes à l’aide du protocole d’affichage HDX de Citrix. Les VDA s’enregistrent auprès de Cloud Connector, qui assurent un proxy sécurisé des communications avec Citrix Cloud Services.

Conseil :

Une règle clé pour fournir des applications virtualisées à prendre en compte. Vous souhaitez placer les applications (exécutées sur les VDA Citrix) près des données (infrastructure requise pour les applications). Le fait de ne pas disposer d’applications et de données locales les unes par rapport aux autres peut entraîner une latence accrue et des applications plus lentes, ce qui peut entraîner une dégradation de l’expérience utilisateur.

Les emplacements de ressources sont généralement conçus pour être hautement disponibles, ce qui signifie que vos services clés sont répartis entre les zones de la région GCP. Le cas échéant, plus d’une instance de machine virtuelle pour les services clés sont déployées à des fins de disponibilité et de facilité de gestion. Les services clés que vous devez avoir dans un emplacement de ressources sont les suivants :

  • *Microsoft Active Directory
  • *Connecteurs Cloud Citrix
  • *Une méthode de sortie fiable d’Internet, telle que Cloud NAT
  • *VDA Citrix (instances de machine virtuelle GCP avec le logiciel VDA de Citrix installé sous les applications en cours de livraison)
  • Autre infrastructure, au besoin, pour soutenir les applications livrées

Examinons plus en détail certains de ces services* car ils sont nécessaires pour disposer d’un emplacement de ressources Citrix Cloud fonctionnel sur Google Cloud.

Microsoft Active Directory

Tous les modèles de conception pour les systèmes de virtualisation Citrix sur Google Cloud nécessitent Microsoft Active Directory. Pour une expérience utilisateur convaincante, les services Active Directory doivent être disponibles dans toutes les régions GCP où vous avez déployé des VDA. Ils sont donc considérés comme un composant principal d’un emplacement de ressources Citrix Cloud. AD est utilisé pour la gestion de la configuration (stratégie de groupe) en plus de l’authentification, mais comme nous l’apprenons plus loin, AD n’a pas besoin d’être le fournisseur d’identité pour le système. De nombreux clients étendent leur AD existant dans Google Cloud, bien que la virtualisation Citrix puisse s’intégrer de manière flexible à divers modèles et modèles de maintenance AD.

Lors du déploiement d’Active Directory sur Google Cloud, les clients peuvent créer/gérer leurs propres contrôleurs de domaine Active Directory à l’aide d’instances Windows Server, utiliser le service géré de Google pour 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, le service géré de Google pour Microsoft Active Directory (Managed Microsoft AD en abrégé) 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. Le service Microsoft AD géré est basé sur une infrastructure gérée par Google hautement disponible et fourni sous la forme d’un service géré. Chaque répertoire est déployé sur plusieurs zones GCP, et la surveillance détecte et remplace automatiquement les contrôleurs de domaine qui échouent. Vous n’avez pas besoin d’installer le logiciel, et Google gère tous les correctifs et les mises à jour logicielles. Avec le service géré de Google pour Microsoft Active Directory, vous pouvez utiliser des outils d’administration Microsoft natifs, gérer les machines Windows et les utilisateurs avec la stratégie de groupe Microsoft. Vous pouvez également y joindre des instances de machine virtuelle et même configurer des approbations Active Directory avec des instances AD existantes pour prendre en charge divers scénarios Enterprise complexes.

Les clients qui choisissent d’utiliser le service AD géré de Google avec les technologies de virtualisation Citrix peuvent s’attendre à ce que ces technologies fonctionnent, avec quelques éléments importants à 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. Vous pouvez également configurer et utiliser différents types de relations d’approbation avec d’autres répertoires.

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 Machine Creation Services (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 pouvant être inscriptible. Si vous ne choisissez pas un tel emplacement, MCS n’est pas en mesure de 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 prévoient d’utiliser 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 Google Cloud à l’aide d’instances de machine virtuelle Windows Server.
  • 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 géré Google pour Microsoft AD, vous devrez peut-être 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 ici, Citrix a fourni une documentation détaillée sur ces sujets applicables aux trois modèles de déploiement.

Remarque :

Pour plus d’informations sur les exigences d’Active Directory pour la virtualisation Citrix sur Google Cloud, consultez Détails techniques de Citrix Cloud Connector. Outre les niveaux fonctionnels pris en charge par Active Directory, cet article couvre également les scénarios de déploiement des Cloud Connectors dans Active Directory.

Important :

La résolution de noms DNS est importante pour un système qui fonctionne correctement. DHCP sur GCP utilise toujours les serveurs de noms de Google. Pour que les instances de machine virtuelle « trouvent » et rejoignent votre instance Active Directory sur GCP, vous souhaitez implémenter des zones DNS gérées privées, mais pas nécessaires si vous utilisez le service Microsoft AD géré. Consultez la présentation de Google Cloud DNS pour plus d’informations.

La résolution de nom DNS est également importante lors de la mise en œuvre de la fonctionnalité Rendezvous de Citrix pour le proxy de session HDX, y compris l’utilisation du transport adaptatif EDT/Citrix. Consultez la documentation du protocole Rendezvous pour plus de détails.

Citrix Cloud Connector

Citrix Cloud Connector fonctionne comme un proxy sécurisé géré dans le cloud pour le système de virtualisation Citrix. Cloud Connector sont des instances Windows Server dédiées, jointes à un domaine, dans des zones distinctes au sein d’une région. Il fonctionne également comme un broker de session hors connexion si l’accès Internet est interrompu (« mode cache hôte local ») - utile pour les déploiements stratégiques avec des exigences de disponibilité extrêmes. Nous discutons de cette fonction plus en détail au fur et à mesure que nous abordons le modèle de conception hybride plus loin dans ce document.

Les Cloud Connector sont généralement déployés en tant que ressource N+1, à l’aide d’instances de machine virtuelle réparties sur plusieurs zones d’une région donnée. Cela permet de mettre à l’échelle un emplacement de ressources et de faciliter la mise à jour automatique du logiciel Cloud Connector.

Remarque :

Pour plus d’informations sur le dimensionnement des instances pour les Citrix Cloud Connector, consultez la section Considérations relatives à l’échelle et à la taille pour

Cloud Connector peut s’asseoir sur n’importe quel VPC où ils peuvent atteindre Active Directory et les VDA Citrix, et ils ont besoin d’une sortie Internet fiable pour fonctionner correctement. Une méthode simple et hautement disponible pour fournir une sortie Internet est Google Cloud NAT, bien que de nombreuses autres méthodes soient également prises en charge. Pour les cas d’utilisation avec des contrôles de sortie stricts ou des exigences d’audit, le trafic sortant des Cloud Connector vers Citrix Cloud peut être transmis par proxy.

Remarque :

Pour plus d’informations sur les ports et les protocoles utilisés par les technologies de virtualisation Citrix, consultez Ports de communication utilisés par Citrix Technologies. Ce document fournit la base des règles de pare-feu que vous établissez sur Google Cloud.

VDA Citrix

Le dernier type de ressource dont vous avez besoin pour disposer d’un système de virtualisation Citrix fonctionnel est appelé VDA - et il s’agit de la charge de travail réelle que vous fournissez. Comme mentionné précédemment, il s’agit d’instances de machine virtuelle Windows ou Linux exécutant le logiciel « Virtual Delivery Agent » de Citrix, qui permet aux interfaces utilisateur de bureau ou d’application d’être distantes vers les machines clientes à l’aide du protocole d’affichage HDX de Citrix. Les VDA peuvent être créés et gérés en dehors du système à l’aide de n’importe quel mécanisme de provisioning que vous souhaitez. Par exemple, vous pouvez utiliser des modèles Google Deployment Manager, mais pour tout type d’échelle, vous souhaitez utiliser la technologie MCS de Citrix.

MCS automatise la création de « catalogues de machines » - des groupes de VDA configurés de manière identique construits à partir d’une ou de plusieurs instances de machines virtuelles « golden master ». MCS utilise des instantanés du disque persistant pour capturer l’état du système d’exploitation et de la pile d’applications installés. Il utilise également les attributs d’instance de votre instance de machine virtuelle « golden master » pour créer des modèles d’instance, qui appliquent ces attributs aux VDA sous gestion MCS. MCS automatise également la mise à jour du disque système sur les VDA à l’aide d’instantanés similaires du disque « maître d’or » et orchestre les efforts de la fonction Mise à l’Autoscale pour gérer automatiquement les coûts et la capacité.

Il y a beaucoup de choses à savoir sur les VDA, mais nous approfondissons plus loin dans ce guide. Vous ne pouvez pas attendre ? Consultez directement les considérations relatives à la conception et à la gestion des VDA.

Remarque :

Consultez Ports de communication utilisés par Citrix Technologies pour identifier les règles de pare-feu que vous établissez sur Google Cloud.

Note supplémentaire :

Les VDA n’ont pas besoin d’avoir une sortie Internet - et pour certains cas d’utilisation, ils ne le font pas par conception. Si, toutefois, les VDA disposent d’une sortie Internet, la fonctionnalité « protocole de rendez-vous » peut être activée via la stratégie Citrix, permettant aux appareils clients (qui exécutent l’application Citrix Workspace) et au VDA de se connecter en toute sécurité via Citrix Gateway Service. Cela améliore l’évolutivité des Cloud Connector, qui sont souvent responsables de l’utilisation par proxy des connexions HDX dans les VDA. L’autre option permettant d’établir des connexions proxy des connexions HDX sur des réseaux publics - déployer des instances Citrix ADC/Gateway gérées par le client sur le périmètre du VPC.

Motifs de conception - Aller plus loin

Plus tôt dans ce document, nous avons introduit trois modèles de conception différents mais associés pour la virtualisation Citrix sur Google Cloud. Ces modèles s’accumulent les uns sur les autres, servant efficacement des cas d’utilisation plus complexes en cours de route. Nous les désignons comme :

  • Le modèle de conception de l’avant du cloud
  • Le modèle de conception hybride
  • Le modèle de conception de migration dans le cloud

Le modèle de conception de l’avant du cloud

Nous avons mentionné qu’il s’agit du modèle de conception de base pour la virtualisation Citrix sur Google Cloud. Il devrait être clair que l’architecture du modèle de conception de l’avant cloud crée un emplacement de ressources Citrix Cloud. Il s’agit de la base commune partagée entre les trois modèles présentés ici. Les différences entre les modèles résident dans l’utilisation des technologies pour le service des cinq composants d’un système de virtualisation Citrix décrits dans le tableau suivant. Avec le modèle de conception avancée du cloud, les services cloud sont utilisés pour les cinq composants suivants :

Courtage et administration des sessions Citrix DaaS - (DaaS) (service cloud)
Services d’interface utilisateur Service Citrix Workspace (service cloud)
Authentification Service Citrix Workspace, Active Directory en tant qu’IdP
Proxy de session HDX Service Citrix Gateway (service cloud)
Analyse Citrix Analytics Service (service cloud)

Modèle de conception vers l'avant du cloud

Le modèle de conception de transfert de cloud peut être répliqué en utilisant le même Active Directory (ou non) dans différentes régions Google Cloud. Cela rend le modèle utile pour les déploiements avec des applications et des données distribuées géographiquement. Ce modèle, pour les déploiements de production, est souvent étendu en connectant l’emplacement des ressources dans GCP aux centres de données gérés par le client à l’aide du VPNGoogle Cloud, de Google Cloud Interconnectou d’un produit spécialement conçu comme le SD-WAN de Citrix. Une telle connexion réseau privé vous permet d’étendre les services clés (tels que Microsoft Active Directory) vers Google Cloud. Cela permet aux VDA d’accéder aux applications et aux ressources qui n’ont pas encore été migrées. Il peut également servir de canal pour migrer des applications et des données vers Google Cloud. Bien que cela ne soit pas illustré dans le diagramme précédent, le service de gestion de l’environnement Citrix Workspace est couramment utilisé, en particulier lorsque les systèmes passent en production. Le service Workspace Environment Management utilise des technologies intelligentes de gestion des ressources et Profile Management pour fournir les meilleures performances possibles, ouvrir une session de bureau et temps de réponse des applications pour les déploiements Citrix Virtual Apps and Desktops. Pour plus de détails, consultez la section Gestion de l’environnement utilisateur/des paramètres plus loin dans ce guide.

Le modèle de conception hybride

Plus tôt, nous avons également introduit le modèle de conception hybride. Variante du modèle de transfert cloud, le modèle de conception hybride introduit des implémentations gérées par le client de technologies éprouvées de couche d’accès Citrix pour fournir des services d’interface utilisateur, une authentification et des fonctions proxy HDX. Ces options permettent au système de virtualisation de traiter des cas d’utilisation plus complexes, dont beaucoup sont courants dans les entreprises qui commencent tout juste leur parcours vers le cloud.

le modèle hybride-conception-modèle

Pour placer le modèle de conception hybride dans le contexte des cinq composants d’un système de virtualisation Citrix :

Fonction système de virtualisation : Fait par :
Courtage et administration des sessions Citrix DaaS (service cloud)
Services d’interface utilisateur Service Citrix Workspace (service cloud) OU Citrix StoreFront (géré par le client)
Authentification Nombreuses combinaisons disponibles pour le service Citrix Workspace (service cloud) OU Citrix StoreFront en introduisant Citrix ADC/Gateway (géré par le client)
Proxy de session HDX Service Citrix Gateway (service cloud) OU Citrix ADC/Gateway (géré par le client)
Analyse Citrix Analytics Service (service cloud)

Plus tôt, nous vous avons donné les points forts du moment où l’introduction de Citrix ADC/Gateway et Citrix StoreFront est utile à introduire dans le système de virtualisation Citrix sur Google Cloud :

  • Citrix ADC/Gateway(❷) : déployé en tant qu’appliances virtuelles sur GCP, ce composant est souvent utilisé pour les cas d’utilisation nécessitant un ou plusieurs des éléments suivants :
    • Scénarios d’authentification avancés, tels que SAML/OAUTH 2/OpenID fédération, RADIUS, carte à puce et conditions d’accès conditionnel.
    • Accès aux sessions hautement optimisé et flexible pour les périphériques des utilisateurs finaux sur les réseaux publics.
    • Services de mise en réseau avancés tels que la commutation de contenu, le pare-feu d’application Web, la mise en cache Web intégrée, l’atténuation des attaques, l’équilibrage de la charge des applications et le déchargement SSL.
    • Possibilité de diriger des utilisateurs/appareils spécifiques vers des « magasins » spécifiques en fonction de stratégies avancées, hautement flexibles et contextuelles. Les décisions de stratégie peuvent être basées sur les attributs du profil utilisateur, l’emplacement, le type d’appareil, l’intégrité de l’appareil, les résultats d’authentification, et bien plus encore.
  • Citrix StoreFront(❸) : prédécesseur du service Citrix Workspace, StoreFront est le fournisseur « classique » de services d’interface utilisateur de Citrix. Installé sur des instances Windows Server gérées par le client, StoreFront est souvent utilisé pour les cas d’utilisation nécessitant un ou plusieurs des éléments suivants :
    • Haute disponibilité extrême, capable de survivre aux interruptions de service Internet et cloud.
    • Routage de session flexible, avec possibilité d’acheminer le trafic de session utilisateur interne directement vers les VDA lors de l’envoi d’utilisateurs externes via Citrix Gateways.
    • Sign-on unique à partir d’appareils locaux gérés par le client.
    • La nécessité de fournir plusieurs « magasins » avec des propriétés de configuration différentes pour prendre en charge divers cas d’utilisation sur le même système.
    • La nécessité d’interfaces utilisateur HTML hautement personnalisées ou de marque.

Ce sont les points forts : il y a beaucoup d’autres éléments fonctionnels que vous pouvez également considérer avant de choisir entre le service cloud ou les composants gérés par le client. Nous vous proposons une plongée plus approfondie dans Citrix ADC/Gateway et Citrix StoreFront sur GCP dans les sections suivantes. Vous pouvez utiliser différentes combinaisons de technologies à chaque niveau pour atteindre des résultats spécifiques ou répondre à des besoins spécifiques, au détriment de la simplicité.

Par exemple : les appliances Citrix ADC/Gateway VPX peuvent être ajoutées à un système et utilisées pour l’authentification ou la fonctionnalité proxy HDX lors de l’utilisation des services Citrix Workspace pour l’interface utilisateur. Cela donne au système la capacité de prendre en charge presque toutes les stratégies d’identité et d’authentification (y compris les scénarios de fédération), ainsi que la possibilité d’utiliser le Enlightened Data Transport de HDX pour obtenir les meilleures performances de session sur des réseaux sous-optimaux.

Vous pouvez également introduire Citrix StoreFront à utiliser pour les services d’interface utilisateur, en parallèle ou à la place de Citrix Workspace. StoreFront requiert Citrix ADC/Gateway pour la plupart des cas d’utilisation, mais cette combinaison servirait des cas d’utilisation avec des exigences de haute disponibilité extrêmes, des exigences de personnalisation de l’interface utilisateur lourdes et la possibilité de créer plusieurs « magasins » différents, avec des propriétés différentes, pour différents groupes d’utilisateurs, propriétés de périphérique , les emplacements physiques, et ainsi de suite.

Le modèle de conception de migration dans le cloud

Le modèle de conception de migration vers le cloud est conçu pour permettre à un client d’exécuter un système de virtualisation Citrix hérité et Citrix Cloud sur GCP en parallèle. Les deux options pour fournir des services d’interface utilisateur (service Citrix Workspace et Citrix StoreFront) peuvent agréger les ressources de l’environnement existant et de Citrix Cloud dans une interface utilisateur unique. Cela fournit à l’utilisateur une expérience d’accès cohérente, quel que soit l’endroit à partir duquel les ressources sont lancées.

Un exemple courant : un client Citrix existant, avec un investissement substantiel dans un déploiement géré par le client de Citrix Virtual Apps and Desktops, souhaite commencer à exécuter ses charges de travail d’application et de bureau sur GCP. Peut-être qu’ils ont également plusieurs ‘fermes Citrix ‘qu’ils gèrent actuellement sur site. Le client a déployé Citrix StoreFront et probablement des appliances Citrix ADC/Gateway pour fournir des services d’authentification, d’interface utilisateur et de proxy HDX.

Dans ce scénario, le client utilise probablement déjà la capacité de StoreFront pour regrouper des applications et des postes de travail de leurs multiples « fermes Citrix » en une seule interface utilisateur. Pour commencer à passer à Google Cloud, ils commenceraient par créer un emplacement de ressources Citrix Cloud dans une région de leur choix. En supposant qu’ils se trouvent tous sur le même réseau, ils peuvent simplement ajouter la nouvelle « ferme Citrix » à StoreFront et déployer leur première charge de travail virtualisée sur Google Cloud. Cela leur donne la possibilité d’exécuter des charges de travail Citrix dans deux environnements, côte à côte - certains sur site, d’autres sur GCP - et de migrer les charges de travail vers GCP en fonction des priorités métier le permettent.

cloud-migration-design-pattern

Ce même client peut également exécuter Citrix Workspace côte à côte avec StoreFront et ajouter les anciennes « batteries Citrix » à l’interface utilisateur de Workspace à l’aide de la fonctionnalité d’ agrégation de sites Citrix Cloud. Les deux UI fourniraient l’accès aux mêmes ressources pour les mêmes utilisateurs. Les utilisateurs finaux peuvent être progressivement migrés vers l’interface utilisateur du service Citrix Workspace selon les priorités de l’entreprise.

site-aggregation.png

L’avantage de l’approche de migration dans le cloud est que les services informatiques peuvent migrer les charges de travail des applications et des postes de travail de l’infrastructure locale héritée vers Google Cloud à un rythme qui leur convient. Les utilisateurs peuvent continuer à accéder à leurs applications et postes de travail de la même manière, que la charge de travail soit livrée sur site ou à partir de Google Cloud.

Grâce à l’ agrégation de sites, les clients peuvent également utiliser Citrix Analytics, ce qui leur donne des informations sur la sécurité, les performances et les opérations de leur infrastructure sur site et hébergée dans le cloud. Cela peut aider à prendre des décisions concernant le moment où une charge de travail doit être transférée d’une charge de travail locale vers Google Cloud Platform. Citrix Security Analytics peut également être utilisé pour garantir que, à mesure que les charges de travail sont distribuées sur l’infrastructure locale et Google Cloud, la posture de sécurité du client peut être appliquée.

Migration avec Google VMware Engine

Si vous envisagez le modèle de conception de migration dans le cloud, il y a probablement de bonnes chances que vous exécutiez Citrix sur VMware aujourd’hui. Pour certains clients, la possibilité d’étendre leur infrastructure VMware existante à Google Cloud peut être attrayante. Pour ces clients, cette voie promet d’accélérer les migrations des charges de travail, en utilisant les connaissances existantes et les investissements de processus pour y arriver plus rapidement. Avec Google Cloud VMware Engine, les clients peuvent provisionner et exécuter des centres de données définis par logiciel (SDDC ) basés sur VMware Cloud Foundation(VCF) sur Google Cloud.

Le service Virtual App and Desktops de Citrix permet le provisionnement et la gestion des images des VDA sur les clouds publics VMware VCF. Avant son lancement, Google Cloud VMware Engine a subi un test de compatibilité complet pour devenir Citrix Ready Verified. Les deux plates-formes Citrix Provisioning (MCS et PVS) ont été testées et fonctionnées comme prévu. Pour plus d’informations, consultez Google Cloud VMware Engine sur Citrix Ready.

Lorsque les clients font tourner un SDDC basé sur VCF à l’aide de Google VMware Engine, le SDDC (qui inclut le calcul, le stockage, la mise en réseau et la gestion) est appairé aux réseaux VPC sur Google Compute Engine. Cela vous permet d’exécuter des charges de travail sur le SDDC ou Google Compute Engine, offrant aux clients des options pour diverses charges de travail. Le diagramme logique suivant illustre la relation entre Google Cloud, Citrix Cloud et une instance SDDC gérée :

cloud

Remarque :

Les clients qui ont besoin d’une prise en charge complète de Citrix App Layering ou PVS devraient envisager d’exécuter leur emplacement de ressources Citrix Cloud sur Google Cloud VMware Engine. Citrix App Layering et PVS sont actuellement disponibles sur les plates-formes VMware.

Bien que la conception et la mise en œuvre d’une solution de virtualisation Citrix sur Google VMware Engine ne relèvent pas du champ d’application de ce guide de conception, la plupart des concepts et composants décrits dans ce guide s’appliquent toujours. Pour plus d’informations sur la configuration d’un emplacement de ressources Citrix Cloud sur VMware (Cloud Foundation), consultez la documentation Citrix DaaS.

Résumé

Comme vous pouvez le voir, ces modèles offrent une flexibilité maximale aux clients Citrix existants et leur permettent de se rendre dans le cloud selon leurs conditions. Il n’existe pas d’approche prescriptive unique, mais les clients Citrix peuvent concevoir une solution et une approche de migration qui conviennent le mieux à leur entreprise. Pour ce faire, les clients qui achètent Citrix Cloud Licensing bénéficient également de droits d’utilisation hybride. De nombreux clients disposent également d’un Citrix Customer Success Manager qui les guidera tout au long du processus. Demandez plus d’informations à votre représentant Citrix.

Maintenant que nous avons recelé quelques couches dans le contexte des modèles de conception de la virtualisation Citrix sur Google Cloud, nous allons approfondir quelques autres sujets.

Considérations concernant la conception et la gestion du VDA

La partie la plus dynamique d’un système de virtualisation Citrix est le VDA. N’oubliez pas que les VDA sont l’endroit où le travail réel se produit : les applications et les bureaux que vous fournissez aux utilisateurs sur un système de virtualisation Citrix s’exécutent à partir d’instances de machine virtuelle sur GCP. Vous voulez vous assurer d’obtenir ce calque correct, mais ne laissez pas la perfection s’opposer au progrès ! Fais tes devoirs à l’avant. Définissez l’attente des utilisateurs que le système changera au fil du temps… et construisez des processus simples et efficaces pour gérer le changement : c’est inévitable ! Grâce à la puissance et à la flexibilité de la technologie de virtualisation Citrix, la gestion du changement ne doit pas être un fardeau majeur.

Dans cette section, nous avons tenté de rompre logiquement le sujet afin de pouvoir plonger profondément sans perdre le contexte. Nous faisons de notre mieux pour fournir les détails dont vous avez besoin dans chaque section et faire connaître les meilleures pratiques et recommandations en cours de route.

Nous commençons par examiner les différentes options liées au VDA pour fournir votre combinaison d’applications et de postes de travail, et il y en a beaucoup ! Nous nous plongeons ensuite sur la façon de configurer et d’utiliser les technologies de gestion des images et des parcs VDA de Citrix Cloud, y compris MCS et la fonctionnalité Autoscale. Nous introduisons ensuite des options de gestion de l’environnement utilisateur (paramètres de registre, mappages de lecteur/imprimante, etc.) et de gestion des paramètres utilisateur (profils utilisateur, couches de personnalisation, lecteurs personnels, etc.), nous nous plongeons dans l’optimisation des coûts et la gestion de la capacité, et terminons la section avec plus de réglage des performances considérations.

C’est une quantité ambitieuse de connaissances à distiller - nous allons aller après ça !

Options et considérations relatives à la livraison des charges de travail

Au moment où vous commencez votre voyage de livraison de charge de travail, il est important que nous commencions le processus du bon pied. Cela signifie toucher un couple d’éléments spécifiques non VDA qui doivent être pris en compte en premier. L’une des conversations les plus importantes qu’un bon consultant Citrix a avec un nouveau client concerne les cas d’utilisation que vous allez prendre en charge. Ces conversations (plus d’une, parce que les besoins des clients, le climat commercial et la technologie évoluent au fil du temps) conduisent généralement à la définition de groupes d’utilisateurs et d’applications raisonnablement bien définis - nous les appelons Groupes de mise à disposition. La plupart des options que nous allons décomposer dans cette section sont réévaluées pour chaque groupe de mise à disposition et chaque cas d’utilisation. Il est courant pour les clients d’avoir un certain nombre de variations et même de chevauchement entre les groupes de mise à disposition. En fin de compte, cependant, l’élément le plus fondamental de chaque groupe de mise à disposition est la combinaison d’applications, de données et de services à fournir. Une fois que vous avez défini cette définition, vous pouvez commencer à évaluer les décisions énoncées dans cette section.

Important :

Pour chaque cas d’utilisation/groupe de mise à disposition, commencez par définir la combinaison d’applications, de données et de services nécessaires, puis parcourez les considérations suivantes afin de déterminer quelles options de livraison peuvent le mieux servir chacun.

Conseil :

Les VDA sont gérés dans un groupe de ressources appelé catalogues de machines. Les catalogues de machines sont des groupes d’instances de machines virtuelles qui servent un cas d’utilisation courant à un groupe d’utilisateurs. Ils sont généralement basés sur le même modèle d’instance de machine virtuelle « golden master » et héritent des propriétés d’instance de machine virtuelle et d’une copie généralisée du disque persistant.

Systèmes d’exploitation VDA

Windows ou Linux ?

Maintenant que vous avez défini les applications, les données et les services requis pour chaque groupe de mise à disposition ou cas d’utilisation, vous pouvez commencer à déterminer quel système d’exploitation convient le mieux à vos VDA. La question la plus fondamentale : avez-vous besoin de Windows ou Linux ? Cette décision est souvent forcée par les exigences de l’application ou de l’ensemble d’applications que vous fournissez. Si l’application fonctionne uniquement sur Windows, alors Windows c’est ! Il en va de même si l’application fonctionne uniquement sous Linux.

Les applications métier sont souvent basées sur Windows, de sorte qu’un grand pourcentage d’applications virtualisées Citrix s’exécutent sur des instances de machine virtuelle Windows sur GCP. Parfois, Windows est choisi parce que c’est ce que l’équipe informatique sait, et le coût de la mise en valeur des compétences opérationnelles sur un nouveau système d’exploitation comme Linux est jugé trop élevé, de sorte que Windows est utilisé même si l’ensemble d’applications peut fonctionner sous Linux. Si, cependant, l’ensemble d’applications peut être exécuté sur Linux, il vaut la peine d’être pris en compte - une grande partie de la complexité et une bonne partie des coûts (Windows OS et licences client) peuvent être évitées.

OS de serveur ou de bureau ?

Si vous pouvez utiliser Linux comme système d’exploitation, le choix de « serveur ou bureau » est relativement simple. Vous devez choisir une version dotée d’une interface graphique, pouvant s’exécuter sur Google Cloudet prise en charge par le VDA Citrix Linux.

Si vous déployez Windows, le choix du serveur par rapport au système d’exploitation de bureau devient un peu plus compliqué. Les deux options partagent une interface graphique commune, et les deux peuvent présenter aux utilisateurs un bureau virtuel. En fait, la plupart des applications Windows s’exécutent sur les systèmes d’exploitation Windows Server et Windows 10, bien que souvent les fournisseurs d’applications n’appellent pas la prise en charge de Windows Server dans leur documentation. L’implication la plus importante de Windows Server contre Windows 10 Desktop est une licence - et c’est un grand.

Les stratégies de licence de Microsoft sont restrictives lors de l’exécution de Windows 10 (ou de tout autre système d’exploitation « bureau ») sur les clouds publics. Ces restrictions basées sur des stratégies peuvent rendre plus coûteux l’exécution d’un système d’exploitation de bureau Windows sur n’importe quel cloud public, y compris GCP. Pour plus d’informations sur les stratégies de licence de Microsoft, consultez votre spécialiste des licences Microsoft, mais voici ce qui vous permet de commencer sur cette rubrique complexe :

Si vous exécutez Windows sur GCP, Windows Server sert la plupart des cas d’utilisation et des mélanges d’applications, et vous payez simplement pour l’utilisation de la licence ainsi que l’utilisation de l’instance. Il est souvent plus rentable qu’un ordinateur de bureau Windows et finit par être le choix pour de nombreux systèmes de virtualisation sur Google Cloud.

Système d’exploitation partagé (multi-utilisateurs) ou utilisateur unique (« VDI ») ?

Une idée fausse courante est que Windows Server ne peut pas servir de cas d’utilisation du bureau, que vous partagiez le système d’exploitation entre plusieurs utilisateurs ou si vous possédez une instance OS/VM par utilisateur. Cette idée fausse est fausse ! Lorsqu’il est déployé en mode multi-utilisateurs (c’est-à-dire que le rôle RDSH est installé), Windows Server peut présenter aux utilisateurs un bureau « partagé hébergé ». Windows Server peut également être utilisé pour les cas d’utilisation « VDI », et même s’il n’est pas aussi rentable ou évolutif que l’option multi-utilisateurs/système d’exploitation partagé, il s’agit d’une option légitime pour un poste de travail utilisateur unique. Nous appelons ce modèle de livraison « Serveur VDI ».

En résumé, les combinaisons d’options/systèmes d’exploitation suivantes peuvent être utilisées en fonction du cas d’utilisation :

Modèle de livraison Un ou plusieurs utilisateurs Versions/composants du système d’exploitation courants Coût relatif à l’exécution sur Google Cloud
Partagés hébergés Multi-utilisateurs Windows Server (2016 ou 2019), le rôle RDSH et l’expérience de bureau activés.
Server VDI Utilisateur unique Windows Server (2016 ou 2019), Expérience de bureau activée. ⭐⭐⭐
VDI de bureau Utilisateur unique Windows 10 (licence BYO et STN requis) ⭐⭐⭐⭐⭐

Une autre idée fausse courante est que les nœuds à locataire unique (STN) de Google Cloud sont nécessaires pour servir des cas d’utilisation « bureau ». Les nœuds locataires uniques sont requis pour se conformer aux scénarios de licence BYO de Microsoft tels que le système d’exploitation Windows 10 (bureau). Comme mentionné ci-dessus, Windows Server peut être utilisé pour fournir un poste de travail mono-utilisateur (« Serveur VDI ») en plus d’un poste de travail multi-utilisateur (hébergé partagé). Les nœuds locataires uniques peuvent également être utilisés pour les instances Windows Server lorsque vous apportez votre propre licence Windows Server.

La plupart des saveurs de Linux sont multi-utilisateurs capables de sortir de la boîte. En tant que tels, ils peuvent être déployés dans des modèles hébergés partagés ou « Serveur VDI », avec des implications de coûts relatifs similaires.

Remarque :

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 différencie pas explicitement les modèles VDI client et VDI serveur, mais les décisions présentées sont valides pour les deux. Lorsqu’un cas d’utilisation suggère que VDI est le modèle de livraison approprié pour votre charge de travail, le serveur VDI doit être pris en compte dans la mesure du possible pour s’exécuter sur Google Cloud.

Postes de travail publiés ou applications publiées ?

En fin de compte, les applications virtualisées que vous fournissez aux utilisateurs dans un système de virtualisation Citrix s’exécutent sur des VDA. Vous avez des options pour la façon dont vous les présentez, ce qui détermine la façon dont les utilisateurs interagissent avec eux. Vous pouvez présenter à l’utilisateur, ou « publier » des applications et des fichiers individuels. Vous pouvez également leur présenter un bureau sur lequel ils interagissent avec les applications et les données.

publiés-desktops-publié-applis

Exemple : un bureau partagé hébergé, présenté comme une application fenêtrée dans l’application Citrix Workspace pour Windows.

Il y a plus à ce choix (et de nombreux clients utilisent les deux), mais voici une tentative de résumer :

Postes de travail publiés (hébergés partagés et VDI) :

   
+ Offrez aux utilisateurs une métaphore familière pour interagir avec les applications et les données du système. Peut être plus simple pour les utilisateurs à saisir et à obtenir une utilisation productive. Idéal pour fournir des environnements flexibles avec de nombreuses applications.
- Les utilisateurs s’attendent à ce que les choses fonctionnent comme elles le font sur un bureau. Vous travaillez plus fort pour équilibrer la sécurité avec l’accès et les fonctionnalités, et vous gérez un bureau Windows. Les profils utilisateur, les paramètres d’application, le stockage des données et la gestion de la configuration des postes de travail deviennent essentiels. Doublement si les utilisateurs s’attendent à ce que les paramètres soient en itinérance entre les régions.
- Exiger davantage de ressources d’instance de machine virtuelle - les services de bureau Windows consomment plus de ressources pour chaque utilisateur par rapport aux applications publiées.

Applications publiées :

   
+ Les applications publiées sont souvent plus faciles à sécuriser, nécessitent moins de ressources à fournir et peuvent offrir aux utilisateurs une expérience utilisateur plus simple. Citrix appelle ceci « fenêtres transparentes ».
- L’expérience utilisateur peut se compliquer avec un plus grand nombre d’applications publiées.
+ Nécessite toujours la gestion des profils utilisateur, des paramètres d’application et du stockage des données, mais souvent plus simple et plus flexible dans l’exécution par rapport aux postes de travail publiés.
+ Nécessité moins de ressources d’instance de machine virtuelle par rapport aux Présentation du Bureau Windows. Plusieurs applications publiées s’exécutent généralement dans la même session - une fonctionnalité Citrix appelle le partage de session.

Pooled ou persistant ?

Ce choix est une autre propriété du catalogue de machines et est défini lors de la création du catalogue. Le modèle de remise partagée hébergé utilise généralement des VDA groupés ou non persistants, mais les deux modèles VDI peuvent utiliser des catalogues de machines groupés ou persistants. Avec le modèle groupé, les instances du système d’exploitation sont réinitialisées par MCS lors de la fermeture de session ou du redémarrage du VDA. Ce modèle garantit que les utilisateurs obtiennent une image système « propre », qui est à son tour basée sur votre modèle ou instance (s) de machine virtuelle (s) et des instantanés de son disque persistant. Ils sont appelés « pool » car un pool de VDA est maintenu et les utilisateurs sont connectés dynamiquement à un VDA disponible/inutilisé dans le pool. Les paramètres utilisateur et les données peuvent être gérés de plusieurs façons différentes. Avec les VDA groupés, ils sont gérés de telle sorte que l’utilisateur obtient la même configuration et l’expérience quel que soit le VDA auquel il est connecté. Pour plus de détails à ce sujet, reportez-vous à la section Gestion de l’environnement utilisateur et des paramètres dans ce document.

Les catalogues de machines persistants contiennent des instances VDA qui sont affectées à des utilisateurs individuels et qui persistent entre les redémarrages. Ce modèle est utile pour les scénarios où les utilisateurs doivent installer leurs propres applications (comme les environnements de développement) et les cas d’utilisation où les applications nécessaires ne sont pas compatibles avec plusieurs utilisateurs.

Les instances groupées ont tendance à être les plus faciles à gérer au fil du temps, car le MCS de Citrix peut mettre à jour les disques système attachés aux instances regroupées en quelques clics. La gestion des capacités et des coûts tend également à être 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 aux instances groupées ne persistent généralement pas entre les redémarrages. Des technologies telles que Citrix User Personalization Layer peuvent être utilisées pour conserver les modifications initiées par l’utilisateur dans les sessions sur différents VDA groupés, bien qu’elles ne soient compatibles qu’avec les cas d’utilisation « VDI » à utilisateur unique.

Les instances persistantes peuvent être plus simples à déployer, mais plus difficiles à gérer au fil du temps, car vous devez gérer les correctifs OS/applications, la mise à niveau et la maintenance au sein de la machine virtuelle. Il peut également s’avérer plus coûteux du point de vue coût/capacité, car il est souvent difficile de prévoir quand un utilisateur se connectera. Cela signifie que les utilisateurs doivent attendre pendant le démarrage de leur instance, ou les administrateurs doivent les maintenir en cours d’exécution pendant les fenêtres temporelles où chaque utilisateur est censé ouvrir une session.

Géré ou non géré ?

Les catalogues créés et gérés par MCS peuvent contenir des clones persistants ou non persistants d’instances de machine virtuelle de modèle (ou « maître d’or »). Les catalogues de machines peuvent également être approvisionnés avec un autre processus ou une autre technologie. De toute façon, vous voulez vous assurer qu’ils sont créés en tant que gestion de l’alimentation :

gérée non gérée

Si vous n’utilisez pas de catalogues de machines à gestion de l’alimentation, les fonctionnalités clés telles que Citrix Autoscale ne fonctionneront pas et vous n’aurez pas d’aide pour gérer les coûts et la capacité. L’utilisation de MCS pour le provisionnement et la gestion de flotte de VDA apporte une foule d’avantages utiles aux administrateurs, mais les VDA « non gérés » - ceux provisionnés en dehors de Citrix - peuvent également être utilisés. Nous aborderons ces avantages dans la section Gestion des flottes et des images plus loin dans ce guide.

Accélération GPU ?

Certains types d’applications déployées sur des VDA peuvent bénéficier des ressources GPU si elles sont disponibles pour l’instance de machine virtuelle. Les trois modèles de livraison (partagé hébergé, VDI serveur et VDI de bureau, pour Linux et Windows) peuvent utiliser des instances GPU accélérées NVIDIA pour les charges de travail graphiques sur Google Cloud. Ces GPU pour stations de travail virtuelles peuvent être attachés à des types de machines N1 à usage général pour les charges de travail exigeantes en graphiques telles que la visualisation 3D, la conception de puces, la CAO/FAO, les graphiques et l’édition vidéo, et incluent la licence GRID requise.

Avec le pilote NVIDIA GRID approprié installé sur l’instance, le logiciel VDA de Citrix détecte la présence du GPU et se configure correctement.

Conseil :

La pile de protocoles d’affichage HDX de Citrix effectue beaucoup de détection automatique et d’adaptation à la volée pour offrir la meilleure expérience utilisateur possible. Cependant, il essaie également d’équilibrer les performances, la réactivité et la richesse de l’UX avec la consommation de bande passante. Ainsi, les charges de travail gourmandes graphiques bénéficient souvent d’un réglage précis pour obtenir un équilibre correct. Pour plus d’informations, consultez la section Présentation des graphiques HDX . Notez que Citrix fournit un modèle de stratégie appelé « Expérience utilisateur très haute définition » (comme indiqué dans la section Conception de la stratégie de base). Ce modèle peut être utilisé comme point de départ pour affiner votre environnement spécifique.

Gestion des flottes et des images

La virtualisation Citrix sur Google Cloud inclut des fonctionnalités intégrées conçues pour simplifier le provisionnement VDA et la gestion des images à grande échelle. Ces fonctionnalités sont souvent appelées « Services de création de machines », ou MCS pour résumer. MCS utilise les comptes de service IAM sur Google Cloud pour faciliter la gestion des VDA sur GCP.

Conseil :

Avant de vous plonger dans la configuration et l’utilisation de MCS sur GCP, consultez la documentation Citrix sur la configuration et l’utilisation de MCS dans les environnements de virtualisation Google Cloud Platform. Ce document vous guide à travers l’activation des API Google Cloud, la création et la configuration du compte de service IAM, la création de connexions et de ressources d’hébergement, et bien plus encore.

Problèmes et limites du MCS

MCS présente quelques limitations importantes que vous devez connaître avant de déployer un système de virtualisation Citrix sur GCP aujourd’hui. Comme l’ensemble de fonctionnalités MCS est fourni en tant que service cloud, vous pouvez vous attendre à ce que cette liste change au fil du temps au fur et à mesure que le service évolue. Dans l’intervalle, vous devez les connaître afin que vous puissiez ajuster votre plan de conception et d’exécution en conséquence.

Les problèmes/limitations connues sont les suivantes :

  • Provisionnement des VDA Linux. MCS sur GCP n’a pas été entièrement testé pour le provisionnement des VDA Linux, donc cette option n’est pas prise en charge actuellement. Exécuter des VDA Linux sur Google Cloud, même avec des GPU connectés, est. Pour contourner ce problème : provisionnez des instances de machine virtuelle Linux en dehors de MCS à l’aide de modèles Google Deployment Manager ou d’un autre mécanisme, puis ajoutez des instances préprovisionnées à un catalogue de machines à gestion de l’alimentation pour l’attribution et la gestion de l’alimentation.

Importation d’images VDA à partir de locaux

Les images VDA personnalisées sont quelque chose que de nombreux clients peuvent déjà avoir et souhaitent utiliser sur GCP. Bien que le déploiement d’une nouvelle instance et la configuration à partir de zéro sont préférables, il peut arriver que cela ne soit pas possible. Par exemple, il peut y avoir une image de base qui a été configurée sur site où les propriétaires d’applications ou les dépendances d’application ne sont pas connus, mais sont utilisés pour les opérations métiers critiques. Heureusement, sur GCP, vous pouvez importer votre image locale dans GCP. L’importation est également nécessaire lors du déploiement de variantes de système d’exploitation client Windows (Windows 10), car les systèmes d’exploitation client Windows ne sont pas disponibles en mode natif dans le catalogue d’images de Google Cloud. Pour plus d’informations, consultez la section Importation d’un disque virtuel.

Remarque :

Avant d’importer un disque existant, assurez-vous de lire et de comprendre les différences entre l’ importation d’un disque virtuel depuis votre environnement sur site. Dans la mesure du possible, il est préférable de déployer de nouvelles instances à partir de la bibliothèque d’images publique et de créer vos images principales à partir de zéro.

Utilisation des nœuds à locataire unique sur GCP

Google Cloud dispose d’une fonctionnalité appelée nœuds à locataire unique qui est utile pour divers cas d’utilisation, y compris l’utilisation de votre propre licence pour le système d’exploitation Windowset le déploiement de VDA clients Windows sur GCP. Lorsque vous configurez des nœuds à locataire unique, vous pouvez les configurer dans une ou plusieurs zones d’une région GCP. Citrix MCS prend entièrement en charge le provisionnement des VDA sur les nœuds à locataire unique, mais n’est pas automatiquement conscient des zones GCP dans lesquelles vos nœuds locataires sont déployés. Si vous avez l’intention de déployer des VDA sur des nœuds à locataire unique, consultez la documentation de sélection de zone GCP pour plus de détails.

Remarque :

Pour obtenir un bon didacticiel sur le déploiement de Windows 10 sur GCP, consultez le guide POC GCP Windows 10 Sole Tenant with Optional Shared VPC Catalog Creation . L’article couvre à la fois l’importation d’images personnalisées et l’utilisation du nœud locataire unique sur GCP.

Optimisation des coûts et gestion de la capacité

Lorsque vous exécutez des VDA sur Google Cloud, vous payez les ressources de calcul, de stockage et de mise en réseau que vous utilisez. Cela signifie qu’il existe une corrélation directe entre la quantité de capacité que vous consommez et les coûts que vous engagez. Les choix que vous faites et les pratiques que vous adoptez ont une corrélation directe avec le coût opérationnel du système de virtualisation.

Tout d’abord, assurez-vous de choisir les bonnes options de répartition de la charge de travail, c’est-à-dire les sujets que vous venez de lire si vous lisez ceci de front en arrière. Celles-ci peuvent avoir un impact spectaculaire sur le coût total de la solution ! Voici quelques autres recommandations et sujets à prendre en considération lorsque vous travaillez à équilibrer coût et capacité et optimiser l’expérience utilisateur.

Provisioning à la demande

Lorsque vous utilisez MCS pour créer des catalogues de machines non persistants dans Compute Engine, MCS utilise le provisionnement à la demande pour réduire vos coûts de stockage, accélérer la création de catalogue et accélérer les opérations d’alimentation des instances. Avec le provisionnement à la demande, les instances Compute Engine sont créées uniquement lorsque Citrix DaaS lance une action de mise sous tension. Le provisionnement à la demande est utilisé pour les catalogues de machines non persistants.

Remarque :

Certains administrateurs trouvent le provisionnement à la demande déroutant au départ, car les instances VDA ne s’affichent pas dans la console Google Cloud tant que MCS ne les a pas mises sous tension. En outre, étant donné que les instances reçoivent une nouvelle carte réseau virtuelle et une adresse MAC, il peut prendre un certain temps pour que les entrées DNS Active Directory puissent mettre à jour/répliquer correctement. Les disques d’identité VDA NE persistent entre les redémarrages et les événements de création/suppression.

Dimensionnement optimal des instances VDA

Maintenant que vous avez un aperçu des décisions importantes liées aux options de livraison de charge de travail, approfondissez la taille adéquate de vos instances VDA. Pour les modèles de mise à disposition basés sur VDI, la sélection du bon type d’instance est simple. En supposant que vous avez fait quelques recherches et que vous avez une bonne compréhension des exigences en matière de ressources du système d’exploitation, des applications et des utilisateurs des instances VDI, vous pouvez simplement mapper ces exigences avec les types d’instances disponibles dans la région Google Cloud de votre choix. Ne vous inquiétez pas si vous ne disposez pas d’une correspondance parfaite entre les types d’instance disponibles et les exigences de charge de travail. Google Cloud prend en charge les types d’instances personnalisés, qui vous permettent de modifier la forme de vos instances de VDA au fur et à mesure. L’utilisation soutenue et les remises sur l’utilisation engagée s’appliquent toujours aux types d’instance personnalisés, donc ne laissez pas cela vous dissuader de vous ajuster au besoin pour obtenir la bonne taille à l’avance.

De plus, la fonctionnalité de recommandations de taille de Google Cloud peut être utilisée pour identifier les ajustements que vous souhaiterez apporter aux formes VDA au fil du temps.

Dimensionnement optimal des instances VDA

Remarque :

Une chose importante à noter : la consommation de ressources de la charge de travail peut changer au fil du temps. Parfois, les événements/activités réduisent les besoins en ressources, comme lorsqu’un administrateur applique des optimisations à l’environnement. Inversement, ces exigences montent parfois, par exemple lorsqu’une vulnérabilité du système d’exploitation ou d’application est corrigée, ou lorsqu’une mise à jour est appliquée. Trouvez votre ligne de base, mais il est important de surveiller les tendances de consommation au fil du temps et de les ajuster au besoin pour trouver l’équilibre optimal entre les performances utilisateur et les coûts.

Lorsque vous sélectionnez la taille d’instance appropriée pour les VDA partagés hébergés, les choses deviennent un peu plus compliquées. Ce que vous recherchez en fin de compte est une cible mobile : le bon équilibre entre performances, coûts et facilité de gestion. Pour compliquer davantage les choses, chaque charge de travail est différente. Les écarts entre les systèmes d’exploitation, les applications, les paramètres, les réglages et les attentes des utilisateurs rendent difficile de définir les formes appropriées pour vos VDA. Elle a également tendance à changer au fil du temps.

Heureusement, les outils et techniques permettant de trouver un équilibre entre les « boules d’or » entre performance, coût et facilité de gestion sont bien connus et bien documentés. Un excellent article que nous recommandons de commencer est Citrix Scalability in a Cloud World 2018 Edition. Cet article est toujours pertinent aujourd’hui car il traite des meilleures pratiques en matière de sélection d’instances en fonction des performances, de la facilité de gestion, des coûts, des modèles de tarification disponibles 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.

Un autre article qui mérite d’être mentionné est le dimensionnement correct de Citrix sur Google Cloud Platform. Bien que quelques dates, cet article approfondisse encore les considérations et fournit un exemple de la façon de trouver le type d’instance le plus rentable basé sur une mise à l’échelle VDA unique et les coûts de votre instance.

Enfin, pour plus d’informations sur les stratégies d’optimisation des coûts des VDA, consultez cette fiche technique Autoscale sur Citrix TechZone. Cela permet d’aligner les estimations de coût de votre instance sur les fonctionnalités de la fonctionnalité Citrix Autoscale, y compris l’utilisation de l’équilibrage de charge vertical.

En parlant de Citrix Autoscale, lisez-le et utilisez-le : avec un peu de réflexion et de conception intelligente, vous pouvez optimiser les coûts de votre flotte VDA tout en vous assurant d’avoir une capacité disponible pour gérer les fluctuations attendues et inattendues de la demande système.

En parlant de modèles de demande, vous voulez investir du temps et des ressources pour comprendre les schémas uniques de chaque charge de travail. Attendez-vous à ce qu’ils changent et évoluent au fil du temps, et soyez prêt à adapter votre stratégie et vos tactiques de gestion de la capacité pour les adapter.

Choisir les bons modèles de tarification

Google Cloud propose différents modèles de tarification que les clients peuvent utiliser pour les différents types de charges de travail que vous y exécutez. Comprendre les schémas de demande pour différents cas d’utilisation peut vous aider à choisir le bon modèle pour chaque ressource afin d’équilibrer les coûts et la disponibilité et les performances du service. Dans un système de virtualisation Citrix, les clients considèrent généralement une utilisation soutenue par rapport à des modèles de remise à usage engagé pour les ressources qui s’exécutent sur GCP. Les remises sur une utilisation soutenue peuvent varier selon les types d’instance (N1 vs N2, par exemple) et certains types d’instance (tels que E2) n’offrent pas de rabais sur l’utilisation soutenue. Consultez la tarification des instances de VM pour plus de détails.

Voici un graphique simplifié illustrant l’utilisation soutenue par rapport aux réductions d’utilisation validée pour les types d’instance N1 :

optimisation des coûts

Certaines ressources sont uniques, hautement évolutives et doivent être disponibles pour qu’un système de virtualisation Citrix fonctionne. En tant que tels, ils sont couramment exécutés 24 heures sur 24 et 7j/7 et déployés N+1 pour la disponibilité, et sont d’excellents candidats pour l’actualisation des utilisations engagées. Cela inclut les instances Active Directory, Citrix Cloud Connector, Citrix ADC/Gateway VPX et Citrix StoreFront VM.

Pour les instances VDA, le choix n’est pas aussi simple, mais plus vous comprenez clairement vos modèles de demande, plus le choix est clair. Tout se résume à combien de temps le VDA doit être mis sous tension. Considérez le graphique suivant (spécifique aux types d’instance N1), qui est reproductible avec un peu de mathématiques back-of-the-enveloppe :

seuil de rentabilité

Ce diagramme montre que si une ressource (exécutée sur un type d’instance N1) est active pendant plus de 50 % du temps au cours d’un cycle de facturation donné, vous commencez à économiser de l’argent si vous pouvez appliquer une réduction d’utilisation validée de 3 ans. Le point d’équivaut à un rabais pour utilisation engagée d’un an est d’environ 82 %. Si une ressource doit être alimentée plus que cela pendant un cycle de facturation et qu’une utilisation validée de 3 ans n’est pas disponible, alors une utilisation validée de 1 an est logique.

Considérations relatives à l’ajustement

De nombreux facteurs peuvent contribuer à la perception des performances que les utilisateurs obtiennent sur votre système de virtualisation Citrix. Outre la sélection de la bonne forme d’instance de machine virtuelle pour vos VDA, d’autres domaines clés à étudier pour l’optimisation des performances sont les suivants :

Choix de gestion de l’environnement utilisateur et des paramètres : les stratégies sont vos amis lors de la gestion et de l’optimisation des performances pour vos utilisateurs. Les stratégies contrôlent la configuration de Windows, des applications, des sessions et bien plus encore. Pour compliquer davantage les choses, il existe plusieurs moteurs de stratégie que vous pouvez potentiellement utiliser, chacun ayant leur propre impact sur l’expérience utilisateur. Il est important de choisir le bon moteur de stratégies et d’établir des niveaux de référence cohérents et, heureusement, ils sont abordés en détail dans Baseline Policy Design. Le service de gestion de l’environnement Citrix Workspace peut également être utilisé pour optimiser l’expérience utilisateur et simplifier la gestion dans un environnement diversifié.

Optimisation de Windows : Windows est un système d’exploitation à usage général et est conçu pour couvrir une grande variété de cas d’utilisation, de types matériels, etc. La plupart des paramètres par défaut de Windows ne sont pas nécessaires dans un environnement de virtualisation Citrix. Heureusement, Citrix Optimizer est disponible pour vous aider et inclut de nombreux modèles complets que vous pouvez appliquer à vos VDA pour obtenir les meilleures performances possibles et une utilisation globale des ressources la plus faible possible.

Réglage antivirus : l’exécution d’un logiciel antivirus sur les VDA Citrix et l’infrastructure de prise en charge est une pratique solide et recommandée. Cependant, s’il est incorrectement installé/configuré, il peut causer des ravages sur l’expérience utilisateur. Consultez Endpoint Security and Antivirus Best Practices pour découvrir comment faire les choses correctement.

Optimisation du protocole HDX : lapile de protocoles d’affichage HDX de Citrix effectue de nombreuses fonctions de détection automatique et d’adaptation à la volée pour offrir la meilleure expérience utilisateur possible. Il tente d’équilibrer les performances, la réactivité et la richesse de l’UX avec la consommation de bande passante. Pour certains cas d’utilisation (par exemple, les charges de travail intensives en graphiques ou les connexions réseau de faible qualité ou de mauvaise qualité) bénéficient souvent d’un réglage fin pour obtenir le juste équilibre. Pour plus d’informations, consultez la section Présentation des graphiques HDX . Le SD-WAN de Citrix peut également aider à optimiser et à mesurer l’expérience utilisateur HDX.

En outre, Citrix fournit plusieurs modèles de stratégie de session prédéfinis qui peuvent être utilisés pour faire correspondre de manière flexible les paramètres à vos cas d’utilisation spécifiques. Ces stratégies sont configurées et gérées dans Citrix Cloud Studio et peuvent être appliquées à l’aide de différents filtres. Ces filtres vous permettent de vous assurer que la bonne stratégie est appliquée pour optimiser des scénarios spécifiques.

Optimisation du protocole HDX

Gestion de l’environnement utilisateur/des paramètres

La conception et la gestion des paramètres et des données utilisateur sont l’un des éléments les plus complexes et les plus importants d’un système de virtualisation Citrix. Lorsque cela est fait correctement, l’ouverture de session ou la fermeture de session est rapide et fiable. Les applications sont préconfigurées pour les utilisateurs, et les utilisateurs bénéficient d’une expérience cohérente et prévisible quel que soit le VDA auquel ils se connectent. Lorsqu’il est mal fait ou ignoré, l’expérience utilisateur peut en souffrir considérablement.

Heureusement, les décisions de gestion de l’environnement utilisateur et des paramètres sont communes à tous les systèmes de virtualisation Citrix, quelle que soit la plate-forme sur laquelle les VDA sont déployés. Ils sont aussi bien documentés. Ces décisions dépendent fortement de l’emplacement de l’utilisateur, de la connectivité de l’utilisateur final et des exigences de sécurité. En tant que tel, nous n’allons pas aborder ce sujet en profondeur ici, mais nous vous démarrons avec quelques références. Il existe de nombreuses options qui peuvent être adaptées à vos besoins spécifiques.

Voici quelques liens pour vous lancer :

   
Workspace Environment Management Service Le service Workspace Environment Management utilise les technologies intelligentes de gestion des ressources et Profile Management pour fournir les meilleures performances possibles, ouvrir une session de bureau et temps de réponse des applications pour les déploiements Citrix Virtual Apps and Desktops.
Conception de stratégie de base Cet article décrit les différentes décisions de stratégie à prendre lors de l’utilisation des stratégies Citrix.
Profile Management Un article décrivant quelques bonnes pratiques en matière de Profile Management.
Planifier votre déploiement Une excellente ressource pour vous aider à planifier Profile Management dans un système de virtualisation Citrix.
Couche de personnalisation utilisateur Citrix Pour les cas d’utilisation VDI (utilisateur unique, instance de système d’exploitation unique), la technologie de couche de personnalisation utilisateur de Citrix peut être utilisée pour simplifier considérablement la gestion du système. Citrix UPL permet aux administrateurs d’utiliser des catalogues de machines groupés ou non persistants tout en offrant aux utilisateurs une expérience utilisateur cohérente et personnalisée sur les instances VDA. La couche utilisateur est conservée en tant que fichier de disque dur virtuel sur un partage de fichiers Windows. Il est monté sur le VDA lors de l’ouverture de session et capture les modifications apportées par l’utilisateur au sein de la session, y compris les applications installées par l’utilisateur. La couche utilisateur est montée sur le VDA lors de l’ouverture de session et détachée lors de la fermeture de session.

Stockage de fichiers et réplication de données

La plupart des systèmes de virtualisation Citrix sur GCP 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. Les partages de fichiers Windows sont également utilisés pour stocker les couches de personnalisation utilisateur Citrix. Lorsque ces partages ne sont pas disponibles, l’expérience utilisateur et les fonctionnalités de l’application en souffrent. Il est important de s’assurer que quelle que soit la solution que vous choisissez de fournir, les partages de fichiers compatibles Windows sont hautement disponibles et 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 de fichiers et de réplication de données sur GCP.

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 GCP.

Géré par le client : Serveurs de fichiers Windows sur Google Compute Engine

La première solution envisagée par de nombreux clients pour fournir des services de fichiers compatibles Windows sur GCP consiste à construire leurs propres serveurs de fichiers Windows sur le moteur de calcul pour servir chaque emplacement de ressources sur GCP. É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 crée une ou plusieurs instances Windows, attache plus de disques persistants, joint les instances à leur Active Directory et termine la configuration des 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 à l’aide de serveurs de fichiers situés dans plusieurs zones et en utilisant Windows DFS-N/DFS-R, des clusters de basculement Windowsou des espaces de stockage directs. Il est 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.

Tiers

Une autre solution consiste à utiliser des solutions tierces telles que NetApp Cloud Volumes ONTAP ou Cloud Volumes Services for GCP. Les deux solutions vous permettent de créer des partages SMB compatibles qui peuvent être utilisés pour vos besoins de stockage. L’utilisation de solutions de stockage tierces présente des avantages par opposition à la gestion de vos propres serveurs de fichiers Windows, par exemple une réduction des frais administratifs lors de la gestion du stockage. Consultez la section Serveurs de fichiers sur Compute Engine pour plus d’informations.

Citrix ADC/Gateway VPX sur Google Cloud

Le déploiement de Citrix ADC/Gateway sur GCP diffère du déploiement local, bien qu’en fin de compte, vous les gérez vous-même. Heureusement, le déploiement de Citrix ADC/Gateway sur GCP est documenté en détail. Nous vous recommandons de consulter les ressources suivantes avant de consolider votre conception et de commencer la mise en œuvre :

  • Citrix ADC VPX on GCP dans Citrix Docs : fournit une vue d’ensemble complète de Citrix ADC sur GCP, y compris les modèles VPX pris en charge, les régions GCP, les types d’instances de Computer Engine et d’autres références de ressources.
  • Déploiements Citrix ADC VPX GCP Marketplace : toutes les solutions de déploiement réseau Citrix disponibles sur GCP Marketplace. Fonctionnel et pertinent pour les déploiements de Citrix Gateway avec CVAD/DaaS également.
  • Modèles Citrix ADC GDM : un référentiel GitHub pour les modèles Citrix ADC GDM. Il s’agit d’une excellente référence pour un référentiel qui héberge des modèles Citrix ADC pour le déploiement d’une instance Citrix ADC VPX sur Google Cloud Platform.

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

  • Autonome : les instances individuelles de Citrix 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 Citrix ADC/Gateway VPX peuvent être déployées à l’aide d’une configuration HA au sein de la même zone ou sur plusieurs zones de la même région. Nous creusons dans cette option plus loin dans cette section.

Meilleure pratique :

Lorsque vous déployez des appliances Citrix ADC/Gateway sur GCP, nous vous recommandons d’utiliser des adresses IP externes Premium (régionales). Lors de l’utilisation d’adresses IP externes de niveau premium, le trafic entre et sortie à l’emplacement réseau Edge le plus proche de l’utilisateur. Le trafic traverse ensuite le réseau privé de Google pour se rendre à la région où la ressource est déployée. Cela fournit un meilleur débit, une latence plus faible et des performances plus cohérentes (plus faible gigue) par rapport aux adresses IP externes standard. Pour plus d’informations, consultez Niveaux de service réseauGoogle Cloud.

ADC autonome

Alors que Citrix 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 réseaux VPC pour chaque ADC lors du déploiement sur GCP, avec une interface réseau dans chaque VPC pour un débit optimal et une séparation des données. Lorsqu’elle est déployée pour prendre en charge Citrix Virtual Apps and Desktops, l’interface de gestion (NSIP) est généralement associée au « sous-réseau d’infrastructure Citrix privé », l’adresse IP du sous-réseau (SNIP) est attachée au « sous-réseau privé Citrix VDA » et l’adresse IP virtuelle Citrix Gateway (VIP) vers le « Sous-réseau public. » Le diagramme conceptuel simplifié suivant illustre cette configuration. Il montre une seule instance VPX dans une seule zone - ce modèle de conception serait dupliqué (probablement dans une deuxième zone) pour une configuration haute disponibilité :

ADC autonome

Le tableau suivant présente le but de chaque carte réseau ainsi que le réseau VPC associé :

Carte d’interface réseau Objectif Réseau VPC associé
NIC 0 Sert le trafic de gestion (NSIP) (❶) Réseau de gestion
CARTE RÉSEAU 1 Sert le trafic côté client (VIP) (❷) Réseau public
NIC 2 Communication avec les serveurs back-end (SNIP) (❸) Réseau de serveurs back-end

Important :

Les instances Citrix ADC VPX avec trois cartes réseau nécessitent un minimum de 4 processeurs virtuels lors de l’exécution sur GCP. Reportez-vous à la section Nombre maximal d’interfaces réseau pour plus d’informations.

Haute disponibilité ADC dans toutes les zones

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 Citrix ADC dans une seule région déployée sur plusieurs zones. La haute disponibilité (actif/passive) peut être obtenue de plusieurs façons. Vous pouvez utiliser un équilibrage de charge HTTPS GCP avec les ADC configurés indépendamment les uns des autres ou à l’aide de Citrix ADCs HA configurés en mode INC (Independent Network Configuration). Cette dernière option/architecture devrait être populaire pour les déploiements de cloud public. Nous nous concentrons donc sur cela ici.

Bien qu’il existe des variantes potentielles pour une architecture Citrix ADC/Gateway VPX sur GCP, le diagramme suivant illustre une solution Citrix ADC HA à trois cartes réseau. Cette solution peut être déployée par le modèle Google Deployment Manager avec des réseaux et des sous-réseaux VPC préconfigurés :

architecture-conceptuelle

Lorsque vous utilisez le modèle Google Deployment Manager, vous devez configurer les réseaux VPC avant de déployer les appliances Citrix ADC. Les trois réseaux de VPC devraient être constitués du (❶) réseau de gestion, (❷) du réseau public et (❸) du réseau principal et des sous-réseaux appropriés au sein de chaque réseau de VPC.

flux de trafic

Dans le diagramme précédent, nous pouvons voir que chaque ADC a une IP virtuelle de passerelle différente (VIP). Il s’agit d’une caractéristique d’une configuration réseau indépendante (INC). Lorsque les VPX d’une paire HA résident dans des zones différentes, l’ADC secondaire doit avoir un INC, car ils ne peuvent pas partager les adresses IP mappées, les réseaux locaux virtuels ou les routes réseau. Le NSIP et le SNIP sont différents pour chaque ADC dans cette configuration, tandis que le VIP Citrix Gateway utilise une fonctionnalité Citrix ADC appelée IPSet, ou serveurs virtuels multi-IP. Cette fonctionnalité peut être utilisée 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 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. Pour obtenir des informations générales sur le déploiement HA pour ADC sur Google Cloud, consultez Déployer une paire haute disponibilité VPX sur Google Cloud Platform.

Citrix StoreFront sur Google Cloud

Citrix StoreFront est un composant de la pile de virtualisation Citrix qui fournit des services d’interface utilisateur et joue également un rôle dans votre stratégie d’authentification. StoreFront peut être considéré comme le prédécesseur géré par le client du service Citrix Workspace, et il est utilisé pour les systèmes de virtualisation Citrix frontal depuis plus d’une décennie. StoreFront est fourni sous la forme d’un fichier MSI/EXE téléchargeable et est installé sur une ou plusieurs instances Windows Server. Plusieurs instances StoreFront peuvent partager des données de configuration (et éventuellement d’abonnement) en créant des groupes de serveurs StoreFront. Plusieurs instances, front-end par un équilibreur de charge conscient du service comme l’appliance Citrix ADC/Gateway, sont utilisées pour créer un sous-système hautement disponible.

Le déploiement de Citrix StoreFront sur Google Cloud 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 Google Cloud.

La principale différence avec StoreFront sur GCP est que vous déployez généralement plusieurs instances StoreFront dans un groupe de serveurs StoreFront sur plusieurs zones Google Cloud. Il est important de noter que les fonctions activées avec cette conception dépendent de la latence entre les zones. 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). Bien que la latence interzone sur GCP soit généralement inférieure à 1 ms, assurez-vous de mesurer les latences entre les instances dans toutes les zones que vous prévoyez d’héberger StoreFront et activer/désactiver les abonnements en conséquence.

Nous l’avons déjà évoqué à quelques reprises dans ce document, mais cela vaut la peine de le rappeler à nouveau : pour les environnements soumis à des exigences de résilience étendues, Citrix recommande vivement d’implémenter StoreFront afin de tirer pleinement parti de la fonctionnalité de cache d’hôte local de Citrix DaaS. Cette architecture offre une résilience au cas où Cloud Connector ne parviendra pas à atteindre Citrix Cloud. Si cela se produit, les utilisateurs peuvent toujours se connecter à des 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 la section Cache d’hôte local (DaaS).

Comme mentionné ci-dessus, les implémentations de StoreFront sur Google Cloud doivent s’étendre à plusieurs zones Google Cloud pour une haute disponibilité, mais n’oubliez pas de prendre en compte la conception Citrix ADC/Gateway. Il est généralement recommandé d’utiliser Citrix ADC/Gateway devant les instances StoreFront pour fournir un équilibrage de charge, une surveillance avancée et une plus grande résilience de service.

Architecture de référence - Virtualisation Citrix sur Google Cloud