Anwenden von NetScaler VPX-Konfigurationen beim ersten Start der NetScaler Appliance in der Cloud
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 während des Startvorgangs 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.
Bereitstellen von Preboot-Benutzerdaten über die AWS-Konsole
Wenn Sie eine NetScaler VPX-Instanz über die AWS-Konsole bereitstellen, navigieren Sie zu Instanzdetails konfigurieren > Erweiterte Details und geben Sie die Preboot-Benutzerdatenkonfiguration in das Feld Benutzerdaten ein.
Detaillierte Anweisungen zu den einzelnen Schritten finden Sie unter Bereitstellen einer NetScaler VPX-Instanz auf 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 mithilfe der 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
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 mithilfe der 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 mithilfe der 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 \
Beispiel:
az vm create --resource-group MyResourceGroup -name MyVm --image debian --custom-data MyCloudInitScript.txt
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.
Preboot-Benutzerdaten mithilfe der GCP-Konsole bereitstellen
Wenn Sie eine NetScaler VPX-Instanz über die GCP-Konsole bereitstellen, füllen Sie die Instanzeigenschaften aus. erweitern 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 mithilfe von 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
metadata-from-file – Liest den Wert oder die Benutzerdaten aus einer Datei, die unter <LOCAL_FILE_PATH> 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 die in den folgenden Abschnitten gezeigte Formatierung 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>
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>
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>
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 Skripte bereitzustellen, die in der NetScaler VPX-Instanz gespeichert und ausgeführt werden müssen.
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 wird, 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 angegebenen Befehle in „/nsconfig/nsafter.sh“ gespeichert und nach dem Start der Paket-Engine als Teil der Ausführung von „nsafter.sh“ 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>
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 der
<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. Sie 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 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>
Im folgenden Snapshot können Sie überprüfen, ob script-1.sh und file-2.txt im Verzeichnis „/var/“ erstellt wurden. Das Skript-1.sh wird ausgeführt, und die Ausgabedatei wird entsprechend erstellt.
Lizenzierung
Verwenden Sie den
<NS-LICENSE-CONFIG> Tag, um die NetScaler-Pool-Lizenzierung beim Starten der VPX-Instanz anzuwenden. Verwenden Sie den <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 Lizenztyp, Kapazität und Lizenzserver, im
<LICENSE-COMMANDS> Abschnitt mithilfe der Standardbefehle für die Pool-Lizenzierung angeben. Weitere Informationen finden Sie unter NetScaler-Pool-Kapazitätslizenzierung 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 das Auschecken der Lizenz erfolgreich ist, wird die konfigurierte Bandbreite auf die VPX angewendet.
-
Wenn das Auschecken der Lizenz 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 der VPX nach dem Anwenden von
<NS-LICENSE-CONFIG> beim Booten mit der Premium Edition, und der 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>
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) zum 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 darüber, 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>.
SKIP-DEFAULT-BOOTSTRAP |
NEW-BOOTSTRAP-SEQUENCE |
Bootstrap-Verhalten |
|---|---|---|
| JA | JA | Das standardmäßige Bootstrapping-Verhalten wird übersprungen, und eine neue benutzerdefinierte Bootstrap-Sequenz, die im Abschnitt <NS-BOOTSTRAP> bereitgestellt wird, wird ausgeführt. |
| JA | NEIN | Das standardmäßige Bootstrapping-Verhalten wird übersprungen. Die im Abschnitt <NS-CONFIG> bereitgestellten Bootstrap-Befehle werden ausgeführt. |
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 Bootstrap 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 gefü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:
-
Navigieren Sie zu AWS Portal > EC2-Instanzen, und wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
-
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.
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 der 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 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:
-
Wählen Sie die Instanz aus, die Sie durch Angabe der benutzerdefinierten Bootstrap-Informationen erstellt haben.
-
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-seitige und Server-seitige 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
-
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 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 Azure
Im folgenden Beispiel wird eine neue Bootstrap-Sequenz für ADC erwähnt und der Standard-Bootstrap wird ü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 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 wird ü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:
-
Wählen Sie die Instanz aus, die Sie durch Angabe der benutzerdefinierten Bootstrap-Informationen erstellt haben.
-
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 wird. 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 in der vorhergehenden Abbildung 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>
Nachdem die VM-Instanz erstellt wurde, können Sie im AWS-Portal die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:
-
Navigieren Sie zu AWS Portal > EC2-Instanzen, und wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
-
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 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 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>
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.
Sie können die in dem 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>
Nachdem die VM-Instanz im GCP-Portal mit dem benutzerdefinierten Bootstrap erstellt wurde, können Sie die Eigenschaften der Netzwerkschnittstelle wie folgt überprüfen:
-
Wählen Sie die Instanz aus, die Sie durch Bereitstellung der benutzerdefinierten Bootstrap-Informationen erstellt haben.
-
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 Konfigurationen, die im vorhergehenden Abschnitt <NS-CONFIG> bereitgestellt wurden, beim ersten Start der ADC-Appliance angewendet werden.
Auswirkungen des Anhängens und Entfernens 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 gemacht.
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 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.