현재 VM 호스트의 NIC 팀에 대해 링크 상태만 사용하고 있지만 최근 두 스위치 중 하나에 메모리 오류가 발생하여 트래픽 전달이 중단되는 문제가 발생했습니다. 모든 VM 호스트가 다운되었고, (이미 해당 경로를 사용하고 있던) 대부분의 게스트도 해당 스위치를 수동으로 종료할 때까지 응답을 중지했습니다.
Linux 본딩 환경에서는 링크 상태를 감지하는 또 다른 방법으로 arp_intervals를 사용할 수 있지만 VMWare에는 Beacon Probing만 있습니다. BP는 연결을 테스트할 호스트를 선택하지 않고 이를 수행하려면 3개 이상의 인터페이스가 필요하다는 점에서 arp_interval과 동일하지 않습니다.
모든 VM 호스트에는 4개의 NIC가 있으므로 3개의 NIC 요구 사항은 그다지 문제가 되지 않습니다. 그러나 설명서에는 3개 이상의 개별 물리적 NIC(pNIC)가 필요하다고 명시되어 있지만 모든 예에는 3개의 개별 물리적 스위치도 있으며 이것이 요구 사항인지 여부는 명시되어 있지 않습니다. 이에 대한 답을 찾다보니 이런 생각이 들었습니다.이것블로그에는 다음과 같은 내용이 나와 있습니다.
"vSwitch의 두 개 이상의 pNIC가 동일한 pSwitch에 연결된 경우 비콘 프로빙을 사용하지 마십시오. 이로 인해 pSwitch의 두 개 이상의 포트에 동일한 MAC 주소가 표시될 수 있으며 이는 "매우 나쁜 일"입니다."
우리 구성에는 이 문제를 추가할 세 개의 스위치가 없으며 일부 예비 테스트에서 동일한 스위치에 연결되는 것과 관련될 수 있는 설명할 수 없는 링크 플래핑 문제가 발생했습니다.
그렇다면 비콘 프로빙을 위해서는 3개의 별도 물리적 스위치도 필요합니까? 내 구성에 대해서만 링크 상태로 강등됩니까? 그리고 반쯤 수사적으로 말하면 왜 NIC 팀에서 arp_interval을 옵션으로 포함하지 않습니까?
답변1
비콘 프로빙에서는 비콘이 가장 잘 작동하는 방식인 최소 3개의 pNIC를 사용하는 것이 좋습니다. ESXi는 물리적 NIC 카드에서 브로드캐스트 패킷을 보냅니다. 그런 다음 동일한 vSwitch 내의 다른 pNIC는 다른 pNIC로부터 패킷을 수신하는지 확인하기 위해 기다립니다. 어떤 pNIC가 브로드캐스트를 수신하지 못하더라도 ESXi는 이를 다운링크로 가정합니다.
3개의 pNIC를 모두 동일한 스위치에 연결하고 비컨 프로브를 사용하는 것은 링크 상태가 작동할 때 더 간단하기 때문에 리소스를 낭비하는 것입니다. 링크가 켜져 있나요, 꺼져 있나요? 구성 문제(STP 또는 포트 블록)는 링크 상태와 함께 표시되지 않습니다.
비컨 프로빙의 의도와 설계는 다운스트림 스위치를 "테스트"하는 데 사용되었기 때문에 pNIC를 다른 pSwitch에 연결하는 것이었습니다. pNIC가 연결된 스위치 이외의 스위치. BP는 iSCSI SAN에 대한 세 번째 pSwitch 다운스트림에 오류가 발생했는지 확인할 수 있습니다. 링크 상태에서는 이를 감지하지 못하지만 BP는 감지해야 합니다. 그런 다음 ESXi 서버는 수행하려는 작업을 결정할 수 있습니다. 링크 상태는 사용할 수 없는 경우에도 SAN으로 패킷을 보내려고 계속 시도합니다.