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

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?

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

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.

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.

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.

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.