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

Introduction

Ce guide explique l’architecture et le modèle de déploiement de Citrix DaaS 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 un déploiement Citrix DaaS. 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 évidence les décisions de conception et les considérations de déploiement selon les cinq principes architecturaux clés suivants :

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

  • Identité - L’une des pierres angulaires de l’ensemble 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 les services de domaine Azure AD. 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 stratégies, 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 propose 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é afin de 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 pour la mise à disposition de Citrix Apps and Desktops via Azure sont les suivants :

  • Déploiement Greenfield avec Citrix Cloud fournissant des emplacements de ressources dans Azure. Ce scénario est fourni via Citrix DaaS et utilisé lorsque les clients préfèrent opter pour un modèle d’abonnement et externaliser l’infrastructure du 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 ressources Citrix pour de nouveaux déploiements ou migrations.
  • Soulevez et déplacez. Avec ce scénario, les clients déploient leur infrastructure Citrix Management dans Azure et traitent Azure comme un site, à l’aide de NetScaler 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 DaaS

Citrix DaaS simplifie la mise à disposition et la gestion des technologies Citrix, aidant les clients à étendre les déploiements de logiciels sur site existants ou à passer à 100 % au 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 Enterprise (Current Branch for Business) par utilisateur de proposer 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 à utiliser de Microsoft Azure RemoteApp. Citrix Virtual Apps Essentials offre des performances et une flexibilité supérieures en déplaçant l’infrastructure dorsale vers le cloud, simplifiant ainsi la mise à disposition 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 au guide de conception sur l’évolutivité et la rentabilité de la mise à disposition de Citrix DaaS sur Microsoft Azure

Opérations

Dans le domaine des opérations, ce guide approfondit la planification des exigences de l’environnement de l’espace de travail et de la hiérarchie des services fondamentaux. Au niveau supérieur se trouvent les considérations relatives à l’abonnement, au groupe de ressources et à la conception régionale. Suivent des questions fréquentes sur le stockage des machines virtuelles, le stockage des profils utilisateur et la gestion/le provisionnement des images principales. Des conseils sur l’optimisation des instances réservées avec Autoscale et la planification de la continuité d’activité/reprise après sinistre sont également fournis.

Conventions de dénomination

La dénomination des ressources dans Microsoft Azure est importante pour les raisons suivantes :

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

La clé du succès des conventions de dénomination est de les établir et de les suivre dans l’ensemble de vos applications et organisations.

Lorsque vous nommez des abonnements Azure, les noms détaillés permettent de comprendre clairement le contexte et l’objectif de chaque abonnement. Le respect d’une convention de dénomination peut améliorer la clarté lorsque vous travaillez dans un environnement comportant de nombreux abonnements.

Voici un modèle recommandé pour nommer les abonnements :

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 communs pour identifier le type et le contexte de la ressource. Alors que toutes les informations sur le type, les métadonnées et le contexte sont disponibles par programme, l’application d’affixes 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’affixe 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 Étendue 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 Réseau virtuel 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] Remarque : doit être alphanumérique en minuscules ctxinfd01scu
Container Compte de stockage [Descriptive Context] vhds
Machine virtuelle Groupe de ressources [System][Role][Environment]##[Location] Remarque : Doit contenir 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 virtuelle Réseau virtuel [System][Environment]##[Location]-vng WSCD01scu-vng
Passerelle réseau locale Groupe de ressources [System][Environment]##[Location]-lng WSCD01scu-lng
Ensembles de disponibilité Groupe de ressources [System][Role]-as CTXSTF-as
Équilibreur de Groupe de ressources [System][Role]-lb CTXNSG-lb
Espaces de travail Abonnement [System][Environment]-analytics CTXP-analytics
Balises Ressource [Descriptive Context] Finance
Clés Vault 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 la présence Azure du client au sein et en dehors du déploiement de 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

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’à 2 500 VDA Citrix (il peut s’agir d’une session, d’un VDI groupé ou d’un VDI persistant). Les limites sont susceptibles d’être modifiées. Consultez les points suivants pour connaître les limites de VDA les plus récentes. Consultez le blog suivant pour connaître les dernières échelles de démarrage/arrêt dans le cadre d’un seul abonnement,

Schéma 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 font l’objet d’abonnements distincts pour gérer l’évolutivité des déploiements à grande échelle. 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 les 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 d’abonnements multiples sont destinés à des déploiements plus importants où les limites d’un seul abonnement posent problème et où des contrôles de sécurité plus granulaires sont nécessaires.
Quelles limites Azure sont susceptibles d’être atteintes ? Combien de ressources se trouvent 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. Vérifiez les limites d’abonnement Azure lors de la planification de la solution.
Quelles autorisations sont nécessaires pour le principe de service CVAD sur l’abonnement Azure ? Citrix DaaS nécessite la création de groupes de ressources et de 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 bénéficier d’un accès Contributeur à un groupe de ressources pré-créé.
Les environnements de développement et de test seront-ils créés dans des abonnements distincts de ceux de la production ? L’isolation des abonnements de développement et de test de la production permet d’appliquer et de modifier les services Azure globaux dans un environnement isolé et de cloisonner l’utilisation des ressources. Cette pratique présente des avantages pour la sécurité, la conformité et les performances des abonnements. La création d’abonnements distincts pour ces environnements complique 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 59 régions du monde, et des plans ont été annoncés pour 19 autres régions à la fin de 2022.

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 au sein d’une région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un refroidissement et d’une 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 existe 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 le site Web de la carte Azure Regions pour les dernières mises
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 par rapport aux utilisateurs et aux centres de données des clients.
Est-ce que plusieurs régions Azure sont nécessaires ? Plusieurs régions Azure sont généralement prises en compte pour les raisons générales suivantes : - la proximité des données d’application ou des utilisateurs finaux - la redondance géographique pour la continuité des activités et la reprise après sinistre - la disponibilité des fonctionnalités ou des services Azure

Ensembles de disponibilité

Un ensemble 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 ensemble 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 ensemble de disponibilité s’exécutent sur plusieurs serveurs physiques, racks de calcul, unités de stockage et commutateurs réseau. En cas de défaillance matérielle ou logicielle Azure, seul un sous-ensemble de vos machines virtuelles est touché, et l’application globale reste active et reste disponible pour les clients. Les ensembles de disponibilité constituent 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é afin de maximiser la disponibilité globale de Citrix. Par exemple, un ensemble de disponibilité distinct doit être utilisé pour les Cloud Connector, un autre pour les Citrix Application Delivery Controller (ADC), StoreFront, etc.

Une fois les ensembles de disponibilité optimisés, l’étape suivante consiste à renforcer la résilience autour des temps d’arrêt des machines virtuelles au sein des ensembles de disponibilité. Cela réduit/é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. Vous pouvez utiliser deux fonctionnalités qui peuvent augmenter la fiabilité du service global.

Ces deux fonctionnalités ne protègent pas contre les maintenances/pannes imprévues.

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

Maintenance planifiée Azure

Azure effectue régulièrement 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. Grâce à Azure Planned Maintenance, il est possible de capturer ces notifications et de prendre des mesures proactives en fonction du calendrier du client, plutôt que du 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 envoie des notifications par programme aux applications pour les avertir d’une 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 interruptions. Bien que cela puisse sembler être une maintenance planifiée, ce n’est pas le cas. La principale différence est que ces événements sont déclenchés pour la maintenance planifiée et parfois pour la maintenance non planifiée. Par exemple, si Azure effectue des activités de réparation de l’hôte et doit déplacer des machines virtuelles dans de brefs délais.

Ces événements sont consommés par programmation et donneront le préavis suivant :

  • Congeler â 15 minutes
  • Redémarrer â 15 minutes
  • Redéploiement â 10 minutes

Reprise après sinistre (DR)

Azure peut fournir une solution de reprise après sinistre très rentable aux 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 la mise en œuvre de la solution DR.

Étendre l’architecture

Dans cette topologie, l’infrastructure de gestion reste sur site, 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 NetScaler 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 simplement un autre emplacement de ressources. 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 en matière de RTO et de RPO de l’environnement Citrix ? RTO : durée ciblée et niveau de service dans lesquels un processus métier doit être restauré après un sinistre. RPO : intervalle de temps qui peut s’écouler pendant une interruption avant que la quantité de données perdues au cours de cette période ne dépasse le seuil maximum autorisé ou la « tolérance » du plan de continuité des activités.
Quel est le résultat souhaité en cas d’interruption de service 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

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

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 appliquée de manière cohérente dans les environnements de développement, de test et de production. Les points suivants doivent être pris en compte lors du développement d’un processus de gestion des images :

Provisioning à

Le client doit déterminer si MCS doit être utilisé pour gérer les machines non persistantes Azure ou créer ses propres modèles Azure Resource Manager (ARM). Lorsqu’un client utilise MCS pour créer des catalogues de machines, la fonctionnalité de provisionnement à la demande d’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 provisionnement à la demande Azure, les machines virtuelles sont créées uniquement lorsque Citrix DaaS lance une action de mise sous tension, une fois le provisionnement terminé. Une machine virtuelle est visible sur 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 comptes de stockage

Le client doit décider de la structure organisationnelle du stockage des images sources (ou de référence) à partir desquelles créer les machines virtuelles à l’aide de Citrix Machine Creation Services (MCS). Les images Citrix MCS peuvent provenir 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 Azure Blob. Les conteneurs sont des dossiers qui peuvent être utilisés pour séparer les images de production, de test et de 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 peuvent être utilisés avec Azure Automation pour planifier la réplication d’images. Vous trouverez plus d’informations sur Citrix App Layering ici, mais gardez à l’esprit qu’Elastic Layering nécessite un partage de fichiers SMB qui ne réside pas sur 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 serveurs de fichiers

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

  • Serveur de fichiers autonome
  • Serveurs de fichiers utilisant le réplica de stockage
  • Serveur de fichiers évolutif (SOFS) avec Storage Spaces Direct (S2D)
  • Système de fichiers distribué â Réplication (DFS-R)
  • Appliances de stockage tierces d’Azure Marketplace (telles que NetApp, etc.)

Le client doit sélectionner les technologies de serveur de fichiers qui répondent le mieux aux besoins de son entreprise. 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. Agnostique du stockage (SAN, Cloud, Local, etc.). Offre une réplication synchrone et asynchrone. Recommandé lorsque l’accès multirégional 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 Storage Spaces Direct Hautement disponible. HA multi-nœuds et multi-disques. Mise à l’échelle ascendante ou décroissante. SMB 3.0 et 3.1. Basculement transparent lors des 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 un domaine. Ne peut pas être déployé 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 exigences d’utilisation du client. Pour des performances optimales, assurez-vous que la prise en charge des disques haut de gamme est sélectionnée. Vous trouverez des conseils supplémentaires dans la documentationMicrosoft Azure.

Gestion des coûts d’infrastructure

Deux technologies sont disponibles 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 machines virtuelles réservées (RI) Azure réduisent considérablement les coûts (jusqu’à 72 % par rapport aux prix payables à 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 instances réservées Azure avec la valeur ajoutée d’Azure Hybrid Benefit, 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.

Alors que les instances réservées Azure nécessitent 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 baliser les machines qui doivent être mises à l’échelle automatique et exclure vos instances réservées (ou les charges de travail locales). Vous pouvez trouver plus d’informations ici : Restreindre la mise à l’Autoscale à certaines machines d’un groupe de mise àdisposition.

Citrix Autoscale

Autoscale est une fonctionnalité exclusive à Citrix DaaS qui fournit une solution cohérente et hautes performances pour gérer de manière proactive l’alimentation de 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 Basé sur la charge et le calendrier
Machinesavec OS de serveur hébergeant des applications publiées ou des postes de travail partagés hébergés (Server VDI) Pris en charge Pris en charge Pris en charge
Machinesavec OS de bureau hébergeant des postes de travail VDI statiques persistants (dédiés) 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 afin qu’Autoscale n’éteigne pas automatiquement les machines avant que l’utilisateur n’ait établi 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 - hébergement de machines - 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 maximum 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 Autoscale ici.

Optimisation de l’expérience utilisateur final

Pour optimiser l’expérience de l’utilisateur final, il faut trouver un équilibre entre la perception de réactivité de l’utilisateur final et la nécessité pour l’entreprise de respecter son 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

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 VDI approprié ? (applications virtuelles ou postes de travail virtuels)
Cas d’utilisation Quels types d’applications seront utilisés par les utilisateurs finaux ? Quelles sont les exigences des VDA pour les applications ? Comment les applications seront-elles livrées au mieux ? (Applications virtuelles et bureaux virtuels)
Horaires de travail des groupes 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 de l’espace de travail pour l’automatisation de l’évolutivité 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 des utilisateurs et des applications Où sont stockées les données de l’utilisateur et de l’application ? Les données seront-elles contenues uniquement dans Azure, uniquement sur site, ou une combinaison 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 de l’infrastructure d’un client dépendront toujours des exigences, de l’échelle 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, la meilleure approche est de commencer plus petit et de passer à l’échelle supérieure Les machines virtuelles Azure nécessitent un redémarrage lors d’un changement de taille. Planifiez donc ces événements uniquement dans les fenêtres de maintenance planifiées et selon les stratégies de contrôle des modifications établies.

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

Les questions générales suivantes doivent être examinées afin de mieux comprendre le cas d’utilisation d’un client et les ressources nécessaires à 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’une seule instance doit être minimisé. Le tableau ci-dessous fournit quelques exemples de types d’instances pour différents composants Citrix.

Composant Type d’instance recommandé
Delivery Controller, Cloud Connector DS2_v2 ou DS2_v3 standard avec stockage SSD Premium
Mise à l’échelle des charges de travail utilisateur du système Les machines virtuelles Standard_F16s_v2 avec application virtuelle ont été identifiées comme présentant le coût en $/utilisateur/heure le plus bas par rapport aux autres instances. Les machines virtuelles Standard_DS5_v2 étaient également compétitives par rapport aux autres instances
Charges de travail des utilisateurs du système d’exploitation serveur Les instances Standard_F4_v2 et Standard_F8_v2 prennent en charge un nombre d’utilisateurs inférieur, mais offrent une plus grande flexibilité dans les opérations de gestion de l’alimentation en raison de la taille réduite des conteneurs d’utilisateurs. Cela permet aux machines d’être désallouées plus efficacement afin de réduire les coûts sur les instances de paiement à l’utilisation. En outre, les domaines de défaillance sont plus petits lors de la montée en puissance.
Charges de travail des utilisateurs d’OS 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é réalisée pour fournir de bonnes informations dans ce domaine et nous vous recommandons vivement de la lire. Dans tous les cas, les clients doivent évaluer les types d’instance avec leurs charges de travail.

Pour les charges de travail gourmandes en ressources graphiques, pensez aux machines virtuelles de la série NVv4 . 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 de GPU, consultez les autres offres d’Azure.

Bien que la mise à l’échelle soit généralement le modèle préféré pour réduire les coûts, 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 de plus grande taille. 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. Autoscale éteint donc plus rapidement les instances plus petites, réduisant ainsi les coûts. Vous pouvez en savoir plus sur les considérations relatives à la taille des instances pour Autoscale dans la documentation 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 possèdent 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 le coût par disque est inférieur. Le stockage Premium n’a aucun coût de transaction, mais a des coûts par disque plus élevés et offre une meilleure expérience utilisateur.

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, une gouvernance des identités et une gestion de l’accès aux applications. Un seul annuaire 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 faire confiance au même annuaire Azure AD, mais un abonnement ne fera confiance qu’à un seul annuaire Azure AD.

Les solutions d’identité de Microsoft intègrent des fonctionnalités locales et basées sur le cloud, créant ainsi une identité utilisateur unique pour l’authentification et l’autorisation de toutes les ressources, quel que soit leur 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 à l’aide des solutions Microsoft et, dans certains cas, il peut être difficile de déterminer quelle combinaison répond le mieux aux besoins d’une organisation.

Considérations communes relatives à la conception

En général, l’extension du site Active Directory du client à Azure utilise 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 sur Azure Active Directory, ce qui vous fournit l’activation par abonnement requise pour Windows 10.

Il est recommandé d’étendre les Active Directory Domain Services locaux au sous-réseau virtuel Azure pour bénéficier de toutes les fonctionnalités et de l’extensibilité. Azure Role-Based Access Control (RBAC) permet de fournir une gestion précise des accès aux ressources Azure. Trop d’autorisations peuvent exposer et rendre compte aux attaquants. Si les autorisations sont trop limitées, les employés ne peuvent pas travailler 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 les 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 Citrix Workspace, Citrix DaaS et NetScaler ADC/StoreFront. Pour un 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 prend en charge l’authentification unique (SSO) pour DaaS dans Citrix Workspace. Citrix FAS est généralement adopté si vous utilisez l’un des fournisseurs d’identité suivants :

  • Azure Active Directory
  • Okta
  • SAML 2.0
  • Citrix Gateway

Résultats d’Active Directory et d’Azure Active Directory

  • Tenant 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 et Azure AD

Par défaut, Citrix Cloud utilise le fournisseur d’identité Citrix pour gérer les informations d’identité de tous les utilisateurs qui accèdent à Citrix Cloud. Les clients peuvent modifier cela 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 en cas de besoin.
  • Configurer l’authentification à plusieurs facteurs. Cela offre un niveau de sécurité plus élevé afin de se protéger contre le vol d’informations d’identification de connexion.
  • Utiliser une page de connexion personnalisée, de façon à ce que vos utilisateurs sachent qu’ils se connectent au site approprié.
  • Utiliser la fédération avec un fournisseur d’identité de votre choix, y compris ADFS, Okta et Ping, entre autres.

Citrix Cloud comprend une application Azure AD qui permet à Citrix Cloud de se connecter à Azure AD sans que vous ayez à vous connecter à une session Azure AD active. 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 identité Citrix, leur identité Active Directory ou Azure AD pour accéder à Citrix Cloud. L’intégration d’Azure AD permet aux administrateurs de bénéficier d’une authentification multifacteur dans Citrix Cloud. Identifiez l’URL d’authentification pour l’authentification Azure AD dans Citrix Cloud. L’URL suit le format https://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 doivent ê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 NetScaler 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 un principal de sécurité. Cela est vrai pour les utilisateurs (utilisateur principal) et les applications (principal de service). Le principal 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 permet d’activer des fonctionnalités de base telles que l’authentification de l’utilisateur/de l’application lors de la connexion et l’autorisation lors de l’accès aux ressources.

Déterminez les autorisations allouées au principal de service utilisé par le service Citrix MCS.

Les mandataires du service d’étendue de l’abonnement disposent des droits de contributeur sur l’abonnement applicable utilisé par l’environnement Citrix. Les principaux de service à portée limitée ont un RBAC granulaire appliqué aux groupes de ressources contenant le réseau, les images principales et les VDA. Il est recommandé aux responsables de service à portée limitée de limiter les autorisations aux seules autorisations requises par le service. Cela adhère au concept de sécurité de « moindre privilège ».

Marquage

Le client applique des balises à ses ressources Azure en fournissant des métadonnées pour les organiser logiquement dans une 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 en production.

Le client peut récupérer toutes les ressources de votre abonnement avec ce nom et cette valeur de balise. Les balises leur permettent de récupérer des ressources associées de différents groupes de ressources. Cette approche est utile lorsque l’administrateur doit 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. Par conséquent, 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 dénomination. Il existe des stratégies par défaut disponibles 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 d’abonnement.

Identifiez les aspects d’Azure qui doivent être contrôlés et normalisés dans l’environnement Citrix. Le quota dur force la stratégie et ne permet pas d’exceptions. Vérifications des quotas souples pour l’application de la stratégie 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 : Stratégie 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é issus de renseignements de sécurité mondiaux, de contrôles sophistiqués orientés vers le client et d’une infrastructure sécurisée et 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, c’est-à-dire un principal de service d’application pour accéder aux groupes de ressources Azure afin d’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 aux documents 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 existe quelques bonnes pratiques que vous devez suivre :

  • Contrôlez l’accès aux 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 et des règles de sécurité réseau 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.
  • Traitement des configurations de système d’exploitation qui ne correspondent pas aux lignes de base recommandées.

Conception du réseau

La sécurité du 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 inclut une infrastructure réseau robuste pour prendre en charge vos besoins de connectivité des applications et des services. La connectivité réseau est possible entre les ressources situées dans Azure, entre les ressources locales et hébergées sur Azure, et 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 qui sous-tend un réseau virtuel Azure est de créer un réseau unique basé sur un espace d’adresses IP privé sur lequel les clients peuvent placer toutes leurs machines virtuelles Azure. La meilleure pratique consiste à segmenter le plus grand espace d’adressage 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 s’effectue 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 périphériques d’inspection de paquets simples et dynamiques qui utilisent l’approche à 5 tuples (l’adresse IP source, le port source, l’adresse IP de destination, le port de destination et le protocole de couche 4) pour créer des règles d’autorisation/de 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 UDR 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 des réseaux virtuels Azure au réseau local/cloud des clients est appelée mise en 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 (VPN) point à site : établi entre un réseau virtuel et un seul ordinateur du réseau du 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 : établi 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 par Internet.

Les principales considérations relatives à la connectivité entre Azure et 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 inférieures à celles d’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.

Les itinéraires express sont des connexions privées dédiées et non via 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 doit ê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 fournisseur d’accès Internet d’un bureau plutôt que l’Express Route ou le 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. Envisagez Azure Network Watcher si l’introspection du trafic est requise.

Peering de réseau virtuel

L’appairage de réseaux virtuels connecte de manière transparente deux réseaux virtuels Azure. Une fois appairés, les réseaux virtuels apparaissent comme un tout, à des fins de connectivité. Le trafic entre les machines virtuelles des réseaux virtuels appairés est acheminé via l’infrastructure dorsale Microsoft, tout comme le trafic est acheminé entre les machines virtuelles du même réseau virtuel, via des adresses IP privées uniquement.

Azure prend en charge :

  • Appairage de réseaux virtuels : connexion de réseaux virtuels au sein d’une même région Azure
  • Appairage global de réseaux virtuels : connexion de réseaux virtuels entre 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 Software-Defined WAN (SD-WAN) permet d’offrir une expérience utilisateur exceptionnelle, même sur des connexions difficiles. Il s’agit d’une solution idéale pour la diffusion d’applications et de postes de travail virtuels.

  • Regroupez toute la bande passante disponible dans une connexion active/active, fournissant ainsi plus de bande passante.
  • Utilisez la technologie unique HDX Quality of Experience pour optimiser les performances et ajuster les stratégies réseau.
  • Garantissez des connexions permanentes pour les utilisateurs d’applications virtuelles et de postes de travail avec une expérience de la plus haute qualité possible, même pour les contenus multimédia 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 fluide que les utilisateurs ne se rendront même pas compte 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

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

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

Méthode d’accès Considérations
Interne uniquement Un NetScaler ADC n’est pas nécessaire si seul un accès interne est nécessaire.
Accès externe via NetScaler ADC Gateway Service. Le service Citrix Cloud ADC Gateway fournit un proxy ICA (connectivité à distance sécurisée uniquement).
Accès externe via NetScaler ADC VPX déployé dans Azure Resource Location Un client doit envisager une appliance NetScaler 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 NetScaler ADC plutôt que sur le service Workspace Experience. StoreFront est requis si l’authentification est gérée par un serveur virtuel NetScaler ADC Gateway.

NetScaler ADC - Modèle de déploiement

Les déploiements Active-Active utilisent des nœuds NetScaler 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 actif-passif nécessitent également Azure Load Balancer.

Plusieurs cartes réseau sont recommandées pour isoler le trafic SNIP, NSIP et VIP afin d’optimiser le débit disponible pour NetScaler 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 ce travail, nous aimerions vous fournir des diagrammes sources que vous pouvez adapter dans vos propres conceptions détaillées et guides d’implémentation : diagrammes source.

Références

Opérations

Identité

Gouvernance

Sécurité

Moniteur Azure

Connectivité

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

Dans cet article