100Mbps 관리망을 유지하고 vMotion과 NFS를 직결한 과정

ESXi 호스트를 구성한 뒤 스위치 구간의 속도가 걸렸다. 서버 NIC에는 1Gbps 링크를 사용할 수 있었지만 기존 관리망은 100Mbps로 연결돼 있었다. 처음에는 스위치를 바꾸는 방향을 검토했다. 다른 L3 스위치도 확인했지만, 모델을 살펴본 뒤 관리 구간은 100Mbps로 유지하기로 했다.

대신 트래픽 경로를 나눴다. ESXi 두 대 사이를 vMotion용으로 직접 연결하고, 각 ESXi와 NFS 서버도 각각 직접 연결했다. 모든 서비스망을 기가비트로 바꾼 구성이 아니라 VM 이동과 스토리지 접근에 별도 경로를 만든 것이다.

물리 포트의 역할부터 나눴다

직결망을 만들면서 관리 트래픽, vMotion, NFS가 어느 NIC를 사용하는지 구분했다. ESXi 사이에는 별도 VMkernel 경로를 두고, NFS 서버에서는 두 개의 직결 NIC를 브리지에 연결했다. NFS용 주소는 브리지에 두는 구성이었다.

포트 번호는 양쪽 서버에서 같은 의미가 아니었다. 한 ESXi에서는 관리 연결이었던 번호가 다른 호스트에서는 직결 링크였다. 그래서 포트 이름만 보지 않고 케이블의 상대 장비와 실제 협상 속도를 함께 확인했다.

NFS 케이블을 연결해도 링크가 올라오지 않았다

vMotion 쪽 문제를 정리한 다음에는 ESXi와 NFS 서버 사이의 연결이 남았다. 케이블을 연결했는데 NFS 서버 쪽 인터페이스가 DOWN이었다. 처음부터 케이블 불량이나 크로스 케이블 종류만 의심하기보다 Linux가 포트를 활성화한 상태인지 봤다.

진단에는 다음 두 명령을 사용했다. 장치명은 당시 실제 인터페이스를 대상으로 확인했다.

ip -br link
ethtool "$NFS_NIC"  # NFS_NIC에는 조회할 실제 인터페이스 이름을 지정

초기 출력에서 직결용 인터페이스에는 UP 플래그가 없었다. ethtool에서는 Speed: Unknown!, Duplex: Unknown!, Link detected: no가 나왔다. 지원 모드에 1000baseT가 있다는 것과 현재 링크가 올라와 있다는 것은 달랐다.

인터페이스를 활성화한 뒤에는 NFS 직결 두 포트가 모두 1000Mb/s, Full, Link detected: yes로 바뀌었다. 관리 NIC는 100Mb/s로 남았다. 이 결과를 보고 케이블 교체에 앞서 인터페이스의 administrative state를 확인해야 한다는 점을 정리했다.

장치명을 잘못 입력해 No such device를 본 시행착오도 있었다. 실제로 없는 이름을 조회한 오류와, 존재하는 NIC의 링크가 내려간 상태를 구분해야 했다. 비슷한 출력이라도 같은 원인으로 묶을 수 없었다.

링크 활성화와 브리지 구성을 따로 확인했다

이후 브리지를 다시 만들려 했을 때는 다음 오류가 나왔다.

RTNETLINK answers: File exists

브리지가 없어서 연결이 안 되는 것으로 생각하고 재생성을 시도했지만 이미 존재했다. 현재 상태를 조회하니 NFS용 브리지가 UP이었고, 직결 NIC 두 개가 그 브리지의 멤버로 forwarding 상태였다. 인터페이스를 추가하는 명령보다 이미 만들어진 객체와 연결 관계를 먼저 확인할 상황이었다.

실행 중 상태와 영구 설정도 나눠 봤다. 당시 살펴본 Netplan 파일에는 관리 NIC만 있었다. 브리지가 현재 동작한다고 해서 재부팅 뒤에도 같은 구성이 적용된다고 생각할 수는 없었다. 이후 영구 설정 작업을 마치고 연결이 되는 것을 확인했다.

링크 속도와 전송 성능은 구별했다

이번에 확인한 1Gbps는 링크 협상 결과다. 스토리지 작업이 항상 그 속도로 처리된다는 뜻으로 사용하지 않았다. 실제 Storage vMotion을 진행할 때는 네트워크 링크와 별개로 NFS 서버의 디스크 쓰기 상태도 살펴봐야 했다.

직결망으로 관리 스위치의 제약을 피할 경로는 만들었지만, 공유 NFS 서버 한 대에 의존하는 구조는 그대로였다. 연결 속도를 확보하는 일과 저장소 가용성을 높이는 일은 다음에도 별개로 다룰 생각이다.