ESXi 커스텀 USB NIC 드라이버 사용과 한계에 대하여

 국내에도 생각보다 많은 분들이 홈 랩을 구축하고, 운용하고 있는 것으로 알고 있습니다. 베어메탈 환경에 직접 리눅스로 서버 환경을 구축할 수도 있지만, Hypervisor를 사용한다면 가상화를 통한 조금 더 유연한 인프라 환경을 구현할 수 있습니다. 저도 여러 Hypervisor들 중에 가장 익숙한 ESXi를 활용하여 인프라 가상화 환경을 구축하고 있습니다.

 

홈 랩의 숙명 - 하드웨어 호환성

 VMware ESXi는 네트워크 인터페이스에 대한 호환성에 많이 인색한 편입니다. 오로지 Intel의 컨트롤러만을 사용하는 네트워크 인터페이스를 지원하기 때문에 ESXi를 하이퍼바이저로 선정한 사람들에게 숙명적으로 따라오는 것이 이 네트워크 인터페이스에 대한 고민입니다. 저 역시도 여기에서 자유롭지 못했습니다. 사용 중인 미니 PC네트워크 인터페이스의 개수가 1개에, 컨트롤러는 리얼텍 r8168입니다.

Home Lab 구축 기록 - 필요성과 설계 [1 - 1편]

 자세한 하드웨에 사양은 위 포스팅에 상세하게 작성해 두었는데... 어쨌든, 리얼텍 r8168을 사용하기 위해서는 ESXi 커스텀 드라이버가 설치된 ISO가 필요했고, 이를 위해 열심히 구글링 한 결과 다른 사람들도 이런 고민이 이미 예전부터 있었다는 것을 알 수 있었습니다. 그중 몇 가지 방법들을 시도해서 겨우 ESXi 커스텀 ISO를 만들어낼 수 있었습니다. 혹시 ESXi 커스텀 이미지를 생성하실 분들은 아래 자료를 참고해 주시면 되겠습니다.(저도 여러 번의 시도 끝에 6.7 버전으로 ISO 이미지를 생성하는 데 성공했습니다.)

ESXi Realtek LAN 사용하기.(ESXi ISO 다운로드)

VMware ESXi 에서 Realtek Driver 추가

esxi 6.7 리얼택 랜카드 드라이버 포함된 설치 iso 만들기

 

홈 랩 인프라 확장과 네트워크 분리의 필요성

 문제는 다음입니다. 홈 랩 인프라가 확장되면서 VM들의 서비스 네트워크와 스토리지용 네트워크 분리가 필요해졌습니다. 문제는 서버가 미니 PC라 확장성이 제한적이라는 점이었습니다. 이를 위해 여러가지 방법을 찾던 중 VMware 진영에서는 홈 랩 인프라 구축에 신선과도 같은 William Lam의 게시글이나 구익환 님의 블로그 등을 참고하여 그 가능성을 발견하였고, 역시나 안 되는 게 없구나 라는 생각으로 ipTIME U1G를 구매하고 테스트해봤습니다.

Realtek RTL8153 칩셋을 사용하는 ipTIME의 U1G 이더넷 어뎁터

 

USB Network Adapters without using the USB Network Native Driver for ESXi

ESXi 7.0 설치 한방팩(?) 만들기 – 098

 flings라는 VMware 사용자 커뮤니티에서 ESXi 버전에 맞는 커뮤니티 드라이버를 다운로드하고 설치를 진행했습니다. 자세한 방법이나 명령어는 아래 사이트를 참조했습니다.

Installing ESXi with a USB NIC

 다행히도 ESXi에서 USB 어뎁터를 잘 인식하여 VM들의 서비스 네트워크와 스토리지 네트워크를 분리할 수 있는 가능성이 열렸습니다. 다만... 생각지도 못한 문제에 부딪힙니다.

 

VLAN과 MTU의 환장의 조합

 아무래도 홈 랩 환경이다 보니 스토리지 전용 스위치를 사용하기에는 비용문제도 있어 1대의 스위치에서 VLAN을 통해 논리적으로 네트워크를 구분하여 사용하려 했습니다. NAS의 iSCSI 타겟과 ESXi의 소프트웨어 iSCSI 어뎁터 간의 인식은 문제가 없이 잘 진행되었는데 디스크를 VMFS 형식으로 포맷하려고 하면 꼭 타겟이 유실되면서 제대로 작동하지 않는 것이었습니다. 이때 물리적 연결에 사용한 네트워크 인터페이스가 앞서 말씀드린 ipTIME USB 이더넷 어뎁터인데 여기에 치명적인 문제가 있었습니다.

 바로 VLAN 태그에 대한 오프로딩 기능이 없다는 점이었습니다. 정확히는 네트워크 드라이버의 문제인지, 어뎁터의 문제인지는 모르겠으나 어쨌든 여기에서 문제가 생긴다는 것이었습니다. 보통의 경우 MTU를 1500으로 설정한 상태에서 ping 테스트를 하면 최대 1472바이트까지 전송이 가능합니다. 그 이유는 ICMP 헤더 8바이트와 IP 헤더 20 바이트 때문인데, 만약 중간 구간에 VLAN까지 있다면 추가로 4바이트가 더 필요합니다. 보통의 경우 하드웨어 레벨에서 이를 오프로딩 처리하기 때문에 VLAN에 속한 호스트의 MTU가 1500이어도 문제가 없지만 그렇지 못한 경우에는 문제가 발생하게 됩니다.

[Ubuntu 22.04] 0% Waiting for headers - 해결됨

 그에 대한 트러블 슈팅에 관한 자세한 내용은 위 포스팅을 참고해 주세요. 어쨌든 이런 이유로 외장 USB NIC의 경우 MTU를 1450으로 설정하니 iSCSI 타겟 유실과 같은 문제가 발생하지 않고 정상 작동하는 것을 확인할 수 있었습니다.

 

성능 욕심과 USB NIC의 뻥카

 그러던 중, 점보 프레임을 사용해 보면 어떨까 하는 생각을 하게 됩니다. 하지만 여전히 VLAN 구간을 지나므로 VLAN 태그 오프로딩 기능이 없다는 점을 감안하여 MTU 사이즈를 안전한 8000 정도로 사용해 보기로 했습니다. NAS의 네트워크 구성, 스위치의 MTU 사이즈, 분산 스위치의 MTU를 조정하고 테스트를 수행했습니다.

 우선 VMware vSphere에서는 분산스위치의 MTU 사이즈를 조절하면 그의 업링크 인터페이스의 MTU 사이즈 역시 같은 값으로 동기화됩니다. 이를 통해 외장 USB NIC에는 MTU 최대 사이즈인 9000이 되도록 하고 iSCSI 어뎁터의 종단점인 VMkernel의 MTU를 8000으로 조정하기로 합니다. NAS 쪽도 MTU 사이즈를 8000으로 맞춥니다.

#esxcli 명령어를 통해 nic의 MTU 상태를 확인

[root@esxi01:~] esxcli network nic list

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description
------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----  -----------------------------------------------------------------------------------------
vmnic0  0000:01:00.0  r8168   Up            Up            1000  Full    b0:41:6f:09:28:dc  1500  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vusb0   Pseudo        uether  Up            Up            1000  Full    58:86:94:31:6c:41  9000  Realtek USB 101001000 LAN

 위 내용에서 장치의 이름이 vusb0인 것이 바로 외장 USB NIC입니다. MTU 사이즈가 9000으로 조정된 것을 확인할 수 있습니다. 또한, VMkernel 어뎁터의 MTU는 8000인 것을 확인할 수 있습니다. 당연하게도 NAS 쪽의 MTU도 8000으로 조정을 하였습니다.

iSCSI용 VMkernel 어뎁터의 MTU 8000으로 설정

NAS의 MTU 사이즈도 8000으로 통일

 이렇게 하니 우선은 iSCSI 연결에는 문제가 없었습니다. 그런데 그다음이 문제였죠. 앞선 상황과 같이 계속 iSCSI 타겟이 유실되는 것이었습니다. 처음에는 VLAN 태그 오프로딩 문제인가 싶어 미세하게 MTU를 조정해 보았지만, 역시나 제대로 작동하지 않는 것을 확인할 수 있었습니다. 정말 혹시나 싶어서 ping -d -s를 통해 전송되는 최대 프레임의 크기를 측정해 보았습니다. 그랬더니 아래와 같은 결과를 얻을 수 있었습니다.

#데이터 크기를 8000으로 esxi 호스트에서 NAS로 ping 테스트
#실패

[root@esxi01:~] ping -d -s 8000 10.10.10.100

PING 192.168.20.254 (10.10.10.100): 8000 data bytes
sendto() failed (Message too long)
sendto() failed (Message too long)
sendto() failed (Message too long)

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1472로 하여 프레임 데이터 합계가 1500바이트가 되도록 테스트
#실패

[root@esxi01:~] ping -d -s 1472 10.10.10.100

PING 10.10.10.100 (10.10.10.100): 1472 data bytes

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1468로 하여 프레임 데이터 합계가 1496바이트가 되도록 테스트
#성공

[root@esxi01:~] ping -d -s 1468 10.10.10.100
PING 10.10.10.100 (10.10.10.100): 1468 data bytes
1476 bytes from 10.10.10.100: icmp_seq=0 ttl=64 time=0.691 ms
1476 bytes from 10.10.10.100: icmp_seq=1 ttl=64 time=0.733 ms
1476 bytes from 10.10.10.100: icmp_seq=2 ttl=64 time=0.767 ms

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.691/0.730/0.767 ms

 혹시나 싶었던 의심이 확신이 되는 순간이었습니다. 명령어 조회를 통해, 또는 UI를 통해 설정했던 MTU값들이 그저 '뻥카'였던 겁니다. 표시만 그렇게 될 뿐, 실제 USB NIC의 MTU는 1500으로 고정이며 당연하게도 VLAN 태그 오프로딩 기능도 없으므로 실질적으로는 1496이 최대 MTU 사이즈인 것입니다. 이런 이유 때문에 MTU가 1450일 때는 아무런 문제 없이 잘 작동했던 것이구요. 역시 외장 USB NIC이 원인인지, 커뮤니티 드라이버가 원인인지 명확하지는 않지만, 그래도 여기에서 문제가 발생하는 것은 확실해졌습니다.

 

 다시 VMkernel과 NAS쪽의 MTU 사이즈를 1468로 낮추고 iSCSI 연결을 하니 문제 없이 잘 작동하는것을 확인할 수 있었습니다. 역시 공식적으로 지원하지 않는 하드웨어를 사용하는데에는 많은 어려움이 있군요.

---

 요 며칠 동안 MTU 때문에 많이 골치를 썩었습니다. 사실 요즘에야 PMTUD(Path MTU Discovery)나 MMS와 같은 기술덕에 이 부분을 크게 신경 쓰지 않는다고는 하는데, 이처럼 호환성이 담보되지 않는 특수한 경우에서는 여전히 문제가 될 소지가 있는 것 같습니다. 덕분에 많은 것을 배웠고 이해할 수 있는 소중한 경험이었습니다.