Google Cloud のCloud Volumes ONTAP HA ペアについて学ぶ
変更を提案
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 つの仮想プライベート クラウド (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インスタンスが使用されていました）
- ディスク
-
それぞれ 10 GiB の標準永続ディスク 2 つ
- オペレーティング システム
-
Debian 11
Cloud Volumes ONTAP 9.10.0 以前では、Debian 10 がメディエーターにインストールされていました。 - アップグレード
-
Cloud Volumes ONTAPをアップグレードすると、 NetAppコンソールは必要に応じてメディエーター インスタンスも更新します。
- インスタンスへのアクセス
-
Debianの場合、デフォルトのクラウドユーザーは
admin。 Google Cloudは、adminGoogle Cloud コンソールまたは gcloud コマンドラインから SSH アクセスが要求された場合のユーザー。指定できます `sudo`ルート権限を取得します。 - サードパーティエージェント
-
サードパーティ エージェントまたは VM 拡張機能は、メディエーター インスタンスではサポートされません。
ストレージの引き継ぎと返却
1 つのノードがダウンした場合、他のノードがパートナーにデータを提供して、継続的なデータ サービスを提供します。データはパートナーに同期的にミラーリングされているため、クライアントはパートナー ノードから同じデータにアクセスできます。
ノードが再起動した後、パートナーはストレージを返す前にデータを再同期する必要があります。データの再同期にかかる時間は、ノードがダウンしている間に変更されたデータの量によって異なります。
ストレージのテイクオーバー、再同期、ギブバックはすべてデフォルトで自動で行われます。ユーザーの操作は必要ありません。
RPOおよびRTO
HA 構成では、次のようにデータの高可用性が維持されます。
-
Recovery Point Objective（RPO;目標復旧時点）は0秒です。
データはトランザクションの整合性が確保されており、データ損失はありません。
-
Recovery Time Objective（RTO;目標復旧時間）は120秒です。
障害が発生した場合、データは120秒以内に使用可能になります。
HA展開モデル
複数のゾーンまたは単一のゾーンに HA 構成を展開することで、データの高可用性を確保できます。
- 複数のゾーン（推奨）
-
3 つのゾーンにわたって HA 構成を展開すると、ゾーン内で障害が発生した場合でも継続的なデータ可用性が確保されます。書き込みパフォーマンスは単一ゾーンを使用する場合と比べてわずかに低下しますが、最小限であることに注意してください。
- 単一ゾーン
-
単一のゾーンにデプロイされる場合、 Cloud Volumes ONTAP HA 構成では、スプレッド配置ポリシーが使用されます。このポリシーにより、障害の分離を実現するために個別のゾーンを使用する必要がなく、ゾーン内の単一障害点から HA 構成が保護されます。
このデプロイメント モデルでは、ゾーン間のデータ送信料金が発生しないため、コストが削減されます。
HAペアにおけるストレージの仕組み
ONTAPクラスターとは異なり、GCP のCloud Volumes ONTAP HA ペアのストレージはノード間で共有されません。代わりに、障害発生時にデータが利用できるように、データはノード間で同期的にミラーリングされます。
ストレージ割り当て
新しいボリュームを作成し、追加のディスクが必要になった場合、コンソールは両方のノードに同じ数のディスクを割り当て、ミラー化されたアグリゲートを作成してから、新しいボリュームを作成します。たとえば、ボリュームに 2 つのディスクが必要な場合、コンソールはノードごとに 2 つのディスクを割り当て、合計 4 つのディスクを割り当てます。
ストレージ構成
HA ペアは、両方のノードがクライアントにデータを提供するアクティブ/アクティブ構成として使用することも、アクティブ ノードのストレージを引き継いだ場合にのみパッシブ ノードがデータ要求に応答するアクティブ/パッシブ構成として使用することもできます。
HA構成のパフォーマンス期待値
Cloud Volumes ONTAP HA 構成では、ノード間でデータが同期的に複製されるため、ネットワーク帯域幅が消費されます。その結果、単一ノードのCloud Volumes ONTAP構成と比較して、次のパフォーマンスが期待できます。
-
1 つのノードからのみデータを提供する HA 構成の場合、読み取りパフォーマンスは単一ノード構成の読み取りパフォーマンスに匹敵しますが、書き込みパフォーマンスは低くなります。
-
両方のノードからデータを提供する HA 構成の場合、読み取りパフォーマンスは単一ノード構成の読み取りパフォーマンスよりも高く、書き込みパフォーマンスは同じかそれ以上になります。
Cloud Volumes ONTAPのパフォーマンスの詳細については、以下を参照してください。"パフォーマンス" 。
ストレージへのクライアントアクセス
クライアントは、ボリュームが存在するノードのデータ IP アドレスを使用して NFS および CIFS ボリュームにアクセスする必要があります。 NAS クライアントがパートナー ノードの IP アドレスを使用してボリュームにアクセスすると、トラフィックが両方のノード間で行われ、パフォーマンスが低下します。
|
HA ペアのノード間でボリュームを移動する場合は、他のノードの IP アドレスを使用してボリュームを再マウントする必要があります。そうしないと、パフォーマンスが低下する可能性があります。クライアントが NFSv4 参照または CIFS のフォルダー リダイレクトをサポートしている場合は、 Cloud Volumes ONTAPシステムでこれらの機能を有効にして、ボリュームの再マウントを回避できます。詳細については、 ONTAP のドキュメントを参照してください。 |
ボリュームを選択し、*マウント コマンド*をクリックすると、コンソールから正しい IP アドレスを見つけることができます。
