UNIVERSIDADE FEDERAL DO ABC. Curso de Pós Graduação em Engenharia da Informação. Dissertação de Mestrado KLEBER DA SILVA DIVINO

Transcrição

1 UNIVERSIDADE FEDERAL DO ABC Curso de Pós Graduação em Engenharia da Informação Dissertação de Mestrado KLEBER DA SILVA DIVINO USO DE MECANISMOS DE ELASTICIDADE COMO SOLUÇÃO DE TOLERÂNCIA A FALHAS PARA AMBIENTE DE COMPUTAÇÃO EM NUVEM Santo André 2014

2

3 Este exemplar foi revisado e alterado em relação à versão original, de acordo com as observações levantadas pela banca no dia da defesa, sob responsabilidade única do autor e com a anuência de seu orientador. Santo André, 22 de Outubro de Assinatura do autor: Assinatura do orientador:

4 Curso de Pós Graduação em Engenharia da Informação Dissertação de Mestrado KLEBER DA SILVA DIVINO USO DE MECANISMOS DE ELASTICIDADE COMO SOLUÇÃO DE TOLERÂNCIA A FALHAS PARA AMBIENTE DE COMPUTAÇÃO EM NUVEM. Trabalho apresentado como requisito parcial para obtenção do título de Mestre em Engenharia da Informação, sob orientação do Professor Doutor Carlos Alberto Kamienski. Orientador: Prof. Dr. Carlos Kamienski Coorientador: Prof. Dr. Guiou Kobayashi Santo André 2014

5 Resumo Cada vez mais as empresas optam por utilizar serviços baseados em computação em nuvem, tanto serviços fornecidos por terceiros como a criação de sua própria infraestrutura de nuvem privada. Nesse contexto, cada vez mais essas empresas dependem de aplicações que são executadas nesses tipos de ambiente. Devido a essa dependência, as soluções baseadas em computação em nuvem devem fornecer soluções de alta disponibilidade, que não comprometerão o fornecimento do serviço em caso de falhas. Em um ambiente de computação em nuvem, todas as aplicações devem possuir um nível mínimo de disponibilidade, porém devido ao modelo de cobrança de serviços de computação em nuvem, um cliente pode necessitar que algumas aplicações possuam um maior nível de confiabilidade, onde em caso de falha o cliente não tenha nenhum período de indisponibilidade. Assim, existem mecanismos de tolerância a falhas com técnicas já consolidadas, que podem ser utilizados também em ambientes de computação em nuvem, porém também existe o conceito de elasticidade que em situações especificas dispensa o uso de mecanismo de proteção para determinados componentes do ambiente, podendo o próprio mecanismo de elasticidade realizar de um mecanismo de tolerância a falhas. Este trabalho tem como principais contribuições a possibilidade de compreender a ocorrência de falhas em um ambiente de elasticidade, possibilitando entender quais as melhores formas de lidar com falhas nesse tipo de ambiente e também conhecer quais as consequências da ocorrência de falhas.

6 Abstract More and more companies choose to use services based in Cloud Computing, either provided by a third party or by its own private cloud infrastructure. In this context, companies are increasing their dependence in applications running in this kind of environment. Consequently, solutions based on Cloud Computing must deliver high availability, not compromising the services in case of failure. In a Cloud Computing environment, all applications must have high availability standard levels, although due to pricing models, a client may require that some applications have greater level of reliability, therefore, in case of failure, the cloud services would still be available. There are consolidated fault tolerance mechanisms with already established techniques that can be used in a cloud computing environment. However, there is also the elasticity concept, which, in a specific situation, eliminates the use of a protection mechanism for some environment components, making the proper elasticity mechanism the one to provide the fault tolerance protection. This paper main contribution is the understanding of failures occurrence in elasticity environment, which lead us to understand the best way to deal with these failures, and also allows us to recognize the consequences generated due to these failures.

7 Sumário Lista de Tabelas Lista de Siglas Capítulo Introdução Motivação Objetivos Contribuições Estrutura do Trabalho Capítulo Estado da arte Computação em nuvem Infraestrutura como serviço (IaaS) Plataforma como serviço Software como serviço Tipos de implementação de computação em nuvem Vantagens adquiridas com o uso de computação em nuvem Virtualização Hipervisores Tipos de virtualização XEN Migração de máquinas virtuais XEN live migration Tolerância a falhas Classificações de falhas Técnicas de tolerância a falhas Detecção de falhas Tolerância a falhas em ambientes de computação em nuvem Soluções de tolerância a falha para aplicações em ambiente de nuvem Soluções para a tolerância a falha de hardware em ambiente de nuvem Soluções para a tolerância a falha de máquina virtual em ambiente de nuvem Injeção de Falhas... 38

8 Capítulo Metodologia Cenário Métricas Ferramentas utilizadas Fatores e níveis Capítulo Resultados Resultados com Carga de trabalho gradativa Resultados com carga de trabalho de média fixa Capítulo Conclusão e trabalhos futuros Principais resultados Trabalhos futuros Referências... 74

9 9 Lista de figuras Figura 1 Relação entre tipo de serviço e usuários de computação em nuvem 18 Figura 2 Uso de elasticidade em nuvens privadas [45] Figura 3 Tipos de hipervisores Figura 4 Virtualização total Figura 5 Paravirtualização no XEN Figura 6 Ciclo live migration [15] Figura 7 Classificação de falhas de Servidores... Erro! Indicador não definido. Figura 8 Tempo de resposta de rede Remus Figura 9 Perda de pacotes Remus Figura 10 Arquitetura de um sistema injetor de falhas Figura 11 Abrangência do trabalho Figura 12 Arquitetura do experimento Figura 13 Cenário com detecção on-line e reparo off-line (adaptado de [50]).. 46 Figura 14 Cálculo MDT Figura 15 Resultados sem falhas Figura 16 Resultados com média de intervalo entre falhas de 5 minutos Figura 17 Comparativo de quantidade de máquinas virtuais Figura 18 Resultados com média de intervalo entre falhas de 10 minutos Figura 19 Tempo de Resposta com DPSR e injeção de falhas seguindo média Figura 20 Quantidade de Máquinas virtuais com DPSR e injeção de falhas seguindo média Figura 21 Resultados com média de intervalo entre falhas de 15 minutos Figura 22 Quantidade de máquinas virtuais Figura 23 Taxa de erros Versus média de falhas... 62

10 10 Figura 24 Tempo médio de recuperação Figura 25 Tempo médio de indisponibilidade Figura 26 Taxa de violações de SLA - Carga variável Figura 27 Quantidade de requisições - Média Fixa Figura 28 Tempo de Resposta com Carga de média fixa Sem Falhas Figura 29 MTTD Carga Fixa Figura 30 Resultados com carga de trabalho fixa Figura 31 Quantidade de Máquinas virtuais com carga fixa Figura 32 Comparativo DPSR X DPCR-SE com carga fixa... 70

11 11 Lista de Tabelas Tabela 1 - Lista de servidores Tabela 2 - Fatores e níveis da primeira fase de testes... 45

12 12 Lista de Siglas ARP CPU DCCR DPCR DRBD GB HBFT HD HTTP HVM IaaS IP MB MDT MTBF MTTD MTTR MV NIST PaaS SaaS SF SLA SPOF SR SO TI TRMB VMM Address Resolution Protocol Central Processor Unit Detector do controlador sem recuperação Detector próprio sem recuperação Distributed Replicated Block Device Gigabyte Hypervisor Based Fault Tolerance Hard disk Hypertext transfer protocl Hardware virtual machine Infraestructure as a Service Internet protocol Megabyte Mean down time Mean time between failures Mean time to detect Mean time to repair Máquina virtual National Institute of Standards and Technology Plataform as a Service Software as a Service Sem falhas Service-level agreement Single point of failure Sem recuperação Sistema Operacional Tecnologia da Informação Tempo de resposta por megabyte Virtual Machine Manager

13 13 Capítulo 1 Introdução Serviços de computação em nuvem possibilitam a clientes contratarem serviços de computação de acordo com sua necessidade, e pagar somente pelo que irão utilizar [3]. Esses serviços podem ser utilizados sem nenhum investimento inicial, onde toda a infraestrutura fica por conta do provedor de serviços (nuvem pública) ou pode ser criada uma infraestrutura completa de nuvem internamente (nuvem privada) [6] [8]. A computação em nuvem não é um conceito totalmente novo, mas sim a evolução e união de diversos conceitos já estabelecidos da computação como sistemas distribuídos, virtualização entre outros. [1]. 1.1 Motivação Cada vez mais empresas estão migrando seus serviços de computação para ambientes de computação em nuvem. Devido a essa dependência cada vez maior desse tipo de ambiente, nos últimos tempos existe uma grande preocupação por parte de pesquisadores em definir um modelo de tolerância a falhas para ambientes de computação em nuvem [33] [34] [35]. Porém existem diversas técnicas de tolerância a falhas para ambientes computacionais, já estabelecidas e reconhecidas como de grande efetividade. Nesse contexto é necessário avaliar se as soluções de tolerância a falhas já existentes e aplicadas em outros tipos de sistemas computacionais também são válidas em ambientes de computação em nuvem. Existem ainda características presentes em ambientes de computação em nuvem como a elasticidade e balanceamento de carga [36], que dependendo do que for especificado para o serviço pode atuar como um mecanismo de tolerância à falha, em casos específicos. Devido à forma de contratação de serviços em ambientes de computação em nuvem, também podem ser oferecidos diferentes níveis de tolerância a falhas de acordo com a necessidade do cliente, uma vez que dependendo da solução de tolerância fornecida pelo provedor de serviços,

14 14 essa solução pode ter custos maiores, tanto computacionais quanto financeiros. Para avaliar o comportamento do ambiente de elasticidade em caso de falhas e também o desempenho de diferentes soluções de tolerância à falhas, foi construído um ambiente de elasticidade baseado em nuvem privada que teve como objetivo se aproximar ao máximo de situações reais de um ambiente de elasticidade, onde existe a variação de recursos de acordo com a demanda. 1.2 Objetivos Objetivo geral O objetivo do trabalho é estudar e avaliar soluções de recuperação de falhas disponíveis para ambientes de computação em nuvem, baseadas em conceitos e técnicas de tolerância a falhas já estabelecidas e verificar se em casos específicos, os próprios mecanismos de computação em nuvem dispensam o uso de mecanismos restritos a tolerância a falhas. Objetivos específicos A partir do objetivo geral são definidos objetivos específicos, listados a seguir: Analisar o desempenho de soluções de tolerância à falha para ambiente de computação em nuvem; Analisar a possibilidade de o próprio mecanismo de elasticidade dispensar o uso de um mecanismo especifico de recuperação de falhas; Analisar deficiências e propor melhorias às soluções de tolerância a falhas para ambiente de nuvem, já integradas a controladores de nuvens; Verificar qual componente de uma solução de recuperação de falhas tem maior influência em um ambiente de elasticidade. 1.3 Contribuições As principais contribuições do trabalho são: Compreensão do comportamento de ambientes de elasticidade em decorrência de falhas;

15 15 Impacto das falhas no desempenho de ambientes de elasticidade; Identificação do grau de importância de cada um dos componentes de um mecanismo de tolerância a falhas, em um ambiente de elasticidade; Definição das melhores ferramentas de tolerância a falhas para ambientes de elasticidade. 1.4 Estrutura do Trabalho A estrutura do trabalho segue da seguinte forma: no primeiro capitulo é realizada uma introdução ao tema central do trabalho. No segundo capítulo é demonstrado o estado da arte dos temas relevantes ao restante da pesquisa e que possibilitaram a seleção de ferramentas e também o desenvolvimento da metodologia. No terceiro capítulo é apresentada a metodologia empregada no trabalho, para alcançar os objetivos propostos. No quarto capítulo são apresentados os resultados obtidos, divididos em duas etapas de acordo com a carga de trabalho aplicada. E por fim no quinto capítulo é concluído o trabalho com apanhado geral após a realização dos experimentos e os trabalhos futuros.

16 16 Capítulo 2 Estado da arte 2.1 Computação em nuvem O conceito de computação em nuvem não é um conceito totalmente novo, surgiu do desenvolvimento de técnicas já consolidadas como computação paralela, computação distribuída e grid computing em combinação com a evolução de técnicas como virtualização, entre outras [1]. Devido ao conceito de computação em nuvem ser muito amplo e envolver diversas tecnologias, existem diferentes definições sobre o tema o National Institute of Stantandards and Technology NIST [2], define computação em nuvem como um modo de fornecer acesso rápido e sob demanda, a um conjunto de recursos computacionais como servidores, redes, aplicativos e armazenamento, interligados em rede. Esses recursos podem ser rapidamente gerenciados e distribuídos entre os clientes, sem gerar uma grande carga de trabalho. Um aspecto importante é relacionado ao valor cobrado pelos serviços de computação em nuvem, Armbrust [3] afirma que, a computação em nuvem proporciona ao usuário serviços de computação como utilidade pública, semelhantes à água, telefonia e energia elétrica, onde o consumidor paga os recursos de acordo com o que utiliza. Buyya et al [4], afirma que a computação chegará a ser o quinto item de utilidade pública junto com água, energia elétrica, gás e telefone. Nesse contexto o conceito de computação em nuvem será fundamental para que todos os serviços computacionais atendam as demandas diárias da comunidade. Os serviços de computação em nuvem são divididos basicamente em três tipos. São eles: infraestrutura como serviço (IaaS), plataforma como serviço (PaaS) e software como serviço (SaaS) [2].

17 Infraestrutura como Serviço (IaaS) O conceito de infraestrutura como serviço (IaaS - Infrastructure as a Service), diz respeito ao oferecimento de infraestrutura total de computador com o uso de máquinas virtuais, oferecendo acesso a essas máquinas virtuais através da internet [5]. Também podemos complementar que IaaS é o oferecimento de recursos de infraestrutura computacional sob demanda, através da implementação de tecnologias de virtualização. Como exemplo desse tipo de serviço podemos citar a plataforma Amazon EC2, que possuí diversos tipos de máquinas virtuais com diversos valores diferentes, que podem ser contratados conforme a necessidade [6] Plataforma como Serviço (PaaS) O conceito de plataforma como serviço (PaaS - Plataform as a Service), diz respeito ao oferecimento de uma plataforma de desenvolvimento de aplicativos online, onde os aplicativos podem ser desenvolvidos individualmente ou em conjunto, para posteriormente serem acessados por outros usuários [5]. Os itens presentes nesse tipo de serviço (PaaS) são: frameworks para desenvolvimento de aplicativos, sistemas operacionais e demais componentes necessários para o desenvolvimento de aplicativos. Entre os serviços que oferecem essa modalidade estão Google App Engine e o Microsoft Azure [6] Software como Serviço (SaaS) O conceito de software como serviço (SaaS Software as a Service), está relacionado ao oferecimento de soluções de software completas e conforme a necessidade, através da internet [6]. Existem diversos tipos de softwares oferecidos totalmente através da internet. Esses softwares vão desde os mais simples até os mais complexos como aplicativos de CRM e ERP [5]. Todos esses serviços são oferecidos aos clientes, sem que os mesmos tenham conhecimento da plataforma em que são implementados, devido à camada de abstração gerada pela arquitetura de computação em nuvem, em conjunto com as técnicas de virtualização [7].

18 18 Na Figura 1, é possível ver a relação entre os tipos de serviços de computação em nuvem, e os tipos de usuários. Em nenhum dos tipos de implementação o usuário tem acesso à infraestrutura física (hardware). Tipos de usuários Tipos de serviços Usuários finais Desenvolvedores Administradores de sistemas Software como Serviço SaaS Plataforma como Serviço- PaaS Infraestrutura como Serviço IaaS , CRM, ERP, redes sociais etc. Windows Azure, Google App Engine etc. Máquinas virtuais Hardware Figura 1. Relação entre tipos de serviço e usuários de computação em nuvem Tipos de implementação de computação em nuvem As principais implementações de nuvem são: nuvens públicas, nuvens privadas, nuvens híbridas e nuvens comunitárias Nuvens públicas Nuvens públicas oferecem serviços de computação em nuvem, onde o provedor de nuvem computacional é o proprietário e responsável pela infraestrutura de TI, implantando suas próprias políticas, modelos de custos e cobrança. Como exemplos de nuvens públicas temos Amazon EC2 e Google App Engine [8]. Clientes de nuvens públicas não precisam fazer um investimento inicial em infraestrutura, uma vez que, todos os custos e riscos decorrentes da infraestrutura ficam por conta do provedor de serviços [6] Nuvens privadas Nuvens privadas podem ser também definidas como nuvens internas, uma vez que os serviços e recursos são oferecidos internamente para uma

19 19 única organização. Questões como implementação, gerenciamento e suporte muitas vezes são realizados pela própria empresa ou por um prestador de serviço [6]. Muitas empresas optam por utilizar nuvens privadas, devido a questões como segurança e privacidade uma vez que a própria empresa tem controle total da infraestrutura computacional, diferente da nuvem pública onde a organização não tem todo esse controle. A transferência de dados que já estão dispostos internamente, para uma nuvem privada, também é um dos fatores que levam empresas a optarem por implementações de nuvem privada [8] Nuvens híbridas Nuvens híbridas buscam combinar os conceitos de nuvens públicas e nuvens privadas, onde parte da infraestrutura utilizada fica armazenada internamente e a outra parte fica externa. A vantagem é que podem ser usados os aspectos de segurança e controle presentes em nuvens privadas, juntamente com aspectos de elasticidade e disponibilidade de recursos, presentes em nuvens públicas [6]. Dillon and Chang [8], afirmam que empresas podem armazenar seus serviços principais em uma nuvem privada contando com um maior controle e segurança, porém podem fazer uso de uma nuvem pública para armazenar serviços secundários e de menor importância, utilizando assim uma nuvem híbrida Nuvens comunitárias Nuvens comunitárias são construídas e mantidas por um grupo de organizações que compartilham dos mesmos valores, políticas e requisitos. Devido a divisão dos custos se torna uma alternativa viável de computação em nuvem e a nuvem computacional pode ser hospedada em um prestador de serviço externo ou mesmo em um ou mais membros mantenedores da nuvem comunitária [8] Vantagens adquiridas da computação em nuvem Existem diversas vantagens que surgem da implantação de ambientes de computação em nuvem. Entre essas vantagens podemos citar

20 20 disponibilidade e flexibilidade. Disponibilidade, pois os provedores que oferecem serviços baseados em computação em nuvem, em sua maioria possuem uma grande infraestrutura com diversos itens redundantes, oferecendo uma disponibilidade muito maior do que recursos armazenados em pequenas infraestruturas internas. Flexibilidade, pois é possível contratar recursos conforme a necessidade, como em situações de teste, onde não seria vantajoso adquirir uma infraestrutura completa, incluindo licenças de software, servidores entre outros [5]. Podemos complementar com as seguintes vantagens [6]: Custos de acordo com a utilização: Os custos de um determinado serviço podem ser baseados na utilização e também a contratação de recursos pode ser de acordo com a demanda. Recursos Compartilhados: Os recursos computacionais (armazenamento, memória, processamento etc.) podem ser agrupados e compartilhados entre diversos serviços diferentes conforme a necessidade. Esse compartilhamento pode ser automatizado, onde os recursos são liberados automaticamente de acordo com o uso, ou podem ser definidos manualmente, sem que sejam necessárias alterações de infraestrutura para disponibilização de recursos. Os recursos são disponibilizados de forma mais simples e dinâmica. Arquitetura baseada em serviço: Por se tratar de uma arquitetura baseada em serviço, é possível estabelecer contratos de níveis de serviço, que irão assegurar os níveis desejados entre clientes e prestadores de serviço Elasticidade Elasticidade é a capacidade de fornecer e retirar recursos, rapidamente e muitas vezes de forma automática, conforme requisições e necessidades dos clientes. Do ponto de vista do cliente ele tem recursos ilimitados que podem ser solicitados conforme a necessidade [2].

21 21 Através dessa estratégia, é possível fornecer espaço de armazenamento, novas instâncias de máquinas virtuais, maior quantidade de memória e processamento, entre outros recursos computacionais. A elasticidade é uma ótima estratégia para gerenciar recursos onde a demanda varia de acordo com o tempo, pois em períodos de alta demanda é disponibilizada uma maior quantidade de recursos para assim cumprir os níveis de SLA, porém em momentos de baixa demanda não são usados recursos de forma desnecessária. O gerenciamento de recursos pode ser realizado através da análise das alterações de carga ou também através de predição [39]. Em ambientes de elasticidade, os recursos são oferecidos de forma dinâmica principalmente no formato de máquinas virtuais, onde os recursos são gerenciados pelo controlador de nuvem, da forma mais efetiva possível. Os recursos devem ser gerenciados de modo que não sejam oferecidos recursos inferiores ao necessário, pois esse tipo de situação traria impacto no desempenho esperado pelos usuários. Já o provisionamento de recursos além da necessidade, irá gerar custos desnecessários, uma vez que a cobrança é realizada de acordo com o tempo de utilização de recursos [45]. Na figura 2, é possível verificar um exemplo do funcionamento de um ambiente com elasticidade, onde a carga de trabalho aumenta gradativamente (a), em consequência do aumento de carga de trabalho, há um aumento na disponibilização de recursos computacionais na forma de máquinas virtuais (b) para atender a demanda, porém o tempo de resposta se mantém estável(c), apesar do aumento na carga. Requests Minutes a) Carga de trabalho

22 VMs Minutes b) Recursos computacionais 9 6 Mean Median 90 th Percentile Seconds Minutes c) Tempo de resposta Figura 2. Uso de elasticidade em nuvens privadas [45] As implementações de computação em nuvem só são possíveis devido a união e implementação de diversas tecnologias e conceitos de computação. Entre esses conceitos está o conceito de virtualização, que será apresentado mais detalhadamente a seguir. 2.2 Virtualização A virtualização é um conjunto de técnicas que foram apresentadas primeiramente pela IBM na década de 1960, para dividir recursos de mainframe em instâncias menores e assim obter um melhor aproveitamento do hardware. Após diversas mudanças e evoluções, tornou-se possível por meio do uso da virtualização habilitar uma única máquina física a executar diversas instâncias de sistemas operacionais simultâneas e em ambientes isolados, apesar de compartilhar o mesmo hardware [9].

23 23 A camada de virtualização é responsável por gerar uma abstração entre o hardware físico e os sistemas operacionais executados de forma virtualizada, denominados sistemas operacionais convidados. Essa camada de virtualização é implementada por um software denominado VMM (virtual machine manager) ou hipervisor. O hipervisor é o software responsável por gerenciar e distribuir os recursos entre as máquinas virtuais, também denominadas instâncias. Através da virtualização é possível realizar diversas tarefas como cópia de máquinas virtuais, migração de máquinas virtuais e gravação de estado atual (checkpoint), para restauração em um momento posterior [10]. As técnicas de virtualização proporcionam as seguintes vantagens [11]: Flexibilidade: é possível executar diversas instâncias de sistemas operacionais diferentes em um único hardware físico; Disponibilidade: torna-se mais simples instâncias de máquinas virtuais em execução do que servidores físicos. Caso seja necessário desligar um servidor, as instâncias de máquinas virtuais podem ser migradas para outro servidor, com um mínimo tempo de interrupção; Escalabilidade: alterações que envolvem o aumento da estrutura podem ser realizadas sem um grande esforço; Utilização do hardware: O hardware pode ser compartilhado entre diversas instâncias com sistemas operacionais diferentes, sem a necessidade de um hardware para cada servidor. Outras vantagens são balanceamento de carga, fácil adaptação a variações de carga de trabalho, entre outras. Também podemos citar como vantagens da virtualização aspectos como migração de máquinas virtuais, otimização de uso do hardware, utilização em teste de software e pesquisa de sistemas operacionais [12]. Existem algumas desvantagens adquiridas ao implantar ambientes virtualizados como único ponto de falha (single point of failure - SPOF), localizado no hardware do host que hospeda as instâncias, onde em caso de falha, em principio ocorrerá falha em todas as instâncias. Existe também a

24 24 perda de desempenho gerada pela camada de virtualização. Em ambientes com soluções de diferentes fornecedores, podem existir problemas devido a cada solução de virtualização utilizar sua própria plataforma de gerenciamento [11]. Apesar das desvantagens citadas, a virtualização continua sendo uma técnica vantajosa, pois as vantagens são muito maiores em relação as desvantagens. Algumas dessas desvantagens podem ser solucionadas inclusive com soluções de código fonte aberto como, por exemplo, através do uso de controladores de nuvem como o OpenNebula [46], que possibilita o gerenciamento de um ambiente heterogêneo, com soluções de virtualização de diversos fornecedores diferentes Hipervisores Hipervisores são os sistemas que implementam a virtualização realizando a criação de máquinas virtuais, gerenciamento de recursos e balanceamento de carga. Os hipervisores são divididos em hipervisores do tipo 1 e hipervisores do tipo 2. Hipervisores do tipo 1 são executados diretamente no hardware, eliminando a necessidade da instalação de um sistema operacional base. Exemplos de hipervisores do tipo 1 são XEN 1 e VMware ESX 2. Já os hipervisores do tipo 2, são executados a partir de um sistema operacional base como os demais aplicativos, adicionando uma camada a mais na estrutura do sistema computacional. Exemplos de hipervisores do tipo 2 são VMware Workstation, VirtualBox 3 e Parallels 4 [13]

25 25 Figura 3 Tipos de hipervisores Tipos de virtualização Os hipervisores implementam basicamente dois tipos de virtualização, denominados paravirtualização e virtualização total Virtualização total Nesse tipo de virtualização não são necessárias alterações no sistema operacional convidado. O sistema operacional convidado é executado normalmente como se estivesse instalado diretamente no hardware. O hipervisor é responsável por apresentar um conjunto de hardware virtual ao sistema operacional convidado. Todas as solicitações a recursoss de hardware, realizadas pelos sistemas operacionais convidados são encaminhadas para os dispositivos de hardware em tempo de execução pelo hipervisor [10].

26 26 MV1 MV2 MVn S.O. Convidado S.O. Convidado S.O. Convidado Hardware virtual Camada de virtualização Hardware Figura 4 Virtualização total Paravirtualização A técnica de paravirtualização é uma técnica onde é necessário alterar o sistema operacional que será executado como convidado, para que esse não realize todas as solicitações de recursos de hardware aos dispositivos de hardware virtual. Neste tipo de virtualização o sistema operacional convidado tem conhecimento de que é executado em um ambiente de virtualização e esse por sua vez se comunica diretamente com o hipervisor através de chamadas de sistema [10]. A Figura 5, mostra em detalhes como funciona a paravirtualização no hipervisor XEN.

27 27 Figura 5 Paravirtualização no XEN Fonte: XEN XEN é um hipervisor do tipo 1, de código aberto que implementa tanto técnicas de virtualização total quanto paravirtualização. A criação de instâncias pode ser realizada tanto como as que utilizam virtualização total quanto como instâncias que utilizam paravirtualização. O XEN é um hipervisor que implementa a virtualização através do conceito de domínios, onde cada nova instância será um novo domínio. Existe um domínio principal que é iniciado durante o processo de boot do sistema denominado domínio 0. O domínio 0 é responsável pela criação e finalização de outros domínios, alocação de memória entre os domínios, e controlar o acesso dos demais domínios aos dispositivos de disco e rede. O XEN utiliza as técnicas de paravirtualização para minimizar a perda de desempenho gerada na virtualização total [14]. Devido às técnicas de paravirtualização utilizadas no XEN necessitarem de alterações do sistema operacional, no caso de executar sistemas operacionais que não permitam alteração em sua estrutura é possível executar esses sistemas operacionais com técnicas de virtualização total, denominadas HVM (hardware virtual machine).

28 Migração de máquinas virtuais A migração de máquinas virtuais entre hosts físicos é uma ótima ferramenta para administradores de sistemas de ambientes virtualizados. A migração de instâncias promove uma maior independência entre o hardware e o software e possibilita o balanceamento de carga e manutenções de hardware [15]. A migração de máquinas virtuais pode ser realizada em tempo de execução, sem que seja necessário interromper o funcionamento da máquina virtual. Esse tipo de migração é denominada live migration no hipervisor XEN e VMotion no hipervisor VMware ESX. Ambos os mecanismos funcionam de forma semelhante, onde todo o conteúdo de memória da instância presente no hipervisor de origem, é copiada para o hipervisor de destino, gerando um tempo mínimo de indisponibilidade [16] XEN live migration A técnica de migração de máquinas virtuais live migration, aplicada pelo XEN é uma técnica utilizada para migrar instâncias de um host a outro com o menor tempo de indisponibilidade possível. Uma das principais vantagens dessa técnica é que as conexões TCP/IP existentes são mantidas mesmo após a migração, causando tempos de indisponibilidade da ordem de milissegundos. O live migration realiza a migração do conteúdo de memória de uma instância presente em um host A para um host B, e é aconselhado o uso de um sistema de arquivos compartilhado como, por exemplo, um NAS (network attached storage), uma vez que apenas o conteúdo de memória é transferido [15]. Na Figura 6, é possível ver o ciclo completo do live migration.

29 29 Figura 6 Ciclo live migration [15] 2.3 Tolerância a falhas Uma falha acontece quando o serviço entregue diverge do serviço inicialmente proposto. Uma falha pode acontecer devido ao serviço não atender as especificações funcionais ou porque as especificações não são realizadas da forma correta. A transição do funcionamento correto de um serviço para o seu funcionamento incorreto é determinado como falha. O período que um serviço fica indisponível é determinado como interrupção de serviço. Já a transição de um estado de falha para o funcionamento correto é apontado como restauração de serviço. O erro diz respeito ao comportamento indesejado que ocorre em decorrência da falha [17]. Um determinado componente é considerado com falhaa quando o seu comportamento não atende as especificações funcionais, resultando em comportamentos fora do previsto em projeto, seja atendendo as necessidades parcialmente ou na totalidade [18]. Tolerância a falhas é o conjunto de meios utilizados paraa evitar que um serviço não atenda os requisitos estabelecidos, em caso de falha [17]. Conforme Laprie [26], a tolerância à falha é a forma de assegurar através de redundância, que os serviços atenderão o que foi especificado, em caso de falhas. Existe também a definição de sistema parcialmente tolerante a falhas,

30 30 onde em caso de falhas o sistema se adéqua a situação, executando uma versão mais simplificada não fornecendo toda sua capacidade computacional ou aumentando o tempo de resposta, até que o problema seja resolvido. Esse conceito também é conhecido como degradação graciosa [20] Classificações de falhas Classes de falhas em relação à origem As falhas podem ser classificadas em duas principais classes diferentes [29]: Falhas físicas: são falhas que acontecem devido a fenômenos físicos, onde podemos citar alterações de temperatura, sobrecarga de circuitos, entre outras. Essas falhas podem acontecer dentro do próprio sistema ou externamente. Uma falha que aconteça devido a desgastes em relação à interação humana, também é uma falha física, pois essa também acontece em decorrência de fenômenos físicos. Falhas humanas: são falhas que não tem como origem fenômenos físicos. Falhas humanas podem ocorrer devido ao uso de compiladores, aplicações, instalações de dispositivos, entre outras. As falhas humanas são divididas em falhas de desenvolvimento e falhas de interação. Falhas de desenvolvimento estão relacionadas à implementação de hardware e software do sistema e também a alterações posteriores de hardware e software, que façam com o que o sistema não cumpra o que foi inicialmente especificado. Falhas de interação são falhas geradas em decorrência de operações cotidianas ou de manutenção, realizadas através de interfaces de gerenciamento, linhas de comando etc Classificação de falhas de Servidores As falhas que ocorrem em servidores são classificadas em três tipos [21]: Falhas de tempo: ocorrem quando um servidor responde fora do tempo especificado. Essa falha pode ser tanto de atraso da resposta quanto em relação a uma resposta adiantada;

31 31 Falhas de omissão: é quando um servidor não responde as solicitações que lhe foram feitas; Falhas arbitrárias: acontecem quando em certos momentos o servidor não responde as solicitações, em outros momentos responde fora do tempo estabelecido Falhas bizantinas Falhas bizantinas são falhas baseadas em uma analogia com os generais bizantinos. Essa analogia, diz que em um determinado momento, diversos agrupamentos do exército bizantino estavam do lado de fora de uma cidade inimiga aguardando o momento certo para atacar. Cada grupo possui o seu próprio general, que no momento que avistar o inimigo ambos devem tomar a mesma decisão, recuar ou atacar. Porém alguns dos generais podem ser traidores, que poderiam passar uma informação incorreta aos mensageiros, uma vez que essa era a forma de comunicação. Em um sistema computacional o conceito se aplica quando os nós envolvidos em um serviço comportam-se de forma arbitrária, comprometendo o resultado final de um determinado serviço [22]. Em um ambiente computacional, uma falha bizantina pode ocorrer, por exemplo, entre dois servidores interligados. Os dois servidores tomam decisões independentes um do outro, como por exemplo finalizar processos para liberar recursos. Um mecanismo de detecção de falhas presente em um servidor A, pode não detectar uma falha em um servidor B devido a esse servidor não estar totalmente operacional. O servidor B envia mensagens ao detector de falha presente no servidor A, informando que está operacional, porém o servidor B não está inteiramente operacional. Apenas o mecanismo de detecção está sem problemas, e esse não foi finalizado pois o sistema operacional do servidor B tomou a decisão de finalizar diversos processos, porém manteve o mecanismo de comunicação entre os servidores operacional.

32 Técnicas de tolerância a falhas Redundância Redundância é uma técnica onde um determinado componente do sistema é duplicado, e qualquer uma das partes pode ser utilizada sem que haja comprometimento do sistema como um todo. Em caso de falha, o sistema continuará funcionando normalmente, minimizando o impacto sobre os usuários [27]. As técnicas de redundância facilitam a operação por que não necessitam da interação de um operador em caso de falha, o próprio sistema se recupera da falha ativando o componente de reserva Formas de recuperação e reconfiguração em sistemas redundantes A recuperação de um sistema redundante pode ser realizada de duas formas: ou o componente defeituoso é substituído por um reserva (spare), ou a carga de trabalho é dividida entre outros componentes do sistema [23]. Em caso de substituição de componente, essa pode ser feita de duas formas diferentes, denominadas hot standby e cold standby. Em uma solução baseada em cold standby, uma unidade extra (backup) com características físicas e funcionalidades idênticas a unidade principal fica preparada para assumir as tarefas no caso da unidade principal falhar. O estado atual não é recuperado pela unidade de backup, pois as alterações não são compartilhadas entre as duas unidades. Devido a essas questões, soluções de cold standby são de simples implementação. Soluções hot standby resolvem o problema encontrado em soluções cold standby realizando o sincronismo de estado entre a unidade principal e a unidade de backup. O sincronismo de dados pode ser realizado através da duplicação de entrada, onde as duas unidades recebem solicitações para alteração de dados, ou através da troca de informações entre a unidade principal e a unidade de backup em intervalos de tempo predeterminados. Em caso de falha a quantidade de informação perdida estará relacionada com o intervalo de tempo entre as trocas de informação [32]. Para realizar a troca de informações entre unidade principal e backup em soluções de hot standby, podem ser utilizadas técnicas de checkpointing.

33 Checkpointing A técnica de checkpointing consiste em realizar a gravação do estado atual de um determinado sistema (checkpoint), em um local de armazenamento seguro. Em caso de falha no sistema, o mesmo é restaurado para um estado anterior. Existem duas formas de se realizar checkpointing, uma abordagem salva somente o último checkpoint, e existe outra abordagem onde são armazenados diversos checkpoints e caso ocorra uma falha, é selecionado o checkpoint correto para a restauração [24]. As técnicas de checkpointing protegem de erros de hardware e software, assim também é possível afirmar que em técnicas de checkpointing e também em outras técnicas de tolerância a falhas, nem sempre é preciso determinar se uma falha acontece devido a hardware ou software [25] Heartbeat Heartbeat é uma técnica de detecção de falhas, onde uma determinada entidade envia mensagens para um detector informando que está disponível. Caso as mensagens não sejam recebidas pelo detector de falha, dentro de um intervalo de tempo pré estabelecido, o detector de falhas assumirá que a entidade está indisponível [28] Detecção de falhas A detecção de falhas consiste basicamente no reconhecimento que algo inesperado está acontecendo no sistema, e com base nessa detecção são tomadas determinadas ações. Existem diversas formas de detecção de falhas e o período entre a ocorrência da falha e a detecção é determinado latência de falha [50]. A detecção de falhas é dividida em duas classes principais [50]: Detecção on-line: nesse tipo de detecção a verificação é realizada em tempo real, sem a necessidade de finalizar ou pausar o sistema para realizar as checagens necessárias; Detecção off-line: ao utilizar essa técnica de detecção, é necessário que o sistema se torne indisponível por um determinado intervalo de tempo, para que sejam realizadas as verificações pertinentes a detecção.

34 Tolerância a falhas em ambientes de computação em nuvem Considerando a arquitetura da computação em nuvem, as falhas podem ser divididas em três grupos principais: falhas de máquinas virtuais, falhas de hardware e falhas de aplicação. As técnicas de tolerância a falha são compostas de duas fases principais: a detecção da falha e a recuperação da falha. Em ambientes de computação em nuvem existe a dificuldade em implementar soluções de tolerância a falha, pois é necessário definir qual membro deverá ser responsável pela detecção e recuperação, o provedor de serviços ou o cliente [29] Soluções de tolerância à falha para aplicações executadas em ambiente de nuvem Monit Monit 5 é uma solução de tolerância a falhas de código livre que monitora processos ou aplicações em sistemas Unix e realiza operações de recuperação em caso de falhas. Com o uso do Monit é possível monitorar aplicações que são executadas em ambiente de computação em nuvem e recuperar essas aplicações, tanto em falhas de tempo quanto em falhas de omissão HAProxy HAProxy 6 é uma solução grátis que incorpora balanceador de carga e solução de alta disponibilidade. O HAProxy é desenvolvido com a finalidade de prover alta disponibilidade a sites que possuem um volume muito alto de conexões. A recuperação em caso de falha é feita basicamente reiniciando a aplicação com problema (servidor web) Soluções para a tolerância a falha de hardware em ambiente de nuvem Pacote Heartbeat O pacote Heartbeat 7 é parte do projeto Linux-HA, projeto esse que é responsável por manter uma série de aplicações para alta disponibilidade de clusters. O pacote Heartbeat é composto de um mecanismo de detecção

35 35 (heartbeat) e um mecanismo de recuperação de falhas denominado CRM (cluster resource manager). Atualmente o pacote Heartbeat, utiliza o Pacemaker 8 como CRM. Em caso de falha, o Pacemaker executa os scripts necessários para inicialização dos serviços desejados. Assim, em um ambiente de virtualização, o pacote Heartbeat não monitora a máquina virtual, mas sim o host que executa a máquina virtual, por isso consideramos uma solução a tolerância a falhas de hardware. O pacote Heartbeat é uma solução de redundância do tipo cold standby Soluções para a tolerância a falha de máquina virtual em ambiente de nuvem HBFT HBFT (hypervisor based fault tolerance), trata-se de uma abordagem onde o hipervisor é responsável por implementar a solução de tolerância a falhas, sendo responsável tanto pelos mecanismos de detecção quando recuperação. A vantagem dessa abordagem é que não são necessárias alterações no hardware ou sistema operacional para implementar a tolerância a falhas [30]. Existem diversas soluções de HBFT disponíveis para o hipervisor XEN, entre elas estão Kemari e Remus, que será tratado em maiores detalhes a seguir, pois foi incorporada ao hipervisor XEN nas últimas atualizações Remus Remus é uma solução de tolerância a falhas baseada em checkpoint, disponível para o hipervisor XEN. O Remus trabalha com o conceito de principal e backup, onde em intervalos preestabelecidos, o conteúdo de memória da máquina virtual principal é copiado para a máquina virtual de backup, ou seja, é criado um checkpoint da máquina virtual principal, no host de backup. Esse processo gera uma grande sobrecarga de rede, uma vez que todas as alterações de memória devem ser transmitidas para o host que contém a máquina virtual de backup. O Remus implementa os checkpoints utilizando o conceito de live migration do 8

36 36 Xen, realizando diversas vezes seguidas a última fase do processo de live migration, à ser executada na máquina principal, que consiste em pausar a máquina virtual de origem e transmitir as últimas alterações de memória para o host de backup [31]. Ao utilizar o Remus, a máquina virtual de backup fica em estado de pausa, caso ocorra algum problema com a máquina principal, a máquina virtual de backup passa a ser executada. O Remus utiliza o próprio checkpoint como mecanismo de detecção de falha. Também em caso de atraso ou falha no recebimento de checkpoints, a máquina virtual de backup passa a ser executada. Apesar da sobrecarga de recursos gerada pelo Remus, a principal vantagem adquirida, é que em caso de falha todas as conexões TCP IP são mantidas, não sendo necessária a criação de uma nova sessão por parte dos usuários. Isso é possível devido à técnica de live migration, que após a migração de uma máquina virtual, gera um pacote ARP, para os clientes da rede local, informando a nova localização de um determinado endereço IP [15]. O Remus realiza a replicação apenas do conteúdo de memória, assim para manter o disco sincronizado entre as máquinas virtuais é necessário o uso de outra tecnologia. Com essa finalidade pode ser utilizado um espaço de armazenamento compartilhado entre as máquinas virtuais como, por exemplo, um NAS (network attached storage), ou um mecanismo de sincronização de discos como o DRBD 9. O Remus é um solução de tolerância a falhas que implementa redundância baseada em hot standby. Realizamos estudos preliminares [47] que permitiram entender o funcionamento do Remus e a quantidade de recursos computacionais consumidos para o seu funcionamento. Nesses estudos foram definidas duas cargas de trabalho diferentes: carga de rede e carga de CPU. Também foram realizados testes sem nenhuma carga, para servir de linha de base para os demais experimentos, esses por sua vez são os fatores do experimento. Já os níveis foram definidos com o intervalo de checkpoint, ou seja, de quanto em 9

37 37 quanto tempo a aplicação replica o conteúdo de memória, da máquina virtual principal para a máquina virtual de backup. Não foram utilizadas métricas de tolerância a falha, somente métricas de desempenho, pois o intuito dos experimentos era verificar o impacto no desempenho, gerado pela utilização de uma proteção como o Remus. Na figura 8, é possível verificar que tanto em carga de rede quanto em um sistema ocioso, o tempo de resposta cai até um intervalo de checkpoint de 100 milissegundos, ao utilizar 200 milissegundos como intervalo de checkpoint, o sistema sujeito a uma carga de rede começa a ter aumento no tempo de resposta. Em se tratando do sistema submetido à carga de CPU, o crescimento é gradativo conforme aumenta o intervalo de checkpoint. Em todos os casos, houve um crescimento muito grande a partir de 300 milissegundos, isso ocorre devido ao funcionamento do processo de checkpoint, onde todas as alterações ocorridas entre um checkpoint e outro devem ser sincronizadas entre a máquina principal e o backup, assim quanto mais tempo demorar o backup maior será a transferência de dados pela rede, deste modo é possível compreender o aumento no tempo de resposta conforme aumenta o intervalo de checkpoint. Figura 7 Tempo de resposta de rede Remus Na Figura 9, é possível perceber que a utilização do Remus pode gerar a perda de pacotes de rede, por conta da intensa troca de informações entre a

38 38 máquina principal e a máquina de backup. Semelhante ao acontecido em relação a tempo de resposta é possível perceber um valor mais alto, quando se é utilizado um intervalo de checkpoint de 500 milissegundos. Ao ser aplicada uma carga de rede, o sistema avaliado se mostrou mais sensível, gerando uma maior quantidade de erros. Figura 8 Perda de pacotes Remus 2.5 Injeção de Falhas Muitas vezes não é possível aguardar dados estatísticos de uso de sistemas em operação para definir o que ocorre em caso de falhas. Assim são necessários experimentos preliminares que prevejam e possam definir o comportamento dos sistemas em caso de falhas. Esses experimentos são possíveis devido a técnicas de injeção de falhas, que consistem basicamente na introdução deliberadaa de falhas em um sistema alvo [38]. Os primeiros estudos com injeção de falhas datam da década de 1970, onde fabricantes utilizavam am técnicas de injeção para avaliar a confiabilidade de computadores tolerantes a falha. Posteriormente, na década de 1980 pesquisadores passaram a utilizar técnicas de injeção de falhas em pesquisas que tinham como objetivo verificar a eficiência de novos mecanismos de tolerância a falhas [43]. As técnicas de injeção de falhas têm como principais objetivos a previsão de falhas e a remoção de falhas. Com relação a remoção de falhas,

39 39 as técnicas de injeção de falhas visam a redução de erros durante o desenvolvimento de mecanismos de tolerância a falhas, e também são úteis para definir como os mecanismos devem se portar no caso de ocorrência de alguma falha, para reduzir ao máximo os impactos destas falhas. Já com relação à previsão de falhas, é possível avaliar taxas de eficiências dos mecanismos de tolerância a falha, comparar diferentes soluções em ocorrência de falhas e também averiguar se os mecanismos de tolerância a falhas irão se portar conforme o desejado. [37]. Através da injeção de falhas é possível realizar diversos experimentos, que variam em como e quando as falhas ocorrem, dessa forma é possível estimar o tempo de recuperação e a confiabilidade do sistema, baseado em experimentos e não somente definir valores aproximados. É fundamental que durante os experimentos com injeção de falhas, o sistema alvo esteja trabalhando com uma carga de trabalho que simule o seu funcionamento em condições reais de uso, para que sejam obtidos dados mais próximos de uma situação real de uso, assim será possível verificar o real comportamento do sistema em ocorrência de uma ou mais falhas [43]. A injeção de falhas pode ser realizada basicamente de duas formas diferentes: injeção de falhas baseada em simulação e injeção de falhas baseada em protótipo. Ao utilizar a técnica baseada em simulação, o sistema é definido como uma abstração de alto nível, e a ocorrência de falhas é definida com base em uma determinada distribuição. É uma alternativa de baixo custo, porém não oferece resultados muito apurados. Já ao utilizar uma técnica baseada em protótipo, o sistema avaliado pode ser um sistema em execução ou um protótipo, dessa forma os resultados serão mais satisfatórios. A injeção de falhas não é indicada para avaliar disponibilidade de um sistema e tempo médio entre falhas (MTBF) [44]. Existem diversas técnicas de injeção de falhas, que são divididas basicamente em injeção de falhas através de hardware e injeção de falhas por software. Na injeção de falhas através de hardware novos componentes de hardware são adicionados ao sistema para gerar as falhas desejadas. A injeção de falhas baseada em software pode ser realizada em dois momentos

40 40 distintos, antes que o código seja compilado, assim a falha estará presente no programa executável final, ou também pode ser injetada em tempo de execução [44]. Figura 9 Arquitetura de um sistema injetor de falhas (Adaptado de [44])

41 41 Capítulo 3 Metodologia Neste capitulo é apresentada a metodologia utilizada nos experimentos e demais assuntos julgados pertinentes a um melhor entendimento do trabalho. 3.1 Cenário A aplicação central do experimento consiste em uma aplicação de transferência de arquivos PDF de um repositório com um conjunto de servidores e um conjunto de clientes. Os arquivos PDF possuem tamanhos que seguem uma distribuição Log-normal, que mais se aproxima dos sistemas de arquivos de servidores da internet [40], e foi utilizado um conjunto de 50 arquivos com média de tamanho de 8 MB. Para o experimento, foi considerado como falha qualquer uma das requisições que não consigam realizar a transferência do arquivo por completo. Considerando a grande quantidade de componentes presentes em um ambiente de computação em nuvem, as falhas podem ocorrer em cada um desses componentes. Como pode ser visto na Figura 11, o escopo desse trabalho engloba apenas as falhas ocorridas em máquinas virtuais, mais especificamente em um ambiente com elasticidade.

42 42 Figura 10 Abrangência do trabalho Como pode ser observado na Figura 12, as requisições são criadas através de um gerador de carga (1), que envia as requisições aleatoriamente, seguindo uma taxa de chegada de Poisson [41], capaz de gerar carga de até 3000 requisições simultâneas. O balanceador de carga recebe as requisições e distribui igualmente entre e as máquinas virtuais existentes (2). O mecanismo de elasticidade (3) monitora ora constantemente (intervalos de um minuto), a quantidade de requisições recebidas pelo balanceador e a quantidade de máquinas virtuais existentes. Caso a quantidade de requisições supere o limiar superior para a criação de máquinas virtuais, ou o limiar inferior para a finalização de máquinas virtuais, o mecanismo de elasticidade envia uma solicitação de criação ou finalização de máquina virtual, para o controlador de nuvem (4), e envia uma solicitação de atualização para o balanceador de carga, informando que houve alteração no pool de máquinas virtuais disponíveis. O balanceador por sua vez adiciona ou remove uma máquina virtual de sua lista, em seguida recarrega o serviço responsável pelo balanceamento (servidorr web).

43 43 Figura 11 Arquitetura do experimento Assim, pode-se afirmar que o nosso mecanismo de elasticidade é baseado em alterações de carga de trabalho e não em predição, uma vez que as alterações no sistema só acontecem mediante alterações de carga de trabalho. Foi utilizado comoo critério a quantidade de requisições, pois a mesma está ligada ao tempo de resposta que é a melhor métrica a ser utilizado devido à aplicação ser baseadaa no protocolo HTTP [42]. Para todos os experimentos foi utilizada a mesma carga de trabalho, essa por sua vez foi pensada de forma que as requisições aumentassem gradativamente e tambémm diminuíssem de forma gradativa, fazendo com que o mecanismo de elasticidade crie e finalize as máquinas virtuais, evidenciando o funcionamento da elasticidade. O limiar para a criação de máquinas virtuais foi definido em 270 requisições simultâneas, assim caso a quantidade de requisições por máquina

44 44 virtual ultrapasse esse valor, uma nova máquina virtual será criada e adicionada ao pool de máquinas virtuais. Este valor foi definido com base em testes preliminares. O mecanismo de elasticidade é limitado a criar uma única máquina virtual por vez, isso foi realizado adicionando uma trava de software (lock) ao mecanismo de elasticidade. Foi adotado esse método, pois em testes preliminares foi verificado que o controlador de nuvem apresentou problemas caso fossem criadas diversas máquinas virtuais simultaneamente. O limiar inferior foi definido em 180 requisições simultâneas e funciona da mesma forma que o limiar superior, porém caso a quantidade de requisições por máquina virtual seja inferior a 180, uma delas será finalizada e removida do pool de máquinas virtuais. Ambos os limiares foram definidos de acordo com testes preliminares, e de acordo com o tempo de resposta aceitável para uma única máquina virtual. Ambos os limiares foram definidos após vários testes preliminares. O injetor de falhas (5) é uma aplicação baseada em um temporizador [44], executado em um computador remoto, que ao final de um intervalo de tempo dispara uma falha finalizando uma máquina virtual do pool de recursos da elasticidade diretamente no hipervisor. Este intervalo de tempo é baseado em uma distribuição Weibull [43] e a arquitetura do sistema injetor de falhas segue o modelo presente na Figura 10. Para que os experimentos fossem realizados em todos os fatores de forma semelhante foram utilizados números pseudo aleatórios. Para isso foram gerados os valores da distribuição Weibull e armazenados em arquivos de texto, sendo um arquivo para cada repetição de experimento, assegurando assim comparação em situações iguais em todos os fatores. Para a detecção de falhas foram utilizados dois métodos diferentes: um detector de desenvolvimento próprio, que em intervalos de um minuto verifica a disponibilidade de todas as máquinas virtuais junto ao hipervisor e um detector de falhas que utiliza a detecção do próprio controlador de nuvem, que verifica a disponibilidade das máquinas virtuais, com base em critérios próprios, ambos são de métodos de detecção on-line.

45 45 O sistema tolerante a falhas utilizado nos experimentos é do tipo detecção on-line reparo off-line [50], uma vez que não é necessário finalizar nenhum componente para a detecção; já o reparo ocorre off-line, dado que a máquina virtual a ser criada para recuperação não está disponível de imediato. Em todos os casos entre a ocorrência da falha e a recuperação, acontecem os seguintes passos: Detecção (Figura 13.1): o detector de falhas verifica que uma ou mais máquinas virtuais presentes no pool de elasticidade não está disponível; Reconfiguração (Figura 13.2): a máquina virtual com falha é removida do balanceador de carga, para que esse não encaminhe requisições a ela. Nesse período até que seja criada uma nova máquina virtual e disponibilizada para o balanceador de carga, pode acontecer um fenômeno denominado degradação graciosa, em razão de a quantidade de máquinas virtuais ser inferior ao necessário; Reinicialização (Figura 13.3): neste momento são recarregadas as configurações do balanceador de carga; Recuperação (Figura 13.4): a nova máquina virtual está criada e disponível para receber novas requisições. Neste estágio ela é adicionada ao balanceador de carga, e o mesmo tem suas configurações recarregadas novamente. Semelhante ao que acontece com o mecanismo de elasticidade, que possui uma trava de software para criar uma máquina virtual por vez, o mecanismo de recuperação também possui essa trava. Assim podem ser criadas duas máquinas virtuais simultaneamente, sendo uma por causa de falha e outra pelo mecanismo de elasticidade, que tem como critério a quantidade de requisições por máquina virtual.

46 46 Figura 12 Cenário com detecção on-line e reparo off-line (adaptado de [50]) 3.2 Métricas Para o desenvolvimento do trabalho foram utilizadas tanto métricas relacionadas à tolerância a falhas, quanto métricas relacionadas a analise de desempenho. São elas: Tempo de resposta por Megabyte (TRMB): Essa métrica está relacionada ao usuário, e consiste basicamente no tempo que o gerador leva para obter uma resposta sobre determinada situação. Foi utilizada a fórmula, onde tt é o tempo total de transferência e MB é o tamanho em megabytes do arquivo ao qual foi solicitado. Não foi utilizado somente o tempo tt como métrica, tendo em conta que existem arquivos de tamanhos variados, assim, através de testes preliminares a métrica trmb mostrou-se mais apropriada para os objetivos do trabalho; Taxa de erros: A taxa de erro consiste basicamente no percentual de arquivos que não têm a sua transferência finalizada por completo; Tempo médio de detecção (MTTD): O tempo médio de detecção é o tempo médio que o detector de falha leva para detectar uma falha; Tempo médio de reparo (MTTR): Consiste na média de tempo entre o inicio da criação de uma máquina virtual, (criada para recuperação de uma falha), e a sua disponibilização para o atendimento de requisições;

47 47 Tempo médio de indisponibilidade (MDT): Consiste na soma do tempo de detecção (MTTD) com o tempo de recuperação (MTTR) [48]; Figura 13 Cálculo MDT Adaptado de [48] Taxa de uso de memória: Percentual médio de memória, utilizado pelas máquinas virtuais presentes no pool de máquinas virtuais; Quantidade de requisições simultâneas: Quantidade de requisições simultâneas presentes no balanceador de carga. Essa métrica é utilizada principalmente para estabelecer os limiares superiores e inferiores; Número de máquinas virtuais: Quantidade de máquinas virtuais presentes no pool de máquinas virtuais de elasticidade. Violações de SLA: Foi definido um valor máximo tolerado que o tempo de resposta possa alcançar, caso o tempo de resposta ultrapasse o valor estipulado, é determinado que aquele arquivo gerou uma violação de SLA. O valor máximo foi definido como a média, acrescida de três vezes o desvio padrão. Para todas as métricas foi calculado o intervalo de confiança de 90%, e os mesmos foram demonstrados nos gráficos quando se julgou necessário.

48 Ferramentas utilizadas Para a realização dos experimentos foram utilizadas ferramentas distintas, são elas: Controlador de nuvem: Foi utilizado o controlador de nuvem OpenNebula 4.2 [46], pois no momento de elaboração do trabalho era o controlador de nuvem que mais se adequava aos testes propostos; Hipervisor: O hipervisor utilizado foi Xen 4.2, por possuir suporte a mecanismos de tolerância a falhas, utilizados previamente (Remus). Esses resultados prévios foram apresentados em parte na sessão que descreve o funcionamento de soluções HBFT. A utilização do Xen 4.2 também foi definida devido a esse hipervisor possibilitar integração com o controlador de nuvem utilizado; Balanceador de carga: O balanceador de carga utilizado foi baseado no servidor web Apache [49], e a escolha dessa aplicação foi feita baseada em testes preliminares que o indicaram como a melhor opção para uso em conjunto com mecanismo de elasticidade. Demais aplicativos que fornecem serviço de balanceamento de carga, apresentaram um alto índice de falhas durante a reinicialização do servidor web, reinicialização essa necessária sempre que existe alteração no número de máquinas virtuais presentes no pool de máquinas virtuais disponíveis. A máquina virtual executando o balanceador de carga utilizava o Sistema operacional Ubuntu 12.10; Máquinas virtuais de elasticidade: As máquinas virtuais do pool de elasticidade executam o servidor web Apache, sistema operacional Ubuntu e são máquinas virtuais baseadas em paravirtualização. Foi escolhida esse tipo de virtualização, pois em testes preliminares o processo de criação e disponibilização de máquinas virtuais paravirtualizadas ocorre de forma mais rápida do que quando é utilizada virtualização total. Cada máquina virtual possui 256 MB de memória. Na Tabela 1, é possível verificar os servidores utilizados nos experimentos e a relação desses servidores com as aplicações utilizadas.

49 49 Marca e modelo Memória HD Função SO Proliant HP ML350 G6 4GB 750 GB Controlador dos experimentos Ubuntu Proliant HP ML350 G6 4GB 750 GB Injetor de falhas Ubuntu Proliant HP ML110 G6 12GB 500 GB Gerador de carga Ubuntu Proliant HP DL380e G8 8GB 500 GB Controlador de Nuvem (Opennebula) Ubuntu Proliant HP DL380e G8 8GB 500 GB Hipevisor (Elasticidade - Xen 4.2) Ubuntu Proliant HP DL380e G8 8GB 500 GB Hipevisor (Balanceador de carga - Xen 4.2) Ubuntu Tabela 1 Lista de servidores 3.4 Fatores e níveis Os fatores foram definidos levando em consideração a forma de detecção e a presença ou não de um mecanismo de recuperação, desta forma os fatores são: Sem falhas (SF): Foram realizados testes sem a injeção de falhas, para que fosse definida uma linha de base, para assim comparar os valores com os demais experimentos; Elasticidade com falhas, detector próprio, com recuperação (DPCR): Neste fator, assim como nos demais, o mecanismo de elasticidade utilizado é o mesmo, porém foi utilizado um detector de falhas de desenvolvimento próprio, e a recuperação que consiste basicamente na criação de uma máquina virtual em caso de falha, independente da carga de trabalho; Elasticidade com falhas, detector do controlador, com recuperação (DCCR): Este fator é semelhante ao anterior, ocorrendo apenas a variação do detector de falhas utilizado ( detector próprio ou detector do controlador); Elasticidade com falhas, sem recuperação (SR): Nesse fator não existe recuperação de máquinas virtuais, apenas são criadas máquinas virtuais normalmente pela elasticidade, mas ocorre a injeção de falhas.

50 50 Detector próprio, com recuperação e sem elasticidade (DPCR-SE): Por fim, neste fator não existe o uso de elasticidade, apenas é realizada a recuperação de falhas e este fator só foi possível de ser aplicado nos experimentos de carga fixa, pois nestes experimentos a quantidade de máquinas virtuais já está no máximo necessária, no inicio dos testes. Foram realizados estes testes para verificar se somente a elasticidade comparada a somente um mecanismo de recuperação, possuem desempenho semelhante, para verificar se um ambiente de elasticidade realmente necessita de mecanismos de recuperação. Para a primeira etapa de testes os níveis foram baseados na média da distribuição Weibull, em relação ao intervalo de ocorrência de falhas e assim foram definidos três diferentes níveis: Alto: com média de cinco minutos entre falhas; Médio: que possui intervalo médio entre falhas de dez minutos; Baixo: que possui intervalo de quinze minutos entre falhas. Na primeira fase de testes com carga variável a combinação dos fatores e níveis resulta em uma quantidade de dez testes diferentes, conforme a Tabela 2: Weibull média 5 Níveis Weibull média 10 Weibull média 15 Fatores Sem Falhas (SF) Elasticidade com falhas, detector próprio com recuperação (DPCR) X X X Elasticidade com falhas, detector do controlador com recuperação (DCCR) X X X Elasticidade com falhas, sem recuperação (SR) X X X Tabela 2 Fatores e níveis da primeira fase de testes Já na segunda etapa de testes, foram realizados testes somente no nível alto (média de cinco minutos entre falhas), porém foram realizados testes para todos os fatores.

51 Experimentos Foram realizados experimentos com dois tipos de carga de trabalho diferentes, que buscaram alcançar situações o mais próximas das reais de trabalho. Na primeira série de experimentos foi utilizada uma carga de trabalho crescente, que possibilitasse uma melhor compreensão do funcionamento dos mecanismos de elasticidade. Para a validação dos resultados da primeira etapa, foram realizados testes com uma carga de trabalho com média de requisições simultâneas fixa. Cada teste tem duração de 40 minutos e foram realizadas 15 repetições de cada teste, pois uma quantidade maior de repetições não apresentava influências no resultado. Após o final de cada teste, os dados são coletados e são realizados os cálculos necessários, essa etapa leva aproximadamente 5 minutos, resultando em um total de aproximadamente 170 horas de testes.

52 52 Capítulo 4 Resultados Os resultados foram divididos em duas partes. Na primeira são apresentados os resultados dos experimentos com carga de trabalho gradativa e na segunda os resultados dos experimentos realizados com carga de trabalho de média fixa. 4.1 Resultados com Carga de trabalho gradativa Para uma maior compreensão dos resultados foram realizados testes sem a injeção de falhas, porém com a mesma carga de trabalho gerada para os demais fatores e níveis, essa etapa de testes foi determinada como Sem falhas (SF). É possível perceber na Figura 15(a) a distribuição da carga de trabalho do experimento, através da medição de requisições simultâneas que chegam ao balanceador de carga. Apesar da carga de trabalho crescer de forma gradativa, a Figura 15(b) mostra que o tempo de resposta não segue a distribuição das requisições, mantendo um valor de média e mediana estável. Esse comportamento só é atingido devido ao mecanismo de elasticidade, que com base nas requisições que chegam ao balanceador de carga cria ou finaliza máquinas virtuais para atender a demanda. Assim podemos verificar na Figura 15(c), que a quantidade de máquinas virtuais segue a distribuição de requisições encontrada no balanceador. Essa criação de máquinas virtuais não acontece além da necessidade, sendo essa uma das características da elasticidade, pois de nada adiantaria se fosse utilizada uma maior quantidade de máquinas virtuais do que o necessário. Explica-se assim a importância da definição dos limiares de elasticidade, que não pode ser muito grande a ponto de comprometer o desempenho, e não pode ser muito pequeno alocando uma menor quantidade de recursos que o necessário para atender a demanda.

53 53 a) Quantidade de requisições simultâneas Sem Falhas b) Tempo de Resposta Sem Falhas c) Quantidade de máquina virtuais - Sem Falhas Figura 14 Resultados sem falhas

54 54 Na Figura 16(a) verificamos o aumento no tempo de resposta em decorrência das falhas, que ocorre em todos os fatores. Esse aumento pode ser explicado devido ao processo de elasticidade, que sempre mantém a quantidade de máquinas virtuais necessárias para atender a um determinado tempo de resposta. Com as falhas o número de máquinas virtuais é reduzido, e com uma quantidade de máquinas virtuais abaixo do necessário algumas delas ficam sobrecarregadas, ocorrendo a situação denominada degradação graciosa, em que o sistema fica disponível, porém o desempenho é inferior ao esperado. Já na Figura 16(b) é possível verificar o percentual de erros, que ocorrem por dois motivos. O primeiro devido ao balanceador de carga que continua encaminhando parte das requisições para as máquinas virtuais que deveriam estar disponíveis, porém não estão devido a falhas. Outra parte dos erros ocorre pela sobrecarga de máquinas virtuais, em situações onde existe uma menor quantidade de máquinas virtuais do que o necessário para atender a demanda. Na Figura 16(c) é possível verificar o tempo médio de detecção (MTTD), que apresenta valores semelhantes ao utilizar o detector próprio, porém valores maiores ao utilizar o detector do controlador. Esse tempo de detecção maior é refletido no percentual de erros e tempo de resposta, uma vez que uma máquina virtual que não está disponível continua tendo requisições sendo encaminhadas a ela, gerando assim uma maior quantidade de erros.

55 55 Segundos SF DPCR DPSR DCCR a) Tempo de resposta com injeção de falhas seguindo média de 5 minutos entre falhas. 50 Percentual DPCR DPSR DCCR b) Percentual de erros com injeção de falhas seguindo média de 5 minutos entre falhas Segundos DPCR DPSR DCCR c) Tempo médio de detecção com injeção de falhas seguindo média de 5 minutos entre falhas. Figura 15 Resultados com média de intervalo entre falhas de 5 minutos A Figura 17 apresenta um comparativo entre a linha de base (SF) e um experimento com o detector do controlador, possibilitando a visualização de diversos momentos onde a quantidade de máquinas virtuais não é o ideal, justificando os valores maiores de tempo de resposta e percentual de erro apresentado nos gráficos anteriores. O sistema irá trabalhar com uma menor quantidade de máquinas virtuais do que o adequado, gerando degradação

56 56 graciosa e também o balanceador de carga continuará direcionando requisições para máquinas virtuais inexistentes ocasionando uma maior quantidade de erros Quantidade de Máquinas virtuais SF DCCR Minutos Figura 16 Comparativo de quantidade de máquinas virtuais A Figura 18(a) mostra que com uma média maior de intervalo entre falhas, que consequentemente resulta em uma menor quantidade de falhas por experimento. A diferença entre os fatores continua existindo, porém temos a diminuição no tempo de resposta. Com relação ao percentual de erros presente na Figura 18(b), verificamos que com uma menor ocorrência de falhas, tanto a recuperação quanto somente o mecanismo de elasticidade possuem desempenho semelhante, pois nesse tipo de situação apenas a elasticidade consegue atender a necessidade. Em relação aos resultados de MTTD presentes na Figura 18(c), percebemos que uma maior quantidade de falhas não altera o tempo de detecção, uma vez que os valores são semelhantes tanto na injeção de falhas com média 5 quanto aos com média 10.

57 57 Segundos SF DPCR DPSR DCCR a) Tempo de resposta com injeção de falhas seguindo média Percentual DPCR DPSR DCCR b) Percentual de erros com injeção de falhas seguindo média Segundos DPCR DPSR DCCR 50 0 c) Tempo médio de detecção com injeção de falhas seguindo média 10. Figura 17 Resultados com média de intervalo entre falhas de 10 minutos

58 58 Na Figura 19 verificamos o impacto causado no tempo de resposta em razão da ocorrência de falhas, que podem ser conferidas ao analisar o gráfico presente na Figura 20, onde não está presente a quantidade de máquinas virtuais necessárias no momento, gerando picos de tempo de resposta, reforçando os resultadoss já apresentados. A apresentação da série temporal, possibilita uma visão mais clara dos resultados finais, através de uma maior compreensão da relação entre quantidade de máquinas virtuais e tempo de resposta, situação essa que não ocorre no ambiente sem falhas, em razão do mecanismo de elasticidade sempre manter a quantidade adequada de máquinas virtuais. Figura 18 Tempo de Resposta com DPSR e injeção de falhas seguindo média 10. Figura 19 Quantidade de Máquinas virtuais com DPSR e injeção de falhas seguindo média 10

59 59 Na Figura 21(a) percebemos que o comportamento em relação ao tempo de resposta apresentado nos resultados anteriores se repete, mesmo com uma quantidade de falhas menor, e é possível perceber a grande influência exercida pelo detector de falhas junto ao tempo de resposta. Já com relação ao percentual de erros apresentado na Figura 21(b), observamos que este segue uma tendência de acordo com a taxa de falhas, diminuindo a diferença em relação às soluções conforme aumenta o intervalo médio de falhas. Quanto aos valores de MTTD presentes na Figura 21(c), notamos que tanto a diferença entre soluções como os valores apresentados anteriormente se repetem, reforçando a ideia que neste experimento a taxa de falhas não tem influência sobre o tempo de detecção. 60 Segundos SF DPCR DPSR DCCR a) Tempo de resposta com injeção de falhas seguindo média Percentual DPCR DPSR DCCR 0 b) Percentual de erros com injeção de falhas seguindo média 15.

60 60 Segundos DPCR DPSR DCCR c) Tempo médio de detecção com injeção de falhas seguindo média 15. Figura 20 Resultados com média de intervalo entre falhas de 15 minutos Ao verificar a quantidade média de máquinas virtuais (Figura 22), percebemos que há uma maior quantidade de máquinas virtuais ao se utilizar o detector próprio em conjunto com a recuperação, em comparação ao detector próprio sem recuperação. Isso acontece por existirem dois mecanismos criando máquinas virtuais ao utilizar o detector próprio e a recuperação: o mecanismo de recuperação e o mecanismo de elasticidade. Já em relação ao detector do controlador, o gráfico apresenta uma quantidade maior de máquinas virtuais ao se utilizar o detector de falhas do controlador, aparentemente demonstra uma vantagem nesse quesito, porém essa superioridade não foi repetida nas métricas anteriores. Isso acontece, pois o experimento mede as máquinas virtuais presentes no pool de elasticidade, como o detector de falhas baseado no controlador leva mais tempo para detectar as falhas as máquinas virtuais continuavam no pool de elasticidade, embora muitas vezes não estivessem respondendo as requisições que lhes eram encaminhadas, explicando assim os valores anteriores de taxa de erro e tempo de resposta.

61 61 Quantidade de Máquinas Virtuais SF DPCR W5 DPCR w10 DPCR w15 DPSR w5 DPSR w10 DPSR w15 DCCR w5 DCCR w10 DCCR w15 Figura 21 Quantidade de máquinas virtuais Observando a Figura 23 percebemos a diferença na taxa de erros em diferentes situações. Variando os fatores e níveis fica explícita a desvantagem do detector baseado no controlador. Conforme explicado anteriormente, o tempo maior que leva a detecção do controlador de uma máquina virtual que apresente uma possível falha, tem como consequência um maior tempo até que esta seja removida do pool de elasticidade, assim o balanceador de carga continuará encaminhando requisições para esta máquina virtual que está com falha, justificando os valores maiores de percentual de erro. Sobre a diferença entre utilizar recuperação ou não, apesar de os dois obterem valores semelhantes e ambos utilizarem o mesmo detector, a superioridade do método com recuperação pode ser explicada. Ao utilizar a recuperação, uma maior quantidade de máquinas virtuais estará disponível evitando a sobrecarga, assim a pequena vantagem adquirida pela solução com recuperação é esclarecida através da sobrecarga de máquinas virtuais enfrentada pela solução sem recuperação, porém é perceptível que a vantagem entre utilizar recuperação (DPCR) e não utilizar (DPSR), é muito pequena. Quando a taxa de falhas é maior, uma vez que ambos removem a máquina virtuais do pool de elasticidade ao detectar a falhas, a única diferença entre os dois serão os erros gerados por sobrecarga do sistema.

62 62 Figura 22 Taxa de erros Versus média de falhas A Figura 24 evidencia que quanto menor a média de falhas do experimento mais rápida é a recuperação de uma falha. Isso ocorre principalmente pela importância do controlador de nuvem no caso de ocorrências de falhas. Quando acontecem diversas falhas seguidas o controlador pode se sobrecarregar em decorrência da criação de máquinas virtuais, explicando os valores maiores nesse caso. Com relação ao detector do controlador obter valores mais altos no tempo de recuperação, pode ser justificado no fato de o controlador realizar a tarefa de detecção, tarefa essa que compromete o desempenho em demais funções como, por exemplo, a criação de máquinas virtuais, tarefa que é de extrema importância no experimento. Com relação ao intervalo de confiança possuir um maior valor com um intervalo de falhas de 15 minutos, é devido a uma menor ocorrência de falhas resultar em uma menor quantidade de valores para análise, explicando assim esses valores.

63 63 Segundos DPCR W5 DCCR W5 DPCR W10 DCCR W10 DPCR W15 DCCR W15 Figura 23 Tempo médio de recuperação Na figura 25, verificamos a confirmação dos resultados anteriores, uma vez que a solução que obteve pior desempenho em tempo de recuperação (MTTR) e tempo de detecção (MTTD) também obteve piores resultados em tempo médio de indisponibilidade (MDT), principalmente por essa métrica estar totalmente relacionada ao tempo de recuperação e detecção, conforme citado anteriormente. Em razão de o MDT ser obtido através da formula MDT= MTTD + MTTR, só foi possível medir nos fatores que realizam recuperação. Segundos DPCR W5 DCCR W5 DPCR W10 DCCR W10 DPCR W15 DCCR W15 Figura 24 Tempo médio de indisponibilidade Na figura 26 é possível verificar, que a taxa de violação de SLA (definida como a média mais três vezes o desvio padrão) também possui grande influência do tempo de detecção pois assim como nos resultados referentes a tempo de resposta, a solução que apresenta o maior tempo de detecção (DCCR) apresentou piores resultados nessa métrica. Esses resultados já eram esperados uma vez que essa métrica tem relação com o tempo de resposta,

64 64 assim podemos verificar também que a recuperação ou não das falhas não apresentou grandes vantagens, onde ambos os fatores não apresentam grandes diferenças que justifiquem a implantação de um mecanismo de recuperação. Figura 25 Taxa de violações de SLA - Carga variável 4.2 Resultados com carga de trabalho de média fixa Após a realização dos testes com a carga de trabalho crescente julgouse necessário realizar testes com uma carga de trabalho de média fixa, para verificar se os resultados obtidos persistem ou se os mesmos tiveram influência da carga de trabalho. Nessa etapa, foram realizados testes apenas com nível alto de falhas (média de 5 minutos entre falhas), pois com base nos testes anteriores acreditamos que serão obtidos resultados mais relevantes nessa fase de testes utilizando esse nível. Vemos na Figura 27 que o comportamento da carga de trabalho utilizando média fixa, apesar de ser uma carga sem variação, resulta em alteração na quantidade de requisições simultâneas. Isso ocorre porque o gerador de carga realizar as requisições seguindo uma taxa de chegada aleatória, com base em uma distribuição de Poisson.

65 Requisições Figura 26 Quantidade de requisições - Média Fixa Assim como nos experimentos anteriores com carga de trabalho variável, foram realizados testes com um fator para servir como linha de base nos experimentos, onde o sistema é sujeito a mesma carga de trabalho. Porém não existe a injeção de falhas, esse fator novamente foi denominado como Sem Falhas. Na Figura 28 é possível perceber que os valores de média e mediana se mantêm estáveis durante o decorrer do teste. Isto ocorre principalmente por que no experimento Sem Falhas a quantidade de máquinas virtuais é sempre de 10, que é a quantidade de máquinas virtuais necessárias para atender a demanda de requisições gerada durante os testes com carga fixa. Figura 27 Tempo de Resposta com Carga de média fixa Sem Falhas A Figura 29 demonstra que em relação à MTTD, foram gerados resultados muito semelhantes aos obtidos nos testes com carga variável, onde o detector do controlador apresenta um tempo maior para a detecção, com