Su práctica estándar para separar los archivos de registro y datos para separar los discos del sistema operativo (tempdb, copias de seguridad y archivos de intercambio también) ¿Tiene sentido esta lógica cuando todas sus unidades están basadas en SAN y sus LUNS no están tallados en discos específicos o conjuntos de incursiones? -son solo parte de la cantidad x de unidades en la SAN y el LUN es solo asignación de espacio
Los registros y las unidades de datos tienen diferentes patrones de acceso a datos que están en conflicto entre sí (al menos en teoría) cuando comparten una unidad.
El registro escribe
El acceso al registro consta de una gran cantidad de pequeñas escrituras secuenciales. De manera algo simplista, los registros de DB son buffers de anillo que contienen una lista de instrucciones para escribir elementos de datos en ubicaciones particulares del disco. El patrón de acceso consiste en 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 silencioso (es decir, no compartido con nada más) RAID-1 o RAID-10. Lógicamente, puede ver el proceso como el DBMS principal que escribe entradas de registro y uno o más hilos lectores de registro que consumen los registros y escriben los cambios en los discos de datos (en la práctica, el proceso está optimizado para que las escrituras de datos se escriban fuera inmediatamente donde sea posible). Si hay otro tráfico en los discos de registro, estos otros accesos mueven los cabezales y las escrituras secuenciales se convierten en escrituras 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 registros deben confirmarse en el disco (denominadas medios estables) para que una transacción sea válida y elegible para confirmar. Uno puede ver esto lógicamente como entradas de registro que se escriben y luego se usan 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 están realmente preparadas y almacenadas en el búfer en el momento en que se realiza la entrada del registro, pero no necesitan escribirse inmediatamente para que se confirme la transacción. Las memorias intermedias 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 los registros puede crear un cuello de botella artificial en el rendimiento del sistema. Las entradas de 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 lenta que la E / S de registro secuencial) convertirá el registro de un dispositivo de acceso secuencial en un dispositivo de acceso aleatorio. Esto crea un serio cuello de botella de rendimiento en un sistema ocupado y debe evitarse. Lo mismo se aplica al compartir áreas temporales con volúmenes de registro.
El papel del almacenamiento en caché
Los controladores SAN tienden a tener grandes cachés de RAM, 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 garantizadas para completarse. Cuando un controlador está configurado para usar el almacenamiento en caché de reescritura, los bloques sucios se almacenan en caché y la llamada de E / S se informa como completa al host.
Esto puede suavizar muchos problemas de contención ya que el caché puede absorber una gran cantidad de E / S que de otro modo se irían al disco físico. También puede optimizar las lecturas y escrituras de paridad para RAID-5, lo que disminuye el efecto sobre el rendimiento que tienen los volúmenes RAID-5.
Estas son las características que impulsan la escuela de pensamiento 'Deje que la SAN se ocupe de ello', aunque esta visión tiene algunas limitaciones:
El almacenamiento en caché de reescritura aún tiene modos de falla que pueden perder datos, y el controlador se ha conectado al DBMS, diciendo que los bloques se han escrito en el disco donde en realidad no. Por esta razón, es posible que no desee utilizar el almacenamiento en caché de reescritura para una aplicación transaccional, en particular algo que contenga datos financieros o de misión crítica donde los problemas de integridad de datos podrían tener serias consecuencias para el negocio.
SQL Server (en particular) usa E / S en un modo en el que un indicador (denominado FUA o acceso de actualización forzada) fuerza las escrituras físicas en el disco antes de que vuelva la llamada. Microsoft tiene un programa de certificación y muchos proveedores de SAN producen hardware que cumple con esta semántica (requisitos resumidos aquí ). En este caso, ninguna cantidad de caché optimizará las escrituras en disco, lo que significa que el tráfico de registros se agitará si se encuentra en un volumen compartido ocupado.
Si la aplicación genera mucho tráfico de disco, su conjunto de trabajo puede desbordar el caché, lo que también causará problemas de contención de escritura.
Si la 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 los hacen bastante antisociales en las SAN.
Incluso en una SAN grande, los 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 controladores SAN. Oracle publica una serie de estudios de caso de diseño de depósito de datos donde algunas de las configuraciones más grandes involucran múltiples controladores.
Poner 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 de SAN sea responsable del rendimiento de la aplicación. Si van a ignorar sus recomendaciones de configuración, asegúrese de que la administración esté al tanto de esto y que la responsabilidad del rendimiento del sistema recaiga 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 retención de página o SLA de E / S de aplicaciones aceptables.
Tenga en cuenta que tener la responsabilidad del rendimiento dividido en varios equipos crea un incentivo para señalar con el dedo y pasar el dinero al otro equipo. Este es un antipatrón de gestión conocido y una fórmula para problemas que se prolongan durante meses o años sin resolverse nunca. Idealmente, debería haber un único arquitecto con autoridad para especificar los cambios de configuración de la aplicación, la base de datos y la SAN.
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 de forma bastante económica en Ebay. Si configura un cuadro como este con una o dos matrices de discos, puede combinar con la configuración del disco físico y medir el efecto en el rendimiento.
Como ejemplo, he hecho una comparación entre una aplicación que se ejecuta en una SAN grande (un IBM Shark) y una caja de dos sockets con una matriz U320 de conexión directa. En este caso, £ 3,000 en hardware comprado en eBay superó a un SAN de gama alta de £ 1M por un factor de dos: en un host con una configuración de memoria y CPU aproximadamente equivalente.
A partir de este incidente en particular, se podría argumentar que tener algo como esto es una muy buena manera de mantener honestos a los administradores de SAN.
Supongo que la etiqueta Equallogic y el contenido de la solicitud significan que estás hablando de una SAN Equallogic. Lo que sigue es específicamente sobre Equallogic y no se aplica a otros tipos de SAN.
Con los arreglos Equallogic, los discos específicos utilizados para los volúmenes no se pueden especificar con la mayor precisión posible con, por ejemplo, los arreglos EMC Clariion, por lo que el enfoque debe ser un poco diferente.
La arquitectura de 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 puede decidir o interactuar con ellos en ese nivel. Coloca las matrices en agrupaciones de almacenamiento y sus agrupaciones pertenecen a un grupo de almacenamiento. El grupo de almacenamiento tiene una dirección IP de clúster / virtual que utiliza 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 maneja 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 desde el espacio libre total en cada grupo. Todos los volúmenes dentro de una agrupación se distribuyen entre todas las matrices de esa agrupación (hasta un máximo de 4 matrices separadas) 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) e IO a través de tantos controladores como sea posible. El software de administración Equallogic monitorea el rendimiento de volumen / matriz a lo largo del tiempo y optimiza dinámicamente la distribución de bloques entre las matrices de miembros. En general, a menos que sepa lo que está haciendo, debe colocar todas las matrices 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 realmente elija las unidades de alto rendimiento reales.
Para una aproximación aproximada, tendrá entre 2.500 y 5.000 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 automatizada 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 unos de otros, 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 agrupaciones de almacenamiento por niveles que solo contienen matrices que ofrecen los diversos grados de rendimiento que necesita para ese nivel en particular y luego distribuir sus volúmenes en las agrupaciones apropiadas. La advertencia de salud que viene con este enfoque es que generalmente necesitará muchos arreglos para que esto realmente brinde un mejor rendimiento general; 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 Oracle DB's utiliza un grupo con 2 conjuntos RAID 10 para datos, disco de votación y el OCR, y un grupo separado con un único conjunto RAID 5 para el área de recuperación de Flash.
En todos los momentos con Equallogic, debe preguntarse si las decisiones que está tomando con respecto a la partición forzada proporcionarán un mejor rendimiento agregado para sus volúmenes en términos de interfaces de red disponibles, ejes de disco y controladores. Si no puede responder eso, opte por el número mínimo de grupos y deje que maneje 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.
fuente
Almacenamos nuestros DB en cajas SAN individuales pero con datos separados, LUN de registro y respaldo, cada uno en diferentes grupos de discos, clasificados por velocidad, con nuestros registros en LUN RAID 10 15Krpm, datos en RAID 1 10 / 15krpm LUN y respaldo en RAID 5 LUN de 7.2 krpm. También presentamos registros y datos a través de diferentes controladores en la misma SAN.
fuente
Gran pregunta!
Primero eche un vistazo al debate "Steel Cage BlogMatch" de Brent Ozar sobre este tema.
En nuestra empresa, para la mayoría de los servidores, colocamos Datos y Registros en la misma unidad SAN, y dejamos que el equipo SAN se encargue de que todo funcione correctamente.
Estoy empezando 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 puntos de referencia de E / S contra las unidades SAN desde nuestro lado ni nada, simplemente asumimos que están "haciendo su trabajo" (ajustando tanto el rendimiento como el espacio), lo que probablemente sea un poco ingenuo.
Mi otro pensamiento es que el tipo de acceso que necesitan los datos frente a los registros es diferente. Trataré de 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í .)
fuente
En resumen, sí, crearía volúmenes separados para archivos de datos, archivos de registro y datos y archivos de registro de TempDB de SQL Server.
Dado que etiquetó su pregunta con Equallogic, lea la Guía de arquitectura de referencia gratuita de Dell: Implementación de Microsoft® SQL Server® con matrices de almacenamiento Dell ™ EqualLogic ™ serie PS5000 (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 .
fuente
Estoy de acuerdo con BradC (+1) en términos de rendimiento. En general, una buena SAN tendría más E / S sin procesar de lo que podría esperar usar.
Todavía es una buena idea separar sus COPIAS DE SEGURIDAD de su sistema en vivo (Obviamente lo sé, pero si tuviera un £ 1 por cada vez que vea esto ...)
Además, se recomienda mantener tempdb alejado de los archivos de registro. La tienda del tipo SAN te pondrá los ojos en blanco cuando comiences a querer "cubos diferentes" (término técnico) para Registros, Datos y Temp, pero si les dices que es así, puedes medir la cantidad diferente de datos IO que van a cada área y ¡haz que te muestren sus gráficos de rendimiento elegantes!
Solo verifique doble / doblemente que el tipo de SAN lo haya configurado correctamente para usted. Si desea RAID 10, insista en ello (lo hice) a pesar de que seguían diciendo que su RAID 5 no tiene penalización de rendimiento.
(Para las operaciones "basadas en archivos", RAID 5 está bien. Para escrituras intensivas, ¡tan pronto como llene el búfer de escritura está atornillado!)
fuente
Tenga en cuenta toda la combinación de términos aquí también.
En general, y muy básico:
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), separe los datos / registro / copia de seguridad en diferentes ejes de la unidad, no solo volúmenes separados.
Editar: y Helvick arriba te dio una gran respuesta sobre Equallogic SAN.
fuente