私は別々のマシンで nginx と php fpm を実行する VM を持っていますが、今のところ、クラスターがそれほど大きくないため、手動でディレクトリを同期するという非常に愚かな方法を使用しています。ただし、共有ストレージ デバイスとして利用したい別のサーバーがあります。
これまでのところ、ocfs2 ファイルシステムを使用して iscsi 経由でストレージを提供できることは理解しています。気になるのは、初期設定で各ノードを事前に指定する必要があり、ノードを追加するには変更を適用するために o2cb をシャットダウンする必要があることです。
目標は、iSCSI 経由で nginx および php-fpm ノードに共有ストレージを提供することです (そのため、レプリケーションを行う必要はありません)。ただし、クラスターの負荷に応じてノードの数が増加する可能性があります。
アイデア #1: ホスト経由で VM にストレージを提供できるかもしれません。そうすれば、ホストだけが ocfs2 を直接処理することになります。そうすれば、ノードが認識されます。
答え1
OCFS2 は、レプリカに使用する各ブロック デバイスが同一であると想定するクラスター化されたファイル システムです。これは、参加ノード間でデータのロックと順序付けが非常に緊密である nginx などとはまったく異なるユース ケース向けに設計されています。
これにはかなりのオーバーヘッドがかかりますが、同じデータセットに変更を加える複数のワーカーを実行する場合に非常に便利です。これは、ストレージでは避けたいパターンですが、役立つ場合もあります。今回はそうではありません。
この実装は、iSCSI でバックアップされたクラスター化された FS ではなく、中央の NFS または SMB 共有から恩恵を受けます。こうすることで、各 Nginx ワーカーは同じディレクトリにアクセスできます。同時に同じファイルに書き込まないようにするのが最善ですが、そうする必要がある場合は、NFS >v4.1 または SMB >v3.x を使用していることを確認してください。どちらも、以前のバージョンよりもロックの処理が優れています。
答え2
3 番目のサーバーを NFS サーバーとして設定するだけで、その使用例では OCFS2 を使用するよりも合理的です。OCFS2 は、高速 SAN ストレージ、または DRBD などのリアルタイムで複製されるストレージのどちらにも適しています。