Gestion du calcul dans une base de données d'IA autonome sur une infrastructure Exadata dédiée

Autonomous AI Database on Dedicated Exadata Infrastructure propose deux modèles de calcul lors de la configuration de vos ressources Autonomous AI Database. Il s'agit des suivantes :

• ECPU : une ECPU est une mesure abstraite des ressources de calcul. Les ECPU sont basées sur le nombre de coeurs alloués élastiquement à partir d'un pool de serveurs de calcul et d'un pool de stockage. Vous avez besoin d'au moins 2 ECPU pour provisionner une base de données d'IA autonome.

  Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et du redimensionnement des ressources d'UC d'une base de données existante, le nombre d'UC par défaut est de 2 ECPU, par incréments de 1. Par exemple, le prochain nombre d'ECPU disponibles au-dessus de 2 est 3.

  Vous pouvez créer des instances Autonomous AI Database for Developers sur des bases de données Conteneur basées sur ECPU. Ce sont des bases de données d'IA autonomes gratuites que les développeurs peuvent utiliser pour créer et tester de nouvelles applications. Pour plus d'informations, reportez-vous à Base de données IA autonome pour les développeurs.

• OCPU : une OCPU est une mesure physique des ressources de calcul. Les OCPU reposent sur le coeur physique d'un processeur avec hyperthread activé.

  Remarque : l'OCPU est une mesure de facturation héritée qui a été retirée pour Autonomous AI Database on Dedicated Exadata Infrastructure. Oracle recommande d'utiliser des ECPU pour tous les déploiements de base de données Autonomous AI nouveaux et existants. Pour plus d'informations, reportez-vous au document de support Oracle 2998755.1.

  Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et du redimensionnement des ressources d'UC d'une base de données existante :

  • Par défaut, le nombre d'UC est de 1 OCPU, par incrément de 1. Par exemple, le prochain nombre d'OCPU disponibles au-dessus de 1 est 2.

  • Pour les bases qui n'ont pas besoin d'une OCPU entière, vous pouvez affecter des OCPU de 0,1 à 0,9 par incrément de 0,1 OCPU, Cela vous permet de surprovisionner les UC et d'exécuter plus de bases de données sur chaque instance d'infrastructure. Pour plus de détails, reportez-vous à Surprovisionnement d'UC.

Le type de calcul du cluster de machines virtuelles Exadata Autonomous s'applique à toutes ses bases de données Conteneur Autonomous et à ses instances de base de données AI Autonomous.

Gestion de calcul

Les instances de base de données Autonomous AI sont déployées dans un cluster de machines virtuelles Autonomous Exadata et dans l'une de ses bases de données Conteneur Autonomous enfant. Les infrastructures Exadata peuvent exécuter plusieurs AVMC. Les UC que vous allouez lors du provisionnement d'une ressource AVMC seront le total des UC disponibles pour ses bases de données d'IA autonomes. Lorsque vous créez plusieurs cluster de machines virtuelles Autonomous, chacun d'eux peut disposer d'une valeur propre pour le total des CPU.

Plusieurs clusters de machines virtuelles Exadata Autonomous de machine virtuelle ne sont disponibles sur aucun déploiement Oracle Public Cloud des ressources d'infrastructure Exadata (EI) créées avant le lancement de la fonctionnalité de base de données d'IA Autonomous de plusieurs machines virtuelles. Pour la génération X8M et les ressources d'infrastructure Exadata supérieures créées après le lancement de la fonctionnalité AVMC multiple, chaque instance AVMC est créée avec un noeud de cluster pour chacun des serveurs de la forme de système Exadata que vous choisissez. Pour plus d'informations sur la limitation de ces CPU totales entre différents groupes d'utilisateurs, reportez-vous à Comment les quotas de compartiment affectent la gestion de la CPU.

Remarque : le nombre maximal de ressources AVMC et ACD que vous pouvez créer sur une infrastructure Exadata donnée varie en fonction de la génération de matériel. Pour plus de détails sur les contraintes de chaque génération, reportez-vous aux limites de ressource et aux caractéristiques des formes d'infrastructure.

Au niveau AVMC ou ACD, le nombre total d'UC disponibles pour la création des bases est appelé UC disponibles. Au niveau de la ressource AVMC, les CPU disponibles sont égales au nombre total de CPU jusqu'à ce que vous créiez la première base de données Conteneur Autonomous. Une fois que vous avez créé une base de données Conteneur Autonomous, 8 ECPU ou 2 OCPU par noeud sont alloués à la nouvelle base de données Conteneur Autonomous à partir des CPU disponibles d'AVMC. Ainsi, les CPU disponibles au niveau des ressources AVMC diminuent en conséquence. Lorsque vous créez la première base de données Autonomous AI dans cette base de données Conteneur Autonomous, la nouvelle base de données consomme les CPU initialement allouées (8 ECPU ou 2 OCPU par noeud). Si la nouvelle base de données a besoin de plus de 8 ECPU ou de 2 OCPU, elles sont affectées à partir des CPU disponibles de l'AVMC parent, en réduisant les CPU disponibles au niveau de l'AVMC parent. Lorsque vous créez d'autres bases de données Conteneur Autonomous et que vous provisionnez des bases de données Autonomous AI dans chaque base de données Conteneur Autonomous, la valeur d'UC disponible change en conséquence.

Les UC disponibles au niveau du cluster des machines virtuelles Exadata Autonomous s'appliquent à toutes ses bases de données Conteneur Autonomous. Le nombre d'UC disponibles pour la base de données Conteneur prend de l'intérêt si vous utilisez la fonctionnalité du redimensionnement automatique, tel que décrit dans Allocation d'UC lors du redimensionnement automatique.

De même, lorsque vous augmentez manuellement les CPU d'une base de données Autonomous AI, les CPU sont consommées à partir des CPU disponibles au niveau AVMC parent et leur valeur change en conséquence.

Lorsque vous créez une base de données Autonomous AI, Oracle réserve par défaut des CPU supplémentaires pour s'assurer que la base de données peut s'exécuter avec au moins 50 % de capacité, même en cas de panne de noeud. Vous pouvez modifier le pourcentage d'UC réservées sur les noeuds à 0 % ou 25 % lors du provisionnement d'une base de données Conteneur Autonomous. Pour obtenir des instructions, reportez-vous à Réservation de basculement de noeud dans Création d'une base de données Conteneur Autonomous. Ces CPU supplémentaires ne sont pas incluses dans la facturation.

Lorsqu'une base de données Autonomous AI est en cours d'exécution, le nombre d'UC actuellement allouées à la base de données vous est facturé, qu'elles soient indiquées lors de sa création ou ultérieurement par une opération de redimensionnement manuel. De plus, si la mise à l'échelle automatique est activée pour la base de données, toutes les UC supplémentaires que la base de données utilise suiteà une augmentation automatique vous sont facturées la seconde. Pour plus d'informations sur le mode de mesure et de calcul de la facturation, reportez-vous àDétails du calcul de la facturation des OCPU.

Lorsqu'une base de données Autonomous AI est arrêtée, vous n'êtes pas facturé. Toutefois, le nombre de CPU qui lui sont allouées n'est pas renvoyé aux CPU disponibles au niveau AVMC parent pour le déploiement global.

Lorsqu'une base de données Autonomous AI est arrêtée ou réduite, le nombre d'UC qui lui sont allouées n'est pas immédiatement renvoyé aux UC disponibles au niveau AVMC parent pour le déploiement global. Elles restent incluses dans le nombre d'UC disponibles pour sa base de données Conteneur parent jusqu'à ce que cette base de données Conteneur parent soit redémarrée. Ces CPU sont appelées CPU récupérables. Les CPU récupérables au niveau AVMC parent correspondent à la somme des CPU récupérables de toutes ses bases de données Conteneur Autonomous. Lorsqu'un ACD est redémarrée, elle renvoie toutes ses CPU récupérables vers les CPU disponibles au niveau de son cluster AVMC parent.

Le redémarrage d'une base de données Conteneur Autonomous est une opération en ligne, effectuée de manière non simultanée sur l'ensemble du cluster, qui n'entraîne pas de temps d'inactivité de l'application si elle est configurée conformément aux meilleures pratiques pour utiliser la continuité transparente des applications.

A savoir : Vous pouvez suivre les différents attributs de calcul abordés dans cet article à partir de la page Détails d'un cluster de machines virtuelles Exadata Autonomous ou d'une base de données Conteneur Autonomous. Pour plus d'informations, reportez-vous à la section Resource Usage Tracking.

Allocation d'OCPU lors du redimensionnement automatique

La fonction de redimensionnement automatique permet à une base de données Autonomous AI d'utiliser jusqu'à trois fois plus d'UC et de ressources d'E/S que le nombre d'UC alloué. En cas de surprovisionnement de la CPU, si trois fois le nombre de CPU aboutit à une valeur inférieure à 1, il sera arrondi au nombre entier suivant. Le surprovisionnement d'UC est pris en charge avec les OCPU uniquement. Pour plus d'informations, reportez-vous à Surprovisionnement d'UC.

Afin qu'aucune base de données d'IA autonome ne puisse se redimensionner automatiquement pour utiliser toutes les UC disponibles dans le pool pour le déploiement global, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure utilise la base de données Conteneur Autonomous comme contrôle de limitation.

Lors du provisionnement d'une base de données Autonomous AI activée pour le redimensionnement automatique dans une base de données Conteneur Autonomous, si les UC disponibles de cette base de données Conteneur Autonomous sont inférieures à 3 fois la valeur d'UC de la nouvelle base de données, des UC supplémentaires seront réservées dans cette base de données Conteneur Autonomous. Ces CPU sont appelées CPU réservées. Les CPU réservées garantissent que les CPU disponibles au niveau de la base de données Conteneur Autonomous sont toujours supérieures ou égales à 3 fois la valeur de la base de données activée pour le redimensionnement automatique la plus importante dans cette base de données Conteneur Autonomous. Ces CPU réservées peuvent toujours être utilisées pour créer ou redimensionner manuellement des bases de données Autonomous AI dans cette base de données Conteneur Autonomous.

Lors du redimensionnement automatique d'une base de données d'IA autonome, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure recherche les UC inactives dans sa base de données Conteneur parent. Si des CPU inactives sont disponibles, la base de données Autonomous AI est augmentée, sinon, elle n'est pas. Les bases de données présentent par nature de longs temps d'inactivité. Le redimensionnement automatique permet d'optimiser l'utilisation des ressources tout en contrôlant les coûts et en maintenant une bonne isolation par rapport aux bases de données d'autres bases de données Conteneur Autonomous.

Si l'UC utilisée pour redimensionner automatiquement une base de données d'IA autonome provient d'une autre base de données d'IA autonome en cours d'exécution qui est légèrement chargée et n'utilise donc pas toutes ses UC allouées, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure réduit automatiquement la base de données redimensionnée automatiquement si la charge augmente sur l'autre base de données et qu'elle a besoin de récupérer l'UC allouée.

Prenons l'exemple d'une base de données Conteneur autonome hébergeant quatre base de données Autonomous à 4 UC en cours d'exécution pour lesquelles le redimensionnement automatique est activé. Le nombre d'UC disponibles pour la base de données Conteneur à des fins de redimensionnement automatique est de12. Si l'une de ces bases de donnée doit être redimensionné automatiquement au-delà des 4 UC en raison d'une augmentation de charge, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée effectue uniquement l'opération de redimensionnement automatique si une ou plusieurs des autres bases de donnée sont légèrement chargées et n'utilisent pas toutes les UC allouées. Le coût de facturation de cet exemple est de l'ordre de 16 CPU au minimum, car les quatre bases de données de 4 CPU sont toujours en cours d'exécution.

En revanche, prenons l'exemple d'une base de données Conteneur Autonomous hébergeant quatre bases de données d'IA autonomes à 2 CPU, toutes avec le redimensionnement automatique activé, et une base de données d'IA autonome à 8 CPU arrêtée. Le nombre d'UC disponibles pour la base de données Conteneur à des fins de redimensionnement automatique est de nouveau de 16. Si l'une des bases de données en cours d'exécution doit être redimensionnée automatiquement en raison de l'augmentation de la charge sur les 2 dernières UC, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure peut effectuer l'opération à l'aide des UC allouées à la base de données à 8 UC arrêtée. Dans cet exemple, les quatre bases de données en exécution peuvent consommer jusqu'à 8 CPU supplémentaires simultanément sans consommer les CPU allouées les unes aux autres. Le coût de facturation de cet exemple est de seulement 8 CPU au minimum, car seules les quatre bases de donnée à 2 CPU sont toujours en cours d'exécution.

Pour toute instance de service Autonomous Data Guard, locale ou inter-région, la tarification supplémentaire correspond au nombre d'ECPU ou d'OCPU réservées lors de la création ou du redimensionnement explicite de l'instance de service principale, que le redimensionnement automatique soit activé ou non. La consommation d'OCPU ou d'ECPU liée au redimensionnement automatique sur les instances de service principales n'a pas lieu sur les instances de service de secours Autonomous Data Guard.

Impact des quotas de compartiment sur la gestion de l'UC

Normalement, lorsque vous créez ou augmentez une base de données d'IA autonome, la capacité d'Oracle Autonomous AI Database sur une infrastructure Exadata dédiée à répondre à votre demande dépend uniquement de la disponibilité d'UC non allouées dans le pool d'UC unique sur l'ensemble du déploiement.

Toutefois, vous pouvez utiliser la fonctionnalité de quotas de compartiment d'Oracle Cloud Infrastructure pour restreindre davantage, par compartiment, le nombre d'UC disponibles pour créer, redimensionner manuellement et redimensionner automatiquement les bases de données Autonomous AI de chaque type (Autonomous AI Lakehouse ou Autonomous AI Transaction Processing) individuellement.

En résumé, utilisez la fonctionnalité de quotas de compartiment en créant des instructions de stratégie set, unset et zero afin de limiter la disponibilité d'une ressource donnée dans un compartiment donné. Pour obtenir des informations et des instructions détaillées, reportez-vous à Quotas de compartiment.

Impact des noeuds de cluster de machines virtuelles sur la gestion de l'UC

Discussion précédente sur les états d'allocation et de gestion de l'UC permettant de créer plusieurs ressources de cluster de machines virtuelles Exadata Autonomous en choisissant le nombre d'UC par noeud lors du provisionnement de la ressource AVMC.

Cette section décrit en détail la façon dont Oracle Cloud Infrastructure place les bases de données AI autonomes dans les noeuds des clusters de machines virtuelles et les conséquences de ce placement sur le redimensionnement automatique et les traitements en parallèle.

Les attributs suivants déterminent quand et comment une base de données Autonomous AI est placée sur plusieurs noeuds :

• Seuil de fractionnement : valeur d'UC au-delà de laquelle Oracle Cloud Infrastructure ouvre une base de données d'IA autonome sur plusieurs noeuds. Le seuil de fractionnement par défaut est 64 pour les ECPU et 16 pour les OCPU. Toutefois, si les clusters de machines virtuelles sont créés avec un nombre de noeuds d'UC inférieur à la valeur par défaut, la valeur par défaut est remplacée par la taille du nombre de noeuds de cluster de machines virtuelles. Vous pouvez également définir la valeur de fractionnement explicitement à l'aide de l'attribut Seuil de fractionnement lors du provisionnement d'une base de données Conteneur Autonomous.

  Les bases de données Autonomous AI créées avec une valeur d'UC inférieure à la valeur de fractionnement s'ouvriront sur un noeud du cluster et celles créées avec une valeur d'UC supérieure à la valeur de seuil de fractionnement s'ouvriront sur plusieurs noeuds.

  • Supposons que vous créez une base de données Conteneur Autonomous avec un seuil de fractionnement par défaut (64 ECPU) dans une base de données Conteneur Autonomous avec deux noeuds et 40 ECPU par noeud. Comme la valeur 40 est inférieure à 64, toute base de données Autonomous AI dont les besoins en CPU sont supérieurs à 40 sera divisée et ouverte sur plusieurs noeuds, ce qui permettra d'effectuer des demandes LMD sur ces noeuds. Toutefois, si l'AVMC a été créé avec deux noeuds et 80 ECPU par noeud, toute base de données dont les besoins en ECPU sont supérieurs à 64 sera divisée et ouverte sur plusieurs noeuds.

  • Supposons que vous créez une base de données Conteneur Autonomous dans un cluster de machines virtuelles avec deux noeuds et 40 ECPU par noeud et définissez explicitement la valeur de seuil de fractionnement sur une valeur beaucoup plus petite, par exemple 20 ECPU. Toute base de données Autonomous AI dont les besoins en CPU sont supérieurs à 20 sera divisée et ouverte sur plusieurs noeuds, et les bases de données dont les besoins en CPU sont inférieurs à 20 seront ouvertes sur un seul noeud.

    La définition du seuil de fractionnement sur un nombre beaucoup plus petit que la valeur par défaut augmente les chances que les bases de données dont le nombre de CPU est inférieur s'ouvrent sur plusieurs noeuds, à condition que leur nombre de CPU soit supérieur à la valeur de fractionnement définie. Chaque fois qu'une base de données est créée ou redimensionnée à une taille supérieure à cette valeur de fractionnement, elle est ouverte sur plusieurs noeuds. Cela est utile lorsque vous voulez que les bases de données s'ouvrent sur plusieurs noeuds pour contrôler la dégradation des performances en cas de panne de noeud ou de maintenance planifiée. Avec des bases de données réparties entre plusieurs noeuds dans des clusters RAC plus volumineux, en cas de défaillance d'un noeud ou lors d'une maintenance programmée, vous pouvez continuer à bénéficier de performances supérieures au lieu de passer à un profil de performances de 50 %.

  • Supposons que vous définissiez explicitement le seuil de fractionnement sur une valeur beaucoup plus élevée que la valeur par défaut, par exemple 80 ECPU, dans un AVMC avec deux noeuds et 40 ECPU. Toute base de données Autonomous AI dont les besoins en CPU sont supérieurs à 40 sera divisée et ouverte sur plusieurs noeuds, et les bases de données dont les besoins en CPU sont inférieurs à 40 seront ouvertes sur un seul noeud.

    Si vous définissez le seuil de fractionnement sur une valeur beaucoup plus élevée que la valeur par défaut, l'instruction LMD (Langage de manipulation de données) de la base de données reste sur un noeud RAC unique et élimine les risques de contention d'attente de cluster.

  • Lorsque vous redimensionnez manuellement une base de données d'IA autonome, la nouvelle valeur d'UC est appliquée au modèle de fractionnement existant. Autrement dit, si la nouvelle valeur est inférieure au seuil de fractionnement, elle s'ouvre sur un noeud et si la valeur est supérieure au seuil de fractionnement, elle s'ouvre sur plusieurs noeuds.

• Affinité de distribution : détermine le nombre de noeuds sur lesquels une base de données Autonomous AI sera ouverte une fois qu'elle aura dépassé le seuil de fractionnement.

  Par exemple, supposons que vous ayez créé une ressource AVMC avec 4 noeuds et 80 ECPU par noeud et que vous ayez créé une base de données Conteneur Autonomous dans cette base de données Conteneur Autonomous avec le seuil de fractionnement de la base de données défini sur 64. La création d'une base de données Autonomous AI avec une exigence d'ECPU de 120 entraînera la division et l'ouverture de la base de données sur plusieurs noeuds, soit 120 de plus que 64 (seuil de fractionnement).

  • Si votre affinité de distribution est définie sur Nœuds minimum, Oracle Cloud Infrastructure tente de créer la base de données sur 2 noeuds avec 60 ECPU sur chaque noeud. Si cela n'est pas possible, il sera réparti sur 3 noeuds avec 40 ECPU chacun. Si cela n'est pas possible non plus, Oracle Cloud Infrastructure tente d'ouvrir la base de données sur 4 noeuds avec 30 ECPU chacun.

  • Si vous indiquez une affinité de distribution avec nombre maximal de noeuds, Oracle Cloud Infrastructure tente de créer la base de données répartie entre les 4 noeuds avec 30 ECPU chacun. Si cela n'est pas possible, il sera réparti sur trois noeuds avec 40 ECPU chacun. Si cela n'est pas possible non plus, Oracle Cloud Infrastructure tente d'ouvrir la base de données sur 2 noeuds avec 60 ECPU chacun.

• Réservation de basculement de noeud (%) : nombre d'UC mises de côté sur les noeuds adjacents (noeuds où le logiciel de base de données est présent mais pas ouvert) dans votre système AVMC pour les événements de maintenance et d'échec localisés. La réservation de basculement de noeud s'applique aux déploiements de base de données non fractionnés. Par défaut, il y a une réserve de 50 %, ce qui signifie que lors d'un événement d'échec ou d'une maintenance, vous continuerez à exécuter mais à 50 % de la CPU allouée.

  • Pour les bases de données ou les bases de données non critiques avec une utilisation très légère, vous pouvez définir la réservation de basculement de noeud sur une valeur inférieure afin de pouvoir créer et consolider un plus grand nombre de bases de données sur votre infrastructure Exadata dédiée.

  • Vous pouvez définir cette valeur sur zéro pour l'environnement de développement et les bases de données où un temps d'arrêt pendant la maintenance est acceptable.

  • Dans une certaine mesure, la réservation de basculement de noeud peut également être contrôlée en s'assurant qu'une base de données est répartie sur plus de 2 noeuds, à l'aide d'un seuil de fractionnement et d'une affinité de distribution. Imaginez un scénario dans lequel une base de données d'IA autonome est divisée en 4 noeuds. En supprimant un noeud à la fois en mode non simultané pendant qu'une activité de maintenance est en cours, vous disposez toujours de 3 noeuds toujours actifs et occupant du trafic, ce qui maintient votre réserve de performances de 75 % plutôt que les 50 % habituels. Avec des clusters plus grands, vous pouvez augmenter encore cette réserve, par exemple une réserve de 87,5 % sur un cluster à 8 noeuds.

La répartition de l'allocation d'UC d'une base de données Autonomous AI sur les noeuds d'un cluster d'unités virtuelles a un impact sur les opérations suivantes :

• Redimensionnement automatique:

  • Le redimensionnement automatique peut se produire au sein d'un seul noeud de cluster de machines virtuelles pour les opérations LMD non parallélisables et entre les noeuds de cluster de machines virtuelles si les opérations LMD sont parallélisables.

  • Plusieurs sessions simultanées avec des requêtes non parallélisables peuvent être acheminées vers tous les noeuds du cluster, ce qui permet le redimensionnement automatique sur tous les noeuds d'une base de données à plusieurs noeuds.

• Traitement en parallèle:

  • Le traitement parallèle des instructions SQL se produit au sein des noeuds de cluster de machines virtuelles Exadata Autonomous ouverts, d'abord au sein d'un noeud unique, puis dans les noeuds ouverts adjacents, ce qui, comme indiqué ci-dessus, dépend de la taille du cluster de machines virtuelles Exadata Autonomous.

En fonction de l'utilisation des ressources sur chaque noeud, toutes les valeurs des UC disponibles Ne peuvent pas être utilisées pour provisionner ou redimensionner des bases de données autonomes AI. Par exemple, si vous avez 20 UC disponibles au niveau d'AVMC, toutes les valeurs comprises entre 1 et 20 UC Ne peuvent pas être utilisées pour provisionner ou redimensionner les bases de données autonomes en fonction de la disponibilité de ressources au niveau du noeud. La liste des valeurs d'UC pouvant être utilisées pour provisionner ou redimensionner une base de données d'IA autonome est appelée UC provisionnables.

Lorsque vous tentez de provisionner ou de redimensionner une base de données d'IA autonome à partir de la console OCI, le champ UC vous fournit une liste déroulante avec la liste des UC provisionnables. Vous pouvez également utiliser les API suivantes pour obtenir la liste des valeurs d'UC provisoires :

• GetAutonomousContainerDatabase renvoie la liste des valeurs d'UC pouvant être provisionnées pouvant être utilisées pour créer une base de données d'IA autonome dans la base de données Conteneur Autonomous indiquée. Pour plus d'informations, reportez-vous à GetAutonomousContainerDatabase.

• GetAutonomousDatabase renvoie la liste des valeurs d'UC pouvant être provisionnées qui peuvent être utilisées pour le redimensionnement d'une base de données d'IA autonome donnée. Pour plus d'informations, reportez-vous à GetAutonomousDatabase.

Contenu connexe

• Facturation d'une base de données d'IA autonome sur une infrastructure Exadata dédiée