EC2で高可用性ファイルシステムクラスターをセットアップする際に興味深い問題が発生しています。セットアップの背後にある考え方は単純です。2つのGlusterFSノードは、2つの別々のアベイラビリティーゾーンにあり、それらの間でデータを同期します。これら2つのサーバーのいずれかを他のEC2インスタンスに問題なくマウントできます。
ただし、物事を分散させ、不良ノードから移行するために、これをロードバランサーの背後に配置したいと思います。問題は非常に単純に見えました。ロードバランサーのポートを開いてから、ホストを個々のglusterFSノードではなくロードバランサーに設定しましたが、接続できないと主張しています。これはファイアウォールの問題である可能性があると考え、それを除外するために、実際にポート1024〜65535を開きました。確かにひどい考えですが、私はそれを除外する必要がありました。
ログの内容は次のとおりです。
[2013-04-24 21:51:03.581564] I [glusterfsd.c:1666:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.3.1
[2013-04-24 21:51:03.608884] W [socket.c:1512:__socket_proto_state_machine] 0-glusterfs: reading from socket failed. Error (Transport endpoint is not connected), peer (1.2.3.4:24007)
奇妙な部分は、同じポートのtelnet経由でそのIPに正常に接続できることです。
誰かが以前にこれを行ったことがありますか、または私がこれを回避する方法について何か洞察がありますか?
ありがとう!
その音から、クライアントがGlusterインフラストラクチャを検出するために行う最初のポーリングの負荷分散を試みています。
mount -t glusterfs loadbalancer:Your_VOL /usr/local/specialhome
これは初期接続専用です。クライアントが対象のボリュームのトポロジを正常にプルすると、クライアントは必要なブリックに直接接続します。その時点で、LBはループから外れています。
あなたが学んでいるように、Glusterはそれを好きではありません。
Glusterで受け入れられているプラクティスに従って、これを解決する方法はいくつかあります。
ラウンドロビンは負荷分散ではありませんはこのあたりでよく耳にするフレーズですが、この場合はそれほど悪くはありません。最初の接続にのみ使用しているので、それだけです。
マウントオプションは次のとおりです。
mount -t glusterfs -o backupvolfile-server=rrdns-02 rrdns-01:Your_VOL /usr/local/specialhome
backupvolfile-server
オプションは、マウントオプションで指定された名前が直接応答しない場合に、別の名前を使用するようにマウントに指示します。これらの2つの方法を組み合わせて使用すると、一時的にダウンしているノードを処理できます。