Gestión de recursos informáticos en base de datos de IA autónoma en infraestructura de Exadata dedicada

Autonomous AI Database on Dedicated Exadata Infrastructure ofrece dos modelos informáticos al configurar los recursos de Autonomous AI Database. Son las siguientes:

  • ECPU: una ECPU es una medida abstracta de los recursos informáticos. Las ECPU se basan en el número de núcleos elásticamente asignados de un pool de servidores informáticos y de almacenamiento. Necesita al menos 2 ECPU para aprovisionar una base de datos de IA autónoma.

    Durante el aprovisionamiento de una nueva base de datos, la clonación de una base de datos existente, y la ampliación o reducción vertical de los recursos de CPU de una base de datos existente, el recuento de CPU se define por defecto en 2 ECPU, en incrementos de 1. Por ejemplo, el siguiente número disponible de ECPU por encima de 2 es 3.

    Puede crear instancias de Autonomous AI Database for Developers en bases de datos de contenedores basadas en ECPU. Son base de datos de IA autónoma gratuitas que los desarrolladores pueden utilizar para crear y probar nuevas aplicaciones. Consulte Base de datos de IA autónoma para desarrolladores para obtener más información.

  • OCPU: una OCPU es una medida física de recursos informáticos. Las OCPU se basan en el núcleo físico de un procesador con hyperthreading activado.

    Note:

    OCPU es una métrica de facturación heredada y se ha retirado para la base de datos de IA autónoma en infraestructura de Exadata dedicada. Oracle recomienda utilizar ECPU para todos los despliegues de base de datos de IA autónoma nuevos y existentes. Consulte el documento de soporte de Oracle 2998755.1 para obtener más información.

    Al aprovisionar una nueva base de datos, clonar una base de datos existente, y escalar o reducir verticalmente los recursos de CPU de una base de datos existente:

    • El recuento de CPU se define por defecto en 1 OCPU, en incrementos de 1. Por ejemplo, el siguiente número disponible de OCPU por encima de 1 es 2.
    • Para las bases de datos que no necesitan una OCPU completa, puede asignar OCPU de 0,1 a 0,9 en incrementos de 0,1 OCPU. Esto permite sobreaprovisionar la CPU y ejecutar más bases de datos en cada instancia de infraestructura. Consulte Sobreaprovisionamiento de CPU para obtener más detalles.

El tipo de cálculo del cluster de VM de Exadata autónomo se aplica a todas sus bases de datos de contenedores autónomas e instancias de base de datos de IA autónoma.

Temas relacionados

Gestión de instancias informáticas

Las instancias de base de datos de IA autónoma se despliegan en un cluster de VM de Exadata autónomo (AVMC) y en una de sus bases de datos de contenedores autónomas (ACD) secundarias. Las infraestructuras de Exadata pueden ejecutar varios AVMC. Las CPU que asigne al aprovisionar un recurso de AVMC serán las CPU totales disponibles para sus base de datos de IA autónoma. Al crear varios AVMC, cada AVMC puede tener su propio valor para el total de CPU.

Varios clusters de VM de Exadata autónomos de VM no están disponibles en ningún despliegue de Oracle Public Cloud de recursos de infraestructura de Exadata (EI) creado antes del inicio de la función de base de datos de IA autónoma de varias VM. Para la generación de X8M y los recursos de infraestructura de Exadata superiores creados después del inicio de la función Varios AVMC, cada AVMC se crea con un nodo de cluster para cada uno de los servidores de la unidad de sistema de Exadata que elija. Para obtener información sobre la restricción de estas CPU totales en diferentes grupos de usuarios, consulte How Compartment Quotas Affect CPU Management.

Note:

El número máximo de recursos de AVMC y ACD que puede crear en una infraestructura de Exadata determinada varía en función de la generación de hardware. Consulte Límites de recursos y Características de las unidades de infraestructura para obtener más información sobre las restricciones de cada generación.

A nivel de AVMC o de ACD, el número total de CPU disponibles para crear bases de Datos se denomina CPU disponibles. En el nivel del recurso de AVMC, las CPU disponibles serán iguales al total de CPU hasta que cree la primera ACD. Una vez creada una base de datos de contenedor automática, de 8 ECPU o 2 OCPU por nodo se asignan a la nueva ACD a partir de las CPU disponibles del AVMC. Por lo tanto, las CPU disponibles en el nivel del recurso de AVMC disminuyen de la forma correspondiente. Al crear la primera base de datos de IA autónoma en esa ACD, la nueva bases de datos consume las OCPU asignadas inicialmente (8 ECPU o 2 OCPU por nodo). Si la nueva base de datos necesita más de8 ECPU o 2 OCPU, se asignan desde las CPU disponibles del AVMC principal, reduciendo las CPU disponibles en el nivel de AVMC principal. A medida que crea más ACD y aprovisiona las base de datos de IA autónoma dentro de cada ACD, el valor de CPU disponible cambia en consecuencia.

Las CPU disponibles en el nivel de cluster de VM de Exadata autónomo se aplican a todas sus bases de datos de contenedores autónomas. Este recuento de CPU disponibles para la base de datos de contenedores cobra importancia si utiliza la función de escala automática, como se describe en Asignación de CPU durante la escala automática.

Del mismo modo, al escalar manualmente las CPU de una base de datos de IA autónoma hacia arriba, las CPU se consumen de las CPU disponibles en su nivel de AVMC principal y su valor cambia según corresponda.

Cuando crea una base de datos de IA autónoma, Oracle reserva por defecto CPU adicionales para garantizar que la base de datos pueda ejecutarse con al menos un 50 % de capacidad incluso en caso de fallos de algún nodo. Puede cambiar el porcentaje de CPU reservadas en los nodos al 0 % o al 25 % al aprovisionar una ACD. Consulte Reserva de failover de nodo en Creación de una base de datos de contenedores autónoma para obtener instrucciones. Estas CPU adicionales no están incluidas en la facturación.

Cuando se ejecuta una base de datos de IA autónoma, se le factura el número de CPU actualmente asignadas a la base, tanto si se ha especificado en la creación inicial o posteriormente mediante una operación de escala manual. Además, si la escalabilidad automática está activada para la base datos, se le facturará cada segundo de todas las CPU adicionales de la base que esté utilizando como resultado de la escalada vertical automática. Para obtener más información sobre cómo se mide y calcula la facturación, consulte Detalles de facturación de CPU.

Cuando se parauna base de datos de IA autónoma, no se le factura. Sin embargo, el número de CPU que tiene asignadas no se devuelve a las CPU disponibles en su nivel de AVMC principal para el despliegue general.

Cuando se termina o se reduce verticalmente una base de datos de IA autónoma, el número de CPU que tiene asignadas no se devuelve inmediatamente a las CPU disponibles en el nivel de su AVMC principal para el despliegue general. Se siguen incluyendo en el recuento de CPU disponibles para su base de datos principal de contenedores hasta que se reinicie dicha base de datos principal de contenedores. Estas CPU se denominan CPU reclamables. Las CPU reclamables en el nivel de AVMC principal son la suma de las CPU reclamables de todas sus ACD. Cuando se reinicia una ACD, esta devuelve todas sus CPU reclamables a las CPU disponibles en su nivel del AVMC principal.

El reinicio de una base de datos de contenedores autónoma (ACD) es una operación en línea, realizada de forma sucesiva en todo el cluster y no generará tiempo de inactividad de la aplicación si se configura de acuerdo con las mejores prácticas para utilizar la continuidad de aplicaciones transparente.

Sugerencia:

Puede realizar un seguimiento de los diferentes atributos de recursos informáticos (CPU) que se tratan en este artículo desde la página Detalles de un cluster de VM de Exadata autónomo (AVMC) o una base de datos de contenedores autónoma (ACD). Para obtener instrucciones, consulte Seguimiento del uso de recursos.

Asignación de CPU durante la escala automática

La función de escala automática permite que una base de datos de IA autónoma utilice hasta tres veces más recursos que el recuento de CPU y E/S que tiene asignado. En caso de sobreaprovisionamiento de CPU, si el recuento de CPU resulta en un valor inferior a 1 tres veces, se redondeará al siguiente número entero. El sobreaprovisionamiento de CPU solo está soportado con OCPU. Consulte Sobreaprovisionamiento de CPU para obtener más información.

Para garantizar que ninguna base de datos de IA autónoma pueda escalarse automáticamente para consumir todas las CPU disponibles en el pool para el despliegue general, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure utiliza la base de datos de contenedores autónoma como control limitante.

Al aprovisionar una base de datos de IA autónoma activada para escala automática en una base de datos de contenedor autónoma, si las CPU disponibles en esa base de datos de contenedor autónoma son inferiores al valor de CPU 3X de la nueva base de datos, se reservarán CPU adicionales en esa base de datos de contenedor autónoma. Estas CPU se denominan CPU reservadas. Las CPU reservadas garantizan que las CPU disponibles en un nivel de ACD siempre sean mayores o iguales que el valor de CPU 3x de la base de datos con mayor capacidad de escala automática activada en esa ACD. Estas CPU reservadas aún se pueden utilizar para crear o escalar manualmente base de datos de IA autónoma en esta ACD.

Al escalar automáticamente una base de datos de IA autónoma, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure busca CPU inactivas en su base de datos de contenedores principal. Si hay CPU inactivas disponibles, la base de datos de IA autónoma se escalará verticalmente; en caso contrario, no se escalará. Las bases de datos tienen de forma inherente mucho tiempo de inactividad, por lo que la escala automática es una forma de maximizar el uso de los recursos al tiempo que se controlan los costos y se mantiene un buen aislamiento de las bases de datos de otras bases de datos de contenedores autónomas.

Si la CPU utilizada para escalar automáticamente una base de datos de IA autónoma proviene de otra base de datos de IA autónoma en ejecución que está ligeramente cargada y, por lo tanto, no está utilizando todas sus CPU asignadas, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure escala automáticamente la base de datos escalada automáticamente hacia abajo si la carga aumenta en la otra base de datos y necesita su CPU asignada de vuelta.

Considere el ejemplo de una base de datos de contenedor autónoma que aloje cuatro base de datos de IA autónoma de 4 CPU en ejecución, todas con la escala automática activada. El recuento de CPU disponibles para la base de datos del contenedor con fines de escala automática es 12. Si una de estas base de datos necesita que se escale de manera automática más allá de las 4 CPU debido a que se aumenta la carga, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure solo realizará la operación de escalado automático si una o más de las otras base de datos tienen carga ligera y no utilizan todas las CPU asignadas. El costo de facturación de este ejemplo son de 16 CPU como mínimo porque las cuatro bases de Datos de 4 CPU siempre están en ejecución.

Por el contrario, considere el ejemplo de una base de datos de contenedores autónoma que aloja cuatro base de datos de IA autónoma de 2 CPU, todas ellas con escala automática activada y una base de datos de IA autónoma de 8 CPU parada. El recuento de CPU disponibles para la base del contenedor con fines de escala automática es nuevamente de 16. En caso de que una de las bases de datos en ejecución deba escalarse automáticamente debido a un aumento de carga de más de 2 CPU, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure puede realizar la operación mediante CPU asignadas a la base de datos de 8 CPU parada. En este ejemplo, las cuatro base de datos en ejecución pueden consumir hasta un total de 8 CPU adicionales a la vez sin consumir las CPU asignadas a la otra. El costo de facturación de este ejemplo es solo de 8 CPU como mínimo porque solo las cuatro bases de dato de 2 CPU están siempre en ejecución.

Para cualquier instancia de servicio de Autonomous Data Guard, local o entre regiones, el precio adicional será el número de ECPU u OCPU que haya reservado al crear o escalar explícitamente su instancia de servicio principal, independientemente de si la escala automática está activada o no. El consumo de ECPU u OCPU relacionado con la escala automática en instancias de servicio principales no se produce en instancias de servicio de Autonomous Data Guard en espera.

Cómo afectan las cuotas de compartimento a la gestión de CPU

Normalmente, al crear o escalar verticalmente una base de datos de IA autónoma, la capacidad de Oracle Autonomous AI Database on Dedicated Exadata Infrastructure para satisfacer su solicitud depende solo de la disponibilidad de CPU no asignadas en el único pool de CPU en todo el despliegue.

Sin embargo, puede utilizar la función de cuotas del compartimento de Oracle Cloud Infrastructure para restringir aún más, en compartimento por compartimento, el número de CPU disponibles para crear, ampliar y escalar automáticamente base de datos de IA autónoma de cada tipo de carga de Trabajo (Autonomous AI Lakehouse o Autonomous AI Transaction Processing) de forma individual.

En resumen, puede utilizar la función de cuotas de compartimento mediante la creación de sentencias de política set, unset y zero para limitar la disponibilidad de un recurso determinado en un compartimento determinado. Para obtener más información e instrucciones, consulte Cuotas de compartimento.

Cómo afectan los nodos de cluster de máquina virtual a la gestión de CPU

En el análisis anterior de la gestión y asignación de CPU, se indica que puede crear varios recursos de cluster de VM de Exadata autónomo (AVMC) seleccionando el recuento de CPU por nodo al aprovisionar el recurso de AVMC.

En esta sección se analizará de forma pormenorizada cómo coloca Oracle Cloud Infrastructure bases de datos de Autonomous AI Database en los nodos de cluster de VM y las consecuencias de dicha colocación en la escalabilidad automática y en el procesamiento paralelo.

Los siguientes atributos determinan cuándo y cómo se coloca una base de datos de IA autónoma en varios nodos:

  • Umbral dividido: valor de CPU más allá del cual Oracle Cloud Infrastructure abre una base de datos de IA autónoma en varios nodos. El umbral de división por defecto es 64 para las ECPU y 16 para las OCPU, pero si los clusters de VM se crean con recuentos de nodos de CPU por debajo del valor por defecto, el valor por defecto se sustituye por el tamaño de recuento de nodos de cluster de VM.También puede definir el valor de división explícitamente mediante el atributo Umbral de división al aprovisionar una base de datos de contenedores autónoma (ACD).

    Las base de datos de IA autónoma creadas con un valor de CPU menor que el valor de división se abrirán en un nodo del cluster y las creadas con un valor de CPU mayor que el valor de umbral de división se abrirán en varios nodos.

    • Supongamos que crea una ACD con un umbral de división predeterminado (64 ECPU) en un AVMC con dos nodos y 40 ECPU por nodo. Dado que 40 es menor que 64, cualquier base de datos de IA autónoma con un requisito de CPU mayor que 40 se dividirá y abrirá en varios nodos, lo que permitirá las solicitudes DML en esos nodos. Sin embargo, si el AVMC se creó con dos nodos y 80 ECPU por nodo, cualquier base de datos con un requisito de ECPU superior a 64 se dividirá y abrirá en varios nodos.

    • Supongamos que crea una ACD en un cluster de VM con dos nodos y 40 ECPU por nodo y establece explícitamente el valor del umbral de división en un valor mucho menor, por ejemplo, 20 ECPU. Cualquier base de datos de IA autónoma con un requisito de CPU superior a 20 se dividirá y abrirá en varios nodos, y las bases de datos con un requisito de CPU inferior a 20 se abrirán en un solo nodo.

      La definición del umbral de división en un número mucho menor que el valor por defecto aumenta las posibilidades de que las bases de datos con recuentos de CPU más pequeños se abran en varios nodos, siempre que su recuento de CPU sea mayor que el valor de división definido. Cada vez que se crea o escala una base de datos a un tamaño mayor que este valor de división, se abre en varios nodos. Esto resulta útil cuando desea que las bases de datos se abran en varios nodos para controlar la degradación del rendimiento en caso de fallo de un nodo o mantenimiento planificado. Con las bases de datos divididas en varios nodos en clusters de RAC más grandes, si falla algún nodo o cuando se produce el mantenimiento programado, puede seguir teniendo un mayor rendimiento en lugar de degradarse a un perfil de rendimiento del 50%.

    • Supongamos que configura explícitamente el umbral de división en un valor mucho mayor que el valor predeterminado, por ejemplo, 80 ECPU, en un AVMC con dos nodos y 40 ECPU. Cualquier base de datos de IA autónoma con un requisito de CPU superior a 40 se dividirá y abrirá en varios nodos, y las bases de datos con un requisito de CPU inferior a 40 se abrirán en un solo nodo.

      La definición del umbral de división en un valor mucho mayor que el valor por defecto hace que el DML de la base de datos permanezca en un único nodo RAC y elimine la posibilidad de contención de espera de cluster.

    • Al escalar manualmente una base de datos de IA autónoma, el nuevo valor de CPU se aplicará al modelo de división existente. Es decir, si el nuevo valor es menor que el umbral de división, se abrirá en un nodo y si el valor es mayor que el umbral de división, se abrirá en varios nodos.

  • Afinidad de distribución: determina el número de nodos en los que se abrirá una base de datos de IA autónoma una vez que cruce el umbral de división.

    Por ejemplo, supongamos que ha creado un recurso de AVMC con 4 nodos y 80 ECPU por nodo, y ha creado una ACD en este AVMC con el umbral de división de base de datos definido en 64. La creación de una base de datos de IA autónoma con un requisito de ECPU de 120 dividirá y abrirá la base de datos en varios nodos como 120 mayor que 64 (Umbral de división).

    • Si la afinidad de distribución se define en Nodos mínimos, Oracle Cloud Infrastructure intenta crear la base de datos en 2 nodos con 60 ECPU en cada nodo. Si esto no es posible, se dividirá en 3 nodos con 40 ECPU cada uno. Si eso tampoco es posible, Oracle Cloud Infrastructure intentará abrir la base de datos en 4 nodos con 30 ECPU cada uno.

    • Si especifica la afinidad de distribución en Máximo de nodos, Oracle Cloud Infrastructure intenta crear la base de datos dividida en los 4 nodos con 30 ECPU cada uno. Si esto no es posible, se dividirá en tres nodos con 40 ECPU cada uno. Si eso tampoco es posible, Oracle Cloud Infrastructure intentará abrir la base de datos en 2 nodos con 60 ECPU cada uno.

  • Reserva de failover de nodo (%): número de CPU reservadas en nodos adyacentes (nodos en los que el software de base de datos está presente pero no abierto) en AVMC para eventos de mantenimiento y fallos localizados. La reserva de failover de nodo se aplica a despliegues de base de datos que no son de división.Por defecto, hay una reserva del 50%, lo que significa que durante un evento de fallo o mantenimiento, seguirá ejecutándose, pero en el 50% de la CPU asignada.

    • Para bases de datos no críticas o con un uso muy ligero, puede definir la reserva de failover de nodo en un valor menor para que, al final, pueda crear y consolidar un mayor número de bases de datos en la infraestructura de Exadata dedicada.

    • Puede definir este valor en cero para el entorno de desarrollo y las bases de datos en las que se acepta un tiempo de inactividad durante el mantenimiento.

    • Hasta cierto punto, la reserva de failover de nodo también se puede controlar asegurándose de que una base de datos se divida en más de 2 nodos, utilizando el umbral de división y la afinidad de distribución.Considere un escenario en el que una base de datos de IA autónoma se divida en 4 nodos. Al eliminar un nodo a la vez de forma sucesiva mientras una actividad de mantenimiento está en curso, siempre tiene 3 nodos activos y ocupando tráfico, manteniendo su reserva de rendimiento de manera efectiva el 75%, en lugar del 50% habitual. Con clusters más grandes, puede aumentar aún más esta reserva, por ejemplo, una reserva del 87,5% en un cluster de 8 nodos.
La distribución de la asignación de CPU de una base de datos de IA autónoma entre los nodos del clúster de VM afecta a las siguientes operaciones:
  • Escala automática:
    • La escala automática se puede producir en un único nodo de cluster de VM para DML no paralelizable y entre nodos de cluster de VM si el DML es paralelizable.
    • Se pueden enrutar varias sesiones simultáneas con consultas no paralelizables a todos los nodos del cluster, lo que permite la escala automática en todos los nodos de una base de datos de varios nodos.
  • Procesamiento Paralelo:
    • El procesamiento paralelo de sentencias SQL se produce en los nodos de cluster de VM de Exadata autónomo que están abiertos, primero en un solo nodo y, a continuación, en los nodos abiertos adyacentes, que, como se ha explicado anteriormente, dependerán del tamaño del cluster de VM de Exadata autónomo.

Según la utilización de recursos en cada nodo; no todos los valores de las CPU disponibles se pueden utilizar para aprovisionar o escalar las base de datos de IA autónoma. Por ejemplo, supongamos que tiene 20 CPU disponibles en el nivel del AVMC. No todos los valores de 1 a 20 CPU se pueden utilizar para aprovisionar o escalar las instancias de la base de datos de IA autónoma en función de la disponibilidad del recurso en el nivel del nodo. La lista de valores de CPU que se pueden utilizar para aprovisionar o escalar una base de datos de IA autónoma se denomina CPU que permiten aprovisionamiento.

Al intentar aprovisionar o escalar una base de datos de IA autónoma desde la consola de OCI, el campo CPU le proporcionará una lista desplegable con la lista de CPU aprovisionables. También puede utilizar las siguientes API para obtener la lista de valores de CPU provisionales:

  • GetAutonomousContainerDatabase devuelve una lista de valores de CPU aprovisionables que se pueden utilizar para crear una nueva base de datos de IA autónoma en la base de datos de contenedores autónoma determinada. Consulte GetAutonomousContainerDatabase para obtener más información.

  • GetAutonomousDatabase devuelve una lista de valores de CPU que pueden aprovisionarse y que se pueden utilizar para escalar una base de datos de IA autónoma determinada. Consulte GetAutonomousDatabase para obtener más información.