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

La base de datos de IA autónoma en una infraestructura de Exadata dedicada ofrece dos modelos informáticos mientras configura sus recursos de base de datos de IA autónoma. 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.

Al aprovisionar una nueva base a datos, clonar una existente y escalar o reducir verticalmente los recursos de CPU de una base a 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 bases de datos de IA autónomas 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.

Nota: OCPU es una métrica de facturación heredada y se ha retirado para Autonomous AI Database on Dedicated Exadata Infrastructure. Oracle recomienda utilizar ECPU para todas las implementaciones de bases de datos de IA autónomas nuevas 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 que no necesitan una OCPU completa, puede asignar las 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 información.

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.

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 bases de datos de IA autónomas. 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 recursos de infraestructura de Exadata (EI) de Oracle Public Cloud 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 del sistema de Exadata que elija. Para obtener información sobre la restricción de estas CPU totales en diferentes grupos de usuarios, consulte Cómo afectan las cuotas de compartimentos a la gestión de CPU.

Nota: 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 los límites de recursos y las características de las unidades de infraestructura para obtener más información sobre las restricciones de cada generación.

En un 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 instancia de Autonomous AI Database en ese ACD, la nueva base datos consume las OCPU asignadas inicialmente (8 ECPU o 2 OCPU por nodo). Si la nueva base de datos necesita más de 8 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 bases de datos de IA autónomas en cada ACD, el valor de CPU disponible cambia en consecuencia.

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

Del mismo modo, al escalar manualmente las CPU de una base de datos de IA autónoma, 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 instancia de Autonomous AI Database, se le factura el número de CPU actualmente asignadas a la base, tanto si se lo 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, se le facturará cada segundo de todas las CPU adicionales de la base que esté utilizando como resultado del escalado vertical automático. 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 para una 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 del contenedor principal hasta que se reinicie dicha base de datos del contenedor principal. 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 bases de datos de contenedor autónomas. 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 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.

Consejo: puede realizar un seguimiento de los diferentes atributos 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 orientación, consulte Seguimiento del uso de recursos.

Asignación de CPU durante la escala automática

La función de escala automática permite a la base de datos de IA autónoma utilizar 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 tienen menos de 3 veces el valor de CPU 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 3 veces el valor de CPU 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 bases de datos de IA autónomas en esta ACD.

Al escalar automáticamente una base de datos de IA autónoma, Oracle Autonomous AI Database en infraestructura de Exadata dedicada 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 de escala automática hacia abajo si la carga aumenta en la otra base de datos y necesita su CPU asignada nuevamente.

Considere el ejemplo de una base de datos de contenedores autónoma en la que se alojan cuatro instancias de bases de datos de IA autónomas 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 bases se debe escalar automáticamente después de las 4 CPU debido al aumento de carga, Oracle Autonomous AI Database en una infraestructura de Exadata dedicada solo realizará la operación de escalado automático si una o más de las otras bases se cargan ligeramente 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 bases de datos de IA autónomas de 2 CPU, todas ellas con escala automática activada y una base de datos de IA autónoma de 8 CPU detenida. 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 se deba escalar 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 Datos de 2 CPU están siempre en ejecución.

Para cualquier instancia de servicio de Autonomous Data Guard, local o entre regiones, los precios adicionales serán el número de ECPU u OCPU que haya reservado al crear o escalar explícitamente la 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 las instancias de servicio principales no se produce en las instancias de servicio de Autonomous Data Guard en espera.

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

Normalmente, cuando crea o escala 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 compartimentos, el número de CPU disponibles para crear, ampliar y escalar automáticamente bases de datos de IA autónomas 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 VM a la gestión de CPU

En el análisis anterior sobre 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 Oracle Cloud Infrastructure coloca las bases de datos de IA autónomas en los nodos del 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 de división: 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 bases de datos de IA autónomas 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. Como 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 configuración del umbral de división en un número mucho menor que el valor predeterminado 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 se 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 se 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 bases de datos divididas en varios nodos en clusters de RAC más grandes, si falla cualquier nodo o cuando se produce un mantenimiento programado, puede seguir teniendo un mayor rendimiento en lugar de degradarlo 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.
  
  Si se define el umbral de división en un valor mucho más alto que el valor por defecto, el DML de la base de datos permanecerá en un único nodo de RAC y eliminará 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 está definida 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 a Máximo de nodos, Oracle Cloud Infrastructure intenta crear la división de la base de datos 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 la base de datos está presente pero no abierto) en el AVMC para eventos de mantenimiento y fallos localizados. La reserva de failover de nodo se aplica a despliegues de base de datos que no sean 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 al 50% de la CPU asignada.
- Para bases de datos no críticas o bases de datos 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 su 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 divide 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 en nodos de cluster de VM si el DML se puede paralelizar.
- Se pueden enrutar varias sesiones simultáneas con consultas no paralelas 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 dentro de un único nodo y, a continuación, en los nodos abiertos adyacentes, lo que, como se ha explicado anteriormente, dependerá del tamaño del cluster de VM de Exadata autónomo.

Según el uso de recursos en cada nodo; no todos los valores de las CPU disponibles se pueden utilizar para aprovisionar o escalar bases de datos de IA autónomas. Por ejemplo, supongamos que tiene 20 CPU disponibles en el nivel de AVMC, no todos los valores de 1 a 20 CPU se pueden utilizar para aprovisionar o escalar bases de datos de IA autónomas según la disponibilidad de recursos en el nivel de 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 aprovisionar.

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 una instancia de 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.

Contenido relacionado

Base de datos de IA autónoma de facturación en infraestructura de Exadata dedicada