Citrix Virtual Apps and Desktops Service sur Azure

Introduction

Ce guide facilite l’architecture et le modèle de déploiement des services Citrix Virtual Apps and Desktops sur Microsoft Azure.

La combinaison de Citrix Cloud et de Microsoft Azure permet de lancer de nouvelles ressources virtuelles Citrix avec plus d’agilité et d’élasticité, en ajustant l’utilisation en fonction de l’évolution des besoins. Les machines virtuelles sur Azure prennent en charge tous les composants de contrôle et de charge de travail requis pour le déploiement d’un service Citrix Virtual Apps and Desktops. Citrix Cloud et Microsoft Azure ont des intégrations communes de plans de contrôle qui établissent l’identité, la gouvernance et la sécurité pour les opérations globales.

Ce document fournit également des conseils sur les conditions préalables, les considérations relatives à la conception de l’architecture et les conseils de déploiement pour les environnements clients. Le document met en lumière les décisions de conception et les considérations de déploiement selon les cinq principes architecturaux clés suivants :

  • Opérations - Opérations comprend une grande variété de sujets tels que la gestion des images, la surveillance des services, la continuité des activités, le support et d’autres. Divers outils sont disponibles pour faciliter l’automatisation des opérations, notamment Azure PowerShell, Azure CLI, ARM Templates et Azure API.

  • Identité - L’une des pierres angulaires de l’image entière d’Azure est l’identité d’une personne et son accès basé sur les rôles (RBAC). L’identité Azure est gérée via Azure Active Directory (Azure AD) et Azure AD Domain Services. Le client doit décider de la voie à suivre pour l’intégration de son identité.

  • Gouvernance - La clé de la gouvernance consiste à établir les politiques, les processus et les procédures associés à la planification, à l’architecture, à l’acquisition, au déploiement et à la gestion opérationnelle des ressources Azure.

  • Sécurité : Azure offre un large éventail d’options de sécurité configurables et la possibilité de les contrôler afin que les clients puissent personnaliser la sécurité pour répondre aux exigences uniques des déploiements de leur organisation. Cette section vous aide à comprendre comment les fonctionnalités de sécurité Azure peuvent vous aider à répondre à ces exigences.

  • Connectivité - La connexion des réseaux virtuels Azure au réseau local/cloud du client est appelée réseau hybride. Cette section explique les options de connectivité réseau et de routage des services réseau.

Planification

Les trois scénarios les plus courants de mise à disposition d’applications et de bureaux Citrix via Azure sont les suivants :

  • Déploiement Greenfield avec Citrix Cloud fournissant des emplacements de ressources dans Azure. Ce scénario est fourni via le service Citrix Virtual Apps and Desktops et utilisé lorsque les clients préfèrent accéder à un modèle d’abonnement et externaliser l’infrastructure de plan de contrôle à Citrix.
  • Extension d’un déploiement local dans Azure. Dans ce scénario, le client dispose d’une couche de contrôle locale actuelle et souhaite ajouter Azure en tant qu’emplacement de ressource Citrix pour les nouveaux déploiements ou migration.
  • Soulever et changer de vitesse. Avec ce scénario, les clients déploient leur infrastructure Citrix Management dans Azure et traitent Azure comme un site, à l’aide de Citrix ADC et StoreFront pour agréger les ressources de plusieurs sites.

Ce document se concentre sur le modèle de déploiement Citrix Cloud. Les clients peuvent planifier et adopter ces services en fonction des besoins de leur organisation :

Citrix Virtual Apps and Desktops Service

Les services Citrix Cloud Virtual Apps and Desktops simplifient la fourniture et la gestion des technologies Citrix, aidant les clients à étendre les déploiements de logiciels locaux existants ou à migrer 100 % vers le cloud. Offrez un accès sécurisé aux applications Windows, Linux et Web ainsi qu’aux postes de travail virtuels Windows et Linux. Gérez les applications et les postes de travail de manière centralisée sur plusieurs sites de ressources tout en conservant une excellente expérience utilisateur final.

Service Citrix Virtual Desktops Essentials

Les clients Citrix et Microsoft disposent de plus d’options pour déployer Windows 10 Entreprise au sein de leur organisation. Citrix Virtual Desktops Essentials Service accélère la migration vers Windows 10 Entreprise pour les clients qui préfèrent les solutions cloud Microsoft Azure. Cela permet aux clients disposant d’une licence Windows 10 Entreprise (Branche actuelle pour les entreprises) par utilisateur d’offrir une expérience de bureau virtuel Windows 10 Entreprise hautes performances à partir d’Azure.

Service Citrix Virtual Apps Essentials

Citrix Virtual Apps Essentials, le nouveau service de virtualisation des applications, combine la puissance et la flexibilité de la plate-forme Citrix Cloud avec la vision simple, prescriptive et facile à consommer de Microsoft Azure RemoteApp. Citrix Virtual Apps Essentials offre des performances et une flexibilité supérieures en déplaçant l’infrastructure back-end vers le cloud, ce qui simplifie la livraison des applications sans sacrifier la gestion ou l’expérience de l’utilisateur final.

Architecture de référence conceptuelle

Cette architecture conceptuelle fournit des directives communes pour le déploiement d’un emplacement de ressource Citrix Cloud dans Azure, qui seront traitées dans les sections suivantes.

Azure-RA-Image-1

Diagram-1 : Architecture de référence conceptuelle Citrix Cloud

Reportez-vous à la section guide de conception sur l’évolutivité et la rentabilité de la fourniture des services Citrix Virtual Apps and Desktops sur Microsoft Azure

Opérations

Dans le domaine des opérations, ce guide aborde plus en plus la planification des exigences en matière d’environnement de travail et de hiérarchie pour les services de base. Dans la couche supérieure, vous trouverez les considérations relatives à l’abonnement, au groupe de ressources et à la conception régionale. Suivi des questions courantes concernant le stockage de machines virtuelles, le stockage de profils utilisateur et la gestion/provisioning des images maîtresses. Vous trouverez également des conseils sur l’optimisation des instances réservées avec la mise à l’échelle automatique et la planification de la continuité d’activité et de la reprise après sinistre.

Conventions de nommage

Le nom des ressources dans Microsoft Azure est important car :

  • La plupart des ressources ne peuvent pas être renommées après leur création
  • Les types de ressources spécifiques ont des exigences de nommage différentes
  • Les conventions de nommage cohérentes facilitent la localisation des ressources et peuvent indiquer le rôle d’une ressource

La clé du succès avec les conventions de nommage est de les établir et de les suivre dans toutes vos applications et organisations.

Lorsque vous nommez des abonnements Azure, les noms verbeux permettent de comprendre clairement le contexte et le but de chaque abonnement. Le fait de suivre une convention de nommage peut améliorer la clarté lorsque vous travaillez dans un environnement avec de nombreux abonnements.

Un modèle recommandé pour nommer les abonnements est :

Variable Exemple Description
[Système] CTX (Citrix), CORE (Azure) Identificateur de trois lettres pour le produit, l’application ou le service pris en charge par la ressource.
[Rôle] XAW (Workers XenApp), VDA (Virtual Delivery Agent), CC (Cloud Connector), CVA (Citrix Virtual Apps) Identificateur de trois lettres pour un sous-système du service.
[Environnement] D, T, P (dev, test ou prod) Identifie l’environnement de la ressource
## 01, 02 Pour les ressources qui ont plusieurs instances nommées (serveurs Web, etc.).
[Emplacement] WU (États-Unis de l’Ouest), UE (États-Unis de l’Est), SCU (Centre-Sud des États-Unis) Identifie la région Azure dans laquelle la ressource est déployée

Lorsque vous nommez des ressources dans Azure, utilisez des préfixes ou des suffixes courants pour identifier le type et le contexte de la ressource. Bien que toutes les informations sur le type, les métadonnées et le contexte soient disponibles par programme, l’application d’apixes communs simplifie l’identification visuelle. Lorsque vous intégrez des affixes dans votre convention de dénomination, il est important de préciser clairement si l’apposition se trouve au début du nom (préfixe) ou à la fin (suffixe).

Un schéma d’affectation de noms bien défini identifie le système, le rôle, l’environnement, le nombre d’instances et l’emplacement d’une ressource Azure. L’attribution de noms peut être appliquée à l’aide d’une stratégie Azure.

Service Portée Modèle suggéré Exemple
Abonnements Global [System][Environment]##[Location]-sub WSCD01scu-sub
Groupes de ressources Global [System]-[Role]-[Environment]##-[Location]-rg CTX-Apps-P01-CUS-rg
Réseau virtuel Groupe de ressources [System][Environment]##[Location]-vnet CTXP01cus-vnet
Sous-réseau VNET parent [Descriptive Context] DMZ - 10.0.1.0/24 Infrastructure - 10.0.2.0/24
Compte de stockage Groupe de ressources [System][Role][Environment]##[Location] Note : Doit être alphanumérique minuscule ctxinfd01scu
Conteneur Compte de stockage [Descriptive Context] vhds
Machine virtuelle Groupe de ressources [System][Role][Environment]##[Location] Remarque : doit comporter 15 caractères ou moins. CTXSTFD01scu
Interface réseau Groupe de ressources [vmname]-nic# CTXSTFD01scu-nic1
IP publiques Groupe de ressources [vmname]-pip CTXSTFD01scu-pip
Passerelle réseau virtuel Réseau virtuel [System][Environment]##[Location]-vng WSCD01scu-vng
Passerelle réseau local Groupe de ressources [System][Environment]##[Location]-lng WSCD01scu-lng
Ensembles de disponibilité Groupe de ressources [System][Role]-as CTXSTF-as
Équilibreur de charge Groupe de ressources [System][Role]-lb CTXNSG-lb
Espaces de travail Abonnement [System][Environment]-analytics CTXP-analytics
Balises Ressource [Descriptive Context] Finance
Coffre à clés Abonnement [System][Environment]-vault CTXP-vault

Abonnements

La sélection d’un modèle d’abonnement est une décision complexe qui implique de comprendre la croissance de l’empreinte Azure du client à l’intérieur et à l’extérieur du déploiement Citrix. Même si le déploiement Citrix est petit, le client peut toujours disposer d’une grande quantité d’autres ressources qui sont en lecture/écriture fortement par rapport à l’API Azure, ce qui peut avoir un impact négatif sur l’environnement Citrix. L’inverse est également vrai, où de nombreuses ressources Citrix peuvent consommer un nombre excessif d’appels d’API disponibles, ce qui réduit la disponibilité des autres ressources au sein de l’abonnement.

Modèle d’espace de travail à abonnement unique

Dans un modèle d’abonnement unique, toutes les infrastructures principales et Citrix sont situées dans le même abonnement. Il s’agit de la configuration recommandée pour les déploiements nécessitant jusqu’à 1 200 VDA Citrix (peut être une session, un VDI groupé ou un VDI persistant). Les limites sont sujettes à changement, vérifiez ce qui suit pour la plupart limites VDA à jour. Reportez-vous à ce qui suit blog pour connaître les derniers numéros d’échelle de démarrage d’arrêt au sein d’un seul abonnement,

Diagram-2 : modèle d’espace de travail Azure Single Subscription Azure-RA-Image-2

Modèle d’espace de travail multi-abonnement

Dans ce modèle, l’infrastructure de base et l’infrastructure Citrix sont dans des abonnements distincts pour gérer l’évolutivité dans les déploiements de grande envergure. Souvent, les déploiements d’entreprise avec une conception d’infrastructure multi-régions sont divisés en plusieurs abonnements pour empêcher d’atteindre les limites d’abonnement Azure.

Azure-RA-Image-3

Diagram-3 : Modèle d’espace de travail Azure Multi-Abonnement

Les questions suivantes fournissent des conseils pour aider les clients à comprendre les options d’abonnement Azure et à planifier leurs ressources.

Composant Exigences
L’abonnement Azure contient-il uniquement des ressources Citrix ? Déterminez si l’abonnement Azure sera utilisé pour des ressources Citrix dédiées ou si les ressources Citrix seront partagées avec d’autres systèmes.
Déploiement d’un abonnement unique ou multiple ? En règle générale, les déploiements par abonnement multiples sont destinés à des déploiements plus importants pour lesquels des limitations d’abonnement uniques posent problème et des contrôles de sécurité plus granulaires sont nécessaires.
Quelles limites Azure sont susceptibles d’être atteintes ? Combien de ressources y a-t-il dans un groupe de ressources ? Les groupes de ressources ont des limites et Machine Creation Services (MCS) nécessite 2 ou 3 disques par ressource de machine virtuelle. PassezLimites d’abonnement Azureen revue lors de la planification de la solution.
Quelles autorisations sont nécessaires pour le principe de service CVAD sur l’abonnement Azure ? Citrix Virtual Apps and Desktops nécessite de créer des groupes de ressources et des ressources au sein de l’abonnement. Par exemple, lorsque le principe de service ne peut pas bénéficier d’un accès complet à un abonnement, il doit lui accorder l’accès à un groupe de ressources précréé.
Les environnements de développement et de test seront-ils créés dans des abonnements distincts de la production ? L’isolation des abonnements au développement et au test de la production permet l’application et la modification des services Azure globaux dans un environnement isolé et l’utilisation des ressources en silos. Cette pratique présente des avantages en termes de sécurité, de conformité et de performances d’abonnement. La création d’abonnements distincts pour ces environnements ajoute de la complexité à la gestion des images. Ces compromis doivent être envisagés en fonction des besoins du client.

Régions Azure

Une région Azure est un ensemble de centres de données déployés dans un périmètre défini par la latence et connectés via un réseau régional dédié à faible latence. Azure offre aux clients la flexibilité nécessaire pour déployer des applications là où ils en ont besoin. Azure est généralement disponible dans 42 régions à travers le monde, avec des plans annoncés pour 12 autres régions à partir de novembre 2018.

Une géographie est un marché discret, qui contient généralement deux régions Azure ou plus, qui préservent les limites de résidence des données et de conformité. Les géographies permettent aux clients ayant des besoins spécifiques en matière de résidence de données et de conformité de garder leurs données et leurs applications proches.

Les zones de disponibilité sont des emplacements physiquement distincts dans une région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’alimentation, de refroidissement et de mise en réseau indépendants. Les zones de disponibilité permettent aux clients d’exécuter des applications stratégiques avec une haute disponibilité et une réplication à faible latence. Pour garantir la résilience, il y a au moins trois zones distinctes dans toutes les régions activées.

Tenez compte de ces facteurs lorsque vous choisissez votre région.

Composant Exigences
Conformité et résidence des données Les clients ont-ils des exigences spécifiques en matière de conformité ou de résidence de données ? Microsoft peut copier les données client entre les régions d’une zone géographique donnée à des fins de redondance des données ou d’autres fins opérationnelles. Par exemple, Azure Globally Redundant Storage (GRS) réplique les données Blob et Table entre deux régions au sein d’une même zone géographique pour une durabilité accrue des données en cas de sinistre majeur du datacenter. Certains services Azure ne permettent pas au client de spécifier la région où le service sera déployé. Ces services peuvent stocker des données clients dans n’importe quel centre de données Microsoft, sauf indication contraire. Consultez leCarte des régions Azuresite Web pour les dernières mises à jour.
Disponibilité du service Examiner la disponibilité des services dans les régions provisoires. La disponibilité des services par région aide le client à déterminer quels services sont disponibles dans une région. Bien qu’un service Azure puisse être pris en charge dans une région donnée, toutes les fonctionnalités du Service ne sont pas disponibles dans les clouds souverains, tels que Azure Government, l’Allemagne et la Chine.
Déterminez les régions Azure cibles pour le déploiement Citrix. Vérifiez la proximité de la région Azure avec les utilisateurs et les centres de données clients.
Plusieurs régions Azure sont-elles requises ? Plusieurs régions Azure sont généralement prises en compte pour les raisons de haut niveau suivantes : - Proximité des données d’application ou des utilisateurs finaux - Redondance géographique pour la continuité d’activité et la reprise après sinistre - Disponibilité des fonctionnalités ou des services Azure

Ensembles de disponibilité

Un jeu de disponibilité est une fonctionnalité de regroupement logique qui peut être utilisée dans Azure pour garantir que les ressources VM placées dans un jeu de disponibilité sont isolées les unes des autres lorsqu’elles sont déployées dans un centre de données Azure. Azure garantit que les machines virtuelles placées dans un jeu de disponibilité s’exécutent sur plusieurs serveurs physiques, racks de calcul, unités de stockage et commutateurs réseau. En cas de panne matérielle ou logicielle Azure, seul un sous-ensemble de vos machines virtuelles est affecté et l’application globale reste disponible pour les clients. Les ensembles de disponibilité sont une fonctionnalité essentielle lorsque les clients souhaitent créer des solutions cloud fiables.

Chaque composant d’un déploiement Citrix doit figurer dans son propre jeu de disponibilité pour optimiser la disponibilité globale de Citrix. Par exemple, un jeu de disponibilité distinct doit être utilisé pour Cloud Connectors, un autre pour Citrix Application Delivery Controller (ADC), StoreFront, etc.

Une fois les jeux de disponibilité optimisés, l’étape suivante consiste à développer la résilience autour des temps d’arrêt de la machine virtuelle au sein des jeux de disponibilité. Cela minimise/élimine les temps d’arrêt de service lorsque les machines virtuelles sont redémarrées ou redéployées par Microsoft. Cela peut également être étendu aux événements de maintenance planifiés. Il y a deux fonctionnalités que vous pouvez utiliser qui peuvent augmenter la fiabilité de l’ensemble du service.

Ces deux fonctionnalités ne protègent pas contre la maintenance ou les plantages imprévus.

  • Maintenance planifiée Azure
  • Événements planifiés Azure

Maintenance planifiée Azure

Azure effectue périodiquement des mises à jour pour améliorer la fiabilité, les performances et la sécurité de l’infrastructure hôte dans Azure. Si la maintenance nécessite un redémarrage, Microsoft envoie un avis. À l’aide de la maintenance planifiée Azure, il est possible de capturer ces avis et d’agir de manière proactive selon le calendrier du client, plutôt que selon le calendrier de Microsoft.

Utilisez la fonction de maintenance planifiée en envoyant des notifications par e-mail au propriétaire du service de chaque niveau (pour une intervention manuelle) et créez des runbooks pour automatiser la protection du service.

Événements planifiés Azure

Azure Scheduled Events est un service de métadonnées Azure qui donne des avis par programme aux applications pour alerter la maintenance immédiate. Il fournit des informations sur les événements de maintenance à venir (par exemple, le redémarrage) afin que l’administrateur de l’application puisse se préparer et limiter les perturbations. Bien que cela puisse sembler comme un entretien planifié, ce n’est pas le cas. La principale différence est que ces événements sont déclenchés pour une maintenance planifiée et parfois non planifiée. Par exemple, si Azure effectue des activités de guérison d’hôte et doit déplacer des machines virtuelles dans un court délai.

Ces événements sont consommés par programme et donnent le préavis suivant :

  • Congeler — 15 minutes
  • Redémarrage — 15 minutes
  • Redéploiement : 10 minutes

Reprise après sinistre (DR)

Azure peut fournir une solution de reprise après sinistre hautement rentable pour les clients Citrix qui souhaitent tirer une valeur immédiate de l’adoption du cloud aujourd’hui. La topologie du modèle de déploiement détermine l’implémentation de la solution de reprise après sinistre.

Extension de l’architecture

Dans cette topologie, l’infrastructure de gestion reste locale, mais les charges de travail sont déployées sur Azure. Si le centre de données local n’est pas accessible, les utilisateurs connectés existants restent connectés, mais de nouvelles connexions ne seront pas possibles car l’infrastructure de gestion n’est pas disponible.

Pour protéger l’infrastructure de gestion, préconfigurez Azure Site Recovery pour restaurer l’infrastructure de gestion dans Azure. Il s’agit d’un processus manuel et une fois récupéré, votre environnement peut être rendu opérationnel. Cette option n’est pas transparente et ne peut pas récupérer des composants tels que ADC VPX, mais pour les organisations ayant un objectif de temps de récupération (RTO) plus flexible, elle peut réduire les coûts opérationnels.

Architecture d’hébergement

Lors du déploiement de cette topologie, l’infrastructure de gestion Citrix est déployée dans Azure et traitée comme un site distinct. Cela permet d’isoler fonctionnel du déploiement local en cas de défaillance d’un site. Utilisez Citrix ADC et StoreFront pour agréger les ressources et fournir aux utilisateurs un basculement quasi instantané entre les ressources de production et de reprise après sinistre.

La présence de Citrix Infrastructure dans Azure signifie qu’aucun processus manuel n’a besoin d’être appelé et aucun système n’a besoin d’être restauré avant que les utilisateurs puissent accéder à leur espace de travail principal.

Architecture des services cloud

Lorsque vous utilisez Citrix Cloud, Azure devient un autre emplacement de ressource. Cette topologie fournit le déploiement le plus simple car les composants de gestion sont hébergés par Citrix en tant que service et les charges de travail de reprise après sinistre peuvent être réalisées sans déployer une infrastructure dupliquée pour la prendre en charge. L’expérience utilisateur lors du basculement en cas de sinistre peut être transparente.

Les articles du tableau suivant aident le client à planifier sa reprise après sinistre :

Composant Exigences
Quelles sont les exigences RTO et RPO de l’environnement Citrix ? RTO - Durée ciblée et niveau de service dans lequel un processus opérationnel doit être restauré après un sinistre. RPO - L’intervalle de temps qui peut s’écouler au cours d’une interruption avant que la quantité de données perdues au cours de cette période dépasse le seuil maximal admissible ou la « tolérance » du plan de continuité des activités.
Quel est le résultat souhaité lorsqu’une interruption de service survient dans toute la région où votre application de machine virtuelle Azure est déployée ? Ces options devraient être examinées en conformité avec le RTO et le RPO du client pour le DR. La reprise après sinistre d’un environnement Citrix dans Azure peut être traitée avec la récupération de site Azure, le site secondaire passif et le site Azure Site actif. La récupération prend uniquement en charge le système d’exploitation de serveur (infrastructure Citrix et VDA de serveur). Le système d’exploitation client n’est pas pris en charge (par exemple, les bureaux persistants créés à l’aide de modèles ARM). En outre, les catalogues de machines créés par MCS (VDA serveur ou client) doivent être recréés à l’aide d’une tâche de récupération.

Groupes de ressources

Groupes de ressources (RG) dans Azure est un ensemble d’actifs dans des groupes logiques pour un provisioning, une surveillance et un contrôle d’accès faciles, voire automatiques, et pour une gestion plus efficace de leurs coûts. L’avantage de l’utilisation de RG dans Azure est de regrouper les ressources associées qui appartiennent à une application ensemble, car elles partagent un cycle de vie unifié, de la création à l’utilisation et, enfin, de la désaffectation.

La clé d’une conception réussie des groupes de ressources est de comprendre le cycle de vie des ressources qui y sont incluses.

Les groupes de ressources sont liés aux catalogues de machines au moment de la création et ne peuvent pas être ajoutés ou modifiés ultérieurement. Pour ajouter des groupes de ressources supplémentaires à un catalogue de machines, le catalogue de machines doit être supprimé et recréé.

Gestion des images

La gestion des images est le processus de création, de mise à niveau et d’attribution d’une image qui est appliqué de manière cohérente dans les environnements de développement, de test et de production. Les éléments suivants doivent être pris en compte lors de l’élaboration d’un processus de gestion d’image :

Provisioning à la demande

Le client doit déterminer si MCS doit être utilisé pour gérer les machines non persistantes Azure ou créer leurs propres modèles ARM (Azure Resource Manager). Lorsqu’un client utilise MCS pour créer des catalogues de machines, la fonctionnalité de Provisioning à la demande Azure réduit les coûts de stockage, accélère la création de catalogues et accélère les opérations d’alimentation des machines virtuelles (VM). Avec le provisioning à la demande d’Azure, les VM sont créées uniquement lorsque Citrix Virtual Apps and Desktops initie une action d’alimentation, une fois que le provisioning est terminé. Une machine virtuelle est visible dans le portail Azure uniquement lorsqu’elle est en cours d’exécution, tandis que dans Citrix Studio, toutes les machines virtuelles sont visibles, quel que soit l’état de l’alimentation. Les machines créées via des modèles ARM ou MCS peuvent être gérées par Citrix à l’aide d’une connexion hôte Azure dans Citrix Studio.

Conteneurs de compte de stockage

Le client doit décider de la structure organisationnelle des images source (ou dorées) de stockage à partir desquelles créer les machines virtuelles à l’aide de Citrix Machine Creation Services (MCS). Les images Citrix MCS peuvent être obtenues à partir de snapshots, de disques gérés ou non gérés et peuvent résider sur un stockage standard ou premium. Les disques non gérés sont accessibles via des comptes de stockage à usage général et sont stockés en tant que disques durs virtuels dans des conteneurs de stockage Blob Azure. Les conteneurs sont des dossiers qui peuvent être utilisés pour séparer les images Production, Test et Développement.

Réplication d’images

Le client doit déterminer le processus approprié pour répliquer les images entre les régions et comment la technologie Citrix App Layering peut être utilisée dans le cadre de la stratégie globale de gestion des images. Les scripts PowerShell cam sont utilisés avec Azure Automation pour planifier la réplication d’image. Vous trouverez plus d’informations sur Citrix App Layeringici, mais gardez à l’esprit qu’Elastic Layering nécessite un partage de fichiers SMB qui ne réside pas dans Azure Files. Consultez la section Serveurs de fichiers pour connaître les technologies de partage SMB prises en charge qui prennent en charge Elastic Layering.

Technologies de serveur de fichiers

Azure propose plusieurs technologies de serveur de fichiers qui peuvent être utilisées pour stocker des données utilisateur Citrix, des informations de profil itinérant ou pour fonctionner comme cibles pour les partages Citrix Layering. Ces options sont les suivantes :

  • Serveur de fichiers autonome
  • Serveurs de fichiers utilisant le réplica de stockage
  • Serveur de fichiers évolutif (SOFS) avec espaces de stockage Direct (S2D)
  • Système de fichiers distribués — Réplication (DFS-R)
  • Appliances de stockage tierces à partir de la Place de marché Azure (telles que NetApp et autres)

Le client doit sélectionner les technologies de serveur de fichiers qui répondent le mieux à ses besoins professionnels. Le tableau ci-dessous présente certains avantages et considérations pour chacune des différentes technologies de service de fichiers.

Options Avantages Considérations
Serveur de fichiers autonome Bien connu et testé. Compatible avec les produits de sauvegarde/restauration existants Point de défaillance unique. Aucune redondance de données. Pannes pour les correctifs mensuels, mesurée en minutes.
Serveurs de fichiers utilisant le réplica de stockage Réplication au niveau des blocs. SMB 3.0. Storage Agnostic (SAN, Cloud, Local, etc.). Offre une réplication synchrone et asynchrone. Recommandé lorsque l’accès multi-régions est requis Basculement manuel nécessaire. Utilise 2 fois l’espace disque. Le basculement manuel a toujours des temps d’arrêt, mesurés en minutes. Dépendance DNS.
SOFS sur les espaces de stockage Direct Hautement disponible. HA multi-nœuds et multi-disques. Mise à l’échelle ou mise à l’échelle. SMB 3.0 et 3.1. Basculement transparent pendant les activités de maintenance planifiées et non planifiées. Recommandé pour le stockage de profil utilisateur dans Azure Utilise 2 à 3x de l’espace disque. Le support des logiciels de sauvegarde tiers peut être limité par le fournisseur. Ne prend pas en charge le déploiement multi-régions
Système de fichiers distribués — Réplication Technologie éprouvée pour la réplication basée sur des fichiers. Prend en charge PowerShell Basé sur le domaine. Impossible de déployer dans une configuration active-active.
Applications de stockage tierces Technologies de déduplication. Meilleure utilisation de l’espace de stockage. Coût supplémentaire. Outils de gestion propriétaires.

Les types de machines virtuelles de serveur de fichiers recommandés sont généralement DS1, DS2, DS3, DS4 ou DS5, avec la sélection appropriée en fonction des besoins d’utilisation du client. Pour des performances optimales, assurez-vous que la prise en charge des disques haut de gamme est sélectionnée. Des instructions supplémentaires peuvent être trouvées sur Microsoft Azure documentation.

Gestion des coûts d’infrastructure

Deux technologies sont disponibles qui peuvent être utilisées pour réduire les coûts de l’environnement Citrix dans Azure, les instances réservées et Citrix Autoscale.

Instances réservées

Les instances de VM réservées Azure réduisent considérablement les coûts — jusqu’à 72 % par rapport aux prix à l’utilisation — avec des durées d’un an ou de trois ans sur des machines virtuelles (VM) Windows et Linux. Lorsque les clients combinent les économies réalisées grâce aux RIs Azure et la valeur ajoutée du bénéfice hybride Azure, ils peuvent économiser jusqu’à 80 %. Le 80 % est calculé sur la base d’un engagement d’instance réservée Azure de trois ans d’un serveur Windows par rapport au tarif normal de paiement à l’utilisation.

Bien que les instances réservées Azure requièrent des engagements initiaux sur la capacité de calcul , elles offrent également la flexibilité d’échanger ou d’annuler des instances réservées à tout moment. Une réservation couvre uniquement les coûts de calcul de la machine virtuelle. Il ne réduit pas les frais supplémentaires de logiciel, de mise en réseau ou de stockage. Ceci est bon pour l’infrastructure Citrix et la capacité minimale nécessaire pour un cas d’utilisation (heures ouvrables et non).

La fonctionnalité Citrix Autoscale prend également en charge les instances réservées afin de réduire davantage vos coûts. Vous pouvez désormais utiliser la mise à Autoscale pour l’éclatement dans le cloud. Dans un groupe de mise à disposition, vous pouvez marquer les machines qui doivent être mises à l’échelle automatique et exclure vos instances réservées (ou charges de travail locales). Vous trouverez plus d’informations ici : Limiter la mise à l’échelle automatique à certaines machines d’un groupe de mise à disposition.

Citrix Autoscale

La mise à l’Autoscale est une fonctionnalité exclusive du service Citrix Virtual Apps and Desktops qui fournit une solution cohérente et hautes performances pour gérer de manière proactive vos machines. Elle vise à équilibrer les coûts et l’expérience des utilisateurs. Autoscale intègre la technologie Smart Scale obsolète dans la solution de gestion de l’alimentation Studio.

Type de machine Basé sur un calendrier Basé sur la charge Chargement et planification
Machinesavec OS de serveur hébergeant des applications publiées ou des postes de travail partagés hébergés (VDI de serveur) Pris en charge Pris en charge Pris en charge
Machinesavec OS de bureau hébergeant des postes de travail VDI permanents (dédiés) statiques Pris en charge. Pendant les périodes où les machines sont hors tension (par exemple, après les heures ouvrées), les utilisateurs peuvent déclencher la mise sous tension des machines via Citrix Receiver. Vous pouvez définir le délai de mise hors tension d’Autoscale de sorte que la mise à l’échelle automatique ne mette pas automatiquement hors tension les machines avant que l’utilisateur puisse établir une session. Pris en charge uniquement pour les machines non affectées. Pris en charge uniquement pour les machines non affectées.
OS de bureau - machines hébergeant - postes de travail VDI non persistants aléatoires (postes de travail VDI groupés) Pris en charge Pris en charge. Utilisez la mesure de mise à l’échelle du nombre de sessions et définissez le nombre maximal de sessions sur 1. Pris en charge. Utilisez la mesure de mise à l’échelle du nombre de sessions et définissez le nombre minimal de machines sur 1.

Azure-RA-Image-4

Diagramme 4 : Flux de mise à l’échelle automatique Citrix

Vous pouvez en savoir plus sur Citrix Autoscaleici.

Optimisation de l’expérience utilisateur final

L’optimisation de l’expérience utilisateur final consiste à équilibrer la perception de la réactivité de l’utilisateur final avec les besoins de l’entreprise de rester dans les limites d’un budget. Cette section traite des concepts de conception et des décisions concernant la fourniture d’un environnement qui est correctement dimensionné pour l’entreprise et l’utilisateur final.

Définition de l’espace de travail utilisateur

Lors de la planification d’une évaluation de l’utilisateur, laGuide et meilleures pratiques de Citrix VDIdocumentation fournit des conseils inestimables. Passez en revue les questions de haut niveau suivantes pour mieux comprendre les cas d’utilisation existants et les ressources nécessaires pour leurs utilisateurs finaux.

Rubrique Question
Nombre d’utilisateurs Combien d’utilisateurs sont attendus dans l’environnement ? La phase d’évaluation a-t-elle permis de déterminer le modèle de VDI approprié ? (Applications virtuelles ou bureaux virtuels)
Cas d’utilisation Quels types d’applications seront consommés par les utilisateurs finaux ? Quelles sont les exigences VDA pour les applications ? Comment les applications seraient-elles le mieux fournies ? (Applications virtuelles vs postes de travail virtuels)
Heures de travail du groupe d’utilisateurs Quand les utilisateurs accèderont-ils à l’environnement ? Quelles sont les heures de pointe ? Quelle est la consommation prévue tout au long de la journée ? (La consommation d’utilisateurs pendant des heures spécifiques permet d’identifier les besoins en espace de travail pour l’automatisation de l’échelle et l’achat d’instances réservées Azure.)
Emplacement Où se trouvent les utilisateurs finaux ? Les espaces de travail devraient-ils être déployés dans plusieurs régions ou seulement dans une seule région ?
Données utilisateur et application Où sont stockées les données de l’utilisateur et de l’application ? Les données seraient-elles uniquement dans Azure, uniquement sur site, ou un mélange des deux ? Quelle est la latence maximale tolérable pour accéder aux données utilisateur ?

Types d’instance de VM Azure

Chaque composant Citrix utilise un type de machine virtuelle associé dans Azure. Chaque série de machines virtuelles disponible est mappée à une catégorie spécifique de charges de travail (usage général, optimisé pour le calcul, etc.) avec différentes tailles contrôlant les ressources allouées à la machine virtuelle (CPU, mémoire, IOPS, réseau, etc.).

La plupart des déploiements Citrix utilisent les types d’instance série D et F-Series. Les séries D sont couramment utilisées pour les composants d’infrastructure Citrix et parfois pour les charges de travail utilisateur lorsqu’elles nécessitent une mémoire supplémentaire au-delà de ce qui se trouve dans les types d’instance de la série F. Les types d’instance de la série F sont les plus courants sur le terrain pour les charges de travail des utilisateurs en raison de leurs processeurs plus rapides qui apportent avec eux la perception de la réactivité.

Pourquoi la série D ou la série F ? Du point de vue Citrix, la plupart des composants d’infrastructure (Cloud Connector, StoreFront, ADC, etc.) utilisent le processeur pour exécuter les processus principaux. Ces types de machines virtuelles ont un rapport CPU à mémoire équilibré, sont hébergés sur du matériel uniforme (contrairement à la série A) pour des performances plus cohérentes et prennent en charge le stockage premium. Certes, les clients peuvent et doivent ajuster leurs types d’instances pour répondre à leurs besoins et à leur budget.

La taille et le nombre de composants au sein de l’infrastructure d’un client dépendent toujours des besoins, de l’évolutivité et des charges de travail du client. Cependant, avec Azure, nous pouvons évoluer de manière dynamique et à la demande ! Pour les clients soucieux des coûts, il est préférable de commencer plus petit et de procéder à une mise à l’échelle. Les machines virtuelles Azure nécessitent un redémarrage lors du changement de taille. Planifiez ces événements dans les fenêtres de maintenance planifiée uniquement et dans le cadre des stratégies de contrôle des modifications établies.

Que diriez-vous de Scale-up ou Scale-out ?

Les questions de haut niveau suivantes doivent être examinées afin de mieux comprendre le cas d’utilisation d’un client et les ressources nécessaires pour ses utilisateurs finaux. Cela les aide également à planifier leur charge de travail bien à l’avance.

La mise à l’échelle est préférable lorsque le coût par utilisateur et par heure doit être le plus bas et qu’un impact plus important peut être toléré en cas de défaillance de l’instance. La mise à l’échelle est préférable lorsque l’impact d’une défaillance d’instance unique doit être minimisé. Le tableau ci-dessous fournit des exemples de types d’instance pour différents composants Citrix.

Composant Type d’instance recommandé
Contrôleurs de livraison, connecteurs cloud DS2_v2 ou DS2_v3 standard avec stockage SSD Premium
Mise à l’échelle des charges de travail utilisateur OS de serveur Les machines virtuelles standard_F16s_v2 avec application virtuelle ont été identifiées comme ayant le coût $/ utilisateur/heure le plus faible par rapport aux autres instances. Les machines virtuelles standard_DS5_v2 étaient également compétitives par rapport à d’autres instances
Mise à l’échelle des charges de travail utilisateur du système d’exploitation du serveur Les instances Standard_F4_v2 et Standard_F8_v2 prennent en charge un nombre d’utilisateurs plus faible, mais offrent plus de flexibilité aux opérations de gestion de l’alimentation en raison de la taille des conteneurs utilisateur plus petite. Cela permet aux machines d’être plus efficacement délocalisées pour économiser des coûts sur les instances de paiement à l’utilisation. En outre, les domaines de défaillance sont plus petits lors de la mise à l’échelle.
Charges de travail utilisateur OS de bureau Standard_F2_v2 a le coût double cœur le plus bas et fonctionne bien avec Windows 10.

La dernière étude de type d’instance a été faite pour fournir une grande compréhension dans ce domaine et nous recommandons fortement lelire. Dans tous les cas, les clients doivent évaluer les types d’instance avec leurs charges de travail.

Pour les charges de travail à forte intensité graphique, tenez compte des machines NVv4-series virtuelles. Ils sont alimentés par des processeurs AMD EPYC 7002 et un GPU Radeon MI25 virtualisé. Ces machines virtuelles sont optimisées et conçues pour la visualisation VDI et à distance. Avec les GPU partitionnés, Nvv4 offre la taille idéale pour les charges de travail nécessitant des ressources GPU plus petites au prix le plus optimal. Alternative, la série NVv3 est optimisée et conçue pour la visualisation à distance, la diffusion en continu, les jeux, l’encodage et les scénarios VDI à l’aide de frameworks tels que OpenGL et DirectX. Ces machines virtuelles sont soutenues par le GPU NVIDIA Tesla M60. Pour plus d’options GPU, vérifiez l’autre offres à partir d’Azure.

Bien que la mise à l’échelle soit généralement un modèle préféré pour réduire le coût, Autoscale peut bénéficier d’instances plus petites (15 à 20 sessions par hôte). Les instances plus petites hébergent moins de sessions utilisateur que les instances plus grandes. Par conséquent, dans le cas d’instances plus petites, Autoscale place les machines dans l’état de drainage beaucoup plus rapidement car il faut moins de temps pour que la dernière session utilisateur soit déconnectée. Par conséquent, Autoscale met en service les instances plus petites plus rapidement, réduisant ainsi les coûts. Vous pouvez en savoir plus sur les considérations relatives à la taille d’instance pour la mise à l’échelle automatique dansdocumentation officielle.

Stockage

Comme tout autre ordinateur, une machine virtuelle dans Azure utilise des disques comme un emplacement pour stocker un système d’exploitation, des applications et des données. Toutes les machines virtuelles Azure disposent d’au moins deux disques : un disque du système d’exploitation Windows et un disque temporaire. Le disque du système d’exploitation est créé à partir d’une image, et le disque du système d’exploitation et l’image sont stockés dans Azure en tant que disques durs virtuels (VHDs). Les machines virtuelles peuvent également avoir des disques supplémentaires attachés en tant que disques de données, également stockés en tant que disques virtuels.

Les disques Azure sont conçus pour offrir une durabilité de qualité professionnelle. Il existe trois niveaux de performance pour le stockage qui peuvent être sélectionnés lors de la création de disques : disques SSD Premium, SSD Standard et Stockage HDD Standard, et les disques peuvent être gérés ou non gérés. Les disques gérés sont les disques par défaut et ne sont pas soumis aux limitations du compte de stockage, comme les disques non gérés.

Les disques gérés sont recommandés par Microsoft sur le disque non géré. Les disques non gérés ne doivent être pris en compte que par exception. Le stockage standard (HDD et SSD) inclut les coûts de transaction (E/S de stockage) qui doivent être pris en compte, mais dont les coûts par disque sont inférieurs. Le stockage Premium n’a pas de coûts de transaction, mais a des coûts par disque plus élevés et offre une expérience utilisateur améliorée.

Les disques ne proposent pas de SLA sauf si un jeu de disponibilité est utilisé. Les jeux de disponibilité ne sont pas pris en charge avec Citrix MCS, mais doivent être inclus avec Citrix Cloud Connector, ADC et StoreFront.

Identité

La section se concentre sur les contrôles d’identité, la planification des utilisateurs de l’espace de travail et l’expérience utilisateur final. La principale considération de conception est la gestion des identités au sein des locataires Azure et Citrix Cloud.

Microsoft Azure Active Directory (Azure AD) est une solution cloud de gestion des identités et des accès qui fournit des services d’annuaire, la gouvernance des identités et la gestion de l’accès aux applications. Un seul répertoire Azure AD est automatiquement associé à un abonnement Azure lors de sa création.

Chaque abonnement Azure a une relation d’approbation avec un annuaire Azure AD pour authentifier les utilisateurs, les services et les appareils. Plusieurs abonnements peuvent approuver le même répertoire Azure AD, mais un abonnement ne fera confiance qu’à un seul répertoire Azure AD.

Les solutions d’identité de Microsoft couvrent des fonctionnalités locales et basées sur le cloud, créant une identité utilisateur unique pour l’authentification et l’autorisation de toutes les ressources, quel que soit l’emplacement. Ce concept est connu sous le nom d’identité hybride. Il existe différentes options de conception et de configuration pour l’identité hybride utilisant les solutions Microsoft et, dans certains cas, il peut être difficile de déterminer quelle combinaison répondra le mieux aux besoins d’une organisation.

Considérations communes en matière de conception d’identité

Généralement, l’extension du site Active Directory aux clients Azure utilise l’utilisation de la réplication Active Directory pour fournir l’identité et l’authentification avec Citrix Workspace. Une étape courante consiste à utiliser AD Connect pour répliquer l’utilisateur vers Azure Active Directory, ce qui vous fournit l’activation basée sur l’abonnement requise pour Windows 10.

Il est recommandé d’étendre les services de domaine Active Directory locaux au sous-réseau virtuel Azure pour obtenir toutes les fonctionnalités et l’extensibilité.Le contrôle d’accès basé sur les rôles Azure (RBAC) permet de fournir une gestion fine des accès pour les ressources Azure. Trop d’autorisations peuvent exposer et rendre compte aux attaquants. Trop peu d’autorisations signifient que les employés ne peuvent pas faire leur travail efficacement. En utilisant RBAC, l’administrateur peut donner aux employés les autorisations exactes dont ils ont besoin.

Authentification

Les services de domaine (AD DS ou AD DS Azure) sont requis pour les fonctionnalités principales de Citrix. RBAC est un système d’autorisation basé sur Azure Resource Manager qui fournit une gestion fine des accès aux ressources dans Azure. RBAC vous permet de contrôler de manière granuleuse le niveau d’accès que les utilisateurs ont. Par exemple, vous pouvez limiter un utilisateur à gérer uniquement des réseaux virtuels et un autre utilisateur à gérer toutes les ressources d’un groupe de ressources. Azure inclut plusieurs rôles intégrés que vous pouvez utiliser.

L’authentification Azure AD est prise en charge pour l’authentification Workspace Experience Service et Citrix ADC/StoreFront. Pour SSON complet avec Azure AD, Citrix Federated Authentication Service (FAS) ou Azure AD DS (pour les services de domaine principaux) doit être utilisé.

Citrix FAS n’est pas encore pris en charge pour Workspace Experience Service, par conséquent StoreFront est requis dans le cadre de l’architecture de déploiement.Le serveur Azure MFA (Cloud Service, Azure MFA Server, Azure MFA NPS Extension) peut activer l’utilisation d’Azure MFA sans nécessiter une stratégie SAML et l’utilisation de Citrix FAS pour SSON complet. Cependant, il s’agit d’une machine virtuelle IaaS et doit être gérée par le client.

Résultats Active Directory et Azure Active Directory

  • Locataire provisionné Azure Active Directory
  • Liste des rôles organisationnels souhaités pour Azure RBAC avec mappage à des rôles Azure intégrés ou personnalisés
  • Liste des niveaux d’accès Admin souhaités (compte, abonnement, groupe de ressources, etc.)
  • Procédure d’octroi d’accès/rôle aux nouveaux utilisateurs pour Azure
  • Procédure pour attribuer une élévation JIT (juste à temps) aux utilisateurs pour des tâches spécifiques

Voici un exemple d’architecture de mise en page d’espace de noms et de flux d’authentification.

Azure-RA-Image-5

Diagram-5 : Architecture de la disposition de l’espace de noms et du flux d’authentification

Administration de Citrix Cloud + Azure AD

Par défaut, Citrix Cloud utilise le fournisseur Citrix Identity pour gérer les informations d’identité de tous les utilisateurs qui accèdent au Citrix Cloud. Les clients peuvent modifier cette option pour utiliser Azure Active Directory (AD) à la place. En utilisant Azure AD avec Citrix Cloud, les clients peuvent :

  • Utilisez leur propre Active Directory, afin qu’ils puissent contrôler l’audit, les stratégies de mot de passe et désactiver facilement les comptes si nécessaire.
  • Configurez l’authentification multifacteur pour un niveau de sécurité plus élevé contre la possibilité d’informations d’identification de connexion volées.
  • Utilisez une page de connexion de marque pour que vos utilisateurs sachent qu’ils se connectent au bon endroit.
  • Utilisez la fédération pour un fournisseur d’identité de votre choix, y compris ADFS, Okta et Ping, entre autres.

Citrix Cloud inclut une application Azure AD qui permet à Citrix Cloud de se connecter à Azure AD sans avoir à vous connecter à une session Active Azure AD. Citrix Cloud Administrator Login permet d’utiliser les identités Azure AD dans le client Citrix Cloud.

  • Déterminez si les administrateurs Citrix Cloud utilisent leur Citrix Identity ou Azure AD pour accéder à Citrix Cloud. L’URL suivra le format https://citrix.cloud.com/go/{Customer Determined}
  • Identification de l’URL d’authentification pour l’authentification Azure AD dans Citrix Cloud

Gouvernance

Azure Governance est un ensemble de concepts et de services conçus pour permettre la gestion de vos différentes ressources Azure à grande échelle. Ces services permettent d’organiser et de structurer vos abonnements de manière logique, de créer, de déployer et de réutiliser des packages natifs Azure de ressources. Ce sujet est axé sur l’établissement des stratégies, processus et procédures associés à la planification, à l’architecture, à l’acquisition, au déploiement, à l’exploitation et à la gestion des ressources Azure.

Connexion Administrateur Citrix Cloud

Déterminez si les administrateurs Citrix Cloud utilisent leur Citrix Identity, Active Directory Identity ou Azure AD pour accéder à Citrix Cloud. L’intégration Azure AD permet l’authentification multifacteur dans Citrix Cloud pour les administrateurs. Identifiez l’URL d’authentification pour l’authentification Azure AD dans Citrix Cloud. URL suit le formathttps://citrix.cloud.com/go/{Customer Determined}.

Autorisations et délégation RBAC

Les clients utilisant Azure AD peuvent implémenter leurs stratégies de gouvernance à l’aide du contrôle d’accès basé sur les rôles (RBAC) des ressources Azure. L’un des principaux outils pour l’application de ces autorisations est le concept d’un groupe de ressources. Pensez à un groupe de ressources comme un ensemble de ressources Azure qui partagent le cycle de vie et la propriété administrative.

Dans le contexte d’un environnement Citrix, ceux-ci devraient être organisés de manière à permettre une délégation appropriée entre les équipes et à promouvoir le concept de moindre privilège. Un bon exemple est lorsqu’un déploiement Citrix Cloud utilise un Citrix ADC VPX provisionné à partir de la Place de marché Azure pour un accès externe. Bien qu’un élément central de l’infrastructure Citrix, les ADC Citrix peuvent avoir un cycle de mise à jour séparé, un ensemble d’administrateurs, etc. Cela demanderait de séparer les ADC Citrix des autres composants Citrix en groupes de ressources distincts afin que les autorisations RBAC Azure puissent être appliquées via les zones d’administration du locataire, de l’abonnement et des ressources.

Responsable du service MCS

Pour accéder aux ressources sécurisées par un locataire Azure AD, l’entité qui nécessite un accès doit être représentée par une entité de sécurité. Ceci est vrai pour les utilisateurs (principal utilisateur) et les applications (principal de service). L’entité de sécurité définit la stratégie d’accès et les autorisations pour l’utilisateur/l’application dans le locataire Azure AD. Cela active des fonctionnalités principales telles que l’authentification de l’utilisateur/application lors de la connexion et l’autorisation lors de l’accès aux ressources.

Déterminez les autorisations allouées au Service Principal utilisé par le service Citrix MCS.

Les entités de service d’étendue d’abonnement disposent des droits de contributeur sur l’abonnement applicable utilisé par l’environnement Citrix. Les entités de service à portée étroite ont un RBAC granulaire appliqué aux groupes de ressources contenant le réseau, les images maîtres et les VDA. Les principaux de service à portée étroite sont recommandés pour limiter les autorisations uniquement aux autorisations requises par le service. Cela adhère au concept de sécurité de « moindre privilège ».

Balisage

Le client applique des balises à ses ressources Azure en donnant des métadonnées pour les organiser logiquement en taxonomie. Chaque balise se compose d’un nom et d’une paire de valeurs. Par exemple, ils peuvent appliquer le nom « Environnement » et la valeur « Production » à toutes les ressources de production.

Le client peut récupérer toutes les ressources de votre abonnement avec ce nom et cette valeur. Les balises leur permettent de récupérer les ressources associées de différents groupes de ressources. Cette approche est utile lorsque l’administrateur a besoin d’organiser des ressources pour la facturation ou la gestion.

Il y a une limite de 15 balises par ressource. Citrix MCS crée 2 balises par machine virtuelle, donc un client est limité à 13 balises pour les machines MCS. Les machines non persistantes MCS sont supprimées lors du redémarrage. Cela supprime les caractéristiques spécifiques aux machines virtuelles Azure telles que les balises, les diagnostics de démarrage Si des balises sont requises, il est recommandé de créer une stratégie Azure Ajout et de l’appliquer aux groupes de ressources MCS applicables.

Stratégie Azure

Les stratégies Azure peuvent contrôler des aspects tels que le balisage, les SKU autorisés, le chiffrement, la région Azure et la convention de nommage. Il existe des stratégies par défaut et la possibilité d’appliquer des stratégies personnalisées. Les stratégies Azure peuvent être appliquées au niveau de l’abonnement ou du groupe de ressources. Plusieurs stratégies peuvent être définies. Les stratégies appliquées au niveau du groupe de ressources ont priorité sur la stratégie de niveau abonnement.

Identifiez les aspects d’Azure qui doivent être contrôlés et normalisés dans l’environnement Citrix. Le quota dur force la politique et ne permet pas d’exceptions. Vérifications des quotas souples pour l’application de la politique et aviser si la stratégie n’est pas respectée. Reportez-vous à la documentation Azure pour plus d’informations sur la définition des stratégies.

Azure-RA-Image-6

Diagram-6 : Politique d’accès à la gouvernance Azure et RBAC

Sécurité

La sécurité est intégrée à tous les aspects d’Azure. Azure offre des avantages uniques en matière de sécurité grâce à des informations de sécurité globales, à des contrôles sophistiqués orientés vers le client et à une infrastructure sécurisée renforcée. Cette puissante combinaison aide à protéger les applications et les données, à soutenir les efforts de conformité et à assurer une sécurité économique pour les entreprises de toutes tailles.

Sécurisation du provisionnement des comptes de stockage par le service CVAD

Comme indiqué précédemment, MCS est le service (au sein de CVAD) responsable de la filature des machines dans l’abonnement client. MCS utilise une identité AAD : principal de service d’application pour accéder aux groupes de ressources Azure pour effectuer différentes actions. Pour le type de ressources de compte de stockage, MCS nécessite l’ listkeys autorisation d’acquérir la clé lorsque nécessaire pour différentes actions (écriture/lecture/suppression). Selon notre mise en œuvre actuelle, une exigence MCS pour :

  • Le réseau de compte de stockage est l’accès à partir de l’Internet public.
  • Compte de stockage RBAC est une listkeys autorisation

Pour certaines organisations, le maintien public du point de terminaison du compte de stockage est un problème. Voici une analyse des ressources créées et stockées lors du déploiement de machines virtuelles avec disque géré (comportement par défaut).

  • Stockage de table : Nous conservons les données de configuration et d’état de la machine dans le stockage de table dans le compte de stockage principal (ou un compte secondaire, si le principal est utilisé pour les disques Premium) pour le catalogue. Il n’y a pas d’information sensible dans les tableaux.
  • Verrous : pour certaines opérations (allocation de machines à des comptes de stockage, réplication de disques), nous utilisons un objet de verrouillage pour synchroniser les opérations de plusieurs instances de plug-in. Ces fichiers sont des objets blob vides et ne contiennent aucune donnée sensible.

Pour les catalogues de machines créés avant le 15 octobre 2020, MCS crée un compte de stockage supplémentaire pour les disques d’identité :

  • Importation de disque : lors de l’importation de disques (identité, instruction), nous téléchargeons le disque en tant que blob de page. Nous créons ensuite un disque géré à partir du blob de page et supprimons le blob de page. Les données transitoires incluent des données sensibles pour les noms d’objets informatiques et le mot de passe. Ceci ne s’applique pas à tous les catalogues de machines créés après le 15 octobre 2020.

Il est recommandé d’utiliser un principal de service d’étendue étroit appliqué aux groupes de ressources spécifiques pour limiter les autorisations uniquement aux autorisations requises par le service. Cela adhère au concept de sécurité de « moindre privilège ». Reportez-vous à CTX219243 et CTX224110 pour plus de détails.

IaaS - Surveillance du Centre de sécurité Azure

Azure Security Center analyse l’état de sécurité des ressources Azure. Lorsque le Centre de sécurité identifie des vulnérabilités de sécurité potentielles, il crée des recommandations qui guident le client tout au long du processus de configuration des contrôles nécessaires. Les recommandations s’appliquent aux types de ressources Azure : machines virtuelles (VM) et ordinateurs, applications, mise en réseau, SQL et Identity and Access. Il y a peu de pratiques exemplaires que vous devez suivre :

  • Contrôlez l’accès VM et Sécurisez l’accès privilégié.
  • Provisioning des logiciels malveillants pour identifier et supprimer les logiciels malveillants.
  • Intégrez votre solution anti-programme malveillant au Centre de sécurité pour surveiller l’état de votre protection.
  • Gardez vos machines virtuelles à jour et assurez-vous au moment du déploiement que les images que vous avez créées incluent la dernière série de mises à jour de Windows et de sécurité.
  • Redéployez périodiquement vos machines virtuelles pour forcer une nouvelle version du système d’exploitation.
  • Configuration des groupes de sécurité réseau et des règles pour contrôler le trafic vers les machines virtuelles.
  • Provisioning de pare-feu d’applications Web pour vous aider à vous défendre contre les attaques qui ciblent vos applications Web.
  • Adresser les configurations de système d’exploitation qui ne correspondent pas aux lignes de base recommandées.

Conception de réseau

La sécurité réseau peut être définie comme le processus de protection des ressources contre les accès non autorisés ou les attaques en appliquant des contrôles au trafic réseau. L’objectif est de s’assurer que seul le trafic légitime est autorisé. Azure comprend une infrastructure réseau robuste pour prendre en charge vos exigences de connectivité applicative et service. La connectivité réseau est possible entre les ressources situées dans Azure, entre les ressources locales et hébergées Azure, ainsi que vers et depuis Internet et Azure.

Segmentation du réseau virtuel (VNet)

Les réseaux virtuels Azure sont similaires à un réseau local sur votre réseau local. L’idée derrière un réseau virtuel Azure est que vous créez un seul réseau basé sur l’espace d’adressage IP privé sur lequel les clients peuvent placer toutes leurs machines virtuelles Azure. La meilleure pratique consiste à segmenter l’espace d’adressage plus grand en sous-réseaux et à créer des contrôles d’accès réseau entre les sous-réseaux. Le routage entre les sous-réseaux se produit automatiquement et vous n’avez pas besoin de configurer manuellement les tables de routage.

Utilisez un groupe de sécurité réseau (NSG). Les NSG sont des dispositifs d’inspection de paquets simples et avec état qui utilisent l’approche 5 tuple (IP source, port source, IP de destination, port de destination et protocole de couche 4) pour créer des règles autorisation/refus pour le trafic réseau. Les règles autorisent ou refusent le trafic vers et depuis une seule adresse IP, vers et depuis plusieurs adresses IP, ou vers et depuis des sous-réseaux entiers.

Les clients peuvent créer des routes personnalisées ou définies par l’utilisateur appelées Routes définies par l’utilisateur (UDR) dans Azure pour remplacer les routes système par défaut d’Azure ou ajouter des itinéraires supplémentaires à la table de routage d’un sous-réseau. Dans Azure, les administrateurs peuvent créer une table de routage, puis associer la table de routage à zéro ou plusieurs sous-réseaux réseau virtuel. Chaque sous-réseau peut être associé à zéro ou à une table de routage.

Les NSG et les UDRs sont appliqués au niveau du sous-réseau au sein d’un réseau virtuel. Lors de la conception d’un réseau virtuel Citrix dans Azure, il est recommandé de concevoir le réseau virtuel en gardant cela à l’esprit, en créant des sous-réseaux pour des composants similaires, ce qui permet l’application granulaire des NSG et des UDRs selon les besoins. Par exemple, la segmentation de l’infrastructure Citrix dans son propre sous-réseau, avec un sous-réseau correspondant pour chaque cas d’utilisation.

Identifiez les ports et protocoles requis pour Citrix et les technologies de prise en charge. Vérifiez que ces ports sont autorisés dans les groupes de sécurité réseau utilisés dans l’environnement. Les groupes de sécurité réseau peuvent limiter les communications entrantes et sortantes à un ensemble défini d’IP, de réseaux virtuels, de balises de service ou de groupes de sécurité d’application.

Azure-RA-Image-7

Diagram-7 : Azure Security Center et Network Security à l’aide de NSG et ASG

Connectivité

La connexion de réseaux virtuels Azure avec le réseau local / cloud des clients est appelée réseau hybride. Cette section explique les options de connectivité réseau et de routage des services réseau. Les clients peuvent connecter leurs ordinateurs et réseaux locaux à un réseau virtuel en utilisant n’importe quelle combinaison des options suivantes :

  • Réseau privé virtuel point à site (VPN) : Établi entre un réseau virtuel et un seul ordinateur dans le réseau client. Chaque ordinateur qui souhaite établir une connectivité avec un réseau virtuel doit configurer sa connexion. Ce type de connexion est idéal pour commencer simplement avec Azure, ou pour les développeurs, car il nécessite peu ou pas de modifications au réseau existant du client. La communication entre votre ordinateur et un réseau virtuel est envoyée via un tunnel crypté sur Internet.
  • VPN de site à site : Établi entre un périphérique VPN local et une passerelle VPN Azure déployée dans un réseau virtuel. Ce type de connexion permet à toute ressource locale autorisée par le client d’accéder à un réseau virtuel. La communication entre un périphérique VPN local et une passerelle VPN Azure est envoyée via un tunnel crypté sur Internet.
  • Azure ExpressRoute : Établie entre le réseau du client et Azure, par l’intermédiaire d’un partenaire ExpressRoute. Cette connexion est privée. Le trafic ne passe pas sur Internet.

Les principaux facteurs à considérer pour la connectivité Azure vers le client sont la bande passante, la latence, la sécurité et le coût. Les VPN de site à site ont des limites de bande passante plus faibles que Express Route et dépendent des performances du routeur périphérique utilisé par le client. Les SLA sont disponibles sur les SKU de passerelle VPN. Les VPN de site à site utilisent IPSEC sur Internet.

Express Routes sont des connexions privées dédiées et non sur Internet. Cela se traduit par une latence plus faible lors de l’utilisation de Route Express. En outre, Express Route peut évoluer jusqu’à 10 Gbit/s. Express Route est configuré à l’aide d’un partenaire certifié. Le temps de configuration par ces fournisseurs devrait être pris en compte lors de la planification du projet. Les coûts de route Express comportent un composant Microsoft et un composant fournisseur Express Route.

Généralement, ces connexions sont partagées entre plusieurs services (réplication de base de données, trafic de domaine, trafic d’applications, etc.) Dans un déploiement de cloud hybride, il peut y avoir des scénarios où les utilisateurs internes ont besoin de leur trafic ICA pour passer par cette connexion pour accéder à leurs applications Citrix dans Azure. la surveillance de sa bande passante est essentielle.

Avec ADC et StoreFront traditionnel, le routage de passerelle optimal peut également être utilisé pour diriger la connexion d’un utilisateur vers un ADC en utilisant le FAI d’un bureau plutôt que l’Express Route ou VPN vers Azure.

Itinéraires définis par l’utilisateur (UDR)

Généralement, les clients utilisent un UDR pour acheminer le trafic Azure vers un dispositif pare-feu dans Azure ou un réseau virtuel spécifique. Par exemple, trafic Nord/Sud d’un VDA à Internet. Si de grandes quantités de trafic sont acheminées vers des appliances pare-feu tierces au sein d’Azure, cela peut créer un goulot d’étranglement des ressources ou un risque de disponibilité si ces appliances ne sont pas dimensionnées ou configurées de manière appropriée. Les NSG peuvent être utilisés pour compléter les pare-feu de tiers et devraient être utilisés autant que possible, le cas échéant. Considérez Azure Network Watcher si une introspection de trafic est requise.

Peering réseau virtuel

L’appairage de réseau virtuel connecte en toute transparence deux réseaux virtuels Azure. Une fois homologué, les réseaux virtuels apparaissent comme un, à des fins de connectivité. Le trafic entre les machines virtuelles dans les réseaux virtuels homologues est acheminé via l’infrastructure de base Microsoft, tout comme le trafic est routé entre les machines virtuelles du même réseau virtuel, via des adresses IP privées uniquement.

Azure prend en charge :

  • Peering de vNet - connexion de réseaux virtuels dans la même région Azure
  • Appeering global de réseaux virtuels - connexion de réseaux virtuels dans les régions Azure

Les clients qui déploient des charges de travail sur plusieurs réseaux virtuels doivent envisager d’utiliser l’appairage de réseaux virtuels pour activer la communication entre les machines virtuelles entre les réseaux virtuels.

Azure-RA-Image-8

Diagramme 8 : Connectivité et itinéraires du centre de données

SD-WAN

La technologie WAN SD-WAN (Software-Defined WAN) permet d’offrir une expérience utilisateur exceptionnelle, même sur des connexions difficiles. C’est un ajustement naturel pour la livraison d’applications virtuelles et de postes de travail.

  • Regrouper toute la bande passante disponible dans une connexion active/active, en fournissant plus de bande passante.
  • Utilisez la technologie HDX Quality of Experience unique pour optimiser les performances et régler les stratégies réseau.
  • Assurez des connexions toujours actives pour les applications virtuelles et les utilisateurs de postes de travail avec la meilleure qualité possible, même pour les médias riches et les vidéos haute définition.

Les clients utilisant VPN peuvent utiliser SD-WAN pour ajouter de la redondance à la connectivité Azure et Customer datacenter ou pour fournir un routage spécifique à l’application. Citrix SD-WAN redirige automatiquement le trafic sur toutes les connexions disponibles. En fait, l’expérience est si transparente que les utilisateurs ne réaliseront même pas qu’aucun changement s’est produit. Leur adresse IP d’accès primaire reste inchangée, ce qui permet aux utilisateurs d’accéder à leurs applications et données à l’aide des mêmes méthodes et appareils.

Citrix ADC

Citrix ADC sur Microsoft Azure garantit aux organisations l’accès à des applications et des ressources sécurisées et optimisées déployées dans le cloud et offre la flexibilité nécessaire pour établir une base de mise en réseau qui s’adapte aux besoins changeants d’un environnement. En cas de défaillance du centre de données, Citrix ADC redirige automatiquement le trafic utilisateur vers un site secondaire, sans interruption pour les utilisateurs. L’équilibrage de la charge et l’équilibrage global de la charge des serveurs dans plusieurs centres de données garantissent en outre l’intégrité, les capacités et l’utilisation optimales du serveur.

Discutez avec le client et définissez le cas d’utilisation suivant pour chaque emplacement de ressource :

Méthode d’accès Considérations
Interne seulement Un Citrix ADC n’est pas requis si seul un accès interne est nécessaire.
Accès externe via Citrix ADC Gateway Service. Le service Citrix Cloud ADC Gateway fournit un proxy ICA (connectivité distante sécurisée uniquement).
Accès externe via Citrix ADC VPX déployé dans Azure Resource Location Un client doit envisager une appliance Citrix ADC VPX dans Azure s’il a besoin des éléments suivants : 1. Authentification multifacteur avec SSON complet 2. Analyse des points de terminaison 3. Stratégies avancées d’authentification ou de pré-authentification 4. Stratégies Citrix SmartAccess. Remarque : ces exigences exigent que l’authentification se produise sur Citrix ADC plutôt que sur le service Workspace Experience. StoreFront est requis si l’authentification est gérée par un serveur virtuel Citrix ADC Gateway.

Citrix ADC - Modèle de déploiement

Les déploiements Active-Active utilisent des nœuds Citrix ADC autonomes qui peuvent être mis à l’échelle à l’aide de l’Azure Load Balancer. Les paires active-passive facilitent le basculement avec état du trafic ICA en cas de défaillance d’un nœud, mais elles sont limitées à la capacité d’un seul VPX. Les nœuds actifs-passifs nécessitent également Azure Load Balancer.

Citrix ADC est limité à 500 Mbit/s par carte réseau Azure. Plusieurs cartes réseau sont recommandées pour isoler le trafic SNIP, NSIP et VIP afin d’optimiser le débit disponible pour Citrix ADC Gateway ou d’autres services.

Sources

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

Références

Opérations

Identité

Gouvernance

Sécurité

Moniteur Azure

Connectivité

Citrix Virtual Apps and Desktops Service sur Azure

Dans cet article