NSX CLI를 사용하여 자세한 비상 로그를 가져오고, 패킷 캡처를 수행하고, 로드 밸런서 문제 해결을 위한 메트릭을 확인할 수 있습니다.

문제

로드 밸런싱이 예상대로 진행되지 않습니다.

해결책

  1. 사용하도록 설정하거나 가상 장치에 대해 SSH를 수행할 수 있는지 확인합니다. Edge Services Gateway는 배포 중에 SSH를 사용하도록 설정하기 위한 옵션이 있는 가상 장치입니다. SSH를 사용하도록 설정해야 하는 경우 필요한 장치를 선택하고 작업(Actions) 메뉴에서 CLI 자격 증명 변경(Change CLI Credentials)을 클릭합니다.
    이미지는 주변 텍스트에 설명되어 있습니다.
  2. Edge Services Gateway에는 런타임 상태 및 구성 상태를 확인하기 위한 몇 가지 show 명령이 있습니다. 명령을 사용하여 구성 및 통계 정보를 표시합니다. 
    nsxedge> show configuration loadbalancer 
nsxedge> show configuration loadbalancer virtual [virtual-server-name] 
nsxedge> show configuration loadbalancer pool [pool-name] 
nsxedge> show configuration loadbalancer monitor [monitor-name] 
nsxedge> show configuration loadbalancer profile [profile-name] 
nsxedge> show configuration loadbalancer rule [rule-name]
  3. 로드 밸런싱 및 NAT가 제대로 작동하려면 방화벽을 사용하도록 설정해야 합니다. #show firewall 명령을 사용합니다. 명령을 사용하여 의미 있는 출력을 얻지 못할 경우 UI를 사용하여 로드 밸런서 구성 확인 및 문제 해결 섹션을 참조하십시오.
    show firewall Edge CLI 명령의 샘플 출력입니다.
  4. 로드 밸런서가 제대로 작동하려면 NAT가 필요합니다. show nat 명령을 사용합니다. 명령을 사용하여 의미 있는 출력을 얻지 못할 경우 UI를 사용하여 로드 밸런서 구성 확인 및 문제 해결 섹션을 참조하십시오.
    show nat Edge CLI 명령의 샘플 출력입니다.
  5. 방화벽이 사용되도록 설정되고 로드 밸런서에 NAT 규칙이 지정되는 것 외에도, 로드 밸런싱 프로세스를 사용하도록 설정해야 합니다. show service loadbalancer 명령을 사용하여 로드 밸런서 엔진 상태(L4/L7)를 확인합니다. 
    nsxedge> show service loadbalancer
haIndex:              0
-----------------------------------------------------------------------
Loadbalancer Services Status:

L7 Loadbalancer     : running
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0
-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    1. show service loadbalancer session 명령을 사용하여 로드 밸런서 세션 테이블을 확인합니다. 시스템에 트래픽이 있으면 세션이 표시됩니다. 
      nsxedge> show service loadbalancer session
-----------------------------------------------------------------------
L7 Loadbalancer Statistics:
STATUS     PID        MAX_MEM_MB MAX_SOCK   MAX_CONN   MAX_PIPE   CUR_CONN   CONN_RATE  CONN_RATE_LIMIT MAX_CONN_RATE
running    1580       0          2081       1024       0          0          0          0               0

-----------------L7 Loadbalancer Current Sessions:

0x2192df1f300: proto=unix_stream src=unix:1 fe=GLOBAL be=<NONE> srv=<none> ts=09 age=0s calls=2 rq[f=c08200h,
i=0,an=00h,rx=20s,wx=,ax=] rp[f=008000h,i=0,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,0h,fd=-1,ex=] exp=19s


-----------------------------------------------------------------------
L4 Loadbalancer Statistics:
MAX_CONN   ACT_CONN   INACT_CONN TOTAL_CONN
0          0          0          0

L4 Loadbalancer Current Sessions:

pro expire state       source       virtual    destination
    2. show service loadbalancer 명령을 사용하여 로드 밸런서 계층 7 고정 테이블 상태를 확인합니다. 이 테이블에는 가속 가상 서버에 대한 정보는 표시되지 않습니다. 
      nsxedge> show service loadbalancer table
-----------------------------------------------------------------------
L7 Loadbalancer Sticky Table Status:

TABLE    TYPE    SIZE(BYTE)   USED(BYTE)
  6. 모든 필수 서비스가 제대로 실행되는 경우 라우팅 테이블을 확인하고 클라이언트 및 서버에 대한 경로가 있어야 합니다. 경로를 인터페이스에 매핑하는 show ip route 및 show ip forwarding 명령을 사용합니다.
    show ip route 및 show ip forwarding Edge CLI 명령의 샘플 출력입니다.
  7. show arp 명령을 사용하여 시스템에 대한 ARP 항목(예: 게이트웨이 또는 다음 홉)과 백엔드 서버가 있는지 확인합니다.
    show arp 명령의 샘플 출력입니다.
  8. 로그에는 문제를 진단하는 데 도움이 될 수 있는 트래픽을 찾기 위한 정보가 제공됩니다. show log 또는 show log follow 명령을 사용하여 트래픽을 찾는 데 도움이 되는 로그에 태그를 지정합니다. 로깅(Logging)을 사용하도록 설정하고 정보(Info) 또는 디버그(Debug)로 설정한 상태로 로드 밸런서를 실행하고 있는지 확인합니다. 
    nsxedge> show log
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuset
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpu
2016-04-20T20:15:36+00:00 vShieldEdge kernel: Initializing cgroup subsys cpuacct
...
  9. 기본 서비스가 클라이언트에 대한 적절한 경로로 실행되고 있음을 확인했으므로 애플리케이션 계층에서 진행되는 상황을 살펴보겠습니다. show service loadbalancer pool 명령을 사용하여 로드 밸런서 풀 상태(L4/L7)를 확인합니다. 하나 이상의 멤버가 컨텐츠를 제공할 수 있도록 작동 상태여야 합니다. 일반적으로 요청 볼륨이 단일 워크로드의 용량을 초과하므로 둘 이상의 멤버가 필요합니다. 기본 제공 상태 검사가 상태 모니터를 제공하는 경우 상태 검사가 실패할 때 출력에 마지막 상태 변경 시간 및 실패 원인도 표시됩니다. 모니터 서비스에서 상태 모니터를 제공하는 경우 위의 두 가지 출력 외에 마지막 확인 시간도 표시됩니다. 
    nsxedge> show service loadbalancer pool
-----------------------------------------------------------------------
Loadbalancer Pool Statistics:

POOL Web-Tier-Pool-01
|  LB METHOD round-robin
|  LB PROTOCOL L7
|  Transparent disabled
|  SESSION (cur, max, total) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
   +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
   |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
   |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
   |  |  SESSION (cur, max, total) = (0, 0, 0)
   |  |  BYTES in = (0), out = (0)
  10. 서비스 모니터 상태(정상, 경고, 주의)를 확인하여 구성된 모든 백엔드 서버의 상태를 알아봅니다. 
    nsxedge> show service loadbalancer monitor
-----------------------------------------------------------------------
Loadbalancer Health Check Statistics:

MONITOR PROVIDER   POOL               MEMBER     HEALTH STATUS
built-in           Web-Tier-Pool-01   web-01a    default_https_monitor:L7OK
built-in           Web-Tier-Pool-01   web-02a    default_https_monitor:L7OK
    show service load balancer monitor 명령의 경우 다음 세 가지 유형의 상태 모니터 값이 CLI 출력에 표시됩니다.
    • 기본 제공: 상태 점검이 사용되도록 설정되고 L7 엔진(HA 프록시)에 의해 수행됩니다.
    • 모니터 서비스: 상태 점검이 사용되도록 설정되고 모니터 서비스 엔진(NAGIOS)에 의해 수행됩니다. 모니터 서비스 실행 상태는 show service monitor 및 show service monitor service CLI 명령을 사용하여 확인할 수 있습니다. 상태(Status) 필드는 정상, 주의 또는 위험일 수 있습니다.
    • 정의되지 않음: 상태 점검이 사용되지 않도록 설정됩니다.
    출력의 마지막 열은 풀 멤버의 상태입니다. 다음 상태가 표시됩니다.
    표 1. 상태 및 설명
    상태 설명
    기본 제공
    • UNK: 알 수 없음
    • INI: 초기화 중
    • SOCKERR: 소켓 오류
    • L4OK: 계층 4에서 검사 통과. 상위 계층 테스트를 사용하도록 설정되지 않음
    • L4TOUT: 계층 1~4 시간 초과
    • L4CON: 계층 1~4 연결 문제. 예: "연결이 거부됨"(tcp rst) 또는 "호스트에 대한 경로 없음"(icmp)
    • L6OK: 계층 6에서 검사 통과
    • L6TOUT: 계층 6(SSL) 시간 초과
    • L6RSP: 계층 6 잘못된 응답 - 프로토콜 오류. 발생 가능한 원인은 다음과 같습니다.
      • 백엔드 서버가 "SSLv3" 또는 "TLSv1.0"만 지원하는 경우
      • 백엔드 서버의 인증서가 올바르지 않은 경우
      • 암호 협상에 실패하는 경우
    • L7OK: 계층 7에서 검사 통과
    • L7OKC: 계층 7에서 조건부로 검사 통과. 예: disable-on-404 상태의 404
    • L7TOUT: 계층 7(HTTP/SMTP) 시간 초과
    • L7RSP: 계층 7 잘못된 응답 - 프로토콜 오류
    • L7STS: 계층 7 응답 오류. 예: HTTP 5xx
    위험
    • SSL 프로토콜 버전 2가 SSL 라이브러리에서 지원되지 않음
    • 지원되지 않는 SSL 프로토콜 버전
    • SSL 컨텍스트를 만들 수 없음
    • SSL 연결을 만들 수 없음
    • SSL 핸드셰이크를 시작할 수 없음
    • 서버 인증서를 검색할 수 없음
    • 인증서 주체를 검색할 수 없음
    • 인증서의 잘못된 시간 형식
    • 인증서 '<cn>'이(가) <expire time of certificate>에 만료됨
    • 인증서 '<cn>'이(가) 오늘 <expire time of certificate>에 만료됨
    주의/위험

    인증서 '<cn>'이(가) <days_left/expire time of certificate>일 후에 만료됨

    ICMP
    • 네트워크에 연결할 수 없음
    • 호스트에 연결할 수 없음
    • 프로토콜에 연결할 수 없음
    • 포트에 연결할 수 없음
    • 소스 경로 실패
    • 소스 호스트가 분리됨
    • 알 수 없는 네트워크
    • 알 수 없는 호스트
    • 네트워크가 거부됨
    • 호스트가 거부됨
    • 네트워크에 대한 잘못된 ToS(서비스 유형)
    • 호스트에 대한 잘못된 ToS(서비스 유형)
    • 필터로 금지됨
    • 호스트 우선 순위 위반
    • 우선 순위 구분. 작업에 필요한 최소 우선 순위 수준
    • 잘못된 코드
    UDP/TCP
    • 소켓 생성 실패
    • 주소 xxxx 및 포트 xxx에 연결: [Linux 오류 코드 참조]
    • 호스트에서 데이터가 수신되지 않음
    • 호스트/소켓의 예기치 않은 응답
    HTTP/HTTPS
    • HTTP 알 수 없음: 메모리 할당 오류
    • HTTP 위험: TCP 소켓을 열 수 없음(소켓 생성 또는 서버 연결 실패)
    • HTTP 위험: 데이터를 수신하는 동안 오류 발생
    • HTTP 위험: 호스트에서 데이터가 수신되지 않음
    • HTTP 위험: 호스트에서 잘못된 HTTP 응답을 수신함: <status line>(잘못된 예상 상태 줄 형식)
    • HTTP 위험: 잘못된 상태 줄 <status line>(상태 코드가 3자리 숫자: XXX가 아님)
    • HTTP 위험: 잘못된 상태 <status line>(상태 코드 >= 600 또는 < 100)
    • HTTP 위험: 문자열을 찾을 수 없음
    • HTTP 위험: 패턴을 찾을 수 없음
    • HTTP 주의: 페이지 크기 <page_length>이(가) 너무 큼
    • HTTP 주의: 페이지 크기 <page_length>이(가) 너무 작음
  11. 오류 코드가 L4TOUT/L4CON인 경우 일반적으로 기본 네트워킹에 연결 문제가 있는 것입니다. Duplicate IP는 다음 이유가 근본 원인인 경우가 많습니다. 이 오류가 발생하면 다음과 같이 문제를 해결합니다.
    1. 두 Edge에서 show service highavailability 명령을 사용하여 HA가 사용되도록 설정될 때 Edge의 HA(고가용성) 상태를 확인합니다. HA 링크가 DOWN 상태인지와 모든 Edge가 Active 상태인지 그리고 결과적으로 네트워크에 중복된 Edge IP가 없는지 확인합니다.
    2. show arp 명령으로 Edge ARP 테이블을 확인하고, 두 MAC 주소 간에 백엔드 서버의 ARP 항목이 변경되는지도 확인합니다.
    3. 백엔드 서버 ARP 테이블을 확인하거나 arp-ping 명령을 사용하고 다른 시스템이 Edge IP와 동일한 IP를 갖는지 여부를 확인합니다.
  12. 로드 밸런서 개체 통계(VIP, 풀, 멤버)를 확인합니다. 특정 풀을 확인하고 멤버가 작동 및 실행되고 있는지 확인합니다. 투명 모드가 사용되도록 설정되어 있는지 확인합니다. 이렇게 설정된 경우 Edge Services Gateway가 클라이언트와 서버 간에 인라인 상태여야 합니다. 서버가 세션 카운터 증분을 표시하는지 확인합니다. 
    nsxedge> show service loadbalancer pool Web-Tier-VIP-01
TIMESTAMP            	SESSIONS   	BYTESIN    	BYTESOUT   	SESSIONRATE	HTTPREQS
2016-04-27 19:56:40  	00         	00         	00         	00         	00
2016-04-27 19:55:00  	00         	32         	100        	00         	00

    nsxedge> show service loadbalancer pool Web-Tier-VIP-01 | MEMBER
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-1, STATUS:  UP
+—> POOL MEMBER: TENANT-1-TCP-POOL-80/SERVER-2, STATUS:  UP
  13. 이제 가상 서버를 확인하고 기본 풀이 있는지와 풀이 바인딩되어 있는지 확인합니다. 애플리케이션 규칙을 통해 풀을 사용하는 경우 #show service loadbalancer pool 명령에 표시되는 것처럼 특정 풀을 확인해야 합니다. 가상 서버의 이름을 지정합니다. 
    nsxedge> show service loadbalancer virtual Web-Tier-VIP-01

-----------------------------------------------------------------------
Loadbalancer VirtualServer Statistics:

VIRTUAL Web-Tier-VIP-01
|  ADDRESS [172.16.10.10]:443
|  SESSION (cur, max, total) = (0, 0, 0)
|  RATE (cur, max, limit) = (0, 0, 0)
|  BYTES in = (0), out = (0)
   +->POOL Web-Tier-Pool-01
   |  LB METHOD round-robin
   |  LB PROTOCOL L7
   |  Transparent disabled
   |  SESSION (cur, max, total) = (0, 0, 0)
   |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-01a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:00
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
      +->POOL MEMBER: Web-Tier-Pool-01/web-02a, STATUS: UP
      |  |  HEALTH MONITOR = BUILT-IN, default_https_monitor:L7OK
      |  |  |  LAST STATE CHANGE: 2016-05-16 07:02:01
      |  |  SESSION (cur, max, total) = (0, 0, 0)
      |  |  BYTES in = (0), out = (0)
  14. 모든 항목이 제대로 구성된 것처럼 보이는데도 여전히 오류가 발생하면 상황을 이해하기 위해 트래픽을 캡처해야 합니다. 두 가지 연결, 즉 클라이언트에서 가상 서버로의 연결과 Edge Services Gateway에서 백엔드 풀로의 연결이 있습니다(풀 수준에서 투명 구성 포함 또는 미포함). #show ip forwarding 명령은 vNic 인터페이스를 나열하며 해당 데이터를 사용할 수 있습니다.
    예를 들어 클라이언트 컴퓨터가 vNic_0에 있고 서버가 vNic_1에 있다고 가정하고 포트 80에서 실행되는 클라이언트 IP 주소 192.168.1.2와 VIP IP 192.168.2.2를 사용합니다. 로드 밸런서 인터페이스 IP는 192.168.3.1이고 백엔드 서버 IP는 192.168.3.3입니다. 두 개의 다른 패킷 캡처 명령이 있습니다. 하나는 패킷을 표시하지만, 다른 하나는 다운로드할 수 있는 파일에 패킷을 캡처합니다. 패킷을 캡처하여 로드 밸런서 비정상 오류를 감지합니다. 다음 두 방향에서 패킷을 캡처할 수 있습니다.
    • 클라이언트에서 패킷을 캡처합니다.
    • 백엔드 서버로 전송된 패킷을 캡처합니다. 
    #debug packet capture interface interface-name [filter using _ for space]- creates a packet capture file that you can download
#debug packet display interface interface-name [filter using _ for space]- outputs packet data to the console
#debug show files - to see a list of packet capture
#debug copy scp user@url:path file-name/all - to download the packet capture
    예:
    • vNIC_0에 캡처: debug packet display interface vNic_0
    • 모든 인터페이스에 캡처: debug packet display interface any
    • 필터를 사용하여 vNIC_0에 캡처: debug packet display interface vNic_0 host_192.168.11.3_and_host_192.168.11.41
    • 클라이언트에서 가상 서버로의 트래픽 패킷 캡처: #debug packet display|capture interface vNic_0 host_192.168.1.2_and_host_192.168.2.2_and_port_80
    • 풀이 투명 모드인 경우 Edge Services Gateway와 서버 간 패킷 캡처: #debug packet display|capture interface vNic_1 host 192.168.1.2_and_host_192.168.3.3_and_port_80
    • 풀이 투명 모드가 아닌 경우 Edge Services Gateway와 서버 간 패킷 캡처: #debug packet display|capture interface vNic_1 host 192.168.3.1_and_host_192.168.3.3_and_port_80