O documento discute planejamento de capacidade em ambientes virtualizados. Ele aborda a necessidade de entender os usuários, as aplicações e a infraestrutura, e como a virtualização pode impactar negativamente o desempenho devido a gargalos como tempo de espera por locks no banco de dados. É importante validar as métricas de desempenho em laboratório e não apenas no papel.

1. Planejamento de Capacidade em Ambiente
Virtualizado
Bruno Domingues
bruno.domingues@intel.com
Sr. Solution Architect
Intel Corporation

2. Agenda
• Introdução
• Entendendo os usuários
• Entendendo as aplicações
• Entendendo a infraestrutura
• A “Tragédia” do planejamento de capacidade

3. Introdução
Escher– Unbelievable

4. Natureza do Ambiente Virtualizado
• Múltiplos usuários de Software as a Service
diferentes aplicações
• Múltiplas aplicações com Platform as a Service
características distintas
• …Compartilhando a Infrastructure as a Service
mesma infraestrutura

5. A arte de acomodar “picos” e “vales”

6. Acomodar recursos computacionais de
natureza distintas (método Ad Hoc)
Memoria
CPU (MHz) Rede (Mbps) Disco (IOPs)
(MB)
Aplicação A 1500 4096 1000 400
Aplicação B 2000 4096 1500 520
Aplicação C 3000 8192 2000 880
… … … … …
Ʃ MHz Ʃ MB Ʃ Mbps Ʃ IOPs
Capacidade
= ������, ������, ������, ������
instalada em
cada servidor
xMhz yMB zMbps wIOPs
������������������ ������, ������, ������, ������ = número de servidores
Será que é simples assim?

7. Entendendo os Usuários
Michelangelo – A aliança entre Deus e os homens

8. Requisições de Acesso
Entender a distribuição de demanda Carga na aplicação
sobre o sistema na linha do tempo é 25000
o primeiro passo. 20000
Hits por hora
15000
10000
Hits por hora Horário
500 6:00 5000
1000 7:00 0
11000 8:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00
20000 9:00 Horário
5000 10:00
1850 11:00
500 12:00
100 13:00
50 14:00
Total de usuários: 40000
x: 20000 Equação da curva de Gauss (σ = desvio padrão, µ =
média (µ):
desvio padrão (α):
4444.444
6829.689
média aritmética)
Normal (y): 0.98863
hits/seg: 12.20526

9. Concorrência de Acesso
0.12000000
Assumindo que a pior situação haja
20mil usuários acessando o sistema 0.10000000
em um período de 1h, não significa
que haja 5,5 requisições/segundos 0.08000000
Probability
(ex. 20mil/3600 segundos) 0.06000000
0.04000000
A maior probabilidade é que se
0.02000000
tenha que lidar com 12 requisições 0.00000000
simultâneas e em intervalos de 0,5 0 2 4 6 8 10 12 14 16 18 20 22 24 26
segundos e a probabilidade de
atender mais de 20
requisições/segundo é menor de 2%
Distribuição de probabilidade de Poisson

10. Entendendo as Aplicações

11. Capacidades da Aplicação
Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento de
requisições, p=λ/μ

12. Entendendo a Infraestrutura
Tópicos:
• Processadores
• Memória
• Rede
• Armazenamento

13. Memória
12GB 24GB 36GB 48GB 72GB 96GB 144GB 192GB 256GB 512GB 1TB
Blade Half Height 2S $ 8,126.00 $ 8,566.00 $ 9,846.00 $ 17,766.00
Blade Full Height 2S $ 9,308.00 $ 9,888.00 $ 10,748.00 $ 11,028.00 $ 12,348.00 $ 18,948.00 $ 23,748.00 $ 64,948.00
Rack 2S $ 8,165.00 $ 8,605.00 $ 9,605.00 $ 9,885.00 $ 11,205.00 $ 17,805.00 $ 22,605.00
Rack 4S $ 22,763.00 $ 23,243.00 $ 23,563.00 $ 24,203.00 $ 25,163.00 $ 26,123.00 $ 28,523.00 $ 31,883.00 $ 36,363.00
Rack 8S $ 45,480.00 $ 45,960.00 $ 46,440.00 $ 46,920.00 $ 47,880.00 $ 48,840.00 $ 50,760.00 $ 52,680.00 $ 55,240.00
Rack 16S $ 180,480.00 $ 180,960.00 $ 181,440.00 $ 181,920.00 $ 182,880.00 $ 183,840.00 $ 185,760.00 $ 187,680.00 $ 190,240.00 $ 200,480.00
Rack 32S $ 300,480.00 $ 300,960.00 $ 301,440.00 $ 301,920.00 $ 302,880.00 $ 303,840.00 $ 305,760.00 $ 307,680.00 $ 310,240.00 $ 320,480.00 $ 340,000.00
Considerando um template básico de VM com 1 vCPU e 4GB de memória RAM

14. Rede unificada para ambiente virtualizado
DAS FCoE
NAS
iSCSI SAN
FC SAN
Direct Attached Network Attached Storage iSCSI Storage Area Fibre Channel Storage Area
Storage Network Network
Discos Locais Armazenamento baseado Ethernet block storage Legacy Block Storage
Baixa Utilização, não em arquivos Crescimento de 72%/ano Declinio na participação de
conectado a rede Crescimento de 52%/ano em capacidade unidades/capacidade
em capacidade
Núvem Publica Núvem Privada Legado

15. Arquitetura padrão de indústria para
scale-out storage (NFSv4.1)
Examplo de Leitura
Servidores de Aplicação
app
1 1 Aplicação requisita
6 objeto
Cliente storage 2 Endereço do local
2
5
3 4 3 Requisição de local
Servidores de Servidores de Storage
Metadados 4 Requisita dado
metadata storage
services services
5 Resposta com o dado
Resposta do objeto
6 para a aplicação
15

16. A “Tragédia” do Planejamento de
Capacidade

17. Impacto da Virtualização em OLTP
VMM assistido por
hardware
VMM usando
paravirtualização

18. A raiz do problema
• Com o VMM C o impacto maior foi o limite de vCPUs
• Com o VMM D o problema foi com a tecnologia de disco virtual
• Em todos eles o mesmo problema se apresentou:
• Tempos altos de read latches
• Banda de I/O para o redo
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
Basicamente, um servidores de DB CPU
log file sync 2,488,836
6,179
3,051 1
59.89
29.57 Commit
4 CPUs virtualizado, apresentou latch: cache buffers chains 50,724 210 4 2.04 Concurrency
o mesmo desempenho de um latch: In memory undo latch
cursor: mutex S
168,928
178,372
150
148
1
1
1.45 Concurrency
1.44 Concurrency
servidor de 2 CPUs não- Desempenho Nativo
virtualizado Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 1,510,872 9,488 6 64.75 Commit
DB CPU 4,345 29.66
latch: cache buffers chains 83,000 387 5 2.64 Concurrency
latch: enqueue hash chains 15,921 72 5 0.49 Other
latch: In memory undo latch 74,511 70 1 0.48 Concurrency
Desempenho Virtualizado

19. A Consequência do Problema
• A maioria dos servidores web são configurados para alocar 25 threads por CPU;
• Maior tempo no round-trip entre o servidor e de aplicação e o banco de dados,
mais tempo a thread fica alocada, logo menos thread disponível para novos
usuários = HTTP ERROR 500 (Server is too busy)
• Maior o número de locks no banco de dados (especialmente para os altamente
normalizados), logo potencial impacto no desempenho e funcionamento da
aplicação.

20. Seja Cético!
• Planejamento de Capacidade
somente no “papel” raramente
funciona – teste em laboratório
• Confira sempre se os valores
esperados estão de fato sendo
realizados no laboratório:
– Configuração de gerenciamento de
energia na BIOS pode derrubar o
desempenho de servidor de BD em 50%!
– Configurações de extensões de
virtualizações podem conter “truques”;
– Configuração de HBA (i.e. queuedetph e
queuelength) possuem um impacto
enorme no I/O
– Etc…
Carl Sagan