Witness（監視）機能 [StarWind vSAN]

投稿日: 2023年9月27日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

今日では、ほとんどのビジネス業務はアプリケーションに直接依存しており、その結果、ITインフラにも依存しています。したがって、アプリケーションに24時間365日のアップタイムと高可用性を提供することは、円滑なビジネス運営を確保するための確実で重要な方法です。クラスタリング・メカニズムはこれらの目標を達成するために設計されていますが、クラスタを稼働させ続けるためには半分以上のノードが必要です。ストレージクラスタの場合、適切なノード通信を確保するために、効果的で簡単な方法は冗長ハートビート接続を使用することです。しかし地理的に分散したクラスタでは、これは必ずしも選択肢ではありません。このような制限を克服するために、ノードマジョリティメカニズムが導入されました。

クラスタ環境の問題点

クラスタ環境は、アプリケーションに対して単一のエンティティを提供し、高可用性、負荷分散、およびシステムのスケーラビリティを保証する、統一されたサーバのグループ（ノード）です。一方で、偶数のノードで構成されるクラスタでは、ノードの半分が故障するとフェイルオーバークラスタがオフラインになり、データやアプリケーションにアクセスできなくなります。

さらに、クラスタノードが適切な投票メカニズムを持たず、相互間のネットワーク通信を失った場合、スプリットブレインが発生し、データの破損につながる可能性があります。このようなシナリオでは、バックアップからデータを復元するしかありません。クラスタノードが異なる場所に分散している場合、サイト間のネットワーク接続を冗長化することで、単一障害点を回避することができます。しかし、複数のファイバ接続を持つことは常に可能であるとは限らず、しばしばコストがかかります。

ノード マジョリティとは何か、なぜWitness（ウィットネス）インスタンスが必要なのか?

ノードの数が偶数の場合にクラスタとそのすべてのVMおよびアプリケーションの可用性を確保するために、StarWindではいわゆるWitness ノード（ノード マジョリティ メカニズム）を導入しています。Witnessノードはクォーラム投票に参加する独立したインスタンスですが、その展開に必要なリソースは最小限です。StarWind 環境に Witness ノードを導入することで、2 ノード クラスターは、いずれかのノードに障害が発生しても実行を継続できます。

独立した StarWind Witnessノードがあれば、定足数を作成し、クラスタの可用性を確保するもう 1 つのインスタンスがあるため、スプリット ブレインの可能性は完全に排除されます。さらに、Witnessノード インスタンスをクラウドに展開することで、複数の場所に分散したクラスタが最大限の稼働率を示し、保守のためにハードウェアを追加する必要がなくなります。

結論：StarWind は、クラウド上のWitnessを持つ 2 ノード クラスタで高可用性(HA)を保証

StarWind のノード マジョリティ メカニズムにより、StarWind ストレージ クラスタが最小限のダウンタイムで稼働していることが保証されます。さらに、StarWind はクラウド・ウィットネスを含め、Witnessを設定するための柔軟なオプションを提供しているため、導入が非常に簡単です。どのようなITインフラストラクチャ構成であっても、StarWindはそのパフォーマンスを最大限に発揮し、いかなる災害にも関係なく、アプリケーションの高い常時稼働率とHAを維持します。

▶ StarWind Virtual SAN (vSAN)の機能一覧

StarWind Virtual SAN (vSAN)の機能詳細一覧

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。