Durante o tempo que passei no serviço Professional da Univention, trabalhei em vários projetos semelhantes e a única coisa que falta na descrição do problema é que o LDAP é realmente usado.
A primeira pergunta que você precisa verificar é
- se seus serviços são ou não tolerantes a falhas suficientes para sobreviver a uma pequena interrupção
- A base do LDAP é codificada em qualquer lugar
Depois de determinar o que está conectado ao servidor LDAP, você pode planejar o tempo de inatividade para cada serviço.
Para o tempo de inatividade real, descobri que um intervalo é geralmente melhor do que rodar os dois sistemas em paralelo. Executar os dois servidores LDAP em paralelo, ou duas bases LDAP em um sistema, geralmente implica que você precisa fazer alterações em ambos os sistemas e mantê-los em sincronia e acabar com mais trabalho e problemas, então uma mudança repentina seria.
Se você quiser minimizar o tempo de inatividade, a virtualização ou um segundo servidor físico seria o caminho a percorrer. Clone o sistema com seu LDAP e remova-o da rede. Faça as alterações no clone como você mesmo descreveu. Altere o IP e o nome do host do novo servidor para corresponder ao servidor ldap produtivo. De preferência, teste sua maioria das aplicações, se houver alguma implicação. Desligue o servidor antigo e conecte a rede ao novo. Altere os aplicativos que não fazem fallover automaticamente.
Durante todo o procedimento, qualquer alteração no LDAP do servidor antigo também precisa ser replicada para o novo. Esteja ciente de que alguns serviços, computadores (especialmente o Windows conectado ao Samba) ou usuários podem alterar suas senhas sem informar a um administrador.
O tempo de inatividade do LDAP pode ser minimizado em alguns segundos, se você alternar a interface de rede virtual com um script.