Este artigo tem por objetivo demonstrar um cenário real de problemas de replicação inter-sites no ISA Server 2006 Enterprise Edition.
Em cenários distribuidos, o ISA Server Enterprise Edition é uma excelente opção para ter controle centralizado de regras e acessos, aumentando o poder administrativo da equipe e facilitando a resolução de problemas em locais de dificil acesso ou onde não há pessoal técnico capacitado localmente.
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.
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.
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.
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.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.
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 já bastate conhecido AD, certo? Certo. Note que, até o presente momento, eu só falei de sites quando citei as localidades. E onde é que eu informo, no active directory, como se dá a replicação?? Active Directory Sites And Services, correto?? E como fazer isso no ADAM??? Através da ferramenta ADAMSites, que podemos chamar de “salvadora da pátria” nesse caso.
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. Eu precisava descobrir o que efetivamente estava acontecendo e consolidar minha teoria com resultados práticos. Agora o troubleshooting começa.
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 para me ajudar. 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, inicio o processo de instalação e chego no momento onde se inicia o processo de inserção. 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”. Na saída do comando, observei que ele estava 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.
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 ficará 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.
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”.`
Adam Tools http://technet.microsoft.com/en-us/library/cc776460(WS.10).aspx
Repadmin
http://technet.microsoft.com/en-us/library/cc811552%28WS.10%29.aspx
ISA e TMG Branch Office Setup
http://support.microsoft.com/kb/982871
Download ADAMSites
http://www.microsoft.com/downloads/en/details.aspx?familyid=e4024852-077f-49c2-8e57-2a37d57b0aad&displaylang=en
Network Monitor
http://support.microsoft.com/kb/933741
Este artigo foi originalmente escrito por:
Alberto Oliveira, CISSP
MCSA/MCSE: Security, MCT, MCTS, MCITP, CompTIA Security +, ITILV2
http://oliveiraalberto.wordpress.com/
http://twitter.com/_AlbertoOliveir
Luciano Lima [MVP] Brazil edited Original. Comment: Alterado o título para padronização e adicionado o [TOC].