災害とは、自然災害または人為的な出来事によって引き起こされるビジネス機能の突然の混乱です。 災害はデータセンターの運用に影響を及ぼし、その後、災害現場で失われたリソースとデータを完全に再構築して復元する必要があります。 データセンターにおけるデータの損失やダウンタイムは重大であり、ビジネスの継続性を崩壊させます。
NetScaler コンソールの災害復旧 (DR) 機能は、高可用性モードで展開された NetScaler コンソールの完全なシステム バックアップおよび復旧機能を提供します。 リカバリ時には、証明書、構成ファイル、およびデータベースの完全なバックアップがリカバリ サイトで利用可能になります。
次の表では、NetScaler コンソールで災害復旧を構成する際に使用される用語について説明します。
| 条項 | 説明 |
|---|---|
| プライマリサイト（データセンターA） | プライマリ サイトには、高可用性モードで展開された NetScaler コンソール ノードがあります。 |
| リカバリサイト（データセンターB） | リカバリ サイトには、スタンドアロン モードで展開された災害復旧ノードがあります。 このノードは読み取り専用モードであり、プライマリ サイトがダウンするまで動作しません。 |
| 災害復旧ノード | リカバリ ノードは、リカバリ サイトに展開されるスタンドアロン ノードです。 このノードは、プライマリ サイトで災害が発生して機能しなくなった場合に備えて、(新しいプライマリに対して) 動作可能になります。 |
注記
プライマリ サイトと DR サイトはポート 5454 と 22 を介して相互に通信し、これらのポートはデフォルトで有効になっています。
ポートとプロトコルの詳細については、「 ポート」を参照してください。
次の図は、災害復旧ワークフロー、災害前の初期設定、および災害後のワークフローを示しています。
この画像は災害発生前の災害復旧のセットアップを示しています。
プライマリ サイトには、高可用性モードで展開された NetScaler コンソール ノードがあります。 詳細については、 高可用性展開を参照してください。
リカバリ サイトには、スタンドアロンの NetScaler Console ディザスタ リカバリ ノードがリモートで展開されています。 災害復旧ノードは読み取り専用モードであり、プライマリノードからデータを受信してデータのバックアップを作成します。 リカバリ サイトの NetScaler インスタンスも検出されますが、それらを通過するトラフィックはありません。 バックアップ プロセス中に、すべてのデータ、ファイル、および構成がプライマリ ノードから災害復旧ノードに複製されます。
災害復旧ノードをセットアップする前に、次の前提条件に注意してください。
災害復旧設定を有効にするには、プライマリ サイトで NetScaler Console ノードが高可用性モードで構成されている必要があります。
NetScaler コンソール HA ペア (プライマリ サイト内) とスタンドアロン ノード (DR サイト内) のソフトウェア バージョン、ビルド、および構成は同じである必要があります。
スケジュール動作とネットワーク遅延を改善するには、CPU 優先度 (仮想マシンのプロパティ) を最高レベルに設定することをお勧めします。
次の表は、災害復旧ノードを構成するための最小要件を示しています。
| 成分 | 要件 |
|---|---|
| ラム | 32GB |
| 仮想CPU | 8個のCPU |
| 収納スペース | NetScaler コンソールの展開には、ソリッド ステート ドライブ (SSD) テクノロジを使用することをお勧めします。 デフォルト値は 120 GB です。 実際のストレージ要件は、NetScaler コンソールのサイズ見積もりによって異なります。 NetScaler コンソールのストレージ要件が 120 GB を超える場合は、追加のディスクを接続する必要があります。 注意 追加できるディスクは 1 枚だけです。 初期展開時にストレージを見積もり、ディスクを追加接続することをお勧めします。 詳細については、「 NetScaler コンソールに追加のディスクを接続する方法」を参照してください。 |
| 仮想ネットワークインターフェース | 1 |
| スループット | 1 Gbps または 100 Mbps |
| ハイパーバイザー | バージョン |
| Citrix ハイパーバイザー | 6.2と6.5 |
| VMware ESXi | 5.5と6.0 |
| マイクロソフト Hyper-V | 2012 R2 |
| Linux KVM | UbuntuとFedora |
NetScalerコンソールを高可用性モードで展開する
NetScalerコンソールの災害復旧ノードを展開して登録する
ユーザーインターフェースから災害復旧設定を有効または無効にする
災害復旧設定を行うには、NetScaler コンソールが高可用性モードで展開されていることを確認します。 NetScaler コンソールを高可用性で展開する方法については、「 高可用性展開」を参照してください。
注記
高可用性モードで展開された NetScaler コンソールは、NetScaler コンソール リリース バージョン 13.1 にアップグレードする必要があります。
フローティング IP アドレスは、災害復旧ノードをプライマリ ノードに登録するには必須です 。
NetScaler コンソールの災害復旧ノードを登録するには:
NetScaler サイトから .xva イメージ ファイルをダウンロードし、ハイパーバイザーにインポートします。
コンソール タブから、初期ネットワーク構成を使用して NetScaler コンソールを構成します。
注記
災害復旧ノードは別のサブネット上に配置できます。
初期ネットワーク構成が完了すると、ログインを求めるメッセージが表示されます。 次の資格情報を使用してログオンします – nsrecover/nsroot。
重要
登録中に DR ノードの資格情報 (
nsrecover/nsroot) を変更しないでください。 DR ノードを正常に登録した後、DR ノードの資格情報を変更できます。
災害復旧ノードをデプロイするには、 /mps/deployment_type.py と入力して Enter キーを押します。 NetScaler コンソールの展開構成メニューが表示されます。
災害復旧ノードを登録するには、 2 を選択します。
コンソールに、高可用性ノードのフローティング IP アドレスとパスワードの入力が求められます。
フローティング IP アドレスとパスワードを入力して、災害復旧ノードをプライマリ ノードに登録します。
災害復旧ノードが正常に登録されました。
注記
災害復旧ノードには GUI がありません。
登録が成功すると、サーバーにログオンするためのデフォルトの管理者資格情報は
nsroot/nsrootになります。
DR ノードのパスワードを変更する場合は、次のスクリプトを実行します。
/mps/change_freebsd_password.sh <username> <password>
<!--NeedCopy-->
例:
/mps/change_freebsd_password.sh nsroot 新しいパスワード
<!--NeedCopy-->
DR コンソールを使用して災害復旧ノードが正常に登録されたら、NetScaler コンソール GUI から DR ノードを展開します。 この手順により、NetScaler コンソール プライマリ サイトからの災害復旧設定が有効になります。
システム > システム管理 > 災害復旧設定に移動します。
ディザスター リカバリ ページで、 DR ノードのデプロイを選択します。
確認ダイアログボックスが表示されます。 続行するには、[ はい ] をクリックします。
注記
システム バックアップにかかる時間は、データ サイズと WAN リンク速度によって異なります。
NetScaler コンソール GUI で DR ノードを正常に展開すると、DR ノードのデータベースの状態、メモリ、CPU、およびディスク使用量を監視できます。
災害復旧設定を無効にするには、 DR ノードの削除を選択します。 確認ダイアログボックスが表示されます。 続行するには、[ はい ] をクリックします。
DR ノードを再度有効にするには、高可用性ペアの DR ノードを再構成します。
ハイパーバイザーまたは SSH コンソールを使用して DR ノードにログオンします。
DR コンソールを使用して NetScaler コンソール災害復旧ノードを展開および登録するの手順に従って DR ノードを構成します。
詳細については、 FAQをご覧ください。
重要
プライマリ サイトで災害が発生したことを検出するのは管理者の責任です。
災害復旧ワークフローは、プライマリ サイトがダウンした後に管理者によって手動で開始されます。
管理者は、リカバリ サイトの災害復旧ノードでリカバリ スクリプトを実行して、プロセスを手動で開始する必要があります。
プライマリ サイトの HA ペアをアップグレードする場合は、DR サイトのスタンドアロン ノードも手動でアップグレードする必要があります。
災害発生後にプライマリ サイトがダウンした場合は、次のように災害復旧ワークフローを開始する必要があります。
管理者は、プライマリ サイトに災害が発生し、プライマリ サイトが動作不能になっていることを確認します。
管理者が回復プロセスを開始します。
管理者は、要件に基づいて、災害復旧ノードで次のいずれかの復旧スクリプトを手動で実行する必要があります (復旧サイト)。
DR ノードで SNMP、Syslog、および Analytics を構成します。
/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-->
内部的には、NetScaler インスタンスは自動的に再構成され、新しいプライマリ サイトとなった災害復旧ノードにデータが送信されます。
次の図は、プライマリ サイトに災害が発生した後の災害復旧ワークフローを示しています。
注記：
DR サイトでスクリプトを開始すると、DR サイトが新しいプライマリ サイトになります。 DR ユーザー インターフェイスにアクセスすることもできます。
災害が発生し、管理者が復旧スクリプトを開始すると、DR サイトが新しいプライマリ サイトになります。
後で構成を元のサイトに戻す場合は、「 構成を元のプライマリ サイトに戻す」を参照してください。
重要
NetScaler Console 12.1.49.x 以前のリリースをインストールしている場合は、Citrix に連絡して元のライセンスを NetScaler Console (DR サイト) に再ホストするための 30 日間の猶予期間が与えられます。
12.1.50.x 以降のリリースでは、NetScaler コンソール ライセンスは DR サイトに自動的に同期されます (ライセンスについて Citrix に連絡する必要はありません)。
インスタンスにプールされたライセンスを適用している場合、バージョン 11.1 65.x 以降、 12.1 58.x 以降、 13.0 47.x 以降、および NetScaler SDX 13.0 76.x 以降 の NetScaler インスタンスでは、DR サイトでの自動ライセンス サーバー更新がサポートされます。 その他のすべてのバージョンでは、インスタンスを DR サイトに手動で再構成する必要があります。
災害発生後、構成された災害復旧 (DR) ノードが新しいプライマリ サイトになり、クライアント トラフィックはこのノードを通過します。
詳細については、「 災害後のワークフロー」を参照してください。
元のプライマリ サイトに災害が発生しておらず、すべての操作をプライマリ サイトに移行する場合は、DR ノードの構成と一致するように元のプライマリ サイトを再構成します。
開始する前に、プライマリ サイトと DR サイトの両方がアクティブであることを確認してください。
DR サイトから元のプライマリ サイトへの変更を戻すには、次の手順を実行します。
元のプライマリ サイトにログインし、次のコマンドを実行します。
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 アドレスを取得し、プライマリ サイトをプールされたライセンス サーバーとして再構成します。
DR サイトを再構成します。 参照: 災害復旧セットアップの展開。
DR サイトから元のプライマリ サイトに構成を正常に戻すと、クライアント トラフィックは NetScaler コンソール プライマリ ノードを通過します。