Movendo Servidores no Mesmo Edifício

Aqui está o meu cenário: sou um desenvolvedor que herdou (sem o meu conhecimento) três servidores localizados no meu escritório. Também herdei o trabalho de ser o administrador dos servidores com uma distinta falta de conhecimento em administração de servidores e o google / ServerFault como ponto de referência. Felizmente, nunca tive que entrar em contato físico com as máquinas ou resolver qualquer problema, pois elas sempre 'funcionavam'.

Todas as três máquinas estão localizadas na mesma sala de dados e têm o seguinte objetivo:

Machine1- IIS 8.0 hospedando vários aplicativos internos
Machine2- Armazenamento de dados do SQL Server 2008 R2 para aplicativos internos
Machine3- Armazenamento em espelho do SQL Server 2008 R2 deMachine2

Todos os três têm discos rígidos externos conectados que fazem backups frequentes com freqüência.

Fui informado de que todos os três precisam passar de um data center para outro nas mesmas instalações. Não completarei a movimentação física do hardware, que será tratada por um responsável competente.

Além de fazer um backup completo de cada um, que considerações devo fazer antes de pressionar hipoteticamente o interruptor e ver meu mundo se mover?

^{Estou ciente de que está longe de ser ideal ter todos os três localizados na mesma sala / local, mas esse já passou do escopo desta pergunta.}

Pergunta genuinamente interessante, bem feita :)

Há algumas coisas que você precisa verificar antes dessa mudança, algumas fáceis, outras difíceis.

Energia - verifique se a nova sala possui não apenas a quantidade certa de tomadas, mas também o tipo certo - como no tipo de conector físico e se o local atual permite diferentes fases de energia por servidor para proteger contra falhas de fase única, então eu recomendamos que você replique 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 ao possível desligamento do servidor. Geralmente, você pode procurar a potência máxima (em watts) ou o calor (em BTUs) que cada servidor pode obter no site do fabricante - informe o gerente da obra e receba uma confirmação por escrito informando que o resfriamento naquele local suportará .

A rede - essa é 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 de uma rede eram praticamente iguais - tenho idade suficiente para lembrar daqueles tempos! mas hoje em dia o número de configurações de portas e o local na rede em que qualquer porta pode estar é astronômico, você precisa garantir que o pessoal da sua rede replicou TUDO para ser idêntico do antigo para o novo - novamente faça isso por escrito, pois não é fácil. Se algo der errado com essa mudança, eu colocaria dinheiro nas portas de rede que não são 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 compartilhada - novamente, caso seja necessário replicá-los de forma idêntica.

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

Outras respostas cobrem os aspectos técnicos da mudança. Você também pode ter que considerar algumas outras coisas.

Verifique se os usuários sabem que seus aplicativos ficarão inativos durante a mudança. Você desejará agendar a mudança, talvez fora do horário comercial, para minimizar o número de pessoas afetadas.

Peça a uma pessoa experiente (ou pessoas) para testar os aplicativos depois de abrir 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 aos usuários que a mudança foi concluída e peça que eles saibam se eles têm algum problema.

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

Nota lateral: Como você já declarou, 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 antes da movimentação. No entanto, você também deve planejar como organizar a mudança real. Pelo fato de o Machine3 ser um espelho do Machine2 , parece que o tempo de atividade é uma consideração significativa para os bancos de dados do SQL Server 2008 R2. O fato de ser um espelho oferece uma oportunidade. O motivo da existência de um espelho deve estar disponível quando o servidor principal não estiver. Isso inclui não estar disponível devido à manutenção, o que inclui a movimentação.

Faça um plano:
você deve fazer um plano por escrito de como a mudança será realizada. Pode ser necessário que você forneça esse plano, ou partes dele, para as pessoas que lidam com partes do trabalho (por exemplo, os responsáveis ​​pela mudança). Esse plano deve incluir todas as atividades anteriores à movimentação, a movimentação real e as ações pós-movimentação (por exemplo, verificação da funcionalidade).

Mova o básico:

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

Descrição mais detalhada da mudança:

A seguir, são apresentados dois métodos (Caminho A e B) do uso da Máquina3 para testar as conexões da Máquina1 e / ou Máquina2 . Você deve usar apenas um método. A maneira de fazer isso, ou mesmo se usar, depende das informações não contidas na pergunta (por exemplo, separação física dos locais finais da máquina, tamanho físico das máquinas, comprimento dos cabos de rede / energia, disponibilidade de extensões para os mesmos, similaridade de configurações de porta de rede, necessidades de tempo de atividade etc.). O uso do Machine3 para testar essas conexões potencialmente permite maior tempo de atividade do Machine2 , mas principalmente do Machine1 , que não possui espelho. Você pode optar por usar um ou outro método.

1. Mova o Machine3 primeiro.

   • Deixe Machine1 e Machine2 no lugar por enquanto.
   • Backup Machine3 e , em seguida, desligue-o
   • Se machine3 completamente movido para a nova localização.
   • [Caminho B: Não usado se você for usar a etapa opcional nº 2.] Se as configurações de rede e energia de todas as máquinas forem idênticas: Coloque a Máquina3 onde a Máquina1 está planejada para terminar usando as conexões destinadas à Máquina1 .
   • Faça o Machine3 voltar a funcionar. No novo local, verifique se está funcionando normalmente como um espelho do Machine2 . Isso fornecerá verificação física de que a configuração de todos os problemas (energia, rede etc.) está funcionando no novo local.
   • Resolva os problemas que surgirem.
   • Verifique se o Machine3 foi totalmente sincronizado novamente com o Machine2 antes de continuar.

2. Caminho A: (opcional):

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

3. Mova o Machine2 .

   • Sua prática com o Machine3 deve tornar isso muito mais suave.
   • Backup Machine2 e desligue-o
   • Mova Machine2 para o novo local; faça todas as conexões
   • Resolva os problemas que surgirem.
   • Verifique se o Machine2 foi totalmente sincronizado novamente com o Machine3 antes de continuar.

4. [Caminho B: Não é necessário se você testou todas as conexões com o Machine3 na etapa opcional nº 2] Se agora possui o Machine3 onde o Machine1 deve terminar:

   • Desligue o Machine3 .
   • Mova-o para o local planejado para terminar (fora do local em que você pretende que o Machine1 seja localizado).
   • Resolva os problemas que surgirem.
   • Verifique se o Machine3 foi totalmente sincronizado novamente com o Machine2 antes de continuar.

5. Mova o Machine1 .

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

Se algum dos IPs dos servidores for alterado e as conexões forem feitas com a caixa SQL via resolução DNS, será necessário agendar uma alteração nos registros DNS ao mesmo tempo que a movimentação.

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

• O software da intranet se conecta ao SQL Server via IP, NetBIOS ou DNS?
• As contas de usuário do SQL Server usadas pelo software da intranet têm autenticação limitada ao tráfego proveniente de um IP?
• Os funcionários da sua empresa acessam o SQL Server diretamente de qualquer planilha ou ferramenta de relatório; se sim, como eles definem o DSN?

Se você não obtiver exatamente os mesmos IPs ou se terminar em uma sub-rede diferente, precisará de acesso para alterar o código-fonte ou os arquivos de configuração de todos os aplicativos que se conectam ao servidor SQL. As pessoas podem confiar no acesso SQL não documentado e direto para relatórios ad-hoc.

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

Pense da seguinte maneira: enquanto sua corveta está sendo aperfeiçoada, 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 a sala era usada antes e quem tem as chaves? 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, por exemplo, troca noturna de dados por arquivo ou pelo uso de serviços da web? 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 demorar?

• Eu acho que é uma boa idéia 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 motor 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.