ESTUDO E IMPLEMENTAÇÃO DE ALTA
DISPONIBILIDADE DE SERVIÇOS UTILIZANDO DOIS
ISP1
Rodrigo Alberto Schlabitz <[email protected]>
César A. H. Loureiro <[email protected]> – Orientador
Universidade Luterana do Brasil (Ulbra) – Curso de Tecnologia em Redes de Computadores – Campus Canoas
Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas - RS
22 de junho de 2011
RESUMO
Este artigo descreve o estudo de Alta Disponibilidade em uma infraestrutura de rede, para uma empresa que
utiliza serviços web hospedados em seu próprio datacenter. Demonstra uma análise feita sobre duas possíveis
soluções para este recurso, o Checkpoint NGX, e o Forefront Team Management Gateway (TMG). Tem como
objetivo, avaliar ferramentas na implementação de Alta Disponibilidade com o uso de dois ISP. Com os resultados
obtidos, faremos uma análise comparativa entre as ferramentas, abordaremos seus pontos negativos e positivos com
relação aos testes e, a solução que apresentar os melhores resultados, será utilizada na implementação de
disponibilidade dos serviços.
Palavras-chave: Alta Disponibilidade; Cluster; Firewall; Internet Service Provider (ISP).
ABSTRACT
Title: “Study and implementation of high availability of services using two ISP”
This article describes a study of High Availability in a network infrastructure for a company that uses web
services hosted on your own datacenter. Demonstrates an analysis on two possible solutions to this feature,
Checkpoint NGX, and Forefront Team Management Gateway (TMG). Its objective is to evaluate tools to implement
high availability using two ISP. With these results, we will make a comparative analysis between the tools, discuss
their negative and positive points about the tests, and the solution to provide the best results will be used in the
implementation of service availability.
Keywords: High Availability; Cluster; Firewall; Internet Service Provider (ISP).
1
INTRODUÇÃO
Alta Disponibilidade nos dias atuais, não deve ser mais novidade para a área de TI, é uma
característica fundamental em qualquer ambiente corporativo. É inimaginável o prejuízo, se um sistema
bancário de uma entidade financeira deixasse de funcionar por algumas horas, ou como impactaria
negativamente no nome de uma empresa como exemplo o site de busca Google, se ele ficasse indisponível
por determinado período. Imaginem o prejuízo gerado para estas empresas, se um tipo de serviço como estes,
é decorrente de uma falha que interrompa seu funcionamento, a empresa pode ter um prejuízo enorme em
sua receita, podendo abalar toda a estrutura financeira e seus investimentos, podendo até a vir a falir. Para
que possamos garantir, que os sistemas possam permanecer o maior tempo possível disponível, empresas
tendem a implementar soluções de Alta Disponibilidade.
Compreendemos que, o termo: HA (Hight Availability ou Alta Disponibilidade), não é um produto,
aplicação ou hardware, é uma característica de funcionamento do sistema ou serviço. O índice de
disponibilidade desejado está inversamente proporcional com seu grau de investimento, assim, quanto maior
o seu investimento, menor será a possibilidade de interrupção de um sistema. Entretanto, podemos ter um
sistema disponível dentro de certas limitações com baixo investimento, que garantiria uma margem muito
próxima dos 99,999% de uma disponibilidade.
Neste contexto, o objetivo deste artigo será avaliar duas soluções de mercado, o Checkpoint NGX e o
Microsoft Forefront Thread Management Gateway (TMG) para a implementação de Alta Disponibilidade
com uso de múltiplos ISP, garantindo um elevado grau de disponibilidade para os serviços web de uma
empresa para seus clientes.
1.
Artigo Final da disciplina de Trabalho de Conclusão do Curso em Superior de Tecnologia em Redes de Computadores da Universidade Luterana
do Brasil, Campus Canoas.
1
As soluções escolhidas apresentam soluções corporativas de grande porte, características como
qualidade, garantia do suporte técnico do fabricante foi levada em consideração na escolha das ferramentas,
sendo que, também estão entre as líderes de mercado no segmento de segurança de infraestrutura
corporativa. Sobre as ferramentas, será avaliada a implantação de Alta Disponibilidade com os recursos de
hardware existentes, utilizando links de operadoras diferentes.
A seguir, na seção 2 será apresentado o conceito sobre disponibilidade e suas aplicações, tipos de
falhas na disponibilidade, suas métricas para índices de disponibilidade e tipos de disponibilidade, para uma
melhor compreensão destas características que tem uma larga abrangência em sua utilização em vários
segmentos na TI. A seção 3 elenca as possíveis soluções a serem analisadas, apresenta seus recursos para
utilização de Alta Disponibilidade. Na seção 4, descrevemos as limitações impostas no projeto, onde será
analisado se as soluções enquadram-se ou não no cenário proposto. Na seção 5, descrevemos as
metodologias e testes das ferramentas e uma análise sobre seus resultados utilizados para a escolha da
solução adequada.
A seção 6 descreve o cenário anterior, a implementação do provimento de disponibilidade e, como
funcionará após a ferramenta em produção no cenário da empresa. Finalizando o artigo, a seção 7 irá validar
a implementação realizada e descreve se a solução utilizada atingiu os objetivos e as possibilidades de
melhorias contínuas no ambiente pós implementação, aumentando o nível de disponibilidade dos serviços na
empresa.
2
HA (HIGHT AVAILABILITY, ALTA DISPONIBILIDADE)
Alta Disponibilidade é um método utilizado cada vez com mais freqüência e importância nas
empresas que necessitam que seus serviços fiquem disponibilizados para seus clientes o maior tempo
possível. É a capacidade que um serviço tem de ficar disponível mesmo após a ocorrência de falhas,
oferecendo um ambiente seguro e confiável a empresa. HA não se compreende apenas como sendo um único
software, hardware ou procedimento, mas sim uma combinação de todos, ou alguns destes fatores onde a sua
implementação de acordo com a necessidade do projeto, possa prover a Alta Disponibilidade de um
determinado serviço ou solução desejado pela empresa.
A Alta Disponibilidade surgiu para permitir a operacionalidade máxima de serviços importantes nas
empresas, soluções estas consideradas vitais e até estratégicas economicamente para seus negócios que não
podem ser interrompidas, garantindo alto nível de disponibilidade para a empresa e para o seu cliente. Tende
a oferecer continuidade a dados e serviços, diminuindo o tempo de inatividade planejado e não planejado,
oferecendo rápida recuperação de uma falha de servidor, serviço ou solução, como um componente integral
para garantir a máxima continuidade dos negócios.
Parada não planejada e parada planejada tem diferentes percepções perante as falhas e
indisponibilidades do serviço. Sendo elas:
 Parada não Planejada: é um processo não elaborado ou planejado antecipadamente, não há
lógica no seu processo, ocorre de forma inesperada e geralmente envolvem falhas de processo físico
como hardware, software, fator ambiental, falta de energia, falha de software, ativos de rede entre o
cliente e o serviço e até queda de links. Também é passível de falha humana como em falhas físicas,
um erro de execução de um colaborador durante a execução de um processo no serviço decorrente de
falta de documentação, ou até inadvertidamente causando a indisponibilidade do serviço. São fatores
adversos que podem ser gerados desde o próprio serviço até o cliente.
 Parada Planejada: é decorrente de um processo elaborado e preparado, para que se minimize o
impacto de indisponibilidade no serviço. È um processo onde se prepara o ambiente, programa sua
parada, executa a manutenção e estima-se o seu tempo de indisponibilidade. É levado em
consideração o índice de indisponibilidade durante um determinado tempo para mensurar e atender
os requisitos de disponibilidade determinado pelo Acordo de Nível de Serviço (SLA – Service Level
Agreement) da empresa. (RUIZ, 2011).
2.1
Métricas de HA
Mensurar o que uma interrupção no serviço ou acesso as informações da empresa poderia causar de
prejuízo é o primordial para que se possa identificar o grau de SLA importante fator que tem como base
2
fundamental a Alta Disponibilidade de serviços. O SLA é uma parte de um contrato ou uma métrica feito
entre duas entidades ou internamente preestabelecido pela empresa para estabelecer o limite de
indisponibilidade de um serviço durante o período de um ano.
“A disponibilidade de um serviço é calculada na percentagem que quantifica a probabilidade de
encontrar o serviço operacional em determinado momento” (FERREIRA e SANTOS, 2005, p. 2). Esta
definição de disponibilidade permite-nos calcular a linha de tempo em que um serviço esteve disponível
(uptime) e também o tempo de indisponibilidade (downtime) deste serviço. Para o problema referenciado
neste artigo não se faz necessário abordar todas as classes de disponibilidade, pois não se enquadrariam todas
no problema a ser resolvido.
Para referenciar o projeto iremos abordar o método de Alta Disponibilidade (HA), que será utilizada
para o problema, mas faz-se necessário sabermos alguns conceitos das outras duas classes, pois o que
diferencia uma da outra é a relação downtime x uptime e custo. Uma ressalva neste momento é importante na
conotação de custo, pois o tempo de uptime está proporcionalmente relacionado ao custo de disponibilidade
do projeto, ou seja, quanto mais se deseja ter um serviço disponível, mais alto será o investimento no projeto
como um todo.
A seguir, citaremos as três faixas de classes de acordo com sua faixa de custo da disponibilidade
desejada.
Disponibilidade Básica: é encontrada em todos os computadores de todos os tipos e níveis de
desempenho. Não utiliza um software ou um hardware específico para este fim. Atende o necessário para o
cliente. Em caso de paradas não planejadas e paradas planejadas o serviço ficará indisponível. Um sistema
com este método conforme o índice de disponibilidade e o tempo de downtime atingem em média de 99% a
99,9% de disponibilidade. Neste modelo um serviço pode ficar indisponível durante o período de um ano em
média entre 4 a 9 dias de indisponibilidade.
Alta Disponibilidade: este método somente é possível com alocação de recursos específicos de
hardware ou software para este fim. Geralmente é utilizado em serviços de monitoramento e detecção de
falhas, onde uma ação é tomada para recuperação da atividade do serviço, tornando o mais rápido possível
disponível para o usuário novamente. Este método utiliza-se de uma margem bastante satisfatória para o uso
de serviços com Alta Disponibilidade, pois pode garantir uma eficiência (uptime) do serviço de 99,99% a 99,
999%, obviamente obedecendo ao custo mais elevado para a implementação deste recurso. Este método
atinge uma margem de downtime que vai de 5 minutos até 1 hora de indisponibilidade durante o período de
um ano.
Disponibilidade Contínua: este método tem-se como modelo ideal de disponibilidade e de índice de
SLA, pois abrange 100% de uptime total ou 24horas em 7 dias na semana durante todo o ano. Segundo
(FERREIRA e SANTOS, 2005), “a disponibilidade contínua (continuous availability), abrange a coutilização dos métodos de Alta Disponibilidade e Disponibilidade Contínua simultaneamente.” Geralmente e
mais utilizado em hardware (servidores), onde possuem recursos de tolerância a falhas que vão desde o hard
disk com Hot Swap (troca de discos a quente) até a fonte de alimentação do servidor. Para sua utilização o
custo é altíssimo e o serviço tem que ser de uma importância extrema e estratégica para a empresa, pois aloca
recursos em diversos segmentos e requer um projeto altamente elaborado. Para sua utilização em serviços é
necessário um projeto que vai desde tolerância a falhas de servidores, contingência de link, balanceamento de
ativos de rede, infraestrutura de rede com backup, contratos de SLA com provedores de ISP e até
procedimentos de paradas planejadas minuciosamente documentadas e homologadas.
Na Tabela 1, a Microsoft (2011) faz referência ao Six Sigma. Quanto mais nove tiver, menor será o
downtime. Six Sigma é uma metodologia, com o objetivo de implementar um vigoroso processo sistemático
para eliminar as deficiências e ineficácia. Ela foi originalmente desenvolvida pela Motorola, no início dos
anos 80, e por causa de sua proficiência tornou-se extremamente popular em muitos ambientes corporativos
e de pequenos negócios em todo o mundo.
Tabela 1 – O significado dos noves (Microsoft, 2011)
3
Existe uma fórmula que permite calcular os índices de disponibilidade em relação aos seus limites de
downtime. Este cálculo é feito sobre um determinado período de tempo.
DISPONIBILIDADE = (Total de Unidade de Tempo - Downtime) / Total de Unidade de
Tempo
Como exemplo, calcularemos a disponibilidade de um serviço durante um ano considerando um
serviço de portal de compras online, onde este esteve fora do ar por 18 dias.
Downtime = 18 dias (432 horas)
Total de Unidade de Tempo = 1 ano (8760 horas)
DISPONIBILIDADE = (8760 horas – 432 horas) / 8760 = 95,0684 %
Existem vários meios e métodos para implantar a Alta Disponibilidade em diversos segmentos como
podemos ver na Tabela 2 abaixo:
Tabela 2 – Exemplos de Alta Disponibilidade em vários segmentos.
Podemos ver que a Alta Disponibilidade está presente em praticamente todos os segmentos
tecnológicos na atualidade, e que, todos visam garantir a máxima continuidade dos seus serviços empregados
em suas metodologias de HA. Como citado na tabela acima, nossa questão envolve a disponibilidade de
serviços web através do uso de dois links contratados.
3
SOLUÇÕES PROPOSTAS
Será realizada uma análise para elencar a que melhor se enquadra nas condições e limitações
propostas no projeto a ser implementado. O Checkpoint e o TMG possuem inúmeras features para várias
finalidades como: firewall, web filter (filtro de conteúdo), VPN, Anti-spam e outros, porém este não é o foco
do artigo. Dentre estas opções citadas, o foco será nas funcionalidades de provimento do HA para a
redundância de links de dois diferentes ISP, mantendo assim, disponível para os clientes os serviços web da
empresa.
3.1
Forefront TMG
O TMG possui recursos de Alta Disponibilidade com redundância de hardware, Network Load
Balance (NLB) e possui redundância de link, ISP Redundancy, veremos as suas características e seus
funcionamentos.
Network Load Balance – NLB: este serviço faz parte da família de Sistema Operacional Windows
Server, que é utilizado para distribuir o tráfego da rede para os hosts membros do Network Load Balance
(NLB). Todos os membros do Cluster possuem um endereço IP dedicado e todos os membros do Cluster
NLB recebem o endereço IP virtual (VIP) em comum. A Figura 1, mostra como funciona a arquitetura do
NLB.
4
Figura 1 – Arquitetura básica do NLB.
O NLB possui três modos de operação que são utilizados para comunicação dos clientes com o
Cluster NLB. Estes três modos são: Unicast, Multicast e Multicast com IGMP (Internet Group Multicast
Protocol), onde veremos apenas os dois primeiros citados que são de interesse do artigo. Para qualquer uma
das modalidades utilizada, o endereço MAC, (Media Access Control) endereço físico da interface de rede do
Cluster, é definido em todos os membros do Cluster NLB. O NLB no TMG pode operar em modo integrado
e não integrado. Quando habilitado o NLB integrado o modo de operação padrão será o Unicast
(HARRISON, DIOGENES e SAXENA, 2010, p. 258).
No modo Unicast, do TMG o processo de entrega dos pacotes são feitos em paralelo em todos os
membros do Cluster e em seguida, o driver NLB filtra os pacotes que não se destinam a ser processado por
um nó específico. No modo Multicast, os adaptadores de rede de cada membro recebem um endereço MAC
Multicast. Apesar de todos os membros do Cluster compartilharem estes mesmo endereço MAC, todos
mantém o endereço MAC original. Assim como existe os recursos de balanceamento de carga de
hardware do TMG o serviço de redundância de link possui dois modos: ISP Load Balancy e ISP
Failover. Como poderemos ver na Figura 2 o principio de funcionamento do balanceamento de
carga de links do TMG.
Figura 2 – Redundância de ISP no TMG.
ISP Failover: este modo permite configurar um link ISP primário e um link ISP secundário de
failover. O link de backup somente é ativado, quando o link principal não estiver disponível. Quando o link
principal estiver disponível novamente, o tráfego dos dados é imediatamente transferido do link secundário
para o primário.
ISP Load Balancy: Nesse modo, pode ser configurado o balanceamento de carga entre
dois links ISP para que o tráfego possa ser balanceado entre eles. O ISP Load Balancing permite que seja
utilizada toda a banda disponível dos dois ISP. Pode fornecer balanceamento de links proporcionalmente
distribuído pelo administrador de maneira variável permitindo que se dimensione o tráfego da melhor
5
maneira a carga utilizada pelos links.
Para que se possa manter um acompanhamento de toda a disponibilidade das ferramentas de Alta
Disponibilidade do TMG existe uma tela de gerência proprietária que pode fornecer um monitoramento em
tempo real dos estados dos links, (uptime de cada link), e também da carga e disponibilidade dos servidores
(% de uso do processador e memória), como mostra a Figura 3:
Figura 3 – Tela de monitoramento de links no TMG.
A ferramenta de monitoramento do TMG possui uma interface simplificada e não oferece muitos
recursos de relatórios, que para sua utilização, se faz necessário a implementação de um servidor com banco
de dados SQL Server. Seu monitoramento de links fornece apenas o tempo de uptime do link e o estado da
redundância destes. Já o monitoramento de hardware pode ser gerenciado com vários tipos de recursos,
citamos como exemplo: a carga e uso de processamento, uso de memória, espaço em disco, dentre outras
várias disponíveis.
3.2
Checkpoint NGX
O Checkpoint possui recursos de disponibilidade como: redundância de hardware (ClusterXL) e
possui redundância de link (ISP Redundancy), veremos a seguir suas características e seus funcionamento.
Dos recursos disponíveis de hardware para Alta Disponibilidade, o serviço de ClusterXL possui dois
modos comumente utilizados, Active/Standby Operation e Load Sharing.
O modo Active/Standby operation, é disposto de no mínimo dois membros no Cluster virtual. No
modo Active/Standby o ClusterXL tem que designar um dos membros como membro ativo no Cluster,
enquanto os outros membros ficam em modo standby. O IP virtual do Cluster é associado a interface da rede
física do membro ativo atrelando o endereço MAC da interface, todo o tráfego enviado ao Cluster é na
verdade roteado pelo membro ativo. Os membros do Cluster neste modo possuem um papel de prioridade
sendo o membro ativo o de prioridade mais alta. Os demais membros em standby podem ter suas prioridades
definidas a qualquer momento na console do Checkpoint. O membro ativo além de ser o firewall-gateway da
rede, fica também responsável por informar aos demais membros do Cluster qualquer alteração no seu
estado, conexões e tabelas, mantendo estes membros atualizados com todo o tráfego que é passado no
Cluster. O Cluster sempre que detectar um problema crítico suficiente para causar um evento de failover,
passa o estado de membro ativo para uma das máquinas em standby na ordem de prioridade designada.
Todas as conexões existentes no ex-membro ativo automaticamente são recebidas e mantidas pelo
novo membro ativo no Cluster com base na última sincronização entre os membros. Ao restabelecer o
membro novamente no Cluster, este passa a função de standby, não alterando o estado atual dos outros
membros, incluído ele mesmo.
6
Este mecanimo geralmente é utilizado em organizações para reduzir o risco de paradas inesperadas,
especialmente em um ambiente de missão crítica, como aqueles que envolvem transações monetárias sobre a
Internet.
O modo Load Sharing trabalha em dois modos de tráfego de dados na rede entre seus nós do Cluster:
Multicast e Unicast.
 Modo Unicast: Load Sharing no modo Unicast, oferece uma solução alternativa onde os
ambientes de redes não podem operar em modo Multicast. Neste modo somente um membro do
Cluster está vinculado com o IP virtual do Cluster chamado de Pivô. É o único membro a receber
pacotes enviados do Cluster. Este membro fica responsável de propagar todos os pacotes aos demais
membros do Cluster criando mecanismos de distribuição de carga. Quando um membro pivô vem a
falhar instantaneamente, outro membro não pivô assume o papel do membro ativo temporariamente,
pois um membro pivô sempre terá prioridade do serviço, e quando ele se restabelece novamente,
automaticamente passa a ser o membro pivô do Cluster (CHECKPOINT SOFTWARES
TECHNOLOGIES LTD, 2009, p. 59).
 Modo Multicast: Load Sharing no modo Multicast permite distribuir o tráfego entre todos os
membros do Cluster. Em contraponto com o modo Active/Standby Operation onde somente um
membro está ativo todo o tempo, todos os membros do Load Sharing Multicast estão ativos e o
Cluster é o responsável pela distribuição fracionada do tráfego para cada membro. Esta atribuição e a
tarefa de decisão que examina cada pacote que passa pelo Cluster e determina qual membro irá tratar
este pacote. Como o processo utiliza todos os membros do Cluster isso aumenta seu throughput. O
processo de falha de um membro neste modo é o mesmo tratado no Unicast, automaticamente é
redistribuído todo o tráfego dos pacotes entre os membros ativos sendo que neste caso, quando o
membro restabelecer-se, já recebe o tráfego redistribuído pelo Cluster. O mecanismo Multicast que é
fornecido pela camada Ethernet, permite que várias interfaces possam ser associadas com um único
endereço MAC, diferentemente do Broadcast de rede que liga todas as interfaces na mesma sub-rede
para um único endereço. O Multicast permite agrupar dentro de redes, significa que é possível
selecionar as interfaces dentro de uma única sub-rede que receberá os pacotes enviados para um
determinado endereço MAC. O ClusterXL utiliza o mecanismos Multicast para associar o IP virtual
do Cluster com todos os membros do Cluster, isso garante que todos os pacotes enviados para o
Cluster chegará a todos os membros do Cluster. Cada membro então decide se deve ou não processar
cada pacote. Esse é o centro do Load Sharing, isso garante que pelo menos um membro irá processar
cada pacote e evita que um mesmo pacote seja tratado por mais de um membro do Cluster evitando o
bloqueio do tráfego (CHECKPOINT SOFTWARES TECHNOLOGIES LTD, 2009, p. 57).
Assim como estas informações, podemos compreender como o Checkpoint provê disponibilidade de
hardware através do seu serviço de ClusterXL com seus recursos de redundância. Veremos a seguir, como
esta característica é utilizada e pode ser implementada na disponibilidade de links. A implementação de
disponibilidade de ISP pode ser realizada com o uso do serviço ISP Redundancy do Checkpoint, que possui
dois modos de utilização: Load Sharing e Primary/Backup.
Load Sharing: distribui o tráfego entre os dois links simultaneamente, sendo que ele distribui o
“estado” dos links de mesma maneira para ambas as paredes do firewall, tanto para a parede ativa como para
a parede em standby, para permitir isso, cada parede recebe em suas controladoras de rede, um link de cada
ISP, ficando a cargo da rede de sincronismo manter as informações destes links. O Checkpoint utiliza um
conjunto de serviços existentes, para monitorar de forma eficiente o estado dos links conectados nas paredes
do firewall, para que o Checkpoint possa monitorar e tomar as medidas necessárias e manter os serviços
disponíveis independente de qual link estiver ativo (CHECKPOINT SOFTWARES TECHNOLOGIES LTD,
2009, p. 142-143).
Para que o Cluster possa informar o status dos links, é adicionado nas propriedades do Cluster o IP
do roteador das operadoras contratadas. Após sua adição, o Cluster passa a monitorar os links através de
pacotes ICMP de tamanhos definidos pelo administrador, quantos pacotes podem ser perdidos em um
determinado tempo e também o tempo aceitável de latência de resposta deste roteador. Caso a latência seja
maior do que a preestabelecida no monitoramento, é disparado um alerta via SMTP para os responsáveis do
serviço. Não possui failover neste modo, se algum link cair, a carga do link ativo receberá 100% do acesso
total.
7
Primary/Backup: permite designar um link primário pelo qual todo o tráfego de saída da Internet
fluirá e um link de backup que é ativado em caso de falha do primeiro link. Quando o link primário é
restaurado, novas conexões de saída são atribuídas a ele, enquanto as conexões existentes são mantidas
através do link de backup, até que sejam concluídas (CHECKPOINT SOFTWARES TECHNOLOGIES
LTD, 2009, p. 142-143).
Assim como o TMG o Checkpoint usa uma ferramenta proprietária de monitoramento de links e
hardware chamado: SmartViewMonitor, esta ferramenta possui vários recursos de monitoramento que vão
desde links até conexões de tunelamento (VPN) e carga de processamento dos servidores. Permite monitorar
todo o fluxo que é recebido e enviado pelos membros do Cluster, inclusive o estado dos links em vários
aspectos: por pacotes, protocolo, conexão, serviços, etc. Ele gera também, relatórios para que se possa ter um
controle efetivo do link e demais serviços que seja da necessidade do administrador da ferramenta. Na Figura
4 a seguir, está demonstrada a interface da ferramenta de monitoramento do Checkpoint:
Figura 4 – Gráfico da ferramenta de monitoramento de link, SmartViewMonitor do Checkpoint.
4
LIMITAÇÕES DO PROJETO
Em qualquer implementação de um projeto seja o projeto com foco em tecnologia ou de qualquer
outro segmento, possuem limitações impostas pela própria estrutura ou pela própria empresa a nível de
investimento. Este projeto não é diferente, a implementação da solução será realizada em um ambiente
desafiador. Possui uma estrutura de rede onde seus ativos de rede são antigos com mais de 10 anos de
utilização, possui gargalos de tráfego de dados em alguns pontos devido às limitações dos equipamentos
destes locais, a política e estrutura geral da rede não possui quase documentação e não permite
monitoramento de recursos em vários pontos desta rede.
Levando em consideração as limitações de recursos e investimento, ainda poderemos obter ótimos
resultados com a solução após sua implementação, respeitados algumas limitações como:

Limitação de hardware (três servidores);

Utilização dos dois links já existentes para implementação;

Utilização do método HA de ISP no modo Active/Passive (devido ao link secundário ser de
menor capacidade do que o primário).
Nas limitações de hardware, a empresa dispõe de três servidores para uso em rack das seguintes
características: 4gigabytes de memória, dois discos de 250 gigabytes em RAID 0, com processadores Xeon
2.0Ghz. A empresa por possuir diversos serviços alocados dentro de sua estrutura interna e publicados na
Internet, adota o recurso de HA. Para tal a empresa mantém um monitoramento extra e cada link com
8
software de terceiros. Para implementação da HA, serão utilizados, dois links já existentes na estrutura, um
de 55Mb de uma operadora, (ISP principal) e outro de 35Mb de outra operadora, (ISP secundário), ambos
possuem um bloco de IP dedicado para a empresa com garantia de banda fixa.
5
METODOLOGIA DE TESTES E ANÁLISE COMPARATIVA
Até este momento, explanamos sobre todas as características e particularidades de cada ferramenta, a
fim de conhecermos mais profundamente seus serviços e suas garantias de Alta Disponibilidade, bem como
seus modos de funcionamento. Isso nos possibilita avaliar e tirar conclusões técnicas através de testes e
resultados de uma maneira prática, de qual ferramenta poderá nos fornecer um resultado positivo e
disponibilizar o melhor desempenho, não só para a resolução do problema, mas de agregar um acréscimo na
qualidade ao serviço da empresa e permitir uma implementação contínua de melhoria para este projeto
mantendo o maior tempo possível seus serviços disponíveis.
Para os testes destas ferramentas, analisamos algumas características neste artigo que nos ajudarão a
escolher a melhor ferramenta. Os testes serão realizados em um ambiente de homologação, com as mesmas
características do ambiente de produção, para que a ferramenta escolhida possa apresentar a mais próxima
possível dos resultados de produção quando for implementada no ambiente.
Teste de pacotes Round-trip Time (RTT) e ICMP: o RTT pode-se dizer que é tempo que passou
desde que o pedido de output foi enviado do cliente ao servidor até o instante em que este pedido de output
do mesmo servidor chega ate o cliente. O RTT pode ser influenciado não só pelo desempenho da rede, bem
como pelo desempenho de todo o sistema, incluindo as características da implementação e otimização da
ferramenta, por isso teremos uma resposta completa de latência no teste de troca de link. Realizaremos testes
de requisição ICMP do cliente ao servidor durante o período de 1 minuto, repetindo-o por cinco vezes
consecutivas, para obtermos uma média do tempo total de downtime e uptime durante e a média de resposta
RTT.
Teste de intermitência entre os links: neste teste iremos simular uma intermitência do link
principal onde durante o período de 1 minuto desativaremos e reativaremos o link principal de 15 em 15
segundos, consecutivamente, e veremos como ele irá se comportar nas respostas de requisições durante a
troca do link.
Depois de efetuado os testes, geraremos os gráficos comparativos através dos dados coletados das
duas soluções testadas e faremos uma análise destes resultados.
5.1
Resultados dos testes do TMG
O gráfico a seguir, nos mostra a média de pacotes perdidos pelo TMG durante os testes onde
desativamos o link principal para que se medisse o tempo de resposta para o link secundário e efetuado cinco
testes consecutivos, com envio de aproximadamente 60 pacote por minuto:
Figura 5 – com estimativa de pacotes perdidos no teste de ICMP (%).
O gráfico da Figura 5 nos mostra que a perda de pacote para requisições ICMP do cliente ao
9
servidor, apresentou uma perda de aproximadamente 34% de todos os pacotes enviados dentre as 5 amostras
de testes. O gráfico da Figura 6 abaixo confirma o alto tempo das respostas pelos resultados obtidos na
latência no RTT:
Figura 6 – Gráfico com estimativa de latência no RTT (em milissegundos).
Os dados do gráfico da Figura 6 demonstram que não houve nenhuma grande alteração nas respostas
do RTT de uma amostra para outra. Apesar do alto tempo de respostas nos testes de ICMP, os resultados do
RTT mantiveram-se dentro do esperado, por se tratar de uma medida de tempo de resposta do cliente ate o
servidor e retornando do servidor até o cliente, passando por vários pontos adversos da estrutura.
Nos testes de intermitência do TMG efetuamos o processo que simula a intermitência do link
principal, e analisamos o comportamento do TMG e como ele tratará o balanceamento dos links. Durante o
processo do primeiro teste observamos que após simularmos a queda do link pela terceira vez, o TMG não
alterou mais o status do link gerando um log de erro no seu gerenciador de monitoramento: Routing Chaining
Failure, como mostra a Figura 7:
Figura 7 – Tela de log do TMG com o erro gerado.
10
O erro apresentado na Figura 7 significa que o algoritmo que monitora o status das interfaces
externas que verifica quando um link estiver indisponível, ao receber rápidas solicitações de troca de link,
começa a mandar infinitamente uma requisição em modo loop de uma interface externa para outra, não
conseguindo verificar qual link está ativo ficando sem acesso externo. As requisições de saída não são
efetuadas, pois ele não sabe por qual link mandar a requisição. Para resolver a dificuldade foi necessário
desativar os links do ISP Balancy e após reiniciar o serviço de Firewall do TMG. Nos testes restantes de
intermitência, ele apresentou a mesma dificuldade em pelo menos quatro dos cinco testes realizados. Por este
motivo o teste no TMG de intermitência de link obteve resultados negativos.
A Figura 8 abaixo demonstra a falha do processo de disponibilidade de links no modo failover do
TMG verificamos que quanto mais intermitente fica o link mais o tempo de dowtime aumenta até o ponto em
que ele não tem mais requisições uptime:
Figura 8 – Resultado da falha na intermitência dos testes no TMG.
5.2
Resultados dos testes do Checkpoint
Do mesmo modo que foi realizado com o TMG, efetuamos os mesmos testes com o Checkpoint,
vejamos como foram os resultados obtidos conforme demonstrado na Figura 9 abaixo:
Figura 9 – Gráfico com estimativa de pacotes perdidos no teste de ICMP (%).
Como podemos observar no gráfico da Figura 9, a margem de perda de pacotes ICMP é muito baixa,
em uma dos testes, a perda foi de somente um pacote dos 60 pacotes enviados, o que nos das
aproximadamente apenas 8% de perda.
11
Figura 10 – Gráfico com estimativa de latência no RTT (em milissegundos).
Em contrapartida, os testes de RTT da Figura 10, revelaram uma latência mais alta em relação ao
TMG provavelmente no modo como o Checkpoint trata o pacote de resposta ao cliente, nos testes
observamos que quando o link principal era desativado, ao assumir o link secundário o tempo médio do RTT
aumentava, e após baixava normalmente, caso que não ocorria no TMG. Esse foi o principal fator que elevou
o índice de latência nos resultados de RTT.
5.3
Análise comparativa entre as ferramentas
Após os testes realizados entre as duas ferramentas, coletados os dados e gerado os gráficos,
realizamos uma análise comparativa entra as ferramentas que permitiu escolher a melhor opção para a
implementação de Alta Disponibilidade com base nos resultados obtidos.
De acordo com os resultados negativos obtidos com o teste de intermitência no TMG onde este,
apresentou problemas críticos de indisponibilidade de link com o modo failover, não será possível fazer uma
análise comparativa deste teste entre as duas soluções, porém, os demais testes puderam ser analisados e
comparados. A seguir no gráfico da Figura 11 um comparativo entre as requisições de pacotes ICMP do
Checkpoint e TMG:
Figura 11 – Média de pacotes perdidos do TMG e Checkpoint.
De acordo como a Figura 11, podemos perceber a diferença entre as duas soluções em suas respostas
ao teste. São bem diferentes visto que o Checkpoint obteve apenas 8% de perda de pacote do total do teste e
já o TMG obteve uma média de pacotes perdidos quatro vezes maior. O que está representado
proporcionalmente ao inverso no gráfico da Figura 12 a seguir sobre o teste de RTT:
12
Figura 12 – Comparativo TMG e Checkpoint da latência do RTT.
Apesar da Figura 11 demonstrar claramente que as respostas do TMG na latência do RTT serem bem
maiores, isso não interferiu no resultado dos testes dos links com pacotes ICMP. Através dos resultados
obtidos nos testes das duas soluções apresentadas, e dos aspectos técnicos de cada um, definimos que a
melhor opção para a implementação de HA no ambiente proposto será o Checkpoint.
6
IMPLEMENTAÇÃO DA FERRAMENTA
Conforme analisamos anteriormente as soluções propostas neste artigo para redundância de ISP, foi
possível realizar alguns testes essenciais que nos ajudaram a identificar a ferramenta mais adequada a atender
aos requisitos técnicos do projeto e de limitações impostas pela empresa.
O cenário anterior à implementação possuía as seguintes características:

Dois DNS (Domain Name System) externos alocados diretamente na rede externa da
operadora do link principal, possuindo um firewall em cada um destes servidores como
perímetros de segurança em um DMZ (DeMilitarized Zone) local entre eles;

Serviços web alocados diretamente na rede externa na mesma operadora do link principal,
estando sob um firewall de distribuição Linux como perímetro de segurança;

Link da operadora principal disposto em um roteador de borda da empresa que redireciona
para o Firewall-Gateway da rede;

Link da operadora secundária disposto em outro roteador de borda da empresa que
redireciona para o Proxy da rede em outro segmento.
Os links eram dispostos como backup um do outro e os serviços divididos entre estes links de entrada
e saída de requisições. O processo planejado constitui na centralização destes links por meio do Checkpoint,
permitindo redundância destes links para os serviços, mantendo o uso do link secundário para o serviço de
Proxy da empresa. Podemos entender melhor a estrutura conforme Figura 13:
13
Figura 13 – Cenário da estrutura atual.
No cenário anterior, a estrutura não permite implementar a redundância de links. Sendo necessário
alterar este cenário, mudando os pontos onde estão os servidores DNS e serviços web.
A implementação obedeceu a uma ordem técnica e planejada de cada etapa da implementação:

Configurar Link secundário no Checkpoint;

Configurar regra de entrada no Checkpoint para pacotes DNS, UDP/TCP na porta 23;

Criar objetos no firewall com o IP interno da DMZ atribuindo os IPs externos a estes objetos
através de Network Address Translation (NAT);

Transferir os DNS externos para a DMZ no Checkpoint, inserindo seus novos IPs internos e
atribuir os IPs externos através de NAT do Checkpoint;

Configurar regra de entrada no Checkpoint para pacotes HTTP (80) e HTTPS (443) no
servidor web;

Transferir os servidores web externos para uma DMZ no Checkpoint, inserindo seus novos
IPs internos e atribuir os IPs externos através de NAT do Checkpoint;
Antes de procedimento, foi necessário inserir mais dois registros de DNS no Serviço de Registro de
Domínio conforme apresenta a Figura 14:
14
Figura 14 – Entradas de DNS Publicadas no Registro de Domínios publicados no Brasil.
A Figura 14 mostra a publicação dos dois apontamentos DNS com os IPs do link secundário,
lembrando que, estes dois novos apontamentos de DNS serão utilizados internamente no Checkpoint, não
havendo necessidade de ser implementado mais dois servidores DNS, pois o próprio Checkpoint fará este
serviço, será necessário que os dois servidores DNS fiquem sob a gerência do Checkpoint através de uma
DMZ gerenciada por ele, e os servidores de serviço web fiquem também em um DMZ do Checkpoint, porém
em outra DMZ separada, o que é politicamente seguro na estrutura a ser implementada. As zonas DNS da
empresa estão todas configuradas diretamente no IP externo do link principal, conforme citado
anteriormente. Colocaremos os servidores DNS em uma DMZ separada de toda a rede, onde somente o
firewall Checkpoint possui acesso a ela. Isso fez com que obrigatoriamente todo o tráfego enviado aos DNS
externos, passe obrigatoriamente pela inspeção do Checkpoint, gerando uma margem maior de segurança e
auditoria futura se necessário.
Após colocarmos os servidores de resolução de nomes em uma DMZ separada, através de VLAN’s
(Virtual Local Area Network) realizados no roteador principal da rede, configuramos uma regra de entrada
no firewall para liberar tráfego de entrada na porta TCP/UDP 53, através de NAT no servidor DNS. A partir
deste momento, iniciamos o processo de configuração no Checkpoint para que ele possa garantir Alta
Disponibilidade do link de Internet, permitindo um acordo de nível de serviço (SLA) na empresa. Em caso de
falha do link de Internet primário, o ISP Balancy automaticamente envia o tráfego para a conexão de backup
disponível sem a intervenção do administrador. Permitirá que as resoluções de nomes sejam automáticas e
transparentes entre os dois links de faixa de IPs diferentes.
O funcionamento de servidores DNS com dois links de ISP com diferentes faixas de IP, somente é
possível, implementando uma funcionalidade particular do Checkpoint que permite resolver os nomes
requisitados de fora da rede aos servidores web dentro da rede independente de qual link esteja ativo.
O processo é relativamente simples. Consiste em alguns procedimentos que devem ser realizados
para que a arquitetura de DNS Proxy do Checkpoint consiga resolver o host do serviço solicitado tanto pelo
link principal como pelo link secundário. Existe um arquivo que é utilizado como tabela interna do
Checkpoint de resolução de nomes do Cluster denominado, local.arp. Cada parede do Cluster possui este
arquivo, assim quando necessário, deve ser inserido o endereço MAC do IP do Cluster e o IP externo do
serviço web a ser apontado e resolvido quando o link secundário estiver em operação, na contingência do
link primário.
O Checkpoint precisa vincular este host a um IP de cada ISP. No gerenciador deve ser configurado o
apontamento destes endereços externo para resolver a consulta deste host em ambos os IPs no DNS externo
da empresa. Entenderemos melhor visualizando a Figura 15:
15
Figura 15 – Exemplo da função DNS Proxy do Checkpoint.
Como observamos na Figura 15, o host no DNS Proxy do Checkpoint apontará para o IP do link
primário e um IP do link secundário. Isso é necessário para que, o Checkpoint quando receber requisições
pelo link secundário saiba para qual endereço IP está apontado no servidor de DNS externo da empresa, e
possa responder através do link secundário para o cliente. Este processo pode ser mais bem compreendido
nas Figuras 16 e 17 a seguir:
Figura 16 – Princípio de funcionamento do serviço de DNS Proxy com link principal ativo.
Figura 17 – Princípio de funcionamento do serviço de DNS Proxy com link principal inativo.
Como podemos observar na Figura 18, a estrutura após a implementação do serviço de Alta
Disponibilidade e Redundância de ISP, obtivemos uma grande mudança em sua estrutura:
16
Figura 18 – Estrutura após implementação do serviço de Alta Disponibilidade.
7
RESULTADOS E VALIDAÇÃO
Após realizarmos a implementação do Checkpoint no ambiente proposto da empresa, veremos com a
realização de alguns testes, os resultados obtidos com o Checkpoint em um ambiente de produção recebendo
todo o fluxo de requisições externas gerada pelos seus clientes aos serviços web. Realizaremos novamente o
teste de disponibilidade dos links gerando um tráfego ICMP externo. Durante o teste desativamos o link
principal e realizamos a resolução de nomes para os IPs dos dois links obtendo o seguinte resultado na Figura
19:
Figura 19 – Resolvendo o serviço web pelo link secundário.
Conforme era esperado o serviço web que respondia pelo IP 200.196.73.228 do link principal, ao
ser desativado, passou a responder pelo link secundário resolvendo pelo 187.60.192.228. Isso demonstra que
17
tanto a redundância de link como a redundância de resolução de nomes do Checkpoint, obteve sucesso.
Vejamos agora o seu tempo de respostas de acordo com a Figura 20 a seguir:
Teste 1
20%
15%
Teste 2
15%
8,00%
10%
Teste 3
Teste 4
5%
Média em Produção
0%
ICMP (Pacotes)
Média em Homologação
Figura 20 – Respostas pacotes ICMP (Homologação x Produção).
Como podemos observar as respostas de pacotes ICMP em comparação com o teste realizado em
ambiente de homologação, os valores de respostas foram quase o dobro. Considerando que o fluxo de
requisições é muito superior no ambiente de produção, mesmo assim, ficou com a metade do tempo de
resposta estabelecido no TMG. De uma maneira prática, a página de empresa quando teve seu link principal
desativado para a realização do experimento, demorou em média 15 segundos para restabelecer seu serviço
no link secundário.
8
CONCLUSÃO
Podemos considerar que a dificuldade de contingência dos serviços web que a empresa vinha
enfrentando com o uso de somente um link de acesso, causava a demora ao restabelecer seus serviços em
decorrências de falhas deste link. Por este motivo, surgiu a necessidade de uma proposta para implementar
um recurso que permitisse que os serviços tivessem maior disponibilidade e menos possibilidade de falhas.
Para a implementação, foram testadas duas possíveis soluções: Checkpoint e TMG. Estas soluções foram
submetidas a uma bateria de testes para que dentre elas, pudesse ser utilizada a que apresentasse melhores
resultados nestes testes. Nos testes comparativos realizados, o TMG apresentou problemas sérios de
contingência, e respostas inferiores ao Checkpoint, o que levou o TMG a não ser o mais indicado para a
implementação, e sim o Checkpoint.
O problema de contingência de serviços web da empresa foi resolvido com a sua implementação do
firewall em nível de hardware e de links no modo Failover. O Checkpoint possuindo uma grande
capacidade e recursos voltados para disponibilidade de serviços, e sua aplicação otimizada para a finalidade
a qual foi implementado, permitiu de forma eficaz obter resultados satisfatórios nos testes, tanto no ambiente
de homologação como no de produção, atingindo assim nosso objetivo com este trabalho. Com a
implementação de Alta Disponibilidade nos serviços e seus resultados positivos, podemos considerar um
primeiro passo, para a melhoria continua na sua contingência. O processo de disponibilidade destes serviços
ainda pode ser melhorado, pois não podemos ter como contingência somente firewall e links de acesso, deve
ser analisado toda a estrutura da rede e sinalizar os pontos possíveis de falhas que possam interferir na
disponibilidade destes serviços. Um próximo passo seria o estudo da implementação de um Autonomous
System (AS) a qual a empresa já possui o licenciamento para uso, faltando somente recursos de hardware,
onde a empresa teria um bloco de IPs fixo independente do ISP contratado.
REFERÊNCIAS
FERREIRA, Felipa Silva; SANTOS, Nélia Catarina Gaspar Gil dos. Cluster de Alta Disponibilidade
Abordagem OpenSource. Portugal: 2005. Disponível em: <http://mosel.estg.IPleiria.pt/files/Artigo.pdf>.
Acesso em: 2 maio 2011, 5 p.
18
HARRISON, Jim; DIOGENES, Yuri; SAXENA, Mohit. Microsoft Forefront Threat Management
Gateway (TMG) Administrator’s Companion. Redmond, Washington: Microsoft Press, 2010. 1056 p.
RUIZ, André; Alta Disponibilidade. Conectiva S.A. Disponível em:
<http://suporte.lbr.com.br/linux/documentos/Portugues/Documentos%20Conectiva/ha.pdf>. Acesso em: 11
maio 2011. 30 p.
MICROSOFT TECHNET. Conceitos sobre Disponibilidade - Parte I. Disponível em:
<http://technet.microsoft.com/pt-br/library/cc668492.aspx>. Acesso em: 23 abril 2011.
CHECKPOINT SOFTWARES TECHNOLOGIES LTD. ClusterXL Administration Guide Version
R70.1. Disponível em:
<http://dl3.checkpoint.com/paid/59/CP_R70.1_ClusterXL_AdminGuide.pdf?HashKey=1307975880_229279
d1de468519c19727d77b7aad38&xtn=.pdf>. 2009. Acesso em: 20 maio 2011. 236 p.
CHECKPOINT SOFTWARES TECHNOLOGIES LTD. Checkpoint Firewall Administration Guide
Version R70.1 Disponível em:
<http://dl3.checkpoint.com/paid/f6/CP_R70_Firewall_AdminGuide.pdf?HashKey=1307976020_c64d98c92
d926f7d68c5e8e3396dfede&xtn=.pdf>. 2009. Acesso em: 23 maio 2011. 400 p.
19