Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Comment fonctionne la haute disponibilité sur AWS

August 11, 2023
Contributeur: 
C

Vous pouvez configurer deux instances NetScaler VPX sur AWS sous la forme d’une paire active-passive à haute disponibilité (HA). Lorsque vous configurez une instance en tant que nœud principal et l’autre en tant que nœud secondaire, le nœud principal accepte les connexions et gère les serveurs. Le nœud secondaire surveille le principal. Si, pour une raison quelconque, le nœud principal n’est pas en mesure d’accepter les connexions, le nœud secondaire prend le relais.

Dans AWS, les types de déploiement suivants sont pris en charge pour les instances VPX :

  • Haute disponibilité dans la même zone
  • Haute disponibilité dans différentes zones

Remarque

Pour que la haute disponibilité fonctionne, assurez-vous que les deux instances NetScaler VPX sont associées à des rôles IAM et que l’adresse IP Elastic (EIP) est attribuée au NSIP. Vous n’avez pas besoin d’attribuer un EIP au NSIP si le NSIP peut accéder à Internet via l’instance NAT.

Haute disponibilité dans les mêmes zones

Dans un déploiement haute disponibilité dans les mêmes zones, les deux instances VPX doivent avoir des configurations réseau similaires.

Suivez ces deux règles :

Règle 1. Toute carte réseau d’une instance VPX doit se trouver dans le même sous-réseau que la carte réseau correspondante de l’autre VPX. Les deux instances doivent avoir :

  • Interface de gestion sur le même sous-réseau (appelé sous-réseau de gestion)
  • Interface client sur le même sous-réseau (appelé sous-réseau client)
  • Interface serveur sur le même sous-réseau (appelé sous-réseau du serveur)

Article 2. La séquence de carte réseau de gestion, de carte réseau client et de carte réseau serveur sur les deux instances doit être la même. Par exemple, le scénario suivant n’est pas pris en charge.

Instance VPX 1

Carte réseau 0 : carte réseau de gestion 1 : carte réseau client 2 : serveur

Instance VPX 2

NIC 0 : gestion

NIC 1 : serveur

Carte réseau 2 : client

Dans ce scénario, la carte réseau 1 de l’instance 1 est dans le sous-réseau client tandis que la carte réseau 1 de l’instance 2 est dans le sous-réseau du serveur. Pour que HA fonctionne, la carte réseau 1 des deux instances doit être soit dans le sous-réseau client, soit dans le sous-réseau du serveur.

À partir de 13.0 41.xx, la haute disponibilité peut être obtenue en migrant des adresses IP privées secondaires attachées aux cartes réseau (cartes réseau client et côté serveur) du nœud HA principal vers le nœud HA secondaire après le basculement. Dans ce déploiement :

  • Les deux instances VPX ont le même nombre de cartes réseau et de mappage de sous-réseau selon l’énumération de carte réseau.

  • Chaque carte réseau VPX possède une adresse IP privée supplémentaire, à l’exception de la première carte réseau, qui correspond à l’adresse IP de gestion. L’adresse IP privée supplémentaire apparaît comme l’adresse IP privée principale dans la console Web AWS. Dans notre document, nous appelons cette adresse IP supplémentaire l’adresse IP fictive).

  • Les adresses IP fictives ne doivent pas être configurées sur l’instance NetScaler en tant que VIP et SNIP.

  • D’autres adresses IP privées secondaires doivent être créées, selon les besoins, et configurées en tant que VIP et SNIP.

  • Lors du basculement, le nouveau nœud principal recherche les SNIP et les VIP configurés et les déplace des cartes réseau attachées à la précédente principale vers les cartes réseau correspondantes sur la nouvelle interface principale.

  • Les instances NetScaler nécessitent des autorisations IAM pour que HA fonctionne. Ajoutez les privilèges IAM suivants à la stratégie IAM ajoutée à chaque instance.

"iam:GetRole" "ec2:DescribeInstances" "ec2:DescribeNetworkInterfaces" "ec2:AssignPrivateIpAddresses"

Remarque : n’unassignPrivateIpAddress est pas obligatoire.

Cette méthode est plus rapide que l’ancienne méthode. Dans l’ancienne méthode, HA dépend de la migration des interfaces réseau élastiques AWS du nœud principal vers le nœud secondaire.

Pour une méthode héritée, les stratégies suivantes sont requises :

"iam:GetRole" "ec2:DescribeInstances" "ec2:DescribeAddresses" "ec2:AssociateAddress" "ec2:DisassociateAddress"

Pour plus d’informations, voir Déployer une paire haute disponibilité sur AWS.

Haute disponibilité dans différentes zones

Vous pouvez configurer deux instances NetScaler VPX sur deux sous-réseaux différents ou deux zones de disponibilité AWS différentes, sous la forme d’une paire active-passive à haute disponibilité en mode Independent Network Configuration (INC). Lors du basculement, l’EIP (Elastic IP) du VIP de l’instance principale migre vers le secondaire, qui prend le relais en tant que nouveau principal. Dans le processus de basculement, l’API AWS :

  • Vérifie les serveurs virtuels qui y sont IPSets connectés.
  • Recherche l’adresse IP qui a une adresse IP publique associée, à partir des deux adresses IP sur lesquelles le serveur virtuel écoute. L’un qui est directement connecté au serveur virtuel et l’autre qui est connecté via l’ensemble d’adresses IP.
  • Réassocie l’adresse IP publique (EIP) à l’adresse IP privée appartenant au nouveau VIP principal.

Pour les HA dans différentes zones, les stratégies suivantes sont requises :

"iam:GetRole" "ec2:DescribeInstances" "ec2:DescribeAddresses" "ec2:AssociateAddress" "ec2:DisassociateAddress"

Pour plus d’informations, consultez la section Haute disponibilité dans les zones de disponibilité AWS.

Avant de commencer votre déploiement

Avant de commencer un déploiement HA sur AWS, lisez le document suivant :

Dépannage

Pour résoudre toute défaillance lors d’un basculement en mode HA d’une instance NetScaler VPX sur le cloud AWS, consultez le cloud-ha-daemon.log fichier stocké à cet emplacement. /var/log/

Comment fonctionne la haute disponibilité sur AWS
August 11, 2023
Contributeur: 
C
August 11, 2023
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.