Acerca das reservas

Este documento apresenta uma vista geral das reservas. Para saber mais sobre os diferentes tipos de reservas, consulte Escolha um tipo de reserva.

Quando cria uma reserva, o Compute Engine verifica se a capacidade pedida está disponível na zona especificada. Se for o caso, o Compute Engine reserva recursos, cria a reserva e ativa o seguinte:

  • Pode consumir os recursos reservados para criar instâncias de máquinas virtuais (VMs) e os recursos reservados permanecem disponíveis até eliminar a reserva.

  • Os recursos reservados são cobrados à mesma taxa a pedido que as VMs em execução, incluindo todos os descontos aplicáveis, até que a reserva exista.

As reservas são úteis para o crescimento, as migrações ou a recuperação de desastres.

Como funcionam as reservas

Uma reserva oferece um elevado nível de garantia de capacidade para uma ou mais VMs com a configuração especificada pelo utilizador. Também pode usar uma reserva com compromissos do Compute Engine.

Quando cria uma reserva, define as seguintes propriedades:

  • Eliminar automaticamente

    A opção de eliminação automática especifica que a reserva deve ser eliminada automaticamente, independentemente de ter sido totalmente consumida ou não. Se ativar a opção de eliminação automática, a reserva é eliminada no prazo de duas horas a partir da data e hora especificadas por predefinição, ou na data e hora personalizadas. A eliminação automática de reservas pode ser útil para evitar cobranças desnecessárias relativas a reservas que não são consumidas durante algum tempo.

  • Tipo de consumo (automático ou específico)
    • Uma reserva consumida automaticamente (predefinição) pode ser consumida por VMs com uma propriedade de afinidade de reserva que lhes permite consumir automaticamente qualquer uma destas reservas. Este tipo de consumo é útil se criar e eliminar muitas VMs e quiser consumir as suas reservas sempre que possível.
    • Uma reserva segmentada especificamente só pode ser consumida por VMs com uma propriedade de afinidade de reserva que segmenta essa reserva específica. Este tipo de consumo facilita o acompanhamento e o controlo das VMs que consomem as reservas.
  • Tipo de partilha (projeto único ou partilhado)
    • Uma reserva de projeto único (predefinição) só pode ser consumida por VMs localizadas no mesmo projeto que a reserva.
    • Uma reserva partilhada pode ser consumida por VMs no projeto onde a reserva está localizada e em qualquer outro projeto com o qual a reserva é partilhada. A utilização de reservas partilhadas pode ajudar a melhorar a utilização das suas reservas e reduzir o número de reservas que tem de criar e gerir. Para mais informações, consulte a secção Como funcionam as reservas partilhadas neste documento.
  • Política de partilha

    A política de partilha especifica se uma reserva de VMs com GPU pode ser usada por tarefas de preparação personalizadas ou tarefas de previsão no Vertex AI. Por predefinição, as tarefas de preparação personalizadas ou as tarefas de previsão não podem consumir reservas de VMs com GPU. Para alterar esta situação, veja como criar ou atualizar reservas para serem consumidas no Vertex AI.

  • Contagem de VMs

    A quantidade de VMs é o número de VMs com propriedades correspondentes e a zona que quer reservar quando cria uma reserva. Depois de criar a reserva, pode modificar o número de VMs.

  • Propriedades da VM

    As propriedades da VM descrevem os requisitos de hardware (memória e CPUs) e os recursos opcionais (discos SSD locais e GPUs) para as VMs que quer reservar. Quando cria uma reserva, pode especificar estas propriedades diretamente, especificar as propriedades com base numa VM existente ou especificar as propriedades através de um modelo de instância. Uma VM só pode consumir uma reserva se as propriedades da VM e as propriedades da VM da reserva corresponderem exatamente. Para mais informações, consulte os requisitos neste documento.

  • Opcional: política de posicionamento de recursos (compacta)

    Uma política de posicionamento compacta indica que as VMs reservadas devem estar localizadas o mais perto possível umas das outras para reduzir a latência da rede entre elas.

Quando para, suspende ou elimina uma VM que consome uma reserva, a VM deixa de ser contabilizada para a reserva. A capacidade reservada fica novamente disponível.

Se quiser eliminar uma reserva para libertar a capacidade reservada, mas manter todas as VMs que consomem a reserva, considere o seguinte:

  • Pode eliminar uma reserva consumida automaticamente sem parar nem suspender as VMs. Depois de eliminar a reserva, todas as VMs que a estavam a usar continuam a ser executadas. Continua a incorrer em cobranças por estes.

  • Só pode eliminar uma reserva especificamente segmentada se nenhuma VM a consumir. Se parar ou suspender VMs, depois de eliminar a reserva, só pode reiniciar ou retomar as VMs se criar uma nova reserva especificamente segmentada com um nome, uma zona e propriedades que correspondam à reserva eliminada.

Como funcionam as reservas partilhadas

Cada VM numa reserva partilhada pode ser consumida por uma VM no projeto que criou a reserva (projeto proprietário) ou em qualquer um dos projetos com os quais a reserva é partilhada (projetos consumidores). Quando uma VM deixa de consumir uma reserva partilhada, esta pode ser consumida por uma VM diferente em qualquer um dos projetos com os quais a reserva é partilhada. Se uma reserva partilhada reservar várias VMs, as VMs de vários projetos podem consumir a mesma reserva partilhada em simultâneo.

Por predefinição, os projetos não podem criar nem modificar reservas partilhadas. Para criar e modificar uma reserva partilhada num projeto, o projeto tem de ser adicionado à lista de autorizações da restrição de política organizacional Projetos proprietários de reservas partilhadas (compute.sharedReservationsOwnerProjects). Se partilhar uma reserva, esta é afetada por requisitos de quota adicionais e tem um comportamento de consumo diferente das reservas de projeto único.

Requisitos

Todas as reservas têm os seguintes requisitos:

  • Uma VM só pode consumir uma reserva se todas as seguintes propriedades da VM e da reserva corresponderem exatamente:

    • Projeto

    • Zona

    • Tipo de máquina

    • Plataforma de CPU mínima

    • Tipo e quantidade de GPU (se aplicável)

    • Tipo e quantidade de discos SSD locais (se aplicável)

    • Afinidade de reservas

      • Os requisitos de afinidade de reserva variam consoante o tipo de consumo da reserva.

    • Política de posicionamento compacta (se aplicável)

      • Uma reserva pode incluir opcionalmente uma política de posicionamento compacto para indicar que as respetivas VMs reservadas devem estar localizadas o mais perto possível umas das outras para reduzir a latência da rede entre elas. Se uma reserva especificar uma política de posicionamento compacta, só pode ser consumida por VMs que especifiquem a mesma política de posicionamento compacta.

    • Sugestão de localização (se aplicável)

      • Uma reserva pode incluir opcionalmente o campo locationHint, que só pode especificar quando cria reservas ou VMs através de REST. A Google não recomenda que especifique o campo locationHint quando criar reservas.

  • Tem de ter quota não usada disponível no seu projeto para os recursos que está a reservar. Se a reserva for criada com êxito, a quota para esses recursos é consumida imediatamente.

Requisitos adicionais para reservas associadas a compromissos

Além disso, as reservas associadas a compromissos têm os seguintes requisitos:

  • As reservas têm de ser para o mesmo projeto e região que o compromisso.

  • As reservas têm de ser para a mesma série de famílias de máquinas que o compromisso. No entanto, pode escolher qualquer tipo de máquina nessa série de famílias de máquinas.

  • As reservas têm de ter a opção de eliminação automática desativada.

  • Se o compromisso especificar GPUs, discos SSD locais ou ambos, a reserva anexada (ou a combinação de reservas anexadas) tem de especificar exatamente os mesmos números e tipos desses recursos que o compromisso.

Para saber mais, consulte o artigo Anexe reservas a compromissos baseados em recursos.

Requisitos adicionais para reservas criadas a partir de um modelo de instância

Além disso, se criar uma reserva especificando um modelo de instância, certifique-se do seguinte:

  • Tem de criar a reserva na mesma região, zona e projeto que os recursos no modelo. Em concreto:

    • Todos os recursos regionais ou zonais especificados num modelo de instância, como um tipo de máquina ou um disco, restringem a utilização do modelo às localizações onde esses recursos existem. Por exemplo, se o modelo de instância especificar um disco existente na zona us-central1-a, tem de criar a reserva na mesma zona.

    • Um modelo de instância contém definições específicas do projeto, pelo que só pode aceder e usar um modelo de instância no mesmo projeto. Para os projetos com os quais uma reserva partilhada é partilhada, tem de criar modelos semelhantes nesses projetos ou criar VMs especificando as propriedades diretamente.

  • Se o modelo de instância especificar uma política de posicionamento compacta, tem de criar uma reserva específica. Em seguida, quando criar as VMs para consumir a reserva, tem de segmentar especificamente a reserva por nome. Caso contrário, as VMs não podem consumir a reserva.

Requisitos de quota adicionais para reservas partilhadas

Além disso, existem as seguintes implicações de quota para os projetos proprietário e consumidor de uma reserva partilhada:

  • Projeto proprietário: o projeto proprietário consome a quota da seguinte forma:

    • Quando cria a reserva partilhada, o projeto proprietário consome a quota dos recursos reservados totais.

    • Quando consomem recursos reservados, o projeto proprietário consome a quota dos recursos que consome.

  • Projetos de consumidor: os projetos de consumidor consomem quota apenas quando consomem os recursos reservados e apenas para os recursos que consomem.

Por exemplo, suponha que o projeto A (o projeto proprietário) cria uma reserva partilhada para 10 recursos e partilha a reserva com os projetos B e C (os projetos consumidores). Após a criação da reserva partilhada, o projeto A consome a quota de 10 recursos. Em seguida, se os projetos A e B consumirem 2 recursos reservados cada, os projetos A e B consomem cada um a quota de 2 recursos. No total, o projeto A consome quota para 12 recursos, o projeto B consome quota para 2 recursos e o projeto C consome quota para 0 recursos (uma vez que não consumiu a reserva).

Requisitos adicionais para reservas com políticas de posicionamento compactas

Além disso, para especificar uma política de posicionamento compacto para uma reserva, certifique-se de que cumpre os seguintes requisitos:

  • A política de posicionamento compacto tem de suportar reservas:

    • A política de posicionamento compacto não pode especificar um valor de distância máximo de 1.

    • Não é possível especificar a política de posicionamento compacto em mais do que uma reserva de cada vez.

  • A reserva tem de suportar políticas de posicionamento compactas:

    • Só pode especificar uma política de posicionamento compacta para uma reserva a pedido, de projeto único e especificamente segmentada que não esteja associada a um compromisso.

    • As VMs reservadas pela reserva têm de ser suportadas pela política de posicionamento compacto:

      • A zona da reserva tem de estar dentro da região da política de posicionamento compacto.

      • O número de VMs da reserva não pode exceder o número máximo de VMs suportado pela política de posicionamento compacto.

      • O tipo de máquina da reserva tem de ser suportado por políticas de posicionamento compacto.

Restrições

Todas as reservas têm as seguintes restrições:

  • Só pode usar reservas com os seguintes Cloud de Confiance produtos:

    • Compute Engine
    • Vertex AI

  • Pode reservar até 1000 VMs por reserva.

  • Não pode reservar VMs A4X, A4, A3 Ultra nem A3 High (com menos de 8 GPUs).

  • Só pode reservar VMs A3 Mega, A3 High (8 GPUs) ou A3 Edge através de reservas especificamente segmentadas.

  • Não pode usar reservas com os seguintes recursos do Compute Engine:

    • f1-micro e g1-small tipos de máquinas

    • VMs do Spot ou VMs preemptivas

    • Nós de inquilino único

  • Só pode atualizar a propriedade de afinidade de reserva das VMs para consumir automaticamente qualquer reserva correspondente (ANY_RESERVATION) ou nenhuma reserva (NO_RESERVATION).

Restrições adicionais para reservas associadas a compromissos

Além disso, as reservas associadas a compromissos têm as seguintes restrições:

  • Só pode anexar reservas a compromissos baseados em recursos.

  • Só pode anexar reservas enquanto compra o seu compromisso.

  • Só pode anexar uma reserva específica a um único compromisso.

  • Não pode eliminar nem redimensionar uma reserva associada a um compromisso. Em alternativa, veja como substituir reservas associadas a compromissos.

Para saber mais, consulte o artigo Anexe reservas a compromissos baseados em recursos.

Restrições adicionais para reservas partilhadas

Além disso, as reservas partilhadas têm as seguintes restrições:

  • Só pode partilhar reservas com projetos na mesma organização que o projeto que cria a reserva.

  • Cada reserva partilhada pode ser partilhada com 1 a 100 projetos de consumidor.

  • Para cada organização, pode criar até 100 reservas partilhadas para cada combinação única de propriedades de VMs.

  • Só pode listar as reservas criadas por um projeto específico. Isto significa que cada reserva partilhada só é apresentada no projeto que a criou. Não pode apresentar todas as reservas partilhadas numa organização nem todas as reservas partilhadas com um projeto específico.

  • Se criar uma reserva partilhada especificando um modelo de instância, apenas os utilizadores no seu projeto podem aceder ao mesmo modelo de instância e usá-lo para criar VMs ou outras reservas.

  • Não pode especificar uma política de posicionamento compacta quando cria uma reserva partilhada.

  • Se mover um projeto que estava a usar reservas partilhadas para uma nova organização, as respetivas reservas partilhadas não são migradas para a nova organização. Todas as reservas partilhadas criadas neste projeto são eliminadas e as reservas da organização anterior que foram partilhadas com este projeto não podem ser usadas na nova organização. Para mais informações, consulte o artigo Como funcionam as reservas partilhadas neste documento.

Pode mitigar as limitações de alguns destes requisitos seguindo as práticas recomendadas para reservas partilhadas.

Restrições adicionais para reservas com políticas de posicionamento compactas

Além disso, as reservas que especifiquem uma política de posicionamento compacta têm as seguintes restrições:

  • Não é possível partilhar uma política de posicionamento compacta entre reservas. Em alternativa, tem de usar uma política de posicionamento compacta separada para cada reserva à qual quer aplicar uma política de posicionamento compacta.

  • Só pode especificar políticas de posicionamento compactas. Qualquer outro tipo de políticas de recursos, como programações de instâncias ou programações de capturas de ecrã, não é suportado.

Faturação

As reservas são faturadas à mesma taxa que os respetivos recursos reservados, incluindo os mesmos preços a pedido e cobranças mínimas de 1 minuto como VMs em execução não reservadas.

Uma reserva incorre em custos pelos respetivos recursos reservados durante o tempo em que a reserva existir, independentemente de os recursos estarem ou não a ser usados. Ao consumir uma reserva, uma VM não incorre em cobranças de recursos duplicados, uma vez que a reserva já é faturada pelo custo dos recursos reservados. Para ver detalhes, consulte os preços das VMs.

Além disso, pode monitorizar as tendências de consumo das suas reservas para reduzir os custos desnecessários de recursos desperdiçados ou não utilizados. Para mais informações, consulte Monitorize o consumo de reservas.

Informações de faturação adicionais para reservas partilhadas

Não existem custos adicionais pela utilização de reservas partilhadas. Estas são faturadas ao mesmo preço que as reservas do Compute Engine de projeto único. No entanto, o projeto que recebe a faturação das reservas partilhadas muda com o consumo, uma vez que projetos diferentes podem ser elegíveis para diferentes CUDs.

O projeto de faturação e o preço das reservas partilhadas são geridos da seguinte forma:

  • Projeto de faturação: por predefinição, o projeto proprietário é faturado pela reserva partilhada. No entanto, quando um recurso de uma reserva partilhada está a ser consumido por um projeto consumidor, o projeto consumidor é faturado pela reserva.
  • Descontos de faturação: por predefinição, a faturação usa o preço a pedido. No entanto, se for elegível para receber CUDs para o projeto que está a ser faturado ou para a conta do Cloud Billing associada a esse projeto, é usado o preço com desconto.

O que se segue?