VCAP – Sección 6 – Troubleshooting de red

Que tal gente, vamos a continuar con los temas de preparación para el examen de certificación VCAP-DCA, en este caso nos toca hablar de como realizar troubleshooting a nivel de red en vSphere.

Identificar configuraciones de vSwitches en un .vmx

Para empezar recordemos que los archivos .vmx son aquellos en donde reside la configuración de nuestra VM, por lo cual todas las opciones de hardware y modificaciones que realicemos se verán reflejadas en este archivo, vamos a ver un ejemplo:

ethernet0.present = “TRUE”
ethernet0.virtualDev = “vmxnet3″
ethernet0.dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b”
ethernet0.dvs.portId = “105″
ethernet0.dvs.portgroupId = “dvportgroup-42″
ethernet0.dvs.connectionId = “692809732″
ethernet0.addressType = “vpx”
ethernet0.generatedAddress = “00:50:56:97:00:00″
ethernet1.present = “TRUE”
ethernet1.virtualDev = “vmxnet3″
ethernet1.dvs.switchId = “”
ethernet1.dvs.portId = “”
ethernet1.dvs.portgroupId = “”
ethernet1.dvs.connectionId = “0″
ethernet1.addressType = “vpx”
ethernet1.generatedAddress = “00:50:56:97:00:01″
ethernet1.networkName = “Produccion alterna”

• virtualDev = “vmxnet3″  – Aquí se nos hace referencia al tipo de vNic que se tiene.
• dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b” – el identificador del switch distribuido al que esta conectado, este id lo podemos verificar de una manera simple utilizando el comando net-dvs:

También tenemos la opción de verificar este ID en la carpeta .dvsData (net-dvs |grep com.vmware.common.port.volatile.persist):

 

• dvs.portgroupId = “dvportgroup-42″ – este es el identificador del portgroup en la base de datos del vCenter, podemos confirmarlo de igual manera con el comando net-dvs

(select * from vpx_dvportgroup)

• addressType = “vpx” – esta línea nos indica que el mac address del ethernet 0 (en este caso) esta a cargo de un vCenter, es decir, este se encargara del manejo de las mismas para que no haya problema con mac addresses repetidas.
• generatedAddress = “00:50:56:97:00:00″ -  mac address generada para el adaptador.
• networkName = “Produccion alterna” - vm portgroup (vSS) al cual esta conectado dicho adaptador.

Identificar entradas de vSwitches en el archivo de configuración del host ESX/ESXi

Aquí con archivo de configuración vamos a entender el archivo esx.conf , que encontramos en /etc/vmware. Vamos a ver un pequeño fragmento del mismo donde podemos ver las entradas de nuestro vSwitch:

/net/vswitch/child[0000]/name = “vSwitch0″
/net/vswitch/child[0000]/numPorts = “128″
/net/vswitch/child[0000]/portgroup/child[0000]/name = “Management Network”
/net/vswitch/child[0000]/portgroup/child[0000]/shapingPolicy/enabled = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/hasUplinkOrder = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/beacon = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/fullDuplex = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/minSpeed = “10″
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/pctError = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/maxActive = “1″
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/notifySwitch = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/reversePolicy = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/rollingRestoration = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/team = “lb_srcid”

Aquí podemos ver que tenemos el nombre de un vSwitch, el vSwitch0,  y podemos ver todas sus configuraciones como load balancing (lb_srcid , port ID) , beacon probing, etc. Todas las configuraciones de switches standard las encontraremos en este archivo empezando con “/net/vswitch/”.

Identificar comandos y herramientas que podemos utilizar para el troubleshooting de red en vSphere

• esxcfg-vswitch
• esxcfg-vswif
• esxcfg-vmknic
• esxcfg-vmknic
• net-dvs

Les sugiero darle un vistazo a esta página http://vmware-land.com/esxcfg-help.html , para poder conocer el uso de estos comandos (con excepción de net-dvs)

identificar logs a utilizar en el troubleshooting de red

Aquí no existen los en especifico que nos brinden información de red, pero por experiencia propia les podría decir que cualquier problema que se tenga en cuanto a desconexiones en las vmnics lo pueden encontrar en /var/log/messages.

utilzar net-dvs para troubleshooting de vDS

El problema con este comando es que no existe documentación oficial por parte de VMware para el uso del mismo, además de ser “unsupported”. Aquí como vimos anteriormente podemos obtener información del mismo. La manera más facil seria ejecutando el comando y mandando el resultado del mismo a un archivo de texto que podamos observar con mas calma:

net-dvs >infodvs.txt

Aquí podemos ver todas las opciones que tenemos para el uso del mismo:

~ # net-dvs –help
net-dvs: unrecognized option `–help’
Warning: This is an unsupported command. Use at your own risk.
net-dvs -a [ -P maxPorts] switch_name
net-dvs -d switch_name
net-dvs [ -A | -D ] -p port switch_name
net-dvs [ -s name=value | -u name ] -p port switch_name
net-dvs -l [ switch_name ]
net-dvs -i (init database)
net-dvs [-S | -R | -G ]
net-dvs -T
net-dvs -v “vlanID[;t|p[0-7][;min-max,min-max...]]
net-dvs -V “primaryVID,secondaryVID,i|c|p;primaryVID,secondaryVID,i|c|p…”
net-dvs -m “sid;dname;snaplen;[oiveld];encapvlan;wildcardsIn,wildcardsOut;dstPort1,dstPort2,…;srcInPort1,srcInport2,…;srcOutPort1,srcOutPort2,…;:sid2;dname2…”
net-dvs dvswitch -k “respool1_id;respool2_id;…”
net-dvs dvswitch -p dvport -K “respool1_id:shares:limit;respool2_id:shares:limit;…”
net-dvs dvswitch -p dvport -z “respool_id”
net-dvs dvswitch -j [activate|deactivate]
net-dvs -L uplink_name1[,uplink_name2,...] -t team_policy_type -p port switch_name
net-dvs dvswitch -H “red|yellow|green:some message” switch_name
net-dvs -o “depth,param|classname;depth,param|classname;… -p port|globalPropList switch_name
net-dvs –mtu mtu_value [-p dvport] switch_name
net-dvs –x 0|1 -p dvport switch_name
net-dvs –vlan vlanID -p dvport switch_name
net-dvs –reset -p dvport switch_name
net-dvs –cap cap_value -p dvport switch_name
net-dvs –states -p dvport switch_name
net-dvs –miscInfo  ;# Dumps cpu/meminfo
net-dvs –vmknicIp <vmknic> ;# Displays IPv4 address on <vmknic>

Utilizar comandos de vicfg-* (vSphere CLI) para realizar troubleshooting de configuraciones de red

Aquí vamos a encontrar muchos equivalentes de los comandos esxcfg-* les sugiero echar un vistazo a este link http://www.vmware.com/support/developer/vcli/vcli41/doc/reference/index.html para que puedan encontrar que comandos pueden utilizar y como utilizarlos.

Configurar un analizador de paquetes en un ambiente vSphere

Aquí básicamente estarán instalando el analizador de paquetes que ustedes utilicen, generalmente nos vamos por wireshark. Un punto importante que debemos de tener en cuenta al configurar la VM donde estará siendo ejecutando este sniffer es que la vNic o interfaz de red de dicha vm que estará capturando paquetes debe de ser conectada a un portgroup que permita “promiscuous mode”

Y para poder capturar paquetes de todas las VLANs configuradas en dicho vSwitch podemos configurar para dicho portgroup la vlan 4095, esto solo aplica para VST.

Troubleshooting de Private VLANs

Aquí mas que nada sería cuestión de entender el concepto de PVLAN, les dejo un link a un articulo propio explicándoselos VCAP – Sección 2 – Configurar y administrar VLANs y PVLANs

Existen algunos puntos importantes en cuanto a la configuración de red física:

• lógicamente los puertos conectados a nuestro servidor ESX/ESXi deben de ser trunk
• Nuestros Switches deben de ser PVLAN aware.
• En el caso del uso de PVLANs VTP (VLAN trunking protocol) deberá estar en modo transparente, debido a que las PVLANs son definidas localmente.

Troubleshooting de red en Service Console e interfaces de vmkernel

Les recomiendo echarle un vistazo a este KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007986. Estaremos utilizando el comando esxcfg-vswif para el manejo de las configuraciones de Service Console.

En el caso de tener ESXi el termino de Service Console nos es irrelevante, por lo cual estaremos realizando troubleshooting de una interfaz de vmkernel y estaremos utilizando el comando esxcfg-vmknic.

También necesitaremos del comando esxcfg-vswitch para poder agregar uplinks,vlans,etc.

 

Troubleshooting de DNS y ruteo

Para modificar nuestros DNS lo podemos realizar desde el vSphere client en “Configuration>DNS and Routing” , al igual que nuestro Default gateway.

Esto también puede ser modificado directamente en los archivos

/etc/sysconfig/network - para poder modificar el default gateway del service console

/etc/resolv.conf - para poder modificar nuestros DNS

Para modificar el gateway del vmkernel, lo tenemos que realizar directamente con el comando esxcfg-route

 

Utilizar ESXTOP / RESXTOP para troubleshooting de red

Aquí les recomendaría leer mis artículos VCAP- sección 3 – utilizar herramientas avanzadas para el monitoreo de performance y VCAP – Sección 3 – realizar medición y calculo de recursos en un ambiente vSphere para que se den una mejor idea de como funciona esxtop.

Aquí solo sería cuestión de poner atención a paquetes caídos:

%DRPTX – “dropped transmit packets” porcentaje de paquetes transmitidos que se han caido, esto representa problemas con la red fisica, alto consumo de la misma, problemas de hardware , etc. si el valor es distinto a “0″ , es algo que tenemos que verificar.

%DRPRX – “dropped received packets” porcentaje de paquetes recibidos que se han caido, aquí puede ser por cuestiones de recursos en el lado de la VM (no hay suficiente capacidad de procesamiento , aumentar recursos) o porque se esta teniendo un buffer overflow a nivel de rx rings.

 

Utilizar CDP y network hints para identificar problemas de conectividad

Podemos obtener información de CDP (Cisco Discovery Protocol) directamente desde nuestro vSphere client en la sección de “Configuration>Networking”, seleccionamos una vmnic conectada a un vSwitch donde tendremos el siguiente simbolo:

Y haciendo click sobre el mismo podremos ver información de CDP (si es que está disponible):

 

También tenemos la opción de obtener esta información desde la línea de comando, utilzando vim-cmd:

vim-cmd hostsvc/net/query_networkhint

 

 

 

VCAP – Sección 3 – Realizar medición y calculo de recursos en un ambiente vSphere

Que tal gente, llego la hora de continuar con los temas de estudio para el examen VCAP-DCA410. En esta ocasión vamos a platicar un poco de como realizar un “capacity planning” o poder planificar los recursos que se requieren actualmente en nuestra infraestructura como también los recursos que se podrán requerir en un futuro.

Entender el Algoritmo de DRS basado el “slots” y el impacto de los mismos en las recomendaciones de migración

Este punto lo veo un poco confuso, debido a que el algoritmo de DRS en si solo no se basa en “slots”, no es hasta la versión 4.1 de vSphere que DRS se integra de una manera muy cercana a HA permitiendo así, en el caso de tener un evento de failover, que HA le solicite a DRS el balanceo de un los recursos en caso que estén esparcidos entre los hosts que  conforman dicho cluster para así poder cumplir con las reservaciones y requerimientos de las VMs que se tienen que encender.

Un buen lugar para entender el funcionamiento de DRS es el siempre confiable sitio de Duncan Epping:

http://www.yellow-bricks.com/drs-deepdive/

Identificar herramientas para el monitoreo de los recursos

Básicamente en este punto podemos enlistar y describir una cantidad enorme de aplicaciones utilizadas para el monitoreo de peformance que existen para ambientes físicos y virtuales, para mi gusto los más utilizados son:

• Perfmon esta herramienta viene incluida en nuestros sistemas Windows, nos permite el monitoreo de recursos en vivo y también la capacidad de crear contadores con los cuales nosotros podemos definir tiempos a monitorear ciertos aspectos como puede ser red,cpu,memoria,etc. tenemos una gran variedad de contadores:

• esxtop esta herramienta incluida tanto en ESX como ESXi nos permite monitorear distintos aspectos de nuestro host, podemos monitorear RAM, CPU, red, almacenamiento,etc. Es una herramienta que ejecutamos en la linea de comando directamente en los hosts o también podemos ejecutarla de forma remota (resxtop). El mejor lugar para aprender mas sobre las métricas que tenemos y el uso de esxtop es un documento de la comunidad de VMware mantenido por mismo personal de VMware:  http://communities.vmware.com/docs/DOC-11812 .

vista CPU

• Gráficas de performance vCenter tenemos la capacidad de monitorear bastantes métricas directamente desde nuestro vCenter, podemos incluso crear nuestras propias gráficas relacionando los parámetros que nos interesen más:

• Capacity Planner es una herramienta de VMware que nos ofrece la capacidad de analizar el comportamiento de nuestra infraestructura, planeación y nos provee con reportes y recomendaciones de posibles escenarios de consolidación, Esta constituido por los siguientes elementos:

1. Data manager: esta aplicación se instala dentro de la infraestructura a monitorear, desde ella se configura el servicio de colección “Data Collector Service”, este servicio se encarga de descubrir equipos en la red local y guarda información de OS, hardware, aplicaciones en uso, métricas de consumo, etc. en una base de datos local para luego ser enviada a en ciertos periodos al “Data Analyzer”.
2. Data analyzer: este componente se encarga de analizar la información enviada por el servicio de Data collector comparándola con información contenida en una base de datos llamada “information wharehouse” donde se almacena toda la información de todos los “collectors” ,  identificando tendencias y comportamientos.
3. Information wharehouse: esta base de datos contiene información de todas los colectores de distintos capacity planners, con esta información logramos una comparación confiable y es posible así definir las recomendaciones que se nos darán. Ejemplo de un reporte:

Identificar métricas de performace que nos indiquen saturación de recursos

Aquí estaré en listando algunas de las métricas más comunes que podemos observar en esxtop para determinar que tenemos problemas:

• memoria: ejecutamos esxtop, ingresamos la tecla “m” después ingresamos la tecla “f” y nos aseguramos que los siguientes medidores están activados “j,k,p” por ultimo activamos la vista de VMs ingresando la tecla “V” (mayúscula):

SWR/s – en caso de tener este medidor distinto a “0″  nuestro host esta leyendo de swap (.vswp).

SWW/s - en caso de tener este medidor distinto a “0″ nuestro host esta escribiendo a swap (.vswp).

MCTLSZ – en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta reclamando memoria de las VMs utilizando el balloon driver.

ZIP/s - en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta comprimiendo memoria.

• CPU: ejecutamos esxtop y activamos la vista de VMs ingresando la tecla “V” (mayúscula) ya que la primera vista de esxtop es de CPU:

%RDY – porcentaje del tiempo de ejecución de un world (proceso de vm) en el cual se encuentra listo para ser enviado a un procesador físico para su ejecución pero este ultimo no esta disponible, por lo cual esta en una fila o “queue” de procesador, si el valor de %RDY es mayor  a “10″ tenemos problemas, generalmente debido a la cantidad de vCPUs que hemos entregado en el host.

%MLMTD - porcentaje del tiempo de ejecución de una vm en el cual no ha sido procesada debido a los limites de cpu configurados para la misma. En el caso que este sea distinto a “0″ debemos modificar el limite de dicha vm si es que tenemos problemas con ella.

%SWPWT - este indicador solo lo veremos activo cuando nuestro host este realizando swap de memoria , por este indicador nos muestra la cantidad de tiempo que la vm esta esperando al vmkernel para leer paginas del swap.

%CSTP – porcentaje del tiempo de ejecución de un world en cual el vmkernel lo pone en modo “co-deschedule”, para ser mas claros , en el caso que una vm tenga smp (symmetric multiprocessing) y el OS o la aplicación ejecutada dentro de dicho os no es capaz de llevar un manejo inteligente de los distintos cpus generando así mas carga en un vCPU que otro, generando así un des balance. Este valor nos ayuda para determinar que una aplicación u OS en especifico no manejan de manera correcta multiples cpus, también nos puede indicar afinidad de un vcpu.

%SYS – porcentaje de tiempo en el cual servicios o worlds del sistema se ha dedicado a dicha vm, generalmente en el caso de tener un valor mayor a “20″ nos indica que dicha vm tiene una alta cantidad de i/o.

• Disco:  ejecutamos esxtop, ingresamos la tecla “u” después ingresamos la tecla “f” y nos aseguramos que los siguientes medidores están activados “f,g,h,i,L” :

DAVG – (device avg) – latencia a nivel del adaptador (hba), latencia entre la hba y el almacenamiento. Si este valor es alto (davg ≥ 25) debemos verificar nuestro almacenamiento (cantidad de discos, problemas) e infraestructura para llegar a el (switches , hba’s ,etc).

KAVG – (kernel avg) – latencia a nivel del vmkernel, generalmente este valor debe de ser menor al valor de DAVG o “0″, en el caso que sea mayor es posible que tengamos encoladas peticiones a disco (QUED).

GAVG - (guest avg) – la suma de KAVG y DAVG nos da como resultado la latencia percibida por el guest o vm (GAVG),valores mayores a 25 nos indican problemas.

QUED – cantidad de comandos encolados a nivel del vmkernel, esto quiere decir que dichos comandos están esperando una oportunidad de entrar en el queue del almacenamiento. En el caso que se tenga un valor distinto a “0″ nos indica problemas con nuestro almacenamiento (queue depth).

ABRTS/s – cantidad de comandos abortados, esto sucede en el momento que después de cierta cantidad de tiempo (dependiendo el os), el almacenamiento  no ha sido capaz de responder a las peticiones de dicha vm, por lo cual el sistema operativo realiza dicho abort.

RESETS/s – reseteo del bus de scsi.

CONS/s – reservaciones scsi por segundo, en el caso de tener una cantidad alta de reservaciones (20+) se nos indica problemas con nuestro almacenamiento, las reservaciones scsi solo aplican para datastores VMFS. Estas ocurren en el momento ciertas operaciones requiere hacer un lock del metadata, por ej: encendido de vm, nueva vm, snapshot, vmotion de una vm, etc. Por estas se presentan comúnmente en el caso de tener una cantidad alta de VMs por cada datastore.

• Red: ejecutamos esxtop, ingresamos la tecla “n”:

 

%DRPTX – “dropped transmit packets” porcentaje de paquetes transmitidos que se han caido, esto representa problemas con la red fisica, alto consumo de la misma, problemas de hardware , etc. si el valor es distinto a “0″ , es algo que tenemos que verificar.

%DRPRX – “dropped received packets” porcentaje de paquetes recibidos que se han caido, aquí puede ser por cuestiones de recursos en el lado de la VM (no hay suficiente capacidad de procesamiento , aumentar recursos) o porque se esta teniendo un buffer overflow a nivel de rx rings. Aquí podemos incrementar el tamaño de dichos rings desde las propiedades de la nic (en el caso de vmxnet3 e intel e1000 con el driver de intel instalado):

 

Predecir en el momento que nuestros hosts requieran mas recursos de red y/o storage observando un ambiente existente

Básicamente aquí sera cuestión de hacer uso de las herramientas antes comentadas, como las gráficas de vCenter donde podemos ver los consumos y performance tanto de red como del almacenamiento.

Determinar cuando incrementar o disminuir los recursos dados a una VM basandonos en los consumos de la misma

Nuevamente, basándonos en las herramientas como son perfmon, gráficas de vCenter y esxtop, podemos rápidamente definir problemas de recursos. En el caso de perfmon en windows siempre utilicemos los counters que instalan las vmware tools debido a que ellos nos muestran los consumos verdaderos. Como ejemplo, podemos basarnos en esxtop para saber que una vm esta teniendo problemas en cuanto al cpu simplemente observando los valores de %RDY con lo cual podremos saber que se han dado una cantidad muy grande de vCPUs en el host lo cual representa un problema.

Interpretar métricas de performance en el vCenter

Aquí mas que nada es entender la información que se nos muestra, aquí les dejo un link a un whitepaper de VMware para entender mejor las gráficas que nos presenta el vcenter:

vSphere performance charts

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

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?

• Windows perfmon — http://www.windowsnetworking.com/articles_tutorials/Key-Performance-Monitor-Counters.html
• Esxtop — http://www.yellow-bricks.com/esxtop/
• vscsiStats    — http://hispavirt.wordpress.com/2010/07/05/paso-a-paso-vscsistats/ ,  http://communities.vmware.com/docs/DOC-10095
• herramientas de proveedores de almacenamiento
• VMware Capacity Planner

 

Revoluciones por minuto (RPM)	IOPS
SSD	6000
15 K	175
10 K	125
7200	75
5400	50