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

11

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?

SqlRyan
fonte
1
Não tenho certeza se o SQL Server está realmente ficando muito atrás do Oracle. Bem, sim, ele possui um recurso que o SQL Server não possui, mas não deixe de revisar esse segmento depois de executá-lo por alguns meses e deixe-nos saber se é tudo rosas ou não. :-) Também não tenho experiência, mas colegas que nem sempre tiveram coisas boas a dizer sobre isso.
Aaron Bertrand
2
Também espero que você não espere especulações precisas sobre recursos em versões futuras do SQL Server. Aqueles que sabem se existem ou não esses recursos na fase de planejamento não podem lhe dizer; aqueles que também não podem contar. :-)
Aaron Bertrand
1
@AaronBertrand: É justo, eu realmente não espero nenhuma especulação de recurso, pois sei que não seria preciso. Embora o AlwaysOn seja uma melhoria (em alguns casos), eu tinha grandes esperanças de replicar mais de perto a funcionalidade do RAC e fechar essa lacuna. O MSSQL faz várias coisas melhores que a Oracle, na minha opinião, mas essa é uma área em que a Oracle detém o bastão, na minha opinião.
SqlRyan
1
@rwmnau novamente, sugiro que você mantenha seus elogios brilhantes ao RAC até implementá-lo e usá-lo por alguns meses. :-) Você pode estar certo; pode ser tudo o que promete e funciona perfeitamente para você. Mas você pode ser enganado pelo brilho brilhante na caixa. :-)
Aaron Bertrand
2
@AaronBertrand: Ha, ponto levado. Eu já ouvi várias críticas, como essa, que é muito sensível à latência da rede e é rápida para despejar nós, e assim, definitivamente, estou mantendo um julgamento total até depois de lançá-la e usá-la em primeira mão. . O SQL Server, embora tenha várias opções de alta disponibilidade, não parecia estar se movendo para o espaço "vários front end graváveis". Talvez eu estou a ponto de descobrir a razão pela qual :)
SqlRyan

Respostas:

8

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.)

Jon Seigel
fonte
1
A principal razão para os 100 km é que o Oracle permanece compatível com ACID entre nós - eles precisam se comunicar através de uma interconexão de alta velocidade e a velocidade da luz se torna um problema. O SQL Server em uma configuração semelhante propaga alterações e você pode obter conflitos no nível da linha se dois nós atualizarem a mesma linha dentro de um determinado período de tempo - não o ACID - nem um único banco de dados. Um conjunto de instâncias do RAC é um único banco de dados, essa é a distinção.
Philᵀᴹ
@ Phil: Sim, esse foi o meu ponto - eles são diferentes.
21412 Jon Seigel
6

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.

Mandril
fonte
1
Bom ponto sobre o SPOF do RAC.
StanleyJohns
5

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.

Eric Higgins
fonte
1

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.

Tagar
fonte
-2

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.

Michelle
fonte