Chubascos Blog

Chubascos tecnológicos para quitarnos la neblina de las tecnologías de la nube! Viva la lluvia!

Archivos por Etiqueta: esxtop

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 5

Hola,

Quinta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.

Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
*Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.*
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.

Bien, entramos de lleno en un tema más que interesante y que por el detalle que requiere se suele pasar por alto o dimensionar “más o menos a ojo y a base de experiencia”.

Como ya se habló en otro post de la serie, cada tipo de RAID viene acompañado de algún tipo de penalización en el momento de escribir. Esta penalización puede ser de 1-1 IOPS (penalización nula o dicho de otra forma, que no hay penalización) o como es el caso más conocido, el del RAID 5, el cual es 4-1 IOPS. Donde por cada operación de I/O que le sea solicitada a nuestro RAID, se generarán 4 IOPS.

Bien, determinar el nivel apropiado de RAID para los distintos tipos de cargas en las VMs primero y sobre todo, implica que conozcamos el tipo de carga de nuestra VM. Esto se refiere a:
– Porcentaje de lecturas
– Porcentaje de escrituras
– Frecuencia de acceso a la información
– Cantidad de información actual y previsión de crecimiento
– Tipo de operaciones (secuenciales o aleatorias)
– Picos y utilización media

Esto sólo para empezar! Para seguir con lo de “nivel apropiado de RAID”, también habría que conocer cómo calcular el impacto de cada tipo de RAID en determinados tipos de carga. Esto básicamente se reduce a una fórmula muy sencilla en la cual se consideran los porcentajes de lectura y de escritura así como la penalización por el tipo de RAID y también la cantidad de IOPS para las que estamos dimensionando el RAID.

Por último podríamos también hablar de la infraestructura en sí. Desde donde viajarán los datos (HBA), el tipo de protocolo que utilizaremos, el recorrido que harán y finalmente las características físicas y configuraciones que tengamos en nuestro storage…desde tipos de procesador hasta tipos de interconexión de los discos. Nada más imaginaos dimensionar un storage para soportar una cantidad altísima de operaciones pero lo conectamos todo a través de un cable a 1Gbps.

Como veréis, no son pocas las variables y sí es poco el conocimiento que se tiene del impacto REAL Y MEDIBLE de cada una de ellas. Evidentemente escribir un libro para calcular un RAID no es la idea (como lo de las HCL que comentábamos en otra entrada) por lo que veremos más en profundidad lo que a mi entender es más relevante.

Por favor, si os parece que me dejo algún aspecto relevante fuera del estudio, avisadme para poder valorar su inclusión en el post.

Tendremos en cuenta:

– Espacio necesario
– Porcentaje de lecturas
– Porcentaje de escrituras
– IOPS de la VM

Espacio necesario

Lo primero será obtener la información de la ocupación actual de la VM y la previsión de crecimiento. Esto es demasiado fácil como para tener que explicarlo 🙂 Pero basta con mirar la información de la VM desde el propio S.O. en todas sus particiones/puntos de montaje y mirar un poco el histórico de crecimiento además de preguntar si habrá algún tipo de cambio importante. Por ejemplo, que en un servidor de correo se desee ampliar la cuota de los buzones, que en un servidor de ficheros se piense comenzar a almacenar otro tipo de información como videos, fotos, etc por las mismas necesidades de negocio…vamos, cualquier cosa que pueda “romper” el histórico de crecimiento.

IOPS y distribución entre lecturas y escrituras

Esto ya tiene un poco más de miga (un poco) y podemos decir que hay muchas formas de verlo. Por ejemplo, con vcOPS. Esta herramienta ya nos presentará la información (TPS=Transacciones por segundo) desglozadas en lecturas y escrituras desde donde podremos obtener los porcentajes.

Utilizando esxtop o resxtop (la variante de esxtop que se usa desde vMA), podremos identificar las IOPS. Bastará con ir a la vista de las VMs (presionando “v”) y ver el número que nos muestra el campo CMDs de comandos por segundo. Normalmente este campo es igual al número de IOPS, salvo que algunas veces puede estar un poco hinchado por otro tipo de datos que no está demás contar como las reservas SCSI. “READS/s y WRITES/s” son la cantidad de inodos que se ven afectados ante las vibraciones de nuestro storage y la posición relativa del sol y la luna….que no! era para ver si estabais despiertos 😀 Evidentemente se trata de las lecturas y escrituras y la suma de estos dos valores dan como resultado los “CMDs” del primer campo.

Imagen

esxtop no sería mi primera opción ya que se trata de una herramienta para diagnosticar problemas y las circunstancias que los causan (root cause analisys). Sin embargo, se puede ejecutar esxtop de forma que guarde la información en un fichero y lugo la podamos “graficar” con un excel. Marco Broeken lo explica detalladamente en su blog http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/

Existe una versión gráfica de esxtop que podréis descargar desde los labs de VMware. Es un “fling” muy útil y fácil de usar.
http://labs.vmware.com/flings/visualesxtop

En lo personal suelo utilizar la versión opensource de Hyperic ya que además de analizar IOPS, me permite relacionar esas IOPS con otros factores como las consultas SQL, el número de usuarios conectados a una aplicación, bbdd, etc.
http://www.hyperic.com/hyperic-open-source-download

Las cuentas claras, conservan la amistad

Ahora sólo falta hacer números. Es MUY sencillo y no guarda ningún misterio. La fórmula con las modificaciones que Duncan Epping hizo para contemplar la penalización en las escrituras de los tipos de RAID, es la siguiente:

( IOPS de la VM × % lecturas ) + (( IOPS de la VM × % escrituras ) × Penalización RAID)

Por tanto, en caso de que nuestro estudio previo nos haya dado como resultado que nuestra VM necesita 1000 IOPS (aquí entra en factor un aspecto de diseño importante…diseñaremos para los picos de carga o diseñaremos para el consumo medio lo que resultará en ahorre de costes y cuellos de botella esporádicos. Aunque esto mejor dejarlo cuando vayamos por el VCAP-DCD 🙂 ) de los cuales el 40% son escrituras y el otro 60% son lecturas. La fórmula quedaría:

IOPS de la VM = 1000
% lecturas = 60%
% escrituras = 40%

( 1000 IOPS x 0,6 ) + (( 1000 IOPS x 0,4) * Penalización RAID) =
600 IOPS + ( 400 IOPS * Penalización RAID) =

Ahora toca jugar un poco con los RAIDs y recordar las penalizaciones para cada uno de ellos. Sobran las tablas por internet que muestran estas penalizaciones así que simplemente supondremos que queremos ver cómo nos quedaría con un RAID 5.

600 IOPS + ( 400 IOPS * 4 IOPS ) =
600 IOPS + 1600 IOPS = 2200 IOPS

Vemos así cómo para una VM con 1000 IOPS necesitaremos un RAID 5 de 2200 IOPS ya que cada una de las IOPS de escritura y sólo de escritura, tendrá una penalización de 4 IOPS por c/u de escritura.

Aquí se puede jugar mucho pero otra vez nos iríamos a la parte de diseño más que VCAP-DCA. Cuando tengamos que diseñar un storage, básicamente en este punto se tratará de un equilibrio entre IOPS y espacio que se necesita. De forma que la tarea se reduzca a encontrar la combinación que cubra las necesidades de IOPS y espacio con el menor coste posible. En este sentido, los discos de estado sólido están rompiendo las reglas del juego ya que para lo que antes podíamos necesitar barbaridades de discos, ahora con 4 o 5 discos de estado sólido lo conseguimos y a un mejor precio!

Algunas cosas que quiero comentar antes de dar por finalizado el post:

Lecturas – Si bien las escrituras sólo pueden quedarse igual o empeorar según el tipo de RAID que utilicemos, las escrituras sólo pueden mejorar. En este caso los cálculos son muy sencillos, basta con sumar las IOPS de los discos que forman el RAID y ya sabremos las IOPS de lectura que tenemos. Hay muchos debates en internet de “qué RAID es el mejor en lecturas”…la respuesta es fácil, mientras de más discos se pueda leer la información, mejor. Supongamos que un fichero de 10 MB está distribuido en 5 discos y que la controladora es capaz de leer de todos a la vez (a cada disco le toca leer 2MB)…mejor que si sólo tenemos el fichero en 2 discos (a cada disco le toca leer 5MB).

IOPS = La cantidad de operaciones de entrada/salida por segundo. Normalmente utilizada para medir los accesos aleatorios de escritura y lectura de bloques pequeños. Cargas habituales OLTP. Se puede calcular:
IOPS = throughput / block size

Throughput = La cantidad de información que se puede transmitir por segundo. Normalmente se utiliza para medir accesos aleatorios de bloques más grandes (64K). Se puede calcular:
Throughput = IOPS * block size

Block size = La cantidad de datos que se transmite en una operación de entrada/salida. Se puede calcular:
Block size = IOPS / Throughput

Frecuencia de acceso a la información = Casi todas las cabinas traen más o menos caché. Algunas con funcionalidades de tiering ponen en esta caché la información más utilizada por lo que es muy posible que cuando estemos realizando operaciones, muchas de ellas se valgan de la caché de nuestro storage. Por esto también es importante contrastar las fuentes de nuestra información. Una cosa es medir desde dentro del entorno virtual, otra es hacerlo a nivel de hipervisor y otra es hacerlo a nivel de storage. Como recomendación, si es posible, contrastar todas las fuentes para depurar la información en la que basaréis el diseño.

Bueno, otro post que se nos fue. Espero que esta información os sea útil y por favor dejad vuestros comentarios que hará ilusión leerlos 🙂

Saludos,
Sebastián Greco

Bibliografía utilizada para escribir este post:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008205
http://www.yellow-bricks.com/esxtop/
http://labs.vmware.com/flings/visualesxtop
https://communities.vmware.com/thread/456397
http://labs.vmware.com/flings/io-analyzer
http://goo.gl/t9Hl0Y
http://www.lucd.info/2011/04/22/get-the-maximum-iops/
http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/
http://www.hyperic.com/hyperic-open-source-download
http://wintelguy.com/2013/20130406_disk_perf.html
http://www.yellow-bricks.com/2009/12/23/iops/
http://www.tomshardware.co.uk/forum/251893-32-raid-raid#.
http://wintelguy.com/raidperf.pl
http://www.dataram.com/blog/?p=112
http://es.wikipedia.org/wiki/OLTP
http://es.wikipedia.org/wiki/OLAP