Archive for the ‘ISA Server’ Category

Configurando o NLB do ISA Server 2006 e como alterar o modo de funcionamento do NLB de Unicast para Multicast

maio 11, 2010

 

Por Carlos Monteiro

Introdução

Antes de começarmos com o processo de troca do modo de funcionamento do NLB do ISA 2006 de unicast para multicast, vamos apresentar algumas informações conceituais sobre o mesmo.

De uma forma simples, o NLB é uma tipo de tecnologia de balanceamento de carga entre servidores, não exclusiva para Microsoft Windows. NLB é parte da família Windows Server 200x e é usado para distribuir o tráfego de rede para até 32 hosts. O NLB usa um algoritmo distribuído de tráfego de entrada para todos os nós, em um cluster NLB Windows. Assim, o NLB pode ser usado para fornecer failover e balanceamento de carga.

NLB Unicast ou Multicast

Network Load Balancing (NLB) pode operar em dois modos: Unicast ou Multicast.

Unicast
O modo de operação padrão é o Unicast. No modo Unicast, NLB altera o endereço MAC do adaptador de rede onde o NLB está ativado. Todos os nós do cluster usam o mesmo endereço MAC. O tráfego de rede irá para todos os nós, e será encaminhado para o controlador de filtro NLB.
Multicast
No modo de Multicast, o NLB atribui a cada adaptador de rede ativado um endereço Layer-2-Multicast. O endereço MAC original de cada nó permanecerá inalterado.
Ambos os métodos possuem seus prós e contras. A vantagem do modo Unicast é que ele funciona na maioria dos ambientes de rede, integrando com quase todos os roteadores e switches. Uma das desvantagens, é que todos os hosts no cluster NLB devem ter o mesmo endereço IP e endereço MAC.
Uma vantagem do modo Multicast é que todos os nós do cluster mantêm o seu endereço MAC original. Uma das desvantagens é que Multicast requer uma configuração adicional no switches, necessitando que seja criada uma entrada ARP estática no switch ligando o endereço IP (VIP Virtual = Endereço IP Virtual) para o endereço MAC do cluster compartilhado.
Observação:
A capacidade de suporte Multicast no switch depende do fornecedor do mesmo. Há também algumas informações adicionais sobre Multicast que você deve conhecer antes de habilitar o NLB Multicast na rede.

ISA Server e NLB

O ISA Server depende da configuração NLB do Windows Server 2003 que estende as características NLB para o ISA Server 2006, com o ISA Server 2006 Enterprise Edition.

Ativando NLB

Para ativar o NLB no ISA Server, os seguintes passos devem ser executados:

– Ter dois ou mais ISA Servers 2006 Enterprise instalados e configurados como membros de um único Array;

– Protocolo NLB instalado nas interfaces de rede que irá suportar o NLB, em ambos os ISA Servers;

O assistente de configuracao do ISA Server deverá ser utilizado para a criação do NLB. O assistente de configuração do Windows não será (e não deverá) ser utilizado.

Para configurar o NLB, basta abrir a console de gerenciamento do ISA Server, é ir em Arrays, “Nome do Array”, Configuration e Networks. Em Networks, clicar com o botão da direita do mouse e em Configure Load Balances Networks:

clip_image002

Figura 1: Configuração do NLB no ISA Server Enterprise.

O assistente de configuração do NLB é aberto.

clip_image004

Figura 2: Assitente de configuração do NLB no ISA Server.

Na guia de seleção de redes, basta selecionar a rede que será configurado o NLB.

clip_image006

Figura 3: Seleção da interface de rede para configuração do NLB.

Após a seleção, basta configurar o IP virtual que será utilizado pelo NLB.

clip_image008

Figura 4: Configuração do IP Virtual do NLB.

Clique em Next para configurar o NLB com o Ip Virtual.

clip_image010

Figura 5: Ip Virtual configurado no NLB.

Clique em Finish para finalizarmos a configuração do NLB.

clip_image012

Figura 6: Tela de finalização do NLB.

O ISA Server pede para as informações sejam salvas e os serviços sejam reiniciados.

clip_image013

Figura 7: ISA Server solicitando que as informações sejam salvas e os serviços sejam reiniciados.

Após essa etapa, os serviços de NLB são instalados no ISA e as etapas de configuração dos mesmos são realizadas.

clip_image015

Figura 8: Serviços do NLB sendo configurados.

Após a configuração dos serviços, os mesmos entrar no estado de execução, e o NLB está ativo.

clip_image017

Figura 9: Serviços do NLB ativos.

Alterando o modo de funcionamento do NLB para Multicast

Por padrão, o modo de funcionamento do NLB no ISA Server é Unicast.
O ISA Server 2006, com o hotfix (KB942639), é a primeira versão do ISA Server que o NLB pode ser alterado de Unicast para Multicast NLB.
A fim de permitir o uso de Multicast no ISA Server 2006 Enterprise, todos os servidores ISA precisam estar executando o hotfix KB942639, ou ISA Server 2006 Service Pack 1. Antes dessa atualização o NLB do ISA Server 2006 era suportado apenas em modo Unicast, o que nem sempre é ideal, dependendo do ambiente de rede.
Antes de começarmos a alterar o modo NLB, deverá ser realizado um backup full do ISA Server 2006, para fins de emergência.
Em primeiro lugar, todas as configurações necessárias para o NLB deverão ser anotadas, porque o processo de troca do modo Unicast para Multicast necessita uma reconfiguração do NLB.

clip_image010[1]

Figura 10: Registrando as informações do NLB.

Em grandes ambientes, múltiplas configurações de NLB podem existir, portanto, é recomendável que todas sejam registradas.

Em seguida, o NLB do ISA deverá ser desabilitado, usando a MMC do ISA. Isso pode ser feito clicando com o botão direito do mouse, e em seguida, Disable Network Load Balancing Integration.

clip_image018Figura 11: Desabilitando o NLB no ISA Server.

Clique em OK.

O ISA Server informa que as informações deverão ser salvas e os serviços deverão ser reiniciados.

clip_image013[1]
Figura 12: ISA Server solicitando que as informações sejam salvas e os serviços sejam reiniciados.

Nesse momento, vamos realizar o download e executar o utilitário NLBCLEAR em todos os nós do NLB do ISA Server. O NLBCLEAR limpa todas as informações do NLB no computador local. O download do NLBCLEAR pode ser feito do site da Microsoft em http://support.microsoft.com/kb/938550/en-us. Execute o RemoveAllNLBSettings.cmd através do prompt de comando, sem nenhum parâmetro.

clip_image019
Figura 13: Usando o NLBCLEAR.

Poderá haver um pequeno delay para que as alterações tenham efeito. É recomendado que os nós do NLS sejam reiniciados.

ARP cache

A tabela ARP de todos os nós deverá ser limpa. Para isso, execute o comando abaixo, via prompt, em todos os nós:

Arp –d *

FSMO Schema Master

ISA Server 2006 salva suas configurações em um banco de dados ADAM. ADAM é o banco de dados Active Directory Application Mode da Microsoft. Um Configuration Storage Server (CSS) central hospeda a configuração do ISA, e todos os membros do array usam esse CSS. Se o ambiente existir múltiplos CSS, o primeiro servidor é o CSS. O update do ISA Server para suporte à Multicast altera o esquema do ADAM. Dessa forma, o Schema Master deve ser contactado para esse update. Caso existam múltiplos CSS no ambiente, será necessário determinar qual hospeda o Schema Master FSMO role.

Existem alguns métodos para determinar quem hospeda o Schema Master role. Um deles é utilizar o script FINDCSSFSMO.VBS, de Jim Harrison. Jim administra um website chamado www.isatools.org. A ferramenta para determinar o Schema Master pode ser baixada através do link http://isatools.org/tools/findcssfsmo.zip.

Execute o script

cscript findcssfsmo.vbs [/server:NameOfCss]

ADSIEDIT

Outra forma de determinar o hospedeiro do Schema Master é usando o ADAM ADSIEDIT, que está instalado em cada Configuration Storage Server.

Inicialmente, estabeleça uma conexão no CSS através da porta 2171, então, navegue pelo objeto NTDS Settings, de cada nó do ISA Server.

clip_image020
Figura 14: usando o ADSIEDIT para localizar o Schema Master

Uma terceira forma de determinar o ADAM Schema Master é utilizar o MMC com a Snapin ADAM Schema. Através de um prompt de commando, registre a MMC com o seguinte commando:

Regsvr32 adam-schmmgmt.dll

clip_image021
Figure 15: Registrando a DLL do Schema Management.

Após o registro, abra a MMC e adicione a Snapin ADAM Schema e conecte no servidor ADAM, na porta 2171.

clip_image022
Figure 16: Snapin Schema MMC.

Após a conexão ser estabelecida, clique com o botão da direita do mouse no objeto ADAM Schema, que o Schema Master poderá ser visualizado.

clip_image023
Figure 17: Determinando o Schema Master com a Snapin Schema Master

Alterando o NLB para Multicast

Após localizar o servidor que hospeda a função de Schema Master, podemos executar o script KB938550.WSF, que pode ser baixado em http://support.microsoft.com/kb/938550/en-us, com a seguinte sintaxe, para alterar o NLB da rede especificada de Unicast para Multicast:

CSCRIPT KB938550.WSF /array:ISA-array-name /NLB:Muticast /Net1:name-of-the-ISA-network

clip_image024
Figure 18: Alterando o NLB de Unicast para Multicast.

Multicast com IGMP

É possível configurar o NLB do ISA Server para trabalhar com Multicast via IGMP (Internet Group Management Protocol). IGMP é baseado no protocolo IP e torna possível usar o Multicast IPv4, com a ajuda dos grupos Multicast. IGMP é usado para ajudar a integrar o protocol Multicast com diferentes ambientes de rede.

A sintaxe para habilitar o Multicast com o IGMP é semelhante ao Multicast tradicional:

CSCRIPT KB938550.WSF /array:ISA-array-name /NLB:IGMP /Net1:name-of-the-ISA-network

clip_image025Figure 19: Alterando o NLB de Unicast para Multicast com IGMP.

Após habilitar o NLB para trabalhar com Multicast, deverá ser recriados os NLBs no ISA Server, conforme o procedimento inicial do artigo. É recomendável que os nós do NLB sejam reiniciados.

Conclusão

Nesse artigo, foi possível verificar a configuração do NLB, no ISA Server 2006 Enterprise, e como alterar o modo de funcionamento de Unicast para Multicast. Como referência, indico o http://support.microsoft.com/kb/938550/en-us para mais informações e download dos executáveis / patchs.

ISA Server – Tráfego excessivo: como manter o firewall operacional

dezembro 17, 2009

 Olá!

Há muito tempo estou ensaiando para iniciar o meu Blog, e para isso, vou falar um pouco sobre performance do ISA Server, em situação extremas de tráfego. A situação que vou descrever abaixo aconteceu comigo, e vou comentar com vocês as soluções que encontrei para o caso.

Abraços e boa leitura!

 

Introdução

O ambiente analisado possuía uma seguinte configuração de software:

– Windows 2003 Enterprise R2 x86, com Service Pack 2;

– ISA Server 2006 Enterprise, com Service Pack 1;

– Todos os updates do servidor foram realizados;

A configuração básica de hardware era a seguinte:

– 8 interfaces de rede Giga;

– 64 GB de RAM;

– 4 processadores Xeon Quad Core 2.3 Mhz;

– 6 discos 146 GB, em RAID 0+1 (via hardware);

O *ambiente era enorme, com mais de 10 mil PCs. O ISA Server concentrava todas as conexões de rede, sendo que existiam 6 interfaces conectadas à redes distintas de diversos tipos, desde unidades remotas de baixa velocidade – 512 Kbps, até unidades com velocidades mais altas – 10 Mbps, além da rede LAN Gigabit. Cada uma dessas redes era configurada como “Network” com sua respectiva faixa de IP no ISA, e os relacionamentos entre elas era “Route”. Para finalizar, existe uma conexão com a Internet de 16 Mbps, que foi configurada como “External” no ISA. Para acesso à Internet, as redes internas possuíam um relacionamento do tipo “NAT” com a interface “External”.

*OBS – esse ambiente foi “herdado” e não estamos aqui discutindo se o layout do mesmo é a melhor solução. OK?

 

O Problema

Durante os horários de pico, todas as interfaces possuíam um alto trafego de rede, porém, não atingiam o máximo de sua capacidade. O problema é que “congelamentos misteriosos” aconteciam com o ambiente, fazendo com que a comunicação entre as redes fosse interrompida.

 

 

Diagnósticos

A análise inicial baseou-se em itens de hardware, onde dispositivos de rede e do próprio servidor foram analisados. Problemas foram encontrados e corrigidos, mas a causa raiz dos congelamentos entre as redes ainda não havia sido descoberto.

Inicialmente, foi realizada uma análise do Dashboard do ISA Server para verificar se alguma anomalia fosse encontrada. Alertas de conectividade haviam sido disparados, mas um alerta específico havia chamado atenção:

“Log Write Time Excessive”

Writing to the log took approximately 37 seconds. If this time exceeds 30 seconds, logging may fail and ISA Server may go into lockdown mode

No Log de eventos do Windows, o Event ID 23501 é apresentado, com a mesma descrição.

“Long Write Time Excessive” é um alerta que indica quando o ISA Server está tendo problemas em registrar entradas no log. Por padrão, quando o log demora mais que 15 segundos para registrar uma entrada, o alerta é disparado. Se esse tempo ultrapassar 30 segundos, o ISA Server entra em “lockdown mode”. Os seguintes artigos da Microsoft apresentam o problema de diversas formas:

http://support.microsoft.com/kb/941296/en-us

http://support.microsoft.com/kb/838711/en-us

http://support.microsoft.com/kb/960925/en-us

“Lockdown mode” é um processo do ISA Server que ativado no ISA Server quando certos alertas são disparados, como por exemplo, problemas de gravação no log. Como o ISA Server supõe que, se o log está habilitado as entradas devem ser gravadas, caso ele tenha problema para gravar no log, ele não irá permitir que o tráfego passe, já que os registro no log não estão acontecendo. Esse é um mecanismo de defesa natural do firewall.

Nesse caso específico, como o subsistema de disco do servidor é de alto desempenho, descartamos a possibilidade de I/O em disco ser o problema (apesar de realizarmos uma análise através do Performance Monitor). Através da análise do tráfego de rede (utilizamos diversas ferramentas para isso, como o Network Monitor do Windows, e PRTG – de terceiros), descobrimos que a rede em geral estava enfrentando um ataque em massa de vírus / worms. Isso estava provocando o problema de gravação no log, e, conseqüentemente, o “lockdown mode” do ISA Server. Como o ambiente é muito disperso, com localidades remotas e de difícil acesso (ou inacessíveis), teríamos que utilizar uma solução de contorno no ambiente.

Para maximizar a performance de gravação do Log, trocamos de MSDE para TXT. A seguinte tela demonstra a alteração:

fig1

fig2

Console do ISA Server/Nome do ISA Server/Monitoring/Logging/Configure Firewall Logging e Configure Web Proxy Logging.

Com isso, o tempo de gravação foi reduzido, e os alertas pararam de acontecer. Para sanar o tráfego dos PCs que estavam infectados, foram criadas regras de bloqueio de tráfego para os mesmos. Porém, os congelamentos ainda estavam acontecendo. Com isso, novas análises foram realizadas, mas agora no log do ISA. A seguinte mensagem de erro foi apresentada com freqüência no “Result Code” do Log do ISA:

0xC0040016 FWX_E_NO_BACKLOG_PACKET_DROPPED

Esse é outro problema de registro no log, mas dessa vez relativo ao tráfego corrente. Isso pode acontecer, tanto quando o ISA Server necessita realizar uma pesquisa DNS, para detectar que um determinado IP pertence a um determinado destino (vale lembrar que o tráfego estava intenso no ISA Server), ou quando uma determinada regra está sendo muito utilizada e registrando muitas informações no log. Como solução de contorno, foi desativado o registro de log dessa regra (já que a sua função e suas origem são bem conhecidas), conforme figura abaixo:

fig3

fig4

Com essas medidas, o ISA Server continuou operacional e foi possível ganharmos o tempo suficiente para que a infestação de vírus fosse contida (sem downtime). Após isso, as configurações do ISA Server puderam ser retornadas ao normal.

 

 

 

Conclusão

Em situação extremas de tráfego, o ISA Server pode encontrar problemas para registro de informações no log. Para isso, medidas de contorno citadas acima podem ser tomadas para evitar que o ISA Server entre em “lockdown mode” o bloqueie o tráfego de outras maneiras. Utilize-as sempre que possuir uma situação parecida, onde a disponibilidade do serviço é primordial para o momento e o tempo para a tomada de decisão é curto.

Abraços e até a próxima.

Carlos Monteiro.