Planejamento de Capacidade em Ambiente Virtualizado
Bruno Domingues
Intel Corporation
O nível de desacoplamento proporcionado pela virtualização trouxe flexibilidade para
a infraestrutura e proporcionou alto nível de consolidação, assim como nos obriga a
repensar metodologias e ferramentas comumente usadas no planejamento de cargas,
estratégias de disponibilidade e governança.
O advento da virtualização permitiu a concepção da computação na nuvem com
características intrínsecas de escalabilidade elástica de processamento. Porém, a
realização deste ideal demanda um desenho elaborado da infraestrutura para evitar
latências e gargalos, ao mesmo tempo em que evita o dimensionamento demasiado e
pobre aproveitamento dos recursos computacionais alocados.
Neste estudo serão abordadas boas práticas de arquitetura e planejamento de
capacidade em ambiente virtualizado para serviços com distintas características
computacionais.
Introdução
A base da computação na nuvem é a virtualização, pois
em termos simples permite o desacoplamento da
infraestrutura dos serviços associados à aplicação e a
própria aplicação, entregando cada uma destas camadas
como serviços independentes, conforme apresentado
na figura 01. Do ponto de vista do planejamento de
capacidade para a infraestrutura, significa que poderá
potencialmente haver múltiplas aplicações com
diferentes padrões de uso, com múltiplos usuários de
diferentes aplicações compartilhando a mesma
infraestrutura.
Figura 01 – Inter-relacionamento das camadas de
serviço na nuvem
O sucesso de uma infraestrutura na nuvem (IaaS) está
diretamente relacionada a capacidade de acomodar
“picos” e “vales” de demanda de várias aplicações no
tempo, de forma a evitar baixa utilização em
determinados períodos bem como planejar para o pior
caso de uma aplicação isolada e sim do conjunto de
todas as possíveis cargas a serem atendidas.
Os “picos” e “vales” no planejamento de capacidade são
multidimensionais, ou seja, é necessário acomodar não
só demanda de CPU, mas também consumo de memória,
rede e armazenamento (i.e. IOPs), conforme
apresentado no exemplo da tabela 01.
Tabela 01 – demanda hipotética de diversas aplicações
Com base no perfil do conjunto de aplicações no
portfólio, a conta básica a ser seguida é somar todas as
demanda no intervalo de tempo (i.e. suponhamos 1h) e
dividir pela capacidade disponível em um servidor.
Figura 02 – Equação geral do planejamento de
capacidade
Sendo o numerador a demanda e o denominador a
capacidade presente em um servidor, sendo que o valor
máximo desta razão predirá a quantidade de servidores
estimados para atender durante o período calculado:
Figura 03 – determinação do número de servidores
requerido.
Completando o período típico de carga estabelecido,
suponhamos que seja de 24hs, ou seja, realizando este
mesmo procedimento de calculo 24 vezes em intervalos
de 1h, e tomando o pior caso, seria a quantidade de
servidores necessários para atender o planejado.
Incluindo ai, portanto uma margem de segurança, como
por exemplo, 50% retirando a demanda prevista de
curto prazo, teríamos então a necessidade simplificada
de infraestrutura.
Portanto sabemos que por experiência que obter tais
valores não são fáceis e também neste modelo estamos
desprezando a penalidade imposta pela camada de
virtualização, porém é um principio a ser seguido.
Entendendo os Usuários
O planejamento de capacidade é composto basicamente
por três grandes variáveis, o “tripé”: Usuários, Aplicação
e Infraestrutura, portanto conhecendo ou estimando
duas destas variáveis nos habilita a calcular a terceira.
Assumindo a situação onde a variável desconhecida do
“tripé” do planejamento de capacidade seja a
infraestrutura, ou seja, as aplicações são conhecidas e a
demanda estimada de consumo destas aplicações é
conhecida, então a quantificação em linguem
matemática é necessária para que se possa quantificar
a infraestrutura necessária.
Assumimos uma situação hipotética, apenas para fins
didáticos que a distribuição em um determinado sistema
respeite a seguinte distribuição de requisições no
tempo (tabela 02).
Tabela 02 – distribuição de requisições no tempo.
Neste caso, podemos estimar que a demanda de
usuários no período de 6h00min até às 14h00min é de
aproximadamente 40.000 hits por hora com média µ =
4444,444 e desvio padrão σ = 6829,689, o que nos
leva ao cálculo da normal pela fórmula de Gauss
apresentado na figura 04 a ser igual a y = 0,98863 e
uma média de 12,20526 hits/seg.
Figura 04 – Fórmula de Gauss
Para o planejamento de capacidade o mais importante é
identificar o pico da aplicação e sua concorrência no
pico, com base na distribuição da tabela 02, onde há
20mil usuários acessando o sistema em um período de
1h, não significa que o pico seja de 5,5
requisições/segundos (e.g. 20min/3600 segundos).
Identificar a pior condição de concorrência é necessária
a aplicação da distribuição de probabilidade de Poisson,
conforme apresentado na figura 05.
Figura 05 – distribuição de probabilidade Poisson
Aplicando Poisson aos dados da tabela 02, para
entender a probabilidade de termos que lidar com
requisições simultâneas, de 0 a 26 (i.e. apenas porque
depois de 26 a probabilidade tende a zero), tem-se a
seguinte distribuição de probabilidade apresentada a
figura 06.
Figure 06 – Distribuição de probabilidade
Portanto, a maior probabilidade, de 11,5%, é que se
tenha que lidar com 12 requisições simultâneas no
período de pico em um intervalo de 0,5 segundos (i.e.
precisão da medida definida em segundos) e atender
mais de 20 requisições/segundo a probabilidade cai
para menos de 2%.
Entendendo a Aplicação
A avaliação da aplicação pode ser realizada de forma
independente da caracterização do perfil dos usuários,
porém é necessário que se teste a aplicação sob carga,
em ambiente de homologação ou laboratório, desde que
seja próximo, em menor escala, do ambiente de
produção.
Para a realização do teste de carga pode ser utilizado
qualquer ferramenta de mercado que simule acesso de
usuários a interface web e que possa ser automatizado.
A carga é aplicada a partir de um servidor (i.e. gerador
de carga) contra a aplicação hospedada no ambiente de
homologação, onde a porção de infraestrutura é
conhecida. A carga deve ser ajustada de tal sorte que
não haja erros significativos de resposta da aplicação
(e.g. erros HTTP 500, 400, etc.), pois erros podem
significar que a aplicação não dispõe de recursos para
tratar tal carga de requisições (e.g. threads,
concorrência por recursos compartilhados, etc.).
Para o planejamento de capacidade, assumimos que a
aplicação está bem construída e usando
adequadamente os recursos computacionais, portanto o
relatório do teste de carga irá predizer para porção de
infraestrutura alocada para homologação a capacidade
máxima de atendimento, e poderá ser usada uma
simples regra de três para estimar a infraestrutura
adequada para uma determinada demanda, bem como o
inverso: para uma determinada infraestrutura, qual é a
capacidade de atendimento.
O relatório da ferramenta de carga também é capaz
reportar o tempo médio para a realização de uma
determinada transação, e com base neste tempo
podemos dimensionar os componentes da solução de
infraestrutura, principalmente cache para evitar grande
degradação de desempenho sob alta demanda.
Assumindo ainda como exemplo, que o tempo de
resposta para uma determinada transação foi de
aproximadamente 0,08 segundos, e aplicando as
formulas das teorias de filas, conforme apresentado na
figura 07.
Figura 07 – Fórmulas de filas
Aplicando o Teorema de Little, onde λ é a taxa de
requisição de Poisson, µ é a capacidade de
processamento obtida pelo teste de carga, logo o p
aplicado na fórmula de filas é
, sendo assim temos
o seguinte gráfico da figura 08 que representa o
comportamento no tempo de resposta do sistema com
o aumento gradativo de requisições (i.e.
processamento/segundo) e a quantidade de comandos
em cache.
Figura 08 – Relação entre comandos processados/seg,
comandos em cache e tempo de espera para
processamento.
O mau dimensionamento dos caches (i.e. subsistema de
armazenamento, servidor de aplicação, rede, banco de
dados, etc.) pode acarretar degradação severa de
desempenho e limitar a capacidade de acomodar picos
de demanda.
Planejando a Infraestrutura
Atualmente, para o ambiente virtualizado onde há
grande concentração de processamento, os
componentes que demandam mais atenção no
planejamento são memória, subsistema de
armazenamento e rede, sendo estes dois últimos
podendo ser unificado de forma a prover maior
flexibilidade de administração e implantação.
A quantidade de memória é determinante para
definição do tipo de servidor a ser utilizado (e.g. 1, 2, 4
ou mais processadores), pois nos servidores atuais,
onde a memoria é organizada segundo Non-Uniform
Memory Architecture – NUMA, tem-se 3 ou 4 canais de
memória para cada socket, dependendo da
microarquitetura do processador, o maior desempenho
é alcançado balanceado de forma uniforme todos os
canais de memória.
Em ambiente virtualizado, assumimos como exemplo
que a configuração básica da máquina virtual é de
1vCPU e 4GB de vMemory, temos para cada tipo de
servidor as seguintes possibilidades de população de
memória, onde destacado em vermelho apresenta a
configuração ótima para cada servidor (tabela 03).
Os custos dos servidores são estimados a preços de
mercado disponíveis na Internet pelo site dos principais
fabricantes multinacionais (e.g. DELL, HP, IBM e etc.) e a
configuração baseada nos custos de memoria destes
fabricantes em diversas configurações.
Tabela 03 – Configuração ótima de memória
Assumindo estes valores, temos o custo estimado de
cada máquina virtual básica que está apresentado na
figura 09.
Figura 09 – Custo por máquinas virtual de acordo com
o servidor.
De acordo com essa avaliação, o custo menor por
máquina virtual está com os servidores de 4-8 CPUs,
para equipamentos com CPU de 3 canais de memória,
porém para servidores com 4 canais de memória, onde é
possível maior capacidade de memória, os servidores de
2 CPUs se tornam mais atrativos.
Outro fator importante na infraestrutura é o
subsistema de armazenamento e rede. Atualmente nas
consolidações típicas de servidores web para ambiente
virtualizado, tem-se alcançado consolidação na ordem
de 15-25 para 1 máquina física. Neste cenário, têm-se
utilizado 2 HBAs para conexão com a rede SAN, e mais
6-8 interfaces 1GbE para rede Ethernet.
A distinção de rede SAN com a rede Ethernet fica desta
forma limitada a capacidade instalada, e com pouca
flexibilidade para ajustes de acordo com a necessidade
da aplicação, que no ambiente de nuvem é dinâmico. A
grande tendência tem sido a adoção de redes de
armazenamento e Ethernet na mesma interface de
10GbE, podendo ser o FCoE, iSCSI ou Ethernet ligado
diretamente ao Network Attached Storage (NAS), onde
é possível balancear em tempo real a demanda entre
armazenamento e rede Ethernet.
Para ambientes onde o crescimento de armazenamento
de dados tem crescimento acentuado, como é caso de
nuvem pública, a adoção de arquitetura de
armazenamento que permite escalabilidade horizontal,
usando, por exemplo, padrão de indústria como é o caso
do NFS v4.1 e apresentado na figura 10.
Figura 10 – Arquitetura de armazenamento em rede
que permite escalabilidade horizontal
Fator de Penalidade da Virtualização
Todo o processo de planejamento de capacidade em
ambiente de nuvem é realizado com base em servidores
virtuais, promovidos pela virtualização (i.e. hypervisor),
porém é uma camada que adiciona penalidade de
desempenho e conhecer tal penalidade é importante
para o sucesso do planejamento de capacidade.
Em testes realizados com diversos fabricantes de
hypervisor, especificamente para banco de dados, pois
é o sistema mais sensível a latências de acesso aos
recursos computacionais do servidor (e.g. memória, rede
e armazenamento), conduzindo em servidores de 2 e 4
CPUs para o banco de dados Oracle 11g usando como
referencia o desempenho alcançado com o banco sendo
executado diretamente sobre o sistema operacional
Linux sem virtualização, e depois comparando com o
desempenho no mesmo equipamento usando os
principais hypervisor do mercado. O resultado do teste
está apresentado na figura 11.
Figura 11 – comparação de desempenho alcançado do
banco de dados Oracle 11g entre nativo e virtualizado.
O impacto de desempenho para sistemas OLTP é alto,
cada uma das tecnologias de virtualização testadas
tiveram diferentes gargalos (i.e. número máximo de
vCPUs, tecnologia do disco virtual, etc.) porém em todos
os casos o gargalo maior foi o aumento no read latches
e banda de I/O para o redo.
Conforme apresentado nas tabelas da figura 12, o
tempo maior apresentado foi na sincronização do log,
que aumentou de 1ms para 6ms.
Figura 12 – Comparativo de desempenho entre nativo
e virtualizado.
Do ponto de vista do hypervisor, o gargalo está no
acesso a memoria e as interfaces de I/O (i.e. rede e
armazenamento).
Conclusão
O impacto da virtualização é grande para sistemas
OLTP, porém é menor para aplicações tipicamente web,
portanto a recomendação é evitar no atual estagio de
maturidade da tecnologia de virtualização, colocar
banco de dados transacionais em servidores virtuais,
pois poderá acarretar baixa utilização dos recursos
computacionais e negação de serviço, pois a latência em
sistemas OLTP aumenta não só as taxas de lock em
banco de dados altamente normalizados como também
segura threads no servidor web aguardando a resposta
do banco por mais tempo exaurindo a capacidade do
servidor de atender novas requisições.
Top Related