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 bestimmte 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 Start an.

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

Sie können Preboot-Benutzerdaten für die Cloud-Instanz im XML-Format bereitstellen. Verschiedene Clouds haben unterschiedliche Schnittstellen für die 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 jedem Schritt 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.

Preboot-Benutzerdaten über die AWS CLI bereitstellen

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 zu Ausführen von Instanzen.

Weitere Informationen finden Sie in der AWS-Dokumentation zu Verwenden von Instanz-Benutzerdaten

Preboot-Benutzerdaten über die Azure-Konsole bereitstellen

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.

Preboot-Benutzerdaten über die Azure CLI bereitstellen

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

Preboot-Benutzerdaten über die GCP-Konsole bereitstellen

Wenn Sie eine NetScaler VPX-Instanz über die GCP-Konsole bereitstellen, füllen Sie die Instanzeigenschaften 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.

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

GCP-Konsole(/de-de/vpx/media/preboot-gcp-console.png)

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 der gespeichert ist.

Weitere Informationen finden Sie in der 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.
• Konfiguration der Pool-Lizenzierung, dargestellt mit dem <NS-LICENSE-CONFIG> Tag.

Sie können die vorangehenden vier Abschnitte in beliebiger Reihenfolge innerhalb der ADC-Preboot-Konfiguration bereitstellen. Stellen Sie sicher, dass Sie die in den folgenden Abschnitten gezeigte Formatierung strikt einhalten, wenn Sie die Preboot-Benutzerdaten bereitstellen.

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 Format ü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 Format ü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 startet mit der im <NS-CONFIG> Abschnitt angewendeten Konfiguration, wie in den folgenden Abbildungen gezeigt.

Benutzerskripte

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

Sie können viele Skripte innerhalb des <NS-SCRIPTS>-Tags einfügen. 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 Hochfahren 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 Zielspeicherort gespeichert, den Sie angeben.

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 wird mit dem Befehl „sh /var/script-1.sh“ ausgeführt, nachdem die Paket-Engine hochgefahren ist.

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 in der vorhergehenden Abbildung 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>

        <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, dass 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 Pool-Lizenzierung bereitzustellen. Diese Befehle müssen syntaktisch gültig sein.

Sie können die Details der Pool-Lizenzierung, wie z. B. Lizenztyp, Kapazität und Lizenzserver, im <LICENSE-COMMANDS>-Abschnitt unter Verwendung der Standardbefehle für die Pool-Lizenzierung 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 abzurufen.

• Wenn der Lizenzabruf erfolgreich ist, wird die konfigurierte Bandbreite auf die VPX angewendet.
• Wenn der Lizenzabruf fehlschlägt, wird die Lizenz innerhalb von etwa 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> mit der Premium Edition, und die VPX versucht, die konfigurierten Lizenzen vom Lizenzserver (10.102.38.214) abzurufen.

Lizenzbefehle(/de-de/vpx/media/license-commands.png)

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.

Lizenzserver anzeigen(/de-de/vpx/media/show-license-server.png)

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 darüber, ob der Standard-Bootstrap vermieden werden soll oder nicht. Wenn das Standard-Bootstrapping vermieden wird, bietet dieser Abschnitt Ihnen 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 Werten, die für die Tags <SKIP-DEFAULT-BOOTSTRAP> und <NEW-BOOTSTRAP-SEQUENCE> zulässig sind.

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

Methode 1: Benutzerdefiniertes Bootstrapping durch Angabe nur der Schnittstellendetails

Sie geben die Management-, Client-seitigen und Server-seitigen Schnittstellen an, jedoch 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 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 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 Clientschnittstelle (VIP) und die Eth0-Schnittstelle als Serverschnittstelle (SNIP) zugewiesen. Der Abschnitt <NS-BOOTSTRAP> 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 einer Cloud-Instanz. Die Eth1-Schnittstelle wird als Verwaltungsschnittstelle (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 Bereitstellung 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-, Client-seitigen und Server-seitigen Schnittstellen zusammen mit ihren IP-Adressen und der Subnetzmaske an.

Beispiele für benutzerdefinierten Bootstrap 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
• Client-seitige Schnittstelle: Schnittstelle – Eth0, VIP – 172.31.5.155 und Subnetzmaske – 255.255.240.0.
• Server-seitige 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 im Abschnitt <NS-BOOTSTRAP> angegebene neue Bootstrap-Sequenz angewendet wird. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Beispiel für benutzerdefinierten Bootstrap 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)
• Client-seitige Schnittstelle (eth1), VIP (172.27.1.53) und Subnetzmaske (255.255.255.0)
• Server-seitige 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 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

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)
• Clientseitige Schnittstelle (eth1), VIP (10.128.0.43) und Subnetzmaske (255.255.255.0)
• Serverseitige 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 Netzwerkschnittstelleneigenschaften 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> bereitstellen. Im Abschnitt <NS-BOOTSTRAP> müssen Sie <NEW-BOOTSTRAP-SEQUENCE> als „No“ angeben, um die Bootstrap-Befehle im Abschnitt <NS-CONFIG> auszuführen. Sie müssen auch die Befehle zur Zuweisung von NSIP, Standardroute und NSVLAN bereitstellen. Zusätzlich müssen Sie die für die von Ihnen verwendete Cloud relevanten Befehle bereitstellen.

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

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 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 überprüfen, wie in den folgenden Abbildungen gezeigt.

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.

Beispiel für benutzerdefinierten Bootstrap 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 der 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 im Abschnitt <NS-BOOTSTRAP> angegebene neue Bootstrap-Sequenz angewendet wird. Sie können den Befehl „show route“ ausführen, um die Subnetzmaske zu überprüfen.

Beispiel für benutzerdefinierten Bootstrap 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 wird und die im Abschnitt <NS-CONFIG> bereitgestellten benutzerdefinierten Bootstrap-Informationen angewendet werden.

Sie können die in der vorhergehenden Abbildung gezeigte Konfiguration 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.

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

Auswirkungen des Anhängens 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 Anhängen 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 anhängen, 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.

Zum Beispiel 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 wird weiterhin über die primäre IP der Eth2-Schnittstelle auf die NetScaler VPX-Instanz zugegriffen. Wenn Eth2 ebenfalls nicht verfügbar ist, wird die verbleibende Schnittstelle (Eth0) zur Verwaltungsschnittstelle. 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, wird, da nach Eth2 keine neue Schnittstelle verfügbar ist, die erste Schnittstelle (Eth0) zur Verwaltungsschnittstelle.