JOSÉ EDUARDO FRANÇA OTIMIZAÇÃO DE CHECKPOINT DE MÁQUINA VIRTUAL PARA TOLERÂNCIA A FALHAS

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO JOSÉ EDUARDO FRANÇA OTIMIZAÇÃO DE CHECKPOINT DE MÁQUINA VIRTUAL PARA TOLERÂNCIA A FALHAS Rio de Janeiro 2013

2 INSTITUTO MILITAR DE ENGENHARIA JOSÉ EDUARDO FRANÇA OTIMIZAÇÃO DE CHECKPOINT DE MÁQUINA VIRTUAL PARA TOLERÂNCIA A FALHAS Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Sistemas e Computação. Orientadora: Raquel Coelho Gomes Pinto Rio de Janeiro 2013

3 c2013 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80 Praia Vermelha Rio de Janeiro - RJ CEP: Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do autor e do orientador F814o França, José Eduardo. Otimização de Checkpoint de Máquina Virtual para Tolerância a Falhas / José Eduardo França; orientado por Raquel Coelho Gomes Pinto. Rio de Janeiro: Instituto Militar de Engenharia, p. : il. Dissertação (mestrado). - Instituto Militar de Engenharia.- Rio de Janeiro, Sistemas e Computação teses, dissertações. 2. Virtualização de Computadores. 3. Redes de Computadores. 4. Checkpoint - processamento de dados. I. Pinto, Raquel Coelho Gomes. II. Título. III. Instituto Militar de Engenharia. CDD 003 2

4 INSTITUTO MILITAR DE ENGENHARIA JOSÉ EDUARDO FRANÇA OTIMIZAÇÃO DE CHECKPOINT DE MÁQUINA VIRTUAL PARA TOLERÂNCIA A FALHAS Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Sistemas e Computação. Orientadora: Raquel Coelho Gomes Pinto D.Sc. Aprovada em 7 de fevereiro de 2013 pela seguinte Banca Examinadora: Profª Raquel Coelho Gomes Pinto D.Sc. do IME Presidente Prof Lauro Luis Armondi Whately D.Sc. da UFRJ Prof Anderson Fernandes Pereira dos Santos D.Sc. do IME Rio de Janeiro

5 AGRADECIMENTOS Agradeço a todas as pessoas que me incentivaram, apoiaram e possibilitaram esta oportunidade de ampliar meus horizontes. Agradecimentos à Profª Raquel, por suas disponibilidades, atenções e, principalmente, pelas relevantes observações realizadas ao longo do curso, e ao funcionário Luiz do Laboratório de Informática Seção de Engenharia de Computação do IME, que me auxiliou na montagem dos meus experimentos. Em especial, desejo agradecer à minha esposa Juliane Marques Romeiro França, que possibilitou alvejar esta grande conquista com o seu imprescindível apoio e compreensão, sem os quais tornariam impossível alcançar esse feito. José Eduardo França 4

6 SUMÁRIO LISTA DE ILUSTRAÇÕES...7 LISTA DE TABELAS...9 LISTA DE ABREVIATURAS INTRODUÇÃO Motivação Doutrina de Defesa Problema do Checkpoint com VMs Objetivo do Trabalho Organização da Dissertação CONCEITOS BÁSICOS Virtualização Máquina Virtual Técnicas de Virtualização Virtualização Total Paravirtualização Virtualização por Containers Tolerância à Falha com a Virtualização Tolerância à Falha Tolerância à Falha com VMs Checkpoints de VMs Checkpoint Contínuo Checkpoint Especulativo Remus Checkpoint Eventual Recuperação Otimizando Checkpoints Checkpoint em WAN

7 3 AJUSTE DINÂMICO DO INTERVALO ENTRE CHECKPOINTS Problema Cenário utilizado pela Abordagem Dinâmica Abordagem Dinâmica VALIDAÇÃO DA ABORDAGEM DINÂMICA Descrição dos Experimentos e Objetivos Ambiente dos Experimentos Benchmarks Metodologia da Validação Resultados de Desempenho Cachebench Httperf Validação da abordagem Cachebench Httperf CONSIDERAÇÕES FINAIS Conclusões do Trabalho Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS

8 LISTA DE ILUSTRAÇÕES FIG. 1.1 Tráfego de saída do host de origem que tem uma VM protegida...15 FIG. 2.1 Princípio básico de máquinas virtuais...18 FIG. 2.2 Representação do aproveitamento dos recursos físicos de uma máquina real (a) sem e (b) com a virtualização. Extraído de 가 상 화 (Virtualization), [S.d.]...20 FIG. 2.3 Modelo em camadas de Virtualização de Computadores...21 FIG. 2.4 Tipos de máquinas virtuais com relação a sua implementação. Adaptado de SMI- TH; RAVI NAIR, FIG. 2.5 Modos de operação de uso de hardware na virtualização. Extraído de TANEN- BAUM, 2007, cap FIG. 2.6 Execução de um checkpoint. Extraído de JUN ZHU et al., FIG. 2.7 Dependência entre os estados do disco e da memória no checkpoint com migração contínua. Extraído de WENCHAO CUI et al., FIG. 2.8 Uso do buffered block device. Extraído de WENCHAO CUI et al., FIG. 2.9 Modelo 3PC para a migração contínua. Extraído de WENCHAO CUI et al., FIG Etapas de um período completo de um checkpoint especulativo. Adaptado de PETROVIC; SCHIPER, FIG Checkpoint assíncrono do disco. Adaptado de CULLY et al., FIG Sincronização em um checkpoint do Kemari. Adaptado de TAMURA, FIG Configuração do SecondSite sobre WAN. Extraído de RAJAGOPALAN et al., FIG. 3.1 Cenário da proposta...44 FIG. 3.2 Gráfico representativo da abordagem...47 FIG. 4.1 Resultado do read-cachebench...52 FIG. 4.2 Resultado do write-cachebench...53 FIG. 4.3 Número de páginas sujas gerado pelo read-cachebench...56 FIG. 4.4 Comparação entre taxas de transmissão do protocolo de checkpoint do Remus com intervalo de 200 ms, demais intervalos e a abordagem dinâmica, usando o cachebench

9 FIG. 4.5 Taxa de transmissão média durante a execução do read-cachebench...57 FIG. 4.6 Taxa de transmissão média durante a execução do write-cachebench...58 FIG. 4.7 Comparação entre taxas de transmissão do protocolo de checkpoint do Remus com intervalo de 200 ms, demais intervalos e a abordagem dinâmica, usando o httperf...60 FIG. 4.8 Taxa de transmissão média durante a execução do httperf

10 LISTA DE TABELAS TAB. 4.1 Dados estatísticos sobre a execução do read-cachebench com intervalo de 200 ms entre checkpoints...52 TAB. 4.2 Dados estatísticos sobre a execução do write-cachebench com intervalo de 200 ms entre checkpoints...54 TAB. 4.3 Percentual de erros de conexão http em relação ao intervalo entre checkpoints...54 TAB. 4.4 Dados estatísticos sobre a execução do httperf com intervalo de 200 ms entre checkpoints...55 TAB. 4.5 Dados estatísticos sobre o intervalo entre checkpoints do trace read-cachebench otimizado com limiares 5,3 e 18,75 MBps...57 TAB. 4.6 Dados estatísticos sobre o intervalo entre checkpoints do trace read-cachebench otimizado com limiares 6 e 18,75 MBps...58 TAB. 4.7 Dados estatísticos sobre o intervalo entre checkpoints do trace write-cachebench otimizado com limiares 6 e 18,75 MBps...59 TAB. 4.8 Dados estatísticos sobre o intervalo entre checkpoints do trace httperf otimizado com limiares 25 e 31,25 MBps

11 LISTA DE ABREVIATURAS ABREVIATURAS 3PC - Three-phase commit ou Confirmação em Três Fases API - Application Programming Interface BGP - Border Gateway Protocol CPU - Central Processing Unit ou Unidade de Processamento Central DRBD - Distributed Replicated Block Device FDRT - Fine-Grained Dirty Region Tracking FT - Fault Tolerance ou Tolerância à Falha HA - High-Availability ou Alta Disponibilidade HBFT - Hypervisor-based fault tolerance HPC - High Performance Computing HVM - Hosted Virtual Machine ou Máquina Virtual Hospedada I/O - In/Out ou Entrada e Saída (E/S) IP - Internet Protocol ou Protocolo de Internet JVM - Java Virtual Machine ou Máquina Virtual Java LAN - Local Area Network LM - Live Migration ou Migração Ativa LVM - Logical Volume Management ou Gerenciamento de Volume Lógico NAS - Network Attached Storage PV - Paravirtualizado ou Paravirtualização SAN - Storage Area Network SO - Sistema Operacional U - Unprivileged ou Não-privilegiado VCPU - Virtual CPU ou CPU Virtual VM - Virtual Machine ou Máquina Virtual VMM - Virtual Machine Monitor ou Monitor Máquina Virtual VT - Virtualization Technology ou Tecnologia de Virtualização WAN - Wide Area Network 10

12 RESUMO Atualmente a virtualização de computadores é amplamente empregada, motivada principalmente pela redução de custos e pela facilidade de gerenciamento dos grandes data centers. Um outro motivo de optar por tal tecnologia deve-se ao fato de proporcionar um maior grau de disponibilidade dos serviços que estão executando sobre uma máquina virtual. E uma das formas de viabilizar a alta disponibilidade é replicar periodicamente o estado da máquina virtual para um host de backup. No entanto, esse procedimento, conhecido como checkpoint, compromete o desempenho das aplicações da máquina virtual protegida, além de gerar um custo adicional sobre a rede. A presente proposta apresenta uma abordagem para reduzir tais custos, ajustando dinamicamente o intervalo de tempo entre os checkpoints. 11

13 ABSTRACT Currently the computer virtualization is widely employed, mainly motivated by cost reduction and easy management of data centers. Another reason to opt for this technology is due to the fact that it provides a higher degree of availability of services which are running on a virtual machine. One way to provide high availability is periodically replicate the state of the virtual machine to a backup host. However, this mechanism, known as checkpoint, compromises the performance of the protected virtual machine applications, besides generating an additional cost on the. This research proposes an approach to reduce such overhead through a dynamic fit between checkpoint interval times. 12

14 1 INTRODUÇÃO A Virtualização tornou-se uma importante ferramenta no projeto de sistemas computacionais. O uso de máquinas virtuais, ou virtual machines (VM), oferece a habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer (BONDI, 2000). Ou seja, essa ferramenta permite o desenvolvimento de um sistema capaz de suportar um aumento de carga elevando a quantidade de recursos, que no caso são as VMs. A migração em tempo real de máquinas virtuais, conhecido como Live Migration (CLARK et al., 2005), é uma técnica que permite a migração de VM entre hosts físicos distintos sem interromper o acesso à VM. Essa técnica pode ser utilizada para realizar o balanceamento de carga em um Data Center e proporcionar um maior grau de disponibilidade. A Virtualização e o Live Migration permitiram estruturar um ambiente tolerante à falha de alta disponibilidade, do inglês high availability (HA), o que é muito desejável por organizações de TI, aumentando o grau de confiabilidade dos seus serviços. Uma solução adotada para construir tal ambiente é proteger uma VM pelo uso de checkpoints, que consiste em enviar as diferenças do estado da VM com relação ao seu estado anterior para um host backup, de modo a assegurar que sempre haja uma imagem consistente da VM disponível em um dos hosts. No entanto, essa solução prejudica o desempenho da VM protegida e gera uma grande sobrecarga na rede, problemas os quais são potencializados em redes de menor velocidade, como uma WAN. Assim, um dos principais desafios é realizar uma contenção da largura de banda utilizada, de modo que a solução de HA não gere um colapso na rede. Do exposto, esta dissertação apresenta uma técnica de um checkpoint otimizado que busca reduzir o custo de sua operação sobre a rede quando comparado com outros checkpoints. 13

15 1.1 MOTIVAÇÃO DOUTRINA DE DEFESA As operações militares compreendem um complexo de atividades que exige uma elevada capacidade de planejamento, comando, controle e coordenação de emprego das forças terrestre, aérea e naval. A grande mobilidade, a velocidade de deslocamento dessas forças e o grande tráfego de informações exigem um planejamento centralizado, um comando único e uma execução descentralizada, fazendo com que as decisões sejam rápidas e que possam ser executadas oportunamente (EME, 1997). Essas características levam à necessidade de um Sistema Militar de Comando e Controle, que é o conjunto de instalações, equipamentos, comunicações, doutrinas, procedimentos e pessoal essenciais para o comandamento, em nível nacional, das crises e dos conflitos (MD, 2006). Conforme preconizado pelo Ministério da Defesa do Brasil (MD, 2006), um Sistema de Comando e Controle será confiável se apresentar os atributos descritos a seguir: a) Segurança: capacidade de preservação do Sistema ou de suas partes componentes, contra violações ou acessos não autorizados; b) Robustez: capacidade de sobrevivência e manutenção da eficácia do sistema em relação a um conjunto de tarefas, situações e condições pré-estabelecidas, quando exposto a eventos desestabilizadores provenientes do ambiente operacional, de danos internos ou de casos fortuitos; e c) Continuidade: capacidade de rápida recuperação do Sistema, ou de seu ajuste, ao sofrer os efeitos dos eventos desestabilizadores supracitados. O planejamento do sistema de Comando e Controle deverá sempre buscar a continuidade de funcionamento, com a utilização de dobramento de meios, rotas seguras e caminhos alternativos. Fazendo um mapeamento desses atributos com os tipos de transparência de um sistema distribuído definidos pelo TANENBAUM (TANENBAUM; STEEN, 2006), observamos que 14

16 o Sistema Militar de Comando e Controle deve ser um sistema transparente à falha ou tolerante à falha. Do exposto no início desta introdução, observa-se que a virtualização poderá atuar nesse ambiente, de modo a propiciar um ambiente tolerante à falha, pois possui suporte a serviços que reforçam os atributos descritos acima PROBLEMA DO CHECKPOINT COM VMS Com o intuito de demonstrar a sobrecarga na rede que o uso de checkpoints em VM gera, foi realizado o seguinte experimento: foi criada uma VM com o Xen que permaneceu um tempo ociosa. Em seguida, utilizou-se a ferramenta de checkpoint do Xen (BARHAM et al., 2003), denominada Remus, que realiza um checkpoint a cada 200ms e, em determinados momentos, foi executado o benchmark Unixbench (NIEMI; SMITH, I., [S.d.]) na VM. FIG. 1.1: Tráfego de saída do host de origem que tem uma VM protegida. O tráfego de saída (outbound) do host de origem que possui uma única VM ociosa não passou de 130 Bps ou 1 kbps. Com o Remus executando, ilustrado na FIG. 1.1, ao proteger essa mesma VM, no período entre 16:10h-17:10h, nota-se um grande salto no tráfego de saída do host, cuja média da taxa foi de 6,7 MBps. E o custo sobre a rede aumenta ainda mais ao executar o Unixbench na VM nos períodos entre 14:00h-14:55h, 15:15h-16:10h e 17:10h- 15

17 18:05h. Nesses períodos, as cargas de trabalho do benchmark geraram picos de quase 12 MBps e uma média de 9,5 MBps de saída. Conclui-se que o Remus gera uma grande sobrecarga na rede com uma VM, o que pode comprometer demasiadamente o desempenho de um ambiente de produção. 1.2 OBJETIVO DO TRABALHO Como já foi visto, os checkpoints de VM geram uma grande sobrecarga na rede, que é po- tencializada em redes de menor velocidade, como por exemplo a WAN, pois a capacidade de vazão é reduzida. Por isso a importância de apresentar melhorias que reduzam tal custo, no intuito de viabilizar a técnica de checkpoint de VM nesses tipos de rede. Sendo assim, esta dissertação apresenta uma técnica de um checkpoint dinâmico, que ajusta o intervalo de tempo entre os checkpoints conforme a necessidade, a fim de reduzir o custo de sua operação sobre a rede quando comparado com outros checkpoints. A ideia principal da abordagem é estabelecer a taxa máxima de transmissão que a técnica de checkpoint pode usar. É com base nesse limiar que o intervalo entre checkpoints é ajustado, de modo a não sobrecarregar a rede. Em contrapartida, se a técnica de checkpoint não estiver usando a capacidade da rede que lhe é atribuída, o intervalo também é ajustado, no intuito de melhorar o desempenho da VM protegida, diminuindo o número de checkpoints gerados por unidade de tempo. 1.3 ORGANIZAÇÃO DA DISSERTAÇÃO Para uma melhor compreensão, esta monografia está organizada da seguinte forma: no capítulo 2, dá-se a visão geral sobre a virtualização e como é a estrutura e o funcionamento de uma máquina virtual, bem como é mostrado as formas de se obter um ambiente HA usando máquinas virtuais, principalmente pelo uso de checkpoints. No capítulo 3, é apresentada a abordagem dinâmica para otimizar o protocolo de checkpoint. No capítulo 4, é feita a descrição do ambiente de testes e dos benchmarks utilizados, bem como a validação da abordagem 16

18 proposta. Por fim, as conclusões, trabalhos relacionados e os trabalhos futuros são apresentados no capítulo 5. 17

19 2 2.1 CONCEITOS BÁSICOS VIRTUALIZAÇÃO Virtualização, em computação, é a criação de uma versão virtual de algo, como uma pla- taforma de hardware, sistema operacional (SO), um dispositivo de armazenamento ou recursos de rede. Em outras palavras, a virtualização consiste em estender ou substituir um recurso1 existente por um outro, de modo a imitar um comportamento (CARISSIMI, 2008). Esta pesquisa aborda a virtualização de máquinas computacionais, conhecidas como Máquinas Virtuais ou Virtual Machines (VM) e são ilustradas genericamente na FIG Por exemplo, sobre o hardware é posto uma camada de software, o sistema operacional hospedeiro (SO A), que fornece a ilusão de uma máquina virtual B para as aplicações sobrejacentes. No entanto, uma dessas aplicações pode ser a implementação de uma VM C e esta, por sua vez, oferece um ambiente de execução para suas aplicações específicas. Um exemplo prático desse último caso é a Máquina Virtual Java (JVM), que permite que aplicações Java executem um ambiente virtual implementado para o sistema operacional GNU/Linux ou para o Windows. FIG. 2.1: Princípio básico de máquinas virtuais. Existem diversas vantagens na virtualização de computadores. As principais são: 1 interface, dispositivo, conjunto de dispositivos, processador, memória, disco etc 18

20 a) Isolamento: talvez a principal vantagem da virtualização. Embora possam compartilhar os recursos físicos de um único computador, as máquinas virtuais ficam totalmente isoladas umas das outras, como se fossem máquinas físicas separadas. Se, por exemplo, houver quatro máquinas virtuais em um único servidor físico, e uma delas falhar, as outras três continuarão disponíveis. O isolamento é um dos principais motivos pelos quais a disponibilidade e a segurança dos aplicativos em execução em ambientes virtuais são muito superiores aos dos aplicativos em execução em um sistema tradicional não virtualizado ( VMware.com, [S.d.]), pois agora é possível dar uma maior grau de segmentação dos serviços, ou seja, atribuir poucos serviços (as vezes apenas um) por VM. Com isso, reduz significativamente a probabilidade de um serviço gerar conflitos em outros; b) Encapsulamento: característica que torna uma VM portátil e fácil de gerenciar. Por exemplo, é possível mover e copiar uma máquina virtual de um local para outro como qualquer outro arquivo de software, ou salvá-la em qualquer mídia padrão de armazenamento de dados ( VMware.com, [S.d.]); c) Compatibilidade: como um computador físico, a VM possui um sistema operacional, aplicativos e todos os componentes encontrados em um computador físico (placa-mãe, placa VGA, controlador de placa de rede, etc.). Consequentemente, as máquinas virtuais são totalmente compatíveis com todos os SO, aplicativos e drivers de dispositivo de uma arquitetura de computador qualquer. Isso permite dar suporte à ambientes legados. Por exemplo, quando uma empresa decide atualizar todo seu parque computacional, é possível manter o uso de aplicações legadas que dependem do sistema operacional antigo, executando-o em uma VM, o que reduz custos e dependências de uma atualização de hardware. Ou seja, a virtualização pode ser útil para aplicações que são executadas em hardware legado, que está sujeito a falhas e tem altos custos de manutenção; d) Adaptabilidade: variações na carga de trabalho podem ser tratadas facilmente. Ferramentas autônomas podem realocar recursos de uma máquina virtual para a outra (MATTOS, 2008); 19

21 e) Segurança: devido à característica de isolamento, a exploração da vulnerabilidade de uma VM não implica em comprometer as demais; e f) Custo: a redução de custos é possível de ser alcançada com a consolidação de pequenos servidores em outros mais poderosos. Essa redução pode variar de 29% a 64% (MATTOS, 2008). Isso é possível devido a baixa utilização média dos recursos na maioria dos servidores (veja FIG. 2.2). FIG. 2.2: Representação do aproveitamento dos recursos físicos de uma máquina real (a) sem e (b) com a virtualização. Extraído de 가 상 화 (Virtualization), [S.d.]. Por outro lado, a virtualização também possui as suas desvantagens, que são: a) Redução no Desempenho: a introdução de uma máquina virtual entre o sistema operacional hospedeiro e as aplicações gera um custo adicional de processamento. Mesmo com a adição de tecnologias adaptadas para a virtualização, que melhoram o desempenho das VM, sempre haverá ciclos de processamento a mais provocados pelo gerenciamento das máquinas virtuais. b) Segurança: caso o SO hospedeiro tenha alguma vulnerabilidade, todas as máquinas virtuais hospedadas sobrejacentes estão vulneráveis. Portanto, o SO hospedeiro torna-se um ponto único de falhas e estratégias de replicação das VMs precisam ser estabelecidas, a fim de dar continuidade dos serviços caso o risco se concretize. 20

22 2.1.1 MÁQUINA VIRTUAL Uma máquina virtual (VM) é uma duplicata eficiente e isolada de uma máquina real (POPEK; GOLDBERG, 1974), que funciona como um computador real com um sistema operacional. Essa definição é mostrada na FIG FIG. 2.3: Modelo em camadas de Virtualização de Computadores. A implementação de máquinas virtuais pode ser feita de dois modos. No primeiro, como é feito na JVM, é possível fazer um programa de aplicação que forneça um ambiente de execução para outras aplicações. Esse ambiente pode oferecer um conjunto de instruções abstratas que são interpretadas para gerar as instruções de máquinas não-privilegiadas, as chamadas de sistema e de API de bibliotecas que correspondem à ação abstrata desejada. Esse tipo de virtualização é o que se denomina de máquina virtual de processo (SMITH, J. E.; RAVI NAIR, 2005), como visto na FIG. 2.4a. Uma abordagem alternativa é fornecer uma camada de software entre o hardware e o SO protegendo o acesso direto deste aos recursos físicos da máquina. Essa camada oferece, como interface ao SO, um conjunto de instruções de máquina que pode ser o mesmo do processador físico, ou um outro. O resultado final é a possibilidade de se ter mais de uma camada Guest (SO + programas), mostrado na FIG. 2.4b, executando independentemente e na mesma plataforma de hardware. Esse tipo de virtualização é denominado de máquina virtual de sistema (SMITH, J. E.; RAVI NAIR, 2005). 21

23 FIG. 2.4: Tipos de máquinas virtuais com relação a sua implementação. Adaptado de SMITH; RAVI NAIR, O processo ou sistema que é executado em uma máquina virtual é o hóspede (guest), enquanto a plataforma subjacente que suporta a ferramenta de virtualização é o host. A ferramenta de virtualização que implementa uma VM de processo é muitas vezes chamado de runtime, abreviação de runtime software. A ferramenta de virtualização em uma VM de sistema é normalmente referido como monitor de máquina virtual (VMM). (SMITH, J. E.; RAVI NAIR, 2005) O VMM, também chamado de hipervisor, é um componente de software (ou seja, é um programa) que hospeda as máquinas virtuais (ROSE, 2004). Ele é responsável pela virtualização e controle dos recursos compartilhados pelas máquinas virtuais, tais como, processadores, dispositivos de entrada e saída, memória, armazenagem. Também é sua função escalonar qual máquina virtual vai executar a cada momento, semelhante ao escalonador de processos do Sistema Operacional (CARISSIMI, 2008). Uma das vantagens dos hipervisores é que normalmente eles possuem menos linhas de código do que um SO e, portanto, sujeitos a menos erros (TANENBAUM, 2007). 22

24 Esta pesquisa trabalha com VM de sistema. Nesse contexto existem dois conceitos importantes: sistema operacional hospedeiro (host) e de sistema operacional hóspede ou visitante (guest). O primeiro refere-se ao sistema operacional nativo da máquina na qual ocorrerá a virtualização, ou seja, este é o sistema operacional que é executado diretamente sobre o hardware físico. O segundo designa-se ao sistema operacional que é executado sobre o hardware virtualizado, isto é, o sistema operacional que é executado na máquina virtual. (MATTOS, 2008) TÉCNICAS DE VIRTUALIZAÇÃO Três são as principais formas de implementação dos monitores de máquina virtual: a virtualização total, a paravirtualização e a virtualização por containers VIRTUALIZAÇÃO TOTAL Nessa técnica, o sistema operacional visitante é executado sem modificações sobre o VMM. Como ilustrado na FIG. 2.5, a máquina virtual funciona como um processo de usuário em modo usuário e, como tal, não pode executar instruções sensíveis. Ela executa um sistema operacional hóspede que acredita estar no modo núcleo, embora, é claro, esteja de fato no modo usuário, denominado então de modo núcleo virtual. A máquina virtual também executa processos do usuário, que acreditam estar no modo usuário, e realmente estão (modo usuário virtual) (TANENBAUM, 2007). Para que seja possível executar instruções sensíveis, é necessário que as haja suporte a tecnologia de virtualização (VT). FIG. 2.5: Modos de operação de uso de hardware na virtualização. Extraído de TANENBAUM, 2007, cap

25 Assim, nas CPUS com essa tecnologia, quando o SO hóspede executa uma instrução sensível, tem-se uma exceção para o núcleo. O hipervisor pode, então, inspecionar a instrução para verificar se ela veio do sistema operacional hóspede na máquina virtual ou de um programa do usuário no mesmo local. No primeiro caso, o hipervisor faz com que a instrução seja executada; no segundo, ele emula o que o hardware real faria quando deparasse com uma instrução sensível sendo executada no modo usuário (TANENBAUM, 2007), ou seja, gera uma exceção. Assim, a exceção é capturada para o sistema operacional hóspede e este faz o tratamento adequado. A virtualização total tem também por objetivo fornecer ao SO visitante uma réplica do hardware subjacente, o que traz alguns inconvenientes. O primeiro deles é que o número de dispositivos a serem suportados pelo VMM é extremamente elevado, o que tornaria custoso mantê-lo atualizado. Para resolver esse contratempo, as implementações da virtualização total usam dispositivos genéricos, que funcionam bem para a maioria dos dispositivos disponíveis, mas não garantem o uso da totalidade de sua capacidade. Outro inconveniente da virtualização total é o fato de o sistema operacional visitante não ter conhecimento de que está sendo executado sobre o VMM. Assim, as instruções executadas pelo SO visitante devem ser testadas pelo VMM para que depois os respectivos tratamentos sejam emuladas pelo VMM, o que acarretaria na redução do desempenho, pois a emulação de instruções peculiares de hardware é uma tarefa desagradável e que consome muito tempo. Ela requer uma chamada ao hipervisor e, em seguida, a emulação da semântica exata de uma instrução complicada (TANENBAUM, 2007) PARAVIRTUALIZAÇÃO É muito melhor que o SO hóspede realize uma chamada direta ao hipervisor para que se realizem, entre outras, operações de E/S, ao invés dessas instruções gerarem interrupções e serem emuladas em seguida. 24

26 Por isso paravirtualizar, ou seja, modificar um SO torna-se uma alternativa interessante. Nesse modelo de virtualização, o sistema operacional é modificado para chamar o hipervisor (hypercall) ao invés de executar uma instrução sensível, ou seja, uma instrução que possa alterar o estado do sistema. Na verdade, o SO hóspede está atuando como um programa do usuário quando faz chamadas ao sistema operacional (o hipervisor). Quando esse caminho é tomado, é preciso que o hipervisor defina uma interface composta por um conjunto de chamadas aos procedimentos que o sistema operacional hóspede possa usar (TANENBAUM, 2007). Esse conjunto é implementado nos moldes de uma API. Outro ponto positivo da paravirtualização é que os dispositivos de hardware são acessados por drivers da própria máquina virtual, não necessitando mais do uso de drivers genéricos que inibiam o uso da capacidade total do dispositivo VIRTUALIZAÇÃO POR CONTAINERS Esta classe de virtualização também é conhecida como virtualização no Nível do Sistema Operacional e se apresenta como uma alternativa à virtualização clássica. Existem cenários que requerem sistemas de virtualização mais eficientes e não requerem diferentes SOs. Para estes casos, a virtualização por containers pode ser mais adequada. (FERNANDES, 2010). Nessa técnica, o kernel do sistema operacional hóspede é compartilhado entre todas as máquinas virtuais do sistema. O fato de compartilhar o kernel evita que mais uma camada de software seja adicionada ao sistema, o que torna mais eficiente as técnica desta classe. Este mesmo fato torna as máquinas virtuais menos isoladas em relação a técnicas da virtualização clássicas, já que um problema no kernel pode afetar todas as máquinas. Os processos das VMs são segregados em containers distintos. Assim, do ponto de vista do kernel, as VMs são um conjunto de processos. Já para a VM, ela tem a impressão de que está executando de forma exclusiva no kernel, ela não consegue "ver"os processos que estão em outros containers. (FERNANDES, 2010) 25

27 Pelo fato do compartilhamento do kernel, esse tipo de técnica tem uma rápida troca de contexto e consegue um acesso mais eficiente à memória. Este último também pelo fato do aproveitamento da memória ser mais eficiente, já que nas outras técnicas é necessário executar o kernel de cada MV. Por outro lado, conforme FERNANDES (FERNANDES, 2010), o Live Migration (CLARK et al., 2005) ainda não é possível nesse tipo de virtualização, pois uma modificação na máquina física de origem pode implicar em algumas modificações na estrutura do kernel. Existem diversas tecnologias pertencentes a esta classe de virtualização. Entre eles o OpenVZ ( OpenVZ.org, [S.d.]), Linux-VServer ( Linux-VServer.org, [S.d.]) e Solaris Zones ( OpenSolaris Zones, [S.d.]). 2.2 TOLERÂNCIA À FALHA COM A VIRTUALIZAÇÃO TOLERÂNCIA À FALHA Um sistema tolerante à falha (FT) deverá continuar funcionando, mesmo de forma degradada, quando encarado com algum tipo de falha, como falha de comunicação, falha de máquina, desastres com dispositivo de armazenamento e deterioração de mídia de armazenamento (SILBERSCHATZ et al., 2008). Existem dois principais modos de tornar um sistema tolerante à falha: incluindo um mecanismo de predição de falhas ou criando réplicas. O primeiro foi tratado pelo NAGARAJAN (NAGARAJAN et al., 2007), cujo experimento em HPC, que visava aumentar o desempenho do sistema em caso de falhas, monitorava hosts saudáveis e não-saudáveis em um cluster por meio de um midleware. Assim, um processo (no caso, uma VM) era migrado caso estivesse executando sobre um host não-saudável. No entanto, o segundo modo, que caracteriza a redundância, é a técnica fundamental para o tratamento de falhas (TANENBAUM; STEEN, 2006), que tem também como objetivo aumentar a disponibilidade e a confiabilidade do sistema. Entretanto, um dos principais problemas disso é manter as réplicas consistentes, pois, quando uma cópia é atualizada, é necessário assegurar que as outras também sejam atualizadas; caso contrário, as réplicas não serão mais iguais. Assim, implementar tal consistência 26

28 com eficiência costuma ser bem difícil em sistemas distribuídos de grande escala. Para isso e em outros casos, podem ser usados modelos de consistência 2 simples, que facilitam a implementação (TANENBAUM; STEEN, 2006). Há forte relação entre ser tolerante à falha e os denominados sistemas confiáveis, que possuem uma série de requisitos, entre os quais a: a) Disponibilidade: é a propriedade de um sistema estar pronto para ser usado imediatamente. Em outras palavras, um sistema de alta disponibilidade (HA) é aquele que mais provavelmente estará funcionando em dado instante no tempo; b) Confiabilidade: é a propriedade de um sistema poder funcionar continuamente sem falha. Um sistema de alta confiabilidade é aquele que mais provavelmente continuará a funcionar sem interrupção durante um período de tempo relativamente longo; c) Segurança: refere-se à situação em que, se um sistema deixar de funcionar corretamente durante um certo tempo, nada de catastrófico acontecerá; e d) Capacidade de manutenção: refere-se à facilidade com que um sistema que falhou pode ser consertado. Um sistema de alta capacidade de manutenção também pode mostrar alto grau de disponibilidade, em especial se as falhas puderem ser detectadas e reparadas automaticamente. Em ambientes redundantes, existem sistemas que dependem do lock stepping da CPU, o que garante que duas CPUs executem os mesmos comandos. Se ambas estiverem em um mesmo ambiente idêntico e possuírem os mesmos códigos e dados, uma instância sempre poderá substituir a outra. Essa abordagem garante, de fato, uma genuína solução tolerante à falha. No entanto, tais sistemas necessitam ser construídos sobre uma complicada estrutura redundante, que é capaz de mantê-los e, em caso de falha, alternar para os backups. A capacidade de per- 2 Um modelo de consistência é um contrato entre processos e o sistema, onde este garante que, se o processo se - guir determinadas regras, o depósito de dados será consistente e os resultados sobre as operações de memória serão previsíveis. (TANENBAUM; STEEN, 2006) 27

29 manecerem ativos de forma transparente à falha é complexa e cara o suficiente para tornar a implantação proibitiva em servidores comuns. Um modo de tornar um sistema HA mais acessível é utilizando VMs, mais estritamente, replicando VMs TOLERÂNCIA À FALHA COM VMS Um dos modos de garantir tolerância à falha usando VMs é usando DRBD ( DRBD.org, [S.d.]), combinando com o Heartbeat ( Heartbeat - Linux-HA, [S.d.]) ou Pacemaker ( Pacemaker - Linux-HA, [S.d.]). Essa solução consiste basicamente em enviar as alterações de disco causadas pela VM protegida para um host de backup, as quais devem gerar um conjunto de dados que possibilita restaurar essa VM em um estado consistente. Assim, caso o host de origem falhe, a solução, que monitora a disponibilidade da máquina virtual constantemente (pelo Heartbeat, por exemplo), inicia a VM no host backup. Essa técnica auxilia os administradores na redução do tempo de interrupção, que se limita a poucos minutos para restaurar os dados e inicializar a máquina virtual no novo host. No entanto, existem aplicações que não sobrevivem a interrupções de alguns minutos (SPENNEBERG, 2010). Para contornar esse problema, começou então a ser pesquisado soluções de HA usando VMs, onde o usuário não percebe a falha. Nesse contexto, as técnicas de replicação adotadas encapsulam o sistema em execução a ser protegido na VM primária, o que é suportado pelo hipervisor, e sincronizam os estados da VM primária e da VM backup em dois hosts distintos, de modo a assegurar que sempre haverá uma imagem consistente disponível em um dos hosts. A primeira ideia apresentada propôs que a sincronização fosse realizada pelo hipervisor (BRESSOUD; SCHNEIDER, 1996), porém observou-se que tal técnica, apesar de eficiente, era de difícil implementação (CULLY, BRENDAN et al., 2008; TAMURA et al., 2008). Atualmente, a sincronização é implementada por meio de aplicações (midlewares). Os hipervisores que implantam esses midlewares ou implementam tais funcionalidades de FT são conhecidos como Hipervisores Baseados em Tolerância à Falha (HBFT). Esses midlewares podem ser implementados de dois modos: baseado em logs, como o VMware FT (VMWARE, 2009) e Marathon everrun nível 3 ( Marathon, [S.d.]), ou baseado em checkpoints (seção 2.2.3), como o Remus (seção ), o Kemari (seção 2.2.6), o Para28

30 tus (DU; YU, H., 2009), o Taiji (JUN ZHU et al., 2011) e o Romulus (PETROVIC; SCHIPER, 2012). O primeiro modo tem dois problemas: a grande dependência do ISA do host backup, pois cada arquitetura precisa de uma implementação específica no hipervisor, e a incidência de um alto overhead em ambiente multiprocessado, por causa do acesso à memória compartilhada (JUN ZHU et al., 2011). No segundo modo, essa dependência é eliminada, o que torna barata a sua adoção, porém gera sobrecargas de rede e CPU. Uma vez que o sistema foi replicado, o próximo passo então é criar mecanismos de recuperação que atuem no momento em que a falha é detectada (a ação de acionar a VM backup em caso de falha é definida como failover). Obviamente, deseja-se que esse mecanismo seja rápido o suficiente para tornar a falha imperceptível ao usuário. Entretanto, a recuperação de um sistema costuma ser uma operação complexa e pode comprometer consideravelmente o desempenho do serviço. Ou ainda, dependendo da situação, a recuperação pode gerar um estado inconsistente ou indesejado. Isso será visto na seção CHECKPOINTS DE VMS Checkpoint ou Ponto de Verificação é o ato de salvar o estado de uma aplicação em execução para um armazenamento estável, de modo que, se a aplicação falhar, ela pode ser reiniciada a partir do último estado salvo, evitando assim a perda do trabalho que já foi feito (AGBARIA; FRIEDMAN, 2002). Para esta dissertação, considera-se uma aplicação como sendo uma máquina virtual, e, para simplificação, considera-se checkpoint de VM apenas como checkpoint. O protocolo de checkpoint geralmente consiste em definir estados consistentes de uma máquina virtual primária (snapshot) em períodos de tempo e enviar as diferenças de um estado com relação ao estado anterior para o host backup, onde elas são reproduzidas. Como ilustrado na FIG. 2.6, o protocolo de checkpoint é iniciado no instante em que o hipervisor de origem inicializa o mecanismo de rastreamento da memória da VM primária. Entre os instantes A e B da FIG. 2.6, as páginas modificadas são rastreadas, ao mesmo tempo em que o estado de saída, como os pacotes de rede transmitidos e os dados gravados no disco, é armazenado em 29

31 um buffer. Em B, o sistema operacional hóspede é suspenso e as páginas sujas são copiadas também para um buffer. Essas páginas sujas, o estado da CPU e o estado dos dispositivos são enviados em C para o host de backup e, paralelamente, o SO hóspede retorna sua execução. Ao receber a confirmação do host de backup em F, o hipervisor confirma o checkpoint gerado no período anterior. Note que a atuação do host backup é passivo, pois ele apenas recebe as atualizações, aplica-as e envia confirmações para o host de origem. Independentemente do hipervisor usado, a geração de um checkpoint precisa ter um conjunto de mecanismos, definido como sistema de replicação, que deve: FIG. 2.6: Execução de um checkpoint. Extraído de JUN ZHU et al., a) detectar e rastrear as mudanças na VM primária: pode ser pelo rastreamento das diferenças do estado da VM, como será visto nas seções e 2.2.5, ou das operações causadas pelos eventos (seção 2.2.6); b) pausar a VM primária de forma eficiente: uma vez que se cria vários snapshots, o processo de pausar e retomar uma VM em execução deve ser muito eficiente; e c) propagar e reproduzir os snapshots no backup. Além disso, as técnicas de checkpoints devem se preocupar com questões como o desempenho da aplicação, instante de sincronização e o dado replicado. Para o desempenho, o desejo natural é que o checkpoint não o prejudique, entretanto isso não é trivial, tendo em vista o custo da replicação. O momento do checkpoint deve ser escolhido de tal forma que garanta 30

32 que se terá um estado consistente da VM. Dependendo da abordagem, isso não será 100% garantido (TAMURA, 2008). Por fim, o dado a ser replicado pode ser tratado de modo a diminuir o custo de throughput na rede. Observa-se ainda que, para alcançar um nível avançado de HA, onde o usuário não percebe a falha caso ela ocorra, o protocolo deve ter uma frequência de replicação adequada. Por exemplo, no Remus, que será apresentado na seção , a frequência é de 5 checkpoints por segundo, ou seja, são propagados a cada 200 ms. No caso do estudo do CULLY, BRENDAN et al., cada checkpoint é enviado a cada 25 ms. Naturalmente, o failover também é importantíssimo para um sistema HA, de modo que a VM e as suas conexões permaneçam íntegras durante a ação do failover. Pelo exposto até aqui, observa-se que os checkpoints geram um acréscimo no custo de desempenho, por conta do gerenciamento da sincronização dos estados das VMs, e de throughput, devido ao tamanho dos estados enviados pela rede. Nas seções a seguir, serão apresentadas algumas técnicas de checkpoint e como reduzir os custos associados CHECKPOINT CONTÍNUO O conceito básico de checkpoint contínuo é migrar os estados de uma máquina virtual para o host de backup de modo contínuo e transparente até que a falha seja detectada. Assim, esse tipo de migração deve garantir que, se uma transferência em andamento for interrompida, haja um estado válido e consistente da VM no host backup para a recuperação (WENCHAO CUI et al., 2009). Isso traz questões importantes, como a: a) continuidade da migração: embora o live migration (LM) proporcione um menor downtime, seu tempo total de migração é considerável. Para obter checkpoints rápidos e frequentes, a migração contínua deve reduzir esse tempo para uma ordem de dezenas de milissegundos. Além disso, procedimentos devem ser adotados para que as migrações em curso não corrompam os estados consistentes anteriormente migrados para a máquina de backup; e 31

33 b) consistência coerente: quando as aplicações são revertidas para o último estado migrado, a imagem de disco correspondente também deve ser restaurada, de modo a não gerar uma incompatibilidade entre os estados da memória e do disco no host backup. É necessário então estabelecer uma dependência entre os estados no momento do checkpoint. Essa dependência pode ser vista na FIG. 2.7, onde o protocolo de checkpoint indica os pontos exatos de restauração do disco e da memória, de modo a garantir a compatibilidade entre os estados. FIG. 2.7: Dependência entre os estados do disco e da memória no checkpoint com migração contínua. Extraído de WENCHAO CUI et al., No checkpoint contínuo, os estados internos (memória, CPU, etc) são replicados através de um fluxo de dados de LM. Assim, esse procedimento estende o live migration com as seguintes modificações: a) Migração programada: a principal mudança na migração contínua é realizar migração imediatamente após a anterior ter sido completada; b) Migração leve: transferir continuamente apenas as páginas sujas; e c) Migração bufferizada : no host de origem, o dado migrado é armazenado em um buffer até que a iteração da migração3 atual seja concluída. Só então esse dado é transferido para o host de backup. No host de backup, o dado é armazenado e verificado antes de com- 3 ou seja, uma iteração i de um processo de LM, onde as páginas transferidas na rodada i são aquelas que foram modificadas durante a rodada i-1 (CLARK et al., 2005). 32

34 biná-lo com os estados já migrados, de modo que uma migração incompleta não afete os atuais estados consistentes. Com relação aos dados armazenados em disco, a proposta apresentada por WENCHAO CUI et al., 2009 faz uso de um NAS. Assim, foi introduzido o buffered block device, que nada mais é do que uma porção da memória para enfileirar as escritas que são em seguida transmitidas para o NAS, como ilustrado na FIG Uma questão importante nesse contexto é que caso uma falha ocorra, os estados internos são revertidos para o estado de migração anterior. No entanto, não há garantias que os estados externos retornarão de modo compatível, devido ao tempo de transferência dos dados. Para evitar esse problema, a migração contínua introduz um mecanismo de confirmação em três fases (three-phase commits ou 3PC), que abre um canal de eventos para solicitações e respostas de confirmações (commits), de modo a possibilitar a visão do estado da migração tanto para o host de origem quanto para o host de backup. FIG. 2.8: Uso do buffered block device. Extraído de WENCHAO CUI et al., Como visto na FIG. 2.9, a primeira fase do 3PC consiste em migrar os estados internos e bufferizar as escritas de disco, sem afetar o NAS. Essa fase finaliza com o envio do COMMIT 1. Na segunda fase, é realizada a escrita dos dados bufferizados no NAS e, em seguida, a confirmação dessa fase é enviada. Na última fase, uma mensagem de COMMIT 3 é enviada 33

35 para o host de backup, que irá mesclar estados internos bufferizados à VM de backup. Tanto a origem e o destino agora definem um novo estado consistente, designado como T1. Caso uma falha ocorra durante o 3PC, a VM é restaurada a partir do último estado consistente conhecido, que, no exemplo da FIG. 2.9, é o T0. FIG. 2.9: Modelo 3PC para a migração contínua. Extraído de WENCHAO CUI et al., Um problema do checkpoint contínuo é a possibilidade de gerar uma inconsistência, dependendo do momento em que a falha acontecesse (TAMURA, 2008). Por exemplo, se uma falha ocorresse entre COMMITTED2 e o FINALIZE (COMMIT3) (FIG. 2.9), o estado da VM no host Slave e não estaria consistente com o estado do NAS. Esse inconveniente não ocorre nos outros checkpoints a seguir CHECKPOINT ESPECULATIVO O checkpoint especulativo se caracteriza pelo fato do sistema de replicação ter que armazenar a saída do estado externo da VM primária até que um determinado checkpoint seja reconhecido e assim enviá-la para os respectivos clientes da VM primária. Durante todo o período em que essa saída é retida, esse sistema deve garantir que a máquina virtual primária continue 34

36 executando como se não houvesse tal retenção, ou seja, a VM primária está no modo de execução especulativa. O checkpoint especulativo observa três precedimentos (CULLY, BRENDAN et al., 2008): a) Replicação de um sistema completo baseado em VMs; b) Execução especulativa: procedimento que permite a VM primária continuar executando, mesmo que suas saídas do estado externo sejam retidas. Durante esse procedimento, as requisições dos clientes são recebidas, mas as respectivas respostas são armazenadas em um buffer local; e c) Replicação Assíncrona: bufferizando a saída da VM primária, permite que a replicação seja realizada de forma assíncrona. Assim, a VM primária pode continuar sua execução no exato momento em que seu estado foi bufferizado, sem esperar pela confirmação da VM de backup, minimizando esse tempo de espera REMUS Uma ferramenta que implementa esse tipo de checkpoint é o Remus (CULLY, BRENDAN et al., 2008). Conforme a FIG. 2.10, cada período do Remus 4 divide-se em quatro etapas: Etapa I Stop-and-copy: a VM primária é pausada e quaisquer alterações de memória e CPU da VM são copiadas para um buffer local do host de origem, nos mesmos moldes do stop-and-copy do LM5 com algumas otimizações. Uma delas, obviamente, é manter a máquina virtual primária executando no host de origem após terminar o stop-and-copy. É nesta 4 No final de 2009, a comunidade Xen adotou o Remus como serviço de tolerância à falha das VMs ( Release Information Xen 4.0.x, [S.d.], Remus Documentation, [S.d.]). 5 a VM de origem é parada, as páginas remanescentes são copiadas para a VM de destino e esta é então iniciada (CLARK et al., 2005). 35

37 etapa também que todas as saídas de rede começam a ser armazenadas em um buffer de rede local até o final da Etapa III. Etapa II Transmissão: as alterações bufferizadas na etapa I são transmitidas e armazenadas na memória do host de backup. È no início desta etapa que a VM retorna à atividade e começa a execução especulativa, que se estende até o final do período. Etapa III Sincronização: as alterações são recebidas e aplicadas pelo host de backup. Após isso, o host de backup envia a confirmação do checkpoint e este é reconhecido pelo host de origem. Etapa IV Liberação: após o reconhecimento do checkpoint, a saída de rede bufferizada é liberada para o cliente. Esta etapa se encerra quando a VM primária é pausada para iniciar o próximo checkpoint. FIG. 2.10: Etapas de um período completo de um checkpoint especulativo. Adaptado de PETROVIC; SCHIPER, É durante as etapas II, III e IV que as páginas alteradas da VM protegida são rastreadas. Ainda da FIG. 2.10, também pode-se observar que o cliente tem uma visão consistente da VM primária em momentos muitos discricionários, como em A e B. Além disso, a taxa de re36

38 produção do checkpoint no host de backup tem que ser rápida o suficiente para não impactar no período T, pois, se o tempo do procedimento de cópia assíncrona for maior que T, acarretará no descompasso do protocolo. O Remus pode realizar seus checkpoints com ou sem replicação de disco ( Remus Documentation, [S.d.]). No caso da replicação (FIG. 2.11), todas as escritas no disco da VM primária (1) são transmitidas de forma assíncrona para o backup (2), onde elas são armazenadas em um buffer até que o estado do checkpoint chegue (final da etapa II). Só então essas escritas bufferizadas são aplicadas no disco (3), de modo a garantir a consistência entre a memória e o disco. Observe que para o Remus, não é necessário o uso de uma rede de armazenamento, diferente do que foi descrito na seção FIG. 2.11: Checkpoint assíncrono do disco. Adaptado de CULLY et al., Para o failover, o critério adotado, para o host de origem, é o timeout de confirmação do host backup e, para o host backup, é o timeout de checkpoint do host de origem. Ou seja, os checkpoints também agem como mensagens de heartbeat. Um dos problemas do checkpoint do Remus é que os aplicativos sensíveis à latência de rede, como os definidos pelo SPECWEB2009 ( SPECweb2009, [S.d.]), podem não ser adequados nesse ambiente de replicação (CULLY, BRENDAN et al., 2008). Além disso, se a rede estiver congestionada, o protocolo pode reduzir significativamente o desempenho da VM hóspede, pois os atrasos que ocorrerão na etapa II atrasarão a execução da cópia assíncrona e 37

39 consequentemente descompassarão os checkpoints. Para esses casos, podem ser adotados otimizações que buscam reduzir a quantidade de memória a ser transferida e, consequentemente, reduzir o atraso, conforme será mostrado na seção CHECKPOINT EVENTUAL O checkpoint eventual é baseado em eventos e foi apresentado pelo TAMURA (TAMURA et al., 2008). Batizado como Kemari, esse tipo de checkpoint tem uma abordagem um pouco diferente, uma vez que a sincronização entre os estados da VM primária e da VM backup ocorre quando há um evento, como uma escrita na rede de armazenamento (FIG. 2.12). Após a sincronização, o sistema reinicia a VM primária e transmite o evento retido para o armazenamento. FIG. 2.12: Sincronização em um checkpoint do Kemari. Adaptado de TAMURA, Destaca-se aqui que o Kemari não requer mecanismos externos de buffering, que impõem latências de saída e são necessários no checkpoint contínuo e no checkpoint especulativo. Observa-se que esse tipo de checkpoint pode comprometer em muito o desempenho de SGBDs que possuem uma grande carga de I/O, pois fariam frequentes acessos ao armazenamento e gerariam muitas pausas para realizar a sincronização, causando um aumento do tempo de resposta aos usuários. 38

40 2.2.7 RECUPERAÇÃO O procedimento de recuperação de um sistema só é acionado quando uma falha ocorre. Então, é necessário detectar essa falha. Essencialmente existe somente dois mecanismos para detectar falhas: ou os processos enviam mensagens você está vivo? (mensagens de heartbeat) uns aos outros, o que é muito usado pelos HBFT, ou esperam pela entrada de mensagens de processos diferentes (TANENBAUM; STEEN, 2006). Esta última abordagem necessita definir um período de tempo que o processo ficará esperando. Uma outra questão importante é que o subsistema de detecção consiga determinar se a falha é de rede ou de nós. Caso seja um problema de rede e não fizer o devido tratamento dessa falha, pode-se ter dois serviços replicados ao mesmo tempo e que juntos gerarão informações não coerentes. No caso de uma falha de nó, mais especificamente em uma VM, não há garantias de que, uma vez efetuada a recuperação, essa mesma falha, ou semelhante, não acontecerá novamente. Para todas essas questões, dependendo do cenário envolvido, pode ser escalado um árbitro para definir qual ação deve ser executada em caso de falha. Isso será visto na seção OTIMIZANDO CHECKPOINTS Um modo de melhorar o desempenho do host de origem durante o procedimento de checkpoint é otimizar o processo de rastreamento das páginas alteradas, visto na seção Um modo de fazer isso é implementar um algoritmo de predição que tentaria prever quais páginas serão alteradas em uma iteração e assim conceder antecipadamente a permissão de escrita nessas entradas. Quando uma página é predita pelo algoritmo para ser alterada em uma rodada, a página apontada por esta entrada é marcada como suja e lhe é concedida a permissão de escrita, o que evita falta de página em caso de alteração futura. No entanto, erros de predição produzirão páginas sujas falsas, provocando consequentemente um maior consumo de banda para atualizar a VM backup. (JUN ZHU et al., 2011) 39

41 Um outro procedimento de otimização de checkpoint é o Rastreamento de Pequenas Regiões Sujas (FDRT) da memória, apresentado pelo MAOHUA LU e TZI-CKER CHIUEH (MAOHUA LU; TZI-CKER CHIUEH, 2009). Nessa abordagem, um bloco de rastreamento (tracking block) é definido como a mínima unidade de região suja (dirty region tracking) e é menor do que uma página. A vantagem nessa técnica é a possibilidade de reduzir significativamente o custo da transferência de dados, uma vez que, na técnica convencional, um único byte alterado acarreta na transferência de uma página inteira. Obviamente, fazer um controle dos blocos de rastreamento gerados provocará uma sobrecarga no desempenho da VM. MINHAS (MINHAS et al., 2011) propôs algumas otimizações que podem ser aplicadas conforme o comportamento de algumas aplicações, em especial para SGBDs. Uma das abordagens era identificar quais são as páginas que são constantemente alteradas e enviá-las independentemente das mudanças ocorridas. Com isso é gerado um ganho de desempenho pelo fato de não haver a necessidade de monitorar essas páginas recorrentes. Uma outra abordagem era não enviar páginas alteradas caso elas tenham acabado de serem carregadas do disco. Como o disco é sincronizado, basta enviar informações para que o host de backup carregue tais páginas para a memória. Outras técnicas, adotadas no LM, também podem otimizar o checkpoint, como a geração de deltas (HACKING; HUDZIA, 2009) ou a compactação de dados (HAI JIN et al., 2009), que são enviados a cada etapa do procedimento Checkpoint em WAN Por fim, vale destacar o SecondSite (RAJAGOPALAN et al., 2012), que é um serviço de tolerância a desastres concebido para a Computação em Nuvens, baseado no Remus, permitindo que máquinas virtuais sejam replicadas sobre um ambiente WAN. Para alcançar esse objetivo na grande rede, foram avaliadas questões como: a Replicação eficiente baseado na Banda disponível: usou-se a compactação dos dados dos checkpoints; 40

42 a detecção confiável de falhas: o critério deve ser bem definido, de modo a evitar que ocorra que duas VM iguais fiquem ativas ou que o failover não demore muito. Para isso, optou-se por estabelecer um serviço de arbitragem que julga a necessidade de realizar o failover; e o redirecionamento de tráfego em uma rede WAN: como a distância entre os hosts é grande, o failover deve ser compreensivo e em tempo oportuno. Assim, esse failover necessita que as atualizações de rotas IP do BGP sejam oportunas e, para isso, foi necessário adaptar o roteador BGP para essa realidade. A FIG mostra a arquitetura de roteamento. Quando o site principal falha, o site de backup executa a reconfiguração necessária da rede (por exemplo, atualizações de BGP) e retoma a execução de todas as máquinas virtuais protegidas. Isso é possível fazendo o uso do BGP multi-homing. FIG. 2.13: Configuração do SecondSite sobre WAN. Extraído de RAJAGOPALAN et al., A desvantagem do SecondSite é que ele não é bom para aplicações com muita escritas. 41

43 No entanto, pode ser útil para soluções off-the-shelf, no intuito de desenvolver e implantar rapidamente aplicações web. Assim, SecondSite é um boa alternativa para essas aplicações, pois elimina o fardo de manter a consistência, acrescentando alta disponibilidade e é transparente para a aplicação. 42

44 3 3.1 AJUSTE DINÂMICO DO INTERVALO ENTRE CHECKPOINTS PROBLEMA Uma das redes estratégicas do Exército é a EBNet, cujos sites remotos são separados por uma rede MPLS, a EBNet, com uma velocidade que varia de 8 à 100 Mbps. Para uma instituição como o Exército, ter sistemas tolerantes à falha é de suma importância. No entanto, os checkpoints convencionais geram uma grande sobrecarga na rede, principalmente em redes WAN. Por isso a importância de apresentar melhorias que reduzam tal custo, no intuito de viabilizar o protocolo de checkpoint nesse tipo de rede. Do exposto, a abordagem de um checkpoint dinâmico, que tem como principal objetivo de reduzir o custo de sua operação sobre a rede quando comparado com outros checkpoints, é apresentada para minimizar o problema descrito. A ideia principal da abordagem é variar dinamicamente o intervalo de tempo entre checkpoints, com o intuito de estabelecer a taxa máxima de transmissão que o checkpoint pode usar. Esse é um dos limiares que a presente abordagem se baseia para ajustar o intervalo entre checkpoints. O outro limiar é definido com base em um eventual subemprego da capacidade da rede, e, consequentemente, a uma redução desnecessária do desempenho, que é atribuída ao protocolo de checkpoint proposto. E nesses casos, o intervalo também é ajustado. Isso será detalhado na seção CENÁRIO UTILIZADO PELA ABORDAGEM DINÂMICA O cenário do estudo leva em consideração a EBNet, descrita na seção 3.1. Para a aborda- gem, assume-se o seguinte cenário, ilustrado na FIG. 3.1: Host de Origem: host que executa as VM que estão com seus serviços ativos. Podem conter diversas VMs, desde que respeite uma política de balanceamento de carga do site. 43

45 Host Backup: host que irá privilegiar as ações de replicação das VMs de backup. Rede WAN: conexão de 8 à 100 Mbps. É um recurso mais limitado e em decorrência disso, a presente abordagem busca minimizar o custo do uso desse meio. Área de armazenamento local: NAS ou SAN no local do site. FIG. 3.1: Cenário da proposta. Observe ainda que a Ferramenta de Checkpoint é a responsável pelo controle da consistência entre os estados das VMs, bem como pelos critérios de atualização. A ferramenta usada para a validação da abordagem, que será mostrada no capítulo 4, foi o Remus, visto na seção ABORDAGEM DINÂMICA Como o objetivo é elaborar um protocolo de checkpoint capaz de reduzir o seu custo de operação sobre a rede, a abordagem aqui deve privilegiar esse recurso, ou seja, o procedimento deve buscar reduzir a quantidade de informações transferidas na rede. A ideia principal é ajustar os intervalos entre checkpoints dinamicamente, como um modo de controlar a taxa de transmissão gerada pelo checkpoint. Observe ainda que tal abordagem pode ser usada para 44

46 qualquer tipo de rede que tenha contenção de banda. Como exemplo desse tipo de rede é a WAN, que, dependendo de suas características, pode apresentar contenção. Um protocolo de checkpoint deve se calcar nos seguintes requisitos, que já são inerentes ao Remus. Garantir a consistência entre estados das VMs origem e backup; Minimizar o tempo de indisponibilidade (downtime); Assegurar que o procedimento não comprometa outros serviços ativos por causa de contenção de recursos; Garantir a transparência aos usuários, ou seja, os serviços não precisam tomar conhecimento do procedimento sobre a VM; e Assegurar que a máquina backup sempre terá outros recursos (memória, CPU, disco) para privilegiar o recurso rede, eliminando ou minimizando uma eventual contenção de rede. Vale ressaltar que a abordagem proposta não avalia as iterações iniciais do protocolo de checkpoint e sim, as iterações intermediárias, a fim de observar seu comportamento sobre o ambiente descrito na seção 3.2. Seja RTx a taxa máxima de transmissão de dados da rede e Rmax um limiar (threshold) que define a taxa máxima de transmissão de qualquer estado gerado por um checkpoint. O objetivo do Rmax é garantir que o procedimento de checkpoint não interfira nos outros serviços que estão executando sobre a rede. Assim: Rmax =c R Tx (3.1) onde c está contido no intervalo (0,1]. Seja uma lista de checkpoints CK = {ck1, ck2, ck3, } e os respectivos tamanhos dos estados enviados em cada checkpoint L = {l1, l2, l3, }. Considere que os checkpoints são gerados 45

47 em intervalos de tempo Δt. Sendo assim, a taxa de dados alterados dentro de um intervalo de tempo Δt é definido como: Rck = i li Δt (3.2) Para alcançar o objetivo do protocolo, é desejável que cada Rck seja menor do que Rmax, i a fim de que o procedimento consiga dar vazão: Rck < Rmax (3.3) li < lmax (3.4) i A condição 3.3 é equivalente à: onde lmax é o maior tamanho de um estado gerado em um checkpoint para a taxa de transmissão Rmax. Sendo assim, quando a condição 3.4 não for verdadeira, ajusta-se o intervalo Δt para manter a taxa de ocupação da rede dentro do limite desejável da seguinte forma: Δt = l max R ck (3.5) i diminuindo portanto o intervalo de tempo entre checkpoints. A redução de Δt gera, como consequência, o aumento do número de checkpoints, o que prejudica o desempenho do sistema. Logo, ao verificar que a quantidade dos dados alterados em um intervalo de tempo é muito pequena, ajusta-se o intervalo para diminuir o número de checkpoints. Define-se então um limiar mínimo para o tamanho dos dados alterados em um checkpoint (lmin) de forma que é necessário garantir que: li > lmin (3.6) Do exposto, o intervalo entre checkpoints também é ajustado quando a condição 3.6 não é satisfeita. O novo valor é dado da seguinte forma: 46

48 Δt = l min R ck (3.7) i A FIG. 3.2 ilustra graficamente a variação dos intervalos entre os checkpoints ao longo do tempo usando o algoritmo da abordagem. A quantidade de dados alterados (li+1) entre os checkpoints i e i+1 está entre os limiares estabelecidos. Nesse caso, o intervalo Δt0 não é alterado. Em cki+2 é verificado que li+2 ultrapassa lmax, o que provoca o ajuste do intervalo para Δt1 < Δt0. No checkpoint seguinte, o caso oposto acontece: o li+3 não supera lmin, causando o reajuste do intervalo para Δt2 > Δt1. FIG. 3.2: Gráfico representativo da abordagem. É importante frisar que apesar da FIG. 3.2 mostrar o crescimento da quantidade de dados alterados ao longo do tempo, isto só é verificado quando é disparado um checkpoint. Ou seja, entre os checkpoints, as páginas alteradas são rastreadas, mas o seu dimensionamento só é realizado no checkpoint. Observe que essa abordagem comprometerá o desempenho da VM protegida nos casos em que o intervalo entre checkpoints permanecer mínimo por um bom período de tempo, pois nestes casos o número de checkpoints aumenta. Em contrapartida, quando houver a opção de explorar mais a banda por causa do seu baixo uso, o protocolo proposto se ajustará a intervalos maiores, a fim de obter um melhor desempenho se comparado com o intervalo padrão. 47

49 4 VALIDAÇÃO DA ABORDAGEM DINÂMICA 4.1 DESCRIÇÃO DOS EXPERIMENTOS E OBJETIVOS Esta seção descreve as configurações dos experimentos e os ajustes necessários para vali- dar a abordagem dinâmica. Inicialmente, foi elaborado um ambiente (seção 4.1.1) para os experimentos. Em seguida foi avaliado o desempenho dos benchmarks (seção 4.1.2) sobre distintos intervalos entre checkpoints, bem como gerado respectivos traces que suportassem a simplificação da abordagem descrito na seção O objetivo dessa simplificação é para estimar como se comportará o checkpoint dinâmico proposto AMBIENTE DOS EXPERIMENTOS Como ilustrado na FIG. 3.1, os experimentos foram realizados em 2 servidores e a rede entre eles era composta por um switch 3Com 100/1000 Mbps. Cada servidor tinha as seguintes características: SO: Ubuntu Server 12.04, arquitetura x86-64, com kernel generic. Processador: Intel Core 2 Duo Processor E7500, com 3MB de L2 Cache, 2.93 GHz e 1066 MHz FSB, com a tecnologia VT habilitada; Memória RAM: 2GB, sendo duas placas de 1 GB DIMM DDR3 síncrona 1066 MHz; Placa de Rede: Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe; Discos: SATA 3.0Gb/s, de 250GB, com 7200 RPM e 8MB Cache. O disco foi montado com a tecnologia Logical Volume Management versão 2 (lvm2) (HOWTOFORGE.COM, [S.d.]). Esses discos fazem o papel da SAN ou NAS descrito na seção 3.2; 48

50 Hipervisor ou VMM: Xen 4.1 (BARHAM et al., 2003); Máquina Virtual: Ubuntu Server (LAMP), arquitetura x86-64, com kernel generic, 01 VCPU, 256 MB RAM e 4GB de imagem de disco virtual; Ferramenta de Checkpoint: Remus, visto na seção , que já se encontra no repositório do Xen BENCHMARKS Foram usados diversos benchmarks para a validação da abordagem, dos quais o Cachebench (MUCCI et al., 1998) e o Httperf 0.9 ( httperf homepage, [S.d.]; MOSBERGER; JIN, T., 1998) foram significativos para os experimentos. A seguir um sumário de cada um deles: Cachebench: com dois benchmarks embutidos, ele avalia o desempenho da hierarquia de memória do sistema de computação. Ele executa consecutivos acessos (leitura ou escrita) a dados sobre um vetor de tamanho variável. O desempenho então é medido pela taxa (MBps) em que esses acessos são realizados. Httperf: é uma ferramenta que mede o desempenho de um servidor web. Esse benchmark permite gerar e manter várias conexões http sobre o servidor e tem suporte para HTTP/1.1 e protocolos SSL METODOLOGIA DA VALIDAÇÃO A fim de validar a abordagem proposta, foram feitas algumas simplificações. Inicialmente, executou-se os benchmarks apresentados na seção sobre a VM protegida pelo Remus, o qual estava configurado para gerar checkpoints em intervalos de 25, 100, 200, 300, 400, 500 e 1000 ms para o cachebench e 100, 200, 300, 400 e 500 ms para o httperf. Cada experimento foi realizado 10 vezes, gerando traces de execução do Remus, com informações de intervalo entre checkpoints e quantidade de páginas sujas. Além disso, foram extraídos dessas amostras, os resultados de desempenho de cada benchmark. Para obter tais traces, foi necessário alterar 49

51 o código do Remus, de modo a gerar informações como tempo transcorrido, duração do intervalo entre checkpoints e a quantidade de páginas sujas. As 10 repetições de cada experimento gerou 10 traces. A partir desses traces, foi calculado o valor médio de páginas alteradas em cada checkpoint e o intervalo médio entre cada par de checkpoints consecutivos. Como será explicado mais adiante, o Remus as vezes gera intervalos maiores do que aquele configurado. O novo trace gerado com os valores médios é denominado trace médio. A partir dos traces médios gerados para vários intervalos com um benchmark, foi gerado um novo trace, no intuito de simular o comportamento de um sistema que realiza checkpoints em intervalos de tempo dinâmico, conforme a FIG Assim, esse novo trace é criado por meio de um algoritmo que analisa inicialmente os dados do trace médio de 200 ms (intervalo padrão do Remus), copiando-os para o novo trace. O algoritmo passa a analisar um trace médio de intervalo imediatamente inferior (100 ms) se lmax é superado. Da mesma forma, se o algoritmo está no trace médio de 100 ms e o lmax é excedido, altera-se para o trace médio de 25 ms (que é o mínimo). A outra via é tomada nos casos em que lmin não é superado e então o algoritmo passa para um trace médio com intervalo imediatamente superior. Por exemplo, se o algoritmo está no trace médio de 500 ms e o lmin não é excedido, altera-se para o trace médio de 1000 ms (que é o máximo). Foram realizadas comparações deste novo trace gerado com o de 200ms, que é o intervalo padrão do Remus, de modo a verificar se foi alcançado o objetivo de diminuir o consumo do recurso de rede. Assim, como será visto a seguir, foram plotados gráficos usando a média das taxas das páginas alteradas dentro de um período de 2 segundos durante toda a execução de um trace, de modo a facilitar a observação do comportamento do sistema. O lmin e o lmax são dados em quantidade de páginas alteradas (dirty pages). Os valores desses limiares foram definidos tomando também como base o intervalo de 200 ms. Foi definido o valor 640 para o lmax, que está associado aproximadamente a taxa de 12,5 MBps ou 100 Mbps (sabendo que o tamanho de cada página registrado nos experimentos é igual a 4 KB). Em alguns experimentos foram usados valores múltiplos de 640 páginas. Para o lmin foram de- 50

52 finidos 270 ou 350 páginas, associados respectivamente às taxas de 5,2 MBps ou 40 Mbps e 6,5 MBps ou 50 Mbps aproximadamente. Todos os algoritmos descritos nesta seção, que geram o trace médio e o da abordagem dinâmica, foram implementados usando a linguagem de programação C. Tais algoritmos também geraram toda a base estatística que permitiram gerar as tabelas e gráficos apresentados nas próximas seções. 4.2 RESULTADOS DE DESEMPENHO Inicialmente, algumas curiosidades apareceram nos experimentos ao observar o intervalo entre checkpoints. A primeira delas é que o intervalo de 25 ms não é respeitado no Remus, atingindo mínimos de 60 ms, o que dificulta fazer uma real avaliação nesse intervalo. Outra situação ocorre em testes que realizam muitos acessos a memória, onde o intervalo é alterado subitamente, a ponto de superar os 3 segundos ou mais nos traces cujos intervalos entre checkpoints estavam definidos em 200 ms. Isso é observado em todos os benchmarks utilizados e é provavelmente causado por instantes de muita alteração de páginas, o que é ruim por dois motivos: causa demora de resposta do sistema, conforme mostrado na seção , e dificulta um controle rigoroso sobre o custo da rede pelo ajuste do intervalo do checkpoint CACHEBENCH O Cachebench realiza consecutivos acessos, leitura ou escrita, a dados sobre um vetor de tamanho variável, o qual, neste experimento, variou até 16 MB. O resultado, definido como throughput de cache, é medido em MBps. Como ilustrado na FIG. 4.1, o read-cachebench tem o throughput de cache melhor em intervalos maiores entre checkpoints, com desempenho de 36% melhor do que com intervalos menores (considerando os intervalos entre 100 e 1000 ms). Isso demonstra que o uso de checkpoints afeta o desempenho, pois quanto maior o intervalo, menor é o número de checkpoints, e vice-versa. 51

53 FIG. 4.1: Resultado do read-cachebench. TAB. 4.1: Dados estatísticos sobre a execução do read-cachebench com intervalo de 200 ms entre checkpoints. Faixa de Percentual no Intervalo (ms) Experimento > ,92% 3,69% 1,54% 21,36% 5,92% 2,40% 0,17% Quantidade de Páginas Sujas Média Máximo Mínimo 489,16 565,22 546,37 520,32 544,3 492, , ,3 1878,5 1345,5 2956,9 1580,1 2391,4 4560,1 279,5 297,2 297,5 288,4 302, ,2 Conforme destacado na seção 4.2, o Remus gera intervalos entre checkpoints diferentes daquele configurado. Isso pode ser verificado na TAB. 4.1, que apresenta dados estatísticos sobre a execução do read-cachebench com o Remus configurado para gerar checkpoints a cada 200 ms. Observa-se que a maioria dos intervalos está próxima de 200 ms, porém mais de 20% dos intervalos estão acima de 300 ms. É possível notar também que a média do número de páginas sujas varia pouco, em torno de 15%, mas a variação entre os valores de mínimo e 52

54 máximo é muito grande, cerca de 5 vezes ou mais, demonstrando que esta última pode ser aproveitada pela abordagem proposta. Da mesma forma, o write-cachebench também tem o throughput de cache melhor em intervalos maiores entre checkpoints (FIG. 4.2), com desempenho 18% melhor (considerando os intervalos entre 100 e 1000 ms). A queda abrupta vista no write-cachebench próximo aos vetores de 3 MB coincide com o tamanho da cache do host, e isso já era esperado nesse benchmark. FIG. 4.2: Resultado do write-cachebench. A TAB. 4.2 mostra a variação dos intervalos entre checkpoints para o write-cachebench com o Remus configurado com intervalos de 200 ms. Para este benchmark, a maioria dos intervalos também ficou próxima a 200 ms e mais de 24% dos intervalos está na faixa de ms. No entanto, a média de páginas sujas varia muito entre as faixas de intervalo. Essa diferença de comportamento ocorre devido ao grande número de escritas feitas nos vetores combinadas ao aumento do tamanho dos vetores. Essas escritas não são geradas no read-cachebench. 53

55 TAB. 4.2: Dados estatísticos sobre a execução do write-cachebench com intervalo de 200 ms entre checkpoints. Faixa de Percentual no Intervalo (ms) Experimento > ,27% 3,11% 3,31% 24,17% 6,62% 4,61% 1,91% Quantidade de Páginas Sujas Média Máximo Mínimo 482,28 689, ,76 666,17 719, , , ,6 1898,4 8646,5 2109,9 2697,2 3906,2 4260,3 285,1 296,1 302, ,8 318, HTTPERF O experimento consiste em disparar requisições de conexões http para a VM protegida, a uma taxa de 400 req/s. Conforme a TAB. 4.3, observou-se que os erros de conexão em geral são grandes, ocorrendo com mais frequência em intervalos entre checkpoints menores, provavelmente por ocorrer mais downtimes nesses intervalos e o serviço não estar disponível nos instantes necessários. Dessa forma, conclui-se que, para esse tipo de workload, o ajuste do intervalo com a abordagem dinâmica poderia ajudar a responsividade do sistema na percepção do usuário. Isso será melhor analisado na seção TAB. 4.3: Percentual de erros de conexão http em relação ao intervalo entre checkpoints. Intervalo entre Checkpoints (ms) Erros de Conexão (%) ,31% 49,62% 47,99% 45,84% 39,06% A TAB. 4.4 mostra ainda a variação dos intervalos entre checkpoints para o httperf com o Remus configurado com intervalo de 200 ms. Diferente do que aconteceu no cachebench, a 54

56 maioria dos intervalos não se concentrou em 200 ms e sim, nas faixas de e ms. O que se ressalta aqui é a grande quantidade de páginas sujas, mostrando que esse benchmark faz muita escrita. É possível notar ainda que tanto a média do número de páginas sujas quanto a faixa de valores máximo e mínimo varia muito, demonstrando que esta variação poderia ser aproveitada pela abordagem proposta. TAB. 4.4: Dados estatísticos sobre a execução do httperf com intervalo de 200 ms entre checkpoints. Faixa de Percentual no Intervalo (ms) Experimento > ,38% 23,08% 20,33% 16,48% 13,19% 11,54% Quantidade de Páginas Sujas Média Máximo Mínimo 939, , , , ,3 1788,1 1769,8 2962,1 3260,3 7555,9 311,4 352,4 631,1 726,5 1568,2 2186,2 VALIDAÇÃO DA ABORDAGEM CACHEBENCH Antes de apresentar os resultados, vale ressaltar um fenômeno que ocorre no Cachebench. Ao analisar o número de páginas alteradas entre checkpoints durante a execução do readcachebench (FIG. 4.3), observa-se uma fileira na casa dos 4500 (o que também acontece no write-cachebench). Cada um desses pontos coincide com a troca do tamanho do vetor, o que faz gerar gráficos dentados ao plotar a média da taxa das páginas alteradas. A FIG. 4.4 mostra uma comparação entre taxas médias de transmissão geradas pelo Remus com intervalo padrão de 200 ms e aquelas geradas pela abordagem dinâmica, conforme a seção 4.1.3, e os demais intervalos. A abscissa indica os intervalos entre checkpoints ou os limiares usados e a ordenada mostra a respectiva taxa média normalizada com o trace médio de 55

57 200 ms. A taxa média de transmissão do trace de 200 ms foi de 8 MBps para o read-cachebench e 9,21 MBps para o write-cachebench. FIG. 4.3: Número de páginas sujas gerado pelo read-cachebench. FIG. 4.4: Comparação entre taxas de transmissão do protocolo de checkpoint do Remus com intervalo de 200 ms, demais intervalos e a abordagem dinâmica, usando o cachebench. Como se pode observar, a escolha dos limiares influencia no resultado. O destaque aqui vai para os limiares inferiores. Quando o lmin = 350 (associado a 6 MBps), a abordagem reduziu a taxa de transmissão em todos os casos. Já quando o lmin = 270 (associado a 5,3 MBps), a abordagem não consegue reduzir a taxa de transmissão do protocolo de checkpoint. Isso se 56