Atualize o hardware do SQLServer 2008

Question

Perdoe-me se não puder ser totalmente claro aqui. Não é intencional, sou desenvolvedor de nível sênior em uma empresa muito pequena tendo que atuar como gerente no momento.

De qualquer forma, a história é que temos dois servidores dell mais antigos com o SQL Server 2008 Standard em um "cluster". Eu coloquei isso entre aspas porque eu ainda não estou 100% claro o que isso significa. Temos 2 novos servidores blade e queremos mover 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. Estou me dizendo que podemos expulsar o nó passivo e, em seguida, puxar um dos novos servidores. Mas também estou sendo informado de que esse é um passo perigoso porque algo poderia dar errado, o que faria com que o cluster falhasse e, em seguida, ficaríamos sem nada porque o servidor ativo não seria capaz de voltar.

Alguém tem alguma opinião sobre como lidar com isso? Estou sendo informado de que a única maneira de garantir o sucesso é ter pelo menos um dia de tempo ocioso, quando exibimos um novo cluster no novo hardware e depois migram os bancos de dados 1 por 1.

[Editar] Como ainda está relacionado a essa questão, gostaria de acrescentar outra pergunta. É possível removermos uma máquina do cluster? Em seguida, crie um novo cluster com o nó removido como a máquina ativa e, em seguida, traga um novo servidor para ele? Preservando efetivamente o antigo cluster enquanto as novas máquinas são inseridas e retiradas caso algo dê errado?

    

Answer 1

little or no down time

Embora seja de pouca ajuda agora, você deve estar executando a empresa, pois precisa 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 teria adicionado mais 2 nós e, em seguida, removido os que você não queria mais. Eu consideraria atualizar a versão enquanto você está atualizando o hardware

... But I'm also being told that this is a dangerous step because something could go wrong that would cause the cluster to fail and then we would be left with nothing because the active server would not be able to come back up.

Tudo é possível. Embora eu nunca tenha visto um cluster de failover de 208 sql 2008 de servidor simplesmente cair morto, é teoricamente possível. Observe que o nó ativo não está "inativo" durante a atualização do nó, portanto, não há nada para ser desativado. O cluster está executando simplesmente em 1 nó sem possibilidade de failover. O pior cenário possível é que o nó antigo está de alguma forma morto e a substituição não será adicionada, caso em que você estaria executando sem o recurso de failover até que o problema que está causando a não inclusão do servidor seja resolvido.

I'm being told that the only way to ensure success is to have at least a day of down time where we bring up a new cluster on the new hardware and then migrate the databases 1 by 1.

Essa é provavelmente a única maneira de garantir o sucesso do cara que está fazendo o trabalho. Eu faria a pergunta inocente de "se é preciso um dia de tempo de inatividade para mover um cluster, por que eu iria me agrupar em primeiro lugar? Eu poderia comprar 2 máquinas e deixar 1 e pronto para ir para esse tipo de disponibilidade". Em resumo, você precisa encontrar alguém que realmente trabalhe com clusters antes e entenda a tecnologia envolvida. Presumindo que não existam problemas únicos (por exemplo, a sua empresa escreveu algum software em cluster quase que em execução no cluster) eu acho que a maioria dos administradores profissionais da Microsoft ficaria constrangida em dizer que levaria um dia de inatividade para substituir / adicionar hardware a um cluster existente em funcionamento

    

Answer 2

Em primeiro lugar, a estratégia recomendada no final da sua pergunta é a maneira que eu recomendaria fazê-lo também, mas vendo que isso não é uma opção, é assim que eu lidaria com isso. Você parece confuso sobre um cluster, basicamente ambos os servidores têm SQL instalado e serviços de cluster, com um comando através de serviços de cluster você pode "rolar" SQL de um servidor para outro. Se eu estivesse no seu lugar, faria como você sugeriu, role todos os serviços para um nó, remova o segundo nó do cluster, adicione um de seus novos servidores como um nó de cluster, role todos os serviços para o novo nó do cluster, adicione o segundo novo nó, remova o segundo nó antigo do cluster.

** Por favor, note que, se você não estiver familiarizado com serviços de cluster e / ou instalações SQL em cluster e você tentar isso em seu sistema ao vivo, isso pode acabar muito, muito mal para você. Como em muito pior do que o dia de um tempo de inatividade planejado. Eu contrataria um consultor com experiência em clusters ou, se essa não fosse uma opção para configurar um ambiente de teste, ele poderia testar o processo por dentro e por fora.

Hereis a link to the steps for adding a node to your cluster.

    

Answer 3

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
• Isntall SQL no novo cluster, mantenha as letras, os caminhos, a porta e o nome da instância (se aplicável) da mesma
• Após a instalação, restaure / substitua os bancos de dados master e msdb do antigo servidor SQL pelo novo para obter os logins e os jobs, ou então faça o script dos jobs no antigo e use sp_help_revlogins
• Registrar ou espelhar o banco de dados do servidor antigo para o novo para atualizar os dados

Isso fará com que sua nova instância esteja 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 instância antiga é INSTA e o novo é INSTB:

• Coloque a antiga instância do SQL offline
• Recupere os bancos de dados no novo servidor
• Exclua o registro DNS do INSTA do DNS do Active Directory
• Criar um novo registro DNS CNAME (alias) no DNS do Active Directory que aponta para INSTB

Quando isso for feito, os aplicativos devem estar conectando o nome antigo da instância do SQL, mas isso os levará ao novo servidor. Pode ser necessário executar "ipconfig / flushdns" em todos os servidores de aplicativos para tornar a alteração do DNS mais rápida, certifique-se de fazer ping no nome antigo para ver quando ele aponta de volta. Usamos esse método para a transição porque nos permite manter o antigo cluster em volta caso precisemos retroceder. Você não poderá atualizar a antiga instância do SQL até alterar o parâmetro de nome de rede do SQL Server para outra coisa, mas, uma vez feito isso, basta apontar o alias do DNS de volta para o antigo, se desejar reverter. / p>     

Answer 4

Sem saber as especificidades do hardware para saber se isso funcionaria, minha sugestão seria a imagem do antigo nó passivo para o novo servidor. Usando algo como o Acronis que permitiria que a imagem fosse colocada em um novo hardware, você deveria basicamente mover o nó passivo para o novo hardware. Uma vez lá, você pode ligá-lo e verificar se está funcionando corretamente (o máximo que puder) e, em seguida, tentar fazer failover para o novo hardware. Embora existam muitas coisas que poderiam dar errado, como Jim B disse, há uma boa chance de que ele seja submetido a um failover adequado para o novo hardware ou não funcione e apenas tenha que voltar ao hardware antigo. Se funcionar, você poderá repetir o processo no outro nó. Se isso não acontecer, você pode ligar novamente o antigo nó passivo (que você não teria que destruir) e tentar outra coisa.