小規模ビジネス環境でダウンタイムが発生したときに稼働時間を維持するために、DRBD またはクラスター化されたファイル システムの使用を検討しています。
現在、Linux と samba を使用したファイル サーバー用のサーバー ボックスを使用しており、Web サーバーとデータベースは VM で実行しています。2 台目のサーバーを追加し、ファイルと VM を分散ファイル システムに配置することを検討していました。ベース OS はより静的であり、より手動で簡単に管理できます (変更時に構成ファイルをコピーし、必要に応じてフル バックアップからベース OS をコピーするなど)。
質問は、手動で行う場合のフェイルオーバー シナリオに関するものです。サーバー 1 がダウンし、フェイルオーバーが手動で行われる場合、サーバー 2 の静的 IP をサーバー 1 に設定し (サーバー 1 はダウンしており、修復が必要な状態になります)、Samba を起動し、サーバー 1 で実行されていたときと同じ静的 IP を持つ VM を起動し、バックアップ サービスを開始するだけで、フェイルオーバーは完了しますか?
これは、簡単すぎるくらいに、素早く簡単なプロセスのように思えます。何か見落としているのでしょうか? これは、スクリプトなど、失敗した場合にあまり熟練していない人が実行するように指示できるものを使用して、簡単に自動化することもできます。
ハードウェア障害が発生した場合、オンコール IT サポートや必要な部品のサポートがなければ、2 台目のサーバーがなければダウンタイムは数日に及ぶ可能性がありますが、2 台目のサーバーがあれば、ダウンタイムは最大でも数時間になります (そのような操作を実行できる十分なスキルを持つオフィスのスタッフがいない場合は、数分で済みます)。
答え1
あなたが説明しているフェイルオーバー プロセスは、正確であると同時にシンプルです。共有ストレージのような単一障害点を排除するため、DRBD を使用することが冗長性を作成するための重要なステップです。
あなたが言及した現在のフェイルオーバーは、次のように簡単に自動化できます。ペースメーカー/コロシンク手動介入の必要がないようにするためです。これは、機能していないノードのフェンシングも処理するため、スプリット ブレイン シナリオ (すべてのデータが台無しになる可能性がある) に遭遇することがないため、自分で記述したスクリプトよりも好ましいと思います。
「本当の」HA には、システムの完全な (または少なくともアーカイブ可能な最大限の) 分離 (別の部屋 (または少なくともラック)、異なる USV、冗長スイッチングなど) が必要であることを覚えておいてください。単一障害点は通常、可用性を最適化するためのすべての努力を台無しにします。