Reservas de recursos zonales de Compute Engine


En este documento, se explica el comportamiento, los requisitos, las restricciones, y la facturación de las reservas de los recursos zonales de Compute Engine.

Descripción general

Para asegurarte de que los recursos de Compute Engine estén disponibles cuando los necesites, usa las reservas. Las reservas proporcionan un nivel de seguridad muy alto para obtener capacidad para los recursos zonales de Compute Engine. Puedes usar las reservas para garantizar que tu proyecto tenga recursos para futuros aumentos de la demanda, por ejemplo:

  • Crecimiento
  • Aumentos planificados o no planificados
  • Migración de una gran cantidad de instancias de máquina virtual (VM)
  • Copia de seguridad y recuperación de desastres

Con las reservas, el 95% de las VMs se inicia en menos de 120 segundos. Cada reserva proporciona garantía para una o más VMs con las mismas propiedades. Después de crear una reserva, los recursos reservados estarán disponibles de inmediato y permanecerán disponibles hasta que borres la reserva. De manera similar, comienzas a pagar los recursos reservados de inmediato y, cuando ya no necesitas una reserva, puedes borrarla para dejar de generar cargos. Si bien una VM consume una reserva, esta no genera cargos independientes.

Sin importar cuánto uses tus recursos reservados, la reserva evita que alguien más los use. Debido a que una reserva ocupa recursos tanto como las VM en ejecución sin reservar, los recursos reservados se cobran con las mismas tarifas según demanda que las VM en ejecución, incluidos los descuentos correspondientes.

Cómo funcionan las reservas

En esta sección, se describe cómo funcionan las reservas.

Una reserva proporciona garantía de capacidad para una o más VMs de Compute Engine con la configuración especificada. También puedes usar una reserva con compromisos de Compute Engine u otros productos que usen VMs.

Cuando creas una reserva, defines las siguientes propiedades:

  • Tipo de aprovisionamiento (on demand o futuro)
    • Una reserva on demand (predeterminada) se aprovisiona en el momento en que la solicitas, si la capacidad solicitada está disponible.
    • Una reserva futura te permite solicitar de forma anticipada garantías de capacidad importante o difícil de obtener. En particular, las reservas futuras constan de dos tipos de recursos: solicitudes de reserva futuras que, si se aprueban, proporcionan reservas creadas automáticamente el tiempo especificado y en el futuro. Después de su período de reserva solicitado, una reserva creada automáticamente se borra automáticamente o se comporta de manera similar a una reserva on demand.

      El uso de reservas futuras puede proporcionar un nivel de seguridad aún mayor para obtener capacidad que las reservas según demanda, ya que permite que Google Cloud tenga más tiempo para completar la solicitud. Si deseas usar reservas futuras, consulta Acerca de las solicitudes de reserva futuras en lugar de este documento.

  • Eliminación automática

    La opción eliminación automática especifica que se borre la reserva automáticamente, sin importar si se consume por completo o no. Si habilitas la opción de eliminación automática, la reserva se borra en un plazo de dos horas a partir de la fecha y hora especificadas. Borrar reservas automáticamente puede ser útil para evitar cargos innecesarios por las reservas que no se consumen durante un tiempo.

  • Tipo de consumo (automático o específico)
    • Pueden consumir una reserva que se consuma automáticamente (configuración predeterminada) las VMs con una propiedad de afinidad de reserva que les permita consumir automáticamente cualquiera de estas reservas (configuración predeterminada).
    • Una reserva orientada específicamente puede ser consumida solo por VMs con una propiedad de afinidad de reserva que se orienta a esa reserva específica para su consumo. El uso de reservas orientadas específicamente puede facilitar el seguimiento y el control de qué VMs consumen qué reservas.
  • Tipo de recurso compartido (de un solo proyecto o compartido)
    • Pueden consumir una reserva de un proyecto único (configuración predeterminada) solo las VMs que se encuentran en el mismo proyecto que la reserva.
    • Pueden consumir una reserva compartida las VMs de un proyecto en el que se encuentra la reserva y cualquier otro proyecto con el que se comparta la reserva. El uso de reservas compartidas puede ayudar a mejorar la utilización de tus reservas y reducir la cantidad de reservas que necesitas crear y administrar. Para obtener más información, consulta Cómo funcionan las reservas compartidas en este documento.
  • Opcional: Política de posición nde recursos (compacta)

    Una política de posición compacta indica que las VMs reservadas deben estar ubicadas lo más cerca posible entre sí para reducir la latencia de red entre ellas.

  • Recuento de VMs

    El recuento de VMs es la cantidad de VMs con propiedades y zonas coincidentes que deseas reservar cuando creas una reserva. Después de crear la reserva, puedes cambiar el recuento de VMs.

  • Propiedades de VM

    Las propiedades de VM definen los requisitos de hardware para las VMs que deseas reservar. Una VM puede consumir una reserva solo si sus propiedades y las propiedades de VM de la reserva coinciden de forma exacta. Para obtener más información, consulta Requisitos en este documento.

Después de crear una reserva, ten en cuenta lo siguiente:

  • Si detienes, suspendes o borras una VM que consume una reserva, la VM ya no cuenta para la reserva. Los recursos consumidos antes vuelven a estar disponibles para su consumo después de detener, suspender o borrar la VM.

  • Si borras una reserva, pero no borras las VMs que usan los recursos reservados, las VMs persisten y deberás pagar por los recursos como de costumbre.

Cómo funcionan las reservas compartidas

Cada VM en una reserva compartida puede ser consumida por cada VM en el proyecto en el que se creó la reserva (proyecto de propietario) o en cualquiera de los proyectos con los que se comparte la reserva (proyectos de consumidor). Cuando una VM deja de consumir una reserva compartida, otra VM diferente puede consumirla en cualquiera de los proyectos con los que se comparte la reserva. Si una reserva compartida reserva varias VMs, las VMs de varios proyectos pueden consumir la misma reserva compartida de manera simultánea.

De forma predeterminada, los proyectos no pueden crear y modificar reservas compartidas. Para crear y modificar una reserva compartida con un proyecto, este debe agregarse a la lista de entidades permitidas de la restricción de la política de la organización Proyectos de propietario de las reservas compartidas (compute.sharedReservationsOwnerProjects). Si compartes una reserva, esta se ve afectada por limitaciones adicionales y tiene un comportamiento de consumo un poco diferente al de las reservas que no se comparten.

Requisitos

Todas las reservas tienen los siguientes requisitos:

  • Una VM puede consumir una reserva solo si todas las propiedades siguientes para la VM y la reserva coinciden de forma exacta:

    • Proyecto*
    • Zona
    • Tipo de máquina
    • Plataforma de CPU mínima
    • Tipo y recuento de GPU
    • Tipo y recuento de SSD locales
    • Afinidad de reserva
    • Política de posición de compactación

    * Los requisitos del proyecto varían según el tipo de recurso compartido de la reserva.

    Los requisitos de afinidad de la reserva varían según el tipo de consumo de la reserva.

    De manera opcional, una reserva puede incluir una política de posición de compactación para indicar que sus VM reservadas deben estar lo más cerca posible entre sí para reducir la latencia de red entre ellas. Si una reserva especifica una política de posición de compactación, solo pueden consumirla las VM que especifican la misma política de posición de compactación.

  • Debes tener cuota suficiente en tu proyecto para los recursos que quieres reservar. Si la reserva se crea de forma correcta, la cuota que corresponde a ese recurso se cobra en consecuencia.

Requisitos adicionales para las reservas adjuntas a los compromisos

Además, las reservas que se adjuntan a los compromisos tienen los siguientes requisitos:

  • Las reservas deben ser para el mismo proyecto y la misma región que el compromiso.

  • Las reservas deben ser para la misma serie de familias de máquinas que el compromiso. Sin embargo, puedes elegir cualquier tipo de máquina dentro de esa serie de familias de máquinas.

  • Las reservas deben tener la opción de eliminación automática inhabilitada.

  • Si el compromiso especifica GPU, discos SSD locales o ambos, la reserva adjunta (o la combinación de reservas adjuntas) debe especificar exactamente los mismos números y tipos de esos recursos que el compromiso.

Para obtener más información, consulta Adjunta reservas a compromisos basados en recursos.

Requisitos adicionales para las reservas creadas a partir de una plantilla de instancias

Además, si creas una reserva a través de la especificación de una plantilla de instancias, asegúrate de lo siguiente:

  • Debes crear la reserva en la misma región, zona y proyecto que los recursos de la plantilla. En particular, haz lo siguiente:

    • Cualquier recurso regional o zonal que se especifique en una plantilla de instancias, como un tipo de máquina o un disco - restringe el uso de la plantilla a las ubicaciones en las que existen esos recursos. Por ejemplo, si tu plantilla de instancias especifica un disco existente en la zona us-central1-a, debes crear la reserva en la misma zona.

    • Una plantilla de instancias contiene una configuración específica del proyecto, por lo que solo puedes acceder a ella y usarla dentro del mismo proyecto. Para los proyectos con los que se comparte una reserva compartida, debes crear plantillas similares en esos proyectos o crear VMs a través de la especificación directa de las propiedades.

  • Si la plantilla de instancias especifica una política de posición de compactación, debes crear una reserva específica. Luego, cuando crees las VMs para consumir la reserva, debes orientar de manera específica la reserva por nombre. De lo contrario, las VMs no pueden consumir la reserva.

Requisitos adicionales para las reservas compartidas

Además, existen implicaciones de cuota específicas para los proyectos de propietario y consumidor de una reserva compartida. En particular, haz lo siguiente:

  • El proyecto de propietario debe tener una cuota suficiente para el doble de recursos que se reservarán. Al proyecto propietario de una reserva compartida se le cobra la cuota de la siguiente manera:

    • Cuando se reservan los recursos, se cobra al proyecto propietario por la cuota de los recursos que reserva.

    • Cuando se consume cualquiera de los recursos reservados, se le cobra al proyecto de propietario por la cuota de los recursos que se consumen.

  • Se cobra la cuota del consumidor solo por los recursos reservados y por los recursos que consume.

Por ejemplo, supongamos que el proyecto A (el proyecto propietario) crea una reserva compartida para 10 recursos y compartimos la reserva con el proyecto B y C (los proyectos de consumidor). Después de crear la reserva compartida, se cobra al proyecto A por 10 recursos. Luego, supongamos que los proyectos consumen la reserva de la siguiente manera:

  • El proyecto A consume 2 recursos reservados y se le cobran 2 recursos.

  • El proyecto B consume 2 recursos reservados. A los proyectos A y B se les cobran 2 recursos.

Requisitos adicionales para las reservas con políticas de posición de compactación

Además, para especificar una política de posición de compactación para una reserva, asegúrate de que se cumplan los siguientes requisitos:

  • La política de posición de compactación debe admitir reservas:

    • La política de posición de compactación no puede especificar una cantidad fija de VM.

    • La política de posición de compactación no puede especificar un valor max-distance de 1.

    • La política de posición de compactación no se puede especificar con más de una reserva a la vez.

  • La reserva debe admitir políticas de posición de compactación:

    • Solo puedes especificar una política de posición de compactación para una reserva a pedido, de un solo proyecto y específicamente orientada que no esté adjunta a una entrega.

    • Las VM reservadas por la reserva deben ser compatibles con la política de posición de compactación:

      • La zona de la reserva debe estar dentro de la región de la política de posición de compactación.

      • La cantidad de VM de la reserva no puede exceder la cantidad máxima de VM que admite la política de posición de compactación.

      • El tipo de máquina de la reserva debe ser compatible con las políticas de colocación compacta.

      Para obtener más información, consulta las restricciones de las políticas de posición de compactación.

Restricciones

Todas las reservas tienen las siguientes restricciones:

  • Puedes reservar hasta 1,000 VMs por reserva.
  • Las reservas solo se aplican al uso de las VMs en los siguientes productos de Google Cloud:

    • Lote
    • Compute Engine
    • Dataflow
    • Dataproc
    • Google Kubernetes Engine

  • Las reservas no se aplican a los siguientes recursos:

    • Tipos de máquinas f1-micro y g1-small
    • VM interrumpibles
    • Nodos de usuario único
    • Otros servicios no enumerados antes, como Cloud SQL
  • Compute Engine intenta asignar recursos a pedido cuando creas una reserva. Si no hay suficientes recursos en la zona al momento de la solicitud, la reserva falla y se muestra un error de disponibilidad de recursos debido a que la capacidad es insuficiente. Si la reserva se crea de forma correcta, los recursos estarán disponibles para que los uses, incluso si no los usas de inmediato.

Restricciones adicionales para las reservas adjuntas a los compromisos

Además, las reservas que se adjuntan a los compromisos tienen las siguientes restricciones:

  • Solo puedes adjuntar reservas a los compromisos basados en recursos.

  • Solo puedes adjuntar reservas mientras compras el compromiso.

  • Puedes adjuntar una reserva específica a un solo compromiso.

  • No puedes borrar o cambiar el tamaño de una reserva que se adjunta a un compromiso. En su lugar, consulta cómo reemplazar las reservas conectadas a los compromisos.

Para obtener más información, consulta Adjunta reservas a compromisos basados en recursos.

Restricciones adicionales para las reservas compartidas

Además, todas las reservas compartidas tienen las siguientes restricciones:

  • Solo puedes compartir reservas con los proyectos que se encuentren en la misma organización que el proyecto que crea la reserva.

  • Cada reserva compartida se puede compartir con 1 a 100 proyectos de consumidor.

  • En cada organización, puedes crear hasta 100 reservas compartidas para cada combinación única de propiedades de la VM.

  • Solo puedes enumerar las reservas que creó un proyecto específico. Esto significa que cada reserva compartida solo aparece en el proyecto que la creó, no puedes enumerar todas las reservas compartidas en una organización ni todas las reservas que se comparten con un proyecto específico.

  • Si creas una reserva compartida a través de la especificación de una plantilla de instancias, solo los usuarios dentro de tu proyecto pueden acceder a la misma plantilla de instancias y usarla para crear VM o, también, otras reservas.

  • No puedes especificar una política de posición de compactación cuando creas una reserva compartida.

  • Si mueves un proyecto que usaba reservas compartidas a una organización nueva, sus reservas compartidas no se migran a la organización nueva. Se borrarán todas las reservas compartidas que se crearon con este proyecto, y cualquier reserva de la organización anterior que se compartió con este proyecto no se puede consumir en la organización nueva. Para obtener más información, consulta Cómo funcionan las reservas compartidas en este documento.

Puedes mitigar las limitaciones de algunos de estos requisitos si sigues las prácticas recomendadas para las reservas compartidas.

Restricciones adicionales para las reservas con políticas de posición de compactación

Además, las reservas que especifican una política de posición de compactación tienen las siguientes restricciones:

  • No puedes compartir una política de posición de compactación entre reservas. En su lugar, debes usar una política de posición de compactación independiente para cada reserva a la que desees aplicarle una.

  • Solo puedes especificar políticas de posición de compactación. No se admite ningún otro tipo de políticas de recursos, como las programaciones de instancias o de instantáneas.

Facturación

En esta sección, se describe cómo se facturan todas las reservas.

Las reservas de Compute Engine se facturan con la misma tarifa que sus recursos reservados, incluidos los mismos precios según demanda y los cargos mínimos de 1 minuto que tienen las VM en ejecución sin reservar. Los descuentos por uso continuo (SUDs), los CUD y los precios personalizados también se aplican de la misma forma que para las VMs en ejecución.

Por ejemplo, supongamos lo siguiente:

  • Tienes un compromiso de 3 CPU virtuales en us-central1
  • Estás ejecutando 5 CPU virtuales en us-central1-a
  • Tienes una reserva de 10 CPU virtuales en us-central1-a

Reservas que incluyen descuentos por compromiso de uso.

Luego, se te facturará de la siguiente manera:

Cobertura Cantidad de CPU virtuales
Precio con descuento por compromiso de uso 3
Precio según demanda (2 reservas usadas de CPU virtuales + 5 reservas no usadas de CPU virtuales) 7

Una reserva genera cargos por sus recursos reservados durante el tiempo que exista, sin importar si se usan o no sus recursos. Cuando se consume una reserva, una VM no genera cargos de recursos duplicados, ya que la reserva ya se factura por el costo de los recursos reservados. Para obtener más información, consulta Precios de VM.

Además, puedes supervisar las tendencias de consumo de tus reservas para reducir los costos innecesarios de los recursos desperdiciados o sin usar. Para obtener más información, consulta Supervisa el consumo de reservas.

Datos de facturación adicionales para reservas compartidas

No se aplican cargos adicionales por usar reservas compartidas, ya que se facturan al mismo precio que las reservas de Compute Engine de un solo proyecto. Sin embargo, el proyecto al que se facturan las reservas compartidas cambia con el consumo, ya que diferentes proyectos podrían calificar para distintos CUD.

El proyecto de facturación y el precio de las reservas compartidas se manejan de la siguiente manera:

  • Proyecto de facturación: de forma predeterminada, la reserva compartida se factura al proyecto de propietario. Sin embargo, cuando un proyecto de consumidor consume un recurso de una reserva compartida, el proyecto de consumidor se factura por la reserva en su lugar.
  • Descuentos de facturación: de forma predeterminada, la facturación usa el precio según demanda. Sin embargo, si eres apto para recibir CUDs para el proyecto que se factura o para la cuenta de Facturación de Cloud asociada con ese proyecto, se usa el precio con descuento.

¿Qué sigue?