Résumé

  • Depuis l'annonce du 8 septembre, la conversion entre réservations Compute Engine mono-projet et partagées est disponible de manière générale. Elle modifie l'accès à une capacité existante.
  • Le partage ne supprime pas la facture des ressources inutilisées. Le retour au mono-projet impose aussi des conditions aux instances des projets consommateurs qui ciblent expressément la réservation.

Donner un autre usage à une marge de sécurité

Une capacité réservée pour une équipe peut attendre alors qu'une autre manque de ressources compatibles. Google Cloud permet désormais de changer le périmètre des utilisateurs d'une réservation. Ses notes Compute Engine du 8 septembre annoncent la disponibilité générale du passage, pour les réservations admissibles, du mono-projet au partage et inversement.

Les réservations partagées existaient déjà. La nouveauté est la conversion entre les deux types, pas l'ouverture d'un marché de revente. Le guide de modification limite le partage à un maximum de 100 projets dans la même organisation. La modification d'une réservation partagée se fait depuis son projet de création : l'équipe consommatrice n'en devient pas propriétaire.

L'intérêt économique potentiel est de rapprocher une réserve déjà constituée d'une demande interne compatible. Cela n'ajoute aucune ressource réservée et ne dispense ni des autorisations ni des quotas applicables. Le nombre de projets admis n'est donc pas une mesure de capacité supplémentaire.

Une facture résiduelle reste au propriétaire

La présentation des réservations précise que leurs ressources sont facturées tant que la réservation existe, utilisées ou non. Une machine virtuelle qui les consomme ne provoque pas une seconde facturation des mêmes ressources réservées.

Le partage lui-même n'entraîne pas de supplément. Par défaut, la facture revient au projet propriétaire. Lorsqu'un projet consommateur utilise des ressources partagées, il est facturé pour ces ressources. Les remises pour engagement d'utilisation et les autres conditions tarifaires applicables peuvent modifier le prix. Changer l'accès n'est ni une nouvelle remise ni la garantie d'un tarif identique entre projets.

Prenons une équipe qui garde une réserve pour une tâche à venir et une autre qui a du travail compatible aujourd'hui. C'est un exemple hypothétique, pas un résultat client publié. Le partage peut rendre la réserve plus utile. Si les deux besoins se présentent ensuite au même moment, il faut pourtant toujours arbitrer une capacité finie. Le paramètre ne choisit pas la priorité commerciale.

Le retour n'est pas un simple geste inverse

Pour convertir en mono-projet une réservation partagée explicitement ciblée par des instances, le guide impose d'arrêter, de suspendre ou de supprimer les instances consommatrices dans les projets auxquels elle est partagée. Cette exigence ne concerne pas les instances du projet propriétaire.

Il existe aussi une condition de reprise : les instances consommatrices arrêtées ou suspendues qui ciblent la réservation ne peuvent redémarrer ou reprendre qu'après création d'une réservation de remplacement dans le même projet propriétaire et la même zone, avec le même nom et des propriétés correspondantes. C'est une dépendance documentée, non un incident rapporté ni un conseil de supprimer des charges de travail. Elle ne doit pas être étendue à toutes les instances qui consomment automatiquement une réserve.

Les réservations liées à des engagements relèvent par ailleurs d'une procédure de remplacement distincte; celles créées automatiquement pour des réservations futures ont leurs propres limites. La disponibilité générale n'autorise pas la réécriture de toutes les conditions commerciales. La souplesse accrue porte sur l'accès, pas sur l'absence de conséquences quand on le retire.