출처: https://blogs.vmware.com/cloud-foundation/2025/06/03/vsan-networking-teaming-for-redundancy/
vSphere의 네트워크 티밍 기능은 단순히 성능 향상만을 위한 것이 아닙니다. 네트워크 인터페이스 카드(NIC)나 스위치에 장애가 발생할 경우 이중화 연결을 제공하는 기능은 모든 운영 환경에서 필수적인 요소입니다. 하지만 이는 자동으로 구현되는 것은 아닙니다. 장애 발생 시 대비 설계를 위해서는 호스트와 스위치를 올바르게 연결하는 방법과 다양한 장애 상황에 대응하도록 하이퍼바이저를 구성하는 방법을 이해해야 합니다.
일부에게는 당연한 것처럼 들릴 수 있지만, 기본적인 구성 방식이 구현되지 않아 필요 이상으로 큰 장애가 발생하는 환경은 드문 일이 아닙니다. vSAN은 분산 스토리지 솔루션이므로 장애 발생 시 대비할 수 있는 호스트의 네트워크 구성은 데이터 가용성에 매우 중요합니다. 아래 구성 항목은 vSAN 환경이 복원력 있는 방식으로 구성되었는지 확인하는 데 도움이 되는 참고 자료입니다.
여기에 설명된 개념은 ” vSAN Networking – Network Topologies “, ” vSAN Networking – Network Oversubscription “, ” vSAN Networking – Optimal Placement of Hosts in Racks “, ” vSAN Networking – Teaming for Performance ” 게시물에서 찾은 정보를 기반으로 합니다. vSAN 네트워킹에 대한 자세한 내용은 vSAN Network Design Guide를 참조하십시오. VCF 환경의 경우 ” VMware Cloud Foundation을 위한 vSAN 네트워크 설계 “를 참조하십시오 .
NIC 오류에 대한 설명
호스트는 NIC 장애 발생 시에도 연결을 유지할 수 있어야 합니다. 최소한 다음 두 가지 조건을 충족해야 합니다.
- 호스트에는 두 개 이상의 물리적 NIC가 있어야 합니다. 서버에 탑재된 최신 NIC는 일반적으로 2~4개의 NIC 포트(업링크라고도 함)를 가지고 있지만, 이것만으로는 NIC에 장애가 발생하더라도 이중화를 보장할 수 없습니다. 경우에 따라 개별 NIC 포트에 장애가 발생할 수 있지만, 대부분의 경우 전체 NIC에 장애가 발생하므로 호스트당 두 개 이상의 NIC가 필요합니다.
- 가상 분산 스위치(VDS)를 올바르게 구성 해야 합니다. 호스트의 VDS는 NIC 장애 발생 시 해당 VDS에 있는 VMkernel 인터페이스와 VM 포트 그룹이 다른 NIC의 다른 포트 로 장애 조치(failover)될 수 있도록 구성되어야 합니다.
예를 들어, 아래 그림에서는 두 개의 포트가 있는 두 개의 NIC가 있는 호스트의 뒷면을 볼 수 있습니다.각 VDS는 두 개의 업링크로 구성됩니다.VDS 자체는 두 업링크를 모두 활성으로 설정할 수 있지만 VDS 내에 생성된 특정 VMkernel 인터페이스는 이 설정을 재정의하도록 구성할 수 있습니다.이 예에서는 “vSAN Networking – Teaming for Performance ” 게시물에 설명된 대로 “Route based on originating virtual port ID “를 사용하여 활성/대기를 사용합니다. vSAN에 태그가 지정된 VMkernel 인터페이스의 경우 vmnic3은 활성으로 설정되고 vmnic1은 대기로 설정됩니다.vMotion에 태그가 지정된 VMkernel 인터페이스도 동일한 VDS에 있지만 리소스를 가장 잘 활용하기 위해 활성 및 대기 업링크가 반대로 되어 있습니다.그림의 오른쪽에 있는 NIC에 장애가 발생하면 vSAN 서비스는 나머지 NIC의 대기 업링크로 장애 조치됩니다.
그림 1. NIC 장애 및 VDS의 대기 포트로의 vSAN VMkernel 인터페이스 장애 조치.
위 예에서 두 개의 개별 VDS 대신 모든 업링크를 포함하는 단일 VDS를 생성할 수도 있었습니다. 두 가지 접근 방식에는 장단점이 있지만, 두 NIC에 걸쳐 두 개의 업링크만 있는 여러 VDS를 생성하면 특정 VMkernel 인터페이스에서 어떤 업링크가 사용되는지 파악하기가 더 쉬울 수 있습니다. 이렇게 하면 활성 및 대기 업링크가 항상 두 개의 서로 다른 NIC에서 전송되도록 보장하는 데 도움이 됩니다 . 모든 업링크를 포함하는 단일 VDS를 사용하면 관리자가 실수로 동일한 NIC에서 전송되는 활성 및 대기 업링크를 선택할 가능성이 높습니다.
ToR 스위치 오류에 대한 설명
중복 네트워킹 업링크는 NIC 장애 발생 시 복원력 그 이상을 제공합니다. 해당 팀에 연결된 업링크가 서로 다른 ToR 스위치에 올바르게 케이블로 연결되어 있다면, ToR 스위치 장애 발생 시에도 호스트를 계속 사용할 수 있습니다.
스위치는 하이퍼바이저의 제어 및 관리 범위를 벗어나는 장치이므로, 장애 감지는 일반적으로 스위치에 연결된 호스트의 업링크 링크 상태를 기반으로 합니다. 이러한 유형의 장애 감지는 호스트에 직접 연결된 스위치에서만 작동합니다. 호스트에 직접 연결되지 않은 스위치를 더욱 정교하게 감지하기 위해 비콘 프로빙을 사용할 수도 있습니다.
스위치 장애 발생 시 vSphere 호스트의 동작은 NIC 장애 발생 시와 거의 동일합니다. 장애가 발생한 스위치에 연결된 업링크를 사용하는 서비스는 사용 가능한 스위치에 연결된 업링크로 페일오버됩니다.
그림 2. 스위치 장애 및 vSAN VMkernel 인터페이스의 VDS 대기 포트로의 장애 조치.
스위치 장애를 적절히 처리 하려면 활성 및 대기 업링크를 해당 ToR 스위치에 올바르게 케이블링해야 합니다. 활성 및 대기 업링크가 동일한 ToR 스위치에 케이블로 연결된 경우, 스위치 장애 발생 시 호스트와 다른 호스트 간의 통신이 차단됩니다. 업링크를 적절하게 케이블링하면 클러스터 내 vSAN 트래픽이 ToR 스위치 내에 머물고 스파인을 통과하지 않도록 할 수 있습니다.
장애를 감지하고 다른 업링크로 페일오버하는 데 얼마나 걸리나요? 실제 소요 시간은 상황과 사용하는 팀 구성 방식에 따라 다르지만, 링크 상태가 변경되면 페일오버는 1초 이내에 완료될 수 있습니다.
권장 사항: 환경 내 VDS에서 CDP/LLDP를 활성화하세요. 이는 호스트 업링크에서 사용되는 물리적 스위치 포트를 직접 문서화하는 좋은 방법입니다. 많은 노력이 필요하지 않지만, 네트워크 토폴로지에 대한 귀중한 정보를 제공할 수 있습니다.
NIC 또는 스위치 장애 시 성능 저하
vSphere 또는 vSAN 클러스터는 공유 하드웨어 리소스의 집합입니다. NIC와 같은 장치에 장애가 발생하면 동일한 양의 워크로드가 더 적은 리소스를 사용하게 될 가능성이 있습니다. 이러한 유형의 장애를 처리하는 가장 좋은 방법은 무엇일까요? 몇 가지 옵션은 다음과 같습니다.
- Network I/O Control (NIOC)를 사용하세요. vSAN에서 NIOC 를 적절한 설정과 함께 사용하면 vSAN VMkernel 트래픽이 다른 트래픽 유형과 병합되어 새로운 업링크로 전송되는 장애 상황에서 vSAN 트래픽의 우선순위를 지정하는 데 도움이 됩니다.
- 서비스와 워크로드를 업링크 전체에 균등하게 분산합니다. 2포트 NIC가 두 개 있는 경우, 다양한 VMkernel 인터페이스와 VM 포트 그룹을 사용 가능한 NIC에 최대한 균등하게 분산합니다. 또한, 장애가 발생하지 않은 상태와 장애가 발생하지 않은 상태에서의 모습을 상상하여 가장 적합한지 확인하십시오.
- 업링크 수를 늘리세요. NIC 장애 발생 시 최적의 운영 상태를 유지하도록 설계하는 경우, 이 요구 사항을 충족하기 위해 더 많은 업링크가 필요할 수 있습니다.
- 더 높은 대역폭의 링크를 사용하세요. 더 높은 대역폭의 업링크를 사용하면 호스트에서 더 많은 업링크가 필요하지 않습니다. 예를 들어, 100GbE 링크 2개는 25GbE 링크 8개와 동일한 대역폭을 제공할 수 있습니다. 또한 스위치의 네트워크 포트 사용량을 줄이는 이점도 있습니다.
회색 실패
모든 장애가 명확하고 영구적이며 구분 가능한 것은 아닙니다. 예를 들어, 일부 NIC 포트는 링크 상태가 주기적으로 변하는 현상(포트 플래핑이라고도 함)을 경험합니다. 다른 NIC 포트는 이더넷이 NIC와 스위치 간에 지원되는 최고 속도를 자동으로 협상하는 기능에 문제가 발생하여, 오류 없이 포트 속도가 훨씬 낮은 지원 속도로 무작위로 떨어질 수 있습니다. 이러한 문제는 NIC의 펌웨어, 드라이버 또는 물리적 링크 문제로 인해 발생할 수 있습니다.
이러한 유형의 문제는 간헐적으로 발생하기 때문에 감지하기 어려울 수 있습니다. vSAN은 데이터를 복원력 있게 저장하기 위해 네트워크에 의존하기 때문에 이러한 유형의 문제에 대한 인식이 특히 중요합니다. 감지되지 않은 비바이너리 장애는 종종 VM에서 비정상적으로 높은 지연 시간을 발생시키는 성능 문제로만 나타납니다. 이러한 유형의 문제를 더 명확하게 파악하려면 어떻게 해야 할까요? VCF Operations for Logs를 사용하면 간과될 수 있는 이러한 유형의 로그 이벤트를 쉽게 파악할 수 있습니다.
그림 3. VCF Operations for Logs를 사용하여 호스트 NIC의 연결 문제 감지.
vSAN 네트워킹에 대한 자세한 내용은 vSAN Network Design Guide를 참조하십시오 . VCF 환경의 경우 ” VMware Cloud Foundation용 vSAN 네트워크 설계 “를 참조하십시오.
요약
vSAN 호스트는 적절한 VDS 구성과 함께 중복 스위치에 연결된 중복 NIC를 사용해야 하며, 이를 통해 vSAN 호스트가 네트워크 관련 중단 중에도 적절한 연결을 유지할 수 있습니다.
