Alta Disponibilidade de Serviços de Rede

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO Alta Disponibilidade de Serviços de Rede Daniel Campos dos Santos Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação Orientador: Prof. Dr. João Bosco da Mota Alves Florianópolis - SC 2004

2 Daniel Campos dos Santos Alta Disponibilidade de Serviços de Rede Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação. Orientador: João Bosco da Mota Alves, Dr. Banca Examinadora João Candido Dovicchi, Dr. Luiz Fernando Jacintho Maia, Dr. 2

3 SUMÁRIO LISTA DE FIGURAS... 4 LISTA DE TABELAS... 4 LISTA DE REDUÇÕES... 5 RESUMO INTRODUÇÃO Objetivo Geral Objetivo específico Técnicas e Ferramentas TOLERÂNCIA A FALHAS Falha, erro, defeito Conceitos ALTA DISPONIBILIDADE Medição de Disponibilidade Clusters Clusters de Alta Disponibilidade Reconfiguração Dinâmica Mascaramento de Falhas Sincronização de Dados REDUNDÂNCIA DE GATEWAYS O Protocolo ARP Endereçamento Multicast Protocolo UDP VRRP Heartbeat FailSafe BALANCEAMENTO DE CARGA EM SERVIDORES Acesso baseado no DNS Algoritmos com TTL constante Algoritmos com TTL variados dinamicamente Distribuidor Concentrado (Dispatcher) Dispatcher em um único caminho Dispatcher em mão dupla Dispatcher de pacotes pelo endereço físico Redirecionamento HTTP Distribuição com base no Servidor AMBIENTE DE ALTA DISPONIBILIDADE CONCLUSÃO REFERÊNCIAS BIBLIOGRAFICAS ANEXO Anexo I Artigo

4 LISTA DE FIGURAS FIGURA 1 - MODELO DE 3 UNIVERSOS FIGURA 2 MASC. HIERÁRQUICO PARA SERVIÇOS FIGURA 3 - MASC. HIERÁRQUICO PARA ACESSO A INTERNET FIGURA 4 - MASCARAMENTO POR GRUPOS FIGURA 5 - PROTOCOLO ARP FIGURA 6 - VRRP COM UM ROTEADOR VIRTUAL FIGURA 7 - VRRP COM DOIS ROTEADORES VIRTUAIS FIGURA 8 - BALANCEAMENTO BASEADO NO DNS FIGURA 9 - DISTRIBUIDOR EM CAMINHO ÚNICO FIGURA 10 - DISTRIBUIDOR EM MÃO DUPLA FIGURA 11 - REDIRECIONAMENTO HTTP FIGURA 12 - AMBIENTE HA LISTA DE TABELAS TABELA 1 - EXEMPLOS DE ENDEREÇOS MULTICAST RESERVADOS

5 LISTA DE REDUÇÕES ARP Address Resolution Protocol BSD Berkeley Software Distribution *BSD Versões do Berkeley UNIX HA High Availability IP Internet Protocol MAC Media Access Control TCP Transmission Control Protocol UDP User Datagram Protocol VRRP Virtual Router Redundancy Protocol HTTP Hypertext Transfer Protocol TTL Time to Live DNS Domain Name Service URL Uniform Resource Locator DMZ Demilitarized Zone SPOF Single Point of Failures RAID Redundant Array of Independent Disks CARP Common Address Redundancy Protocol Web World Wide Web 5

6 RESUMO A plataforma de computação mais utilizada hoje em dia são as redes locais. O fato de um servidor parar de funcionar pode prejudicar a produtividade de toda uma organização, principalmente se esse servidor for o único disponível e se estiver executando serviços importantes. Alta disponibilidade é uma área que tem como principal objetivo trabalhar na tentativa de garantir que os sistemas permaneçam confiáveis e disponíveis. Sistemas redundantes e alta disponibilidade são utilizados por empresas e profissionais de tecnologia da informação para denotar sistemas que podem mascarar a ocorrência e falhas. Cluster é a arquitetura ideal para o fornecimento de serviços altamente disponíveis. Neste trabalho são estudados mecanismos e esquemas que compõe o comportamento dos clusters de alta disponibilidade e de balanceamento de carga. 6

7 1 INTRODUÇÃO Não podemos evitar as falhas, mas as suas conseqüências, ou seja, a interrupção no fornecimento do serviço, a perda de dados e o colapso do sistema, podem ser evitadas pelo uso adequado de técnicas possíveis de ser implantadas. Até pouco tempo, a preocupação em relação a falhas era exclusividade de desenvolvedores de sistemas críticos como aeroespaciais e de tempo real. A popularização de redes fornecendo os mais variados serviços aumentou a dependência de uma grande parcela da população aos serviços oferecidos. Falhas nesses serviços podem ter conseqüências muito ruins para a população ou para a credibilidade das empresas. As redes locais passaram a ser, nos últimos tempos, a plataforma de computação mais utilizada nas organizações. A queda de um servidor pode comprometer a produtividade de toda uma empresa, principalmente se esse servidor for o único disponível ou se estiver executando serviços importantes. Na evolução dos computadores, o crescimento na confiabilidade dos componentes de hardware é uma realidade. Entretanto, os sistemas operacionais estão se tornando cada vez mais complexos e apresentando cada vez mais problemas. Só a confiabilidade dos componentes de hardware não garante mais a qualidade e segurança desejada aos sistemas de computação. 7

8 Disponibilidade é o conceito mais aplicado em sistemas de missão crítica. Servidores de rede e de banco de dados são exemplos de sistemas que requerem alta disponibilidade. Alta disponibilidade é um ramo de uma área maior, chamada tolerância a falhas, que tem com principal objetivo trabalhar na tentativa de garantir que os sistemas permaneçam confiáveis e disponíveis. 8

9 1.1 Objetivo Geral O objetivo geral deste trabalho é propor uma estrutura de alta disponibilidade para provimento de serviços em sistema operacional da família *BSD. 1.2 Objetivo específico Este projeto visa realizar: Estudo de técnicas para alta disponibilidade de serviços de rede, bem como de ferramentas disponíveis para este propósito. Definição de uma estrutura para alta disponibilidade de serviços na plataforma OpenBSD [9]. 1.3 Técnicas e Ferramentas Os testes de ferramentas para HA serão feitos utilizando-se Sistemas Operacionais baseados em UNIX, mas especificamente da família *BSD, por serem sistemas de excelente performance, de maneira geral, e com características de segurança e compatibilidade não encontradas em outros sistemas operacionais. 9

10 2 TOLERÂNCIA A FALHAS Está capítulo apresenta conceitos básicos de tolerância a falhas publicados em [1]. 2.1 Falha, erro, defeito Defeito é definido com um desvio da especificação. Pode-se definir que um sistema está em estado de erro se o processamento posterior a partir desse estado pode levar a um defeito. Falha é a causa física ou algorítmica do erro. Falhas estão relacionadas ao universo físico. Uma interferência eletromagnética, ou um chip de memória com falha podem provocar uma interpretação errada da informação e o sistema operacional, de um servidor, travar (erro no universo da informação), como resultado a rede de uma empresa pode ficar sem acesso a internet (defeito no universo do usuário). Nem sempre uma falha leva a um erro. A falha em uma das interfaces de rede de um servidor pode não levar a um erro se ela não estiver sendo utilizada. E um erro não necessariamente provoca um defeito. No exemplo, o acesso à internet da empresa pode ser feito por outros equipamentos, sem interrupção aparente. Os conceitos de falha, erro e defeito podem ser mais bem exemplificados usando-se um modelo de 3 universos, como mostra a figura 1. 10

11 Figura 1 - Modelo de 3 universos Define-se latência de falha como o período de tempo desde a ocorrência da falha até a manifestação do erro devido aquela falha e latência de erro como o período de tempo desde a ocorrência do erro até a manifestação do defeito devido aquele erro. 2.2 Conceitos Sistemas tolerantes a falha têm com objetivo alcançar dependabilidade 1 (dependability), que indica a qualidade do serviço fornecido por um dado sistema e a confiança depositada no serviço fornecido. Confiabilidade, disponibilidade, segurança de funcionamento (safety), segurança (security), mantenabilidade, testabilidade e comprometimento de desempenho (performability) são os principais atributos de dependabilidade. Confiabilidade é a capacidade de um sistema atender uma dada especificação, dentro de condições definidas, durante certo tempo de funcionamento. Independente do tipo de falha o sistema deve continuar 1 Apesar do termo dependabilidade não fazer parte da língua portuguesa, esta palavra será utilizada devido à falta de outra mais significativa neste contexto. 11

12 comportando-se de acordo com a sua especificação. Confiabilidade e disponibilidade têm conceitos diferentes. Um sistema pode ser de alta confiabilidade e de baixa disponibilidade. Um exemplo seria a manutenção programada de um sistema, feita diariamente, durante 4 horas. Disponibilidade é a probabilidade de o sistema estar funcionando num instante de tempo determinado. A disponibilidade de um sistema está muito relacionada com o seu tempo de reparo. Segurança de funcionamento (safety) é a probabilidade do sistema ou estar operacional, e executar sua função corretamente, ou parar de funcionar sem provocar dano a outros sistemas ou usuários. Sistemas preparados para falhas intencionais ou maliciosas buscam segurança (security), que está relacionada com a privacidade, autenticidade e integridade dos dados. Mantenabilidade está relacionada com a facilidade de realizar manutenção no sistema. Testabilidade é a capacidade de realizar testes do sistema. Quanto maior a testabilidade, melhor a mantenabilidade, e menor o tempo que o sistema não está disponível devido a reparos. O comprometimento de desempenho (performability) está relacionado a quanto o desempenho do sistema pode ser afetado na ocorrência de falhas. 12

13 3 ALTA DISPONIBILIDADE Sistemas redundantes e alta disponibilidade são utilizados por empresas e profissionais de tecnologia da informação para denotar sistemas que podem mascarar a ocorrência de falhas. Ao longo do tempo o termo dependabilidade também vem sendo utilizado neste sentido. Este capítulo apresenta conceitos baseados em [1] e [6]. Redundância de recursos é uma necessidade para se ter alta disponibilidade. Redundância em um sistema pode ser hardware, software ou tempo. Redundância de hardware compreende os componentes de hardware adicionados para tolerar falhas. Redundância de software inclui todos os programas e instruções que são usados na tolerância a falhas. Uma técnica comum de tolerância a falhas é executar certa instrução várias vezes. Esta técnica necessita redundância de tempo, isto é, tempo extra para executar tarefas para tolerar falhas. Os pontos únicos de falha (single point of failures - SPOF) são recursos que não podem falhar pois todo o sistema depende deles. A redundância de recursos é um pré-requisito para se eliminar os SPOFs. Além dos recursos de hardware dos servidores, os pontos únicos de falha estão nas redes de computadores (switches, routers, hubs, cabeamento, etc) que disponibilizam os serviços ao mundo externo, nas redes elétricas que alimentam as máquinas e na própria localização dos recursos. Desastres (ataques terroristas, incêndios, etc) podem inviabilizar toda a operação de um site, se este tiver suas informações e sistemas operando em somente um lugar físico. 13

14 3.1 Medição de Disponibilidade Uma outra questão sobre alta disponibilidade é como medi-la. A disponibilidade de certo serviço é definida com a probabilidade de encontrálo operando normalmente em determinado momento. Esta probabilidade leva em conta o provável uptime e downtime. O uptime é o tempo em que os serviços estarão funcionando e downtime o tempo em que os serviços ficarão fora do ar. Desta forma podemos calcular disponibilidade pela equação MTBF A = MTBF + MTTR onde A é o grau de disponibilidade expresso como uma porcentagem, MTBF é o tempo médio entre falhas (mean time between failures), e MTTR é o tempo máximo para reparos (maximum time to repair). Disponibilidade pode ser classificada em: Disponibilidade Básica encontrada em máquinas sem nenhum tratamento especial visando mascarar falhas, 99% a 99,9% de disponibilidade. Alta Disponibilidade quando a detecção, recuperação e mascaramento de falhas fazem com que o sistema chegue à faixa de 99,99% a 99,999% de disponibilidade. Disponibilidade Contínua o tempo de inoperância do sistema pode ser desprezível ou inexistente, chegando a 100 % de disponibilidade. 14

15 Com o crescimento do mercado para servidores de alta disponibilidade, passou-se a utilizar a medida de números de noves. Um sistema de cinco noves possui disponibilidade 99,999%. 3.2 Clusters De maneira geral um cluster é um grupo de computadores que trabalham juntos para criar um sistema muito mais poderoso. Em outras palavras, um cluster é um conjunto de máquinas independentes, chamadas nós, que ajudam umas as outras a realizarem tarefas com um determinado objetivo comum. A comunicação entre elas deve existir a fim de coordenar e organizar todas as ações a serem executadas. As máquinas de um cluster são fracamente agrupadas, ou seja, não fazem parte de uma mesma arquitetura de hardware. São máquinas regulares que foram acopladas. Ainda, frequentemente elas precisam compartilhar algum hardware com o objetivo de tolerar certas situações de falha. Para um usuário externo, a utilização de cluster para fornecer um serviço tem que ser transparente, tem que ser visto como sendo um único sistema lógico. Os objetivos principais para a formação de clusters são alta disponibilidade ou alta performance. Ainda é possível a situação onde o cluster deve atingir os dois objetivos juntos. 15

16 3.3 Clusters de Alta Disponibilidade Existem diferentes métodos e esquemas para prover a capacidade dos sistemas continuarem a funcionar mesmo na ocorrência de falhas. O comportamento de clusters de alta disponibilidade deve contar basicamente com: Relógios Sincronizados É um requisito para algumas aplicações, pois a diferença entre os relógios dos nós pode levar a problemas de coordenação do cluster. Repositório Estável Um sistema de armazenamento comum, com sua integridade do conteúdo preservada mesmo em caso de falhas, e estável para as aplicações, sendo capaz de tolerar os tipos de falhas mais prováveis e comuns. Detecção de Defeitos e Diagnóstico de Falhas Aplicações e métodos, em sua maioria, assumem que na ocorrência de falha em um nó, outros nós perceberão esta falha dentro de um período de tempo finito, e então executarão as medidas de reparo necessárias. Entrega Confiável de Mensagens Perdas de mensagens e erros em meios de comunicação podem ocorrer. Portando são necessários mecanismos para garantir que uma mensagem enviada por um nó chegue incorrupta ao seu destino e que a ordem das mensagens seja preservada entre dois nós. 16

17 3.4 Reconfiguração Dinâmica Clusters de alta disponibilidade devem ser capazes de se reorganizar e se reconfigurar dinamicamente para mascarar a presença de falhas. Isto deve ser feito de maneira que os serviços afetados sejam restabelecidos nos nós restantes, devidamente sincronizados com o nó que falhou Mascaramento de Falhas Mascaramento Hierárquico Quando um servidor depende de outros servidores em um nível inferior para prover seu serviço corretamente. Servidores em um nível mais alto de abstração mascaram falhas de um nível inferior. Figura 2 Masc. Hierárquico para Serviços As figuras 2 e 3 mostram um exemplo de mascaramento hierárquico de falhas para provimento de serviços internet e para acesso a internet de uma rede local respectivamente. 17

18 Figura 3 - Masc. Hierárquico para acesso a Internet O mascaramento hierárquico pode ser aliado com balanceamento de carga e apresenta ponto único de falha no servidor de nível mais alto de abstração. Mascaramento por Grupos O grupo mascara a falha de um dos servidores do mesmo nível. Como mostra a figura 4. Figura 4 - Mascaramento por Grupos Neste tipo de mascaramento de falhas podem ficar equipamentos ociosos, mas não apresenta recurso como ponto único de falha. Freqüentemente combina-se mascaramento hierárquico e por grupos. 18

19 3.4.2 Sincronização de Dados Em um ambiente onde trabalhamos com um grupo de máquinas independentes, sempre precisamos sincronizar algum tipo de informação entre as máquinas. Esta informação pode ser um estado interno ou os próprios dados utilizados pelo serviço fornecido. A sincronização de dados armazenados em um sistema de arquivos, entre dois nós, busca aumentar a disponibilidade do servidor de arquivos, tornando possível que o servidor reserva assuma em caso de falha do servidor principal. Qualquer alteração nos dados do servidor principal deve ser replicada para o servidor de reserva. cluster: Temos dois mecanismos genéricos de sincronização de dados em um Replicação Servidores devem manter sua própria cópia dos dados. Toda alteração deve ser sincronizada com outra unidade de armazenamento. Neste mecanismo podem-se utilizar hardwares simples. Switch-Over Servidores acessam dispositivos de armazenamento compartilhados. Usa-se somente uma cópia da unidade de armazenamento, portando deve-se utilizar repositórios mais robustos como RAID. 19

20 4 REDUNDÂNCIA DE GATEWAYS As redes locais com estações de trabalho, assim como DMZs ou clusters de servidores, tem os gateways como sua porta para internet. Uma falha no gataway de uma rede faz os sistemas que precisam de conexão com a internet se tornarem indisponíveis. Buscando alta disponibilidade, as ferramentas que implementam redundância em servidores são aplicadas principalmente nos gateways. Neste capítulo descrevem-se ferramentas para alta disponibilidade que implementam, basicamente, um mascaramento de falhas por grupos, como VRRP, Heartbeat e FailSafe, bem como conceitos que as envolvem baseados em [5]. 4.1 O Protocolo ARP O ARP descobre o endereço de hardware associado a um endereço IP em particular. Isso pode ser utilizado em qualquer tipo de rede que suporte broadcasting. Embora seja mais encontrado em termos de Ethernet. Se o host A quer enviar um pacote ao host B na mesma Ethernet, ele utiliza o ARP para descobrir o endereço de hardware do host B. Quando B não estiver na mesma rede do host A, o host A utiliza um ARP para localizar o MAC do roteador do próximo hop para o qual um pacote destinado ao host B deveria ter sido enviado. Uma vez que o ARP utiliza pacotes broadcast que não podem cruzar redes, ele só pode ser utilizado para localizar os endereços de hardware de máquinas conectadas diretamente a rede local do host que os envia. 20

21 Todas as máquinas mantêm uma tabela na memória denominada cache ARP, que contém os resultados das consultas a ARP mais recentes. Sob circunstâncias normais, vários dos endereços de que um host necessita são descobertos logo depois da inicialização, assim o ARP não é responsável por uma grande quantidade de tráfego de rede. O ARP funciona fazendo broadcast de um pacote perguntando se alguém conhece o endereço de hardware de um determinado IP. A máquina que está sendo pesquisada reconhece o próprio endereço IP e retorna afirmando que esse endereço IP está em uma das suas interfaces de rede e o endereço de hardware correspondente também é retornado. Figura 5 - Protocolo ARP A consulta original inclui os endereços IP e Ethernet do requisitante, de modo que a máquina que está sendo buscada possa responder sem emitir uma consulta a ARP. Portanto, as duas máquinas aprendem os seus respectivos mapeamentos de ARP com apenas uma troca de pacotes. Outras máquinas que ouvem por acaso o broadcast inicial do requisitante 21

22 também podem registrar o endereço do mapeamento. Essa inspeção passiva do tráfego ARP, às vezes, é chamada de espionagem. 4.2 Endereçamento Multicast Um endereço multicast identifica um grupo de máquinas da rede, ele é válido durante toda a sessão multicast, sendo dinamicamente alocado. Os quatro primeiros bits, de um endereço IPv4 multicast, são iguais a 1110, o que corresponde à faixa de a [2] Geralmente um endereço multicast é requisitado e atribuído dinamicamente, além de ser temporário. Entretanto, os endereços de a foram reservados pelo IANA (Internet Assigned Numbers Authority). Esta faixa corresponde a endereços de escopo local ao enlace (link-local), portanto não devem ser encaminhados por roteadores. [2] Alguns endereços são reservados para serviços específicos. O restante da faixa de endereços Classe D ( a ) corresponde a endereços multicast dinâmicos All Hosts All Multicast Routers All DVMRP Routers All OSPF Routers VRRP Tabela 1 - Exemplos de endereços multicast reservados Em uma rede Ethernet, são possíveis transmissões ponto-a-ponto, broadcast, e multicast. Uma faixa de endereços MAC da Ethernet foi reservada para o serviço multicast. Desta forma um endereço IP multicast é mapeado em um endereço multicast Ethernet. 22

23 4.3 Protocolo UDP O UDP (User Datagram Protocol) é usado por alguns programas em vez de TCP para o transporte rápido de dados entre hosts TCP/IP. Porém o UDP não fornece garantia de entrega e nem verificação de dados. Devido ao fato de o UDP ser muito mais rápido (por não fazer verificações e por não estabelecer sessões), o seu uso é recomendado em determinadas situações. 4.4 VRRP [3] O VRRP (Virtual Router Redundancy Protocol) é projetado para eliminar falhas causadas por problemas no gateway de uma Rede. VRRP especifica um protocolo de eleição que atribui dinamicamente a um dos roteadores VRRP, de uma LAN, a responsabilidade de roteador virtual. Quando o roteador Master se torna indisponível, o processo de eleição prove um controle de falha dinâmico para a definir qual roteador VRRP vai se tornar o roteador virtual. A figura abaixo [3] mostra uma rede simples com dois roteadores VRRP implementando um roteador virtual. 23

24 Figura 6 - VRRP com um roteador virtual O roteador 1 tem a interface com o endereço IP , e todas as estações têm ele configurado como sua rota default. Diferentemente das infra-estruturas de rede comuns, temos o roteador 2 com o endereço O VRRP está habilitado, em ambos os roteadores, nas interfaces de rede /24 e com apenas um roteador virtual (VRID=1, IP= ). VRID é a identificação de um roteador virtual. Desta forma o VRRP está configurado para assumir sempre o IP do roteador 1, que será inicialmente definido com Master. Como o roteador 2 não possui uma interface com o IP real , ele automaticamente assume que é Backup. Os roteadores irão se comunicar através de pacotes multicast. O roteador Master envia VRRP Advertisements, que são mensagens indicando 24

25 a que ele está vivo. Quando o Backup deixa de ouvir 3 mensagens, ele se torna Master e passa a responder pelo endereço IP virtual O endereço MAC virtual, que antes estava associado ao roteador 1, passa para o novo roteador Master. Desta forma o cache ARP das estações continua valendo para a sua rota default. O endereço MAC do roteador virtual possui o formato E {VRID em hexadecimal}, permitindo até 255 roteadores VRRP em uma rede. [3] Um outro exemplo é a configuração do VRRP com dois roteadores virtuais, como mostrado pela figura a baixo. Figura 7 - VRRP com dois roteadores virtuais 25

26 Desta forma o roteador 1 é Master para e Backup para , o roteador 2, por sua vez, é Master para e Backup para Metade das estações tem rota default para um roteador virtual e outra metade aponta para o outro. Desta forma temos uma divisão de carga sendo efetuada. E se um dos roteadores parar de funcionar ou se o seu link com a internet cair, o outro assume as duas instâncias de VRRP. 4.5 Heartbeat Com o mesmo princípio do VRRP o Heartbeat [6] (batimento cardíaco), utiliza o protocolo UDP na porta 694 para checar a saúde das máquinas. Trocas de mensagens entre máquinas ocorrem em intervalos regulares de tempo. Se a mensagem não é recebida para uma máquina em particular, o protocolo Heartbeat assume que a máquina falhou. Este sistema suporta somente 2 (duas) máquinas, a comunicação entre elas é muito importante, e também deve ter redundância. 4.6 FailSafe Desenvolvido originalmente para IRIX, e portado posteriormente para o Linux, o FailSafe é capaz de monitorar serviços e não somente se as máquinas continuam enviando mensagens. Ele permite clusters de até 16 máquinas. 26

27 5 BALANCEAMENTO DE CARGA EM SERVIDORES Aplicações que exigem alta disponibilidade têm nos clusters a arquitetura ideal para o fornecimento do serviço. Clusters de balanceamento de carga aliam escalabilidade e equilíbrio de carga de trabalho. Os conceitos de alta disponibilidade e de balanceamento de carga não possuem nenhuma relação, mas na prática são frequentemente ligados. O investimento em HA pode não ser justificado se o equipamento adicional está ocioso, ou se está duplicando o trabalho executado nos servidores primários. Desta forma um equipamento redundante pode dividir a carga de trabalho em operação normal, e substituir equipamentos em caso de falha. Neste capítulo descrevem-se as arquiteturas utilizadas no balanceamento dinâmico de carga classificadas por [4]. 5.1 Acesso baseado no DNS Uma requisição de acesso a Internet, normalmente é feita através do URL do site. Esta solicitação necessitará ter seu endereço resolvido para o respectivo endereço IP que constará da requisição. Esta fase de pesquisa inicial poderá ter uma solução em nível local, através do servidor de DNS da instalação, e caso não seja encontrado, será resolvido pela hierarquia da resolução de DNS até obter, do servidor de DNS do site procurado, o respectivo endereço IP. Todo este procedimento entre o nome simbólico (URL) e o endereço IP é realizado através de um protocolo de procedimentos específicos de resolução até o servidor apropriado que responderá o endereço IP do nome simbólico. Neste procedimento de busca 27

28 entre o cliente e o site de DNS em questão, a requisição poderá passar através de vários outros servidores de Domínio que poderão resolver o endereço através da busca deste mapeamento IP no conteúdo de seu cache (network-level address caching) para reduzir o tráfego na rede, podendo em alguns casos, inclusive, ser resolvido pelo navegador do cliente (client-level address caching). O servidor de DNS ao informar o endereço IP, também é especificado um tempo de validade para esta informação, tempo este conhecido por Time-To-Live (TTL), para ser usado no armazenamento do mapeamento IP. Quando o TTL expira no cache dos servidores de DNS, as solicitações recebidas são encaminhadas em frente para que possam achar um DNS válido possibilitando, assim, que o servidor de DNS forneça outro endereço IP de um servidor espelhado. Possibilitando desta forma uma divisão de tráfego entre servidores. Figura 8 - Balanceamento baseado no DNS 28

29 Existem duas alternativas para a resolução do endereço de URL. Se algum servidor de Domínio entre o cliente e o servidor de Domínio do site a ser requisitado dispuser de uma válida resolução para aquele determinado endereço, ele assim será resolvido e informado ao cliente, e a outra solicitação irá até o servidor de DNS do site solicitado (cluster DNS) que selecionará conforme um algoritmo um endereço IP entre a família de servidores disponíveis e estipulará um tempo TTL para esta resolução retornando ao cliente, sendo que todos os servidores de DNS intermediários neste procedimento de retorno ao cliente irão armazenar no respectivo cache esta associação e o tempo de vida da mesma. Como podemos observar o controle de endereçamento realizado através do DNS é limitado aos seguintes fatores: ao tempo de vida da associação (TTL), armazenada nos servidores de DNS intermediários e no caching do navegador do cliente (neste caso o tempo de vida é desconsiderado); o TTL não pode ser utilizado com valor próximo de zero, devido os servidores de DNS não cooperativos ignorarem valores menores que 120ms; não existe um controle efetivo do número de requisições que estão sendo realizados em um determinado instante por um servidor internet, tornando, assim, um ponto de gargalo de tráfego do servidor. Considerando que o TTL da arquitetura DNS pode assumir duas situações distintas, isto é, trabalhar com um TTL constante, ou com um TTL variado de forma dinamicamente pelo servidor de DNS, isto possibilita implementar algoritmos diferentes para trabalhar em cada caso. 29

30 5.1.1 Algoritmos com TTL constante Na utilização de um TTL constante, a escolha de um servidor internet poderá utilizar um algoritmo com base em: nenhuma informação (System stateless algorithms (SSA)); cliente, servidor internet; combinação de mais de um desses fatores. O algoritmo SSA mais importante é chamado Round Robin DNS (DNS-RR). Ele realiza uma distribuição das requisições para uma lista de servidores disponíveis cadastradas no servidor de DNS, de forma seqüencial na lista, sendo esta uma lista circular, isto é, após o último elemento retorna a distribuição ao primeiro elemento da lista. A distribuição de carga utilizando o DNS-RR não realiza um balanceamento efetivo, devido aos diversos dispositivos na rede internet guardarem a informação de endereçamento (cache e servidores de DNS), tornando-se sem efeito quando o acesso é realizado por clientes de um mesmo domínio, que possivelmente serão destinados a um mesmo servidor devido à resolução de endereçamento realizada em função do cache do servidor de DNS deste domínio. Estas restrições podem causar um desequilíbrio e uma sobrecarga dos servidores devido: ao método não considerar a disponibilidade e capacidade dos servidores; a obrigatoriedade de todos os servidores terem o mesmo conteúdo ou oferecerem o mesmo serviço, isto é, assume-se que o ambiente de distribuição das requisições é homogêneo. Com algoritmo baseado no estado do servidor, a distribuição DNS com controle permite combinar a técnica DNS-RR com mecanismos de 30

31 alerta enviado pelos servidores, possibilitando um controle de distribuição, tentando evitar a sobrecarga dos servidores. Nos algoritmos baseados no estado do cliente dois tipos de informação podem ser obtidos: localização geográfica e a carga típica de um determinado domínio com base na média das requisições realizadas por este domínio em um determinado tempo. Uma estimativa de carga de um determinado domínio não permite predizer a situação de carga dos servidores, que disparando um alarme de sobrecarga, permite que o distribuidor de DNS exclua o servidor da distribuição durante este período. Um avançado sistema de balanceamento utiliza vários tipos de informação do cliente/domínio e dos servidores que lhes permite um controle eficiente do estado dos mesmos, como por exemplo, o Cisco Distributed Director [7] Algoritmos com TTL variados dinamicamente. Inicialmente os algoritmos de controle variados estabeleciam um ajuste mais eficiente na distribuição DNS através de uma redução no TTL para poder obter um controle supostamente mais efetivo da sobrecarga dos servidores, contudo este método não se mostrou tão eficiente na distribuição de cargas aos clientes de domínios populares e com o uso de servidores de desempenhos diferentes. A razão deste acontecimento é que o fator de peso de um domínio cresce com o valor do TTL e com o correto ajuste do TTL irá permitir o controle subseqüente das requisições de cargas previstas de um 31

32 domínio, então esta situação é a principal causa de sobrecargas dos servidores. Os algoritmos dinâmicos realizam o processo de decisão em duas etapas. A primeira seleciona o servidor com base na carga estimada pela variação média do tempo entre requisições, e na segunda etapa, o DNS arbitrará o valor apropriado do TLL para o próximo período. Para o caso de domínios populares o TTL é inversamente proporcional à taxa de requisição do domínio, ou ajustado conforme o desempenho dos servidores, atribuindo valores mais altos a servidores de maior desempenho. 5.2 Distribuidor Concentrado (Dispatcher) O distribuidor de requisições, ao contrario do DNS, possui total controle das requisições dos clientes e disfarça para o cliente como se fosse o servidor internet, de fato o endereço IP do dispatcher é o único endereço conhecido dos clientes de um determinado URL. Desta forma o dispatcher age como um concentrador e distribuidor de requisições pela família de servidores através de algoritmos simples (round-robin, carga de servidores) ou complexos (SITA-V algoritmos). Existem duas formas distintas de implementação da distribuição, cuja requisição ao ser atendida pelo servidor internet retorna diretamente ao cliente e a outra forma retorne ao dispatcher para ele retornar ao cliente. 32

33 5.2.1 Dispatcher em um único caminho O dispatcher direciona a requisição do cliente para o servidor, alterando a requisição do cliente, o endereço de destino com o IP (e IP checksums) do servidor. Como mostra a figura 9. Figura 9 - Distribuidor em caminho único Este procedimento é executado em todas as requisições HTTP do cliente, pois o Distribuidor é o único endereço conhecido pela rede e pelo cliente do servidor destino, assumindo, assim, como concentrador e redirecionador de todas as requisições enviadas dos clientes ao servidor. As novas requisições de um determinado cliente são enviadas para o mesmo servidor das requisições anteriores. O servidor deverá alterar o cabeçalho IP com o endereço IP do dispatcher, assim sendo, o cliente não 33

34 tem conhecimento do endereço do servidor. Esta é uma solução totalmente transparente para o cliente. A arquitetura também permite que seja estabelecido um alto nível de disponibilidade do sistema, pois em caso de alguma falha em qualquer servidor, o endereço poderá ser removido da tabela de roteamento, sendo o dispatcher o ponto vital da rede, por ser um ponto único de acesso aos servidores, e seu endereço IP cadastrado em todos os servidores, sendo o mesmo o ponto de risco da estabilidade Dispatcher em mão dupla O dispatcher direciona a requisição do cliente para o servidor, escrevendo na requisição o endereço IP do servidor, e o endereço IP do cliente é substituído pelo endereço IP do dispatcher, que somente no retorno da requisição do servidor, será alterado novamente o endereçamento IP, agora com o endereço IP do Cliente. Como mostra a figura 10. Figura 10 - Distribuidor em mão dupla 34

35 Esta metodologia de alterar o pacote IP duas vezes, na ida e volta do servidor, é a base do Network Address Translation [8]. Ela possibilita o balanceamento através de diferentes tipos de algoritmos para a escolha do servidor: round-robin, randômico, carga proporcional (seleciona o servidor com a menor carga corrente estimada) e baseado no menor número de conexão ativas. Esta arquitetura não funciona com protocolos que manipulam o endereçamento IP dentro da aplicação e requer que o próprio dispatcher altere o pacote nos dois sentidos, sendo que no sentido do servidor para o cliente existe muito mais tráfego Dispatcher de pacotes pelo endereço físico O dispatcher pode encaminhar os pacotes dos clientes ao servidor selecionado, usando o endereçamento físico do servidor quando eles estão em uma mesma rede local, não modificando o cabeçalho IP. A escolha do servidor de destino pode ser de forma dinâmica (através de algoritmos baseados na carga e disponibilidade dos servidores) ou de forma estática. 5.3 Redirecionamento HTTP O protocolo HTTP permite ao distribuidor encaminhar as requisições de acordo com o conteúdo existente no cabeçalho e destinar ao servidor cujo documento deve ser acessado, desta forma a distribuição é realizada em função do conteúdo da requisição enviada pelo cliente que assim a 35

36 informa em função da resposta recebida anteriormente pelo servidor web, o que pode proporcionar uma distribuição fundamentada na localização do cliente e na situação do conteúdo requisitado. Figura 11 - Redirecionamento HTTP Esta técnica apresenta um tempo de avaliação bem superior e tem algoritmos mais complexos, pois a decisão é tomada fundamentada no conteúdo da mensagem, o que pode ser mais um ponto de sobrecarga de tráfego a ser considerado. 36

37 5.4 Distribuição com base no Servidor A arquitetura de distribuição com base no servidor realiza o encaminhamento das mensagens com base em dois níveis, primeiro as requisições são distribuídas pelo serviço de DNS para os servidores, então em um segundo nível o servidor assinalado poderá ou não redistribuir a requisição para um outro servidor. Esta combinação complementa a técnica de distribuição por DNS, tais como a distribuição não uniforme em um determinado domínio e uma limitação de requisições a um servidor. Os servidores redirecionam a requisição sobrescrevendo o endereçamento ou as informações de cabeçalho do protocolo HTTP. Esta arquitetura de distribuição com base no servidor garante uma escalabilidade do sistema, contudo apresenta um crescimento no tempo de latência das mensagens. 37

38 6 AMBIENTE DE ALTA DISPONIBILIDADE Este capítulo propõe um ambiente de alta disponibilidade para provimento de serviços no sistema operacional OpenBSD [9]. O ambiente proposto pode ser utilizado para diversos serviços, mas vamos restringir o exemplo para hospedagem de sites web. Propõe-se a utilização da ferramenta CARP [10] (Common Address Redundancy Protocol), similar ao protocolo VRRP, para um mascaramento de falhas por grupos, no gateway. Ainda a implantação do dispatcher em mão dupla para balanceamento de carga entre os servidores web com a ferramenta pf [11] (packet filter), o firewall do OpenBSD, mas especificamente com rdr (redirection - port forwarding), como mostra a figura 12. O método source-hash, do rdr, para distribuição de tráfego assegura que o endereço de origem do cliente sempre terá sua requisição respondida pelo mesmo servidor web. Mantendo uma consistência nas sessões. 38

39 Figura 12 - Ambiente HA Neste ambiente, cada máquina tem dados estáticos, que em caso de alterações serão replicados pela ferramenta rsync [12]. Ainda apresenta um repositório estável, para dados dinâmicos. Duas LANs são utilizadas. Uma para o tráfego de internet e outra para replicação de dados e acesso ao repositório estável. Ainda um cabo crossover faz a comunicação entre os gateways, como alternativa. 39

40 7 CONCLUSÃO Este trabalho cobriu vários aspectos de uma grande área. Estudamos os principais conceitos de tolerância a falhas e de alta disponibilidade. Vimos que um cluster é a melhor arquitetura para alta disponibilidade, e como ele se comporta para tal objetivo. Ferramentas que implementam clusters de alta disponibilidade foram apresentadas, bem como, técnicas para balanceamento dinâmico de tráfego em servidores. Foi proposto um ambiente HA para servidores web na plataforma OpenBSD [9], que se mostrou a melhor open-source pra este objetivo. Alta disponibilidade ainda é um tema pouco explorado. Durante o desenvolvimento deste trabalho notou-se a necessidade de padronização no que diz respeito à especificação e implementação de sistemas tolerantes a falhas. Entre as arquiteturas para HA, ainda temos um domínio de sistemas proprietários. No decorrer desta pesquisa foram encontradas dificuldade para testes, porque nesta área temos que contar com um número grande de equipamentos para realizar um teste real. Um cluster de alta disponibilidade definitivamente não é um sistema simples. Trabalhos Futuros Implantar o ambiente proposto para um sistema em produção e pesquisar sobre um sistema de gerenciamento para tal ambiente. 40

41 8 REFERÊNCIAS BIBLIOGRAFICAS [1] WEBER, T. S., Um roteiro para exploração dos conceitos básicos de tolerância a falhas, INF/UFRGS, Porto Alegre, [2] COSTA, L. H., DUARTE, O. C., Roteamento Multicast na Internet, GTA/UFRJ, Rio de Janeiro, [3] HINDEN, R., Ed., Virtual Router Redundancy Protocol (VRRP), RFC 3768, [4] V. Cardellini, M. Colajanni, P. Yu; Dynamic Load Balancing on Web- Server System. IEEE Internet Computing, vol 3,nº 3, pp 28-39, May/June [5] TANENBAUM, Andrew S., Redes de Computadores, 3. ed. Rio de Janeiro: Campus, [6] High-Availability Linux Project. [7] Cisco s Distributed and Local Director. [8] K. Egevang, P.Francis, The IP Network Address Translator (NAT), RFC 1631, Maio, [9] OpenBSD. [10] McBride, R., Firewall Failover with pfsync and CARP. [11] PF: The OpenBSD Packet Filter. [12] rsync. 41

42 ANEXO 42

43 Anexo I Artigo ALTA DISPONIBILIDADE DE SERVIÇOS DE REDE Daniel Campos dos Santos Curso de Bacharelado em Ciências da Computação Departamento de Informática e Estatística - INE Universidade Federal de Santa Catarina - UFSC danielcs@inf.ufsc.br RESUMO Alta disponibilidade é uma área que tem como principal objetivo trabalhar na tentativa de garantir que os sistemas permaneçam confiáveis e disponíveis. Os objetivos principais para a formação de clusters são alta disponibilidade ou alta performance. Ainda é possível a situação onde o cluster deve atingir os dois objetivos juntos. Este artigo mostra conceitos do comportamento dos clusters de alta disponibilidade e propõe um ambiente para HA. Palavras-chave: alta disponibilidade, rede, cluster, internet. INTRODUÇÃO As redes locais passaram a ser, nos últimos tempos, a plataforma de computação mais utilizada nas organizações. A queda de um servidor pode comprometer a produtividade de toda uma empresa, principalmente se esse servidor for o único disponível ou se estiver executando serviços importantes.

44 Alta disponibilidade é um ramo de uma área maior, chamada tolerância a falhas, que tem com principal objetivo trabalhar na tentativa de garantir que os sistemas permaneçam confiáveis e disponíveis. O objetivo deste trabalho é propor uma estrutura de alta disponibilidade em servidores web com sistema operacional OpenBSD[1]. ALTA DISPONIBILIDADE Sistemas redundantes e alta disponibilidade são utilizados por empresas e profissionais de tecnologia da informação para denotar sistemas que podem mascarar a ocorrência de falhas. Ao longo do tempo o termo dependabilidade 1 também vem sendo utilizado neste sentido. Os pontos únicos de falha (single point of failures - SPOF) são recursos que não podem falhar, pois, todo o sistema depende deles. A redundância de recursos é um pré-requisito para se eliminar os SPOFs. Além dos recursos de hardware dos servidores, os pontos únicos de falha estão nas redes de computadores, que disponibilizam os serviços ao mundo externo, nas redes elétricas, que alimentam as máquinas e na própria localização dos recursos. Uma outra questão sobre alta disponibilidade é como medi-la. A disponibilidade de certo serviço é definida com a probabilidade de encontrá-lo operando normalmente em determinado momento. Esta probabilidade leva em conta o provável uptime e downtime. 1 Apesar do termo dependabilidade não fazer parte da língua portuguesa, esta palavra será utilizada devido à falta de outra mais significativa neste contexto. 44

45 Desta forma podemos calcular disponibilidade pela equação, MTBF A =, MTBF + MTTR onde A é o grau de disponibilidade expresso como uma porcentagem, MTBF é o tempo médio entre falhas (mean time between failures), e MTTR é o tempo máximo para reparos (maximum time to repair). CLUTERS DE ALTA DISPONIBILIDADE Um cluster é um conjunto de máquinas independentes, chamadas nós, que ajudam umas as outras a realizarem tarefas com um determinado objetivo comum. Os objetivos principais para a formação de clusters são alta disponibilidade ou alta performance. Ainda é possível a situação onde o cluster deve atingir os dois objetivos juntos. O comportamento de clusters de alta disponibilidade deve contar basicamente com Relógios Sincronizados, Repositório Estável, Entrega Confiável de Mensagens, Detecção de Defeitos, Diagnóstico de Falhas e Reconfiguração Dinâmica que é capacidade de se reorganizar e se reconfigurar dinamicamente para mascarar a presença de falhas. Isto deve ser feito de maneira que os serviços afetados sejam restabelecidos nos nós restantes, devidamente sincronizados com o nó que falhou. Em um ambiente onde trabalhamos com um grupo de máquinas independentes, sempre precisamos sincronizar algum tipo de informação entre as máquinas. Esta informação pode ser um estado interno ou os próprios dados utilizados pelo serviço fornecido. A sincronização de dados armazenados em um sistema de arquivos, entre dois nós, busca aumentar a 45

46 disponibilidade do servidor de arquivos, tornando possível que o servidor reserva assuma em caso de falha do servidor principal. Qualquer alteração nos dados do servidor principal deve ser replicada para o servidor de reserva. Os conceitos de alta disponibilidade e de balanceamento de carga não possuem nenhuma relação, mas na prática são frequentemente ligados. O investimento em HA pode não ser justificado se o equipamento adicional está ocioso, ou se está duplicando o trabalho executado nos servidores primários. Desta forma um equipamento redundante pode dividir a carga de trabalho em operação normal, e substituir equipamentos em caso de falha. Clusters de balanceamento de carga aliam escalabilidade e equilíbrio de carga de trabalho. AMBIENTE WEB DE ALTA DISPONIBILIDADE Propõe-se a utilização da ferramenta CARP [2] (Common Address Redundancy Protocol), para redundância de gateway. Ainda a implantação de um distribuidor para balanceamento de carga entre os servidores web com a ferramenta pf [3] (packet filter), o firewall do OpenBSD, mas especificamente com rdr (redirection - port forwarding). O método source-hash, do rdr, para distribuição de tráfego assegura que o endereço de origem do cliente sempre terá sua requisição respondida pelo mesmo servidor web. Mantendo uma consistência nas sessões. Neste ambiente, cada máquina tem dados estáticos, que em caso de alterações serão replicados pela ferramenta rsync [4]. Ainda apresenta um repositório estável, para dados dinâmicos. 46

47 Figura 13 - Ambiente HA Duas LANs são utilizadas. Uma para o tráfego de internet e outra para replicação de dados e acesso ao repositório estável. Ainda um cabo crossover faz a comunicação entre os gateways, como alternativa. Como mostra a figura 1. CONCLUSÃO Este artigo apresentou os principais conceitos de tolerância a falhas e de alta disponibilidade. Vimos que um cluster é a melhor arquitetura para alta disponibilidade, e como ele se comporta para tal objetivo. Alta disponibilidade ainda é um tema pouco explorado. Durante o desenvolvimento deste trabalho notou-se a necessidade de padronização no 47

48 que diz respeito à especificação e implementação de sistemas tolerantes a falhas. Entre as arquiteturas para HA, ainda temos um domínio de sistemas proprietários. Um cluster de alta disponibilidade definitivamente não é um sistema simples. BIBLIOGRAFIA [1] OpenBSD. [2] McBride, R., Firewall Failover with pfsync and CARP. [3] PF: The OpenBSD Packet Filter. [4] rsync. 48