☰

RabbitMQ、LinuxでSCPを切断する

tag-icon • tag-icon linux performance ulimit forensics rabbitmq
RabbitMQ、LinuxでSCPを切断する

GNU / Linuxで作成されたアプリケーションに問題があります。ほとんどのコンポーネントはDockerで実行されているか、デフォルトで実行されている開発環境で動作しますが、展開する必要があるサーバー環境ではランダムに（しばしば必ずしもそうではありません）失敗します。

下部構造：

[App in Ubuntu Server 20.04 host-1]   <--->[router+firewall]<--->   [Ubuntu Server 20.04 host-2]

どちらのサーバーもCPU 4個、RAM 4GBなど十分なリソースを持っているようです。

アプリケーションを実行しているマシンは、そのホスト2で実行されているRabbitMQに接続する必要があり、発行（ここでは失敗は表示されません）とサブスクリプション（失敗する傾向がある）は異なるキューにあります。

問題：時には機能しますが（ルーター+ファイアウォールはありますが、問題は存在しないようです）、多くの場合、何らかの理由で2つの接続がランダムに失敗します。 MTU（1500、他の展開でも動作します）を確認しましたが、ulimitは問題ないようです。しかし、問題は見えません...

複数回Rabbit接続が開始されますが、最終的にRabbitエラーメッセージが表示されます。

  • AMQPConnector - reporting failure: AMQPConnectorAMQPHandshakeError: ProbableAuthenticationError[..]("ConnectionClosedByBroker: (403) 'ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.'"

私はこれらの資格情報が大丈夫だと100％確信し、実際に時々動作するので、これは本当ではありません。

再接続しようとしましたが、成功しませんでした。

ウサギのログから：

[info] <0.16188.30> Closing all channels from connection 
   'xxx.yyy.zzz.kkk:41426 -> yyy.zzz.kkk.zzz:5672' because it has been
   closed 
[info] <0.16192.30> accepting AMQP
   connection <0.16192.30> (xxx.yyy.zzz.kkk:41430 ->
   yyy.zzz.kkk.zzz:5672) 
[error] <0.16192.30>
   Error on AMQP connection <0.16192.30> (xxx.yyy.zzz.kkk:41430 ->
   yyy.zzz.kkk.zzz:5672, state: starting): PLAIN login refused: user
   'someuser' - invalid credentials

500と90のハートビートと300のブロック接続タイムアウトを試しました...

時々心拍数を受け取らないように感じられることがあります。

混乱しています。他の制御された環境でも機能していたので、これはパフォーマンスやネットワークの問題かもしれません。では、何を確認できますか？

答え1

驚くべきことに、最も確実な理由は実用的な理由のようです。つまり、クラウドコンピューティングプラットフォームの破損した仮想ネットワークです。

デバッグプロセスを実行する方法（ネットワークエンジニアが確認するように説得するため）：

  • さまざまなネットワークのネットワーク分析ツール（traceroute、nmap）を適用します。クライアントとサーバー間に接続があると、一部のポートが正しく機能しません。
  • 他のVMで同じターゲットとしてSSHとSCP...一部のネットワークでは機能しますが、クライアントとサーバー間の接続が確立されたネットワークでは失敗します。ログイン失敗、おそらくハンドシェイク交渉中にログイン中にパイプが切断され、接続は行われますが、何かを入力するとすぐにパイプが切断されます。
  • [これを証明し、ネットワークエンジニアを案内するための多くのログとスクリーンショット]

これは、私がRabbitの設定/パラメータなどを調査するのをやめたときです。

最後に、クラウド展開のために他のネットワークを強制的に使用する必要があり、成功しました。

これにより、最終的にネットワーク問題であることが確認され、問題はネットワークエンジニアに伝えられました。

関連情報