Reservas de recursos zonais do Compute Engine,Reservas de recursos zonais do Compute Engine

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este documento explica o comportamento, os requisitos, as restrições e o faturamento das reservas dos recursos zonais do Compute Engine.

Use reservas para obter um alto nível de garantia de que as instâncias de máquinas virtuais (VM) com as mesmas propriedades estarão disponíveis em uma zona específica quando você precisar delas. As reservas são úteis para escalabilidade, migrações ou recuperação de desastres.

Visão geral

As reservas ajudam a garantir que você tenha os recursos disponíveis para criar VMs com o mesmo hardware (memória e vCPUs) e recursos opcionais (GPUs e discos SSD locais) sempre que precisar deles. As reservas oferecem os seguintes benefícios:

• Alta garantia de capacidade : Os recursos são reservados para futuros aumentos na demanda, como crescimento, picos planejados ou não planejados, migrações de um grande número de VMs ou backup e recuperação de desastres.

• Acesso exclusivo : As reservas impedem que outras pessoas utilizem seus recursos reservados.

• Propriedades herdadas : as reservas herdam as mesmas propriedades da família de máquinas escolhida.

Ao criar uma reserva, o Compute Engine verifica se a capacidade solicitada está disponível na zona especificada. Nesse caso, o Compute Engine reserva os recursos, cria a reserva e acontece o seguinte:

• Você pode consumir imediatamente os recursos reservados e eles permanecerão disponíveis até você excluir a reserva.

• Você será cobrado pelos recursos reservados na mesma taxa sob demanda das VMs em execução, incluindo quaisquer descontos aplicáveis, até que a reserva seja excluída. Uma VM que consome uma reserva não incorre em cobranças separadas.

Como funcionam as reservas

Uma reserva fornece um alto nível de garantia de capacidade para uma ou mais VMs com a configuração especificada pelo usuário.Você também pode 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 da solicitação, se a capacidade solicitada estiver disponível.

  • Uma reserva futura permite solicitar antecipadamente uma garantia de alto nível de capacidade importante ou difícil de obter. Especificamente, as reservas futuras consistem em dois tipos de recursos: solicitações de reservas futuras que, se aprovadas, fornecem reservas criadas automaticamente (criadas automaticamente) em seu horário futuro 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.

    A utilização de reservas futuras pode proporcionar um nível de garantia ainda mais elevado na obtenção de capacidade do que as reservas a pedido, permitindo Google Cloudmais tempo para atender sua solicitação. Se você quiser usar reservas futuras, consulte Sobre solicitações de reservas futuras em vez deste documento.

• Excluir automaticamente

  A opção de exclusão automática especifica a exclusão automática da reserva, independentemente de ela estar 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 por padrão ou em uma data e hora personalizadas. A exclusão automática de reservas pode ser útil para evitar cobranças desnecessárias pelas reservas que não são consumidas há 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 lhes permite consumir automaticamente qualquer uma dessas reservas. Este tipo de consumo é útil se você criar e excluir muitas VMs e quiser consumir suas reservas sempre que possível.
  • Uma reserva especificamente direcionada só pode ser consumida por VMs com uma propriedade de afinidade de reserva direcionada a essa reserva específica. Este tipo de consumo facilita rastrear e controlar quais VMs consomem quais reservas.
• Tipo de compartilhamento (projeto único 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 por VMs no projeto onde a reserva está localizada e em qualquer outro projeto com o qual a reserva seja compartilhada. O uso de reservas compartilhadas pode ajudar a melhorar a utilização das suas reservas e reduzir o número de reservas que você precisa criar e gerenciar. Para obter 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 de GPU pode ser consumida por jobs de treinamento personalizados ou de previsão na Vertex AI. Por padrão, os trabalhos de formação personalizados ou de previsão não podem consumir reservas de VMs GPU. Para mudar isso, veja como criar ou atualizar reservas para serem consumidas na Vertex AI .

• Contagem de VMs

  A contagem de VMs é o número de VMs com propriedades e zonas correspondentes que você deseja reservar ao criar uma reserva. Depois de criar a reserva, você poderá modificar a contagem de VMs .

• Propriedades da VM

  As propriedades da VM descrevem os requisitos de hardware (memória e CPUs) e recursos opcionais (discos SSD locais e GPUs) para as VMs que você deseja reservar. Ao criar uma reserva, você pode especificar essas propriedades diretamente, especificar as propriedades com base em uma VM existente ou especificar as propriedades usando um modelo de instância . Uma VM só poderá consumir uma reserva se as propriedades da VM e as propriedades da VM da reserva corresponderem exatamente . Para obter mais informações, consulte Requisitos neste documento.

• Opcional: Política de colocação de recursos (compacto)

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

Quando você interrompe, suspende ou exclui uma VM que consome uma reserva, a VM não conta mais para a reserva. A capacidade reservada fica disponível novamente.

Se quiser eliminar uma reserva para libertar a capacidade reservada, mas manter quaisquer VMs que consumam a reserva, considere o seguinte:

• Você pode excluir uma reserva consumida automaticamente sem parar ou suspender VMs. Depois de excluir a reserva, todas as VMs que a estavam consumindo continuarão em execução. Você continua cobrando por eles.

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

Como funcionam as reservas compartilhadas

Cada VM em uma reserva compartilhada 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 é compartilhada ( projetos consumidores ). Quando uma VM deixa de consumir uma reserva partilhada, a reserva partilhada pode ser consumida por uma VM diferente em qualquer um dos projetos com os quais a reserva é partilhada. Se uma reserva partilhada reservar vários VMs, os VM de vários projetos poderão consumir a mesma reserva partilhada simultaneamente.

Por padrão, os projetos não podem criar e modificar reservas compartilhadas. Para criar e modificar uma reserva compartilhada em um projeto, o projeto deve ser adicionado à lista de permissões da restrição de política organizacional Projetos de Proprietários de Reservas Compartilhadas ( compute.sharedReservationsOwnerProjects ) . Se você compartilhar uma reserva, ela será afetada por requisitos de cota adicionais e terá um comportamento de consumo diferente das reservas de projeto único.

Requisitos

Todas as reservas têm os seguintes requisitos:

• Uma VM poderá consumir uma reserva somente se todas as propriedades a seguir 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

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

  • Política de posicionamento compacto (se houver)

    • Opcionalmente, uma reserva pode incluir uma política de posicionamento compacto para indicar que suas VMs reservadas devem estar localizadas o mais próximas possível umas das outras para reduzir a latência da rede entre elas. Se uma reserva especificar uma política de posicionamento compacto, ela só poderá ser consumida por VMs que especifiquem a mesma política de posicionamento compacto.

  • Dica de localização (se houver)

    • Opcionalmente, uma reserva pode incluir o campo locationHint , que você só pode especificar ao criar reservas ou VMs usando REST. O Google não recomenda especificar o campo locationHint ao criar reservas.

• Você deve ter uma cota não utilizada disponível em seu projeto para os recursos que está reservando. Se a reserva for criada com êxito, a cota desses recursos será consumida imediatamente.

Requisitos adicionais para reservas associadas a compromissos

Além disso, as reservas anexas aos compromissos têm os seguintes requisitos:

• As reservas devem ser para o mesmo projeto e região do compromisso.

• As reservas devem ser para a mesma série de família de máquinas do compromisso. No entanto, você pode escolher qualquer tipo de máquina dentro da série dessa família de máquinas.

• As reservas deverão ter a opção de exclusão automática desabilitada.

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

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

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

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

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

  • Quaisquer 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 esses recursos existem. Por exemplo, se o seu modelo de instância especificar um disco existente na zona us-central1-a , você deverá criar sua reserva na mesma zona.

  • Um modelo de instância contém configurações específicas do projeto, portanto você só pode acessar e usar um modelo de instância dentro do mesmo projeto. Para os projetos com os quais uma reserva compartilhada é compartilhada, você deve criar modelos semelhantes nesses projetos ou criar VMs especificando propriedades diretamente.

• Se o modelo de instância especificar uma política de colocação compacta, você deverá criar uma reserva específica . Então, ao criar as VMs para consumir a reserva, você deverá direcionar especificamente a reserva por nome. Caso contrário, as VMs não poderão consumir a reserva.

Requisitos adicionais de cota para reservas compartilhadas

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

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

  • 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 somente quando consomem os recursos reservados e somente para os recursos que consomem.

Por exemplo, suponha que o projeto A (o projeto proprietário) crie uma reserva compartilhada para 10 recursos e compartilhe a reserva com os projetos B e C (os projetos consumidores). Ao criar a reserva compartilhada, o projeto A consome cota de 10 recursos. Então, se os projetos A e B consumirem 2 recursos reservados cada, os projetos A e B consumirão cota de 2 recursos cada. No total, o projeto A consome cota de 12 recursos, o projeto B consome cota de 2 recursos e o projeto C consome cota de 0 recursos (pois não consumiu a reserva).

Requisitos adicionais para reservas com políticas de colocação compactas

Além disso, para especificar uma política de posicionamento compacta para uma reserva, certifique-se dos seguintes requisitos:

• A política de colocação compacta deve apoiar reservas:

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

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

• A reserva deve suportar políticas de colocação compactas:

  • Você só pode especificar uma política de colocação compacta para uma reserva sob demanda, de projeto único e especificamente direcionada, que não esteja anexada a um compromisso.

  • As VMs reservadas pela reserva devem ser suportadas pela política de posicionamento compacto:

    • A zona da reserva deverá estar dentro da região da política de colocação compacta.

    • 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 deve ser suportado por políticas de colocação compactas.

Restrições

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

• Você só pode usar reservas com os seguintes Google Cloudprodutos:

  • Lote
  • Mecanismo de computação
  • Fluxo de dados
  • Dataproc
  • Motor Kubernetes do Google
  • Vértice AI

• Você pode reservar até 1.000 VMs por reserva.

• Você só pode reservar VMs A4 e A3 Ultra por meio de solicitações de reserva futuras, conforme descrito na documentação do AI Hypercomputer sobre como solicitar capacidade .

• Você só pode reservar VMs A3 Mega, A3 High ou A3 Edge por meio de reservas sob demanda e direcionadas especificamente .

• Não é possível usar reservas com os seguintes recursos do Compute Engine:

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

  • VMs spot ou VMs preemptivas

  • Nós de locatário individual

• Você 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 vinculadas aos compromissos têm as seguintes restrições:

• Você pode anexar reservas somente a compromissos baseados em recursos.

• Você pode anexar reservas somente enquanto estiver adquirindo seu compromisso.

• Você pode anexar uma reserva específica a apenas um único compromisso.

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

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

Restrições adicionais para reservas compartilhadas

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

• Você só pode compartilhar reservas com projetos da mesma organização do projeto que cria a reserva.

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

• Para cada organização, você pode criar até 100 reservas compartilhadas para cada combinação exclusiva de propriedades de VM .

• Você só pode 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 em uma organização ou todas as reservas compartilhadas com um projeto específico.

• Se você criar uma reserva compartilhada especificando um modelo de instância , somente os usuários do 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 compacto ao criar uma reserva compartilhada.

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

Você pode mitigar as limitações de alguns desses requisitos seguindo as práticas recomendadas para reservas compartilhadas .

Restrições adicionais para reservas com políticas de colocação compactas

Além disso, as reservas que especificam uma política de colocação compacta têm as seguintes restrições:

• Não é possível compartilhar uma política de posicionamento compacta entre reservas. Em vez disso, você deve usar uma política de posicionamento compacto separada para cada reserva à qual deseja aplicar uma política de posicionamento compacto.

• Você só pode especificar políticas de posicionamento compacto. Qualquer outro tipo de política de recursos, como agendas de instâncias ou agendas de instantâneos, não é compatível.

Cobrança

As reservas são cobradas à mesma taxa que os seus recursos reservados, incluindo os mesmos preços sob demanda e cobranças mínimas de 1 minuto que as VMs em execução não reservadas.Descontos por uso prolongado (SUDs) , CUDs e preços personalizados também se aplicam como seriam para VMs em execução.

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

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

Neste cenário, Google Cloud cobra você da seguinte forma:

Uma reserva incorre em encargos pelos seus recursos reservados enquanto a reserva existir, independentemente de os seus recursos estarem ou não a ser utilizados. Ao consumir uma reserva, uma VM não incorre em cobranças duplicadas de recursos, uma vez que a reserva já é cobrada pelo custo dos recursos reservados. Para obter detalhes, consulte preços de VMs .

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

Informações adicionais de cobrança para reservas compartilhadas

Não há cobranças adicionais pelo uso de reservas compartilhadas. Elas são cobradas pelo mesmo preço das reservas de projeto único do Compute Engine. Porém, o projeto cobrado pelas reservas compartilhadas muda de acordo com o consumo, pois projetos diferentes podem se qualificar para CUDs diferentes.

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

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

O que vem a seguir

• Aprenda como criar reservas:
  • Crie uma reserva para um único projeto .
  • Crie uma reserva compartilhada .

Este documento explica o comportamento, os requisitos, as restrições e o faturamento das reservas dos recursos zonais do Compute Engine.

Use reservas para obter um alto nível de garantia de que as instâncias de máquinas virtuais (VM) com as mesmas propriedades estarão disponíveis em uma zona específica quando você precisar delas. As reservas são úteis para escalabilidade, migrações ou recuperação de desastres.

Visão geral

As reservas ajudam a garantir que você tenha os recursos disponíveis para criar VMs com o mesmo hardware (memória e vCPUs) e recursos opcionais (GPUs e discos SSD locais) sempre que precisar deles. As reservas oferecem os seguintes benefícios:

• Alta garantia de capacidade : Os recursos são reservados para futuros aumentos na demanda, como crescimento, picos planejados ou não planejados, migrações de um grande número de VMs ou backup e recuperação de desastres.

• Acesso exclusivo : As reservas impedem que outras pessoas utilizem seus recursos reservados.

• Propriedades herdadas : as reservas herdam as mesmas propriedades da família de máquinas escolhida.

Ao criar uma reserva, o Compute Engine verifica se a capacidade solicitada está disponível na zona especificada. Nesse caso, o Compute Engine reserva os recursos, cria a reserva e acontece o seguinte:

• Você pode consumir imediatamente os recursos reservados e eles permanecerão disponíveis até você excluir a reserva.

• Você será cobrado pelos recursos reservados na mesma taxa sob demanda das VMs em execução, incluindo quaisquer descontos aplicáveis, até que a reserva seja excluída. Uma VM que consome uma reserva não incorre em cobranças separadas.

Como funcionam as reservas

Uma reserva fornece um alto nível de garantia de capacidade para uma ou mais VMs com a configuração especificada pelo usuário.Você também pode 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 da solicitação, se a capacidade solicitada estiver disponível.

  • Uma reserva futura permite solicitar antecipadamente uma garantia de alto nível de capacidade importante ou difícil de obter. Especificamente, as reservas futuras consistem em dois tipos de recursos: solicitações de reservas futuras que, se aprovadas, fornecem reservas criadas automaticamente (criadas automaticamente) em seu horário futuro 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.

    A utilização de reservas futuras pode proporcionar um nível de garantia ainda mais elevado na obtenção de capacidade do que as reservas a pedido, permitindo Google Cloudmais tempo para atender sua solicitação. Se você quiser usar reservas futuras, consulte Sobre solicitações de reservas futuras em vez deste documento.

• Excluir automaticamente

  A opção de exclusão automática especifica a exclusão automática da reserva, independentemente de ela estar 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 por padrão ou em uma data e hora personalizadas. A exclusão automática de reservas pode ser útil para evitar cobranças desnecessárias pelas reservas que não são consumidas há 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 lhes permite consumir automaticamente qualquer uma dessas reservas. Este tipo de consumo é útil se você criar e excluir muitas VMs e quiser consumir suas reservas sempre que possível.
  • Uma reserva especificamente direcionada só pode ser consumida por VMs com uma propriedade de afinidade de reserva direcionada a essa reserva específica. Este tipo de consumo facilita rastrear e controlar quais VMs consomem quais reservas.
• Tipo de compartilhamento (projeto único 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 por VMs no projeto onde a reserva está localizada e em qualquer outro projeto com o qual a reserva seja compartilhada. O uso de reservas compartilhadas pode ajudar a melhorar a utilização das suas reservas e reduzir o número de reservas que você precisa criar e gerenciar. Para obter 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 de GPU pode ser consumida por jobs de treinamento personalizados ou de previsão na Vertex AI. Por padrão, os trabalhos de formação personalizados ou de previsão não podem consumir reservas de VMs GPU. Para mudar isso, veja como criar ou atualizar reservas para serem consumidas na Vertex AI .

• Contagem de VMs

  A contagem de VMs é o número de VMs com propriedades e zonas correspondentes que você deseja reservar ao criar uma reserva. Depois de criar a reserva, você poderá modificar a contagem de VMs .

• Propriedades da VM

  As propriedades da VM descrevem os requisitos de hardware (memória e CPUs) e recursos opcionais (discos SSD locais e GPUs) para as VMs que você deseja reservar. Ao criar uma reserva, você pode especificar essas propriedades diretamente, especificar as propriedades com base em uma VM existente ou especificar as propriedades usando um modelo de instância . Uma VM só poderá consumir uma reserva se as propriedades da VM e as propriedades da VM da reserva corresponderem exatamente . Para obter mais informações, consulte Requisitos neste documento.

• Opcional: Política de colocação de recursos (compacto)

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

Quando você interrompe, suspende ou exclui uma VM que consome uma reserva, a VM não conta mais para a reserva. A capacidade reservada fica disponível novamente.

Se quiser eliminar uma reserva para libertar a capacidade reservada, mas manter quaisquer VMs que consumam a reserva, considere o seguinte:

• Você pode excluir uma reserva consumida automaticamente sem parar ou suspender VMs. Depois de excluir a reserva, todas as VMs que a estavam consumindo continuarão em execução. Você continua cobrando por eles.

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

Como funcionam as reservas compartilhadas

Cada VM em uma reserva compartilhada 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 é compartilhada ( projetos consumidores ). Quando uma VM deixa de consumir uma reserva partilhada, a reserva partilhada pode ser consumida por uma VM diferente em qualquer um dos projetos com os quais a reserva é partilhada. Se uma reserva partilhada reservar vários VMs, os VM de vários projetos poderão consumir a mesma reserva partilhada simultaneamente.

Por padrão, os projetos não podem criar e modificar reservas compartilhadas. Para criar e modificar uma reserva compartilhada em um projeto, o projeto deve ser adicionado à lista de permissões da restrição de política organizacional Projetos de Proprietários de Reservas Compartilhadas ( compute.sharedReservationsOwnerProjects ) . Se você compartilhar uma reserva, ela será afetada por requisitos de cota adicionais e terá um comportamento de consumo diferente das reservas de projeto único.

Requisitos

Todas as reservas têm os seguintes requisitos:

• Uma VM poderá consumir uma reserva somente se todas as propriedades a seguir 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

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

  • Política de posicionamento compacto (se houver)

    • Opcionalmente, uma reserva pode incluir uma política de posicionamento compacto para indicar que suas VMs reservadas devem estar localizadas o mais próximas possível umas das outras para reduzir a latência da rede entre elas. Se uma reserva especificar uma política de posicionamento compacto, ela só poderá ser consumida por VMs que especifiquem a mesma política de posicionamento compacto.

  • Dica de localização (se houver)

    • Opcionalmente, uma reserva pode incluir o campo locationHint , que você só pode especificar ao criar reservas ou VMs usando REST. O Google não recomenda especificar o campo locationHint ao criar reservas.

• Você deve ter uma cota não utilizada disponível em seu projeto para os recursos que está reservando. Se a reserva for criada com êxito, a cota desses recursos será consumida imediatamente.

Requisitos adicionais para reservas associadas a compromissos

Além disso, as reservas anexas aos compromissos têm os seguintes requisitos:

• As reservas devem ser para o mesmo projeto e região do compromisso.

• As reservas devem ser para a mesma série de família de máquinas do compromisso. No entanto, você pode escolher qualquer tipo de máquina dentro da série dessa família de máquinas.

• As reservas deverão ter a opção de exclusão automática desabilitada.

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

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

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

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

• Você deve criar sua reserva na mesma região, zona e projeto que os recursos dentro do modelo. Especificamente:

  • Quaisquer 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 nos locais onde esses recursos existem. Por exemplo, se o seu modelo de instância especificar um disco existente na zona us-central1-a , você deverá criar sua reserva na mesma zona.

  • Um modelo de instância contém configurações específicas do projeto, portanto você só pode acessar e usar um modelo de instância dentro do mesmo projeto. Para os projetos com os quais uma reserva compartilhada é compartilhada, você deve criar modelos semelhantes nesses projetos ou criar VMs especificando propriedades diretamente.

• Se o modelo de instância especificar uma política de colocação compacta, você deverá criar uma reserva específica . Então, quando você cria as VMs para consumir a reserva, você deve direcionar especificamente a reserva pelo nome. Caso contrário, as VMs não podem consumir a reserva.

Requisitos de cotas adicionais para reservas compartilhadas

Além disso, existem as seguintes implicações de cotas para os projetos proprietários e consumidores de uma reserva compartilhada:

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

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

  • Ao consumir recursos reservados, o projeto do proprietário consome cotas para os recursos que consome.

• Projetos de consumo : os projetos de consumidores consomem cota apenas ao consumir os recursos reservados e apenas para os recursos que eles consomem.

Por exemplo, suponha que o projeto A (o projeto do proprietário) crie uma reserva compartilhada para 10 recursos e compartilha a reserva com o projeto B e C (os projetos de consumo). Ao criar a reserva compartilhada, o Projeto A consome cotas para 10 recursos. Então, se o Projeto A e B consumirem 2 recursos reservados cada, o projeto A e B, cada um consuma cota para 2 recursos. No total, o Projeto A consome cotas para 12 recursos, o Projeto B consome cotas para 2 recursos e o Projeto C consome cotas para 0 recursos (pois não consome a reserva).

Requisitos adicionais para reservas com políticas de colocação compactas

Além disso, para especificar uma política de colocação compacta para uma reserva, verifique se os seguintes requisitos:

• A política de colocação compacta deve apoiar reservas:

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

  • A política de colocação compacta não pode ser especificada por mais de uma reserva por vez.

• A reserva deve apoiar políticas de colocação compactas:

  • Você pode especificar apenas uma política de colocação compacta para uma reserva sob demanda, destaque e direcionada especificamente que não está anexada a um compromisso.

  • As VMs reservadas pela reserva devem ser apoiadas pela política de colocação compacta:

    • A zona da reserva deve estar dentro da região da política de colocação compacta.

    • O número de VMs da reserva não pode exceder o número máximo de VMs que a política de colocação compacta suporta.

    • O tipo de máquina da reserva deve ser suportado por políticas de colocação compactas.

Restrições

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

• Você só pode usar reservas com o seguinte Google Cloudprodutos:

  • Lote
  • Mecanismo de computação
  • Fluxo de dados
  • DataPROC
  • Motor Kubernetes do Google
  • Vértice AI

• Você pode reservar até 1.000 VMs por reserva.

• Você só pode reservar VMs A4 e A3 Ultra através de futuras solicitações de reserva, conforme descrito na documentação da IA ​​Hypercomputer sobre como solicitar capacidade .

• Você só pode reservar VMs A3 Mega, A3 High ou A3 Edge através de reservas sob demanda e especificamente direcionadas .

• Você não pode usar reservas com os seguintes recursos de mecanismo de computação:

  • Tipos de máquina f1-micro e g1-small

  • Spot VMs ou VMs preventíveis

  • Nós soldados-inquilinos

• Você só pode atualizar a propriedade de afinidade da reserva das VMs para consumir automaticamente qualquer reserva correspondente ( ANY_RESERVATION ) ou sem reservas ( NO_RESERVATION ).

Restrições adicionais para reservas anexadas a compromissos

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

• Você pode anexar reservas apenas a compromissos baseados em recursos.

• Você pode anexar reservas apenas enquanto compra seu compromisso.

• Você pode anexar uma reserva específica a apenas um único compromisso.

• Você não pode excluir ou redimensionar uma reserva anexada a um compromisso. Em vez disso, consulte como substituir as reservas anexadas a compromissos .

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

Restrições adicionais para reservas compartilhadas

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

• Você só pode compartilhar reservas com projetos na mesma organização que o projeto que cria a reserva.

• Cada reserva compartilhada pode ser compartilhada com 1 a 100 projetos de consumo.

• Para cada organização, você pode criar até 100 reservas compartilhadas para cada combinação única de propriedades da VM .

• Você só pode listar as reservas criadas por um projeto específico . Isso significa que cada reserva compartilhada está listada apenas no projeto que o criou - você não pode listar todas as reservas compartilhadas em uma organização ou em todas as reservas compartilhadas com um projeto específico.

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

• Você não pode especificar uma política de colocação compacta ao criar uma reserva compartilhada.

• Se você mover um projeto que estava usando reservas compartilhadas para uma nova organização, suas reservas compartilhadas não migram para a nova organização. Quaisquer reservas compartilhadas criadas neste projeto são excluídas e quaisquer reservas da organização anterior compartilhada com este projeto não podem ser consumidas na nova organização. Para obter mais informações, consulte como as reservas compartilhadas funcionam neste documento.

Você pode mitigar as limitações de alguns desses requisitos, seguindo as melhores práticas para reservas compartilhadas .

Restrições adicionais para reservas com políticas de colocação compactas

Além disso, as reservas que especificam uma política de colocação compacta têm as seguintes restrições:

• Você não pode compartilhar uma política de colocação compacta nas reservas. Em vez disso, você deve usar uma política de colocação compacta separada para cada reserva à qual deseja aplicar uma política de colocação compacta.

• Você só pode especificar políticas de colocação compactas. Qualquer outro tipo de políticas de recursos, como cronogramas de instância ou cronogramas de instantâneos, não é suportado.

Cobrança

As reservas são cobradas na mesma taxa que seus recursos reservados, incluindo os mesmos preços sob demanda e cobranças mínimas de 1 minuto que as VMs que não reservadas.Descontos de uso sustentado (SUDs) , CUDs e preços personalizados também se aplicam como faria na execução de VMs.

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

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

Neste cenário, Google Cloud Fills você o seguinte:

Uma reserva incorre em acusações por seus recursos reservados enquanto a reserva existir, independentemente de serem usados ​​ou não seus recursos. Ao consumir uma reserva, uma VM não incorre em cobranças de recursos duplicadas, pois a reserva já está cobrada pelo custo dos recursos reservados. Para detalhes, consulte Preços de VMS .

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

Informações de cobrança adicionais para reservas compartilhadas

Não há cobranças adicionais pelo uso de reservas compartilhadas-elas são cobradas pelo mesmo preço que as reservas de mecanismo de computação de projeto único. Porém, o projeto que é cobrado por reservas compartilhadas muda com o consumo, pois diferentes projetos podem se qualificar para diferentes CUDs.

O projeto de cobrança e o preço das reservas compartilhados são gerenciados da seguinte forma:

• Projeto de cobrança : por padrão, o projeto do proprietário é cobrado para a reserva compartilhada. Mas, quando um recurso de uma reserva compartilhado está sendo consumido por um projeto de consumo, o projeto do consumidor é cobrado pela reserva.
• Descontos de cobrança : por padrão, o faturamento usa o preço sob demanda. Mas, se você for elegível para receber CUDs para o projeto que está sendo cobrado ou a conta de cobrança em nuvem associada a esse projeto, o preço com desconto será usado.

O que vem a seguir

• Aprenda a criar reservas:
  • Crie uma reserva para um único projeto .
  • Crie uma reserva compartilhada .