No prestes atención a esa SAN detrás de la cortina

Érase una vez, construí mis propios servidores SQL y tenía control sobre la configuración de la unidad, los niveles de RAID, etc. El consejo tradicional de separación de datos, registros, tempdb, copias de seguridad (¡dependiendo del presupuesto!) Siempre fue una parte muy importante del proceso de diseño del servidor SQL.

Ahora con una SAN de nivel empresarial, solo solicito una cantidad específica de espacio en disco para un nuevo servidor SQL, dividido en unidades lógicas para datos, copias de seguridad y archivos compartidos. Ciertamente hace que mi trabajo sea más fácil, pero hay una parte de mí que no se siente completamente cómoda y que realmente no puedo mirar "detrás de la cortina" para ver lo que realmente está sucediendo allí.

Tengo entendido que el equipo de SAN no configura diferentes "tipos" de unidades de manera diferente (optimizando las unidades de datos para acceso aleatorio frente a las unidades de registro para las transmisiones de secuencias). Algo de esto puede depender del producto SAN en sí (tenemos un HP XP12000 y un HP XP24000), pero me han asegurado que el software de HP realiza todo tipo de configuración de rendimiento dinámico (vigilando los puntos calientes de E / S y reconfigurando sobre la marcha). optimizar esos LUN), para que los equipos de aplicaciones y los DBA no tengan que preocuparse por nada de eso. Algo sobre "distribuir la carga de todos los servidores en una gran cantidad de husillos" o algo así.

Mis preguntas / discusión:

1. Sin hacer enemigos en el equipo de SAN, ¿cómo puedo asegurarme a mí mismo y a los desarrolladores de aplicaciones que nuestros servidores SQL no están sufriendo de un almacenamiento mal configurado? ¿Solo usa estadísticas de perfmon? Otros puntos de referencia como sqlio?

2. Si cargo la prueba en estas unidades SAN, ¿eso realmente me da una medida confiable y repetible de lo que veré cuando salgamos al mercado? (suponiendo que el software SAN podría "configurarse dinámicamente" de manera diferente en diferentes momentos).

3. ¿El IO pesado en una parte de la SAN (digamos el servidor de Exchange) afecta mis servidores SQL? (suponiendo que no estén dando discos dedicados a cada servidor, lo que me han dicho que no están)

4. ¿Ayudaría la solicitud de separar unidades lógicas para diferentes funciones de unidades lógicas (datos vs registro vs tempdb)? ¿El SAN ver la diferente actividad de IO en estos y óptimamente configurar de manera diferente?

5. Estamos en una especie de crisis espacial en este momento. A los equipos de aplicaciones se les dice que recorten los archivos de datos, etc. ¿Las preocupaciones de espacio causarían que el equipo de SAN tome diferentes decisiones sobre cómo configuran el almacenamiento interno (niveles RAID, etc.) que podrían afectar el rendimiento de mi servidor?

Gracias por sus pensamientos (tema similar discutido brevemente en esta pregunta de SF )

Sin hacer enemigos en el equipo de SAN, ¿cómo puedo asegurarme a mí mismo y a los desarrolladores de aplicaciones que nuestros servidores SQL no están sufriendo de un almacenamiento mal configurado? ¿Solo usa estadísticas de perfmon? Otros puntos de referencia como sqlio?

En resumen, probablemente no haya una manera de estar realmente seguro. Lo que diría (soy administrador de SAN) es que si sus aplicaciones están funcionando a la altura de sus expectativas, no se preocupe. Si comienza a ver problemas de rendimiento que cree que podrían estar relacionados con el rendimiento de SAN / Disk IO, entonces sería prudente preguntar. No utilizo mucho almacenamiento HP como usted, pero en el mundo de IBM / NetApp puedo decir por experiencia que no hay muchas opciones que le permitan configurarlo "mal". En la actualidad, la mayoría del almacenamiento empresarial elimina muchas conjeturas al construir matrices de incursiones, y realmente no le permite hacerlo mal. A menos que estén mezclando velocidades de disco y capacidades dentro de los mismos grupos de banda, puede estar seguro en la mayoría de los casos de que su disco está funcionando bien.

Si cargo la prueba en estas unidades SAN, ¿eso realmente me da una medida confiable y repetible de lo que veré cuando salgamos al mercado? (suponiendo que el software SAN podría "configurarse dinámicamente" de manera diferente en diferentes momentos).

La prueba de carga debe ser bastante confiable. Solo tenga en cuenta que cuando realiza una prueba de carga de una casilla, es decir, al estar en una matriz de disco / SAN compartida, su rendimiento puede (y se verá) afectado por otros sistemas que usan el mismo almacenamiento.

¿El IO pesado en una parte de la SAN (digamos el servidor de Exchange) afecta mis servidores SQL? (suponiendo que no estén dando discos dedicados a cada servidor, lo que me han dicho que no están)

Puede. No se trata solo de los discos, o de qué discos, están los servidores. Todos los datos se están sirviendo a través de un controlador de disco y luego un conmutador SAN. El rendimiento que verá dependerá en gran medida de cómo esté conectado el controlador de disco a los estantes de disco correspondientes y la SAN correspondiente. Si toda la matriz se conecta a la red troncal SAN en una sola hebra de fibra de 4 gbps, entonces claramente el rendimiento se verá afectado. Si la matriz está conectada a través de dos SAN redundantes que tienen equilibrio de carga, utilizando enlaces troncalizados, entonces sería imposible que el intercambio solo absorbiera demasiado ancho de banda. Otra cosa que debe tenerse en cuenta es la cantidad de E / S que puede hacer la matriz. Siempre que la matriz y la SAN a la que está conectada se escalen correctamente,

¿Ayudaría la solicitud de separar unidades lógicas para diferentes funciones de unidades lógicas (datos frente a registro frente a tempdb)? ¿Vería la SAN las diferentes actividades de E / S en estas y las configuraría de manera diferente de manera óptima?

Probablemente sea una cuestión de preferencia, y también depende en gran medida de cómo lo configuren los administradores de almacenamiento. Podrían darle tres LUN en la misma matriz o volumen, en cuyo caso todo es lo mismo de todos modos. Si le dieron LUN individuales en diferentes arreglos, en diferentes volúmenes (discos físicamente diferentes), entonces podría valer la pena que los separe.

Estamos en una especie de crisis espacial en este momento. A los equipos de aplicaciones se les dice que recorten los archivos de datos, etc. ¿Las preocupaciones de espacio causarían que el equipo de SAN tome diferentes decisiones sobre cómo configuran el almacenamiento interno (niveles RAID, etc.) que podrían afectar el rendimiento de mi servidor?

No creo que su administrador de almacenamiento cambie el nivel de incursión para liberar espacio. Si lo hiciera, entonces probablemente debería ser despedido. Los problemas de espacio pueden hacer que las cosas se configuren de manera diferente, pero normalmente no de una manera que afecte el rendimiento. Es posible que se vuelvan un poco más estrictos sobre la cantidad de espacio que le dan. Pueden habilitar características como la desduplicación de datos (si la matriz lo admite) que puede dificultar el rendimiento de la matriz mientras se ejecuta el proceso, pero no durante todo el día.

El equipo de SAN debe tener herramientas que puedan ayudarlo a revelar si su aplicación está activa. Obviamente, también debe monitorear y medir su extremo.

La mayor parte de mi experiencia es con EMC, así que YMMV. Pero lo siguiente debería aplicarse a la mayoría de los equipos SAN.

Solo hay muchos puertos que entran en la matriz. A veces hay un interruptor SAN en el medio que puede definir zonas. El hecho de que la matriz sea esencialmente un gran conjunto de almacenamiento no significa que no deba preocuparse por el rendimiento de E / S.

Entonces, si siente que tiene problemas de E / S, debe reducir dónde está el cuello de botella. Si está en algún lugar entre el HBA y la matriz, puede averiguar si el HBA está al máximo o si el puerto SAN en el lado del conmutador / matriz está suscrito en exceso. Además, debe hacer que el equipo de SAN monitoree los patrones de acceso para su aplicación, tanto desde un arranque en frío como desde un arranque en caliente.

Obviamente, el almacenamiento subyacente marca la diferencia al ejecutar RAID5 lento grande frente a RAID10 rápido, ya que en algún momento tendrá que golpear el disco independientemente de los diferentes niveles de caché.

HTH Puede hacerme ping fuera de línea si tiene un problema específico, ya que esto podría tomar un tiempo para investigar.

Sin hacer enemigos en el equipo de SAN, ¿cómo puedo asegurarme a mí mismo y a los desarrolladores de aplicaciones que nuestros servidores SQL no están sufriendo de un almacenamiento mal configurado? ¿Solo usa estadísticas de perfmon? Otros puntos de referencia como sqlio?

Lo primero que debe saber antes de realizar cualquier tipo de evaluación comparativa es a qué tolerancia debe ejecutar su propia carga de trabajo. Por lo tanto, evalúe sus propias cosas antes de verificar el nuevo sistema. De esa manera, si descubre que está presionando un máximo de, por ejemplo, 56 MB / s durante las cargas máximas (¿copias de seguridad?), Descubriendo que la matriz de discos conectada a SAN 'solo' empuja 110 MB / s bajo cargas máximas simuladas, puede ser aseguró que el límite no será el canal de E / S.

Cuando revisé una nueva matriz de discos, hice este tipo de pruebas de rendimiento. La nueva matriz utilizaba unidades SATA en lugar de unidades de canal de fibra (SCSI), y necesitaba asegurarme de que funcionaría en nuestro entorno. Estaba profundamente dudosa. Pero después de la caracterización, descubrí que el nuevo sistema tenía suficiente sobrecarga de E / S bajo el pico para mantenerse al día con el pico medido en los discos más confiables. Me sorprendió.

Si cargo la prueba en estas unidades SAN, ¿eso realmente me da una medida confiable y repetible de lo que veré cuando salgamos al mercado? (suponiendo que el software SAN podría "configurarse dinámicamente" de manera diferente en diferentes momentos).

Debido a la naturaleza compartida de las matrices de discos conectados a SAN, el rendimiento es variable durante la semana. Si ya sabe cuándo es su carga máxima de E / S, realice una serie de pruebas de carga durante la hora del día en que se encuentre su carga máxima de E / S. De esa forma, puede caracterizar mejor qué tipo de sobrecarga de E / S está disponible durante los períodos que más le interesan. Las pruebas de carga durante los momentos de menor actividad le darán una idea de cómo serán las cosas "ágiles", pero las pruebas máximas lo harán. darle una verdadera verificación de límites.

¿El IO pesado en una parte de la SAN (digamos el servidor de Exchange) afecta mis servidores SQL? (suponiendo que no estén dando discos dedicados a cada servidor, lo que me han dicho que no están)

Si los LUN de Exchange comparten discos con sus LUN de SQL, lo harán absolutamente. Usamos HP EVA, no XP, pero creo que usan la misma terminología de "grupo de discos". Los LUN del mismo grupo de discos comparten discos y, por lo tanto, compiten por E / S en esos dispositivos físicos. Cuantos más discos coloque en un grupo de discos, más margen de maniobra tendrá la matriz para hacer malabarismos con las E / S. Los arreglos (al menos los EVA hacen esto, y supongo que los XP más caros hacen lo mismo) distribuyen bloques LUN lógicos a través de los discos físicos de una manera no secuencial. Esto le permite hacer lo que sugiere, que es distribuir dinámicamente grupos de bloques a los que se accede con frecuencia a diferentes dispositivos físicos para aumentar el paralelismo y reducir la contención de E / S a nivel de disco.

La pregunta que debe hacerse es cuánto presupuesto de E / S tiene ese grupo de discos y si las aplicaciones que usan esos LUN están o no suscritas en exceso para E / S. Esa es una pregunta que los administradores de almacenamiento tendrán que seguir. Podría ser que el pico de E / S para Exchange (probablemente durante las copias de seguridad) no coincida con las cargas SQL, y ambos sistemas pueden coexistir felizmente.

¿Ayudaría la solicitud de separar unidades lógicas para diferentes funciones de unidades lógicas (datos frente a registro frente a tempdb)? ¿Vería la SAN las diferentes actividades de E / S en estas y las configuraría de manera diferente de manera óptima?

Para las matrices HP, necesitaría colocar los diferentes patrones de E / S en diferentes grupos de discos , no en LUN. Los patrones de E / S de la base de datos no deberían coexistir con los patrones de acceso de servicio web, por ejemplo. Los diferentes LUN no mejoran notablemente su rendimiento a menos que estén en diferentes grupos de discos. Si están en el mismo grupo de discos, la única ventaja real es el sistema operativo, donde puede hacer la programación de E / S en el núcleo para mejorar el paralelismo con el subsistema de disco. Dicho eso ...

Los arreglos HP, a mi entender de todos modos, son conscientes de los diferentes patrones de acceso en los LUN, pero prestan mucha atención a los bloques lógicos reales. Poner los registros en un LUN diferente pone un límite en los bloques lógicos que obtendrán ese tipo de tráfico de E / S, y eso facilitará la tarea de ordenar correctamente los bloques lógicos en los discos físicos.

Estamos en una especie de crisis espacial en este momento. A los equipos de aplicaciones se les dice que recorten los archivos de datos, etc. ¿Las preocupaciones de espacio causarían que el equipo de SAN tome diferentes decisiones sobre cómo configuran el almacenamiento interno (niveles RAID, etc.) que podrían afectar el rendimiento de mi servidor?

Seguro. Si hay poco espacio, no obtendrá grupos de discos dedicados para su E / S (a menos que su entorno de almacenamiento sea lo suficientemente grande como para justificar dedicar 7 TB de disco físico para su uso exclusivo, en cuyo caso ese puede ser el caso ) El debate Raid5 / Raid10 depende en gran medida de las políticas de la organización, y preguntar es su mejor opción.

Sugiero abrir un diálogo con su equipo SAN y su proveedor para abordar sus inquietudes. Uno de los problemas que tendrá al ejecutar sus propios puntos de referencia es que sus pruebas pueden no tener relación con lo que sucede en la producción, particularmente en las cargas máximas. La mayoría de las SAN tienen toneladas de caché respaldada por batería, lo que en muchos casos (especialmente cuando ejecuta puntos de referencia sintéticos) significa que está escribiendo en la RAM y obteniendo un rendimiento increíble.

Dependiendo de su entorno y la solución que esté utilizando, es posible que algunos proveedores CE hayan ingresado y configurado la SAN al estándar que prefiera. Eso sucede más de lo que piensas. Tendrá que reducir el shell "el equipo de SAN lo sabe todo" hasta que tenga la confianza de que la solución cumple con sus requisitos.

Buena suerte.

Una vez estuve en una conferencia de Oracle con una charla sobre este tema: SAN sana para bases de datos.

La esencia de la charla está disponible en este archivo PDF o en el sitio de los autores aquí.