高可用性向けに災害復旧を構成する

最終公開日 : Sep 25, 2026
災害とは、自然災害または人為的な事象によって引き起こされる、ビジネス機能の突然の中断です。災害はデータセンターの運用に影響を与え、その後、災害現場で失われたリソースとデータは完全に再構築および復元される必要があります。データセンターでのデータ損失やダウンタイムは致命的であり、事業継続性を崩壊させます。
NetScaler Consoleの災害復旧(DR)機能は、高可用性モードで展開されたNetScaler Consoleに対して、完全なシステムバックアップおよび復旧機能を提供します。復旧時には、証明書、構成ファイル、およびデータベースの完全なバックアップが復旧サイトで利用可能です。
以下の表は、NetScaler Consoleで災害復旧を構成する際に使用される用語について説明しています。
用語 説明
プライマリサイト(データセンターA) プライマリサイトには、高可用性モードで展開されたNetScaler Consoleノードがあります。
復旧サイト(データセンターB) 復旧サイトには、スタンドアロンモードで展開された災害復旧ノードがあります。このノードは読み取り専用モードであり、プライマリサイトがダウンするまで動作しません。
災害復旧ノード 復旧ノードは、復旧サイトに展開されたスタンドアロンノードです。プライマリサイトで災害が発生し、機能しなくなった場合に、このノードが(新しいプライマリとして)動作可能になります。
注
プライマリサイトとDRサイトは、ポート5454と22を介して相互に通信し、これらのポートはデフォルトで有効になっています。
ポートとプロトコルの詳細については、ポートを参照してください。

基本認証を有効にする

基本認証は、一時的に有効にする必要があります。
  • エージェントとディザスタリカバリノードの初期登録を完了する。
  • NetScaler GUIからライセンスアクティベーションシステム (LAS) のチェックアウトを開始する。
注
基本認証は、初期登録にのみ必要です。

基本認証を構成する

  1. 「設定 > 管理 > システム構成 > システム、タイムゾーン、許可されたURL、およびエージェント設定」に移動します。
  2. Basic Settings をクリックします。
  3. Enable Allow Basic Authentication を選択します。
  4. OK をクリックします。
注
DRサイトが正常に構成される前に基本認証オプションを有効にしてください。そうしないと、次のエラーが表示されます。
Not valid username/password or incorrect host IP, or the host is unable to respond to the request..

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

以下の画像は、ディザスターリカバリーのワークフロー、災害発生前の初期設定、および災害発生後のワークフローを示しています。

災害発生前の初期設定

初期設定
この画像は、災害発生前のディザスターリカバリー設定を示しています。
プライマリサイトには、高可用性モードで展開されたNetScaler Consoleノードがあります。詳細については、「高可用性展開」を参照してください。
リカバリーサイトには、スタンドアロンのNetScaler Consoleディザスターリカバリーノードがリモートで展開されています。ディザスターリカバリーノードは読み取り専用モードで、プライマリノードからデータを受信してデータバックアップを作成します。リカバリーサイトのNetScalerインスタンスも検出されますが、それらを介してトラフィックは流れません。バックアッププロセス中、すべてのデータ、ファイル、および構成はプライマリノードからディザスターリカバリーノードにレプリケートされます。

前提条件

ディザスターリカバリーノードをセットアップする前に、以下の前提条件に注意してください。
  • ディザスターリカバリー設定を有効にするには、プライマリサイトに高可用性モードで構成されたNetScaler Consoleノードが必要です。
  • NetScaler Console HAペア(プライマリサイト内)とスタンドアロンノード(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 が高可用性モードで展開されていることを確認してください。NetScaler Console を高可用性で展開する方法については、「高可用性展開」を参照してください。
注
  • 高可用性モードで展開された NetScaler Console は、NetScaler Console リリースバージョン 13.1 にアップグレードする必要があります。
  • プライマリノードにディザスターリカバリーノードを登録するには、フローティング IP アドレスが必須です。

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

NetScaler Console ディザスターリカバリーノードを登録するには:
  1. NetScalerサイトから.xvaイメージファイルをダウンロードし、ハイパーバイザーにインポートします。
  2. Consoleタブから、NetScaler Consoleに初期ネットワーク設定を構成します。
    注
    ディザスタリカバリノードは、異なるサブネット上に配置できます。
    ディザスタリカバリノード
  3. 初期ネットワーク設定が完了すると、システムはログインを促します。次の資格情報を使用してログオンします – nsrecover/nsroot。
    重要
    登録中にDRノードの資格情報 (nsrecover/nsroot) を変更しないでください。DRノードを正常に登録した後で、DRノードの資格情報を変更できます。
  4. ディザスタリカバリノードを展開するには、「/mps/deployment_type.py」と入力してEnterキーを押します。NetScaler Consoleの展開構成メニューが表示されます。
    構成メニュー
  5. ディザスタリカバリノードを登録するには、2を選択します。
    ノードの登録
  6. コンソールは、高可用性ノードのフローティングIPアドレスとパスワードを要求します。
  7. フローティングIPアドレスとパスワードを入力して、ディザスタリカバリノードをプライマリノードに登録します。
    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. Disaster Recoveryページで、Deploy DR Nodeを選択します。
  3. 確認ダイアログボックスが表示されます。続行するにはYesをクリックします。
    注
    システムバックアップにかかる時間は、データサイズとWANリンク速度によって異なります。
NetScaler Console GUIでDRノードを正常に展開した後、DRノードのデータベースの状態、メモリ、CPU、およびディスク使用量を監視できます。
災害復旧設定を無効にするには、「DRノードの削除」を選択します。確認ダイアログボックスが表示されます。続行するには「はい」をクリックします。
DRノードを再度有効にするには、高可用性ペアのDRノードを再構成します。
  1. ハイパーバイザーまたはSSHコンソールを使用してDRノードにログオンします。
  2. DRノードは、DRコンソールを使用してNetScaler Console災害復旧ノードを展開および登録するで利用可能な手順に従って構成します。
詳細については、FAQを参照してください。
重要
  • プライマリサイトで災害が発生したことを検出するのは管理者の責任です。
  • 災害復旧ワークフローは、プライマリサイトがダウンした後、管理者によって手動で開始されます。
  • 管理者は、リカバリサイトの災害復旧ノードで復旧スクリプトを実行して、プロセスを手動で開始する必要があります。
  • プライマリサイトでHAペアをアップグレードする場合、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インスタンスは、新しいプライマリサイトとなった災害復旧ノードにデータを送信するように自動的に再構成されます。
    次の図は、プライマリサイトが災害に見舞われた後の災害復旧ワークフローを示しています。
    災害復旧ワークフロー(/en-us/netscaler-application-delivery-management-software/media/drpostdisaster.png)
    注:
    DRサイトでスクリプトを起動すると、DRサイトが新しいプライマリサイトになります。DRユーザーインターフェイスにもアクセスできます。

災害復旧後

災害が発生し、管理者が復旧スクリプトを起動すると、DRサイトが新しいプライマリサイトになります。
後で構成を元のサイトに戻したい場合は、「構成を元のプライマリサイトに戻す」を参照してください。
重要
  • 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プライマリノードを経由して流れます。