Black-box and Gray-box Strategies for Virtual Machine Migration 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 4th 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 XenMon 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 Caixa preta Caixa cinza 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 Série temporal 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 VM1 utilza 70% e VM2 20% Perfil de distribuição infere corretamente necessidade de CPU VM2 utiliza 50% e VM1 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 VM1 e VM2: 384 MB de RAM VM3 e VM4: 256 MB de RAM Carga de VM1 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 PM1 Intensivo em rede Transferência de arquvivos grandes VMs em PM2 Intensivo em CPU Apache com scripts PHP dinâmicos VM2 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 httperf VM1, VM2 e VM3 em PM1, e VM4 em PM2 httperf Em t=80s taxa de requisição incrementada rapidamente em VM1 e VM2 Necessidade de CPU alcança 70% VM3 e VM4 requerem constantemente 33 e 7% de CPU I = 6s

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