Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues

Planejamento de Capacidade em Ambiente

Virtualizado

Bruno Domingues bruno.domingues@intel.com

Sr. Solution Architect

Intel Corporation

Agenda

• Introdução

• Entendendo os usuários

• Entendendo as aplicações

• Entendendo a infraestrutura

• A “Tragédia” do planejamento de capacidade

Introdução

Escher– Unbelievable

Natureza do Ambiente Virtualizado

Software as a Service

Platform as a Service

Infrastructure as a Service

• Múltiplos usuários de

diferentes aplicações

• Múltiplas aplicações com

características distintas

• …Compartilhando a

mesma infraestrutura

A arte de acomodar “picos” e “vales”

Acomodar recursos computacionais de natureza distintas (método Ad Hoc)

CPU (MHz) Memoria

(MB) Rede (Mbps) Disco (IOPs)

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

xMhz yMB zMbps wIOPs

𝑀𝑎𝑥 𝛼, 𝛽, 𝛾, 𝛿 = número de servidores

Capacidade

instalada em

cada servidor

= 𝛼, 𝛽, 𝛾, 𝛿

Será que é simples assim?

Entendendo os Usuários

Michelangelo – A aliança entre Deus e os homens

Requisições de Acesso

Entender a distribuição de demanda

sobre o sistema na linha do tempo é

o primeiro passo.

Hits por hora Horário

500 6:00

1000 7:00

11000 8:00

20000 9:00

5000 10:00

1850 11:00

500 12:00

100 13:00

50 14:00

Total de usuários: 40000

x: 20000

média (µ): 4444.444

desvio padrão (α): 6829.689

Normal (y): 0.98863

hits/seg: 12.20526

0

5000

10000

15000

20000

25000

6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00

Hit

s p

or

ho

ra

Horário

Carga na aplicação

Equação da curva de Gauss (σ = desvio padrão, µ =

média aritmética)

Concorrência de Acesso

0.00000000

0.02000000

0.04000000

0.06000000

0.08000000

0.10000000

0.12000000

0 2 4 6 8 10 12 14 16 18 20 22 24 26P

rob

abili

ty

Assumindo que a pior situação haja

20mil usuários acessando o sistema

em um período de 1h, não significa

que haja 5,5 requisições/segundos

(ex. 20mil/3600 segundos)

A maior probabilidade é que se

tenha que lidar com 12 requisições

simultâneas e em intervalos de 0,5

segundos e a probabilidade de

atender mais de 20

requisições/segundo é menor de 2%

Distribuição de probabilidade de Poisson

Entendendo as Aplicações

Capacidades da Aplicação

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

Entendendo a Infraestrutura

Tópicos:

• Processadores

• Memória

• Rede

• Armazenamento

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

Rede unificada para ambiente virtualizado

DAS

NAS

iSCSI SAN FC SAN

Direct Attached Storage

Network Attached Storage iSCSI Storage Area Network

Fibre Channel Storage Area Network

Discos Locais

Baixa Utilização, não conectado a rede

Armazenamento baseado em arquivos

Crescimento de 52%/ano em capacidade

Ethernet block storage

Crescimento de 72%/ano em capacidade

FCoE

Legacy Block Storage

Declinio na participação de unidades/capacidade

Núvem Publica Núvem Privada Legado

Arquitetura padrão de indústria para scale-out storage (NFSv4.1)

2

Requisição de local 3

Endereço do local

4 Requisita dado

5 Resposta com o dado

Examplo de Leitura

6 Resposta do objeto

para a aplicação

1 Aplicação requisita

objeto

Servidores de Storage Servidores de

Metadados

Servidores de Aplicação

2

3

Cliente storage

1 6

5 4

app

metadata

services storage

services

15

A “Tragédia” do Planejamento de

Capacidade

Impacto da Virtualização em OLTP

VMM assistido por hardware

VMM usando paravirtualização

A raiz do problema

Event Waits Time(s) Avg wait (ms) % DB time Wait Class

DB CPU 6,179 59.89

log file sync 2,488,836 3,051 1 29.57 Commit

latch: cache buffers chains 50,724 210 4 2.04 Concurrency

latch: In memory undo latch 168,928 150 1 1.45 Concurrency

cursor: mutex S 178,372 148 1 1.44 Concurrency

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 Nativo

Desempenho Virtualizado

• 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

Basicamente, um servidores de

4 CPUs virtualizado, apresentou

o mesmo desempenho de um

servidor de 2 CPUs não-

virtualizado

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.

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