Olá pessoal,

Espero que todos estejam bem durante a pandemia.

Continuando a série que iniciamos há alguns dias, este é o segundo post sobre AutoScaling. Hoje discutiremos sobre AutoScaling no OCI.

O primeiro post pode ser visto aqui: Desafios de Scaling em Workloads On-Premises – Post 1

Primeiro é interessante explicar que há dois tipos de Scaling. Observe que eu não citei dois tipos de AutoScaling, mas, dois tipos de Scaling:

  • Vertical Scaling: quando mudamos o tipo de shape da instância;
  • Horizontal Scaling: quando mudamos o número de nodes/instâncias dentro de um pool.

Essa série de post tratará sobre o Horizontal Scaling.

Pois bem, há dois tipos de política de AutoScaling no OCI:

  • Metric-Based:
    • Usado geralmente quando temos alguma demanda que não podemos prever. Pense em algum aumento súbito de processamento onde não se pode prever que acontecerá;
    • Para que possa ser configurado, uma métrica de performance precisa ser definida como threshold. As métricas disponíveis são CPU ou memória;
    • O AutoScaling redimensiona o pool quase em real-time;
    • Se a carga aumentar, o AutoScaling fará uma operação de scale-out (aumento do número de nodes);
    • Se a carga diminuir, o AutoScaling fará uma operação de scale-in (diminuição do número de nodes);
    • As métricas de performance são coletadas pelo Monitoring Service;
    • As métricas são agregadas em períodos de um minuto e depois é calculada a média entre todas as instâncias do pool;
    • Quando três valores consecutivos (quando a média entre todas as instâncias por três minutos consecutivos) atingir o threshold definido, um evento de autoscaling será disparado;
    • Quando uma instância é iniciada, ela passa por um período de cooldown de 300 segundos (5 minutos) à partir do momento que a instância atinge o status de Running. Durante o cooldown, o OCI entende que o sistema está em estado de estabilização;
    • O AutoScaling continuará avaliando as métricas durante o período de cooldown, e, quando o cooldown acabar, o autoscaling poderá ajustar o tamanho do pool de instâncias se necessário. Isso significa que se o threshold for atingido nos últimos três minutos de cooldown, quando o cooldown se encerrar, um evento de autoscaling será disparado.
  • Schedule-Based:
    • Usado principalmente quando se pode prever o aumento/diminuição de demanda (Black Friday, folha de pagamento, fechamento de ano fiscal, etc);
    • Para cada operação de aumento ou diminuição, uma política de agendamento precisa ser feita (se haverá um aumento no final do mês, dia 30, uma política precisa ser criada com o agendamento para o dia 30 e o tamanho que o pool precisa ter – neste caso, o pool seria aumentado). No caso de diminuição, uma nova política precisa ser criada com a data de agendamento e o tamanho desejado do pool (neste caso, diminuindo o pool).
    • Pode haver múltiplas políticas de agendamento de autoscaling (vários schedules);

Alguns pré-requisitos para AutoScaling:

  • Para o AutoScaling metric-based, se a instância estiver utilizando uma subnet privada, precisa ter acesso a um Service Gateway para acessar o Monitoring Service. Se a instância estiver em uma subnet pública com saída para a Internet, não há ação a ser feita;
  • Limits ou Quotas da conta não podem ter atingido o valor máximo permitido;
  • Opcionalmente, pode-se attachar/detachar as instâncias de um Load Balancer.

Para um pool metric-based, a seguinte regra será válida para remoção/deleção de instâncias:

  • O número de instâncias no pool será balanceado entre os Availability Domains. Isso significa que se houver 3 instâncias no AD1, 2 instâncias no AD2 e 1 instância no AD3, uma instância no AD1 será removida do pool;
  • Após ter o número de instâncias no pool balanceado entre os AD’s, haverá então o balanceamento das instâncias entre os Fault Domains. Ou seja, se algum Fault Domain tiver mais instâncias que em outros FD’s, este FD terá instância(s) removida(s);
  • Depois que as instâncias entre AD’s e FD’s estiverem balanceadas, a instância mais antiga/velha no pool será removida.

Principais componentes para que se tenha uma boa configuração de AutoScaling:

  • Custom Image: para que novas instâncias sejam adicionadas ao pool, caso você tenha uma Custom Image, ela poderá ser a imagem padrão para provisionamento de novas instâncias. Para que você tenha uma Custom Image, significa que você precisa criar uma instância, instalar os produtos que necessita e ajustar as configurações necessárias para que a instância esteja pronta para servir de padrão para as próximas;
  • Instance Configuration: depois que uma instância for provisionada utilizando a Custom Image, você pode criar uma Instance Configuration. A Instance Configuration nada mais é que um “arquivo” de configurações com informações úteis para que novas instâncias sejam criadas: imagem utilizada (aí o motivo pelo qual utilizamos uma Custom Image), Metadata, Shape, Storage Volumes atachados, VNICs, etc). A Instance Configuration funciona como se fosse um template para as próximas instâncias. Além disso, uma Instance Configuration pode estar associada com N instance pools;
  • Instance Pool: é usado para criar múltiplas instâncias usando a mesma configuração (Instance Configuration), dentro da mesma região entre os AD’s e FD’s disponíveis. Com a Instance Pool é possível gerenciar as instâncias como se fossem um grupo. Pode-se fazer scale-out (aumentar) o pool sob demanda. É possível associar o Pool a um ou mais Load Balancers. Apesar da Instance Configuration poder ser associada com vários Instance Pools, um Instance Pool pode ser associado apenas com 1 Instance Configuration;
  • AutoScaling Configuration: é usado para criar uma configuração de AutoScaling para um determinado pool. Pode utilizar uma configuração baseada em métrica (metric-based), como citado anteriormente neste post, ou, uma configuração baseada em agendamento (schedule-based). 1 AutoScaling Configuration pode ser associada com apenas 1 Instance Pool. Isso significa que se você criar uma Instance Pool e quiser configurar uma política de autoscaling para metric-based e outra para schedule-based, você precisará ter 2 Instance Pools. Uma Instance Pool associada para cada AutoScaling Configuration.

Desta forma, o Workflow sugerido para criar este tipo de configuração é o seguinte:

Nos próximos posts teremos o Hands-On com as seguintes tarefas:

  • Criação de um Compartment;
  • Criação de uma VCN e subnets;
  • Criação de um Load Balancer;
  •  Ajuste da Security List com as portas/protocolos necessários para que o AutoScaling funcione (adição das instâncias no backend-set do Load Balancer);
  • Criação de uma instância;
  • Configuração da instância;
  • Criação de uma Custom Image;
  • Remoção da instância criada;
  • Criação de uma nova instância utilizando uma Custom Image;
  • Criação de uma Instance Configuration;
  • Criação de 2 Instance Pools;
  • Criação de 2 AutoScaling Configurations.

Espero que seja útil.

Um abraço

Vinicius