Google Cloud のハイアベイラビリティペア
変更を提案
PDF
Cloud Volumes ONTAPのハイアベイラビリティ（HA）構成は、ノンストップオペレーションとフォールトトレランスを実現します。Google Cloudでは、2つのノード間でデータが同期ミラーリングされます。
HA コンポーネント
Google CloudのCloud Volumes ONTAP HA構成には、次のコンポーネントが含まれています。
-
データが同期的にミラーリングされる 2 つの Cloud Volumes ONTAP ノード。
-
ストレージのテイクオーバーとギブバックプロセスを支援するためにノード間の通信チャネルを提供するメディエータインスタンス。
-
1 つまたは 3 つのゾーン（推奨）。
3 つのゾーンを選択すると、 2 つのノードとメディエーターが別々の Google Cloud ゾーンに配置されます。
-
4 つの Virtual Private Cloud （ VPC ；仮想プライベートクラウド）
GCP では各ネットワークインターフェイスが別々の VPC ネットワークに存在する必要があるため、構成では 4 つの VPC を使用します。
-
Cloud Volumes ONTAP HA ペアへの着信トラフィックを管理する 4 つの Google Cloud 内部ロードバランサ（ TCP / UDP ）。
"ネットワーク要件について説明します"ロードバランサ、 VPC 、内部 IP アドレス、サブネットなどの詳細が含まれます。
次の概念図は、 Cloud Volumes ONTAP HA ペアとそのコンポーネントを示しています。
メディエーター
Google Cloud のメディエーターインスタンスの重要な詳細を次に示します。
- インスタンスタイプ
-
E2-micro（以前はF1-microインスタンスが使用されていました）
- ディスク
-
それぞれ10GiBの標準的な永続ディスク2本
- オペレーティングシステム
-
Debian 11.
Cloud Volumes ONTAP 9.10.0 以前では、 Debian 10 はメディエーターにインストールされていました。 - アップグレード
-
Cloud Volumes ONTAP をアップグレードすると、必要に応じてメディエーターインスタンスも更新されます。
- インスタンスへのアクセス
-
Debian の場合、デフォルトのクラウドユーザは「 admin 」です。Google Cloud は、 Google Cloud コンソールまたは gcloud コマンドラインから SSH アクセスが要求された場合に、「 admin 」ユーザの証明書を作成して追加します。root 権限を取得するには 'sudo を指定します
- サードパーティのエージェント
-
サードパーティエージェントまたは VM 拡張機能は、メディエーターインスタンスではサポートされていません。
ストレージのテイクオーバーとギブバック
ノードがダウンした場合、もう一方のノードはパートナーにデータを提供して、継続的なデータサービスを提供できます。データはパートナーに同期的にミラーリングされているため、クライアントはパートナーノードから同じデータにアクセスできます。
ノードのリブート後、パートナーはデータを再同期してからストレージを返却する必要があります。データの再同期にかかる時間は、ノードがダウンしている間に変更されたデータの量によって異なります。
ストレージのテイクオーバー、再同期、ギブバックは、すべてデフォルトで自動的に実行されます。ユーザによる操作は必要ありません。
RPO と RTO
HA 構成では、次のようにデータの高可用性が維持されます。
-
RPO （ Recovery Point Objective ：目標復旧時点）は 0 秒です。
データはトランザクション的に整合性が保たれ、データ損失は発生しません。
-
Recovery Time Objective（RTO；目標復旧時間）は120秒です。
システム停止が発生した場合、120秒以内にデータを利用できるようにする必要があります。
HA の導入モデル
複数のゾーンまたは単一のゾーンに HA 構成を導入することで、データの高可用性を確保できます。
- 複数のゾーン（推奨）
-
3 つのゾーンに HA 構成を導入することで、ゾーン内で障害が発生した場合の継続的なデータ可用性を確保できます。書き込みパフォーマンスは、単一のゾーンを使用する場合に比べてわずかに低くなりますが、最小のパフォーマンスです。
- シングルゾーン
-
Cloud Volumes ONTAP HA 構成では、単一のゾーンに導入する場合は分散配置ポリシーを使用します。このポリシーにより、 HA 構成がゾーン内の単一点障害から保護されます。障害の切り分けに別々のゾーンを使用する必要はありません。
この導入モデルでは、ゾーン間にデータ出力料金が発生しないため、コストが削減されます。
HA ペアでのストレージの動作
Cloud Volumes ONTAP クラスタとは異なり、 GCP の ONTAP HA ペアのストレージはノード間で共有されません。代わりに、障害発生時にデータを利用できるように、データはノード間で同期的にミラーリングされます。
ストレージの割り当て
新しいボリュームの作成時に追加のディスクが必要な場合、BlueXPは両方のノードに同じ数のディスクを割り当て、ミラーされたアグリゲートを作成し、新しいボリュームを作成します。たとえば、ボリュームに2つのディスクが必要な場合、BlueXPはノードごとに2つのディスクを割り当て、合計4つのディスクを割り当てます。
ストレージ構成
HA ペアは、アクティブ / アクティブ構成として使用できます。アクティブ / アクティブ構成では、両方のノードがクライアントにデータを提供します。アクティブ / パッシブ構成では、パッシブノードは、アクティブノードのストレージをテイクオーバーした場合にのみデータ要求に応答します。
HA 構成に期待されるパフォーマンス
Cloud Volumes ONTAP HA 構成では、ノード間でデータを同期的にレプリケートするため、ネットワーク帯域幅が消費されます。その結果、シングルノードの Cloud Volumes ONTAP 構成と比較して、次のパフォーマンスが期待できます。
-
1 つのノードからのみデータを提供する HA 構成では、読み取りパフォーマンスはシングルノード構成の読み取りパフォーマンスと同等ですが、書き込みパフォーマンスは低くなります。
-
両方のノードからデータを提供する HA 構成の場合、読み取りパフォーマンスはシングルノード構成の読み取りパフォーマンスよりも高く、書き込みパフォーマンスは同じかそれ以上です。
Cloud Volumes ONTAPのパフォーマンスの詳細については、を参照してください"パフォーマンス"。
ストレージへのクライアントアクセス
クライアントは、ボリュームが存在するノードのデータ IP アドレスを使用して、 NFS ボリュームと CIFS ボリュームにアクセスする必要があります。NAS クライアントがパートナーノードの IP アドレスを使用してボリュームにアクセスする場合、トラフィックは両方のノード間を通過するため、パフォーマンスが低下します。
|
HA ペアのノード間でボリュームを移動する場合は、もう一方のノードの IP アドレスを使用してボリュームを再マウントする必要があります。そうしないと、パフォーマンスが低下する可能性があります。クライアントが CIFS の NFSv4 リファールまたはフォルダリダイレクションをサポートしている場合は、ボリュームの再マウントを回避するために、 Cloud Volumes ONTAP システムでこれらの機能を有効にできます。詳細については、ONTAPのドキュメントを参照してください。 |
BlueXPの[Manage Volumes]パネルにある_Mount Command_Optionを使用すると、正しいIPアドレスを簡単に特定できます。
