Welcome to Delicate template
Header
Just another WordPress site
Header

Relog.exe  es una herramienta la cual nos permite trabajar sobre los ficheros .blg de contadores obtenidos mediante la heramienta de perfmon. Relog.exe crea nuevos logs de performance en base a un contador inicial pudiendo realizar varias tareas sobre el mismo, como acortar y/o convertir.

Podemos obtener la sintaxis completa de esta herramienta ejecutando desde CMD el siguiente comando:

rerelog.exe -?

Si se ejecuta obtenemos la siguiente salida:

Parameters: 

<filename [filename …]>     Performance file to relog.

Options:

  -?                            Displays context sensitive help.

  -a                            Append output to the existing binary file.

  -c <path [path …]>          Counters to filter from the input log.

   -cf <filename>                File listing performance counters to filter from the input log. Default is all counters in the original log file.

  -f <CSV|TSV|BIN|SQL>          Output file format.

  -t <value>                    Only write every nth record into the output file. Default is to write every record.

  -o                            Output file path or SQL database.

  -b <dd/MM/yyyy H:mm:ss>       Begin time for the first record to write into the output file.

  -e <dd/MM/yyyy H:mm:ss>       End time for the last record to write into the output file.

  -config <filename>            Settings file containing command options.

  -q                            List performance counters in the input file.

  -y                            Answer yes to all questions without prompting.

 Veamos algunos ejemplos sobre lo que podemos hacer:

Convertir un Log: Convertir un Log nos permitirá ,por ejemplo, generar un CSV desde el blg original. Aunque el uso de blg es amigable para los administradores, puede ser necesario en muchas ocasiones trabajar en CSV sobre dichos ficheros.  Este proceso es muy sencillo, simplemente ejecutamos:

Relog.exe FicheroLog.blg –f CSV –o NuevoNombre.CSV

Filtrar contadores determinados: Esta funcion es muy útil cuando se han sacado muchos contadores y solo queremos obtener y trabajar sobre un contador especifico. Imaginemos que queremos trabajar unicamente sobre los contadores de % tiempo de procesador. Podríamos generar un nuevo .blg con la siguiente linea de ejecución:

Relog FicheroLog.blg –c “\Processor(*)\%Processor Time” –o NuevoFichero_filtrado.blg

Este filtrado tambien podemos realizar-lo apoyados sobre un fichero txt con una lista de contadores concreta. El formato debe ser el siguiente:

\Memory\Pages/sec

\Hyper-V Hypervisor Virtual Processor(_Total)\% Guest Run Time

\Server\Logon Total

\PhysicalDisk(_Total)\% Idle Time

Un contador por cada linea. Y podemos ejecutar-lo de la siguiente forma:

Relog.exe FicheroLog.blg –cf ficheroContadores.txt –o NuevoFichero.blg

Filtrar un contador por tiempo: Este es el tipo de filtrado que mas utilizo. A menudo los clientes me envian contadores sin paradas durante varios dias. Ello implica un contador con poco detalle que abarca varios dias y con el que es sumamente dificil trabajar. Para estos casos, relog es la mejor herramienta, la cual nos permite seleccionar un periodo de tiempo del contador y generar un nuevo contador mas pequeño con la información necesaria. Para ello ejecutaremos:

Relog.exe fichero.blg –b “DD/MM/YYY HH:MM:SS” –e “DD/MM/YYY HH:MM:SS” –o nuevoFichero.blg

 Input

—————-

File(s):

     .\Performance Counter.blg (Binary)

Begin:    9/1/2014 13:11:24

End:      10/1/2014 13:11:22

Samples:  8641

100.00%

—————-

Output

—————-

File:     PERFORMANCE_DAY1.blg

Begin:    9/1/2014 13:11:24

End:      9/1/2014 20:11:00

Samples:  2518

Consultar los contadores dentro de un blg. Relog nos permite obtener una lista de los contadores incluidos dentro de un fichero de perfomance sin la necesedida de abrir-lo. Ademas al sacar una lista, es facil exportar-la a un fichero para poder indicar-le al próximo cliente que contadores debe sacar ;). Para ello ejecutaremos:

Relog.exe –q fichero.blg

Filtar Registros según valor: Adicionalmente, sobre todo el procesamiento, podemos incluir el modificador –t<valor> el cual nos permite filtrar el contador BLG sobre cada x registro. Es decir, si disponemos de un contador que cada 10 sec. tenemos un registro del contador obtenido cada 10 sec.

Registro1 -> 10segundos despues -> Registro2 -> 10segundos despues -> Registro3 -> 10segundos despues -> Nregistro (…)

Este parametro (-t) nos permite escoger cada cuantos registros incluimos en el nuevo fichero. Es decir, si ponemos –t 2 diremos que obtenga unicamente 1 registro cada 2. Así pues obtendriamos:

Registro1(incluido) – Registro2(descartado)  – Registro3(incluido).

De este modo simplificamos y reducimos el fichero blg para su uso, aunque tambien reducimos el detalle global del contador.

Tips: Ten en cuenta que todos los tipos de filtrajes pueden ser mezclados, asi pues podemos acortar en el tiempo un blg al mismo tiempo que seleccionamos contadores especificos y lo convertimos en CSV. ¿Fácil no?

Resources: http://technet.microsoft.com/en-us/library/bb490958.aspx

XenServer permite el “tunning” del Dom0 de cara a mejorar la escalabilidad del entorno cuando es necesario, poniendo de este modo el rendimiento de nuestro hypervisor al máximo.

Cabe indicar, que no siempre estas recomendaciones son aplicables y que habrá que ver cada entorno, para saber si es o no es aplicable. De echo, normalmente estas recomendaciones no serán aplicables ya que la configuración por defecto de XenServer es en la mayoría de casos suficiente.

Pero si tenéis problemas de rendimiento a pesar de tener suficiente CPU y memoria, ello puede estar ocasionado por un cuello de botella es nuestro dominio de control y los siguientes ajustes podrían solventar en algunos casos dicha perdida de rendimiento.

Cuando un host XenServer arranca, el hypervisor carga una pequeña VM invisible para los usuarios; incluso para los administradores en algunos casos. Esta VM es conocida como Dominio de Control o Dom0.  Dom0 se ejecuta en la pila de gestión y proporciona servicios básicos al resto de las VMs, como el acceso físico a los dispositivos.

No existe un número determinado de VMs en las cuales podamos asegurar que la vcpu0 de dom0 se colapse, ocasionando un cuello de botella. Dependerá también en gran medida del tipo de VMs que estemos rodando, pudiendo ser necesario realizar cambios en dom0 a partir de 60-70 vms o no siendo necesario realizar incluso con 100 vms rodando. Por ello, es importante no tener una referencia numérica en este aspecto, y revisar los contadores y el estado de nuestro Dom0 para asegurar un correcto tunning. En el 99% de los casos, no serán necesarias modificaciones en Dom0.

Si durante el uso de nuestro host, observamos problemas de rendimiento, y mediante xentop comprobamos un uso excesivo (llegando al 100% constante) de recursos, se recomienda, en estos casos, el tuning de dom0, ampliando memoria o asignando vcpus, según corresponda.

Ya hemos hablado de ampliar el número de vcpus de nuestro dominio de control, pero también la memoria se puede ver afectada en estos problemas de cuello de botella. Sobretodo en entornos con mas de 50 Vms corriendo por host. En estos, se recomienda la ampliación de memoria hasta 2’96GiB, y decimos 2’96GB y no 4 ya que mas de 2’96GiB queda fuera de soporte, además de ser arriesgado.

Si quieres saber mas, continua leyendo aquí

Hace poco conocí  “GeekTool”, una herramienta que viene a ser un conky para OSX.

De echo, hacia tiempo que buscaba una herramienta de este tipo, pues algo que me gustaba de mis escritorios Linux era poder monitorizar mi maquina entre otras tareas y mostrar dicha información en tiempo real en mi escritorio, sin necesidad de utilizar consolas adicionales.

Así pues, descubierto este, nos pusimos manos a la obra, instalamos GeekTool y utilizamos unos .glets desarrollados por la comunidad y realizamos modificaciones en otros para disponer de un wallpaper con vida que nos muestra datos interesantes en pantalla.

Inicialmente, incluí un bonito reloj, un resumen de uso del sistema y el top de procesos por consumo de memoria/cpu en mi sistema OSX.

Reloj

Si buscáis en google por GeekTool, veréis escritorios que son autenticas maravillas. De echo, este no es el fondo del artículo.

Posteriormente, añadí  un lector RSS para detectar nuevos artículos de algunos de mis blogs, y de aquí y haciendo pruebas empezarón a surgir dudas… ¿podre utilizar esto para monitorizar mis hypervisores y mostrar la inforamción en pantalla?

Rss

Como algunos saben, tengo debilidad por XenServer, así que mi objetivo de monitorización, en cuanto a hypervisor, era claro; aunque con un poco de mañana, el resto de hypervisores seguro que tambien encajarán aquí.

Monitorizando XenServer vía GeekTool

Aquí es dónde viene lo divertido. Echas las primeras pruebas, el objetivo era poder ver datos de mi XenServer  que utilizo como laboratorio en casa.

Y como podemos hacer esto… … … … tras unos minutos de estruje neuronal…. ¿Por qué no usar SSH? Probemos.

Realizar un NAT en nuestro router para redirigir el tráfico SSH de la IP Publicahacia mi IP interna de XenServer.

Por supuesto, es importante, probar que funciona correctamente el acceso 😉

ALARM:  Es momento de solucionar un posible dolor de cabeza.

Sabemos que para abrir una conexión SSH, deberemos realizar:

# ssh root@IP_Publica

Ello nos solicitara la contraseña. Y este punto puede suponer un problema. Seria interesante, que nuestro host confie en nuestra máquina y posiblite la conexión con validación por key para conectar y ejecutar tareas sin necesidad de solicitar contraseña (y sin que nos obligue a incluirla en nuestros scripts).

La solución …, si no recuerdo mal, algo escribí por aquí, que podría ayudarnos…

http://blogs.itpro.es/cristiansan/2011/10/01/ssh-key-maclinux-to-xenserver-without-pass/

Solventando el problema de SSH, es necesario crear el script que queremos. Vamos a empezar con una prueba sencilla. Muy muy sencilla, no voy a explicar como funciona GeekTool (hay fabulosos manuales en internet), ni a realizar complejos scrips de monitorización para nuestro host (probablemente en futuros artículos).

El foco de este, es simplemente, enseñar que podemos hacer con un poco de imaginación…

Vamos a empezar por un comando simple: Listar las VMs y su estado y situar-las en nuestro Wallpaper.

Creando el GLET

Para mostrar un listado de VM en nuestro host de XenServer, podemos ejecutar:

# xe vm-list

Podriamos filtrar un poco mas, y mostrar solo las que esten ejecución..

# xe vm-list power-state=running

 Pero el primero nos vale…

Para ello, necesitaramos saber como ejecutar comandos de forma remota en XenServer. Utilizando SSH y la opción de autovalidación comentada anteriormente, es una opción.

# ssh root@IP_SERVER “Commands”

Una vez tengamos la línea de comando a ejecutar, podemos guardarla en un script o ejecutar-la directamente desde SSH. Mi script básico para GeekTool, es el siguiente:

udate=date +"%D %H:%M"
echo Last Update:  ${udate};
echo #
ssh root@IP_PUBLICA «xe vm-list params=name-label,power-state»

La priemra linea guarda en la variable $udate, la fecha en formato MM\DD\AA HH:MM.

Posteriormente, ecribimos la fecha en patalla precedido del texto «Last Update:» (Ello nos servira para saber cuando fue actualizada la información del host por última vez.)

Finalmente, dejamos un espació en blanco, y realizamos la conexión via SSH con nuestro host, donde ejecutamos el comando para listar las VMs de nuestro host y seleccionamos unicamente los campos de Name-Label y Estado (Power-State) para mostrar en pantalla.

Verificamos el resultado desde nuestro CLI (ejecutamos el comando desde el terminal de OSX para verificar su correcta aplicación) y echo esto, utilizamos GeekTool para configurar nuestro nuevo script de Monitorización.

Se incluye el codigo en nuestro «shell» de GeekTool y especificamos als opciones tales como fuente, color, fondo y tiempo de refresco del script (en mi caso lo estableci cada 30 min).

Echo, esto solo queda vestir-lo un poco para que quede wapo. Aquí ya entra la vena artística de cada uno… a mi no se me dan muy bien estas cosas.

Como ejemplo, os dejo una captura de esta primera versión de mi escritorio dónde podemos ver…

Fecha; Logo de CTXDOM, Logo de Apple con estado de nuestro OSX, Logo de monitorización con el top process de mi equipo, el RSS de Citrix Blogs y los logos del panda de Xen con la información mostrada por el Script escrito anteriormente y mi dirección IP publica.

Modif

¿Mola eh? … ahora os toca a vosotros… Que la fuerza os acompañe!

Resource

Página oficial GeekTool: http://projects.tynsoe.org/en/geektool/

 

Algunas veces existen quejas referentes al performance de red en entornos virtuales y su mal performance de red en relación a una maquina física. Articulos independientes muestran que el performance con xenserver, vmware e hyper-v es parecido al físico y ya no es una excusa para no virtualizar. Eso si, para ello, es necesario realizar ciertas acciones y aplicar todas las buenas practicas posibles en cada uno de los entornos siempre que sea posible.

Una de las mejoras realizables para mejorar el performance de red, es el relacionado con los paramétros de checksum y off-load (TCP Segmentation offload, Generic Segmentation offload y UDP Fragmentation Offload – Todas ellas explicadas en los recursos adicionales al final del artículo).

Para su configuración, podemos hacer uso de la herramienta ethtool-K, el cual nos permitirá realizar cambios sobre las tarjetas, sin que los cambios sean “permanentes”. Estos serán reseteados tras un reinicio.

Para ver los parámetros actuales podemos consultar-los de la siguiente forma:

ethtool –K “Interface”

Por ejemplo, podemos deshabilitar el tcp-offload de la Eth0 de la siguiente manera:

ethtool -K eth0 tso off

Para información ampliada sobre ethtool podemos consultar el manual en línea (man) de ethtool o desde http://linux.die.net/man/8/ethtool

Para establecer los cambios de forma permanente, deberemos utilizar nuestra herramienta en línea de comandos XE. Para ello, realizaremos:

xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-tx=”off”

xe vif-param-set uuid=<UUID of VIF> other-config:ethtool-tso=”off”

La sintaxis genérica seria:

   xe [vif/pif]-param-set uuid=<uuid pif/vif> other-Config:KEY=”off”/”on”

dónde KEY:

ethtool-tx : TX Checksum

         ethtool-rx: RX Checksum

         ethtool-tso: Tcp Segmentation offload

ethtool-ufo:  UDP Fragmentation offload

ethtool-gso: Generic Segmentation offload

NOTA: no se recomienda la desactivación del TSO en los VIF. Las buenas practicas aconsejan desactivar la misma desde la propia VM, tal y como indica el http://support.microsoft.com/kb/904946/  y http://support.microsoft.com/kb/951037

NOTA: Ojo al aplicar en entornos productivos. Testear antes.

Resources:

TSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/tso

GSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/gso

UFO: http://www.linuxfoundation.org/collaborate/workgroups/networking/ufo

 

C-State

Cuando una maquina esta inactiva, con el fin de ahorrar energía, es posible hacer que la cpu entre en modo bajo consumo. Cada cpu tiene varios modos y son llamados de forma colectiva estados C (C-State).

El trabajo de estos modos, es cortar el reloj de las unidades inactivas dentro de la CPU. Cuantas mas unidades se paran, mas ahorro de energía se obtiene, pero se requiere de mas tiempo cuando es necesario “despertar” las VMs para disponer de nuevo el sistema 100% operativo.

¿Problemas en virtualización?

Los estados-C pueden (en algunos casos) suponer un problema en entornos virtuales, ocasionando picos de memoria/cpu o cortes intermitentes de red.  El uso del modo Turbo y de los estados C, suele ser el responsable de estos problemas.

Si se encuentra con problemas debido a ello, puede des-habilitar esta funcionalidad.

¿Están los C-State habilitados?

Podemos ver y configurar esta funcionalidad desde la Bios de nuestro servidor. Ello ocasiona que para realizar la comprobación paremos maquinas y reiniciemos el host. Existe, pero, un método para verificar este estado sin necesidad de entrar en la Bios y reiniciar el host.

Verificar C-State en XenServer.

Para ello, abriremos una sesión SSH con nuestros host (mediante putty o a través de XenCenter) y teclearemos:

xenpm get-cpuidle-states | grep total | uniq

•    Si Total C-States = 4 ; los C-States están habilitados
•    Si Total C-States = 2; Los C-States no están habilitados.

Extra Info:
How to Disable C-States and Turbo Mode on Fujitsu Servers : http://support.citrix.com/article/CTX136863
Hosts Become Unresponsive with XenServer 5.6 on Nehalem and Westmere CPUs: http://support.citrix.com/article/CTX127395

 

Extending the performance

Initially have a number of specific data query. In addition to the initial data query, you can expand the query threshold using the PME Pack for XenServer 6.1 which provides a number of additional metrics query.

5 (más…)