Autonomous Database on Dedicated Exadata Infrastructure의 컴퓨트 관리
-
ECPU: ECPU는 컴퓨트 리소스의 추상화된 측정 단위입니다. ECPU는 컴퓨트 및 스토리지 서버의 풀에서 탄력적으로 할당된 코어 수를 기반으로 합니다. Autonomous Database를 프로비저닝하려면 2개 이상의 ECPU가 필요합니다.
새 데이터베이스를 프로비저닝하고, 기존 데이터베이스를 복제하고, 기존 데이터베이스의 CPU 리소스를 확장 또는 축소하는 동안 CPU 개수는 기본적으로 2개의 ECPU로, 1씩 증분됩니다. 예를 들어, 2개 이상의 사용 가능한 다음 ECPU 수는 3개입니다.
ECPU 기반 컨테이너 데이터베이스에서 개발자용 Autonomous Database 인스턴스를 생성할 수 있습니다. 개발자가 새로운 애플리케이션을 구축하고 테스트하는 데 사용할 수 있는 무료 Autonomous Database입니다. 자세한 내용은 개발자를 위한 Autonomous Database를 참조하십시오.
-
OCPU: OCPU는 컴퓨트 리소스의 물리적 측정값입니다. OCPU는 하이퍼 스레드가 사용으로 설정된 프로세서의 물리적 코어를 기반으로 합니다.
주:
OCPU는 레거시 청구 측정지표이며 Autonomous Database on Dedicated Exadata Infrastructure에 대해 사용 중단되었습니다. Oracle은 모든 신규 및 기존 Autonomous Database 배포에 ECPU를 사용할 것을 권장합니다. 자세한 내용은 Oracle Support Document 2998755.1을 참조하십시오.새 데이터베이스를 프로비저닝(Provisioning), 기존 데이터베이스 복제(Clone) 및 기존 데이터베이스의 CPU 리소스 확장/축소:
- CPU 수는 기본적으로 1개 OCPU로, 1씩 증분됩니다. 예를 들어, 1을 초과하는 사용 가능한 다음 OCPU 수는 2입니다.
- 전체 OCPU가 필요하지 않은 데이터베이스의 경우 0.1에서 0.9까지 OCPU를 0.1 OCPU 단위로 할당할 수 있습니다. 이렇게 하면 CPU를 오버프로비저닝하고 각 Infrastructure Instance에서 더 많은 데이터베이스를 실행할 수 있습니다. 자세한 내용은 CPU Overprovisioning을 참조하십시오.
The Autonomous Exadata VM Cluster's compute type applies to all its Autonomous Container Databases and Autonomous Database instances.
컴퓨트 관리
Autonomous Database 인스턴스는 자율운영 Exadata VM 클러스터(AVMC) 및 자식 ACD(자율운영 컨테이너 데이터베이스) 중 하나에 배포됩니다. Exadata 인프라는 여러 AVMC를 실행할 수 있습니다. AVMC 리소스를 프로비저닝하는 동안 할당하는 CPU는 Autonomous Database에서 사용할 수 있는 총 CPU가 됩니다. 여러 AVMC를 만들 때 각 AVMC는 총 CPU에 대해 고유한 값을 가질 수 있습니다.
다중 VM Autonomous Database 기능이 실행되기 전에 생성된 Exadata 인프라(EI) 리소스의 Oracle Public Cloud 배포에서 다중 VM 자율운영 Exadata VM 클러스터를 사용할 수 없습니다. 다중 AVMC 기능 실행 후 생성된 X8M 세대 이상의 Exadata 인프라 리소스의 경우 각 AVMC는 선택한 Exadata 시스템 구성의 각 서버에 대해 하나의 클러스터 노드로 생성됩니다. 이러한 총 CPU를 여러 사용자 그룹에 걸쳐 제한하는 방법에 대한 자세한 내용은 컴파트먼트 할당량이 CPU 관리에 미치는 영향을 참조하십시오.
주:
지정된 Exadata 인프라에 생성할 수 있는 최대 AVMC 및 ACD 리소스 수는 하드웨어 생성에 따라 다릅니다. 각 세대의 제약 조건에 대한 자세한 내용은 자원 한도 및 인프라 구성 특성을 참조하십시오.AVMC 또는 ACD 레벨에서는 데이터베이스 생성에 사용할 수 있는 총 CPU 수를 사용 가능한 CPU라고 합니다. AVMC 리소스 레벨에서 사용 가능한 CPU는 첫번째 ACD를 만들 때까지 총 CPU와 같습니다. ACD를 만들면 노드당 ECPU 8개 또는 OCPU 2개가 AVMC의 사용 가능한 CPU에서 새 ACD에 할당됩니다. 따라서 AVMC 리소스 레벨에서 사용 가능한 CPU가 그에 따라 줄어듭니다. 해당 ACD에 첫 번째 Autonomous Database를 생성하면 새 데이터베이스가 초기에 할당된 CPU(노드당 ECPU 8개 또는 OCPU 2개)를 소비합니다. 새 데이터베이스에 8개 이상의 ECPU 또는 2개 이상의 OCPU가 필요한 경우 상위 AVMC 레벨에서 사용 가능한 CPU를 줄여 상위 AVMC의 사용 가능한 CPU에서 지정됩니다. 각 ACD 내에 더 많은 ACD를 생성하고 Autonomous Database를 프로비저닝하면 사용 가능한 CPU 값이 그에 따라 변경됩니다.
자율운영 Exadata VM 클러스터 레벨에서 사용 가능한 CPU는 모든 자율운영 컨테이너 데이터베이스에 적용됩니다. CPU Allocation When Auto-Scaling에 설명된 대로 자동 크기 조정 기능을 사용하는 경우 컨테이너 데이터베이스에서 사용할 수 있는 CPU 수가 중요해집니다.
마찬가지로 Autonomous Database의 CPU를 수동으로 스케일 업하면 상위 AVMC 레벨에서 사용 가능한 CPU에서 CPU가 소비되고 그에 따라 값이 변경됩니다.
Autonomous Database를 생성하는 경우 기본적으로 Oracle은 노드 장애 발생 시에도 최소 50%의 용량으로 데이터베이스를 실행할 수 있도록 추가 CPU를 예약합니다. ACD를 프로비저닝하는 동안 노드 전체에서 예약된 CPU의 백분율을 0% 또는 25%로 변경할 수 있습니다. 지침은 자율운영 컨테이너 데이터베이스 생성의 노드 복구 예약을 참조하십시오. 이러한 추가 CPU는 과금에 포함되지 않습니다.
Autonomous Database가 실행 중인 경우 초기 생성 시 또는 이후 수동 스케일링 작업을 통해 데이터베이스에 현재 할당된 CPU 수에 대해 비용이 청구됩니다. 또한 데이터베이스에 대해 자동 크기 조정이 사용으로 설정된 경우 자동 크기 조정의 결과로 데이터베이스가 사용 중인 추가 CPU에 대해 초당 비용이 청구됩니다. 청구 측정 및 계산 방법에 대한 자세한 내용은 CPU 청구 세부정보를 참조하십시오.
Autonomous Database가 중지되면 비용이 청구되지 않습니다. 하지만 할당된 CPU 수는 전체 배치를 위해 상위 AVMC 레벨에서 사용 가능한 CPU로 반환되지 않습니다.
Autonomous Database가 종료되거나 축소되는 경우 할당된 CPU 수는 전체 배포를 위해 상위 AVMC 레벨에서 사용 가능한 CPU로 즉시 반환되지 않습니다. 상위 컨테이너 데이터베이스가 재시작될 때까지 상위 컨테이너 데이터베이스에서 사용 가능한 CPU 수에 계속 포함됩니다. 이러한 CPU를 확보 가능 CPU라고 합니다. 상위 AVMC 레벨의 확보 가능한 CPU는 모든 ACD의 확보 가능한 CPU의 합계입니다. ACD가 다시 시작되면 재생 가능한 모든 CPU가 상위 AVMC 레벨에서 사용 가능한 CPU로 반환됩니다.
ACD(자율운영 컨테이너 데이터베이스) 재시작은 온라인 작업으로, 클러스터 전체에서 롤링 방식으로 수행되며, Transparent Application Continuity를 사용하기 위한 최적의 사용법에 따라 구성된 경우 애플리케이션 작동 중지 시간이 발생하지 않습니다.
참고:
이 문서에 설명된 여러 컴퓨트(CPU) 속성은 AVMC(자율운영 Exadata VM 클러스터) 또는 ACD(자율운영 컨테이너 데이터베이스)의 세부정보 페이지에서 추적할 수 있습니다. 지침은 리소스 사용량 추적을 참조하십시오.자동 크기 조정 시 CPU 할당
자동 크기 조정 기능을 통해 Autonomous Database는 할당된 CPU 수보다 최대 3배 더 많은 CPU 및 IO 리소스를 사용할 수 있습니다. CPU 오버프로비저닝의 경우 CPU 수의 3배로 인해 값이 1보다 작으면 다음 정수로 반올림됩니다. CPU 오버프로비저닝은 OCPU에서만 지원됩니다. 자세한 내용은 CPU Overprovisioning을 참조하십시오.
단일 Autonomous Database가 전체 배포를 위해 풀에서 사용 가능한 모든 CPU를 소비하도록 자동 스케일 업할 수 없도록 하기 위해 Oracle Autonomous Database on Dedicated Exadata Infrastructure는 자율운영 컨테이너 데이터베이스를 제한 제어로 사용합니다.
ACD에서 자동 스케일링이 사용으로 설정된 Autonomous Database를 프로비전하는 동안 해당 ACD에서 사용 가능한 CPU가 새 데이터베이스의 3X CPU 값보다 작으면 해당 ACD에 추가 CPU가 예약됩니다. 이러한 CPU를 예약된 CPU라고 합니다. 예약된 CPU는 ACD 레벨에서 사용 가능한 CPU가 항상 해당 ACD에서 가장 큰 자동 스케일링 사용 데이터베이스의 3x CPU 값보다 크거나 같은지 확인합니다. 이러한 예약된 CPU는 여전히 이 ACD에서 Autonomous Database를 생성하거나 수동으로 확장하는 데 사용할 수 있습니다.
Autonomous Database를 자동으로 확장하면 Oracle Autonomous Database on Dedicated Exadata Infrastructure는 상위 컨테이너 데이터베이스에서 유휴 CPU를 찾습니다. 유휴 CPU를 사용할 수 있으면 Autonomous Database가 확장됩니다. 그렇지 않으면 확장되지 않습니다. 기본적으로 데이터베이스에는 많은 유휴 시간이 있으므로 자동 확장은 비용을 제어하고 다른 자율운영 컨테이너 데이터베이스의 데이터베이스로부터 좋은 격리를 유지하면서 리소스 사용을 최대화하는 방법입니다.
Autonomous Database 자동 스케일링에 사용된 CPU가 로드가 짧고 할당된 모든 CPU를 사용하지 않는 실행 중인 다른 Autonomous Database에서 온 경우 Oracle Autonomous Database on Dedicated Exadata Infrastructure는 다른 데이터베이스의 로드가 증가하고 할당된 CPU가 다시 필요한 경우 자동 스케일링된 데이터베이스를 자동으로 스케일링합니다.
자동 스케일링이 사용으로 설정된 네 개의 실행 중인 4-CPU 자율운영 데이터베이스를 호스트하는 자율운영 컨테이너 데이터베이스의 예를 고려해 보십시오. 자동 크기 조정을 위해 컨테이너 데이터베이스에서 사용할 수 있는 CPU 수는 12개입니다. 로드 증가로 인해 이러한 데이터베이스 중 하나를 4개 CPU를 초과하여 자동 스케일링해야 하는 경우 Oracle Autonomous Database on Dedicated Exadata Infrastructure는 다른 데이터베이스 중 하나 이상이 로드가 부족하고 할당된 모든 CPU를 사용하지 않는 경우에만 자동 스케일링 작업을 수행합니다. CPU 4개 데이터베이스 4개가 모두 항상 실행 중이므로 이 예제의 청구 비용은 최소 16개 CPU입니다.
대조적으로 자동 스케일링이 사용으로 설정되고 CPU가 8개인 Autonomous Database가 중지된 4개의 실행 중인 2CPU Autonomous Databases를 호스팅하는 자율운영 컨테이너 데이터베이스의 예를 고려해 보십시오. 자동 크기 조정을 위해 컨테이너 데이터베이스에서 사용할 수 있는 CPU 수는 다시 16개입니다. Oracle Autonomous Database on Dedicated Exadata Infrastructure는 CPU 2개 이후의 로드 증가로 인해 실행 중인 데이터베이스 중 하나를 자동 스케일 조정해야 하는 경우 정지된 8개 CPU 데이터베이스에 할당된 CPU를 사용하여 작업을 수행할 수 있습니다. 이 예에서 네 개의 실행 중인 데이터베이스는 서로의 할당된 CPU를 소비하지 않고도 동시에 총 8개의 추가 CPU를 소비할 수 있습니다. CPU 2개 데이터베이스 4개만 항상 실행되고 있기 때문에 이 예제의 청구 비용은 최소한 CPU 8개에 불과합니다.
자율운영 Data Guard 서비스 인스턴스(로컬 또는 지역 간)의 경우 추가 가격은 자동 스케일링 사용 여부에 관계없이 기본 서비스 인스턴스를 생성하거나 명시적으로 스케일링할 때 예약한 ECPU 또는 OCPU 수입니다. 기본 서비스 인스턴스에서 자동 스케일링 관련 ECPU 또는 OCPU 소비는 자율운영 Data Guard 대기 서비스 인스턴스에서 발생하지 않습니다.
컴파트먼트 할당량이 CPU 관리에 미치는 영향
일반적으로 Autonomous Database를 생성하거나 확장할 때 요청을 충족할 수 있는 Oracle Autonomous Database on Dedicated Exadata Infrastructure 기능은 전체 배포에서 단일 CPU 풀에 할당되지 않은 CPU의 가용성에 따라 달라집니다.
그러나 Oracle Cloud Infrastructure의 구획 할당량 기능을 사용하여 구획별로 각 워크로드 유형(데이터 웨어하우스 또는 트랜잭션 처리)의 자율운영 데이터베이스를 생성, 수동으로 확장 및 자동 스케일링하는 데 사용할 수 있는 CPU 수를 개별적으로 추가로 제한할 수 있습니다.
간단히 말해서, set, unset 및 zero 정책 문을 생성하여 구획 할당량 기능을 사용하여 지정된 구획에서 지정된 리소스의 가용성을 제한합니다. 자세한 정보 및 지침은 구획 할당량을 참조하십시오.
VM 클러스터 노드가 CPU 관리에 미치는 영향
CPU 관리 및 할당에 대한 앞의 설명에 따르면 AVMC 리소스를 프로비저닝하는 동안 노드당 CPU 수를 선택하여 AVMC(자율운영 Exadata VM 클러스터) 리소스를 여러 개 만들 수 있습니다.
이 섹션에서는 Oracle Cloud Infrastructure가 VM 클러스터 노드에 Autonomous Database를 배치하는 방법과 자동 크기 조정 및 병렬 처리에 이러한 배치로 인한 결과에 대해 자세히 설명합니다.
-
분할 임계값: Oracle Cloud Infrastructure가 여러 노드에 걸쳐 Autonomous Database를 여는 그 이상의 CPU 값입니다. 기본 분할 임계값은 ECPU의 경우 64개, OCPU의 경우 16개이지만, CPU 노드 수가 기본값보다 작은 상태로 VM 클러스터가 생성되면 기본값이 VM 클러스터 노드 수 크기로 대체됩니다.ACD(자율운영 컨테이너 데이터베이스)를 프로비전하는 동안 분할 임계값 속성을 사용하여 분할 값을 명시적으로 설정할 수도 있습니다.
CPU 값이 분할 값보다 작은 Autonomous Database는 클러스터의 한 노드에서 열리고 CPU 값이 분할 임계값보다 큰 노드로 생성된 노드가 여러 노드에서 열립니다.
-
AVMC에서 노드 2개와 노드당 ECPU 40개로 기본 분할 임계값(ECPU 64개)을 사용하여 ACD를 생성한다고 가정해 보겠습니다. 40이 64보다 작기 때문에 CPU 요구사항이 40보다 큰 모든 Autonomous Database가 여러 노드에 분할되어 열리므로, 해당 노드에서 DML 요청을 수행할 수 있습니다. 그러나 AVMC가 노드 2개와 노드당 ECPU 80개로 생성된 경우 ECPU 요구사항이 64보다 큰 데이터베이스는 여러 노드에서 분할되어 열립니다.
-
노드가 2개이고 노드당 ECPU가 40개인 VM 클러스터에서 ACD를 만들고 ECPU가 20개인 분할 임계값을 훨씬 작은 값으로 명시적으로 설정한다고 가정해 보겠습니다. CPU 요구사항이 20보다 큰 Autonomous Database는 여러 노드에서 분할 및 열리고, CPU 요구사항이 20보다 작은 데이터베이스는 단일 노드에서 열립니다.
분할 임계값을 기본값보다 훨씬 작은 숫자로 설정하면 CPU 수가 설정된 분할 값보다 많으면 여러 노드에서 CPU 수가 작 열릴 가능성이 높아집니다. 데이터베이스가 생성되거나 이 분할 값보다 큰 크기로 확장될 때마다 여러 노드에서 열립니다. 이 기능은 노드 장애 또는 계획된 유지 관리 시 데이터베이스가 여러 노드에서 열리도록 성능 저하를 제어하려는 경우에 유용합니다. 대규모 RAC 클러스터의 여러 노드에 데이터베이스가 분할되어 있으면 한 노드에 장애가 발생하거나 일정이 잡힌 유지 관리가 발생할 경우 성능 프로파일을 50%로 낮추는 대신 성능이 계속 향상될 수 있습니다.
-
2개의 노드와 40개의 ECPU가 있는 AVMC에서 80개의 ECPU와 같이 기본값보다 분할 임계값을 훨씬 높은 값으로 명시적으로 설정한다고 가정해 보겠습니다. CPU 요구사항이 40보다 큰 Autonomous Database는 여러 노드에서 분할 및 열리고, CPU 요구사항이 40보다 작은 데이터베이스는 단일 노드에서 열립니다.
분할 임계값을 기본값보다 크게 설정하면 데이터베이스 DML이 단일 RAC 노드에 유지되고 클러스터 대기 경합이 발생하지 않습니다.
-
Autonomous Database를 수동으로 스케일링하면 새 CPU 값이 기존 분할 모델에 적용됩니다. 즉, 새 값이 분할 임계값보다 작으면 한 노드에서 열리고, 값이 분할 임계값보다 크면 여러 노드에서 열립니다.
-
-
분배 선호도: 분할 임계값을 초과한 후 Autonomous Database가 열릴 노드 수를 결정합니다.
예를 들어 노드가 4개이고 노드당 ECPU가 80개인 AVMC 리소스를 생성하고 이 AVMC에서 데이터베이스 분할 임계값이 64로 설정된 ACD를 생성했다고 가정해 보겠습니다. ECPU 요구사항이 120인 Autonomous Database를 생성하면 64보다 큰 120(분할 임계값)으로 여러 노드에서 데이터베이스가 분할되고 열립니다.-
배포 유사성이 최소 노드로 설정된 경우 Oracle Cloud Infrastructure는 각 노드에 ECPU가 60개인 두 노드에 데이터베이스를 생성하려고 시도합니다. 불가능한 경우 각각 40개의 ECPU를 사용하여 3개 노드로 분할됩니다. 또한 가능하지 않은 경우 Oracle Cloud Infrastructure는 각각 30개의 ECPU를 사용하여 4개 노드에서 데이터베이스를 열려고 시도합니다.
-
최대 노드에 분포 유사성을 지정하면 Oracle Cloud Infrastructure는 각각 30개의 ECPU를 사용하여 4개 노드 전체에 걸쳐 분할된 데이터베이스를 생성하려고 시도합니다. 이 기능을 사용할 수 없는 경우 ECPU가 각각 40개인 3개 노드에 걸쳐 분할됩니다. 또한 가능하지 않은 경우 Oracle Cloud Infrastructure는 각각 60개의 ECPU를 사용하여 2개 노드에서 데이터베이스를 열려고 시도합니다.
-
-
노드 페일오버 예약(%): AVMC에서 현지화된 실패 및 유지보수 이벤트에 대해 인접한 노드(데이터베이스 소프트웨어가 있지만 열려 있지 않은 노드)에 따로 설정된 CPU 수입니다. 노드 복구 예약은 분할되지 않은 데이터베이스 배치에 적용됩니다.기본적으로 50%의 예약이 있습니다. 즉, 실패 이벤트 또는 유지 관리 중에는 계속 실행되지만 할당된 CPU의 50%는 실행됩니다.
-
활용률이 매우 낮은 중요하지 않은 데이터베이스 또는 데이터베이스의 경우 노드 복구 예약을 더 작은 값으로 설정하면 결국 전용 Exadata 인프라에서 더 많은 수의 데이터베이스를 생성하고 통합할 수 있습니다.
-
유지 관리 중 작동 중지 시간이 허용되는 개발 환경 및 데이터베이스에 대해 이 값을 0으로 설정할 수 있습니다.
- 어느 정도까지는 분할 임계값 및 분산 유사성을 사용하여 데이터베이스가 2개 이상의 노드로 분할되도록 하여 노드 페일오버 예약을 제어할 수도 있습니다.Autonomous Database가 4개 노드로 분할되는 시나리오를 고려해 보십시오. 유지 관리 작업이 진행되는 동안 한 번에 한 노드를 롤링 방식으로 제거하면 항상 3개의 노드가 작동되어 트래픽이 발생하므로 성능 예약이 보통 50%가 아닌 75%로 효과적으로 유지됩니다. 클러스터가 클수록 8노드 클러스터에서 87.5%의 예약과 같이 이 예약을 더욱 확장할 수 있습니다.
-
- 자동 스케일링:
- DML을 병렬화할 수 있는 경우 병렬화할 수 없는 DML의 경우 단일 VM 클러스터 노드와 VM 클러스터 노드 간에 자동 스케일링이 발생할 수 있습니다.
- 병렬화할 수 없는 query가 포함된 여러 동시 세션이 클러스터의 모든 노드로 라우팅될 수 있으므로 다중 노드 데이터베이스의 모든 노드에서 자동으로 확장할 수 있습니다.
- 병렬 프로세싱:
- SQL 문의 병렬 처리는 먼저 단일 노드 내에서 열린 자율운영 Exadata VM 클러스터 노드 내에서 수행된 다음, 앞에서 설명한 대로 자율운영 Exadata VM 클러스터의 크기에 따라 인접한 열린 노드에서 수행됩니다.
각 노드의 리소스 사용률을 기반으로 합니다. 사용 가능한 CPU의 일부 값을 사용하여 Autonomous Database를 프로비저닝하거나 확장할 수 있는 것은 아닙니다. 예를 들어 AVMC 레벨에서 20개의 CPU를 사용할 수 있다고 가정합니다. 노드 레벨의 리소스 가용성에 따라 1~20개의 CPU 중 일부 값을 사용하여 Autonomous Database를 프로비저닝하거나 확장할 수 있는 것은 아닙니다. Autonomous Database를 프로비저닝하거나 확장하는 데 사용할 수 있는 CPU 값 목록을 프로비저닝 가능한 CPU라고 합니다.
-
GetAutonomousContainerDatabase는 제공된 자율운영 컨테이너 데이터베이스에서 새 Autonomous Database를 생성하는 데 사용할 수 있는 프로비전 가능한 CPU 값 목록을 반환합니다. 자세한 내용은 GetAutonomousContainerDatabase를 참조하십시오.
-
GetAutonomousDatabase는 제공된 Autonomous Database를 확장하는 데 사용할 수 있는 프로비전 가능한 CPU 값 목록을 반환합니다. 자세한 내용은 GetAutonomousDatabase를 참조하십시오.