Azure Load Balancer 백엔드 트래픽 응답 문제 해결
이 페이지에서는 Azure Load Balancer 질문에 대한 문제 해결 정보를 제공합니다.
부하 분산 장치 뒤에 있는 가상 머신에서 트래픽이 고르지 않게 분포되어 있습니다.
백 엔드 풀 멤버가 트래픽을 수신하는 것으로 의심되는 경우 다음 원인 때문일 수 있습니다. Azure Load Balancer는 연결을 기반으로 트래픽을 분산합니다. 패킷당이 아닌 연결당 트래픽 분포를 확인합니다. 사전 구성된 Load Balancer Insights 대시보드에서 흐름 분산 탭을 사용하여 확인합니다.
Azure Load Balancer는 진정한 라운드 로빈 부하 분산을 지원하지 않지만 해시 기반 분산 모드를 지원합니다.
원인 1: 세션 지속성을 구성했습니다.
원본 지속성 배포 모드를 사용하면 트래픽이 고르지 않게 배포될 수 있습니다. 이 배포를 원하지 않으면 세션 지속성을 없음으로 업데이트하여 백 엔드 풀의 모든 정상 인스턴스에 트래픽이 분산되도록 합니다. Azure Load Balancer의 배포 모드에 대해 자세히 알아봅니다.
원인 2: 프록시가 구성되어 있습니다.
프록시 뒤에서 실행되는 클라이언트는 부하 분산 장치의 관점에서 하나의 고유한 클라이언트 애플리케이션으로 보일 수 있습니다.
부하 분산 장치 뒤에 있는 VM이 구성된 데이터 포트의 트래픽에 응답하지 않음
백 엔드 풀 VM이 정상으로 표시되고 상태 프로브에 응답하지만 여전히 부하 분산에 참여하지 않거나 데이터 트래픽에 응답하지 않을 경우 다음 이유 중 하나 때문일 수 있습니다.
부하 분산 장치 백 엔드 풀 VM이 데이터 포트에서 수신 대기하지 않음
네트워크 보안 그룹이 부하 분산 장치 백 엔드 풀 VM에서 포트를 차단하고 있습니다.
동일한 VM 및 NIC에서 부하 분산 장치에 액세스
참여하는 부하 분산 장치 백 엔드 풀 VM에서 인터넷 부하 분산 장치 프런트 엔드에 액세스
원인 1: 부하 분산 장치 백 엔드 풀 VM이 데이터 포트에서 수신 대기하지 않음
VM이 데이터 트래픽에 응답하지 않는 경우 대상 포트가 참여하는 VM에서 열려 있지 않거나 VM이 해당 포트에서 수신 대기하지 않기 때문일 수 있습니다.
유효성 검사 및 해결
백 엔드 VM에 로그인합니다.
명령 프롬프트를 열고 다음 명령을 실행하여 데이터 포트에서 수신 대기하는 애플리케이션이 있는지 확인합니다.
netstat -an포트가 LISTENING 상태로 나열되지 않으면 적절한 수신기 포트를 구성합니다.
포트가 LISTENING으로 표시되어 있는 경우 해당 포트의 대상 애플리케이션에 문제가 있는지 확인합니다.
원인 2: 네트워크 보안 그룹이 부하 분산 장치 백 엔드 풀 VM에서 포트를 차단하고 있습니다.
서브넷 또는 VM에 구성된 하나 이상의 네트워크 보안 그룹이 원본 IP 또는 포트를 차단하는 경우 VM이 응답할 수 없습니다.
공용 부하 분산 장치의 경우 클라이언트와 부하 분산 장치 백 엔드 VM 간의 통신에 인터넷 클라이언트의 IP 주소가 사용됩니다. 백 엔드 VM의 네트워크 보안 그룹에서 클라이언트의 IP 주소가 허용되는지 확인합니다.
백 엔드 VM에 구성된 네트워크 보안 그룹을 나열합니다. 자세한 내용은 네트워크 보안 그룹 관리를 참조하세요.
네트워크 보안 그룹 목록에서 다음을 확인합니다.
데이터 포트에서 들어오거나 나가는 트래픽에 간섭이 있습니다.
VM 또는 서브넷의 NIC에 대해 부하 분산 장치 프로브 및 트래픽을 허용하는 기본 규칙보다 우선 순위가 더 높은 모두 거부 네트워크 보안 그룹 규칙(네트워크 보안 그룹은 프로브 포트에 해당하는 168.63.129.16의 부하 분산 장치 IP를 허용해야 함).
규칙에 의해 트래픽이 차단되는 경우 해당 규칙을 제거한 후 데이터 트래픽을 허용하도록 다시 구성합니다.
VM이 상태 프로브에 응답하기 시작했는지 테스트합니다.
원인 3: 동일한 VM 및 네트워크 인터페이스에서 내부 부하 분산 장치 액세스
내부 부하 분산 장치의 백 엔드 VM에서 호스트된 애플리케이션이 동일한 네트워크 인터페이스를 통해 동일한 백 엔드 VM에서 호스트되는 다른 애플리케이션에 액세스하려고 하는 경우 이는 지원되지 않는 시나리오이며 실패합니다.
해결 방법
다음 방법 중 하나를 통해 이 문제를 해결할 수 있습니다.
애플리케이션마다 별도 백 엔드 풀 VM을 구성합니다.
각 애플리케이션이 자체 네트워크 인터페이스 및 IP 주소를 사용하도록 이중 NIC VM에 애플리케이션을 구성합니다.
원인 4: 참여하는 부하 분산 장치 백 엔드 풀 VM에서 내부 부하 분산 장치 VIP에 액세스
내부 부하 분산 장치가 가상 네트워크 내에서 구성되고, 참여하는 백 엔드 부하 분산 장치 중 하나가 내부 부하 분산 장치 프런트 엔드에 액세스하려고 하면 흐름이 원본 VM에 매핑될 때 오류가 발생할 수 있습니다. 이 시나리오는 지원되지 않습니다.
해결 방법
프록시 사용을 포함하여 이 시나리오의 차단을 해제하는 방법에는 여러 가지가 있습니다. Application Gateway 또는 기타 타사 프록시(예: nginx 또는 haproxy)를 평가하세요. Application Gateway에 대한 자세한 내용은 Application Gateway에 대한 개요를 참조하세요.
세부 정보
내부 부하 분산 장치는 둘 다 개인 IP 주소 공간에 있으므로 아웃바운드에서 시작된 연결을 내부 부하 분산 장치의 프런트 엔드로 변환하지 않습니다. 퍼블릭 부하 분산 장치는 가상 네트워크 내의 개인 IP 주소에서 공용 IP 주소로의 아웃바운드 연결을 제공합니다. 내부 부하 분산 장치의 경우 이 방법은 변환이 필요하지 않은 고유한 내부 IP 주소 공간 내에서 잠재적인 SNAT 포트 고갈을 방지합니다.
부작용은 백 엔드 풀의 VM에서 아웃바운드 흐름이 풀 의 내부 부하 분산 장치의 프런트 엔드로의 흐름을 시도하고 자체에 다시 매핑되는 경우 흐름의 두 다리가 일치하지 않는다는 것입니다. 두 레그가 일치하지 않기 때문에 흐름이 실패합니다. 흐름이 프런트 엔드에 흐름을 만든 백 엔드 풀의 동일한 VM에 다시 매핑되지 않은 경우 흐름이 성공합니다.
흐름이 스스로에게 다시 매핑되는 경우 아웃바운드 흐름은 VM에서 시작된 후 프런트 엔드에 나타나며 해당 인바운드 흐름은 VM에서 시작된 후 자신에게 나타납니다. 게스트 운영 체제의 관점에서 동일한 흐름의 인바운드 및 아웃바운드 부분은 가상 머신 내에서 일치하지 않습니다. TCP 스택은 동일한 흐름의 이러한 절반을 동일한 흐름의 일부로서 인식하지 않습니다. 소스와 대상은 일치하지 않습니다. 흐름이 백 엔드 풀의 다른 VM에 매핑되면 흐름의 절반이 일치하며 VM이 흐름에 응답할 수 있습니다.
이 시나리오에 대한 증상은 흐름이 흐름을 처음 시작한 동일한 백 엔드로 돌아갈 때 일시적인 연결 시간 제한입니다. 일반적인 해결 방법은 프록시 계층을 내부 부하 분산 장치 내에 삽입하고 DSR(Direct Server Return) 스타일 규칙을 사용하는 것입니다. 자세한 내용은 Azure Load Balancer의 다중 프런트 엔드를 참조하세요.
타사 프록시에 내부 부하 분산 장치를 결합하거나 HTTP/HTTPS가 있는 프록시 시나리오에 대해 내부 Application Gateway를 사용할 수 있습니다. 퍼블릭 부하 분산 장치를 사용하여 이 문제를 완화할 수는 있지만 결과 시나리오에서 SNAT 고갈이 발생할 가능성이 높습니다. 신중하게 관리하지 못할 경우에는 이 두 번째 방법을 사용하지 마세요.
다음 단계
앞의 단계에서 문제가 해결되지 않으면 지원 티켓을 엽니다.