Não é segredo que eu conheço muito bem a solução de cluster de banco de dados da Oracle. Recentemente, concluí uma solução de alta disponibilidade de cluster do SQL Server que levou dois anos desde o design inicial até a implementação final. Esse processo envolveu documentar os requisitos, determinar as opções, mapear os requisitos para detalhes de implementação, orçamento, aquisição, instalação, configuração e teste.

Agora que meu projeto está completo, pensei em dar alguns itens sobre o clustering do SQL Server da perspectiva de um cara do Oracle RAC. Todos sabemos que o SQL Server e o Oracle são mecanismos RDBMS e podem ter algumas coisas em comum. Mas eles também são criaturas completamente diferentes também. Portanto, se você estiver familiarizado com o Grid Infrastructure e RAC e Data Guard da Oracle e estiver pensando em implementar uma solução SQL Server HA, talvez isso forneça algumas boas informações para você.

Nosso sistema de produção atual é um banco de dados primário Oracle RAC de 4 nós. Isso fornece alta disponibilidade (e alto desempenho) em nosso data center principal. Usamos o Data Guard para transportar refazer para um banco de dados de espera física RAC de 3 nós. Mesmo sendo SQL Server <> Oracle, eu queria manter nossa configuração o mais semelhante possível para facilitar a administração. Assim, implantamos um cluster de failover do SQL Server de 2 nós em nosso site primário e um banco de dados “standby” de 1 nó em nosso site de DR.

Agora vamos às minhas observações, sem nenhuma ordem específica.

• A solução de cluster de alta disponibilidade do SQL Server é ativa/passiva. O da Oracle é Ativo/Ativo, o que para mim é “melhor”, e sim… esse é um termo subjetivo. Para nossa implementação ativa/passiva, não gostei da ideia de dois servidores físicos sentados com um essencialmente ocioso o tempo todo. Portanto, temos um servidor físico que é o nó 'preferido' e um servidor virtual. Se o servidor físico falhar, o clustering fará o failover automaticamente da instância do SQL Server para o servidor virtual e estaremos operacionais novamente. Esse cluster ativo/passivo não trata da escalabilidade como o Oracle RAC, mas me dá maior disponibilidade em nosso ambiente primário.
• Implementar o clustering é super fácil. Ative o clustering no nível do SO. Como essa é uma pilha totalmente da Microsoft, eles criaram clustering no sistema operacional. Já está lá para você. Você só precisa ativá-lo. Em seguida, inicie as Ferramentas Administrativas -> Gerenciador de Cluster de Failover e os assistentes o orientam na configuração. É muito mais fácil do que instalar Grid Infrastructure. Mas a Oracle tem que lidar com diferentes plataformas de sistema operacional, o que torna as coisas mais difíceis. Será interessante ver como o SQL Server 2016 no Linux lida com o cluster de failover.
• O Oracle usa um modelo de Disco Compartilhado, enquanto o SQL Server é Nada Compartilhado. Mas você precisa usar o “disco compartilhado” de uma maneira porque o disco precisa estar disponível em ambos os nós. No entanto, o MSFC (Microsoft Failover Clustering) monta o disco clusterizado no nó ativo. Quando o SQL Server é movido para o outro nó, automática ou manualmente, o MSFC desmontará o disco em um nó e o montará no outro. É meio estranho ter uma janela do Windows Explorer aberta e ver o disco aparecer ou desaparecer durante essa transição.
• Grid Infrastructure usa o Voting Disk para operações de quorum. No MSFC, você pode ter um disco de quorum, usar um compartilhamento de arquivos ou configurar sem quorum. Se você optar pelo último, prejudicará seu recurso de failover automático.
• Estou acostumado a que meu primário tenha seu próprio cluster e o standby seu próprio cluster. Com o SQL Server, os nós primários e os nós de espera precisam fazer parte do mesmo cluster. Felizmente, o cluster pode cruzar sub-redes, o que é diferente do Oracle GI. Adicionar o nó em espera foi super fácil, apenas removemos seus direitos de voto e não configuramos o disco de quorum para o nó em espera. Isso foi bom para nós, pois queremos que o failover para o modo de espera seja uma operação manual.
• Para um banco de dados em espera, você pode usar espelhamento de banco de dados, envio de log ou grupos de disponibilidade AlwaysOn (AGs). Os dois primeiros estão saindo, então eu fui com os AGs. Os AGs exigem que o nó em espera faça parte do mesmo cluster que o primário. Há um assistente para orientá-lo na configuração dos bancos de dados para participar do AG. Isso é muito mais fácil do que configurar uma espera física do Oracle.
• Para aqueles que odeiam a documentação da Oracle, é hora de agradecer. Muitas vezes durante este processo eu encontrei a documentação do MS faltando pedaços muito grandes. Por exemplo, nunca descobri como configurar meu nó de espera para não ter direitos de voto. Felizmente, conseguimos clicar no caminho.

Quando tudo foi dito e feito, implementar a solução SQL Server não foi tão difícil. Às vezes eu tinha que confiar no meu conhecimento de clustering. Outras vezes, a terminologia da Microsoft atrapalhava. Por exemplo, o resto do mundo o chama de “cérebro dividido”, mas a MS o chama de “grupo dividido”. Às vezes, superar as diferenças do léxico era o maior obstáculo.