スタンドアロンノードのディザスタリカバリを構成する

最終公開日 : Sep 25, 2026
スタンドアロンモードで展開されたNetScaler Consoleのディザスタリカバリも構成できます。
次の表は、NetScaler Consoleでディザスタリカバリを構成する際に使用される用語について説明しています。
用語 説明
プライマリサイト (データセンター A) プライマリサイトには、スタンドアロンモードで展開されたNetScaler Consoleノードがあります。
リカバリサイト (データセンター B) リカバリサイトには、スタンドアロンモードで展開されたディザスタリカバリノードがあります。このノードは読み取り専用モードであり、プライマリサイトがダウンするまで動作しません。
ディザスタリカバリノード リカバリノードは、リカバリサイトに展開されたスタンドアロンノードです。プライマリサイトで障害が発生し、機能しなくなった場合に、このノードが運用可能になります（新しいプライマリとして）。
注
プライマリサイトとDRサイトは、ポート5454と22を介して相互に通信し、これらのポートはデフォルトで有効になっています。
ポートとプロトコルの詳細については、ポートを参照してください。

ディザスタリカバリのワークフロー

プライマリサイトには、スタンドアロンモードで展開されたNetScaler Consoleノードがあります。
リカバリサイトには、リモートで展開されたディザスタリカバリノードがあります。ディザスタリカバリノードは読み取り専用モードであり、プライマリノードからデータを受信してデータバックアップを作成します。リカバリサイトのNetScalerインスタンスも検出されますが、それらを介してトラフィックは流れません。バックアッププロセス中に、すべてのデータ、ファイル、および構成がプライマリノードからディザスタリカバリノードにレプリケートされます。

前提条件

ディザスタリカバリノードをセットアップする前に、次の前提条件に注意してください。
  • ディザスタリカバリ設定を有効にするには、プライマリサイトでNetScaler Consoleがスタンドアロンモードで構成されている必要があります。
  • スタンドアロンのNetScaler Console（プライマリサイト内）とディザスタリカバリノード（DRサイト内）は、同じソフトウェアバージョン、ビルド、および構成である必要があります。
スケジューリング動作とネットワーク遅延を改善するために、CPU優先度（仮想マシンプロパティ内）を最高レベルに設定することをお勧めします。
次の表に、ディザスタリカバリノードを構成するための最小要件を示します。
コンポーネント 要件
RAM 32 GB
仮想CPU 8 CPU
ストレージ容量 NetScaler Consoleの展開には、ソリッドステートドライブ (SSD) テクノロジーを使用することをお勧めします。デフォルト値は120 GBです。実際のストレージ要件は、NetScaler Consoleのサイジング見積もりによって異なります。NetScaler Consoleのストレージ要件が120 GBを超える場合は、追加のディスクを接続する必要があります。注 ディスクは1つしか追加できません。初期展開時にストレージを見積もり、追加のディスクを接続することをお勧めします。詳細については、「NetScaler Consoleにディスクを追加する方法」を参照してください。
仮想ネットワークインターフェイス 1
スループット 1 Gbpsまたは100 Mbps
ハイパーバイザー バージョン
シトリックス ハイパーバイザー 6.2および6.5
ヴイエムウェア ESXi 5.5および6.0
マイクロソフト Hyper-V 2012 R2
リナックス KVM UbuntuおよびFedora

初めてのディザスタリカバリ設定

  • NetScaler Console を展開する
  • NetScaler Console ディザスタリカバリノードを展開して登録する
  • ユーザーインターフェイスからディザスタリカバリ設定を有効/無効にする

NetScaler Console を展開する

ディザスタリカバリ設定を行うには、NetScaler Console がスタンドアロンモードで展開されていることを確認してください。詳細については、シングルサーバー展開を参照してください。

DR コンソールを使用して NetScaler Console ディザスタリカバリノードを展開および登録する

NetScaler Console ディザスタリカバリノードを登録するには：
  1. NetScaler サイトから .xva イメージファイルをダウンロードし、ハイパーバイザーにインポートします。
  2. コンソールタブから、NetScaler Console の初期ネットワーク設定を構成します。
    注
    ディザスタリカバリノードは、異なるサブネット上に配置できます。
    ディザスタリカバリノード
  3. 初期ネットワーク設定が完了すると、システムはログインを要求します。次の資格情報を使用してログオンします – nsrecover/nsroot。
    重要
    登録中にDRノードの資格情報 (nsrecover/nsroot) を変更しないでください。DRノードを正常に登録した後で、DRノードの資格情報を変更できます。
  4. ディザスタリカバリノードを展開するには、/mps/deployment_type.py と入力してEnterキーを押します。NetScaler Consoleの展開設定メニューが表示されます。
    構成メニュー
  5. ディザスタリカバリノードを登録するには、2 を選択します。
    ノードの登録
  6. コンソールは、スタンドアロンノードのIPアドレスとパスワードを要求します。
  7. ディザスタリカバリノードを登録するには、スタンドアロンノードのIPアドレスとパスワードを入力します。
    ディザスタリカバリノードが正常に登録されました。
    登録成功
    注
    • ディザスタリカバリノードにはGUIがありません。
    • 登録が成功すると、サーバーにログオンするためのデフォルトの管理者資格情報は nsroot/nsroot です。
  8. DRノードのパスワードを変更する場合は、次のスクリプトを実行します。
    /mps/change_freebsd_password.sh <username> <password>
    例:
    /mps/change_freebsd_password.sh nsroot new_password

NetScaler Console GUIを使用してディザスタリカバリノードを展開する

DRコンソールを使用してディザスタリカバリノードが正常に登録されたら、NetScaler Console GUIからDRノードを展開します。この手順により、NetScaler Consoleプライマリサイトからディザスタリカバリ設定が有効になります。
  1. > > の順に移動します。
  2. ページで、 を選択します。
  3. 確認ダイアログボックスが表示されます。続行するには をクリックします。
    注
    システムバックアップにかかる時間は、データサイズとWANリンク速度によって異なります。
NetScaler Console GUIでDRノードを正常に展開した後、DRノードのデータベースの状態、メモリ、CPU、ディスク使用量を監視できます。
ディザスタリカバリ設定を無効にするには、 を選択します。確認ダイアログボックスが表示されます。続行するには をクリックします。
DRノードを再度有効にするには、高可用性ペア用にDRノードを再構成します。
  1. ハイパーバイザーまたはSSHコンソールを使用してDRノードにログオンします。
  2. DRコンソールを使用してNetScaler Consoleディザスタリカバリノードを展開および登録する に記載されている手順に従って、DRノードを構成します。
  3. NetScaler Console GUIを使用してディザスタリカバリノードを展開する。
詳細については、FAQ を参照してください。
重要
  • プライマリサイトで障害が発生したことを検出するのは、管理者の責任です。
  • プライマリサイトがダウンした後、災害復旧ワークフローは管理者によって手動で開始されます。
  • 管理者は、リカバリサイトの災害復旧ノードでリカバリススクリプトを実行して、プロセスを手動で開始する必要があります。
  • プライマリサイトのスタンドアロンノードをアップグレードする場合、DRサイトのスタンドアロンノードも手動でアップグレードする必要があります。

災害後のワークフロー

災害後にプライマリサイトがダウンした場合、災害復旧ワークフローは次のように開始する必要があります。
  1. 管理者は、プライマリサイトが災害に見舞われ、動作不能になっていることを確認します。
  2. 管理者はリカバリプロセスを開始します。
  3. 管理者は、要件に基づいて（リカバリサイトの）災害復旧ノードで次のいずれかのリカバリススクリプトを手動で実行する必要があります。
    • DRノードでSNMP、Syslog、およびAnalyticsを構成します。
      /mps/scripts/pgsql/pgsql\_restore\_remote\_backup.sh
    • DRノードをライセンスサーバーとしても構成します。

      /mps/scripts/pgsql/pgsql\_restore\_remote\_backup.sh -reconfig-ls <IP-address-of-the-primary-site>
  4. 内部的には、NetScalerインスタンスは、新しいプライマリサイトとなった災害復旧ノードにデータを送信するように自動的に再構成されます。
    注:
    DRサイトでスクリプトを開始すると、DRサイトが新しいプライマリサイトになります。DRユーザーインターフェイスにもアクセスできます。

災害復旧後

災害が発生し、管理者がリカバリススクリプトを開始すると、DRサイトが新しいプライマリサイトになります。
後で設定を元のサイトに戻したい場合は、「元のプライマリサイトへの設定の復元」を参照してください(#revert-configurations-to-the-original-primary-site)。
重要
  • NetScaler Console 12.1.49.x以前のリリースをインストールしている場合、Citrixに連絡してNetScaler Console（DRサイト）で元のライセンスを再ホストするための30日間の猶予期間が与えられます。
  • 12.1.50.x以降のリリースでは、NetScaler ConsoleライセンスはDRサイトに自動的に同期されます（ライセンスについてCitrixに連絡する必要はありません）。
  • インスタンスにプールライセンスを適用している場合、バージョン 11.1 65.x以降、12.1 58.x以降、13.0 47.x以降、およびNetScaler SDX 13.0 76.x以降のNetScalerインスタンスは、DRサイトでの自動ライセンスサーバー更新をサポートしています。その他のすべてのバージョンでは、インスタンスをDRサイトに手動で再構成する必要があります。

元のプライマリサイトへの設定の復元

災害後、構成された災害復旧（DR）ノードが新しいプライマリサイトとなり、クライアントトラフィックはこのノードを経由して流れます。
災害後のセットアップ
詳細については、「災害後のワークフロー」を参照してください(#workflow-after-the-disaster)。
元のプライマリサイトが災害から復旧し、すべての操作をプライマリサイトに移行することを決定した場合、DRノードの設定に合わせて元のプライマリサイトを再構成します。
開始する前に、プライマリサイトとDRサイトの両方がアクティブであることを確認してください。
DRサイトから元のプライマリサイトに変更を戻すには、次の手順を実行します。
  1. 元のプライマリサイトにログインし、次のコマンドを実行します。
    nohup /mps/sync_adm_node.py -I <DR-site-IP-address> -R <DR-node-password> -L <primary-node-password> &
    このコマンドは、Syslog、SNMP、およびAnalyticsのみをプライマリサイトに構成します。
    プライマリサイトをNetScalerインスタンスのプールライセンスサーバーとして構成する場合は、次のコマンドを実行します。
    nohup /mps/sync_adm_node.py -I <DR-site-IP-address> -R <DR-node-password> -L <primary-node-password>  -O yes &
    -O コマンドは、DRサイトのIPアドレスを取得し、プライマリサイトをプールライセンスサーバーとして再構成します。
  2. DRサイトを再構成します。「災害復旧セットアップの展開」(#first-time-disaster-recovery-setup)を参照してください。
DRサイトから元のプライマリサイトに構成を正常に復元した後、クライアントトラフィックはNetScaler Consoleプライマリノードを介して流れます。