Perdoe-me se não consigo ser totalmente claro aqui. Não é intencional, sou desenvolvedor de nível sênior em uma empresa muito pequena e preciso atuar como gerente no momento.
Enfim, a história é que temos 2 servidores Dell mais antigos com SQL Server 2008 Standard em um "cluster". Coloquei isso entre aspas porque ainda não estou 100% claro sobre o que isso significa. Temos dois servidores blade totalmente novos e queremos migrar os bancos de dados existentes para o novo hardware.
Ok, então aqui está a pegadinha. Precisamos fazer isso com pouco ou nenhum tempo de inatividade. Disseram-me que podemos expulsar o nó passivo e, em seguida, instalar um dos novos servidores. Mas também me disseram que esta é uma etapa perigosa porque algo pode dar errado e causar falha no cluster e então ficaríamos sem nada porque o servidor ativo não seria capaz de voltar a funcionar.
Alguém tem alguma idéia de como lidar com isso? Disseram-me que a única maneira de garantir o sucesso é ter pelo menos um dia de inatividade, onde criamos um novo cluster no novo hardware e depois migramos os bancos de dados 1 por 1.
[Editar] Como ainda está relacionado a esta questão, gostaria de adicionar outra pergunta. É possível removermos uma máquina do cluster. Em seguida, crie um novo cluster com o nó removido como máquina ativa e, em seguida, traga um novo servidor para ele? Preservar efetivamente o cluster antigo enquanto as novas máquinas são trocadas caso algo dê errado?
Responder1
pouco ou nenhum tempo de inatividade
Embora seja de pouca ajuda agora que você deveria estar executando uma empresa se precisar de alta disponibilidade, o recurso mais óbvio que você usaria nessa situação é a capacidade de ter até 16 nós em um cluster, portanto, no seu caso, você apenas teria adicionado Mais 2 nós removeram aqueles que você não queria mais. Eu consideraria atualizar a versão enquanto você atualiza o hardware
... Mas também me disseram que esta é uma etapa perigosa porque algo pode dar errado e causar a falha do cluster e então ficaríamos sem nada porque o servidor ativo não seria capaz de voltar a funcionar.
Tudo é possível. Embora eu nunca tenha visto um cluster de failover do servidor 208 sql 2008 simplesmente morrer, é teoricamente possível. Observe que o nó ativo não fica "inativo" durante a atualização do nó, portanto não há nada para ser desativado. O cluster está simplesmente rodando em 1 nó sem possibilidade de failover. O pior cenário razoável é que o nó antigo esteja de alguma forma morto e a substituição não seja adicionada; nesse caso, você estaria executando sem capacidade de failover até que o problema que está causando a não adição do servidor seja resolvido.
Disseram-me que a única maneira de garantir o sucesso é ter pelo menos um dia de inatividade, onde criamos um novo cluster no novo hardware e depois migramos os bancos de dados 1 por 1.
Essa é provavelmente a única maneira de garantir o sucesso do cara que faz o trabalho. Eu faria a pergunta inocente: "se leva um dia de inatividade para mover um cluster, por que eu agruparia em primeiro lugar? Eu poderia comprar 2 máquinas e deixar 1 desligada e pronta para esse tipo de disponibilidade". Resumindo, você precisa encontrar alguém que realmente trabalhe com clusters antes e entenda a tecnologia envolvida. Presumindo que não haja problemas únicos (por exemplo, sua empresa escreveu algunsquasesoftware com reconhecimento de cluster que é executado no cluster) Acho que a maioria dos administradores profissionais da Microsoft ficaria com vergonha de dizer que levaria um dia de inatividade para substituir/adicionar hardware a um cluster existente e funcional
Responder2
Em primeiro lugar, a estratégia recomendada no final da sua pergunta é a maneira que eu recomendaria fazer também, mas como isso não é uma opção, é assim que eu lidaria com isso. Você parece confuso sobre um cluster, basicamente ambos os servidores possuem SQL instalado e serviços de cluster, com um comando através de serviços de cluster você pode "rolar" o SQL de um servidor para outro. Se eu estivesse no seu lugar, faria como você sugeriu, transferiria todos os serviços para um nó, removeria o segundo nó do cluster, adicionaria um de seus novos servidores como um nó do cluster, transferiria todos os serviços para o novo nó do cluster, adicione o segundo novo nó, remova o segundo nó antigo do cluster.
**Observe que se você não estiver familiarizado com serviços de cluster e/ou instalações SQL em cluster e tentar fazer isso em seu sistema ativo, isso pode acabar muito, muito mal para você. Muito pior do que um dia de inatividade planejado. Eu contrataria um consultor com experiência em clusters ou, se essa não fosse uma opção, configuraria um ambiente de teste que pudesse testar o processo por dentro e por fora.
Aquié um link para as etapas para adicionar um nó ao cluster.
Responder3
Você não precisa quebrar o cluster antigo, a menos que queira usar o hardware novamente. Eu recomendaria o seguinte:
- Crie um novo cluster com os novos blades
- Instale o SQL no novo cluster, mantenha as letras das unidades, caminhos, porta e nome da instância (se aplicável) iguais
- Após a instalação, restaure/substitua os bancos de dados master e msdb do antigo servidor SQL para o novo para obter os logins e trabalhos, ou então faça o script dos trabalhos no antigo e use sp_help_revlogins
- Faça logon ou espelhe o banco de dados do servidor antigo para o novo para atualizar os dados
Isso deixará sua nova instância no mesmo estado da antiga, junto com uma nova instalação do sistema operacional e do SQL. Para fazer a transição para o novo cluster, você pode fazer o seguinte, assumindo que o nome da sua instância antiga seja INSTA e o novo seja INSTB:
- Coloque a antiga instância SQL off-line
- Recupere os bancos de dados no novo servidor
- Exclua o registro DNS INSTA do DNS do Active Directory
- Crie um novo registro DNS CNAME (alias) no DNS do Active Directory que aponte para INSTB
Feito isso, os aplicativos deverão estar se conectando ao nome antigo da instância SQL, mas isso os levará ao novo servidor. Pode ser necessário executar "ipconfig /flushdns" em todos os servidores de aplicativos para que a alteração do DNS funcione mais rapidamente. Certifique-se de executar ping no nome antigo para ver quando ele aponta de volta. Usamos esse método para transição porque nos permite manter o cluster antigo caso precisemos reverter. Você não poderá ativar a instância antiga do SQL até alterar o parâmetro Nome de rede do SQL Server para outro, mas, uma vez feito isso, basta apontar o alias DNS de volta para o antigo, se desejar reverter.
Responder4
Sem conhecer as especificidades do hardware para saber se isso funcionaria, minha sugestão seria transferir a imagem do antigo nó passivo para o novo servidor. Usar algo como o Acronis, que permitiria que a imagem fosse colocada em um novo hardware, deveria permitir basicamente mover o nó passivo para o novo hardware. Uma vez lá, você pode ligá-lo e verificar se está funcionando corretamente (tanto quanto possível) e, em seguida, tentar fazer failover para o novo hardware. Embora haja muitas coisas que podem dar errado, como disse Jim B, há uma boa chance de que o failover seja feito corretamente no novo hardware ou não funcione e apenas seja necessário voltar para o hardware antigo. Se funcionar, você poderá repetir o processo no outro nó. Caso contrário, você pode simplesmente ligar novamente o antigo nó passivo (que você não precisaria destruir) e tentar outra coisa.