단독 테넌트 노드

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

단독 테넌시를 사용하면 프로젝트의 VM만 호스팅하는 물리적 Compute Engine 서버인 단독 테넌트 노드에 독점적으로 액세스할 수 있습니다. 단독 테넌트 노드를 사용하여 VM을 다른 프로젝트의 VM과 물리적으로 분리하여 유지하거나 동일한 호스트 하드웨어에서 여러 VM을 그룹화합니다. 단독 테넌트 노드에서 실행되는 VM은 투명한 예약 및 블록 스토리지를 비롯해 다른 VM과 동일한 Compute Engine 기능을 사용할 수 있지만 추가 하드웨어 격리 레이어가 있습니다. 물리적 서버의 VM을 완벽하게 제어할 수 있도록 각 단독 테넌트 노드는 노드를 지원하는 물리적 서버에 대한 일대일 매핑을 유지합니다.

단독 테넌시는 특정 유형의 워크로드에 적합합니다. 예를 들어 성능 요구사항이 있는 게임 워크로드는 자체 하드웨어에서 격리되기 때문에 이점이 있을 수 있고, 금융 또는 의료 워크로드는 보안 및 규정 준수에 대한 요구사항이 있을 수 있으며, Windows 워크로드에는 라이선스와 관련된 요구사항이 있을 수 있습니다.

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

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

단독 테넌트 노드를 사용하면 구성 가능한 유지보수 정책을 통해 호스트 유지보수 이벤트 중에 VM의 동작을 제어할 수 있습니다. 유지보수 정책을 통해 단독 테넌트 노드에 프로비저닝된 VM이 특정 물리적 서버와의 어피니티를 유지할지 VM을 고정된 물리적 서버 그룹 내로 이동할지 지정할 수 있습니다.

노드 템플릿 및 노드 유형

노드 템플릿은 노드 그룹 내 각 노드의 속성을 정의하는 리전 리소스이며, 노드 템플릿에 정의하는 모든 속성은 템플릿에서 생성된 노드 그룹의 각 노드에 변경 없이 복사됩니다. 노드 템플릿을 만들 때 노드 유형을 지정하고 원하는 경우 노드 어피니티 라벨을 지정합니다. 노드 어피니티 라벨은 노드 템플릿에서만 지정할 수 있으며, 노드 그룹에서는 노드 어피니티 라벨을 지정할 수 없습니다.

각 노드 템플릿에 지정해야 하는 단독 테넌트 노드 유형은 해당 특정 노드의 총 vCPU 코어 및 메모리 양을 지정합니다. 예를 들어 n1-node-96-624 노드 유형에는 96개의 vCPU와 624GB의 메모리가 있습니다. 이 유형의 노드는 최대 96개의 vCPU와 624GB의 메모리가 있는 머신 유형에서 실행되는 VM을 수용할 수 있습니다. 노드 유형은 노드 그룹 전체가 아니라 노드 그룹 내의 각 개별 노드에 적용됩니다. 따라서 노드 유형이 n1-node-96-624인 2개의 노드로 노드 그룹을 만들면 각 노드에는 96개의 vCPU와 624GB의 메모리가 할당됩니다.

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

프로젝트에 사용할 수 있는 노드 유형 목록을 보려면 gcloud compute sole-tenancy node-types list 명령어 또는 nodeTypes.list REST 요청을 실행합니다. Compute Engine이 이전 노드 유형을 새 노드 유형으로 교체하는 경우가 있습니다. Compute Engine이 노드 유형을 교체하는 경우 교체된 노드 유형을 지정하는 템플릿에서 추가 노드 그룹을 만들 수 없습니다. Compute Engine이 노드 유형을 교체하는 경우 더 이상 사용할 수 없는 노드 유형을 지정하는 기존 노드 템플릿을 검토하고 수정해야 합니다.

노드 그룹 및 VM 프로비저닝

단독 테넌트 노드 템플릿은 노드 그룹의 속성을 정의하며, Google Cloud 영역에 노드 그룹을 만들기 전에 노드 템플릿을 만들어야 합니다. 그룹을 만들 때 노드 그룹에서 VM 인스턴스의 유지보수 정책과 노드 그룹의 노드 수를 지정합니다. 노드 그룹에는 0개 이상의 노드가 있을 수 있습니다. 예를 들어 그룹의 노드에서 VM 인스턴스를 실행할 필요가 없다면 노드 그룹의 노드 수를 0으로 줄이거나 노드 그룹 자동 확장 처리를 사용 설정하여 노드 그룹의 크기를 자동으로 관리할 수 있습니다.

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

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

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

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

유지보수 정책

다양한 워크로드 요구사항을 처리하기 위해 노드 그룹을 만들 때 VM의 유지보수 정책을 지정할 수 있습니다. 단독 테넌트 노드 유지보수 정책을 통해 유지보수 이벤트 후 노드 그룹의 VM을 마이그레이션하는 방법과 마이그레이션 여부를 구성할 수 있습니다. 예를 들어 라이선스 또는 규정 준수 요구사항에 따라 유지보수 정책을 선택하거나 물리적 서버 사용량을 제한할 수 있는 구성을 선택할 수 있습니다. 이러한 모든 유지보수 정책으로 VM이 전용 하드웨어에서 유지됩니다. 다음은 이러한 유지보수 정책에 대한 설명입니다.

  • 기본값: 이 정책으로 구성된 노드 그룹의 VM은 단독 테넌트가 아닌 VM의 기존 유지보수 동작을 따릅니다. 즉, VM 호스트의 호스트 유지보수 설정에 따라 호스트 유지보수 이벤트 전에 VM이 노드 그룹의 새 단독 테넌트 노드로 라이브 마이그레이션되며, 이 새 단독 테넌트 노드 VM은 고객의 VM만 실행합니다. 이 설정은 물리적 서버의 고정된 풀 내로 VM 마이그레이션을 제한하지 않으며, 물리적 서버 요구사항이 없고 기존 라이선스가 필요하지 않은 일반 워크로드에 권장됩니다.

  • 그대로 다시 시작: VM이 종료되고 유지보수 이벤트 후 동일한 물리적 호스트에서 다시 시작됩니다. 워크로드에 라이브 마이그레이션이 필요하지 않고, 호스트 유지보수 이벤트를 위해 4~6주마다 약 1시간의 다운타임을 허용할 수 있으며, VM이 단일 호스트에 대한 물리적 서버 어피니티를 유지해야 하는 경우 이 정책을 사용하는 것이 좋습니다.

  • 노드 그룹 내 마이그레이션: VM의 호스트 유지보수 설정에 따라 호스트 유지보수 이벤트 전에 VM이 노드 그룹의 다른 노드로 라이브 마이그레이션됩니다. 기본 설정과 달리 이러한 마이그레이션은 VM이 사용하는 고유한 물리적 서버의 수를 제한하기 위해 고정된 물리적 서버 집합 내에서 발생합니다. Compute Engine은 VM 마이그레이션에 충분한 용량을 확보하기 위해 단독 테넌트 노드 20개마다 1개의 노드를 예약합니다. 다운타임을 허용할 수 없기 때문에 라이브 마이그레이션해야 하고, 워크로드에 코어 또는 프로세서 기반 라이선스 요구사항이 있으며, 단독 테넌트 노드를 추가로 프로비저닝하려는 경우 이 정책을 사용하는 것이 좋습니다.

하드웨어 고장

드물게 서버에서 심각한 하드웨어 오류가 발생할 수 있습니다. 이 경우 Compute Engine은 물리적 서버와 고유 식별자를 사용 중지하고, 물리적 서버에 대한 액세스 권한을 취소하고, 새 고유 식별자가 있는 대체 노드를 할당하고, VM을 대체 노드로 이동합니다. 단독 테넌트 노드 구성에 따라 Compute Engine이 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 Engine은 단독 테넌트 노드의 비용을 최소화하기 위해 약정 사용 할인지속 사용 할인을 제공합니다. 또한 단독 테넌트 노드의 vCPU 및 메모리에 대한 요금이 이미 청구되었으므로 단독 테넌트 노드의 VM에 대한 추가 요금은 지불하지 않습니다.

가용성

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

제한사항

다음 단계