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

Une base de données d'IA autonome sur une infrastructure Exadata dédiée offre deux modèles de calcul lors de la configuration de vos ressources de base de données d'IA autonome. Il s'agit de :

ECPU : Une ECPU est une mesure abstraite des ressources de calcul. Les ECPU sont basées sur le nombre de coeurs affectés de manière élastique à partir d'un groupe de serveurs de calcul et de stockage. Vous avez besoin d'au moins 2 ECPU pour provisionner une base de données IA autonome.

Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et de l'augmentation ou de la réduction 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 nombre d'ECPU suivant disponible au-dessus de 2 est de 3.

Vous pouvez créer des instances Autonomous AI Database for Developers sur des bases de données conteneur basées sur ECPU. Il s'agit de bases de données autonomes gratuites que les développeurs peuvent utiliser pour créer et tester de nouvelles applications. Pour plus de détails, voir Autonomous AI Database pour les développeurs.
OCPU : Une OCPU est une mesure physique des ressources de calcul. Les OCPU sont basées sur le coeur physique d'un processeur avec la technologie Hyperthread.

Note : L'OCPU est une mesure de facturation existante et a été retirée pour une base de données d'intelligence artificielle autonome sur une infrastructure Exadata dédiée. Oracle recommande d'utiliser des ECPU pour tous les déploiements de base de données d'IA autonome, nouveaux ou existants. Pour plus d'informations, voir Oracle Support Document 2998755.1.

Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et de l'augmentation ou de la réduction des ressources d'UC d'une base de données existante :
- Le nombre d'UC par défaut est de 1 OCPU, par incréments de 1. Par exemple, le nombre suivant d'OCPU disponibles au-dessus de 1 est de 2.
- Pour les bases de données qui n'ont pas besoin d'une OCPU entière, vous pouvez affecter des OCPU de 0,1 à 0,9 par incréments de 0,1 OCPU. Cela vous permet d'effectuer un surprovisionnement d'UC et d'exécuter plus de bases de données sur chaque instance d'infrastructure. Pour plus de détails, consultez Surprovisionnement d'UC.

Le type de calcul de la grappe de machines virtuelles Exadata autonome s'applique à toutes ses bases de données conteneur autonomes et à ses instances de base de données avec intelligence artificielle autonome.

Gestion des calculs

Les instances de base de données d'IA autonome sont déployées dans une grappe de machines virtuelles Exadata autonome (AVMC) et dans l'une de ses bases de données conteneur autonomes enfants. Les infrastructures Exadata peuvent exécuter plusieurs machines virtuelles autonomes. Les UC que vous affectez lors du provisionnement d'une ressource AVMC seront le total des UC disponibles pour ses bases de données autonomes d'IA. Lorsque vous créez plusieurs machines virtuelles autonomes, chaque machine virtuelle autonome peut avoir sa propre valeur pour le nombre total d'UC.

La grappe de machines virtuelles Exadata autonome sur plusieurs machines virtuelles n'est disponible dans aucun déploiement Oracle Public Cloud des ressources d'infrastructure Exadata créées avant le lancement de la fonction Base de données d'intelligence artificielle autonome sur 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 fonction Multiple AVMC, chaque AVMC est créée avec un noeud de grappe pour chacun des serveurs de la forme de système Exadata que vous choisissez. Pour plus d'informations sur la limitation de ces UC totales entre différents groupes d'utilisateurs, voir Incidence des quotas de compartiment sur la gestion d'UC.

Note : 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. Reportez-vous aux sections Limites de ressource et Caractéristiques des formes d'infrastructure pour plus de détails sur les contraintes pour chaque génération.

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

Les UC disponibles au niveau de la grappe de machines virtuelles Exadata autonome s'appliquent à toutes ses bases de données conteneur autonomes. Ce nombre d'UC disponibles pour la base de données conteneur devient important si vous utilisez la fonction d'ajustement automatique, comme décrit dans Affectation d'UC lors de l'ajustement automatique.

De même, lorsque vous ajustez manuellement les UC d'une base de données d'IA autonome vers le haut, les UC sont consommées à partir des UC disponibles à leur niveau AVMC parent et leur valeur change en conséquence.

Lorsque vous créez une base de données autonome d'IA, Oracle réserve par défaut des UC supplémentaires pour garantir que la base de données puisse s'exécuter avec une capacité d'au moins 50 %, même en cas de défaillance d'un noeud. Vous pouvez modifier le pourcentage d'UC réservées entre les noeuds à 0 % ou à 25 % lors du provisionnement d'une base de données conteneur autonome. Voir Réservation pour le basculement de noeud dans Créer une base de données conteneur autonome pour obtenir des instructions. Ces UC supplémentaires ne sont pas incluses dans la facturation.

Lorsqu'une base de données d'IA autonome est en cours d'exécution, le nombre d'UC actuellement affecté à la base de données vous est facturé, qu'il soit spécifié lors de la création initiale ou ultérieurement au moyen d'une opération d'ajustement manuel. De plus, si l'ajustement automatique est activé pour la base de données, toutes les UC supplémentaires utilisées par la base de données vous sont également facturées à la seconde. Voir Détails de facturation des unités centrales pour plus d'informations sur la mesure et le calcul de la facturation.

Lorsqu'une base de données d'IA autonome est arrêtée, vous n'êtes pas facturé. Toutefois, le nombre d'UC qui lui sont affectées n'est pas renvoyé aux UC disponibles au niveau de la grappe de machines virtuelles autonome parent pour le déploiement global.

Lorsqu'une base de données d'IA autonome est arrêtée ou réduite, le nombre d'UC qui lui sont affectées n'est pas immédiatement retourné aux UC disponibles au niveau de la grappe de machines virtuelles autonome parent pour le déploiement global. Ils continuent d'être inclus 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 UC sont appelées UC récupérables. Les UC récupérables au niveau AVMC parent sont la somme des UC récupérables de toutes ses bases de données conteneur autonomes. Lorsqu'une base de données conteneur autonome est redémarrée, elle renvoie toutes ses unités centrales récupérables aux unités centrales disponibles au niveau de la machine virtuelle autonome parent.

Le redémarrage d'une base de données conteneur autonome (ACD) est une opération en ligne, effectuée de manière continue dans la grappe et n'entraînera pas de temps d'arrêt de l'application si elle est configurée conformément aux meilleures pratiques pour utiliser la continuité transparente des applications.

Conseil : Vous pouvez suivre les différents attributs de calcul (UC) décrits dans cet article à partir de la page Détails d'une grappe de machines virtuelles Exadata autonome (AVMC) ou d'une base de données conteneur autonome (ACD). Pour obtenir des conseils, consultez Suivi de l'utilisation des ressources.

Affectation d'UC lors de l'ajustement automatique

La fonction d'ajustement automatique permet à une base de données autonome d'IA d'utiliser jusqu'à trois fois plus de ressources d'UC et d'E/S que le nombre d'UC qui lui est affecté. En cas de surprovisionnement d'UC, si trois fois le nombre d'UC entraîne une valeur inférieure à 1, il sera arrondi au nombre entier suivant. Le surprovisionnement d'UC n'est pris en charge qu'avec les OCPU. Pour plus de détails, voir Surprovisionnement d'UC.

Pour s'assurer qu'aucune base de données autonome ne peut s'adapter automatiquement à toutes les UC disponibles dans le groupe pour le déploiement global, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée utilise la base de données conteneur autonome comme contrôle limitatif.

Lors du provisionnement d'une base de données autonome avec ajustement automatique dans une base de données conteneur autonome, si les UC disponibles dans cette base de données conteneur autonome ont une valeur inférieure à 3 fois celle de la nouvelle base de données, des UC supplémentaires seront réservées dans cette base de données conteneur autonome. Ces UC sont appelées UC réservées. Les UC réservées garantissent que les UC disponibles au niveau de la base de données conteneur autonome sont toujours supérieures ou égales à 3 fois la valeur UC de la base de données avec ajustement automatique la plus importante de cette base de données conteneur autonome. Ces UC réservées peuvent toujours être utilisées pour créer ou ajuster manuellement des bases de données autonomes dans cette base de données conteneur autonome.

Lors de l'ajustement automatique d'une base de données d'intelligence artificielle autonome, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée recherche les UC inactives dans sa base de données conteneur parent. Si des UC inactives sont disponibles, la base de données Autonomous AI Database est mise à l'échelle; sinon, elle ne l'est pas. Comme les bases de données présentent intrinsèquement une durée d'inactivité importante, l'ajustement automatique est un moyen d'optimiser l'utilisation des ressources tout en contrôlant les coûts et en préservant un bon isolement des bases de données situées dans d'autres bases de données conteneur autonomes.

Si l'UC utilisée pour ajuster automatiquement une base de données autonome basée sur l'IA provient d'une autre base de données autonome exécutée légèrement chargée et n'utilise donc pas toutes les unités centrales qui lui sont affectées, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée réduit automatiquement la base de données ajustée automatiquement si la charge augmente sur l'autre base de données et qu'elle a besoin de son processeur affecté.

Prenons l'exemple d'une base de données conteneur autonome hébergeant quatre bases de données d'IA autonomes à 4 unités centrales, toutes avec l'ajustement automatique activé. Le nombre d'UC disponibles pour la base de données conteneur à des fins d'ajustement automatique est de 12. Si l'une de ces bases de données doit être ajustée automatiquement au-delà de 4 UC en raison de l'augmentation de charge, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée n'effectuera l'opération d'ajustement automatique que si une ou plusieurs autres bases de données sont légèrement chargées et n'utilisent pas toutes les UC affectées. Le coût de facturation de cet exemple est de 16 UC au minimum, car les quatre bases de données à 4 UC sont toujours en cours d'exécution.

En revanche, prenons l'exemple d'une base de données conteneur autonome hébergeant quatre bases de données d'IA autonomes à 2 unités centrales, toutes avec l'ajustement automatique activé et une base de données d'IA autonome à 8 unités centrales arrêtée. Le nombre d'UC disponibles pour la base de données conteneur à des fins d'ajustement automatique est de nouveau de 16. Si l'une des bases de données en cours d'exécution doit être ajustée automatiquement en raison de l'augmentation de charge au-delà de 2 unités centrales, Oracle Autonomous AI Database sur une infrastructure Exadata dédiée peut effectuer l'opération à l'aide d'unités centrales affectées à la base de données à 8 unités centrales arrêtée. Dans cet exemple, les quatre bases de données en cours d'exécution peuvent consommer jusqu'à 8 UC supplémentaires simultanément sans consommer les UC allouées l'une à l'autre. Le coût de facturation de cet exemple est de seulement 8 UC au minimum, car seules les quatre bases de données à 2 UC sont toujours en cours d'exécution.

Pour toute instance de service Autonomous Data Guard, locale ou inter-région, la tarification supplémentaire est le nombre d'ECPU ou d'OCPU que vous avez réservées lors de la création ou de l'ajustement explicite de votre instance de service principale, que l'ajustement automatique soit activé ou non. La consommation d'ECPU ou d'OCPU liée à l'ajustement automatique sur les instances de service principales n'est pas effectuée sur les instances de service de secours Autonomous Data Guard.

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

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

Toutefois, vous pouvez utiliser la fonction de quotas de compartiment d'Oracle Cloud Infrastructure pour restreindre davantage, compartiment par compartiment, le nombre d'UC disponibles pour créer, ajuster manuellement et ajuster automatiquement les bases de données autonomes basées sur l'IA de chaque type de charge de travail (entrepôt avec lac de données de l'IA autonome ou traitement des transactions d'IA autonome) individuellement.

En résumé, vous utilisez la fonction de quotas de compartiment en créant des énoncés de politique set, unset et zero pour limiter la disponibilité d'une ressource donnée dans un compartiment donné. Pour des informations et des instructions détaillées, voir Quotas de compartiment.

Incidence des noeuds de grappe de machines virtuelles sur la gestion de l'UC

La discussion précédente sur la gestion et l'affectation d'UC indique que vous pouvez créer plusieurs ressources de grappe de machines virtuelles Exadata autonome (AVMC) en choisissant le nombre d'UC par noeud lors du provisionnement de la ressource AVMC.

Cette section traite des détails granulaires sur la façon dont Oracle Cloud Infrastructure place les bases de données autonomes d'IA dans les noeuds de la grappe de machines virtuelles, ainsi que des conséquences de ce positionnement sur l'ajustement automatique et le traitement parallèle.

Les attributs suivants déterminent quand et comment une base de données IA autonome 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'intelligence artificielle autonome sur plusieurs noeuds. Le seuil de fractionnement par défaut est de 64 pour les ECPU et de 16 pour les OCPU, mais si des grappes de machines virtuelles sont créées 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 grappe 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 autonome.

Les bases de données d'IA autonomes créées avec une valeur d'UC inférieure à la valeur de fractionnement s'ouvriront sur un noeud de la grappe 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 autonome avec un seuil de fractionnement par défaut (64 ECPU) dans une grappe de machines virtuelles autonome avec deux noeuds et 40 ECPU par noeud. Comme 40 est inférieur à 64, toute base de données autonome d'intelligence artificielle ayant des besoins en CPU supérieurs à 40 sera fractionnée et ouverte sur plusieurs noeuds, ce qui permettra aux demandes LMD sur ces noeuds. Toutefois, si la machine virtuelle autonome a été créée avec deux noeuds et 80 ECPU par noeud, toute base de données ayant une exigence ECPU supérieure à 64 sera fractionnée et ouverte sur plusieurs noeuds.
- Supposons que vous créez une base de données conteneur autonome dans une grappe de machines virtuelles avec deux noeuds et 40 ECPU par noeud et que vous réglez explicitement la valeur du seuil de fractionnement à une valeur beaucoup plus petite, par exemple 20 ECPU. Toute base de données autonome avec une exigence d'UC supérieure à 20 sera fractionnée et ouverte sur plusieurs noeuds, et les bases de données avec une exigence d'UC inférieure à 20 seront ouvertes sur un seul noeud.
  
  Le fait de régler le seuil de fractionnement à un nombre beaucoup plus petit que la valeur par défaut augmente les chances d'ouverture des bases de données avec un nombre d'UC inférieur sur plusieurs noeuds, à condition que leur nombre d'UC soit supérieur à la valeur de fractionnement définie. Chaque fois qu'une base de données est créée ou mise à l'échelle à une taille supérieure à cette valeur de fractionnement, elle est ouverte sur plusieurs noeuds. Cette fonction est utile lorsque vous souhaitez que les bases de données s'ouvrent sur plusieurs noeuds afin de contrôler la dégradation de la performance en cas de défaillance d'un noeud ou de maintenance planifiée. Avec des bases de données fractionnées sur plusieurs noeuds dans des grappes RAC plus grandes, en cas de défaillance d'un noeud ou lors d'une maintenance programmée, vous pouvez continuer à bénéficier d'une performance supérieure plutôt que de passer à un profil de performance de 50 %.
- Supposons que vous définissiez explicitement le seuil de fractionnement à une valeur beaucoup plus élevée que la valeur par défaut, par exemple 80 ECPU, dans une machine virtuelle autonome avec deux noeuds et 40 ECPU. Toute base de données autonome avec une exigence d'UC supérieure à 40 sera fractionnée et ouverte sur plusieurs noeuds, et les bases de données avec une exigence d'UC inférieure à 40 seront ouvertes sur un seul noeud.
  
  Si vous affectez une valeur beaucoup plus élevée que la valeur par défaut au seuil de fractionnement, les instructions LMD de la base de données restent sur un seul noeud RAC et éliminent les risques de contention liée aux attentes du cluster.
- Lorsque vous ajustez manuellement une base de données d'IA autonome, la nouvelle valeur d'UC est appliquée au modèle fractionné existant. Autrement dit, si la nouvelle valeur est inférieure au seuil de fractionnement, elle s'ouvrira sur un noeud et si la valeur est supérieure au seuil de fractionnement, elle s'ouvrira sur plusieurs noeuds.
Affinité de répartition : Détermine le nombre de noeuds sur lesquels une base de données d'IA autonome sera ouverte une fois qu'elle aura dépassé le seuil de fractionnement.

Par exemple, supposons que vous ayez créé une ressource de grappe de machines virtuelles autonome avec 4 noeuds et 80 ECPU par noeud, et que vous ayez créé une base de données conteneur autonome dans cette grappe de machines virtuelles autonome avec le seuil de fractionnement de base de données réglé à 64. La création d'une base de données d'IA autonome avec une exigence d'ECPU de 120 fractionnera et ouvrira la base de données sur plusieurs noeuds en 120 de plus de 64 (seuil de fractionnement).
- Si votre affinité de distribution est réglée à Noeuds 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 divisé entre 3 nœuds avec 40 ECPU chacun. Si cela n'est pas possible non plus, Oracle Cloud Infrastructure tentera d'ouvrir la base de données sur 4 noeuds chacun avec 30 ECPU.
- Si vous spécifiez une affinité de distribution avec Noeuds maximum, Oracle Cloud Infrastructure tente de créer la base de données fractionnée entre les 4 noeuds avec 30 ECPU chacun. Si cela n'est pas possible, il sera divisé entre trois noeuds avec 40 ECPU chacun. Si cela n'est pas possible non plus, Oracle Cloud Infrastructure tentera d'ouvrir la base de données sur 2 noeuds chacun avec 60 ECPU.
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) de votre machine virtuelle autonome pour les événements de défaillance et de maintenance 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 de défaillance ou d'une maintenance, vous continuerez à exécuter, mais à 50 % de l'UC affectée.
- Pour les bases de données non critiques ou les bases de données à très faible utilisation, vous pouvez affecter une valeur inférieure à la réservation de basculement de noeud 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 régler cette valeur à zéro pour les environnements 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 fractionnée sur plus de 2 noeuds, à l'aide d'un seuil de fractionnement et d'une affinité de distribution. Prenons l'exemple d'un scénario dans lequel une base de données d'IA autonome est divisée en 4 noeuds. En supprimant un nœud à la fois de manière continue pendant qu'une activité de maintenance est en cours, vous avez toujours 3 nœuds toujours actifs et prenant du trafic, gardant votre réserve de performance efficacement de 75%, plutôt que les 50% habituels. Avec des grappes plus grandes, vous pouvez augmenter cette réserve encore plus, par exemple pour une réserve de 87,5 % sur une grappe à 8 noeuds.

La répartition de l'UC d'une base de données d'IA autonome entre les noeuds de grappe de machines virtuelles a une incidence sur les opérations suivantes :

Ajustement automatique :
- L'ajustement automatique peut se produire au sein d'un seul noeud de grappe de machines virtuelles pour les opérations LMD non parallélisables et entre les noeuds de grappe de machines virtuelles si l'opération LMD est parallélisable.
- Plusieurs sessions simultanées avec des interrogations non parallélisables peuvent être acheminées vers tous les noeuds du cluster, ce qui permet une mise à l'échelle automatique sur tous les noeuds d'une base de données multinoeud.
Traitement parallèle :
- Le traitement parallèle des énoncés SQL se produit au sein des noeuds de grappe de machines virtuelles Exadata autonome qui sont ouverts, d'abord au sein d'un seul noeud, puis dans les noeuds ouverts adjacents, ce qui, comme indiqué ci-dessus, dépend de la taille de la grappe de machines virtuelles Exadata autonome.

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 ajuster des bases de données d'intelligence artificielle autonomes. Par exemple, si vous disposez de 20 UC disponibles au niveau de la grappe de machines virtuelles autonome, toutes les valeurs comprises entre 1 et 20 UC ne peuvent pas être utilisées pour provisionner ou ajuster des bases de données autonomes basées sur la disponibilité des ressources au niveau du noeud. La liste des valeurs d'UC pouvant être utilisées pour provisionner ou ajuster une base de données d'intelligence artificielle autonome est appelée UC provisionnables.

Lorsque vous tentez de provisionner ou d'adapter une base de données autonome avec intelligence artificielle à 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 retourne une liste de valeurs d'UC provisionnables pouvant être utilisées pour créer une nouvelle base de données d'intelligence artificielle autonome dans la base de données conteneur autonome indiquée. Pour plus d'informations, voir GetAutonomousContainerDatabase.
GetAutonomousDatabase retourne une liste de valeurs d'UC provisionnables pouvant être utilisées pour l'ajustement d'une base de données d'IA autonome donnée. Pour plus d'informations, voir GetAutonomousDatabase.

Contenu connexe

Facturation d'une base de données autonome avec intelligence artificielle sur une infrastructure Exadata dédiée