Cuando instalamos una cabina de almacenamiento, ya sea NAS o SAN, es importante conocer el rendimiento de la misma, especialmente si disponemos de discos de diferentes tecnologías y niveles RAID necesitaremos saber cual es el mas apropiado para cada caso, no necesita el mismo rendimiento en almacenamiento un servidor con bases de datos SQL o de Exchange que un Gateway de Terminal Server por ejemplo. Ademas, sin esta información se hace difícil la gestión y el crecimiento. Con IOMeter podemos identificar donde están los cuellos de botella de nuestro sistema de almacenamiento. En alguna ocasión he tenido que testear un disco RDM, desconectarlo y presentárselo a un servidor físico para volverlo a testear y determinar si tengo algún problema en el host (Controladora inadecuada, firmware inadecuada, switch con problemas, Storage Adapter mal configurado, etc..).
Además de medir el rendimiento de I/O disponemos de un componente llamado Dynamo que genera carga de trabajo (Workload) simulando diferentes escenarios de forma granular.
Siempre que sea posible, intentar que el host que contenga la VM que generar los test no contenga mas VMs en marcha para conseguir un resultado mas preciso.
Instalación:
La instalación de IOMeter no tiene ningún secreto, tan solo ha de ejecutarse en la VM sobre la que lanzaremos los tests.
Existen multitud de variables en la configuración de los tests con IOMeter, yo acostumbro a utilizar la siguiente de forma genérica para medir el numero de R/W MB/s secuenciales, IOPS totales, IOPS de escritura, IOPS de lectura y latencia en ms.
A no ser que queramos testear el rendimiento de un disco local de la VM crearemos un disco RDM o VMDK en el datastore o LUN que queramos medir.
Disk Targets:
Crear 4 workers por disco de destino a testear, especificar el disco de destino creado.
El campo sectores "sectors", indica el tamaño de archivo para el test, con 4GB. sera suficiente para Datastores locales, no obstante si vamos a testear una NAS o SAN con caches de controladoras de 4,8 o mas GB. el tamaño de archivo debera ser mayor. Como se ve en la configuración siguiente suelo usar archivos de 32GB. que acustumbran a superar el tamaño de cache de la mayoria de cabinas.
Si lo que queremos es testear subsistemas de discos, caches, etc. usaremos valores mas pequeños para que el workload no llege al disco.
Worker 1:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 1
# of Outstanding I/Os: 32
Worker 2:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 2
# of Outstanding I/Os: 32
Worker 3:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 3
# of Outstanding I/Os: 32
Worker 4:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 4
# of Outstanding I/Os: 32
Access Specifications:
Crear dos reglas de Access Specifications para todos los Workers al 50% cada una.
Para testear almacenamiento en entornos virtualizados se recomiendan bloques de 8k.
8K;100% read;0% random (lectura).
8K;0% read;0% random(escritura).
Test Setup:
Ramp Up Time: 30 s
Run Time: 3 minutes
Y por ultimo, en results Display modificaremos la frecuencia de actualización a 1 segundo:
Update Frequency: 1 s
