단독 테넌시 개요

이 문서에서는 단독 테넌트 노드를 설명합니다. 단독 테넌트 노드에서 VM을 프로비저닝하는 방법은 단독 테넌트 노드에서 VM 프로비저닝을 참조하세요.

단독 테넌시를 사용하면 프로젝트의 VM만 호스팅하는 물리적 Compute Engine 서버인 단독 테넌트 노드에 독점적으로 액세스할 수 있습니다. 다음 다이어그램과 같이 단독 테넌트 노드를 사용하면 VM을 다른 프로젝트의 VM으로부터 물리적으로 분리하거나 동일한 호스트 하드웨어에 그룹화할 수 있습니다. 또한 단독 테넌트 노드 그룹을 만들고 다른 프로젝트 또는 전체 조직과 공유할지 여부를 지정할 수 있습니다.

멀티 테넌트 호스트와 단독 테넌트 노드 비교
그림 1: 멀티 테넌트 호스트와 단독 테넌트 노드 비교

단독 테넌트 노드에서 실행되는 VM은 투명한 예약 및 블록 스토리지를 비롯해 다른 VM과 동일한 Compute Engine 기능을 사용할 수 있지만 추가 하드웨어 격리 레이어가 있습니다. 물리적 서버의 VM을 완벽하게 제어할 수 있도록 각 단독 테넌트 노드는 노드를 지원하는 물리적 서버에 대한 일대일 매핑을 유지합니다.

단독 테넌트 노드 내에서 다양한 크기의 머신 유형에 여러 VM을 프로비저닝할 수 있으므로 전용 호스트 하드웨어의 기본 리소스를 효율적으로 사용할 수 있습니다. 또한 호스트 하드웨어를 다른 프로젝트와 공유하지 않으면 다른 워크로드나 VM과 물리적으로 격리해야 하는 워크로드의 보안 또는 규정 준수 요구사항을 충족할 수 있습니다. 워크로드에 한시적으로 단독 테넌시가 필요한 경우 필요에 따라 VM 테넌시를 수정할 수 있습니다.

단독 테넌트 노드는 코어별 또는 프로세서별 라이선스가 필요한 Bring Your Own License(사용자 라이선스 사용) 시나리오의 전용 하드웨어 요구사항을 충족하는 데 도움이 될 수 있습니다. 단독 테넌트 노드를 사용하면 기본 하드웨어에 대한 가시성이 확보되어 코어 및 프로세서 사용량을 추적할 수 있습니다. 이 사용량을 추적할 수 있도록 Compute Engine은 VM이 예약된 물리적 서버의 ID를 보고합니다. 그런 다음 Cloud Logging을 사용하여 VM의 이전 서버 사용량을 볼 수 있습니다.

호스트 하드웨어 사용을 최적화하려면 다음을 실행합니다.

구성 가능한 호스트 유지보수 정책을 통해 호스트가 유지보수되는 동안 단독 테넌트 VM의 동작을 제어할 수 있습니다. 유지보수가 발생하는 시점, VM이 특정 물리적 서버와의 어피니티를 유지할지 또는 VM이 노드 그룹 내 다른 단독 테넌트 노드로 이동할지 여부를 지정할 수 있습니다.

워크로드 고려사항

다음 유형의 워크로드는 단독 테넌트 노드를 사용하는 것이 좋습니다.

  • 성능 요구사항이 있는 게임 워크로드

  • 보안 및 규정 준수 요구사항이 있는 금융 또는 의료 워크로드

  • 라이선스 요구사항이 있는 Windows 워크로드

  • 머신러닝, 데이터 처리, 이미지 렌더링 워크로드. 이러한 워크로드의 경우 GPU를 예약하는 것이 좋습니다.

  • 증가한 초당 입출력 작업 수(IOPS) 및 감소된 지연 시간을 필요로 하는 워크로드 또는 캐시, 처리 공간, 가치가 낮은 데이터의 형식으로 임시 스토리지를 사용하는 워크로드. 이러한 워크로드의 경우 로컬 SSD를 예약하는 것이 좋습니다.

노드 템플릿

노드 템플릿은 노드 그룹에 있는 각 노드의 속성을 정의하는 리전별 리소스입니다. 노드 템플릿에서 노드 그룹을 만들면 노드 템플릿 속성은 노드 그룹에 있는 각 노드에 변경 없이 복사됩니다.

노드 템플릿을 만들 때 노드 유형을 지정해야 합니다. 노드 템플릿을 만들 때 원하는 경우 노드 어피니티 라벨을 지정할 수 있습니다. 노드 템플릿에서만 노드 어피니티 라벨을 지정할 수 있습니다. 노드 그룹에서는 노드 어피니티 라벨을 지정할 수 없습니다.

노드 유형

노드 템플릿을 구성할 때 노드 템플릿을 기반으로 만든 노드 그룹 내 모든 노드에 적용할 노드 유형을 지정합니다. 노드 템플릿에서 참조되는 단독 테넌트 노드 유형은 이 템플릿을 사용하는 노드 그룹에서 만든 노드의 총 vCPU 코어와 메모리 양을 지정합니다. 예를 들어 n2-node-80-640 노드 유형에는 vCPU 80개와 메모리 640GB가 있습니다.

단독 테넌트 노드에 추가하는 VM은 노드 템플릿에서 지정하는 노드 유형과 동일한 머신 유형이 있어야 합니다. 예를 들어 n2 단독 테넌트 노드 유형은 n2 머신 유형으로 생성된 VM과만 호환됩니다. 총 vCPU 또는 메모리 양이 노드의 용량을 초과할 때까지 단독 테넌트 노드에 VM을 추가할 수 있습니다.

노드 템플릿을 사용하여 노드 그룹을 만들면 노드 그룹의 각 노드가 노드 템플릿의 노드 유형 사양을 상속합니다. 노드 유형은 노드 그룹 내 각 개별 노드에 적용되며 그룹의 모든 노드에 균일하게 적용되지 않습니다. 따라서 노드 유형이 n2-node-80-640인 노드 두 개로 노드 그룹을 만들면 각 노드에는 vCPU 80개와 메모리 640GB가 할당됩니다.

워크로드 요구사항에 따라 사전 정의된 머신 유형, 커스텀 머신 유형, 확장 메모리가 있는 머신 유형을 비롯한 다양한 크기의 머신 유형에서 실행되는 작은 VM 여러 개로 노드를 채울 수 있습니다. 노드가 가득차면 이 노드에 추가 VM을 예약할 수 없습니다.

다음 표에서는 사용 가능한 노드 유형을 보여줍니다. 프로젝트에 사용할 수 있는 노드 유형 목록을 보려면 gcloud compute sole-tenancy node-types list 명령어를 실행하거나 nodeTypes.list REST 요청을 만듭니다.

노드 유형 프로세서 vCPU GB vCPU:GB 소켓 Cores:Socket 총 코어 수
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192
c4-node-192-384 Emerald Rapids 192 384 1:2 2 52 104
c4-node-192-720 Emerald Rapids 192 720 1:3.75 2 52 104
c4-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 52 104
c4a-node-72-144 Google Axion 72 144 1:2 2 1 72
c4a-node-72-288 Google Axion 72 288 1:4 2 1 72
c4a-node-72-576 Google Axion 72 576 1:8 2 1 72
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56
g2-node-96-432 Cascade Lake 96 432 1:4.5 2 28 56
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96
m1-node-96-1433 Skylake 96 1433 1:14.93 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-8832 Cascade Lake 416 8832 1:21.23 8 28 224
m2-node-416-11776 Cascade Lake 416 11776 1:28.31 8 28 224
m3-node-128-1952 Ice Lake 128 1952 1:15.25 2 36 72
m3-node-128-3904 Ice Lake 128 3904 1:30.5 2 36 72
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48
n2-node-128-864 Ice Lake 128 864 1:6.75 2 36 72
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128

이러한 노드 유형의 가격에 대한 상세 설명은 단독 테넌트 노드 가격 책정을 참조하세요.

모든 노드에서 다양한 형태의 VM을 예약할 수 있습니다. n 유형의 노드는 커스텀 머신 유형 VM을 예약할 수 있는 범용 노드입니다. 선택할 노드 유형에 대한 권장사항은 머신 유형 권장사항을 참조하세요. 성능에 대한 상세 설명은 CPU 플랫폼을 참조하세요.

노드 그룹 및 VM 프로비저닝

단독 테넌트 노드 템플릿은 노드 그룹의 속성을 정의하며, Google Cloud 영역에 노드 그룹을 만들기 전에 노드 템플릿을 만들어야 합니다. 그룹을 만들 때 노드 그룹의 VM에 대한 호스트 유지보수 정책, 노드 그룹에 대한 노드 수, 다른 프로젝트 또는 전체 조직과 공유할지 여부를 지정합니다.

노드 그룹에는 0개 이상의 노드가 있을 수 있습니다. 예를 들어 그룹의 노드에서 VM을 실행할 필요가 없다면 노드 그룹의 노드 수를 0으로 줄이거나 노드 그룹 자동 확장 처리를 사용 설정하여 노드 그룹의 크기를 자동으로 관리할 수 있습니다.

단독 테넌트 노드에 VM을 프로비저닝하려면 먼저 단독 테넌트 노드 그룹을 만들어야 합니다. 노드 그룹은 특정 영역의 동종 단독 테넌트 노드의 집합입니다. 머신 유형에 vCPU가 2개 이상 있다면 노드 그룹은 다양한 크기의 머신 유형에서 실행되는 여러 VM을 포함할 수 있습니다.

노드 그룹을 만들 때 워크로드 요구사항에 맞게 그룹 크기가 자동으로 조정되도록 자동 확장을 사용 설정하세요. 워크로드 요구사항이 정적인 경우 수동으로 노드 그룹의 크기를 지정할 수 있습니다.

노드 그룹을 만든 후 그룹 또는 그룹 내 특정 노드에 VM을 프로비저닝할 수 있습니다. 추가 제어를 위해서는 노드 어피니티 라벨을 사용하여 어피니티 라벨이 일치하는 노드에서 VM을 예약합니다.

노드 그룹에 VM을 프로비저닝하고 선택적으로 어피니티 라벨을 할당하여 특정 노드 그룹 또는 노드에 VM을 프로비저닝한 후 리소스에 라벨을 지정하면 VM 관리에 도움이 됩니다. 라벨은 결제 등의 이유로 집계하여 볼 수 있도록 VM을 분류하는 데 도움이 되는 키-값 쌍입니다. 예를 들어 라벨을 사용하여 VM의 역할, 테넌시, 라이선스 유형 또는 위치를 표시할 수 있습니다.

호스트 유지보수 정책

라이선스 시나리오와 워크로드에 따라 VM에서 사용되는 물리적 코어 수를 제한해야 할 수 있습니다. 예를 들어 라이선스 또는 규정 준수 요구사항에 따라 호스트 유지보수 정책을 선택하거나 물리적 서버의 사용량을 제한할 수 있는 정책을 선택할 수 있습니다. 이러한 모든 정책을 통해 VM이 전용 하드웨어에서 유지됩니다.

단독 테넌트 노드에서 VM을 예약하는 경우 다음 세 가지 호스트 유지보수 정책 중에서 선택할 수 있습니다. 이러한 정책을 통해 약 4~6주마다 발생하는 호스트 이벤트 중에 Compute Engine이 VM을 라이브 마이그레이션할지 여부와 그 방법을 결정할 수 있습니다. 유지보수 중에 Compute Engine은 호스트의 모든 VM을 한 그룹으로 다른 단독 테넌트 노드에 라이브 마이그레이션합니다. 하지만 경우에 따라 VM을 소규모 그룹으로 나누고 이러한 그룹 각각을 라이브 마이그레이션하여 단독 테넌트 노드를 분리할 수도 있습니다.

기본 호스트 유지보수 정책

기본 호스트 유지보수 정책입니다. 이 정책으로 구성된 노드 그룹의 VM은 단독 테넌트가 아닌 VM의 기존 유지보수 동작을 따릅니다. 즉, VM 호스트의 호스트 유지보수 설정에 따라 VM이 호스트 유지보수 이벤트 전에 노드 그룹의 새 단독 테넌트 노드로 라이브 마이그레이션되며 이 새 단독 테넌트 노드는 고객의 VM만 실행합니다.

이 정책은 호스트 이벤트 중에 라이브 마이그레이션이 필요한 사용자별 또는 기기별 라이선스에 가장 적합합니다. 이 설정은 VM 마이그레이션을 물리적 서버의 고정된 풀 내로 제한하지 않으며 물리적 서버 요구사항이 없고 기존 라이선스가 필요하지 않은 일반 워크로드에 적합합니다.

VM은 기존 서버의 이 정책과의 어피니티를 고려하지 않고 어떤 서버로도 라이브 마이그레이션되므로 호스트 이벤트 중에 물리적 코어 사용량을 최소화해야 하는 시나리오에는 이 정책이 적합하지 않습니다.

다음 그림은 기본 호스트 유지보수 정책의 애니메이션을 보여줍니다.

기본 호스트 유지보수 정책의 애니메이션입니다.
그림 2: 기본 호스트 유지보수 정책의 애니메이션.

호스트 유지보수 정책 그대로 다시 시작

이 호스트 유지보수 정책을 사용하면 Compute Engine이 호스트 이벤트 중에 VM을 중지하고 호스트 이벤트 후에 동일한 물리적 서버에서 VM을 다시 시작합니다. 이 정책을 사용하는 경우 VM의 호스트 유지보수 시 설정을 TERMINATE로 설정해야 합니다.

이 정책은 내결함성이 있고 호스트 이벤트 중에 약 1시간 동안 다운타임이 발생할 수 있는 워크로드, 동일한 물리적 서버에 남아 있어야 하는 워크로드, 라이브 마이그레이션이 필요 없는 워크로드 또는 물리적 코어나 프로세서 수를 기준으로 라이선스를 부여받은 경우에 가장 적합합니다.

이 정책을 사용하는 경우 node-name, node-group-name, 노드 어피니티 라벨을 사용하여 노드 그룹에 인스턴스를 할당할 수 있습니다.

다음 그림은 그대로 다시 시작 유지보수 정책의 애니메이션을 보여줍니다.

그대로 다시 시작 호스트 유지보수 정책의 애니메이션
그림 3: 그대로 다시 시작 호스트 유지보수 정책의 애니메이션

노드 그룹 내 마이그레이션 호스트 유지보수 정책

이 호스트 유지보수 정책을 사용하면 Compute Engine이 호스트 이벤트 중에 고정 크기의 물리적 서버 그룹 내에서 VM을 실시간 마이그레이션하므로 VM에서 사용되는 고유한 물리적 서버 수를 제한할 수 있습니다.

이 정책은 물리적 코어나 프로세서 수를 기반으로 한 라이선스가 있는 고가용성 워크로드에 가장 적합합니다. 기본 정책에서 VM이 모든 서버로 마이그레이션되도록 허용하는 것과 달리 이 호스트 유지보수 정책에서는 그룹의 각 단독 테넌트 노드가 고정된 물리적 서버 집합에 고정되기 때문입니다.

라이브 마이그레이션 용량을 보장하도록 Compute Engine은 예약되는 노드 20개마다 1개의 보류 노드를 예약합니다. 다음 표에서는 노드 그룹에 예약된 노드 수에 따라 Compute Engine이 예약하는 보류 노드 수를 보여줍니다.

그룹의 총 노드 수 라이브 마이그레이션을 위해 예약된 보류 노드
1 해당 없음 노드를 2개 이상 예약해야 합니다.
2~20 1
21~40 2
41~60 3
61~80 4
81~100 5

이 정책을 사용하는 경우 각 인스턴스는 node-group-name 어피니티 라벨을 사용하여 단일 노드 그룹을 타겟팅해야 하며 특정 노드 node-name에 할당될 수 없습니다. 이렇게 하면 호스트 이벤트가 있을 때 Compute Engine이 VM을 보류 노드로 라이브 마이그레이션할 수 있습니다. VM은 node-name이 아닌 node-group-name에 할당되어 있는 모든 커스텀 노드 어피니티 라벨을 사용할 수 있습니다.

다음 그림은 노드 그룹 내 마이그레이션 호스트 유지보수 정책의 애니메이션을 보여줍니다.

노드 그룹 내 마이그레이션 호스트 유지보수 정책의 애니메이션
그림 4: 노드 그룹 내 마이그레이션 호스트 유지보수 정책의 애니메이션

유지보수 기간

라이브 마이그레이션의 성능 영향에 민감할 수 있는 워크로드(예: 미세 조정된 데이터베이스)를 관리하는 경우 노드 그룹을 만들 때 유지보수 기간을 지정하여 단독 테넌트 노드 그룹에서 유지보수가 시작되는 시점을 결정할 수 있습니다. 노드 그룹을 만든 후에는 유지보수 기간을 수정할 수 없습니다.

유지보수 기간은 Google이 단독 테넌트 VM에서 유지보수를 수행하는 시점을 지정하는 데 사용할 수 있는 4시간 단위입니다. 유지보수 이벤트는 약 4~6주마다 한 번 발생합니다.

유지보수 기간은 단독 테넌트 노드 그룹의 모든 VM에 적용되며 유지보수가 시작되는 시점만 지정합니다. 유지보수 기간 중에 유지보수가 완료되지 않을 수 있으며 유지보수 수행 주기에 대한 보장은 없습니다. 유지보수 기간은 노드 그룹 내 마이그레이션 호스트 유지보수 정책이 있는 노드 그룹에서 지원되지 않습니다.

호스트 유지보수 이벤트 시뮬레이션

호스트 유지보수 이벤트를 시뮬레이션하여 단독 테넌트 노드에서 실행 중인 워크로드가 호스트 유지보수 이벤트 중에 어떻게 작동하는지 테스트할 수 있습니다. 이렇게 하면 단독 테넌트 VM의 호스트 유지보수 정책이 VM에서 실행되는 애플리케이션에 미치는 영향을 확인할 수 있습니다.

호스트 오류

호스트(단독 테넌트 또는 멀티 테넌트)에서 드물게 심각한 하드웨어 오류가 발생하는 경우 Compute Engine은 다음을 수행합니다.

  1. 물리적 서버와 그 고유 식별자를 사용 중지합니다.

  2. 프로젝트의 물리적 서버 액세스를 취소합니다.

  3. 결함이 발생한 하드웨어를 새 고유 식별자가 있는 새 물리적 서버로 바꿉니다.

  4. VM을 결함이 발생한 하드웨어에서 교체용 노드로 이동합니다.

  5. VM을 자동으로 다시 시작하도록 구성한 경우 해당 VM을 다시 시작합니다.

노드 어피니티 및 안티어피니티

단독 테넌트 노드는 공유 단독 테넌트 노드 그룹을 사용하지 않는 한 VM이 다른 프로젝트의 VM과 호스트를 공유하지 않도록 합니다. 공유 단독 테넌트 노드 그룹을 사용하면 조직 내의 다른 프로젝트에서 동일한 호스트에 VM을 프로비저닝할 수 있습니다. 하지만 동일한 단독 테넌트 노드에서 여러 워크로드를 그룹화하거나 서로 다른 노드에 워크로드를 서로 격리해야 하는 경우가 있습니다. 예를 들어 일부 규정 준수 요구사항을 충족하려면 어피니티 라벨을 사용하여 민감한 워크로드와 민감하지 않은 워크로드를 분리해야 할 수 있습니다.

VM을 만들 때 하나 이상의 노드 어피니티 라벨을 참조하는 노드 어피니티 또는 안티어피니티를 지정하여 단독 테넌시를 요청합니다. 노드 템플릿을 만들 때 커스텀 노드 어피니티 라벨을 지정하면 Compute Engine은 각 노드에 몇 가지 기본 어피니티 라벨을 자동으로 포함시킵니다. VM을 만들 때 어피니티를 지정하면 특정 노드 또는 노드 그룹의 노드에 여러 VM을 함께 예약할 수 있습니다. VM을 만들 때 안티어피니티를 지정하면 특정 VM이 동일 노드 또는 노드 그룹의 노드에 함께 예약되지 않도록 할 수 있습니다.

노드 어피니티 라벨은 노드에 할당된 키-값 쌍이며 노드 템플릿에서 상속됩니다. 어피니티 라벨을 사용하면 다음을 수행할 수 있습니다.

  • 개별 VM 인스턴스가 노드에 할당되는 방식을 제어합니다.
  • 템플릿에서 만든 VM 인스턴스(예: 관리형 인스턴스 그룹에서 만든 VM 인스턴스)가 노드에 할당되는 방식을 제어합니다.
  • 특정 VM 또는 노드 그룹에서 민감한 VM 인스턴스를 다른 VM과 별도로 그룹화합니다.

기본 어피니티 라벨

Compute Engine이 각 노드에 할당하는 기본 어피니티 라벨은 다음과 같습니다.

  • 노드 그룹 이름 라벨:
    • 키: compute.googleapis.com/node-group-name
    • 값: 노드 그룹의 이름
  • 노드 이름 라벨:
    • 키: compute.googleapis.com/node-name
    • 값: 개별 노드의 이름.
  • 노드 그룹이 공유된 프로젝트의 라벨:
    • 키: compute.googleapis.com/projects
    • 값: 노드 그룹을 포함하는 프로젝트의 프로젝트 ID

커스텀 어피니티 라벨

노드 템플릿을 만들 때 커스텀 노드 어피니티 라벨을 만들 수 있습니다. 이러한 어피니티 라벨은 노드 템플릿에서 만든 노드 그룹의 모든 노드에 할당됩니다. 노드 그룹을 만든 후에는 노드 그룹의 노드에 커스텀 어피니티 라벨을 추가할 수 없습니다.

어피니티 라벨을 사용하는 방법은 노드 어피니티 구성을 참조하세요.

가격 책정

  • Compute Engine은 단독 테넌트 노드의 비용을 최소화하기 위해 약정 사용 할인 및 지속 사용 할인을 제공합니다. 또한 단독 테넌트 노드의 vCPU 및 메모리에 대한 요금이 이미 청구되었으므로 단독 테넌트 노드의 VM에 대한 추가 요금은 지불하지 않습니다.

  • 단독 테넌트 노드를 GPU 또는 로컬 SSD로 프로비저닝하면 프로비저닝한 각 노드의 모든 GPU 또는 로컬 SSD에 대한 요금이 청구됩니다. 단독 테넌시 프리미엄은 GPU 또는 로컬 SSD에 적용되지 않습니다.

사용 가능 여부

  • 단독 테넌트 노드는 일부 영역에서 사용할 수 있습니다. 고가용성을 보장하려면 여러 영역의 단독 테넌트 노드에서 VM을 예약하세요.

  • 단독 테넌트 노드에서 GPU 또는 로컬 SSD를 사용하기 전에 리소스를 예약할 영역에 GPU 또는 로컬 SSD 할당량이 충분한지 확인합니다.

  • Compute Engine은 GPU를 지원하는 영역에 있는 n1 및 g2 단독 테넌트 노드 유형의 GPU를 지원합니다. 다음 표에서는 n1 및 g2 노드에 연결할 수 있는 GPU 유형과 노드 템플릿을 만들 때 연결해야 하는 GPU 수를 보여줍니다.

    GPU 유형 GPU 수량 단독 테넌트 노드 유형
    NVIDIA L4 8 g2
    NVIDIA P100 4 n1
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • Compute Engine은 로컬 SSD를 지원하는 영역에 있는 n1, n2, n2d, g2 단독 테넌트 노드 유형의 로컬 SSD를 지원합니다.

제한사항

  • N1, N2, N2D, N4 단독 테넌트 노드만 CPU 오버커밋을 지원합니다.

  • C3 단독 테넌트 노드는 동일한 단독 테넌트 노드에서 서로 다른 C3 VM 구성을 지원하지 않습니다. 예를 들어 c3-standard VM을 c3-highmem VM과 동일한 단독 테넌트 노드에 배치할 수 없습니다.

  • 라이브 노드 그룹에서 유지보수 정책을 업데이트할 수 없습니다.

M3 단독 테넌트 노드에서 지원되는 VM 구성

단독 테넌시는 M3 단독 테넌트 노드에 대해 다음 VM 구성을 지원합니다.

  • m3-node-128-3904 노드에서 단독 테넌시는 다음 VM 구성을 지원합니다.

    • 1 x m3-ultramem-128
    • 2 x m3-ultramem-64
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    m3-ultramem-32 VM 인스턴스를 실행하려면 다음 구성에서 실행하면 됩니다.

    • 1 x m3-ultramem-64 (또는 1 x m3-megamem-64) + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

  • m3-node-128-1952 노드에서 단독 테넌시는 다음 VM 구성을 지원합니다.

    • 2 x m3-ultramem-32
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    m3-ultramem-32 VM 인스턴스를 실행하려면 다음 구성에서 실행하면 됩니다.

    • 1 x m3-megamem-64 + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

다음 단계