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:
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:
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.
Carlos Monteiro's Blog 