A alta disponibilidade compõe-se por uma arquitectura de dois ou mais computadores configurados para que possam trabalhar em conjunto. Desta forma, cada computador monitoriza os demais e em caso de falha assume os serviços que ficaram indisponíveis. Neste projecto são abordadas questões relativamente a hardware e software, privilegiando as soluções de alta disponibilidade baseadas em software. No mercado existem várias soluções para alcançar esse objectivo, mas o elevado custo de implementação e licenciamento impede a adopção desses sistemas por empresas economicamente limitadas. Para contornar essa limitação, foi utilizado software Open Source que permite a implementação de alta disponibilidade a baixo custo. Neste projecto é abordada a alta disponibilidade em servidores Web, recorrendo a software de código aberto e hardware vulgar. No capítulo direccionado aos conceitos básicos são apresentados alguns conceitos necessários para a compreensão do projecto, de seguida são explicados os diferentes tipos de cluster e respectivas vantagens de implementação, posteriormente os pontos de falha existentes nos sistemas computacionais bem como possíveis soluções. Finalmente é apresentada uma solução que garante alta disponibilidade através da utilização dos softwares Heartbeat, Keepalived, Haproxy, Apache, Mysql, GlusterFS e do módulo Bonding. Embora o objectivo deste projecto seja direccionado para os servidores Web, é possível recorrer aos mesmos mecanismos na implementação de outras soluções que exijam alta disponibilidade.

• ARP – Address Resolution Protocol
• CPU – Central Processing Unit
• DNS – Domain Name System
• HA – High Availability
• HDD – Hard Disk Drive
• HTML – HyperText Markup Language
• IIS – Internet Information Services
• I/O – Input-Output
• IP – Internet Protocol
• LAN – Local Area Networks
• MAC address – Media Access Control address
• MAN – Metropolitan Area Networks
• NAS – Network-attached storage
• NASA – National Aeronautics and Space Administration
• RAM – Random Access Memory
• SPOF – Single points of Failure
• TCP – Transmission Control Protocol
• UDP – User Datagram Protocol
• UPS – Uninterruptible Power Supply
• UTP – Unshielded Twisted Pair
• WAN – Wide Area Networks

O rápido avanço tecnológico provocou dependências computacionais cada vez maiores na vida das pessoas e no dia-a-dia das empresas. A comunicação entre organizações e pessoas tem vindo a ganhar cada vez mais ênfase nas actividades comerciais e de lazer. As transacções comerciais, comunicação interpessoal e realização de negócios electronicamente, ocorrem a todo o instante. Os recursos tecnológicos passaram de ferramentas de trabalho a factores competitivos de extrema importância. Os actuais sistemas de informação beneficiam com a rede global “Internet”, que lhe permite a troca de dados e informações em formato digital. As redes informáticas foram desenvolvidas para suportar inúmeras aplicações tal como voz, vídeo e dados independentemente da dispersão geográfica. A ocorrência de falhas de serviço é uma das grandes preocupações da actual sociedade de informação. A indisponibilidade de um site ou serviço de correio electrónico reflecte negativamente a facturação bem como a interacção com clientes e fornecedores. Actualmente o site de uma empresa é o seu cartão de visitas, e o e-mail um canal muito importante para a correspondência entre entidades interna e externas à empresa. Sendo assim só é possível garantir qualidade e disponibilidade de serviço se os dados estiverem disponíveis em tempo real e corresponderem a informação fiável. A necessidade de disponibilidade e dependência faz com que qualquer processo que envolva recursos computacionais seja crítico. Torna-se, por isso, necessário implementar sistemas de armazenamento de dados seguros e que nos garantam disponibilidade. Desta forma é necessário arranjar mecanismos que nos permitam contornar possíveis falhas de hardware e software, mantendo intacta a interacção com o utilizador final. A alta disponibilidade (HA-High Availability) visa garantir a máxima disponibilidade dos serviços prestados, recorrendo a software e hardware específico para o efeito. Actualmente os maiores construtores de hardware e software disponibilizam soluções HA os quais permitem suportar aplicações críticas que devem estar permanentemente disponíveis. No entanto, estas soluções têm um elevado custo e estão dependentes de sistemas proprietários. Este facto faz com que os sistemas Open Source tenham cada vez mais adeptos permitindo o aparecimento de soluções HA gratuitas, de código aberto e com actualizações permanentes. Este projecto pretende implementar uma solução de alta disponibilidade para servidores Web através de criação de um cluster LINUX com recurso a software baseado na licença GNU-GPL. Porém, o conceito apresentado pode ser utilizado em qualquer serviço que necessite de alta disponibilidade.

O objectivo geral deste trabalho é implementar um sistema que sustente um servidor Web de alta disponibilidade. Devido a restrições de recursos computacionais é pretendido uma implementação de alta disponibilidade recorrendo a hardware de baixo custo evitado soluções proprietárias e recorrendo a software OpenSource.

Para que o objectivo deste projecto seja perceptível, é necessário ter presente alguns conceitos que servem de suporte ao desenvolvimento do tema.

Uma rede informática consiste em dois ou mais sistemas computacionais interligados. As redes podem ser distinguidas por factores geográficos. As redes que se encontram próximas ou seja no mesmo edifício designam-se por Local Area Networks (LANs). As Metropolitan Area Networks (MANs)) que abrangem áreas semelhantes a uma cidade ou Wide Area Networks (WANs), de grandes dimensões implementadas por operadores ou empresas de grandes dimensões. Existem diferentes tipos e topologias de redes compostas por uma variedade de equipamentos que juntamente com a cablagem potenciam a comunicação. Os switch são utilizados para interligar redes locais, equipamentos e computadores que existem. Os routers servem para interligar redes distintas, definir redes de broadcast e efectuar encaminhamento (Routing) para determinada rede utilizando protocolos de encaminhamento. (Edmundo Monteiro, 2000)

Os utilizadores de uma rede pretendem usufruir de tudo o que ela lhe possa facultar a nível de comunicações. Para que isso seja possível é necessário que os elementos da rede suportem os serviços necessários. EX: Domain Name System (DNS). Embora para o utilizador final a existência deste serviço não seja notória, é essencial que ele exista na rede. Só desta forma é possível efectuar a tradução de nomes em endereços IP. Um serviço é algo existente numa rede que visa executar uma determinada função sempre que um elemento da rede a solicite.

No que diz respeito a transporte de informação o modelo TCP/IP é o mais utilizado em redes de computadores. Os dois protocolos de transporte utilizados são TCP e UDP, o primeiro é orientado á ligação o qual garante a entrega da informação, já o segundo não nos oferece a mesma garantia no entanto é um protocolo mais leve e com menor impacto na rede. Num nível mais baixo na comunicação é utilizado o protocolo IP tanto em LANs, MANs ou WANs. Em qualquer dos casos podem ser utilizadas ligações físicas com cabo UTP, cobre ou fibra óptica dependendo da largura de banda exigida bem como distância entre equipamentos. As ligações via rádio, actualmente muito explorada, dificilmente são utilizadas em ambientes que requerem alta disponibilidade e grande largura de banda. (Loureiro)

Um cluster é um conjunto de computadores independentes, designado por nós, que colaboram entre si para atingir um objectivo comum. Para que isso aconteça, os computadores devem comunicar entre si através de ligações de alta velocidade, de forma a coordenar todas as acções a executar sendo vistos pelo utilizador final como um único sistema. Um cluster tem como objectivo principal o aumento de disponibilidade e ou de desempenho. Ao longo deste trabalho é apresentada uma descrição mais pormenorizada dos diferentes tipos de cluster. (Pitanga, 2003)

Nas redes informáticas a redundância pode significar a existência de vários sistemas para efectuar a mesma operação, ou de equipamentos alternativos que em caso de falha assumem automaticamente as funções do equipamento que falhou. A redundância nas redes garante que existem vários caminhos para chegar ao mesmo destino, com dois ou mais equipamentos a efectuar a mesma função. Actualmente os equipamentos destinados a redes empresariais (switch, Routers, etc.) são construídos a pensar em soluções ao nível da redundância. A prova deste facto é a existência de duas fontes de alimentação. Os bastidores onde os equipamentos são instalados já disponibilizam energia socorrida recorrendo a UPS’s, geradores e estabilizadores de corrente. (Pitanga, 2003)

A disponibilidade de um serviço é visível através de tarefas simples e que fazem parte do nosso dia-a-dia, tal como o pagamento via multibanco impossíveis de concretizar sem a existência de um sistema informático. No caso referido anteriormente a disponibilidade é tão crucial que pode levar ou não à realização de um negócio. O conceito de disponibilidade num sistema informático refere-se ao período de tempo em que os serviços estão disponíveis, ou o tempo aceitável para o processamento de uma determinada operação solicitada pelo utilizador. Contudo, podem ocorrer interrupções planeadas tais como upgrades de sistema operativo, podendo implicar retoma dos serviços por parte de outra máquina destinada para o efeito. A disponibilidade de um serviço é baseada na percentagem que mede a probabilidade de encontrar o sistema em funcionamento num determinado intervalo temporal. A disponibilidade de serviço é denominada por uptime. Já o downtime representa o tempo em que este se encontra indisponível. (Stern, 2003)

O conceito de tolerância a falha surgiu em 1967 por Avizienis que defendia que um sistema de tolerância a falhas deveria ter a capacidade de garantir continuidade de serviços, mesmos quando ocorrem falhas de Hardware ou Software, mas não em caso de erro humano. Este tipo de sistema pode ser implementado com recurso a redundância de hardware, (CPU, memorias, dispositivos I/O) e ou de software (Vários aplicações desenvolvidas por equipas distintas com base nas mesmas especificações e com implementações diferentes). A tolerância a falha passa pela existência de redundância de equipamentos, para que em caso de detecção de falha o equipamento secundário assuma automaticamente as funções do primário. (Ruponi, 2004)

Este conceito visa garantir disponibilidade de serviço 24 horas/dia sem nenhuma falha, o que implica HA. Esta abordagem combina as características do funcionamento contínuo e de alta disponibilidade HA, que representa o estado ideal. É geralmente utilizada quando pretendemos elevados níveis de disponibilidade e um downtime quase nulo. É comum ser executada simultaneamente a mesma tarefa em duas máquinas distintas. Este tipo de sistema tenta garantir uma disponibilidade de 100% recorrendo à utilização de equipamentos redundantes e capacidade de recuperação total em caso de erro. (Ruponi, 2004)

No desenvolvimento de um projecto HA devemos analisar alguns aspectos talis como equipamentos e software envolvido. Ambiente de instalação do sistema bem como o poder de processamento e armazenamento de dados. Para que a falha de qualquer equipamento que compõe o sistema computacional não se reflicta para o utilizador final, é importante que não existam Single points of Failure (SPOF). Numa primeira fase, mais simples e económica deve-se aplicar redundância a nível de Hardware recorrendo a fontes de alimentação redundantes UPS’s, discos em mirror, CPU’s, ligações de rede, até obtermos a duplicação de todos o sistema computacional. No que diz respeito à infra-estrutura de rede também devemos garantir redundância quer ao nível da cablagem quer ao nível de switching (Switchs, routers, etc.).

A duplicação do sistema computacional implica a instalação de novos equipamentos. Caso sejam instalados no mesmo segmento de rede ou bastidor estamos perante uma SPOF. Desta forma devemos colocar o computador noutro segmento de rede e noutro Bastidor. Em casos onde a segurança da informação e a redundância de serviços é crucial podemos optar pela instalação dos equipamentos em locais geograficamente distintos (

A instalação do sistema redundante geograficamente disperso obriga a que seja efectuado um grande investimento. Para rentabilizar este sistema é conveniente a adopção de balanceamento onde ambos os sistemas respondem aos pedidos provendo um aumento de qualidade de serviço e aperfeiçoamento de performance.

Neste capítulo são abortados os diferentes tipos de cluster bem como vantagem e desvantagens resultantes de cada um.

A tecnologia de Cluster surgiu para computadores de alto desempenho conhecidos por super-computadores, no entanto a implementação deste sistema com recurso a computadores “normais” teve inicio em 1994 num projecto da NASA, que necessitava de alto processamento na ordem de alguns gigaflops (um gigaflop é igual a um bilião de operações de ponto flutuante por segundo). Nessa altura um super computador com esse nível de desempenho custava alguns milhares de dólares. Resultante do elevado preço, Thomas Sterling e Donald J. Backer resolveram interligar 16 computadores com um processador 486 DX4-100 que utilizavam um sistema operativo Linux e interligados via rede. Este grupo de computadores tinha uma capacidade de processamento de 70 megaflops com um custo de quarenta mil dólares, que equivalia a dez porcento do custo de um super computador equivalente na época. Este grupo de computadores foi denominado Beowulf Cluster, com capacidade para integrar computadores com deferentes capacidades computacionais (com hardware distinto). (The Beowulf Cluster Site)

Para que possamos retirar vantagens da utilização de um cluster o mesmo deve reunir as seguintes características:

Todos os computadores denominados por nós, devem esta interligados por uma rede que opere sobre protocolos standard e equipamentos genéricos. Em relação ao sistema operativo deve ser padrão em todos os computadores pois o software de gestão deve ser comum a todos os elementos. (Pitanga, 2003)

Deve permitir a adição de novos elementos ao cluster, aplicações, periféricos e novas ligações de rede sem interromper a disponibilidade de serviços. (Pitanga, 2003)

Os computadores devem comunicar entre si através de ligações de alta velocidade de forma a coordenar todas as acções a serem executadas, sendo vistos pelo utilizador final como um único sistema. (Pitanga, 2003)

Um dos grandes problemas destes sistemas computacionais é a manutenção ser uma tarefa morosa e com grande propensão a erros. Assim sendo, um cluster deve reunir um ambiente que facilite a sua configuração e administração para que ele não se torne um grande sistema complexo, que requer um grande trabalho de configuração e administração. (Pitanga, 2003)

• Alto desempenho que nos permite resolver problemas complexos que requerem grande capacidade computacional através de processamento paralelo, possibilitando a redução do tempo dispendido para a execução de uma determinada tarefa. • Escalabilidade permitindo a adição de novos nós de forma a aumentara a capacidade de processamentos mediante o incremento da carga de trabalho. • Tolerância a falhas que permite a continuidade de serviço em caso de falha, este facto aumenta a fiabilidades do sistema.

Os clusters podem ser utilizados em diferentes situações ou cenários. Vulgarmente encontram-se instalados em ambientes que requerem alta disponibilidade, ex: servidores Web, e-mail etc. Também podem ser utilizados em situações que requerem grande capacidade de processamento tal como investigação científica ou centros de cálculo. De seguida são descritos os principais tipos de cluster e quais as suas especificidades.

Como o nome indica, este tipo de cluster foca aspectos que dizem respeito à necessidade de grande poder de processamento, normalmente na execução de actividades complexas. Neste sistema, as tarefas que requerem grande capacidade computacional são divididas e distribuídas por todos os elementos que constituem o cluster. Este processo é denominado por processamento distribuído ou processamento paralelo, permitindo a redução do tempo dispendido para a execução da tarefa. O processamento paralelo caracteriza-se pela distribuição do processo por mais do que um CPU e o processamento distribuído pela partilha dos recursos computacionais permitindo optimizar a execução das tarefas computacionais. No que diz respeito a cluster de alto desempenho, a principal referência é o projecto Beowulf da NASA. Desta forma muitos administradores de sistemas denominam os clusters de alto desempenho por Cluster Beowulf. Beowulf é uma arquitectura multicomputador que pode ser utilizada para computação paralela. Normalmente esta arquitectura consiste num nó servidor e um ou mais nós clientes interligados via rede. Não é necessário hardware específico, sendo apenas necessário um sistema operativo Linux com as bibliotecas PVM ou MPI. Este facto faz com que o custo da solução total de um cluster Beowulf seja consideravelmente mais baixo quando comparado com um super computador. Os clusters de alto desempenho normalmente são utilizados em projectos científicos ou em análises financeiras que requerem cálculos complexos. (The Beowulf Cluster Site)

Nos clusters de balanceamento de carga, todos os nós executam as mesmas aplicações sendo os pedidos divididos entre eles de forma equilibrada. Se um dos nós falhar a distribuição dos pedidos é distribuída pelos nós activos. O cluster de balanceamento de carga tem como objectivo principal fornecer aumento do desempenho global do sistema, no entanto é muito diferente do cluster de alto desempenho, pois os pedidos são processados exclusivamente no nó para o qual o pedido foi reencaminhado. O objectivo deste sistema consiste apenas em dividir as requisições e não as subtarefas resultantes de um pedido. Este tipo de cluster é muito utilizado em servidores Web e e-mail. (The Reliable, High Performance TCP/HTTP Load Balancer)

A alta disponibilidade compõe-se por uma arquitectura de dois ou mais computadores configurados para que possam trabalhar em conjunto. Desta forma, cada computador monitoriza os demais e em caso de falha assume os serviços que ficaram indisponíveis. Este tipo de cluster dá-se o nome de cluster HA (High availability) sendo este um dos modelos implementados neste projecto. Os clusters de alta disponibilidade são utilizados sempre que se verifica a necessidade de responder a serviços que devam estar sempre disponíveis. Podemos classificar a disponibilidade em três classes distintas: 1) Disponibilidade Convencional – Este tipo de disponibilidade é a que maioria dos servidores Web existentes no mercado implementa e que de alguma forma oculta eventuais falhas. Os recursos computacionais pertencentes a esta classe facultam uma disponibilidade de 99% a 99.9%, isto significa que ao longo de um ano poderá existir uma indisponibilidade num período de 9 horas e quatro dias. 2) Alta disponibilidade – É facultada por servidores munidos de recursos que os permitem detectar, recuperar e ocultar eventuais falhas. Estes sistemas computacionais garantem uma disponibilidade de 99.99% a 99.999%, ou seja ao longo de um ano pode existir uma indisponibilidade de pouco superior a cinco minutos. 3) Disponibilidade contínua – Existe em servidores muito sofisticados com recursos muito eficientes no que diz respeito à detecção, recuperação e capazes de ocultar eventuais falhas. Estes têm disponibilidades cada vez mais próximas dos 100% sendo o período de inactividade insignificante ou até inexistente. Nos sistemas de tolerância a falhas, a existência de redundância é um dos pré-requisitos para alcançar alta disponibilidade num sistema computacional. Caso não exista redundância de todos os equipamentos e sistemas (Hardware e software) estamos perante um Single point of Failure (SPOF), ponto único de falha. Contudo não existe um tipo de cluster melhor ou pior, desta forma devemos escolher o cluster que mais se adequa ao problema a resolver ou à realidade da empresa ou instituição. (Linux-HA Project)

Como referido anteriormente, o objectivo deste projecto é implementar um sistema que garanta alta disponibilidade num servidor Web recorrendo a hardware de baixo custo, evitando soluções proprietárias. Para alcançar este objectivo foram criados dois clusters; Servidor Web e HaProxy e instalado um servidor de base de dados. Ambos os clusters são compostos por 2 computadores. No que diz respeito a infra-estrutura de rede e servidores, com excepção do servidor de base de dados, existe redundância em todos os equipamentos (routers, switch, interfaces de rede e servidores).

O esquema lógico representa o fluxo de informação gerado pela interacção com os clientes. Quando um cliente faz um pedido, o router reencaminha o tráfego para o HAproxy sendo esse pedido posteriormente reencaminhado para o servidor Web. O servidor Web para obter a informação solicitada recorre ao servidor de base de dados e devolve a informação ao cliente.

O Router Backup e o HAproxy 2 Backup estão configurados em modo failover, apenas entram em funcionamento caso ocorra alguma falha no Router primário ou HAproxy 1. Os servidores Web 1 e Web2 estão configurados para responder em modo balanceador de carga. Ambos respondem aos pedidos mediante a distribuição dos mesmos por parte do HAproxy. O servidor de base de dados responde aos pedidos solicitados pelos servidores Web.

Como referido anteriormente foi necessário adoptar algumas ferramentas de forma a obter uma arquitectura de alta disponibilidade. O sistema operativo adoptado foi o Ubuntu Server 9.04. A sincronização de dados entre Servidores ficou a cargo do GLUSTERFS. O Heartbeat e Keepalived foram utilizados na monitorização dos elementos do cluster de balanceamento HAproxy. Foi adoptado o Apache como servidor http e o Mysql para servidor de base de dados. O módulo Bonding serviu para a agregação de interfaces de rede. Todos os pacotes de software supra referidos serão explicados pormenorizadamente.

Nas seguintes tabelas está representada a distribuição de software por servidor:

Software Instalado no HAproxy

• Sistema Operativo Ubuntu server 9.04
• Heartbeat
• Keepalived
• Haproxy
• Modulo Bonding

Software Instalado Servidor Web

• Sistema Operativo Ubuntu server 9.04
• Apache
• GlusterFS
• Modulo Bonding

Software Instalado no servidor de base de dados

* Sistema Operativo Ubuntu server 9.04

• Mysql
• Modulo Bonding

De seguida são descritos os principais componentes de hardware que compõem o sistema computacional implementado.

Os servidores HAproxy foram instalados em dois computadores Compaq D310DT com as seguintes características:

• CPU Pentium 4 a 2.4 GHZ
• HDD Disco IDE de 40GB
• RAM 1152MB
• LAN1 D-link DGE-530T 10/100/1000
• LAN2 D-link DGE-530T 10/100/1000

Os servidores Web foram instalados em dois computadores HP Compaq dc7600 com as seguintes características:

• CPU Pentium 4 a 3.2 GHZ
• HDD Disco SATA de 40GB
• RAM 3072MB
• LAN1 Broadcom NetXtreme 10/100/1000
• LAN2 D-link DGE-530T 10/100/1000

O servidor de base de dados foi instalado num computador IBM IntelliStation M Pro com as seguintes características:

• CPU Pentium 4 a 3.2 GHZ
• HDD SATA de 80GB
• RAM 1024MB
• LAN1 Broadcom NetXtreme 10/100/1000
• LAN2 D-link DGE-530T 10/100/1000

Tendo em conta a complexidade da solução global a mesma vai ser subdividida em várias áreas as quais serão descritas separadamente. Numa primeira fase vai ser descrita a configuração e infra-estrutura de rede, seguindo-se o cluster para balanceamento de tráfego (Load Balancer) HAProxy, posteriormente o cluster http com recurso ao Apache e finalmente o servidor de base de dados Mysql.

Independentemente do tipo de cluster implementado neste projecto, a arquitectura de rede é comum. Todos os servidores utilizam simultaneamente dois interfaces de rede. Este facto faz com que haja um incremento de performance e diminuição da probabilidade de falha. Para possibilitar essa implementação, é necessário acrescentar ao kernel dos servidores o módulo Bonding. Este módulo surgiu juntamente com o projecto Beowulf, inicialmente desenvolvido por Donald Becker’s o qual tem sofrido constantes actualizações provenientes das comunidades criadas em torno deste componente.

O módulo Bonding foi evoluindo e gradualmente surgiram upgrades com novas funcionalidades e forma de comunicação. De seguida são descritas as abordagens conhecidas até ao momento: Round-robin policy (mode=0)

Os pacotes são transmitidos sequencialmente do primeiro dispositivo escravo até ao último. Esta abordagem implementa balanceamento de carga e tolerância a falhas.

Active-backup policy (mode=1)

Apenas um interface está activo sendo o seguinte activado em caso de falha. Esta abordagem implementa tolerância a falhas.

Balance-xor policy (mode=2)

Transmissão baseada no endereço MAC de destino. É seleccionado o mesmo interface slave para cada endereço MAC de destino. Implementa balanceamento de carga e tolerância a falhas.

Broadcast (mode=3)

Transmite todos os pacotes em todos os interfaces slave. Implementa tolerância a falhas.

Dynamic link aggregation IEEE 802.3ad (mode=4 )

Agrega interfaces com a mesma velocidade e utiliza todos os interfaces slave desde que o switch suporte a especificação 802.3ad e o driver do interface de rede suporte ethertool para garantir full-duplex.

TLB – Transmit load balancing (mode=5)

Não requer um switch especial e a saída do tráfego é distribuída de acordo com a carga de cada interface slave. O tráfego de entrada é recebido pela primeira interface slave e em caso de falha a outra interface assume as suas funções.

* Adaptive load balancing (mode=6)

Inclui Transmit Load Balancing (tlb) com Receive Load Balancing (rlb) não requer um switch especial. O bonding intercepta a resposta ARP enviada pelo sistema local e ao enviar os pacotes reescreve o endereço do hardware de origem com o endereço de hardware de uma das interfaces slave.

Depois de testados os diferentes modos de funcionamento do Bonding, foi utilizada a configuração Round-robin policy (mode=0). Desta forma, para além de garantir tolerância a falhas obtemos um incremento de performance. O modo Active-backup policy (mode=1) foi excluído pelo facto de subaproveitar os equipamentos de rede, pois apenas são utilizados em caso de falha dos dispositivos primários. O modo Broadcast (mode=3) embora utilize todos os dispositivos de rede foi excluído por não fornecer incremento de performance. Os módulos TLB – Transmit load balancing (mode=5) e Adaptive load balancing (mode=6) foram excluídos pela obrigatoriedade de suporte ao ethertool por parte do driver da placa de rede. O Dynamic link aggregation IEEE 802.3ad (mode=4 ) foi excluído pela necessidade de um switch com suporte à especificação 802.3ad. O balance-xor policy (mode=2) é um bom candidato, no entanto apenas se torna vantajoso em situações de múltiplos clientes. O facto de recorrer sempre ao mesmo interface para responder ao pedido de um determinado MAC impede-o de tirar partido da agregação de interfaces.

De seguida são apresentados todos os passos necessários para proceder à instalação do suporte ao Bonding. Todos os comandos devem ser executados como root para tal devemos executar o seguinte:

$ sudo –s

Para simplificar o processo de instalação devemos sempre que possível recorrer ao gestor de pacotes APT desta forma para activar o suporte a Bonding devemos executar o seguinte comando:

# apt-get install ifenslave

Agora vamos iniciar a configuração do Bonding. Para tal devemos editar o ficheiro Bonding que se encontra na directoria /etc/modprobe.d/. Neste caso recorremos ao VI ou qualquer outro editor de texto.

# vi /etc/modprobe.d/bonding

Para activar o modo Round-robin o ficheiro deve ficar assim: alias bond0 bonding options bonding mode=0 miimon=100 downdelay=200 updelay=200

Agora vamos iniciar a configuração dos interfaces de rede. Para isso devemos editar o ficheiro interfaces que se encontra na directoria /etc/network/:

# vi /etc/network/interfaces

Os servidores encontram-se instalados na rede 192.168.200.xxx Para configurar a agregação de dois interfaces, o conteúdo do ficheiro deve ser idêntico ao seguinte e apenas devemos substituir o endereço IP conforme o servidor:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
        address 192.168.200.XXX
        netmask 255.255.255.0
        network 192.168.200.0
        broadcast 192.168.200.255
        gateway 192.168.200.254
        up /sbin/ifenslave bond0 eth0 eth1
        down /sbin/ifenslave -d bond0 eth0 eth1

Depois de efectuadas as respectivas alterações para que as mesmas sejam carregadas é necessário reiniciar o serviço de rede. Para tal devemos executar o seguinte comando:

# /etc/init.d/networking restart

A necessidade de instalação de um cluster de loadbalancer deve-se ao facto de existirem vários servidores Web, sendo necessário proceder à distribuição de pedidos http entre os diferentes servidores. Depois de analisados diversos conceitos de loadbalances, foi adoptado o HAproxy. A escolha desta ferramenta deve-se ao facto de ser open source, robusta e estável, não tendo sido detectado qualquer problema de segurança nos últimos sete anos. O facto de o Haproxy ser adoptado pelo RedWall e Exceliance comprovam a sua robustez. Como referido anteriormente a alta disponibilidade apenas é garantida através da redundância, sendo por isso primordial a existência de dois servidores.

O HAproxy 1 é o servidor principal, o Haproxy 2 o servidor secundário e o Keepalived é responsável pela configuração do endereço IP virtual nos dois loadbalancers. A aplicação Heartbeat é responsável pela monitorização do estado do servidor de balanceamento, que em caso de falha do servidor principal e servidor secundário assume o balanceamento, sendo activado nele o endereço virtual recorrendo ao Keepalived. O HAProxy faz o redireccionamento dos pedidos para os servidores Web que estão em funcionamento. Caso ocorra algum problema com o servidor Web onde o cliente está ligado, o servidor de balanceamento reencaminha os pedidos para outro servidor, sendo que este processo é transparente para o cliente. Tendo em conta a forma de funcionamento deste servidor, podemos constatar que o mesmo se enquadra nos clusters de Alta disponibilidade.

De seguida são apresentados todos os passos necessários para proceder à instalação do HAproxy, Heartbeat e Keepalived. Todos os comandos e ficheiros devem ser executados de igual forma em ambos os servidores até que apareçam indicações contrárias. Todos os comandos devem ser executados como root para tal devemos executar o seguinte:

$ sudo –s

Para instalar o HAproxy devemos executar o seguinte comando:

# apt-get install haproxy

As configurações do HAProxy são guardadas em /etc/haproxy/haproxy.cfg antes de procedermos às configurações, devemos fazer um backup dos ficheiros originais e proceder à criação de novos com os seguintes comandos:

# cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_orig
# cat /dev/null > /etc/haproxy/haproxy.cfg

Agora vamos editar o ficheiro de configuração:

# vi /etc/haproxy/haproxy.cfg

Deve ficar assim:

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        #log loghost    local0 info
        maxconn 4096
        #debug
        #quiet
        user haproxy
        group haproxy

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        redispatch
        maxconn 2000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

listen webfarm 192.168.200.120:80
       mode http
       stats enable
       stats auth admin:olamundo
       balance roundrobin
       cookie JSESSIONID prefix
       option httpclose
       option forwardfor
       option httpchk HEAD /check.txt HTTP/1.0
       server server1 192.168.200.100:80 cookie A check
       server server2 192.168.200.101:80 cookie B check

Para activar o script de init devemos editar o ficheiro haproxy que se encontra na pasta /etc/default/

# vi /etc/default/haproxy

Verificar se a opção ENABLED é igual a 1, deve ficar assim:

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

Depois de instalar o HAproxy, devemos instalar o Heartbeat com o seguinte comando:

# apt-get install heartbeat

Para permitir o HAProxy utilizar endereço IP virtual partilhado, devemos editar o ficheiro /etc/sysctl.conf:

# vi /etc/sysctl.conf

Deve ficar assim:

net.ipv4.ip_nonlocal_bind=1

Depois de guardar o ficheiro, deve-se executar o seguinte comando:

# sysctl -p

A configuração do heartbeat é baseada em três ficheiros de configuração: /etc/ha.d/authkeys, /etc/ha.d/ha.cf e /etc/ha.d/haresources. Os /etc/ha.d/authkeys e /etc/ha.d/haresources devem ser idênticos no HAproxy1 e HAproxy2, o ficheiro /etc/ha.d/ha.cf difere apenas por uma linha. Para isso devemos executar os seguintes comandos:

# vi /etc/ha.d/authkeys

Deve definir a senha para autenticar o heartbeat do HAproxy 1 no HAproxy 2 e vice-versa:

auth 3
3 md5 olamundo

O ficheiro /etc/ha.d/authkeys deve ser lido apenas pelo root, para tal devemos executar o seguinte comando:

chmod 600 /etc/ha.d/authkeys

Atenção: O ficheiro ha.cf é diferente em ambos os servidores! Ficheiro ha.cf do HAproxy 1 Usar este comando para editar:

# vi /etc/ha.d/ha.cf

Fica assim:

#
#       keepalive: how many seconds between heartbeats
#
keepalive 2
#
#       deadtime: seconds-to-declare-host-dead
#
deadtime 10
#
#       What UDP port to use for udp or ppp-udp communication?
#
udpport        694
bcast  bond0
mcast bond0 225.0.0.1 694 1 0
ucast bond0 192.168.200.122
#       What interfaces to heartbeat over?
udp     bond0
#
#       Facility to use for syslog()/logger (alternative to log/debugfile)
#
logfacility     local0
#
#       Tell what machines are in the cluster
#       node    nodename ...    -- must match uname -n
node    balancer1
node    balancer2

Ficheiro ha.cf do HAproxy 2

#
#       keepalive: how many seconds between heartbeats
#
keepalive 2
#
#       deadtime: seconds-to-declare-host-dead
#
deadtime 10
#
#       What UDP port to use for udp or ppp-udp communication?
#
udpport        694
bcast  bond0
mcast bond0 225.0.0.1 694 1 0
ucast bond0 192.168.200.121
#       What interfaces to heartbeat over?
udp     bond0
#
#       Facility to use for syslog()/logger (alternative to log/debugfile)
#
logfacility     local0
#
#       Tell what machines are in the cluster
#       node    nodename ...    -- must match uname -n
node    balancer1
node    balancer2

Agora vamos editar o haresources para tal execute o seguinte comando:

# vi /etc/ha.d/haresources

Fica assim:

Balancer  192.168.200.120

Para terminar devemos iniciar o Haproxy com o seguinte comando:

#/etc/init.d/heartbeat start

Se tudo ocorrer como esperado, podemos aceder ao interface Web com informações referentes aos pedidos bem como o encaminhamento para diferentes servidores através do seguinte link http://192.168.200.120/haproxy?stats.

Todo o projecto foi desenhado em torno dos ervidores http, e pretende-se que os memos possam responder a um elevado número de pedidos garantindo disponibilidade e capacidade de resposta. Estes servidores tem como requisito garantir a execução de HTML, PHP 5, perl e suporte a Mysql. Relativamente ao servidor http, foi adoptado o Apache pelo facto de ser o servidor Web mais seguro e utilizado no mundo. Como referido anteriormente, este cluster é composto por 2 servidores, web1 e web2. Para potenciar o aumento da capacidade de resposta os servidores, estes utilizam uma arquitectura multicomputador recorrendo ao loadbalance sendo o HAproxy responsável pela distribuirão dos pedidos. Uma vez que o objectivo deste projecto é a utilização de hardware de baixo custo, foi excluída a possibilidade de utilização dispositivos de armazenamento de dados comum aos dois servidores (NAS Network-attached storage, etc.). Esta limitação obrigou a adopção de softwares que nos permitia sincronismo do directório do apache em tempo real, sem grande impacto de performance. Para esse efeito foi utilizado o GlusterFS. Quanto ao serviço de Mysql este é disponibilizado por um cluster dedicado ao efeito o qual será explicado de seguida.

O Gluster FS é um cluster de armazenamento de dados de alta disponibilidade, que nos permite agregar múltiplas unidades de armazenamento remotas num único volume. As unidades de armazenamentos denominam-se por bricks, distribuídas pela rede num único sistema de ficheiros paralelo. Esta arquitectura permite uma grande escalabilidade possibilitando a adição de milhares de bricks, resultando vários peta bytes de armazenamento. O GlusterFS baseia-se num sistema cliente servidor, podendo existir um ou mais servidores de ficheiros. Este sistema também permite que cada computador funcione como servidor. Grandes partes das funcionalidades facultadas pelo GlusterFS são implementadas através de tradutores (objectos binários carregados em tempo real). Estes objectos definem o interface de comunicação, de modo a que os mesmos possam ser carregados tanto por clientes como pelos servidores. O GlusterFs corre sobre Linux, FreeBSd, OpenSolaris, e MACX OS X. Este sistema de ficheiro também pode ser acedido por Windows recorrendo à partilhar via SAMBA. (GlusterFS)

De seguida são apresentados os passos necessários para a instalação do cluster http. Numa primeira fase são descritos os passos necessários para instalação e parametrização do Apache, para que possam interagir correctamente com o HAproxy. Posteriormente à referida instalação e parametrização, são descritos todos os passos necessários para a instalação do GlusterFS. Todos os comandos e ficheiros devem ser executados nos dois servidores que constituem o cluster http até que apareçam indicações em contrário.

Instalação do Apache

Se tudo correr como previsto o apache já esta a correr para validar essa situação podemos recorrer a um browser e aceder os seguintes endereços http://192.168.200.111 e http://192.168.200.112

Como o HAproxy está configurado no modo proxy transparente ele vai passar o endereço IP do computador original num campo chamado X-Forwarded-For. Com é óbvio os logs do servidor devem registar o endereço IP de origem e não o endereço do HAproxy. Para rectificar esse problema devemos editar o ficheiro /etc/apache2/apache2.conf e alterar o parâmetro LogFormat onde aparece %h por %\\\\{X-Forwarded-For\\\\}i : Para editar o ficheiro do configuração executar o seguinte comando:

# vi /etc/apache2/apache2.conf

Original:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%\\\\{Referer\\\\}i\" \"%\\\\{User-Agent\\\\}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%\\\\{Referer\\\\}i -> %U" referer
LogFormat "%\\\\{User-agent\\\\}i" agent

Deve ficar assim:

LogFormat "%\\\\{X-Forwarded-For\\\\}i %l %u %t \"%r\" %>s %b \"%\\\\{Referer\\\\}i\" \"%\\\\{User-Agent\\\\}i\"" combined
LogFormat "%\\\\{X-Forwarded-For\\\\}i %l %u %t \"%r\" %>s %b" common
LogFormat "%\\\\{Referer\\\\}i -> %U" referer
LogFormat "%\\\\{User-agent\\\\}i" agent

Como o HAproxy está constantemente a verificar a disponibilidade dos servidores com base no ficheiro /var /www/Check.txt, é importante desactivar os logs dessa operação porque provoca enorme crescimento dos logs e afecta as estatísticas geradas pelo Webalizer ou AWStats. Para resolver esse problema devemos executar as seguintes alterações:

# vi /etc/apache2/sites-available/default

Devemos adicionar as seguintes linhas:

SetEnvIf Request_URI "\\\\^/check\.txt$" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

Agora devemos criar o ficheiro check.txt na directoria do apache

# touch /var/www/check.txt

Feito isto apenas nos resta reiniciar o apache:

# /etc/init.d/apache2 restart

Depois de concluída a execução de todos os passos o apache já está pronto a servir conteúdos PHP, PERL e HTML. No entanto, é necessário garantir que os ficheiros e scripts constantes na raíz do apache são exactamente iguais em todos os servidores. Para tal, o GlusterFs foi configurado em modo cliente e servidor. Este tipo de abordagem garante-nos uma espécie de RAID 1 via Software. De seguida são apresentados todos os passos necessários para obter os resultados pretendidos:

Os comandos devem ser executados como root para tal devemos executar o seguinte: $ sudo –s

Antes de iniciar a instalação do GlusterFs devemos satisfazer todos os requisitos instalando os pacotes que se seguem:

# apt-get install sshfs 
# apt-get install build-essential 
# apt-get install flex 
# apt-get install bison 
# apt-get install byacc 
# apt-get install wget

Como o Fuse disponível nos repositórios apresentava alguma instabilidade, foi necessário proceder à sua instalação a partir do código fonte. Os comandos que se seguem devem ser seguidos à risca:

# mkdir /root/install/
# cd /root/install
# wget http://ftp.gluster.com/pub/gluster/glusterfs/fuse/fuse-2.7.4glfs11.tar.gz
# tar -zxvf fuse-2.7.4glfs11.tar.gz
# cd /root/install/fuse-2.7.4glfs11

A próxima etapa é compilar e instalar o Fuse

# ./configure
# make && make install

Depois vamos instalar o GlusterFS mais a partir do código fonte

# cd /root/install/
# wget http://ftp.gluster.com/pub/gluster/glusterfs/2.0/LATEST/glusterfs-2.0.4.tar.gz
# tar -zxvf glusterfs-2.0.4.tar.gz
# cd /root/install/glusterfs-2.0.4

Agora devemos compilar e instalar o GlusterFS:

# ./configure
# make && make install

Durante a compilação existem algumas bibliotecas que são compiladas para as directorias erradas. Para evitar problemas futuros devemos movelas para o local certo:

# cp /usr/local/lib/\\\\* -R /usr/lib/

Vamos criar as directorias que vão ser utilizados pelo cluster:

# mkdir /etc/glusterfs/
# mkdir /mnt/glusterfs
# mkdir /data/
# mkdir /data/export-ns
# mkdir /data/export

Agora vamos configurar o GlusterFS. É importante salientar que ambos os computadores correm tanto o GlusterFS em modo servidor e cliente. Desta forma é necessário configurar dois ficheiros. O glusterfs-server.vol e o glusterfs-client.vol.   Para tal devemos executar o seguinte comando:

# vi /etc/glusterfs/glusterfs-server.vol

Deve ficar assim:

volume posix
type storage/posix
option directory /data/export
end-volume
volume locks
type features/locks
subvolumes posix
end-volume
volume brick
type performance/io-threads
option thread-count 8
subvolumes locks
end-volume
volume posix-ns
type storage/posix
option directory /data/export-ns
end-volume
volume locks-ns
type features/locks
subvolumes posix-ns
end-volume
volume brick-ns
type performance/io-threads
option thread-count 8
subvolumes locks-ns
end-volume
volume server
type protocol/server
option transport-type tcp
option auth.addr.brick.allow
option auth.addr.brick-ns.allow
subvolumes brick brick-ns
end-volume

Se tudo estiver como pretendido já podemos iniciar o servidor:

# glusterfsd -f /etc/glusterfs/glusterfs-server.vol

Agora vamos activar o arranque automático do servidor do GlusterFs:

# chmod +x /etc/init.d/glusterfsd
# update-rc.d glusterfsd defaults

Alterar o ficheiro /etc/init.d/glusterfsd:

# vi /etc/init.d/glusterfsd

O parâmetro CONFIGFILE seve ser o seguinte

CONFIGFILE=/etc/glusterfs/glusterfs-server.vol

Uma vez configurado o modo servidor, agora vamos configurar o modo cliente:

# vi /etc/glusterfs/glusterfs-client.vol

Deve ficar assim:

# Adiciona condicao de cliente e anexa subvolume remoto no PC 1

volume brick1
type protocol/client
option transport-type tcp/client
option remote-host 192.168.200.100 \\\\# Computador 1
option remote-subvolume brick \\\\# Nome do volume remoto
end-volume

# Adiciona condicao de cliente e anexa subvolume remoto no PC 2

volume brick2
type protocol/client
option transport-type tcp/client
option remote-host 192.168.200.101 # Computador 2
option remote-subvolume brick # Nome do volume remoto
end-vdice 
volume brick1-ns
type protocol/client
option transport-type tcp/client
option remote-host 192.168.200.100 # Computador 1
option remote-subvolume brick-ns # Nome do volume remoto
end-vdice 
volume brick2-ns
type protocol/client
option transport-type tcp/client
option remote-host 192.168.200.101 # Computador 2
option remote-subvolume brick-ns # Nome do volume remoto
end-volume
  
# Volume replicado com dados
volume afr1
type cluster/afr
subvolumes brick1 brick2
end-volume
  
#Volume replicado
volume afr-ns
type cluster/afr
subvolumes brick1-ns brick2-ns
end-volume
  
# Junção  de todos os volumes afr (usado para > 2 servidores)
volume unify
type cluster/unify
option scheduler rr \\\\# round robin
option namespace afr-ns
subvolumes afr1
end-volume
volume afr-ns
type cluster/afr
subvolumes brick1-ns brick2-ns
end-volume
  
# Junção de todos os volumes afr (usado para > 2 servidores)
volume unify
type cluster/unify
option scheduler rr \\\\# round robin
option namespace afr-ns
subvolumes afr1
end-volume

Para finalizar basta arrancar o GlusterFS em modo cliente e utilizar a raíz do apache como ponto de montagem:

# glusterfs -f /etc/glusterfs/glusterfs-client.vol /var/www

Para terminar, vamos activar o arranque automático do GlusterFs em modo cliente com o seguinte script:

# vi /etc/init.d/glusterfs-clientd

Deve ficar assim:

ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin:/sbin"

do_start() \\\\{
        echo "Running ldconfig";
        ldconfig;
        sleep 1;
        echo "Running depmod -a";
        depmod -a;
        sleep 1;
        if \\\\[ -x /var/www \\\\] ; then
                HAVE_SAN=1
        else
                echo "Mount point: /var/www doesn\\\\’t exist creating..."
                mkdir /var/www;
        fi
        sleep 1;
        echo "Starting glusterfs";
        glusterfs -p /var/run/glusterfs.pid -f /etc/glusterfs/glusterfs-client.vol /var/www;


        # Add whatever else you want to start after gluster here
        # Imagine if we were serving /etc/nginx/nginx.conf off of gluster
        #echo "Starting nginx";
        #sleep 3;
        #/etc/init.d/nginx start;

 }

do_stop() {
      echo "Killing glusterfs";
      if kill $(cat /var/run/glusterfs.pid); then
              KILLED=1
      else
              KILLED=0
      fi
      sleep 3;

      echo "Unmounting /var/www";
      if umount -l /var/www; then
              UMOUNT=1
      else
              UMOUNT=0
      fi
}

do_restart() {
        do_stop;
        sleep 3;
        do_start;
}


case "$1" in
          start)
                do_start
                ;;
        restart|reload|force-reload) 
                do_restart
                ;;
        stop)
              do_stop
              ;;
esac

Finalmente, activamos o GlusterFs no arranque de sistema:

# chmod +x /etc/init.d/glusterfs-clientd
# update-rc.d glusterfs-clientd defaults

Depois de executadas todas as etapas até aqui descritas, obtêm-se sincronismo dos ficheiros constantes no directório raiz do apache de ambos os servidores web. Este sincronismo equipara-se a um sistema RAID1.

Tendo em conta que o objectivo deste projecto não pretere abordar alta disponibilidade em bases de dados, este servidor apenas servirá para facultar suporte a base de dados Mysql sem garantia de alta disponibilidade. No entanto este servidor tal, como todos os outros anteriormente instalados, implementa redundância ao nível de infra-estrutura de rede e módulo Bonding.

O processo de instalação do MySQL é descrito no seguinte link: Instalação do MySQL

Actualmente, a utilização de sistemas computacionais é de elevada importância para grande parte das actividades comerciais e tarefas do nosso quotidiano. Desta forma, a interrupção de um serviço de forma inesperada pode causar um enorme transtorno para todos os utilizadores do sistema. A utilização de redundância é uma das melhores forma de colmatar esse problema, no entanto a aquisição de sistemas proprietários podem inviabilizar a sua execução devido ao elevado custo de implementação e manutenção. Neste projecto foi realizado um estudo de alternativas para a implementação de servidores Web de alta disponibilidade recorrendo a software livre. O maior desafio foi encontrar uma solução que para além de redundância de software e hardware nos possibilitasse redundância dos dados existentes na raiz do apache em tempo real e simultaneamente todos os membros do cluster pudessem responder a pedidos. Esse desafio foi ultrapassado com a utilização do GlusterFS e HAproxy. Os clusters implementados e testados garantem resultados ao nível de soluções comerciais com custo de implementação muito reduzidos, o aumento de qualidade e disponibilidade de serviços é notório. Actualmente existem grandes empresas que utilizam este tipo de soluções como suporte aos seus sistemas computacionais. É com enorme satisfação que podemos constatar que a maturidade dos sistemas Linux e software Open Source para este fim permite a sua adopção em sistemas de missão crítica tanto em pequenas como grandes organizações. Como recomendação para trabalhos futuros seria interessante a implementação de um cluster de base de dados recorrendo a sistemas de ficheiros como o OCFS2 e GFS. Este tipo de abordagem potenciava a implementação de dois nós Mysql em modo de balanceamento de carga. Resultando um sistema de alta disponibilidade e balanceamento com incremento de performance.

Apache.org. (s.d.). Obtido em 18 de Agosto de 2009, de Apache HTTP Server Project: http://httpd.apache.org/docs/2.2/

Edmundo Monteiro, F. B. (2000). Engenharia de Redes Informáticas 4ª Edição. FCA.

Exceliance load balancing. (s.d.). Obtido em 25 de Agosto de 2009, de Exceliance load balancing: http://www.exceliance.fr/en/index.htm

GlusterFS. (s.d.). Obtido em 14 de Agosto de 2009, de GlusterFS – Highly Scalable Clustered Storage : http://www.gluster.com/community/documentation/index.php/GlusterFS

Keepalived. (s.d.). Obtido em 17 de Agosto de 2009, de keepalived project : http://www.keepalived.org/

Linux-HA Project. (s.d.). Obtido em 25 de Agosto de 2009, de Open Source High-Availability Software: www.linux-ha.org

Loureiro, P. TCP-IP em Redes Microsoft Para Profissionais. FCA.

MySQL Documentation. (s.d.). Obtido em 15 de Agosto de 2009, de MySQL: http://dev.mysql.com/doc/

Netcraft Ltd – Internet Research, Anti-Phishing and PCI Security. (s.d.). Obtido em 5 de Setembro de 2009, de Netcraft Ltd: http://news.netcraft.com/

Pitanga, M. (2003). Computação em Cluster. Rio de Janeiro: Brasport.

RedWall Firewall . (s.d.). Obtido em 25 de Agosto de 2009, de RedWall: http://www.redwall-firewall.com/

Ruponi, V. (2004). Towards Zero Downtime: High Availability Blueprints. Authorhouse.

Stern, E. M. (2003). Blueprints for High Availability. Authorhouse.

The Beowulf Cluster Site. (s.d.). Obtido em 10 de Agosto de 2009, de Beowulf.org: http://www.beowulf.org/overview/history.html

The Reliable, High Performance TCP/HTTP Load Balancer. (s.d.). Obtido em 12 de Agosto de 2009, de HAProxy: http://haproxy.1wt.eu/