Como ya sabéis, trabajar en CLI (command Line Interface) proporciona muchas ventajas, entre ellas, la tan querida automatización de tareas que nos proporciona el scripting y la ejecución de tareas desde CLI.
Dicho esto, vamos a ver como realizar una instalación de Citrix XenDesktop, así como el agente VDA, completamente, desde linea de comandos. (más…)
XenServer ofrece un seguimiento detallado de las métricas de rendimiento, incluyendo CPU, memoria, disco, red, información de estados C/P y almacenamiento.
En su caso, estas cifras están disponibles en una base de datos almacenada localmente por host y un por VM. Estas métricas están disponibles directamente, o se puede acceder y ver gráficamente en XenCenter o consultando desde una herramienta de terceros.
Los administradores y clientes pueden monitorizar los host de XenServer y sus máquinas virtuales utilizando métricas del sistema de base de datos Round Robind (RRDS) . Estas métricas se pueden consultar tanto desde http como haciendo uso de la herramienta RRD2CSV, además de los gráficos generados por XenCenter, el cual es apoyado sobre RRDS.
Nota: Podemos obtener una lista de métricas disponibles en el manual de Administración de XS6.2. Sección 9.1.1 y 9.1.2.
Herramientas necesarias
RRDTool ; wget ; XML editor. (con versiones windows/mac/Linux)
SDK no es necesario para el alcance de este post.
Analizando métricas
XenCenter permite ver una representación gráfica de algunas de las métricas de XenServer, de forma sencilla en periodos que comprenden desde los 10 min hasta 1 año.
Existen, pero muchas métricas que no aparecen en esta sección gráfica. Ello no significa que no exista la métrica, únicamente que no esta activa para su consulta.
Como comentamos anteriormente, existen una seria de métricas disponibles, documentadas en las secciones 9. del manual de administración. Adicionalmetne, disponemos de un Suplemental Pack (descargable a parte) que introduce métricas adicionales de monitorización.
Es importante tener en cuenta el retorno del comando de consulta de métrica. Cada métrica consultada proporciona:
Para ver una lista de las métricas disponibles en nuestro host ejecutaremos:
xe host-data-source-list host=<host>
Igual podemos obtener sobre una máquina virtual corriendo en nuestro host.
xe vm-data-source-list vm=<vm>
Estas métricas pueden habilitar-se (si no están) o des-habilitarse si no nos son necesarias. Para ello, seguiremos los siguientes pasos:
xe host-data-source-record data-source=<metric name> host=<hostname>
Para des-habilitarlos utilizaremos:
xe host-data-source-forget data-source=<metric name> host=<hostname>
Nota: Por defecto las métricas “tipo” incluidas en XS vienen activas por defecto. Tras instalar el Supplemental Pack, si queremos disponer de las mismas, deberemos habilitar-las.
RRDS (Round Robin Database)
XenServer almacena las métricas del sistema en una base de datos local. RRDS. Consiste en múltiples ficheros Round Robin (RRA) fijados en una base de datos.
El funcionamiento de RRDS es el siguiente: se trata la base de datos como si fuese un círculo, sobrescribiendo los datos almacenados con anterioridad una vez alcanzada la capacidad máxima de la misma. Esta capacidad máxima dependerá de la cantidad de información que se quiera conservar como historial.
Cada fichero en la base de datos contiene una métrica particular con una granularidad de tiempo especifica:
– Cada 5 segundos en los últimos 10 min. (RRA 0)
– Cada mínuto en las dos últimas horas (RRA 1-3)
– Cada hora en la última semana (RRA 4-6)
– Cada 24h durante el último año. (RRA 7-9)
Además, RRAs utilizar funciones de consolidación (CF). Entre ellas, son soportados los datos de tipo:
– Average (media)
– MIN
– MAX
Existen RRDS para cada VMs individual, asi como el propio dom-0. VMs RRDs son almacenadas en el host dónde corren, o en el Pool Master si estas están paradas.
Es importante conocer el indice de cada RRA y a que corresponde . Por ejemplo, imaginemos que queremos analizar la media de CPU utilizada en intervalos de 1 minuto. Con la información anterior, sabemos que debemos extraer las métricas del fichero RRA 1.
RRA 0 es llamado PDPs (Primary Data Points) que reflejan el valor actual de la métrica obtenida cada 5 segundos. El resto de RRAs son llamados CDPs (Consolidated Data Points) basados en la consolidación de los datos de los PDPs según los CF (Consolidation Function) aplicados al PDPs.
Es importante entender este ciclo, ya que si queremos obtener métricas por minuto de las últimas 24h, eso no será posible, y deberemos sacar metricas cada 2h para obtener la medición de 10 min. que deseamos y poder presentar los resultados necesarios.
CF – Consolidated Functions
Hemos visto en la sección anterior, los llamados CF. Es importante también entender el significado de los CF cuando estamos utilizando datos RRD para el seguimiento del rendimiento de nuestro sistema.
Cuando se analizan las métricas de nuestro sistema, es importante prestar atención a los valores de los DRR con granularidad limitada.
Utilizando http para la consulta RRDS.
RRDS puede ser descargado vía http, utilizando el controlador registrado http en host_rrd o vm_rrd. Ambas direcciones requieren de autenticación, ya sea http o proporcionada a traves de la API como un argumento de consulta.
wget http://<server>/host_rrd?session_id=OpaqueRef:<SESSION HANDLE>>
Dónde Server es la IP del servidor y SESSION HANDLE la métrica de consulta. Por ejemplo:
http://<user>:<password>@192.168.1.240/host_rrd?session_id=OpaqueRef:runstate_fullrun
Podemos obtener todas las métricas desde una fecha determinada utilizando la siguiente consulta.
http://<server>/rrd_updates?start=1234567890
Esta consulta recupera las actualizaciones de métricas, con el fin de no obtener toda la bd de métricas.
Con el parámetro Start=xxx indicamos que nos de las métricas a partir de esta fecha y hora (mostrado en segundos desde el 1 de enero 1970). Obtendremos métricas desde la fecha indicada en formato XML RRD Xport, que contiene las métricas de cada VM (si no se especificaron métricas especificas para una VM determinada, como veremos a continuación).
Nota: para obtener las actualizacion de un host, debe ser incluido el parámetro “host=true”.
http://<server>/rrd_updates?start=123456790&host=true
Para sacar todas las métricas rrd de nuestro host, podemos ejecutar:
http://<user>:<passwd>@<server>/host_rrd
Podemos consultar las métricas de una VM mediante el UUID de la misma.
http://<user>:<passwd>@<server>/vm_rrd?uuid=<vm_uuid>
Importante: RRD_Updates solo devolverá aquellos datos que estan siendo recogidos actualmente. VM_rrd le puede proporcionar datos historicos de una VM apagada, pero no podremos obtener datos con rrd_updates al no poder ser recogidos de forma inmediata.
http://<server>/rrd_updates?session_id=OpaqueRef:<SessionHANDlE>&Start=1234567890&cf=AVERAGE
RRD_Updates proporcionará el archivo mas adecuadoa a su solicitud. Tal como indicamos anteriormente hay 4 tipos de ficheros de bd y 3 Cfs. Cuando especificamos el parametro Start indicamos desde cuando queremos que se nos suministren los datos y en base a esa definición el sistema nos devolvera de forma automatica el tipo de archivo mas acertado.
Obteniendo datos desde CLI
Igual que podemos obtener todas las métricas históricas en tiempo real y especificas, podemos obtener datos RealTime desde la linea de comandos y obtener y redirecionar a CSV que luego podremos editar.
Como vimos anteriormente, con xe [vm|host]-data-source-list podemos obtener el listado de métricas y sus datos. Utilizando este listado podemos consultar cualquier métrica que sea necesaria.
xe host-data-source-query host=<host> data-source=memory_target
o para un vm
xe vm-data-source-query vm=<vm> data-source=<source_query>
Por supuesto, podemos incluir estas consultas en un script que nos permitan consultar o monitorizar datos de nuestro servidor.
Por ejemplo, veamos un pequeño script que nos proporciona métricas de host especificas cada x tiempo.
while true ; do
sleep 5
xe host-data-source-query host=<my_host> data-source=cpu_avg
done
El cual nos mostrará la métrica media de uso de cpu en el host, cada 5 segundos.
Scripts como este, nos permitirán observar en tiempo real métricas de nuestro servidor así como almacenar las mismas en ficheros que posteriormente nos servirán para analizar en caso que sea necesario.
Utilizando RRDs
Volvemos a la monitorización por RRDs. Como hemos visto antes, podemos obtener fichero XML con la representación de RRDs que es de nuestro interés.
Y que hacemos ahora? Podemos utilizar herramientas como rdtool que nos permitirán generar gráficos adecuados para las métricas obtenidas, o analizar, si así lo deseas los ficheros de forma manual.
Para el análisis de los ficheros obtenidos, existe una biblioteca de Python (parse_rrd) para el tratamiento de los ficheros RRDs.
Un vistazo a RRDTool
RRDTool es una herramienta que permite la representación gráfica y análisis de los datos en serie obtenidos por RRDS. RRDTool puede ser integrado fácilmente en Scripts y en aplicaciones perl, python, ruby, lua o tcl. Es un re-implementación del conocido MRTG.
RRDtool esta disponible para plataformas Windows/Unix en el siguiente link: http://www.mrtg.org/rrdtool/download.en.html
Rddtool no solo genera gráficos, si no, que nos permite el análisis de los ficheros RRDs obtenidos.
Consulta de datos: rrdtool fetch file.rrd AVERAGE
El retorno <nan> indica que no existe métrica en ese punto del tiempo. Utilizar rrdtool para el análisis puede ser interesante, pero lo que queremos en este punto, es generar una gráfica entendible del estado actual.
Es sin duda la característica mas potente de la herramienta. No cabe indicar, que disponemos siempre de la ayuda en linea “man” para la obtención de detalles.
Generando gráficas con RRDTool.
La sintaxis para generar un gráfico con rrdtool es la siguiente: rrdtool graph. Con “man rddgraph” podemos obtener ayuda sobre el uso del comando.
Lo primero que debemos tener es una serie de datos en variables, las cuales definimos a continuación:
rrd: path de la base de datos rrd
last: tiempo unix del último registro añadido
file1: fichero de salida utilizado (.png)
fecha: fecha actual para la generación de la gráfica
Width y height: Anchura y Altura de la gráfica.
Todas estas variables serán pasadas a nuestro rrdtool para la generación de la gráfica. Disponemos, pero, de otros parámetros del comando necesarios, que definiremos en ejecución del comando en lugar de usar con variable.
Start: tiempo
DEF: <>
Nota: La especificación del tiempo de inicio podemos utilizar un valor negativo, de esta forma podemos usar -1day o -7day para indicar datos de hace un día o una semana respectivamente.
Adicionalmente, tenemos el parámetro DEF, el mas complicado de entender, pero a priori el mas importante. Este parámetro nos permite definir un nombre “virtual” para una fuente de datos que podremos utilizar con rrdtool.
DEF:vname=rrd:ds-name:CF
vname: nombre ficticio que le damos a la consulta.
rrd: fichero rrd.
ds-name: nombre que le hemos dado en la creación de la bd rrd.
CF: funcion de consolidación que utilizaremos.
Nota: recordad que los CF hacen referencia al tipo (AVERAGE, MIN, MAX).
Con estas lineas ya podriamos crear nuestra gráfica, pero rrdtool nos permite anexionar comentarios entre otras opciones, de las que destacamos.
COMMENT: “comentario\n”
GPRINT: escribe datos debajo de la gáfica. Su sintaxys es: GPRINT:vnmae:CF:format
LINE: definición de las lineas graficas, o lo que nos ayuda a especificar como serán las lineas. Su sintaxys: LINE{1|2|3}:vname[#rrggbb_code[:legend]]
LINE1 crea una linea mas gruesa que LINE2.
Un ejemplo
Vamos a ver un ejemplo práctico de cómo poner esto en practica. Mas vale un ejempo que mil palabras dicen.
En primera instancia vamos a obtener datos desde nuestro servidor de XenServer. Como vimos anteriormente, vamos a obtener un XML con todos los datos de nuestras metricas RRD.
wget http://user:password@host_ip/host_rrd
Ya tenemos nuestro fichero XML extraido del log RRD. Podemos editar el fichero con XMLEditor para ver que contiene y los respectivos tags del mismo, asi como valores especificos de recursos.
Estas metricas obtenidas son almacenados en datasets (<ds></ds>) dentro de una estructura XML. Dependiendo de los componentes de nuestro sistema (numero de Cpus, de Nics, etc) dispondremos de mas o menos datasets. Veamos un ejemplo de dataset.
El inicio del fichero contiene un TimeStamp con la fecha de colección de los datos.
Ademas cada DS contiene un tipo: GAUGE o DERIVE. Gauge hace referencia a valores absolutos. DERIVE es una comparativa entre dos mediciones. Por ejemplo, %CPU es siempre un valor DERIVE así como el número de KB de memoria es una valor GAUGE.
Tras los DS, veremos unos tags RRA. Anteriormente hablamos de los RRA, cada uno de los RRA posteriores, es referente a los tipos RRA0,1,2,3…
Las comprobaciones y revisiones desde el XML son muy confusas, por eso vamos a generar gráficos para ayudarnos a entender estos datos. Es importante en este caso, conocer el contenido del campo “name” de los datos que queremos analizar. Por ejemplo, para el analisis de la recepción de paquetes en la interface 0, deberemos usar el contenido englobado en <name>pif_eth0_rx</name> .
Posteriormente, vamos a convertir el XML en un base de datos RRD para su uso con RRDtool. Para ello ejecutaremos:
rrdtool restore filexml file.rrd
Ahora, ya disponemos de un fichero RRD con el que poder trabajar.
Podemos ver el cotenido con el comando.
rrdtool fetch file.rrd AVERAGE
Determinamos el inicio/fin: Para determinar el intervalo de datos que queremos mostrar en la gráfica primero deberemos determinar los tiempos para el RRA que queremos analizar. Los siguientes comandos van a mostrarnos el último punto de datos grabado en el RRD y el tiempo del primer registro que ha sido guardado en el segundo RRA en una notación de tiempo UNIX.
rrdtool last host_rrd.rrd
rrdtool first host_rrd.rrd –rraindex 1
Generando el gráfico
Ya vimos anteriormente como generar el gráfico, ahora, es momento de ponerlo en practica.
Definiendo DataSets
Lo primero que debemos hacer es definir el dataset (ds) que queremos que sea mostrado utilizando la propiedad Def de RRDTool.
DEF:CPU00_MAX=host_rrd.rrd:cpu0:MAX
Ahora aclaremos y entendamos esta linea.
DEF:CPU00_MAX= :: En esta linea definimos una variable CPU00_MAX a la que asignamos el valor de lo siguiente:
Host_rrd.rrd :: Es el nombre de la base de datos RRD generada que será consultada.
:cpu0 :: Es el nombre del set que asignaremos a la variable. Anteriormente indicamos que lo importante era conocer el <name> del “contador” a consultar. Este es el parametro <name>.
MAX :: El CF utilizado identificado dentro del RRA.
Todo ello define CPU00_MAX. Con lo que podemos definir adicionalmente variaciones de la misma.
DEF:CPU00_AVG=host_rrd.rrd:cpu0:AVG
DEF:CPU00_MAX=host_rrd.rrd:cpu0:MAX
DEF:CPU00_MIN=host_rrd.rrd:cpu0:MIN
O sobre otras CPUs (si existen; comprobar en XML).
DEF:CPU00_AVG=host_rrd.rrd:cpu0:AVG
DEF:CPU01_AVG=host_rrd.rrd:cpu1:AVG
DEF:CPU02_AVG=host_rrd.rrd:cpu2:AVG
Ya tenemos los conjuntos de datos a definir. Ahora necesitamos donde empieza y dónde acaba la toma de datos que deber ser mostrada en la gráfica.
Si queremos generar una gráfica que contenga todos los datos del RRA consultado, utilizar la fecha de inicio y final obtenida del comando rrdtool “last” & “First” que comentamos anteriormente.
Así pues, nuestra sintaxis para el tiempo será definida como:
–start <valor obtenido de rrdtool first bd>
–end <valor obtenido de rrdtool last bd>
Nota: Podemos definir ventanas de tiempo menores dentro de esos dos valores. Unicamente debemos tener cuidad de que los valores indicados no engloben dos ficheros RRA.
Definir las características del gráfico.
Ya tenemos lo dificil. Ahora toca pintar 😀 y para pintar, debemos saber como. Tipo de linea, color, marco, tamaño del lienzo, etc.
Así pues ahora viene lo divertido. Pintemos!!! RRDtool puede crear lineas o areas para graficos. (un area comprende una linea con todo el campo inferior pintado completo)
Para ello utilizaremos el parametro LINE. Una linea comprende de varios punto. Incluye, un tamaño, un color y una leyenda. Por ejemplo, vamos a crear una linea doble Azul que incluira la leyenda CORE0 para el dato max. de cpu0. Y una linea simper verde que incluya datos para la cpu1.
LINE2:CPU00_MAX#0033FF:Core0
LINE1:CPU01_MAX#00CC66:Core1
Para finalizar, únicamente nos queda definir el Lienzo, que incluirá datos como Alto, ancho, limites de los indices, y un título.
–weidth 1024
–height 786
–uper-limit 100
–lower-limit 0
Y con eso ya tendremos nuestro grafico. Ahora simplemente es necesario incluir todo en una única linea mediante el uso de RRDtool. Podemos usar un fichero de texto dado el tamaño del comando y ejecutar a posterior.
rrdtool graph migrafica.png DEF:CPU00AVG=host_rdd.rrd:cpu0:AVERAGE DEF:CPU01AVG=host_rdd.rrd:cpu1:AVERAGE DEF:CPU02AVG=host_rdd.rrd:cpu2:AVERAGE DEF:CPU03AVG=host_rdd.rrd:cpu3:AVERAGE LINE2:CPU00AVG#0033FF:Core0 LINE2:CPU01AVG#00CC66:Core1 LINE2:CPU02AVG#FF66FF:Core2 LINE2:CPU03AVG#66CCFF:Core3 –width1024 –height 786 –upper-limit 0.2 –lower-limit 0
Y ejecutamos para obtener nuestro gráfico.
Otra vuelta de tuerca
Esto nos permitira generar nuestras gráficas y disponer de nuestros scripts para generar nuestras graficas a petición cuando sean necesarias. Pero puede que en ocasiones queramos valores mas compresinbles (como vimos el XML es bastante tedioso) que poder exportar para generar nuestras propias gráficas mas elaboradas, como es el caso de usar Excel o Numbers. Para ello siempre podemos realizar capturas de datos en tiempo real y exportar-los a CSV…
Creando CSV
XenServer nos proporciona otra herramienta interesante. Rrd2csv. Esta nos permite crear ficheros CSV desde fichero RRD.
Estos son explicados en los post: Playing with Counters: Part1, Part2 y Part3
Cacti
“Cacti es una completa solución para la generación de gráficos en red, diseñada para aprovechar el poder de almacenamiento y la funcionalidad para gráficas que poseen las aplicaciones RRDtool. Esta herramienta, desarrollada en PHP, provee un pooler ágil, plantillas de gráficos avanzadas, múltiples métodos para la recopilación de datos, y manejo de usuarios. Tiene una interfaz de usuario fácil de usar, que resulta conveniente para instalaciones del tamaño de una LAN, así como también para redes complejas con cientos de dispositivos.” – Wikipedia
Podemos obtener Cacti del siguiente Link: http://www.cacti.net/download_cacti.php
Disponemos de version Windos, Unix y para varias distribuciones Linux, y para instalar-lo en Mac, basta con ejecutar nuestro “port”.
Recursos:
Rdtool: http://www.mrtg.org/rrdtool/index.en.html
Rrdxport: http://www.mrtg.org/rrdtool/doc/rrdxport.en.html
Parse_rrd & SDK: http://www.xenserver.org/partners/developing-products-for-xenserver.html
Bulma: http://bulma.net
XenServer Manual: http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf
Calc. RGB Values: http://www.calculatorcat.com/free_calculators/color_slider/rgb_hex_color_slider.phtml
Rrd2csv: http://support.citrix.com/article/CTX135033
Cacti: http://www.cacti.net/
ctxdom: http://www.ctxdom.com/
CTXDOM.COM TEAM
En este post explicamos algunos de los cmdlets utilizados para la creación de un catálogo en XenDesktop con el fin de ayudar a entender y realizar nuestras tareas de automatización del Brocker.
Una vez realizado el documento de arquitectura, elegidos y definidos los métodos de despliegue así como la definición del resto de componentes de diseño, tendremos claro que pasos seguir durante el proceso de despliegue. El proceso completo puede realizar-se claramente desde Citrix Studio, pero vamos a realizar un completo deploy desde PowerShell para que veáis como funciona y lo que podemos llegar a realizar desde el mismo.
No vamos a profundizar en el uso de PowerShell, para ello hay muchos manuales y muy bueno colgados en la red.
Empezando
Un Catálogo de máquinas es una colección de máquinas (ya sean físicas o virtuales) que podemos asignar a usuarios de nuestra organización. Podemos desplegar un catalogo basado en equipos físicos (dónde instalamos previamente nuestros agentes VDA) o realizar un deploy automatizado, utilizando servicios como MCS o PVS, desde una GoldImage previamente generada.
El primer paso, es la generación de este catalogo , para ello utilizaremos el comando “New-BrockerCatalog”.
Debemos tener en cuenta la sintaxis a utilizar, la cual se establece de la siguiente forma.
SYNTAX. Ver Aquí
Generemos el Catalogo y veamos posteriormente que hemos hecho:
NewC-BrokerCatalog –name ‘PowerShell_Catalog’ –AllocationType ‘Permanent’ -MachineArePhysical $false -ProvisioningType ‘Manual’ -SessionSupport ‘SingleSession’ –PersistUserChanges ‘OnLocal’ -AdminAdress “Localhost:80” –Description ‘Catalogo creado en PowerShell’
Tras la ejecución del comando, podemos ver el nuevo Catalogo generado en nuestra consola de Studio.
Ahora ya tenemos generado el catalogo, hemos indicado que tipo de maquinas incluirá y nos toca proceder a incluir-las. Recordad, que podemos obtener datos de nuestro catalogo con el comando Get-BrockerCatalog –name ‘Name_Catalog’. Aunque no todos los parámetros del catalogo son modificables y en alguos casos será necesario crear uno nuevo si deseamos otro tipo.
Veamos ahora que ocurre si generamos un Catalogo, del tipo MCS con la sintaxis anterior:
New-BrokerCatalog –name ‘PowerShell_Catalog2’ –AllocationType ‘Random’ -MachineArePhysical $false -ProvisioningType ‘MCS’ -SessionSupport ‘SingleSession’ –PersistUserChanges ‘OnLocal’ -AdminAdress “Localhost:80” –Description ‘Catalogo creado en PowerShell’
Durante el proceso de creación no obtendremos errores, pero al comprobar nuestra consola:
Esto es normal, debido a que hemos indicado que se genere un catalogo de tipo MCS sin indicar datos relativos a la imagen que será utilizada para el deploy.
Veamos como solucionar-lo. Si intentamos solucionar el problema desde la MMC, veremos que no disponemos de opciones para ello, y únicamente podremos realizar un test o borrar el catalogo para generar de nuevo.
Lo primero que debemos hacer, es generar un IdentityPool. Y que es esto? Los cmdlet AcctIdentityPool proporcionan la habilidad de generar pool que pueden ser almacenados como máquinas en AD. Para ello debe ser provisto de el nombre de esquema, el tipo de esquema, la OU y el dominio al que hace referencia, para que sea utilizado para el almacenaje de las nuevas cuentas.
Su sintaxis puede ser consultada Aquí.
Veamos como utilizar-lo.
New-AcctIdentityPool -AdminAddress ‘localhost:80′ -AllowUnicode -Domain ‘ctxdom.local’ -IdentityPoolName ‘Ejemplo_PowerShellVMs’ -NamingScheme ‘Maquina-####’ -NamingSchemeType ‘Numeric’
Ahora ya hemos definido como van a generar-se las VMs en nuestro AD y dónde.Continuemos con el proceso.
Es el momento de crear nuestros metadatos del catálogo de la siguiente forma. Este paso no es obligatorio.
Set-BrokerCatalogMetadata -AdminAddress ‘localhost:80’ -CatalogId 5 -Name ‘Citrix_Desktop_PShellCatalog’ –Value ‘1234’
El nombre por defecto suele ser: Citrix_DesktopStudio_IdentityPoolUid. El CatalogID lo podemos encontrar realizando una consulta. Tal como comentamos anteriormente, tenemos los cmdlets que empiezan con “get-“ los cuales nos permitirán obtener información. Podemos obtener el ID de nuestro catalogo de la siguiente forma:
Get-BrokerCatalog | ft Name, Uid
Donde obtendremos el listado de catálogos con su respectivo ID.
Opcional: Chekear Catalogo
Test-ProvSchemeNameAvailable -AdminAddress ‘Localhost:80’ -ProvisioningSchemeName @(‘Ejemplo_PowerShellVMs’)
Ahora es momento de crear el objeto de esquema para el aprovisionamiento de VMs.
Syntaxis aquí.
El proceso de creación hace una copia del disco duro conectado a una instantánea de máquina virtual y lo almacena en el lugar de almacenamiento que la unidad de alojamiento en el esquema de provisiones define . Esta es una tarea de larga y por lo general tomará un rato en completar la operación (dependiendo del tamaño del disco duro que está siendo copiado y el número de instantáneas generado ) .
Para la generación de las VMs deben utilizar-se Snapshot en lugar de la propia VM, de forma que el contenido del disco duro pueda ser determinado fácilmente.
Para este cmdlet se requiere información facilitada por el “Citrix Machine Creation Services: Hosting Unit Service Snapin”, el cual provee información relativa a los hipervisores. También toma información del Snapin de “AD Identity Service”, el cual proporciona información acerca de los IdentityPool.
El esquema de aprovisionamiento es una colección de todos los datos que son necesarios para generar una plantilla desde las cuales las VMs serán creadas. Por ello, necesitamos la siguiente información.
• Hosting Unit A definido en el HostService, así como la red y el almacenamiento definido previamente.
• Un IdentityPool definido.
Veamos un ejemplo de cración de esquema sencillo.
New-ProvScheme -CleanOnBoot -HostingUnitName HostSettings -IdentityPoolName Ejemplo_VMs_Pshell -MasterImageVM ‘XDHyp:\hostingunits\HostSettings\XenDesktop_Shared.VM\NEW UPGRADE XD7.5 VDA.snapshot’ -ProvisioningSchemeName ‘PowerShellScheme’
El proceso tardará un rato. Adicionalmente, podemos especificar la red a utilizar, númeor de CPUs y memoria, mediante los parámetros indicados en Syntaxis. O se puede modificar posteriormente mediante el comando Set-.
Podemos especificar el num de CPU o memoria con los parámetros –VMMemoryMB o – VMCpuCount
Cabe recalcar, que IdentityPoolName debe coincidir con el PoolName creado en el punto 2 del proceso. Así como ProvisioningSchemeName debe ser un nombre único.
Ahora vamos a actualizar nuestro Catalogo al cual vamos a asignar el esquema de PVS recien creado.
Set-Broker –Name PowerShell_Calago2 –ProvisioningSchemeID f75ced9b-7ef4-47a7-ad1e-22694ae190fd
Añadimos direcciones de controlador al esquema de aprovisionamiento. Esta es la lista de controladores donde las maquinas creadas pueden registrar-se . Esto solo afecta a las maquinas que sean creadas. No afectará a las maquinas ya creadas.
Add-ProvSchemeControllerAddress -AdminAddress ‘localhost:80’ -ControllerAddress @(‘Citrix1.ctxdom.local) -ProvisioningSchemeName ‘PowerShellScheme’
Vamos a ver como crear ahora las cuentas de nuestras VMs en AD.
New-AcctADAccount -Count 2 -IdentityPoolUid 79ae43e8-09e6-4b0f-93f6-c34ce81f73a0
Esto creara, según lo definido en el IdentityPool, dos cuentas [“Count2”] con la nomenclatura Maquina-#### que definimos anteriormente. Maquina-0001 Maquina-0002.
Podemos verlas en nuestra dirección AD suministrada.
Y ahora queda desplegar VMs. Hemos generado el GoldenImage desde un Snapshot, hemos creado las cuentas de AD, hemos generado la definición de las VMs con el esquema de PVs y ahora es momento de deployar.
New-ProvVM -ADAccountName @(‘CTXDOM\Maquina-0001$’,’CTXDOM\Maquina-0002$’) -ProvisioningSchemeName ‘ExampleMachines’ -RunAsynchronously
Podemos obtener el VMID ejecutando el comando “Get-ProvVM”. Ahora, bloqueamos la maquina y prevenimos posibles cambios accidentales sobre la misma.
Lock-ProvVM -ProvisioningSchemeName ‘ PowerShellScheme’ -Tag ‘Brokered’ -VMID @(‘VMID_VM’)
Añadimos una máquina asignada al sitio. Este paso se utiliza para fabricación de la máquina disponible para ejecutar aplicaciones y escritorios de los usuarios.
New-BrokerMachine -CatalogUid -MachineName CTXDOM\Maquina-0001′
New-BrokerMachine -CatalogUid -MachineName CTXDOM\Maquina-0002′
Detalles:
Al no definir anteriormente el parámetro CPU y MEM, toma como defecto, el valor de la VM utilizada como master.
Y aquí tenemos nuestras VMs en nuestro Host Hyper-V.
¿Y todo esto, para que?
Los administradores solemos realizar muchos procesos repetitivos diariamente. No cabe entrar en detalle la utilidad del Scripting y sus posibilidades. Si a priori generar estos procesos puede ser algo engorroso y/o tediosos, una vez preparados nuestros correspondientes Scripts nos permitirán automatizar tareas que realizamos de forma común de forma mas ágil y rápida, reduciendo la cantidad de faena así como evitando errores en la ejecución de las tareas.
Recursos adicionales:
http://support.citrix.com/static/kc/CTX127254/help/New-BrokerCatalog.html
http://support.citrix.com/static/kc/CTX127254/help/Set-BrokerCatalog.html
http://support.citrix.com/proddocs/topic/infocenter/ic-how-to-use.html
http://support.citrix.com/static/kc/CTX127254/help/New-ProvScheme.html
http://support.citrix.com/static/kc/CTX127254/help/about_HypHostSnapin.html
http://support.citrix.com/static/kc/CTX127254/help/Get-HypConfigurationDataForItem.html
http://support.citrix.com/static/kc/CTX127254/help/Lock-ProvVM.html
http://support.citrix.com/static/kc/CTX127254/help/New-BrokerMachine.html
La función de “Configuration Loggin” nos permite realizar un seguimiento de los cambios administrativos realizados en el entorno de Citrix. Mediante la generación de los informes que esta función pone a su disposición, puede determinar qué cambios se hicieron a la comunidad de servidores, cuando se hicieron y quien los hizo. Esto es especialmente útil cuando varios administradores modifican la configuración de la granja de servidores. También facilita la identificación y, si fuera necesario, la reversión de los cambios administrativos que pueden estar causando problemas para la comunidad de servidores.
En este post vamos a realizar un breve repaso a todos los cmdlets proporcionados para el uso de Conf. Loggin. La siguiente tabla, muestra la lista de cmdlets al respecto y su funcionalidad.
Recordad que podemos obtener ayuda sobre la sintaxis y uso de cada uno de ellos, mediante el uso del comando “Get-Hep CMDLET” y podemos obtener ejemplos utilizando el modificador –examples al final del mismo.
Export-LogReportCsv: Exporta e Configuration Loggin sobre un fichero CSV
Export-LogReportHtml : Exporta e Configuration Loggin sobre un fichero HTML
Get-LogDataStore: Nos proporciona detalles sobre los datos del DataStore. Estos datos incluyen: Servidor, Database, Datastore, Provider, Schemaname, Status, Security, etc.
Get-LogDBConnection: Obtenemos unicamente el String de conexión.
Get-LogDBSchema: Obtiene un script que crea el esquema de base de datos del Servicio ConfigurationLogging para el almacén de datos especificado.
Get-LogDBVersionChangeScript: Obtiene un script que actualiza el esquema de base de datos del Servicio
Get-LogHighLevelOperation: Obtiene operaciones de alto nivel
Get-LogInstalledDBVersion: Obtiene una lista de todas las versiones de esquema de base de datos
Get-LogLowLevelOperation: Obtiene operaciones de bajo nivel
Get-LogService: Obtiene las entradas de registro de servicio para el servicio ConfigurationLogging
Get-LogServiceAddedCapability: Obtiene las capacidades adicionales para el Servicio ConfigurationLogging en el controlador
Get-LogServiceInstance: Obtiene las entradas de la instancia de servicio para el servicio.
Get-LogServiceStatus: Obtiene el estado actual del servicio ConfigurationLogging en el controlador.
Get-LogSite: Obtiene la configuración de registro de configuración global.
Get-LogSummary: Obtiene operaciones registradas dentro de los intervalos de tiempo dentro de un rango de fechas .
Remove-LogOperation: Elimina los registros de configuración
Remove-LogServiceMetadata: Elimina los metadatos del servicio dado.
Remove-LogSiteMetadata: Elimina los metadatos desde el sitio dado.
Reset-LogDataStore: Actualiza la cadena de base de datos que se utiliza actualmente por el servicio de registro.
Reset-LogServiceGroupMembership: Vuelve a cargar los permisos de acceso y de servicio de configuración para el Servicio ConfigurationLogging .
Set-LogDBConnection: Configura una conexión de base de datos para el Servicio ConfigurationLogging
Set-LogServiceMetadata: Añade o actualizaciones de metadatos en el servicio dado
Set-LogSite: Establece la configuración de registro de configuración global.
Set-LogSiteMetadata: Añade o actualizaciones de metadatos en el sitio dado.
Start-LogHighLevelOperation: Registra el inicio de una operación de alto nive
Stop-LogHighLevelOperation: Registra la finalización de una operación de alto nivel previamente iniciado
Test-LogDBConnection: Prueba de una conexión de base de datos para el Servicio ConfigurationLogging .
(ctxdom.com) Tal y como se explica en el manual de XenDesktop, por defecto, solo el 10% de escritorios esta levantado en horario pico en los Escritorio sin uso.
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-control-power-management-rho.html
Esto puede suponer un problema (o no) y en caso de necesitar modificar-lo, como conprovareis, no disponeis de forma desde la GUI para realizar la modificación especifica. Así como lo hacemos? Vayamos a nuestro querido PowerShell.
Disponemos de dos características dentro del objeto de Catalogo que permiten la configuracion y comportamiento sobre el uso y administrador de Energia en XenDesktop.
El OffPeakBufferSizePercent y el PeakBufferSizePercent. Por defecto, ambos valores estan a 10%.
10% OffPeakBufferSizePercent: En los umbrales definidos como “fuera de horario pico” se establece que se deberá disponer de un 10% del total de escritorios del catalogo en estado “Running”.
10% PeakBufferSizePercent: En los umbrales definidos como “horario pico” se establece que se deberá disponer de un 10% del total de escritorios del catalogo en estado “Running”.
Para comprobar el estado de nuestro umbrales, podemos hacer uso del CMDLET:
Get-BrokerDesktopGroup -Name ‘CATALOG NAME’
Ello nos mostrará todos los objetos definidos en nuestro catalogo y su correspondiente valor. Podemos observar estas dos propiedades en el listado obtenido. Estas pueden ser modificadas de la siguiente forma (sin incluir %):
Set-BrokerDesktopGroup -Name ‘CATALOG NAME’ –OffPeakBufferSizePercent %NUM
Set-BrokerDesktopGroup -Name ‘CATALOG NAME’ –PeakBufferSizePercent %NUM
Adicionalmente, es importante tener en cuenta que hacen los Escritorios, tras la desconexion de los usuarios, o como actuan cada cierto tiempo en des-uso, tal y como vimos anteriormente en http://goo.gl/eiMVO0
Recursos:
XenDesktop eDocs Power Management: http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-control-power-management-rho.html
XenDesktop eDocs SDK cmdlets: http://support.citrix.com/proddocs/topic/xendesktop-7/cds-sdk-cmdlet-help.html
XenDesktop eDocs SDK cmdlets About Brocker PowerManagement: http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/about_broker_powermanagement-xd7.html
CTXDOM.COM Spanish Citrix Community: http://www.ctxdom.com
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
