web-dev-qa-db-ja.com

ハードウェアRAID1は、冗長性の高いコンピュータークラスターのS/W RAIDに大きな利点をもたらしますか?

5つの物理サーバーノードのLinuxクラスターをセットアップしようとしています(おそらく、後でノードを追加する予定です)。

  • クラスターは Proxmox によって管理されます(はい、ソフトウェアRAIDで動作します)
  • 共有ストレージは、 Gluster in redundantセットアップで実装され、各物理サーバーはブリックを保持します(したがって、データはすべてのマシンから冗長的に利用可能になります)
  • Percona XtraDBクラスター メインのマルチマスターデータベースとして使用されます-データはすべての物理マシンで共有されます
  • rAID1セットアップでは、各マシンに2台のHDDが約2〜3 TBサイズ)あります。
  • すべてのマシンは、冗長電源などを備えた大規模なデータセンターでホストされます。
  • サーバーの仕様を見ることができます ここ
  • クラスタ全体の範囲は、ワークロードを分散し、高可用性を実現することです。マシンは、システム全体に問題を起こすことなく、いつでもダウンする可能性があります。

残された決定の1つは、ソフトウェアRAID1またはハードウェアRAID1 + BBのどちらを使用するかです。

ソフトウェアRAIDは、私がよく知っているソリューションです(15年以来、多くのサーバーを管理しており、ツールがどのように機能するかを知っています)。深刻な問題は発生しませんでした(主にHDDのみが故障します)。これらが理由ですソフトウェアRAIDが好きです

私がハードウェアRAIDについて嫌いなのは、コントローラーベンダー間の非互換性と、それらのベンダーでの経験の欠如です。さまざまな構成オプション、さまざまな監視方法、さまざまなユーティリティプログラムなど、クラスターシステムを作成するのに適していません。

BBUを使用する場合、ハードウェアRAIDはfastreliable(キャッシュを介した書き込み)の両方になり得ることを私は知っています。ただし、すべてのデータは非常に冗長な方法でクラスターに格納されるため、私の考えはソフトウェアRAID1を使用して ファイルシステムのバリアを無効にする書き込みパフォーマンスを向上させることです。これにより、ハードウェアRAID1と同様のパフォーマンスになると思います。もちろん、揮発性の書き込みキャッシュが原因でデータが失われるリスクがありますが、とにかくクラスタリングメカニズムで処理する必要があるIMHO(マシン全体が障害後に他のノードからデータを復元できる必要があります)。

ソフトウェアRAIDの実装に必要なCPUリソースについては心配していません。

私の仮定は正しいですか、それとも正しい選択をするのに役立つ重要な詳細が欠けていますか?

1
Udo G

ハードウェアRAIDは、管理者にRAIDコントローラーのハードウェア障害に対する予防措置を強制するため、単一サーバー上のハードウェアRAIDよりもソフトウェアRAIDの方が好きです。これには通常、予備のRAIDコントローラーをストックして定期的にテストする必要があります。

ただし、セットアップでは、冗長性はディスクレベルではなく、ノードレベルにあると想定しています。ノードに何らかの理由(CPU、電源、レイドコントローラーなど)で障害が発生した場合、そのノードはクラスターから外れ、できるだけ早く新しいノードまたは修復されたノードに置き換えられます。その後、データはクラスターからではなく、クラスターから再構築されます。 RAID。そうは言っても、問題は、RAIDが必要かどうかということです。

「私のデータベースはほとんど読み取り済みです。読み取りは両方のディスクに分散できるため、RAID1ではスループットが約2倍になります」と言うかもしれません。ただし、ディスク障害に続いてそのディスクを交換し、RAIDを再構築すると、そのノードの読み取り速度が一時的に単一ディスクレベルに低下することに注意してください。遅いノードに与えるトラフィックが少ないために、データベースが等しくないノード間で妥当なトラフィックを共有できない場合、データベースが処理できる負荷全体が通常の値の半分に低下します。そのため、内部RAIDの再構築でビジー状態である限り、ディスク障害のあるノードをデータベースから完全に削除する必要が生じる可能性があります。しかし、それはRAIDをほとんど役に立たないものにします。

別の方法は、RAIDを使用しないことですが、ディスクごとに1回ずつ、任意のノードを2回データベースに参加させます。それはCPUにより多くの負担をかけますが、ディスクが制限要因である場合、誰がCPU時間を気にしますか?また、ディスクに障害が発生した場合、ディスクが交換されると、その特定のハーフノードがオフラインになり、再び参加します。したがって、負荷はすべてのディスクに公平に共有されます。

書き込み負荷が高い場合は、個別のディスクソリューションを使用すると、RAID1の2倍の書き込みスループットが得られます。

したがって、基本的に、BBUについてまだ考える唯一の理由は、レイテンシ要件が非常に狭い場合、データが物理的にディスクに送られるのを待つことができないということです。電源障害が発生した場合、BBUはデータが引き続き書き込まれることを保証します。ただし、代替手段、つまりdm-cacheやbcacheなどのSSDキャッシュモジュールがあります。ライトバックモードでは、最初にデータをSSDに書き込みます。これは、ディスクへの書き込みよりもはるかに高速であり、その後、すでに書き込みをコミットしています。停電後でも、SSDからブロックを正しく読み取ります。 dm-cacheとbcacheには最近のすべてのLinuxカーネルが付属しており、小型(64GBや128GBなど)のサーバーグレード(!!)SSDはBBURAIDコントローラーよりも安価です。

2
Kai Petzke