Welcome to Delicate template
Header
Just another WordPress site
Header

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í

Veamos la versión actual de python en XS6.2

[root@xenserver62 ~]# python -V

Python 2.4.3

Vamos a utilizar YUM en primer momento, para instalar todos los paquetes necesarios para la instalación de Python3.

NOTA: Si al realizar un yum update aparece un error referente al repositorio de Citrix 6.2

* Deshabilitar el repositorio Citrix.Repo

* Habilitar el repositorio CentOS-base Repo

Sobre esto hable hace tiempo en el siguiente link: http://blogs.itpro.es/cristiansan/2012/05/23/xenserver-trick-linux-repository/

Instalando Requerimientos

Habilitados los repositorios. Procedemos a instalar Make y el compilador GCC.

Install Make.

# sudo yum install make

Install GCC

# sudo yum install gcc

Descargamos e instalamos Python3

Para ello, desde nuestra linea de comandos, ejecutamos:

wget http://www.python.org/ftp/python/3.3.2/Python-3.3.2.tgz

tar xf Python-3.3.2.tgz

cd Python-3.3.2/

./configure –prefix=/usr/local

make && make altinstall

ahora ya podemos ejecutar python3.3 sin problemas.

[root@xenserver62 bin]# python3.3
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

NOTA: Si ejecutamos python seguimos en versión 2.4.3

NOTA: No se recomienda el cambio del link symbolico, pues muchos programas realizados en Python apuntan a «python» como enlace de Python2. Modificar-lo puede suponer un problema para scripts que necesiten de python2.

TRICK: Para simpliciar las cosas, podemos crear un link simbólico “py” para ejecutar python3.

 # ln /usr/local/bin/python3.3 /usr/bin/py

De este modo, al ejecutar py, estaremos ejecutando python 3.3

[root@xenserver62 bin]# py -V
Python 3.3.2
[root@xenserver62 bin]# py
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

Y con esto, y un biscocho,  ya tenemos Python 3 en nuestro querido XenServer 6.2. 😉

En algunos entornos (laboratorios, servidores StandAlone, etc) disponer de una maquina para almacenar los repositorios ISO que compartimos en nuestro XenServer puede suponer un gasto de recursos adicionales que nos podriamos ahorrar.

En este breve artículo os enseñamos como crear vuestro propio repositorio local en XenServer que permita almacenar y utilizar ISO.

Tened en cuenta que utilizar un SR local hace que este repositorio no este disponible para el resto de host que componen un pool. Si dispones de un pool y quieres que estas ISO estén disponibles para todos los host, recuerda utilizar un recurso compartido como almacen.

Los pasos aquí indicados te ayudarán a crear un SR de ISOs Local y las propias ISO solo estarán disponibles únicamente sobre la máquina que almacena dichas imágenes.

Quieres saber como… continua leyendo aquí

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

 

Las diferentes versiones de Citrix Receiver para distribuciones Linux pueden encontrar-se en el siguiente Link: http://www.citrix.com/downloads/citrix-receiver/receivers-by-platform/receiver-for-linux-121.html

Para instalar y utilizar Citrix Receiver es necesario instalar previamente la biblioteca de OpenMotif : http://www.opengroup.org/openmotif/

En nuestro caso vamos a realizar la instalación del receiver en un Ubuntu Unity 12.0 dentro de un eeePC 1080HA.

Para este caso, vamos a instalar previamente las librerías necesarias.

Navegar a la dirección: ftp://ftp.ics.com/openmotif/2.3/2.3.1/ versión necesaria para la instalación de Citrix Receiver. Disponéis de versiones especificas para Fedora, RH y/o SuSe. En nuestro caso, utilizaremos la versión de RH y utilizaremos Alien para la conversión del paquete a .DEB (para detalles sobre el uso de Alien, puedes revisar el siguiente Post dónde explicamos como utilizar-lo : http://goo.gl/OwjEO

Una vez descargado el RPM, realizamos la conversión con Alien:

# sudo alien –d opennmotif-2.3.1-1.RHEL3.0.1386.rpm

Una vez convertido, realizamos la instalación del paquete .DEB recién creado.

# sudo dkpg –i opennmotif-2.3.1-1_i386.deb

Finalizada la instalación, podemos proceder a descargar el correspondiente paquete Citrix Receiver para la distribución requerida. En nuestro caso, descargaremos el paquete correspondiente a Debian (.deb) y realizaremos la instalación tal y como se indico anteriormente.

# sudo dkpg –i icaclient-12.1.0_i386.deb

Realizamos el mismo procedimiento para el soporte de USB local.

# sudo dkpg –i  ctxusb-2.2.0_i386.deb

Captura de pantalla 2013-05-02 a la(s) 15.40.19

Post Original: www.ctxdom.com – Tu comunidad 100% Citrix

PowerShell Jobs – Basic

mayo 10th, 2013 | Posted by cristiansan in CLI | Microsoft | PowerShell - (0 Comments)

Los objetivos de automatizar procesos, son los de facilitar tus tareas cotidianas y repetitivas.  Podemos automatizar los procesos de forma que no sea necesario realizar las acciones de forma manual.

PowerShell por eso, tiene un inconveniente en este punto. Cuando se inicia una secuencia de comandos PowerShell, pueden necesitar de un tiempo determinado para su finalización, si además realizamos las tareas sobre maquinas remotas, como vimos en el anterior post “basics”, el tiempo puede aumentar. Su pompt de powerShell no estará disponible hasta la finalización de las mismas. Una forma de solucionar este problema es utilizar varios prompt PowerShell o lanzar los procesos en Background, como Job.

Los trabajos en PowerShell se ejecutan de forma asíncrona. Cabe tener en cuenta, que los resultados no son persistentes, con lo cual, si cerramos una sesión con un Job, los datos del mismo se perderán.

Podemos crear Jobs de dos formas:

Cmdlets Jobs

Cmdlets específicos para la generación de trabajos. Podemos ver un listado con el comando Get-Command .

Get-Command -Name *job* | Format-Wide -Column 3

Veamos como ejecutar un proceso Job con Cmdlets.

Start-Job –name PrimerJob –scriptblock {Get-Service WinRM}

Generamos un segundo Job

Start-Job –name SegundoJob –scriptblock {Get-Service WSService}

Para comprobar los Jobs y su estado, ejecutaremos

Get-job

1

Parametro -AsJob

Algunos cmdlets permiten el parámetro –asjob el cual nos permite ejecutar el mismo como trabajo. Veamos un ejemplo.

Invoke-command –computername vm1 –scriptblock {get-Service WinRm} -asJob

En este caso, es el propio sistema el que nombra el trabajo.

2

En este caso, la maquina VM1 no existe, con lo cual podemos ver el estado “Failed” en su ejecución.

Resultados

Como podemos ver en los dos primeros trabajos, disponemos en la columna HAsMoreData del valor TRUE. Esta columna indica si han sido devueltos resultados.

Este es el momento de poder ver el resultado de la operación. Para ello utilizaremos el comando “receive-Job”.

Receive-Job –name PrimerJob –keep

3

Aquí vemos la salida de Get-Service en la salida del primer Job.  El modificador –keep evita que los datos sean borrados y que podamos accedamos a ellos nuevamente posteriormente.  Recordad, que si cerramos el prompt, los datos se pierden.

Borrar Jobs

Para borrar un Job, basta con obtener el Job deseado con “Get-Job –id X” y redirigir el mismo hacia el cmdlet “Remove-Job”