1. 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 O sucesso de uma infraestrutura na nuvem (IaaS) está
diretamente relacionada a capacidade de acomodar
A base da computação na nuvem é a virtualização, pois “picos” e “vales” de demanda de várias aplicações no
em termos simples permite o desacoplamento da tempo, de forma a evitar baixa utilização em
infraestrutura dos serviços associados à aplicação e a determinados períodos bem como planejar para o pior
própria aplicação, entregando cada uma destas camadas caso de uma aplicação isolada e sim do conjunto de
como serviços independentes, conforme apresentado todas as possíveis cargas a serem atendidas.
na figura 01. Do ponto de vista do planejamento de
capacidade para a infraestrutura, significa que poderá Os “picos” e “vales” no planejamento de capacidade são
potencialmente haver múltiplas aplicações com multidimensionais, ou seja, é necessário acomodar não
diferentes padrões de uso, com múltiplos usuários de só demanda de CPU, mas também consumo de memória,
diferentes aplicações compartilhando a mesma rede e armazenamento (i.e. IOPs), conforme
infraestrutura. 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
Figura 01 – Inter-relacionamento das camadas de portfólio, a conta básica a ser seguida é somar todas as
serviço na nuvem

2. demanda no intervalo de tempo (i.e. suponhamos 1h) e respeite a seguinte distribuição de requisições no
dividir pela capacidade disponível em um servidor. tempo (tabela 02).
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 Tabela 02 – distribuição de requisições no tempo.
máximo desta razão predirá a quantidade de servidores
estimados para atender durante o período calculado: 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
Figura 03 – determinação do número de servidores
apresentado na figura 04 a ser igual a y = 0,98863 e
requerido.
uma média de 12,20526 hits/seg.
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. Figura 04 – Fórmula de Gauss
Incluindo ai, portanto uma margem de segurança, como
por exemplo, 50% retirando a demanda prevista de Para o planejamento de capacidade o mais importante é
curto prazo, teríamos então a necessidade simplificada identificar o pico da aplicação e sua concorrência no
de infraestrutura. pico, com base na distribuição da tabela 02, onde há
20mil usuários acessando o sistema em um período de
Portanto sabemos que por experiência que obter tais 1h, não significa que o pico seja de 5,5
valores não são fáceis e também neste modelo estamos requisições/segundos (e.g. 20min/3600 segundos).
desprezando a penalidade imposta pela camada de
virtualização, porém é um principio a ser seguido. Identificar a pior condição de concorrência é necessária
a aplicação da distribuição de probabilidade de Poisson,
Entendendo os Usuários conforme apresentado na figura 05.
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. Figura 05 – distribuição de probabilidade Poisson
Assumindo a situação onde a variável desconhecida do Aplicando Poisson aos dados da tabela 02, para
“tripé” do planejamento de capacidade seja a entender a probabilidade de termos que lidar com
infraestrutura, ou seja, as aplicações são conhecidas e a requisições simultâneas, de 0 a 26 (i.e. apenas porque
demanda estimada de consumo destas aplicações é depois de 26 a probabilidade tende a zero), tem-se a
conhecida, então a quantificação em linguem seguinte distribuição de probabilidade apresentada a
matemática é necessária para que se possa quantificar figura 06.
a infraestrutura necessária.
Assumimos uma situação hipotética, apenas para fins
didáticos que a distribuição em um determinado sistema

3. 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.
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
Figura 07 – Fórmulas de filas
mais de 20 requisições/segundo a probabilidade cai
para menos de 2%.
Aplicando o Teorema de Little, onde λ é a taxa de
requisição de Poisson, µ é a capacidade de
Entendendo a Aplicação
processamento obtida pelo teste de carga, logo o p
A avaliação da aplicação pode ser realizada de forma aplicado na fórmula de filas é , sendo assim temos
independente da caracterização do perfil dos usuários, o seguinte gráfico da figura 08 que representa o
porém é necessário que se teste a aplicação sob carga, comportamento no tempo de resposta do sistema com
em ambiente de homologação ou laboratório, desde que o aumento gradativo de requisições (i.e.
seja próximo, em menor escala, do ambiente de processamento/segundo) e a quantidade de comandos
produção. em cache.
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.).
Figura 08 – Relação entre comandos processados/seg,
comandos em cache e tempo de espera para
Para o planejamento de capacidade, assumimos que a
processamento.
aplicação está bem construída e usando
adequadamente os recursos computacionais, portanto o
O mau dimensionamento dos caches (i.e. subsistema de
relatório do teste de carga irá predizer para porção de
armazenamento, servidor de aplicação, rede, banco de
infraestrutura alocada para homologação a capacidade
dados, etc.) pode acarretar degradação severa de
máxima de atendimento, e poderá ser usada uma
desempenho e limitar a capacidade de acomodar picos
simples regra de três para estimar a infraestrutura
de demanda.
adequada para uma determinada demanda, bem como o
inverso: para uma determinada infraestrutura, qual é a
capacidade de atendimento.

4. Planejando a Infraestrutura microarquitetura do processador, o maior desempenho
é alcançado balanceado de forma uniforme todos os
Atualmente, para o ambiente virtualizado onde há canais de memória.
grande concentração de processamento, os
componentes que demandam mais atenção no Em ambiente virtualizado, assumimos como exemplo
planejamento são memória, subsistema de que a configuração básica da máquina virtual é de
armazenamento e rede, sendo estes dois últimos 1vCPU e 4GB de vMemory, temos para cada tipo de
podendo ser unificado de forma a prover maior servidor as seguintes possibilidades de população de
flexibilidade de administração e implantação. memória, onde destacado em vermelho apresenta a
configuração ótima para cada servidor (tabela 03).
A quantidade de memória é determinante para
definição do tipo de servidor a ser utilizado (e.g. 1, 2, 4 Os custos dos servidores são estimados a preços de
ou mais processadores), pois nos servidores atuais, mercado disponíveis na Internet pelo site dos principais
onde a memoria é organizada segundo Non-Uniform fabricantes multinacionais (e.g. DELL, HP, IBM e etc.) e a
Memory Architecture – NUMA, tem-se 3 ou 4 canais de configuração baseada nos custos de memoria destes
memória para cada socket, dependendo da fabricantes em diversas configurações.
Tabela 03 – Configuração ótima de memória
Assumindo estes valores, temos o custo estimado de virtualizado, tem-se alcançado consolidação na ordem
cada máquina virtual básica que está apresentado na de 15-25 para 1 máquina física. Neste cenário, têm-se
figura 09. 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.
Figura 09 – Custo por máquinas virtual de acordo com
o servidor. Para ambientes onde o crescimento de armazenamento
de dados tem crescimento acentuado, como é caso de
De acordo com essa avaliação, o custo menor por nuvem pública, a adoção de arquitetura de
máquina virtual está com os servidores de 4-8 CPUs, armazenamento que permite escalabilidade horizontal,
para equipamentos com CPU de 3 canais de memória, usando, por exemplo, padrão de indústria como é o caso
porém para servidores com 4 canais de memória, onde é do NFS v4.1 e apresentado na figura 10.
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

5. 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,
Figura 10 – Arquitetura de armazenamento em rede que aumentou de 1ms para 6ms.
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
Figura 12 – Comparativo de desempenho entre nativo
é o sistema mais sensível a latências de acesso aos
e virtualizado.
recursos computacionais do servidor (e.g. memória, rede
e armazenamento), conduzindo em servidores de 2 e 4
Do ponto de vista do hypervisor, o gargalo está no
CPUs para o banco de dados Oracle 11g usando como
acesso a memoria e as interfaces de I/O (i.e. rede e
referencia o desempenho alcançado com o banco sendo
armazenamento).
executado diretamente sobre o sistema operacional
Linux sem virtualização, e depois comparando com o
Conclusão
desempenho no mesmo equipamento usando os
principais hypervisor do mercado. O resultado do teste
O impacto da virtualização é grande para sistemas
está apresentado na figura 11.
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.