Embed Size (px)
Citation preview
Consumo e Gestão de Recursos em Cloud:técnicas reais por trás das abstrações
Alexandre Biancalana
Qcon - Março 2016
• Servidores Dedicados == Zero concorrência por recursos
• Recursos computacionais ociosos na maior parte do tempo
• Muito mais capacidade instantânea do que necessário == derperdício
• Crescimento depende de CAPEX, negociação, entrega, instalação…
Antes do Cloud, em um DC perto de você…
Oportunidade
• Abstração de toda a camada fisíca (Opaque to the application)
• Recursos disponíveis instantâneamente (Everything has an API)
• Sensação de Recursos Infinitos
• Capacidade Massiva de Recursos Computacionais Compartilhados
• Grande variação na quantidade de recursos provisionados (VMs, vCPUs, Memória)
Are your servers PETS or CATTLE?
PETS
•Nomes bonitos e singulares
(brain.company.com)
•São únicos, conhecidos e cuidados
•Impacto percebido em caso de problemas
•Scale UP
CATTLE
•Identificados por números
(web001.company.com)
•Em caso de problemas são substituídos
sem percepção (automaticamente)
•Automação de provisionamento e
configurações
•Scale OUT
Overcommitment
verb (used with object), overcommitted, overcommitting.
1. to commit more than is feasible
Allocated Resource > Available Resource
Overcommitment
VM A
Physical Host
VM B VM C
Physical Host Resource Available
overcommit
Total Resource Allocated
Overcommitment
VM A
Physical Host
VM B VM C
Total Physical Host Resource
overcommit
Total Resource AllocatedV
M A
VM
B
VM
C
Total Resource Used
CPU Overcommit
CPU 0
Physical Host CPU Cores
VM A
1 2
VM B
1 2 3 4
VM D
1 VM F
1 2 3 4 5 6
1 2 3 4 5 6 7 8
CPU 11 2 3 4 5 6 7 8
VM G
1 2 3 4 5 6 7 8
VM C
1 VM E
1 2 3 4 5 6
CPU Scheduling
Hypervisor Scheduling Algorithms
ESXi Relaxed Co-scheduling, aka “Gang Scheduling”
Hyper-V There is a name ???
KVM vCPU is like a thread
Xen Credit Scheduler
Memory Overcommit
Hypervisor Dedup Balloon Compress Swap Other
ESXi TSP vmware-tools ✓ ✓
Hyper-V page combining dynamic memory - ✓
KVM KSM virtio balloon - ✓
Xen - xenballoond - ✓ DMC
Memory Deduplication
Physical Host Memory
Total Memory Allocated
VM A
a b a c d b
b c d
a b c dc daa b b c c d e f g Antes
VM B
d e f g
e f gDepois
a
Memory Ballooning
Physical Host Memory
Inflate
VM A
a b a c
a dcb e f g
Ballon
Driver
Low Memory Condition
h i
g h i
a dcb e fRecovered Memory
✪✪✪
page cache drop
page-out (swap)
Memory Compression
Physical Host Memory
VM A
a b a c
a cb gUncompressed Memory
g
a c-gbCompressed Memory
c g
Memory Swapping
Physical Host Memory
Random OS Pages
VM A
a b
a dcb e f gLow Memory Condition
h i
d e fAfter Swapping
c
Physical Host Disk
a
cb
g h i
x
Storage Thick x Thin Provisioning
VM A VM B
50GB50GB20GB} {
used
capacity} provisioned
capacity
Thick Thin
Resource Pooling
Workload BWorkload
E
Workload C
Workload DWorkload A Workload F
• Permite a alocação recursos (cpu, memória) dentro de um pool de servidores
• Permite a reserva de recursos (isolamento de workloads)
• Possibilita controle do overcommit de recursos pelo Cliente
Resource Pooling
VM A VM B
Resource Pool A
VM C VM D
Resouce Pool Configured Limit
Total Resource Allocated
VM E
Conteção CPU
Como identificar (*nix) ?
top ou vmstat
“Steal time is the percentage of time a virtual CPU waits for
a real CPU while the hypervisor is servicing another virtual
processor”
Conteção CPU
Como identificar (Windows) ?
contadores perfmon:
VM Processor/CPU stolen time (ESXi)
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
Conteção CPU
Possíveis causas:
•Alto nível de CPU Overcommit, associado à alta utilização (Noisy Neighbors)
•Alto número de vCPUs (ESXi)
•Limitação de Recursos no Hypervisor
Conteção CPU
Oque pode ser feito ?
• Dimensionar corretamente a quantidade de vCPUs (ESXi)
• Aumentar o tamanho da instância (amzn, azure, gcp, openstack)
• Destruir/Reiniciar instância com sintoma (amzn, azure, gcp, openstack)
Conteção Memória
Como identificar (*nix) ?
# vmware-toolbox-cmd stat balloon
990 MB
# cat /proc/vmmemctl
target: 1247 pages
current: 174 pages
Conteção Memória
Como identificar (Windows) ?
Contador perfmon:
VM Memory/Memory Ballooned in MB (ESXi)
Conteção Memória
Possíveis Causas:
•Alto nível de Memory Overcommit, associado à alta utilização (Noisy
Neighbors)
•Resource Pool Subdimensionado (ESXi)
•Limitação de Recursos no Hypervisor
Conteção Memória
Oque pode ser feito ?
• Dimensionar corretamente Resource Pool (ESXi)
• Aumentar o tamanho da instância (amzn, azure, gcp, openstack)
• Destruir/Reiniciar instância com sintoma (amzn, azure, gcp, openstack)
E o que mais ?
• Identifique seus componentes sensíveis a latência
• Tenha visão da percepção do usuário (tempo de resposta)
• Entenda seus picos e sazonalidades (prepare-se para eles)
• Reserve recursos onde for necessário (se possível)
• Instâncias maiores tendem a ter mais prioridade e compartilhar menos
recursos
• Use imagens fornecidas pelo provedor
• Não desabilite os agentes
