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
