들어가며
이번에는 Home Lab 환경에서 vSAN ESA를 RDMA를 사용하도록 구성하고, 구성을 검증하는 방법을 step-by-step으로 알아볼 것이다.
이 포스팅에서는 vSAN ESA와 RDMA를 함께 사용하기 위한 네트워크, NIC, vSphere 구성도 함께 다룰 것이다.
클러스터 구성
테스트에 사용된 클러스터의 구성은 다음과 같다
- ESXi Host: Huawei 1288H V5 / 2288H V5 (총 8대)
- NIC: Mellanox ConnectX-4 100GbE Dual Port
- Switch: Arista DCS-7304 (w/ 4x 7320X-32C-LC)
- SSD: Intel P4610 3.2TB U.2 NVMe SSD (x16) / Micron 7300 MAX 3.2TB U.2 NVMe SSD (x16) - 백플레인 불량으로 디스크 하나 사용 불가
- vSphere: vSphere 8.0 U3b (Build 24280767)
그리고 클러스터는 다음과 같은 요구사항을 만족해야 한다.
vSAN ESA 구성 요구사항
vSAN ESA Ready Node
현재 vSAN ESA는 Ready Node로 인증된 시스템만을 공식적으로 지원한다.
Ready Node가 아닌 시스템에서도 ESA를 활성화 할 수 있지만, VMware의 공식 지원을 받을 수 없다. 홈 랩이 아닌 프로덕션 환경에서는 ESA Ready Node를 사용해야 한다.
10GbE 이상의 네트워크
vSAN ESA의 성능을 제대로 활용하기 위해서는 25Gbps 이상의 네트워크 대역폭이 필요하다.
단, 최근에 AF-0 ESA Ready Node 구성이 승인되면서, 공식적으로 10GbE 네트워크로 ESA를 구성할 수 있게 되었다.
NIC 펌웨어 버전
vSAN OSA와 마찬가지로, vSAN ESA 또한 NIC 펌웨어에 대한 호환성 목록을 가지고 있다.
Broadcom Compatibility Guide에서 VCF/vSAN Ready Node 목록을 확인할 수 있고, 해당 시스템에서 지원하는 NIC도 함께 확인할 수 있다.
단, NIC의 vSAN 호환성은 OSA/ESA를 구분하지 않는다.
Ready Node가 아닌 경우, vSAN Over RDMA 의 지원 여부를 참고할 수 있다.
내가 사용하는 ConnectX-4 EN NIC의 경우 12.28.2006 버전이 필요하며, Mellanox MFT의 mlxfwmanager를 통해 현재 펌웨어 버전을 확인할 수 있다.
RDMA 구성 요구사항
vSAN ESA에서 RDMA 기능을 활성화 하기 위해서는 다음과 같은 구성요소가 필요하다.
- RoCEv2 지원 NIC
- DCBx/PFC 지원 이더넷 스위치
vSAN ESA over RDMA 구성하기
현재 환경이 사전 요구사항을 모두 만족한다면, 실제 구성 작업을 진행할 수 있다.
스위치 설정
먼저, 스위치에서 RoCEv2를 구성한다.
LLDP 활성화
DCBx가 LLDP를 기반으로 동작하기 때문에, config 모드에서 lldp run 명령어를 실행하여 LLDP를 전역적으로 활성화 한다.
LLDP를 활성화 할 경우, 스위치의 전체 인터페이스에서 RX/TX가 모두 허용된다.
인터페이스별 LLDP 구성 상태를 확인하려면 show lldp 명령어를 사용한다.
PFC 구성
PFC를 이용해 Lossless Fabric을 구성한다.
# Config Mode
interface ethernet 3/1/1
dcbx mode ieee
qos trust dscp
priority-flow-control on
priority-flow-control priority 3 no-drop설정이 완료된 인터페이스 구성의 예시는 다음과 같다.
NIC 설정
NIC에서도 DCBx/PFC 설정을 구성해야 한다. 이 때, 펌웨어 수준에서 설정해야 하는 것과 펌웨어/드라이버 모두에서 설정해야 하는 것, 드라이버에서 설정해야 하는 것이 나뉜다.
펌웨어 설정
- DCBx 활성화 여부
- LLDP TX/RX 활성화 여부
- DCBx 모드 (IEEE/CEE)
펌웨어/드라이버 설정
- PFC Lossless Class
드라이버 설정
- DCBx 동작 모드
- PCP/DSCP (L2/L3 Trust) 모드 선택
펌웨어 구성 예시
/opt/mellanox/bin/mlxconfig -d 0000:86:00.0 set \
LLDP_NB_DCBX_P1=1 LLDP_NB_RX_MODE_P1=2 LLDP_NB_TX_MODE_P1=2 DCBX_WILLING_P1=1 \
LLDP_NB_DCBX_P2=1 LLDP_NB_RX_MODE_P2=2 LLDP_NB_TX_MODE_P2=2 DCBX_WILLING_P2=1 \
DCBX_IEEE_P1=1 DCBX_CEE_P1=0 DCBX_IEEE_P2=1 DCBX_CEE_P2=0 \
CNP_DSCP_P1=26 CNP_DSCP_P2=26 CNP_802P_PRIO_P1=3 CNP_802P_PRIO_P2=3위 펌웨어 설정은 ECN의 CNP가 사용하는 PCP/DSCP Class를 3으로 설정하고, LLDP/DCBx를 활성화 한 뒤 동작 모드를 IEEE로 설정한다.
드라이버 구성 예시
esxcli system module parameters set -m nmlx5_core -p "pfctx=0x08 pfcrx=0x08 trust_state=2 dcbx=1"
esxcli system module parameters set -m nmlx5_rdma -p "pcp_force=3 dscp_force=26"위 드라이버 파라미터 구성은 RDMA 트래픽의 PFC Class를 3으로 구성한 뒤 DCBx 설정이 펌웨어 구성을 따라가게 한다.
그리고 PFC L3 Trust (DSCP) 모드를 활성화한다.
마지막으로, ESXi에 펌웨어와 드라이버 설정을 적용하기 위해 호스트를 재부팅 해야 한다.
호스트의 재부팅이 완료되면, esxcli network nic dcb status get 명령어를 통해 현재 ESXi의 PFC 구성 상태를 확인할 수 있다.
Optimal 한 구성에서는 ETS/ECN을 활성화해야 하나, 이 내용은 차후 포스팅에서 다룰 것이다.
vSAN ESA over RDMA 구성
준비가 완료되었으니, 이제 실제로 vSAN ESA를 구성할 때가 되었다.
1) Cluster Configure > vSAN > Services 메뉴에서, vSAN HCI 구성을 시작한다
2) vSAN ESA를 활성화 한다
3) RDMA Support를 켜고, Auto-Policy management를 끈다
4) vSAN ESA에서 사용할 NVMe 디스크를 Claim 한다
위 그림의 경우에는 기존에 이미 모든 NVMe 디스크를 Claim 한 상태이기 때문에, Eligible Disk가 보이지 않지만, 새로 클러스터를 구성하는 경우에는 Claim 열의 체크박스를 선택하여 NVMe 디스크를 Claim 할 수 있다.
5) Fault Domain을 설정한다
일반적으로는 전체 노드를 하나의 Fault Domain으로 취급하게 될 것이다.
6) 지금까지의 구성을 Review 하고, vSAN ESA 구성을 진행한다.
구성 검토
Cluster의 Configure/Monitor 탭에서 vSAN 구성을 확인할 수 있다
1) Configure > vSAN > Services
클러스터의 전반적인 구성 상태와 컴포넌트의 Health를 확인한다.
2) Configure > vSAN > Disk Management
3) **Monitor > vSAN > Skyline Health
vSAN 클러스터의 상태와 구성 불일치 등을 종합적으로 확인할 수 있는 대시보드이다.
4) VSISH RDT 정보
vsish -e get /vmkModules/rdt/clusterProtocol
vsish -e get /vmkModules/rdt/allConnCount
위와 같이 2번 (RDMA) 프로토콜로 RDT 커넥션을 맺고 있으면 vSAN이 RDMA 모드로 동작하고 있는 것이다.
Storage Policy 구성
클러스터의 정상 동작을 확인한 뒤, vSAN Object의 Storage Policy를 구성한다.
1) vSAN Performance Service 정책 구성
4대 이하의 호스트를 가진 클러스터에서는 vSAN ESA Default Policy - RAID5를, 5대 이상의 호스트를 가진 클러스터에서는 vSAN ESA Default Policy - RAID6 를 사용할 것을 권장한다
2) vSAN Datastore Default Policy 구성
마찬가지로, 노드의 수에 따라 RAID5/RAID6을 유동적으로 구성한다.
트러블슈팅
CMMDS에서 Cluster Partitioning을 보고할 때
먼저, 호스트에서 esxcli vsan cluster get 명령어를 실행하여 vSAN 클러스터 상태를 확인한다.
만약 위 그림과 같이, 하나의 호스트만 보인다면 vSAN 구성에 문제가 있는 것이다.
이런 경우에는 크게 다음과 같이 경우의 수를 구분할 수 있다.
- 네트워크 구성 문제
- Unicast Agent 등록 문제
- 클러스터 등록 문제
- 구성 불일치 문제
문제를 파악하기 위해 다음과 같은 점검 절차를 수행한다.
vmkping을 이용한 노드간 통신 검증
문제가 생긴 노드에서 다른 노드와 통신을 시도했을 때, 정상적으로 통신이 이루어지는지 확인한다.
MTU 미스매치로 인한 문제가 발생할 수 있으므로, vSwitch의 MTU 값을 사용한 ping 테스트도 진행한다.
위 경우, 노드간 통신에는 이상이 없었다. 따라서 네트워크 문제가 아니라는 것을 확인할 수 있었다.
만약 네트워크 연결에 이상이 있다면, vSAN 네트워크의 논리/물리적 구성, VLAN 구성, MTU 구성 등을 점검해 봐야 한다.
Unicast Agent 등록 문제
CMMDS는 노드간 통신을 위해 Unicast Agent 목록을 관리한다. 만약 vSAN 구성 과정에서 어떠한 이유로 이 목록이 정상적으로 구성되지 않는다면, vSAN 클러스터간 통신에 실패할 수 있다.
문제가 있는 호스트에서 esxcli vsan cluster unicastagent list 명령어를 실행한다.
출력된 목록에 자기 자신을 제외한 다른 클러스터 노드들이 모두 보이면 정상이다.
따라서, 이 경우에는 Unicast Agent 등록 문제도 아니었음을 알 수 있다.
만약 Unicast Agent 목록에 이상이 있다면, 수동으로 클러스터의 다른 노드를 추가해 줌으로써 문제를 해결할 수 있다.
VMware KB 326427 을 참고하여 Unicast Agent를 등록하고, 네트워크 파티션 문제가 해결되는지 확인한다.
클러스터 등록 문제
어떠한 이유로 인해, vSAN 구성 과정에서 클러스터가 제대로 등록되지 않았다면 문제가 발생할 수 있다.
대부분의 경우, vSAN 노드를 클러스터에 다시 조인해 주면 해결된다.
문제가 있는 호스트에서 esxcli vsan cluster leave 명령어를 실행한다.
그리고 esxcli vsan cluster -u <Sub-Cluster-UUID> 를 실행한다. Sub-Cluster UUID는 정상 노드의 esxcli vsan cluster get 명령어의 출력에서 확인할 수 있다.
vSAN ESA의 경우, esxcli vsan cluster -x -u <Sub-Cluster-UUID> 를 실행한다.
위 경우에는 노드를 클러스터에 다시 조인한 뒤에도 문제가 지속되었다.
구성 불일치 문제
다음으로 고려해 볼 수 있는 것은 vSAN 노드간의 구성 불일치 문제이다. 이전에 vSAN 클러스터를 만들었다 파괴하는 일을 몇 번 반복했기 때문에 새로 클러스터를 구성하는 과정에서 일부 노드에서 기존 구성의 cleanup이 완전히 이루어지지 않았을 수 있다고 판단했다.
이러한 경우 vsanmgmtd를 재시작하는 것이 도움이 될 수 있다. /etc/init.d/vsanmgmtd restart 명령어를 실행하여 매니지먼트 데몬이 구성 정보를 재동기화하게 한다.
vsanmgmtd를 재시작 한 뒤에도 문제가 지속된다면, ESXi 호스트를 재시작하여 설정을 다시 로드하게 한다.
호스트 재시작 후 최종적으로 문제가 해결되었다.
vSAN 클러스터에서 RDMA Configuration Issue 를 보고하는 경우
vSAN > Skyline Health 에서 어떤 노드/포트에 문제가 있는지 확인한다.
DCBx 구성 문제의 경우, esxcli network nic dcb status get 명령어를 통해 현재 구성 상태를 확인할 수 있다.
Skyline Health에서 보고한 대로, DCBx 모드가 IEEE가 아닌 Unknown으로 구성되어 있음을 알 수 있다.
이 문제의 원인은 매우 다양한데, 펌웨어/드라이버 설정, 펌웨어 버전 불일치, ESXi DCBx 에이전트의 버그 등을 고려할 수 있다.
만약 모든 설정과 펌웨어 구성이 정상이라면, VMware에 지원 티켓을 열어서 문제를 해결해야 한다. 다만, 구성이 정상적으로 되어 있다면 성능에는 영향을 미치지 않는다.
