Alta disponibilidade com Baixo custo

Disponibilidade também é segurança

A agilidade requerida pelas corporações no cenário globalizado, exige soluções tecnológicas que possibilitem a sua presença contínua no universo virtual. Dependendo do seu porte e tipo de negócio, alguns minutos de indisponibilidade de seus sistemas computacionais podem representar perdas de milhares de reais (ou dólares).

Como a segurança da informação está fundamentada na tríade: Confidencialidade (permitir o acesso à informação somente a quem tem direito), Integridade (garantia de que a informação seja recuperada tal como foi armazenada) e Disponibilidade (a informação tem que estar disponível sempre que se fizer necessário), vamos abordar hoje uma solução de alta disponibilidade.

Normalmente quando pensamos em tais sistemas, imaginamos logo o cenários de grandes corporações, com servidores robustos, redundantes, storage com discos em RAID-5, robôs para backup, etc. Mas, fazendo uso de softwares livres, é possível construir sistemas de alta disponibilidade, investindo muito pouco.

Cenário típico

Vamos imaginar que uma empresa quer investir no comércio eletrônico, construindo um site para fazer vendas e/ou prestar algum tipo de serviço on-line. É sabido que esse tipo de site deve permanecer 24 horas por dia disponível para que seus clientes possam acessar quando desejarem, caso contrário, o eles procuram imediatamente outro site similar, traduzindo-se em prejuízo para a empresa.

Com esse cenário hipotético em mente, vamos desenvolver uma possível solução.

A alta disponibilidade pode ser provida através de dois links de internet de operadoras diferentes, conectados à um appliance firewall/load balancer que por sua vez fará o balanço de carga para dois servidores web respondendo pela camada de apresentação da aplicação. Cada servidor web fará acesso a um servidor de aplicações, cabendo à aplicação do servidor web comutar o acesso ao outro servidor de aplicações em caso de ausência de resposta do seu servidor primário. Ambos servidores de aplicações estarão acessando um único gerenciador de banco de dados por questões de integridade. O gerenciador de banco de dados será replicado em um servidor secundário, formando um cluster de alta disponibilidade com dois nós, o qual assumirá as transações em caso de failover do servidor primário, de forma transparente para a aplicação.

[Figura1] Esquema lógico com uso de storage.

As soluções mais comuns de alta disponibilidade para banco de dados prevêem a utilização de storages compartilhados entre os servidores do cluster, entretanto, essa solução apresenta o inconveniente de ter os storages como único ponto de falha, além de ser um equipamento adicional que pode representar uma parcela significativa do orçamento.

A solução que apresentamos, consiste na utilização do software DRBD – Distributed Replicated Block Device (http://www.drbd.org), que é largamente utilizada pela comunidade de software livre para implementar espelhamento de dispositivos de blocos (disco) entre dois servidores. Maiores detalhes serão abordados mais abaixo.

[Figura 2] Alta disponibilidade com uso de DRBD

As linhas pontilhadas representam caminhos alternativos entre os servidores web e o banco de dados.

Outro ponto de falha existente na solução é o Load Balancer, mas podemos considerar como um risco menor por se tratar de um dispositivo inteiramente “estado sólido”, sem uso de componentes mecânicos e cuja falha pode ser contornada com a conexão direta entre os roteadores e os servidores web.

Esse ponto de falha pode ser eliminado com uso de dispositivos que suportem redundância ou até mesmo com uso softwares como o UltraMonkey (http://www.ultramonkey.org/), também lar­gamente utilizado pela comunidade para prover balanceamento de carga.

[Figura 3] Load Balance com UltraMonkey

Essa solução é baseada no uso de sistema operacional Linux em máquinas redundantes, formando um cluster de alta disponibilidade com uso do Heartbeat (http://www.linux-ha.org).

A Arquitetura de Software

Como já foi citando anteriormente, a solução baseia-se totalmente no uso de softwares livres para evitar custos com licenciamento de softwares. Os servidores devem utilizar o sistema operacional Linux. Pessoalmente indicaria Debian ou Ubuntu Server por questões de facilidade de manutenção, mas distribuição Linux é como religião: cada um tem a sua preferência e não se discute.

As aplicações podem ser desenvolvidas com uso de tecnologias Java, por serem largamente utilizados e portáveis em sua essência.

Os servidores web podem ter suas funcionalidades atendidas pelo uso de Apache Tomcat e JSF (Java Server Faces) para o desenvolvimento da camada de apresentação das aplicações.

A camada de negócios pode ser desenvolvida na plataforma EJB – Enteprise Java Beans, executando em servidores de aplicações, lançando mão do JBoss ou GlassFish.

O EJB é um dos principais componentes da plataforma J2EE (Java 2 Enterprise Edition). É um componente do tipo servidor que executa no container do servidor de aplicação. Os principais objetivos da tecnologia EJB são fornecer um rápido e simplificado desenvolvimento de aplicações Java baseado em componentes distribuídas, transacionais, seguras e portáveis. O seu uso permite que aplicações da camada de apresentação criem instâncias de objetos remotos, de forma semelhante à tecnologia de web services, sendo que de forma mais robusta para soluções baseadas em Java.

O banco de dados utilizado pode ser o PostgreSQL, que, apesar de ser de uso livre, é tão robusto e estável quanto as soluções comerciais e comparáveis ao banco de dados Oracle, que hoje é referência de mercado.

A Solução para Alta Disponibilidade

O ponto chave da solução está no emprego do espelhamento do disco com uso do DRBD, aplicado aos servidores de bancos de dados, em conjunto como o uso do Heartbeat para prover alta disponibilidade através do recurso de failover.

Na figura seguinte, temos a representação de um cluster formado por dois servidores, sendo um primário que responde por todas as conexões provenientes da rede.

[Figura 4] Alta disponibilidade com Heartbeat.

O Heartbeat, executando no servidor secundário monitora constantemente o servidor primário. Havendo indisponibilidade do servidor primário, inicia-se o processo de failover e todas as funcionalidades são assumidas pelo secundário, havendo inclusive transferência de endereço IP, de tal forma que os clientes não são afetados, acessando os serviços pelo mesmo endereço IP inicial.

Uma vez que o servidor primário volte a ficar disponível, inicia-se o processo de failback, onde todas as funcionalidades são devolvidas do servidor secundário para o primário.

Para que o processo de transição entre os servidores primário e secundário seja efetiva, é necessário que os dados estejam replicados em ambos servidores, de forma consistente. Isso é obtido pelo uso do DRBD que “intercepta” todas as requisições de gravação em disco no servidor primário e replica para o servidor secundário através de um link de rede de alta velocidade, exclusivo entre os servidores e independente da infra-estrutura de rede local.

[Figura 5] DRBD em detalhes.

Essa conexão é obtida pelo uso de interfaces Gigabit Ethernet e cabo cross-over entre os servidores, que se comunicam de forma exclusiva por esse meio.

O Heartbeat do servidor secundário também utiliza essa conexão Gigabit para monitorar o estado do servidor principal e controlar as ações de failover e failback.

Quando o servidor primário retorna após uma condição de off-line, o DRBD se encarrega de fazer a sincronização dos discos, antes de efetivar as ações de failback. O mesmo ocorre se o servidor secundário ficar off-line, com a diferença que não é tomada nenhuma ação de failover/failback.

O DRBD pode trabalhar de duas formas: síncrona, onde as informações são gravadas simultaneamente nos dois servidores, ou assíncrona, onde a gravação entre os servidores são feitos de forma independentes, sendo mais indicado para conexões de baixa velocidade, como no caso se servidores fisicamente distantes.

Detalhes da Solução

Os links de internet, com velocidade inicial de 2 Mbps devem ser fornecidos por diferente operadoras de telecom, para prover redundância no acesso à internet. Preferencialmente, os pontos de entrada no prédio devem ser feitos em locais diferentes para minimizar os riscos de queda por fatores externos como um acidente de trânsito, por exemplo, que venha a derrubar um poste por onde passam os cabos de comunicação.

Os roteadores devem ser alugados como parte do contrato de prestação de serviços das operadoras, e devem prever a reposição dos mesmos em caso de pane, dentro no menor tempo possível, também previsto no SLA – Service Level Agreement (acordo de qualidade de serviço) do contrato.

Os endereços de ambas operadoras responderão pelo domínio de internet da empresa, cuja alternância pode ser provida pelo servidor DNS.

Uma vez que as requisições de conexões provenientes da internet cheguem ao site da empresa, o Load Balancer faz a distribuição das requisições entre os dois servidores web disponíveis. Esse dispositivo também pode cumprir a função de firewall de borda, provendo a segurança da rede em primeira instância.

Os servidores web e de aplicações (dois de cada) são localizados na DMZ, independentes entre si, com a mesma cópia da aplicações rodando em cada par de servidores e acessando o servidor de banco de dados localizado na rede interna.

Os servidores web e de aplicações poderiam rodar em cluster, mas não foram feitos dessa forma, para distribuir a carga entre diferentes servidores ao invés de trabalhar somente com um, deixando ou outro em stand-by.

O firewall interno isola a DMZ da rede interna, provendo a segurança em profundidade, agindo como uma segunda barreira de contenção caso o firewall externo seja comprometido (invadido). Ele também tem a finalidade de controlar o acesso aos servidores da rede, feitos a partir das estações da rede local, a fim de proteger contra ataques internos.

Para finalizar a infra-estrutura de alta disponibilidade, deve-se considerar as alternativas para a manutenção do fornecimento de energia elétrica. Como geralmente não é posível contar com diferentes fornecedores de energia elétrica, é necessário fazer uso de no-breaks e gerador de energia de emergência para suprir a alimentação dos equipamentos principais por um tempo superior ao tempo suportado pelo no-break.

Topologia Física da Solução

O diagrama a seguir, apresenta a configuração final da topologia física da solução, evidenciando as áreas distintas:

DMZ: Servidores que fornecem serviços para internet

Rede Local – Servidores: Segmento de rede exclusivo para servidores, protegidos pelo firewall interno.

Rede Local – Estações: Segmento de rede destinado às estações de trabalho da rede local.

[Figura 6] Topologia física da solução.

Nesse diagrama, foram incluídos um servidor e e-mail e DNS primário. O DNS secundário é respondido por um servidor interno, acessível pelo mapeamento de porta (port forward) feito pelo firewall interno.

Considerações finais

A solução ora apresentada visa atingir um ambiente de alta disponibilidade, a um custo reduzido pelo emprego de tecnologias de software de uso livre mas nem por isso, menos confiável ou de menor desempenho, sendo largamente aceitas como soluções mercado e endossadas por nomes de peso como IBM e Red Hat.

——

Adicione um comentário.