Resumo

  • A atualização do Compute Engine de 8 de setembro tornou geralmente disponível a conversão entre reservas de um único projeto e reservas compartilhadas.
  • Compartilhar muda quem pode usar recursos já reservados, sem criar capacidade adicional. A cobrança por ociosidade permanece e a retirada tem condições para instâncias que apontam explicitamente para a reserva.

Dar outro destino a uma folga de capacidade

Uma equipe pode manter recursos para uma tarefa futura enquanto outra precisa de capacidade compatível agora. As notas do Compute Engine de 8 de setembro anunciam a disponibilidade geral de uma ferramenta para ajustar essa relação: reservas elegíveis podem passar de uso em um só projeto para compartilhamento e fazer o caminho inverso.

As reservas compartilhadas não são novas. O avanço está na conversão entre os dois tipos. Também não se trata de revenda de capacidade para outra organização. O guia de modificação permite compartilhar com até 100 projetos da mesma organização. A alteração de uma reserva compartilhada ocorre no projeto em que ela foi criada; usar seus recursos não transfere a propriedade.

Para uma equipe central de nuvem, a oportunidade econômica é aproveitar demanda interna compatível e reduzir ociosidade. Abrir a lista de consumidores, porém, não amplia a reserva e não elimina os requisitos de permissão e cota.

A conta acompanha o consumo, mas a ociosidade fica

A visão geral de reservas explica que os recursos são cobrados enquanto a reserva existir, usados ou não. A máquina virtual que os consome não gera cobrança duplicada pelos mesmos recursos reservados.

Não há tarifa adicional apenas por compartilhar. Por padrão, o projeto proprietário recebe a cobrança; quando um projeto consumidor utiliza recursos da reserva, passa a ser cobrado por essa utilização. Descontos por compromisso de uso e outras condições aplicáveis podem alterar o preço. Mudar o acesso não equivale a anunciar um novo desconto nem garante uma tarifa idêntica para todos os projetos.

Considere duas equipes: uma guarda capacidade para um trabalho posterior, e outra tem uma tarefa compatível hoje. É uma hipótese para explicar o mecanismo, não um resultado de cliente divulgado pelo Google. O compartilhamento pode aumentar o uso efetivo. Se ambas precisarem dos recursos depois, ao mesmo tempo, a capacidade continuará limitada. O parâmetro não define qual prioridade de negócio deve prevalecer.

Voltar ao uso exclusivo pode exigir coordenação

Para transformar em reserva de um só projeto uma reserva compartilhada que instâncias consumidoras selecionam explicitamente, a documentação exige parar, suspender ou excluir as instâncias que a consomem nos projetos com os quais ela é compartilhada. Essa exigência não se aplica às instâncias do projeto proprietário.

Há ainda uma condição para voltar a executar o trabalho. Instâncias consumidoras paradas ou suspensas que apontam para a reserva não podem reiniciar ou retomar até existir uma reserva substituta no mesmo projeto proprietário e zona, com o nome original e propriedades correspondentes. Trata-se de uma dependência documentada, não de uma falha observada em clientes ou de uma recomendação de apagar cargas de trabalho. A regra não deve ser estendida a toda instância que consome capacidade compartilhada automaticamente.

Reservas ligadas a compromissos seguem um procedimento separado de substituição; reservas criadas automaticamente para solicitações futuras têm limites próprios. O anúncio não torna qualquer modalidade ou condição comercial livremente editável. A flexibilidade do acesso aumentou, mas retirar capacidade de um trabalho dependente continua sendo uma decisão operacional.