SQL Server equivalente à funcionalidade do Oracle RAC? [fechadas]

Eu pesquisei no Google e não consegui encontrar uma resposta para essa pergunta mais recente do que alguns anos atrás, então pensei em perguntar. O recurso RAC da Oracle oferece balanceamento de carga para transações de leitura e gravação, além de expansão e alta disponibilidade sem tempo de inatividade (pelo menos, pelo que entendi - estamos prestes a implantar nossos primeiros bancos de dados que usam RAC, portanto, vou ver como vai).

Existe algum conjunto de recursos do SQL Server (ou componente de terceiros que você possa instalar na parte superior) que ofereça funcionalidade equivalente? Sempre usamos o clustering do Windows, onde um evento de failover causa cerca de 20 a 30 segundos de tempo de inatividade do SQL - sempre tolerável, mas não ideal. Agora, com o AlwaysOn no SQL 2012, o SQL Server reduz esse número para cerca de 15 segundos e adiciona o conceito de bancos de dados secundários somente leitura, mas eles ainda exigem que as transações de gravação sejam bloqueadas por um único ponto de conexão (muito aprimorado, pois muitas transações são acabou de ler, mas ainda não é realmente o balanceamento de carga) e, no caso de uma falha do nó ou da necessidade de correção, ainda há tempo de inatividade.

Suponho que seja apenas mais curiosidade - sinto que essa é a única área em que o SQL Server fica atrás do Oracle (pelo menos entre os recursos que pessoalmente vi usados). Eu queria ver se existem opções disponíveis para fechar essa lacuna e possivelmente melhorar nossa própria implantação do SQL Server enquanto aguardamos a adição do recurso equivalente da Microsoft - talvez no SQL 2014/2015?

Não, nada no SQL Server pode fornecer a mesma coisa imediatamente .

Atualmente, a única tecnologia do SQL Server que permite gravações simultâneas em vários nós é a replicação ponto a ponto . Observe que eu não disse "redimensionar gravação", porque funciona de uma maneira que todo o sistema tem a capacidade de gravação de apenas um nó. O parágrafo introdutório dessa página é redigido com cuidado para incluir o termo "dimensionamento horizontal" sem dizer "escrever dimensionamento horizontal". Yay para falar de marketing.

Pelo que li , o Oracle RAC é o mesmo a esse respeito. Funcionalmente, a única coisa que falta no SQL Server nessa configuração é uma solução de balanceamento de carga, que é uma vantagem (você pode implementá-la da maneira que desejar) e uma desvantagem (não está na caixa ou é suportada pela Microsoft) quando comparando com produtos concorrentes.

Por outro lado, a Oracle RAC não lhe dá a mesma coisa que o SQL Server fora da caixa também. Por exemplo, recomenda-se que o RAC seja implementado com nós a 100 km um do outro devido à latência da rede em tempo real, enquanto a replicação ponto a ponto não tem essa restrição. (Não estou dizendo que uma solução seja melhor que a outra: estou apenas apontando que elas são diferentes. A empresa deve escolher uma solução que melhor atenda às suas necessidades específicas.)

Sou DBA suportando SQL 2000-2012, Oracle 11g e Oracle 11g RAC.

Os Grupos de Disponibilidade AlwaysOn da IMO no SQL 2012 aproximam-se muito da disponibilidade e escalabilidade do RAC a um custo muito menor em dólares e em complexidade. Você pode expandir as leituras consultando os espelhos, mas deseja direcionar todo o DML para o servidor principal (os espelhos do SQL Server não podem ser atualizados). Se o SQL Server primário falhar, o failover para um dos espelhos é quase instantâneo. O RAC experimenta uma pausa semelhante se um nó travar, pois as transações não confirmadas no nó com falha são revertidas pelo nó sobrevivente.

A maior vantagem (IMHO) do SQL 2012 AAAG sobre o RAC é que é uma arquitetura de nada compartilhado. O RAC compartilha o armazenamento. Se isso falhar, o cluster inteiro estará inoperante. Esse é um enorme SPOF no RAC que todo mundo parece esquecer. Se você quiser se proteger contra isso, precisará configurar um servidor em espera. Se você deseja que isso seja RAC, o custo fica ainda mais complexo.

A resposta direta à sua pergunta é não, o SQL Server não possui funcionalidade equivalente. Existem aspectos do SQL Server que oferecem o tipo de tolerância a falhas que você deseja (mesmo no SQL Server 2005 ao usar o espelhamento de banco de dados e um aplicativo com reconhecimento de espelho), mas não há um 1: 1 com o Oracle RAC.

Uma comparação melhor do AlwaysOn seria o recurso Data Guard da Oracle. Cluster ativo-passivo. (sim, você pode ler no modo de espera, mas é somente leitura, portanto, apenas um nó está ativo ")

O Oracle RAC é um animal completamente diferente e um cluster ativo-ativo. Não vi nenhum movimento se a Microsoft quiser implementar isso.

O SQL Server 2012/2014 com AlwaysOn adiciona muitos recursos que o aproximam do Oracle RAC - e, em alguns casos, aprimoram-no. (Lembre-se de que, com o RAC, você precisa usar o servidor de aplicativos Oracle, weblogic e JDBC - além de operar em um único datacenter e o aplicativo pode se conectar a apenas um cluster RAC - armazenamento compartilhado significa que o RAC não funciona na nuvem) .

Com o AlwaysOn, você obtém secundários somente leitura (4 em 12, 8 em 14) e suporte a failover automático. No entanto, algumas coisas são desafiadoras - o AlwaysOn não suporta balanceamento de carga - a menos que você escreva um script, ele sempre desenhará o primeiro servidor da lista. O failover também afeta o aplicativo - não é transparente, portanto, talvez seja necessário reiniciar os aplicativos.

Divulgação completa - trabalho para uma empresa que fabrica softwares que aumentam o AlwaysOn. Nosso software de balanceamento de carga de banco de dados front-end do SQL Server - ele faz leitura / gravação dividida em nome do aplicativo, faz balanceamento de carga baseado em tempo de resposta que abrange data centers e enfileira gravações / transações de entrada durante o failover para que os aplicativos não vejam erros . Veja como a Microsoft, Dell, Quicken Loans e outras empresas estão usando o software ScaleArc para aprimorar o SQL Server AlwaysOn e obter recursos semelhantes ao RAC sem alterações no aplicativo.