Estoy considerando usar una configuración RAID0 para uno de nuestros clústeres de SQL Server. Esbozaré la situación y buscaré por qué puede ser una mala idea. Además, si alguien tiene casos de uso, documentos técnicos u otra documentación que pueda señalarme sobre este tema, sería genial.
Tenemos 3 servidores en 2 centros de datos que forman parte de un clúster de SQL. Todos ejecutan SQL Server en un grupo de disponibilidad. El primario tiene una réplica sentada justo al lado y otra en el otro centro de datos. Están ejecutando la replicación síncrona con conmutación por error automática. Todas las unidades son SSD de clase empresarial. Ejecutarán SQL Server 2017 o 2019.
Estoy pensando que habría múltiples beneficios al ejecutarlos en matrices RAID0 sobre otros métodos con pocos inconvenientes, si es que hay alguno. Lo único negativo que estoy viendo actualmente es la falta de redundancia en el servidor primario, por lo que la falla aumenta. Como profesionales:
Si una unidad falla, en lugar de funcionar en un estado lento y degradado hasta que alguien recibe un aviso y actúa manualmente en ella, el servidor fallará inmediatamente a un secundario que mantiene la capacidad operativa completa. Esto tendrá un beneficio adicional de notificarnos de una conmutación por error, para que podamos investigar la causa antes.
Reduce la posibilidad de falla general por capacidad de TB. Como no necesitamos unidades de paridad o espejo, reducimos el número de unidades por matriz. Con menos unidades hay menos posibilidades de una falla en la unidad.
Es más barato. Necesitar menos unidades para nuestra capacidad requerida obviamente cuesta menos.
Sé que este no es el pensamiento comercial convencional, pero ¿hay algo que no esté considerando? Me encantaría cualquier entrada, ya sea a favor o en contra.
No estoy tratando de hacer esto para aumentar el rendimiento de las consultas, aunque si hay otras significativas, no dude en señalarlas. Mi principal preocupación es no considerar o abordar un problema de confiabilidad o redundancia en el que no he pensado.
El sistema operativo está en una unidad duplicada separada, por lo que el servidor en sí debería mantenerse activo. Una de esas unidades se puede reemplazar y volver a duplicar. Es pequeño y no hay ningún archivo de base de datos que no sean los DB del sistema. No puedo imaginar que me lleve más de unos minutos. Si falla una de las matrices de datos, reemplazamos la unidad, reconstruimos la matriz, restauramos y volvemos a sincronizar con el AG. En mi experiencia personal, la restauración ha sido MUCHO más rápida que la reconstrucción de una unidad RAID5. Nunca he tenido una falla RAID1, así que no sé si esa reconstrucción sería más rápida o no. Las restauraciones vendrían de una copia de seguridad y avanzarían para coincidir con el primario, por lo que el aumento de carga en el servidor primario debería ser muy mínimo, solo sincronizando los últimos minutos de registros con la réplica recuperada.
fuente
Respuestas:
Hay un aspecto muy importante que creo que falta en su evaluación:
¿Cómo planeas recuperarte?
Cuando raid5 pierde una unidad, se ejecutará en un estado degradado hasta que se recupere automáticamente. (Al menos si tienes un repuesto caliente a mano).
Cuando un raid0 pierde una unidad, nunca puede recuperarse en absoluto. Esto significa que ha perdido la redundancia, y para recuperarla, necesita reconstruir su raid0 y copiar todos los datos (no solo los datos en el disco roto) desde el secundario que ahora está bajo carga de producción. Es decir, en lugar de la única matriz raid5 degradada, ahora es toda su configuración de producción la que obtiene el impacto en el rendimiento.
Si la penalización de rendimiento de estado degradado raid5 (o raid6) no es algo con lo que pueda lidiar, probablemente debería hacer la incursión 1 + 0 en su lugar . Sí, cuesta más, pero siendo los precios de los discos lo que son, va a ser dinero bien gastado.
¿Quizás "monitorear activamente el estado de raid5 y transferir la carga del primario cuando falla una unidad" es la solución que le brinda la mayoría de los beneficios sin inconvenientes? (Además de perder el factor de frescura de la ejecución sin ninguna redundancia local, por supuesto). Si la recuperación de su unidad raid5 tarda mucho más que una sincronización completa de datos de la base de datos, su software de incursión está actuando de manera extraña o tiene discos muy grandes, Yo pensaría
fuente
La falla de la unidad debe tenerse en cuenta aquí.
Imagine por un segundo que nuestras unidades en un día en particular tienen una tasa de falla de 1/1000. Imagine entonces que tenemos 20 unidades en cada una de nuestras 3 matrices.
La posibilidad de que una sola unidad falle en una matriz es, por lo tanto, 20/1000 = 1/50. La posibilidad de que dos unidades fallen dentro de la misma matriz es algo cercano a 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Entonces, al cambiar de RAID 0 a RAID 5, es mucho menos probable que matemos uno de nuestros arreglos.
Entonces, podemos llevar esto más lejos: si la probabilidad de que una matriz falle en un día es 1/50, entonces la posibilidad de que dos matrices fallen en un día es 1 / (50 * 50) = 1/2500. La posibilidad de que fallen dos matrices RAID 0 idénticas es el doble de la falla de una matriz RAID 5, suponiendo el mismo conjunto de discos. Este aumento exponencial en las posibilidades de falla debería preocuparte, ya que aumenta enormemente la posibilidad de que más de una matriz falle a la vez.
Como es probable que estos discos tengan una larga vida útil, es probable que pueda ejecutar los números como se indica arriba y ver directamente qué efecto tendrá esto en la confiabilidad; si puede publicar las especificaciones de la unidad, puedo agregar ese cálculo a esta publicación. Si el riesgo es aceptable o no, es decisión de su organización.
Otro elemento a tener en cuenta es que la probabilidad de falla de la unidad se puede aumentar utilizando SSD fabricados dentro del mismo lote (misma fábrica, mismo tiempo). Si no tiene cuidado, podría terminar con los 3 nodos cayendo debido a este problema.
Descargo de responsabilidad: los cálculos anteriores se han simplificado, todavía son relativamente precisos.
fuente
Esta es una configuración bastante común cuando se ejecutan AG con unidades de almacenamiento internas / conectadas directamente. Especialmente con NVMe u otros dispositivos de almacenamiento flash basados en PCI.
Simplemente equivale a tratar una falla de la unidad como una falla del servidor. Con una pequeña cantidad de unidades de estado sólido, realmente no tiene un MTBF significativamente menor para las unidades que para los otros componentes de estado sólido del servidor, por lo que simplemente trata cada unidad como un punto de falla para el servidor, y reemplazar / reconstruir el servidor en caso de una falla de la unidad.
fuente
¿Me intriga lo que intentas lograr? Usted menciona que no está tratando de obtener ganancias de rendimiento de esta configuración, entonces, ¿qué ganancia está tratando de obtener?
Nota sobre el problema de rendimiento: si está ejecutando SSD de clase empresarial, ¿su cálculo RAID es realmente un cuello de botella que necesita para mejorarlo?
Tomando sus 3 profesionales, no creo que lo haya pensado lo suficiente:
¿SQL failover de inmediato? ¿Qué va a hacer que la conmutación por error se active automáticamente? ¿El servidor desconectará la unidad tan pronto como alguien la golpee? ¿Qué pasa si es solo un sector defectuoso en un disco? Si SQL no afecta al sector defectuoso, ¿se realizará la conmutación por error? No estoy 100% seguro de eso.
¿Reduce la posibilidad de falla en general por capacidad de TB? Su pensamiento parece ser la menor cantidad de discos significa menos puntos de falla, pero no creo que sea correcto. Las probabilidades de que falle 1 disco siguen siendo las mismas si tiene 1 disco o 10 discos (o 100 discos), pero con RAID 0 también significa que es una falla catastrófica.
¿Un SSD adicional le costará mucho más que obtenga RAID5? Entiendo cómo RAID1 O 1 + 0 podría volar el presupuesto, pero ¿1 disco adicional?
Sin redundancia, si un disco falla y el RAID se desconecta, ese nodo estará desconectado hasta que reconstruya el RAID y restaure todas sus bases de datos desde cero. ¿Qué proceso vas a tomar para que eso suceda? No puede eliminar la base de datos del Grupo de disponibilidad, ya que eso detendrá la replicación a DR, pero si no realiza alguna acción, los otros dos servidores no podrán truncar sus archivos de registro. ¿Eso esta bien? ¿Qué sucede si falla un viernes por la noche de un largo fin de semana? ¿Eso todavía está bien? ¿Pueden sus secundarias hacer frente a esa cantidad de datos acumulados?
Mis últimas preguntas serían sobre el tiempo de reconstrucción que mencionas será más rápido. ¿Estás 100% seguro de que será más rápido? Cuanto mas rapido
La configuración del servidor Brent Ozar sigue siendo mi guía para configurar nuevas instancias de SQL. El primer punto de la guía es validar que no está utilizando RAID0 para ninguna unidad.
==== ACTUALIZACIÓN ====
Un pensamiento adicional, ¿qué sucede cuando los servidores secundarios no están sincronizados con los principales? Incluso con la replicación síncrona, sus secundarias pueden volver automáticamente a asíncrono, y una vez que lo hacen, pierde la capacidad de conmutación por error automática ya que cualquier conmutación por error provocará la pérdida de datos. Un par de ejemplos cuando esto podría suceder:
Son casos extremos, pero podrían ser catestróficos dependiendo de lo que se pierda en esos momentos.
fuente