私は長い間、クライアントとともに AWS を利用してきましたが、サービスを継続するためにはコストを削減する必要があります。AWS では、いくつかのフォルダを同期するために RSync を使用し、透過的なフェイルオーバーによる高可用性を実現するために DRDB を使用し、各クライアント マシンに常に運用可能ですぐに使用できるミラーを用意しています。
現在、私が移行しているはるかに安価なクラウド ソリューションでは、各マシンに 1 つのパーティションのみで LVM のない Ubuntu 14.04 LTS しか提供されないため、DRBD を使い続けることはできません。このクラウド プラットフォームは、私のクライアントの一部にとっても必須のものになります。
私が考えている解決策は、一方で毎日 BKP を実行するシェル スクリプトをスケジュールし、それを SSH でもう一方の側に転送して BKP を復元することですが、これは複雑になり、エラーが発生しやすくなり、開発と管理に多くの作業が必要になります。
私のクライアントの多くは Wordpress+Mysql のみを使用しており、1 日の遅延を許容しています。私は、たとえ 1 日の遅延が発生しても、制限されたコンテキストでケースごとにスクリプトを開発および管理する必要のない「高可用性」を提供する代替手段を探しています。
答え1
ブロック デバイスを実際に使用できない場合 (DRBD の方が適しており、既に使用経験がある場合)、GlusterFS を使用すると、ファイル レベルで必要なレプリケーション機能を実現できます。
Gluster の「ブリック」は、理想的には XFS で終わる独自の薄い LVM スタックを備えた単一のストレージ デバイスですが、実際にはノード上の任意の POSIX 準拠のファイルシステム (または専用の FS ではなく単なるディレクトリ) にすることができます。
これらのブリックは、「レプリカ」ポリシーを使用して統合された「ボリューム」に集約されます。このポリシーでは、特定のファイルで多くのブリックが書き込まれることが定義されています (この場合はレプリカ 2 または 3 になります)。これらのレプリカは、可能な限り異なるノードに配置されるように努めます。
Gluster の障害セマンティクスは、DRBD ほど一貫性がありません。データ レプリケーションは接続クライアントの責任であるため、スプリット ブレイン状態は簡単に解決できます (マスターに書き込んでデータを複製するのではなく、すべての書き込みの N 個のコピーを各 Gluster ノードに送信します)。ただし、レプリケーションを使用すると、各ブリックは完全に読み取り可能なデータを含む完全なファイル システムであるため、異なるデータを持つスプリット ブレインを解決する方が潜在的に簡単になります。
DRBD ほど高速ではありませんが、それほど高速である必要はないかもしれません。