IPs do Exchange, Backup, DAG e iSCSI; como 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. Passou-se 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. Eles alegaram 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, 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. A interface de rede principal deve ter preferência sobre a interface de rede de backup:
-
Em todos os servidores pertencentes ao DAG, configure o DNS lookup apenas para utilizar a interface de rede principal:
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 rede 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. Isso ocorre 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 – DAG sem IP. 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.