Script para reportear estado de la configuración de vSphere

Esto es mas como un trabajo en progreso, tengo meses tratando de darme el tiempo para generar un script que me ayude con la información necesaria para hacer la “memoria técnica” de una implementación, porque odio documentar, pero es parte del trabajo, así que…

Este script arroja la info de como está la configuración de red, datastores, VMs. Se que le hace falta info y pulir las salidas, pero lo voy a ir actualizando. Crea varios TXT que se van depositando en una carpeta que lleva como nombre el día que se ejecuta el script.

Está diseñado para que la salida sea como “lista”, pero se puede configurar para que sea una tabla. También con unas pequeñas modificaciones se pueden exportar como csv o como HTML.

La idea también es poder programar la ejecución del script para poder tener a la mano la información actualizada de la configuración de vSphere, y en caso de tener que hacer troubleshooting no tener que recurrir a esa “memoria técnica” en físico y que ya se encuentra desactualizada ¡¡porque se hizo hace años!!

Déjenme un comentario si lo quieren probar y tiene dudas de como echarlo a volar o ideas para mejorarlo 🙂

spotify:track:0k73nWaD6RPx2sHFEkGPcn

Advertisements

Throughput, IOPS y proporción Reads/Writes de discos virtuales.

Hora de trabajar un poco con Get-Stat, en esta ocasión para generar un script que nos muestre las estadísticas sobre la demanda de trafico en KBps, latencia e IOPS de los discos virtuales de nuestras VMs. Para ponerle un poco de peligro, le incluí ciertos parámetros para que sólo arroje datos de la operación durante “horario de oficina”, esto con el objetivo de excluír datos de periodos de tiempo donde sabemos que no hay usuarios activos o procesos ejecutándose.

La idea del script es que corra el fin de semana y muestre información de la demanda de recursos que tuvieron los discos virtuales durante la semana. Pero se puede editar para mostrar el periodo de tiempo que queramos.

Las columnas que arroja son el tráfico en KBps generado por los discos virtuales (throughput), latencia en milisegundos, cantidad de I/O por segundo y la proporción de Reads/Writes. Conocer la proporción de I/O de lectura y de escritura nos puede ayudar a diseñar y tomar mejores decisiones sobre el tipo de discos virtuales y especificaciones que debe tener el storage donde van a residir los discos de nuestras máquinas virtuales.

## Horario inicio de operaciones ##
$abre = get-date -hour 8 -minute 0 -second 0

## Horarios cierre de operaciones ##
$cierre = get-date -hour 16 -minute 0 -second 0

## Horario inicio de operaciones ##
$abre = get-date -hour 8 -minute 0 -second 0
## Horarios cierre de operaciones ##
$cierre = get-date -hour 16 -minute 0 -second 0

$IOarray = Get-VM $MisVMs | Where {$_.PowerState -eq "PoweredOn"} | select name,
@{N="IORead";E={[Math]::Round((($_ |Get-Stat -Stat virtualDisk.numberReadAveraged.average -Start $abre.adddays(-5) -finish $cierre.adddays(-1) |Measure-Object Value -Average).Average),2)}},
@{N="IOWrite";E={[Math]::Round((($_ |Get-Stat -Stat virtualDisk.numberWriteAveraged.average -Start $abre.adddays(-5) -finish $cierre.adddays(-1) |Measure-Object Value -Average).Average),2)}},
@{N="LatRead";E={[Math]::Round((($_ |Get-Stat -Stat virtualDisk.totalReadLatency.average -Start $abre.adddays(-5) -finish $cierre.adddays(-1) |Measure-Object Value -Average).Average),2)}},
@{N="LatWrite";E={[Math]::Round((($_ |Get-Stat -Stat virtualDisk.totalWriteLatency.average -Start $abre.adddays(-5) -finish $cierre.adddays(-1) |Measure-Object Value -Average).Average),2)}},
@{N="Throughput";E={[Math]::Round((($_ |Get-Stat -Stat disk.usage.average -Start $abre.adddays(-5) -finish $cierre.adddays(-1) |Measure-Object Value -Average).Average),2)}}

$IOarray = $IOarray | Select name,IORead,IOWrite,Throughput,
@{Name="IOPS";Expression={($_.IORead + $_.IOWrite)}},
@{Name="Latencia";Expression={($_.LatRead + $_.LatWrite)}}

$IOarray = $IOarray | Select name,IOPS,Latencia,Throughput,
@{Name="IORead";Expression={"{0:N0}" -f (($_.IORead/$_.IOPS) * 100)}},
@{Name="IOWrite";Expression={"{0:N0}" -f (($_.IOWrite/$_.IOPS) * 100)}}

$IOarray | FT @{Name="VM";Expression={$_.Name};a="left";width=15},
@{Name="Throughput(KBps)";Expression={$_.Throughput};a="right";width=10},
@{Name="Latencia (ms)";Expression={$_.Latencia};a="right";width=9},
@{Name="IOPS";Expression={$_.IOPS};a="right";width=10},
@{Name="Rd/Wr";Expression={($_.IORead + "/" + $_.IOWrite)};a="center";width=10} -wrap 

Debemos de ver algo así, que son las estadísticas generadas por nuestras VMs de Lunes a Viernes de la última semana, en un horario de 8hrs a 16hrs.

123

Si desean conocer con mas detalle como trabajar con estadísticas en vSphere utilizando PowerCLI, les recomiendo consultar la serie que Luc Dekens publicó en su Blog:

http://www.lucd.info/2009/12/30/powercli-vsphere-statistics-part-1-the-basics/
http://www.lucd.info/2010/01/05/powercli-vsphere-statistics-part-2-come-together/
http://www.lucd.info/2010/01/13/powercli-vsphere-statistics-part-3-instances/
http://www.lucd.info/2010/01/24/powercli-vsphere-statistics-part-4-grouping/
http://www.lucd.info/2011/07/08/powercli-vsphere-statistics-part-5-rollup-types/

¡Suerte!

spotify:track:6gnnB3kYtn02wNPbCxOk1t

Reporte de discos virtuales. Tipo, tamaño, formato y ruta.

Aproveché que me pidieron ayuda en una migración de storage para hacer un script que me arrojara la información de la configuración y ubicación de todos los discos virtuales.

Algo importante que hay que tener presente en cuanto a la configuración de los discos virtuales (VMDKs), y que podemos observar con este reporte, es que a los discos independiente no le podemos tomar snapshot, por lo tanto no pueden ser respaldados por ninguna herramienta que utilice los VMware Storage APIs for Data Protection (VADP). Y en general siempre deberíamos de saber como y donde están creados los discos de los servidores.

En el script va el nombre de la máquina virtual, nombre del disco, capacidad provisionada, información sobre el formato, si es de tipo RDM, datastore en que se encuentra y carpeta. Creo podría ser buena idea si queremos documentar el inventario o vamos a comenzar a trabajar en el datacenter.

Va…

$MyVMs = Get-VM
foreach($VM in $MyVMs){
Get-VM $VM |Get-HardDisk |
Format-Table @{Name="VM";Expression={$_.Parent};a="left"},
@{Name="Disco";Expression={$_.name};a="left"},
@{Name="Capacidad GB";Expression={"{0:N1}" -f $_.CapacityGB};a="right"},
@{Name="Formato";Expression={if ($_.StorageFormat -eq 'Thin') { "Thin" } else { "Thick" }};a="center"},
@{Name="RDM";Expression={if ($_.ExtensionData.backing.LunUuid -ne $null) { "Si" } else { "No" }};a="center"},
@{Name="Independiente";Expression={if ($_.Persistence -eq 'Persistent') { "No" } else { "Si" }};a="center"},
@{Name="Persistente";Expression={if ($_.Persistence -eq 'IndependentPersistent' -or 'Persistent') { "Si" } else { "No" }};a="center"},
@{Name="Datastore";Expression={$_.FileName.Split(']')[0].TrimStart('[')};a="center"},
@{Name="Folder/VMDK";Expression={$_.filename.Split(']')[1]};a="left"} -a
}

Y debemos de tener algo así por cada una de las VMs que queramos revisar…

Captura de pantalla 2015-02-20 a las 23.15.19

Espero les sea de utilidad…

spotify:track:2PMFI32xNoSXExAfFklKbb

¿Que VMs no se están respaldando? | Veeam + PowerCLI

Con este Script de PowerShell podemos crear una lista de las máquinas virtuales las cuales no se encuentran en ningún Job de respaldo o replicación, por lo tanto en riesgo de perder información en caso de corromperse el sistema operativo o eliminar accidentalmente información, algo mas común que fallas a nivel de hardware.

El primer paso es generar una tabla con la lista de las VMs efectivamente protegidas. Posteriormente generamos una tabla con las máquinas virtuales que nos interesa proteger, que pueden ser de todo nuestro Datacenter, un Cluster, un grupo de hosts, VMs con cierto TAG, etc, etc… A esta lista la comparamos contra la lista de VMs que efectivamente se están respaldando/replicando y obtenemos las cuales no se encuentran en ningún Job.

Va el script…

## Variables de columna "Estado" ##
$on = "Encendida"
$off = "Apagada"

## Genera una lista de VM en todos los Jobs de respaldo (backup) ##
$jobs = get-vbrjob | where {$_.jobtargettype -eq "backup"}
$protected = $jobs.getobjectsinjob()
$vmresp = $protected.name

## Crea la tabla con las VMs que no aparecen en la lista de VMs protegidas en alguno de los Jobs ##
Get-VM $MyVMs | where{$_.name -notin $vmresp} |
Format-Table @{Name="VM";E={$_.name}},
@{Name="Nombre DNS";E={$_.guest.hostname};a="center"},
@{Name="IP";E={$_.guest.ipaddress[0]};a="center"},
@{Name="Estado";E={ if ($_.guest.state -eq $running) { $on } else { $off }};a="center"} -a 

En este script agregé un poco mas de info a la tabla con la intención de contar con suficiente información que me permita identificar al servidor virtual rápidamente, le incluí el hostname de la VM, su IP (requiere tener instaladas las VMware Tools) y su power state, pero le puedes agregar todos estos campos…

Captura de pantalla 2015-02-18 a las 23.23.57

La salida con la lista de las VMs sin protección es algo así…

Captura de pantalla 2015-02-18 a las 23.36.46

Espero les sea de utilidad.

spotify:track:40PZjzPaevtxWSReEG6RQ1

Identificar status de VMware Tools con PowerCLI

Instalar las VMware Tools en las máquinas virtuales es de la mayor importancia, instala drivers y scripts dentro de los sistemas operativos que permiten la utilización de harware virtual y realizar ciertas tareas administrativas remotamente, como apagar la VM como si se hiciera desde el sistema operativo.

Algo de documentación de VMware Tools:
https://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.vm_admin.doc/GUID-151025AE-6641-428B-9818-5E06916543F3.html

Este script de PowerCLI permite generar un reporte que ayuda a identificar si las máquinas virtuales de nuestro vCenter/Datacenter/Cluster/Folder/Pool tienen instaladas las Tools, están desactualizadas o nunca se han instalado.

Va el script:

## Variables para "traducir" los valores de Status de los Tools que arroja PowerCLI ##
$current = "guestToolsCurrent"
$unmanaged = "guestToolsUnmanaged"
$needsupgrade = "guestToolsNeedUpgrade"
$ok = "Ok"
$noact = "No Actualizado"
$noinstall = "No Instalado"

Get-VM | Where {$_.PowerState -eq "PoweredOn"} | 
FT @{Name="VM Name";Expression={$_.name};a="left"},
@{Name="VMware Tools";E={ if (($_.guest.ExtensionData.Toolsversionstatus -eq $current) -or ($_.guest.ExtensionData.Toolsversionstatus -eq $unmanaged)) { $ok } else { 
if ($_.guest.ExtensionData.Toolsversionstatus -eq $needsupgrade) { $noact } else { $noinstall }}};a="center"} -a

El script sólo arroja un par de columnas, el nombre de la VM y el status de las Tools.

Espero les sea de utilidad.

spotify:track:2sQwrhVWXpZHPIF6YQbUvT

Reporte Snapshots

En los últimos días me ha tocado apoyar en un par de casos de “monster Snapshots”, en un caso en particular el disco del snapshot consumió la totalidad del datastore y la máquina virtual no podía encender, afortunadamente la máquina virtual estaba configurada con 24GB de RAM por lo que bastó reservarle toda su memoria para liberar espacio suficiente y así se pudo encender la VM. Tuvimos suerte.

¿Pero que es un Snapshot?
Understanding virtual machine snapshots in VMware ESXi and ESX (1015180)

En corto, un snapshot es un disco “delta” que se crea cuando deseamos mantener un punto de restauración de una máquina virtual, NO ES BACKUP. Mientras exista dicho archivo “delta” todas las operaciones de I/O que tenga la VM se van a redirigir hacia el delta, dejando el disco original VMDK en un estado de “solo lectura”. Dicho archivo VMDK “delta” puede crecer hasta el tamaño provisionado de la VMDK original. He ahí la importancia de mantener los snapshot a raya.

La teoría dice que los snapshot deben de durar abiertos la menor cantidad de tiempo, sin embargo muchas veces se olvidan, o lo que he visto mas comunmente, las herramientas de respaldo dejan snapshots sin cerrar y si no los estamos monitoreando pueden tener graves consecuencias para nuestras VMs.

Hay mucha información en línea y vmware ha publicando documentación al respecto, sin embargo, sigue siendo muy común los casos de problemas con los mismos. No es la intención hacer un post de la teoría, mas bien quiero compartir un script de PowerCLI que hice para reportar snapshots abiertos, tamaño y cuanto tiempo llevan creados, con la idea de no tener que llegar al punto donde ya tenemos el problema encima.

Primero, el KB de mejores prácticas:

Best practices for virtual machine snapshots in the VMware environment (1025279)

Script:

$VMs = Get-Cluster -Name $MiCluster | Get-VM
foreach ($VM in $VMs) {
Get-Snapshot -VM $VM |FT VM,
@{Name="Tamaño GB";Expression={"{0:N1}" -f $_.SizeGB};a="center"},
@{Name="Fecha";Expression={"{0:dd-MMM-yyyy}" -f $_.Created};a="center"},
@{Name="Dias";Expression={"{0:N0}" -f ((get-date) - $_.Created).days};a="center"}, 
@{Name="Descripcion";Expression={$_.Description};a="left"} -a
}

Así se ve la salida del script y aprovecho para compartirles un ejemplo.

vm_1

Lo hice para que me arrojara la información de un cluster, pero puede ser editado para que arroje información de las VMs de todo el vCenter, Datacenter, Folder, Resource Pool, vApp, etc.. Con Task Scheduler se puede programar y que nos llegue el reporte por correo.

Es un pequeño script pero puede darnos información muy valiosa que nos puede ayudar a monitorear y así poder tomar medidas antes de que tengamos datastores completamente llenos o, en el peor de los casos, corrupción de discos de máquinas virtuales.

Espero les sea de utilidad.

spotify:track:07YhAU4StAFzsWv2gMCCPb

Exportar syslog de ESXi 5.x a Splunk Storm

Recientemente un cliente me pidió ayuda para exportar los logs que genera sus ESXi a algún servicio en la nube. Le propuse Splunk Storm, es buen servicio y además gratuito. Está muy limitado en espacio, 20GB, no te permite generar alarmas, entre algunas otras herramientas, pero como la idea es tener fuera del datacenter los logs en caso de que algo grave suceda y poder analizarlo, Splunk Storm resulto una muy buena opción.   Lo primero fue abrir la cuenta en SplunkStorm.com, una vez generada se crea un “Proyecto” …

add-proyect

Luego lo nombramos …

name-proyect

Seleccionamos la opción de configuración automática y Splunk nos asigna direcciones y puerto a donde apuntar los logs de los ESXi.

puertos-enviar-datos2

Ahora lo que hay que hacer es hacer la configuración en los ESXi y crear la regla de firewall con el puerto específico que nos entrega Splunk. Para esto se necesita crear un archivo XML y guardarlo en la ruta /etc/vmware/firewall/. Yo lo nombré “service1.xml” y con éste se crea la regla de firewall llamada “syslog-Splunk”

<!-- Firewall configuration information -->
<ConfigRoot>

  <!-- Known and blessed services -->

  <service id="0101">
    <id>syslog-Splunk</id>
    <rule id='0000'>
      <direction>outbound</direction>
      <protocol>udp</protocol>
      <porttype>dst</porttype>
      <port>21222</port>
    </rule>
    <enabled>false</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

Ahora hay que enviarlo al host ESXi, yo utilicé SCP y lo envié a la carpeta /etc/vmware/firewall/ en el host ESXi

guardar-XML

Ahora nos conectamos via SSH al host y revisamos que haya sido reconocido como una nueva regla del firewall

esxcli network firewall refresh
esxcli network firewall ruleset list

Ahora ya podemos ver listada la regla …

nueva-rule

..y también ya la podemos ver en el web client …

rule-webclient

Ahora utilizando un poco de PowerCLI apuntamos los logs del ESXi hacia el servicio de Splunk y habilitamos la excepción del firewall

Get-VMHost $interpol | Set-VMHostAdvancedConfiguration -Name Syslog.global.logHost -Value udp-xxxx-xxxx.data.splunkstorm.com
Get-VMHost $interpol | Set-VMHostSysLogServer -SysLogServer udp-xxxx-xxxx.data.splunkstorm.com -SysLogServerPort 21222
Get-VMHost $interpol | Get-VMHostFirewallException | where {$_.Name.StartsWith('syslog-Splunk')} | Set-VMHostFirewallException -Enabled $true

Volvemos a nuestra sesión de SSH y reiniciamos el servicio de syslog

esxcli system syslog reload

Ahora si, en unos momentos mas se registra el host en Splunk y comienza a recibir los logs …

nuevo-syslog-splunk2 listo2

 

Como podrán ver es un proceso sencillo y que permite contar con información para analisis detallado en caso de que algo salga mal en el centro de datos.

Hay muchas herramientas que se pueden utilizar como servidores de logs, puede ser cualquiera, ya que lo importante es tener esa información disponible en el momento que se requiera.

Fuentes:

http://www.virtuallyghetto.com/2011/07/how-to-create-custom-firewall-rules-in.html

http://kb.vmware.com/kb/2003322