NetScaler VPX

NetScaler VPX構成をクラウドでNetScalerアプライアンスの最初の起動時に適用する

October 17, 2024

寄稿者:

C C

NetScaler VPX構成は、クラウド環境でのNetScalerアプライアンスの最初の起動時に適用できます。このステージは、 このドキュメントでプレブートステージとして取り上げられています 。したがって、ADC プールライセンスなどの特定のケースでは、特定の VPX インスタンスがはるかに短時間で起動されます。この機能は、Microsoft Azure、Google Cloud Platform、および AWS クラウドで使用できます。

ユーザーデータとは何ですか

クラウド環境で VPX インスタンスをプロビジョニングする場合、ユーザーデータをインスタンスに渡すオプションがあります。ユーザーデータを使用すると、一般的な自動設定タスクの実行、インスタンスの起動動作のカスタマイズ、インスタンスの起動後にスクリプトを実行できます。最初の起動時に、NetScaler VPXインスタンスは次のタスクを実行します。

ユーザーデータを読み取ります。
ユーザーデータで提供される構成を解釈します。
新しく追加された構成をブート時に適用します。

クラウドインスタンスでプレブートユーザーデータを提供する方法

プレブートユーザーデータを XML 形式でクラウドインスタンスに提供できます。クラウドによって、ユーザーデータを提供するためのインターフェースが異なります。

AWS コンソールを使用してプレブートユーザーデータを提供する

AWSコンソールを使用してNetScaler VPXインスタンスをプロビジョニングする場合は、[ インスタンスの詳細の構成] > [詳細の詳細] に移動し、[ユーザーデータ] フィールドにプレブートユーザーデータ構成を指定します 。

各手順の詳細な手順については、「 AWS Web コンソールを使用して AWS に NetScaler VPX インスタンスをデプロイする」を参照してください。詳細については、AWS ドキュメントの「インスタンスの起動」を参照してください。

AWS コンソールのユーザーデータ

注

プリブートユーザーデータ機能のAWS IMDSv2専用モードは、NetScaler VPXリリース13.1.48.x以降のリリースでサポートされています。

AWS CLI を使用してプレブートユーザーデータを提供する

AWS CLI で次のコマンドを入力します。

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

詳細については、インスタンスの実行に関するAWS ドキュメントを参照してください。

詳細については、インスタンスユーザーデータの使用に関するAWS ドキュメントを参照してください。

Azure コンソールを使用してプリブートユーザーデータを提供する

Azureコンソールを使用してNetScaler VPXインスタンスをプロビジョニングする場合は、［ 仮想マシンの作成］>［詳細設定 ］タブに移動します。 [ カスタムデータ ] フィールドに、プリブートユーザーデータの構成を指定します。

Azure コンソール

Azure CLI を使用してプリブートユーザーデータを提供する

Azure CLI で次のコマンドを入力します。

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

例

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

カスタムデータまたはプリブート設定をファイルとして「—custom-data」パラメータに渡すことができます。この例では、ファイル名は MyCloudInitScript.txtです。

詳細については、 Azure CLI のドキュメントを参照してください。

GCP コンソールを使用してプレブートユーザーデータを提供する

GCP コンソールを使用してNetScaler VPXインスタンスをプロビジョニングする場合は、インスタンスのプロパティを入力します。 管理、セキュリティ、ディスク、ネットワーキング、単独テナンシを展開します。 [ 管理 ] タブに移動します。 [ 自動化 ] セクションで、[ スタートアップスクリプト ] フィールドにプリブートユーザーデータ設定を指定します。

GCP を使用して VPX インスタンスを作成する方法の詳細については、「 Google Cloud Platform に NetScaler VPX インスタンスをデプロイする」を参照してください。

GCP コンソール

gcloud CLI を使用してプレブートユーザーデータを提供する

GCP CLI で次のコマンドを入力します。

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

metadata-from-file -に格納されているファイルから値またはユーザーデータを読み取ります。 .

詳細については、 gcloud CLI ドキュメントを参照してください。

プレブートユーザーデータ形式

プレブートユーザーデータは XML 形式でクラウドインスタンスに提供する必要があります。起動時にクラウドインフラストラクチャを介して提供されるNetScaler プレブートユーザーデータは、次の4つのセクションで構成されます。

NetScaler構成は<NS-CONFIG>タグで表されます。
<NS-BOOTSTRAP>タグで表されるNetScalerをカスタムブートストラップします。
<NS-SCRIPTS>タグで表されるNetScalerにユーザースクリプトを保存する。
<NS-LICENSE-CONFIG>タグで表されるプールライセンス構成。

前の 4 つのセクションは、ADC のプレブート構成内で任意の順序で提供できます。プリブートユーザーデータを提供しながら、次のセクションに示す書式に厳密に従うようにしてください。プリブートユーザーデータを提供する際は、次のセクションに示すフォーマットに厳密に従ってください。

注

次の例に示すように、プレブートユーザーデータ構成全体を<NS-PRE-BOOT-CONFIG>タグで囲む必要があります。

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

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

<NS-CONFIG>タグを使用して、プレブート段階でVPXインスタンスに適用する必要がある特定のNetScaler VPX構成を指定します。

注

<NS-CONFIG>セクションには、有効な ADC CLI コマンドが必要です。 CLI は、構文エラーまたは形式について検証されません。

NetScaler 構成

<NS-CONFIG>タグを使用して、プレブート段階でVPXインスタンスに適用する必要がある特定のNetScaler VPX構成を指定します。

注

<NS-CONFIG>セクションには、有効な ADC CLI コマンドが必要です。 CLI は、構文エラーまたは形式について検証されません。

例

次の例では、<NS-CONFIG>セクションに設定の詳細を示します。 ID「5」の VLAN が設定され、SNIP（5.0.0.1）にバインドされます。負荷分散仮想サーバー (4.0.0.101) も構成されています。

ADC 構成

前のスクリーンショットに示した設定をここからコピーできます。

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

NetScaler VPXインスタンスは、次の図に示すように、<NS-CONFIG>セクションに適用された構成を表示します。

VLAN 設定の確認

サーバー構成の確認

ユーザースクリプト

<NS-SCRIPTS>タグを使用して、NetScaler VPXインスタンスに保存して実行する必要があるスクリプトを指定します。

<NS-SCRIPTS>タグには多数のスクリプトを含めることができます。各スクリプトは<SCRIPT>タグ内に含める必要があります。各<SCRIPT>セクションは 1 つのスクリプトに対応し、次のサブタグを使用してスクリプトの詳細をすべて含みます。各 <SCRIPT> セクションは 1 つのスクリプトに対応し、次のサブタグを使用してスクリプトの詳細がすべて含まれています。

<SCRIPT-NAME>:保存する必要のあるスクリプトファイルの名前を示します。
<SCRIPT-CONTENT>:保存する必要のあるファイルの内容を示します。
<SCRIPT-TARGET-LOCATION>:このファイルを保存する必要がある指定されたターゲットの場所を示します。ターゲットの場所が指定されていない場合、デフォルトでは、ファイルまたはスクリプトは「/nsconfig」ディレクトリに保存されます。
<SCRIPT-NS-BOOTUP>:スクリプトの実行に使用するコマンドを指定します。
- <SCRIPT-NS-BOOTUP>セクションを使用する場合、セクションで提供されるコマンドは「/nsconfig/nsafter.sh」に保存され、コマンドは「nsafter.sh」実行の一部としてパケットエンジンが起動した後に実行されます。
- <SCRIPT-NS-BOOTUP>セクションを使用しない場合、スクリプトファイルは指定したターゲットの場所に保存されます。

例1：

この例では、<NS-SCRIPTS>タグには script-1.sh というスクリプトの詳細が 1 つだけ含まれています。「script-1.sh」スクリプトは「/var」ディレクトリに保存されます。スクリプトは指定された内容で読み込まれ、パケットエンジンの起動後に「sh /var/script-1.sh」コマンドで実行されます。

Script1

前のスクリーンショットに示した設定をここからコピーできます。

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

次のスナップショットでは、「script-1.sh」スクリプトが「/var/」ディレクトリに保存されていることを確認できます。「Script-1.sh」スクリプトが実行され、出力ファイルが適切に作成されます。

script1 出力

例2：

次の例では、<NS-SCRIPTS>タグに 2 つのスクリプトの詳細が含まれています。

最初のスクリプトは「script-1.sh」として「/var」ディレクトリに保存されます。スクリプトは指定された内容で読み込まれ、パケットエンジンの起動後にコマンド「sh /var/script-1.sh」で実行されます。
2 番目のスクリプトは「file-2.txt」として「/var」ディレクトリに保存されます。このファイルには、指定されたコンテンツが入力されます。しかし、ブートアップ実行コマンド<SCRIPT-NS-BOOTUP>が提供されていないため、実行されません。

script2

前のスクリーンショットに示した設定をここからコピーできます。

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

次のスナップショットでは、script-1.sh と file-2.txt が「/var/」ディレクトリに作成されていることを確認できます。 Script-1.sh が実行され、出力ファイルが適切に作成されます。

script2 出力

ライセンス

VPXインスタンスの起動中にNetScalerプールライセンスを適用するには、<NS-LICENSE-CONFIG>タグを使用します。 <NS-LICENSE-CONFIG>セクション内の<LICENSE-COMMANDS>タグを使用して、プールされたライセンスコマンドを指定します。これらのコマンドは構文的に有効である必要があります。

標準のプールライセンスコマンドを使用して、<LICENSE-COMMANDS>セクションで、ライセンスタイプ、容量、ライセンスサーバーなどのプールされたライセンスの詳細を指定できます。詳細については、「 NetScalerプール容量ライセンスの構成」を参照してください。

<NS-LICENSE-CONFIG>を適用した後、VPXは起動時に要求されたエディションを起動し、VPXはライセンスサーバから構成されたライセンスをチェックアウトしようとします。

ライセンスのチェックアウトが成功すると、構成された帯域幅がVPXに適用されます。
ライセンスのチェックアウトに失敗した場合、約 10 ～ 12 分以内にライセンスはライセンスサーバから取得されません。その結果、システムがリブートし、ライセンスなしの状態になります。

例

次の例では、<NS-LICENSE-CONFIG>を適用した後、VPX は起動時にプレミアムエディションを起動し、VPX はライセンスサーバ（10.102.38.214）から構成されたライセンスをチェックアウトしようとします。

ライセンスコマンド

前のスクリーンショットに示した設定をここからコピーできます。

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

次の図に示すように、「ライセンスサーバーの表示」コマンドを実行し、ライセンスサーバー（10.102.38.214）がVPXに追加されていることを確認します。

ライセンスサーバーを表示

ブートストラッピング

<NS-BOOTSTRAP>タグを使用して、カスタムブートストラップ情報を指定します。 <NS-BOOTSTRAP>セクション内では、 <SKIP-DEFAULT-BOOTSTRAP>タグと<NEW-BOOTSTRAP-SEQUENCE>タグを使用できます。このセクションでは、デフォルトのブートストラップを回避するかどうかをNetScalerアプライアンスに通知します。デフォルトのブートストラップが回避される場合、このセクションでは、新しいブートストラップシーケンスを提供するオプションを提供します。

デフォルトのブートストラップ構成

NetScalerアプライアンスのデフォルトのブートストラップ構成は、次のインターフェイスの割り当てに従います。

Eth0 -特定の NSIP アドレスを持つ管理インターフェイス。
Eth1 -特定の VIP アドレスを持つクライアント向けインターフェイス。
Eth2 -特定の SNIP アドレスを持つサーバー側インターフェイス。

ブートストラップ構成をカスタマイズする

デフォルトのブートストラップシーケンスをスキップして、NetScaler VPXインスタンスに新しいブートストラップシーケンスを指定することができます。 <NS-BOOTSTRAP>タグを使用して、カスタムブートストラップ情報を指定します。たとえば、管理インターフェイス（NSIP）、クライアント側インターフェイス（VIP）、およびサーバー側インターフェイス（SNIP）が常に特定の順序で提供されるデフォルトのブートストラップを変更できます。

次の表に、<SKIP-DEFAULT-BOOTSTRAP>および<NEW-BOOTSTRAP-SEQUENCE>タグで許可されるさまざまな値を使用したブートストラップ動作を示します。

`SKIP-DEFAULT-BOOTSTRAP`	`NEW-BOOTSTRAP-SEQUENCE`	ブートストラップ動作
はい	はい	デフォルトのブートストラップ動作はスキップされ、 `<NS-BOOTSTRAP>`セクションで提供される新しいカスタムブートストラップシーケンスが実行されます。
はい	いいえ	デフォルトのブートストラップ動作はスキップされます。「`<NS-CONFIG>`」セクションに記載されているブートストラップコマンドが実行されます。

ブートストラップ構成は、次の 3 つの方法でカスタマイズできます。

インターフェイスの詳細のみを入力します。
IP アドレスとサブネットマスクとともにインターフェイスの詳細を指定します。
<NS-CONFIG>セクションにブートストラップ関連のコマンドを入力します。

方法 1: インターフェイスの詳細のみを指定してカスタムブートストラップ

管理インターフェイス、クライアント向けインターフェイス、およびサーバ側インターフェイスは指定しますが、その IP アドレスとサブネットマスクは指定しません。 IP アドレスとサブネットマスクは、クラウドインフラストラクチャのクエリによって設定されます。

AWS のカスタムブートストラップの例

次の例に示すように、カスタムブートストラップシーケンスを指定します。詳細については、「クラウドインスタンスでプレブートユーザーデータを提供する方法」を参照してください。 Eth2 インターフェイスは、管理インターフェイス（NSIP）として、Eth1 インターフェイスをクライアントインターフェイス（VIP）として、Eth0 インターフェイスをサーバインターフェイス（SNIP）として割り当てます。 <NS-BOOTSTRAP>セクションには、インターフェイスの詳細のみが含まれ、IP アドレスとサブネットマスクの詳細は含まれません。

AWS カスタムブートストラップ方法1

VM インスタンスの作成後、AWS ポータルで、ネットワークインターフェイスのプロパティを次のように確認できます。

[ AWS Portal] > [EC2 インスタンス] に移動し、カスタムブートストラップ情報を指定して作成したインスタンスを選択します。
[ 説明 ] タブでは、次の図に示すように、各ネットワークインタフェースのプロパティを確認できます。

AWS eth1

AWS eth0

AWS eth2

ADC CLIでshow nsipコマンドを実行し、ADCアプライアンスの初回起動時にNetScalerVPXインスタンスに適用されるネットワークインターフェイスを確認できます。

AWS show nsip method1

Azure のカスタムブートストラップの例

次の例に示すように、カスタムブートストラップシーケンスを指定します。詳細については、「クラウドインスタンスでプレブートユーザーデータを提供する方法」を参照してください。 Eth1 インターフェイスは管理インターフェイス（NSIP）、クライアントインターフェイス（VIP）として Eth0 インターフェイス、サーバインターフェイス（SNIP）として Eth2 インターフェイスが割り当てられます。 <NS-BOOTSTRAP>セクションには、インターフェイスの詳細のみが含まれ、IP アドレスとサブネットマスクの詳細は含まれません。

Azure カスタムブートストラップ方法1

NetScaler VPXインスタンスが3つのネットワークインターフェイスで作成されていることがわかります。 Azure Portal > VM インスタンス > ネットワークに移動し、次の図に示すように 3 つの NIC のネットワークプロパティを確認します。

Azure サーバーメソッド1

Azure クライアントメソッド1

Azure 管理方法1

ADC CLIでshow nsipコマンドを実行し、<NS-BOOTSTRAP>セクションで指定された新しいブートストラップシーケンスが適用されていることを確認できます。「show route」コマンドを実行して、サブネットマスクを確認できます。

Azure show nsip コマンド

GCP のカスタムブートストラップの例

GCP Method1

GCP ポータルで VM インスタンスを作成した後、ネットワークインターフェイスのプロパティを次のように確認できます。

カスタムブートストラップ情報を指定して、作成したインスタンスを選択します。
ネットワークインターフェイスのプロパティに移動し、NIC の詳細を次のように確認します。

GCP method1

Gcp-show-nsip-method1

方法 2: インターフェイス、IP アドレス、およびサブネットマスクを指定してカスタムブートストラップ

管理インターフェイス、クライアント向けインターフェイス、およびサーバ向けインターフェイスと IP アドレスとサブネットマスクを指定します。

AWS のカスタムブートストラップの例

次の例では、デフォルトのブートストラップをスキップして、NetScalerアプライアンスの新しいブートストラップシーケンスを実行します。新しいブートストラップシーケンスでは、次の詳細を指定します。

管理インターフェイス： インターフェイス-Eth1、NSIP-172.31.52.88、およびサブネットマスク-255.255.240.0
クライアント側インターフェイス： インターフェイス-Eth0、VIP-172.31.5.155、およびサブネットマスク-255.255.240.0。
サーバー側インターフェイス： インターフェイス-Eth2、SNIP-172.31.76.177、サブネットマスク-255.255.240.0。

AWS カスタムブートストラップ方法2

AWS show nsip method2

Azure のカスタムブートストラップの例

次の例では、ADC の新しいブートストラップシーケンスが記述され、デフォルトのブートストラップがスキップされます。インターフェイスの詳細と IP アドレスとサブネットマスクを次のように指定します。

管理インターフェイス（eth2）、NSIP（172.27.2.53）、およびサブネットマスク（255.255.255.0）
クライアント側インターフェイス（eth1）、VIP（172.27.1.53）、およびサブネットマスク（255.255.255.0）
サーバー側インターフェイス (eth0)、SNIP (172.27.0.53)、およびサブネットマスク (255.255.255.0)

Azure カスタムブートストラップ方法2

Azure 管理インターフェイスメソッド2

Azure クライアントインターフェイスメソッド2

Azure サーバーインターフェイスメソッド2

Azure show nsip method2

GCP のカスタムブートストラップの例

管理インターフェイス（eth2）、NSIP（10.128.4.31）、およびサブネットマスク（255.255.255.0）
クライアント側インターフェイス（eth1）、VIP（10.128.0.43）、およびサブネットマスク（255.255.255.0）
サーバ側インターフェイス（eth0）、SNIP（10.160.0.75）、およびサブネットマスク（255.255.255.0）

GCP method2

カスタムブートストラップを使用して GCP ポータルで VM インスタンスを作成した後、ネットワークインターフェイスのプロパティを次のように確認できます。

カスタムブートストラップ情報を指定して、作成したインスタンスを選択します。
ネットワークインターフェイスのプロパティに移動し、NIC の詳細を次のように確認します。

GCP NIC の詳細

GCP show nsip command

方法 3: `<NS-CONFIG>`セクションにブートストラップ関連のコマンドを指定して、カスタムブートストラップ

ブートストラップ関連のコマンドについては、<NS-CONFIG>セクションを参照してください。 <NS-BOOTSTRAP>セクションでブートストラップコマンドを実行するには、<NS-CONFIG>セクションで<NEW-BOOTSTRAP-SEQUENCE>を「No」と指定する必要があります。 NSIP、デフォルトルート、および NSVLAN を割り当てるコマンドも指定する必要があります。さらに、使用するクラウドに関連するコマンドも提供します。

カスタムブートストラップを提供する前に、クラウドインフラストラクチャが特定のインターフェイス構成をサポートしていることを確認してください。

AWS のカスタムブートストラップの例

この例では、ブートストラップ関連のコマンドを<NS-CONFIG>セクションで提供しています。 <NS-BOOTSTRAP>セクションは、デフォルトのブートストラップがスキップされ、<NS-CONFIG>セクションで提供されるカスタムブートストラップ情報が実行されることを示します。 NSIP の作成、デフォルトルートの追加、および NSVLAN の追加を行うコマンドも指定する必要があります。

AWS カスタムブートストラップ方法3

前のスクリーンショットに示した設定をここからコピーできます。

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

VM インスタンスの作成後、AWS ポータルで、ネットワークインターフェイスのプロパティを次のように確認できます。

[ AWS Portal] > [EC2 インスタンス] に移動し、カスタムブートストラップ情報を指定して作成したインスタンスを選択します。
[ 説明 ] タブでは、次の図に示すように、各ネットワークインタフェースのプロパティを確認できます。

AWS eth1 method3

AWS eth0 method3

AWS eth2 method3

AWS show nsip method3

Azure のカスタムブートストラップの例

この例では、ブートストラップ関連のコマンドを<NS-CONFIG>セクションで提供しています。 <NS-BOOTSTRAP>セクションは、デフォルトのブートストラップがスキップされ、<NS-CONFIG>セクションで提供されるカスタムブートストラップ情報が実行されることを示します。

注

Azure クラウドの場合、インスタンスメタデータサーバー (IMDS) と DNS サーバーはプライマリインターフェイス (Eth0) を介してのみアクセスできます。したがって、Eth0 インターフェイスが管理インターフェイス（NSIP）として使用されない場合、Eth0 インターフェイスは、少なくとも IMDS または DNS アクセスを動作させるには、SNIP として設定する必要があります。 Eth0 のゲートウェイを経由する IMDS エンドポイント（169.254.169.254）および DNS エンドポイント（168.63.129.16）へのルートも追加する必要があります。

Azure カスタムブートストラップ方法3

  <NS-PRE-BOOT-CONFIG>

     <NS-CONFIG>

          set ns config -IPAddress 172.27.2.61 -netmask 255.255.255.0
          add route 0.0.0.0   0.0.0.0   172.27.2.1
          set ns config -nsvlan 10 -ifnum 1/2  -tagged NO
          add ns ip 172.27.0.61   255.255.255.0   -type SNIP
          add route 169.254.169.254 255.255.255.255 172.27.0.1
          add route 168.63.129.16 255.255.255.255 172.27.0.1

          add vlan 5
          bind vlan 5 -IPAddress 5.0.0.1 255.255.255.0
          enable ns feature WL SP LB RESPONDER
          add server 5.0.0.201 5.0.0.201
          add service preboot_s5_201 5.0.0.201 HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO
          add lb vserver preboot_v4_101 HTTP 4.0.0.101 80 -persistenceType NONE -cltTimeout 180

      </NS-CONFIG>

      <NS-BOOTSTRAP>

      <SKIP-DEFAULT-BOOTSTRAP>YES</SKIP-DEFAULT-BOOTSTRAP>
      <NEW-BOOTSTRAP-SEQUENCE> NO </NEW-BOOTSTRAP-SEQUENCE>

      </NS-BOOTSTRAP>

  </NS-PRE-BOOT-CONFIG>
<!--NeedCopy-->

Azure サーバーインターフェイス

Azure クライアントインターフェイス

Azure 管理インターフェイス

Azure show nsip method3

GCP のカスタムブートストラップの例

この例では、ブートストラップ関連のコマンドを<NS-CONFIG>セクションで提供しています。 <NS-BOOTSTRAP>セクションは、デフォルトのブートストラップがスキップされ、<NS-CONFIG>セクションで提供されるカスタムブートストラップ情報が適用されることを示します。

GCP method3

前のスクリーンショットに示した設定をここからコピーできます。

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

カスタムブートストラップ情報を指定して、作成したインスタンスを選択します。
[Network Interface] プロパティに移動し、図に示すように NIC の詳細を確認します。

GCP コンソールに示す NIC の詳細

ADC CLIでshow nsipコマンドを実行し、ADCアプライアンスの最初の起動時に前の<NS-CONFIG>セクションで説明した設定が適用されていることを確認できます。

NSIP 出力の表示

AWS および Azure での NIC のアタッチとデタッチによる影響

AWS と Azure には、ネットワークインターフェイスをインスタンスにアタッチし、ネットワークインターフェイスをインスタンスからデタッチするオプションが用意されています。インターフェイスをアタッチまたはデタッチすると、インターフェイスの位置が変わることがあります。そのため、CitrixではNetScaler VPXインスタンスからインターフェイスをデタッチしないことをお勧めします。カスタムブートストラップが構成されているときにインターフェイスをデタッチまたは接続すると、NetScaler VPXインスタンスは、管理インターフェイスの位置で新しく使用可能なインターフェイスのプライマリIPをNSIPとして再割り当てします。デタッチしたインターフェイスの後に使用可能なインターフェイスがない場合は、最初のインターフェイスがNetScaler VPXインスタンスの管理インターフェイスになります。

たとえば、NetScaler VPXインスタンスは、Eth0（SNIP）、Eth1（NSIP）、およびEth2（VIP）の3つのインターフェイスで起動されます。管理インターフェイスであるインスタンスから Eth1 インターフェイスをデタッチすると、ADC は次の使用可能なインターフェイス（Eth2）を管理インターフェイスとして設定します。そのため、NetScaler VPXインスタンスには引き続きEth2インターフェイスのプライマリIPを介してアクセスされます。 Eth2 も使用できない場合は、残りのインターフェイス（Eth0）が管理インターフェイスになります。そのため、NetScaler VPXインスタンスには引き続きアクセスできます。

Eth0 (SNIP)、Eth1 (VIP)、Eth2 (NSIP) の異なるインターフェイスの割り当てを考えてみましょう。 Eth2（NSIP）をデタッチすると、Eth2 の後に新しいインターフェイスが使用できないため、最初のインターフェイス（Eth0）が管理インターフェイスになります。

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

NetScaler VPX構成をクラウドでNetScalerアプライアンスの最初の起動時に適用する

October 17, 2024

寄稿者:

C C

October 17, 2024

寄稿者:

C C

この記事の概要

ユーザーデータとは何ですか
クラウドインスタンスでプレブートユーザーデータを提供する方法
AWS コンソールを使用してプレブートユーザーデータを提供する
Azure コンソールを使用してプリブートユーザーデータを提供する
GCP コンソールを使用してプレブートユーザーデータを提供する
プレブートユーザーデータ形式
NetScaler 構成
ユーザースクリプト
ライセンス
ブートストラッピング
方法 1: インターフェイスの詳細のみを指定してカスタムブートストラップ
方法 2: インターフェイス、IP アドレス、およびサブネットマスクを指定してカスタムブートストラップ
方法 3: <NS-CONFIG>セクションにブートストラップ関連のコマンドを指定して、カスタムブートストラップ
AWS および Azure での NIC のアタッチとデタッチによる影響

この情報は役に立ちましたか?

NetScaler VPX構成をクラウドでNetScalerアプライアンスの最初の起動時に適用する

ユーザーデータとは何ですか

クラウドインスタンスでプレブートユーザーデータを提供する方法

AWS コンソールを使用してプレブートユーザーデータを提供する

AWS CLI を使用してプレブートユーザーデータを提供する

Azure コンソールを使用してプリブートユーザーデータを提供する

Azure CLI を使用してプリブートユーザーデータを提供する

GCP コンソールを使用してプレブートユーザーデータを提供する

gcloud CLI を使用してプレブートユーザーデータを提供する

プレブートユーザーデータ形式

NetScaler 構成

ユーザースクリプト

ライセンス

ブートストラッピング

デフォルトのブートストラップ構成

ブートストラップ構成をカスタマイズする

方法 1: インターフェイスの詳細のみを指定してカスタムブートストラップ

AWS のカスタムブートストラップの例

Azure のカスタムブートストラップの例

GCP のカスタムブートストラップの例

方法 2: インターフェイス、IP アドレス、およびサブネットマスクを指定してカスタムブートストラップ

AWS のカスタムブートストラップの例

Azure のカスタムブートストラップの例

GCP のカスタムブートストラップの例

方法 3: &lt;NS-CONFIG&gt;セクションにブートストラップ関連のコマンドを指定して、カスタムブートストラップ

AWS のカスタムブートストラップの例

Azure のカスタムブートストラップの例

GCP のカスタムブートストラップの例

AWS および Azure での NIC のアタッチとデタッチによる影響

この記事の概要

方法 3: `<NS-CONFIG>`セクションにブートストラップ関連のコマンドを指定して、カスタムブートストラップ