No es ningún secreto que conozco bastante bien la solución de agrupación de bases de datos de Oracle. Recientemente, completé una solución de alta disponibilidad de agrupación en clústeres de SQL Server que tomó dos años desde el diseño inicial hasta la implementación final. Ese proceso involucró la documentación de los requisitos, la determinación de las opciones, la asignación de los requisitos a los detalles de implementación, el presupuesto, la adquisición, la instalación, la configuración y las pruebas.
Ahora que mi proyecto está completo, pensé en dar algunos elementos sobre la agrupación en clústeres de SQL Server desde la perspectiva de un tipo de Oracle RAC. Todos sabemos que SQL Server y Oracle son motores RDBMS y pueden tener algunas cosas en común. Pero también son criaturas completamente diferentes. Entonces, si se siente cómodo con la Infraestructura Grid de Oracle, RAC y Data Guard, y está buscando implementar una solución SQL Server HA, tal vez esto le brinde buena información.
Nuestro sistema de producción actual es una base de datos primaria Oracle RAC de 4 nodos. Esto proporciona alta disponibilidad (y alto rendimiento) dentro de nuestro centro de datos principal. Usamos Data Guard para transportar redo a una base de datos física en espera de RAC de 3 nodos. Aunque SQL Server <> Oracle, quería mantener nuestra configuración lo más similar posible para facilitar la administración. Por lo tanto, implementamos un clúster de conmutación por error de SQL Server de 2 nodos en nuestro sitio principal y una base de datos "en espera" de 1 nodo en nuestro sitio DR.
Ahora pasemos a mis observaciones, sin ningún orden en particular.
- La solución de agrupación en clústeres de alta disponibilidad de SQL Server es activa/pasiva. Oracle es Activo/Activo, que para mí es "mejor", y sí... ese es un término subjetivo. Para nuestra implementación Activa/Pasiva, no me gustó la idea de dos servidores físicos sentados allí con uno esencialmente inactivo todo el tiempo. Así que tenemos un servidor físico que es el nodo "preferido" y un servidor virtual. Si el servidor físico falla, el agrupamiento automáticamente conmutará por error la instancia de SQL Server al servidor virtual y estamos operativos nuevamente. Este clúster activo/pasivo no aborda la escalabilidad como lo hace Oracle RAC, pero me brinda una mayor disponibilidad en nuestro entorno principal.
- Implementar la agrupación en clústeres es muy fácil. Active la agrupación en clústeres a nivel del sistema operativo. Debido a que esta es una pila completamente de Microsoft, incorporaron la agrupación en clústeres en el sistema operativo. Ya está ahí para ti. Solo necesitas encenderlo. Luego inicie Herramientas administrativas -> Administrador de clústeres de conmutación por error y los asistentes lo guiarán a través de la configuración. Es mucho más fácil que instalar Grid Infrastructure. Pero Oracle tiene que lidiar con diferentes plataformas de sistemas operativos, lo que lo hace más difícil allí. Será interesante ver cómo SQL Server 2016 en Linux maneja los clústeres de conmutación por error.
- Oracle utiliza un modelo de disco compartido, mientras que SQL Server no comparte nada. Pero debe usar el "disco compartido" de alguna manera porque el disco debe estar disponible en ambos nodos. Sin embargo, MS Failover Clustering (MSFC) monta el disco en clúster en el nodo activo. Cuando SQL Server se mueve al otro nodo, ya sea de forma automática o manual, MSFC desmontará el disco en un nodo y luego lo montará en el otro. Es un poco extraño tener una ventana del Explorador de Windows abierta y ver que el disco aparece o desaparece durante esta transición.
- Grid Infrastructure utiliza el disco de votación para las operaciones de quórum. En MSFC, puede tener un disco de quórum, usar un recurso compartido de archivos o configurar sin quórum. Si opta por lo último, obstaculizará su capacidad de conmutación por error automática.
- Estoy acostumbrado a que mi principal tenga su propio clúster y el standby su propio clúster. Con SQL Server, los nodos principales y los nodos en espera deben formar parte del mismo clúster. Afortunadamente, el clúster puede cruzar subredes que es diferente a Oracle GI. Agregar el nodo en espera fue muy fácil, simplemente eliminamos sus derechos de voto y no configuramos el disco de quórum para el nodo en espera. Esto estuvo bien para nosotros, ya que queremos que la conmutación por error al modo de espera sea una operación manual.
- Para una base de datos en espera, puede usar la creación de reflejo de la base de datos, el trasvase de registros o los grupos de disponibilidad (AG) AlwaysOn. Los dos primeros están a punto de salir, así que fui con los AG. Los AG requieren que el nodo en espera forme parte del mismo clúster que el principal. Hay un asistente que lo guiará a través de la configuración de las bases de datos para participar en el AG. Esto es mucho más fácil que configurar una reserva física de Oracle.
- Para aquellos de ustedes que odian la documentación de Oracle, es hora de estar agradecidos. Muchas veces durante este proceso descubrí que faltaban piezas muy grandes en la documentación de MS. Por ejemplo, nunca descubrí cómo configurar mi nodo en espera para que no tenga derechos de voto. Por suerte, pudimos hacer clic en nuestro camino a través de él.
Cuando todo estuvo dicho y hecho, implementar la solución SQL Server no fue tan difícil. A veces tuve que confiar en mi conocimiento de la agrupación. Otras veces, la terminología de Microsoft se interpuso en el camino. Por ejemplo, el resto del mundo lo llama "cerebro dividido", pero MS lo llama "clúster dividido". A veces, superar las diferencias de léxico era el mayor obstáculo.
