web-dev-qa-db-ja.com

ZFS overiSCSI高可用性ソリューション

プレーンPCハードウェアのwimpyノードで実行され、FreeBSD 9を実行するHA /スケールアウト/シェアードナッシングデータベースプラットフォーム用のZFS/iSCSIベースのアーキテクチャを検討しています。

動作しますか？考えられる欠点は何ですか？

アーキテクチャ

  1. ストレージノードには、直接接続された安価なSATA/SASドライブがあります。各ディスクは個別のiSCSI LUNとしてエクスポートされます。このレイヤーには、RAID（HWでもSWでもない）、パーティショニング、ボリューム管理などは含まれないことに注意してください。物理ディスクごとに1つのLUNのみ。

  2. データベースノードはZFSを実行します。 ZFSミラーリングされたvdevは、3つの異なるストレージノードのiSCSILUNから作成されます。 ZFSプールは、vdevの上に作成され、そのファイルシステム内にデータベースをバックアップします。

  3. ディスクまたはストレージノードに障害が発生した場合、それぞれのZFS vdevは縮退モードで動作し続けます（ただし、2つのミラーリングされたディスクがあります）。障害が発生したディスクまたはストレージノードを置き換えるために、別の（新しい）ディスクがvdevに割り当てられます。 ZFSの再シルバーリングが行われます。故障したストレージノードまたはディスクは、再び利用可能になった場合、常に完全にリサイクルされます。

  4. データベースノードに障害が発生すると、そのノードが以前使用していたLUNは解放されます。新しいデータベースノードが起動され、障害が発生したデータベースノードが残っているLUNからZFS vdev/poolが再作成されます。高可用性の理由から、データベースレベルのレプリケーションは必要ありません。

考えられる問題

  • Vdevの低下を検出するにはどうすればよいですか？ 5秒ごとにチェックしますか？ ZFSで利用できる通知メカニズムはありますか？

  • Vdevを構成する既存のLUNから新しいプールを再作成することも可能ですか？罠は？

storagefreebsdiscsizfs
5
oberstet

それはあなたの質問に対する直接の答えではありませんが、この種のもののためのより伝統的なアーキテクチャは、 [〜＃〜] hast [〜＃〜] と [〜＃〜 ] carp [〜＃〜] ストレージの冗長性を処理します。

基本的な概要（詳細については、リンクされたドキュメントを参照してください）：

マシンA（「マスター」）

  • HASTデーモンを構成し、プールメンバーデバイスごとに適切なリソースを作成します。
  • HASTデバイスを使用して、他の単一システムと同じようにZFSミラーリングデバイスを作成します。

マシンB（「スレーブ」）

  • マスターで行ったのと同様にHASTデーモンを構成しますが、セカンダリ/スレーブノードとして起動します。
    （HASTはマスターからスレーブへのすべてのデータをミラーリングします）

両方のマシン

ここでの大きな注意点は、HASTはマスター/スレーブレベルでのみ機能するため、エクスポートするLUN/LUNのセットごとにマシンのペアが必要になることです。

注意すべきもう1つの点は、ストレージアーキテクチャは、提案した設計の場合ほど柔軟ではないということです。
HASTを使用すると、1組のマシンに配置できるディスクの数が制限されます。
提案したISCSIメッシュのような構造を使用すると、理論的には、より多くのLUNをエクスポートするマシンを追加して、必要なだけ（ネットワークの限界まで）拡張できます。

柔軟性のトレードオフにより、FreeBSD管理者なら誰でもすぐに理解できる（またはハンドブックを読んで理解できる）、テスト済みで実証済みの文書化されたソリューションを購入できます。私にとっては、価値のあるトレードオフです:-)

9
voretaq7