Estamos buscando configurar un clúster de conmutación por error para nuestra base de datos SQL 2008R2. Para lograr esto, tenemos 2 servidores, ambos equipados con tarjetas Fusion I/O que tendrán copias idénticas de nuestras bases de datos de producción.
Por todo lo que he leído, se supone que debemos configurar los servidores para que ambos extraigan las bases de datos de algún tipo de almacenamiento de archivos compartido. Nuestra intención era que ambos servidores simplemente ejecutaran las bases de datos desde sus respectivas tarjetas Fusion I/O en lugar de desde un archivo compartido.
La agrupación en clústeres parece ser la opción correcta para una configuración SQL de alta disponibilidad, dadas las comprobaciones "LooksAlive" e "isAlive" que realiza, pero si el almacenamiento compartido es un requisito, es posible que debamos considerar una solución alternativa.
Dado que realmente solo necesitamos la funcionalidad de red HeartBeat y no necesitamos ningún almacenamiento compartido, ¿podemos seguir usando un clúster de conmutación por error para SQL?
Respuesta1
Considere obtener SQL 2012 (o superior). Esto le permite tener grupos de disponibilidad. Esto almacena la base de datos en el almacenamiento local y replica los cambios (sincronizados o asíncronos, usted elige) en la otra instancia. Parece que esta es una mejor solución a su problema.
Los grupos de disponibilidad también utilizan MS Clustering para enviar la IP/Listerner de un nodo a otro, pero no requieren almacenamiento compartido. Aún puede utilizar un disco de quórum, pero también funcionará un testigo de recurso compartido de archivos.
Respuesta2
¿Cómo mantendrás los datos sincronizados entre las dos tarjetas FusionIO? Por su naturaleza, la agrupación en clústeres en 2008R2 requiere almacenamiento compartido. Si esta es una configuración admitida por FusionIO, deben proporcionar los pasos para configurarla correctamente.