Duas semanas atrás, recebi, em minha empresa, um chamado já atendido por outro analista, também especialista em ISA Server. Ele não pôde dar continuidade ao chamado por conta de um projeto e o mesmo foi “escalado” para mim.
O caso me chamou a atenção pela ausência de dados que pudessem ajudar no troubleshooting.
Produto: ISA Server 2006 Enterprise Edition SP1 + Supportability Update
Descrição do cenário:
O cliente possui um cenário com vários sites remotos, conectados por links de variadas velocidades. Para fazer uso dos recursos de gerenciamento centralizado, com política corporativa, o mesmo optou por utilizar o ISA 2006 EE, tendo 1 CSS e 2 nós de array no escritório central e arrays distribuidos, de acordo com a localidade (sites), consolidando ISA e CSS na mesma máquina.
Descrição do problema:
Ao adicionar novos arrays ao ISA, a instalação do novo array demorava por volta de 4 horas, sem nenhum motivo aparente para isso. Além disso, por vezes, o novo array demorava mais de 1 dia para aparecer no CSS do escritório central e ser replicado para os demais arrays, causando inconsistência de replicação e, consequentemente, na utilização do produto.
Dados para troubleshooting:
Nenhum. Não havia indicativo, nos logs de evento do produto, do que poderia estar ocorrendo para isso. O analista que atendeu o caso antes de mim fez várias verificações, testes, sem sucesso. Aproveitei o que ele já havia feito para continuar a análise.
Testes iniciais:
Análise de logs, testes de replicação e avaliação dos logs de replicação através da ferramenta repadmin, do ADAM tools.
Atenção: Para utilizar o repadmin com o ISA Server, é necessário, no comando, utilizar a sintaxe nomedoservidor:2171. Lembre-se de abrir o repadmin do ADAM! Aparentemente não havia problema de replicação no ambiente, corroborado pelos logs e testes.
Continuei avaliando o cenário e resolvi simular a instalação de um novo ambiente do zero, de acordo com os procedimentos utilizados pelo cliente.
Foram instalados novos servidores, devidamente configurados e prontos para a nova instalação. Cheguei a cogitar a possibilidade de o problema ser a versão do ADAM do ambiente, visto que ele já estava com a versão mais recente do produto e a midia sequer tinha o SP1. Por isso, realizei a integração do SP1, conforme artigo anterior meu aqui no blog. Obviamente, não tive sucesso . O servidor já ia em 2 horas e nada de terminar a instalação. Abortei e decidi mudar a estratégia. De que forma?? Vamos para a teoria.
A teoria:
O ADAM (“apelido” do Active Directory Application Mode) nada mais é do que um servidor LDAP, com vários itens semelhantes ao do nosso já conhecido active directory. Ora, se o ADAM é um “active directory” da aplicação ISA Server, ele deve se comportar, em termos de replicação, “igual” ao nosso querido e estimado AD, certo? Certo. Nesse momento você deve estar pensando: “E ai, mano? E ai?”. Note que, até o presente momento, eu só falei de sites quando citei as localidades, não é?? E onde é que eu informo, no active directory, como se dá a replicação?? Active Directory Sites And Services, correto?? E quem disse que tem isso no ADAM??? Não, não tem. Mas tem uma ferramenta chamada ADAMSites, que podemos chamar de “salvadora da pátria” nesse caso.
A descoberta:
Executando o ADAMSites, descobri que todos os servidores estavam no mesmo site do ADAM, não havendo restrição de quem replica com quem e em como isso é feito, já que, do ponto de vista do ADAM, TODOS os servidores estão no mesmo site e subnet. Portanto, QUALQUER UM pode ser utilizado para replicar de um ponto a outro ou até mesmo, pasmem, para a criação de um novo array/site. Nesse momento, eu tive aquele momento “venha para a luz”. Vi a dita cuja iluminando o servidor e me “chamando”. Eu precisava descobrir o que efetivamente estava acontecendo e consolidar minha teoria com resultados práticos. Agora o troubleshooting começa.
Instalação do ADAMSites:
Troubleshooting, finalmente:
Depois de, segundo o word, 602 palavras, chegamos ao que interessa. Como um grande amigo meu costuma dizer, baseado em uma expressão utilizada pela Laura Chapell (aquela cidadã do Wireshark), “packets never lie”. E já que os pacotes não mentem, network monitor na veia. Instalei ele nos servidores em questão para monitorar o tráfego e ver se havia comunicação e transferência de informação entre o servidor novo e meu CSS da central. Captura iniciada, põe o cd, sim, eu aceito, bla bla bla, chega na parte que interessa. Mando criar o array, o setup inicia, começa a instalação e… Cadê os pacotes no CSS?? Para saber onde ele estava criando as informações, netstat –na | find “2171” e netstat -na | find “2173”. E lá estava o meu novo servidor, replicando com o servidor que possuia o link MAIS LENTO DE TODO O CENÁRIO. Bem, dá pra imaginar, agora, porque o setup dos novos servidores demorava 4 horas. Eu já tinha os dados, já sabia o que estava ocorrendo, já havia provado minha teoria. Hora de resolver.
A resolução:
Eu precisava criar uma topologia de replicação que fosse organizada e fizesse o melhor uso possível dos links existentes entre os pontos. Como todos os saltos , obrigatoriamente, passavam pela central, optei por utilizar o conhecido Hub and spoke, onde os pontos remotos replicam com a central, e somente com ela, sem interação entre si. Assim, o seguintes passos eram necessários:
1 – Criação dos novos sites, de acordo com a localidade;
2 – Criação dos “site links”, para que tivessemos os links de replicação ativos e definidos;
3 – Mover os servidores para os seus devidos sites, evitando o problema anteriormente encontrado.
Criei um cenário de exemplo para mostrar os passos que utilizei, já que, por questões de segurança, não posso expor o cenário de meu cliente em local público.
O nosso cenário é composto de um Head Office (escritório central) e 2 branch offices (escritórios remotos), de acordo com o desenho abaixo.
Nesse cenário, temos 3 integrantes do ambiente de replicação. O CSS-HEAD-ISA2K6, o FW-BRCH1-ISA2K6 e o FW-BRCH2-ISA2K6.
Saída do ipconfig do Head Office
Saída do ipconfig do branch1
Saída do ipconfig do Branch 2
Antes da criação dos sites e do reposicionamento do servidores, o comando adamsites sites gera a seguinte saída:
Como vocês podem observar, todos os servidores fazem parte do Default-First-Site-Name, site padrão criado na instalação do ISA.
Vamos, então, criar os os novos sites, atraves do comando Adamsites site create nomedositedesejado. Veja exemplo abaixo:
Saída do Adamsites Sites, após criação dos novos sites:
Uma vez que criamos os sites, vamos criar os links de replicação entre os branch offices e o head office.
Para isso utilizaremos o comando :
adamsites Sitelink createNomeDositeLink NumeroDeparticipantesdoSiteLink NomedoSite1 NomedoSite2 NomedoSiteN CustodeReplicação IntervaloDeReplicação(em minutos) “Descrição do Site Link”
Devemos ter atenção especial para o custo da replicação e o intervalo. O custo merece atenção especial em topologias onde você terá um site participando de mais de um link de replicação. Seria como, por exemplo, eu ter, no meu cenário, os branchs 1 e 2 replicando entre si, além de replicar com a central.
O custo definirá de qual caminho será a prioridade de replicação. Links mais velozes devem ter custo menor para ter prioridade sobre os mais lentos. Quanto menor o custo, maior a prioridade. O intervalo mínimo de replicação permitido pelo comando é de 15 minutos. Bastante cuidado ao definir o intervalo, para que o mesmo não seja muito baixo, em ambientes com atualizações muito constantes, e acabe gerando mais tráfego do que o esperado.
Por fim, devemos mover os servidores para os sites de destino.
adamsites MoveServer “NomedoServidor” SitedeOrigem SitedeDestino
Com a estruturação citada, agora, os servidores e sites ficam da seguinte forma:
A replicação fica configurada assim:
Notem que não existe link direto entre o Branch Office 1 e o Branch Office 2, exatamente para evitar que a replicação passe por dentro de um link de menor velocidade.
Conclusão:
Os pacotes não mentem, como pudemos observar no caso acima. Sempre que possível, se familiarize com ferramentas de monitoramento e captura de pacotes de rede. Muitas vezes, um problema não aparente pode residir na rede e a melhor forma de de descobrir isso é exatamente analisando os pacotes e as informações que eles nos trazem.
Lembrem-se sempre: “Packets Never Lie”.`
Links para referência:
Adam Tools
http://technet.microsoft.com/en-us/library/cc776460(WS.10).aspx
Repadmin
http://technet.microsoft.com/en-us/library/cc811552(WS.10).aspx
ISA e TMG Branch Office Setup
http://support.microsoft.com/kb/982871
Download ADAMSites
Network Monitor
http://support.microsoft.com/kb/933741
Eu sei que o post ficou bem grande, mas eu procurei ser o mais detalhista possível, para que vocês tenham a informação mais completa. Espero que gostem.
Boa leitura.
[]’s
Alberto Oliveira
Microsoft MVP, Forefront
Segurança da Informação 
Parabéns!
Como sempre, um excelente material técnico.
“Packets Never Lie”…
[]’s
GK