vSAN Network Design Guide

vSAN 6.6 의 GA 와 함께 따근한 vSAN Network Design Guide 가 나왔습니다. 페이지가 많아서 다 들여다 보기에는 쉽지 않습니다만.. 몇가지만 뽑아내보도록 하겠습니다.

https://storagehub.vmware.com/#!/vmware-vsan/vmware-r-vsan-tm-network-design

NO MORE MULTICAST

vSAN 6.5 버전까지는 vSAN network 을 위해서 Multicast 의 사용이 Requirement 였는데, vSAN 6.6 버전에서는 더이상 Multicast 를 사용하지 않습니다.

기존에는 vSAN 내의 Master Node 로부터 다른 Node 들로의 heartbeat 체킹들을 Multicast 를 통해 진행했었습니다. 그래서 vSAN 내의 호스트들이 Active 한 상태인지 확인이 가능하였습니다.
그러나 vSAN 6.6 부터는 Multicast 가 아니라 Unicast 만 사용합니다.

vSAN 내에는 Master node, Backup node, Agent node 가 있는데요, vSAN cluster 가 구성될 때, vSAN 에서 자동으로 선택하기 때문에, 특별히 따로 할일은 없습니다.

Master node 는 CMMDS (Clustering Monitoring, Membership and Directory Service) 와 관련된 업데이트들을 다른 Node 들로부터 수신합니다.
Backup node 는 Master node 가 가지고 있는 데이터를 동일하게 가지고 있는 Node 이며 Master node 에 장애가 생겼을 때에 Master role 을 수행하는 호스트입니다. 따라서 Master node 에 문제가 생겼더라도, Master node 를 새로 election 하는 과정을 피할 수 있습니다.

CMMDS 관련 트래픽은 얼마 되지 않기 때문에 크게 신경쓰실건 없습니다.

Virtual Machine Disk I/O 는 원래 Unicast 였기 때문에 바뀐 부분은 없습니다.

Physical Nic 관련

Hybrid 냐 All Flash 냐에 따라서 다음과 같이 권장입니다.

HF – 10GB/1GB – 10GB 권장, 그러나 1GB 도 사용가능 <1ms 이내 Latency
AF – 10GB only – 1GB 사용불가, <1ms 이내 Latency
Stretched Cluster – 10GB only, <5ms 이내 Latency
Stretched Cluster Witness – 10GB/1GB – 100MB 연결필요, <200ms 이내 Latency
2-Node Cluster – 10GB for AF, 1GB for HF, 10GB 권장
2-Node Witness – 10GB/1GB, 1.5Mbps bandwidth 필요, <500ms 이내 Latency

참고로 Direct connection 2-node vSAN cluster 는 6.5 버전부터 지원됩니다.

Layer-2 and Layer-3

Layer-2 구성이 강력하게 권장됩니다. Layer 3 구성도 가능합니다만, 6.6 이전버전에서는 Multicast 도 라우팅이 필요합니다.

HF – L2/L3 supported
AF – L2/L3 supported
Stretched Cluster – L2/L3 supported
Stretched Cluster witness – L3 only

Stretched Cluster 구성에서는 Data – witness 간 통신이 아닌 Data- Data 통신이 Witness network 를 타고 가는 경우가 생길 수 있으니 구성에 주의하셔야 합니다.

Mutlicast

vSAN cluster 에 호스트가 조인을 할때 자동으로 Multicast 주소가 assign 됩니다. (Multicast group : 224.1.2.3 / Mutlicast Agent 224.2.3.4)
만약 같은 L2 network 위에 여러개의 vSAN cluster 가 존재한다면, Cluster 별로 Mutlicast 주소를 변경하실 것을 권장합니다. (불필요한 Multicast traffic 를 받을 수 있기 때문)
KB https://kb.vmware.com/kb/2075451 를 참조하세요

NIC Teaming on the vSAN network

굳이 LACP 구성하실필요 없습니다. 특별히 써야하는 이유가 없다면, 기본적인 Active/Standby 구성으로 사용하시는것이 좋겠습니다. vSAN 을 위한 NIC teaming 은 Load Balancing 목적이 아닌 Availability 를 확보하기 위한 목적입니다.

Load Balancing option 1 : Route based on originating virtual port

이 옵션은 사용하면 한번에 1개의 Link 만 사용합니다. Active/Active 나 Active/Standby 로 구성하더라도 동시에 2개의 링크를 사용하는게 아닌 1개의 링크만 사용합니다.

장점 : 구성이 간단
단점 : 10GB 링크 2개가 있더라도 1개만 사용

Load balancing option 2: Route Based on Physical NIC Load (Load Based Teaming)

vDS 에서만 가능한 옵션입니다. 이 옵션을 선택하면, 매 30초동안 업링크의 상태를 체크해서, 75% 이상이 사용중이라고 확인이 되면 다른 링크를 사용하도록 넘깁니다.

장점 : 구성이 간단, 하나의 10GB 네트워크에 vSAN/vMotion/Management Traffic 들이 다 사용될 경우에 유용할 수 있음
단점 : uplink 가 변경되는 과정에서 약간의 overhead 가 발생할 수 있으며, vSAN 을 Load Balancing 하는데는 큰 효과 없음.

Network failure detection, Notify Switches

그냥 디폴트인 값을 사용하실것을 권장합니다.

Failback : 불필요한 Failback 을 줄이기 위해서 No 로 두시는 것이 좋습니다.

Failover order
Active/Standby : Active link 에 장애가 발생하면, Standby link 가 Promote 됩니다.
Active/Active : A/A 로 사용하더라도 동시게 2개의 링크를 사용하지 않습니다. 링크 장애 발생시에 Standby link 가 Active 로 Promote 되는 과정이 생략됩니다. 이것으로 설정했을 때는 Failback 이 반드시 No 로 설정되어야 합니다.

Advanced NIC Teaming

Multiple vmknics for vSAN network

위와 같이 구성하기 위해서는 vmkernel adapter 의 IP 를 다른 Network 으로 분리해야 합니다. (KB https://kb.vmware.com/kb/2010877 참조)

거의 구성하지 않는 편이니 생략하도록 하겠습니다. 그리고 권장하지도 않구요.

나머지는 문서를 한번 보시면 되겠습니다.