3.1 – Conceitos Fundamentais
Segundo o fórum de disponibilidade de serviços (Service Availability Fórum – SAF ; SAF, 2008 ; HOLLAND, 2002 apud TARKOMA, 2003) um ponto de partida para aplicações baseadas em serviços tem sido alta disponibilidade, o que garante que os sistemas seu tenham seu funcionamento contínuo, colocando a probabilidade de inatividade ou falha abaixo dos limites previstos. Disponibilidade é a medida da probabilidade de um serviço estar disponível em um dado instante (SAF, 2008 ; HAF, 2001). Atualmente, os sistemas que têm um índice de disponibilidade de cinco noves ou 99,999% (Sigma-Five) são chamados altamente disponíveis. Estes sistemas têm menos de cinco minutos de inatividade acumulada por ano.
3.1.1 – Disponibilidade
Disponibilidade é dada em função da confiabilidade, recuperabilidade e redundância (SAF, 2008). A confiabilidade é normalmente expressa em termos de tempo médio entre falhas (MTBF – Mean Time Between Failures). Recuperabilidade nos informa quão rápido o sistema pode ser restabelecido após a ocorrência de falhas, sendo expressa como um tempo médio de reparo (MTTR – Mean Time to Repair). Segundo os Fóruns de disponibilidade de serviços e de Alta Disponibilidade na ausência de qualquer redundância, a disponibilidade é dada pela fórmula (SAF, 2008 ; HAF, 2001):
Disponibilidade = MTBF / (MTBF + MTTR)
Segundo Holland (2002 ; apud TARKOMA, 2003) um dos requisitos-chave para alta disponibilidade é o gerenciamento de redundância. Neste contexto redundância significa que quando um componente da solução, ou serviço de negócio, falha, um serviço duplicado ou uma réplica deve estar disponível e pode continuar o processamento. Gerenciar a redundância de maneira efetiva requer a implementação de uma plataforma de solução com
capacidade de detecção automática de falhas e autoconfiguração. O correto gerenciamento da redundância direciona a solução a um MTTR próximo de zero. Fatores chave para medir o sucesso no gerenciamento de redundância seriam: a quantidade de recursos disponibilizados para que o serviço possa ser rapidamente re-estabelecido; e qual a velocidade que esta operação acontece (TARKOMA, 2003).
De acordo com O’Brien et al (2005), disponibilidade pode ser definida como a proporção de tempo que um sistema ou componente está operacional e acessível quando seu uso se faz necessário. A disponibilidade de serviços nas perspectivas do usuário e do provedor é uma preocupação para o sucesso de implementação de uma arquitetura SOA.
Na perspectiva do usuário do serviço, se o mesmo não estiver disponível (mesmo que momentaneamente), o sistema não atinge seus requerimentos funcionais de forma bem sucedida. Na perspectiva do provedor do serviço, para que o serviço possa ser utilizado (pelo qual o provedor pode receber compensação financeira), ele tem que estar disponível quando necessário. Se assim não for, o tempo no qual o sistema estiver inoperante poderá afetar a reputação e as finanças do provedor (O’BRIEN et al, 2005).
De acordo com o ITIL, podemos definir disponibilidade como sendo a habilidade de um serviço de aplicação ou componente de executar suas funções em dado instante ou em dado período de tempo (ITIL, 2003).
Disponibilidade (ou mesmo indisponibilidade) é um indicador crucial da qualidade do serviço percebida pelos usuários e pelos negócios, sendo enfatizada pela confiabilidade e manutenibilidade dos serviços.
Resumindo, a Disponibilidade dos Serviços depende de: • Disponibilidade de componentes
• Poder de recuperação contra eventuais erros
• Qualidade da manutenção e assistência
• Qualidade, padrão e extensão do desenvolvimento de processos e procedimentos operacionais
Um serviço crítico que consistentemente atinge os objetivos de disponibilidade tem como características a pequena freqüência de erros e a rápida retomada dos serviços após a ocorrência de algum incidente.
3.1.2 – Continuidade de Serviço
O Fórum de Alta Disponibilidade (HAF, 2001) coloca que a alta disponibilidade é vista como um requisito básico para continuidade do processamento, porém quando um componente falha, uma cópia redundante é utilizada e o serviço é rapidamente re- estabelecido, porém o que ocorre com as sessões ativas de usuários? O sistema deve assegurar que não apenas os componentes de hardware, mas os serviços sejam executados sem interrupção. Portanto torna-se necessária uma solução de software que preserve os dados e as sessões ativas de usuário dentro do cenário de falha de serviços. Continuidade de serviços significa que sessões de usuário são mantidas em execução mesmo que um de seus componentes apresente falha, ou seja, se mantém em execução durante o processo de mudança de cenário num ambiente redundante (TARKOMA, 2003).
Indiferente a um processo de rápida evolução da tecnologia computacional, tanto o hardware como o software estão sujeitos a inúmeras condições de falha. Empregando métodos para minimizar a exposição dos serviços das aplicações a este grande conjunto de condições de falhas, poderemos aumentar significativamente a utilização dos recursos computacionais da empresa. A disponibilidade contínua destes serviços pode tornar-se um importante indicador na avaliação de desempenho das organizações (REL_HA, 2008).
Atualmente as empresas demandam que sistemas automatizados apresentem o "Tamanho Correto (Right Sized)” visando uma implantação mais rápida, proporcionando uma redução dos custos de propriedade (TCO – Total Cost of Ownership), promovendo uma diminuição dos custos com suporte e manutenção e aumentando o suporte a sistemas distribuídos em múltiplas plataformas. Os conceitos de Data Warehouses e replicação de serviços, fornecem mecanismos para garantir que a informação correta esteja disponível para o nível corporativo-executivo em momentos de alta criticidade negocial (REL_HA, 2008).
Esta nova forma de operação deve ser baseada em serviços que sejam constantemente monitorados, medidos e otimizados, sendo capazes de fornecer uma plataforma de componentes (serviços) confiáveis e precisos.
Visando um melhor esclarecimento na definição de termos importantes relacionados ao tema de Alta Disponibilidade, são colocados abaixo à formalização de alguns destes termos segundo ITIL (ITIL, 2003):
3.1.3 – Indisponibilidade
Segundo framework de governança ITIL (2003), os custos totais de um serviço de aplicação essencial são influenciados pelos níveis de disponibilidade requeridos e os investimentos demandados em tecnologia, além dos serviços fornecidos pela organização para atingi-los. A disponibilidade não é algo que se alcança gratuitamente.
Entretanto, é importante considerarmos que a indisponibilidade também tem seu custo. Para sistemas altamente sensíveis, é necessário considerar não apenas o custo do fornecimento do serviço, como também os custos decorrentes de falhas. O balanço ótimo a se perseguir é aquele entre o custo da disponibilidade comparados com os custos da indisponibilidade.
3.1.4 – Gestão de Disponibilidade
Segundo ITIL, o termo Gestão de Disponibilidade pode ser definido como um processo que requer pessoal e infra-estrutura para uma bem sucedida implementação e execução. Uma organização pode optar por delegar esta responsabilidade a um só indivíduo, a uma função organizacional ou terá papéis e responsabilidades associados ao processo delegado a múltiplas áreas organizacionais.
Os avanços contínuos em design de TI vêm resultando em melhorias significativas na disponibilidade e confiabilidade na estrutura de TI. Características de design de software e hardware que toleram erros e os corrigem reduzem os riscos de falha no componente de TI e, desta forma melhoram os níveis de disponibilidade. Entretanto, apesar de atingirmos melhores níveis confiabilidade, a necessidade de gerenciamento da disponibilidade é ainda crescente (ITIL, 2003).
Porque necessitamos de Gestão de Disponibilidade ?
O capítulo de Entrega de Software (Software Delivery ; ITIL, 2003) do framework ITIL defende que a disponibilidade de TI é um fator fundamental para o sucesso do negócio. Durante os últimos anos a interdependência entre o processo empresarial e a operação de TI atingiu níveis críticos onde, uma indisponibilidade de TI significa impacto direto no negócio.
Esta importância de suporte às atividades empresariais também deveria ser vista no contexto das tendências que afetam a sociedade, como, por exemplo, economia global funcionando 24 horas, e-Commerce, funcionamento flexível, mercados sob demanda específica e respostas rápidas para exigências empresariais novas. Estes fatores são o ímpeto para uma demanda crescente de Disponibilidade de alguns serviços de aplicação empresariais críticos e independentes de tempo e lugar. Isto é comprovado pelo aparecimento de serviços de negócios on-line pela Internet, quer seja empresa-empresa quer seja empresa-consumidor. Estes são vistos agora como essenciais já que o objetivo empresarial não é apenas o de conseguir novos clientes, mas também de reter os clientes existentes (ITIL, 2003).
No mercado competitivo de hoje em dia, a satisfação do cliente com o serviço ofertado é essencial. A lealdade do cliente não pode mais ser considerada garantida e alguma insatisfação com a disponibilidade e confiabilidade do serviço pode ser um fator chave para que clientes levem seus negócios a um competidor (ITIL, 2003).
O papel de TI é, portanto, crucial. A disponibilidade e confiabilidade de TI podem influenciar a satisfação de cliente e a reputação do negócio diretamente. É por esta razão que as organizações necessitam um gerenciamento da disponibilidade, assegurando que a área de TI entregue níveis satisfatórios de serviços requeridos pelo negócio e exigidos por seus clientes (ITIL, 2003).
3.1.5 - Meta de Gerenciamento de Disponibilidade
De acordo com Framework ITIL (2003), a meta do processo de Gerenciamento de Disponibilidade é aperfeiçoar a capacidade de Infra-estrutura em TI, serviços e organização de suporte para oferecer níveis de disponibilidade contínuos a custo aceitável, permitindo à empresa satisfazer seus objetivos de negócio.
Isto é alcançado determinando as exigências de Disponibilidade do negócio e emparelhando estas à capacidade de infra-estrutura em TI e organização de suporte. Onde há desigualdade entre a exigência e a capacidade, o gerenciamento de disponibilidade deve proporcionar ao cliente alternativas disponíveis e opções de custo associadas (ITIL, 2003).
O gerenciamento de disponibilidade deve assegurar que o nível exigido de Disponibilidade seja fornecido. A mensuração e monitoração de Disponibilidade de TI é uma atividade fundamental para assegurar que os níveis de disponibilidade estão sendo alcançados de forma consistente. O Gerenciamento de disponibilidade deve aperfeiçoar continuamente a Disponibilidade de Infra-estrutura em TI, serviços e organização de suporte para oferecer melhorias efetivas de Disponibilidade, a custo aceitável, gerando benefícios comprovados tanto para a empresa quanto para usuários (ITIL, 2003).
Os objetivos do processo de Gerenciamento de Disponibilidade são:
• Assegurar que serviços de TI sejam projetados para garantir que os níveis de Disponibilidade requeridos pelo negócio sejam alcançados;
• Prover uma gama de relatórios acerca de disponibilidade de TI que assegurem que níveis de Disponibilidade, confiabilidade e manutenibilidade contratadas estão sendo medidas e monitoradas continuamente;
• Otimizar a disponibilidade de infra-estrutura em TI para oferecer melhorias efetivas, a custo aceitável, que gerem benefícios tangíveis ao negócio e ao usuário;
• Alcançar durante um certo tempo uma redução na freqüência e duração de Incidentes que afetem a Disponibilidade de TI;
• Assegurar que déficits em Disponibilidade sejam reconhecidos e ações corretivas apropriadas sejam identificadas e implementadas;
• Criar e manter um Plano de Disponibilidade com o objetivo de melhorar a Disponibilidade global de TI e componentes de infra-estrutura para assegurar que negócios atuais e futuros tenham suas exigências de Disponibilidade satisfeitas.
3.1.6 - Escopo da Gestão de Disponibilidade
De acordo com ITIL (2003) em seu capitulo de Entrega de Serviços (Service
Delivery), o gerenciamento de disponibilidade está relacionado com o design, implementação, mensuração e gerenciamento de serviço de disponibilidade em aplicações críticas para assegurar que as exigências empresariais em Disponibilidade sejam alcançadas consistentemente e, desta forma podemos dizer que o Gerenciamento de disponibilidade:
• Deve ser aplicado em todos novos serviços de TI e para serviços existentes onde Requerimentos de Nível de Serviço (SLRs) ou Acordos de Nível de Serviço (SLAs) foram estabelecidos (ITIL, 2003);
• Pode ser aplicado a serviços de TI considerados críticos para a organização com SLAs formalmente descritos (ITIL, 2003);
• Deveria ser aplicado aos provedores (interno e externo) que formam a organização de apoio de TI, como um precursor para a criação de um SLA formal (ITIL, 2003);
• Considera todos os aspectos da infra-estrutura de serviços e organização de suporte que podem impactar a Disponibilidade, inclusive treinamento, habilidades, diretrizes, efetividade de processo, procedimentos e ferramentas (ITIL, 2003).
3.1.7 - Confiabilidade
A confiabilidade de um serviço pode ser definida qualitativamente como a falta de falhas operacionais, sendo determinada por:
• Confiabilidade de cada componente pode ser medida de acordo com o número de vezes que o mesmo não execute suas funções exigidas. Esta métrica pode ser medida baseada na norma ISO/IEC 9126-2 (2002) por meio do atributo MTBF, como detalhado no Quadro 11.
• Nível de recuperação do serviço projetado e inserido em sua infra- estrutura (outros serviços), como por exemplo, habilidade de uma falha no serviço ser contornada para permitir a continuação de suas operações empresariais normais. Esta métrica pode ser mensurada com base na norma ISO/IEC 9126-2 (2002) por meio do atributo MTTR, como descrito no Quadro 11.
3.1.8 – Redundância
Uma visão convencional de sistemas altamente disponíveis passa por algumas características básicas:
• Configuração de componentes redundantes;
• Técnicas de redirecionamento dinâmico de carga e fluxo de trabalho;
• Ausências programadas de sistemas (Scheduled Outages);
• Diminuição ou mesmo eliminação de interferência humana na operação dos sistemas;
Dentre estas características o uso de componentes redundantes são aqueles que eliminam de forma bastante eficaz os pontos únicos de falha (SPOF – Single Points of Failure
– Ver 3.1.13 - Pontos Únicos de Falha - Single Points of Failure – SPOF) permitindo assim que componentes independentes possam assumir dinamicamente o processamento de acordo com a necessidade.
Redirecionamento dinâmico de Hardware e Software é o mecanismo que fornece a capacidade de um componente (serviço) independente assumir o lugar do componente que apresentou falha, sem que haja impacto para o usuário final.
Planejando a redundância
Planejamento de redundância significa analisar, avaliar e executar a duplicação de vários componentes da solução, tanto Hardware como Software até que todos os pontos únicos de falha (Ver 3.1.13 - Pontos Únicos de Falha - Single Points of Failure – SPOF) sejam eliminados. Componentes redundantes são mais freqüentemente utilizados em sistemas computacionais de alta performance, porém a duplicação pode ser feita em sistemas de software. Para este fim, deve ser construída uma arquitetura com previsão de redundância, serviços de clusterização de servidores, que suportam aplicações críticas, técnicas de redirecionamento de carga de aplicativos (switching) e replicação automática de dados são técnicas utilizadas para eliminação de pontos únicos de falha em software.
Thomas Erl (2008) reforça que a arquitetura SOA apresenta características importantes neste cenário tendo em vista a natureza agnóstica de seus componentes (serviços)
transformando-os em unidades funcionais independentes capazes de serem tratadas de forma individualizada. Estes são alguns aspectos que diferenciam a Governança de serviços (SOA) das técnicas tradicionais de governança de TI trazendo a necessidade de novo alinhamento e planejamento organizacional de TI. O planejamento, modelagem e construção da arquitetura de execução devem ser feitos com base em serviços e não mais levando em consideração aplicações de forma monolítica. No item 2.2 – Governança em SOA, são descritos com maiores detalhes alguns fatores de governança em SOA (ERL, 2008 ; HENDERSON e VENKATRAMAN, 1999 ; CARTER, 2007).
3.1.9 - Manutenibilidade
A Manutenibilidade está relacionada à habilidade de um serviço de aplicação ou componente ser mantido em um estado operacional. A Manutenibilidade de um componente de Infra-estrutura de TI pode ser dividida em 7 estágios distintos:
• Antecipação de falhas.
• Descoberta de falhas.
• Diagnóstico de falhas
• Solução das falhas.
• Recuperação de falhas.
• Restauração dos dados e do serviço de TI.
• Níveis de manutenção preventiva, utilizados para evitar a ocorrência de falhas.
Atributos pertencentes à norma ISO/IEC 9126-2 (2002) podem ser utilizados para medição da manutenibilidade de um serviço, como descrito no Quadro 11.
3.1.10 - Níveis de Serviço
O Nível de Serviço (Serviceability) descreve os arranjos contratuais (SLA -
Service Level Agreements) feitos com provedores de Serviço de TI terceirizados, como por
exemplo o Gerenciamento de instalações. O objetivo é assegurar a confiabilidade e manutenibilidade de serviços de TI sob sua responsabilidade (ITIL, 2003).
É importante reconhecer que o Nível de Serviço em si mesmo não pode ser medido como uma métrica específica, na verdade a disponibilidade, confiabilidade, manutenibilidade do serviço de TI e os componentes sob sua responsabilidade que devem ser medidos.
3.1.11 - Disponibilidade de Sistemas Críticos
A Disponibilidade de serviços de informação críticos em sistemas críticos é afetada pelos tempos de inoperância do(s) serviço(s) ou do(s) sistema(s), agendados ou não. Embora algum tempo de inoperância agendado para manutenção e atualização de sistema seja inevitável, eles são fatais para serviços que não possam ser interrompidos. Além disso, tempos de manutenção não agendados são imprevisíveis e devem ser evitados. Erros humanos, falhas no sistema operacional, de hardware e de rede normalmente são a causa da maioria destas interrupções não programadas (REL_HA, 2008).
Para descrever os métodos para evitar essas falhas, precisamos entender algumas definições relativas aos níveis de disponibilidade, como também alguns mecanismos de melhoria da disponibilidade baseados em ontologias:
♦ Sistemas de Disponibilidade Normal (NAS)
Sistemas de disponibilidade normais são definidos como sistemas de hardware e software de uso geral que não têm nenhuma redundância de hardware ou otimização de software para recuperar falhas no processamento. Eles exigem intervenção manual, para identificar e corrigir/reparar o(s) componente(s) defeituoso(s) e reiniciar o sistema antes da retomada das operações normais. Esta característica está de acordo com os elementos fundamentais apresentados na definição da norma ISO / IEC 9126 podendo ser classificados como fatores externos de qualidade de produtos (REL_HA, 2008).
♦ Sistema de Alta Disponibilidade (High Availability)
Sistemas de alta disponibilidade podem ser definidos como NAS livremente associados a componentes de hardware redundantes administrados por softwares que detectam falhas e utilizam procedimentos de correção para maximizar a disponibilidade dos serviços críticos e aplicações gerenciados por aquele sistema. Estes sistemas não exigem nenhuma intervenção manual na identificação do componente defeituoso, na execução de
procedimentos para evitar falhas no sistema e em sua notificação. Esta configuração minimiza a possibilidade de perda imediata de dados e interrupção nos serviços. Esta característica está de acordo com os elementos fundamentais apresentados na definição da norma ISO / IEC 9126 podendo ser classificados como fatores externos de qualidade de produtos (REL_HA, 2008).
♦ Modelos de Alta Disponibilidade
Há dois modelos distintos de Alta Disponibilidade para arquiteturas cliente- servidor. Eles são o Modelo de Replicação de Serviços e o Modelo de Prevenção a Falhas
(Failover ; REL_HA, 2008).
a) Modelo de Replicação de Serviços
Este modelo utiliza componentes e serviços de aplicações distribuídas instalados em servidores múltiplos em ambiente LAN/WAN onde são replicados serviços empresariais (componentes) a alguns ou todos os servidores. Quando um fracasso de servidor acontece, aquele serviço ou aplicação específicos podem ser iniciados a partir de um servidor alternativo (REL_HA, 2008).
b) Modelo de Prevenção a Falhas (Failover Model)
Este modelo utiliza configurações de hardware de servidor duplicadas nas quais um servidor tem o papel ativo para dados e serviços de aplicação, enquanto o outro funciona como backup monitorando o estado do servidor ativo. Quando o servidor backup descobre um defeito no hardware ou software ocorrido no servidor ativo, assume o papel e identidade do mesmo (REL_HA, 2008).
♦ Modelo de Tolerância a falhas
Tolerância a falhas pode ser definida como um dispendioso ambiente de sistemas duplicados e altamente integrados. Ao sistema operacional são agregadas capacidades que controlam as falhas, tornando-se funções do mesmo. Estes sistemas têm resposta espontânea e completamente automática às falhas do sistema e provêem serviços ininterruptamente (REL_HA, 2008).
♦ Modelo RATIONALE com uso de Ontologias
Segundo Gannod et al (2007), para melhorar disponibilidade, provedores de serviço de ٛ Internet podem usar as mesmas técnicas em geral utilizadas para aplicações Web. Uma topologia de infra-estrutura que envolve réplica e balanceamento de carga é uma solução comum. O arquiteto deveria projetar serviços sem estado (stateless), já que é mais simples fazer réplicas a um serviço disponível em um cluster quando o serviço não apresentar estado. Além disso, usuários de serviço que dependem de serviços específicos que estejam disponíveis têm que ter contingências embutidas, no caso dos serviços ficarem indisponíveis. Por exemplo, a aplicação poderia achar um provedor alternativo para um serviço.
Ainda há problemas a serem tratados relativos a mecanismos de contingenciamento que devem estar disponíveis e quando é mais apropriado usá-los dentro de um sistema. É necessário que ainda sejam realizados trabalhos de pesquisa adicionais, como também em mecanismos de monitoração e escala em sistemas baseados em SOA, especialmente em como estes podem ser automatizados dentro de uma arquitetura orientada a serviços (GANNOD et al, 2007).
Em lugar de ser uma descrição estática, RATIONALE, de acordo com GANNOD et al (2007), descreve as tomadas de decisões, as alternativas consideradas e as razões a favor e contra estas alternativas. Muito do trabalho em RATIONALE foi focalizado em atividades de design, particularmente nos campos de criar design de engenharia e interação humana (LEE, 1997 apud GANNOD et al, 2007) com computadores (HCI) (MORAN et al, 1995 apud GANNOD et al, 2007). Também houve trabalho significante feito usando RATIONALE para desenvolvimento de software (DUTOIT et al, 2006 apud GANNOD et al, 2007).
Segundo Gannod et al (2007) uma maneira de captar o impacto de qualidade e de atributos e suas dependências na fase de projeto seria por meio do uso de RATIONALE. O projeto RATIONALE de um sistema de software descreve as decisões que foram tomadas, as