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

Appliquez les configurations Citrix ADC VPX au premier démarrage de l’appliance Citrix ADC dans le cloud

February 13, 2024
Contributeur: 
C

Vous pouvez appliquer les configurations Citrix ADC VPX lors du premier démarrage de l’appliance Citrix ADC 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 Citrix ADC 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 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 Citrix ADC VPX à l’aide de la console AWS, accédez à Configurer les détails de l’instance > Détails avancéset indiquez 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 Citrix ADC 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

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 Citrix ADC VPX à l’aide de la console Azure, accédez à Créer une machine virtuelle > onglet 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 Citrix ADC 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 plus d’informations sur la création de l’instance VPX à l’aide de GCP, voir Déployer une instance Citrix ADC VPX sur 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 <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 prédémarrage Citrix ADC que vous fournissez via l’infrastructure cloud pendant le démarrage peuvent comprendre les quatre sections suivantes :

  • Configuration Citrix ADC représentée par la <NS-CONFIG> balise.
  • Démarrage personnalisé du Citrix ADC représenté avec la <NS-BOOTSTRAP> balise.
  • Stockage de scripts utilisateur dans Citrix ADC représenté par la <NS-SCRIPTS> balise.
  • 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 Citrix ADC VPX spécifiques qui doivent être appliquées à l’instance VPX au stade de pré-démarrage. Cette configuration est stockée dans un nouveau fichier « ns.conf ». Lorsque l’ADC est démarré pour la première fois, les configurations stockées dans le fichier « ns.conf » sont appliquées à l’instance VPX.

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 Citrix ADC

Utilisez la <NS-CONFIG> balise pour fournir les configurations Citrix ADC VPX spécifiques qui doivent être appliquées à l’instance VPX au stade de pré-démarrage. Cette configuration est stockée dans un nouveau fichier « ns.conf ». Lorsque l’ADC est démarré pour la première fois, les configurations stockées dans le fichier « ns.conf » sont appliquées à l’instance VPX.

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 Citrix ADC VPX fournit la configuration appliquée dans la <NS-CONFIG> section, comme illustré 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 une instance Citrix ADC 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.

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

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

Système de licences

Utilisez la <NS-LICENSE-CONFIG> balise pour appliquer les licences regroupées Citrix ADC 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, voir Configurer les licences de capacité regroupées Citrix ADC.

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

Afficher le serveur de licences

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 informe l’appliance Citrix ADC si l’amorçage par défaut doit être évité ou non. 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 dans l’appliance Citrix ADC 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 Citrix ADC 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.

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 <NS-BOOTSTRAP> section est exécutée.
OUI NON Le comportement de démarrage par défaut est ignoré, les commandes d’amorçage fournies dans la <NS-CONFIG> section 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 <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 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.

Méthode d'amorçage personnalisée AWS 1

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 show nsip commande dans ADC CLIet vérifier les interfaces réseau appliquées à l’instance ADC VPX lors du premier démarrage de l’appliance ADC.

Méthode AWS show nsip 1

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

Méthode bootstrap personnalisée Azure 1

Vous pouvez voir que l’instance Citrix ADC 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.

Méthode de serveur Azure1

Méthode client Azure1

Méthode de gestion Azure1

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.

commande Azure show nsip

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

Méthode GCP 1

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 :

Méthode GCP 1

Vous pouvez exécuter la show nsip commande dans ADC CLIet vérifier les interfaces réseau appliquées à l’instance ADC 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 Citrix ADC. 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.

Méthode d'amorçage personnalisée AWS 2

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 AWS show nsip 2

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)

Méthode bootstrap personnalisée Azure 2

Vous pouvez voir que l’instance Citrix ADC 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.

Méthode d'interface de gestion Azure2

Méthode d'interface client Azure 2

Méthode d'interface serveur Azure2

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 Azure show nsip 2

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

commande GCP show nsip

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.

Méthode d'amorçage personnalisée AWS 3

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.

Méthode 3 AWS eth1

Méthode 3 AWS eth0

Méthode 3 d'AWS eth2

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

Méthode AWS show nsip 3

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 Eth0 doit également être ajoutée.

Méthode bootstrap personnalisée Azure 3

<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 constater que l’instance Citrix ADC 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 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 Azure show nsip 3

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.

Méthode GCP 3

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

Afficher la sortie NSIP

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 ADC VPX. Si vous détachez ou attachez une interface lorsque le démarrage personnalisé est configuré, l’instance Citrix ADC VPX réattribue l’adresse IP principale de la nouvelle interface disponible dans 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 est alors l’interface de gestion de l’instance ADC VPX.

Par exemple, une instance Citrix ADC VPX est créé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 ADC 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 ADC 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.

Appliquez les configurations Citrix ADC VPX au premier démarrage de l’appliance Citrix ADC 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.