As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Um pool ativo oferece a capacidade de diminuir a latência para suas aplicações que apresentam tempos de inicialização excepcionalmente longos, por exemplo, porque as instâncias precisam gravar grandes quantidades de dados no disco. Com os pools ativos, você não precisa mais provisionar excessivamente seus grupos do Auto Scaling para gerenciar a latência a fim de melhorar a performance das aplicações. Para obter mais informações, consulte a seguinte postagem no blog Como escalar seus aplicativos mais rapidamente com o EC2 Auto Scaling
Importante
Criar um pool ativo quando ele não é necessário pode gerar custos desnecessários. Se o tempo da primeira inicialização não causar problemas de latência visíveis para sua aplicação, provavelmente não há necessidade de usar um pool ativo.
Tópicos
Conceitos principais
Antes de começar a usar, familiarize-se com os seguintes conceitos principais:
- Pool ativo
-
Um pool aquecido é um pool de EC2 instâncias pré-inicializadas que fica ao lado de um grupo de Auto Scaling. Sempre que é necessário aumentar a escala da aplicação na horizontal, o grupo do Auto Scaling pode utilizar o pool ativo para atender à nova capacidade desejada. Isso o ajuda a garantir que as instâncias estejam prontas para começar rapidamente a servir o tráfego das aplicações, acelerando a resposta a um evento de aumento de escala na horizontal. Quando as instâncias deixam o pool ativo, elas passam a contar para a capacidade desejada do grupo. Isso é conhecido como inicialização a quente.
Enquanto as instâncias estão no pool quente, suas políticas de escalabilidade só são dimensionadas se o valor da métrica das instâncias que estão no estado
InServicefor maior que o limite alto de alarme da política da escalabilidade (que é o mesmo que a utilização de destino de uma política de dimensionamento com monitoramento do objetivo). - Tamanho do pool ativo
-
Por padrão, o tamanho do pool ativo é calculado como a diferença entre a capacidade máxima do grupo do Auto Scaling e a capacidade desejada. Por exemplo, se a capacidade desejada do grupo do Auto Scaling for 6 e a capacidade máxima for 10, o tamanho do pool ativo será 4 quando você configurar o pool ativo pela primeira vez e o pool estiver inicializando.
Para especificar a capacidade máxima do grupo dinâmico separadamente, use a opção de especificação personalizada (
MaxGroupPreparedCapacity) e defina um valor personalizado para ela que seja maior do que a capacidade atual do grupo. Se você fornecer um valor personalizado, o tamanho do grupo dinâmico será calculado como a diferença entre o valor personalizado e a capacidade desejada atual do grupo. Por exemplo, se a capacidade desejada do seu grupo do Auto Scaling for 6, se a capacidade máxima for 20 e se o valor personalizado for 8, o tamanho do seu grupo dinâmico será 2 quando você configurar o grupo dinâmico pela primeira vez e o grupo estiver sendo inicializado.Talvez você só precise usar a opção de especificação personalizada (
MaxGroupPreparedCapacity) ao trabalhar com grandes grupos do Auto Scaling para gerenciar os benefícios de custo de ter um grupo dinâmico. Por exemplo, talvez um grupo do Auto Scaling com 1.000 instâncias, uma capacidade máxima de 1.500 (para fornecer capacidade extra durante picos de tráfego de emergência) e um pool ativo de 100 instâncias seja uma estratégia melhor para ajudar você a atingir seus objetivos do que manter 500 instâncias reservadas para uso futuro no pool ativo. - Tamanho mínimo do pool ativo
-
Considere usar a configuração de tamanho mínimo (
MinSize) para definir estaticamente o número mínimo de instâncias a serem mantidas no pool aquecido. Não há tamanho mínimo definido por padrão. AMinSizeconfiguração é útil quando você especificaMaxGroupPreparedCapacitypara garantir que um número mínimo de instâncias seja mantido no pool aquecido, mesmo quando a capacidade desejada do grupo Auto Scaling for maior do que o.MaxGroupPreparedCapacity - Estado da instância do pool ativo
-
Você pode manter as instâncias no pool ativo em um de três estados:
Stopped,Running, ouHibernated. Manter as instâncias no estadoStoppedé uma maneira eficaz de minimizar os custos. Com as instâncias interrompidas, você paga apenas pelos volumes usados e pelos endereços IP elásticos anexados às instâncias.Você também pode manter as instâncias em um estado
Hibernatedpara interromper instâncias sem excluir o conteúdo da memória (RAM). Quando uma instância é hibernada, isso sinaliza ao sistema operacional para salvar o conteúdo da RAM no volume raiz do Amazon EBS. Quando você inicia a instância novamente, o volume raiz é restaurado ao seu estado anterior, e o conteúdo da RAM é recarregado. Enquanto as instâncias estão em hibernação, você paga somente pelos volumes do EBS, incluindo armazenamento para o conteúdo da RAM e os endereços IP elásticos anexados às instâncias.Também é possível manter instâncias em um estado
Runningno pool ativo, mas isso é altamente desaconselhável a fim de evitar a geração de cobranças desnecessárias. Quando as instâncias são interrompidas ou hibernadas, você economiza o custo das próprias instâncias. Você paga pelas instâncias somente quando elas são executadas. - Ganchos do ciclo de vida
-
Você usa ganchos do ciclo de vida para colocar instâncias em um estado de espera para poder executar ações personalizadas nas instâncias. Ações personalizadas são executadas à medida que as instâncias são iniciadas ou antes de serem terminadas.
Em uma configuração de pool quente, os ganchos do ciclo de vida atrasam a interrupção ou hibernação das instâncias e a colocação em serviço durante um evento de expansão até que concluam a inicialização. Se você adicionar um pool ativo ao seu grupo do Auto Scaling sem um gancho do ciclo de vida, as instâncias que demorarem muito para concluir a inicialização poderão ser interrompidas ou hibernadas e, em seguida, colocadas em serviço durante um evento de aumento de escala na horizontal antes de estarem prontas.
- Política de reutilização de instâncias
-
Por padrão, o Amazon EC2 Auto Scaling encerra suas instâncias quando seu grupo de Auto Scaling se expande. Em seguida, ele inicia novas instâncias no pool ativo para substituir as instâncias que foram terminadas.
Se desejar devolver instâncias ao pool ativo, você poderá especificar uma política de reutilização de instâncias. Isso permite reutilizar instâncias que já estão configuradas para atender ao tráfego de aplicações. Para garantir que seu pool aquecido não seja provisionado em excesso, o Amazon EC2 Auto Scaling pode encerrar instâncias no pool aquecido para reduzir seu tamanho quando for maior do que o necessário com base em suas configurações. Ao terminar instâncias no pool ativo, ele usa a política de término padrão para escolher quais instâncias terminar primeiro.
Importante
Se você desejar hibernar instâncias em redução de escala na horizontal e houver instâncias existentes no grupo do Auto Scaling, elas deverão atender aos requisitos de hibernação de instâncias. Caso contrário, quando as instâncias forem devolvidas ao pool ativo, elas recuarão para serem interrompidas em vez de serem hibernadas.
nota
No momento, só é possível especificar uma política de reutilização de instâncias usando a AWS CLI ou um SDK. Esse recurso não está disponível no console.
Pré-requisitos
Antes de criar um pool ativo para seu grupo do Auto Scaling, decida como você usará ganchos do ciclo de vida para inicializar novas instâncias com um estado inicial apropriado.
Para realizar ações personalizadas em instâncias enquanto elas estão em estado de espera devido a um gancho do ciclo de vida, você tem duas opções:
-
Para cenários simples em que você deseja executar comandos em suas instâncias no início, você pode incluir um script de dados do usuário ao criar um modelo de execução ou configuração de execução para o grupo do Auto Scaling. Os scripts de dados do usuário são apenas scripts de shell normais ou cloud-init diretivas que são executadas por cloud-init quando suas instâncias são iniciadas. O script também pode controlar quando as instâncias fazem a transição para o próximo estado usando o ID da instância na qual é executado. Se você já não estiver fazendo isso, atualize seu script para recuperar o ID da instância nos metadados da instância. Para obter mais informações, consulte os metadados da instância de acesso no Guia do EC2 usuário da Amazon.
dica
Para executar scripts de dados do usuário quando uma instância é reiniciada, os dados do usuário devem estar no formato MIME de várias partes e especificar o seguinte na seção
#cloud-configdos dados do usuário:#cloud-config cloud_final_modules: - [scripts-user, always] -
Para cenários avançados em que você precisa de um serviço, como AWS Lambda fazer algo enquanto as instâncias entram ou saem do pool aquecido, você pode criar um gancho de ciclo de vida para seu grupo de Auto Scaling e configurar o serviço de destino para realizar ações personalizadas com base nas notificações do ciclo de vida. Para obter mais informações, consulte Destinos de notificação compatíveis.
Preparar instâncias para hibernação
Para preparar as instâncias do Auto Scaling para usar o estado do Hibernated pool, crie um novo modelo de execução ou configuração de execução que esteja configurado corretamente para suportar a hibernação da instância, conforme descrito no tópico de pré-requisitos de hibernação no Guia do usuário da Amazon. EC2 Em seguida, associe o novo modelo de execução ou a configuração de execução ao grupo do Auto Scaling e inicie uma atualização de instância para substituir as instâncias associadas a um modelo de execução ou a uma configuração de execução anterior. Para obter mais informações, consulte Use uma atualização de instância para atualizar instâncias em um grupo do Auto Scaling.
Atualização das instâncias em um pool ativo
Para atualizar as instâncias em um pool ativo, você cria um novo modelo de execução ou configuração de execução e o associa ao grupo do Auto Scaling. Todas as novas instâncias serão iniciadas usando a nova AMI e outras atualizações especificadas no modelo de execução ou na configuração de execução, mas as instâncias existentes não serão afetadas.
Para forçar as instâncias do pool ativo de substituição a executar esse uso, o modelo de execução ou a configuração de execução, é possível iniciar uma atualização de instância para fazer uma atualização contínua de seu grupo. Uma atualização de instância substitui primeiro as instâncias InService. Em seguida, ela substitui as instâncias no pool ativo. Para obter mais informações, consulte Use uma atualização de instância para atualizar instâncias em um grupo do Auto Scaling.
Recursos relacionados
Você pode visitar nosso GitHubrepositório
Limitações
-
Não é possível adicionar um grupo dinâmico a um grupo do Auto Scaling que tenha uma política de instâncias mistas. Você também não pode adicionar um pool aquecido a um grupo de Auto Scaling que tenha um modelo de execução ou uma configuração de execução que solicite instâncias spot ou tenha um modelo de execução que especifique um parâmetro do Systems Manager.
-
O Amazon EC2 Auto Scaling pode colocar uma instância em um
HibernatedestadoStoppedou somente se ela tiver um volume do Amazon EBS como dispositivo raiz. Instâncias que usam armazenamento de instâncias para o dispositivo raiz não podem ser interrompidas ou hibernadas. -
O Amazon EC2 Auto Scaling pode colocar uma instância em um
Hibernatedestado somente se atender a todos os requisitos listados no tópico de pré-requisitos de hibernação no Guia do usuário da Amazon. EC2 -
Se o pool ativo se esgotar em meio a um evento aumento de escala horizontal, as instâncias serão iniciadas diretamente no grupo do Auto Scaling (uma inicialização de baixa atividade). Uma inicialização de baixa atividade também poderá ocorrer se uma zona de disponibilidade estiver sem capacidade.
-
Se uma instância dentro do grupo dinâmico encontrar um problema durante o processo de execução, impedindo-a de atingir o estado
InService, a instância será considerada uma execução defeituosa e será terminada. Isso se aplica independentemente da causa subjacente, como um erro de capacidade insuficiente ou qualquer outro fator. -
Se você tentar usar pools ativos com um grupo de nós gerenciados do Amazon Elastic Kubernetes Service (Amazon EKS), as instâncias que ainda estão sendo inicializadas poderão se registrar no cluster do Amazon EKS. Como resultado, o cluster pode agendar trabalhos em uma instância enquanto se prepara para ser interrompido ou hibernado.
-
Da mesma forma, se você tentar usar um pool ativo com um cluster do Amazon ECS, as instâncias poderão se registrar no cluster antes que a inicialização seja concluída. Para resolver esse problema, você deve configurar um modelo de inicialização ou uma configuração de inicialização que inclua uma variável de configuração de agente especial nos dados do usuário. Para obter mais informações, consulte Using a warm pool for your Auto Scaling group (Usar um pool ativo para o grupo do Auto Scaling) no Amazon Elastic Container Service Developer Guide (Guia do desenvolvedor do Amazon Elastic Container Service).
