Sub-NUMA 클러스터링

더 많은 ESXi 호스트에서 Sub-NUMA 클러스터링을 사용하도록 설정하는 추세를 확인했습니다. 일반적으로 이 설정은 고성능 컴퓨팅 공간 또는 통신 환경에서 사용되며, 여기서 마지막 1밀리초의 지연 시간을 줄이고 시스템이 제공할 수 있는 모든 대역폭을 압축해야 합니다. 이러한 워크로드는 대부분 고도로 조정되고 제어된 환경에서 작동하는 반면 ESXi 서버는 일반적으로 조직 내에서 상상할 수 있는 모든 유형의 워크로드 모음을 실행합니다. 이제 Sub-NUMA 클러스터링의 기능을 살펴보고 사용자 환경에서 이 기능을 사용하도록 설정하는 것이 적절한지 살펴보겠습니다.

NUMA

대부분의 데이터 센터 서버 시스템은 NUMA 시스템입니다. NUMA 시스템에서 각 CPU에는 로컬로 연결된 메모리에 액세스할 수 있는 자체 메모리 컨트롤러가 포함되어 있습니다. 전 세계 데이터 센터의 시스템 대부분은 이중 소켓 시스템입니다. 각 CPU는 자체 메모리 컨트롤러를 통해 로컬 메모리 용량에 액세스할 수 있지만 원격 CPU에 의해 연결되고 제어되는 메모리에도 액세스할 수 있습니다. 로컬 메모리와 원격 메모리의 읽기와 쓰기 사이에는 지연 시간과 대역폭에 차이가 있으므로 NUMA(Non-Uniform Memory Access)라는 용어가 사용됩니다.

AMD EPYC 아키텍처는 MCM(Multi-Chip-Module) 아키텍처로 모노리식 아키텍처 및 I/O 경로 동작과 크게 다릅니다. 하위 NUMA 클러스터링은 Intel CPU 패키지를 파티셔닝하는 기능입니다. AMD는 NPS(소켓당 NUMA)라는 유사한 기능을 제공합니다. 이 문서에서는 서버 공급업체의 NPS 설정 기본 설정을 보지 못했기 때문에 Intel Sub-NUMA 클러스터링 기술에만 초점을 맞추고 있습니다.

논리 파티션

Intel E5-2600 프로세서 제품군은 링 아키텍처를 사용하여 Intel이 CPU 코어-메모리 액세스를 더욱 최적화할 수 있도록 했습니다. Intel은 Haswell 릴리스(v3)에서 COD(Cluster-On-Die) 기능을 도입했습니다. COD는 CPU를 두 개의 NUMA 노드로 논리적으로 분할합니다.

COD 기능은 메모리 계층의 검색 도메인을 줄입니다. NUMA 시스템은 캐시 일관성이 있습니다. 코어는 메모리 요청을 생성할 때 로컬 L1 및 L2 캐시, LLC(공유 L3 캐시) 및 원격 CPU 캐시를 확인합니다. “자연적인” 링 구조 장벽을 따라 CPU를 분할하면 캐시 누락이 있는지 검색하기 위해 더 작은 메모리 도메인을 갖게 됩니다. 게다가 애플리케이션과 운영 체제가 NUMA에 최적화된 경우 로컬 메모리 트래픽이 적어야 합니다. 자세한 내용은 NUMA 심층 분석을 참조하거나 COD 캐싱 구조에 대한 이 연구 문서를 참조하십시오. Skylake 아키텍처(Intel Xeon 스케일러블 프로세서)는 링 아키텍처에서 벗어나 메시 아키텍처를 도입했습니다. 논리 파티션 기능은 그대로 유지되었으며 SNC(Sub-NUMA Clustering)라는 새로운 이름으로 도입되었습니다.

SNC를 사용하도록 설정하면 이전에 표시된 이중 CPU 소켓 ESXi 호스트 시스템이 이제 4개의 NUMA 노드 시스템이 됩니다.

SNC와 NUMA 성능 비교

SNC는 BIOS에 숨겨져 있는 Turbo 기능인가요? 일부 공급업체에서 사용하는 설명을 보면 즉시 사용하도록 설정하려고 합니다. Dell과 Lenovo는 SNC에 대해 다음과 같이 설명합니다. “…LLC의 평균 대기 시간을 향상시킵니다.” 저는 Hadar Greinsmark가 그의 연구 “Effective Task Scheduling of In-Memory Databases on a Sub-NUMA Processor Topology.”에서 발표한 성능 수치를 사용하고 있습니다. 기본 NUMA 구성(SNC 사용 안 함)에서 소켓 0(S0)과 소켓 1(S1)의 지연 시간 차이를 살펴보겠습니다.

SNC를 사용하도록 설정한 경우 소켓 0에는 0과 1이라는 두 개의 NUMA 노드가 포함됩니다. 소켓 1에는 NUMA 노드 2 및 3이 포함되어 있습니다. 이러한 논리 파티션은 정품 NUMA 노드입니다. 서로 다른 메모리 컨트롤러와 캐시 도메인이 동일한 다이에 있지만, 메모리 컨트롤러의 캐싱 메커니즘과 비인터리빙은 도메인 간에 불균일한 메모리 액세스 패턴을 생성합니다. 따라서 동일한 소켓 내에 위치한 다른 “원격” NUMA 노드에서 메모리를 가져올 때 지연 시간이 증가합니다.

로컬 메모리 컨트롤러에서 가장 가까운 LLC로 메모리 주소를 SNC 매핑하는 방법은 기본 NUMA 구성에 비해 SNC가 평균 6~7% 감소하는 로컬 NUMA 지연 시간으로 확실히 작동합니다. NUMA 노드 0을 예로 들어 보겠습니다. SNC를 사용하면 74.2ns의 메모리 지연 시간을 경험합니다. SNC를 사용하지 않도록 설정한 경우와 비교하여 액세스 지연 시간은 80.8ns입니다. 따라서 SNC는 NUMA 노드 0의 경우 메모리 지연 시간을 7.5%까지 줄입니다.

성능 수치는 노드 0 및 노드 2에서 처리된 원격 연결이 SNC 사용 안 함 상태보다 성능이 우수한 반면 NUMA 노드 1 및 노드 3은 SNC 사용 안 함 상태보다 성능이 낮은 것으로 표시됩니다. 동일한 소켓의 원격 노드에 보고되는 지연 시간 수는 매우 흥미롭습니다. 그것은 아마도 상호 연결 아키텍처의 매력적인 행동을 보여줍니다. 그러나 Intel은 UPI(Ultra Path Interconnect) 프레임워크에 대한 자세한 정보를 공유하지 않습니다.

아키텍처 다이어그램을 보면 NUMA 노드 0 위에 두 개의 UPI 연결이 있는 컨트롤러가 있음을 알 수 있습니다. NUMA 노드 1 위에는 단일 UPI 연결이 있는 컨트롤러가 있습니다. 단일 UPI는 메시에서 더 많은 I/O 트래픽 차단을 경험하는 반면, 두 개의 연결이 있는 UPI 컨트롤러는 흐름을 더 잘 관리할 수 있는 더 많은 방법을 가지고 있습니다.

하지만 이것은 제 입장에서는 순수한 추측일 뿐입니다. 절대 원격 I/O 수치를 보면 지연 시간이 급증합니다. 중요한 것은 로컬에서 메모리를 읽거나 쓸 수 없는 경우 워크로드가 원격 I/O 작업을 실행한다는 것입니다. 동일한 소켓에 있는 NUMA 노드에서 메모리를 찾을 수 있는 경우 지연 시간이 8.6% 증가합니다. 인터커넥트를 통해 다른 소켓의 NUMA 노드로 이동하면 지연 시간이 78.2%로 증가합니다. 가장 먼 NUMA 노드로 이동해야 할 경우 대기 시간이 거의 두 배(90%) 증가합니다. 기본 NUMA 시스템의 평균 원격 지연 시간은 73%에 달합니다. 그러나 SNC는 로컬에서 평균 최대 7% 향상되지만 원격 메모리 액세스를 최대 5%까지 저하시키기 때문에 더 광범위한 성능을 제공합니다. 비교해보죠. 기본 상황에서 로컬 액세스는 80ns이고 원격 액세스는 138.9ns입니다. SNC에서는 73.6ns 대 142.0이라는 최악의 시나리오를 처리해야 합니다. 이것이 바로 실적 격차가 92.9%로 확대되는 이유입니다. 그리고 어떤 워크로드가 로컬 및 원격이 되는지를 결정하는 요소는 무엇입니까? 그것이 이 기사의 핵심입니다. 그러나 이에 대해 자세히 살펴보기 전에 먼저 대역폭 성능을 살펴보겠습니다.

대역폭

Skylake CPU 모델에는 두 개 또는 세 개의 UPI 링크가 있습니다. 각 UPI 링크는 각 방향에 대해 별도의 차선이 있는 포인트 투 포인트 전이중 연결입니다. UPI 링크의 이론적 전송 속도는 초당 10.4기가바이트(GT/s)이며, 이는 초당 20.8기가바이트(GB/s)를 의미합니다. 보고서에 사용된 Intel Xeon Platinum 8180 프로세서에는 세 개의 UPI 링크가 포함되어 있으며, 이론적으로 총 62.4GB/s의 대역폭을 제공할 수 있습니다. 한 컨트롤러에는 두 개의 UPI 링크가 있고 다른 컨트롤러에는 하나의 UPI 링크가 있습니다. 연구 논문에 따르면 원격 노드와 통신할 때 평균 대역폭은 약 34.4GB/s입니다.

Speculation

UPI 통신 패턴에 대한 정보는 제한적이므로 시스템은 기본 NUMA 노드에서 두 개의 UPI 링크만 사용하는 것으로 가정합니다. 기본 NUMA를 사용하면 메모리 컨트롤러 간에 메모리 인터리브가 실행되므로 두 메모리 컨트롤러에서 메모리를 검색해야 하므로 시스템에서 두 UPI 컨트롤러를 모두 사용합니다. 세 개의 링크를 모두 사용하지 않는 이유는 세 개의 링크에서 I/O 작업을 동기화하고 다른 작업에서 상호 연결을 사용하도록 허용하는 오버헤드가 추가 업링크의 잠재적 이점을 능가한다고 생각합니다.

/speculation

하지만 사실에 충실해요. 여기서는 원격 메모리 액세스의 영향을 확인할 수 있습니다. 기본 NUMA 시스템에서 원격 I/O를 수행하면 대역폭 성능이 69% 감소합니다. 이러한 정확한 이유로 NUMA에 최적화된 워크로드 또는 적절한 크기의 가상 시스템이 필요합니다. 화면에서 진행 표시줄이 선형으로 이동하지 않는 이유는 무엇입니까? 원격 NUMA 노드에서 메모리를 가져오는 NUMA 최적화되지 않은 코드가 있을 수 있습니다.

SNC가 활성화된 경우 시스템은 CPU 패키지 내의 두 메모리 컨트롤러에서 전체 메모리 범위의 인터리빙을 중지하고 각 메모리 컨트롤러에 메모리 범위의 하위 집합을 할당합니다. 각 메모리 컨트롤러에는 3개의 채널이 있으며 NUMA 노드의 대역폭을 절반으로 분할합니다. 테스트 시스템은 이론적으로 SNC NUMA 노드당 최대 63.9GB/s를 제공하는 DDR4 2666MHz(21.3GB/s) 메모리 모듈을 사용합니다. 연구 결과를 검토할 때, 기본 NUMA 노드는 SNC를 사용하도록 설정하여 111GB/s(6채널)를 제공했으며, 이는 NUMA 노드당 약 55.5GB/s의 결과가 될 것입니다. 그러나 테스트 결과에 따르면 58GB/s입니다. SNC는 워크로드 격리로 인해 로컬 대역폭을 평균 4.5% 향상시켜 메시에서 다른 I/O 작업의 차단 순간을 줄입니다. 동일한 소켓의 NUMA 노드에서도 유사한 개선이 발생합니다.

따라서 SNC는 조정된 워크로드에 대해 마지막 성능을 제공하는 좋은 방법입니다. 코어 수와 메모리 용량에서 워크로드가 더 작은 NUMA 노드에 적합한 경우 지연 시간이 7%, 메모리 대역폭이 4% 향상될 것으로 예상할 수 있습니다. 하지만, 크지만, Sir Mix-a-Lot이 좋아하는 방식은 아닙니다. 그러나 스케일아웃 워크로드를 구현하는 경우에만 해당됩니다. 별도의 워크로드를 실행하는 각 작업자 노드에 두 명의 작업자를 배치할 수 있는 경우 두 작업자 모두 추가로 얻을 수 있는 대역폭의 이점을 누릴 수 있습니다. 단일 워크로드만 배포하면 해당 워크로드에서 얻을 수 있는 대역폭의 절반을 빼앗은 것입니다. 워크로드는 원격 메모리 용량에 액세스할 수 있으며 더 많은 대역폭을 얻을 수 있습니다. 그러나 NUMA 스케줄러 또는 애플리케이션의 재량에 따라 현명하게 이동하여 올바른 NUMA 노드를 선택할 수 있습니다. 이 시점에서 베어메탈의 전용 워크로드와 여러 워크로드를 고려해야 하는 NUMA 스케줄러를 처리하는 것 사이의 차이가 시작됩니다.

SNC는 NUMA 노드당 용량을 효과적으로 줄여 단일 NUMA 노드 가상 시스템 크기의 경계를 줄입니다. 질문이 있습니다. 워크로드 스케일아웃을 위한 대역폭 4% 향상과 지연 시간 7% 향상이 가상화 플랫폼에서 사용하기를 원하는 것처럼 들립니까? CPU 패키지 시스템당 18개 코어가 있는 이중 소켓에 10-vCPU VM을 배치하는 방법은 무엇입니까?

단일 NUMA 노드 VM 사이징

모든 애플리케이션이 NUMA를 인식하는 것은 아닙니다. 대부분의 플랫폼 운영자 및 관리 팀은 이 문제를 방지하기 위해 가상 시스템의 “적절한 크기 조정(right-size)”을 시도합니다. 적절한 크기 조정은 VM에 포함된 vCPU와 메모리 용량이 CPU 소켓에 포함된 CPU 코어와 메모리 용량보다 적지만 여전히 올바르게 작동할 수 있음을 의미합니다. SNC를 사용하면 NUMA 노드가 절반으로 분할되므로 VM이 단일 NUMA 노드 내에 있어야 할 경우 VM이 더 작아집니다.

vNUMA 토폴로지

VM에 포함된 vCPU가 NUMA 노드에 포함된 CPU 코어보다 많은 경우 ESXi의 NUMA 스케줄러는 이 VM에 대한 vNUMA 토폴로지를 생성하고 NUMA 최적화를 위해 게스트 OS에 공개합니다. NUMA 스케줄러는 이 VM에 대해 여러 NUMA 클라이언트를 생성하고 이에 따라 배치합니다. 이는 사용자 환경에서 SNC를 사용하거나 사용하지 않아야 하는 이유를 파악하는 데 중요한 역할을 합니다.

초기배치

VM의 전원이 켜져 있거나 가상 시스템이 DRS를 통해 호스트로 마이그레이션된 경우 NUMA 스케줄러는 초기 배치 요청을 받습니다. 초기 배치 작업 중에 NUMA 스케줄러는 NUMA 노드 간의 거리를 인식합니다. 또한 VM의 NUMA 클라이언트 배치를 최적화하려고 시도합니다. 즉, NUMA 클라이언트를 서로 최대한 가깝게 배치하려고 합니다. 따라서 VM이 두 개의 NUMA 클라이언트로 구성된 경우 대부분의 경우 두 NUMA 클라이언트가 SNC를 사용하도록 설정된 동일한 소켓을 공유하는 NUMA 노드에 배치됩니다.

일반적으로 이 문제는 이 VM이 호스트에서 실행 중인 유일한 VM인 모든 통합 테스트 중에 발생하므로 NUMA 스케줄러가 경합이나 복잡한 퍼즐을 처리하거나 다른 44개의 바쁜 NUMA 클라이언트에 이러한 새 클라이언트를 맞출 필요가 없습니다.

NUMA 로드 밸런싱

하이퍼바이저는 매우 동적인 환경입니다. CPU 스케줄러는 다양한 워크로드 패턴을 처리해야 하며, 로드 상관 관계 및 로드 동기화와 같은 워크로드 패턴이 있습니다. 로드 상관 관계를 통해 스케줄러는 서로 다른 시스템에서 실행되는 워크로드 간의 관계로 인해 발생하는 로드 스파이크를 처리해야 합니다. NUMA 스케줄러는 2초마다 CPU 로드를 검토하여 이러한 패턴을 파악합니다. 예를 들어 프런트 엔드 VM이 있는 애플리케이션은 데이터베이스와 통신합니다. 로드 동기화 워크로드가 함께 증가함에 따라 매일 아침 여러 대의 데스크톱이 가동되는 VDI 환경은 지속적인 로드 스파이크를 유발합니다. 따라서 NUMA 로드 밸런싱 장치는 시스템 전체에서 일부 NUMA 클라이언트를 이동하는 것이 더 낫다고 결정할 수 있습니다. NUMA 로드 밸런싱 알고리즘의 세부 정보를 입력하는 것은 이 문서에서 설명하기에는 너무 깊습니다. NUMA 딥 다이브에서 가장 많이 다루었습니다. 하지만 NUMA 클라이언트를 이동해야 하는 경우에는 NUMA 클라이언트를 이동하지만 거리는 고려하지 않는다는 점을 이해해야 합니다. 이 시도는 시스템에 가장 현명한 방법이지만 VM에 항상 최선은 아닐 수 있습니다.

대부분의 경우 SNC를 사용하도록 설정하지 않으면 해당 VM이 단일 NUMA 노드에 적합하게 되며 단일 NUMA 노드에 적합하므로 원격 액세스가 발생하지 않습니다. SNC의 경우 큰 VM이 SNC-NUMA 노드 크기보다 클 수 있으므로 분할됩니다. 이 VM이 GPU와 같은 PCIe 디바이스에 연결된 경우에는 더욱 심각합니다. 인터커넥트 간에 일괄 데이터 전송이 발생하여 호스트에서 디바이스로의 메모리 전송 작업 중에 일관되지 않은 데이터 로드 동작이 발생할 수 있습니다. 여기에서 NUMA PCI-e 인접성에 대해 자세히 알아보십시오.

SNC의 기본적 활성화

내가 왜 이런 말을 하는 거죠? HP가  “Virtualization – Max Performance” and “General Throughput Compute.” 워크로드 프로파일을 통해 SNC를 지원한다는 것을 알게 되었습니다.

ESXi에는 SNC 사용 여부를 보여주는 설정이 UI에 없지만 아름다운 예술 형식의 공제를 적용할 수 있습니다. ESXi 호스트에서 SSH를 통해 다음(지원되지 않음) 명령을 실행합니다.

echo "CPU Packages";vsish -e dir /hardware/cpu/packageList;echo "NUMA nodes";vsish -e dir /hardware/cpuTopology/numa/nodes

CPU 패키지 수(CPU 코어, 메모리 컨트롤러 및 PCI 컨트롤러가 포함된 디바이스의 화려한 이름)와 시스템의 NUMA 노드 수 목록이 표시됩니다. SNC를 사용하지 않도록 설정한 경우 NUMA 노드의 수는 CPU 패키지의 수와 같아야 합니다. 이 시나리오에서는 SNC가 활성화됩니다. 대부분의 시스템에서는 설정을 개별적으로 사용하거나 사용하지 않도록 설정할 수 있지만 HP 시스템과 같은 프로파일의 일부인 경우에는 이 설정을 사용자 지정해야 합니다. Dan은 이 방법을 트위터에 올렸습니다.

Disclaimer

이 트윗과 이 기사는 SNC를 해제하기 위한 공식적인 VMware 권장 사항이 아닙니다. 이 자료에서는 SNC가 하드웨어 계층에서 SNC의 전반적인 동작에 미치는 영향과 ESXi NUMA 스케줄러의 작동 방식을 이해하는 데 도움이 됩니다. 운영 환경을 변경하기 전에 항상 정상적인 작동 상태에서 환경 및 워크로드의 설정을 테스트하십시오.

SNC에 대한 개인적인 생각

SNC는 모든 유형의 워크로드를 실행하는 가상화 플랫폼에 제공할 수 있는 기능이 거의 없다고 생각합니다. 작은 VM에서 몬스터 VM까지 다양한 워크로드. VOIP 워크로드 또는 High-Frequency Trading 워크로드와 같이 실행해야 하는 대기 시간이 짧은 특정 워크로드를 실행하는 전용 vSphere 플랫폼이 있는 경우 SNC가 적합합니다.

Oracle, SQL 또는 많은 vCPU가 필요한 고성능 데이터베이스를 실행하는 평균 vSphere 환경과 일부 프런트 엔드 애플리케이션 및 기타 수많은 프레임워크의 경우 SNC가 성능에 영향을 미칩니다. 대부분의 관리자는 VM이 단일 NUMA 노드에 포함되기를 원합니다. SNC는 VM 설치 공간을 줄입니다. SNC는 메모리 액세스에 더 많은 부담을 줍니다. 로컬 I/O와 원격 I/O 사이의 간격이 증가하기 때문에 사용자는 워크로드 성능의 일관성이 훨씬 더 떨어지는 느낌을 감지할 수 있습니다. 이제 NUMA 스케줄러는 두 개의 큰 도메인 대신 네 개의 작은 NUMA 도메인의 균형을 조정해야 하므로 최적이 아닐 수 있는 더 많은 결정이 내려질 것입니다. 단기 마이그레이션을 예로 들 수 있습니다. NUMA 스케줄러는 VM을 이동하여 NUMA 노드 간의 불균형을 해결합니다. 이 시나리오에서는 스케줄러가 vCPU를 즉시 마이그레이션하지만 메모리가 더 느리게 이동합니다. 메모리 재배치가 즉시 이루어지지 않으므로 페이지가 새 NUMA 노드로 마이그레이션되는 동안 원격 메모리 액세스가 일시적으로 증가합니다. 4개의 작은 NUMA 노드를 처리하면 전체 사용자 환경에 영향을 미칠 수 있습니다. 특히 로컬 메모리와 원격 메모리 간의 차이가 69%에서 90%로 확대되는 경우에는 더욱 그렇습니다.

이제 단일 NUMA 노드 내에 포함되는 균일한 메모리 액세스 VM이 여러 NUMA 노드에 걸쳐 있습니다. 따라서 게스트 OS와 애플리케이션이 NUMA에 최적화되기를 바랍니다. 최근 Linux를 NUMA 스케줄러에 최적화하면 호스트를 기본 NUMA로 유지하면 성능 불일치가 많이 발생하지 않습니다.

본질적으로 SNC는 책의 모든 트릭을 활용한 고도로 최적화되고 잘 큐레이션된 환경을 위한 것이라고 생각합니다. 모든 가상화 플랫폼의 출발점이 되어서는 안 됩니다.

NUMA에 대해 자세히 알고 싶으십니까? VMware에서 NUMA 최적화를 추진하는 원동력에 대해  Unexplored Territory Podcast 팟캐스트 19화에서 이야기했습니다. Unexplored Territory website, Apple Podcasts, Spotify를 통해 리차드 루와의 대화를 들을 수 있습니다.

출처 : https://frankdenneman.nl/2022/09/21/sub-numa-clustering/