Recuperação autônoma: uma arquitetura de componente para recursos de sistemas de informação

RECUPERAÇÃO AUTÔNOMA: UMA ARQUITETURA DE

COMPONENTE PARA RECURSOS DE SISTEMAS DE

INFORMAÇÃO

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

Recife

2017

CARLOS EDUARDO SERPA DE SOUSA

RECUPERAÇÃO AUTÔNOMA: UMA ARQUITETURA DE

COMPONENTE PARA RECURSOS DE SISTEMAS DE

INFORMAÇÃO

Dissertação apresentada ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, como parte dos requisitos necessários à obtenção do título de Mestre em Ciência da Computação. Orientador: Kiev Santos da Gama

Recife

2017

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

S725r Sousa, Carlos Eduardo Serpa de

Recuperação autônoma: uma arquitetura de componente para recursos de sistemas de informação / Carlos Eduardo Serpa de Sousa. – 2017.

105 f.: il., fig., tab.

Orientador: Kiev Santos da Gama.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.

Inclui referências e apêndice.

1. Ciência da computação. 2. Sistemas de informação. 3. Recuperação autônoma. I. Gama, Kiev Santos da (orientador). II. Título.

004 CDD (23. ed.) UFPE- MEI 2018-024

Carlos Eduardo Serpa de Sousa

Recuperação Autônoma: Uma arquitetura de componente para

recursos de sistemas de informação

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 20 de dezembro de 2017.

Aprovado em: 20/12/2017.

BANCA EXAMINADORA

______________________________________________ Prof. Carlos André Guimarães Ferraz

Centro de Informática / UFPE

__________________________________________ Prof. Vanilson André de Arruda Burégio Universidade Federal Rural de Pernambuco __________________________________________

Prof. Kiev Santos da Gama Centro de Informática / UFPE

AGRADECIMENTOS

Em primeiro lugar gostaria de agradecer a Deus por tudo que tem proporcionado em minha vida. Por todas as vezes que fraquejei e ele me trouxe força e coragem para continuar. Por todos os males que ele tirou da minha frente e me protegendo em todos os momentos que eu precisei.

Agradeço também à minha família, minha esposa Milena, meus filhos Cauê e Benjamin que me ajudaram, dando o suporte necessário para que eu enfrentasse mais esse desafio. Além disso, souberam me compreender quando tive que abdicar de muitos momentos familiares para a realização deste trabalho.

Presto meus agradecimentos especiais ao meu orientador, o Prof. Kiev Gama, por sempre estar à disposição, ajudando e motivando nos momentos mais necessá-rios.Também agradeço pela compreensão que ele teve diante dos meus momentos de dificuldade.

Sou muito grato aos meus colegas de trabalho, pois me deram muita força e su-porte quando eu precisei me ausentar para estar presente nas atividades relacionadas ao mestrado.

Deixo também meus sinceros agradecimentos a minha tia Rosângela que me ajudou a obter meu primeiro computador, que me propiciou essa paixão pela área, por ter me ajudado a pagar minha graduação e a todos aqueles que de forma direta ou in-diretamente me auxiliaram para que eu pudesse desenvolver os trabalhos relacionados a esta pesquisa.

Por último, um agradecimento muito especial a minha mãe, Francisca Ineide, que me deu todo o amor que podia dar e todo o suporte necessário para que eu conseguisse ter boas condições de vida. À minha mãe presto os meus mais profundos agradecimentos. Obrigado por tudo!

dade se você tem coragem para persegui-los” (Walt Disney).

RESUMO

À medida que sistemas modernos baseados em software ganham versatilidade e escalabilidade, a capacidade de gerenciar recursos inconsistentes e atender aos requisitos diversos dos usuários, torna-se cada vez mais imprescindível. Além disso, à medida que os sistemas aumentam em complexidade, a retificação de falhas de sistemas que requerem intervenção humana se torna mais difícil, suscetível a erros, e aumentam os custos associados à manutenção. Uma abordagem para resolver estes problemas é construir sistemas de autorrecuperação que possam detectar e recuperar-se de estados defeituosos de forma autônoma. Barecuperar-seado nas pesquisas da computação autônoma, a propriedade da autocura constitui o monitoramento de comportamentos e a “cura”, no sentido de se recuperar de falhas, utilizando entradas para se adaptarem ao ambiente em tempo de execução. Motivado pela complexidade de gerenciamento e alto custo de manuntenção de sistemas de informação, este trabalho, apresenta uma arquitetura de componente para autorrecuperação de recursos de sistemas de informação baseada na característica da computação autonôma, a autocura, tendo como finalidade exercer o papel de extensão para que sistemas de informação sejam capazes de se autocurarem de falhas sem ou com a mínima intervenção humana. Palavras chaves: Autocura. Computação autônoma. Recuperação autônoma.

As software-based systems gain versatility and scalability, an ability to manage inconstant resources and attend diverse user requirements becomes increasingly indis-pensable. In addition, as systems increase in complexity, rectification of system failures that require human intervention becomes more difficult, error prone, and increases the costs associated with maintenance. One approach to solving these problems is to build self-healing systems that examines and recover from defeat states autonomously. Based on research on autonomous computing, the self-healing property is behavior monitoring and a “cure,” in sense of recovering from failures, using inputs to adapt to the environment at runtime. Motivated by the complexity of management and high cost of maintaining information systems, this work presents a component architecture for self-recovery of information system resources based on the autonomic computation characteristic, the self-healing, with the purpose of exercising the extension role for that information systems are capable of self-healing of failures without or with minimal human intervention.

LISTA DE FIGURAS

Figura 1 – Figura demostrativa do MTBF e MTTR. . . 18

Figura 2 – Autonomic System . . . 28

Figura 3 – MAPE-K . . . 30

Figura 4 – Relações e propriedades da pesquisa de autocura . . . 35

Figura 5 – Design da arquitetura para recuperação autônoma . . . 43

Figura 6 – Mapa de pesquisa conforme DSR . . . 53

Figura 7 – Diagrama de componentes. . . 56

Figura 8 – Model-View-Controller - MVC . . . 58

Figura 9 – Interface element . . . 61

Figura 10 – Interface resources . . . 62

Figura 11 – Interface log . . . 62

Figura 12 – Chaves assimétricas . . . 63

Figura 13 – Diagrama de classe . . . 64

Figura 14 – Diagrama de Sequência . . . 66

Figura 15 – Ambiente sem componente . . . 68

Quadro 1 – Características trabalhos correlatos e proposta . . . 44 Quadro 2 – Critérios para condução das pesquisas que utilizam a design science

LISTA DE GRÁFICOS

Gráfico 1 – Comparação de ocorrências de indisponibilidades e chamados

re-sultantes . . . 72

Gráfico 2 – Comparação de ocorrências ferramenta ZABBIX e registros no com-ponente . . . 73

Gráfico 3 – CPU/IO sem aplicação do componente . . . 75

Gráfico 4 – CPU/IO com aplicação do componente . . . 76

Gráfico 5 – Memória livre sem aplicação do componente . . . 76

Gráfico 6 – Memória livre com aplicação do componente . . . 77 Gráfico 7 – Taxa de transferência sem aplicação do componente no ambiente. 77 Gráfico 8 – Taxa de transferência com aplicação do componente no ambiente. 78

Tabela 1 – Trabalhos correlatos . . . 38

Tabela 2 – Análise consolidada dos trabalhos relacionados. . . 45

Tabela 3 – Síntese dos métodos utilizados na pesquisa . . . 48

Tabela 4 – Método de pesquisa proposto por Peffers et al.(2007) . . . 54

Tabela 5 – Variáveis, ferramentas, períodos e forma de avaliação . . . 70

Tabela 6 – Verificação de MTBF, MTTR e Disponibilidade . . . 74

Tabela 7 – Análise comparativa dos trabalhos correlatos com a proposta. . . . 79

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associação Brasileira de Normas Técnicas

AC Autonomic Computing

AJAX Asynchronous Javascript and XML

API Application Programming Interface

BDTD Banco de Teses e Dissertaçõe

DSR Design Science Research

ECA Event, Condition and Action

ERP Enterprise Resource Planning

IBM International Business Machines

JDBC Java Database Connectivity

JEE Java Enterprise Edition

JSON JavaScript Object Notation

MTBF Mean Time Between Failures

MTTR Mean Time to Repair

MVC Model, View and Controller

OTRS Open-source Ticket Request System

PDF Portable Document Format

PNG Plano de Negócios e Gestão

POA Process-Oriented Architecture

REST Representational State Transfer

SDN Software Defined Network

SQL Structured Query Language

SSH Secure Shell

TCO Total Cost Ownership

UI User Interface

URL Uniform Resource Locator (Localizador Padrão de Recurso)

VPN Virtual Private Network

WAR Web application ARchive

SUMÁRIO

2.3 Sistemas de Autocura (Self-Healing) . . . . 32

2.4 Síntese do Capítulo . . . . 36

3 TRABALHOS CORRELATOS . . . . 37

3.1 Seleção de Trabalhos . . . . 37

3.1.1 Critérios de Inclusão e Exclusão . . . 38

3.1.2 Estratégia de Pesquisa . . . 39

3.1.3 Critérios de Avaliação . . . 39

3.2 Trabalho 1 - Aplicações Baseadas em Microsserviços . . . 40

3.3 Trabalho 2 - Aplicações Web . . . . 41

3.4 Trabalho 3 - Aplicações Componentizadas . . . . 42

3.5 Análise Conjunta . . . . 44 3.6 Síntese do Capítulo . . . . 45 4 METODOLOGIA . . . . 47 4.1 Classificação da Pesquisa . . . . 48 4.2 Universo da Pesquisa . . . . 51 4.3 Desenho da Pesquisa . . . . 51 4.4 Síntese do Capítulo . . . . 55 5 PROPOSTA . . . . 56

5.1 Motor de Regras e Base da Dados . . . . 57

5.2 Agente de Interface com o Sistema Gerenciado . . . . 57

5.3 Interface de Monitoramento com o Componente . . . . 57

5.6 Implementação . . . . 58 5.7 Síntese do Capítulo . . . . 66 6 AVALIAÇÃO DO ARTEFATO . . . . 67 6.1 Contextualização . . . . 67 6.2 Metodologia . . . . 69 6.3 Resultados . . . . 71 6.4 Discussão . . . . 78 6.5 Síntese do Capítulo . . . . 80 7 CONSIDERAÇÕES FINAIS . . . . 81 7.1 Conclusão . . . . 81 7.2 Limitações da Pesquisa . . . . 82 7.3 Trabalhos Futuros . . . . 82 REFERÊNCIAS . . . . 84

17

1 INTRODUÇÃO

“A menos que modifiquemos a nossa maneira de pensar, não seremos capazes de resolver os problemas causados pela forma como nos acostumamos a ver o mundo”.

(Albert Einstein) Este capítulo apresenta o problema que motivou o desenvolvimento deste traba-lho, os objetivos definidos para sua solução e uma descrição detalhada da estrutura desta dissertação.

1.1 Contextualização

Todos os dias nos encontramos à espera de algum serviço ou de uma entrega, imaginando “quanto tempo devo esperar?”. Assim também ocorre em sistemas de informação, ao esperar o resultado de um cálculo, a resposta a um pedido ou a uma comunicação. Por trás desta pergunta encontra-se a suspeita de que o sistema pode ter falhado, o pedido ter sido perdido, a ligação ter sido interrompida ou um processo erroneamente ter parado e nunca irá responder. De modo a decidir se o tempo esperado ainda está dentro de limites razoáveis, a pergunta “quanto tempo esperar?” implica em vários aspectos como: a consideração das razões para o tempo de espera; a investigação de possíveis soluções dos problemas que levam a longos tempos de espera; e a reativação desse recurso. A indisponibilidade de sistemas de informação exige uma análise detalhada para chegar à causa da falha e à reativação dos mesmos (WOLTER, 2010).

Quando sistemas de informação estão indisponíveis, os usuários finais são fre-quentemente os primeiros a notar, estes, por sua vez, contactam o suporte técnico e/ou o administrador de sistemas que pode então reestabelecer as operações. Restabelecer as operações dos sistemas envolve a dificuldade de detectar e localizar as falhas que causam esta indisponibilidade, podendo levar dias para detectá-las e recuperar os serviços (CANDEA et al., 2006).

Avizienis et al. (2004) define disponibilidade como a presteza para o serviço correto. Reussner, Schmidt e Poernomo (2003) reitera a disponibilidade como a probabilidade de um sistema estar disponível quando necessário, ou seja, o tempo durante o qual um componente ou sistema está funcionando de forma aceitável, o período de atividade durante o tempo de serviço total.

A disponibilidade pode ser pensada como composta por dois elementos: o MTBF ( Mean time between fails ou tempo médio entre falhas) e o MTTR (Mean time to repair ou tempo médio para reparo). Embora o tempo médio entre falhas seja essencialmente um resultado do processo de desenvolvimento, o tempo médio para reparar depende

principalmente do processo de manutenção Lucca, Penta e Gradara (2002). Uma vez que a falha ocorre em algum momento é necessária corrigir o erro e o MTTR mede o tempo médio que leva para rastrear os erros que causam a falha e corrigi-los (KAUR; BAHL, 2014), conforme apresentado na figura 1.

Figura 1 – Figura demostrativa do MTBF e MTTR.

Fonte: Autor (2017) adaptado de KAUR; BAHL (2014).

Apesar do design cada vez melhor em hardware e software, sistemas ainda travam ou falham com frequência. Ficam indisponíveis quando mais precisamos de seus serviços e regularmente trazem transtornos para administrá-los (DING, 2007). O dinamismo e a variedade de serviços integrados em grande escala têm motivado aplicações de computação autônoma (CORRÊA; CERQUEIRA, 2009).

A preocupação com essa complexidade dos sistemas de informação e a capa-cidade dos administradores de TI de lidar com elas, serviu como incentivo para com-putação autônoma1 _{(do inglês Autonomic Computing - AC). A solução proposta era} que o sistema assumisse grande parte da carga desse gerenciamento. O objetivo da computação autônoma é criar sistemas de computação que se administrem de acordo com objetivos de alto nível definidos por administradores ou usuários de sistemas de informação (CÁMARA et al., 2017).

Um requisito cada vez mais importante para os sistemas baseados em software é a capacidade de lidar com constantes mudanças, necessitando de recursos para tratar falhas em sistemas. Certos recursos de tratamento de erros contribuem para sistemas de prestação de tolerância a falhas ou mecanismos de autocura (GHOSH et al., 2007).

Projetos que permitem sistemas de software a se autocurar de falhas poderiam melhorar a confiabilidade e consistência de tecnologias. Com esforço, para garantir esses benefícios, se originou o conceito de sistemas de autocura (WOLTER, 2010).

Ao longo dos últimos anos o interesse em autorreparo e autocura aumentou constantemente, juntamente com contribuições nesta área de pesquisa. Diferentes 1 _{Os termos “Computação Autônoma” e “Computação Autonômica” são ambos usadas na}

Capítulo 1. INTRODUÇÃO 19

pesquisadores usam o mesmo termo com diferentes significados. Autorreparo é uma abordagem onde o sistema é capaz de se manter ou autorreparar sem influência ou controle externo e executa o reparo em si usando uma ferramenta. Normalmente os componentes com falha são substituídos. O conceito de autocura utilizado neste trabalho, é uma abordagem onde os componentes do sistema curam o dano por dentro. Normalmente, um componente com falha é reabilitado e nem todos os danos podem ser reparados e o design do mecanismo de autocura não pode cobrir todos os danos. Além disso, o mecanismo de cura também pode falhar (FREI et al., 2013).

A ideia principal é que componentes de sistema de autocura devem se recuperar a partir do estado anormal (ou “debilitado”) e retornar ao estado normal (“saudável”), voltando ao estado antes do rompimento (GHOSH et al., 2007).

Corrêa e Cerqueira (2009) relatam que desde 2001 trabalhos foram propostos com o propósito de inserir características autônomas em sistemas computacionais. Frei et al. (2013) mencionam que cientistas de materiais desenvolveram formas de tornar os revestimentos superficiais autorrecuperáveis (BLAISZIK et al., 2010) e aplicaram esses princípios com sucesso a uma variedade de materiais e outras tecnologias. Na robótica, a maioria das abordagens atualmente existentes para a autorreparação dependem de algum tipo de redundância e da substituição de peças com defeito, que apresentam alto custo e podem exigir horários de reparação específicos durante a vida útil do robô. Na engenharia de software são apresentadas características da autocura e outras propriedades de auto-* quando se trabalha com sistemas multiagente ou arquiteturas orientadas a serviços, embora ainda haja muita pesquisa. Na maioria das outras áreas, no entanto, as estratégias de autocura e autorreparação ainda são objetos de pesquisas intensas.

A computação em grande escala e os sistemas de informação são uma parte vital e integral da sociedade de hoje. Muitos desses sistemas de computação são tão críticos para a infraestrutura essencial e, às vezes, para a vida humana, que nenhum tempo de inatividade ou falha é realmente aceitável (WEI et al., 2011).

Tendo em vista essa visão e com intuito de diminuir o tempo de indisponibili-dade de sistemas de informações, algumas soluções têm utilizado uma abordagem baseada na computação autônoma, seguindo seu paradigma, fazendo uso do au-togerencimento, a fim de se produzir uma camada de abstração que possibilite o desenvolvimento de arquiteturas, mecanismos, frameworks, modelos e ferramentas, de modo a assumir grande parte da administração de sistemas de informação.

Dado este cenário, uma arquitetura de componente para recuperação autônoma melhoraria a disponibilidade de sistemas de informação em ambiente de produção minimizando o tempo médio para reparo (MTTR)?

1.2 Motivação

A motivação para a presente dissertação foi constituída através de duas percep-ções: a primeira decorrente da visão do pesquisador; e a segunda fundada na literatura, mais especificamente em relatos de trabalhos evidenciados na área de recuperação autônoma (SHRIRAM; HANI, 2015; MAGALHÃES; SILVA, 2015; CANDEA et al., 2006).

A primeira perspectiva motivacional é fundamentada na ambiente do pesquisa-dor onde há a necessidade de melhora na disponibilidade de sistemas de informação de forma autônoma, bem como, também, melhorar a confiabilidade dos serviços, per-mitindo que sistemas se recuperem em “tempo real” em vez de “tempo humano”, resultando em experiências melhores para usuários finais de serviços de TIC (CANDEA et al., 2006).

O ambiente, Instituto Federal de Santa Catarina - IFSC, é o órgão onde o pes-quisador faz parte do quadro de servidores, contando com um portfólio de 22 sistemas em média, variando entre 14 tecnologias, a serem gerenciados, e uma quantidade de 30.000 (trinta mil) usuários ativos desses sistemas. Como consequências, essa variedade de sistemas resulta em redundância de atividades, fluxos de processos inter-rompidos, problemas de interoperabilidade entre os sistemas e a necessidade de maior controle para gerenciá-los. Essas consequências geram uma demanda considerável de ocorrências de indisponibilidade de serviços, afetando assim diretamente a questão da confiabilidade do mesmos.

Diante dessas situações, o pesquisador foi buscar na literatura (dando início à segunda perspectiva motivacional para a pesquisa) trabalhos que legitimassem essas percepções e também trabalhos que sugerissem abordagens para minimizar os problemas encontrados. Na pesquisa literária foram encontrados diversos traba-lhos (SHRIRAM; HANI, 2015; MAGALHÃES; SILVA, 2015; CANDEA et al., 2006), comentados no capítulo 3, que legitimaram as percepções observadas no cenário mencionado como:

1) Erros de software e regressões de desempenho são causas importantes de tempo de inatividade;

2) A complexidade de interoperabilidade entre sistemas de informaçao e dificuldade de gerenciamento os levam à indisponibilidade;

3) Redução do tempo de inatividade de sistemas de informação;

4) Capacidade de extensão com características de autogerenciamento para siste-mas de informação.

Capítulo 1. INTRODUÇÃO 21

A contribuição da pesquisa será uma proposta de arquitetura de componente para autorrecuperação de recursos de sistemas de informação, visando melhorar a disponibilidade dos sistemas. O componente terá como fundamental função recuperar recurso(s) de sistemas de informação de um estado anormal para um estado normal, anterior ao momento da falha que causou a indisponibilidade do sistema de informação. 1.3 Justificativa

Hudaib et al. (2017) declaram que os sistemas atuais não têm compreensão de autogerenciamento e exigem uma extensão para o comportamento autônomo, adaptando-se no tempo de execução a mudanças imprevisíveis do sistema. Eles enfatizam essa necessidade de uma extensão autonôma com base nos números crescentes de gastos na manutenção dos sistemas nos últimos anos. A complexidade das arquiteturas de computadores, software e o rápido aumento do número de usuários em complemento do aumento do custo de manutenção são fatores que guiaram muitos pesquisadores para desenvolver software, aplicações e sistemas que tenham a capacidade de autocura, útil em todas as situações em que o envolvimento humano é dispendioso e precisa ser automatizado.

A complexidade dos componentes de TI são de gerenciamento complexo dificul-tando que os profisionai de TI consigam manter uma infraestrutura estável. À medida que a infraestrutura cresce e muda, falhas de implantação do sistema, problemas de hardware e software e erros humanos podem dificultar cada vez mais a administração do sistema. A intervenção humana é necessária para melhorar o desempenho em um sistema de TI, elevando os seus custos (IBM, 2006).

Na literatura foram encontrados indicativos que apresentam ferramentas para serem utilizadas como instrumento para o problema da recuperação autônoma como uma extensão do sistema a ser gerenciado, como por exemplo: uso de inteligência arti-ficial, modelo de comunicação entre gerentes autônomos, homologação de arquiteturas de recuperação autônoma, entre outros.

Diante desse cenário, que envolve diferentes áreas - recuperação autônoma, computação autônoma e sistemas de autocura observou-se a oportunidade de investi-gar e propor uma arquitetura de componente para autorrecuperação de recursos de sistemas de informação visando melhorar disponibilidade dos sistemas, minimizando interrupções, considerando características mínimas das áreas mencionadas.

1.4 Definição do Problema

O crescimento e complexidade dos sistemas computacionais atuais, dado a grande diversidade de elementos de software e hardware que os integram (LIU;

PA-RASHAR; HARIRI, 2004), resultam na inevitável incapacidade humana de os gerenciar. A computação autônoma lida com tal problema conferindo grande parte das respon-sabilidades para o próprio sistema, criando-se software com a capacidade de se autogerenciarem a partir de diretivas de alto nível (CORRÊA; CERQUEIRA, 2009).

Hudaib et al. (2017) menciona que muitos recursos destinados à tecnologia de informação são gastos em manutenções preventivas, recuperações de falhas e localização e determinação de problemas. Um manifesto elaborado pela IBM (H, 2001) alertava para a dificuldade do gerenciamento de software complexo como o principal obstáculo para futuras inovações na indústria de TI.

Embora inicialmente concebido como um paradigma para o futuro do gerenci-amento de TI, ao longo do tempo, os princípios, objetivos e técnicas de computação autônoma passaram a ser aplicados de forma mais ampla, estendendo-se a sistemas físicos como data centers (e robôs de centro de dados), a internet de coisas, casas inteligentes, etc (CÁMARA et al., 2017).

Aplicações para provimento de diversos serviços são criadas em um ambiente corporativo, tendo grande importância o cuidado em prover uma infraestrutura que man-tenha estas aplicações disponíveis com a qualidade esperada pelo cliente do serviço, tendo como desafio neste cenário manter o controle operacional destas aplicações, coletando informações referentes à disponibilidade do serviço, desempenho, consumo de recursos de hardware e de rede, defeitos no software, dentre outros (ORACLE, 2017).

Para que este monitoramento se torne uma realidade dentro do ambiente, é indispensável o uso de ferramentas que possam disponibilizar estas informações em tempo hábil para que sejam realizadas as intervenções necessárias. Manter um histó-rico destas informações traz um diferencial importante, pois, com o seu uso, medidas pró-ativas podem ser efetuadas na aplicação e/ou ambiente, evitando a indisponibi-lidade do serviço oferecido; consequentemente, evitando que apenas intervenções corretivas sejam realizadas (WOLTER, 2010). Para criar o monitoramento de um ambi-ente com este cenário, muitas vezes, é comum integrar estas aplicações com outros produtos para prover recursos de monitoramento. Identificar e alertar os pontos críticos de falha e repassar estas informações à equipe responsável pela operação da aplicação e/ou ambiente é um dos principais objetivos para manter o serviço operante (ORACLE, 2017).

Esse problema é particularmente evidente em arquiteturas de vários níveis, onde os serviços são compostos de vários conjuntos de sistemas com responsabilidades diferentes (LASTER; OLATUNJI, 2007; SCHNEIDER; BARKER; DOBSON, 2013).

Capítulo 1. INTRODUÇÃO 23

1.5 Objetivos 1.5.1 Objetivo Geral

Dentro destas perspectivas, os objetivos da presente pesquisa podem ser defini-dos por:

• MELHORAR a disponibilidade de sistemas de informação;

• POR MEIO DE uma arquitetura de software baseada em recuperação autônoma; • DE MODO QUE sistemas de informação se autorrecuperem de falhas, reduzindo

o tempo de indisponibilidade com a mínima intervenção humana;

• A FIM DE QUE usuários tenham uma melhor experiência com sistemas de informação, de modo que possíveis falhas passem imperceptíveis.

1.5.2 Objetivos Específicos

Levando-se em consideração o objetivo geral, podemos estabelecer os seguintes objetivos específicos:

a) Investigar técnicas e visões de diferentes autores sobre recuperação autônoma e computação autônoma;

b) Investigar as dificuldades relatadas por profissionais na administração de com-ponentes de sistemas de informação;

c) Minimizar o tempo de indisponibilidade de componentes de sistemas (ou subsis-temas) combinando técnicas de recuperação autônoma;

d) Minimizar intervenção humana na administração de sistemas de informação; e) Definir uma arquitetura de componente para autorrecuperação de recusros de

sistemas de informação, adaptando-se à correção de falhas e/ou mudanças internas e externas;

f) Propor mecanismo de definição de regras para recuperação;

g) Criar interfaces interoperáveis para gerenciamento autônomo de sistemas de informação.

1.6 Estrutura do Trabalho

O trabalho está organizado em sete(7) capítulos correlacionados. O capítulo 1 apresenta o contexto da pesquisa, destacando o problema, justificativa e a motivação do pesquisador em realizá-la. Nessa seção, também são formulados os objetivos de pesquisa.

O capítulo 2 traz os termos, os fundamentos e os conceitos teóricos necessá-rios para subsidiar a pesquisa: Complexidade de software, Computação autônoma, Recuperação autônoma.

O capítulo 3 discute os trabalhos correlatos que possuem similaridade com a presente pesquisa. São descritos três (3) trabalhos, seguidos de uma análise das características destacadas.

O capítulo 4 descreve a metodologia utilizada para realização da pesquisa. São apresentados o esquema metodológico e o desenho da pesquisa, contendo todas as suas etapas.

O capítulo 5 aborda detalhadamente o objeto principal da pesquisa, ou seja, a arquitetura desenvolvida. Nos primeiros itens são apresentados os fundamentos que levaram à construção da arquitetura e suas premissas e, na sequência, são descritas todas as partes e particularidades que a compõem.

O capítulo 6 expõe a avaliação que foi executada na arquitetura proposta: um estudo de caso. Ainda são elucidados a técnica utilizada e os resultados obtidos.

O capítulo 7 apresenta as conclusões acerca do trabalho, as principais contri-buições da pesquisa, as limitações e, por fim, recomenda alguns possíveis trabalhos futuros.

25

2 FUNDAMENTAÇÃO TEÓRICA

“A persistência é o menor caminho do êxito”. (Charles Chaplin). Muito do que é abordado no trabalho se refere a trabalhos existentes na compu-tação autônoma que abrange uma ampla gama de tópicos em sistemas de autogeren-ciamento, incluindo autocura, auto-otimização, autoproteção e autoconfiguração como propriedades.

Este capítulo apresenta os conceitos necessários para o entendimento do conteúdo apresentado nos capítulos seguintes, contextualizando sobre a propriedade da computação autônoma, autocura.

2.1 Complexidade de Software

A crescente complexidade dos ambientes de computação modernos continua a gerar desafios no gerenciamento de sistemas confiáveis e eficientes. Como as infraestruturas partilham requisitos físicos e virtuais multifacetados, as capacidades da administração humana estão a mostrar diminuições na sua eficácia. Isso está aumentando os custos de gerenciamento de sistemas, ao mesmo tempo, introduzindo problemas potenciais como o gerenciamento de mudanças e simples erros humanos (LASTER; OLATUNJI, 2007; SCHNEIDER; BARKER; DOBSON, 2013).

Psaier e Dustdar (2010) destacam que os atuais ambientes de tecnologia da informação em larga escala são composições complexas e heterogêneas, muitas vezes afetadas por comportamentos imprevisíveis e pouca capacidade de gerenciamento. Isso promoveu pesquisas substanciais sobre projetos e técnicas que aprimoram esses sistemas com um comportamento autônomo.

O “design” dos sistemas modernos geralmente resulta em esforço para um controle adequado. Os projetos compreendem componentes heterogêneos, de alta coesão e baixo acoplamento. Da mesma forma, dependências de diferentes tipos de software são inesperadas e muitas vezes afetadas. O dilema tornou-se uma das principais forças motrizes para pesquisa em sistemas de comportamento autônomo. Como resultado da complexidade, Ganek e Corbi (2003), Psaier e Dustdar (2010) reclamam do aumento dos custos de manutenção. Huebscher e McCann (2008), Psaier e Dustdar (2010) descrevem isso como o esforço humano crescente necessário para manter os sistemas operacionais. Salehie e Tahvildari (2005), Psaier e Dustdar (2010) culpam a heterogeneidade, dinamismo e interconectividade em aplicações de software, serviços e redes.

devem fortalecer a capacidade de resposta e a resiliência da prestação de serviços -melhorar a qualidade do serviço - reduzindo o custo total de propriedade (TCO) dos seus ambientes operacionais. No entanto, os componentes de TI produzidos pelas empresas de alta tecnologia nas últimas décadas são tão complexos que os profissionais de TI são desafiados a efetivamente operar uma infraestrutura de TI estável. É a complexidade dos próprios componentes de TI que ajudou a alimentar esse problema. À medida que as redes e os sistemas distribuídos crescem e mudam, as falhas de implantação do sistema, problemas de hardware e software e erros humanos podem dificultar cada vez mais a administração efetiva do sistema. A intervenção humana é necessária para melhorar o desempenho e a capacidade dos componentes em um sistema de TI, elevando os custos globais - mesmo que os custos dos componentes de tecnologia continuem a diminuir (IBM, 2006).

Ganek e Corbi (2003), Psaier e Dustdar (2010) apresentam os fundamentos de sua visão para a computação autônoma em quatro propriedades próprias ligadas a um sistema de autogestão:

• Autoconfiguração: a capacidade de se reajustar “em tempo de execução”; • Autocura: descobre, diagnostica e reage à interrupções;

• Auto-otimização: maximiza a utilização de recursos para atender às necessida-des dos usuários finais;

• Autoproteção: Antecipa, detecta, identifica e se protege de ataques.

2.2 Computação Autônoma

Segundo Gama e Donsez (2014), com sistemas cada vez mais complexos, diferentes comunidades de pesquisa em ciência da computação têm se concentrado em abordagens que podem minimizar a intervenção humana para a manutenção do sistema. Uma dos objetivos a atingir é a redução dos custos de instalação, configuração, ajuste e manutenção de software. Sistemas de autoadaptação ou autoadaptativos (OREIZY et al., 1999 apud GAMA; DONSEZ, 2014) são termos mais genéricos para definir sistemas que empregam mecanismos autônomos que geralmente não envolvem a decisão humana direta.

A Computação Autônoma ajuda a resolver a complexidade usando a tecnologia para gerenciar a tecnologia. O termo autônomo é derivado da biologia humana. O sistema nervoso autônomo monitora seus batimentos cardíacos, verifica seu nível de açúcar no sangue e mantém sua temperatura corporal próxima a 37° C sem nenhum esforço consciente da sua parte. Da mesma forma, as capacidades autônomas auto-gerenciáveis antecipam os requisitos do sistema de informação e resolvem problemas

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 27

com uma intervenção humana mínima. Como resultado, os profissionais de TI, podem se concentrar em tarefas com maior valor para o negócio(IBM, 2006).

A IBM definiu quatro aspectos do sistema autônomo que são: autoconfiguração, autoproteção, autocura e auto-otimização. Ao longo dos anos, houveram adições a esses conjuntos de atributos que são coletivamente conhecidos como atributos auto-* (KEPHART; CHESS, 2003).

IBM (2006) reforça que em um ambiente de autogerenciamento autônomo, os componentes do sistema, desde hardware (como unidades de armazenamento, computadores e servidores) até software (como sistemas operacionais, middleware e aplicativos de negócios), podem incluir funcionalidades de loop de controle embutidas. Embora esses loops de controle consistam nas mesmas partes fundamentais, suas fun-ções podem ser divididas em quatro grandes categorias de loop de controle embutidas. Essas categorias são atributos dos componentes do sistema e são definidas como:

• Autoconfiguração - pode se adaptar dinamicamente a ambientes em mudança Os componentes de autoconfiguração se adaptam dinamicamente às mudanças no ambiente usando políticas fornecidas pelo profissional de TI. Tais mudanças podem incluir a implantação de novos componentes, a remoção de existentes ou mudanças impactantes nas características do sistema. A adaptação dinâmica ajuda a garantir a força contínua e a produtividade da infraestrutura de TI, resultando em crescimento e flexibilidade de negócios.

• Autocura: pode descobrir, diagnosticar e reagir a disrupções. Os componentes de autocura podem detectar falhas no sistema e iniciar ações corretivas base-adas em políticas sem interromper o ambiente de TI. A ação corretiva pode envolver um produto alterando seu próprio estado ou efetuando mudanças em outros componentes no ambiente. O sistema de TI como um todo torna-se mais resiliente porque as operações do dia a dia são menos propensas a falhar. • Auto-otimização: pode monitorar e ajustar recursos automaticamente. Os

com-ponentes de otimização de sistemas podem ajustar-se para atender às neces-sidades do usuário final ou da empresa. As ações de ajuste podem significar recuperar recursos como em resposta a mudanças dinâmicas de trabalho -para melhorar a utilização geral ou garantir que determinadas transações comer-ciais possam ser concluídas em tempo hábil. A auto-otimização ajuda a fornecer um alto padrão de serviço tanto para os usuários finais do sistema como para os clientes de uma empresa.

• Autoproteção: pode antecipar, detectar, identificar e proteger contra ameaças de qualquer lugar. Os componentes autoprotetores podem detectar

comporta-mentos hostis à medida que ocorrem e tomar ações corretivas para se tornarem menos vulneráveis. Os comportamentos hostis podem incluir acesso e uso não autorizados, infecção e proliferação de vírus bem como ataques de negação de serviço. Os recursos de auto-proteção permitem que as empresas apliquem consistentemente políticas de segurança e privacidade.

Quando os componentes do sistema possuem esses atributos é possível auto-matizar as tarefas que os profissionais de TI devem desempenhar hoje para configurar, curar, otimizar e proteger a infraestrutura de TI. O software de gerenciamento de siste-mas, então, pode orquestrar as ações em todo o sistema executadas por esses laços de controle incorporados.

A computação autônoma busca transformar sistemas de computação em auto-gerenciados. Seu objetivo é permitir que os sistemas se autogerenciem para minimizar a necessidade de intervenção humana. Na visão de computação autônoma, os ad-ministradores apenas definem os objetivos em alto nível para os sistemas. Esses objetivos servem para nortear os processos autônomos. Nessas configurações, os administradores podem se concentrar mais na definição de objetivos em alto nível ou políticas(políticas de ação, politicas de metas e políticas com função de utilidade), e não precisar lidar com detalhes técnicos de nível inferior necessários para atingir esses objetivos, já que essas tarefas são agora realizadas pelo sistema autônomo. Além disso, para especificar metas de sistemas em alto nível, os administradores podem empregar conceitos e idiomas específicos do domínio, em vez de ter que traduzir permanentemente esses conceitos em termos específicos de computador em baixo nível conforme figura 2. (LALANDA; MCCANN; DIACONESCU, 2013).

Figura 2 – Autonomic System

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 29

O principal elemento de design da computação autônoma é o elemento autô-nomo que compreende um gerente que possui cinco funções distintas com tarefas individuais: monitoramento, análise, planejamento, execução e conhecimento (IBM, 2006).

Frei et al. (2013) relata que a maioria das propriedades de auto-* pode ser alcançada sob a responsabilidade de uma única entidade autônoma (um gerente) que controla uma hierarquia de outras entidades autônomas. O gerente autônomo consiste em um ciclo central que lida com todos os eventos futuros dentro do sistema. Uma alternativa a essa abordagem centralizada é a computação autônoma descentralizada, onde pessoas interativas e bastante autônomas substituem o gerente.

A IBM definiu uma arquitetura de referência para estruturar gerentes autônomos (KEPHART; CHESS, 2003), geralmente chamado de loop MAPE-K (acrônimo de moni-toramento, análise, planejamento e execução, apoiado por uma base de conhecimento) ou self-healing loop (PSAIER; DUSTDAR, 2010). É uma arquitetura lógica, não um modelo, que define as diferentes atividades a serem executadas para realizar loops autônomos. Está sendo usada cada vez mais para transmitir os conceitos arquitetu-rais de sistemas autônomos e tem a vantagem de ser uma maneira clara de identificar e classificar áreas de foco particular.

Dependendo da complexidade do sistema visado e do grau de autonomia (WEI et al., 2011) são necessários diferentes níveis de conhecimento e raciocínio para conceber o gerenciamento autônomo. Como o conhecimento sobre o sistema e seu contexto é compartilhado entre todas as fases do loop, ele é mostrado como um aspecto transversal. Esta arquitetura, ilustrada pela Figura 3, pode ser utilizada para implementar loops reativos e proativos (LALANDA; MCCANN; DIACONESCU, 2013).

Figura 3 – MAPE-K

Fonte: LALANDA et. al.; 2013. p. 109.

O elemento autônomo compreende um gerente que possui cinco funções distin-tas com tarefas individuais (PSAIER; DUSTDAR, 2010):

• monitoramento: o monitor reúne informações de status do sistema através de sensores e o pré-processa para a tarefa de análise;

• análise: esta entidade determina se as informações monitoradas recebidas devem seguir uma ação designada. Isso geralmente é feito comparando infor-mações de status com os limites específicos do sistema;

• planejamento: um sistema de execução muitas vezes é cheio de dinâmicas específicas da situação. Portanto, é necessária uma implantação precisa e planejada das ações exigidas pela análise;

• execução: apresenta a entidade que executa as partes de planos previamente concebidos no elemento gerenciado;

• conhecimento: representa a base de conhecimento consumida e produzida pelas quatro tarefas mencionadas anteriormente.

A capacidade de diretivas de alto nível é de importância central para o compor-tamento de sistemas autônomos, amplamente dimensionada, para serem convertidas em ações específicas. Isto é alcançado pelo uso de políticas. Uma política é uma representação, em uma forma externa e padrão, dos comportamentos ou restrições desejadas sobre o comportamento. A gestão baseada em políticas de sistemas de informação tem sido um tema de pesquisa ativo há mais de uma década. Para a

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 31

computação autônoma, o foco é específico na autogestão baseada em políticas. Para cobrir a mais ampla gama possível de situações e contextos, permitimos pelo menos três formas de política inter-relacionadas (WHITE et al., 2004) :

• Políticas de ação: No nível mais baixo de especificação são as políticas de ação, que são tipicamente da forma IF (Condição) THEN (Ação), e IF (Tempo de Respota > 2 seg) ENTÃO (Aumentar a participação da CPU em 5%). Um elemento autônomo que emprega políticas de ação deve medir e / ou sintetizar as quantidades indicadas na condição, e deve executar as ações indicadas sempre que a condição for satisfeita.

• Políticas de metas: No próximo nível, elas descrevem as condições a serem al-cançadas sem especificar como alcançá-las, por exemplo “O tempo de resposta não deve exceder 2 segundos”. As políticas de metas são mais poderosas do que as políticas de ação porque um elemento humano ou autônomo pode dar direção a outro elemento sem requerer um conhecimento detalhado do funci-onamento interno desse elemento. Os elementos autônomos que empregam políticas de metas devem possuir capacidades de modelagem ou planejamento suficientes para traduzir objetivos em ações.

• Políticas de função de utilidade: No nível mais alto, elas especificam o desejo relativo de estados alternativos. Isto é conseguido atribuindo um valor numérico ou uma ordem parcial ou total aos possíveis estados. As funções de utilidade são ainda mais poderosas do que as políticas de metas porque determinam automaticamente o objetivo mais valioso em qualquer situação. Os elementos autônomos que empregam políticas de função de utilidade devem ter capaci-dades de modelagem e otimização suficientemente sofisticadas para traduzir funções de utilidade em ações.

A arquitetura lógica MAPE-K afetou profundamente o campo autônomo, forne-cendo uma estrutura para começar com a construção de um sistema autônomo. É uma arquitetura modular que faz sentido para profissionais e combina propriedades como a separação de preocupações ou escalabilidade. As diferentes atividades, definidas em termos bastante abstratos, cuidam de aspectos específicos, bem definidos e comple-mentares. A padronização das interfaces de comunicação dessas atividades, tal como defendida pela IBM (IBM, 2006), permitiria uma integração mais fácil de várias técnicas desenvolvidas por diferentes provedores. A arquitetura também é escalável, uma vez que as atividades podem ser executadas em máquinas diferentes, assumindo que isso está correlacionado com a latência da rede e não afeta a reatividade.

É importante notar que o loop MAPE-K representa uma arquitetura lógica e não se destina a ser implementado literalmente como está em todos os sistemas autônomos. Em vez disso, seu objetivo é indicar as principais funções que um gerente autônomo deve suportar para administrar um sistema e as principais interdependências entre essas funções, isto é, análise dependendo do monitoramento, planejamento em análise, execução em planejamento e tudo em conhecimento. Mostra, também, a maneira como o gerente autônomo interage com recursos gerenciados (através de pontos de contato, sensores e atuadores). Vários projetos e implementações são possíveis para criar essa arquitetura de referência (PSAIER; DUSTDAR, 2010).

Uma arquitetura para computação autônoma deve realizar dois objetivos fun-damentais: primeiro deve descrever as interfaces e os comportamentos externos necessários para tornar autônomo um componente individual, ou seja, autogerenciável. Em segundo lugar, ele deve descrever como compor sistemas desses componentes autônomos de tal forma que o sistema como um todo seja autogerenciável (WHITE et al., 2004).

2.3 Sistemas de Autocura (Self-Healing)

A abordagem de autocura tenta habilitar os sistemas de computação para descobrir, diagnosticar e reparar automaticamente (ou pelo menos mitigar) falhas sem intervenção humana, portanto, é uma abordagem capaz de melhorar a confiabilidade e a autonomia de um sistema de computação (WEI et al., 2011).

Os desafios com o problema de monitoramento são a implementação de forma não intrusiva, os comportamentos do sistema a serem monitorados e o design dos componentes do sistema a serem monitorados. No aspecto de interpretação é impor-tante determinar quando há um problema a ser adaptado; em outras palavras, deve haver um mecanismo para detectar se os comportamentos dos sistema são alterados de forma a afetar o sistema corretamente ou não e como podemos selecionar o método de adaptação para melhorar o sistema. O problema de resolução está preocupado com a eficácia do mecanismo de reparo proposto, o plano de backup se ocorrer um conflito, a melhoria do sistema sem pará-lo, a solução de reparo adequada e, finalmente a fase de adaptação, em que a implementação em tempo real é uma questão vital e o design de um componente do sistema que responde à adaptação em tempo real (AL-ZAWI et al., 2011).

Em face das falhas dos sistemas que, por muitas vezes, são devidas a bugs, por não dispor de tempo para executar diagnósticos necessários e com o propósito de trazer o sistema de volta à disponibilidade imediatamente, a reinicialização é a única solução usada, ao invés de detectar e corrigir a falha quando esta ocorrer (CANDEA et

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 33

al., 2006).

Existem duas abordagens diferentes utilizadas nos sistemas de autocura, os me-canismos de adaptação integrada e externa (GARLAN; SCHMERL, 2002; SCHMERL; GARLAN, 2002):

A) Mecanismo de adaptação integrado: É descrito como uma metodologia ad-hoc por sistema, que é baseada no método tradicional que assume que o sistema a ser modificado está em estado off-line. Neste método, a autoadaptação é implementada internamente com o próprio sistema, portanto é pré-formada e especificada com um sistema específico - o que dificulta a separação e não é fácil de ser modificado. O conhecimento de adaptação resultante é difícil de ser reutilizado em outros sistemas; portanto, a técnica não poderá determinar a verdadeira fonte de erros. Cada vez mais, os sistemas são necessários para trabalhar de forma que não fiquem indisponíveis para atender aos requisitos das novas tecnologias em sistemas de software e hardware nos dias de hoje, onde os recursos em execução podem mudar com frequência.

B) Mecanismo de adaptação externa (controle de circuito fechado): Neste método, o comportamento do sistema é monitorado por componentes externos do sistema em execução. Esses componentes determinam quando o comportamento do sistema está dentro do nível aceitável e quando ele está fora do intervalo desejado. Este método suporta as seguintes características: diferentes modelos podem ser usados; o mecanismo pode ser reutilizado; facilmente alterado, estudado e fundamentado; a infraestrutura de monitoramento e adaptação pode ser compartilhada e permite a validade de qualquer alteração (AL-ZAWI et al., 2011).

Inicialmente os sistemas de autocura foram descritos como capazes de detectar e se recuperar de possíveis falhas, sem a necessidade ou com a mínima intervenção humana (KEPHART; CHESS, 2003). Embora nenhum sistema tenha sido capaz de operar com total autonomia, vários avanços foram feitos para a realização de ambientes de sistemas de informação autogerenciados. Isso ocorreu à medida que os processos evolutivos foram sendo rotineiramente envolvidos com o desenvolvimento e manutenção de estruturas de computação autônoma(IBM, 2006).

Projetos que permitem que os sistemas de software se autorrecuperem de falhas iriam melhorar radicalmente a confiabilidade e consistência da tecnologia no campo. O esforço para garantir esses benefícios originou o conceito de sistemas de autocura. A autocura pode ser definida como a propriedade que permite a um sistema perceber que não está operando corretamente e, sem ou com a mínima intervenção

humana, fazer os ajustes necessários para restaurar a normalidade. Os sistemas de autocura que requerem intervenção humana ou intervenção de um agente externo ao sistema podem ser categorizados como sistemas de autocura assistida. O foco central ou ideia principal é que um sistema de autocura deve se recuperar do estado anormal (ou “debilitado”) e retornar ao estado normal (“saudável”) e funcionar como antes da interrupção(GHOSH et al., 2007).

As estruturas de sistemas de autocura estão surgindo como uma abordagem útil para enfrentar os requisitos de complexidade crescente da gestão de sistemas. Essas estruturas tentam classificar e analisar dados sensoriais para detectar e mitigar, de forma autônoma, falhas. Isso, por sua vez, reduz a necessidade de sistemas para interagir com os administradores humanos, reduzindo os custos operacionais e, idealmente, melhorando as técnicas de mitigação existentes (SCHNEIDER; BARKER; DOBSON, 2013).

Pode-se argumentar que isso é muito geral e altamente similar ao que se espera dos sistemas de tolerância a falhas ou de sobrevivência bem estabelecidos. Os sistemas tolerantes a falhas compreendem técnicas de estabilização e estratégias de replicação como métodos essenciais de recuperação. Portanto, Ghosh et al. (2007) admitem que sistemas de autocura em alguns casos são vistos como subordinados a sistemas tolerantes a falhas. Os sistemas de sobrevivência manipulam comportamentos maliciosos contendo componentes com falha e assegurando os “serviços essenciais” que representam uma configuração de sistema mínima, mas funcional (ELLISON et al., 1999; R; N; H, 1998; M, 2003). Geralmente, o foco da pesquisa de autocura é a recuperação como um processo elaborado. Isso compreende ambos, métodos para estabilizar, substituir, proteger e isolar, mas, essencialmente, estratégias para reparar e prevenir falhas. Ghosh et al. (2007) identifica o aspecto-chave dos sistemas de autocura como informática voltada para a recuperação. Isso também pode ser uma razão, por que algumas das abordagens pesquisadas descrevem a autocura apenas como um método de recuperação aprimorado, por exemplo Akoglu, Sreeramareddy e Josiah (2009), Corsava e Getov (2003). Sterritt (2005) vê os esforços de toda a computação autônoma como um caminho evolutivo e bem elaborado para atingir os objetivos.

O modo de operação das aplicações de autocura é como um processo organi-zado de detecção e isolamento de um componente defeituoso, corrigindo o componente falhado e reintroduzindo o componente fixo ou de substituição no sistema sem qualquer aparente interrupção. O objetivo das propriedades de autocura é apoiar a confiabilidade do sistema, minimizando as interrupções. Além disso, os sistemas de autocura devem poder antecipar conflitos que tentam evitar possíveis falhas (GANEK; CORBI, 2003) .

O motivo para melhorar um sistema com propriedades de autocura é obter disponibilidade contínua que inclui a resiliência contra as adaptações pretendidas e

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 35

necessárias e o comportamento não intencional e arbitrário. As implementações de autocura funcionam através da detecção de interrupções, o diagnóstico de falha na raiz e a obtenção de um “remédio” com uma estratégia de recuperação. Além disso, a precisão da infraestrutura para sensores e atuadores depende da detecção temporária do mau comportamento do sistema. Isso só é possível analisando continuamente os dados detectados e observando os resultados das ações de adaptação necessárias. As políticas possíveis incluem conjuntos simples de instruções dependentes do evento, mas também estimativas ampliadas de IA(Inteligência Artificial) que suportam a re-solução de falhas anteriormente desconhecidas. Um consenso da pesquisa sobre propriedades de autocura é mostrado na Figura 4. Na parte esquerda, as origens das ideias e algumas pesquisas baseadas na autocura são ilustradas e na direita, as propriedades da autocura. (SCHNEIDER; BARKER; DOBSON, 2013).

Figura 4 – Relações e propriedades da pesquisa de autocura

Fonte: Schneider; Barker; Dobson (pag. 5, 2013).

De um modo mais geral, para alcançar a autocura em sistemas de software um estilo arquitetural precisa atender a certos requisitos (MIKIC-RAKIC; MEHTA; MEDVI-DOVIC, 2002), que incluem adaptabilidade, dinamicidade, conscientização, autonomia, robustez, mobilidade e rastreabilidade. Esses requisitos suportam as quatro fases de um ciclo de vida de software autoadaptativo, que consiste em monitorar, planejar

as mudanças necessárias, implementar descrições de mudanças e implementar as mudanças. Quão bem um estilo arquitetural atende aos requisitos de autocura pode ser medido ao longo de cinco características das arquiteturas de software: estrutura externa, regras de topologia, comportamento, interação e fluxo de dados (FREI et al., 2013).

2.4 Síntese do Capítulo

Neste segundo capítulo, foram apresentados os conceitos base como conceito da complexidade de software, computação autônoma e recuperação autônoma.

Conceituou-se a propriedade da autocura e detalhou propriedades e relações com pesquisas no campo.

37

3 TRABALHOS CORRELATOS

“Que os vossos esforços desafiem as impossibilidades, lembrai-vos de que as grandes coisas do homem foram conquistadas do que parecia impossível.”

(Charles Chaplin) O terceiro capítulo da dissertação visa apresentar o estudo sobre os trabalhos relacionados ao tema da presente pesquisa. O capítulo referencia três trabalhos apre-sentando características do trabalho e ao final, apresenta o diferencial da pesquisa, destacando sua contribuição.

3.1 Seleção de Trabalhos

A partir da identificação das características de sistemas de recuperação autô-noma fundamentados nas seções anteriores, buscou-se, baseado em uma revisão ad-hoc (exploratória), trabalhos que disponibilizassem algum artefato, como por exem-plo, uma arquitetura, um modelo, um framework, uma metodologia, um mecanismo ou mesmo uma ferramenta, que utilizasse a abordagem de recuperação autônoma como instrumento principal, a fim de solucionar, ou ao menos minimizar, os desafios observados.

A verificação de trabalhos correlatos partiu de uma consulta realizada em banco de teses e dissertações disponibilizadas pelas universidades, bem como a consulta de periódicos e anais de congressos, como, por exemplo, o da Capes.

Diante da pesquisa realizada, foram analisadas as características e os propósitos de cada um dos trabalhos selecionados, sendo que ao final, foram destacados três(3) trabalhos correlacionados, como apresentado na Tabela 1.

Tabela 1 – Trabalhos correlatos

Trabalho Título Autor(es) Ano Proposta

1 App-Bisect: Autonomous Healing for Microservice-based Apps(SHRIRAM; HANI, 2015) Rajagopalan Shri-ram,Jamjoom Hani 2015 App-Bisect: Recuperação autônoma para aplicações baseadas em microsserviços 2 SHõWA : A Self-Healing Framework for Web-Based Applica-tions(MAGALHÃES; SILVA, 2015) Magalhães. João Paulo,Silva. Luis Moura 2015 Shõwa: Um framework de autocura para aplicações web. 3 Autonomous recovery in componentized Internet applicati-ons(CANDEA et al., 2006) George Candea, Emre Kiciman, Shinichi Kawamoto, Armando Fox 2006 Recuperação autonôma em aplicações de internet componentizadas Fonte: Autor (2017).

3.1.1 Critérios de Inclusão e Exclusão

Para este mapeamento, foram considerados incluídos/excluídos estudos (KIT-CHENHAM, 2010) que:

Inclusão:

• Trabalhos primários;

• Trabalhos mais referenciados; • Fossem disponíveis na internet;

• Tenham sido publicados a partir de 2002;

• Apresentem uma análise ou proposta de utilização de técnicas de recuperação autônoma.

Capítulo 3. TRABALHOS CORRELATOS 39

• Não fossem relacionados ao tema da pergunta de pesquisa; • Não respondem à pergunta de pesquisa;

3.1.2 Estratégia de Pesquisa

Bases de dados utilizadas no estudo: • IEEE Xplore,

• Google acadêmico, • ACM, e

• Capes

String de busca definida:

(’Autonomous recovery’ OR ’Self-Healing’ OR ’Autonomic Computing’ OR ’resili-ence systems’ OR ’adaptive systems’ )

No processo de extração a string de pesquisa foi utilizada separadamente em cada uma delas.

3.1.3 Critérios de Avaliação

Baseado no que foi apresentado nos capítulos anteriores, dando particular importância ao aspecto arquitetural e de infraestrutura adotados por essas soluções, levando em consideração o impacto no tempo médio para reparo e com o propósito de avaliar os trabalhos relacionados, apresentamos a seguir os critérios de avaliação para cada trabalho, considerando “Sim” para aquele que atende, “Não” para aquele que não atende ou atende parcialmente.

1) Estrutura de integração não intrusiva: Disponibiliza interfaces interoperáveis com o sistema gerenciado (elemento gerenciado) de forma que não sejam necessárias alterações no sistema gerenciado. O mínimo de impacto a nível de alterações no sistema gerenciado como também em seu ambiente;

2) Políticas de ações ECA: Possui política baseada em evento-condiçao-ação con-siderando ser menos onerosa quanto a manuntenção de sistemas de informação comparado às políticas de metas e políticas de função de utilidade.

3) Monitoramento por agente: Disponibiliza interfaces de monitoramento do sis-tema gerenciado (elemento gerenciado) para possíveis consultas de estado de recursos, ocorrências de inatividades e estado do elemento;

4) Interfaces de integração: Disponibiliza interface(s) de integraçao para monitorar o componente (gerente autônomo). Oferece formas de consultar e integrar o componente com outros sistemas;

5) Mecanismo de adaptação externa: Disponibiliza interfaces interoperáveis com o sistema gerenciado (elemento gerenciado) que seja reutilizável, de fácil es-tudo e aplicabilidade e onde o comportamento do sistema é monitorado por componentes externos do sistema em execução.

6) Mecanismo de contingência: Dispõe de mecanismo caso o processo de auto-cura não tenha sucesso, comunicando de forma automática um administrador responsável a não conformidade;

7) Caracterísitca(s) da computação autônoma ( autoconfiguraçao, autocura, au-toproteção e auto-otimização): Apresenta pelo menos duas características de autogerenciamento para considerar o sistema como autônomo;

8) Possui loop lógico MAPE-K: Indica as principais funções que um gerente autô-nomo deve suportar para administrar um sistema.

3.2 Trabalho 1 - Aplicações Baseadas em Microsserviços

A abordagem de Microsserviços e DevOps para o design do software resultou em novos recursos de software que são entregues imediatamente aos usuários, em vez de aguardar longos ciclos de atualização. Os erros de software e as regressões de desempenho tornaram-se uma causa importante de tempo de inatividade.

É proposto o app-bisect, uma ferramenta autônoma para solucionar e reparar tais problemas de software em ambientes de produção. A visão é que a evolução dos microsserviços em uma aplicação pode ser capturada como mutações no gráfico das dependências dos microsserviços, de modo que uma versão específica do gráfico do passado possa ser implantada, automaticamente, como medida provisória até que o problema seja permanentemente corrigido. Usando testes e técnicas de roteamento compatíveis com versões do software, descreve como o processo de busca pode ser acelerado para identificar essa versão candidata. Foi apresentando o design geral e os principais desafios para implementar esse sistema.

Foi introduzida a aplicação app-bisect, uma ferramenta de diagnóstico de nível de sistema para reagir a problemas de desempenho que surgem em aplicações de microsserviços. O app-bisect destina-se a operar em modo não supervisionado.

A operação de alto nível do app-bisect é a seguinte: após a ativação, ele testa sistematicamente várias versões passadas dos microsserviços da aplicação, co-implantando-os, juntamente com suas peças do contador da versão atual, até encontrar

Capítulo 3. TRABALHOS CORRELATOS 41

uma combinação onde o problema de desempenho não está presente. Em seguida, descomprime todas as outras versões efetivamente retornando as partes do aplicativo para o passado.

Como um sistema autônomo encarregado de manter o desempenho do apli-cativo, a aplicação app-bisect precisa saber quando reparar um aplicativo e quando não operar no nível do sistema. A aplicação app-bisect permite o conhecimento tanto da implantação do aplicativo quanto da infraestrutura subjacente. Essa visibilidade permite que o app-bisect consiga reparar aplicativos somente quando a questão de desempenho possa ser atribuída ao aplicativo e não à infraestrutura subjacente.

Enquanto o aplicativo web comum se tornou um aplicativo resiliente e distribuído, a complexidade de solução de problemas também se espalhou de uma única máquina para uma implantação que abrange várias máquinas. A aplicação app-bisect é uma tentativa de enfrentar essa complexidade com base em visões futuristas da computação autônoma.

3.3 Trabalho 2 - Aplicações Web

A complexidade dos sistemas é considerada um obstáculo para o progresso da indústria de TI. A computação autônoma é apresentada como a alternativa para lidar com a crescente complexidade. É uma abordagem holística, na qual os sistemas são capazes de configurar, curar, otimizar e se proteger sozinhos. Aplicativos baseados na Web são um exemplo de sistemas onde a complexidade é alta. O número de componentes, sua interoperabilidade e variações da carga de trabalho são fatores que podem levar a falhas de desempenho ou cenários de indisponibilidade. A ocorrência desses cenários afeta a receita e a reputação das empresas que dependem desses tipos de aplicativos. Neste trabalho foi apresentado um framework de autocura para aplicações web chamado Shõwa.

O Shõwa é composto por vários módulos que monitoram a aplicação, analisam os dados para detectar e identificar anomalias e executar ações de recuperação de forma autônoma.

O monitoramento é feito por um pequeno agente de programação orientado a aspectos. Esse agente não requer alterações ao código-fonte do aplicativo e inclui algoritmos adaptativos e seletivos para regular o nível de monitoramento. As anomalias são detectadas e identificadas por meio de correlação estatística. A análise de dados detecta mudanças no tempo de resposta do servidor e analisa se essas alterações estão correlacionadas com a carga de trabalho ou são devido a uma anomalia de desempenho indentificada na própria análise de dados. Após a identificação de anomalias, Shõwa executa um procedimento de recuperação. Também foi apresentado um estudo sobre a

detecção e localização de anomalias, a precisão da análise de dados e o impacto no desempenho induzido por Shõwa. Duas aplicações de benchmarking exercidas através de cargas de trabalho dinâmicas e diferentes tipos de anomalia foram consideradas no estudo. Os resultados revelaram que: a capacidade de Shõwa para detectar e identificar anomalias, enquanto o número de usuários finais afetados, é baixa; Shõwa conseguiu detectar anomalias sem aumentar o alarme falso; e Shõwa não induz uma sobrecarga de desempenho significativa (o throughput foi afetado em menos de 1% e o tempo de resposta não foi superior a 2 milissegundos).

3.4 Trabalho 3 - Aplicações Componentizadas

O trabalho mostra como reduzir o tempo de inatividade de aplicações cons-truídas na plataforma J2EE através da recuperação rápida e automática de falhas de software transitórias e intermitentes, sem necessidade de modificações na aplicação e sem intervenção humana. O protótipo combina três técnicas de aplicação: macroanálise para detecção e localização de falhas, controle de microrebooting para recuperação rápida e gerenciamento externo de ações de recuperação. As técnicas individuais são autônomas e funcionam através de uma ampla gama de aplicativos de internet compostos, tornando-os adequados ao software de serviços de internet em rápida mudança. O framework proposto foi integrado ao JBoss, um servidor de aplicativos J2EE de código aberto. O protótipo fornece uma plataforma de execução que pode recuperar aplicações J2EE automaticamente, em segundos, após a manifestação de uma falha. O sistema pode fornecer aos usuários finais ativos de um sistema a ilusão de tempo de atividade contínua, apesar das falhas que ocorrem nos bastidores, mesmo que não haja redundância funcional no sistema.

O design para recuperação autônoma é ilustrado de forma abstrata na Figura 5. Mais do que simplesmente combinar detecção/localização e recuperação de falhas, foi adicionado uma entidade separada que pudesse ter conhecimento de ponta a ponta do processo de recuperação e fornecer o veículo para implementar uma variedade de políticas - o gerenciador de recuperação.

Capítulo 3. TRABALHOS CORRELATOS 43

Figura 5 – Design da arquitetura para recuperação autônoma

Fonte: CANDEA et. al.; 2013. p.3.

O processo de recuperação autônoma é composto por três etapas: monitora-mento generalizado, detecção e localização genérica de falhas e recuperação genérica. No monitoramento, o sistema que precisa ser recuperado deve ter pontos de monitoramento disseminados (sondas). Os monitores geram observações de baixo nível que são centralizadas em um mecanismo de análise. As sondas de monitoramento são introduzidas no sistema usando várias formas de instrumentação; No trabalho, foi utilizado a interposição aproveitando os recursos de linguagem de Java.

A detecção e localização de falhas trata-se de um mecanismo de análise que correlaciona relatórios de monitoramento entre si e com outras informações para inferir quando o sistema está se comportando de forma anômala. Os relatórios de anomalia contêm uma localização preliminar da falha, listando todos os componentes que estão se comportando de forma anômala. Todos os componentes anômalos relatados podem estar com defeito e se comportar mal ou um componente verdadeiramente defeituoso pode estar causando o mal comportamento de outros.

Na recuperação os relatórios de anomalia são encaminhados para um geren-ciador de recuperação, responsável por interpretar relatórios de anomalia e decidir quais ações, se houver, para executá-las. Uma vez que a ação foi tomada, o gerente de recuperação avalia sua eficácia e decide se são necessárias mais ações. Uma vez que a causa da falha não é conhecida, mas sim apenas a localização, é necessária uma técnica de recuperação universal. No sistema, foi usada, exclusivamente, a recu-peração com base em microreboot porque nos concentramos em falhas transitórias

e intermitentes. O Microreboot reinicia um único componente dentro de um sistema maior, reiniciando seu estado e diminuindo o tempo de resposta para retorno ao estado saudável de um determinado sistema.

3.5 Análise Conjunta

Para evidenciar as principais características em cada um dos trabalhos elenca-dos e da proposta, foram compiladas as particularidades de cada trabalho. O resumo destas características é apresentado no quadro 1.

Quadro 1 – Características trabalhos correlatos e proposta

Fonte: Autor (2017).

Segue uma análise conjunta dos trabalhos relacionados consolidada na tabela 7, onde pode-se destacar as seguintes conclusões:

• Todos os trabalhos apresentam características claras da propriedade de auto-cura, atendendo requisitos de sistemas de autocura como, também, de sistemas de computaçao autônoma;

• Todos os trabalhos apresentam estrutura de integração não intrusiva, não re-querendo alterações no código-fonte ou no ambiente do aplicativo(elemento gerenciado);