1

ESTUDO E IMPLEMENTAÇÃO DE ALTA

DISPONIBILIDADE DE SERVIÇOS UTILIZANDO DOIS

ISP1

Rodrigo Alberto Schlabitz <rodrigo.schlabitz@gmail.com>

César A. H. Loureiro <cesar.loureiro@gmail.com> – 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.

2

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

3

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 co-

utilizaçã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)

4

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.

5

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

6

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.

7

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.

8

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

9

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

10

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.

11

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.

12

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:

13

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:

14

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:

15

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:

16

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:

17

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

18

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:

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.

0%

5%

10%

15%

20%

ICMP (Pacotes)

15%

8,00%

Teste 1

Teste 2

Teste 3

Teste 4

Média em Produção

Média em Homologação

19

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.