O Red Hat Server não responde depois que o controlador de domínio primário é desligado

Question

Temos vários servidores (servidores de aplicativos, servidores da Web e servidores FTP) executando o Red Hat 5, todos virtuais. Também temos uma configuração semelhante que é baseada no Windows. Ontem, nossa equipe de infraestrutura precisou desligar o controlador de domínio primário para que pudessem mover o servidor físico para um novo rack. Sua suposição era que, assim que o controlador de domínio primário fosse desativado, o controlador de domínio secundário atenderia. Assim que o controlador de domínio principal foi desativado, todos os servidores de aplicativos baseados em Linux diminuíram a velocidade, até o ponto em que simplesmente tentar efetuar login via ssh levou aproximadamente 3 minutos.

Antes que pudéssemos concluir a solução do problema, a equipe de infraestrutura conseguiu colocar o controlador de domínio primário novamente on-line.

Durante o tempo de inatividade do controlador de domínio primário, todos os servidores baseados em janelas pareciam estar funcionando normalmente.

Nosso primeiro pensamento foi que os servidores Linux não tinham o controlador de domínio secundário listado como um servidor DNS, mas esse não é o caso. Os servidores red hat não se ligam a nenhuma funcionalidade do AD, além de usá-lo como um servidor DNS.

Quaisquer pensamentos sobre o que mais poderíamos verificar? Nós não somos realmente administradores de sistemas Linux, então eu não tenho certeza se estamos perdendo algo bem básico.

    

Answer 1

Depende do que você está usando para autenticação. Parece que os mecanismos de fail-back para o que você está usando estavam demorando demais ou trabalhando muito devagar. Se você estava usando LDAP para auth e tinha um único endereço IP listado em suas configurações para verificação, então sim, o que você está vendo é totalmente apropriado para esse caso. Se você estiver usando o Winbind, ele deve ser inteligente o suficiente para fazer o failover para outro controlador de domínio, mas ainda pode demorar um pouco antes de tomar essa decisão.

Acredito que o problema "apenas um servidor LDAP pode ser listado no LDAP-auth config" já existe há algum tempo. Uma maneira de contornar isso é fazer com que a entrada DNS aponte para uma entrada DNS round-robin entre vários controladores de domínio. Outra possibilidade, se você tiver a infraestrutura para isso, é hospedar o endereço em um balanceador de carga; nós fizemos isso no meu antigo emprego e funcionou muito bem.

    

Answer 2

Os servidores do RHEL usam o DNS como resolvedores de DNS ou o usam para se conectar a outros serviços? Você verificou os logs (por exemplo, / var / log / messages) nesses servidores sobre o que estava acontecendo?

Para mim, parece que alguns serviços em servidores são muito dependentes do domínio e a não resolução desses domínios resultou em uma tentativa vigorosa de se reconectar a esses domínios.

Você talvez possa testar isso com a suspensão temporária dos domínios que os servidores RHEL estão usando.

    

Answer 3

Tente desativar "GSSAPIAuthentication" no / etc / ssh / sshd_config. Eu tive um problema semelhante que foi resolvido dessa maneira. Alguns dos recursos SSO GSSAPI, eu acho que tentar fazer uma pesquisa inversa que, naturalmente, falharia se os servidores DNS estivessem offline.