Movendo servidores dentro do mesmo prédio

Pergunta genuinamente interessante, bem feita :)

Há algumas coisas que você precisa verificar antes desse movimento, algumas fáceis, outras difíceis.

Energia - verifique se a nova sala tem não apenas a quantidade certa de tomadas de energia, mas também se elas são do tipo certo - como no tipo de conector físico e se o local atual permite diferentes fases de energia por servidor para proteger contra falha monofásica, então eu 'exorto você a replicar isso também no novo local.

Resfriamento - você precisa verificar se não haverá um acúmulo imediato ou gradual de calor que levará ao superaquecimento e possível desligamento do servidor. Normalmente, você pode procurar a potência máxima (em watts) ou calor (em BTUs) que cada servidor pode consumir no site do fabricante - informe ao gerente do prédio e obtenha uma confirmação por escrito informando que o resfriamento naquele local funcionará .

Rede - essa é a difícil - não apenas o mesmo número de portas precisa ser replicado entre o local antigo e o novo, mas também o tipo, a velocidade e a configuração mais importante. Este último ponto é a chave - houve um tempo em que quase todas as portas em uma rede eram praticamente iguais - tenho idade suficiente para me lembrar desses tempos! mas hoje em dia o número de configurações de porta e o local na rede em que qualquer porta pode estar é astronômico, você precisa ter certeza de que o pessoal da sua rede replicou TUDO para ser idêntico do antigo ao novo - novamente, escreva isso por escrito como este não é fácil. Se algo der errado com esse movimento eu colocaria dinheiro, será nas portas de rede não serem idênticas, isso acontece o tempo todo.

'Outras conexões' - você sabe se seus servidores têm outras conexões além de energia e rede? talvez eles tenham links Fibre-Channel para armazenamento compartilhado, links KVM para uma tela de gerenciamento compartilhado - novamente, se você precisar replicá-los de forma idêntica.

Fora isso, sinta-se à vontade para voltar aqui com perguntas mais específicas e espero que tudo corra bem.

Outras respostas cobrem os aspectos técnicos do movimento. Você também pode ter que considerar algumas outras coisas.

Certifique-se de que os usuários saibam que seus aplicativos ficarão inativos durante a mudança. Você vai querer agendar a mudança, talvez fora do horário de trabalho, para minimizar o número de pessoas afetadas.

Faça com que uma pessoa (ou pessoas) experiente teste os aplicativos depois de ativar os servidores. Faça com que eles façam algumas verificações de sanidade para garantir que os aplicativos funcionem conforme o esperado.

Após o teste, informe a seus usuários que a mudança foi concluída e informe-os se tiverem algum problema.

É muito difícil dizer e limítrofe "muito amplo" para o nosso formato. A coisa mais importante que você precisa verificar é se precisa reconfigurar sua rede de alguma forma ou se eles podem continuar funcionando com os mesmos endereços. Mesmo que possam manter os mesmos endereços, certifique-se de que não estejam configurados via DHCP e/ou verifique se o servidor DHCP estará disponível no novo local.

Nota lateral: como você já afirmou, ter o servidor SQL e seu espelho está longe de ser o ideal. No entanto, ter as unidades de backup no mesmo local é realmente perigoso. Você precisa ter seu backup em um local físico diferente.

Outras respostas têm boas considerações pré-movimento. No entanto, você também deve planejar como organizar a mudança real. Pelo fato de Machine3 ser um espelho de Machine2 , parece que o tempo de atividade é uma consideração significativa para o(s) banco(s) de dados do SQL Server 2008 R2. O fato de ser um espelho lhe dá uma oportunidade. O motivo da existência de um espelho é estar disponível quando o servidor primário não estiver. Isso inclui não estar disponível devido a manutenção, que inclui mudança.

Faça um plano:
você deve fazer um plano por escrito de como a mudança será realizada. Você pode precisar fornecer este plano, ou partes dele, para pessoas que lidam com partes do trabalho (por exemplo, as mudanças). Este plano deve incluir todas as atividades pré-mudança, a mudança real e ações pós-mudança (por exemplo, verificação de funcionalidade).

Noções básicas de movimento:

1. Move Machine3 (o espelho do SQL Server): deixe-o totalmente operacional. Verifique a ressincronização.
2. Move Machine2 : Deixe-o totalmente operacional.
3. Move Machine1 : Deixe-o totalmente operacional.

Descrição mais detalhada do movimento:

O seguinte inclui dois métodos (Caminho A e B) de uso de Machine3 para testar as conexões para Machine1 e/ou Machine2 . Você deve usar apenas um método. A maneira de fazê-lo, ou mesmo se usar qualquer um, depende de informações não contidas na pergunta (por exemplo, separação física dos locais finais das máquinas, tamanho físico das máquinas, comprimento dos cabos de rede/alimentação, disponibilidade de extensões para os mesmos, semelhança de configurações de porta de rede, necessidades de tempo de atividade, etc.). Usar Machine3 para testar essas conexões potencialmente permite maior tempo de atividade para Machine2 , mas particularmente para Machine1 , que não possui espelho. Você pode optar por usar um dos métodos ou nenhum.

1. Mova Machine3 primeiro.

   • Deixe Machine1 e Machine2 no lugar por enquanto.
   • Backup Machine3 e, em seguida, desligue-o
   • Faça com que a Machine3 seja completamente movida para o novo local.
   • [Caminho B: Não usado se você for usar a etapa opcional nº 2.] Se as configurações de rede e energia para todas as máquinas forem idênticas: Coloque Machine3 onde Machine1 está planejado para terminar usando as conexões destinadas a Machine1 .
   • Coloque a Machine3 de volta em funcionamento. No novo local, verifique se ele está funcionando normalmente como um espelho da Machine2 . Isso fornecerá a verificação física de que a configuração de todos os problemas (energia, rede etc.) está funcionando no novo local.
   • Resolva quaisquer problemas que surgirem.
   • Verifique se Machine3 foi totalmente ressincronizado com Machine2 antes de prosseguir.

2. Caminho A: (Opcional):

   • Use Machine3 para testar todos os recursos destinados a Machine2 e Machine1 .
   • Desligue a Máquina3 e mova/alterne usando a posição/conexões para a Máquina2 , (verifique a ressincronização) e a Máquina1 (verifique a ressincronização). Se você planejou fazer isso, Machine3 deveria ter sido inicialmente configurado com as conexões destinadas ao uso final por Machine1 ou Machine2 , então você não deve configurá-lo primeiro no local final para Machine3 e depois alterá-lo 3 vezes, mas apenas 2 começando com ele usando as facilidades de uma das outras máquinas.
   • Verifique se Machine3 foi totalmente ressincronizado com Machine2 antes de prosseguir.

3. Mover Máquina2 .

   • Sua prática com Machine3 deve tornar isso muito mais suave.
   • Backup Machine2 e, em seguida, desligue-o
   • Mova Machine2 para o novo local; fazer todas as conexões
   • Resolva quaisquer problemas que surgirem.
   • Verifique se a Máquina2 foi totalmente ressincronizada com a Máquina3 antes de continuar.

4. [Caminho B: não é necessário se você testou todas as conexões com a Máquina3 na etapa opcional nº 2] Se agora tiver a Máquina3 onde a Máquina1 deve terminar:

   • Desligue a máquina3 .
   • Mova-o para onde está planejado para terminar (fora do local que você pretende que a Máquina1 seja localizada).
   • Resolva quaisquer problemas que surgirem.
   • Verifique se Machine3 foi totalmente ressincronizado com Machine2 antes de prosseguir.

5. Mover Máquina1 .

   • Tendo movido Machine2 e Machine3 (e esperançosamente testado as conexões reais que Machine1 estará usando fazendo com que Machine3 as use temporariamente), este deve ser o mais suave dos movimentos.
   • Backup Machine1 e, em seguida, desligue-o
   • Mova Machine1 para o novo local; fazer todas as conexões
   • Resolva quaisquer problemas que surgirem.
   • Se algo der errado com as instalações na posição que a Máquina1 deveria ocupar, você tem a opção de usar as instalações onde a Máquina3 está agora localizada. Esperamos que você já tenha conseguido testar todas as facilidades na posição da Máquina1 por tê-la usado pela Máquina3 por um tempo (Caminho A ou Caminho B).

Se algum dos IPs dos servidores for alterado e as conexões forem feitas para a caixa SQL por meio da resolução DNS, você precisará agendar uma alteração nos registros DNS ao mesmo tempo que a mudança.

Coisas que você deve saber sobre o software de intranet e bancos de dados:

• O software de intranet se conecta ao SQL Server via IP, NetBIOS ou DNS?
• As contas de usuário do SQL Server utilizadas pelo software da intranet possuem autenticação limitada ao tráfego proveniente de um IP?
• Os funcionários da sua empresa acessam o SQL Server diretamente de alguma planilha ou ferramenta de relatório, em caso afirmativo, como eles definem o DSN?

Se você não obtiver exatamente os mesmos IPs ou se acabar em uma sub-rede diferente, precisará de acesso para alterar o código-fonte ou os arquivos de configuração de qualquer aplicativo que se conecte ao servidor SQL. As pessoas podem estar contando com acesso SQL não documentado e direto para relatórios ad hoc.

Utilize seus servidores de "Recuperação de desastres". Mude para eles para lidar com a carga enquanto você move seus servidores de produção. Com o equipamento DR configurado corretamente, você pode fazer a mudança no meio do dia sem ter muito tempo de inatividade (até 15 minutos). Como os servidores de recuperação de desastres devem ser configurados da mesma maneira que os servidores de produção. Se você não possui equipamento de DR, recomendo fortemente obtê-los.

Pense desta maneira: enquanto sua corveta está sendo ajustada, use sua minivan para passar o dia.

Uma coisa que acho que não foi mencionada é a segurança física da nova casa dos servidores. Para que era usado o quarto antes e quem tem as chaves dele? Existe segurança adequada (sistemas de alarme, câmeras, etc.).

Algumas considerações além das outras respostas:

• Os aplicativos estão vinculados a outros, por exemplo, troca noturna de dados por arquivo ou pelo uso de webservices? Quais são as consequências quando os aplicativos não estão disponíveis? Os aplicativos relacionados podem lidar com isso ou eles falham ou até produzem resultados errados devido à falta de informações de seus aplicativos?

• Um tempo de inatividade é aceitável para seus usuários, empresa ou mesmo clientes? Quanto tempo pode ser?

• Eu acho que é uma boa ideia ter um plano para uma reversão. Você pode usá-lo no caso de um problema que não pode ser resolvido rapidamente, por exemplo, um problema de rede. Você provavelmente precisará manter o movedor disponível para o caso de trazer o hardware de volta.

• Seus aplicativos levam a um alto tráfego de rede e a rede precisa estar preparada para isso (provavelmente um problema muito mais improvável do que problemas com endereços e firewalls)? Se você tiver aplicativos em tempo real (por exemplo, software de videoconferência), as latências serão importantes.

• Os servidores devem caber no rack do servidor, se você tiver um.