Archive

Posts Tagged ‘almacenamiento’

VCAP – Sección 1 – Analizar comportamientos de I/O para determinar los requerimientos de almacenamiento

November 1, 2010 2 comments

Que tal gente, continuando con los temas de VCAP nos toca hablar sobre el como analizar los comportamientos o workloads a nivel del almacenamiento, para esto estaremos primero entendiendo ciertos conceptos y factores que componen estos workloads.

Es importante conocer el comportamiento que tienen nuestras aplicaciones para poder hacer un correcto diseño de nuestra infraestructura, en este caso nos estamos enfocando al almacenamiento parte fundamental del performance que tendrán nuestras aplicaciones virtualizadas.

¿Que elementos determinan el performance de nuestro almacenamiento?

  • IOPS: I/O per second, básicamente la cantidad de lecturas y escrituras que un disco puede realizar en un segundo, esto básicamente nos dirá la capacidad del disco o del tipo de disco que estaremos utilizando para responder a nuestras operaciones. Existen valores aceptados y utilizados como base para cada tipo de disco:

  • Latencia: básicamente es la cantidad de tiempo que nuestro disco o almacenamiento tarda en responder a nuestras solicitudes en disco, este valor se mide en ms,  un valor aceptable estaría entre 5 ms a 10 ms dependiendo los requerimientos de las aplicaciones virtualizadas.
  • Ancho de banda o capacidad del arreglo/disco/interfaz (Mbps): este ancho de banda depende de que interfaz estaremos utilizando, existen varias interfaces actualmente, IDE, SATA,SCSI,SAS y FC.  Estas interfaces son vistas de distinta manera en el lado de un almacenamiento central (SAN, NAS), ya que ahí estaríamos hablando de 2 tipos de interfaces, back-end y front-end. En el caso de back-end es la interconexión entre los distintos controladores o storage processors de dicho almacenamiento aquí generalmente hablamos de interfaces SAS y FC. Finalmente en el caso de Front-end hace referencia a la interfaz que tiene contacto directamente con los servidores o clientes de este almacenamiento, aquí demos interfaces de FC y ethernet (ISCSI , NFS ,CIFS).

  • RAID: en un post anterior tocamos el tema de los niveles de RAID, aquí tenemos que tener en cuenta que el nivel de RAID implica cierta implicación al performance en cuanto a escritura se refiere , para ser más claro, debido a la paridad que se tenga dependiendo del nivel de RAID para poder hacer la escritura de un bloque tiene que también escribir los bloques de su paridad es por eso que debemos tener en consideración este punto en el momento de hacer el calculo de nuestro almacenamiento. Aquí les dejo el link a mi post anterior sobre los niveles de RAID:

http://hispavirt.wordpress.com/2010/10/11/vcap-%e2%80%93-seccion-1-%e2%80%93raid-y-vms/

  • Cache: En los sistemas de almacenamiento central, incluso en los mismos discos que utilizamos día a día existe un factor clave para mejorar el performance, el cache, por cache entendemos escencialmente memoria RAM que actua como buffer almacenando las operaciones de I/O, existen 2 tipos de caches , volatiles y no volatiles estos se diferencian simplemente en si se pierde o no la información almacenada en el caso de perdida de energía. Generalmente el cache para operaciones de escritura es no volatil es decir no se pierde en el caso de perdida de energía al contrario del cache para lecturas. Al ser memoria RAM es mucho más veloz que cualquier sistema de disco con esto mejoramos significativamente el performance de nuestro almacenamiento debido a que las operaciones son almacenadas temporalmente en estos caches y después escritas a disco, con esto ganamos la capacidad de aceptar mas operaciones concurrentes y en el caso de lectura almacena las lecturas anteriores a disco y en casos de almacenamientos avanzados existen algoritmos que predicen que información será leída y se almacena en dicho cache para ser entregada mas rápido.
  • Queuing: con esta capacidad del almacenamiento se encolan las operaciones de I/O para poder ser procesadas después, esto puede ser a nivel del almacenamiento y directamente en las HBAs de nuestros servidores.
  • Coalescing: esta capacidad de algunos almacenamientos lo que realiza es ordenar las operaciones de I/O almacenadas en cache  en el caso que tengamos un comportamiento “random” con esto se busca reducir la cantidad de actividad en disco ya que los comportamientos de escritura serán uniformes.

¿Que tipos de comportamientos o workloads existen? ¿Que debo tener en cuenta?

Existen 2 principales tipos de comportamientos en cuanto a operaciones a disco se refiere, secuencial y random. En el caso de un comportamiento secuencial las operaciones de I/O se llevan a cabo de manera más rápida debido a que se necesita un menor numero operaciones de “seek” que básicamente lo que se realiza es un posicionamiento de la aguja del o los discos en el correcto sector donde reside la información. Al contrario en el caso de un comportamiento random o al azar las operaciones de I/O estarán tratando de acceder a distintos sectores del almacenamiento, aumentando así las operaciones de seek a este tiempo se le llama “seek latency”.

Una vez que sabemos que tipo de comportamiento tiene nuestra aplicación sea secuencial o random es importante tener en cuenta los siguientes elementos:

  • tamaño de las operaciones I/O (I/O request size):  el tamaño de la información leída o escrita a nuestro almacenamiento, entre más grande el tamaño de nuestra operación ej. 64k será más eficiente de procesar y decrece el uso de procesador. Existen distintos tamaños, podemos ver 2k, 4k, 8k, etc. En el caso que quisiéramos virtualizar servidores Windows podemos determinar el tamaño de nuestras operaciones utilizando perfmon y ejecutando el siguiente counter “Avg. Disk Bytes/Read”.
  • porcentaje de escritura y/o lectura: importante para determinar el nivel de RAID a utilizar, ej. en el caso de aplicaciones que requieran un alto nivel de escritura se benefician de un raid 10.

¿Como puedo obtener todos estos datos?

 


Revoluciones por minuto (RPM)

IOPS

SSD

6000

15 K

175

10 K

125

7200

75

5400

50

VMware View 4.5 – Conociendo lo nuevo – parte 2

September 17, 2010 Leave a comment

Que tal Gente, el día de hoy continuando con la serie les hablaré de mas nuevas capacidades y/o cambios que existen en VMware View 4.5 con respecto a versiones anteriores.

En esta parte 2 es el turno de platicar un poco sobre el almacenamiento y VMware View 4.5 , y el concepto de “storage tiering” aplicado a view.  Storage teiring hace referencia a la categorización de nuestros tipos de almacenamiento por cualidades como puede ser si esta basado en discos sata, sas o ssd , con esto podemos manejar calidades de almacenamiento para distintas aplicaciones, organizaciones, etc.

Con esto tenemos la capacidad de asignar distintos tipos de almacenamiento según sea el tipo de disco requerido por las vms , en esta nueva versión se existen los siguientes tipos de discos duros virtuales para nuestros “linked clones”:

  • Persistent Disk -  Este disco aloja todos los datos de usuario, o profile del usuario que se esta haciendo uso dicha maquina virtual , que no es algo nuevo en versiones anteriores de VMware View lo conocíamos como User Data Disk. Lo interesante en esta nueva versión es que este tipo de disco lo podemos desconectar o conectar a una VM, en caso que se vaya a destruir la vm o pool de escritorios podemos archivarlo y re-utilizarlo para otro escritorio para el mismo usuario como lo vemos en la siguiente imagen:

  • Disposable Disk -  En este tipo de disco se aloja todos los archivos temporales del sistema y el archivo de paginación (pagefile.sys) , este disco es creado cuando dicho linked clone es encendido y en el momento que es apagado se destruye ya que como sabemos son archivos transitorios. Algo que tenemos que tener siempre en cuenta aquí es que el tamaño de este disco tiene que ser mayor al archivo de pagefile.

Una vez que sabemos que tipos de discos conforman un linked clone es donde podemos claramente ver la ventaja de poder definir donde estará cada uno de estos discos, por ejemplo, el tipo de disco Disposable seria un candidato perfecto a estar en almacenamiento basado en SATA debido al precio y performance del mismo, mientras que las replicas de view serian un candidato para almacenamiento SSD debido a su alta transaccionalidad. Aquí les dejo una imagen de como nosotros configuramos que datastore será el que este alojando cada tipo de disco:

¿DRS para nuestro almacenamiento?

May 24, 2010 Leave a comment

¿Alguna vez han querido darle cierta preferencia a una vm en cuanto al vmfs se refiere? Bueno, pues esto puede ser una realidad, en varios posts en la web se ha hablado de una nueva posible característica que VMware incluirá en un próximo release de vSphere ¿El nombre? Storage I/O Control (SIOC), les recomiendo que lean el post del gurú de performance en VMware Scott Drummonds, que lo pueden encontrar en este link : http://vpivot.com/2010/05/04/storage-io-control/#more-515.

Todos sabemos que muchas veces la perdida de performance en una infraestructura VMware se debe a una mala configuración de nuestro almacenamiento , o a que el mismo no tiene la capacidad de entregar la cantidad de IOPS que nuestra infraestructura requiere , SIOC lo que nos permitirá es definir shares de disco pero esta vez no a nivel servidor ESX, sino a nivel arreglo, es decir esto aplicara para todos los servidores ESX que estén accediendo a un VMFS determinado en algún arreglo de discos esto lo podemos ver en las siguientes imágenes :

En esta primera  imagen podemos ver claramente que la distribución de nuestro arreglo está totalmente dispareja, la vm C está teniendo 50% del Queue del almacenamiento, mientra s las otras maquinas se reparten el otro 50%.

En esta segunda imagen podemos ver él como SIOC en base a los shares que tenemos configurados para cada máquina virtual , asignará los respectivos porcentajes de queue a nuestras vms, repartiendo el acceso al arreglo de una manera más equitativa.

SIOC se basará en la latencia que está presentando nuestro vmfs , y esto como nos comenta Scott , se basa en el total de latencias que están teniendo todas las vms que residen en dicho vmfs. Cuando este valor sobrepase el valor que nosotros configuramos como tope, se reducirá el acceso a nuestro arreglo a las maquinas con menos shares, permitiendo así que las maquinas criticas puedan mantener un buen funcionamiento.

Recuerden que esta funcionalidad no ha sido revelada oficialmente, hasta ahora solo se ha comentado que se está trabajando en ella,  aquí les dejo un link de vmware donde pueden lver una presentación del vmworld 2009 sobre SIOC:

http://vmworld.com/docs/DOC-3855

Follow

Get every new post delivered to your Inbox.

Join 38 other followers