web-dev-qa-db-ja.com

手動フェイルオーバーを備えたDRBD

小規模ビジネス環境でダウンタイムが発生した場合に、DRBDまたはクラスター化ファイルシステムを使用してアップタイムを支援することを検討しています。

現在、Linuxとsambaを使用するファイルサーバー用のサーバーボックスを使用し、VMでWebサーバーとデータベースを実行しています。 2台目のサーバーを追加し、ファイルとVMを分散ファイルシステムに配置することを検討していました。ベースOSはより静的で、より手動で簡単に管理できます(変更時に構成ファイルをコピーします)。 、必要に応じて完全バックアップなどからベースOSをコピーします)

質問は、手動で実行した場合のフェイルオーバーシナリオに関するものです。サーバー1がダウンし、フェイルオーバーが手動で行われた場合、サーバー2の静的IPをサーバー1に設定し(サーバー1がダウンし、修復が必要な状態になります)、Sambaを起動し、起動するだけでフェイルオーバーが完了します。 VMサーバー1で実行し、バックアップサービスを開始したときと同じ静的IPを持ちますか?

これは、迅速で単純なプロセスのように聞こえますが、ほとんど単純すぎます。私は何かが足りないのですか?これは、スクリプトなど、障害が発生した場合に実行するように指示できるものを使用して、簡単に自動化することもできます。

ハードウェア障害が発生した場合のダウンタイムは、オンコールITサポートのサポートがなく、2台目のサーバーがなくても必要な部品がない場合は数日になる可能性がありますが、2台目のサーバーを使用すると、ダウンタイムは最大で数時間になります( 1つは、そのような操作を実行するのに十分な能力を備えたオフィスです。

2
Damon

あなたが説明しているフェイルオーバープロセスは、それが正しいのと同じくらい簡単です。共有ストレージのような単一障害点を排除するため、DRBDを使用することは冗長性を作成するための重要なステップです。

あなたが言及している現在のフェイルオーバーは、 Pacemaker/Corosync によって簡単に自動化できるため、手動で介入する必要はありません。スプリットブレインシナリオ(すべてのデータを台無しにする可能性がある)に遭遇しないように、機能していないノードのフェンシングも処理するため、これは自作のスクリプトよりも好まれます。

「実際の」HAには、システムの完全な(または少なくとも最大のアーカイブ可能な)分離(個別の部屋(または少なくともラック)、異なるUSV、冗長スイッチングなど)が必要であることに注意してください。単一障害点は通常、可用性を最適化するための全努力を台無しにします。

3
Henrik