it-swarm-es.com

Diseño de disco de SQL Server en un ISCSI SAN

Su práctica estándar es separar los archivos de registro y de datos para separar los discos del sistema operativo (tempdb, copias de seguridad y archivos de intercambio también) ¿Esta lógica todavía tiene sentido cuando sus unidades están todas SAN basadas y sus no están tallados en discos específicos o conjuntos de incursiones; son solo parte del número x de unidades en el SAN y el LUN es solo la asignación de espacio

27
CPU_BUSY

Los registros y las unidades de datos tienen diferentes patrones de acceso a los datos que están en conflicto entre sí (al menos en teoría) cuando comparten una unidad.

Escrituras de registro

El acceso al registro consta de una gran cantidad de pequeñas escrituras secuenciales. De manera algo simplista, los registros de base de datos son búferes de anillo que contienen una lista de instrucciones para escribir elementos de datos en ubicaciones particulares del disco. El patrón de acceso consta de una gran cantidad de pequeñas escrituras secuenciales que se debe garantizar que se completen, por lo que se escriben en el disco.

Idealmente, los registros deben estar en un volumen RAID-1 o RAID-10 silencioso (es decir, no compartido con nada más). Lógicamente, puede ver el proceso como el DBMS principal escribiendo entradas de registro y uno o más subprocesos de lectura de registros que consumen los registros y escriben los cambios en los discos de datos (en la práctica, el proceso se optimiza para que las escrituras de datos se escriban inmediatamente cuando sea posible). Si hay otro tráfico en los discos de registro, estos otros accesos mueven los cabezales y las escrituras de registro secuenciales se convierten en escrituras de registro aleatorias. Estos son mucho más lentos, por lo que los discos de registro ocupados pueden crear un punto de acceso que actúa como un cuello de botella en todo el sistema.

Escrituras de datos

(actualizado) Las escrituras de registro deben confirmarse en el disco (denominado medio estable) para que una transacción sea válida y apta para su confirmación. Uno puede ver esto lógicamente como entradas de registro que se escriben y luego se utilizan como instrucciones para escribir páginas de datos en el disco mediante un proceso asincrónico. En la práctica, las escrituras de la página del disco se preparan y almacenan en búfer en el momento en que se realiza la entrada de registro, pero no es necesario escribirlas inmediatamente para que se confirme la transacción. Los búferes de disco se escriben en medios estables (disco) mediante el proceso Lazy Writer (gracias a Paul Randal por señalar esto) que Este artículo de Technet analiza con un poco más de detalle.

Este es un patrón de acceso muy aleatorio, por lo que compartir los mismos discos físicos con registros puede crear un cuello de botella artificial en el rendimiento del sistema. Las entradas del registro deben escribirse para que la transacción se confirme, por lo que tener búsquedas aleatorias ralentiza este proceso (la E/S aleatoria es ¡mucho más lento que la E/S de registro secuencial) convertirá el registro de secuencial en un dispositivo de acceso aleatorio. Esto crea un cuello de botella de rendimiento grave en un sistema ocupado y debe evitarse. Lo mismo se aplica al compartir áreas temporales con volúmenes de registro.

La función del almacenamiento en caché

Los controladores SAN tienden a tener grandes RAM cachés, que pueden absorber el tráfico de acceso aleatorio hasta cierto punto. Sin embargo, para la integridad transaccional es deseable tener escrituras en disco desde un DBMS garantizado para completar. un controlador está configurado para usar el almacenamiento en caché de escritura diferida, los bloques sucios se almacenan en caché y la llamada de E/S se informa como completa al Host.

Esto puede solucionar muchos problemas de contención, ya que la memoria caché puede absorber una gran cantidad de E/S que, de otro modo, iría al disco físico. También puede optimizar las lecturas y escrituras de paridad para RAID-5, lo que reduce el efecto sobre el rendimiento que tienen los volúmenes RAID-5.

Estas son las características que impulsan la escuela de pensamiento 'Dejemos que SAN se ocupe de ello'), aunque este punto de vista tiene algunas limitaciones:

  • El almacenamiento en caché de escritura no simultánea todavía tiene modos de falla que pueden perder datos, y el controlador ha fallado al DBMS, diciendo que los bloques se han escrito en el disco donde de hecho no lo han hecho. Por esta razón, es posible que no desee utilizar el almacenamiento en caché de escritura diferida para una aplicación transaccional, en particular algo que contenga datos financieros o de misión crítica donde los problemas de integridad de los datos podrían tener consecuencias graves para la empresa.

  • SQL Server (en particular) usa E/S en un modo en el que una bandera (llamada FUA o Acceso de actualización forzada) fuerza las escrituras físicas en el disco antes de que regrese la llamada. Microsoft tiene un programa de certificación y muchos SAN proveedores producen hardware que respeta esta semántica (requisitos resumidos aquí ). En este caso, ninguna cantidad de el caché optimizará las escrituras de disco, lo que significa que el tráfico de registro ¡lo hará traspasará si está en un volumen compartido ocupado.

  • Si la aplicación genera mucho tráfico en el disco, su conjunto de trabajo puede invadir el caché, lo que también provocará problemas de contención de escritura.

  • Si el SAN se comparte con otras aplicaciones (particularmente en el mismo volumen de disco), el tráfico de otras aplicaciones puede generar cuellos de botella en el registro.

  • Algunas aplicaciones (por ejemplo, almacenes de datos) generan grandes picos de carga transitorios que las hacen bastante antisociales en las SAN.

Incluso en un gran SAN volúmenes de registro separados siguen siendo una práctica recomendada. Puede salirse con la suya sin preocuparse por el diseño en una aplicación poco utilizada. En aplicaciones realmente grandes, incluso puede obtener un beneficio de múltiples SAN controladores. Oracle publica una serie de estudios de casos de diseño de almacenamiento de datos donde algunas de las configuraciones más grandes involucran múltiples controladores.

Ponga la responsabilidad del desempeño donde corresponde

En algo con grandes volúmenes o donde el rendimiento podría ser un problema, haga que el equipo SAN responsable del rendimiento de la aplicación. Si van a ignorar sus recomendaciones de configuración, asegúrese de que la administración son conscientes de esto y que la responsabilidad del rendimiento del sistema reside en el lugar apropiado. En particular, establezca pautas aceptables para las estadísticas clave de rendimiento de la base de datos, como esperas de E/S o esperas de pestillo de página o SLA de E/S de aplicaciones aceptables.

Tenga en cuenta que tener la responsabilidad del desempeño dividida entre varios equipos crea un incentivo para señalar con el dedo y pasar la pelota al otro equipo. Se trata de un antipatrón de gestión conocido y una fórmula para los problemas que se prolongan durante meses o años sin llegar a resolverse. Idealmente, debería haber un solo arquitecto con autoridad para especificar la aplicación, la base de datos y SAN cambios de configuración.

Además, compare el sistema bajo carga. Si puede organizarlo, los servidores de segunda mano y las matrices de conexión directa se pueden comprar a un precio bastante bajo en Ebay. Si configura una caja como esta con una o dos matrices de discos, puede configurar la configuración del disco físico y medir el efecto sobre el rendimiento.

Como ejemplo, he hecho una comparación entre una aplicación que se ejecuta en un SAN (un IBM Shark) grande y una caja de dos sockets con una matriz U320 de conexión directa. En este caso, £ 3,000 El valor del hardware comprado en ebay superó al de gama alta de £ 1M SAN por un factor de dos - en un Host con una configuración de CPU y memoria aproximadamente equivalente.

A partir de este incidente en particular, se podría argumentar que tener algo como esto por ahí es una muy buena manera de mantener a los administradores SAN honestos.

Supongo que la etiqueta Equallogic y el contenido de la solicitud significan que está hablando de una SAN Equallogic. Lo que sigue es específicamente sobre Equallogic y no se aplica a otros tipos SAN.

Con los arreglos Equallogic, los discos específicos utilizados para los volúmenes no se pueden especificar con tanta precisión como con, digamos, los arreglos EMC Clariion, por lo que el enfoque tiene que ser un poco diferente.

La arquitectura Equallogic es muy automatizada y dinámica. Su componente básico es la unidad de matriz, no los paquetes/grupos RAID dentro de una matriz, como se ve en otras SAN. Cada matriz está completamente configurada para RAID 5, 6, 10 o 50, aunque esto no implica que solo haya un grupo RAID por matriz, simplemente nunca podrá decidir o interactuar con ellos en ese nivel. Coloca arreglos en grupos de almacenamiento y sus grupos luego pertenecen a un grupo de almacenamiento. El grupo de almacenamiento tiene una dirección IP virtual de clúster que usted usa como destino de descubrimiento iSCSI para todos los volúmenes dentro de ese grupo: el software de administración del grupo EQL y la pila MPIO del host manejan la redirección de nivel de IP necesaria para enrutar realmente al puerto más apropiado en las matrices individuales al solicitar bloques de datos, pero eso es algo que tiene poca o ninguna capacidad de controlar.

Los volúmenes de almacenamiento se asignan a partir del espacio libre total en cada grupo. Todos los volúmenes dentro de un grupo se distribuyen en todos los arreglos en ese grupo (hasta un máximo de 4 arreglos separados) para distribuir la red IO a través del número total de interfaces de red (2-4 por matriz Eql según el modelo) y IO en tantos controladores como sea posible. El software de gestión Equallogic supervisa el rendimiento de volumen\matriz a lo largo del tiempo y optimiza dinámicamente la distribución de bloques en las matrices de miembros. En general a menos que sepa lo que está haciendo, debe poner todos los arreglos en un solo grupo y dejar que haga lo suyo, solo recuerde asegurarse de configurar sus discos de alta velocidad (SAS 10k\15k) con RAID 10, velocidad media con RAID 50 o 5 para garantizar que el proceso de optimización elija realmente las unidades de alto rendimiento reales. Puede llevar varios días (más de 7) llegar a un estado óptimo, pero en general debería alcanzar una distribución equilibrada bastante rápido, ya que distribuye los volúmenes de inmediato. sobre tantas matrices como pueda (de nuevo hasta t o 4) cuando se crean inicialmente.

En una aproximación aproximada, tendrá entre 2500-5000 IOP por matriz de PS, según el tipo de unidad y el tipo de RAID. Si proporciona suficientes IOP totales, el proceso de administración automatizado eventualmente debería brindarle un buen rendimiento, incluso si simplemente agrupa todos los volúmenes en un solo grupo.

Sin embargo, si desea garantizar que sus registros, bases de datos, almacenes temporales, unidades de sistema operativo, etc.estén realmente aislados entre sí, puede hacer un par de cosas. En primer lugar, puede definir una preferencia RAID para un volumen que garantizará que el volumen específico siempre se almacene solo en matrices de ese tipo RAID (si están presentes en el grupo al que pertenece el volumen). En segundo lugar, puede definir grupos de almacenamiento por niveles que solo contengan arreglos que brinden los diversos grados de rendimiento que necesita para ese nivel en particular y luego distribuir sus volúmenes en los grupos apropiados. La advertencia de salud que viene con este enfoque es que generalmente necesitará muchos arreglos para que esto realmente brinde un mejor rendimiento general; sin embargo, eso puede ser menos importante para usted que garantizar el rendimiento en sus volúmenes críticos, por lo que a menudo sigue siendo el mejor elección. La arquitectura de referencia de Dell para bases de datos Oracle utiliza un grupo con 2 arreglos RAID 10 para datos, disco de votación y OCR, y un grupo separado con un solo arreglo RAID 5 para el área de recuperación de Flash.

En todo momento con Equallogic, debe preguntarse si las decisiones que está tomando con respecto al particionamiento forzado proporcionarán un mejor rendimiento agregado para sus volúmenes en términos de interfaces de red, ejes de disco y controladores disponibles. Si no puede responder eso, opte por el número mínimo de piscinas y deje que se encargue de los detalles o solicite a un especialista de Equallogic que haga un diseño real. Si solo tiene una matriz, no hay nada que pueda hacer en términos de separación de volúmenes.

9
Helvick

Almacenamos nuestras bases de datos en cajas individuales SAN pero con datos, registros y LUN de respaldo separados, cada uno en diferentes grupos de discos, escalonados por velocidad, con nuestros registros en RAID 10 15 Krpm LUN, datos en RAID 1 LUN de 10/15krpm y copia de seguridad en LUN de 7.2krpm RAID 5. También presentamos registros y datos a través de diferentes controladores en la misma SAN.

5
Chopper3

¡Gran pregunta!

Primero eche un vistazo al debate de Brent Ozar "Steel Cage BlogMatch" sobre este tema.

En nuestra empresa, para la mayoría de los servidores, colocamos los datos y registros en la misma unidad SAN y lo dejamos en manos del equipo SAN para asegurarnos de que todo funcione Derecha.

Empiezo a pensar que esta no es la mejor estrategia, especialmente para servidores de mayor volumen. El problema subyacente es que realmente no tengo forma de verificar que el equipo de SAN realmente esté haciendo algo más que juntar suficientes unidades para el espacio que necesitamos. No ejecutamos IO puntos de referencia contra SAN unidades de nuestro lado o algo así, simplemente asumimos que están "haciendo su trabajo" (ajustando el rendimiento y el espacio), que probablemente sea un poco ingenuo.

Mi otro pensamiento es que el tipo de acceso que los datos y los registros necesitan es diferente. Intentaré encontrar el artículo que leí recientemente que hablaba sobre cómo los dos tipos de unidades diferentes realmente deberían optimizarse de maneras muy diferentes (creo que uno necesitaba optimización para escrituras secuenciales, el otro necesitaba optimización para lecturas aleatorias, algo así .)

4
BradC

En resumen, sí, crearía volúmenes separados para archivos de datos, archivos de registro y archivos de registro y datos TempDB de SQL Server.

Dado que etiquetó su pregunta con Equallogic, lea la Guía de arquitectura de referencia de Dell: Implementación de Microsoft® SQL Server® con matrices de almacenamiento Dell ™ EqualLogic ™ serie PS50 (se requiere registro) antes de diseñar su solución. A menudo, encontrará que la orientación sobre configuraciones específicas puede diferir significativamente de los consejos genéricos .

4
Peter Stuer

Estoy de acuerdo con BradC (+1) en términos de rendimiento. Generalmente, una buena SAN tendría más E/S sin procesar de las que podría esperar usar.

Todavía es una buena idea separar sus BACKUPs de su sistema en vivo (Obviamente, lo sé, pero si tuviera una £ 1 por cada vez que veo esto ...)

Además, se recomienda mantener el tempdb alejado de los archivos de registro. El tipo de SAN tienda de campaña para ponerte los ojos en blanco cuando empiezas a querer "cubos diferentes" (término técnico) para Logs, Data y Temp, pero si les dices es para que puedas medir los diferentes cantidad de datos IO yendo a cada área y haz que te muestren sus elegantes gráficos de rendimiento!

Simplemente verifique dos veces que el tipo de SAN lo haya configurado correctamente para usted. Si desea RAID 10, insista en él (yo lo hice) a pesar de que seguían diciendo que su RAID 5 no tiene rendimiento multa.

(Para operaciones "basadas en archivos", RAID 5 está bien. Para escrituras intensivas, tan pronto como llene el búfer de escritura, ¡se arruinará!)

3
Guy

Tenga en cuenta también todas las combinaciones de términos aquí.

Generalmente, y muy básico:

  • Array = un grupo de discos en una configuración RAID (como RAID5)
  • Volumen = una parte de una matriz presentada al Host en el SAN con un LUN

Puede tener varios volúmenes en la misma matriz, lo cual es algo para recordar cuando está haciendo optimizaciones de alto grado discutidas en este hilo.

La clave es lo que varios otros han mencionado (no lo olvide), separar los datos/registro/copia de seguridad en diferentes ejes de disco, no solo en volúmenes separados.

Editar: ¡y Helvick arriba le dio una -gran respuesta- sobre las SAN Equallogic!

2
pauska