Planejamento de Capacidade em Ambiente Virtualizado

Bruno Domingues

bruno.domingues@intel.com

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.