Gerenciamento de Computação no Autonomous AI Database na Infraestrutura Dedicada do Exadata

O Autonomous AI Database on Dedicated Exadata Infrastructure oferece dois modelos de computação ao configurar seus recursos do Autonomous AI Database. Os dois URLs são:

• ECPU: Uma ECPU é uma medida resumida de recursos de computação. ECPUs se baseiam no número de núcleos alocados elasticamente de um pool de servidores de computação e armazenamento. Você precisa de pelo menos 2 ECPUs para provisionar um Autonomous AI Database.

  Ao provisionar um novo banco do dados, clonar e ampliar ou reduzir os recursos de CPU de um banco existente, a contagem de CPUs assume como padrão 2 ECPUs, em incrementos de 1. Por exemplo, o próximo número disponível de ECPUs acima de 2 é 3.

  Você pode criar instâncias do Autonomous AI Database for Developers em bancos de dados contêineres baseados em ECPU. Eles são Autonomous AI Databases gratuitos que os desenvolvedores podem usar para criar e testar novas aplicações. Consulte Autonomous AI Database para Desenvolvedores para obter mais detalhes.

• OCPU: Uma OCPU é uma medida física de recursos de computação. As OCPUs se baseiam no núcleo físico de um processador com hyper-threading ativado.

  Observação: A OCPU é uma métrica de faturamento legada e foi desativada para o Autonomous AI Database on Dedicated Exadata Infrastructure. A Oracle recomenda o uso de ECPUs para todas as implantações novas e existentes do Autonomous AI Database. Consulte o Documento do Suporte Técnico Oracle 2998755.1 para obter mais informações.

  Ao provisionar um novo banco de dados, clonar um banco de dados existente e expandir ou reduzir os recursos de CPU de um banco de dados existente:

  • A contagem de CPUs assume 1 OCPU como padrão, em incrementos de 1. Por exemplo, o próximo número disponível de OCPUs acima de 1 é 2.

  • Para bancos que não precisam de OCPU inteira, você pode atribuir OCPUs de 0,1 a 0,9 em incrementos de 0,1 OCPUs. Com isso, é possível superprovisionar a CPU e executar mais bancos de dados em cada instância de infraestrutura. Para obter mais detalhes, consulte Sobprovisionamento de CPU.

O tipo de computação do Cluster de VMs do Autonomous Exadata se aplica a todas as suas instâncias do Autonomous Container Databases e do Autonomous AI Database.

Gerenciamento de Computação

As instâncias do Autonomous AI Database são implantadas em um Cluster de VMs do Autonomous Exadata (AVMC) e em um de seus Autonomous Container Databases (ACD) filhos. As Infraestruturas do Exadata podem executar vários AVMCs. As CPUs que você aloca ao provisionar um recurso AVMC serão as CPUs totais disponíveis para seus Autonomous AI Databases. Quando você cria vários AVMCs, cada AVMC pode ter seu próprio valor quando quiser o total de CPUs

Vários Clusters de VMs do Autonomous Exadata não estão disponíveis em nenhuma implantação do Oracle Public Cloud dos recursos do Exadata Infrastructure (EI) criados antes do início do recurso Várias VMs do Autonomous AI Database. Para a geração X8M e acima dos recursos do Exadata Infrastructure criados após a inicialização do recurso Vários AVMC, cada AVMC é criado com um nó de cluster para cada um dos servidores da forma do sistema Exadata escolhida. Para obter informações sobre como restringir essas CPUs totais em diferentes Grupos de usuários, consulte Como as Cotas de Compartimento Afetam o Gerenciamento de CPU.

Observação: O número máximo de recursos AVMC e ACD que você pode criar em uma determinada Infraestrutura Exadata varia de acordo com a geração de hardware. Consulte Limites de Recursos e Características de Formas de Infraestrutura para obter detalhes sobre restrições para cada geração.

Em um nível de AVMC ou ACD, o número total de CPUs disponíveis para criação de banco de dados é chamado CPUs disponíveis. No nível de recurso do AVMC, as CPUs disponíveis serão iguais ao total de CPUs até você criar o primeiro ACD. Depois que você cria um ACD, 8 ECPUs ou 2 OCPUs por nó são alocadas para o novo ACD das CPUs disponíveis do AVMC. Portanto, as CPUs disponíveis no nível do recurso AVMC se reduzem adequadamente. Quando você cria o primeiro Autonomous AI Database nesse ACD, o novo banco de dados consome as CPUs inicialmente alocadas (8 ECPUs ou 2 OCPUs por nó). Se o novo banco de dados precisar de mais de 8 ECPUs ou 2 OCPUs, ele será designado pelas CPUs disponíveis do AVMC pai, reduzindo as CPUs disponíveis no nível do AVMC pai. À medida que você cria mais ACDs e provisiona Autonomous AI Databases em cada ACD, o valor da CPU disponível é alterado de acordo.

As CPUs disponíveis no nível do Cluster da VM do Autonomous Exadata se aplicam a todos os seus Autonomous Container Databases. Essa contagem de CPUs disponíveis para o banco dos dados contêineres se tornará importante se você estiver usando o recurso de dimensionamento automático, conforme descrito em Alocação de CPU Quando o Dimensionamento Automático.

Da mesma forma, quando você dimensiona manualmente as CPUs de um Autonomous AI Database, as CPUs são consumidas das CPUs disponíveis em seu nível AVMC pai e seu valor muda de acordo.

Quando você cria um Autonomous AI Database, por padrão, a Oracle reserva CPUs adicionais para garantir que o banco de dados possa ser executado com pelo menos 50% de capacidade, mesmo em caso de qualquer falha de nó. Você pode alterar a porcentagem de CPUs reservadas entre nós para 0% ou 25% ao provisionar um ACD. Consulte Reserva de failover do nó em Criar um Autonomous Container Database para obter instruções. Essas CPUs adicionais não estão incluídas no faturamento.

Quando um Autonomous AI Database está em execução, você recebe a cobrança pelo número de CPUs atualmente alocadas para o banco, seja especificado na criação inicial ou posteriormente por uma operação manual de dimensionamento. Além disso, se a escala automática estiver ativada para o banco, você receberá uma cobrança de cada segundo para quaisquer CPUs adicionais que o banco estiver usando como resultado da expansão automática. Consulte Detalhes de Faturamento da CPU para mais informações sobre como o faturamento é medido e calculado.

Quando um Autonomous AI Database for interrompido, você não será cobrado. No entanto, o número de CPUs alocadas a ele não será retornado para as CPUs disponíveis em seu nível AVMC principal para a implantação geral.

Quando um Autonomous AI Database é encerrado ou reduzido, o número de CPUs alocadas a ele não são imediatamente devolvidas às CPUs disponíveis em seu nível AVMC pai para a implantação geral. Elas continuam a ser incluídas na contagem de CPUs disponíveis para o banco de dados contêiner pai até que o banco de dados contêiner pai seja reiniciado. Essas CPUs são chamadas de CPUs reivindicáveis. CPUs Recuperáveis no nível AVMC pai é a soma de CPUs recuperáveis de todos os seus ACDs. Quando um ACD é reiniciado, ele retorna todas as CPUs reivindicáveis para as CPUs disponíveis no nível AVMC pai.

A reinicialização de um ACD (Autonomous Container Database) é uma operação on-line, feita de maneira incremental em todo o cluster e não resultará em tempo de inatividade do aplicativo se configurado de acordo com as melhores práticas para usar a Continuidade Transparente de Aplicativos.

Dica: Você pode rastrear os diferentes atributos de computação (CPU) discutidos neste artigo na página Detalhes de um Cluster de VMs do Autonomous Exadata (AVMC) ou do Autonomous Container Database (ACD). Para obter orientação, consulte Rastreamento de Uso de Recursos.

Alocação de CPU ao Dimensionar Automaticamente

O recurso de dimensionamento automático permite a um Autonomous AI Database usar até três vezes mais recursos da CPU e de Entrada/Saída do que sua contagem de CPUs alocadas. No caso de superprovisionamento da CPU, se três vezes a contagem de CPUs resultar em um valor menor que 1, ela será arredondada para o próximo número inteiro. Só há suporte para o superprovisionamento de CPU com OCPUs. Consulte Sobprovisionamento de CPU para obter mais detalhes.

Para garantir que nenhum Autonomous AI Database possa ser dimensionado automaticamente para consumir todas as CPUs disponíveis no pool para a implantação geral, o Oracle Autonomous AI Database on Dedicated Exadata Infrastructure usa o Autonomous Container Database como controle de limitação.

Ao provisionar um Autonomous AI Database ativado por dimensionamento automático em um ACD, se as CPUs disponíveis nesse ACD forem inferiores ao valor de CPU 3X do novo banco de dados, as CPUs adicionais serão reservadas nesse ACD. Essas CPUs são chamadas de CPUs reservadas. As CPUs reservadas garantem que as CPUs disponíveis em um nível de ACD sejam sempre maiores ou iguais a 3x o valor de CPU do maior banco de dados ativado por dimensionamento automático nesse ACD. Essas CPUs reservadas ainda podem ser usadas para criar ou dimensionar manualmente Autonomous AI Databases neste ACD.

Ao expandir automaticamente um Autonomous AI Database, o Oracle Autonomous AI Database on Dedicated Exadata Infrastructure procura CPUs ociosas em seu banco de dados contêiner principal. Se CPUs ociosas estiverem disponíveis, o Autonomous AI Database será expandido; caso contrário, não. Os bancos de dados têm muito tempo ocioso, portanto, o dimensionamento automático é uma maneira de maximizar o uso de recursos enquanto controla custos e preserva o bom isolamento dos bancos de dados em outros Autonomous Container Databases.

Se a CPU usada para dimensionar automaticamente um Autonomous AI Database vier de outro Autonomous AI Database em execução que seja levemente carregado e, portanto, não estiver usando todas as suas CPUs alocadas, o Oracle Autonomous AI Database on Dedicated Exadata Infrastructure dimensionará automaticamente o banco de dados dimensionado automaticamente se a carga aumentar no outro banco de dados e ele precisar de sua CPU alocada de volta.

Considere o exemplo de um Autonomous Container Database que hospeda quatro Autonomous AI Databases em execução com 4 CPUs, todos com dimensionamento automático ativado. A contagem de CPUs disponíveis para o banco de dados contêiner para fins de dimensionamento automático é 12. Se um desses bancos de Dados precisar ser escalado automaticamente além de 4 CPUs devido ao aumento da carga, o Oracle Autonomous AI Database on Dedicated Exadata Infrastructure só executará a operação de dimensionamento automático se um ou mais dos outros bancos de Dados forem carregados levemente e não usar todas as CPUs alocadas. O custo de faturamento deste exemplo é 16 CPUs, no mínimo, porque todos os quatro bancos de dado de 4 CPUs estão sempre em execução.

Por outro lado, considere o exemplo de um Autonomous Container Database que hospeda quatro Autonomous AI Database em execução com 2 CPUs, todos com dimensionamento automático ativado e um Autonomous AI Database com 8 CPUs interrompido. A contagem de CPUs disponíveis para o banco de dados contêiner para fins de dimensionamento automático é novamente 16. Se um dos bancos de dados em execução precisar ser dimensionado automaticamente em decorrência de aumento de carga nas últimas 2 CPUs, o Oracle Autonomous AI Database on Dedicated Exadata Infrastructure poderá executar a operação usando CPUs alocadas para o banco de dados de 8 CPUs interrompido. Neste exemplo, os quatro banco de dados em execução podem consumir até um total de 8 CPUs adicionais simultaneamente sem consumir as CPUs alocadas umas das outras. O custo de faturamento deste exemplo é apenas 8 CPUs, no mínimo, porque apenas os quatro bancos de dado de 2 CPUs estão sempre em execução.

Para qualquer instância de serviço do Autonomous Data Guard, local ou entre regiões, o preço adicional será o número de ECPUs ou OCPUs reservadas quando você criou ou dimensionou explicitamente sua instância de serviço principal, independentemente de o dimensionamento automático estar ativado ou não. O consumo automático de ECPU ou OCPU relacionado ao dimensionamento em instâncias de serviço principais não ocorre em instâncias de serviço Stand-by do Autonomous Data Guard.

Como as Cotas de Compartimento Afetam o Gerenciamento da CPU

Normalmente, quando você cria ou amplia um Autonomous AI Database, a capacidade do Oracle Autonomous AI Database on Dedicated Exadata Infrastructure de atender à sua solicitação depende apenas da disponibilidade de CPUs não alocadas no único pool de CPUs em toda a implantação.

No entanto, você pode usar o recurso de cotas do compartimento do Oracle Cloud Infrastructure para restringir ainda mais, em uma base de compartimento por compartimento, o número de CPUs disponíveis para criar, dimensionar manualmente e dimensionar automaticamente Autonomous AI Databases de cada tipo da carga de trabalho (Autonomous AI Lakehouse ou Autonomous AI Transaction Processing) individualmente.

Em resumo, você usa o recurso de cotas de compartimento criando instruções de política set, unset e zero para limitar a disponibilidade de um determinado recurso em um determinado compartimento. Para obter informações detalhadas e instruções, consulte Cotas de Compartimento.

Como os Nós do Cluster de VMs Afetam o Gerenciamento da CPU

A discussão anterior sobre gerenciamento de CPU e alocação indica que você pode criar vários recursos AVMC (Autonomous Exadata VM Cluster) escolhendo a contagem de CPUs por nó ao provisionar o recurso AVMC.

Esta seção discutirá detalhes granulares sobre como o Oracle Cloud Infrastructure coloca Autonomous AI Databases nos nós de cluster de VMs e as consequências dessa colocação em dimensionamento automático e processamento paralelo.

Os seguintes atributos determinam quando e como um Autonomous AI Database é colocado em vários nós:

• Limite de Divisão: O valor da CPU além do qual o Oracle Cloud Infrastructure abre um Autonomous AI Database em vários nós. O limite de divisão padrão é 64 para ECPUs e 16 para OCPUs, mas se os Clusters de VMs forem criados com contagens de nós de CPU abaixo do valor padrão, o padrão será substituído pelo tamanho da contagem de nós do Cluster de VMs. Você também pode definir o valor de divisão explicitamente usando o atributo Dividir Limite ao provisionar um ACD (Autonomous Container Database).

  Os Autonomous AI Databases criados com um valor de CPU menor que o valor de divisão serão abertos em um nó do cluster e os criados com um valor de CPU maior que o valor de limite de divisão serão abertos em vários nós.

  • Suponha que você crie um ACD com um limite de divisão padrão (64 ECPUs) em um AVMC com dois nós e 40 ECPUs por nó. Como o 40 é menor que 64, qualquer Autonomous AI Database com um requisito de CPU maior que 40 será dividido e aberto em vários nós, permitindo solicitações DML nesses nós. No entanto, se o AVMC tiver sido criado com dois nós e 80 ECPUs por nó, qualquer banco de dados com um requisito de ECPU maior que 64 será dividido e aberto em vários nós.

  • Suponha que você crie um ACD em um Cluster de VMs com dois nós e 40 ECPUs por nó e defina explicitamente o valor de limite de divisão para um valor muito menor, digamos 20 ECPUs. Qualquer Autonomous AI Database com um requisito de CPU maior que 20 será dividido e aberto em vários nós, e os bancos de dados com um requisito de CPU menor que 20 serão abertos em um único nó.

    A definição do limite de divisão como um número muito menor que o valor padrão aumenta as chances de bancos de dados com contagens de CPU menores serem abertos em vários nós, desde que a contagem de CPUs seja maior que o valor de divisão definido. Sempre que um banco de dados é criado ou dimensionado para um tamanho maior que esse valor de divisão, ele é aberto em vários nós. Isso é útil quando você deseja que os bancos de dados sejam abertos em vários nós para controlar a degradação do desempenho em caso de falha de nó ou manutenção planejada. Com bancos de dados divididos em vários nós em clusters RAC maiores, se qualquer nó falhar ou quando ocorrer manutenção programada, você poderá continuar a ter desempenho mais alto em vez de degradar para um perfil de desempenho de 50%.

  • Suponha que você defina explicitamente o limite de divisão para um valor muito maior que o padrão, digamos, 80 ECPUs, em um AVMC com dois nós e 40 ECPUs. Qualquer Autonomous AI Database com um requisito de CPU maior que 40 será dividido e aberto em vários nós, e os bancos de dados com um requisito de CPU menor que 40 serão abertos em um único nó.

    A definição do limite de divisão para um valor muito maior do que o padrão faz com que o DML do banco de dados permaneça em um único nó RAC e elimine a chance de contenção de espera do cluster.

  • Quando você dimensiona manualmente um Autonomous AI Database, o novo valor da CPU será aplicado ao modelo de Divisão existente. Ou seja, se o novo valor for menor que o limite de divisão, ele será aberto em um nó e se o valor for maior que o limite de divisão, ele será aberto em vários nós.

• Afinidade de Distribuição: Determina o número de nós nos quais um Autonomous AI Database será aberto depois de cruzar o Limite de Divisão.

  Por exemplo, suponha que você tenha criado um recurso AVMC com 4 nós e 80 ECPUs por nó e criado um ACD nesse AVMC com o Limite de Divisão do banco de dados definido como 64. A criação de um Autonomous AI Database com um requisito de ECPU igual a 120 dividirá e abrirá o banco de dados em vários nós como 120 maior que 64 (Limite de Divisão).

  • Se a sua afinidade de distribuição estiver definida como Nós mínimos, o Oracle Cloud Infrastructure tentará criar o banco de dados em 2 nós com 60 ECPUs em cada nó. Se isso não for possível, ele será dividido em 3 nós com 40 ECPUs cada. Se isso também não for possível, o Oracle Cloud Infrastructure tentará abrir o banco de dados em 4 nós com 30 ECPUs cada.

  • Se você especificar a afinidade de distribuição para o Máximo de nós, o Oracle Cloud Infrastructure tentará criar o banco de dados dividido em todos os 4 nós com 30 ECPUs cada. Se isso não for possível, ele será dividido em três nós com 40 ECPUs cada. Se isso também não for possível, o Oracle Cloud Infrastructure tentará abrir o banco de dados em 2 nós com 60 ECPUs cada.

• Reserva de Failover de Nó (%): O número de CPUs reservadas em nós adjacentes (nós em que o software do banco de dados está presente, mas não está aberto) no seu AVMC para eventos de falha e manutenção localizados. A Reserva de Failover de Nó se aplica a implantações de banco de dados não divididas. Por padrão, há uma reserva de 50%, o que significa que durante um evento de falha ou manutenção, você continuará a executar, mas em 50% da CPU alocada.

  • Para bancos de dados não críticos ou com utilização muito leve, você pode definir a Reserva de Failover de Nó como um valor menor para que, no final, você possa criar e consolidar um número maior de bancos de dados em sua Infraestrutura Dedicada do Exadata.

  • Você pode definir esse valor como zero para ambiente de desenvolvimento e bancos de dados em que um período de indisponibilidade durante a manutenção seja aceitável.

  • Até certo ponto, a Reserva de Failover de Nó também pode ser controlada garantindo que um banco de dados seja dividido em mais de 2 nós, usando o limite de divisão e a afinidade de distribuição. Considere um cenário em que um Autonomous AI Database é dividido em 4 nós. Ao remover um nó de cada vez de forma contínua enquanto uma atividade de manutenção está em andamento, você sempre tem 3 nós ainda ativos e levando o tráfego, mantendo sua reserva de desempenho efetivamente 75%, em vez dos 50%. Com clusters maiores, você pode aumentar ainda mais essa reserva, digamos, para uma reserva de 87,5% em um cluster de 8 nós.

Como a alocação de CPU de um Banco de Dados AI Autônomo é distribuída pelos nós do cluster da VM afeta as seguintes operações:

• Dimensionamento automático:

  • O dimensionamento automático poderá ocorrer em um único nó de cluster de VMs para DML não paralelizável e entre nós de Cluster de VMs se o DML for paralelizável.

  • Várias sessões simultâneas com consultas não paralelizáveis podem ser roteadas para todos os nós do cluster, permitindo efetivamente o dimensionamento automático em todos os nós em um banco de dados de vários nós.

• Processamento Paralelo:

  • O processamento paralelo de instruções SQL ocorre nos nós de cluster de VMs do Autonomous Exadata que estão abertos, primeiro em um único nó e, em seguida, nos nós abertos adjacentes, que, conforme discutido acima, dependerão do tamanho do Cluster de VMs do Autonomous Exadata.

Com base na utilização de recursos em cada nó; nem todos os valores das CPUs disponíveis podem ser usados para provisionar ou dimensionar Bancos de Dados Autônomos de IA. Por exemplo, suponha que você tenha 20 CPUs disponíveis no nível de AVMC. Nem todos os valores de 1 a 20 CPUs podem ser usados para provisionar ou dimensionar Autonomous AI Databases, dependendo da disponibilidade do recurso no nível do nó. A lista de valores de CPU que podem ser usados para provisionar ou dimensionar um Autonomous AI Database é chamada de CPUs provisionáveis.

Quando você tenta provisionar ou dimensionar um Autonomous AI Database na console do OCI, o campo CPU oferece uma lista drop-down com a lista de CPUs provisionáveis. Como alternativa, você pode usar as seguintes APIs para obter a lista de valores de CPU provisórios:

• GetAutonomousContainerDatabase retorna uma lista de valores de CPU provisionáveis que podem ser usados para criar um novo Autonomous AI Database no Autonomous Container Database fornecido. Consulte GetAutonomousContainerDatabase para obter mais detalhes.

• GetAutonomousDatabase retorna uma lista de valores de CPU provisionáveis que podem ser usados para dimensionar um determinado Autonomous AI Database. Consulte GetAutonomousDatabase para obter mais detalhes.

Conteúdo Relacionado

• Faturamento do Autonomous AI Database na Infraestrutura Dedicada do Exadata