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

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

February 13, 2024
Contributeur: 
C

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, voir 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.

Données utilisateur de la console AWS

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.

console Azure

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 des informations détaillées sur la création de l’instance VPX à l’aide de GCP, voir Déployer une instance NetScaler VPXsur Google Cloud Platform.

Console GCP

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

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 .

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é.

Configurations ADC

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.

Vérifier les configurations VLAN

Vérifier les configurations des serveurs

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, le fichier ou le script est enregistré par défaut dans le répertoire « /nsconfig ».
  • <SCRIPT-NS-BOOTUP>: Spécifiez les commandes que vous utilisez pour exécuter le script.
    • Si vous utilisez la section <SCRIPT-NS-BOOTUP>, 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 section <SCRIPT-NS-BOOTUP>, le fichier de script est stocké à l’emplacement cible que vous spécifiez.

Exemple 1 :

Dans cet exemple, la balise <NS-SCRIPTS> 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.

Script1

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.

sortie script1

Exemple 2 :

Dans l’exemple suivant, la balise <NS-SCRIPTS> 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 second 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 <SCRIPT-NS-BOOTUP> n’est pas fournie.

script2

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.

sortie script2

Licences

Utilisez la balise <NS-LICENSE-CONFIG> pour appliquer les licences groupées NetScaler lors du démarrage de l’instance VPX. Utilisez la balise <LICENSE-COMMANDS> dans la section <NS-LICENSE-CONFIG> 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 section <LICENSE-COMMANDS> à 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).

Commandes de licence

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 indiqué 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.

Afficher le serveur de licences

Bootstrapping

Utilisez la balise <NS-BOOTSTRAP> pour fournir les informations de démarrage personnalisées. Vous pouvez utiliser les balises <SKIP-DEFAULT-BOOTSTRAP> et <NEW-BOOTSTRAP-SEQUENCE> dans la section <NS-BOOTSTRAP>. 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 balise <NS-BOOTSTRAP> 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 les balises <SKIP-DEFAULT-BOOTSTRAP> et <NEW-BOOTSTRAP-SEQUENCE>.

SKIP-DEFAULT-BOOTSTRAP NEW-BOOTSTRAP-SEQUENCE Comportement Bootstrap
OUI OUI Le comportement d’amorçage par défaut est ignoré et une nouvelle séquence d’amorçage personnalisée fournie dans la section <NS-BOOTSTRAP> est exécutée.
OUI NON Le comportement d’amorçage par défaut est ignoré. Les commandes d’amorçage fournies dans la section <NS-CONFIG> sont exécutées.

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 section <NS-CONFIG>

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 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 section <NS-BOOTSTRAP> contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

AWS custom bootstrap method1

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.

AWS eth1

AWS eth0

AWS eth2

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.

AWS show nsip method1

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 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 section <NS-BOOTSTRAP> contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

Azure custom bootstrap method1

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.

Azure server method1

Azure client method1

Azure management method1

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

Azure show nsip command

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 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 section <NS-BOOTSTRAP> contient uniquement les détails de l’interface et non les détails des adresses IP et des masques de sous-réseau.

GCP Method1

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 :

GCP method1

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.

Gcp-show-nsip-method1

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.

AWS custom bootstrap method2

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

AWS show nsip method2

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)

Azure custom bootstrap method2

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.

Azure management interface method2

Azure client interface method2

Azure server interface method2

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

Azure show nsip method2

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)

Méthode GCP 2

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.

Détails sur la carte réseau GCP

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

GCP show nsip command

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

Vous pouvez fournir les commandes associées au bootstrap dans la section <NS-CONFIG>. Dans la section <NS-BOOTSTRAP>, vous devez spécifier la valeur <NEW-BOOTSTRAP-SEQUENCE> « Non » pour exécuter les commandes d’amorçage de la section <NS-CONFIG>. 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 section <NS-CONFIG>. La section <NS-BOOTSTRAP> indique que le démarrage par défaut est ignoré et que les informations d’amorçage personnalisées fournies dans la section <NS-CONFIG> 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.

AWS custom bootstrap method3

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.

AWS eth1 method3

AWS eth0 method3

AWS eth2 method3

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.

AWS show nsip method3

Exemple de bootstrap personnalisé pour Azure

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

Azure custom bootstrap method3

<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.

Interface du serveur Azure

Interface client Azure

Interface de gestion Azure

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

Azure show nsip method3

Exemple de bootstrap personnalisé pour GCP

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

GCP method3

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.

Détails de la carte réseau comme indiqué dans la console GCP

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

Show NSIP output

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

AWS et Azure offrent la possibilité 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 affectation 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.

Appliquez les configurations NetScaler VPX lors du premier démarrage de l’appliance NetScaler dans le cloud
February 13, 2024
Contributeur: 
C
February 13, 2024
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.