SQL Server equivalente a la funcionalidad de Oracle RAC? [cerrado]

11

Busqué en Google y no pude encontrar una respuesta a esta pregunta más reciente que hace unos años, así que pensé en preguntar. La función RAC de Oracle ofrece equilibrio de carga para transacciones de lectura y escritura, así como escalamiento horizontal y alta disponibilidad sin tiempo de inactividad (al menos, según tengo entendido, estamos a punto de implementar nuestras primeras bases de datos que usan RAC, por lo que Ya veremos cómo va).

¿Existe algún conjunto de características de SQL Server (o componente de terceros que pueda instalar en la parte superior) que brinde una funcionalidad equivalente? Siempre hemos utilizado la agrupación en clúster de Windows, donde un evento de conmutación por error causa aproximadamente 20-30 segundos de tiempo de inactividad de SQL, siempre tolerable, pero no ideal. Ahora, con AlwaysOn en SQL 2012, SQL Server lo reduce a unos 15 segundos y agrega el concepto de bases de datos secundarias de solo lectura, pero aún así requieren que las transacciones de escritura se bloqueen a través de un único punto de conexión (muy mejorado, ya que muchas transacciones son solo lea, pero aún no realmente equilibra la carga), y en el caso de una falla del nodo o la necesidad de parchear, todavía hay tiempo de inactividad.

Supongo que es solo más curiosidad: siento que esta es la única área en la que SQL Server se queda atrás de Oracle (al menos entre las características que he visto personalmente). Quería ver si hay alguna opción para cerrar esa brecha y posiblemente mejorar nuestra propia implementación de SQL Server mientras esperamos que se agregue la característica equivalente de Microsoft, ¿tal vez en SQL 2014/2015?

sql-server feature-comparison high-availability rac oracle-rac SqlRyan
fuente
1
No estoy seguro de que SQL Server se esté quedando tan atrás de Oracle. Bueno, sí, tiene una característica que SQL Server no tiene, pero asegúrese de volver a visitar este hilo después de haberlo estado ejecutando durante unos meses y háganos saber si todo es rosas o no. :-) Yo tampoco tengo experiencia con eso, pero los colegas que no siempre han tenido cosas buenas que decir al respecto.
Aaron Bertrand
2
También espero que no espere ninguna especulación precisa sobre las características en futuras versiones de SQL Server. Aquellos que saben si hay o no tales características en la fase de planificación no pueden decirle; aquellos que no pueden decírtelo tampoco. :-)
Aaron Bertrand
1
@AaronBertrand: Bastante justo, realmente no espero ninguna especulación de características, ya que me doy cuenta de que no sería precisa en absoluto. Si bien AlwaysOn es una mejora (en algunos casos), tenía mayores esperanzas de que replicaría más estrechamente la funcionalidad de RAC y cerrara esa brecha. MSSQL hace una serie de cosas mejor que Oracle, en mi opinión, pero esta es un área donde Oracle tiene el testigo, en mi opinión.
SqlRyan
1
@rwmnau nuevamente, le sugiero que mantenga su brillante elogio de RAC hasta que lo haya implementado y lo haya usado durante unos meses. :-) Puede que tengas razón; Puede ser todo lo que promete y funciona perfectamente para usted. Pero puede ser engañado por el brillo brillante en la caja. :-)
Aaron Bertrand
2
@AaronBertrand: Ja, punto tomado. He escuchado una serie de críticas, como que es demasiado sensible sobre la latencia de la red y es rápido para desalojar nodos y demás, por lo que definitivamente tengo un juicio total hasta después de que lo hayamos implementado y lo haya usado de primera mano. . SQL Server, si bien tiene varias opciones de alta disponibilidad, no parece que se esté moviendo al espacio de "front end de escritura múltiple". Tal vez estoy a punto de descubrir la razón por la cual :)
SqlRyan

Respuestas:

8

No, nada en SQL Server puede darle lo mismo de fábrica .

Actualmente, la única tecnología de SQL Server que permite escrituras simultáneas en múltiples nodos es la replicación punto a punto . Tenga en cuenta que no dije "escalar horizontalmente de escritura", porque funciona de tal manera que todo el sistema tiene la capacidad de escritura de un solo nodo. El párrafo introductorio de esa página está redactado cuidadosamente para incluir el término "escalar" sin decir "escribir escalar". Yay para hablar de marketing.

Por lo que he leído , Oracle RAC es el mismo en ese sentido. Funcionalmente, lo único que falta en SQL Server en esta configuración es una solución de equilibrio de carga, que es tanto una ventaja (puede implementarla como desee) como una desventaja (no está en la caja o no es compatible con Microsoft) cuando comparando con productos de la competencia.

Por el contrario, Oracle RAC no le da lo mismo que SQL Server fuera de la caja tampoco. Por ejemplo, se recomienda implementar RAC con nodos dentro de los 100 km entre sí debido a la latencia de la red en tiempo real, mientras que la replicación punto a punto no tiene esa restricción. (No digo que una solución sea mejor que la otra: solo estoy señalando que son diferentes. La empresa debe elegir la solución que mejor se adapte a sus necesidades específicas).

Jon Seigel
fuente
1
La razón principal de los 100 km es porque Oracle sigue siendo compatible con ACID en todos los nodos: necesitan comunicarse entre sí a través de una interconexión de alta velocidad y la velocidad de la luz se convierte en un problema. SQL Server en una configuración similar propaga cambios y puede obtener conflictos a nivel de fila si dos nodos actualizan la misma fila dentro de un cierto período de tiempo, no ACID, ni una sola base de datos. Un conjunto de instancias RAC son una única base de datos, esa es la distinción.
Philᵀᴹ
@ Phil: Sí, ese era mi punto, son diferentes.
Jon Seigel
6

Soy un DBA que admite SQL 2000-2012, Oracle 11g y Oracle 11g RAC.

En mi opinión, los grupos de disponibilidad Always On en SQL 2012 se acercan mucho a la disponibilidad y escalabilidad de RAC a un costo mucho menor en dólares y complejidad. Puede escalar las lecturas consultando los espejos, pero desea dirigir todos los DML al servidor primario (los espejos de SQL Server no se pueden actualizar). Si el SQL Server primario falla, la conmutación por error a uno de los espejos es casi instantánea. RAC experimenta una pausa similar si un nodo falla cuando las transacciones no confirmadas en el nodo fallido son revertidas por el nodo superviviente.

La mayor ventaja (en mi humilde opinión) de SQL 2012 AAAG sobre RAC es que es una arquitectura de nada compartido. RAC comparte el almacenamiento. Si eso falla, todo el clúster está inactivo. Esa es una gran SPOF en RAC que todos parecen olvidar. Si desea protegerse contra eso, debe configurar un servidor en espera. Si desea que sea RAC, el costo se agrava aún más.

Arrojar
fuente
1
Buen punto sobre el SPOF de RAC.
StanleyJohns
5

La respuesta directa a su pregunta es no, SQL Server no tiene una funcionalidad equivalente. Hay aspectos de SQL Server que le brindan el tipo de tolerancia a fallas que desea (incluso desde SQL Server 2005 cuando usa la duplicación de DB y una aplicación compatible con duplicación), pero no hay un 1: 1 con Oracle RAC.

Eric Higgins
fuente
1

Una mejor comparación de AlwaysOn sería la función Data Guard de Oracle. Agrupación activa-pasiva. (sí, puede leer desde el modo de espera, pero es de solo lectura, por lo que solo un nodo está activo ")

Oracle RAC es un animal completamente diferente, y agrupación activo-activo. No vi ningún movimiento si Microsoft alguna vez querrá implementar eso.

Tagar
fuente
-2

SQL Server 2012/2014 con AlwaysOn agrega muchas capacidades que lo acercan a Oracle RAC y, en algunos casos, lo mejoran. (Recuerde que con RAC, debe usar el servidor de aplicaciones Oracle, weblogic y JDBC, además de operar en un solo centro de datos y la aplicación puede conectarse a un solo clúster RAC; el almacenamiento compartido significa que RAC no funciona en la nube) .

Con AlwaysOn obtienes secundarios de solo lectura (4 en 12, 8 en 14) y soporte de conmutación por error automática. Sin embargo, algunas cosas son desafiantes: AlwaysOn no admite el equilibrio de carga; a menos que escriba un script, siempre dibujará el primer servidor de la lista. La conmutación por error también afecta la aplicación: no es transparente, por lo que es posible que las aplicaciones tengan que reiniciarse.

Divulgación completa: trabajo para una empresa que fabrica software que aumenta AlwaysOn. Nuestro software de equilibrio de carga de bases de datos SQL Server: realiza una división de lectura / escritura en nombre de la aplicación, hace un equilibrio de carga basado en el tiempo de respuesta que abarca centros de datos y pone en cola las escrituras / transacciones entrantes durante la conmutación por error para que las aplicaciones no vean errores . Vea cómo Microsoft, Dell, Quicken Loans y otras empresas están utilizando el software ScaleArc para aumentar SQL Server AlwaysOn y obtener capacidades similares a RAC sin cambios en la aplicación.

Michelle
fuente