none
Migração cluster SQL Server 2008 Standard x64 para SQL Server 2008 R2 Enterprise RRS feed

  • Pergunta

  • Tenho um cluster SQL Server 2008 Standard x64 de dois nós rodando em Windows Server 2008 x64 SP2.

    O objetivo é atualizar o SQL Server dos nós do cluster, de SQL Server 2008 Standard para SQL 2008 R2 Enterprise.

    É possível executar essa mudança sem ter de migrar os dados do ambiente clusterizado para stand alone ?

    Quais os procedimentos recomendados para a execução dessa mudança ?


    Everson Santos Amancio MCITP Server Administrator Windows Server 2008 MCTS Windows Server 2008
    sexta-feira, 13 de janeiro de 2012 01:05

Respostas

  • Bom Dia,

    Nenhuma estratégia requer que você migre os dados para um servidor StandAlone. É possível de utilizá-lo, mas é apenas um passo a mais (que pode ser desnecessário na minha opinião). Para migrar você terá basicamente duas estratégias:

    Atualização InPlace: Nessa opção, você utiliza a mídia do SQL Server 2008 R2 Enterprise e simplesmente instala por cima do Standart atualizando-o. Isso fará com que ao final você tenha exatamente os mesmos IPs, nome virtuais, discos, etc. É sem dúvida a estratégia mais rápida e direta, mas se algo der errado... Aí você está com um grande problema, pois, terá que reinstalar o SQL Server novamente. Se for optar por essa estratégia, tire os backups de todos os bancos de dados (inclusive MASTER), para que um eventual retorno seja menos traumático possível.

    Atualização Side by Side: Nessa opção, você montaria um cluster SQL Server 2008 R2 Enterprise a parte e iria migrando os dados do Cluster Standard para o Enterprise. Não é necessário novo hardware, pois, você poderia montar a instância Enterprise no mesmo cluster da Standard, mas seria uma instância a parte e após a migração seria necessário reapontar as aplicações para a nova instância. É mais trabalhoso, porém mais seguro.

    Qual é a melhor ? Aí depende de novo, pois, itens como SLA, complexidade das aplicações, fatores políticos, etc irão sensibilizar sua escolha. Eu diria que se você tiver uma janela muito grande (tipo um fim de semana inteiro), eu optaria pelo InPlace. Se der problema, você terá muito tempo para resolver e tentar novamente ou ir para o Side by Side

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Everson Amancio sexta-feira, 13 de janeiro de 2012 15:43
    sexta-feira, 13 de janeiro de 2012 12:06

Todas as Respostas

  • Bom Dia,

    Nenhuma estratégia requer que você migre os dados para um servidor StandAlone. É possível de utilizá-lo, mas é apenas um passo a mais (que pode ser desnecessário na minha opinião). Para migrar você terá basicamente duas estratégias:

    Atualização InPlace: Nessa opção, você utiliza a mídia do SQL Server 2008 R2 Enterprise e simplesmente instala por cima do Standart atualizando-o. Isso fará com que ao final você tenha exatamente os mesmos IPs, nome virtuais, discos, etc. É sem dúvida a estratégia mais rápida e direta, mas se algo der errado... Aí você está com um grande problema, pois, terá que reinstalar o SQL Server novamente. Se for optar por essa estratégia, tire os backups de todos os bancos de dados (inclusive MASTER), para que um eventual retorno seja menos traumático possível.

    Atualização Side by Side: Nessa opção, você montaria um cluster SQL Server 2008 R2 Enterprise a parte e iria migrando os dados do Cluster Standard para o Enterprise. Não é necessário novo hardware, pois, você poderia montar a instância Enterprise no mesmo cluster da Standard, mas seria uma instância a parte e após a migração seria necessário reapontar as aplicações para a nova instância. É mais trabalhoso, porém mais seguro.

    Qual é a melhor ? Aí depende de novo, pois, itens como SLA, complexidade das aplicações, fatores políticos, etc irão sensibilizar sua escolha. Eu diria que se você tiver uma janela muito grande (tipo um fim de semana inteiro), eu optaria pelo InPlace. Se der problema, você terá muito tempo para resolver e tentar novamente ou ir para o Side by Side

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Everson Amancio sexta-feira, 13 de janeiro de 2012 15:43
    sexta-feira, 13 de janeiro de 2012 12:06
  • Everson,

    Se você quiser economizar no rede utilize a Atualização InPlace, agora se você quer começar um novo ambiente, limpo, partindo do zero mas sabendo que vai demandar tempo, a escolha é a Side by Side.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    domingo, 15 de janeiro de 2012 10:30
    Moderador
  • Gustavo e Junior, como vocês fazer com os logins, jobs, linked servers?

    Geram os scripts e executam-o no outro ambiente? Quanto aos logins, não tem perigo deles ficarem órfãos?

    quinta-feira, 9 de fevereiro de 2012 22:20
  • Bom dia Leonardo;

    Para os logins, você pode usar o SQL Server Business Intelligence. Uma das tasks que existem lá é Transfer Logins, funciona muito bem e vc pode optar por copiar também os SID's (eliminando assim a necessidade de correção de usuários nos bancos).

    Atente para uma possível necessidade de ter em mãos as senhas dos usuários SQL.

    Eu fiz em um servidor Standalone um upgrade de feactures (inplace) a 3 semanas sem nenhum tipo de problema. Como disse o Gustavo, faça backup de tudo antes, inclusivo os bancos de sistema (master, msdb e se tiver customizações faça do model também). Neste caso não é necessário se preocupar com logins, linked servers, jobs, etc.

    Uma alteranativa interessante, se sentir-se desconfortável com o In-Place é fazer o Side-by-Side com Mirror, veja:

    1-Monte a mesma estrutura idêntica ao que tem hoje (Cluster SQL com versão STANDARD). Muito importante ser Standard o novo servidor/cluster.

    2-Configure um Mirroring sincrono do servidor antigo para o novo

    3-SOMENTE após todos os databases estarem configurados em Mirror, faça um upgrade de versão no servidor sercundário (não pare o mirror, simplesmente coloque o cd do SQL e faça o upgrade para Enterprise).

    4-Certifique-se da funcionalidade do Cluster após o Updgrade e se tudo estiver ok, vá o principal, garanta que ninguém o acesse (desabilite os logins e dê um deny nas conexões), derrube todos os usuários (eu opter por dar um restart na estância) "Leve em consideração o failover do seu Cluster".

    5-Ainda no principal, desmonte todos os Mirrors.

    6-Dê um Shutdown no principal.

    7-Vá ao secundário e coloque as bases de dados como Online (RESTORE DATABASE XXXXX WITH RECOVERY).

    Se vocês usarem Alias para a aplicação, este método é bem rápido, mas sua preparação é bem mais complexa (principalmente levando-se em consideração o Cluster.), mas é sem dúvida um método muito seguro, pois, os dados no servidor (STD) estarão intáctos e o plano de rollback é basicamente ligar os servidores novamente.

    **Depois de fazer o upgrade de feacture no secundário, você não conseguirá criar novos mirrors a partir de um principal com versão Standard.


    View Ricardo Muramatsu's profile on LinkedIn

    quarta-feira, 22 de fevereiro de 2012 11:41
  • Ricardo,

    muito boa sua resposta, obrigado pelas informações. A task de transferir é show de bola, o único problema que tive foi alguns logins SQL não funcionarem (foi onde vc disse pra se atentar e ter as senhas sql em mãos).

    sexta-feira, 24 de fevereiro de 2012 21:56
  • Que isso, se der poste os resultados de sua migração quando terminar.

    Abs.


    View Ricardo Muramatsu's profile on LinkedIn

    quinta-feira, 1 de março de 2012 14:31