Appliquez les configurations NetScaler VPX lors du premier démarrage de l’appliance NetScaler dans le cloud

Vous pouvez appliquer les configurations NetScaler VPX lors du premier démarrage de l’appliance NetScaler dans un environnement cloud. Cette étape est abordée comme étape de pré-démarrage dans ce document. Par conséquent, dans certains cas, comme les licences groupées ADC, une instance VPX spécifique est mise en place en beaucoup moins de temps. Cette fonctionnalité est disponible dans Microsoft Azure, Google Cloud Platform et AWS Clouds.

Qu’est-ce que les données utilisateur

Lorsque vous provisionnez une instance VPX dans un environnement cloud, vous avez la possibilité de transmettre des données utilisateur à l’instance. Les données utilisateur vous permettent d’effectuer des tâches de configuration automatisées courantes, de personnaliser les comportements de démarrage des instances et d’exécuter des scripts après le démarrage de l’instance. Au premier démarrage, l’instance NetScaler VPX exécute les tâches suivantes :

• Lit les données utilisateur.
• Interpréte la configuration fournie dans les données utilisateur.
• Applique la configuration nouvellement ajoutée au démarrage.

Comment fournir des données utilisateur de pré-démarrage dans une instance cloud

Vous pouvez fournir des données utilisateur de pré-démarrage à l’instance cloud au format XML. Différents clouds ont des interfaces différentes pour fournir des données utilisateur.

Fournir des données utilisateur de pré-démarrage à l’aide de la console AWS

Lorsque vous provisionnez une instance NetScaler VPX à l’aide de la console AWS, accédez àConfigurer les détails de l’instance > Détails avancés, puisfournissez la configuration des données utilisateur avant le démarrage dans le champ Données utilisateur.

Pour obtenir des instructions détaillées sur chacune des étapes, consultez Déployer une instance NetScaler VPX sur AWS à l’aide de la console Web AWS. Pour plus d’informations, consultez la documentation AWS sur le lancement d’une instance.

Remarque :

Le mode AWS IMDSv2 uniquement pour la fonctionnalité de données utilisateur avant le démarrage est pris en charge à partir de NetScaler VPX version 13.1.48.x et versions ultérieures.

Fournir des données utilisateur de pré-démarrage à l’aide de l’AWS CLI

Saisissez la commande suivante dans l’interface de ligne de commande AWS :

  aws ec2 run-instances \
      --image-id ami-0abcdef1234567890 \
      --instance-type t2.micro \
      --count 1 \
      --subnet-id subnet-08fc749671b2d077c \
      --key-name MyKeyPair \
      --security-group-ids sg-0b0384b66d7d692f9 \
      --user-data file://my_script.txt
<!--NeedCopy-->

Pour plus d’informations, consultez la documentation AWS sur les instances en cours d’exécution.

Pour plus d’informations, consultez la documentation AWS sur l’utilisation des données utilisateur d’instance.

Fournir des données utilisateur de pré-démarrage à l’aide de la console Azure

Lorsque vous provisionnez une instance NetScaler VPX à l’aide de la console Azure, accédez à l’onglet Créer une machine virtuelle > Avancé . Dans le champ Données personnalisées, indiquez la configuration des données utilisateur avant le démarrage.

Fournir des données utilisateur de pré-démarrage à l’aide de l’interface de ligne de commande Azure

Saisissez la commande suivante dans l’interface de ligne de commande Azure :

  az vm create \
    --resource-group myResourceGroup \
    --name MyVm \
    --image debian \
    --custom-data MyCloudInitScript.txt \
<!--NeedCopy-->

Exemple

  az vm create --resource-group MyResourceGroup -name MyVm --image debian --custom-data MyCloudInitScript.txt
<!--NeedCopy-->

Vous pouvez transmettre vos données personnalisées ou votre configuration de prédémarrage sous forme de fichier au paramètre « —custom-data ». Dans cet exemple, le nom de fichier est MyCloudInitScript.txt.

Pour plus d’informations, consultez la documentation Azure CLI.

Fournir des données utilisateur de pré-démarrage à l’aide de la console GCP

Lorsque vous provisionnez une instance NetScaler VPX à l’aide de la console GCP, renseignez les propriétés de l’instance. Développez la gestion, la sécurité, les disques, la mise en réseau et la location exclusive. Accédez à l’onglet Gestion . Dans la section Automation, indiquez la configuration des données utilisateur de pré-démarrage dans le champ Script de démarrage.

Pour obtenir des informations détaillées sur la création de l’instance VPX à l’aide de GCP, consultez Déployer une instance NetScaler VPX sur Google Cloud Platform.

Fournir des données utilisateur de pré-démarrage à l’aide de la CLI gcloud

Saisissez la commande suivante dans l’interface de ligne de commande GCP :

  gcloud compute instances create INSTANCE_NAMES --metadata-from-file=startup-script=LOCAL_FILE_PATH
<!--NeedCopy-->

metadata-from-file - Lit la valeur ou les données utilisateur à partir d’un fichier stocké dans le <LOCAL_FILE_PATH>. .

Pour plus d’informations, consultez la documentation de l’interface de ligne de commande gcloud

Format de données utilisateur de prédémarrage

Les données utilisateur de pré-démarrage doivent être fournies à l’instance cloud au format XML. Les données utilisateur de NetScaler avant le démarrage que vous fournissez via l’infrastructure cloud lors du démarrage peuvent comprendre les quatre sections suivantes :

• Configuration de NetScaler représentée par la balise. <NS-CONFIG>
• Démarrage personnalisé du NetScaler représenté par la balise <NS-BOOTSTRAP>.
• Stockage des scripts utilisateur dans NetScaler représentés par la balise. <NS-SCRIPTS>
• Configuration des licences regroupées représentée par la <NS-LICENSE-CONFIG> balise.

Vous pouvez fournir les quatre sections précédentes dans n’importe quel ordre dans la configuration de prédémarrage ADC. Assurez-vous de suivre strictement la mise en forme affichée dans les sections suivantes tout en fournissant les données utilisateur de pré-démarrage.

Remarque :

La configuration complète des données utilisateur de pré-démarrage doit être incluse dans la <NS-PRE-BOOT-CONFIG> balise, comme illustré dans les exemples suivants.

Exemple 1 :

  <NS-PRE-BOOT-CONFIG>
       <NS-CONFIG>          </NS-CONFIG>
       <NS-BOOTSTRAP>       </NS-BOOTSTRAP>
       <NS-SCRIPTS>         </NS-SCRIPTS>
       <NS-LICENSE-CONFIG>  </NS-LICENSE-CONFIG>
  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Exemple 2 :

  <NS-PRE-BOOT-CONFIG>
      <NS-LICENSE-CONFIG> </NS-LICENSE-CONFIG>
      <NS-SCRIPTS>        </NS-SCRIPTS>
      <NS-BOOTSTRAP>      </NS-BOOTSTRAP>
      <NS-CONFIG>         </NS-CONFIG>
  </NS-PRE-BOOT-CONFIG>  
<!--NeedCopy-->

Utilisez la <NS-CONFIG> balise pour fournir les configurations NetScaler VPX spécifiques qui doivent être appliquées à l’instance VPX au stade de pré-démarrage.

Remarque :

La <NS-CONFIG> section doit comporter des commandes ADC CLI valides. Les CLI ne sont pas vérifiés pour les erreurs syntaxiques ou le format.

Configurations NetScaler

Utilisez la <NS-CONFIG> balise pour fournir les configurations NetScaler VPX spécifiques qui doivent être appliquées à l’instance VPX au stade de pré-démarrage.

Remarque :

La <NS-CONFIG> section doit comporter des commandes ADC CLI valides. Les CLI ne sont pas vérifiés pour les erreurs syntaxiques ou le format.

Exemple

Dans l’exemple suivant, la <NS-CONFIG> section contient les détails des configurations. Un VLAN de l’ID « 5 » est configuré et lié au SNIP (5.0.0.1). Un serveur virtuel d’équilibrage de charge (4.0.0.101) est également configuré.

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>
       <NS-CONFIG>
           add vlan 5
           add ns ip 5.0.0.1 255.255.255.0
           bind vlan 5 -IPAddress 5.0.0.1 255.255.255.0
           enable ns feature WL SP LB RESPONDER
           add server 5.0.0.201 5.0.0.201
           add service preboot_s5_201 5.0.0.201 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip
   NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
           add lb vserver preboot_v4_101 HTTP 4.0.0.101 80 -persistenceType NONE -cltTimeout 180
       </NS-CONFIG>
  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

L’instance NetScaler VPX propose la configuration appliquée dans la <NS-CONFIG> section, comme indiqué dans les illustrations suivantes.

Scripts utilisateur

Utilisez la <NS-SCRIPTS> balise pour fournir tout script qui doit être stocké et exécuté dans l’instance NetScaler VPX.

Vous pouvez inclure de nombreux scripts dans la <NS-SCRIPTS> balise. Chaque script doit être inclus dans la <SCRIPT> balise. Chaque <SCRIPT> section correspond à un script et contient tous les détails du script à l’aide des sous-balises suivantes.

• <SCRIPT-NAME>: Indique le nom du fichier de script qui doit être stocké.
• <SCRIPT-CONTENT>: Indique le contenu du fichier qui doit être stocké.
• <SCRIPT-TARGET-LOCATION>: Indique l’emplacement cible désigné où ce fichier doit être stocké. Si l’emplacement cible n’est pas fourni, par défaut, le fichier ou le script est enregistré dans le répertoire « /nsconfig ».
• <SCRIPT-NS-BOOTUP>: Spécifiez les commandes que vous utilisez pour exécuter le script.
  • Si vous utilisez <SCRIPT-NS-BOOTUP> cette section, les commandes fournies dans la section sont stockées dans « /nsconfig/nsafter.sh » et les commandes sont exécutées après le démarrage du moteur de paquets dans le cadre de l’exécution de « nsafter.sh ».
  • Si vous n’utilisez pas la <SCRIPT-NS-BOOTUP> section, le fichier de script est stocké à l’emplacement cible que vous spécifiez.

Exemple 1 :

Dans cet exemple, la <NS-SCRIPTS> balise contient des détails sur un seul script : script-1.sh. Le script « script-1.sh » est enregistré dans le répertoire « /var ». Le script est rempli avec le contenu spécifié et est exécuté avec la commande « sh /var/script-1.sh » après le démarrage du moteur de paquets.

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>
      <NS-SCRIPTS>
      <SCRIPT>
              <SCRIPT-CONTENT>
                  #Shell script
                  echo "Running script 1" > /var/script-1.output
                  date >> /var/script-1.output
              </SCRIPT-CONTENT>

                  <SCRIPT-NAME> script-1.sh </SCRIPT-NAME>
                  <SCRIPT-TARGET-LOCATION> /var/ </SCRIPT-TARGET-LOCATION>
                  <SCRIPT-NS-BOOTUP>sh /var/script-1.sh</SCRIPT-NS-BOOTUP>
          </SCRIPT>
      </NS-SCRIPTS>
  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Dans l’instantané suivant, vous pouvez vérifier que le script « script-1.sh » est enregistré dans le répertoire « /var/ ». Le script « Script-1.sh » est exécuté et le fichier de sortie est créé de manière appropriée.

Exemple 2 :

Dans l’exemple suivant, la <NS-SCRIPTS> balise contient des détails sur deux scripts.

• Le premier script est enregistré sous le nom « script-1.sh » dans le répertoire « /var ». Le script est rempli avec le contenu spécifié et est exécuté avec la commande « sh /var/script-1.sh » après le démarrage du moteur de paquets.
• Le deuxième script est enregistré sous le nom « file-2.txt » dans le répertoire « /var ». Ce fichier contient le contenu spécifié. Mais il n’est pas exécuté car la commande d’exécution de démarrage n’ <SCRIPT-NS-BOOTUP> est pas fournie.

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>
      <NS-SCRIPTS>
          <SCRIPT>
              <SCRIPT-CONTENT>
                 #Shell script
                 echo "Running script 1" > /var/script-1.output
                 date >> /var/script-1.output
              </SCRIPT-CONTENT>

              <SCRIPT-NAME>  script-1.sh  </SCRIPT-NAME>
              <SCRIPT-TARGET-LOCATION> /var/  </SCRIPT-TARGET-LOCATION>
              <SCRIPT-NS-BOOTUP>sh /var/script-1.sh</SCRIPT-NS-BOOTUP>
              </SCRIPT>

          <SCRIPT>
              <SCRIPT-CONTENT>
                  This script has no execution point.
                  It will just be saved at the target location
                  NS Consumer module should consume this script/file
              </SCRIPT-CONTENT>
              <SCRIPT-NAME>file-2.txt</SCRIPT-NAME>
              <SCRIPT-TARGET-LOCATION>/var/</SCRIPT-TARGET-LOCATION>
          </SCRIPT>
      </NS-SCRIPTS>
  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Dans l’instantané suivant, vous pouvez vérifier que script-1.sh et file-2.txt sont créés dans le répertoire « /var/ ». Le fichier Script-1.sh est exécuté et le fichier de sortie est créé de manière appropriée.

Système de licences

Utilisez la balise <NS-LICENSE-CONFIG> pour appliquer les licences groupées NetScaler lors du démarrage de l’instance VPX. Utilisez la <LICENSE-COMMANDS> balise dans <NS-LICENSE-CONFIG> la section pour fournir les commandes de licence regroupées. Ces commandes doivent être valides syntaxiquement.

Vous pouvez spécifier les détails de licence regroupés tels que le type de licence, la capacité et le serveur de licences dans la <LICENSE-COMMANDS> section à l’aide des commandes de licences groupées standard. Pour plus d’informations, consultez la section Configurer les licences de capacité groupées NetScaler.

Après avoir appliqué le <NS-LICENSE-CONFIG>, le VPX arrive avec l’édition demandée au démarrage, et VPX tente d’extraire les licences configurées à partir du serveur de licences.

• Si la récupération de la licence est réussie, la bande passante configurée est appliquée à VPX.
• Si la récupération des licences échoue, la licence n’est pas extraite du serveur de licences dans les 10 à 12 minutes environ. Par conséquent, le système redémarre et entre dans un état sans licence.

Exemple

Dans l’exemple suivant, après avoir appliqué le <NS-LICENSE-CONFIG>, le VPX arrive avec l’édition Premium au démarrage, et VPX tente d’extraire les licences configurées à partir du serveur de licences (10.102.38.214).

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>
     <NS-LICENSE-CONFIG>
          <LICENSE-COMMANDS>
              add ns licenseserver 10.102.38.214 -port 2800
              set ns capacity -unit gbps -bandwidth 3  edition platinum
          </LICENSE-COMMANDS>
      </NS-LICENSE-CONFIG>
  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Comme illustré dans l’illustration suivante, vous pouvez exécuter la commande « show license server » et vérifier que le serveur de licences (10.102.38.214) est ajouté au VPX.

Bootstrapping

Utilisez la <NS-BOOTSTRAP> balise pour fournir les informations de démarrage personnalisées. Vous pouvez utiliser les <NEW-BOOTSTRAP-SEQUENCE> balises <SKIP-DEFAULT-BOOTSTRAP> et dans la <NS-BOOTSTRAP> section. Cette section indique à l’appliance NetScaler s’il faut éviter ou non le bootstrap par défaut. Si le démarrage par défaut est évité, cette section vous offre la possibilité de fournir une nouvelle séquence de démarrage.

Configuration d’amorçage par défaut

La configuration d’amorçage par défaut de l’appliance NetScaler suit les attributions d’interface suivantes :

• Eth0 - Interface de gestion avec une certaine adresse NSIP.
• Eth1 - Interface client avec une certaine adresse VIP.
• Eth2 - Interface serveur avec une certaine adresse SNIP.

Personnalisation de la configuration de bootstrap

Vous pouvez ignorer la séquence d’amorçage par défaut et fournir une nouvelle séquence d’amorçage pour l’instance NetScaler VPX. Utilisez la <NS-BOOTSTRAP> balise pour fournir les informations de démarrage personnalisées. Par exemple, vous pouvez modifier le démarrage par défaut, où l’interface de gestion (NSIP), l’interface VIP et l’interface orientée serveur (SNIP) sont toujours fournies dans un certain ordre.

Le tableau suivant indique le comportement d’amorçage avec les différentes valeurs autorisées pour <SKIP-DEFAULT-BOOTSTRAP> et les <NEW-BOOTSTRAP-SEQUENCE> balises.

Vous pouvez personnaliser la configuration d’amorçage à l’aide des trois méthodes suivantes :

• Fournissez uniquement les détails de l’interface
• Fournir les détails de l’interface ainsi que les adresses IP et le masque de sous-réseau
• Fournir des commandes liées au bootstrap dans la <NS-CONFIG> section

Méthode 1 : amorçage personnalisé en spécifiant uniquement les détails de l’interface

Vous spécifiez les interfaces de gestion, orientées client et orientées serveur, mais pas leurs adresses IP et masques de sous-réseau. Les adresses IP et les masques de sous-réseau sont renseignés en interrogeant l’infrastructure cloud.

Exemple d’amorçage personnalisé pour AWS

Vous fournissez la séquence d’amorçage personnalisée, comme illustré dans l’exemple suivant. Pour plus d’informations, voir Comment fournir des données utilisateur de pré-démarrage dans une instance cloud. L’interface Eth2 est assignée en tant qu’interface de gestion (NSIP), Eth1 comme interface client (VIP) et interface Eth0 en tant qu’interface serveur (SNIP). La <NS-BOOTSTRAP> section contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

Une fois l’instance de machine virtuelle créée, dans le portail AWS, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Accédez au portail AWS > instances EC2et sélectionnez l’instance que vous avez créée en fournissant les informations d’amorçage personnalisées.
2. Dans l’onglet Description, vous pouvez vérifier les propriétés de chaque interface réseau, comme illustré dans les illustrations suivantes.

Vous pouvez exécuter la commande show nsip dans l’interface de ligne de commande ADCet vérifier les interfaces réseau appliquées à l’instance NetScaler VPX lors du premier démarrage de l’appliance ADC.

Exemple de bootstrap personnalisé pour Azure

Vous fournissez la séquence d’amorçage personnalisée, comme illustré dans l’exemple suivant. Pour plus d’informations, voir Comment fournir des données utilisateur de pré-démarrage dans une instance cloud. L’interface Eth1 est assignée en tant qu’interface de gestion (NSIP), Eth0 comme interface client (VIP) et interface Eth2 en tant qu’interface serveur (SNIP). La <NS-BOOTSTRAP> section contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

Vous pouvez voir que l’instance NetScaler VPX est créée avec trois interfaces réseau. Accédez au portail Azure > Instance de machine virtuelle > Mise en réseauet vérifiez les propriétés réseau des trois cartes réseau, comme illustré dans les illustrations suivantes.

Vous pouvez exécuter la commande « show nsip » dans l’ADC CLI et vérifier que la nouvelle séquence d’amorçage spécifiée dans la <NS-BOOTSTRAP> section est appliquée. Vous pouvez exécuter la commande « show route » pour vérifier le masque de sous-réseau.

Exemples de bootstrap personnalisés pour GCP

Vous fournissez la séquence d’amorçage personnalisée, comme illustré dans l’exemple suivant. Pour plus d’informations, voir Comment fournir des données utilisateur de pré-démarrage dans une instance cloud. L’interface Eth2 est assignée en tant qu’interface de gestion (NSIP), Eth1 comme interface client (VIP) et interface Eth0 en tant qu’interface serveur (SNIP). La <NS-BOOTSTRAP> section contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

Une fois l’instance de machine virtuelle créée dans le portail GCP, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Sélectionnez l’instance que vous avez créée en fournissant les informations d’amorçage personnalisées.
2. Accédez aux propriétés de l’interface réseau et vérifiez les détails de la carte réseau comme suit :

Vous pouvez exécuter la commande show nsip dans l’interface de ligne de commande ADCet vérifier les interfaces réseau appliquées à l’instance NetScaler VPX lors du premier démarrage de l’appliance ADC.

Méthode 2 : amorçage personnalisé en spécifiant les interfaces, adresses IP et masques de sous-réseau

Vous spécifiez les interfaces de gestion, orientées client et serveur, ainsi que leurs adresses IP et leur masque de sous-réseau.

Exemples de bootstrap personnalisés pour AWS

Dans l’exemple suivant, vous ignorez le bootstrap par défaut et exécutez une nouvelle séquence d’amorçage pour l’appliance NetScaler. Pour la nouvelle séquence d’amorçage, vous spécifiez les détails suivants :

• Interface de gestion : Interface - Eth1, NSIP - 172.31.52.88 et masque de sous-réseau - 255.255.240.0
• Interface client : Interface - Eth0, VIP - 172.31.5.155 et masque de sous-réseau - 255.255.240.0.
• Interface serveur : Interface - Eth2, SNIP - 172.31.76.177 et masque de sous-réseau - 255.255.240.0.

Vous pouvez exécuter la show nsip commande dans l’interface de ligne de commande ADC et vérifier que la nouvelle séquence d’amorçage spécifiée dans la <NS-BOOTSTRAP> section est appliquée. Vous pouvez exécuter la commande « show route » pour vérifier le masque de sous-réseau.

Exemple de bootstrap personnalisé pour Azure

Dans l’exemple suivant, une nouvelle séquence d’amorçage pour ADC est mentionnée et l’amorçage par défaut est ignoré. Vous fournissez les détails de l’interface ainsi que les adresses IP et les masques de sous-réseau comme suit :

• Interface de gestion (eth2), NSIP (172.27.2.53) et masque de sous-réseau (255.255.255.0)
• Interface client (eth1), VIP (172.27.1.53) et masque de sous-réseau (255.255.255.0)
• Interface serveur (eth0), SNIP (172.27.0.53) et masque de sous-réseau (255.255.255.0)

Vous pouvez voir que l’instance NetScaler VPX est créée avec trois interfaces réseau. Accédez au portail Azure > Instance de machine virtuelle > Mise en réseauet vérifiez les propriétés réseau des trois cartes réseau, comme illustré dans les illustrations suivantes.

Vous pouvez exécuter la show nsip commande dans l’interface de ligne de commande ADC et vérifier que la nouvelle séquence d’amorçage spécifiée dans la <NS-BOOTSTRAP> section est appliquée. Vous pouvez exécuter la commande « show route » pour vérifier le masque de sous-réseau.

Exemple de bootstrap personnalisé pour GCP

Dans l’exemple suivant, une nouvelle séquence d’amorçage pour ADC est mentionnée et l’amorçage par défaut est ignoré. Vous fournissez les détails de l’interface ainsi que les adresses IP et les masques de sous-réseau comme suit :

• Interface de gestion (eth2), NSIP (10.128.4.31) et masque de sous-réseau (255.255.255.0)
• Interface client (eth1), VIP (10.128.0.43) et masque de sous-réseau (255.255.255.0)
• Interface serveur (eth0), SNIP (10.160.0.75) et masque de sous-réseau (255.255.255.0)

Une fois l’instance de machine virtuelle créée dans le portail GCP avec le bootstrap personnalisé, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Sélectionnez l’instance que vous avez créée en fournissant les informations d’amorçage personnalisées.
2. Accédez aux propriétés de l’interface réseau et vérifiez les détails de la carte réseau comme suit.

Vous pouvez exécuter la show nsip commande dans l’interface de ligne de commande ADC et vérifier que la nouvelle séquence d’amorçage spécifiée dans la <NS-BOOTSTRAP> section est appliquée. Vous pouvez exécuter la commande « show route » pour vérifier le masque de sous-réseau.

Méthode 3 : Bootstrap personnalisé en fournissant des commandes liées au bootstrap dans la <NS-CONFIG> section

Vous pouvez fournir les commandes associées au bootstrap dans la <NS-CONFIG> section. Dans la <NS-BOOTSTRAP> section, vous devez spécifier « Non » pour exécuter les commandes d’amorçage de la <NS-CONFIG> section. <NEW-BOOTSTRAP-SEQUENCE> Vous devez également fournir les commandes pour attribuer NSIP, routage par défaut et NSVLAN. En outre, fournissez les commandes pertinentes pour le cloud que vous utilisez.

Avant de fournir un bootstrap personnalisé, assurez-vous que votre infrastructure cloud prend en charge une configuration d’interface particulière.

Exemple d’amorçage personnalisé pour AWS

Dans cet exemple, les commandes liées au bootstrap sont fournies dans la <NS-CONFIG> section. La <NS-BOOTSTRAP> section indique que le démarrage par défaut est ignoré et que les informations d’amorçage personnalisées fournies dans la <NS-CONFIG> section sont exécutées. Vous devez également fournir les commandes permettant de créer NSIP, d’ajouter un itinéraire par défaut et d’ajouter un NSVLAN.

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>
      <NS-CONFIG>

          set ns config -IPAddress 172.31.52.88 -netmask 255.255.240.0
          add route 0.0.0.0 0.0.0.0 172.31.48.1
          set ns config -nsvlan 10 -ifnum 1/2  -tagged NO
          add route 172.31.0.2 255.255.255.255 172.31.48.1

          enable ns feature WL SP LB RESPONDER
          add server 5.0.0.201 5.0.0.201
          add service preboot_s5_201 5.0.0.201 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO - useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
          add lb vserver preboot_v4_101 HTTP 4.0.0.101 80 -persistenceType NONE -cltTimeout 180

      </NS-CONFIG>

      <NS-BOOTSTRAP>
       <SKIP-DEFAULT-BOOTSTRAP>YES</SKIP-DEFAULT-BOOTSTRAP>
       <NEW-BOOTSTRAP-SEQUENCE> NO </NEW-BOOTSTRAP-SEQUENCE>
      </NS-BOOTSTRAP>


  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Une fois l’instance de machine virtuelle créée, dans le portail AWS, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Accédez au portail AWS > instances EC2et sélectionnez l’instance que vous avez créée en fournissant les informations d’amorçage personnalisées.
2. Dans l’onglet Description, vous pouvez vérifier les propriétés de chaque interface réseau, comme illustré dans les illustrations suivantes.

Vous pouvez exécuter la commande show nsip dans l’interface de ligne de commande ADCet vérifier les interfaces réseau appliquées à l’instance NetScaler VPX lors du premier démarrage de l’appliance ADC.

Exemple de bootstrap personnalisé pour Azure

Dans cet exemple, les commandes liées au bootstrap sont fournies dans la <NS-CONFIG> section. La <NS-BOOTSTRAP> section indique que le démarrage par défaut est ignoré et que les informations d’amorçage personnalisées fournies dans la <NS-CONFIG> section sont exécutées.

Remarque :

Pour le cloud Azure, le serveur de métadonnées d’instance (IMDS) et les serveurs DNS sont accessibles uniquement via l’interface principale (Eth0). Par conséquent, si l’interface Eth0 n’est pas utilisée comme interface de gestion (NSIP), l’interface Eth0 doit au moins être configurée comme SNIP pour l’accès IMDS ou DNS pour fonctionner. La route vers le point de terminaison IMDS (169.254.169.254) et le point de terminaison DNS (168.63.129.16) via la passerelle d’Eth0 doit également être ajoutée.

  <NS-PRE-BOOT-CONFIG>

     <NS-CONFIG>

          set ns config -IPAddress 172.27.2.61 -netmask 255.255.255.0
          add route 0.0.0.0   0.0.0.0   172.27.2.1
          set ns config -nsvlan 10 -ifnum 1/2  -tagged NO
          add ns ip 172.27.0.61   255.255.255.0   -type SNIP
          add route 169.254.169.254 255.255.255.255 172.27.0.1
          add route 168.63.129.16 255.255.255.255 172.27.0.1

          add vlan 5
          bind vlan 5 -IPAddress 5.0.0.1 255.255.255.0
          enable ns feature WL SP LB RESPONDER
          add server 5.0.0.201 5.0.0.201
          add service preboot_s5_201 5.0.0.201 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
          add lb vserver preboot_v4_101 HTTP 4.0.0.101 80 -persistenceType NONE -cltTimeout 180

      </NS-CONFIG>

      <NS-BOOTSTRAP>

      <SKIP-DEFAULT-BOOTSTRAP>YES</SKIP-DEFAULT-BOOTSTRAP>
      <NEW-BOOTSTRAP-SEQUENCE> NO </NEW-BOOTSTRAP-SEQUENCE>

      </NS-BOOTSTRAP>

  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Vous pouvez voir que l’instance NetScaler VPX est créée avec trois interfaces réseau. Accédez au portail Azure > Instance de machine virtuelle > Mise en réseauet vérifiez les propriétés réseau des trois cartes réseau, comme illustré dans les illustrations suivantes.

Vous pouvez exécuter la show nsip commande dans l’interface de ligne de commande ADC et vérifier que la nouvelle séquence d’amorçage spécifiée dans la <NS-BOOTSTRAP> section est appliquée. Vous pouvez exécuter la commande « show route » pour vérifier le masque de sous-réseau.

Exemple de bootstrap personnalisé pour GCP

Dans cet exemple, les commandes liées au bootstrap sont fournies dans la <NS-CONFIG> section. La <NS-BOOTSTRAP> section indique que le démarrage par défaut est ignoré et que les informations d’amorçage personnalisées fournies dans la <NS-CONFIG> section sont appliquées.

Vous pouvez copier la configuration affichée dans la capture d’écran précédente à partir d’ici :

  <NS-PRE-BOOT-CONFIG>

      <NS-CONFIG>

          set ns config -IPAddress 10.128.0.2 -netmask 255.255.255.0
          add route 0.0.0.0 0.0.0.0 10.128.0.1
          set ns config -nsvlan 10 -ifnum 1/1  -tagged NO

          enable ns feature WL SP LB RESPONDER
          add server 5.0.0.201 5.0.0.201
          add service preboot_s5_201 5.0.0.201 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
          add lb vserver preboot_v4_101 HTTP 4.0.0.101 80 -persistenceType NONE -cltTimeout 180

      </NS-CONFIG>

      <NS-BOOTSTRAP>
          <SKIP-DEFAULT-BOOTSTRAP>YES</SKIP-DEFAULT-BOOTSTRAP>
          <NEW-BOOTSTRAP-SEQUENCE> NO </NEW-BOOTSTRAP-SEQUENCE>
      </NS-BOOTSTRAP>

  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Une fois l’instance de machine virtuelle créée dans le portail GCP avec le bootstrap personnalisé, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Sélectionnez l’instance que vous avez créée en fournissant les informations d’amorçage personnalisées.
2. Accédez aux propriétés de l’interface réseau et vérifiez les détails de la carte réseau, comme indiqué dans l’illustration.

Vous pouvez exécuter la show nsip commande dans ADC CLIet vérifier que les configurations fournies dans la <NS-CONFIG> section précédente sont appliquées au premier démarrage de l’appliance ADC.

Impact de l’attachement et du détachement de cartes réseau dans AWS et Azure

AWS et Azure permettent d’attacher une interface réseau à une instance et de détacher une interface réseau d’une instance. La fixation ou le détachement d’interfaces peuvent modifier la position de l’interface. Citrix vous recommande donc de ne pas détacher les interfaces de l’instance NetScaler VPX. Si vous détachez ou attachez une interface lorsque le bootstrap personnalisé est configuré, l’instance NetScaler VPX réattribue l’adresse IP principale de l’interface nouvellement disponible à la position de l’interface de gestion en tant que NSIP. Si aucune autre interface n’est disponible après celle que vous avez détachée, la première interface devient l’interface de gestion de l’instance NetScaler VPX.

Par exemple, une instance NetScaler VPX est proposée avec 3 interfaces : Eth0 (SNIP), Eth1 (NSIP) et Eth2 (VIP). Si vous détachez l’interface Eth1 de l’instance, qui est une interface de gestion, ADC configure la prochaine interface disponible (Eth2) comme interface de gestion. Ainsi, l’instance NetScaler VPX est toujours accessible via l’adresse IP principale de l’interface Eth2. Si Eth2 n’est pas non plus disponible, l’interface restante (Eth0) devient l’interface de gestion. Par conséquent, l’accès à l’instance NetScaler VPX continue d’exister.

Considérons une attribution différente des interfaces comme suit : Eth0 (SNIP), Eth1 (VIP) et Eth2 (NSIP). Si vous détachez Eth2 (NSIP), car aucune nouvelle interface n’est disponible après Eth2, la première interface (Eth0) devient l’interface de gestion.