IPs de backup, IPs do Exchange, IPs de DAG e IPs de iSCSI; de que forma lidamos com isso ?

Alguns conceitos realmente nos dão um nó na cabeça, um exemplo é quando falamos de configurar um DAG e seu backup de forma funcional, especialmente se possuímos uma rede apartada de backup.

Afinal, qual é a melhor pratica no que se refere a configuração de IP de Exchange ?

Retornando ao passado, especificamente com o Exchange 2010 – já fazem 8 anos, heim?! –, existia o conceito de rede apartada de todas as outras apenas para comunicação dos nodes pertencentes ao DAG, em poucas palavras seria uma subnet/VLAN segmentada apenas para o heartbeat entre os nodes do cluster.

Esse conceito ficou no passado, e com a chegada do Exchange 2013 a Microsoft realmente virou a página, passando a recomendar o uso de apenas uma interface de rede para a comunicação dos servidores do DAG e também para a comunicação MAPI. Juntamente com essa mudança, a Microsoft passou também a não incentivar mais o uso de NIC Team, alegando que quanto mais simples fosse a infraestrutura, melhor seria seu aproveitamento e a complexidade para troubleshootings. Esse conceito veio baseando-se em que a alta disponibilidade será proveniente a nível de software, promovida pelo próprio DAG com pelo menos três nodes, deixando-se assim de lado o uso de redundâncias e nível de hardware.

Passaram-se mais alguns anos, e cá estamos com o Exchange 2016 – a beira do Exchange 2019 – e podemos dizer que pouca coisa mudou desde então. A Microsoft continua mantendo sua recomendação em deixar a coisa mais simples possível, mantendo apenas uma interface de rede para as redes de MAPI e DAG, sem a necessidade de NIC Team, duas interfaces separadas por subnet/VLAN, ou redundância a nível de hardware.

Para nós então que estamos sob o Exchange 2013 ou 2016, basicamente se formos seguir a PA (Prefered  Architecture), nós teremos apenas uma interface de rede na máquina, porém e no caso em que possuímos a necessidade de uma rede de backup apartada ? Nesse caso somos obrigados a fugir da PA recomendada pela Microsoft e instalar uma nova interface de rede nos servidores pertencentes a DAG, seguindo alguns requisitos:

  • Em todas as interfaces de rede usadas para o backup, desabilitar o “Register this connection address in DNS”.

 

  • Configure sempre o binding order de cada servidor para que a interface de rede principal tenha preferência sobre a interface de rede de backup:

2

  • Em todos os servidores pertencentes ao DAG, configure o DNS lookup apenas para utilizar a interface de rede principal:

3

Após realizados os passos mencionados, nos resta iniciar a configuração de rede no DAG. Por padrão o DAG possui um parâmetro habilitado de configuração automática, o que nos impossibilita de realizar qualquer mudança. Após a alterar para modo manual, podemos então realizar a criação de uma rede

 

  • Habilitar o modo manual de configuração de rede:
Set-DatabaseAvailabilityGroup "DAGNAME" -ManualDagNetworkConfiguration $true

 

  • Verifique se já existe um Network Group para a subnet de backup com o comando:
Get-DatabaseAvailabilityGroupNetwork

 

  • Após verificar que existe, desabilite o uso de MAPI e Replicação com o seguinte comando:
Set-DatabaseAvailabilityGroupNetwork -Identity “NOMEDAG\DAGNetwork02” -ReplicationEnabled:$False MapiAccessEnabled:$False -IgnoreNetwork:$True

Nota: Nos casos em que o servidor utilize também uma rede de iSCSI, é recomendado que se faça o mesmo processo feito para a rede de backup, uma exclusão total de seu uso pelo Exchange Server com os atributos -ReplicationEnabled:$False MapiAccessEnabled:$False -IgnoreNetwork:$True

Dessa forma nós temos todas as configurações necessária para o bom funcionamento do backup/DAG. Lembrem-vos de alguns pontos de atenção:

  • Não se adiciona IP de backup no DAG. A ferramenta de backup deve ser capaz – digo a nível de roteamento – de contatar o IP do DAG para realizar a verificação de onde estão os Databases para realizar o backup. Após essa verificação, a ferramenta de backup irá iniciar o backup contatando o IP de backup diretamente do host.

 

  • Ok Denis, mesmo sabendo que não se adiciona IP de backup na DAG e mesmo sabendo que não é suportado, é minha única solução e quero correr o risco, existe algo que se possa fazer ? Em teoria sim, nunca testei e não recomento, mas esse artigo explica uma possível forma de contorno para adicionar um IP de backup na DAG.

 

  • Como os IPs de backup atribuídos aos nodes do DAG não possuem registro no DNS, a melhor pratica no caso é atribuir os IPs no HOSTS file do servidor de backup, a menos que exista um DNS especifico apenas para a rede de backup.

 

  • Não são todos os softwares de backup que são compatíveis com a nova feature IP Less – a não utilização de IP no DAG – portanto é necessário verificar diretamente com o desenvolvedor do produto. Um que posso adiantar de antemão que não suporta é o EMC Networker.

 

  • Atençao também ao criar o filesystem dos databases e logs em formatação ReFS – como recomenda a PA do Exchange 2016 – pois conforme mencionado neste meu artigo, algumas ferramentas de backup suportam apenas o uso de NTFS, portanto veja sempre a matriz de compatibilidade do teu produto, lembrando sempre que a Microsoft não oferecera suporte a nenhuma ferramenta de backup terceira.

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s

Crie um website ou blog gratuito no WordPress.com.

Acima ↑

%d blogueiros gostam disto: