RabbitMQ, Linux에서 SCP 연결 해제

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에 연결되어야 하며 게시(여기서는 실패가 표시되지 않음)와 구독(실패하는 경향이 있음)이 서로 다른 대기열에 있습니다.

문제: 때로는 작동하지만(라우터 + 방화벽이 있지만 문제가 존재하지 않는 것 같습니다) 많은 경우 어떤 이유로 두 연결이 무작위로 실패합니다. 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 구성/매개변수 등을 조사하는 것을 중단했을 때입니다.

마지막으로 클라우드 배포를 위해 다른 네트워크를 강제로 사용해야 했고 성공했습니다.

이를 통해 최종적으로 네트워크 문제임이 확인되었으며 해당 문제는 네트워크 엔지니어에게 전달되었습니다.

관련 정보