Alta disponibilidade em servidores Linux
Requisito fundamental em sistemas que ficam no ar 24 horas por dia, sete dias por semana, durante anos

Andre Ruiz
andre@conectiva.com.br

Quanto mais os computadores ganham espaço nas empresas, nos escritórios e na vida das pessoas em geral, mais se houve falar em "alta disponibilidade". Por um simples e bom motivo: nenhum usuário quer que sua máquina pare, de repente, de funcionar. E é justamente a alta disponibilidade que vai garantir a continuidade de operação do sistema na prestação de serviços de rede, armazenamento ou processamento, mesmo se houver falhas em um ou mais de seus elementos.

Assim, alta disponibilidade é hoje um assunto que interessa a um número cada vez maior de usuários. E, sem dúvida, tornou-se um requisito fundamental em sistemas que ficam no ar 24 horas por dia, sete dias por semana, ou que não aguentam paradas de meia hora ou até mesmo de alguns minutos. Afinal, paradas não planejadas podem comprometer, no mínimo, a qualidade do serviço, sem contar o prejuízo financeiro.

Em 1995, dois estudos patrocinados pela Oracle Corporation e a Datamation mostraram que empresas diversas por todo os Estados Unidos perderam, em média, US$ 80 mil a US$ 350 mil por hora de paralisação não planejada. Vale lembrar que prevenir é melhor do que remediar, mesmo que nem sempre saia mais barato, mas há a vantagem de se saber quanto se está gastando.

Já uma parada crítica pode causar prejuízos incalculáveis e, dependendo do sistema, até mesmo a perda de vidas.

Tudo isso passa a ter ainda mais sentido quando consideramos os baixos preços das plataformas Intel-PC existences hoje, e a possibilidade de rodar sistemas operacionais free Unix-like, como o Linux e o FreeBSD.

A situação ideal, sem dúvida, é um "cluster de alta disponibilidade", em que as máquinas são usadas em conjunto para processar transações paralelamente (diferente de processamento paralelo), replicando serviços e servidores, o que evita máquinas paradas, ociosas, esperando apenas a outra falhar. E no caso de alguma delas cair, as demais continuam atendendo normalmente.

Perdas na performance ou na capacidade de processamento são normalmente aceitáveis; o objetivo principal é não parar. Existem algumas exceções, como sistemas de tempo real e de missão crítica.

Conceitos mais utilizados

Para familiarizar-se com o mundo da alta disponibilidade, vale a pena conhecer alguns termos e conceitos mais comuns:

Recurso: é o próprio objeto de trabalho dos mecanismos de alta disponibilidade, algo que se pretende manter disponível continuamente. Pode ser um serviço da rede, um sistema de arquivos, discos, processador entre outros.

Failover: quando um recurso de uma máquina apresenta uma falha, outra máquina do sistema deve assumi-lo, de forma transparente para os usuários. A máquina não precisa necessariamente parar por completo, basta que o recurso protegido pare.

Failback: é o oposto do failover, o elemento que falhou retoma seu estado normal e é colocado (manual ou automaticamente) de volta para trabalhar.

High Availability: Alta disponibilidade em inglês (também usado como HA).

Transferência de estado: quando uma máquina executa o failback, ela pode estar desatualizada em relação à que a substituiu. Ela então realiza uma transferência de estado para sincronizar os recursos de ambas as máquinas, mantendo a consistência.

Single point of failure (SPOF) ou ponto único de falha: é usado para identificar um recurso que não possui alta disponibilidade.

Uma falha em um SPOF comprometerá todo o sistema independentemente de quão protegidos estejam outros recursos.

Disponibilidade contínua: implica em serviço "non-stop", sem intervalos. Representa um estado ideal, e geralmente é um termo usado para indicar um altíssimo grau de disponibilidade, no qual apenas uma pequena quantidade de "downtime" é permitida. Alta disponibilidade não implica em disponibilidade contínua.

Tolerância a falhas: significa altíssima disponibilidade. Um sistema que tolera falhas tem a habilidade de continuar servindo independentemente de uma falha de hardware ou de software, e é caracterizado por redundância em hardware, incluindo CPU, memória e subsistema de I/O. Alta disponibilidade não implica em tolerância a falhas.

Cluster: agrupamento de recursos que fornecem ao sistema a ilusão de um recurso único. Exige um mecanismo de gerência (Birman, Pfister) e permite alta disponibilidade, escalabilidade e alto desempenho. Por definição, implica em dois ou mais computadores juntos fazendo o serviço que normalmente uma máquina faria sozinha. Existem basicamente cinco tipos de clusters: HA (Alta Disponibilidade), FT (Fault Tolerance), MPP (Massive Parallel Processing), SMP (Simetric Multiprocessing) e NUMA (Non-uniform Memory Access). Essas categorias não são mutuamente exclusivas e devem ser consideradas características individuais que definem um cluster. De qualquer forma, uma delas se sobressairá.

Falha (fault): um comportamento inesperado do sistema em uma situação aparentemente normal, um desvio da especificação do sistema. Ocorre no universo físico.

Erro (error): manifestação visível da falha, que pode ser percebida pelo usuário/programador, porém, sem permitir a identificação da causa ou a localização da falha em si. Ocorre no universo lógico.

Defeito (fail): desvio da especificação, causado pelo erro. O sistema fornece respostas/reações incorretas. Ocorre no universo do usuário. A relação causal é: falha –> erro –> defeito. Um erro é, portanto, a interpretação lógica de uma falha, e um defeito é uma manifestação de um erro percebida pelo usuário.

Parada planejada: quando o sistema é paralisado intencionalmente para manutenção, upgrade, ou para qualquer outra tarefa que exija o sistema fora de funcionamento.

Parada não planejada: quando o sistema sai do ar inesperadamente. São as paradas não planejadas que a alta disponibilidade tenta evitar.

Enganos comuns

No cálculo da disponibilidade de um sistema leva-se em conta normalmente apenas as paradas não planejadas, pois são as que queremos impedir. No entanto, esses cálculos deveriam considerar também as paradas planejadas. Por isso, ao adotar uma solução, preste atenção na quantidade de paradas planejadas que o produto exige para manutenção. Quanto menos paradas planejadas, melhor a solução.

Outro ponto que causa confusão é o termo "clusters", que é um modelo mais genérico e não necessariamente de alta disponibilidade. Com sua crescente popularidade, eles estão sendo muito utilizados em várias áreas na última década, incluindo aplicações de missão crítica. Essas aplicações são tipicamente não tolerantes a falhas, e requerem que o sistema em que elas rodam tenha um "downtime" baixíssimo, independente de ter sido planejado ou não.

Pode-se até ter um cluster em que todo o serviço é perdido, caso um dos nodes pare. Existem clusters para processamento paralelo e clusters para distribuição e balanceamento de tráfego e de carga para serviços de uso intensivo, entre outros, mas nenhum desses será considerado de alta disponibilidade enquanto houver SPOFs que comprometam todo o sistema, e não existir nenhum mecanismo que gerencie as possibilidades de HA.

Isso naturalmente levou a uma forte demanda por soluções de alta disponibilidade também para os ambientes de clusters, e a maioria dos grandes fornecedores da indústria atual estão oferecendo soluções para alta disponibilidade, com garantias de uptime variáveis. Em resumo, alto desempenho e balanceamento de carga em um cluster não significam, por si sós, alta disponibilidade.

Deve-se também tomar cuidado com a expressão "tolerância a falhas", que está fortemente ligada a soluções proprietárias e geralmente por hardware (redundância de equipamento). Alta disponibilidade é um subconjunto de tolerância a falhas.

Quando se utiliza um hardware adicional em alta disponibilidade, não se tem necessariamente a intenção de aumentar a performance do sistema como um todo, nem mesmo processar transações paralelamente, mas sim de que este hardware fique de prontidão para entrar em funcionamento caso o hardware principal falhe.

Técnicas de hardware e software

A alta disponibilidade pode ser alcançada de várias formas e em vários níveis. O espectro de soluções possíveis tem dois extremos: os casos em que apenas um hardware especializado é usado para criação de redundância, e os casos que são totalmente implementados por software com equipamento padrão, sem modificações.

A primeira categoria oferece maior grau de segurança, mas é muito mais cara, o que tem levado esta última a uma maior popularidade, com vários vendedores de sistemas computacionais oferecendo diversos níveis de alta disponibilidade por software. É claro que uma boa solução pode eventualmente mesclar recursos das duas categorias para obter resultados melhores, sem que se gaste muito.

Redundância é a idéia básica, a palavra-chave, das soluções de hardware. Existem algumas soluções de alta disponibilidade que se utilizam de hardware, mas a maioria é considerada "tolerância a falhas", uma expressão usada comercialmente. Se um equipamento falhar, deve haver outro, devidamente preparado e sincronizado, para assumir seu lugar de forma imediata e transparente (discos duplicados e/ou espelhados em soluções RAID por hardware, processadores duplicados etc.). Isso se aplica a discos, rede, enfim, qualquer recurso necessário para o correto funcionamento do sistema.

Na área de software, em que o termo alta disponibilidade está realmente sendo utilizado, o objetivo é obter a continuidade de serviços sem o uso de um hardware especial e caro. Por serem mais baratas, as técnicas de software são muito mais comuns e mais amplamente utilizadas. Entre elas podemos citar:

IP Takeover: quando uma máquina, ou um serviço dessa máquina sai do ar, uma segunda máquina assume seu endereço IP, passando a responder por ela. Muitas vezes é necessário causar propositadamente uma parada geral na primeira máquina, caso ela não tenha saído totalmente do ar, até que esteja em condições de um failback, manual ou automático.

Espelhamento local ou via rede: é uma espécie de "RAID 1 via rede", em que um disco de uma máquina é espelhado em outra máquina através da rede, para que esta tenha dados atuais no caso de a primeira falhar. O espelhamento também pode ser feito localmente, tudo via software. Aqui também entram os sistemas de arquivos distribuídos (CODA, por exemplo).

DNS Rotativo: este sistema é simples e fácil de ser implementado em sua maneira básica. Basta atribuir mais de um endereço IP a um mesmo nome de máquina, e o DNS irá responder às requisições de forma "circular" (uma vez cada endereço), balanceando assim o tráfego entre os servidores. A alta disponibilidade entra em cena quando se utilizam versões modificadas de servidores de DNS, que monitoram se a máquina está ok antes de servir seu endereço, até mesmo usando o estado da carga de CPU das máquinas para decidir quem terá prioridade (em alternativa ao sistema "circular").

Projetos em Linux

Especificamente para Linux, existem projetos em andamento, dos quais podemos citar alguns open source: Heartbeat, LVS (Linux Virtual Server), Eddie, DRBD, Fake, Mon, Big Brother, Failover (veja mais no Apêndice, ao final deste artigo).

Um dos maiores projetos atualmente é o "High-Availability Linux Project" www.linux-ha.org.

O atual estado do projeto é relatado no site, e no momento ele está sendo considerado "bastante interessante e útil". Existem cerca de seis sites produtivos no mundo real rodando protegidos pelo projeto (oficialmente). É um projeto aberto, todas as ferramentas envolvidas são open source, e está disponível a qualquer interessado.

O projeto Linux-HA atualmente está trabalhando na melhoria do utilitário "Heartbeat", que faz monitoramento e takeover (já funcionando relativamente bem) e já pode ser aplicado em alguns casos como servidores DNS, Proxy Caching, Web e LVS director, e qualquer outra coisa que tenha replicação própria dos dados e manutenção de estado mínima (stateless applications). A Conectiva está oficialmente mantendo o pacote do Heartbeat, e irá liberar uma versão melhorada em sua próxima versão do Conectiva Linux (edição servidor 5.1).

Outro grande projeto é o chamado LVS (Linux Virtual Server). Ele parte para uma solução um pouco diferenciada, em que uma máquina é colocada no "front-end" recebendo conexões externas e repassando essas conexões, de uma maneira balanceada, para o "cluster" que ela esconde do "lado de dentro". A alta disponibilidade é atingida através de monitoramento das máquinas que fazem parte do cluster, e quando alguma delas falha, ela é excluída da lista de máquinas receptoras de pacotes. Com isso, há uma queda na performance, mas não se compromete o sistema como um todo.

Uma solução como esta tem ainda a vantagem de possibilitar que se adicione mais máquinas ao cluster, ao invés de fazer upgrade nas máquinas existentes. Cada máquina pode ter um "peso" diferente no algoritmo de decisão de roteamento, para receber mais ou menos requisições em relação às outras. Isso pode ser usado para compensar a diferença de poder de processamento entre elas.

Apêndice

As informações abaixo foram extraídas e traduzidas do Linux High Availability Overview, no website HA.

Introdução:

Projeto iniciado em 1997: Linux HA HOWTO; inspirado em um produto comercial; desenvolvimento bastante centralizado;

Informações: www.henge.com/~alanr/ha/

Hoje existem mais de dez projetos ou soluções, algumas free (sob qual for a licença) e outras comerciais, e logo surgirão mais "ports" de soluções comerciais;

Poucas soluções são de uso genérico, a maioria prevê apenas websites ou firewalls;

Clustering: Computação distribuída x Alta disponibilidade.

Heartbeat: www.henge.com/~alanr/ha/

Disponível, usável, incompleto;

Pode fazer: comunicação intra-cluster de propósito genérico;

Heartbeat (monitoramento) através de diferentes meios, serial/UDP/Broadcast; IP Takeover, API de aplicação; informação para balanceamento de tráfego; facilmente adicionar outras mídias para o heartbeat (monitoramento);

Não pode monitorar mais do que dois nodes ou múltiplas interfaces de rede. Ainda tem muita coisa a fazer.

Heart: www.lemuria.org/Heart/

Framework básico para implementação de HA (Alta Disponibilidade);

Desenvolvido com a Web e os bancos de dados em mente; IPAT (IP Address Takeover) é o método padrão;

Tenta ser o mais genérico possível;

Mantém um database distribuído do status de cada node;

Chama scripts externos para tomar as atitudes apropriadas;

Não existe ainda documentação real disponível.

Failover: failover.othello.ch/

Portado do Solaris para o Linux;

Trabalha orientado para o serviço e não para o servidor;

Tem o conceito de masters e slaves;

Baseado em TCL;

Está sob GPL mas não pode ser portado para plataformas M$, o que é uma violação da GPL;

Pode fazer IPAT (IP Address Takeover) em interfaces virtuais;

Pode publicar traps de SNMP.

Failoverd: www.ps-ax.com/failoverd/

Provê capacidade rudimentar para failovers;

Não é 100% específico para Linux, escrito em Perl;

Dispara scripts com argumentos start/stop;

Usa ping como mecanismo de heartbeat (monitoração);

Usa PLIP como mecanismo de heartbeat secundário;

Licença GPL;

Aparentemente necessita de mais esforço para se tornar maduro.

Fake - Redundant Server: linux.zipworld.com.au/fake/

Desenvolvido para trocar servidores backup por servidores primários em uma LAN; aplicável facilmente em servidores Mail, Web e Proxy;

Faz IPAT (IP Address Takeover) e ARP spoofing;

Interface adicional pode ser tanto uma interface primária quanto uma virtual;

Desenvolvido para cooperar com Heartbeat ou Heart;

Não pode fazer failover de disco;

Apresentado na Linux Expo May 98.

LVS - Linux Virtual Server Project: proxy.iinchina.net/~wensong/ippfvs/

Objetivo primário: balanceamento de carga e alta disponibilidade distribuídos por um cluster de servidores representados por um único "servidor virtual";

Usa apenas uma máquina para "servidor virtual", e usa o fake para ativar um backup caso esta máquina pare (redundância);

Pode usar NAT, tunneling ou Direct Routing como métodos de re-envio dos pacotes;

Não pode fazer failover de discos, ainda.

Eddieware: www.eddieware.org/

Objetivo primário: escalabilidade de servidores web;

Disponibilidade: EPL (Erlang Public License -source code downloadable); derivado do Mozilla PL;

Consiste de: um servidor de balanceamento de http (Intelligent HTTP Gateway), um servidor de DNS "aprimorado", estrutura de servidor de duas camadas (frontend e backend);

Faz IPAT (IP Address Takeover) e re-roteamento de tráfego após falha do servidor;

Disponível para Solaris, Linux, FreeBSD (NT em breve).

TurboLinux Cluster: community.turbolinux.com/cluster/

Provê alta disponibilidade para roteadores e servidores

(oficialmente aceita apenas http);

Baseado no LVS (Linux Virtual Server), mais alguns "pedaços" de outros projetos, mais um pouco de código proprietário; patch no kernel mais algumas idéias vindas do LVS; ferramentas para instalação e configuração e gerenciamento; usa ping e protocolos específicos para checagem dos nodes; usa devices "tunneling" nos servidores;

Preço não definido: provavelmente algo como US$ 1 mil por node;

Patch do kernel será GPL: licenças do tclusterd e ferramentas de configuração/monitoração ainda não foram anunciadas.

RSF-1 (Resilient Server Facility): www.rsi.co.uk/

Não se posiciona como uma solução especializada –> uso geral;

Aceita dois nodes e dois serviços (V2.0: 16 / 240);

Heartbeat (monitoramento) de IP e não-IP (RS232 e disco);

Pode fazer failover manual ou automático;

Multiplataforma;

Aceita balanceamento de carga, movendo aplicações entre máquinas;

Aceita "disaster recovery" por espelhamento geográfico;

Sites dispersos;

Portado do Solaris — mais plataformas por vir: AIX, NT, FreeBSD.

Wizard Watchdog:www.wizard.de/

Uso genérico, orientado para o serviço e não para o servidor;

Recursos compartilhados livremente, como discos, rede

e aplicativos para um serviço;

Limite (teórico) é de 65536 nodes;

Failovers cross-plataform (Solaris/Linux);

Usa "Network Attached Storage";

API para: mensagens de status de objetos específicos, monitoramento e eliminação de erros de qualquer objeto

de software, suporte para qualquer software de gerenciamento de disco ou RAID;

Monitor de serviço com Java GUI e agente capaz de SNMP;

Portado do Solaris: tem histórias de sucesso, como o cluster de serviços em um canal popular de esportes alemão (DSF);

Custo um pouco alto, mas ainda barato se comparado ao HACMP.

BIG/ip:www.f5.com/

Objetivo primário: server load balancing;

Solução de duas camadas combinadas, software/hardware;

Três produtos: BIG/ip LB, BIG/ip HA e BIG/ip HA+ (diferentes níveis de serviços);

Usa NAT (Network Address Translation) para proteger portas conhecidas (80, 22, 23 etc.);

ID persistente em secção SSL;

BIP/ip HA + DNS ~ 100-120K USD.

Net/Equater: www.bscsoft.com/

Desenvolvido por BSCsoft;

Solução para HA e load balancing;

Segue a técnica "Shared Nothing" (não faz failover de disco);

Usa a seguinte terminologia: partições lógicas, em que o

tráfego é balanceado; aplicações "plexes", que distribuem o load entre os servidores físicos;

Preço e licença desconhecidos.

IBM WebSphere Performance Pack: www.software.ibm.com/webservers/perfpack/about.html

Load balancing entre servidores web físicos dentro

de um "WebSphere Setup";

Integra: SecureWay Network Dispatcher (load balancing), Web Traffic Express (cache e proxy), Andrew File System (Transarc AFS);

Atualmente em Solaris, NT, AIX e Linux.

O que está faltando?

Filesystiem com Journal:

Garante integridade dos metadados no filesystem; não garante integridade dos dados (isso é tarefa da aplicação); permite checks de fsck rápidos depois de uma falha; deverá estar no kernel 2.3 (Stephen Tweedie);

Raw I/O:

Resolve o problema do fsck — alguns databases apenas;

ftp.uk.linux.org/pub/linux/sct/fs/

Soluções:

CODA ( coda.cs.cmu.edu/ ), lida com sites desconectados corretamente; GFS ( gfs.lcse.umn.edu/ ), lida com Dlock (Seagate, Mylex etc) para implementar um Gerenciador de Lock Distribuído; SGI está portando e abrindo os fontes do XFS.

O kernel do Conectiva Linux Ed. Servidor 5.1 terá o ReiserFS (filesystem com Journal) já incorporado. Este filesystem tem se mostrado incrivelmente rápido e confiável.

Outras ferramentas

Mon: www.kernel.org/software/mon/

Sistema de monitoramento de uso geral, que pode ser usado para monitorar um serviço, um servidor, condições ambientais, como temperatura de uma sala, ou um grande número de outras coisas.

Piranha: www.redhat.com/support/wpapers/piranha>

Piranha é um produto para clustering da RedHat, e inclui o código do LVS para o kernel, uma ferramenta gráfica para configuração do cluster e uma ferramenta de monitoração do cluster. O whitepaper do piranha e o Piranha HOWTO estão disponíveis no website da RedHat. O RPMS e o SRPMS do Piranha podem ser achados na distribuição do RH 6.1, ou podem ser baixados no site ftp.redhat.com.