Reservas de recursos zonais do Compute Engine

Neste documento, explicamos o comportamento, os requisitos, as restrições e o faturamento de reservas de recursos zonais do Compute Engine.

Informações gerais

Para garantir que os recursos do Compute Engine estejam disponíveis quando você precisar deles, use reservas. As reservas fornecem um nível muito alto de garantia da capacidade dos recursos zonais do Compute Engine. É possível usar reservas para ajudar a garantir que seu projeto tenha recursos para aumentos futuros na demanda, como nos seguintes casos:

  • Crescimento
  • Picos planejados ou não planejados
  • Migração de um grande número de instâncias de máquina virtual (VM)
  • Backup e recuperação de desastres

Com as reservas, 95% das VMs iniciam em menos de 120 segundos. Cada reserva oferece garantia para uma ou mais VMs com as mesmas propriedades. Depois de criar uma reserva, os recursos reservados ficam disponíveis imediatamente e permanecem disponíveis até que você a exclua. Da mesma forma, você começa a pagar pelos recursos reservados imediatamente e, quando não precisar mais de uma reserva, poderá excluí-la para interromper as cobranças relativas. Enquanto uma VM está consumindo uma reserva, ela não gera cobranças separadas.

Independentemente de quanto você usa os recursos reservados, a reserva impede que outra pessoa use seus recursos reservados. Como uma reserva ocupa recursos tanto quanto VMs em execução não reservadas, os recursos reservados são cobrados com as mesmas taxas sob demanda que a execução de VMs, incluindo quaisquer descontos aplicáveis.

Como funcionam as reservas

Uma reserva fornece garantia de capacidade para uma ou mais VMs do Compute Engine com a configuração especificada. Também é possível usar uma reserva com compromissos do Compute Engine ou outros produtos que usam VMs.

Ao criar uma reserva, você define as seguintes propriedades:

  • Tipo de provisionamento (sob demanda ou futuro)
    • Uma reserva sob demanda (padrão) é provisionada no momento em que você a solicita, se a capacidade solicitada estiver disponível.

    • Uma reserva futura permite solicitar a garantia de capacidade importante ou difícil de conseguir com antecedência. Especificamente, reservas futuras consistem em dois tipos de recursos: solicitações futuras de reserva que, se aprovadas, oferecemreservas criadas automaticamente no seu futuro, com horário especificado. Após o período de reserva solicitado, uma reserva criada automaticamente é excluída automaticamente ou se comporta de maneira semelhante a uma reserva sob demanda.

      O uso de reservas futuras pode fornecer um nível ainda mais alto de garantia na capacidade do que as reservas sob demanda, permitindo que o Google Cloud tenha mais tempo para atender sua solicitação. Para usar reservas futuras, consulte Sobre solicitações de reserva futuras em vez deste documento.

  • Exclusão automática

    A opção exclusão automática especifica a exclusão automática da reserva, independentemente de ser totalmente consumida ou não. Se você ativar a opção de exclusão automática, a reserva será excluída dentro de duas horas a partir da data e hora especificadas. A exclusão automática de reservas pode ser útil para evitar cobranças desnecessárias pelas reservas que não são consumidas por algum tempo.

  • Tipo de consumo (automático ou específico)
    • Uma reserva consumida automaticamente (padrão) pode ser consumida por VMs com uma propriedade de afinidade de reserva que permite consumir automaticamente qualquer uma dessas reservas (padrão).
    • Uma reserva segmentada especificamente só pode ser consumida por VMs com uma propriedade de afinidade de reserva que segmenta essa reserva específica para consumo. O uso de reservas segmentadas especificamente pode facilitar o rastreamento e o controle de quais VMs estão consumindo quais reservas.
  • Tipo de compartilhamento (para um único projeto ou compartilhado)
    • Uma reserva de projeto único (padrão) só pode ser consumida por VMs localizadas no mesmo projeto que a reserva.
    • Uma reserva compartilhada pode ser consumida pelas VMs no projeto em que a reserva está localizada e em qualquer outro projeto com que ela seja compartilhada. O uso de reservas compartilhadas pode ajudar a melhorar a utilização de suas reservas e reduzir o número de reservas que você precisa criar e gerenciar. Para mais informações, consulte Como funcionam as reservas compartilhadas neste documento.
  • Política de compartilhamento

    A política de compartilhamento especifica se uma reserva de VMs A2 ou A3 pode ser consumida por jobs de treinamento personalizado ou jobs de previsão na Vertex AI. Por padrão, os jobs de treinamento ou de previsão personalizados não podem consumir reservas de VMs A2 ou A3. Para mudar isso, consulte como criar ou atualizar reservas para consumo na Vertex AI.

  • Contagem de VMs

    A contagem de VMs é o número de VMs com propriedades e zona correspondentes que você quer reservar ao criar uma reserva. Depois de criar a reserva, também é possível modificar a contagem de VMs.

  • Propriedades da VM

    As propriedades da VM definem os requisitos de hardware (memória e CPUs) e recursos opcionais (discos SSD locais e GPUs) para as VMs que você quer reserva. Ao criar uma solicitação de reserva futura, especifique essas propriedades diretamente, com base em uma VMou usando 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 Requisitos neste documento.

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

    Uma política de posicionamento compacta indica que as VMs reservadas precisam estar localizadas o mais próximo possível uma da outra para reduzir a latência de rede entre elas.

Depois de criar uma reserva, esteja ciente do seguinte:

  • Se você interromper, suspender ou excluir uma VM que esteja consumindo uma reserva, ela não será mais contabilizada na reserva. Os recursos consumidos anteriormente ficarão disponíveis de novo para consumo após a interrupção, suspensão ou exclusão da VM.

  • Se você excluir uma reserva, mas não excluir as VMs que estão usando os recursos reservados, as VMs permanecerão e você será cobrado pelos recursos como de costume.

Como funcionam as reservas compartilhadas

Cada VM em uma reserva compartilhada pode ser consumida por uma VM no projeto que criou a reserva (projeto de proprietário) ou em qualquer projeto com que a reserva foi compartilhada (projetos de cliente). Quando uma VM para de consumir uma reserva compartilhada, ela pode ser consumida por uma VM diferente em qualquer um dos projetos com que a reserva for compartilhada. Se uma reserva compartilhada reservar várias VMs, as VMs de vários projetos poderão consumir a mesma reserva compartilhada simultaneamente.

Por padrão, os projetos não podem criar e modificar reservas compartilhadas. Para criar e modificar uma reserva compartilhada em um projeto, esse projeto precisa ser adicionado à lista de permissões da restrição de políticas da organização de Projetos de proprietário de reservas compartilhadas (compute.sharedReservationsOwnerProjects). O compartilhamento de uma reserva é afetado por requisitos de cota adicionais e apresenta um comportamento de consumo diferente das reservas de projeto único.

Requisitos

Todas as reservas têm os requisitos a seguir:

  • Uma instância de VM pode consumir uma reserva apenas se todas as seguintes propriedades da VM e da reserva corresponderem exatamente:

    • Projeto

      • *Os requisitos do projeto variam de acordo com o tipo de compartilhamento da reserva.

    • Zona

    • Tipo de máquina

    • Plataforma mínima de CPU

    • Tipo e contagem de GPU (se houver)

    • Tipo e contagem de disco SSD local (se houver)

    • Afinidade de reserva

    • Política de posicionamento compacto (se houver)

      • Como alternativa, uma reserva tem a opção de incluir uma política de posicionamento compacto para indicar que as VMs reservadas precisam estar localizadas o mais próximo possível uma da outra para reduzir a latência de rede entre elas. Se uma reserva especificar uma política de posicionamento compacto, ela só poderá ser consumida por VMs que especificarem a mesma política de posicionamento compacto.

    • Sugestão de local (se houver)

      • Uma reserva pode incluir o campo locationHint, que só pode ser especificado ao criar reservas ou VMs usando REST. O Google não recomenda especificar o campo locationHint ao criar reservas.

  • Você precisa ter cota suficiente em seu projeto para os recursos que está reservando. Se a reserva for criada com sucesso, a cota desse recurso será cobrada de modo proporcional.

Outros requisitos para reservas anexadas a compromissos

Além disso, as reservas anexadas a compromissos têm estes requisitos:

  • As reservas precisam ser para o mesmo projeto e região que o compromisso.

  • As reservas precisam ser para a mesma série da família de máquinas que o compromisso. No entanto, é possível escolher qualquer tipo de máquina dentro dessa série.

  • A opção de exclusão automática precisa estar desativada nas reservas.

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

Para saber mais, consulte Anexar reservas a compromissos baseados em recursos.

Outros requisitos para reservas criadas com base em um modelo de instância

Além disso, se você criar uma reserva especificando um modelo de instância, verifique o seguinte:

  • Crie sua reserva na mesma região, zona e projeto que os recursos do modelo. Especificamente:

    • Todos os recursos regionais ou zonais especificados em um modelo de instância, como um tipo de máquina ou um disco, restringem o uso do modelo aos locais onde existem esses recursos. Por exemplo, se o modelo de instância especificar um disco existente na zona us-central1-a, será necessário criar sua reserva na mesma zona.

    • Um modelo de instância contém configurações específicas do projeto. Portanto, só é possível acessar e usar um modelo de instância no mesmo projeto. Para os projetos com os quais uma reserva é compartilhada, crie modelos semelhantes nesses projetos ou crie VMs especificando propriedades diretamente.

  • Se o modelo de instância determina uma política de posicionamento compacto, é preciso criar uma reserva específica. Em seguida, ao criar as VMs para consumir a reserva, segmente-a especificamente por nome. Caso contrário, as VMs não poderão consumir a reserva.

Requisitos de cota adicional para reservas compartilhadas

Além disso, há implicações específicas de cota para os projetos proprietários e consumidores de uma reserva compartilhada.

  • Projeto do proprietário: o projeto do proprietário consome a cota da seguinte maneira:

    • Ao criar a reserva compartilhada, o projeto proprietário consome a cota do total de recursos reservados.

    • Ao consumir recursos reservados, o projeto proprietário consome a cota dos recursos que consome.

  • Projetos consumidores: os projetos consumidores consomem cota apenas quando consomem os recursos reservados e apenas pelos recursos que consomem.

Por exemplo, vamos supor que o projeto A (o projeto proprietário) crie uma reserva compartilhada para 10 recursos e a compartilhe com os projetos B e C (os projetos consumidores). Ao criar a reserva compartilhada, o projeto A consome a cota de 10 recursos. Se os projetos A e B consumirem 2 recursos reservados cada, eles vão consumir a cota de 2 recursos. No total, o projeto A consome cota para 12 recursos, o projeto B consome cota para 2 recursos e o projeto C consome cota para 0 recursos (já 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, verifique os seguintes requisitos:

  • A política de posicionamento compacto precisa aceitar reservas:

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

    • A política de posicionamento compacto não pode ser especificada por mais de uma reserva por vez.

  • A reserva precisa ser compatível com políticas de posicionamento compactas:

    • Só é possível especificar uma política de posicionamento compacto para uma reserva específica, sob demanda, de projeto único e que não esteja anexada a um compromisso.

    • As VMs reservadas pela reserva precisam ser compatíveis com a política de posicionamento compacto:

      • A zona da reserva precisa 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 compatível com a política de posicionamento compacto.

      • O tipo de máquina da reserva precisa ser compatível com as políticas de posicionamento compacto.

Restrições

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

  • É possível reservar até 1.000 VMs por reserva.

  • Só é possível reservar VMs A3 com reservas on demand e segmentadas especificamente.

  • As reservas se aplicam apenas ao uso de VMs nos seguintes produtos do Google Cloud:

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

  • As reservas não se aplicam a estes recursos:

    • Tipos de máquina f1-micro e g1-small
    • VMs preemptivas
    • Nós de locatário individual
    • Outros serviços não listados anteriormente, como o Cloud SQL

  • O Compute Engine tenta alocar recursos sob demanda quando você cria uma reserva. Se não houver recursos suficientes na zona no momento da solicitação, a reserva falhará com um erro de disponibilidade de recursos insuficiente. Se a reserva for criada, os recursos ficarão disponíveis para uso mesmo que você não os utilize imediatamente.

Outras restrições para reservas anexadas a compromissos

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

  • Só é possível anexar reservas a compromissos baseados em recursos.

  • É possível anexar reservas somente enquanto você está comprando seu compromisso.

  • É possível anexar uma reserva específica a somente um único compromisso.

  • Não é possível excluir ou redimensionar uma reserva anexada a um compromisso. Em vez disso, veja como substituir reservas anexadas a compromissos.

Para saber mais, consulte Anexar reservas a compromissos baseados em recursos.

Outras restrições para reservas compartilhadas

Além disso, as reservas compartilhadas têm estas restrições:

  • Só é possível compartilhar reservas com projetos da mesma organização do projeto que criou a reserva.

  • Cada reserva compartilhada pode ser compartilhada com 1 a 100 projetos do consumidor.

  • Para cada organização, é possível criar até 100 reservas compartilhadas para cada combinação exclusiva de propriedades da VM.

  • Só é possível listar as reservas criadas por um projeto específico. Isso significa que cada reserva compartilhada é listada apenas no projeto que a criou. Não é possível listar todas as reservas compartilhadas de uma organização ou todas as reservas que são compartilhadas com um projeto específico.

  • Se você criar uma reserva compartilhada especificando um modelo de instância, somente os usuários em seu projeto poderão acessar o mesmo modelo de instância e usá-lo para criar VMs ou outras reservas.

  • Não é possível especificar uma política de posicionamento compacta ao criar uma reserva compartilhada.

  • Se você passar um projeto que estava usando reservas compartilhadas para uma nova organização, as reservas compartilhadas não serão migradas para a nova organização. Todas as reservas compartilhadas criadas nesse projeto serão excluídas e as reservas da organização anterior que foram compartilhadas com esse projeto não poderão ser consumidas na nova organização. Para mais informações, consulte Como funcionam as reservas compartilhadas neste documento.

É possível reduzir as limitações de alguns desses requisitos seguindo as práticas recomendadas para reservas compartilhadas.

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

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

  • Não é possível compartilhar uma política de posicionamento compacto entre as reservas. Em vez disso, use uma política de posicionamento compacto separada para cada reserva à qual você quiser aplicar umaa política de posicionamento compacto.

  • Só é possível especificar políticas de posicionamento compactas. Qualquer outro tipo de política de recursos, como programações de instâncias ou snapshots, não é compatível.

Faturamento

As reservas são cobradas com a mesma taxa que os recursos reservados, inclusive os mesmos preços sob demanda e as cobranças mínimas de um minuto das VMs não reservadas em execução. Desconto por uso prolongado (SUDs), CUDs e preços personalizados também se aplicam à execução de VMs.

Por exemplo, suponha que você tenha o seguinte cenário:

  • Você tem um compromisso de 3 vCPUs em us-central1.
  • Você está executando 5 vCPUs em us-central1-a.
  • Você tem uma reserva de 10 vCPUs em us-central1-a.

Reservas que incluem descontos por compromisso de uso.

Nesse cenário, o Google Cloud vai cobrar da seguinte forma:

Coberto por Número de vCPUs
Preço com desconto por compromisso de uso 3
Preço sob demanda (duas vCPUs usaram reservas + cinco reservas sem uso de vCPU) 7

Uma reserva incorre em cobranças pelos recursos reservados enquanto ela existir, independentemente de os recursos estarem sendo usados ou não. Ao consumir uma reserva, uma VM não gera cobranças de recursos duplicadas, já que a reserva já é cobrada pelo custo dos recursos reservados. Para mais detalhes, consulte os preços das VMs.

Além disso, é possível monitorar as tendências de consumo das reservas para reduzir custos desnecessários de recursos desperdiçados ou não utilizados. Para mais informações, consulte Monitorar o consumo de reservas.

Outras informações de faturamento para reservas compartilhadas

Não há cobranças extras pelo uso de reservas compartilhadas. Elas são cobradas pelo mesmo preço das reservas de projeto único do Compute Engine. No entanto, o projeto faturado pelas reservas compartilhadas muda com o consumo, já que projetos diferentes podem se qualificar para CUDs distintos.

O projeto de faturamento e o preço das reservas compartilhadas são processados da seguinte maneira:

  • Projeto de faturamento: por padrão, o projeto de proprietário é cobrado pela reserva compartilhada. Porém, quando um recurso de uma reserva compartilhada está sendo consumido por um projeto do consumidor, este projeto passa a ser cobrado pela reserva.
  • Descontos de faturamento: por padrão, o faturamento usa o preço sob demanda. No entanto, se você se qualificar para receber CUDs para o projeto que está sendo faturado ou para a conta do Cloud Billing associada a esse projeto, o preço com desconto será usado.

A seguir