Endereço IP vs hostname para se referir a servidores no ambiente de domínio do Windows

Question

Eu sempre preferi usar o hostname para coisas como compartilhamentos de rede, instâncias do SQL Server, etc. Eu costumo achar nomes de host mais descritivos e fáceis de lembrar.

No entanto, recentemente um dos nossos servidores de arquivos morreu. O IP foi vinculado ao adaptador de rede em outro servidor, os compartilhamentos foram recriados e quase todos os trabalhos que usaram o endereço IP continuaram funcionando, pois nada aconteceu.

Para os jobs em que usei hostname, tive que passar por várias dezenas de arquivos de configuração para alterar o nome do host e, no dia seguinte, descobri que realmente sentia falta de um casal. Note que desta vez eu realmente usei o endereço IP para que quando o servidor de substituição estivesse online eu não teria que mudar nada novamente: D

Sei que provavelmente existe uma maneira de criar outra entrada de DNS no controlador de domínio e / ou no roteador de rede (em vez de reatribuir o IP a outro servidor), mas não foi feito dessa maneira (não é minha decisão) .

Existem algumas diretrizes recomendadas sobre como isso deve ser feito? O que você faz no seu ambiente?

    

Answer 1

No caso de servidores de arquivos, como você mencionou, você deve estar usando Espaços para Nome do DFS, mesmo que tenha apenas um único servidor de arquivos. Isso permitirá que seus compartilhamentos sejam referenciados por \domain\share em vez de \server\share . No caso de uma falha, basta restaurar os arquivos para outro servidor e adicioná-lo ao namespace no lugar do servidor original. O caminho não muda, já que é baseado em domínio.

Também torna as migrações de servidores de arquivos super fáceis.

No seu caso em que você teve uma falha e ainda não tinha o DFSN configurado, você deve ter desabilitou a verificação de nome estrito , criou um CNAME no DNS com o nome do seu servidor inativo e apontou para o registro A do novo servidor (ou apenas criou um registro A), e continuou feliz com o seu dia.

    

Answer 2

O problema provavelmente não era o nome ou o endereço IP. Se você atribuiu o endereço IP a outro servidor, todas as chamadas para o nome do servidor com falha devem ter sido resolvidas para o endereço IP designado novamente para o servidor substituto. O problema era mais do que provável devido à verificação rigorosa de nomes, o que significa que o servidor substituto não respondeu autoritativamente ao nome do servidor com falha, o que pode afetar o acesso ao compartilhamento de rede e o acesso ao servidor SQL.

P: Qual endereço IP resolve o servidor com falha?

Resposta do servidor DNS: failed_server é resolvido para x.x.x.x

P: Qual endereço MAC é x.x.x.x em?

Resposta do servidor de substituição: x.x.x.x está em xx-xx-xx-xx-xx-xx

Q: OK. Posso acessar o compartilhamento em \failed_servername\share

Resposta do servidor de substituição: não sou servidor_seguro, desculpe.

link

    

Answer 3

Are there some kind of recommended guidelines about how this should be done? What do you do in your environment?

Sim, sempre use nomes de DNS / host sempre que possível, qualquer outra coisa, se feita corretamente, é loucura.

I realize there is probably a way to create another DNS entry in domain controller and/or network router (instead of re-assigning IP to another server) but it wasn't done that way in this case (not my decision).

Esta é a maneira de fazê-lo, geralmente em um mundo Windows usando o Active Directory - se isso exigir algum retrabalho por essas outras pessoas, então que assim seja, se eles lhe causarem algum problema, diga que eles precisam recuperar o atraso com os anos 90 como qualquer outra coisa ficou antiga antes disso.