Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues

601 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
601
On SlideShare
0
From Embeds
0
Number of Embeds
51
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues

  1. 1. Planejamento de Capacidade em Ambiente Virtualizado Bruno Domingues bruno.domingues@intel.com Sr. Solution Architect Intel Corporation
  2. 2. Agenda• Introdução• Entendendo os usuários• Entendendo as aplicações• Entendendo a infraestrutura• A “Tragédia” do planejamento de capacidade
  3. 3. IntroduçãoEscher– Unbelievable
  4. 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. 5. A arte de acomodar “picos” e “vales”
  6. 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 emcada servidor xMhz yMB zMbps wIOPs ������������������ ������, ������, ������, ������ = número de servidores Será que é simples assim?
  7. 7. Entendendo os Usuários Michelangelo – A aliança entre Deus e os homens
  8. 8. Requisições de AcessoEntender a distribuição de demanda Carga na aplicaçãosobre o sistema na linha do tempo é 25000o 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. 9. Concorrência de Acesso 0.12000000Assumindo que a pior situação haja20mil usuários acessando o sistema 0.10000000em um período de 1h, não significaque haja 5,5 requisições/segundos 0.08000000 Probability(ex. 20mil/3600 segundos) 0.06000000 0.04000000A maior probabilidade é que se 0.02000000tenha que lidar com 12 requisições 0.00000000simultâneas e em intervalos de 0,5 0 2 4 6 8 10 12 14 16 18 20 22 24 26segundos e a probabilidade deatender mais de 20requisições/segundo é menor de 2% Distribuição de probabilidade de Poisson
  10. 10. Entendendo as Aplicações
  11. 11. Capacidades da AplicaçãoAplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento derequisições, p=λ/μ
  12. 12. Entendendo a InfraestruturaTópicos:• Processadores• Memória• Rede• Armazenamento
  13. 13. Memória 12GB 24GB 36GB 48GB 72GB 96GB 144GB 192GB 256GB 512GB 1TBBlade Half Height 2S $ 8,126.00 $ 8,566.00 $ 9,846.00 $ 17,766.00Blade 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.00Rack 2S $ 8,165.00 $ 8,605.00 $ 9,605.00 $ 9,885.00 $ 11,205.00 $ 17,805.00 $ 22,605.00Rack 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.00Rack 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.00Rack 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.00Rack 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. 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 StorageBaixa 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. 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ção15
  16. 16. A “Tragédia” do Planejamento de Capacidade
  17. 17. Impacto da Virtualização em OLTP VMM assistido por hardware VMM usando paravirtualização
  18. 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 ClassBasicamente, um servidores de DB CPU log file sync 2,488,836 6,179 3,051 1 59.89 29.57 Commit4 CPUs virtualizado, apresentou latch: cache buffers chains 50,724 210 4 2.04 Concurrencyo 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 Concurrencyservidor de 2 CPUs não- Desempenho Nativovirtualizado 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. 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. 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

×