배경

Windows 장애 조치 클러스터가 중단 된 사고가있었습니다. 사후 검토 에서이 기사에서 설명한대로 노드가 "제거" 되었다고 표시 했습니다 .

최근에이 클러스터를 VMware 환경으로 완전히 마이그레이션했으며 위에서 설명한 이벤트가 중단의 원인 일 수 있습니다.

이에 대한 관련 VMware KB 기사에서는 설정 Small Rx Buffers및 Rx Ring #1설정을 늘리는 방법에 대해 설명 하지만 너무 많이 늘리면 호스트의 메모리 오버 헤드가 크게 증가 할 수 있습니다.

Network Interface\Packets Received Discarded~ 150 개의 Windows VM에 대한 성능 카운터를 감사 한 후 16 개 게스트에서 22 개의 vNIC에 버려진 패킷이있었습니다.

추가 메모리 사용량으로 호스트에 부담을주지 않을 정도로 적은 양이지만 이러한 설정에 메모리가 사용되는 방식과 메모리의 출처를 이해하고 싶습니다.

질문

1. 버퍼 수와 링 크기 사이의 관계는 무엇입니까?
2. 이러한 설정 값에 사용 된 메모리 양을 어떻게 계산합니까?
3. 이러한 설정은 게스트 OS 내의 NIC 자체에 있기 때문에 드라이버 설정이라고 가정합니다. 이것은 사용 된 RAM이 페이징되거나 비 페이징 풀이라고 생각합니다.
   1. 이 올바른지?
   2. 그렇다면 걱정해야합니까?
4. 여기에서 고려하지 않은 문제가 있습니까?

VMware 호스트 메모리 사용량 이외의 영향을받는 VM에서이를 최대 값으로 설정하는 데 단점이 있는지 확인하려고합니다. 예를 들어 게스트에서 풀 메모리가 고갈 될 위험이 증가하면 소규모로 시작하는 경향이 더 큽니다.

이러한 질문 중 일부 (아마도 모두)는 VMware 또는 가상화에만 국한되지 않을 수 있습니다.

버퍼 수와 링 크기 사이의 관계는 무엇입니까?

그들은 관련이 있지만 독립적입니다. rx "링"은 들어오는 네트워크 패킷을 호스트 (하이퍼 바이저)에서 게스트 (Windows VM)로 전달하기 위해 큐로 사용되는 메모리의 버퍼 세트를 나타냅니다. 메모리는 네트워크 드라이버에 의해 게스트에 예약되어 호스트 메모리에 매핑됩니다.

새로운 네트워크 패킷이 호스트에 들어 오면 링에서 사용 가능한 다음 버퍼에 배치됩니다. 그런 다음 호스트는 게스트에서 IRQ를 트리거합니다. 게스트 드라이버는 링에서 패킷을 가져와 게스트 OS의 네트워크 스택으로 디스패치하여 게스트 OS가 응답하도록 게스트 응용 프로그램으로 보냅니다. 패킷이 충분히 느려지고 게스트 드라이버가 충분히 빠르게 처리한다고 가정하면 항상 링에 여유 슬롯이 있어야합니다. 그러나 패킷이 너무 빨리 들어 오거나 게스트가 너무 느리게 처리하는 경우 링이 가득 찰 수 있으며 상황에 따라 패킷이 삭제 될 수 있습니다.

링 크기를 늘리면이 문제를 완화하는 데 도움이 될 수 있습니다. 늘리면 한 번에 더 많은 슬롯을 링에서 사용할 수 있습니다. 이것은 두 번째 설정 인 "Small Rx Buffers"로 이어지며, 링의 슬롯을 채우는 데 사용할 수있는 총 버퍼 양입니다. 링의 슬롯 수만큼 버퍼가 있어야합니다. 일반적으로 더 많이 원합니다. 게스트가 게스트 네트워크 스택에 제공하기 위해 링에서 버퍼를 꺼낼 때 항상 즉시 드라이버로 반환되는 것은 아닙니다. 이 경우 링을 채우는 여분의 버퍼가 있으면 패킷을 삭제하지 않고도 더 오래 갈 수 있습니다.

Rx Ring # 1 / Small Rx Buffers는 비 점보 프레임에 사용됩니다. 기본 NIC 구성이있는 경우 이것이 유일하게 사용되는 링입니다.

이러한 설정 값에 사용 된 메모리 양을 어떻게 계산합니까?

비 점보 프레임에 대해 이야기 할 때 각 버퍼는 전체 네트워크 패킷 (약 1.5kb)을 저장할 수있을만큼 커야합니다. 따라서 8192 개의 버퍼를 사용할 수 있으면 12MB를 사용합니다. 더 큰 링은 더 많은 메모리를 사용하지만 디스크립터는 작으므로 (바이트) 실제로 걱정해야 할 버퍼입니다.

이러한 설정은 게스트 OS 내의 NIC 자체에 있기 때문에 드라이버 설정이라고 가정합니다. 이것은 사용 된 RAM이 페이징되거나 비 페이징 풀이라고 생각합니다.

예, 비 페이징 풀입니다. 링 버퍼가 페이징 된 경우 버퍼가 다시 페이징되는 동안 패킷이 손실 될 수 있습니다.

여기에서 고려하지 않은 문제가 있습니까?

이것이 귀하의 상황과 관련이 있는지는 확실하지 않지만 더 큰 링은 네트워크 rx 경로의 캐시 풋 프린트를 증가시킬 것입니다. 마이크로 벤치 마크에서는 링이 클수록 일반적으로 성능이 저하된다는 것을 알 수 있습니다. 즉, 실제 응용 프로그램에서 패킷이 손실되면 속도 버스트의 작은 성능 향상보다 일반적으로 더 큽니다.

출처 : 저는 VMware에서 근무했습니다.

1-2-3 점에 대한 답변이 없지만 가상 enginner에게 Vmware 호스트 구성에 대해 확인할 수 있습니다. 그가 VCP라면 그는 물건을 이해할 것입니다 :)

Windows 문제가 게스트가 아닌 호스트에있을 수 있으므로 호스트를 확인해야합니다.

당신의 문제, directpath io, rss, vcpu, 전원 관리 체계를 설명 할 수있는 많은 하드웨어 기능이 있습니다 ...

나는 당신에게 당신의 가상 팀 또는 당신을 도울 수있는 링크를 줄 수 있습니다 :)

이 링크는 http://buildvirtual.net/tuning-esxi-host-networking-configuration/ 호스트 조정에 관한 것입니다.

그리고이 지방 pdf :

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

그리고 이것은 rss에 관한 것입니다.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925

나는 완전한 페이지를 찾고 당신을 올바른 페이지로 안내 할 수있는 입장에 있지 않습니다 : 그래서 나는 당신에게 세부 사항을 스스로 찾아 보라고 요구합니다 ... (죄송합니다)

Fail over Cluster에는 tweeked 될 수있는 4 가지 설정이 있습니다. 버퍼 또는 페이징 또는 비 페이징에 영향을 미치지 않습니다. 클러스터 장애 조치 (Fail over Cluster)가 노드를 "제거"한 것으로 간주하는 방식을 변경합니다. 이러한 설정은 다음과 같습니다.

SameSubnetDelay SameSubnetThreshold CrossSubnetDelay 교차 서브넷 임계 값

그들은 당신의 문제를 해결하지 못할 수도 있지만, 이것을 조정하면 현재 문제에서 벗어날 수 있습니다 ...

월요일에 돌아 오면 추가 질문이 있으면이 게시물을 다시 확인하겠습니다.

에드윈.