Resumen

  • La actualización de Compute Engine del 8 de septiembre declara disponible de forma general la conversión entre reservas de un proyecto y reservas compartidas.
  • El cambio amplía o reduce quién puede usar recursos existentes. No elimina los cargos por capacidad ociosa y tiene condiciones de retirada para instancias que apuntan expresamente a la reserva.

Cambiar el acceso a una capacidad ya contratada

Una reserva que una unidad mantiene para un trabajo futuro puede servir hoy a otra unidad. Google Cloud ofrece una nueva forma de ajustar ese acceso: sus notas del 8 de septiembre anuncian la disponibilidad general de la conversión, para las reservas que cumplen los requisitos, de un solo proyecto a compartidas y viceversa.

No es el estreno de las reservas compartidas. La novedad consiste en cambiar de tipo. Tampoco abre un mercado de reventa entre organizaciones. Según la guía de modificación, los recursos pueden compartirse con hasta 100 proyectos de la misma organización. La reserva compartida se modifica desde el proyecto donde se creó; el consumidor no se convierte en su propietario.

Para quien administra capacidad de forma centralizada, el beneficio posible es aprovechar demanda interna compatible sin dejar recursos ociosos. Pero admitir más proyectos no añade capacidad reservada ni sustituye los controles de permisos y cuotas.

El uso mueve la factura, no borra el coste

La documentación general de reservas señala que los recursos generan cargos mientras exista la reserva, estén utilizados o no. Una máquina virtual que los consume no paga de nuevo por esos mismos recursos reservados.

Compartir no tiene un cargo adicional propio. Por defecto se factura al proyecto propietario; cuando otro proyecto consume recursos de la reserva, ese proyecto recibe la facturación correspondiente a lo utilizado. Los descuentos por compromiso de uso y otras condiciones aplicables pueden variar el precio. No se ha anunciado una nueva rebaja ni un coste idéntico para cualquier proyecto.

Imaginemos dos equipos: uno guarda un margen para una tarea posterior y otro tiene trabajo compatible ahora. Es un supuesto explicativo, no un caso de ahorro divulgado por Google. Compartir puede mejorar el aprovechamiento. Si después ambos demandan los recursos al mismo tiempo, seguirá habiendo una capacidad limitada. El ajuste técnico no decide qué necesidad de negocio debe prevalecer.

La retirada puede alterar el trabajo ajeno

La guía establece una condición para convertir en reserva de un solo proyecto una reserva compartida que las instancias consumidoras seleccionan expresamente. Antes deben detenerse, suspenderse o eliminarse las instancias que la consumen en los proyectos con los que se comparte. El requisito no afecta a las instancias del proyecto propietario.

Además, las instancias consumidoras detenidas o suspendidas que apuntan a la reserva no podrán reiniciarse o reanudarse hasta contar con una reserva de sustitución en el mismo proyecto propietario y zona, con el nombre original y propiedades coincidentes. Es una dependencia documentada, no un fallo de cliente observado ni una recomendación de borrar cargas. Tampoco se aplica por extensión a todas las instancias que consumen reservas de forma automática.

Las reservas vinculadas a compromisos tienen un procedimiento de sustitución distinto; las generadas automáticamente para reservas futuras conservan límites propios. La función no convierte todos los tipos de reserva ni sus condiciones comerciales en parámetros libremente editables. La flexibilidad de acceso y la facilidad para retirar capacidad no son equivalentes.