Application Delivery Management

高可用性を実現するためのディザスタリカバリの構成

June 19, 2024

寄稿者:

災害（さいがん）とは、自然の災害、または人為的な出来事によって引き起こされる事業機能の突然の混乱である。災害はデータセンターの運用に影響を及ぼします。その後、災害現場で失われたリソースとデータを完全に再構築して復元する必要があります。データ消失やデータセンターのダウンタイムは重要であり、ビジネス継続性が低下します。

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

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

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

注

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

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

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

次の図は、災害復旧ワークフロー、災害前の初期設定、および災害後のワークフローを示しています。

災害発生前の初期設定

初期セットアップ

この図は、ディザスタ前のディザスタリカバリ設定を示しています。

プライマリサイトには、高可用性モードで展開されたNetScaler Consoleノードがあります。詳しくは、「高可用性展開」を参照してください

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

前提条件

障害回復ノードをセットアップする前に、次の前提条件に注意してください：

障害復旧設定を有効にするには、プライマリサイトのNetScaler Consoleノードが高可用性モードで構成されている必要があります。
NetScaler Console HAペア（プライマリサイト）とスタンドアロンノード（DRサイト内）のソフトウェアバージョン、ビルド、および構成が同じである必要があります。

スケジューリング動作とネットワーク遅延を改善するために、CPU 優先度を (仮想マシンのプロパティで) 最高レベルに設定することをお勧めします。

次の表は、ディザスタリカバリノードを設定するための最小要件を示しています：

コンポーネント	条件
RAM	32 GB
仮想CPU	8基のCPU
記憶域	NetScaler Consoleの展開には、ソリッドステートドライブ（SSD）テクノロジーを使用することをお勧めします。デフォルト値は120GBです。実際のストレージ要件は、NetScaler Consolerコンソールのサイズ見積もりによって異なります。NetScaler Consoleのストレージ要件が120 GBを超える場合は、追加のディスクを接続する必要があります。注: 追加できるディスクは 1 つだけです。初期導入時には、ストレージを見積もり、ディスクを追加することをお勧めします。詳しくは、「 NetScaler コンソールに追加ディスクを接続する方法」を参照してください。
仮想ネットワークインターフェイス	1
スループット	1Gbpsまたは100Mbps
ハイパーバイザー	バージョン
Citrix Hypervisor	6.2 と 6.5
VMware ESXi	5.5 と 6.0
Microsoft Hyper-V	2012 R2
Linux KVM	UbuntuとFedora

初めてのディザスタリカバリのセットアップ

NetScaler コンソールを高可用性モードで展開
NetScaler コンソールのディザスタリカバリノードを展開して登録する
ユーザーインターフェイスからディザスタリカバリ設定を有効または無効にする

NetScaler コンソールを高可用性モードで展開

ディザスタリカバリの設定を行うには、NetScaler Consoleが高可用性モードで展開されていることを確認してください。 NetScaler Consoleを高可用性で展開する方法については、「高可用性展開」を参照してください。

注

高可用性モードで展開されたNetScalerコンソールは、NetScalerコンソールリリースバージョン13.1にアップグレードする必要があります。

障害復旧ノードをプライマリノードに登録するには、Floating IPアドレスが必須 です。

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

NetScaler コンソールのディザスタリカバリノードを登録するには：

.xva NetScalerサイトからイメージファイルをダウンロードし、ハイパーバイザーにインポートします。
［ コンソール ］タブから、NetScaler Consoleを初期ネットワーク構成で構成します。

注

災害復旧ノードは、別のサブネット上に配置できます。
初期ネットワーク設定が完了すると、ログインのプロンプトが表示されます。次の認証情報を使用してログオンします — nsrecover/nsroot.

重要

:登録中に DR ノードの認証情報 (nsrecover/nsroot) を変更しないでください。DR ノードが正常に登録されたら、DR ノードの認証情報を変更できます。
災害復旧ノードを展開するには、 /mps/deployment_type.py と入力し、Enter キーを押します。NetScaler コンソールの展開構成メニューが表示されます。
災害復旧ノードを登録するには、[ 2 ] を選択します。
コンソールは、高可用性ノードの Floating IP アドレスとパスワードを要求します。
Floating IP アドレスとパスワードを入力して、障害復旧ノードをプライマリノードに登録します。

これで、災害復旧ノードが正常に登録されました。
注
- ディザスタリカバリノードには GUI がありません。
- 登録が成功すると、サーバにログオンするためのデフォルトの管理者資格情報はnsroot/nsrootになります。

DR ノードのパスワードを変更する場合は、次のスクリプトを実行します。

/mps/change_freebsd_password.sh <username> <password>
<!--NeedCopy-->

例：

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

NetScalerコンソールのGUIを使用してディザスタリカバリノードをデプロイします

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

[ システム] > [システム管理] > [障害回復の設定] に移動します。
「 障害回復 」ページで、「 DR ノードのデプロイ」を選択します。
確認ダイアログが表示されます。［Yes］をクリックして続行します。

注

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

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

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

DR ノードを再度有効にするには、高可用性ペアの DR ノードを再設定します：

Hypervisor または SSH コンソールを使用して DR ノードにログオンします。
「デプロイ」に記載されている手順に従ってDRノードを構成し、DRコンソールを使用してNetScaler Consoleディザスタリカバリノードを登録します。
NetScalerコンソールGUIを使用してディザスタリカバリノードを展開します。

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

重要

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

災害復旧ワークフローは、プライマリサイトがダウンした後、管理者が手動で開始します。

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

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

災害後のワークフロー

障害発生後にプライマリサイトがダウンした場合は、災害復旧ワークフローを次のように開始する必要があります。

管理者は、プライマリ・サイトが障害に見舞われ、そのサイトが稼働していないことを確認しました。
管理者がリカバリプロセスを開始します。
管理者は、（リカバリサイトで）要件に基づいて、障害復旧ノードで次のいずれかのリカバリスクリプトを手動で実行する必要があります。
- DR ノードでの SNMP、Syslog、および分析の把握：
```
 /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>

 
```
内部的には、NetScaler インスタンスは、新しいプライマリサイトになった災害復旧ノードにデータを送信するように自動的に再構成されます。

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

Note:

DR サイトでスクリプトを開始すると、DR サイトが新しいプライマリサイトになります。また、DR ユーザーインターフェイスにアクセスすることもできます。

災害復旧後

災害が発生し、管理者がリカバリ・スクリプトを開始すると、DRサイトが新しいプライマリ・サイトになります。

後で構成を元のサイトに戻す場合は、「構成を元のプライマリサイトに戻す」を参照してください。

重要

NetScaler Console 12.1.49.x以前のリリースをインストールしている場合、Citrix に連絡してNetScalerコンソール（DRサイト）で元のライセンスを再ホストするための30日間の猶予期間があります。

12.1.50.x以降のリリースでは、NetScaler Consoleライセンスは自動的にDRサイトと同期されます（ライセンスについてCitrix に問い合わせる必要はありません）。

インスタンスにプールライセンスを適用した場合、バージョン11.1 65.x以降、12.1 58.x以降、13.0 47.x以降のNetScaler、および13.0 76.x以降のNetScalerSDXでは、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> &

```
このコマンドは、プライマリサイトに 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 アドレスを取得し、プライマリサイトをプールライセンスサーバーとして再構成します。
DR サイトを再構成します。ディザスタリカバリのセットアップを展開するを参照してください。

元のプライマリ・サイトに戻す

DRサイトから元のプライマリサイトに構成を正常に戻すと、クライアントトラフィックはNetScaler Consoleプライマリノードを経由します。

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

高可用性を実現するためのディザスタリカバリの構成

June 19, 2024

寄稿者:

June 19, 2024

寄稿者:

この情報は役に立ちましたか?