データレプリケーションにglusterfs 3.7.6を使用し、リソースマネージャーとしてペースメーカー+コロシンクを使用して、高可用性Apacheを備えた2ノードLinuxサーバーを作成しようとしています。ただし、両方のノードがシャットダウンし、そのうちの1つが最初にオンラインになる特定のシナリオで、glusterに問題が発生しています。そのノードにブリックがあり、glusterサービスが実行されていても、ブリックプロセスはありません。
[root@node1 ~]# gluster volume status data
Status of volume: data
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data N/A N/A N N/A
NFS Server on localhost N/A N/A N N/A
NFS Server on localhost N/A N/A N N/A
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks
そして、もう一方のノードを起動すると、すべてが機能しているように見え、ボリュームをマウントできます。
[root@node1 ~]# gluster volume status data
Status of volume: data
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data 49152 0 Y 2674
Brick node2:/gluster_data 49152 0 Y 3086
NFS Server on localhost N/A N/A N N/A
Self-heal Daemon on localhost N/A N/A Y 2796
NFS Server on node2 N/A N/A N N/A
Self-heal Daemon on node2 N/A N/A Y 3085
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks
そして、この時点でnode2をシャットダウンすると、node1ブリックプロセスはアクティブなままなので、少なくともマウントして使用できます。
[root@node1 ~]# gluster volume status data
Status of volume: data
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick node1:/gluster_data 49152 0 Y 2674
NFS Server on localhost N/A N/A N N/A
Self-heal Daemon on localhost N/A N/A Y 2796
Task Status of Volume data
------------------------------------------------------------------------------
There are no active volume tasks
したがって、私の観察では、glusterボリュームが機能するためには、両方のノードが少なくともオンラインになっている必要があるため、ブリックを開始でき、一方のノードがダウンしてもボリュームの操作に影響を与えません。それで、ノードの1つが完全なブラックアウトからオンラインになったときに、それをどのように機能させることができますか?
クラスターノードが完全停止から立ち上がるときに発生する問題は次のとおりです。
最新の状態ですか?他のダウンノードの背後にいる場合は、
latest
を要求したくありません。
このため、クラスタリングにはある種のクォーラムメカニズムが含まれることが多く、既存のノードが状態に投票してコンセンサスに収束することができます。 「マジョリティ」パーティションが存在しないため、2つのノードのクラスターはこのメカニズムを使用できません。 3.7リリースでは、Glusterがクォーラム機能を獲得しました。
http://gluster.readthedocs.org/en/release-3.7.0beta1/Features/server-quorum/
そのドキュメントでは、上記で説明した理由により、2ノードのクラスターはそれを使用できないと述べています。
あなたのケースでは、Glusterセットアップでいくつかの管理専用ノードを作成することを検討することができます。これらは、クラスターにprobed
しているピアですが、ストレージをホストしていません。存在する理由は、クラスターの状態を維持するためです。これらは、異なるラック、データセンター、電源フェーズに存在し、ストレージブリックとは異なるフォールトドメインにあることを確認します。これにより、クラスター内のメンバーの数が増加し、一方のストレージレンガがもう一方のレンガなしで起動した場合にマジョリティパーティションが作成される可能性が高くなります。
不運にも、あなたが見ている振る舞いは設計通りに機能しており、クラスターにサーバーを追加せずに変更することはできません。