F5 BIG-IP Standard: Pool이 내려가도 VIP TCP 연결이 되는 이유

BIG-IP Standard virtual server의 VIP에 TCP 연결이 됐다고 해서 뒤의 Pool member가 정상이라는 뜻은 아닙니다. Standard는 클라이언트 측과 서버 측 연결을 분리합니다. TCP 프로파일을 쓰는 일반적인 구성에서 클라이언트 연결이 먼저 성립한 뒤 서버 연결이 시도될 수 있습니다.

2019년 사례에서 다시 구분할 부분

기존 기록은 i2600에서 서버 데몬을 내렸는데 VIP로 telnet 연결이 되어 의문을 가졌던 경험입니다. 이를 “장비 결함”이나 “연결되는 것처럼 보이기만 한다”로 설명하면 부정확합니다. 클라이언트 측 TCP 연결 자체는 성립할 수 있고, 그 뒤 애플리케이션 요청을 처리할 서버가 없는 상황을 구분해야 합니다.

1. 클라이언트 ↔ BIG-IP: 클라이언트 측 TCP 연결
2. BIG-IP ↔ Pool member: 별도의 서버 측 연결
3. 서비스 요청과 응답: 두 연결 사이의 실제 처리 확인

TCP 접속과 실제 HTTP 응답을 대조하기

운영자가 허용한 읽기 전용 상태 확인 URL에서 실행할 예제입니다. 도메인·경로와 VIP를 실제 값으로 바꾸세요. 주소는 문서용입니다. 다음 명령을 이 글의 특정 장비에서 실측했다는 의미는 아닙니다.

curl --verbose --connect-timeout 3 --max-time 10   --resolve service.example.com:443:192.0.2.20   https://service.example.com/health

--resolve는 접속 IP를 지정하면서 호스트명과 TLS SNI를 유지합니다. 인증서 검증은 유지하세요. TCP 연결, TLS 검증, HTTP 상태와 응답 본문을 나눠 봅니다. 200이어도 안내·오류 페이지일 수 있으므로 기대한 본문도 확인합니다.

점검 순서

Virtual server 유형과 TCP·HTTP·TLS 프로파일, iRule·정책을 확인합니다.
기본 Pool과 실제 선택되는 Pool, member 주소·포트·상태를 확인합니다.
모니터의 대상, 요청 경로·Host, 성공 응답과 감지 간격을 비교합니다.
같은 시점의 클라이언트 오류, 서버 측 연결·응답, 장비 로그를 대조합니다.
서버 정상화 이후 새 요청과 기존 연결을 구분해 재확인합니다.

“데몬 중단 즉시 VIP도 내려가야 한다”는 가정은 모니터 감지 지연과 virtual address 상태 설정 등을 무시합니다. 모든 Pool이 내려간 뒤 RST·HTTP 응답·거부가 어떻게 나타나는지는 TMOS 버전, 유형과 정책에 따라 확인해야 합니다. Standard를 Performance L4로 바꾸는 작업은 단순한 장애 해결책으로 적용하지 마세요.

함께 읽기

L4 배치와 응답 경로에서 관련 개념을 이어서 확인할 수 있습니다.