My quick notes for our virtual world …

Los switches distribuidos han sido uno de los más importantes cambios introducidos en vSphere desde la versión 4. Facilitan no solo el despliegue de nuevos hypervisores , tambiéns aportan un único punto de administración que facilita su gestión. Gracias a esta nueva funcionalidad podemos hacer uso del fabuloso NIOC (Network IO Control) que además nos garantiza una buena gestión del ancho de banda en un entorno donde usamos adaptadores convergentes de 10GbE o más, concrétamente en momentos de alta demanda como son las tareas de vMotion.

AWESOME

Networking is awesoooooome . . .

Os podéis imaginar cómo sería poder ver los paquetes de nuestras máquinas virtuales circulando por la red, entrando y saliendo de nuestros Uplinks como si fueran piezas de LEGO cantando aquello de “Todo es fabuloso”. Porque en realidad, lo es. Hasta que tu vCenter decide dejar de cantar en armonía y dar el salto a nuestra realidad con un tremendo casque.

Puede ser algo habitual, como una parada de servicio, una falta de espacio en disco, o simplemente lo ha reiniciado el HA por un error inesperado en el ESXi dónde estaba corriendo y la cosa tarde un poco más en arrancar de lo que esperábamos. O desafortunadamente nuestra BBDD se ha ido al garete. El caso es que sabemos que vamos a tardar más tiempo del esperado en traer nuestro vCenter de vuelta.

Normalmente no tenemos demasiada presión porque nuestras máquinas van a estar funcionando y dando servicio, manteniéndose totalmente ajenas al apagado de nuestro vCenter. El asunto se nos puede complicar cuando, por cumplir ciertos SLA,  nos demandan realizar una migración de una VM a otro ESX dentro del clúster en ese preciso momento. Suena raro, pero lamentablemente, en ocasiones existen pequeñas diferencias a nivel de networking que hacen que una VM de serios problemas en uno de los DC’s cuando se trata de un Cluster extendido. En  un reciente caso, la máquina en cuestión perdía toda conectividad resultando ser totalmente inaccesible. Os imagináis que esa VM sea la BBDD del vCenter ?. Al conocer las virtudes y defectos de nuestro entorno, sabemos que si la VM la pasamos a otro Host ubicado en el DC contrario recuperaríamos nuestro mundo fabuloso de nuevo, y eso es lo que me ha tocado hacer.

Recordáis el “No Martini, no party !”?. Pues en nuestro caso aplica a “No hay vCenter, no hay vMotion”. Y como quiern no quiere la cosa van pasando los minutos, los indicadores ya marcan un DEFCON 2 y algunos alrededor nuestro comienzan a sufrir ciertas contracciones por lo que viene siendo la bajante principal. Todo un indicio claro de que ésto empieza a ser serio, y nos va a tocar improvisar para traer de vuelta ese vCenter.

Tiempo atrás, el vCenter era una herramienta exclusiva que solamente utilizábamos los responsables de la plataforma de virtualización, en realidad, en España, hace 4 aLños nadie ajeno a virtualización conocía el vCenter Server mas allá de una máquina Windows que era crítica para nosotros y que usaba una Base de Datos. Si se nos caía el servicio, nadie se enteraba. Eso de instalar un programa que, tras escribir un nombre de máquina, usuario y password, te abría un entorno gráfico con Hosts y Virtual Machines, te permitía acceder a las consolas de cada una de ellas, montar ficheros ISO, añadir y quitar discos, adaptadores de red…. todo eso, era algo desconocido y misteriorp  que solamente conocíamos nosotros. No exagero si os digo que hablar de vCenter (“viCenter“) en algunos proyectos de hace años, para otros equipos de trabajo era como quien tenía un primo llamado Vicente. Hoy en día vCenter Server es una herramienta ampliamente conocida y utilizada por el resto de equipos de trabajo. Backup, Monitorización, Storage, etc. Por tanto,  la criticidad de “Éste, nuestro servicio” se ha incrementado con el paso de los años.

No vamos a realizar un vMotion, eso está claro, pero si podemos aprovechar la falta de servicio para apagar la máquina en cuestión – en éste caso la BBDD del vCenter- y que eso nos de opción a registrar la VM en otro ESX desde su Datastore. Es aquí donde quiero llegar con este post, hay que tener siempre en cuenta que trabajar con los vDS nos facilita la vida, pero toda la información relativa a su configuración y todos sus PortGroups residen en la BBDD del vCenter y están accesibles mientras lo esté el propio vCenter server. Por tanto antes de hacer esta operación hay que recordar que cuando vayamos a registrar la misma VM en otro ESX, mediante nuestro vSphere Client, todas las VLANS que actualmente residen en el vDS no estarán disponibles y nos quedaremos con el culete al aire.

panic-o

Hemos perdido el vCenter !!!!

Ésta situación es algo confusa, pero real. Y es el comportamiento normal cuando se crean los Port Groups por defecto en un vDS, es como funciona la asignación por defecto y que todos usamos, es el Static Binding. Con ésta opción por defecto, cuando conectamos una VM a un PortGroup, se asigna y se reserva un nuevo puerto inmediatamente. Por supuesto garantiza la conectividad en todo momento, incluso si el vCenter está “apagado o fuera de cobertura”.  El puerto se desconecta solo al quitar la VM de ese PortGroup.

También existe un segundo modo, que prácticamente está en desuso, llamado Dynamic Binding. En este caso el puerto se asigna y reserva cuando la máquina se enciende – y además tiene conectada la NIC. Del mismo modo, el puerto se elimina cuando la VM se apaga o se desconecta su adaptador de red desde el vSphere client. Obviamente éstas VM solo pueden encenderse y apagarse desde el vCenter.

El modo más avanzado corresponde al Ephemeral Binding. En este modo el puerto también se asigna y crea al encender la VM teniendo el adaptador de red en estado “conectado” pero a diferencia del Dynamic, es el Host el que realiza esta asignación, pudiendo actuar de forma independiente del vCenter Server. Ésta sería nuestra opción adecuada para un caso como el que vengo planteando. Por supuesto, una vez apagada la VM, el puerto se borra.

 

EPH1

EPH2

Vmware recomienda usar este último modo de creación de puertos solo para propósitos de recuperación. Sinceramente no he apreciado en prácticamente ningún entorno por los que he estado la selección de éste tipo de binding. En el escenario que estoy planteando, con el Static Binding, tenemos que seguir improvisando.

De modo que nos encontramos ahora mismo con la VM que contiene nuestra BBDD registrada en el ESX que está en el DC correcto para garantizar su funcionamiento, está apagada, y no podemos seleccionar la VLAN correcta porque pertenece a un PortGroup creado por defecto en un Switch Distribuido y el vCenter está KO.

En esta situación necesitamos sacarnos un PortGroup para poder Taggear la VLAN correspondiente, y lamentablemente solo podemos hacerlo en un vSS (virtual Standard Switch) en nuestro ESX. Podemos crear el vSS, pero nuestros vmnics están todos ya asignados en nuestra , ya madura, infraestructura.

Una de las maravillosas funcionalidades de una infrastructura vSphere que, por supuesto siga las buenas prácticas, es la facilidad de crear tolerancia a fallos, en nuestro caso la que nos vendría de maravilla sería aprovecharnos de la redundancia de los adaptadores de red y disponer de, al menos, dos Uplinks totalmente funcionales en nuestro vDS.

Con esta simple y mínimamente exigida configuración, podríamos ‘romper’ esa redundacia sacándo un vmnic del vDS y añadírselo a nuestro recien creado vSS. Ahora, solamente necesitaríamos crear un PortGroup con la VLAN de nuestra BBDD y posteriormente seleccionar esta nueva VLAN para que la use nuestra ansiada VM editando sus propiedades.

Recapitulando. En este punto tendríamos nuestra máquina de BBDD del vCenter registrada en el ESX adecuado dónde tenemos garantizada su conectividad, además está conectada a un vSS que solo existe en ese host,  usando uno de los vmnics que formaban NLB en el vDS, y finalmente conectada a un PortGroup que tiene la VLAN correctamente taggeada. Tenemos todos los ingredientes para el éxito. Así pues, tras encendérla, nuestros servicios de vCenter serán capaces, y de hecho lo fueron, de poder conectar con la BBDD y arrancar de forma satisfactoria. Nuestro vCenter volvío a la vida.

Alive

Vicente Viveee…!!

Today I’ve been asked by an old colleague about a quick way of listing the disk latency for all virtual machines in a vCenter. Normally this is also held by the statistics level set on vCenter Settings so, I’d check at least you chose a Level 2.
At this point the following command will show the average value for the Maximum Disk Latency for every Virtual Machine during the last week.

Get-VM | ? {$_.PowerState -eq "PoweredOn"} | Select Name, @{n="AVG Max Latency (ms)";e={(get-stat -Entity $_ -Stat Disk.MaxTotalLatency.Latest -Start (Get-Date).AddDays(-7) | Measure Value -Average ).Average }}

Still can even be more descriptive when adding a second column with the Maximum value reached, so we could identify some peaks:

Get-VM | ? {$_.PowerState -eq "PoweredOn"} | Select Name, @{n="AVG Max Latency (ms)";e={(get-stat -Entity $_ -Stat Disk.MaxTotalLatency.Latest -Start (Get-Date).AddDays(-7) | Measure Value -Average ).Average }},@{n="Max Latency (ms)";e={(get-stat -Entity $_ -Stat Disk.MaxTotalLatency.Latest -Start (Get-Date).AddDays(-7) | Measure Value -Maximum ).Maximum }}

Try it. If your’re still dealing with vSphere older versions you will be impressed after checking the ESX Uptime. I’ve seen ESX running for more than 5 years, meaning that no reboot was made since then, so no firmware updates nor hardware replacement. Scary.

So, a quick way to identify those inmortal ESX is as follows:

Get-VmHost | Select Name, @{n="Booted Date";e={($_ | Get-View).RunTime.BootTime}}

CPU Ready quick table

It’s been a long time since last post, but I want to share a simple table to calculate the percentage of CPU Ready a Virtual Machine has based on the vCenter Performance tab graph.

Bear in mind the Real Time view is updated every 20 seconds but the rest of periods are updated using a different interval like described:

  • Realtime: 20 seconds
  • Past Day: 5 minutes (300 seconds)
  • Past Week: 30 minutes (1800 seconds)
  • Past Month: 2 hours (7200 seconds)
  • Past Year: 1 day (86400 seconds)

So do not forget this: Is not the same having 4000 ms Average value for CPU Ready Time on a Real-Time view than having the same value on the Past Week view.

In order to help on this, I’ll create a simple excel table which will show the amount of CPU Ready percentage for every period knowing the initial Average CPU in ms and the number of vCPU the Virtual Machine has.

CR

Download this CPUReady Values to keep it.

 

Recently I faced the horror of dealing with a very high overcommitted cluster and needed to assess the amount of memory usage quickly. Get-View PowerCli cmdlet stores the deepest secret of any virtual machine. This time I’m searching for those virtual machines that are swapping. Well it turns out the answer is called SwappedMemory and it goes – in a non-elegant but quick mode – like that:

$Result = Get-cluster <ClusterName> | Get-Vm | % { $D= $_ | Get-View | Select Summary; $VmName=$_.Name;$D.Summary.QuickStats | Select @{n="VM";e={$VmName}},SwappedMemory};$result | % {$X+= $_.SwappedMemory}; $X

If you get something greater than 1 then “Winter is coming…” for you🙂 . The greater the number is, the coldest winter you’ll have. Run the following command so you can identify which VMs are affected by Swapping / Ballooned:

Get-Cluster <ClusterName> | Get-Vm | % { $D= $_ | Get-View | Select Summary; $VmName=$_.Name;$D.Summary.QuickStats | Select @{n="VM";e={$VmName}},BalloonedMemory, swappedmemory}

One possible cause of memory ballooning or swapping could be due to some memory limits. Check it on your VM settings or you can disable Memory Limits on several VMs using the following command:

Get-Cluster <ClusterName> | Get-Vm | Get-VMResourceConfiguration | ? {$_.;MemLimitMB -gt 0} | % { get-vm $_.vm | Get-VMResourceConfiguration | Set-VMResourceConfiguration -MemLimitMB $null}

Check VMware tools on the VMs and keep them updated so memctl is working as it should.

Sometimes you might find that VMs are still swapping but the Host is in a High State and memory is not overcommited, check what Duncan says about it, I think some old ESXi versions are not able to reset the swapping ram after a real lack of memory specially if ballooning / swapped amount of MB is equal to the current Host free memory.

 

No doubt this new feature will get my attention. Standardizing and documenting new Software-Defined Datacenter solutions is one of the most pending tasks on every place I’ve been.

Looks like VMware is going to build a detailed set of documentation for specific SDDC deployment architectures and scenarios.Basically now there are two of them, do not miss the chance and have a look at them : Foundation and Single-Region IT Automation Cloud.

Let’s follow this in detail here.

VMworld 2015

VMworld offers attendees informative Breakout Sessions and Hands-on Lab training, plus access to a wealth of technology partners to discuss virtualization best practices, building a private cloud, leveraging the public cloud, managing desktops as a service, virtualizing enterprise applications and more.
VMworld 2015 US:

Conference is August 30-September 3, 2015
Registration opened May 5th
Content Catalog is live June 9th
Schedule Builder is live July 21


VMworld 2015 Europe

Conference is October 12-15, 2015
Registration opens June 9th
Contnet Catalog is live June 23rd
Schedule Builder is live August 18th

Click for More info .