Guide de déploiement Citrix ADC VPX sur Azure - Reprise après sinistre
Contributeurs
Auteur : Blake Schindler, Architecte de solutions
Présentation
Citrix ADC est une solution de livraison d’applications et d’équilibrage de charge qui offre une expérience utilisateur de haute qualité pour les applications web, traditionnelles et natives du cloud, quel que soit leur hébergement. Elle est disponible dans une grande variété de facteurs de forme et d’options de déploiement, sans enfermer les utilisateurs dans une configuration ou un cloud unique. La licence de capacité mutualisée permet le déplacement de la capacité entre les déploiements cloud.
En tant que leader incontesté de la livraison de services et d’applications, Citrix ADC est déployé dans des milliers de réseaux à travers le monde pour optimiser, sécuriser et contrôler la livraison de tous les services d’entreprise et cloud. Déployé directement devant les serveurs web et de bases de données, Citrix ADC combine l’équilibrage de charge et la commutation de contenu à haute vitesse, la compression HTTP, la mise en cache de contenu, l’accélération SSL, la visibilité du flux d’applications et un puissant pare-feu d’applications dans une plate-forme intégrée et facile à utiliser. Le respect des SLA est grandement simplifié grâce à une surveillance de bout en bout qui transforme les données réseau en informations commerciales exploitables. Citrix ADC permet de définir et de gérer des politiques à l’aide d’un moteur de politique déclaratif simple, sans aucune expertise en programmation requise.
Citrix VPX
Le produit Citrix ADC VPX est une appliance virtuelle qui peut être hébergée sur une grande variété de plates-formes de virtualisation et de cloud :
-
Citrix Hypervisor™
-
VMware ESX
-
Microsoft Hyper-V
-
Linux KVM
-
Amazon Web Services
-
Microsoft Azure
-
Google Cloud Platform
Ce guide de déploiement se concentre sur Citrix ADC VPX sur Microsoft Azure
Microsoft Azure
Microsoft Azure est un ensemble en constante expansion de services de cloud computing conçus pour aider les organisations à relever leurs défis commerciaux. Azure offre aux utilisateurs la liberté de créer, gérer et déployer des applications sur un réseau mondial massif en utilisant leurs outils et frameworks préférés. Avec Azure, les utilisateurs peuvent :
-
Être prêts pour l’avenir grâce à l’innovation continue de Microsoft pour soutenir leur développement aujourd’hui et leurs visions de produits pour demain.
-
Opérer un cloud hybride de manière transparente sur site, dans le cloud et en périphérie — Azure répond aux besoins des utilisateurs où qu’ils se trouvent.
-
Construire selon leurs conditions grâce à l’engagement d’Azure envers l’open source et le support de tous les langages et frameworks, permettant aux utilisateurs de construire comme ils le souhaitent et de déployer où ils le souhaitent.
-
Faire confiance à leur cloud avec une sécurité intégrée — soutenue par une équipe d’experts et une conformité proactive, leader de l’industrie, à laquelle font confiance les entreprises, les gouvernements et les startups.
Terminologie Azure
Voici une brève description des termes essentiels utilisés dans ce document que les utilisateurs doivent connaître :
-
Azure Load Balancer – L’équilibreur de charge Azure est une ressource qui distribue le trafic entrant entre les ordinateurs d’un réseau. Le trafic est distribué entre les machines virtuelles définies dans un ensemble d’équilibrage de charge. Un équilibreur de charge peut être externe ou orienté vers Internet, ou il peut être interne.
-
Azure Resource Manager (ARM) – ARM est le nouveau framework de gestion pour les services dans Azure. Azure Load Balancer est géré à l’aide d’API et d’outils basés sur ARM.
-
Pool d’adresses de back-end – Le pool d’adresses de back-end est constitué des adresses IP associées à la carte réseau (NIC) de la machine virtuelle vers laquelle la charge est distribuée.
-
BLOB - Binary Large Object – Tout objet binaire comme un fichier ou une image pouvant être stocké dans le stockage Azure.
-
Configuration IP frontale – Un équilibreur de charge Azure peut inclure une ou plusieurs adresses IP frontales, également appelées adresses IP virtuelles (VIP). Ces adresses IP servent d’entrée pour le trafic.
-
IP publique au niveau de l’instance (ILPIP) – Une ILPIP est une adresse IP publique que les utilisateurs peuvent attribuer directement à une machine virtuelle ou à une instance de rôle, plutôt qu’au service cloud dans lequel réside la machine virtuelle ou l’instance de rôle. L’ILPIP ne remplace pas l’IP virtuelle (VIP) attribuée à leur service cloud. Il s’agit plutôt d’une adresse IP supplémentaire qui peut être utilisée pour se connecter directement à une machine virtuelle ou à une instance de rôle.
Remarque :
Par le passé, un ILPIP était appelé PIP, ce qui signifie IP publique.
-
Règles NAT entrantes – Ceci contient des règles mappant un port public sur l’équilibreur de charge à un port pour une machine virtuelle spécifique dans le pool d’adresses du back-end.
-
Configuration IP (IP-Config) - Elle peut être définie comme une paire d’adresses IP (IP publique et IP privée) associée à une carte réseau individuelle (NIC). Dans une configuration IP, l’adresse IP publique peut être NULL. Chaque carte réseau peut avoir plusieurs configurations IP associées, jusqu’à 255.
-
Règles d’équilibrage de charge – Une propriété de règle qui mappe une combinaison donnée d’IP et de port front-end à un ensemble d’adresses IP et de combinaisons de ports back-end. Avec une seule définition d’une ressource d’équilibreur de charge, les utilisateurs peuvent définir plusieurs règles d’équilibrage de charge, chaque règle reflétant une combinaison d’une IP et d’un port front-end et d’une IP et d’un port back-end associés aux machines virtuelles.
-
Groupe de sécurité réseau (NSG) – Un NSG contient une liste de règles de liste de contrôle d’accès (ACL) qui autorisent ou refusent le trafic réseau vers les instances de machines virtuelles dans un réseau virtuel. Les NSG peuvent être associés à des sous-réseaux ou à des instances de machines virtuelles individuelles au sein de ce sous-réseau. Lorsqu’un NSG est associé à un sous-réseau, les règles ACL s’appliquent à toutes les instances de machines virtuelles de ce sous-réseau. De plus, le trafic vers une machine virtuelle individuelle peut être restreint davantage en associant un NSG directement à cette machine virtuelle.
-
Adresses IP privées – Utilisées pour la communication au sein d’un réseau virtuel Azure et du réseau local de l’utilisateur lorsqu’une passerelle VPN est utilisée pour étendre un réseau utilisateur à Azure. Les adresses IP privées permettent aux ressources Azure de communiquer avec d’autres ressources dans un réseau virtuel ou un réseau local via une passerelle VPN ou un circuit ExpressRoute, sans utiliser d’adresse IP accessible via Internet. Dans le modèle de déploiement Azure Resource Manager, une adresse IP privée est associée aux types de ressources Azure suivants : machines virtuelles, équilibreurs de charge internes (ILB) et passerelles d’application.
-
Sondes – Ceci contient des sondes d’intégrité utilisées pour vérifier la disponibilité des instances de machines virtuelles dans le pool d’adresses du back-end. Si une machine virtuelle particulière ne répond pas aux sondes d’intégrité pendant un certain temps, elle est retirée du service de trafic. Les sondes permettent aux utilisateurs de suivre l’état de santé des instances virtuelles. Si une sonde d’intégrité échoue, l’instance virtuelle est automatiquement retirée de la rotation.
-
Adresses IP publiques (PIP) – Une PIP est utilisée pour la communication avec Internet, y compris les services Azure accessibles au public, et est associée aux machines virtuelles, aux équilibreurs de charge accessibles via Internet, aux passerelles VPN et aux passerelles d’application.
-
Région - Une zone géographique qui ne traverse pas les frontières nationales et qui contient un ou plusieurs centres de données. La tarification, les services régionaux et les types d’offres sont exposés au niveau de la région. Une région est généralement associée à une autre région, qui peut se trouver à plusieurs centaines de kilomètres, pour former une paire régionale. Les paires régionales peuvent être utilisées comme mécanisme pour les scénarios de reprise après sinistre et de haute disponibilité. Également appelée généralement emplacement.
-
Groupe de ressources - Un conteneur dans Resource Manager qui contient les ressources associées à une application. Le groupe de ressources peut inclure toutes les ressources d’une application, ou seulement celles qui sont regroupées logiquement.
-
Compte de stockage – Un compte de stockage Azure donne aux utilisateurs accès aux services de blob, de file d’attente, de table et de fichier Azure dans Azure Storage. Un compte de stockage utilisateur fournit l’espace de noms unique pour les objets de données de stockage Azure de l’utilisateur.
-
Machine virtuelle – L’implémentation logicielle d’un ordinateur physique qui exécute un système d’exploitation. Plusieurs machines virtuelles peuvent s’exécuter simultanément sur le même matériel. Dans Azure, les machines virtuelles sont disponibles en différentes tailles.
-
Réseau virtuel - Un réseau virtuel Azure est une représentation du réseau d’un utilisateur dans le cloud. C’est une isolation logique du cloud Azure dédiée à un abonnement utilisateur. Les utilisateurs peuvent contrôler entièrement les blocs d’adresses IP, les paramètres DNS, les politiques de sécurité et les tables de routage au sein de ce réseau. Les utilisateurs peuvent également segmenter davantage leur VNet en sous-réseaux et lancer des machines virtuelles Azure IaaS et des services cloud (instances de rôle PaaS). De plus, les utilisateurs peuvent connecter le réseau virtuel à leur réseau local en utilisant l’une des options de connectivité disponibles dans Azure. En substance, les utilisateurs peuvent étendre leur réseau à Azure, avec un contrôle complet sur les blocs d’adresses IP et le bénéfice de l’échelle d’entreprise qu’Azure offre.
Cas d’utilisation
Comparé aux solutions alternatives qui exigent que chaque service soit déployé en tant qu’appliance virtuelle distincte, Citrix ADC sur Azure combine l’équilibrage de charge L4, la gestion du trafic L7, le déchargement de serveur, l’accélération d’application, la sécurité d’application et d’autres capacités essentielles de livraison d’applications dans une seule instance VPX, commodément disponible via la Place de marché Azure. De plus, tout est régi par un cadre de politique unique et géré avec le même ensemble d’outils puissants utilisés pour administrer les déploiements Citrix ADC sur site. Le résultat net est que Citrix ADC sur Azure permet plusieurs cas d’utilisation convaincants qui non seulement répondent aux besoins immédiats des entreprises d’aujourd’hui, mais aussi à l’évolution continue des infrastructures informatiques héritées vers les centres de données cloud d’entreprise.
Reprise après sinistre (DR)
Une catastrophe est une perturbation soudaine des fonctions commerciales causée par des calamités naturelles ou des événements d’origine humaine. Les catastrophes affectent les opérations des centres de données, après quoi les ressources et les données perdues sur le site sinistré doivent être entièrement reconstruites et restaurées. La perte de données ou les temps d’arrêt dans le centre de données sont critiques et entraînent l’effondrement de la continuité des activités.
L’un des défis auxquels les clients sont confrontés aujourd’hui est de décider où placer leur site de reprise après sinistre. Les entreprises recherchent la cohérence et la performance, quelles que soient les infrastructures ou les pannes de réseau sous-jacentes.
Les raisons possibles pour lesquelles de nombreuses organisations décident de migrer vers le cloud sont les suivantes :
-
Économie d’utilisation — Les dépenses en capital liées à la possession d’un centre de données sur site sont bien documentées et, en utilisant le cloud, ces entreprises peuvent libérer du temps et des ressources pour développer leurs propres systèmes.
-
Temps de récupération plus rapides — Une grande partie de l’orchestration automatisée permet une récupération en quelques minutes seulement.
-
De plus, il existe des technologies qui aident à répliquer les données en offrant une protection continue des données ou des instantanés continus pour se prémunir contre toute panne ou attaque.
-
Enfin, il existe des cas d’utilisation où les clients ont besoin de nombreux types de conformité et de contrôle de sécurité différents qui sont déjà présents sur les clouds publics. Cela facilite l’atteinte de la conformité dont ils ont besoin plutôt que de construire la leur.
Un Citrix ADC configuré pour le GSLB achemine le trafic vers le centre de données le moins chargé ou le plus performant. Cette configuration, appelée configuration active-active, améliore non seulement les performances, mais offre également une reprise après sinistre immédiate en acheminant le trafic vers d’autres centres de données si un centre de données faisant partie de la configuration tombe en panne. Citrix ADC permet ainsi aux clients d’économiser un temps et de l’argent précieux.
Types de déploiement
Déploiement multi-NIC multi-IP (déploiement à trois NIC)
-
Déploiements typiques
-
Haute disponibilité (HA)
-
Autonome
-
-
Cas d’utilisation
-
Les déploiements multi-NIC multi-IP sont utilisés pour obtenir une isolation réelle du trafic de données et de gestion.
-
Les déploiements multi-NIC multi-IP améliorent également l’échelle et les performances de l’ADC.
-
Les déploiements multi-NIC multi-IP sont utilisés dans les applications réseau où le débit est généralement de 1 Gbit/s ou plus et où un déploiement à trois NIC est recommandé.
-
Déploiement multi-IP à NIC unique (déploiement à une NIC)
-
Déploiements typiques
-
Haute disponibilité (HA)
-
Autonome
-
-
Cas d’utilisation
-
Équilibrage de charge interne
-
Le cas d’utilisation typique du déploiement multi-IP à NIC unique concerne les applications intranet nécessitant un débit inférieur (moins de 1 Gbit/s).
-
Modèles Citrix ADC Azure Resource Manager
Les modèles Azure Resource Manager (ARM) fournissent une méthode de déploiement d’infrastructure ADC en tant que code vers Azure de manière simple et cohérente. Azure est géré à l’aide d’une API Azure Resource Manager (ARM). Les ressources gérées par l’API ARM sont des objets dans Azure tels que les cartes réseau, les machines virtuelles et les bases de données hébergées. Les modèles ARM définissent les objets que les utilisateurs souhaitent utiliser, ainsi que leurs types, noms et propriétés, dans un fichier JSON qui peut être compris par l’API ARM. Les modèles ARM sont un moyen de déclarer les objets que les utilisateurs souhaitent, ainsi que leurs types, noms et propriétés, dans un fichier JSON qui peut être intégré au contrôle de code source et géré comme n’importe quel autre fichier de code. Les modèles ARM sont ce qui donne réellement aux utilisateurs la possibilité de déployer l’infrastructure Azure en tant que code.
-
Cas d’utilisation
-
Personnalisation du déploiement
-
Automatisation du déploiement
-
Déploiement multi-NIC multi-IP (trois NIC) pour la reprise après sinistre
Les clients déploieraient potentiellement en utilisant un déploiement à trois cartes réseau s’ils déploient dans un environnement de production où la sécurité, la redondance, la disponibilité, la capacité et l’évolutivité sont critiques. Avec cette méthode de déploiement, la complexité et la facilité de gestion ne sont pas des préoccupations critiques pour les utilisateurs.
Déploiement à carte réseau unique multi-IP (une carte réseau) pour la reprise après sinistre
Les clients déploieraient potentiellement en utilisant un déploiement à une seule carte réseau s’ils déploient dans un environnement hors production, s’ils configurent l’environnement pour des tests, ou s’ils préparent un nouvel environnement avant le déploiement en production. Une autre raison potentielle d’utiliser un déploiement à une seule carte réseau est que les clients souhaitent déployer directement vers le cloud rapidement et efficacement. Enfin, un déploiement à une seule carte réseau serait utilisé lorsque les clients recherchent la simplicité d’une configuration de sous-réseau unique.
Déploiement de modèles Azure Resource Manager
Les clients déploieraient en utilisant des modèles Azure Resource Manager (ARM) s’ils personnalisent leurs déploiements ou s’ils automatisent leurs déploiements.
Architecture réseau
Dans ARM, une machine virtuelle (VM) Citrix ADC VPX réside dans un réseau virtuel. Une carte réseau virtuelle (NIC) est créée sur chaque VM Citrix ADC. Le groupe de sécurité réseau (NSG) configuré dans le réseau virtuel est lié à la carte réseau, et ensemble, ils contrôlent le trafic entrant et sortant de la VM.
Le NSG transmet les requêtes à l’instance Citrix ADC VPX, et l’instance VPX les envoie aux serveurs. La réponse d’un serveur suit le même chemin en sens inverse. Le NSG peut être configuré pour contrôler une seule VM VPX, ou, avec des sous-réseaux et des réseaux virtuels, peut contrôler le trafic dans des déploiements de plusieurs VM VPX.
La carte réseau contient des détails de configuration réseau tels que le réseau virtuel, les sous-réseaux, l’adresse IP interne et l’adresse IP publique.
Sous ARM, il est bon de connaître les adresses IP suivantes qui sont utilisées pour accéder aux VM déployées avec une seule carte réseau et une seule adresse IP :
-
L’adresse IP publique (PIP) est l’adresse IP accessible depuis Internet, configurée directement sur la carte réseau virtuelle de la VM Citrix ADC. Cela permet aux utilisateurs d’accéder directement à une VM depuis le réseau externe.
-
L’adresse IP Citrix ADC (NSIP) est une adresse IP interne configurée sur la VM. Elle n’est pas routable.
-
L’adresse IP virtuelle (VIP) est configurée en utilisant l’adresse NSIP et un numéro de port. Les clients accèdent aux services Citrix ADC via l’adresse PIP, et lorsque la requête atteint la carte réseau de la VM Citrix ADC VPX ou l’équilibreur de charge Azure, la VIP est traduite en adresse IP interne (NSIP) et en numéro de port interne.
-
L’adresse IP interne est l’adresse IP interne privée de la VM provenant du pool d’espace d’adressage du réseau virtuel. Cette adresse IP n’est pas accessible depuis le réseau externe. Cette adresse IP est dynamique par défaut, sauf si les utilisateurs la définissent comme statique. Le trafic provenant d’Internet est acheminé vers cette adresse conformément aux règles créées sur le NSG. Le NSG fonctionne avec la carte réseau (NIC) pour envoyer sélectivement le bon type de trafic au bon port de la carte réseau, ce qui dépend des services configurés sur la VM.
La figure suivante montre comment le trafic circule d’un client vers un serveur via une instance Citrix ADC VPX provisionnée dans ARM.

Étapes de déploiement
Lorsque les utilisateurs déploient une instance Citrix ADC VPX sur Microsoft Azure Resource Manager (ARM), ils peuvent utiliser les capacités de cloud computing d’Azure et les fonctionnalités d’équilibrage de charge et de gestion du trafic de Citrix ADC pour leurs besoins commerciaux. Les utilisateurs peuvent déployer des instances Citrix ADC VPX sur Azure Resource Manager soit en tant qu’instances autonomes, soit en tant que paires haute disponibilité en modes actif-veille.
Mais les utilisateurs peuvent déployer une instance Citrix ADC VPX sur Microsoft Azure de deux manières :
-
Via la Place de marché Azure. L’appliance virtuelle Citrix ADC VPX est disponible sous forme d’image dans la Place de marché Microsoft Azure.
-
En utilisant le modèle JSON Citrix ADC Azure Resource Manager (ARM) disponible sur GitHub. Pour plus d’informations, consultez : Modèles Azure Citrix ADC.
Fonctionnement d’une instance Citrix ADC VPX sur Azure
Dans un déploiement sur site, une instance Citrix ADC VPX nécessite au moins trois adresses IP :
-
Adresse IP de gestion, appelée adresse NSIP
-
Adresse IP de sous-réseau (SNIP) pour la communication avec la batterie de serveurs
-
Adresse IP de serveur virtuel (VIP) pour accepter les requêtes client
Pour plus d’informations, consultez : Architecture réseau pour les instances Citrix ADC VPX sur Microsoft Azure.
Remarque :
Les appliances virtuelles VPX peuvent être déployées sur tout type d’instance disposant de deux cœurs ou plus et de plus de 2 Go de mémoire.
Dans un déploiement Azure, les utilisateurs peuvent provisionner une instance Citrix ADC VPX sur Azure de trois manières :
-
Architecture multi-NIC multi-IP
-
Architecture multi-IP à NIC unique
-
Modèles ARM (Azure Resource Manager)
Selon les exigences, les utilisateurs peuvent déployer n’importe lequel de ces types d’architecture pris en charge.
Architecture multi-NIC multi-IP (trois NIC)
Dans ce type de déploiement, les utilisateurs peuvent avoir plusieurs interfaces réseau (NIC) attachées à une instance VPX. Chaque NIC peut avoir une ou plusieurs configurations IP - adresses IP publiques et privées statiques ou dynamiques qui lui sont attribuées.
Reportez-vous aux cas d’utilisation suivants :
Configurer une configuration haute disponibilité avec plusieurs adresses IP et NIC
Dans un déploiement Microsoft Azure, une configuration haute disponibilité de deux instances Citrix ADC VPX est réalisée à l’aide de l’équilibreur de charge Azure (ALB). Ceci est réalisé en configurant une sonde d’intégrité sur l’ALB, qui surveille chaque instance VPX en envoyant des sondes d’intégrité toutes les 5 secondes aux instances primaire et secondaire.
Dans cette configuration, seul le nœud principal répond aux sondes d’intégrité et le secondaire ne le fait pas. Une fois que le principal envoie la réponse à la sonde d’intégrité, l’ALB commence à envoyer le trafic de données à l’instance. Si l’instance principale manque deux sondes d’intégrité consécutives, l’ALB ne redirige pas le trafic vers cette instance. En cas de basculement, le nouveau principal commence à répondre aux sondes d’intégrité et l’ALB y redirige le trafic. Le temps de basculement standard de haute disponibilité VPX est de trois secondes. Le temps de basculement total qui peut se produire pour la commutation de trafic peut être d’un maximum de 13 secondes.
Les utilisateurs peuvent déployer une paire d’instances Citrix ADC VPX avec plusieurs NIC dans une configuration haute disponibilité (HA) active-passive sur Azure. Chaque NIC peut contenir plusieurs adresses IP.
Les options suivantes sont disponibles pour un déploiement haute disponibilité multi-NIC :
-
Haute disponibilité utilisant un groupe à haute disponibilité Azure
-
Haute disponibilité utilisant des zones de disponibilité Azure
Pour plus d’informations sur les groupes à haute disponibilité Azure et les zones de disponibilité Azure, consultez la documentation Azure : Gérer la disponibilité des machines virtuelles Linux.
Haute disponibilité utilisant un groupe à haute disponibilité
Une configuration de haute disponibilité utilisant un groupe à haute disponibilité doit répondre aux exigences suivantes :
-
Une configuration de réseau indépendant (INC) HA
-
L’équilibreur de charge Azure (ALB) en mode Direct Server Return (DSR)
Tout le trafic passe par le nœud principal. Le nœud secondaire reste en mode veille jusqu’à la défaillance du nœud principal.
Remarque :
Pour qu’un déploiement de haute disponibilité Citrix VPX fonctionne sur le cloud Azure, les utilisateurs ont besoin d’une adresse IP publique flottante (PIP) qui peut être déplacée entre les deux nœuds VPX. L’équilibreur de charge Azure (ALB) fournit cette PIP flottante, qui est automatiquement déplacée vers le deuxième nœud en cas de basculement.
Pour qu’un déploiement de haute disponibilité Citrix VPX fonctionne sur le cloud Azure, les utilisateurs ont besoin d’une adresse IP publique flottante (PIP) qui peut être déplacée entre les deux nœuds VPX. L’équilibreur de charge Azure (ALB) fournit cette PIP flottante, qui est automatiquement déplacée vers le deuxième nœud en cas de basculement.
Dans un déploiement actif-passif, les adresses IP publiques (PIP) frontales de l’ALB sont ajoutées comme adresses VIP dans chaque nœud VPX. Dans une configuration HA-INC, les adresses VIP sont flottantes et les adresses SNIP sont spécifiques à l’instance.
Les utilisateurs peuvent déployer une paire VPX en mode haute disponibilité actif-passif de deux manières en utilisant :
-
Modèle de haute disponibilité standard Citrix ADC VPX : utilisez cette option pour configurer une paire HA avec l’option par défaut de trois sous-réseaux et six cartes réseau.
-
Commandes Windows PowerShell : utilisez cette option pour configurer une paire HA en fonction de vos exigences en matière de sous-réseau et de carte réseau.
Cette section décrit comment déployer une paire VPX dans une configuration HA active-passive à l’aide du modèle Citrix. Si les utilisateurs souhaitent déployer avec des commandes PowerShell, consultez : Configurer une configuration haute disponibilité avec plusieurs adresses IP et cartes réseau à l’aide de commandes PowerShell.
Configurer les nœuds HA-INC à l’aide du modèle de haute disponibilité Citrix
Les utilisateurs peuvent déployer rapidement et efficacement une paire d’instances VPX en mode HA-INC à l’aide du modèle standard. Le modèle crée deux nœuds, avec trois sous-réseaux et six cartes réseau. Les sous-réseaux sont destinés au trafic de gestion, client et côté serveur, et chaque sous-réseau dispose de deux cartes réseau pour les deux instances VPX.
Les utilisateurs peuvent obtenir le modèle de paire HA Citrix ADC 12.1 sur Azure Marketplace en visitant : Azure Marketplace/Citrix ADC 12.1 (Haute disponibilité).
Suivez les étapes suivantes pour lancer le modèle et déployer une paire VPX à haute disponibilité, en utilisant les groupes à haute disponibilité Azure.
-
Depuis Azure Marketplace, sélectionnez et lancez le modèle de solution Citrix. Le modèle apparaît.
-
Assurez-vous que le type de déploiement est Resource Manager et sélectionnez Créer.
-
La page Informations de base apparaît. Créez un groupe de ressources et sélectionnez OK.
-
La page Paramètres généraux apparaît. Saisissez les détails et sélectionnez OK.
-
La page Paramètres réseau apparaît. Vérifiez les configurations VNet et de sous-réseau, modifiez les paramètres requis et sélectionnez OK.
-
La page Résumé apparaît. Vérifiez la configuration et modifiez-la si nécessaire. Sélectionnez OK pour confirmer.
-
La page Acheter apparaît. Sélectionnez Acheter pour terminer le déploiement.
La création du groupe de ressources Azure avec les configurations requises peut prendre un certain temps. Une fois l’opération terminée, sélectionnez le groupe de ressources dans le portail Azure pour afficher les détails de configuration, tels que les règles d’équilibrage de charge (LB), les pools de back-end, les sondes d’intégrité, etc. La paire à haute disponibilité apparaît sous les noms ns-vpx0 et ns-vpx1.
Si d’autres modifications sont nécessaires pour la configuration HA, telles que la création de règles de sécurité et de ports supplémentaires, les utilisateurs peuvent le faire depuis le portail Azure.
Ensuite, les utilisateurs doivent configurer le serveur virtuel d’équilibrage de charge avec l’adresse IP publique frontale (PIP) de l’ALB, sur le nœud principal. Pour trouver l’IP publique de l’ALB, sélectionnez ALB > Configuration IP frontale.
Consultez la section Ressources pour plus d’informations sur la configuration du serveur virtuel d’équilibrage de charge.
Ressources :
Les liens suivants fournissent des informations supplémentaires relatives au déploiement HA et à la configuration du serveur virtuel (serveur virtuel) :
Ressources associées :
Haute disponibilité à l’aide de zones de disponibilité
Les zones de disponibilité Azure sont des emplacements isolés des pannes au sein d’une région Azure, offrant une alimentation, un refroidissement et une mise en réseau redondants et augmentant la résilience. Seules certaines régions Azure prennent en charge les zones de disponibilité. Pour plus d’informations, consultez la documentation Azure : Régions et zones de disponibilité dans Azure.
Les utilisateurs peuvent déployer une paire VPX en mode haute disponibilité à l’aide du modèle appelé « NetScaler 13.0 HA using Availability Zones », disponible sur Azure Marketplace.
Suivez les étapes suivantes pour lancer le modèle et déployer une paire VPX haute disponibilité, en utilisant les zones de disponibilité Azure.
-
Depuis Azure Marketplace, sélectionnez et lancez le modèle de solution Citrix.
-
Assurez-vous que le type de déploiement est Resource Manager et sélectionnez Créer.
-
La page Informations de base s’affiche. Saisissez les détails et cliquez sur OK.
Remarque :
Assurez-vous qu’une région Azure prenant en charge les zones de disponibilité est sélectionnée. Pour plus d’informations sur les régions prenant en charge les zones de disponibilité, consultez la documentation Azure : Régions et zones de disponibilité dans Azure.
Assurez-vous qu’une région Azure prenant en charge les zones de disponibilité est sélectionnée. Pour plus d’informations sur les régions prenant en charge les zones de disponibilité, consultez la documentation Azure : Régions et zones de disponibilité dans Azure.
-
La page Paramètres généraux s’affiche. Saisissez les détails et sélectionnez OK.
-
La page Paramètres réseau s’affiche. Vérifiez les configurations du VNet et du sous-réseau, modifiez les paramètres requis et sélectionnez OK.
-
La page Résumé s’affiche. Vérifiez la configuration et modifiez-la si nécessaire. Sélectionnez OK pour confirmer.
-
La page Acheter s’affiche. Sélectionnez Acheter pour terminer le déploiement.
La création du groupe de ressources Azure avec les configurations requises peut prendre un instant. Une fois l’opération terminée, sélectionnez le groupe de ressources pour afficher les détails de la configuration, tels que les règles d’équilibrage de charge (LB), les pools de back-end, les sondes d’intégrité, etc., dans le portail Azure. La paire haute disponibilité apparaît sous les noms ns-vpx0 et ns-vpx1. De plus, les utilisateurs peuvent voir l’emplacement sous la colonne Emplacement.
Si d’autres modifications sont nécessaires pour la configuration HA, telles que la création de règles de sécurité et de ports supplémentaires, les utilisateurs peuvent le faire à partir du portail Azure.
Architecture IP multiple à carte réseau unique (One-NIC)
Dans ce type de déploiement, une interface réseau (NIC) est associée à plusieurs configurations IP (adresses IP publiques et privées statiques ou dynamiques) qui lui sont attribuées. Pour plus d’informations, reportez-vous aux cas d’utilisation suivants :
Configurer plusieurs adresses IP pour une instance autonome Citrix ADC VPX
Cette section explique comment configurer une instance autonome Citrix ADC VPX avec plusieurs adresses IP, dans Azure Resource Manager (ARM). L’instance VPX peut avoir une ou plusieurs cartes réseau (NIC) qui lui sont attachées, et chaque carte réseau peut avoir une ou plusieurs adresses IP publiques et privées statiques ou dynamiques qui lui sont attribuées. Les utilisateurs peuvent attribuer plusieurs adresses IP comme NSIP, VIP, SNIP, etc.
Pour plus d’informations, consultez la documentation Azure : Attribuer plusieurs adresses IP à des machines virtuelles à l’aide du portail Azure.
Si vous souhaitez déployer à l’aide de commandes PowerShell, consultez Configurer plusieurs adresses IP pour une instance autonome Citrix ADC VPX à l’aide de commandes PowerShell.
Cas d’utilisation d’une instance autonome Citrix ADC VPX avec une seule carte réseau
Dans ce cas d’utilisation, une appliance autonome Citrix ADC VPX est configurée avec une seule carte réseau (NIC) connectée à un réseau virtuel (VNET). La carte réseau est associée à trois configurations IP (ipconfig), chacune ayant un objectif différent, comme indiqué dans le tableau :
| IPconfig | Associé à | Objectif |
|---|---|---|
| ipconfig1 | Adresse IP statique ; | Gère le trafic de gestion |
| adresse IP privée statique | ||
| ipconfig2 | Adresse IP publique statique | Gère le trafic côté client |
| adresse IP privée statique | ||
| ipconfig3 | Adresse IP privée statique | Communique avec les serveurs back-end |
Remarque :
IPConfig-3 n’est associée à aucune adresse IP publique.
Dans un déploiement Azure Citrix ADC VPX multi-NIC et multi-IP, l’adresse IP privée associée à la première IPConfig (principale) de la première NIC (principale) est automatiquement ajoutée en tant que NSIP de gestion de l’appliance. Les adresses IP privées restantes associées aux IPConfigs doivent être ajoutées dans l’instance VPX en tant que VIP ou SNIP à l’aide de la commande
add ns ip, conformément aux exigences de l’utilisateur.
Avant de commencer le déploiement
Avant de commencer le déploiement, les utilisateurs doivent créer une instance VPX en suivant les étapes ci-dessous.
Pour ce cas d’utilisation, l’instance VPX NSDoc0330VM est créée.
Configurer plusieurs adresses IP pour une instance Citrix ADC VPX en mode autonome
-
Ajouter des adresses IP à la VM
-
Configurer les adresses IP appartenant à Citrix ADC
Étape 1 : Ajouter des adresses IP à la VM
-
Dans le portail, cliquez sur Plus de services > tapez machines virtuelles dans la zone de filtre, puis cliquez sur Machines virtuelles.
-
Dans le panneau Machines virtuelles, cliquez sur la VM à laquelle vous souhaitez ajouter des adresses IP. Cliquez sur Interfaces réseau dans le panneau de la machine virtuelle qui apparaît, puis sélectionnez l’interface réseau.
Dans le panneau qui apparaît pour la carte réseau sélectionnée, cliquez sur Configurations IP. La configuration IP existante qui a été attribuée lors de la création de la VM, ipconfig1, est affichée. Pour ce cas d’utilisation, assurez-vous que les adresses IP associées à ipconfig1 sont statiques. Ensuite, créez deux configurations IP supplémentaires : ipconfig2 (VIP) et ipconfig3 (SNIP).
Pour créer d’autres configurations IP, cliquez sur Ajouter.
Dans la fenêtre Ajouter une configuration IP, entrez un Nom, spécifiez la méthode d’allocation comme Statique, entrez une adresse IP (192.0.0.5 pour ce cas d’utilisation) et activez Adresse IP publique.
Remarque :
Avant d’ajouter une adresse IP privée statique, vérifiez la disponibilité de l’adresse IP et assurez-vous que l’adresse IP appartient au même sous-réseau auquel la carte réseau est attachée.
Ensuite, cliquez sur Configurer les paramètres requis pour créer une adresse IP publique statique pour ipconfig2.
Par défaut, les adresses IP publiques sont dynamiques. Pour vous assurer que la VM utilise toujours la même adresse IP publique, créez une adresse IP publique statique.
Dans le panneau Créer une adresse IP publique, ajoutez un Nom, sous Attribution cliquez sur Statique. Puis cliquez sur OK.
Remarque :
Même lorsque les utilisateurs définissent la méthode d’allocation sur statique, ils ne peuvent pas spécifier l’adresse IP réelle attribuée à la ressource IP publique. Au lieu de cela, elle est allouée à partir d’un pool d’adresses IP disponibles dans la région Azure où la ressource est créée.
Suivez les étapes pour ajouter une configuration IP supplémentaire pour ipconfig3. L’adresse IP publique n’est pas obligatoire.
Étape 2 : Configurer les adresses IP appartenant à Citrix ADC
Configurez les adresses IP appartenant à Citrix ADC à l’aide de l’interface graphique ou de la commande add ns ip. Pour plus d’informations, reportez-vous à : Configuration des adresses IP appartenant à Citrix ADC.
Pour plus d’informations sur le déploiement d’une instance Citrix ADC VPX sur Microsoft Azure, consultez Déployer une instance Citrix ADC VPX sur Microsoft Azure.
Pour plus d’informations sur le fonctionnement d’une instance Citrix ADC VPX sur Azure, consultez Fonctionnement d’une instance Citrix ADC VPX sur Azure.
Modèles ARM (Azure Resource Manager)
Le référentiel GitHub pour les modèles ARM (Azure Resource Manager) de Citrix ADC héberge des modèles personnalisés Citrix ADC pour le déploiement de Citrix ADC dans les services cloud Microsoft Azure ici : Modèles Azure Citrix ADC. Tous les modèles de ce référentiel ont été développés et sont maintenus par l’équipe d’ingénierie de Citrix ADC.
Chaque modèle de ce référentiel est accompagné d’une documentation décrivant son utilisation et son architecture. Les modèles visent à codifier l’architecture de déploiement recommandée du Citrix ADC VPX, ou à présenter Citrix ADC à l’utilisateur, ou à démontrer une fonctionnalité, une édition ou une option particulière. Les utilisateurs peuvent réutiliser, modifier ou améliorer les modèles pour répondre à leurs besoins spécifiques de production et de test. La plupart des modèles nécessitent des abonnements suffisants à portal.azure.com pour créer des ressources et déployer des modèles.
Les modèles Azure Resource Manager (ARM) de Citrix ADC VPX sont conçus pour assurer un moyen simple et cohérent de déployer des Citrix ADC VPX autonomes. Ces modèles augmentent la fiabilité et la disponibilité du système grâce à une redondance intégrée. Ces modèles ARM prennent en charge les sélections Bring Your Own License (BYOL) ou basées sur l’heure. Le choix de la sélection est soit mentionné dans la description du modèle, soit proposé lors du déploiement du modèle. Pour plus d’informations sur la façon de provisionner une instance Citrix ADC VPX sur Microsoft Azure à l’aide de modèles ARM (Azure Resource Manager), visitez : Modèles Citrix Azure ADC.
Prérequis
Les utilisateurs doivent posséder certaines connaissances préalables avant de déployer une instance Citrix VPX sur Azure :
-
Familiarité avec la terminologie Azure et les détails du réseau. Pour plus d’informations, consultez la terminologie Azure dans la section précédente.
-
Connaissance d’une appliance Citrix ADC. Pour des informations détaillées sur l’appliance Citrix ADC, consultez Citrix ADC 13.0.
-
Connaissance du réseau Citrix ADC. Consultez la rubrique Réseau ici : Réseau.
Limitations
L’exécution de la solution d’équilibrage de charge Citrix ADC VPX sur ARM impose les limitations suivantes :
-
L’architecture Azure ne prend pas en charge les fonctionnalités Citrix ADC suivantes :
-
Clustering
-
IPv6
-
ARP gratuit (GARP)
-
Mode L2 (pontage). Les serveurs virtuels transparents sont pris en charge avec L2 (réécriture MAC) pour les serveurs situés dans le même sous-réseau que le SNIP.
-
VLAN étiqueté
-
Routage dynamique
-
MAC virtuel
-
USIP
-
Jumbo Frames
-
-
Si vous pensez devoir arrêter et désallouer temporairement la machine virtuelle Citrix ADC VPX à tout moment, attribuez une adresse IP interne statique lors de la création de la machine virtuelle. Si vous n’attribuez pas d’adresse IP interne statique, Azure pourrait attribuer une adresse IP différente à la machine virtuelle à chaque redémarrage, et la machine virtuelle pourrait devenir inaccessible.
-
Dans un déploiement Azure, seuls les modèles Citrix ADC VPX suivants sont pris en charge : VPX 10, VPX 200, VPX 1000 et VPX 3000. Pour plus d’informations, consultez la fiche technique de Citrix ADC VPX.
-
Si une instance Citrix ADC VPX avec un numéro de modèle supérieur à VPX 3000 est utilisée, le débit réseau pourrait ne pas être le même que celui spécifié par la licence de l’instance. Cependant, d’autres fonctionnalités, telles que le débit SSL et les transactions SSL par seconde, pourraient être améliorées.
-
L’« ID de déploiement » généré par Azure lors du provisionnement de la machine virtuelle n’est pas visible par l’utilisateur dans ARM. Les utilisateurs ne peuvent pas utiliser l’ID de déploiement pour déployer une appliance Citrix ADC VPX sur ARM.
-
L’instance Citrix ADC VPX prend en charge un débit de 20 Mb/s et les fonctionnalités de l’édition standard lors de son initialisation.
-
Pour un déploiement XenApp et XenDesktop®, un serveur virtuel VPN sur une instance VPX peut être configuré dans les modes suivants :
-
Mode de base, où le paramètre de serveur virtuel VPN ICAOnly est défini sur ON. Le mode de base fonctionne entièrement sur une instance Citrix ADC VPX sans licence.
-
Mode Smart-Access, où le paramètre de serveur virtuel VPN ICAOnly est défini sur OFF. Le mode Smart-Access ne fonctionne que pour 5 utilisateurs de session Citrix ADC AAA sur une instance Citrix ADC VPX sans licence.
-
Remarque :
Pour configurer la fonctionnalité Smart Control, les utilisateurs doivent appliquer une licence Premium à l’instance Citrix ADC VPX.
Modèles et licences Azure-VPX pris en charge
Dans un déploiement Azure, seuls les modèles Citrix ADC VPX suivants sont pris en charge : VPX 10, VPX 200, VPX 1000 et VPX 3000. Pour plus d’informations, consultez la fiche technique de Citrix ADC VPX.
Une instance Citrix ADC VPX sur Azure nécessite une licence. Les options de licence suivantes sont disponibles pour les instances Citrix ADC VPX exécutées sur Azure.
- Licences basées sur l’abonnement : Les appliances Citrix ADC VPX sont disponibles en tant qu’instances payantes sur Azure Marketplace. La licence basée sur l’abonnement est une option de paiement à l’utilisation. Les utilisateurs sont facturés à l’heure. Les modèles VPX et types de licences suivants sont disponibles sur Azure Marketplace :
| Modèle VPX | Type de licence |
|---|---|
| VPX10 | Standard, Advanced, Premium |
| VPX200 | Standard, Advanced, Premium |
| VPX1000 | Standard, Advanced, Premium |
| VPX3000 | Standard, Avancé, Premium |
-
Apportez votre propre licence (BYOL) : Si vous apportez votre propre licence (BYOL), consultez le Guide de licences VPX à l’adresse : CTX122426/NetScaler VPX and CloudBridge VPX Licensing Guide. Les utilisateurs doivent :
-
Utiliser le portail de licences dans MyCitrix pour générer une licence valide.
-
Télécharger la licence vers l’instance.
-
-
Licences d’enregistrement/de retrait Citrix ADC VPX : Pour plus d’informations, consultez : Citrix ADC VPX Check-in and Check-out Licensing.
À partir de la version 12.0 56.20 de NetScaler, VPX Express pour les déploiements sur site et dans le cloud ne nécessite pas de fichier de licence. Pour plus d’informations sur Citrix ADC VPX Express, consultez la section « Licence Citrix ADC VPX Express » dans Licensing Overview.
Remarque : Quelle que soit la licence horaire par abonnement achetée sur Azure Marketplace, dans de rares cas, l’instance Citrix ADC VPX déployée sur Azure peut démarrer avec une licence NetScaler® par défaut. Cela se produit en raison de problèmes avec le service de métadonnées d’instance Azure (IMDS).
Effectuez un redémarrage à chaud avant d’apporter toute modification de configuration sur l’instance Citrix ADC VPX, pour activer la licence Citrix ADC VPX correcte.
Directives d’utilisation des ports
Les utilisateurs peuvent configurer davantage de règles entrantes et sortantes dans le NSG lors de la création de l’instance NetScaler VPX™ ou après le provisionnement de la machine virtuelle. Chaque règle entrante et sortante est associée à un port public et à un port privé.
Avant de configurer les règles NSG, notez les directives suivantes concernant les numéros de port que vous pouvez utiliser :
-
L’instance NetScaler VPX réserve les ports suivants. Les utilisateurs ne peuvent pas les définir comme ports privés lorsqu’ils utilisent l’adresse IP publique pour les requêtes provenant d’Internet. Ports 21, 22, 80, 443, 8080, 67, 161, 179, 500, 520, 3003, 3008, 3009, 3010, 3011, 4001, 5061, 9000, 7000. Cependant, si les utilisateurs souhaitent que des services accessibles depuis Internet, tels que le VIP, utilisent un port standard (par exemple, le port 443), ils doivent créer un mappage de port à l’aide du NSG. Le port standard est ensuite mappé à un port différent configuré sur le Citrix ADC VPX pour ce service VIP. Par exemple, un service VIP peut s’exécuter sur le port 8443 de l’instance VPX mais être mappé au port public 443. Ainsi, lorsque l’utilisateur accède au port 443 via l’IP publique, la requête est dirigée vers le port privé 8443.
-
L’adresse IP publique ne prend pas en charge les protocoles dans lesquels le mappage de port est ouvert dynamiquement, tels que le FTP passif ou l’ALG.
-
La haute disponibilité ne fonctionne pas pour le trafic qui utilise une adresse IP publique (PIP) associée à une instance VPX, au lieu d’une PIP configurée sur l’équilibreur de charge Azure. Pour plus d’informations, consultez : Configure a High-Availability Setup with a Single IP Address and a Single NIC.
-
Dans un déploiement NetScaler Gateway, les utilisateurs n’ont pas besoin de configurer une adresse SNIP, car le NSIP peut être utilisé comme SNIP lorsqu’aucun SNIP n’est configuré. Les utilisateurs doivent configurer l’adresse VIP en utilisant l’adresse NSIP et un numéro de port non standard. Pour la configuration de rappel sur le serveur principal, le numéro de port VIP doit être spécifié avec l’URL VIP (par exemple,
url: port).
Remarque :
Dans Azure Resource Manager, une instance Citrix ADC VPX est associée à deux adresses IP : une adresse IP publique (PIP) et une adresse IP interne. Alors que le trafic externe se connecte à la PIP, l’adresse IP interne ou le NSIP n’est pas routable. Pour configurer un VIP dans VPX, utilisez l’adresse IP interne (NSIP) et l’un des ports libres disponibles. N’utilisez pas la PIP pour configurer un VIP.
Par exemple, si le NSIP d’une instance Citrix ADC VPX est 10.1.0.3 et qu’un port libre disponible est 10022, les utilisateurs peuvent configurer un VIP en fournissant la combinaison 10.1.0.3:10022 (adresse NSIP + port).
Dans cet article
- Contributeurs
- Présentation
- Citrix VPX
- Microsoft Azure
- Terminologie Azure
- Cas d’utilisation
- Reprise après sinistre (DR)
- Types de déploiement
- Déploiement multi-NIC multi-IP (trois NIC) pour la reprise après sinistre
- Déploiement à carte réseau unique multi-IP (une carte réseau) pour la reprise après sinistre
- Déploiement de modèles Azure Resource Manager
- Architecture réseau
- Étapes de déploiement
- Architecture multi-NIC multi-IP (trois NIC)
- Haute disponibilité utilisant un groupe à haute disponibilité
- Architecture IP multiple à carte réseau unique (One-NIC)
- Modèles ARM (Azure Resource Manager)
- Prérequis
- Limitations
- Modèles et licences Azure-VPX pris en charge
- Directives d’utilisation des ports