링크는 1Gbps인데 vmkping이 실패한 이유는 비어 있는 uplink였다

ESXi 두 대를 vMotion용으로 직접 연결했다. 케이블도 연결했고 NIC는 Up이었으며 1Gbps Full로 협상됐다. VMkernel 인터페이스에 주소도 넣었다. 그런데 상대 호스트로 vmkping을 보내면 응답이 없었다.

이때는 물리 링크와 가상 네트워크 구성이 각각 맞는지 나누어 확인해야 했다. NIC의 불이 켜져 있는 것과 VMkernel의 패킷이 그 NIC로 나갈 수 있는 것은 같은 상태가 아니었다.

물리 NIC, 표준 vSwitch, VMkernel을 순서대로 조회했다.

esxcli network nic list
esxcli network vswitch standard list
esxcli network ip interface list
esxcli network ip interface ipv4 get

명령을 늘리기보다 각 출력에서 무엇을 확인할지 정했다. NIC에서는 링크와 속도, vSwitch에서는 uplink와 포트그룹, VMkernel에서는 인터페이스와 주소를 봤다.

두 호스트의 포트 번호는 같은 역할이 아니었다

한 호스트에서는 vmnic0이 직결용 1000 Full이고 vmnic3이 관리망 100 Full이었다. 다른 호스트에서는 vmnic0이 관리망 100 Full, vmnic3이 직결용 1000 Full이었다. 두 장비에서 같은 번호의 NIC가 같은 케이블에 연결돼 있다고 생각하면 잘못된 포트를 선택할 수 있었다.

관리망은 기존 vSwitch0을 사용했고, vMotion용으로는 vSwitch1과 포트그룹, vmk1을 구성했다. 양쪽 vmk1은 같은 전용 대역에 있었지만 이 인터페이스를 지정한 ping 결과는 다음과 같았다.

3 packets transmitted, 0 packets received, 100% packet loss

IP 주소가 있다는 사실만으로 전용망 구성이 끝났다고 보기 어려웠다. 실제 출력에서 물리 NIC와 vSwitch가 연결돼 있는지 확인했다.

결정적인 차이는 Uplinks 공란이었다

vSwitch1 조회 결과에는 vMotion 포트그룹이 있었지만 uplink가 비어 있었다.

vSwitch1
   Uplinks:
   Portgroups: PG-vMotion

VMkernel과 포트그룹은 만들어져 있었고 물리 NIC도 살아 있었지만, 그 둘을 잇는 vSwitch의 uplink가 빠져 있었다. 주소를 다시 넣거나 케이블 종류를 바꾸는 문제로 접근할 상황이 아니었다.

양쪽 호스트에서 이 누락을 기준으로 연결 구성을 바로잡은 뒤 vMotion 링크 문제를 해결했다. 그다음에는 ESXi와 NFS 사이의 직결 링크 문제를 조사하는 단계로 넘어갔다. 포트그룹을 만들었다는 결과와 물리 uplink가 연결됐다는 결과를 따로 확인한 것이 핵심이었다.

통신 경로를 구성 요소로 나눠 봤다

이번에는 물리 NIC의 링크, vSwitch uplink, 포트그룹, VMkernel 주소를 차례로 대조하면서 원인을 좁혔다. 한 항목이 정상이라고 나머지도 정상이라고 가정하지 않으니, 1Gbps 링크가 살아 있어도 ping이 실패한 이유를 설명할 수 있었다.

이후 네트워크를 점검할 때도 최종 주소만 보는 대신 그 인터페이스가 어느 가상 스위치와 물리 포트로 이어지는지 확인하게 됐다. 화면에서 생성한 객체가 모두 존재하는 것과, 실제 통신 경로가 연결된 것은 다른 확인 항목이었다.