NetScaler VPX-Konfigurationen beim ersten Start der NetScaler Appliance in der Cloud anwenden

Sie können die NetScaler VPX-Konfigurationen während des ersten Starts der NetScaler Appliance in einer Cloud-Umgebung anwenden. Diese Phase wird in diesem Dokument als Preboot-Phase bezeichnet. Daher wird in bestimmten Fällen, wie z. B. bei der ADC-Pool-Lizenzierung, eine spezifische VPX-Instanz in wesentlich kürzerer Zeit hochgefahren. Diese Funktion ist in Microsoft Azure, Google Cloud Platform und AWS-Clouds verfügbar.

Was sind Benutzerdaten

Wenn Sie eine VPX-Instanz in einer Cloud-Umgebung bereitstellen, haben Sie die Möglichkeit, Benutzerdaten an die Instanz zu übergeben. Die Benutzerdaten ermöglichen es Ihnen, gängige automatisierte Konfigurationsaufgaben durchzuführen, das Startverhalten von Instanzen anzupassen und Skripte nach dem Start der Instanz auszuführen. Beim ersten Start führt die NetScaler VPX-Instanz die folgenden Aufgaben aus:

• Liest die Benutzerdaten.
• Interpretiert die in den Benutzerdaten bereitgestellte Konfiguration.
• Wendet die neu hinzugefügte Konfiguration beim Hochfahren an.

So stellen Sie Preboot-Benutzerdaten in der Cloud-Instanz bereit

Sie können Preboot-Benutzerdaten für die Cloud-Instanz im XML-Format bereitstellen. Verschiedene Clouds verfügen über unterschiedliche Schnittstellen zur Bereitstellung von Benutzerdaten.

Preboot-Benutzerdaten über die AWS-Konsole bereitstellen

Wenn Sie eine NetScaler VPX-Instanz über die AWS-Konsole bereitstellen, navigieren Sie zu Instanzdetails konfigurieren > Erweiterte Details und geben Sie die Preboot-Benutzerdatenkonfiguration im Feld Benutzerdaten ein.

Detaillierte Anweisungen zu den einzelnen Schritten finden Sie unter Bereitstellen einer NetScaler VPX-Instanz in AWS mithilfe der AWS-Webkonsole. Weitere Informationen finden Sie in der AWS-Dokumentation unter Starten einer Instanz.

Hinweis:

Der AWS IMDSv2-Only-Modus für die Preboot-Benutzerdatenfunktion wird ab NetScaler VPX Release 13.1.48.x und späteren Releases unterstützt.

Bereitstellen von Preboot-Benutzerdaten über die AWS CLI

Geben Sie den folgenden Befehl in der AWS CLI ein:

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

Weitere Informationen finden Sie in der AWS-Dokumentation unter Running instances.

Weitere Informationen finden Sie in der AWS-Dokumentation unter Using instance user data

Bereitstellen von Preboot-Benutzerdaten über die Azure-Konsole

Wenn Sie eine NetScaler VPX-Instanz über die Azure-Konsole bereitstellen, navigieren Sie zur Registerkarte Virtuellen Computer erstellen > Erweitert. Geben Sie im Feld Benutzerdefinierte Daten die Preboot-Benutzerdatenkonfiguration an.

Bereitstellen von Preboot-Benutzerdaten über die Azure CLI

Geben Sie den folgenden Befehl in der Azure CLI ein:

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

Beispiel:

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

Sie können Ihre benutzerdefinierten Daten oder die Preboot-Konfiguration als Datei an den Parameter „–custom-data“ übergeben. In diesem Beispiel lautet der Dateiname MyCloudInitScript.txt.

Weitere Informationen finden Sie in der Azure CLI-Dokumentation.

Bereitstellen von Preboot-Benutzerdaten über die GCP-Konsole

Wenn Sie eine NetScaler VPX-Instanz über die GCP-Konsole bereitstellen, füllen Sie die Eigenschaften der Instanz aus. Erweitern Sie Verwaltung, Sicherheit, Datenträger, Netzwerk, Einzelmandantenfähigkeit. Navigieren Sie zur Registerkarte Verwaltung. Geben Sie im Abschnitt Automatisierung die Preboot-Benutzerdatenkonfiguration im Feld Startskript an.

Detaillierte Informationen zum Erstellen der VPX-Instanz mit GCP finden Sie unter Bereitstellen einer NetScaler VPX-Instanz auf der Google Cloud Platform.

Preboot-Benutzerdaten mithilfe der gcloud CLI bereitstellen

Geben Sie den folgenden Befehl in der GCP CLI ein:

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

metadata-from-file – Liest den Wert oder die Benutzerdaten aus einer Datei, die unter gespeichert ist.

Weitere Informationen finden Sie unter gcloud CLI-Dokumentation

Format der Preboot-Benutzerdaten

Die Preboot-Benutzerdaten müssen der Cloud-Instanz im XML-Format bereitgestellt werden. Die NetScaler-Preboot-Benutzerdaten, die Sie während des Starts über die Cloud-Infrastruktur bereitstellen, können die folgenden vier Abschnitte umfassen:

• NetScaler-Konfiguration, dargestellt mit dem <NS-CONFIG> Tag.
• Benutzerdefiniertes Bootstrapping des NetScaler, dargestellt mit dem <NS-BOOTSTRAP> Tag.
• Speichern von Benutzerskripten in NetScaler, dargestellt mit dem <NS-SCRIPTS> Tag.
• Gepoolte Lizenzierungskonfiguration, dargestellt mit dem <NS-LICENSE-CONFIG> Tag.

Sie können die vorangegangenen vier Abschnitte in beliebiger Reihenfolge innerhalb der ADC-Preboot-Konfiguration bereitstellen. Stellen Sie sicher, dass Sie beim Bereitstellen der Preboot-Benutzerdaten das in den folgenden Abschnitten gezeigte Format strikt einhalten.

Hinweis:

Die gesamte Preboot-Benutzerdatenkonfiguration muss in den <NS-PRE-BOOT-CONFIG> Tag eingeschlossen werden, wie in den folgenden Beispielen gezeigt.

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

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

Verwenden Sie das <NS-CONFIG> Tag, um die spezifischen NetScaler VPX-Konfigurationen bereitzustellen, die in der Preboot-Phase auf die VPX-Instanz angewendet werden müssen.

Hinweis:

Der <NS-CONFIG> Abschnitt muss gültige ADC CLI-Befehle enthalten. Die CLIs werden nicht auf syntaktische Fehler oder Formatierung überprüft.

NetScaler-Konfigurationen

Verwenden Sie das <NS-CONFIG> Tag, um die spezifischen NetScaler VPX-Konfigurationen bereitzustellen, die in der Preboot-Phase auf die VPX-Instanz angewendet werden müssen.

Hinweis:

Der <NS-CONFIG> Abschnitt muss gültige ADC CLI-Befehle enthalten. Die CLIs werden nicht auf syntaktische Fehler oder Formatierung überprüft.

Beispiel:

Im folgenden Beispiel enthält der <NS-CONFIG> Abschnitt die Details der Konfigurationen. Ein VLAN mit der ID ‘5’ wird konfiguriert und an die SNIP (5.0.0.1) gebunden. Ein virtueller Lastausgleichsserver (4.0.0.101) wird ebenfalls konfiguriert.

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration von hier kopieren:

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

Die NetScaler VPX-Instanz wird mit der Konfiguration gestartet, die im <NS-CONFIG> Abschnitt angewendet wurde, wie in den folgenden Abbildungen gezeigt.

Benutzerskripte

Verwenden Sie das <NS-SCRIPTS>-Tag, um ein Skript bereitzustellen, das in der NetScaler VPX-Instanz gespeichert und ausgeführt werden muss.

Sie können viele Skripte innerhalb des <NS-SCRIPTS>-Tags einschließen. Jedes Skript muss innerhalb des <SCRIPT>-Tags enthalten sein. Jeder <SCRIPT>-Abschnitt entspricht einem Skript und enthält alle Details des Skripts unter Verwendung der folgenden Unter-Tags.

• <SCRIPT-NAME>: Gibt den Namen der Skriptdatei an, die gespeichert werden muss.
• <SCRIPT-CONTENT>: Gibt den Inhalt der Datei an, die gespeichert werden muss.
• <SCRIPT-TARGET-LOCATION>: Gibt den vorgesehenen Zielspeicherort an, an dem diese Datei gespeichert werden muss. Wenn der Zielspeicherort nicht angegeben ist, wird die Datei oder das Skript standardmäßig im Verzeichnis „/nsconfig“ gespeichert.
• <SCRIPT-NS-BOOTUP>: Geben Sie die Befehle an, die Sie zum Ausführen des Skripts verwenden.
  • Wenn Sie den <SCRIPT-NS-BOOTUP>-Abschnitt verwenden, werden die in diesem Abschnitt bereitgestellten Befehle in „/nsconfig/nsafter.sh“ gespeichert, und die Befehle werden nach dem Start der Paket-Engine als Teil der „nsafter.sh“-Ausführung ausgeführt.
  • Wenn Sie den <SCRIPT-NS-BOOTUP>-Abschnitt nicht verwenden, wird die Skriptdatei am von Ihnen angegebenen Zielspeicherort gespeichert.

Beispiel 1:

In diesem Beispiel enthält das <NS-SCRIPTS>-Tag Details zu nur einem Skript: script-1.sh. Das Skript „script-1.sh“ wird im Verzeichnis „/var“ gespeichert. Das Skript wird mit den angegebenen Inhalten gefüllt und nach dem Start der Paket-Engine mit dem Befehl „sh /var/script-1.sh“ ausgeführt.

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration von hier kopieren:

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

Im folgenden Snapshot können Sie überprüfen, ob das Skript „script-1.sh“ im Verzeichnis „/var/“ gespeichert ist. Das Skript „Script-1.sh“ wird ausgeführt, und die Ausgabedatei wird entsprechend erstellt.

Beispiel 2:

Im folgenden Beispiel enthält das <NS-SCRIPTS> Tag Details zu zwei Skripten.

• Das erste Skript wird als „script-1.sh“ im Verzeichnis „/var“ gespeichert. Das Skript wird mit den angegebenen Inhalten gefüllt und nach dem Start der Paket-Engine mit dem Befehl „sh /var/script-1.sh“ ausgeführt.
• Das zweite Skript wird als „file-2.txt“ im Verzeichnis „/var“ gespeichert. Diese Datei wird mit den angegebenen Inhalten gefüllt. Es wird jedoch nicht ausgeführt, da der Startausführungsbefehl <SCRIPT-NS-BOOTUP> nicht angegeben ist.

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration hier kopieren:

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

Im folgenden Snapshot können Sie überprüfen, ob script-1.sh und file-2.txt im Verzeichnis „/var/“ erstellt wurden. Das Skript script-1.sh wird ausgeführt, und die Ausgabedatei wird entsprechend erstellt.

Lizenzierung

Verwenden Sie das <NS-LICENSE-CONFIG> Tag, um die NetScaler Pooled Licensing beim Starten der VPX-Instanz anzuwenden. Verwenden Sie das <LICENSE-COMMANDS> Tag innerhalb des <NS-LICENSE-CONFIG> Abschnitts, um die Befehle für die Pooled Licensing bereitzustellen. Diese Befehle müssen syntaktisch gültig sein.

Sie können die Details der Pooled Licensing, wie Lizenztyp, Kapazität und Lizenzserver, im <LICENSE-COMMANDS> Abschnitt mithilfe der Standardbefehle für die Pooled Licensing angeben. Weitere Informationen finden Sie unter NetScaler Pooled Capacity Licensing konfigurieren.

Nach dem Anwenden von <NS-LICENSE-CONFIG> startet die VPX mit der angeforderten Edition und die VPX versucht, die konfigurierten Lizenzen vom Lizenzserver auszuchecken.

• Wenn der Lizenz-Checkout erfolgreich ist, wird die konfigurierte Bandbreite auf die VPX angewendet.
• Wenn der Lizenz-Checkout fehlschlägt, wird die Lizenz innerhalb von ca. 10–12 Minuten nicht vom Lizenzserver abgerufen. Infolgedessen wird das System neu gestartet und wechselt in einen nicht lizenzierten Zustand.

Beispiel:

Im folgenden Beispiel startet die VPX nach dem Anwenden von <NS-LICENSE-CONFIG> beim Booten mit der Premium Edition, und die VPX versucht, die konfigurierten Lizenzen vom Lizenzserver (10.102.38.214) auszuchecken.

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration von hier kopieren:

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

Wie in der folgenden Abbildung gezeigt, können Sie den Befehl „show license server“ ausführen und überprüfen, ob der Lizenzserver (10.102.38.214) zur VPX hinzugefügt wurde.

Bootstrapping

Verwenden Sie das Tag <NS-BOOTSTRAP>, um die benutzerdefinierten Bootstrapping-Informationen bereitzustellen. Sie können die Tags <SKIP-DEFAULT-BOOTSTRAP> und <NEW-BOOTSTRAP-SEQUENCE> innerhalb des Abschnitts <NS-BOOTSTRAP> verwenden. Dieser Abschnitt informiert die NetScaler Appliance, ob das Standard-Bootstrapping vermieden werden soll oder nicht. Wenn das Standard-Bootstrapping vermieden wird, bietet Ihnen dieser Abschnitt die Möglichkeit, eine neue Bootstrapping-Sequenz bereitzustellen.

Standard-Bootstrap-Konfiguration

Die Standard-Bootstrap-Konfiguration in der NetScaler Appliance folgt diesen Schnittstellenzuweisungen:

• Eth0 – Managementschnittstelle mit einer bestimmten NSIP-Adresse.
• Eth1 – Client-seitige Schnittstelle mit einer bestimmten VIP-Adresse.
• Eth2 – Server-seitige Schnittstelle mit einer bestimmten SNIP-Adresse.

Bootstrap-Konfiguration anpassen

Sie können die Standard-Bootstrap-Sequenz überspringen und eine neue Bootstrap-Sequenz für die NetScaler VPX-Instanz bereitstellen. Verwenden Sie das Tag <NS-BOOTSTRAP>, um die benutzerdefinierten Bootstrapping-Informationen bereitzustellen. Sie können beispielsweise das Standard-Bootstrapping ändern, bei dem die Managementschnittstelle (NSIP), die Client-seitige Schnittstelle (VIP) und die Server-seitige Schnittstelle (SNIP) immer in einer bestimmten Reihenfolge bereitgestellt werden.

Die folgende Tabelle zeigt das Bootstrapping-Verhalten mit den verschiedenen zulässigen Werten für die Tags <SKIP-DEFAULT-BOOTSTRAP> und <NEW-BOOTSTRAP-SEQUENCE>.

Sie können die Bootstrap-Konfiguration mit den folgenden drei Methoden anpassen:

• Nur die Schnittstellendetails angeben
• Die Schnittstellendetails zusammen mit IP-Adressen und Subnetzmaske angeben
• Bootstrap-bezogene Befehle im Abschnitt <NS-CONFIG> angeben

Methode 1: Benutzerdefiniertes Bootstrapping durch Angabe nur der Schnittstellendetails

Sie geben die Management-, Client-seitigen und Server-seitigen Schnittstellen an, aber nicht deren IP-Adressen und Subnetzmasken. Die IP-Adressen und Subnetzmasken werden durch Abfragen der Cloud-Infrastruktur ausgefüllt.

Benutzerdefiniertes Bootstrap-Beispiel für AWS

Sie stellen die benutzerdefinierte Bootstrap-Sequenz wie im folgenden Beispiel gezeigt bereit. Weitere Informationen finden Sie unter Bereitstellen von Preboot-Benutzerdaten in einer Cloud-Instanz. Die Eth1-Schnittstelle wird als Verwaltungsschnittstelle (NSIP), die Eth0-Schnittstelle als Client-Schnittstelle (VIP) und die Eth2-Schnittstelle als Server-Schnittstelle (SNIP) zugewiesen. Der <NS-BOOTSTRAP>-Abschnitt enthält nur die Schnittstellendetails und nicht die Details der IP-Adressen und Subnetzmasken.

Nachdem die VM-Instanz erstellt wurde, können Sie im AWS-Portal die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:

1. Navigieren Sie zu AWS Portal > EC2-Instanzen, und wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
2. Auf der Registerkarte Beschreibung können Sie die Eigenschaften jeder Netzwerkschnittstelle wie in den folgenden Abbildungen gezeigt überprüfen.

Sie können den Befehl show nsip in der ADC CLI ausführen und die Netzwerkschnittstellen überprüfen, die während des ersten Starts der ADC-Appliance auf die NetScaler VPX-Instanz angewendet wurden.

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Sie stellen die benutzerdefinierte Bootstrap-Sequenz wie im folgenden Beispiel gezeigt bereit. Weitere Informationen finden Sie unter Bereitstellen von Preboot-Benutzerdaten in einer Cloud-Instanz. Die Eth2-Schnittstelle wird als Verwaltungsschnittstelle (NSIP), die Eth1-Schnittstelle als Client-Schnittstelle (VIP) und die Eth0-Schnittstelle als Server-Schnittstelle (SNIP) zugewiesen. Der <NS-BOOTSTRAP>-Abschnitt enthält nur die Schnittstellendetails und nicht die Details der IP-Adressen und Subnetzmasken.

Sie können sehen, dass die NetScaler VPX-Instanz mit drei Netzwerkschnittstellen erstellt wird. Navigieren Sie zu Azure-Portal > VM-Instanz > Netzwerk, und überprüfen Sie die Netzwerkeigenschaften der drei NICs wie in den folgenden Abbildungen gezeigt.

Sie können den Befehl „show nsip“ in der ADC-CLI ausführen und überprüfen, ob die neue Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> angegeben ist, angewendet wurde. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Benutzerdefinierte Bootstrap-Beispiele für GCP

Sie stellen die benutzerdefinierte Bootstrap-Sequenz wie im folgenden Beispiel gezeigt bereit. Weitere Informationen finden Sie unter Bereitstellen von Preboot-Benutzerdaten in der Cloud-Instanz. Die Eth1-Schnittstelle wird als Managementschnittstelle (NSIP), die Eth0-Schnittstelle als Clientschnittstelle (VIP) und die Eth2-Schnittstelle als Serverschnittstelle (SNIP) zugewiesen. Der Abschnitt <NS-BOOTSTRAP> enthält nur die Schnittstellendetails und nicht die Details der IP-Adressen und Subnetzmasken.

Nachdem die VM-Instanz im GCP-Portal erstellt wurde, können Sie die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:

1. Wählen Sie die Instanz aus, die Sie durch Angabe der benutzerdefinierten Bootstrap-Informationen erstellt haben.
2. Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die NIC-Details wie folgt:

Sie können den Befehl show nsip in der ADC-CLI ausführen und die Netzwerkschnittstellen überprüfen, die während des ersten Starts der ADC-Appliance auf die NetScaler VPX-Instanz angewendet wurden.

Methode 2: Benutzerdefinierter Bootstrap durch Angabe der Schnittstellen, IP-Adressen und Subnetzmasken

Sie geben die Management-, clientseitigen und serverseitigen Schnittstellen zusammen mit ihren IP-Adressen und der Subnetzmaske an.

Benutzerdefinierte Bootstrap-Beispiele für AWS

Im folgenden Beispiel überspringen Sie den Standard-Bootstrap und führen eine neue Bootstrap-Sequenz für die NetScaler-Appliance aus. Für die neue Bootstrap-Sequenz geben Sie die folgenden Details an:

• Managementschnittstelle: Schnittstelle - Eth1, NSIP - 172.31.52.88 und Subnetzmaske - 255.255.240.0
• Clientseitige Schnittstelle: Schnittstelle - Eth0, VIP - 172.31.5.155 und Subnetzmaske - 255.255.240.0.
• Serverseitige Schnittstelle: Schnittstelle - Eth2, SNIP - 172.31.76.177 und Subnetzmaske - 255.255.240.0.

Sie können den Befehl show nsip in der ADC-CLI ausführen und überprüfen, ob die neue Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> angegeben ist, angewendet wurde. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Im folgenden Beispiel wird eine neue Bootstrap-Sequenz für ADC erwähnt und der Standard-Bootstrap übersprungen. Sie geben die Schnittstellendetails zusammen mit den IP-Adressen und Subnetzmasken wie folgt an:

• Managementschnittstelle (eth2), NSIP (172.27.2.53) und Subnetzmaske (255.255.255.0)
• Clientseitige Schnittstelle (eth1), VIP (172.27.1.53) und Subnetzmaske (255.255.255.0)
• Serverseitige Schnittstelle (eth0), SNIP (172.27.0.53) und Subnetzmaske (255.255.255.0)

Sie können sehen, dass die NetScaler VPX-Instanz mit drei Netzwerkschnittstellen erstellt wird. Navigieren Sie zu Azure-Portal > VM-Instanz > Netzwerk, und überprüfen Sie die Netzwerkeigenschaften der drei NICs, wie in den folgenden Abbildungen gezeigt.

Sie können den Befehl show nsip in der ADC-CLI ausführen und überprüfen, ob die neue Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> angegeben ist, angewendet wurde. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Beispiel für benutzerdefinierten Bootstrap für GCP

Im folgenden Beispiel wird eine neue Bootstrap-Sequenz für ADC erwähnt und der Standard-Bootstrap übersprungen. Sie geben die Schnittstellendetails zusammen mit den IP-Adressen und Subnetzmasken wie folgt an:

• Verwaltungsschnittstelle (eth2), NSIP (10.128.4.31) und Subnetzmaske (255.255.255.0)
• Client-seitige Schnittstelle (eth1), VIP (10.128.0.43) und Subnetzmaske (255.255.255.0)
• Server-seitige Schnittstelle (eth0), SNIP (10.160.0.75) und Subnetzmaske (255.255.255.0)

Nachdem die VM-Instanz im GCP-Portal mit dem benutzerdefinierten Bootstrap erstellt wurde, können Sie die Netzwerkschnittstelleneigenschaften wie folgt überprüfen:

1. Wählen Sie die Instanz aus, die Sie durch Angabe der benutzerdefinierten Bootstrap-Informationen erstellt haben.
2. Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die NIC-Details wie folgt.

Sie können den Befehl show nsip in der ADC-CLI ausführen und überprüfen, ob die neue Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> angegeben ist, angewendet wurde. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Methode 3: Benutzerdefinierter Bootstrap durch Bereitstellung von Bootstrap-bezogenen Befehlen im Abschnitt <NS-CONFIG>

Sie können die Bootstrap-bezogenen Befehle im Abschnitt <NS-CONFIG> angeben. Im Abschnitt <NS-BOOTSTRAP> müssen Sie <NEW-BOOTSTRAP-SEQUENCE> als „No“ angeben, um die Bootstrapping-Befehle im Abschnitt <NS-CONFIG> auszuführen. Sie müssen auch die Befehle zur Zuweisung von NSIP, Standardroute und NSVLAN angeben. Geben Sie außerdem die für die von Ihnen verwendete Cloud relevanten Befehle an.

Bevor Sie einen benutzerdefinierten Bootstrap bereitstellen, stellen Sie sicher, dass Ihre Cloud-Infrastruktur eine bestimmte Schnittstellenkonfiguration unterstützt.

Beispiel für benutzerdefinierten Bootstrap für AWS

In diesem Beispiel werden Bootstrap-bezogene Befehle im Abschnitt <NS-CONFIG> bereitgestellt. Der Abschnitt <NS-BOOTSTRAP> zeigt an, dass das Standard-Bootstrapping übersprungen wird und die im Abschnitt <NS-CONFIG> bereitgestellten benutzerdefinierten Bootstrap-Informationen ausgeführt werden. Sie müssen auch die Befehle zum Erstellen von NSIP, Hinzufügen einer Standardroute und Hinzufügen von NSVLAN angeben.

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration hier kopieren:

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

Nachdem die VM-Instanz erstellt wurde, können Sie im AWS-Portal die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:

1. Navigieren Sie zum AWS-Portal > EC2-Instanzen und wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
2. Auf der Registerkarte Beschreibung können Sie die Eigenschaften jeder Netzwerkschnittstelle überprüfen, wie in den folgenden Abbildungen gezeigt.

Sie können den Befehl show nsip in der ADC CLI ausführen und die auf die NetScaler VPX-Instanz angewendeten Netzwerkschnittstellen während des ersten Starts der ADC-Appliance überprüfen.

Benutzerdefiniertes Bootstrap-Beispiel für Azure

In diesem Beispiel werden Bootstrap-bezogene Befehle im Abschnitt <NS-CONFIG> bereitgestellt. Der Abschnitt <NS-BOOTSTRAP> zeigt an, dass das Standard-Bootstrapping übersprungen wird und die im Abschnitt <NS-CONFIG> bereitgestellten benutzerdefinierten Bootstrap-Informationen ausgeführt werden.

Hinweis:

Für die Azure Cloud sind Instance Metadata Server (IMDS) und DNS-Server nur über die primäre Schnittstelle (Eth0) zugänglich. Wenn die Eth0-Schnittstelle daher nicht als Verwaltungsschnittstelle (NSIP) verwendet wird, muss die Eth0-Schnittstelle zumindest als SNIP konfiguriert werden, damit der IMDS- oder DNS-Zugriff funktioniert. Die Route zum IMDS-Endpunkt (169.254.169.254) und zum DNS-Endpunkt (168.63.129.16) über das Gateway von Eth0 muss ebenfalls hinzugefügt werden.

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

Sie können sehen, dass die NetScaler VPX-Instanz mit drei Netzwerkschnittstellen erstellt wird. Navigieren Sie zum Azure-Portal > VM-Instanz > Netzwerk, und überprüfen Sie die Netzwerkeigenschaften der drei NICs, wie in den folgenden Abbildungen gezeigt.

Sie können den Befehl show nsip in der ADC CLI ausführen und überprüfen, ob die neue Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> angegeben ist, angewendet wird. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Benutzerdefiniertes Bootstrap-Beispiel für GCP

In diesem Beispiel werden Bootstrap-bezogene Befehle im Abschnitt <NS-CONFIG> bereitgestellt. Der Abschnitt <NS-BOOTSTRAP> zeigt an, dass das Standard-Bootstrapping übersprungen und die benutzerdefinierten Bootstrap-Informationen, die im Abschnitt <NS-CONFIG> bereitgestellt werden, angewendet werden.

GCP-Methode3(/de-de/vpx/media/gcp-method3.png)

Sie können die im vorhergehenden Screenshot gezeigte Konfiguration von hier kopieren:

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

Nachdem die VM-Instanz im GCP-Portal mit dem benutzerdefinierten Bootstrap erstellt wurde, können Sie die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:

1. Wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
2. Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die NIC-Details, wie in der Abbildung gezeigt.

NIC-Details, wie in der GCP-Konsole gezeigt(/de-de/vpx/media/gcp-nic-method3.png)

Sie können den Befehl show nsip in der ADC-CLI ausführen und überprüfen, ob die Konfigurationen, die im vorhergehenden Abschnitt <NS-CONFIG> bereitgestellt wurden, beim ersten Start der ADC-Appliance angewendet werden.

NSIP-Ausgabe anzeigen(/de-de/vpx/media/gcp-show-nsip-method3.png)

Auswirkungen des Anfügens und Trennens von NICs in AWS und Azure

AWS und Azure bieten die Möglichkeit, eine Netzwerkschnittstelle an eine Instanz anzuhängen und eine Netzwerkschnittstelle von einer Instanz zu trennen. Das Anfügen oder Trennen von Schnittstellen kann die Schnittstellenpositionen ändern. Daher empfiehlt Citrix, Schnittstellen nicht von der NetScaler VPX-Instanz zu trennen. Wenn Sie eine Schnittstelle trennen oder anfügen, während benutzerdefiniertes Bootstrapping konfiguriert ist, weist die NetScaler VPX-Instanz die primäre IP der neu verfügbaren Schnittstelle an der Position der Verwaltungsschnittstelle als NSIP neu zu. Wenn nach der von Ihnen getrennten Schnittstelle keine weiteren Schnittstellen verfügbar sind, wird die erste Schnittstelle zur Verwaltungsschnittstelle für die NetScaler VPX-Instanz gemacht.

Beispielsweise wird eine NetScaler VPX-Instanz mit 3 Schnittstellen gestartet: Eth0 (SNIP), Eth1 (NSIP) und Eth2 (VIP). Wenn Sie die Eth1-Schnittstelle von der Instanz trennen, die eine Verwaltungsschnittstelle ist, konfiguriert ADC die nächste verfügbare Schnittstelle (Eth2) als Verwaltungsschnittstelle. Dadurch ist die NetScaler VPX-Instanz weiterhin über die primäre IP der Eth2-Schnittstelle zugänglich. Wenn Eth2 ebenfalls nicht verfügbar ist, wird die verbleibende Schnittstelle (Eth0) zur Verwaltungsschnittstelle gemacht. Daher bleibt der Zugriff auf die NetScaler VPX-Instanz bestehen.

Betrachten wir eine andere Zuweisung von Schnittstellen wie folgt: Eth0 (SNIP), Eth1 (VIP) und Eth2 (NSIP). Wenn Sie Eth2 (NSIP) trennen, da nach Eth2 keine neue Schnittstelle verfügbar ist, wird die erste Schnittstelle (Eth0) zur Verwaltungsschnittstelle gemacht.