製品ドキュメント
NetScaler VPX
14.1-Aktuelle Version 13.1 12.1
PDFを表示

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

June 8, 2026
寄稿者: 
C C

クラウド環境でNetScalerアプライアンスを初回起動する際に、NetScaler VPX構成を適用できます。この段階は、このドキュメントではプレブート段階として扱われます。そのため、ADCプールライセンスのような特定のケースでは、特定のVPXインスタンスがはるかに短い時間で起動します。この機能は、Microsoft Azure、Google Cloud Platform、およびAWSクラウドで利用できます。

ユーザーデータとは

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

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

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

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

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

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

各手順の詳細については、「AWSウェブコンソールを使用して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つのセクションで構成できます。

  • <NS-CONFIG> タグで表される NetScaler 構成。
  • <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-->

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

注:

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

ネットスケーラーの構成

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

注:

<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構成の確認

サーバー構成の確認

ユーザースクリプト

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

<NS-SCRIPTS>タグ内に複数のスクリプトを含めることができます。各スクリプトは<SCRIPT>タグ内に含める必要があります。 各<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>タグには1つのスクリプト（script-1.sh）の詳細のみが含まれています。「script-1.sh」スクリプトは「/var」ディレクトリに保存されます。スクリプトには指定された内容が入力され、パケットエンジンが起動した後、「sh /var/script-1.sh」コマンドで実行されます。

スクリプト1

前のスクリーンショットに示されている構成は、ここからコピーできます。

<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」スクリプトが実行され、出力ファイルが適切に作成されます。

スクリプト1の出力

例 2:

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

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

スクリプト2

前のスクリーンショットに示されている構成は、ここからコピーできます。

<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 が実行され、出力ファイルが適切に作成されます。

スクリプト2出力

ライセンス

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は起動時にPremiumエディションで起動し、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-->

次の図に示すように、「show license server」コマンドを実行して、ライセンスサーバー（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 のカスタムブートストラップの例

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

AWS カスタムブートストラップ メソッド1

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

  1. AWS Portal > EC2 instances に移動し、カスタムブートストラップ情報を提供して作成したインスタンスを選択します。
  2. Description タブで、以下の図に示すように、各ネットワークインターフェイスのプロパティを確認できます。

エーダブリューエス eth1

エーダブリューエス eth0

AWSのeth2インターフェースの図

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

AWSのnsip表示 メソッド1

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

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

Azure カスタムブートストラップ メソッド1

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

「Azureサーバー方式1」(/ja-jp/vpx/media/azure-server-method1.png)

「Azureクライアント方式1」(/ja-jp/vpx/media/azure-client-method1.png)

「Azure管理方式1」(/ja-jp/vpx/media/azure-mgmt-method1.png)

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

アジュール show nsip コマンド(/ja-jp/vpx/media/azure-show-nsip-method1.png)

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

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

ジーシーピー 方式1

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

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

ジーシーピー 方式1

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

ジーシーピー NSIP表示 方式1

方法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(/ja-jp/vpx/media/aws-custom-bootstrap-method2.png)

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

AWSでのNSIP表示方法2

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(/ja-jp/vpx/media/azure-custom-bootstrap-method2-new.png)

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

Azure管理インターフェース method2(/ja-jp/vpx/media/azure-mgmt-method2.png)

Azureクライアントインターフェース method2(/ja-jp/vpx/media/azure-client-method2.png)

Azureサーバーインターフェース method2(/ja-jp/vpx/media/azure-server-method2.png)

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

アジュールでの show nsip 方法2(/ja-jp/vpx/media/azure-show-nsip-method2.png)

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

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

  • 管理インターフェース (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での方法2(/ja-jp/vpx/media/gcp-method2.png)

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

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

GCPのNICに関する詳細情報

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

GCPのnsip表示コマンド(/ja-jp/vpx/media/gcp-show-nsip-method2.png)

方法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」(/ja-jp/vpx/media/aws-custom-bootstrap-method3.png)

前のスクリーンショットに示されている構成は、ここからコピーできます。

<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ポータルで、ネットワークインターフェースのプロパティを次のように確認できます。

  1. AWS Portal > EC2 instancesに移動し、カスタムブートストラップ情報を提供して作成したインスタンスを選択します。
  2. Descriptionタブで、以下の図に示すように、各ネットワークインターフェースのプロパティを確認できます。

AWS eth1の3番目の方法(/ja-jp/vpx/media/aws-eth1-method3.png)

AWS eth0 の設定方法3

AWS eth2 の設定方法3

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

AWSでのNSIP表示（方法3）

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

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

注:

Azureクラウドの場合、インスタンスメタデータサーバー (IMDS) およびDNSサーバーは、プライマリインターフェース (Eth0) を介してのみアクセス可能です。したがって、Eth0インターフェースが管理インターフェース (NSIP) として使用されていない場合、IMDSまたはDNSアクセスが機能するためには、Eth0インターフェースを少なくとも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-->

ご覧のとおり、NetScaler VPXインスタンスは3つのネットワークインターフェースで作成されます。Azure portal > VM instance > Networkingに移動し、次の図に示すように、3つのNICのネットワークプロパティを確認します。

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

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

Azure 管理インターフェース

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

アジュールでのNSIP表示（方法3）

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

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

GCP メソッド3

上記のスクリーンショットに示されている構成は、ここからコピーできます。

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

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

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

GCPコンソールに表示されるNICの詳細

ADC CLI で show nsip コマンドを実行し、上記の <NS-CONFIG> セクションで提供された構成がADCアプライアンスの初回起動時に適用されていることを確認できます。

NSIP出力の表示

AWSおよびAzureにおけるNICの接続と切断の影響

AWSとAzureでは、ネットワークインターフェイスをインスタンスに接続したり、インスタンスからネットワークインターフェイスを切断したりするオプションが提供されています。インターフェイスの接続または切断により、インターフェイスの位置が変更される可能性があります。そのため、CitrixはNetScaler VPXインスタンスからインターフェイスを切断しないことを推奨します。カスタムブートストラップが構成されている状態でインターフェイスを切断または接続すると、NetScaler VPXインスタンスは、新しく利用可能になったインターフェイスのプライマリIPを管理インターフェイスの位置にNSIPとして再割り当てします。切断したインターフェイスの後に利用可能なインターフェイスがない場合、最初のインターフェイスがNetScaler VPXインスタンスの管理インターフェイスになります。

たとえば、NetScaler VPXインスタンスが3つのインターフェイス（Eth0 (SNIP)、Eth1 (NSIP)、Eth2 (VIP)）で起動されたとします。管理インターフェイスであるEth1インターフェイスをインスタンスから切断すると、ADCは次に利用可能なインターフェイス（Eth2）を管理インターフェイスとして構成します。これにより、NetScaler VPXインスタンスは引き続きEth2インターフェイスのプライマリIPを介してアクセスされます。Eth2も利用できない場合、残りのインターフェイス（Eth0）が管理インターフェイスになります。したがって、NetScaler VPXインスタンスへのアクセスは継続して可能です。

次のようにインターフェイスの割り当てが異なる場合を考えてみましょう。Eth0 (SNIP)、Eth1 (VIP)、Eth2 (NSIP)。Eth2 (NSIP) を切断した場合、Eth2の後に新しいインターフェイスが利用できないため、最初のインターフェイス (Eth0) が管理インターフェイスになります。

クラウドでのNetScalerアプライアンスの初回起動時にNetScaler VPX構成を適用する
June 8, 2026
寄稿者: 
C C
June 8, 2026
寄稿者: 
C C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.