Appliquer les configurations NetScaler VPX au 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 désignée comme l’étape de prédémarrage dans ce document. Par conséquent, dans certains cas, comme la licence groupée ADC, une instance VPX spécifique est démarrée en beaucoup moins de temps. Cette fonctionnalité est disponible dans les clouds Microsoft Azure, Google Cloud Platform et AWS.

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 effectue 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 fur et à mesure de son 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 à Configure Instance Details > Advanced Details, et fournissez la configuration des données utilisateur de prédémarrage dans le champ User data.

Pour 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 Lancement d’une instance.

Remarque :

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

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

Saisissez la commande suivante dans l’AWS CLI :

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 l’exécution d’instances.

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, fournissez la configuration des données utilisateur de pré-démarrage.

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

Saisissez la commande suivante dans l’Azure CLI :

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 du 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 Gestion, sécurité, disques, réseau, location exclusive. Accédez à l’onglet Gestion. Dans la section Automatisation, fournissez 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, consultez Déployer une instance NetScaler VPX sur Google Cloud Platform.

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

Saisissez la commande suivante dans la CLI 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é à l’emplacement .

Pour plus d’informations, consultez la documentation de la CLI gcloud

Format des 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 pré-démarrage NetScaler que vous fournissez via l’infrastructure cloud pendant le démarrage peuvent comprendre les quatre sections suivantes :

• Configuration NetScaler représentée par la balise <NS-CONFIG>.
• Amorçage personnalisé de NetScaler représenté par la balise <NS-BOOTSTRAP>.
• Stockage des scripts utilisateur dans NetScaler représenté par la balise <NS-SCRIPTS>.
• Configuration de la licence en pool représentée par la balise <NS-LICENSE-CONFIG>.

Vous pouvez fournir les quatre sections précédentes dans n’importe quel ordre au sein de la configuration de pré-démarrage ADC. Assurez-vous de suivre scrupuleusement le formatage indiqué dans les sections suivantes lors de la fourniture des données utilisateur de pré-démarrage.

Remarque :

L’intégralité de la configuration des données utilisateur de pré-démarrage doit être incluse dans la balise <NS-PRE-BOOT-CONFIG> comme indiqué 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 balise <NS-CONFIG> pour fournir les configurations spécifiques de NetScaler VPX qui doivent être appliquées à l’instance VPX lors de l’étape de pré-démarrage.

Remarque :

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

Configurations NetScaler

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

Remarque :

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

Exemple :

Dans l’exemple suivant, la section <NS-CONFIG> contient les détails des configurations. Un VLAN d’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 démarre avec la configuration appliquée dans la section <NS-CONFIG>, comme illustré dans les figures suivantes.

Scripts utilisateur

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

Vous pouvez inclure plusieurs scripts dans la balise <NS-SCRIPTS>. Chaque script doit être inclus dans la balise <SCRIPT>. Chaque section <SCRIPT> 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 la section <SCRIPT-NS-BOOTUP>, les commandes fournies dans cette 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 les détails d’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 balise <NS-SCRIPTS> contient les détails de 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 est rempli avec le contenu spécifié. Mais il n’est pas exécuté car la commande d’exécution au démarrage <SCRIPT-NS-BOOTUP> n’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 script Script-1.sh est exécuté et le fichier de sortie est créé de manière appropriée.

Licences

Utilisez la balise <NS-LICENSE-CONFIG> pour appliquer la licence groupée 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 groupée. Ces commandes doivent être syntaxiquement valides.

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

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

• Si l’extraction de la licence est réussie, la bande passante configurée est appliquée au VPX.
• Si l’extraction de la licence échoue, la licence n’est pas récupérée du serveur de licences dans un délai d’environ 10 à 12 minutes. En conséquence, le système redémarre et passe à un état sans licence.

Exemple :

Dans l’exemple suivant, après avoir appliqué le <NS-LICENSE-CONFIG>, le VPX démarre avec l’édition Premium, et le VPX tente de récupérer les licences configurées depuis le 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 le montre 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.

Amorçage

Utilisez la balise <NS-BOOTSTRAP> pour fournir les informations d’amorçage 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 l’amorçage par défaut ou non. Si l’amorçage par défaut est évité, cette section vous offre la possibilité de fournir une nouvelle séquence d’amorçage.

Configuration d’amorçage par défaut

La configuration d’amorçage par défaut dans l’appliance NetScaler suit ces attributions d’interface :

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

Personnaliser la configuration d’amorçage

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 d’amorçage personnalisées. Par exemple, vous pouvez modifier l’amorçage par défaut, où l’interface de gestion (NSIP), l’interface côté client (VIP) et l’interface côté 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>.

Vous pouvez personnaliser la configuration du bootstrap selon les trois méthodes suivantes :

• Fournir 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 les commandes liées au bootstrap dans la section <NS-CONFIG>

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

Vous spécifiez les interfaces de gestion, côté client et côté 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 de bootstrap personnalisé pour AWS

Vous fournissez la séquence de bootstrap personnalisée comme indiqué dans l’exemple suivant. Pour plus d’informations, consultez Comment fournir des données utilisateur de pré-démarrage dans une instance cloud. L’interface Eth1 est attribuée comme interface de gestion (NSIP), l’interface Eth0 comme interface client (VIP) et l’interface Eth2 comme 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.

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 à AWS Portal > Instances EC2, et sélectionnez l’instance que vous avez créée en fournissant les informations de bootstrap personnalisées.
2. Dans l’onglet Description, vous pouvez vérifier les propriétés de chaque interface réseau comme indiqué dans les illustrations suivantes.

Vous pouvez exécuter la commande show nsip dans ADC CLI, et 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 de bootstrap personnalisée comme indiqué dans l’exemple suivant. Pour plus d’informations, consultez Comment fournir des données utilisateur de pré-démarrage dans une instance cloud. L’interface Eth2 est attribuée comme interface de gestion (NSIP), l’interface Eth1 comme interface client (VIP) et l’interface Eth0 comme 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.

Vous pouvez voir que l’instance NetScaler VPX est créée avec trois interfaces réseau. Accédez à Portail Azure > Instance de machine virtuelle > Réseau, et vérifiez les propriétés réseau des trois cartes réseau comme indiqué dans les illustrations suivantes.

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.

Exemples d’amorçage personnalisé pour GCP

Vous fournissez la séquence d’amorçage personnalisée comme indiqué dans l’exemple suivant. Pour plus d’informations, consultez Comment fournir des données utilisateur de pré-amorçage dans une instance cloud. L’interface Eth1 est attribuée comme interface de gestion (NSIP), l’interface Eth0 comme interface client (VIP) et l’interface Eth2 comme 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.

Une fois l’instance de VM 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 ADC et 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, les adresses IP et les masques de sous-réseau

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

Exemples de démarrage personnalisé pour AWS

Dans l’exemple suivant, vous ignorez le démarrage par défaut et exécutez une nouvelle séquence de démarrage pour l’appliance NetScaler. Pour la nouvelle séquence de démarrage, 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 côté client : Interface - Eth0, VIP - 172.31.5.155, et masque de sous-réseau - 255.255.240.0.
• Interface côté serveur : Interface - Eth2, SNIP - 172.31.76.177, et masque de sous-réseau - 255.255.240.0.

Vous pouvez exécuter la commande show nsip dans l’interface de ligne de commande ADC et vérifier que la nouvelle séquence de démarrage 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.

Exemple de démarrage personnalisé pour Azure

Dans l’exemple suivant, une nouvelle séquence de démarrage pour ADC est mentionnée et le démarrage 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 côté client (eth1), VIP (172.27.1.53), et masque de sous-réseau (255.255.255.0)
• Interface côté 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 > Réseau, et vérifiez les propriétés réseau des trois cartes réseau comme indiqué dans les illustrations suivantes.

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.

Exemple d’amorçage 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 côté client (eth1), VIP (10.128.0.43) et masque de sous-réseau (255.255.255.0)
• Interface côté 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 l’amorçage 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é.
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 ADC et vérifier que la nouvelle séquence de démarrage 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.

Méthode 3 : Démarrage personnalisé en fournissant des commandes de démarrage dans la section <NS-CONFIG>

Vous pouvez fournir les commandes liées au démarrage dans la section <NS-CONFIG>. Dans la section <NS-BOOTSTRAP>, vous devez spécifier <NEW-BOOTSTRAP-SEQUENCE> comme “No” pour exécuter les commandes de démarrage dans la section <NS-CONFIG>. Vous devez également fournir les commandes pour attribuer NSIP, la route par défaut et NSVLAN. De plus, fournissez les commandes pertinentes pour le cloud que vous utilisez.

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

Exemple de démarrage personnalisé pour AWS

Dans cet exemple, les commandes liées au démarrage 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 de démarrage personnalisées fournies dans la section <NS-CONFIG> sont exécutées. Vous devez également fournir les commandes pour créer NSIP, ajouter une route par défaut et ajouter NSVLAN.

Vous pouvez copier la configuration présentée dans la capture d’écran précédente 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 VM créée, dans le portail AWS, vous pouvez vérifier les propriétés de l’interface réseau comme suit :

1. Accédez à AWS Portal > EC2 instances, et sélectionnez l’instance que vous avez créée en fournissant les informations de démarrage 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 la CLI ADC, et 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 section <NS-CONFIG>. La section <NS-BOOTSTRAP> indique que le bootstrapping par défaut est ignoré, et que les informations de bootstrap 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 que l’accès IMDS ou DNS fonctionne. 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 > Réseau, et vérifiez les propriétés réseau des trois cartes réseau comme indiqué dans les illustrations suivantes.

Vous pouvez exécuter la commande show nsip dans la CLI ADC, et vérifier que la nouvelle séquence de bootstrap 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.

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 bootstrapping par défaut est ignoré et que les informations de bootstrap personnalisées fournies dans la section <NS-CONFIG> 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 VM 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 de bootstrap personnalisées.
2. Accédez aux propriétés de l’interface réseau et vérifiez les détails de la NIC comme indiqué dans l’illustration.

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

Impact de l’attachement et du détachement des NIC 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. L’attachement ou le détachement d’interfaces peut modifier les positions des interfaces. Par conséquent, Citrix vous recommande de ne pas détacher les interfaces de l’instance NetScaler VPX. Si vous détachez ou attachez une interface lorsque le bootstrapping personnalisé est configuré, l’instance NetScaler VPX réaffecte l’IP principale de la nouvelle interface 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 démarré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, l’ADC configure l’interface disponible suivante (Eth2) comme interface de gestion. Ainsi, l’instance NetScaler VPX est toujours accessible via l’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), comme aucune nouvelle interface n’est disponible après Eth2, la première interface (Eth0) devient l’interface de gestion.