tencent cloud

피드백

상태 확인 문제 해결

마지막 업데이트 시간:2024-01-04 20:22:15
    Tencent Cloud CLB는 상태 확인을 통해 리얼 서버의 가용성을 확인할 수 있습니다. 상태 확인 예외가 발생하면 다음과 같이 문제를 해결할 수 있습니다.
    설명:
    상태 확인 중에 예외가 감지되면 CLB는 더 이상 예외적인 리얼 서버로 트래픽을 포워딩하지 않습니다.
    상태 확인 중에 모든 리얼 서버에서 예외가 감지되면 요청이 모든 리얼 서버로 포워딩됩니다.
    상태 확인 작동 방식에 대한 자세한 내용은 상태 확인을 참고하십시오.

    리얼 서버의 공중망 대역폭 확인

    기존 계정의 경우 계정의 대역폭 속성이 CLB가 아닌 CVM에 있으므로 CLB에 바인딩된 백엔드 CVM 인스턴스에 대해 공중망 대역폭을 구성해야 합니다. 그렇지 않으면 상태 확인 예외가 발생합니다.
    표준 계정의 경우 CLB에 바인딩된 백엔드 CVM 인스턴스에 대해 공중망 대역폭을 구성할 필요가 없으며 CLB 서비스는 영향을 받지 않습니다.
    설명
    계정 유형을 확인하려면 Checking Account Type을 참고하십시오.
    기존 계정에는 CLB 트래픽 또는 대역폭 요금이 부과되지 않습니다. CLB 서비스에서 발생하는 공중망 트래픽 요금은 바인딩된 백엔드 CVM 인스턴스에 의해 과금됩니다.
    공중망 IP를 할당하지 않고 CVM 인스턴스에 대한 공중망 대역폭을 구입할 수 있습니다.

    보안 그룹 구성 확인

    CLB 인스턴스에서 보안 그룹에서 기본적으로 트래픽 허용 기능이 활성화되어 있는지 확인하고, 그렇지 않은 경우 CVM 인스턴스의 보안 그룹에서 원본 IP를 열어야 합니다. CLB 서비스가 모든 IP에서 액세스를 허용하도록 하려면 보안 그룹의 인바운드 규칙에서 원본 IP를 0.0.0.0/0으로 구성합니다. 자세한 내용은 Configuring CLB Security Group을 참고하십시오.

    레이어 4 리스너 확인

    설명
    TCP 프로토콜에서 CLB는 확인을 위해 SYN 패킷을 사용합니다.
    UDP 프로토콜에서 CLB는 확인을 위해 ping 명령을 사용합니다.
    페이지에 표시된 대로 CLB 리얼 서버 포트의 상태가 예외적인 경우 다음 단계에 따라 문제를 해결하십시오.
    CLB 리얼 서버가 서비스에 영향을 미치는 보안 그룹으로 구성되어 있는지 확인하십시오. 리얼 서버는 보안 그룹을 통해 액세스를 제어하여 서비스의 정상적인 실행을 보장할 수 있습니다. 자세한 내용은 Configuring CVM Security Groups를 참고하십시오.
    netstat 명령을 실행하여 리얼 서버 포트에서 수신 대기하는 프로세스가 있는지 확인합니다. 그러한 프로세스가 없으면 서비스를 다시 시작합니다.

    레이어 7 프로토콜 확인

    레이어 7(HTTP 프로토콜) 서비스의 경우 상태 확인 중 리스너에 ‘예외’가 발생하면 다음 단계에 따라 문제를 해결할 수 있습니다.
    CLB의 레이어 7 상태 확인 서비스는 사설망을 통해 백엔드 CVM 인스턴스와 통신하기 때문에 해당 사설망 주소에서 애플리케이션 서버 포트가 정상적으로 수신되는지 확인하기 위해서는 서버에 로그인이 필요하며, 그렇지 않은 경우 애플리케이션 서버 포트의 리스너를 사설망으로 이동하여 CLB와 백엔드 CVM 인스턴스 간의 정상적인 통신을 보장합니다. CLB의 프런트엔드 포트와 CVM의 백엔드 포트가 모두 80이고 CVM의 사설망 IP가 1.1.1.10이라고 가정합니다.
    Windows의 서버의 경우 다음 명령을 사용합니다.
    netstat -ano | findstr :80
    Linux의 서버의 경우 다음 명령을 사용합니다.
    netstat -anp | grep :80
    1.1.1.10:80 또는 0.0.0.0:80에서 수신을 볼 수 있다면 구성이 정상입니다.
    CLB 리스너에 구성된 백엔드 포트가 리얼 서버에서 활성화되었는지 확인하십시오.
    레이어 4 CLB의 경우 백엔드 포트에 대한 telnet이 응답하는 한 정상으로 간주됩니다. 테스트를 위해 telnet 1.1.1.10 80을 사용할 수 있습니다.
    레이어 7 CLB의 경우 200과 같은 HTTP 상태 코드가 반환되면 정상으로 간주됩니다. 확인 방법은 다음과 같습니다.
    Windows에서는 CVM 인스턴스의 브라우저에 사설망 IP를 직접 입력하여 정상인지 테스트할 수 있습니다. 이 예시에서는 http://1.1.1.10을 사용합니다.
    Linux에서는 curl -I 명령을 실행하여 상태가 HTTP/1.1 200 OK인지 확인할 수 있습니다. 이 예시에서는 curl -I 1.1.1.10 명령을 사용합니다.
    백엔드 CVM에 CLB의 로컬 IP 주소를 차단할 가능성이 있는 방화벽 또는 기타 보안 소프트웨어가 있는지 확인하십시오. 이로 인해 CLB가 리얼 서버와 통신할 수 없습니다. 서버의 사설망 방화벽이 포트 80의 통과를 허용하는지 확인하십시오. 테스트를 위해 방화벽을 일시적으로 비활성화할 수 있습니다.
    Windows의 경우 'firewall.cpl' 명령을 실행하여 방화벽을 비활성화합니다.
    Linux의 경우 /etc/init.d/iptables stop 명령을 실행하여 방화벽을 비활성화합니다(CentOS 7.x의 경우 systemctl stop firewalld 실행).
    CLB의 상태 확인 매개변수가 올바르게 구성되었는지 확인합니다. Health Check Overview에 설명된 대로 기본 상태 확인 매개변수 값을 사용하는 것이 좋습니다.
    상태 확인을 위해 지정한 테스트 파일은 반환된 결과만 확인하는 HTML 형식의 단순 페이지를 사용하는 것이 좋습니다. PHP와 같은 동적 프로그래밍 언어는 권장되지 않습니다.
    백엔드 CVM 인스턴스의 부하가 높아 응답이 느린지 확인합니다.
    HTTP 요청 방법을 확인합니다.
    HEAD를 사용하는 경우 리얼 서버는 HEAD를 지원해야 합니다.
    GET을 사용하는 경우 리얼 서버는 GET을 지원해야 합니다.
    TCP 고속 재활용(tcp_tw_recycle)과 타임스탬프(tcp_timestamps)가 모두 활성화된 경우 상태 확인이 예외적일 수 있습니다. tcp_tw_recycle을 비활성화하는 것이 좋습니다. 자세한 내용은 Cause Analysis를 참고하십시오.

    높은 상태 확인 빈도

    상태 확인 패킷은 콘솔에 구성된 대로 5s마다 전송되지만 리얼 서버는 1s 이내에 하나 또는 여러 개의 상태 확인 요청이 수신되는 것을 찾습니다. 이 문제는 주로 CLB 리얼 서버 상태 확인의 구현 메커니즘과 관련이 있습니다. Client의 100만 요청이 리얼 서버로 전송되기 전에 4개의 CLB 리얼 서버에 배포된다고 가정합니다. 각 CLB 리얼 서버는 개별적으로 상태 확인을 수행합니다. CLB 인스턴스가 5s마다 상태 확인 요청을 보내도록 구성된 경우 각 CLB 리얼 서버는 5s마다 상태 확인 요청을 보냅니다. 따라서 리얼 서버는 5s 동안 4개의 상태 확인 요청을 수신할 수 있습니다.
    
    이 방식의 장점은 높은 효율, 정확한 검사, 잘못된 삭제 방지입니다. 예를 들어, CLB 인스턴스 클러스터에 있는 8개의 물리적 서버 중 하나가 실패하더라도 나머지 7개의 서버는 여전히 정상적으로 트래픽을 포워딩할 수 있습니다.
    
    귀하의 비즈니스가 부하에 민감한 경우 매우 빈번한 상태 확인이 정상적인 비즈니스 액세스에 영향을 미칠 수 있습니다. 이 경우 확인 간격을 늘려 영향을 줄일 수 있습니다(예: 15s에 한 번 상태 확인 수행).
    
    리얼 서버가 여러 CLB 인스턴스에 바인딩된 경우 각 CLB 인스턴스는 서버의 정상 여부를 감지하기 위해 상태 감지 메시지를 전송하므로 상태 감지 빈도가 높아집니다.
    문의하기

    고객의 업무에 전용 서비스를 제공해드립니다.

    기술 지원

    더 많은 도움이 필요하시면, 티켓을 통해 연락 바랍니다. 티켓 서비스는 연중무휴 24시간 제공됩니다.

    연중무휴 24시간 전화 지원