NetScaler Console

高可用性向けにディザスタリカバリを構成する

災害とは、自然災害または人為的な事象によって引き起こされるビジネス機能の突然の中断です。災害はデータセンターの運用に影響を与え、その後、災害サイトで失われたリソースとデータは完全に再構築され、復元される必要があります。データセンターでのデータ損失やダウンタイムは致命的であり、事業継続性を損ないます。

NetScaler Consoleのディザスタリカバリ(DR)機能は、高可用性モードで展開されたNetScaler Console向けに、完全なシステムバックアップおよびリカバリ機能を提供します。リカバリ時には、証明書、構成ファイル、およびデータベースの完全なバックアップがリカバリサイトで利用可能です。

次の表は、NetScaler Consoleでディザスタリカバリを構成する際に使用される用語について説明しています。

用語 詳細説明
プライマリサイト(データセンターA) プライマリサイトには、高可用性モードで展開されたNetScaler Consoleノードがあります。
リカバリサイト(データセンターB) リカバリサイトには、スタンドアロンモードで展開されたディザスタリカバリノードがあります。このノードは読み取り専用モードであり、プライマリサイトがダウンするまで動作しません。
ディザスタリカバリノード リカバリノードは、リカバリサイトに展開されたスタンドアロンノードです。プライマリサイトで災害が発生し、機能しなくなった場合に、このノードが(新しいプライマリとして)動作可能になります。

プライマリサイトとDRサイトは、ポート5454と22を介して相互に通信し、これらのポートはデフォルトで有効になっています。

ポートとプロトコルの詳細については、ポートを参照してください。

基本認証を有効にする

基本認証は、一時的に有効にする必要があります。目的は次のとおりです。

  • エージェントとディザスタリカバリノードの初期登録を完了する。

  • NetScaler GUIからライセンスアクティベーションシステム (LAS) のチェックアウトを開始する。

基本認証は、初期登録にのみ必要です。

基本認証を構成する

  1. 設定 > 管理 > システム構成 > システム、タイムゾーン、許可されたURL、およびエージェント設定」に移動します。
  2. 基本設定」をクリックします。
  3. 基本認証を許可する」を有効にする、を選択します。
  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 ギガビット/秒 または 100 メガビット/秒
ハイパーバイザー バージョン
シトリックス ハイパーバイザー 6.2および6.5
ヴイエムウェア ESXi 5.5および6.0
マイクロソフト ハイパーV 2012 R2
リナックス ケーブイエム ウブントゥおよびフェドラ

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

  • 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>
    <!--NeedCopy-->
    

    /mps/change_freebsd_password.sh nsroot new_password
    <!--NeedCopy-->
    

NetScaler Console GUIを使用して災害復旧ノードを展開する

DRコンソールを使用して災害復旧ノードが正常に登録されたら、NetScaler Console GUIからDRノードを展開します。この手順により、NetScaler Consoleプライマリサイトから災害復旧設定が有効になります。

  1. システム > システム管理 > 災害復旧設定に移動します。

  2. 災害復旧ページで、DRノードの展開を選択します。

  3. 確認ダイアログボックスが表示されます。続行するにはYesをクリックします。

    システムバックアップにかかる時間は、データサイズとWANリンク速度によって異なります。

NetScaler Console GUIでDRノードを正常に展開した後、DRノードのデータベースの状態、メモリ、CPU、およびディスク使用量を監視できます。

ディザスターリカバリ設定を無効にするには、DRノードの削除を選択します。確認ダイアログボックスが表示されます。続行するには、はいをクリックします。

DRノードを再度有効にするには、高可用性ペアのDRノードを再構成します。

  1. ハイパーバイザーまたはSSHコンソールを使用してDRノードにログオンします。

  2. DRノードを構成するには、DRコンソールを使用してNetScaler Consoleディザスターリカバリノードを展開して登録するの手順に従います。

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

詳細については、FAQを参照してください。

重要

  • プライマリサイトで障害が発生したことを検出するのは管理者の責任です。

  • ディザスターリカバリワークフローは、プライマリサイトがダウンした後、管理者によって手動で開始されます。

  • 管理者は、リカバリサイトのディザスターリカバリノードでリカバリスクリプトを実行して、プロセスを手動で開始する必要があります。

  • プライマリサイトのHAペアをアップグレードする場合、DRサイトのスタンドアロンノードも手動でアップグレードする必要があります。

障害発生後のワークフロー

障害発生後にプライマリサイトがダウンした場合、ディザスターリカバリワークフローは次のように開始する必要があります。

  1. 管理者は、プライマリサイトに障害が発生し、動作していないことを特定します。

  2. 管理者はリカバリプロセスを開始します。

  3. 管理者は、要件に基づいて、災害復旧ノード(復旧サイト)で以下のいずれかの復旧スクリプトを手動で実行する必要があります。

    • 災害復旧ノードでSNMP、シスログ、およびアナリティクスを設定します。

       /mps/scripts/pgsql/pgsql\_restore\_remote\_backup.sh
      
       <!--NeedCopy-->
      
    • DRノードをライセンスサーバーとしても構成します。

      
       /mps/scripts/pgsql/pgsql\_restore\_remote\_backup.sh -reconfig-ls <IP-address-of-the-primary-site>
      
       <!--NeedCopy-->
      
  4. 内部的には、NetScalerインスタンスは、新しいプライマリサイトとなった災害復旧ノードにデータを送信するように自動的に再構成されます。

    次の図は、プライマリサイトが災害に見舞われた後の災害復旧ワークフローを示しています。

    災害復旧ワークフロー(/ja-jp/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) ノードが新しいプライマリサイトとなり、クライアントトラフィックはこのノードを経由して流れます。

災害後のセットアップ(/ja-jp/netscaler-application-delivery-management-software/media/disaster-recovery-node-active-console.png)

詳細については、「災害後のワークフロー(#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> &
    <!--NeedCopy-->
    

    このコマンドは、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 &
    <!--NeedCopy-->
    

    -Oコマンドは、DRサイトのIPアドレスを取得し、プライマリサイトをプールライセンスサーバーとして再構成します。

  2. DRサイトを再構成します。「災害復旧セットアップの展開(#first-time-disaster-recovery-setup)」を参照してください。

元のプライマリサイトに戻す(/ja-jp/netscaler-application-delivery-management-software/media/revert-to-original-primary-site-console.png)

DRサイトから元のプライマリサイトへの設定の復元が正常に完了すると、クライアントトラフィックはNetScaler Consoleプライマリノードを経由して流れます。

高可用性向けにディザスタリカバリを構成する