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

Tamanho: px
Começar a partir da página:

Download "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

UMA VISÃO GERAL SOBRE CHECKPOINTS DE MÁQUINAS VIRTUAIS

UMA VISÃO GERAL SOBRE CHECKPOINTS DE MÁQUINAS VIRTUAIS UMA VISÃO GERAL SOBRE CHECKPOINTS DE MÁQUINAS VIRTUAIS José Eduardo França *, Raquel Coelho Gomes Pinto Seção de Engenharia de Computação Instituto Militar de Engenharia (IME, Praça General Tibúrcio 80,

Leia mais

Introdução a Virtualização. Sergio Roberto Charpinel Junior Profa. Roberta Lima Gomes

Introdução a Virtualização. Sergio Roberto Charpinel Junior Profa. Roberta Lima Gomes Introdução a Virtualização Sergio Roberto Charpinel Junior Profa. Roberta Lima Gomes Por que virtualizar? Descentralização de recursos computacionais Cloud computing Plena utilização de recursos físicos

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Virtualização. O conceito de VIRTUALIZAÇÃO

Virtualização. O conceito de VIRTUALIZAÇÃO Virtualização A virtualização está presente tanto no desktop de um entusiasta pelo assunto quanto no ambiente de TI de uma infinidade de empresas das mais variadas áreas. Não se trata de "moda" ou mero

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Unidade III FUNDAMENTOS DE SISTEMAS. Prof. Victor Halla

Unidade III FUNDAMENTOS DE SISTEMAS. Prof. Victor Halla Unidade III FUNDAMENTOS DE SISTEMAS OPERACIONAIS Prof. Victor Halla Conteúdo Arquitetura de Processadores: Modo Operacional; Velocidade; Cache; Barramento; Etc. Virtualização: Maquinas virtuais; Gerenciamento

Leia mais

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines Timothy Wood, Prashant Shenoy, K.K. Ramakrishnan, Jacobus Van der Merwe VEE '11 Proceedings of the 7th ACM SIGPLAN/SIGOPS

Leia mais

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores Máquinas Virtuais e Emuladores Marcos Aurelio Pchek Laureano Sistemas de Computadores Os sistemas de computadores são projetados com basicamente 3 componentes: hardware sistema operacional aplicações Sistemas

Leia mais

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013 MC714 Sistemas Distribuídos 2 semestre, 2013 Virtualização - motivação Consolidação de servidores. Consolidação de aplicações. Sandboxing. Múltiplos ambientes de execução. Hardware virtual. Executar múltiplos

Leia mais

Computação na Nuvem: Virtualização e Migração de VM. André Meireles Estêvão Monteiro Monique Soares

Computação na Nuvem: Virtualização e Migração de VM. André Meireles Estêvão Monteiro Monique Soares Computação na Nuvem: Virtualização e Migração de VM André Meireles Estêvão Monteiro Monique Soares Agenda Overview Histórico Abordagens Desafios em x86 Snapshots Virtualização de Hardware/Plataforma/Sevidor:

Leia mais

Virtualização Gerencia de Redes Redes de Computadores II

Virtualização Gerencia de Redes Redes de Computadores II Virtualização Gerencia de Redes Redes de Computadores II *Créditos: baseado no material do Prof. Eduardo Zagari Virtualização - Introdução Introduzido nos anos 60 em Mainframes Em 1980 os microcomputadores

Leia mais

FAMÍLIA EMC VPLEX. Disponibilidade contínua e mobilidade de dados nos datacenters e entre eles

FAMÍLIA EMC VPLEX. Disponibilidade contínua e mobilidade de dados nos datacenters e entre eles FAMÍLIA EMC VPLEX Disponibilidade contínua e mobilidade de dados nos datacenters e entre eles GARANTINDO DISPONIBILIDADE CONTÍNUA E MOBILIDADE DE DADOS PARA APLICATIVOS ESSENCIAIS A infraestrutura de armazenamento

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA INE BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO.

UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA INE BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO. UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA INE BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO Xen Hypervisor Glauco Neves 07132022 Guilherme Pacheco 07232063 INE 5412-0432

Leia mais

SISTEMAS OPERACIONAIS. Maquinas Virtuais e Emuladores

SISTEMAS OPERACIONAIS. Maquinas Virtuais e Emuladores SISTEMAS OPERACIONAIS Maquinas Virtuais e Emuladores Plano de Aula Máquinas virtuais Emuladores Propriedades Benefícios Futuro Sistemas de Computadores Os sistemas de computadores são projetados com basicamente

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Phil Maynard UNIDADE DE SOLUÇÕES DE GERENCIAMENTO DE DADOS PARA O CLIENTE FEVEREIRO DE 2012 Introdução Em todos os lugares, o volume de

Leia mais

Sistemas Operacionais 1/66

Sistemas Operacionais 1/66 Sistemas Operacionais 1/66 Roteiro Máquinas virtuais Emuladores Propriedades Benefícios Futuro 2/66 Sistemas de Computadores Os sistemas de computadores são projetados com basicamente 3 componentes: hardware

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

Leia mais

Sistemas Operacionais. Roteiro. Sistemas de Computadores. Os sistemas de computadores são projetados com basicamente 3 componentes: Marcos Laureano

Sistemas Operacionais. Roteiro. Sistemas de Computadores. Os sistemas de computadores são projetados com basicamente 3 componentes: Marcos Laureano Sistemas Operacionais Marcos Laureano 1/66 Roteiro Máquinas virtuais Emuladores Propriedades Benefícios Futuro 2/66 Sistemas de Computadores Os sistemas de computadores são projetados com basicamente 3

Leia mais

Xen e a Arte da Virtualização

Xen e a Arte da Virtualização Xen e a Arte da Virtualização Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield University of Cambridge Computer Laboratory Microsoft

Leia mais

Proteção de ambientes Microsoft Hyper-V 3.0 com Arcserve

Proteção de ambientes Microsoft Hyper-V 3.0 com Arcserve Proteção de ambientes Microsoft Hyper-V 3.0 com Arcserve Desafios do cliente Hoje em dia, você enfrenta desafios como acordos de nível de serviço exigentes e limitações de equipe e orçamento. Você procura

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

Prof. Luiz Fernando Bittencourt MO809L. Tópicos em Sistemas Distribuídos 1 semestre, 2015

Prof. Luiz Fernando Bittencourt MO809L. Tópicos em Sistemas Distribuídos 1 semestre, 2015 MO809L Tópicos em Sistemas Distribuídos 1 semestre, 2015 Virtualização Virtualização Threads/processos: Modo de fazer mais coisas ao mesmo tempo. Concorrência - impressão de execução paralela em computador

Leia mais

Proteção de ambientes VMware vsphere/esx com Arcserve

Proteção de ambientes VMware vsphere/esx com Arcserve Proteção de ambientes VMware vsphere/esx com Arcserve Desafios do cliente Hoje em dia, você enfrenta desafios como acordos de nível de serviço exigentes e limitações de equipe e orçamento. Você procura

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

ARQUITETURA TRADICIONAL

ARQUITETURA TRADICIONAL INTRODUÇÃO Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da informação seu bem mais precioso. Nos dias de hoje,

Leia mais

Hypervisor. Diego Souza Gomes 3 de maio de 2007

Hypervisor. Diego Souza Gomes 3 de maio de 2007 Hypervisor Diego Souza Gomes 3 de maio de 2007 Resumo As máquinas virtuais envolvem a criação de um sistema de computador totalmente em software. Usando-as, é possível hospedar vários computadores virtuais

Leia mais

A SALA DE AULA é meu paraíso. Nela me realizo, nela exercito minha cidadania e nela me sinto útil.

A SALA DE AULA é meu paraíso. Nela me realizo, nela exercito minha cidadania e nela me sinto útil. Virtualização Meu nome: Nome de guerra: Meu e-mail: Marcos Vinicios Bueno Marques Professor Cidão marcos@cidao.com.br Quem sou? Professor e coordenador de cursos de TI do Senac Informática em Porto Alegre,

Leia mais

VIRTUALIZAÇÃO EM SERVIDORES DE BANCO DE DADOS. Resumo: A estratégia de virtualização de servidores de banco de dados é uma tendência

VIRTUALIZAÇÃO EM SERVIDORES DE BANCO DE DADOS. Resumo: A estratégia de virtualização de servidores de banco de dados é uma tendência VIRTUALIZAÇÃO EM SERVIDORES DE BANCO DE DADOS Igor Lucas Coelho Santos 1 Iremar Nunes de Lima 2 Resumo: A estratégia de virtualização de servidores de banco de dados é uma tendência recente em Tecnologia

Leia mais

SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 5 PROCESSOS 1. INTRODUÇÃO Em sistemas distribuídos é importante examinar os diferentes tipos de processos e como eles desempenham seu papel. O conceito de um processo é originário do campo de sistemas

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com Cloud Computing Andrêza Leite andreza.lba@gmail.com Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing O

Leia mais

arcserve Unified Data Protection Resumo da solução de virtualização

arcserve Unified Data Protection Resumo da solução de virtualização arcserve Unified Data Protection Resumo da solução de virtualização Hoje a virtualização de servidores e desktops é uma realidade não só nas empresas, mas em todos os tipos de negócios. Todos concordam

Leia mais

Symantec NetBackup for VMware

Symantec NetBackup for VMware Visão geral A virtualização de servidor é a maior tendência modificadora na área de TI atual. Os departamentos de TI, que dependem do orçamento, estão se apressando para aderir à virtualização por vários

Leia mais

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Eduardo Ferreira dos Santos SparkGroup Treinamento e Capacitação em Tecnologia eduardo.edusantos@gmail.com eduardosan.com 13 de Junho de 2013

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Acelere sua viagem à virtualização

Acelere sua viagem à virtualização Back to top Acelere sua viagem à virtualização Índice Acelere sua viagem à virtualização........................................ 1 Faça a virtualização trabalhar para você....................................

Leia mais

Virtualização de Software

Virtualização de Software UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE BACHARELADO DE SISTEMAS DE INFORMAÇÃO Virtualização de Software Luana Sandrini Saft Trabalho de conclusão de curso

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Proteção de ambientes Citrix XenServer com Arcserve

Proteção de ambientes Citrix XenServer com Arcserve Proteção de ambientes Citrix XenServer com Arcserve Desafios do cliente Hoje em dia, você enfrenta desafios como acordos de nível de serviço exigentes e limitações de equipe e orçamento. Você procura maneiras

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

Leia mais

Veritas Storage Foundation da Symantec

Veritas Storage Foundation da Symantec Veritas Storage Foundation da Symantec Gerenciamento de armazenamento heterogêneo on-line O Veritas Storage Foundation oferece uma solução completa para o gerenciamento de armazenamento heterogêneo on-line.

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Benefícios do Windows Server 2008 R2 Hyper-V para SMB

Benefícios do Windows Server 2008 R2 Hyper-V para SMB Benefícios do Windows Server 2008 R2 Hyper-V para SMB Sumário Introdução... 3 Windows Server 2008 R2 Hyper-V... 3 Live Migration... 3 Volumes compartilhados do Cluster... 3 Modo de Compatibilidade de Processador...

Leia mais

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Márcio Parise Boufleur Guilherme Piegas Koslovski Andrea Schwertner Charão LSC - Laboratório de Sistemas de Computação UFSM - Universidade

Leia mais

Classificação::Modelo de implantação

Classificação::Modelo de implantação Classificação::Modelo de implantação Modelo de implantação::privado Operada unicamente por uma organização; A infra-estrutura de nuvem é utilizada exclusivamente por uma organização: Nuvem local ou remota;

Leia mais

Virtualização: VMWare e Xen

Virtualização: VMWare e Xen Virtualização: VMWare e Xen Diogo Menezes Ferrazani Mattos Professor: Otto Carlos Disciplina: Redes I Universidade Federal do Rio de Janeiro POLI/COPPE 1 Introdução Virtualização Divisão da máquina física

Leia mais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais

1º Estudo Dirigido. Capítulo 1 Introdução aos Sistemas Operacionais 1º Estudo Dirigido Capítulo 1 Introdução aos Sistemas Operacionais 1. Defina um sistema operacional de uma forma conceitual correta, através de suas palavras. R: Sistemas Operacionais são programas de

Leia mais

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas ATIVIDADE 1 MÁQUINAS VIRTUAIS Existem hoje diversas tecnologias e produtos para virtualização de computadores e ambientes de execução, o que pode gerar uma certa confusão de conceitos. Apesar disso, cada

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 1 Conceitos da Computação em Nuvem A computação em nuvem ou cloud computing

Leia mais

Desmistificando a desduplicação de dados para backup com o Dell DR4000

Desmistificando a desduplicação de dados para backup com o Dell DR4000 Desmistificando a desduplicação de dados para backup com o Dell DR4000 Este informe oficial técnico da Dell explica como a desduplicação de dados com o DR4000 pode ajudar a sua organização a economizar

Leia mais

FAMÍLIA EMC RECOVERPOINT

FAMÍLIA EMC RECOVERPOINT FAMÍLIA EMC RECOVERPOINT Solução econômica para proteção de dados e recuperação de desastres local e remota FUNDAMENTOS Maximize a proteção de dados de aplicativos e a recuperação de desastres Proteja

Leia mais

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema Sistemas Operacionais I Parte III Estrutura dos SOs Prof. Gregorio Perez gregorio@uninove.br 2007 Roteiro Serviços Estrutura dos Sistemas Operacionais Funções do Sistema Operacional Chamadas do Sistema

Leia mais

Tecnólogo em Análise e Desenvolvimento de Sistemas

Tecnólogo em Análise e Desenvolvimento de Sistemas Tecnólogo em Análise e Desenvolvimento de Sistemas O conteúdo deste documento tem como objetivos geral introduzir conceitos mínimos sobre sistemas operacionais e máquinas virtuais para posteriormente utilizar

Leia mais

CAPÍTULO 7 O SERVIÇO DOS AGENTES

CAPÍTULO 7 O SERVIÇO DOS AGENTES CAPÍTULO 7 O SERVIÇO DOS AGENTES A inteligência... é a capacidade de criar objetos artificiais, especialmente ferramentas para fazer ferramentas. ( Henri Bergson) O serviço dos agentes surge como uma prestação

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

Professor Esp.: Douglas Diego de Paiva douglas.ddp@gmail.com

Professor Esp.: Douglas Diego de Paiva douglas.ddp@gmail.com VIRTUALIZAÇÃO Professor Esp.: Douglas Diego de Paiva douglas.ddp@gmail.com Virtualização o que é? É uma forma de esconder as características físicas de uma plataforma computacional dos usuários, emulando

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS

Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS Naomi - GT8 HARDWARE & SISTEMAS DISTRIBUÍDOS INTEGRANTES Aniel Cruz Claudio Sant Anna José Eurique Ribeiro Roberto Nou HARDWARE & SISTEMAS DISTRIBUÍDOS Clusters Conceito; Desempenho, Disponibilidade, Balanceamento

Leia mais

Monitoramento de Rede de Nuvens Privadas

Monitoramento de Rede de Nuvens Privadas Monitoramento de Rede de Nuvens Privadas White Paper Autores: Dirk Paessler, CEO da Paessler AG Dorte Winkler, Redatora Técnica na Paessler AG Primeira Publicação: Maio de 2011 Edição: Fevereiro de 2013

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Por que os administradores de sistema devem estar atentos ao desempenho de virtualização e armazenamento

Por que os administradores de sistema devem estar atentos ao desempenho de virtualização e armazenamento Por que os administradores de sistema devem estar atentos ao desempenho de virtualização e armazenamento 2013, SolarWinds Worldwide, LLC. Todos os direitos reservados. É importante que os administradores

Leia mais

Virtualização de Sistemas Operacionais

Virtualização de Sistemas Operacionais Virtualização de Sistemas Operacionais Felipe Antonio de Sousa 1, Júlio César Pereira 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil felipeantoniodesousa@gmail.com, juliocesarp@unipar.br Resumo.

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Gerência de processos Controle e descrição de processos Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Representação e controle de processos pelo SO Estrutura

Leia mais

Virtualização - VMWare e Xen

Virtualização - VMWare e Xen Virtualização - VMWare e Xen A virtualização consiste na emulação de ambientes isolados, capazes de rodar diferentes sistemas operacionais dentro de uma mesma máquina, aproveitando ao máximo a capacidade

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer

Leia mais

http://www.microsoft.com/brasil/security/guidance/prodtech/backup/secmod201.mspx

http://www.microsoft.com/brasil/security/guidance/prodtech/backup/secmod201.mspx Página 1 de 9 Clique aqui para instalar o Silverlight Brasil Alterar Todos os sites da Microsoft Enviar Consulta Centro de orientações de segurança Publicações Recentes Pequenas Empresas Produtos e tecnologias

Leia mais

Resumo da solução de virtualização

Resumo da solução de virtualização Resumo da solução de virtualização A virtualização de servidores e desktops se tornou muito difundida na maioria das organizações, e não apenas nas maiores. Todos concordam que a virtualização de servidores

Leia mais

Visão Geral do Recurso Live Migration no Windows Server 2008 R2 Hyper-V. Versão: 1.0

Visão Geral do Recurso Live Migration no Windows Server 2008 R2 Hyper-V. Versão: 1.0 Visão Geral do Recurso Live Migration no Windows Server 2008 R2 Hyper-V Versão: 1.0 Publicado: 02 de Dezembro de 2008 Índice Visão Geral Visão Geral dos Recursos do Windows Server 2008 R2 Hyper-V... 3

Leia mais

Unidade III. Unidade III

Unidade III. Unidade III Unidade III 4 ADMINISTRAÇÃO DE SGBDs As pessoas que trabalham com um banco de dados podem ser categorizadas como usuários de banco de dados ou administradores de banco de dados. 1 Entre os usuários, existem

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Computação em Nuvem Introdução Centralização do processamento Surgimento da Teleinformática Década de 60 Execução de programas localmente Computadores

Leia mais

A Academia Brasileira de Letras diz que este verbete não existe.

A Academia Brasileira de Letras diz que este verbete não existe. Virtualização Virtualização? A Academia Brasileira de Letras diz que este verbete não existe. Virtual: Segundo o Dicionário da Língua Portuguesa, significa: adj (lat virtuale) 1- Que não existe como realidade,

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

CA ARCserve Backup. Visão geral

CA ARCserve Backup. Visão geral INFORME DE PRODUTO: CA ARCSERVE BACKUP R12.5 CA ARCserve Backup CA ARCSERVE BACKUP, O PRODUTO DE ALTA PERFORMANCE, LÍDER DA INDÚSTRIA DE PROTEÇÃO DE DADOS, COMBINA TECNOLOGIA INOVADORA DE ELIMINAÇÃO DE

Leia mais

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

Arcserve Cloud. Guia de Introdução ao Arcserve Cloud

Arcserve Cloud. Guia de Introdução ao Arcserve Cloud Arcserve Cloud Guia de Introdução ao Arcserve Cloud A presente Documentação, que inclui os sistemas de ajuda incorporados e os materiais distribuídos eletronicamente (doravante denominada Documentação),

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Software Sistema de Entrada/Saída Princípios de Software Tratadores (Manipuladores) de Interrupções Acionadores de Dispositivos (Device Drivers)

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

Alta disponibilidade em máquinas

Alta disponibilidade em máquinas Alta disponibilidade em máquinas paravirtualizadas João Eriberto Mota Filho SIRC / RS 2007 09 de outubro de 2007 Sumário Introdução Técnicas de virtualização Conceito de alta disponibilidade Paravirtualização

Leia mais

Profs. Deja e Andrei

Profs. Deja e Andrei Disciplina Sistemas Distribuídos e de Tempo Real Profs. Deja e Andrei Sistemas Distribuídos 1 Conceitos e Projetos de Sistemas Distribuídos Objetivos: Apresentar uma visão geral de processamento distribuído,

Leia mais

Sistemas Operacionais Gerência de Dispositivos

Sistemas Operacionais Gerência de Dispositivos Universidade Estadual de Mato Grosso do Sul UEMS Curso de Licenciatura em Computação Sistemas Operacionais Gerência de Dispositivos Prof. José Gonçalves Dias Neto profneto_ti@hotmail.com Introdução A gerência

Leia mais

ETEC RAPOSO TAVARES GESTÃO DE SISTEMAS OPERACIONAIS I. Máquina Virtual. Instalação de S.O. em dual boot. 1º Semestre 2010 PROF.

ETEC RAPOSO TAVARES GESTÃO DE SISTEMAS OPERACIONAIS I. Máquina Virtual. Instalação de S.O. em dual boot. 1º Semestre 2010 PROF. ETEC RAPOSO TAVARES GESTÃO DE SISTEMAS OPERACIONAIS I Máquina Virtual Instalação de S.O. em dual boot 1º Semestre 2010 PROF. AMARAL Na ciência da computação, máquina virtual é o nome dado a uma máquina,

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Processos I: Threads, virtualização e comunicação via protocolos Prof. MSc. Hugo Souza Nesta primeira parte sobre os Processos Distribuídos iremos abordar: Processos e a comunicação

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 SISTEMA DE INTERCONEXÃO (BARRAMENTOS) Prof. Luiz Gustavo A. Martins Arquitetura de von Newmann Componentes estruturais: Memória Principal Unidade de Processamento Central

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC RESUMO EXECUTIVO O PowerVault DL2000, baseado na tecnologia Symantec Backup Exec, oferece a única solução de backup em

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

Consolidação inteligente de servidores com o System Center

Consolidação inteligente de servidores com o System Center Consolidação de servidores por meio da virtualização Determinação do local dos sistemas convidados: a necessidade de determinar o melhor host de virtualização que possa lidar com os requisitos do sistema

Leia mais

GUIA DE DESCRIÇÃO DO PRODUTO

GUIA DE DESCRIÇÃO DO PRODUTO GUIA DE DESCRIÇÃO DO PRODUTO EMC CLOUDARRAY INTRODUÇÃO Atualmente, os departamentos de TI enfrentam dois desafios de armazenamento de dados críticos: o crescimento exponencial dos dados e uma necessidade

Leia mais

Licenciamento de estações de trabalho Windows para Ambientes VDI

Licenciamento de estações de trabalho Windows para Ambientes VDI Microsoft VDI e Windows VDA Perguntas Frequentes Licenciamento de estações de trabalho Windows para Ambientes VDI Como a Microsoft licencia o Windows das estações de trabalho em ambientes virtuais? A Microsoft

Leia mais

Monitoramento de Rede de Nuvens Privadas

Monitoramento de Rede de Nuvens Privadas Monitoramento de Rede de Nuvens Privadas White Paper Autores: Dirk Paessler, CEO da Paessler AG Gerald Schoch, Redator Técnico na Paessler AG Primeira Publicação: Maio de 2011 Edição: Fevereiro de 2015

Leia mais

Executando o Modo Windows XP com Windows Virtual PC

Executando o Modo Windows XP com Windows Virtual PC Executando o Modo Windows XP com Windows Virtual PC Um guia para pequenas empresas Conteúdo Seção 1: Introdução ao Modo Windows XP para Windows 7 2 Seção 2: Introdução ao Modo Windows XP 4 Seção 3: Usando

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas Operacionais Um sistema operacional fornece o ambiente no qual os programas são executados. Internamente,

Leia mais

1 Redes de comunicação de dados

1 Redes de comunicação de dados 1 Redes de comunicação de dados Nos anos 70 e 80 ocorreu uma fusão dos campos de ciência da computação e comunicação de dados. Isto produziu vários fatos relevantes: Não há diferenças fundamentais entre

Leia mais

Estruturas do Sistema de Computação

Estruturas do Sistema de Computação Estruturas do Sistema de Computação Prof. Dr. José Luís Zem Prof. Dr. Renato Kraide Soffner Prof. Ms. Rossano Pablo Pinto Faculdade de Tecnologia de Americana Centro Paula Souza Estruturas do Sistema de

Leia mais

6 - Gerência de Dispositivos

6 - Gerência de Dispositivos 1 6 - Gerência de Dispositivos 6.1 Introdução A gerência de dispositivos de entrada/saída é uma das principais e mais complexas funções do sistema operacional. Sua implementação é estruturada através de

Leia mais

Symantec NetBackup 7.1 Clients and Agents Complete protection for your information-driven enterprise

Symantec NetBackup 7.1 Clients and Agents Complete protection for your information-driven enterprise Complete protection for your information-driven enterprise Visão geral O Symantec NetBackup oferece uma seleção simples e abrangente de clientes e agentes inovadores para otimizar a performance e a eficiência

Leia mais

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa.

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa. CLUSTERS Pode-se pegar uma certa quantidade de servidores e juntá-los para formar um cluster. O serviço então é distribuído entre esses servidores como se eles fossem uma máquina só. Um cluster de servidores

Leia mais