Tendencias de rendimiento de E / S aleatorias con tendencia precisa para la planificación de capacidad

Donde trabajo tenemos numerosos servidores de "gran hierro" que se utilizan para alojar muchas máquinas virtuales con un hipervisor Xen. Por lo general, se configuran con 32 GB de RAM, procesos de doble núcleo cuádruple y discos rápidos con una gran capacidad de E / S.

Estamos en el momento en que la configuración de hardware existente se está volviendo un poco larga y es hora de salir y buscar hardware nuevo más grande, más rápido y más brillante.

Como se mencionó anteriormente, el kit existente se ha implementado con 32 GB de RAM y eso ha limitado de manera efectiva la cantidad de máquinas virtuales que podemos implementar en un host.

Sin embargo, al investigar el hardware más nuevo, es evidente que puede obtener más RAM en una sola máquina con 64, 72 o incluso 96 GB en un solo chasis. Evidentemente, esto nos permitirá llevar más máquinas a un host determinado, lo que siempre es una victoria. El análisis completado hasta ahora sugiere que el factor limitante ahora se trasladará al subsistema de disco.

El problema ahora es tratar de tener una idea de dónde estamos ... En virtud del uso, sabemos que no estamos limitados en términos de ancho de banda de E / S, más aún, el número de I aleatorios / O operaciones que pueden completarse. Sabemos anecdóticamente que una vez que lleguemos a este punto, entonces iowait se disparará y todo el rendimiento de la máquina se destinará a los perros.

Ahora, este es el meollo de la pregunta que estoy haciendo. ¿Alguien sabe de una manera precisa de rastrear / marcar con precisión el rendimiento de E / S existente específicamente en relación con el número de operaciones de E / S aleatorias que se están completando?

En lo que realmente estoy tratando de obtener una métrica es "esta configuración puede manejar con éxito X número de solicitudes de E / S aleatorias, y actualmente (en promedio) estamos haciendo operaciones Y con un pico de operaciones Z".

¡Gracias por adelantado!

sarhace el trabajo bien aquí; recopilará la cantidad de transacciones, así como los sectores leídos / escritos por segundo, que se pueden usar para luego reproducir su carga de trabajo de E / S con una precisión relativamente decente (en términos de relaciones de lectura / escritura, así como el tamaño de la transacción, que es el factor determinante de cuán "aleatorio" es su IO). No es perfecto, pero en mi experiencia hace un trabajo lo suficientemente bueno como para hacer el tipo de estimación que estás viendo.

Entonces, esto parece un problema de monitoreo e informes de capacidad. Si va a comenzar a medir las estadísticas de tendencias, iría en todos los ámbitos, para que pueda comparar, correlacionar, etc.

En términos de herramientas, tiene ganglios, zenoss, nagios, etc. en el mundo de código abierto y muchos otros productos de proveedores.

Puede configurarlos para rastrear, medir y almacenar los KPI que le interesan, y luego informarlos periódicamente.

Dadas sus consultas sobre el uso de RAM, tendría sentido incluir las estadísticas de memoria, el uso de intercambio y la CPU también, para que pueda compararlas en todos los ámbitos durante el mismo período de tiempo y ver cuál es limitado, etc.

Una vez que esté capturando datos, puede almacenarlo todo en una gran base de datos para informes, posiblemente con datos históricos, por ejemplo. almacene cada métrica de 5 segundos durante 6 meses, luego por minuto, luego 5, luego por hora, a medida que retrocede. Ese tipo de cosas puede ser programado y ejecutado a través de cron, autosys, etc.

Esos informes le darán lo que la gerencia quiere, es decir. algo con bonitos gráficos.

Y para la administración diaria, puede ver información en tiempo real en un gráfico / figuras a través de la consola para ver cómo se está desempeñando en un momento dado.

Usamos collectl ya que podemos extraer toda la información necesaria en un solo archivo y reproducir las estadísticas que necesiten. Esto le permitirá ver el número de IOPS por intervalo de grabación, cambios de contexto, estadísticas de memoria. Puede desglosar esto por disco o simplemente echar un vistazo general al sistema. Collectl también admite brillo.

Esta es una gran herramienta para obtener una visión general del rendimiento total del sistema. Buena suerte, según las observaciones, los discos SATA generalmente superan entre 200 y 300 IOPS cuando se hace acceso aleatorio.

Grabamos y graficamos E / S de disco de la misma manera que hacemos todas las demás métricas:

• Los datos se extraen de los hosts mediante SNMP. Nuestras cajas NAS / SAN hacen esto de forma nativa. Utilizamos net-snmp en todos los hosts de Linux, que proporciona esta información de USB-DISKIO-MIB .

• Los datos se almacenan (en formato RRD) y se grafican con Cacti . Algunas plantillas de Disk IO nos dan un recuento y tamaño de transacciones, que se muestran en el formato actual, promedio y pico habitual.

Estas métricas no son necesariamente tan finitas como usar iostat/ dstat/ saren un host. Pero es fuego y olvido, que se configura automáticamente cuando se pone en marcha una nueva máquina, se almacena centralmente y permanece disponible para futuras referencias.

Utilizamos estos datos para alertarnos sobre tendencias inusuales sobre una base operativa y siempre mirar hacia atrás cuando se realiza la planificación de la capacidad.

En lo que realmente estoy tratando de obtener una métrica es "esta configuración puede manejar con éxito X número de solicitudes de E / S aleatorias [..]".

Hay un par de problemas con esto:

• Es bastante difícil separar y cuantificar las E / S aleatorias de las E / S secuenciales. Dado que la diferencia fundamental entre los dos es la ubicación física de los bloques almacenados en el plato del disco. Puede hacer una suposición educada a partir del tamaño de las transacciones, sobre la base de que muchas transacciones pequeñas probablemente se relacionan con pequeños archivos punteados en el disco. Pero no hay garantía. Se podría estar leyendo pequeñas cantidades de datos de forma secuencial desde un único archivo o contiguo bloques en el disco.

• Registrar las métricas le dará una muy buena idea de cuáles son sus compromisos hoy, cómo han cambiado con el tiempo y, por lo tanto, cómo cambiarán en el futuro. Lo que no te dirá es cuál es el techo. Al menos no antes de que sea demasiado tarde. Para determinar esto, necesita hacer algunos cálculos matemáticos (de sus especificaciones de hardware), evaluación comparativa (me aprecio a bonnie++mí mismo) y es útil tener una idea logística de para qué están haciendo / siendo utilizados esos domUs.

Dependiendo de su backend de almacenamiento (IBM SVC / DS8000), puede obtener estadísticas relacionadas con IOPS aleatorias directamente.

Para extraer estadísticas del servidor, puede usar nmon . Es gratis (como en la cerveza). Originalmente desarrollado por IBM para AIX, también se ejecuta en Linux.

Si la gente usa SAR, al menos espero que esté muestreando sus datos cada pocos segundos. Cuando uso collectl, pruebo una vez / segundo. En cuanto a medir qué tan bien le está yendo a las E / S aleatorias, use una herramienta como el dt de Robin Miller (google it) y puede generar fácilmente MUCHAS E / S aleatorias y luego simplemente medir con collectl para ver cuántas puede hacer por segundo. Un disco típico generalmente hace un máximo de 200-300 I / Os / seg, basado más o menos en la latencia rotacional. El tamaño del bloque tuvo un efecto mínimo, ya que esperar 1/2 revolución para que el disco esté en la ubicación correcta supera todo lo demás.

por cierto, iowait es una de las medidas más incomprendidas. No tiene NADA que ver con la carga de la CPU, solo significa que la CPU no estaba haciendo nada más mientras ocurría la E / S. De hecho, si estás al 100% de iowait, ¡eso significa que estás aproximadamente al 100% inactivo!

-marca