SQL Clustering en Hyper V: un clúster dentro de un clúster es un beneficio

Question

Esta es una repetición de unpreguntaPregunté hace un tiempo: después de que un consultor llegó y presentó ideas a otros equipos del departamento, todo el problema volvió a plantearse, por lo que estoy buscando respuestas más detalladas.

Tenemos la intención de configurar un clúster SQL de múltiples instancias en varios blades físicos que ejecutarán una variedad de sistemas diferentes en cada instancia de SQL. En uso general, habrá una instancia virtual de SQL ejecutándose en cada host de VM. Nuevamente, en la operación general, cada host de VM se ejecutará en un blade subyacente dedicado. La configuración debería brindarnos mucha flexibilidad para el mantenimiento de cualquier VM individual o blade subyacente con todas las instancias de SQL capaces de conmutar por error según sea necesario.

Mi plan original había sido hacer lo siguiente:

1. Instale 2008 R2 en cada hoja
2. Agregue Hyper V a cada hoja
3. Instale una máquina virtual 2008 R2 en cada blade
4. Dentro de las máquinas virtuales, cree un clúster de conmutación por error y luego instale el clúster de SQL Server.

El consultor ha sugerido que en su lugar hagamos lo siguiente:

1. Instale 2008 R2 en cada hoja
2. Agregue Hyper V a cada hoja
3. Instale una máquina virtual 2008 R2 en cada blade
4. Cree un clúster en las máquinas HOST que alojará todas las máquinas virtuales.
5. Dentro de las máquinas virtuales, cree un clúster de conmutación por error y luego instale el clúster de SQL Server.

La gran diferencia es la adición del paso 4 mediante el cual también agrupamos todas las máquinas virtuales invitadas. El argumento es que mejora aún más el mantenimiento ya que no tenemos ningún vínculo entre el clúster SQL y el hardware físico. En teoría, podemos migrar en vivo las máquinas virtuales invitadas alrededor de los hosts sin afectar en absoluto el clúster SQL, por lo que, para el mantenimiento de rutina de los blades físicos, movemos el clúster SQL sin interrupción y sin necesidad de realizar una conmutación por error.

Suena como una buena idea, pero no he encontrado nada en Internet donde la gente diga que han hecho esto y que funciona bien. ¿Puedo realmente realizar las migraciones en vivo de los invitados sin que el clúster SQL alojado en ellos se moleste?

¿Alguien tiene alguna experiencia con esta configuración, buena o mala? ¿Hay algunos pros y contras que no he considerado?

Aprecio que la duplicación también sea una opción valiosa a considerar; en este caso, preferimos la agrupación en clústeres, ya que se encargará de la totalidad de cada instancia y tenemos una buena cantidad de bases de datos. Algunas bases de datos son para pesados ​​sistemas de terceros que pueden ni siquiera funcionar bien con la duplicación (y entiendo que la agrupación en clústeres es que las conmutaciones por error son completamente transparentes para los clientes).

Gracias.

Answer 1

Si esos blades estarán completamente dedicados a ejecutar SQL Server únicamente, ¿por qué preocuparse siquiera por la virtualización?

¿Por qué no simplemente instala Windows Server y SQL Server en cada uno de ellos y configura su clúster en consecuencia, sin la sobrecarga adicional de virtualización?

Answer 2

Suena complicado.

Tendría que sopesar la "complejidad" de su solución con la confiabilidad y la relativa simplicidad de una implementación de servidor SQL en clúster físico estándar.

¿TODAS las bases de datos son de misión crítica? En mi experiencia, normalmente no, por lo que tiendo a alojar las bases de datos más importantes en servidores configurados con total resiliencia y el resto (generalmente una gran proporción) en servidores SQL simples.

Esto le permite concentrarse en mantener los sistemas más importantes en funcionamiento y no intentar mantener "todas las bolas en el aire al mismo tiempo".

Todos los servidores necesitarán un mantenimiento de rutina regular. Dada la regularidad, severidad e importancia de los parches de seguridad, hemos pasado de tratar de mantener un tiempo de actividad teórico de 5 nueve (que a los usuarios les gustó, pero que en realidad no NECESITAN) a un intento más realista de "mantendremos los servidores seguros". y seguro, pero HABRÁ períodos cortos de mantenimiento OBLIGATORIO para permitirnos mantener los servidores correctamente parcheados".

Answer 3

De las opciones enumeradas, elegiría la número 2, pero no agruparía SQL (paso 5) porque agrega una capa de complejidad de la que no se gana mucho. La agrupación en clústeres de Hyper-V ya le permitirá ejecutar esa máquina virtual en cualquier host, por lo que estará cubierto ante fallas de hardware.

Supongo que planea utilizar VHD de tamaño fijo para los volúmenes de bases de datos y registros SQL.

Entiendo completamente los comentarios de otros sobre omitir Hyper-V por completo y simplemente usar los 2 blades como un clúster SQL normal; ese sería sin duda el enfoque tradicional. Sin embargo, las ventajas de flexibilidad de virtualizar cargas de trabajo son enormes para el mantenimiento, las actualizaciones y las fallas de hardware. La portabilidad de las máquinas virtuales es muy atractiva.

Sin embargo, tenga en cuenta que el valor de esta solución también depende de su entorno. Si no tiene otros servidores Hyper-V y su personal no tiene mucha experiencia con Hyper-V, virtualizar una de sus cargas de trabajo más críticas puede no ser una buena idea. Sin embargo, si usted es como muchos departamentos de TI y comenzó a virtualizar servidores menos críticos, ha creado algunos hosts y tiene las habilidades y procedimientos para ejecutar Hyper-V de manera confiable, expandir ese enfoque a cargas de trabajo más críticas es completamente razonable. Personalmente, prefiero gestionar la agrupación en clústeres a nivel de host en lugar de a nivel de SQL y creo que veremos que esto se hace cada vez más, aunque todavía no es tan común.

Finalmente, sus preguntas sobre la ejecución de SQL en Hyper-V: sí, la migración en vivo funcionará bien con SQL y no se dará cuenta - Y - la duplicación de bases de datos de SQL es excelente, pero sí, no es compatible universalmente, por lo que no se adapta a todos situación.

Answer 4

Creo que su consultor tiene razón. Tengo la idea exacta como él, que deseo implementar en mi entorno actual. 2 piezas físicas de hardware, cada pieza de hardware que ejecuta Hyper-V con 2 instalaciones W2k8.

1. Instale 2x VM en el primer host físico.
2. Instale SQL en VM1 y Mirror o en clúster con VM2 con configuración de tolerancia a fallas en el nivel de O/S para conmutación por error al entorno replicado.
3. Instale W2k8 en el segundo servidor físico y en el clúster de conmutación por error Hyper-V.

Esto le proporciona un nivel completo de agrupación en caso de error y H/A completo en su entorno SQL.

¿O tal vez mi idea es estúpida?