0

glusterfs サーバーを使用して geo レプリケーションをセットアップしようとしています。テスト環境、ステージング環境ではすべてが期待どおりに機能しましたが、本番環境を試してみたところ行き詰まりました。

私が持っているとしましょう

gluster fs サーバーはパブリック IP 1.1.1.1 上にあります

gluster fs スレーブはパブリック 2.2.2.2 にありますが、この IP はインターフェイス eth1 にあります。gluster fs スレーブ サーバーの eth0 は 192.168.0.1 です。

したがって、1.1.1.1でコマンドを開始すると（ファイアウォールとsshキーが適切に設定されます）

gluster volume geo-replication vol0 2.2.2.2::vol0 create push-pem

エラーが発生します。

スレーブ ボリュームの詳細を取得できません。スレーブ クラスタとスレーブ ボリュームを確認してください。geo レプリケーション コマンドが失敗しました

この場合、エラーはそれほど重要ではありません。問題はスレーブ IP アドレスです。

2015-03-16T11:41:08.101229+00:00 xxx kernel: TCP LOGDROP: IN= OUT=eth0 SRC=1.1.1.1 DST=192.168.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24243 DF PROTO=TCP SPT=1015 DPT=24007 WINDOW=14600 RES=0x00 SYN URGP=0

上記のファイアウォール ドロップ ログでわかるように、スレーブ gluster デーモンのポート 24007 は、スレーブ サーバーのインターフェイス eth0 のプライベート IP でアドバタイズされ、eth1 プライベート IP の IP である必要があります。したがって、マスターは接続できず、タイムアウトします

gluster サーバーにインターフェイス eth1 をアドバタイズさせるか、それにのみバインドさせる方法はありますか?

私は cfengine と ansible を使用して構成をプッシュするため、インターフェイスへのバインドは IP よりも優れたソリューションになる可能性がありますが、どのようなソリューションでも構いません。

前もって感謝します。

4

2 に答える 2

0

この問題に遭遇しましたが、別のコンテキストで発生しました。両方とも NAT の背後にある 2 つのノード (異なるリージョンの AWS インスタンス) をジオレプリケートしようとしていました。

マスターがパブリック IP を介してスレーブに接続し、ボリュームの互換性/サイズやその他の詳細を確認するとき、マスターはスレーブのホスト名を取得します。これは通常、そのリモート リージョンでのみ意味を持つものに解決されます。

次に、後でセッションをセットアップするときに、そのホスト名を使用してスレーブにダイヤルバックしますが、そのホスト名が別の地域のプライベート IP に解決されるため、失敗します。

この問題に対する私の回避策は、ボリュームの作成、ピアのプローブ、geo レプリケーションの確立時にホスト名を使用し、通常はプライベート IP に解決されるスレーブ ホスト名をパブリック IP にマッピングする /etc/hosts エントリを追加することでした。プライベート IP。

これでセッションを確立できるようになりますが、どこかで間違った IP を再び使用するため、実際に同期することはできませんでした。

編集：

両側に /etc/hosts ハックを追加することで、実際に実行することができました。

于 2015-10-18T10:46:12.710 に答える
0

GlusterFS にはネットワーク層の概念がありません。ルートを確認してください。geo レプリケーション スレーブのネクスト ホップが eth1 にある場合、gluster はそのインターフェイスでスレーブ IP アドレス用のポートを開きます。

また、このポートで geo レプリケーション トラフィックを転送するようにファイアウォールが構成されていることを確認してください。

于 2015-03-29T22:21:03.377 に答える