NetScaler VPX

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

October 17, 2024

Beitrag von:

C C

Sie können die NetScaler VPX-Konfigurationen beim ersten Start der NetScaler-Appliance in einer Cloud-Umgebung anwenden. Diese Phase wird in diesem Dokument als Preboot-Phase behandelt. Daher wird in bestimmten Fällen wie der ADC-gepoolten Lizenzierung eine bestimmte VPX-Instanz in viel geringerer Zeit aufgebracht. Diese Funktion ist in Microsoft Azure, Google Cloud-Plattform 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. Mit den Benutzerdaten können Sie allgemeine automatisierte Konfigurationsaufgaben ausführen, das Startverhalten von Instanzen anpassen und Skripts ausführen, nachdem die Instanz gestartet wurde. Beim ersten Start führt die NetScaler VPX-Instanz die folgenden Aufgaben aus:

Liest die Benutzerdaten.
Interpretiert die in Benutzerdaten bereitgestellte Konfiguration.
Wendet die neu hinzugefügte Konfiguration beim Booten an.

So stellen Sie Preboot-Benutzerdaten in Cloud-Instanz zur Verfügung

Sie können der Cloud-Instanz Preboot-Benutzerdaten im XML-Format zur Verfügung stellen. Verschiedene Clouds haben unterschiedliche Schnittstellen zur Bereitstellung von Benutzerdaten.

Bereitstellung von Preboot-Benutzerdaten über die AWS-Konsole

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

Ausführliche Anweisungen zu den einzelnen Schritten finden Sie unter Stellen Sie mithilfe der AWS-Webkonsole eine NetScaler VPX-Instanz auf AWS bereit. Weitere Informationen finden Sie in der AWS-Dokumentation zum Starten einer Instanz.

Benutzerdaten der AWS-Konsole

Hinweis:

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

Bereitstellung von Preboot-Benutzerdaten mit AWS CLI

Geben Sie den folgenden Befehl in die 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 Running Instances.

Weitere Informationen finden Sie in der AWS-Dokumentation zur Verwendung von Instanz-Benutzerdaten

Stellen Sie Preboot-Benutzerdaten mit der Azure-Konsole bereit

Wenn Sie eine NetScaler VPX-Instanz mit der Azure-Konsole bereitstellen, navigieren Sie zu Virtuelle Maschine erstellen > Erweitert . Geben Sie im Feld Benutzerdefinierte Daten eine Preboot-Benutzerdatenkonfiguration an.

Azure-Konsole

Bereitstellen von Preboot-Benutzerdaten mit der Azure CLI

Geben Sie den folgenden Befehl in die 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.

Stellen Sie Preboot-Benutzerdaten mit der GCP-Konsole bereit

Wenn Sie eine NetScaler VPX-Instanz mit der GCP-Konsole bereitstellen, füllen Sie die Eigenschaften der Instanz aus. Erweitern Sie Management, Sicherheit, Datenträger, Netzwerke, Einzelmandanten. Navigieren Sie zur Registerkarte Verwaltung. Geben Sie im Abschnitt Automatisierung die Konfiguration der Preboot-Benutzerdaten im Feld Startskript ein.

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

GCP-Konsole

Stellen Sie Preboot-Benutzerdaten mit der gcloud CLI bereit

Geben Sie den folgenden Befehl in die 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 im .

Weitere Informationen finden Sie in der gcloud CLI-Dokumentation

Preboot-Benutzerdatenformat

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

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

Sie können die vorangegangenen vier Abschnitte in beliebiger Reihenfolge innerhalb der ADC-Preboot-Konfiguration angeben. Stellen Sie sicher, dass Sie die in den folgenden Abschnitten gezeigten Formatierung genau befolgen, während Sie die Preboot-Benutzerdaten bereitstellen.

Hinweis:

Die gesamte Preboot-Benutzerdatenkonfiguration muss in das <NS-PRE-BOOT-CONFIG> Tag eingeschlossen sein, 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 im Preboot-Stadium auf die VPX-Instanz angewendet werden müssen.

Hinweis:

Der <NS-CONFIG> Abschnitt muss über gültige ADC CLI-Befehle verfügen. Die CLIs werden nicht auf die syntaktischen Fehler oder das Format überprüft.

NetScaler-Konfigurationen

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

Hinweis:

Der <NS-CONFIG> Abschnitt muss über gültige ADC CLI-Befehle verfügen. Die CLIs werden nicht auf die syntaktischen Fehler oder das Format überprüft.

Beispiel

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

ADC-Konfigurationen

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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 enthält die im <NS-CONFIG> Abschnitt angewendete Konfiguration, wie in den folgenden Abbildungen gezeigt.

Überprüfen Sie VLAN-Konfigurationen

Überprüfen der Serverkonfigurationen

Benutzer-Skripts

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 Skripts in das <NS-SCRIPTS> Tag aufnehmen. Jedes Skript muss in das <SCRIPT> Tag aufgenommen sein. Jeder <SCRIPT> Abschnitt entspricht einem Skript und enthält alle Details des Skripts unter Verwendung der folgenden Sub-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 angegebenen 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 bereitgestellten Befehle in “/nsconfig/nsafter.sh” gespeichert, und die Befehle werden ausgeführt, nachdem die Paket-Engine im Rahmen der Ausführung “nsafter.sh” hochgefahren ist.
- Wenn Sie den <SCRIPT-NS-BOOTUP> Abschnitt nicht verwenden, wird die Skriptdatei an dem 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 “script-1.sh” -Skript wird im Verzeichnis “/var” gespeichert. Das Skript wird mit dem angegebenen Inhalt gefüllt und nach dem Hochfahren der Paket-Engine mit dem Befehl “sh /var/script-1.sh” ausgeführt.

Script1

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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 “script-1.sh” -Skript im Verzeichnis “/var/” gespeichert ist. Das “Script-1.sh” -Skript wird ausgeführt und die Ausgabedatei wird entsprechend erstellt.

script1-Ausgang

Beispiel 2:

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

Das erste Script wird als “script-1.sh” im Verzeichnis “/var” gespeichert. Das Skript wird mit dem angegebenen Inhalt gefüllt und nach dem Hochfahren der Paket-Engine mit dem Befehl “sh /var/script-1.sh” ausgeführt.
Das zweite Script wird als “file-2.txt” im Verzeichnis “/var” gespeichert. Diese Datei wird mit dem angegebenen Inhalt gefüllt. Es wird jedoch nicht ausgeführt, da der Bootup-Ausführungsbefehl nicht bereitgestellt <SCRIPT-NS-BOOTUP> wird.

script2

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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. Die Script-1.sh wird ausgeführt und die Ausgabedatei wird entsprechend erstellt.

script2-Ausgang

Lizenzierung

Verwenden Sie das <NS-LICENSE-CONFIG> Tag, um die gepoolte NetScaler-Lizenzierung anzuwenden, während Sie die VPX-Instanz hochfahren. Verwenden Sie das <LICENSE-COMMANDS> Tag im <NS-LICENSE-CONFIG> Abschnitt, um die gepoolten Lizenzbefehle bereitzustellen. Diese Befehle müssen syntaktisch gültig sein.

Sie können die gepoolten Lizenzierungsdetails wie Lizenztyp, Kapazität und Lizenzserver im <LICENSE-COMMANDS> Abschnitt mit den standardmäßigen gepoolten Lizenzbefehlen angeben. Weitere Informationen finden Sie unter Konfigurieren der Lizenzierung der gepoolten Kapazität von NetScaler.

Nach dem <NS-LICENSE-CONFIG>Anwenden des wird der VPX beim Booten mit der angeforderten Edition geliefert, und VPX versucht, die konfigurierten Lizenzen vom Lizenzserver auszuchecken.

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

Beispiel

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

Lizenzbefehle

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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) zum VPX hinzugefügt wurde.

Lizenzserver anzeigen

Bootstrapping

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

Standardmäßige Bootstrap-Konfiguration

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

Eth0 - Verwaltungsschnittstelle mit einer bestimmten NSIP-Adresse.
Eth1 - Clientorientierte Schnittstelle mit einer bestimmten VIP-Adresse.
Eth2 - Server-Schnittstelle mit einer bestimmten SNIP-Adresse.

Anpassen der Bootstrap-Konfiguration

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

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

`SKIP-DEFAULT-BOOTSTRAP`	`NEW-BOOTSTRAP-SEQUENCE`	Bootstrap-Verhalten
JA	JA	Das standardmäßige Bootstrapping-Verhalten wird übersprungen, und eine neue benutzerdefinierte Bootstrap-Sequenz im `<NS-BOOTSTRAP>` Abschnitt wird ausgeführt.
JA	NEIN	Das standardmäßige Bootstrapping-Verhalten wird übersprungen. Die im `<NS-CONFIG>` Abschnitt bereitgestellten Bootstrap-Befehle werden ausgeführt.

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

Geben Sie nur die Schnittstellendetails
Geben Sie die Schnittstellendetails zusammen mit IP-Adressen und Subnetzmaske an
Geben Sie Bootstrap-bezogene Befehle im <NS-CONFIG> Abschnitt

Methode 1: Benutzerdefinierter Bootstrap durch Angabe nur der Schnittstellendetails

Sie geben die verwaltungs-, clientorientierten und serverorientierten Schnittstellen an, nicht jedoch 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 geben die benutzerdefinierte Bootstrap-Sequenz an, wie im folgenden Beispiel gezeigt. Weitere Informationen finden Sie unter So stellen Sie Preboot-Benutzerdaten in Cloud-Instanzbereit. Eth1-Schnittstelle wird als Verwaltungsschnittstelle (NSIP), Eth0-Schnittstelle als Client-Schnittstelle (VIP) und Eth2-Schnittstelle als Serverschnittstelle (SNIP) zugewiesen. Der <NS-BOOTSTRAP> Abschnitt enthält nur die Schnittstellendetails und nicht die Details von IP-Adressen und Subnetzmasken.

Benutzerdefinierte Bootstrap-Methode1 von AWS

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

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

AWS eth1

AWS eth0

AWS eth2

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

AWS zeigt nsip method1

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Benutzerdefinierte Azure Bootstrap-Methode1

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 Netzwerkkarten wie in den folgenden Abbildungen gezeigt.

Azure-Servermethode1

Azure-Client-Methode1

Azure-Verwaltungsmethode1

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

Azure show nsip Befehl

Benutzerdefinierte Bootstrap-Beispiele für GCP

GCP-Methode1

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 erstellt haben, indem Sie die benutzerdefinierten Bootstrap-Informationen angeben.
Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die NIC-Details wie folgt:

GCP-Methode1

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

Gcp-show-nsip-method1

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

Sie geben die verwaltungs-, clientorientierten und serverorientierten 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 folgende Details an:

Verwaltungsschnittstelle: Interface - Eth1, NSIP - 172.31.52.88 und Subnetzmaske - 255.255.240.0
Clientorientierte Schnittstelle: Schnittstelle - Eth0, VIP - 172.31.5.155 und Subnetzmaske - 255.255.240.0.
Server-zugewandte Schnittstelle: Schnittstelle - Eth2, SNIP - 172.31.76.177 und Subnetzmaske - 255.255.240.0.

Benutzerdefinierte Bootstrap-Methode2 von AWS

AWS zeigt nsip method2

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:

Verwaltungsschnittstelle (eth2), NSIP (172.27.2.53) und Subnetzmaske (255.255.255.0)
Clientorientierte Schnittstelle (eth1), VIP (172.27.1.53) und Subnetzmaske (255.255.255.0)
Server-zugewandte Schnittstelle (eth0), SNIP (172.27.0.53) und Subnetzmaske (255.255.255.0)

Benutzerdefinierte Azure Bootstrap-Methode2

Methode der Azure-Verwaltungsschnittstellen2

Azure-Client-Schnittstellenmethode2

Methode der Azure-Serverschnittstellen2

Azure zeigt nsip method2

Benutzerdefiniertes Bootstrap-Beispiel für GCP

Verwaltungsschnittstelle (eth2), NSIP (10.128.4.31) und Subnetzmaske (255.255.255.0)
Clientorientierte Schnittstelle (eth1), VIP (10.128.0.43) und Subnetzmaske (255.255.255.0)
Server-zugewandte Schnittstelle (eth0), SNIP (10.160.0.75) und Subnetzmaske (255.255.255.0)

GCP-Methode2

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 erstellt haben, indem Sie die benutzerdefinierten Bootstrap-Informationen angeben.
Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die Netzwerkdetails wie folgt.

Details zur GCP-NIC

GCP show nsip Befehl

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

Sie können die Bootstrap-bezogenen Befehle im <NS-CONFIG> Abschnitt angeben. In <NS-BOOTSTRAP> diesem Abschnitt müssen Sie das <NEW-BOOTSTRAP-SEQUENCE> als “Nein” angeben, um die Bootstrapping-Befehle im <NS-CONFIG> Abschnitt auszuführen. Sie müssen auch die Befehle angeben, um NSIP, Standardroute und NSVLAN zuzuweisen. Geben Sie außerdem die Befehle ein, die für die von Ihnen verwendete Cloud relevant sind.

Stellen Sie vor der Bereitstellung eines benutzerdefinierten Bootstrap sicher, dass Ihre Cloud-Infrastruktur eine bestimmte Schnittstellenkonfiguration unterstützt.

Benutzerdefiniertes Bootstrap-Beispiel für AWS

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

AWS custom bootstrap method3

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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:

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

AWS eth1 method3

AWS eth0 method3

AWS eth2 method3

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

AWS show nsip method3

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Hinweis:

Für Azure Cloud sind Instance Metadata Server (IMDS) und DNS-Server nur über die primäre Schnittstelle (Eth0) zugänglich. Wenn die Eth0-Schnittstelle nicht als Verwaltungsschnittstelle (NSIP) verwendet wird, muss die Eth0-Schnittstelle daher zumindest als SNIP für IMDS- oder DNS-Zugriff auf die Arbeit konfiguriert werden. 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.

Benutzerdefinierte Azure Bootstrap-Methode3

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

Azure-Server-Schnittstelle

Azure-Clientschnittstelle

Azure-Verwaltungsschnittstelle

Azure show nsip method3

Benutzerdefiniertes Bootstrap-Beispiel für GCP

GCP-Methode3

Sie können die im vorherigen Screenshot gezeigte Konfiguration von hier aus 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:

Wählen Sie die Instanz aus, die Sie erstellt haben, indem Sie die benutzerdefinierten Bootstrap-Informationen angeben.
Navigieren Sie zu den Eigenschaften der Netzwerkschnittstelle und überprüfen Sie die Netzwerkdetails wie in der Abbildung gezeigt.

NIC-Details wie in der GCP-Konsole gezeigt

Sie können den show nsip Befehl in ADC CLIausführen und sicherstellen, dass die im vorherigen <NS-CONFIG> Abschnitt bereitgestellten Konfigurationen beim ersten Start der ADC-Appliance angewendet werden.

NSIP-Ausgabe anzeigen

Auswirkungen des Anhängen und Trennen von NICs in AWS und Azure

AWS und Azure bieten die Möglichkeit, eine Netzwerkschnittstelle an eine Instanz anzuschließen und eine Netzwerkschnittstelle von einer Instanz zu trennen. Das Anhängen oder Trennen von Schnittstellen kann die Positionen der Schnittstelle verändern. Daher empfiehlt Citrix, Schnittstellen nicht von der NetScaler VPX-Instanz zu trennen. Wenn Sie eine Schnittstelle trennen oder anhängen, wenn benutzerdefiniertes Bootstrapping konfiguriert ist, weist die NetScaler VPX-Instanz die primäre IP der neu verfügbaren Schnittstelle in der Position der Verwaltungsschnittstelle als NSIP 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 aufgebracht: Eth0 (SNIP), Eth1 (NSIP) und Eth2 (VIP). Wenn Sie die Eth1-Schnittstelle von der Instanz trennen, bei der es sich um eine Verwaltungsschnittstelle handelt, konfiguriert ADC die nächste verfügbare Schnittstelle (Eth2) als Verwaltungsschnittstelle. Dadurch wird auf die NetScaler VPX-Instanz weiterhin über die primäre IP der Eth2-Schnittstelle zugegriffen. Wenn Eth2 ebenfalls nicht verfügbar ist, wird die verbleibende Schnittstelle (Eth0) zur Verwaltungsschnittstelle gemacht. Daher besteht der Zugriff auf die NetScaler VPX-Instanz weiterhin.

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.

Die offizielle Version dieses Inhalts ist auf Englisch. Für den einfachen Einstieg wird Teil des Inhalts der Cloud Software Group Dokumentation maschinell übersetzt. Cloud Software Group hat keine Kontrolle über maschinell übersetzte Inhalte, die Fehler, Ungenauigkeiten oder eine ungeeignete Sprache enthalten können. Es wird keine Garantie, weder ausdrücklich noch stillschweigend, für die Genauigkeit, Zuverlässigkeit, Eignung oder Richtigkeit von Übersetzungen aus dem englischen Original in eine andere Sprache oder für die Konformität Ihres Cloud Software Group Produkts oder Ihres Diensts mit maschinell übersetzten Inhalten gegeben, und jegliche Garantie, die im Rahmen der anwendbaren Endbenutzer-Lizenzvereinbarung oder der Vertragsbedingungen oder einer anderen Vereinbarung mit Cloud Software Group gegeben wird, dass das Produkt oder den Dienst mit der Dokumentation übereinstimmt, gilt nicht in dem Umfang, in dem diese Dokumentation maschinell übersetzt wurde. Cloud Software Group kann nicht für Schäden oder Probleme verantwortlich gemacht werden, die durch die Verwendung maschinell übersetzter Inhalte entstehen können.

War dieser Artikel hilfreich?

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

October 17, 2024

Beitrag von:

C C

October 17, 2024

Beitrag von:

C C

In diesem Artikel

Was sind Benutzerdaten
So stellen Sie Preboot-Benutzerdaten in Cloud-Instanz zur Verfügung
Bereitstellung von Preboot-Benutzerdaten über die AWS-Konsole
Stellen Sie Preboot-Benutzerdaten mit der Azure-Konsole bereit
Stellen Sie Preboot-Benutzerdaten mit der GCP-Konsole bereit
Preboot-Benutzerdatenformat
NetScaler-Konfigurationen
Benutzer-Skripts
Lizenzierung
Bootstrapping
Methode 1: Benutzerdefinierter Bootstrap durch Angabe nur der Schnittstellendetails
Methode 2: Benutzerdefiniertes Bootstrap durch Angabe der Schnittstellen, IP-Adressen und Subnetzmasken
Methode 3: Benutzerdefiniertes Bootstrap durch Bereitstellung von Bootstrap-bezogenen Befehlen im <NS-CONFIG> Abschnitt
Auswirkungen des Anhängen und Trennen von NICs in AWS und Azure

War dieser Artikel hilfreich?

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

Was sind Benutzerdaten

So stellen Sie Preboot-Benutzerdaten in Cloud-Instanz zur Verfügung

Bereitstellung von Preboot-Benutzerdaten über die AWS-Konsole

Bereitstellung von Preboot-Benutzerdaten mit AWS CLI

Stellen Sie Preboot-Benutzerdaten mit der Azure-Konsole bereit

Bereitstellen von Preboot-Benutzerdaten mit der Azure CLI

Stellen Sie Preboot-Benutzerdaten mit der GCP-Konsole bereit

Stellen Sie Preboot-Benutzerdaten mit der gcloud CLI bereit

Preboot-Benutzerdatenformat

NetScaler-Konfigurationen

Benutzer-Skripts

Lizenzierung

Bootstrapping

Standardmäßige Bootstrap-Konfiguration

Anpassen der Bootstrap-Konfiguration

Methode 1: Benutzerdefinierter Bootstrap durch Angabe nur der Schnittstellendetails

Benutzerdefiniertes Bootstrap-Beispiel für AWS

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Benutzerdefinierte Bootstrap-Beispiele für GCP

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

Benutzerdefinierte Bootstrap-Beispiele für AWS

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Benutzerdefiniertes Bootstrap-Beispiel für GCP

Methode 3: Benutzerdefiniertes Bootstrap durch Bereitstellung von Bootstrap-bezogenen Befehlen im &lt;NS-CONFIG&gt; Abschnitt

Benutzerdefiniertes Bootstrap-Beispiel für AWS

Benutzerdefiniertes Bootstrap-Beispiel für Azure

Benutzerdefiniertes Bootstrap-Beispiel für GCP

Auswirkungen des Anhängen und Trennen von NICs in AWS und Azure

In diesem Artikel

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