 VSAN 설1221;할ǐ12; 업링크 2개를 active active /196; 설1221;했lj16;데도 불구Ȣ16;고, 스위치1901;에서 트래픽1012; 확1064;해 보면 한1901;1004;/196;만 7120;릅니다..그 한1901;1004;/196; 트래픽1060; Ǻ12;1796;ǐ12;lj16; 몰/140;서 
스위치1901; 포트에서 확1064;해 보면 output discard 현상1060; 1068;Ǻ12;납니다... 한1901;1004;/196;만 7120;르lj16;,144; 1221;상1064;가요?? 아니면 설1221;할ǐ12; 뭔가 특별7176; ,148;들Ǻ12;야 Ȣ16;lj16;,172; 1080;lj16;1648; Ƽ17;금합니다. 회사에서 vsan 도1077;처1020;1060;라 시스템 1901; NJ12;NJ17;Ȣ16;시lj16; ǥ16;1008; 그냥 메뉴얼보면서 설1221;Ȣ16;ǯ12;다고 Ȣ16;셔서요. 특별7176; 설1221;1088;체가 Ǻ12;/140;운,148; 없었다고 Ȣ16;ǯ12;,144;든요..
P.S 현1116; 설1221;.108; 상태 캡쳐한,144; 올립니다.
- VSAN의 Uplink을 하나만 사용 하는 것을 권고 하고, 트래픽이 너무 많을 때 2개를 사용 (1개와 여러 개 사용시의 장단점 정리와 대충 어느 정도 일때 여러개 사용 내용이 문서로 되어 있습니다.)
- 현재 Teaming 정책이 Route based on orininaing virtual port 으로 되어 있을 것으로 예상 되며, Route based on orininaing virtual port은 A/S으로 해야 된다고 기억 합니다.
- A/A 으로 사용 하기 위해서는 Route based on IP hash 와 Route based on physical network adapter load 가 있는데, 특히 IP hash는 성능 이점이 없을 수도 있습니다. (VSAN 운영 중에 Teaming 정책 바꾸는 것은 스위치 설정 및 단절이 발생 될 수 있으니 모든 VM 종료 상태에서 해야 합니다.)
- 상단 물리 스위치의 spaning-tree 설정에 따라서 VSAN 가상스위치 설정이 다름.
- 기타 등등...
VMware 하시는 분들 중에서 일반 문서만 보고 VVD 문서을 안 보고, 또는 Network 잘 모르시느 분들이 많이 있어서 이런 저런 문제가 생기는 경우가 많습니다.
담당자분께 Teaming, Spanning-Tree, Network 구성(ex. IP hash)에 따른 VSAN 구성이 맞는지 확인 해 달라고 하세요.
일단 설정에 문제가 있는거 같으니, 내일 담당자와 이야기 해보도록 하겠습니다 ^^
위에 언급 해 드린 STP에 대한 내용도 있으며, beacon 설정 등 세부 사항들이 있습니다.
https://docs.vmware.com/en/VMware-vSphere/7.0/vsan-network-design-guide/GUID-4ECAF913-95E6-4A7C-89A7-BF06DC03F18C.html
A/A을 사용 하기 위한 정책 결정은 상단 스위치에서 권고 하는 수준에서 거의 결정 됩니다.
혹시 몰라서 설정 캡쳐한것을 원문에 첨부하였습니다.
참고로 LACP 처럼 동시에 트래픽이 분산 되어서 처리 하지 않습니다.!!! End-To-End 연결 포인트를 분산 하는 것 입니다.
예. Host1 - Host2, Host1 - Host3 의 트래픽 NIC1에서 75% 이상 사용 할 경우, Host1-Host2는 NIC1 & Host1-Host3는 NIC2로 분산 입니다.
LACP와 같이 항시 모든 NIC에 분산 처리 하지 않습니다.!!!
물리 포트 링크 속도 증가 또는 LBT로 대응 불가능한 상황인가요?
총 서버가 4개가 연결되어 있는데, 2개만 이런 현상이 발생합니다...sfp 가 고장이 난거면 스위치쪽에서 에러메시지가 확인가능하기 떄문에 이건 아닌거 같고, vsan 도 좀전에 트래픽 양을 vcenter 에서 확인해 보니 10메가도 채 되지 않습니다...미스테리 하네요..
첫번째 서버에는 vm 도 전혀 들어가 있지 않아도 도대체 어떤게 순간적으로 트래픽을 저렇게 유발하는지, 어떤 트래픽이 드랍되는지 알수가 없네요.
drop이 발생할 때 port queue도 한번 모니터링 해 보시구요. burst traffic이 밀려들어와서 순간적으로 버퍼에서 드랍이 발생하는 경우라면, LACP로 해결되지 않을 가능성이 있습니다.
10Gbps S/W의 VSAN에서 이 정도로는 성능 부족 하지 않습니다.
장비 혹은 설정 등의 문제 가능성이 높습니다.
언급되는 내용들 보면 기본적인 설계, 가이드, 설치확인도 안된 것 같고요.
문제가 생겼음에도 커뮤니티에 의존해야할 정도로 지원도 못 받는 것 같습니다.
좀 답답하시것습니다.
화웨이는 Intel NIC을 써도 Firmware 문제 많고, 후지쯔는 엔진니어가 제대로 지원 못 하고, 레노보는 옛날의 IBM이 아닌 마감 상태 안 좋았습니다.
특히 레이드 배터리 없다고 ESXi 설치 안 되는 현상은 황당
DellEMC와 HPE가 그래도 쓸만 합니다.
위에서는 밑에 능력 때문에 제대로 못 하는 것인지? 장비 문제가 원인인지?? 제대로 인지를 못 할 수도 있기 때문에 잘 설득 하셔야 합니다.
하드웨어야 흥마님 말씀 처럼 장애리스트 정리해서 보고하면 장애시간 -> 비용으로 환산되니 설득가능한 요소일겁니다.
다만, 하드웨어와 솔루션이 하나로 뭉뚱구려져서 최저가로 진행되버리면,
해당 솔루션에 대한 역량 없는 업체가 진행하면서 이런 일이 생기는게 아닌가 싶습니다.
토닥토닥~