Departamento de Eletrnica Escola Politcnica Programa de Engenharia

Departamento de Eletrônica – Escola Politécnica Programa de Engenharia Elétrica – COPPE Black-box and Gray-box Strategies for Virtual Machine Migration Rafael dos Santos Alves http: //www. gta. ufrj. br

Informações • Autores • Timothy Wood • Prashant Shenoy • Arun Venkataramani • Mazin Yousif • Publicação • 4 th Symposium on Networked Systems Design and Implementation (NSDI) – 2007.

Motivação • Data centers • Hospedagem de sites web • Sistemas empresariais • E-commerce • Múltiplas aplicações por servidor • Alocação de recursos para atender SLAs • Popularização da virtualização

Data centers • Flutuação dinâmica da carga de trabalho • Crescimento incremental • Dependência do momento no dia • Flash crowds

Virtualização em data centers • • Redução da complexidade de gerenciamento Isolamento entre aplicações Consolidação de servidores Habilidade de remapeamento de servidores virtuais • Tratamento de carga dinâmica • Detecção de hotspots e início de migração realizados manualmente

Objetivo da proposta • Automação • Monitoramento dos recursos do sistema (CPU, memória, rede) • Detecção de hotspot • Determinação do novo mapeamento de máquinas virtuais • Duas técnicas • Caixa preta • Caixa cinza

Sandpiper • Sistema para migração automatizada de servidores virtuais • Premissas – Cluster de servidores heterogêneos – Recursos das máquinas físicas conhecidos – Cada PM (Physical Machine) executa um monitor de máquina virtual – Cada VM (Virtual Machine) executa uma aplicação ou um componente de uma aplicação – Armazenamento num sistema de arquivos em rede – Existência de um mecanismo de migração • Implementado no Xen

Sandpiper - arquitetura

Sandpiper - arquitetura • Nucleus – Responsável por coleta de estatísticas de uso de recursos em um servidor físico • Monitoring engine – Coleta de estatísticas de CPU, interface de rede e swap de memória em cada servidor virtual • Daemons nas máquinas virtuais – No caso de abordagem caixa cinza – Coleta de estatísticas em nível de SO e possivelmente de aplicação • Plano de controle – Executado num servidor separado

Sandpiper – plano de controle • Responsável pela inteligência do sistema • Recebe informações periódicas de cada nucleus • Componentes – Profile engine • Construção de perfis de utilização de recursos de máquinas físicas e virtuais – Hotspot detector • Análise dos perfis em busca de utilização agregada de algum recurso por um período suficientemente grande – Migration manager • Escolha das máquinas virtuais a serem migradas, para onde movê-las e quanto recurso alocar a cada máquina virtual

Monitoramento – caixa preta • CPU – Xen. Mon • Análise da utilização da CPU no domínio 0 – Entretanto, sobrecarga provocada por processamento de requisições de I/O de disco e de rede não são capturadas – À carga de cada VM é adicionado um fator equivalente ao montante de operações de I/O realizadas • Rede – Monitoramento interface /proc/net/dev

Monitoramento – caixa preta • Memória – Desafio • Hipervisor só conhece a alocação total de memória da VM – Solução possível • Monitoramento com tabelas de páginas sombra • Alta sobrecarga – Solução • Inferência • Baseada na atividade de swap

Monitoramento – caixa cinza • Daemon instalado no sistema hóspede • Monitoramento da interface /proc da VM – Estatísticas em nível de SO de utilização de memória, CPU e rede • Daemon de aplicação – Possível em alguns casos – Estatísticas a partir de logs de aplicação – Possibilidade de detecção explícita de violações de SLA

Geração de perfis • Perfil – Descrição compacta da utilização dos recursos de um servidor num janela de tempo W – Distribuição e série temporal • Caixa preta – 3 perfis por servidor • Caixa cinza – 4 perfis adicionais • Utilização de memória, tempo de serviço, taxa de drop de requisições, taxa de chegada de requisições

Geração de perfis • Distribuição – Distribuição de probabilidade da utilização do recurso na janela W • Ex. : histograma normalizado – Captura variações da utilização de recursos – Utilizado pelo migration manager para estimar picos de utilização de recursos • Série temporal – Lista de todas as observações reportadas numa janela de tempo W – Captura correlação temporal da utilização de um recurso – Utilizado pelo hotspot detector para observar tendências de utilização

Geração de perfil

Detecção de Hotspots • Implícita • Por servidor físico • CPU, rede ou swap de memória excedem limiar • Explícita • Por servidor virtual • Utilização de memória, taxa de pacotes descartados ou tempo de resposta excede limiar • Hotspot sinalizado se • k observações acima do limiar nas últimas n observações • Previsão de hostpot na próxima iteração

Detecção de Hotspots • Predição • Utiliza séries temporais

Provisão de recursos – black box • Descoberta dos recursos necessários para as VMs sobrecarregadas • CPU e rede • Pico de utilização para cada VM sobrecarregada • Perfil de distribuição • Percentil 95, por exemplo • Escalonador do Xen é work-conserving • Entretanto, se todas as VMs sobrecarregadas distribuição não fornece bons resultados • Subestimativa da necessidade de CPU

Provisão de recursos – black box • Exemplos • 2 VMs • VM 1 utilza 70% e VM 2 20% • Perfil de distribuição infere corretamente necessidade de CPU • 2 VMs • VM 2 utiliza 50% e VM 1 precisa de 70% • Xen aloca 50% para cada VM • Perfil infere necessidade subestimada • Quando CPU (ou rede) é totalmente utilizada Sandpiper adiciona um valor ∆ à estimativa

Provisão de recursos – black box • Memória • Utilização de memória não acessível no domínio 0 • Utilização inferida a partir da frequência de swap • Adição de um fator ∆m à alocação de memória da máquina virtual

Provisão de recursos – gray box • Estimativa do pico de taxa de chegada requisições (λpeak) • A partir do perfil de distribuição • CPU • Aplicação modelada como uma fila G/G/1 λcap: taxa de chegada requerida, d: tempo médio de resposta, s: tempo médio de serviço das requisições, σa: desvio-padrão do tempo entre chegadas de requisições, σb: desvio-padrão do tempo de serviço

Provisão de recursos – gray box • d – fornecido pelo SLA • λcap capacidade atual da máquina virtual • λpeak/ λcap fator de escala da necessidade de CPU

Provisão de recursos – gray box • Rede • Produto entre λpeak e tamanho médio do arquivo requerido (b) • Montante de dados transferido na rede no período de pico

Migração de hotspots • Determinação de novo mapeamento entre máquinas virtuais e servidores físicos evitando violações de limiares • NP-hard • Solução: utilização de heurística com redução da sobrecarga de migração • Migração de carga do servidor mais carregados para os menos carregados • Capturando cargas multidimensionais

Migração de hotspots • Fase de migração • PMs ordenados - volume • VMs ordenados - VSR (volume-to-size ratio) • Migração do máximo volume por unidade movida • Minimização da sobrecarga • VM com maior VSR do PM com maior volume • É possível alocação no PM com menor volume? • Em caso negativo tentar PM com 2º maior volume • Se nenhum PM pode abrigar VM com maior VSR então segundo VSR é selecionado • Em seguida, PM com segundo maior volume

Migração de hotspots • Fase de troca • Utilizada se não existem recursos para reduzir carga de servidores e eliminar hotspots • Troca de uma VM com VSR alto com VMs com VSRs baixos de outros PMs com baixa carga • Possível se dois PMs podem abrigar as VMs candidatas do outro sem exceder limiares • Pode requerer um terceiro servidor de rascunho

Implementação e avaliação • Plano de controle • Daemon executado no nó de controle • Profile engine • 200 medidas • Hotspot detector • k = 3, n = 5, limiar = 75% • 750 linhas de código python

Implementação e avaliação • Nucleus • Xen’s Python management API • I = 10 segundos • Daemons – caixa cinza • Informações a partir da interface /proc • Apache • Analisador de log e dispatcher em tempo real • 650 linhas de código python

Efetividade de migração • Scripts PHP intensivos em CPU • Tráfego gerado com httperf • Três fases causando hotspots em diferentes máquinas físicas

Efetividade de migração

Troca de VMs • • VM 1 e VM 2: 384 MB de RAM VM 3 e VM 4: 256 MB de RAM Carga de VM 1 incrementada de forma gradual Memória do nó de controle utilizada como rascunho

Cargas em múltiplos recursos • • 2 PMs com 2 VMs cada Cada PM com Cada VM com 256 MB de RAM VMs em PM 1 – Intensivo em rede – Transferência de arquvivos grandes • VMs em PM 2 – Intensivo em CPU – Apache com scripts PHP dinâmicos – VM 2 executa um banco de dados • Crescimento da utilização de memória no tempo • ∆m = 32 MB

Cargas em múltiplos recursos

Cargas em múltiplos recursos

Gray v. Black – memória • • • SPECjbb 2005 1 VM com 256 MB de RAM PM com 384 MB de RAM PM adicional com 1 GB de RAM Carga incrementada a cada 2 minutos Cinza – Hotspot sinalizado sempre que RAM livre menor que 32 MB

Gray v. Black – memória

Gray v. Black – Apache • 3 PMs e 4 VMs – VM 1, VM 2 e VM 3 em PM 1, e VM 4 em PM 2 • httperf • Em t=80 s taxa de requisição incrementada rapidamente em VM 1 e VM 2 – Necessidade de CPU alcança 70% • VM 3 e VM 4 requerem constantemente 33 e 7% de CPU • I = 6 s

Gray v. Black – Apache

Gray v. Black – Apache

Gray v. Black – data center • 16 PMs e 35 VMs • Aplicações – – – 5 VMs com LAMP com RUBis 5 VMs com Apache 5 VMs servidores de streaming 2 VMs com banco de dados 15 VMs com scripts PHP e arquivos html grandes • cargas gerados – – 14 VMs com hotspots 4 PMs com hotspots de CPU e 2 com hotspots de rede 4 PMs com 45% de utilização de pelo menos um recurso 6 PMs entre 25 e 40% de utilização de recusos

Gray v. Black – data center

Sobrecarga e escalabilidade • Nucleus – rede – CPU • 1% de sobrecarga – Apache • negligenciável

Sobrecarga e escalabilidade • Plano de controle

Estabilidade • Simulação – 50 PMs com 3 VMs cada – Número de hotspots simultâneos entre 20 e 45 – Utilização média • 85% e 45%

Conclusão • Virtualizção possibilita migração de máquinas virtuais • Sandpiper – Automação das tarefas ligadas à migração • Caixa cinza vs. caixa preta