UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO ESTUDO DOS RECURSOS DE ALTA DISPONIBILIDADE E IMPLEMENTAÇÃO DE UM MODELO DE PEQUENO PORTE Área de Administração em Informática por Edson Neri Schneider Ovídio Felippe Pereira da Silva Júnior, Dr. Orientador Itajaí (SC), dezembro de 2006

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO ESTUDO DOS RECURSOS DE ALTA DISPONIBILIDADE E IMPLEMENTAÇÃO DE UM MODELO DE PEQUENO PORTE Área de Administração em Informática por Edson Neri Schneider Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Ovídio Felippe Pereira da Silva Jr., Dr. Itajaí (SC), dezembro de 2006

AGRADECIMENTOS Demorou, mas aqui estou escrevendo a última página de uma história de alegrias, tristezas, dedicação e aprendizado. Nesta hora certamente é necessário lembrar de todas as pessoas que durante esse período participaram do desenvolvimento desse trabalho. Aos meus pais, agradeço por terem me apoiado e incentivado desde o início, mesmo estando longe sempre estiveram presentes de alguma forma. Não poderia deixar de agradecer também aos mestres, que emprestaram todo o seu conhecimento e tempo para me auxiliar nos momentos em que eu não sabia mais o que fazer, nem a quem recorrer. Dentre muitas pessoas que dedicaram alguns minutos de suas vidas para me ajudar, não poderia deixar de agradecer a uma em especial. Ela que foi amiga, companheira, namorada, esposa e me dando força nos momentos em que mais precisei, sem dúvida merece todo o agradecimento. Obrigado Nadir. Por fim, a todos aqueles que, de uma forma ou outra, ajudaram para que eu concluísse esse trabalho, deixo aqui o meu muito obrigado. Aos que durante esse período, não ajudaram, porém não atrapalharam, também agradeço por terem me deixado caminhar. Já aqueles que de certa forma, tentaram impedir que eu concluísse esse trabalho, não me resta outra coisa, senão pedir desculpas por tê-los decepcionado, pois... eu consegui. ii

SUMÁRIO LISTA DE ABREVIATURAS...v LISTA DE FIGURAS...vi LISTA DE TABELAS...vii LISTA DE EQUAÇÕES...viii RESUMO...ix ABSTRACT...x 1 INTRODUÇÃO...11 1.1 PROBLEMATIZAÇÃO... 13 1.1.1 Formulação do Problema... 13 1.1.2 Solução Proposta... 13 1.2 OBJETIVOS... 16 1.2.1 Objetivo Geral... 16 1.2.2 Objetivos Específicos... 16 1.3 METODOLOGIA... 16 1.4 ESTRUTURA DO TRABALHO... 17 2 FUNDAMENTAÇÃO TEÓRICA...18 2.1 ALTA DISPONIBILIDADE... 19 2.2 COMPONENTES DE UM AMBIENTE DE ALTA DISPONIBILIDADE 28 2.2.1 Infra-estrutura... 29 2.2.2 Hardware... 30 2.2.3 Software... 32 2.3 TECNOLOGIAS ENVOLVIDAS... 34 2.3.1 Recursos de Discos... 34 2.3.2 Principais Recursos de Storage... 38 2.3.3 Disaster Recovery Plan... 42 2.4 CONSIDERAÇÕES DE UM AMBIENTE COMPUTACIONAL DE PEQUENO PORTE... 46 3 PROJETO...48 3.1 PREMISSAS... 48 3.2 LIMITAÇÕES... 50 3.3 MODELAGEM DO SISTEMA... 52 3.3.1 Requisitos Funcionais... 54 3.3.2 Regras de Negócio... 55 3.3.3 Casos de Uso... 55 3.4 MODELO TRADICIONAL... 61 3.4.1 Descrição da solução... 61 3.4.2 Hardware... 62 iii

3.4.3 Software... 62 3.4.4 Pontos positivos... 64 3.4.5 Pontos negativos... 64 3.4.6 Recomendações atendidas... 65 3.4.7 Considerações Entre o Modelo Tradicional e Uma Solução de Disponibilidade Contínua... 65 3.5 SOLUÇÃO 1 - HEARTBEAT + RSYNC... 67 3.5.1 Descrição da solução... 67 3.5.2 Pontos positivos... 70 3.5.3 Pontos negativos... 70 3.5.4 Recomendações atendidas... 71 3.6 SOLUÇÃO 2 - PROGRAMA + RSYNC... 71 3.6.1 Descrição da solução... 71 3.6.2 Pontos positivos... 76 3.6.3 Pontos negativos... 77 3.6.4 Recomendações atendidas... 77 3.7 SOLUÇÃO 3 - HEARBEAT + DRDB... 78 3.7.1 Apache... 78 3.7.2 Heartbeat... 79 3.7.3 DRBD... 79 3.7.4 Pontos positivos... 82 3.7.5 Pontos negativos... 82 3.7.6 Recomendações atendidas... 83 3.8 ANÁLISE COMPARATIVA... 83 4 CONSIDERAÇÕES FINAIS...86 4.1 CONTRIBUIÇÕES DO PROJETO... 86 4.2 RESULTADOS... 87 4.3 APLICAÇÃO DA SOLUÇÃO NO MERCADO... 88 5 REFERÊNCIAS BIBLIOGRÁFICAS...90 iv

LISTA DE ABREVIATURAS CPD CPU DRP DWDM DRBD FCIP JBOD IBM ICOD IFCP IP I/O LDAP LUN LTO MSCS MTBF MTTR NAS NAT NFS NIS NTP P2P RAID SAN SDH SLA SMS SPOF SSH TCC UML UNIVALI UPS VG TI Centro de Processamento de Dados Central Processing Unit Disaster Recovery Plan Dense Wavelength Division Multiplexing Distributed Replicated Block Device Fibre Channel Over IP Just a Bunch of Disks International Business Machines Instant Capacity on Demand Internet Fibre Channel Protocol Internet Protocol Input/Output Lightweight Directory Access Protocol Logical Unit Number Linear Tape Open Microsoft Cluster Service Mean Time Between Failures Mean Timer do Repair Network Attached Storage Network Address Translation Network File System Network Information Services Network Time Protocol Peer-to-Peer Redundant Array of Independent Disks Storage Area Network Synchronous Digital Hierarchy Service Level Agreement Short Message Service Single Point of Failure Secure Shell Trabalho de Conclusão de Curso Unified Modeling Language Universidade do Vale do Itajaí Uninterruptible Power Supply Volume Group Tecnologia da Informação v

LISTA DE FIGURAS Figura 1. Proposta de Cluster de Servidores...14 Figura 2. Causas da Indisponibilidade...21 Figura 3. Raid 1 Mirroring...37 Figura 4. RAID 5 Striping with distributed parity...37 Figura 5. Visão Geral de um Ambiente de SAN...40 Figura 6. Virtualização de Dados...42 Figura 7. Camada do VMWare...49 Figura 8. Níveis de Alta Disponibilidade...51 Figura 9. Cluster de Servidores com Heartbeat e rsync...53 Figura 10. Requisitos Funcionais...54 Figura 11. Regra de Negócio...55 Figura 12. Casos de Uso...55 Figura 13. Heartbeat e rsync...56 Figura 14. Diagrama de Seqüência - Heartbeat e rsync...57 Figura 15. Programa e rsync...58 Figura 16. Diagrama de Seqüência - Programa e rsync...59 Figura 17. Heartbeat e drbd...60 Figura 18. Diagrama de Seqüência - Heartbeat e drbd...61 Figura 19. Configuração dos servidores com heartbeat e rsync...68 Figura 20. Configuração do arquivo de heartbeat da solução 1...69 Figura 21. Configuração do arquivo de rsync da solução 1...69 Figura 22. Configuração da crontab da solução 1...69 Figura 23. Criação da chave de ssh da solução 1...70 Figura 24. Configuração de rede da solução 2...72 Figura 25. Programa que ativa pacote e faz rsync da solução 2 Parte 1...74 Figura 26. Programa que ativa pacote e faz rsync da solução 2 Parte 2...75 Figura 27. Configuração do arquivo de rsync da solução 2...76 Figura 28. Configuração da crontab da solução 2...76 Figura 29. Criação da chave de ssh da solução 2...76 Figura 30. Configuração do arquivo de heartbeat da solução 3...79 Figura 31. Criação do módulo DRDB - slave...79 Figura 32. Criação do módulo DRDB - master...80 Figura 33. Arquivo drbd.conf...81 Figura 34. Startup do serviço do DRDB...81 vi

LISTA DE TABELAS Tabela 1. Temas do Capítulo 2...18 Tabela 2. Medidas de Disponibilidade...21 Tabela 3. Principais Níveis de Raid...36 Tabela 4. Considerações entre o modelo tradicional e uma solução de disponibilidade contínua...66 Tabela 5. Protocolos DRBD...80 Tabela 6. Análise comparativo entre as soluções...84 vii

LISTA DE EQUAÇÕES Equação 1...22 Equação 2...22 Equação 3...23 viii

RESUMO SCHNEIDER, Edson Neri. Estudo dos Recursos de Alta Disponibilidade e Implementação de um Modelo de Pequeno Porte. Itajaí, 2006. 92 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. A cada dia as empresas dependem mais dos recursos da Tecnologia da Informação, que se fazem presentes em praticamente todos os setores da economia, seja com maior ou menor intensidade, direta ou indiretamente. Ao usuário final e para a organização como um todo, o importante é ter em mãos informações confiáveis e precisas de forma imediata, não importando a estrutura de Informática envolvida nem onde estão os dados. Na tentativa de prover uma solução adequada de disponibilidade de dados para a organização, muitos gestores enfrentam sérios problemas para identificar qual a real necessidade de sua empresa. Este projeto visa descrever os principais componentes de um ambiente computacional para torná-lo de alta disponibilidade, citar as tecnologias envolvidas, as funcionalidades de um storage, abordar o impacto negativo no negócio gerado pela indisponibilidade dos serviços de Informática e descrever as principais arquiteturas de discos. A implementação do projeto consiste em um cluster passivo entre dois servidores com sistema operacional Linux. Caso ocorra algum problema no servidor primário, o servidor secundário deverá prover a disponibilidade da aplicação sem a necessidade de intervenção humana. O desenvolvimento do projeto baseou-se em pesquisas na Internet, manuais de fabricantes de storage e livros específicos sobre o assunto. Palavras-chave: Sistemas Distribuídos. Linux. Storage. ix

ABSTRACT Each day the companies depend more on the resources of the Information Technology, that is present in practically all sectors of the economy, either with greater or minor intensity, directly or indirectly. To the final user and for the organization as a whole, its important to have in hands reliable, precise and immediate information, not importing the structure of the Information Technology involved or where these data are. In the attempt to provide an adequate solution with availability of data for the organization, many managers face serious problems to identify the real necessity of their company. This project aims to describe the main components of a computational environment to turn it of high availability, to cite the involved technologies, the functionalities of a storage, to approach the negative impact in the business generated by the non-availability of the Information Technology services and to describe the disks main architectures. The development of the project consist in a passive cluster among two servers whith Linux Operation System. Case occur any problem whit the primary server, the second server need provide the application availability whitout the human intervention necessity. The development of the project is based on research in the Internet, manuals of storage manufacturers and specific books on the subject. Keywords: Distributed Systems. Linux. Storage. x

1 INTRODUÇÃO Na década de 60, a arquitetura predominante era baseada no mainframe (computador de grande porte), mas a partir de 1990 as empresas passaram a usar um ambiente mais heterogêneo, o que acabou acarretando em maiores custos e dificuldades para administrá-lo. O problema se agravou com o advento dos sistemas cliente/servidor e da Internet. O simples upgrade (atualização para uma versão mais nova) de um sistema operacional passou a ser uma tarefa árdua e demorada. Além disto, ocasionou a má utilização dos recursos uma vez que alguns equipamentos podem estar com recursos sobrando enquanto outros estão sobrecarregados. Conforme pesquisa do International Data Corporation (2005), em função deste novo cenário, destacam-se cinco tipos básicos de consolidação, que tem por objetivo facilitar o gerenciamento do ambiente, segurança, disponibilidade e também redução de custos, quais sejam: Centralização: concentrar os servidores e subsistemas de armazenamento em um local central ou em uma menor quantidade de sites (locais onde ficam instalados os servidores); Consolidação física: reduzir a quantidade de servidores ou storage (dispositivos de armazenamento de dados); Integração dos dados: combinação de dados de diferentes formatos em uma mesma plataforma; Integração de aplicações: consolidação de servidores que suportem diferentes tipos de aplicações; e Consolidação de storage: consolidação de storage em sistemas independentes de servidores, sistemas operacionais ou aplicação. Todo este trabalho é necessário, pois, a cada dia, as empresas dependem mais dos recursos da Tecnologia da Informação, que se fazem presentes em praticamente todos os setores da economia, seja com maior ou menor intensidade, direta ou indiretamente. Desta forma, algumas empresas e organizações dependem da disponibilidade dos seus dados vinte e quatro horas por dia durante os trezentos e sessenta e cinco dias do ano. Uma vez que muitos trabalhos são automatizados, resta ao homem somente a função de administrar as tarefas que as máquinas deverão executar.

Ainda, segundo dados da pesquisa realizada pela Gartner (2003), as paradas não programadas em computadores ou aplicações, devido a problemas de hardware, software ou de ambiente acarretam as seguintes conseqüências: Impactos quantificáveis: Perda de receita: prejuízos financeiros que muitas vezes são irrecuperáveis; Trabalho ocioso: mão-de-obra parada; e Penalidades financeiras: multas por atraso de pagamento. Impactos não quantificáveis: Perda de produtividade: interrompe a operação de linhas de produção e logística; Reputação: imagem da empresa fica prejudicada perante o mercado; Insatisfação dos clientes: gerando perda de negócios e prejuízos financeiros futuros; Perda de credibilidade: ferindo o nome e a marca no mercado; e Risco: para a segurança pessoal dos envolvidos. De acordo com Weygant (1996), um ambiente computacional de alta disponibilidade é uma combinação de componentes de hardware redundantes, sistema operacional e softwares, os quais trabalham em conjunto para minimizar o impacto que uma falha poderia gerar na disponibilidade dos serviços computacionais de uma empresa ou organização. Segundo Laudon e Laudon (1999), dado é qualquer elemento identificado em sua forma bruta que por si só não conduz a uma compreensão de determinado fato e sendo informação o dado trabalhado que permita ao executivo tomar decisões, nada é mais importante para uma organização do que ter seus dados disponíveis a qualquer momento de uma forma rápida e precisa. Este projeto aborda as tecnologias de centralização da informação e consolidação de storage em sistemas independentes de servidores, sistemas operacionais ou aplicação, conforme citado na pesquisa do International Data Corporation (2005). E, de forma complementar, pretende-se implementar um modelo básico de disponibilidade contínua entre dois servidores. 12

1.1 PROBLEMATIZAÇÃO 1.1.1 Formulação do Problema Na tentativa de prover uma solução adequada de disponibilidade de dados para uma organização de pequeno porte, muitos gestores enfrentam sérios problemas para identificar qual a real necessidade de sua empresa. Normalmente, durante a atualização do parque de equipamentos de uma empresa, ou quando ocorre a centralização dos equipamentos surgem muitas dúvidas, principalmente na área de storage e os recursos que o mesmo deverá prover. Outra dúvida que surge é se existe a necessidade de se criar um datacenter backup. Não é de interesse do usuário final saber onde estão seus dados. O que ele precisa, é ter acesso aos mesmos de alguma forma, seja no mesmo prédio onde ele trabalha ou não. Para efeito de implementação de projeto, será considerado um ambiente de pequeno porte. Um ambiente de pequeno porte poderá utilizar a mesma estrutura de componentes de um ambiente de grande porte. O que irá caracterizar o ambiente de pequeno porte serão os componentes envolvidos. Por exemplo, num ambiente de grande porte, possivelmente será usado um switch de alta performance, enquanto no ambiente de pequeno porte, um hub poderá fazer este papel. 1.1.2 Solução Proposta O estudo em questão, visa identificar os principais componentes para prover a redundância de servidores de uma forma genérica. De forma complementar, pretende-se implementar um modelo básico de disponibilidade contínua entre dois servidores, melhor representado na Figura 1. Como conceito de disponibilidade, pretende-se abordar na pesquisa de uma proposta genérica. Porém, a aplicação, deverá ser desenvolvida segundo o ambiente computacional para pequeno a médio porte, pois percebe-se, que os mesmos também já possuem a necessidade de missão crítica conforme a realidade de grandes empresas, de onde provém estes conceitos. 13

` Usuário Master Pacote Slave Figura 1. Proposta de Cluster de Servidores A aplicação a ser implementada ao final do projeto será um modelo passivo, ou seja, em caso de problemas no servidor master, toda a aplicação deverá executar no servidor slave e viceversa. Quando uma máquina falha e outra assume o sistema de forma transparente para o usuário, o processo é chamado de failover. Já o processo oposto é chamado de failback, ou seja, o elemento que falhou retoma seu estado original e é colocado (manual ou automaticamente) de volta para trabalhar. O modelo também será caracterizado como sendo de pequeno porte, tendo em vista as limitações e restrições de recursos disponíveis. Ou seja, não será possível aplicar e demonstrar todos os conceitos e técnicas citadas na fundamentação teórica. A partir de observações e pesquisas prévias, percebe-se que atualmente, a bibliografia a respeito deste assunto é bastante restrita, ficando basicamente limitada a Internet e aos fabricantes de storage que também desenvolvem os softwares de gerenciamento dos mesmos. Ainda como limitação, não está contemplado neste projeto o tema planejamento de capacidade e o resultado do trabalho será a implementação de um ambiente de tendência à disponibilidade contínua, usando-se dois servidores com sistema operacional Linux. 14

O Linux é um sistema operacional que foi criado em 1991 por Linus Torvalds na Universidade de Helsinki na Finlândia. É um sistema operacional de código aberto e distribuído gratuitamente pela Internet. Segundo Filho (2002), desde sua criação, o Linux trouxe muita atenção ao movimento open-source, e à concreta possibilidade de se usar soluções de baixo custo em missões críticas. Nos últimos anos, esta possibilidade tornou-se real com a criação de vários sistemas de alta disponibilidade de código aberto, os quais eram muitas vezes patrocinados por empresas tradicionais. Embora de maneira independente, a participação de comunidades de software livre também colaborou para o desenvolvimento de cluster de servidores utilizando o Linux, e, apesar de existirem algumas soluções no mercado, não existe um padrão formal a seguir. É relevante citar também que embora seja utilizado o Linux Fedora 5 neste projeto, a aplicação servirá para outras plataformas do sistema operacional Linux, uma vez que existe grande portabilidade entre os mesmos. O sistema operacional Linux Fedora 5 foi escolhido, pois, além de gratuito, é um ambiente onde a possibilidade de invasão por vírus é menor e existe uma liberdade maior de se desenvolver aplicações de software livre que serão necessárias para a implementação do modelo desejado. A partir de observações pessoais, identificou-se ainda, que este sistema operacional é bastante difundido e seu código é bastante próximo do sistema operacional Red Hat, cujo código é pago e possui uma ampla estrutura de suporte. Durante o curso de Ciência da Computação, alguns conceitos são estudados nas disciplinas de Sistemas Distribuídos e Redes, mas de forma não muito aprofundada. Considerando a tendência de crescimento destes tipos de tecnologias que logo deverão ter um espaço maior, esta proposta é interessante como TCC (Trabalho de Conclusão de Curso) na medida em que poderá servir como referência de estudos de tecnologias de implementação de alta disponibilidade, ao mesmo tempo, que resultará numa solução para pequenas e médias empresas. 15

1.2 OBJETIVOS 1.2.1 Objetivo Geral O objetivo principal deste trabalho é desenvolver uma proposta de modelo básico de disponibilidade contínua de dados aplicada a um ambiente computacional de pequeno porte. 1.2.2 Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são: Pesquisar conceitos quanto a: componentes de um ambiente computacional de alta disponibilidade, tecnologias envolvidas e funcionalidades de um storage, impacto negativo no negócio gerado pela indisponibilidade dos serviços de Informática e citar as principais tecnologias de discos; Modelar a implementação de uma disponibilidade básica em um ambiente de pequeno porte; Implementar uma estrutura de disponibilidade contínua em laboratório; e Analisar propostas de soluções de disponibilidade de pequeno porte, apresentando suas vantagens e desvantagens. 1.3 Metodologia Este trabalho realizou-se em pesquisas bibliográficas baseadas em livros e artigos técnicos de conceituados autores relacionados com o tema principal, complementados por pesquisas na Internet focalizadas em sites de institutos de pesquisa, renomadas empresas de consultoria e fornecedoras de soluções para ambientes computacionais de alta disponibilidade. O cronograma de pesquisa e elaboração dos documentos deste projeto considerou os requisitos e recursos necessários bem como o prazo de cumprimento do TCC estabelecido pelo Curso. 16

1.4 Estrutura do trabalho Este documento está organizado em quatro capítulos assim distribuídos: Introdução, Fundamentação Teórica, Projeto e Considerações Finais, além do apêndice. O Capítulo 1, Introdução, apresenta uma visão geral do trabalho, e de que maneira o mesmo foi elaborado, bem como cita os principais objetivos traçados no início do projeto. Na Fundamentação Teórica, Capítulo 2, é apresentado uma revisão bibliográfica de autores especialistas a respeito de disponibilidade de dados. Além disto, neste capítulo, são citados os principais recursos de storage, arquiteturas de disco, conceitos a respeito de plano de contingência e, ainda, algumas considerações em relação a um ambiente computacional de pequeno porte. No Capítulo 3, Projeto, é apresentado a modelagem do sistema, que será utilizada na implementação de uma disponibilidade contínua em um ambiente de pequeno porte. No Capítulo 4, são apresentadas as considerações finais do projeto de pesquisa. 17

2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo, é apresentada uma revisão bibliográfica de diversos autores a respeito de alta disponibilidade de dados. São citados os principais recursos de storage, arquiteturas de discos e considerações em relação a um ambiente computacional de pequeno porte. Além disso, são descritos alguns princípios básicos que devem ser atendidos para que se aumente a disponibilidade de dados para a corporação e algumas recomendações para a implementação de um site de contingência de uma forma genérica. Os principais elementos que compõem este capítulo estão descritos na Tabela 1. Tabela 1. Temas do Capítulo 2 Tema Autor Resumo Alta Disponibilidade e princípios básicos Componentes de um ambiente de alta disponibilidade Principais tecnologias envolvidas Considerações de um ambiente de pequeno porte Peter Weigant (1996) Richard Lee (1999) Marcus e Stern (2003) Marcus e Stern (2003), Peter Weigant (1996), IBM (2002), Hewlett Packard (2004) Advanced Computer & Network Corporation (2005) Joni Storck (2004) Por meio de uma revisão bibliográfica, são apresentados os conceitos de disponibilidade e suas fundamentações. Descrição de medidas percentuais de disponibilidade aplicadas em algumas organizações, bem como são citados alguns princípios básicos a serem respeitados para implementar a disponibilidade. Descrição dos principais componentes de alta disponibilidade, separados por infra-estrutura, hardware e software. Nesta seção são descritas as principais arquiteturas de discos, bem como as vantagens e desvantagens de cada arquitetura. Cita-se também, as tecnologias de storage e virtualização de dados, além de algumas observações em relação ao Disaster Recovery Plan. Esta seção apresenta os dados relevantes a serem considerados em um ambiente de disponibilidade contínua de pequeno porte. 18

2.1 ALTA DISPONIBILIDADE Nesta seção, serão revisados os conceitos de disponibilidade, as medidas de disponibilidade, as principais causas da indisponibilidade e também alguns princípios básicos a serem seguidos na implementação de um ambiente de alta disponibilidade. Apesar das expectativas realizadas pelos especialistas nas décadas de 70 e 80 a respeito de que os computadores facilitariam a vida das pessoas e permitiriam que todos tivessem mais tempo para lazer, o que é visto hoje parece ser exatamente o contrário. Os computadores tornaram-se mais rápidos, graças a processadores mais velozes e novas tecnologias implementadas, mas o mundo dos negócios num mercado globalizado parece mover-se ainda mais rápido. De acordo com Storck (2004), com o crescimento e aceitação da Internet como nunca antes visto, as pessoas esperam ser capazes de comprar vestuário ou suprimentos para o escritório via Internet as quatro horas da manhã. E se eles não puderem comprar no site da empresa A, por estar indisponível por algum motivo, certamente comprarão no site da empresa B concorrente. Atualmente os computadores e seus aplicativos necessitam estar operacionais e disponíveis vinte e quatro horas por dia, sete dias por semana. Paradas para manutenção, chamados downtimes não são mais tolerados. Portanto, manter os computadores e aplicativos disponíveis aos seus usuários e possíveis clientes tornou-se uma obrigação às empresas e organizações e com isto surgiu o conceito de ambientes computacionais de alta disponibilidade também chamados de high availability in computer systems. De acordo com Lee (1999), o termo disponível é definido como o tempo que o sistema é capaz de prover serviço aos seus usuários, tecnicamente chamado de uptime. Disponibilidade é expressa na porcentagem que representa a parte do tempo que o sistema fornece um serviço aceitável versus o tempo total que este sistema deveria estar operacional. Em um ano são 8760 horas. Isto significa que todas as paradas para manutenção não programadas, (downtime), devem ser executadas durante o período estipulado no máximo downtime permitido. Complementando, quanto mais alta a porcentagem de disponibilidade menor o tempo permitido para falhas e manutenções neste sistema. 19

De acordo com Weygant (1996), alta disponibilidade caracteriza um sistema projetado para não permitir paradas no serviço através de redução ou gerenciamento de falhas, bem como minimizando o tempo das paradas programadas. Espera-se que serviços importantes como saúde, energia elétrica, telefonia, entre outros estejam altamente disponíveis. E em caso de um blackout, (falta de energia elétrica), por exemplo, deseja-se que a companhia energética aja rapidamente para corrigir o problema, pois falhas de energia não são aceitáveis para a sociedade moderna. Em muitas empresas, a disponibilidade do acesso aos computadores tornou-se tão importante quanto a disponibilidade de energia elétrica. Alta disponibilidade em computação significa usar sistemas computacionais projetados e capazes de operar com o mínimo de tempo de paradas programadas ou não programadas. Segundo Weygant (1996), nota-se que alta disponibilidade não é um valor absoluto. Necessidades diferentes de negócios necessitam de diferentes níveis de alta disponibilidade. Negócios internacionais ou companhias que operam 24 horas por dia podem requerer acesso a sua base de dados em tempo integral. Instituições financeiras devem ser capazes de transferir fundos a qualquer hora do dia ou da noite, sete dias por semana. Por outro lado, alguns negócios no varejo podem requerer os computadores disponíveis somente 18 horas por dia, porém nestas 18 horas necessitam um tempo de resposta do processamento de transações extremamente rápido. Em uma pesquisa realizada pelo Gartner (2003), definiram-se quatro níveis de ambientes de alta disponibilidade, conforme o impacto causado nos negócios gerado por uma parada não programada nos sistemas, sendo: o nível 1 aquele que causa pequenos inconvenientes e tem baixo custo para recuperação das informações; o nível 2 que afeta alguns departamentos importantes da empresa e, consequentemente, terão um custo maior para recuperação dos dados; o nível 3 que implica em perdas financeiras significantes; o nível 4, onde as interrupções do negócio são inaceitáveis e o custo para recuperação dos dados é altíssimo. Pode-se observar, então, que quanto maior o impacto causado no negócio da empresa ou organização ocasionado pela parada do sistema, maior o nível de alta disponibilidade que este sistema necessita e, logicamente, os custos para implementá-lo também serão mais altos. Assim, muitas empresas estão partindo para soluções que atendam os quatro noves, ou seja, disponibilidade de 99,99 % (Tabela 2), que é uma medida intermediária entre necessidade x custo. 20

Tabela 2. Medidas de Disponibilidade % Uptime % Downtime Downtime Ano Downtime por Semana 98 % 2 % 7,3 dias 3 horas e 22 minutos 99 % 1 % 3,65 dias 1 hora e 41 minutos 99,8 % 0,2 % 17 horas e 30 minutos 20 minutos e 10 segundos 99,9 % 0,1 % 8 horas e 45 minutos 10 minutos e 5 segundos 99,99 % 0,01 % 52,5 minutos 1 minuto 99,999 % 0,001 % 5,25 minutos 6 segundos 99,9999 % 0,0001 % 31,5 segundos 0,6 segundos Fonte: Adaptado de Marcus e Stern (2003). Para que uma organização busque a devida disponibilidade, será necessário em primeiro lugar buscar as causas da indisponibilidade. Segundo o livro Blueprints for High Availability, de Marcus e Stern (2003), as principais falhas estão relacionadas a falha de software, falha de hardware, falha humana, falha de rede e desastres naturais (Figura 2). Outros eventos 7% Desastre Natural 8% Falha de Rede 17% Erro Humano 18% Hardware 23% Software 27% 0% 5% 10% 15% 20% 25% 30% Seqüência1 Figura 2. Causas da Indisponibilidade Fonte: Adaptado de Marcus e Stern (2003). 21

Percebe-se na Figura 2, que 50% das causas de indisponibilidade está relacionada a falhas de software e hardware. O tema deste projeto pretende trabalhar justamente nestas questões. De acordo com Weygant (1996), existem algumas fórmulas para calcular a disponibilidade de um ambiente computacional. Em primeiro lugar é preciso saber o tempo de disponibilidade atual do ambiente e para tanto deverá ser usada a fórmula constante na Equação 1. disponibilidade = 100 * total tempo decorrido soma dos tempos inoperantes total tempo decorrido Equação 1 Exemplo da disponibilidade em um ano com parada de 96 horas: ou seja, disponibilidade =100 * 8672-96 8672 disponibilidade = 98,89 % (quanto maior melhor) É importante citar neste contexto de que a disponibilidade de informação não depende apenas de um servidor, de um storage ou de um equipamento de rede. Na verdade, será necessário aplicar esta fórmula a todos os equipamentos. Também é possível se chegar ao tempo médio entre uma falha e outra (MTBF Mean Time Between Failures). Para tanto, será necessário usar a fórmula da Equação 2. MTBF = tempo em operação Número de falhas Equação 2 Exemplo de MTBF de um servidor em um ano com 19 paradas: ou seja, MTBF = 8672 19 MTBF = 456,42 horas (quanto maior melhor) 22