Résumé

  • Oracle rattache une réservation de capacité à un seul domaine de disponibilité à l'intérieur d'un tenancy et à une forme, le domaine de défaillance restant une option ; une instance n'est décomptée au titre de la réservation que si celle-ci se trouve dans son propre domaine de disponibilité, et les types de capacité sont déclarés mutuellement exclusifs.
  • La capacité préemptible est documentée comme récupérable à tout moment, sans durée de conservation minimale garantie, avec un événement émis deux minutes avant le début de la terminaison.
  • Les domaines de disponibilité et les domaines de défaillance sont décrits comme des unités d'isolation et de co-localisation, non comme des réservoirs de capacité ; aucune des cinq pages lues le 19 octobre 2026 n'énonce de durée contractuelle, de prix, ni d'exclusion visant les formes accélérées.

Ce qu'une réservation désigne réellement

La page Réservations de capacité est d'une précision inhabituelle sur l'objet qu'elle crée. Traduite de l'anglais, elle indique que « lorsque vous créez votre réservation de capacité, vous spécifiez le domaine de disponibilité du tenancy où vous souhaitez réserver de la capacité », puis que la quantité et le type de machine sont fixés dans un second temps : « vous pouvez ensuite ajouter une configuration de capacité, qui définit la quantité d'espace à réserver et la forme à utiliser pour créer des instances contre cette configuration ».

Deux phrases supplémentaires resserrent la frontière. Le domaine de défaillance est facultatif — « vous pouvez éventuellement préciser le domaine de défaillance dans lequel réserver » — et la réservation est un conteneur plutôt qu'un lot unique : « chaque réservation de capacité peut comporter plusieurs configurations de capacité ».

La page Lancement d'une instance referme la boucle par l'autre bout, car une réservation ne produit d'effet que là où le placement correspond : « pour créer une instance et qu'elle soit décomptée au titre d'une réservation de capacité, vous devez disposer d'une réservation dans le même domaine de disponibilité que l'instance ». La même page ajoute la phrase que la plupart des plans de capacité ne lisent jamais : « les types de capacité sont mutuellement exclusifs ».

Rassemblé, l'instrument possède des coordonnées. Pas une région, pas un compte, pas une famille de formes. Un domaine de disponibilité, un tenancy et, par configuration, une forme nommée assortie d'une quantité. Les résumés publiés par Oracle vont plus loin et décrivent des réservations incapables de couvrir plusieurs régions ou d'être déplacées entre domaines de disponibilité ou entre tenancies — mais il s'agit d'un résumé et non d'une citation, et l'écart mérite d'être maintenu visible.

Le signal de deux minutes n'est pas une promesse

La page Instances préemptibles est tout aussi explicite sur ce qu'est ce mode. Les instances préemptibles « se comportent comme des instances compute ordinaires, mais la capacité est récupérée lorsqu'elle est nécessaire ailleurs, et les instances sont terminées ». La page n'adoucit pas cela en fenêtre de rétention : « la capacité n'est pas garantie pour une durée minimale, de sorte que les instances peuvent être récupérées à tout moment ».

La mécanique opérationnelle tient en une phrase : « un événement instancepreemptionaction est émis deux minutes avant le début de la terminaison de l'instance ». Deux minutes, c'est un signal dans une séquence de terminaison. Ce n'est ni une durée d'exécution minimale, ni une promesse de réinstanciation, ni un substitut à un chemin de redémarrage qu'une équipe a réellement construit et chronométré. Une charge de travail qui traite cet événement comme une assurance de continuité a mal lu le document.

Un second fait de portée, ici, intéresse directement la planification. La capacité préemptible et la capacité réservée ne sont pas des quantités interchangeables : la liste des limitations de la page range les réservations de capacité parmi les fonctions que les instances préemptibles ne peuvent pas utiliser, et la page de lancement affirme que les types de capacité sont mutuellement exclusifs. Un plan qui suppose pouvoir basculer de l'un à l'autre suppose une migration que ces pages ne décrivent pas.

L'isolation n'est pas la capacité

La page Régions et domaines de disponibilité est celle où la discipline de lecture compte le plus, car son vocabulaire est fort et son objet est la défaillance, non l'offre. Elle énonce que « les domaines de disponibilité sont isolés les uns des autres, tolérants aux pannes et très peu susceptibles de tomber en panne simultanément ». Elle définit ensuite l'unité interne : « un domaine de défaillance est un regroupement de matériel et d'infrastructure à l'intérieur d'un domaine de disponibilité ; chaque domaine de disponibilité contient trois domaines de défaillance ; les domaines de défaillance assurent une anti-affinité : ils permettent de répartir vos instances de sorte qu'elles ne se trouvent pas sur le même matériel physique au sein d'un même domaine de disponibilité ».

C'est une affirmation sur la co-défaillance, assortie d'une règle de placement, et elle est réellement utile : trois domaines de défaillance par domaine de disponibilité donnent au concepteur un endroit où répartir des répliques. Mais elle ne dit rien sur l'existence de capacité pour ces répliques, sur la forme concernée, ni sur les conditions associées. L'isolation et la capacité sont des couches orthogonales : le fait qu'une architecture survive à la perte d'un domaine de défaillance ne prouve pas qu'elle pourra se reconstruire dans un autre au moment voulu.

Ce que les pages ne disent pas

Trois frontières méritent d'être formulées aussi précisément que les constats.

Premièrement, aucune durée. Aucune des pages lues n'indique combien de temps dure une réservation de capacité, comment elle se renouvelle, ni ce qui se produit à son terme. Les énoncés de portée sont des règles d'éligibilité ; ce n'est pas un langage d'engagement, et qualifier la réservation de garantie contractuelle dépasserait tout ce qui figure ici.

Deuxièmement, aucun prix et aucune position d'offre. La page sur le préemptible n'affirme jamais que cette capacité coûte moins cher que le mode à la demande, et la page sur les réservations n'énonce aucun prix. Par ailleurs, les résumés décrivent une capacité allouée à la création de la réservation, une demande insuffisamment servie étant créée à hauteur du maximum possible. C'est un comportement de provisionnement, non une mesure d'inventaire, et il ne faut pas le présenter comme une affirmation de rareté pour une forme ou une région données.

Troisièmement, aucune exclusion par famille de formes. Les cinq pages lues comprennent la page de présentation de Compute, décrite comme listant la capacité à la demande, préemptible, réservée et dédiée — mais cette page n'a fourni aucun passage littéral, sa liste n'est donc pas citable ici, et rien dans le matériel lu n'indique que les formes accélérées ou GPU soient exclues du préemptible ou de la réservation. Le silence n'est pas une inclusion. La position honnête est que la question reste ouverte au vu de ces éléments.

Pourquoi la distinction mord au moment du scale-out

La surface de contrôle n'est pas un détail technique : c'est la question de savoir qui lit quelle page. Les architectes, les acheteurs et les investisseurs rencontrent couramment un nombre de régions et un catalogue de formes, et l'un comme l'autre se consomment facilement comme des affirmations sur la capacité obtenable.

Les phrases qui décident si la capacité est effectivement obtenue — la portée de la réservation, la règle du même domaine de disponibilité, l'exclusivité mutuelle, l'absence de durée garantie sur le préemptible — se trouvent dans des pages de référence distinctes qu'un lecteur de catalogue n'a aucune raison d'ouvrir.

Le mode de défaillance suit mécaniquement. Un plan d'entraînement ou de service est dimensionné en agrégé, comme si une région était un réservoir. L'instrument est borné à un domaine de disponibilité et à une forme. Au moment de l'extension, les tâches qui atterrissent hors du domaine de disponibilité de la réservation ne sont pas décomptées au titre de celle-ci, et la capacité préemptible censée absorber le débordement n'offre aucune durée de vie minimale. Rien n'a changé dans le catalogue. Le déficit apparaît à l'étape d'extension, c'est-à-dire à l'étape qui ne peut pas être suspendue à bon compte.

Telle est la portée pratique de ces pages : elles ne rendent pas compte de la position d'Oracle en matière de capacité, et elles ne visent pas à le faire. Elles définissent la forme de l'instrument qu'un client détient et indiquent ainsi au planificateur le dénominateur auquel son plan n'a pas droit. Le contexte sur l'opérateur se trouve dans la fiche Oracle Cloud du répertoire.