O uso de sistemas móveis está sendo amplamente disseminado entre as empresas, com a promessa de aumentar a produtividade e acelerar seus processos. No entanto, para que esse objetivo seja atingido, todos os sistemas envolvidos seja cliente ou servidor, hardwares ou softwares, precisam funcionar de forma ininterrupta, 24×7. Diversas situações podem interromper esse processo, desde problemas físicos nos equipamentos até falhas nos sistemas. O objetivo deste post é auxiliar os leitores a identificarem a existência de Single Point of Failure (SPOF) ou pontos únicos de falha na arquitetura dos servidores e apresentar um modelo de arquitetura que minimize esses problemas.
SPOF são pontos que realizam alguma tarefa exclusiva na arquitetura do sistema e que se ficarem inoperantes vão tornar o sistema “inútil”, servindo tanto para hardware quanto para software. Para resolver o problema dos SPOF, a alternativa é criar uma redundância desses pontos. Assim, no caso de algum deles falhar, outro assumirá sua função imediatamente.
Como exemplo na figura abaixo é apresentado um ambiente de alta disponibilidade. Podemos observar que todos os pontos são redundantes, desde o link de fornecimento de internet até o espelhamento de um banco de dados e na utilização de um storage, garantindo que se qualquer ponto falhar, outro poderá assumir as tarefas do sistema.

O espelhamento de banco de dados consiste em manter um banco escravo idêntico, “espelho” do banco principal. Caso o principal tenha algum problema, o escravo assume sua posição. Geralmente esses bancos de dados ficam em máquinas diferentes, pois se houver algum problema isso não afetará ambos os bancos. Já o storage é um dispositivo que consiste em oferecer na rede uma área de armazenamento, sendo composta por um hardware redundante desde a placa de rede, fonte de energia até discos rígidos. Os discos rígidos são sincronizados/espelhados por meio da utilização, principalmente, de RAIDs. Um storage também permite a troca quente de discos rígidos danificados e a inclusão de novos discos para aumentar o espaço compartilhado entre os servidores e sistemas, facilitando a sua manutenção.
Como exemplo prático, na Mobiltec há projetos móveis menos sensíveis que exigem apenas a troca de informação ou sincronização entre o cliente e o servidor, uma vez ao dia sem importância de horário. Nesse caso, a utilização de um nobreak ou gerador já poderia ser o suficiente para garantir o funcionamento dos servidores. No entanto, há projetos que exigem a urgência na sincronização para que seja realizado algum atendimento/operação em campo o mais breve possível, sendo o cliente informado e sua tarefa realizada em poucas horas. Isso exige que o sistema servidor esteja operacional 24/7, não permitindo falhas e inoperação por grandes períodos. O exemplo apresentado a seguir é utilizado para oferecer a alta disponibilidade em um servidor M3, implantando para dar suporte a um sistema de atendimento de Ordem de Serviços (OS) e Leituras de medidores em campo. Sendo que o sistema de OSs exige que o sistema esteja online 24/7 e o sistema de Leituras exige que o sistema esteja operacional todos os dias das 6:00 às 19:00, sem falhas.
A arquitetura que será apresenta está baseada em sistemas operacionais Microsoft, porém também é possível a implantação de um ambiente de alta disponibilidade em sistemas Linux, com base principalmente na ferramenta Heartbeat que monitora os servidores do ambiente. Caso o servidor principal tenha algum problema, o segundo assume. Nessa arquitetura também pode ser utilizado o DRBD (Distributed Replicated Block Device) para manter os HDs dos servidores sincronizados. Dessa forma, quando um servidor secundário assumir o posto de primário, garantimos que não haja divergência de informações. Mais informações podem ser obtidas no site http://www.linux-ha.org, que se trata de um projeto que busca estudar e desenvolver novas tecnologias de alta disponibilidade para ambientes Linux com base nas ferramentas aqui apresentadas.
Na figura a seguir é apresentado o ambiente de alta disponibilidade com servidores M3, como mencionado anteriormente. Nessa arquitetura não serão apresentadas questões de redundância de roteadores, switch e interfaces de rede, pois os servidores estão alocados em um sistema de Blade Server ou Blade Systems. Em resumo, um sistema de Blades é um rack composto pela redundância de fonte de energia, ventilação e interfaces de rede, permitindo que sejam alocadas diversas Blades, sendo que cada uma é um computador com memória(s), processador(es) e um HD para a instalação do sistema operacional ou máquinas virtuais. Em geral é um conjunto de servidores com todo o hardware redundante, que garante a alta disponibilidade. No entanto, nada impede que a mesma arquitetura seja implantada utilizando roteadores, switches e servidores separados, não integrados em um cluster.

Como pode ser visto, também optamos pela utilização do conceito de servidores DMZ (DeMilitarized Zone). Esse conceito permite separar os servidores que trabalham com conteúdo importante/secreto/sigiloso do acesso direto a internet pública, evitando a invasão da rede, pois entre a DMZ e a rede local há um firewall que permite somente o acesso necessário para que o sistema funcione corretamente. Basicamente, em uma infraestrutura do M3 o M3FTS fica alocado na DMZ com o objetivo de validar os pacotes recebidos e direcioná-los para os módulos M3 internos, por isso torna-se obrigatória a redundância do M3FTS. Para evitar mais um SPOF, cada servidor DMZ é ligado a um link de internet diferente, permitindo que o sistema continue operante mesmo no caso de algum fornecedor de internet ter algum problema e até que o mesmo seja corrigido.
Vocês devem se questionar sobre, como o sistema cliente será capaz de saber em que servidor M3FTS ele deve se conectar? Teremos que ficar selecionando/testando qual dos servidores está operando? A resposta é não. Para isso, utilizamos o DNS Round Robin (DNS RR), que é uma técnica que permite configurar diversos IP para o mesmo nome de rede. Por meio dessa técnica, o próprio sistema operacional dos dispositivos recebe do servidor DNS uma a lista de IPs associados ao nome, ao resolver o nome de rede para acesso aos servidores do M3. Com isso o SO (Sistema Operacional) é capaz de alterar o IP caso seja verificado que o servidor atual não está mais respondendo as requisições, trocando o IP principal para o próximo IP da lista apresentado pelo servidor DNS. Com o DNS RR também é possível utilizar-se do balanceamento de carga, pois a cada pedido de resolução de nome, o servidor de DNS entrega a lista de IPs diferente. O primeiro IP da lista para cada dispositivo será intercalado e como conseqüência cada dispositivo irá acessar os servidores intercaladamente.
Até aqui já garantimos a redundância de hardware e garantimos que ao menos um servidor de DMZ estará operante para responder as requisições dos clientes. Porém, o M3 utiliza servidores internos para realizar o processamento dos dados de forma segura com acesso a serviços de banco de dados, repositórios e autenticação de usuários. Nesse momento, é necessário que o módulo M3FTS seja inteligente o suficiente para lidar com a redundância de máquinas, realizando a troca de um servidor principal para um secundário caso haja erro ou até mesmo realizando o balanceamento de carga entre os servidores de destino. Para isso, também é possível a utilização de ferramentas que auxiliem no desenvolvimento e implantação do sistema. Nesse caso, ambos os servidores M3FTS utilizam o plug-in ARR (Application Request Routing) do IIS (Internet Information Services).
O ARR, como seu nome diz, tem como objetivo rotear requisições HTTP entre uma fazenda de servidores conforme for configurado. Nesse caso, cada servidor M3FTS possui um ARR, que possui uma fazenda que aponta para todos os M3 internos e os fica monitorando periodicamente para verificar se cada um está respondendo as requisições de HTTP. Caso algum deles demore a responder, será considerado inoperante até que volte a responder em um novo teste. Para realizar o roteamento é possível configurar para que o ARR trabalhe de diversas maneiras, como enviando a requisição sempre para o primeiro servidor operante, ou fazendo com que ele realize um Roud Robin com base no tamanho dos pacotes ou tempo de resposta dos servidores da fazenda. Como apresentado na figura abaixo, mais informações como instalar e configurar podem ser vistas no site: http://www.iis.net/download/applicationrequestrouting.

Com a utilização do ARR, cada vez que o M3FTS necessita se comunicar com os servidores internos, ele na verdade envia uma requisição para a fazenda do seu ARR que irá rotear o pacote, retornando posteriormente a resposta do servidor interno. Assim, garante-se que mesmo que um servidor interno falhe, os módulos de M3 FTS continuem operando normalmente.
Já os servidores internos utilizam-se de tecnologias que já possuem funcionalidades de redundância, como:
- Storage que garante uma área de armazenamento na rede redundante para o compartilhamento de arquivos entre os módulos replicados;
- Oracle possui pacote Oracle RAC (Real Application Clusters- http://www.oracle.com/technetwork/database/clustering/overview/index.html) que monta um cluster do banco de dados. Caso o banco de dados principal falhe o seu escravo assumirá sua posição;
- Active Directory pode ser implantando em diversos servidores e configurados para que respondam a requisição de autenticação sobre o mesmo nome de domínio da rede, garantindo que sempre haverá um servidor que possa responder a autenticação;
Como pode ser observado, a arquitetura de alta disponibilidade apresentada não possui nenhum SPOF. No entanto, não podemos garantir que nunca haverá nenhuma falha, pois ainda existem fatores externos. Para que o sistema de alta disponibilidade seja o melhor possível, temos que possuir todos os pontos únicos da arquitetura redundantes. Em questão de hardware não há muitos problemas, a maior questão é que o seja software capaz de lidar a redundância verificando se o servidor está operacional e, em caso negativo, saber qual é o próximo que ele deve acessar. Para isso também podemos utilizar ferramentas que possam dar suporte nessas questões. Num próximo post iremos apresentar como o M3 é capaz de lidar com a redundância de forma paralela e como o mesmo pode ser disposto nesse ambiente, aumentando ainda mais a alta disponibilidade.
Escrito por Giovani Barili