Hola, que tal? Soy Jose Maria Gris y de nuevo estoy con vosotros tras una temporada alejado de vosotros por temas de salud. Que le vamos a hacer.

Pero bueno, ya estamos aquí de nuevo con vosotros y traigo noticias que seguro os van a interesar.

Como seguro sabéis, se ha celebrado el Partner Exchange Conference en USA. En este tipo de eventos se aprovecha para presentar novedades que iremos comentando. Una de las mas esperadas es la próxima versión de vSphere, posiblemente la 5 aunque no sabemos si va a ser ese su nombre definitivo.

Se ha comentado que la próxima versión va a incorporar Replicación basada en Host para Site Recovery Manager(SRM). Interesante como replicación asíncrona para quien no dispone de replicación en cabina. (Chicos, vamos a tener que hacer una nueva traducción de SRM…)

vMotion a larga distancia. Aunque ahora se puede hacer usando soluciones del triunvirato VMware/Cisco/EMC, al parecer se van a poder hacer vMotion entre CPD distantes más de 200Km mediante feature estándar.

DRS para Storage. Si, si, has leído bien, para storage. De igual forma que una cpu o memoria sobrecargada hace que un DRS mueva nuestra VM de Host, ahora si una Lun tiene sobrecarga moverá nuestra vm entre storage (tengo interés en ver el algoritmo). Parece ser que en lugar de asignar nuestras VMs a un Datastore lo haremos a un Pool de Datastores llamados “Pods”, los cuales harán autobalance.

Estamos asistiendo al momento de la verdad del Storage y podemos ver soluciones muy interesante como el AutoTiering de Datacore (inminente aparición) o el FAST de EMC. Ambos mueven los bloques de información de una LUN de menor velocidad a una de mayor velocidad si el uso de la VM es intensivo y viceversa cuando no se usa.

También se han comentado que con la aparición de los 10Gig Ethernet va a ofrecer QoS y reservas de ancho de banda para nuestras VMs que tengan prioridad. Interesante no?

Hasta la semana que viene. Take Care

Hola, soy Miguel Angel Alonso y aquí estoy como cada martes para contaros algo nuevo acerca del tema de la virtualización, y hoy, más en concreto, acerca de VMware View y las cuatro opciones principales que tenemos a la hora de modificar nuestros escritorios.

Para aclarar estos 4 términos, que a veces parecen no quedar muy claros para los lectores del Blog de virtualización y para asiduos de otros foros de virtualización, pondremos nombre y apellidos a estos conceptos con la buena intención de que sean mejor entendidos:

1. Reset

El Reset lo puede hacer tanto el administrador como el usuario, si se tiene el permiso necesario para hacerlo. Este permiso puede prestarse al usuario durante la configuración del Pool de escritorios. Esto es interesante para el usuario desde un punto de vista de autoservicio si algo va mal con su máquina virtual. La opción “Reset” desde la consola de Administración de View muestra el siguiente mensaje al hacer clic.

Esto explica lo que sucede cuando se restablezca el escritorio: Sólo se restablece la máquina virtual sin necesidad de apagar el sistema operativo correctamente, igualmente que como cuando se hace clic en la opción de Reset en el vCenter. Se desconectará la sesión del usuario, se perderá todo el trabajo que no se haya guardado.

Los términos Refresh y Recompose vinieron con la primera versión de View Composer. Las dos palabras describen dos funciones muy importantes dentro de la tecnología de Linked Clones que se utiliza en VMware View.

Si no estás familiarizado con View Composer, aquí está una pequeña introducción de forma rápida. El Composer de VMware View, utiliza la tecnología de Linked Clone, lo que significa que varios discos de la máquina virtual se basan en una imagen principal desde donde se leen. También, tienen su propio disco llamado disco delta donde ese escriben y reflejan todos los cambios realizados. Para crear una agrupación de escritorios con tecnología de Linked Clone, has de utilizar una máquina virtual, y no una plantilla (Template).

Esta máquina virtual se debe agregar al dominio mediante Active Directory y cerrarse antes de crear una instantánea (Snapshot) de esta. Los pools con tecnología Linked Clone, se basan en instantáneas (Snapshots), pero sólo funciona si la máquina virtual se cerró cuando la creamos. Durante la configuración del asistente de pool de escritorios, se requerirá de la imagen Golden principal, que es la máquina virtual que ya hemos preparado con dicho propósito. En el siguiente paso, el asistente nos mostrará una visión general de todas los Snapshots de la máquina virtual y entonces habremos de seleccionar uno de ellos.

Cuando se haya terminado con el asistente del pool desde el administrador de VMware View, View Composer comenzará a crear el grupo de escritorios. En primer lugar, se hará un aprovisionamiento completo de un clon del Snapshot seleccionado para cada LUN. A esta imagen se la llama Imágen Réplica. Después, se creará una imagen fina, por así llamarla, tomando como base a nuestra Réplica, creando así de esta manara nuestro primer Linked Clone. Todas las máquinas virtuales serán personalizadas con el nombre del host y otros detalles a través de los procesos de Quickprep o Sysprep, cuando nuestros Linked Clones se inicien.

Con las funciones de Recompose y Refresh desde este momento, se podrán reducir el tamaño de la máquina virtual (Refresh) y actualizar los Linked Clones de nuevo, al volver a crearlas con nuevos Service Pack de Windows, actualizaciones de seguridad o cualquier tipo de modificaciones realizadas por nosotros.

2. Recompose

La acción de Recompose es realizada por el administrador, dentro de la interfaz del administrador de View. Con esta función, el administrador puede hacer cambios en la instantánea (Snapshot) dentro de la Matriz de la VM o puede cambiar a otra Parent VM (Imagen Padre o Golden). En ambos casos, se aprovisionará una nueva imagen de la Réplica para los pool de escritorios configurados en las LUNs de hospedaje de nuestros Linked Clones.

3. Refresh

Mediante la acción de un Refresh, no se cambiará la instantánea (Snaphot) de la VM Parent. Esta acción sólo afectará al disco delta para restablecerlo a su estado inicial. Esto se hace para reducir la cantidad de almacenamiento utilizado por la máquina virtual. Ambas opciones sólo están disponibles en un pool de discos persistentes automatizados y “no” en pools de discos no persistentes.

Para hacer un Refresh de un grupo no persistente de VMs, deberán ser creadas todas de nuevo. Una buena opción aquí es eliminar la VM después del primer uso y personalizarlos con perfiles móviles y secuencias de comandos (Scripts) o con una solución de gestión de perfiles como AppSense o RTO.

En un pool de escritorios de carácter persistente se deberían redirigir todos los datos de aplicación hacia el disco de datos de usuario (User Data Disk) y que también almacena, a su vez, el perfil de usuario ya que los datos de la unidad C:\ se perderán al actualizar o recomponiendo el disco.

4. Rebalance

Durante esta acción, todas las máquinas virtuales serán rebalanceadas entre las LUN de almacenamiento para utilizar el espacio de manera más eficiente.

Aquí llegamos al final del tema de hoy, esperando haber podido contar algo de interés a nuestros queridos lectores del blog de virtualización en español.

Os emplazo hasta la semana que viene, donde hablare de un nuevo tema de este maravilloso mundo de la virtualización. Gracias como siempre y hasta la semana que viene.

Ya esta disponible online el sexto episodio en nuestro Web TV show de virtualización en español, un nuevo programa de televisión web que es audaz, innovador y dedicado en exclusiva a los profesionales de la virtualización de sistemas y el cloud computing en español.

Esta semana tenemos una gran leccion del Ministerio de Defensa Español, hablaremos del anuncio hecho publico por VMware sobre el lanzamiento gratuito de la versión SuSe Linux Enterprise para VMware, contestaremos a una gran pregunta de un usuario relacionada con los procesadores Intel y AMD en virtualización y descubriremos una utilidad increíble que te ayudara a mover máquinas virtuales desde tu cloud privada a una cloud publica.

¿Y tú qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Crees que aun AMD tiene una ventaja competitiva con respecto a los procesadores de Intel en virtualización? Deja tu comentario en virtualizacion.TV o charlemos sobre ello en twitter.

¿Y si la virtualizacion fuese más accesible y fácil de implementar?

Pues sencillamente, esto es lo que VMware y JmG Virtual Consulting, nuestra empresa de servicios y soluciones de virtualizacion y partner tecnológico enterprise de VMware, pretenden hacer.

Según un estudio de Gartner publicado en octubre del 2010, en 2012 más del 75% de las pymes habrá adoptando la virtualización, frente al 28% que emprendía proyectos de este tipo en el año 2009.

Durante los próximos dos años, las soluciones de virtualización que tendrán una demanda mucho mayor serán las soluciones de virtualización de servidores y la recuperación ante desastres. El informe de la consultora también destaca que el 88% de los encuestados admitieron contar con alguna versión de las soluciones de virtualización de VMware vSphere.

Por este motivo, VMware y JmG Virtual Consulting ponen a tu disposición este nuevo recurso web con información, videos, enlaces y descargas sobre las soluciones de virtualización, un recurso que es imprescindible a tener en cuenta en tu arsenal.

Como prueba de ello, ya puedes beneficiarte de la virtualización con VMware y JmG Virtual Consulting descargando nuestra guía de virtualización desde esta web.

¿Y tú qué opinas? ¿Cuáles son tus experiencias personales con VMware? ¿Crees que es una tecnología accesible y fácil de implementar? Deja tu comentario abajo o charlemos sobre ello en twitter.

Que VMware es una empresa que trata de innovar y superarse a sí misma día a día es algo por todos conocidos, y prueba de ello son el desarrollo de tecnologías como vMotion, Storage vMotion, View, HA o Fault Tolerance por mencionar algunas.

En este artículo me gustaría hablar sobre Storage I/O Control (SIOC), una de esas nuevas funcionalidades que, independientemente de la calidad de la implementación, suelen calificarse como “una gran idea”.

Y es que SIOC es una vuelta de tuerca más al aprovechamiento de recursos, ya que extrapola el concepto de “shares” que ya conocíamos y que se aplicaban a la memoria y a la CPU y lo extiende al almacenamiento. Sin embargo la parte novedosa de SIOC es que esta priorización y optimización del consumo de recursos, en este caso del almacenamiento, se hace en base al almacenamiento compartido y no al almacenamiento local.

Para entender un poco mejor el funcionamiento de SIOC y apreciar verdaderamente la novedad de la solución debemos remontarnos a los tiempo de PARDA, nombre original que se le dio al proyecto, y en cuya definición podremos encontrar las bases de lo que hoy es SIOC.

Como comentaba, la idea base de SIOC/PARDA es la de optimizar el acceso al almacenamiento compartido, y en particular a la LUN que aloja nuestro datastore. Para ello, SIOC controla la latencia de acceso al almacenamiento y modifica la ventana del host en base a un umbral de latencia definido por el usuario. Es importante resaltar que cuando hablamos de umbral de latencia estamos tratando con el tiempo medio de retraso de acceso al almacenamiento de todo el clúster y no de un host en particular. La virtud de SIOC es que mantiene la desviación estándar de este valor bastante baja. Esto quiere decir que para conseguir un umbral de latencia de 20ms no nos encontraremos un hosts con una latencia de 30ms y otro con una latencia de 10ms.

¿Y cómo consigue SIOC mantener el umbral de latencia?

Pues gracias al concepto de ventana, a un algoritmo que se encarga de calcular el valor esta ventana y a la comunicación entre los hosts ESX/ESXi para conocer y poder calcular la latencia total del clúster. Desgranemos un poco estos elementos:

• El concepto de ventana es análogo al utilizado en las pilas TCP/IP, y representa a la longitud de cola de operaciones de entrada salida por segundo (IOPS). Esta ventana es recalculada de forma periódica por el algoritmo ejecutado en el host. Es importante destacar, que al contrario que ocurre con los paquetes TCP que se segmentan en una longitud fija (el MTU), el tamaño de la IO suele cambiar con bastante frecuencia, por lo que se toma el promedio del tamaño de estas IO para hacer el cálculo de la ventana.
• El algoritmo que se usa para ajustar la ventana, que podréis encontrar explicado en la definición del proyecto PARDA, se ejecuta periódicamente en cada host ESX/ESXi de forma independiente. Esto se hace así para evitar la sobre carga que podría suponer la comunicación entre todos los miembros del clúster. Sin embargo, el algoritmo necesita conocer el estado del clúster para poder calcular correctamente el tamaño de la ventana. Para ello hace uso del siguiente componente que encontramos en el siguiente punto.
• La comunicación entre los hosts ESX/ESXi. Como he comentado resulta un elemento fundamental para poder calcular la latencia total del clúster. En este caso se trata de un fichero compartido entre todos los miembros del clúster, en el que se le asigna un bloque completo a cada nodo y donde se almacena la latencia media y el número de IOs de cada uno de ellos.

En el plano más práctico todo esto se traduce en poder priorizar el acceso al almacenamiento de aquellas máquinas virtuales que lo requieran. Y esto se consigue aplicando el mismo concepto de share que ya conocemos de los recursos de memoria y de CPU, con lo que si a una máquina virtual A (VM A) le aplico el doble de shares que a la máquina virtual B (VM B), la VM A tendrá el doble de throughput (medido en IOPS) y la mitad de latencia que la VM B.

¿Y cómo consigo configurar todo esto?

Pues para empezar necesito tener una licencia vSphere Enterprise Plus, que el almacenamiento sea gestionado por un único vCenter, que sea de tipo FiberChannel o iSCSI (de momento NFS y RDM no está soportado) y que el datastore no tenga extensiones (extents).

El siguiente paso será habilitar SIOC en el datastore que queramos monitorizar, y donde se alojarán las máquinas críticas. Esto lo podemos hacer desde las propiedades del datastore, en la pestaña de configuración del vSphere Client, y marcar la opción “Storage I/O Control” y establecer el umbral de latencia. Cuando hayamos habilitado SIOC en el datastore podremos ver el fichero iormstat.sf, que es el encargado de almacenar la información del clúster que necesita SIOC para controlar la latencia de las máquinas virtuales.

El último paso que nos queda sería la asignación de los valores de share para el almacenamiento en cada una de las máquinas virtuales, del mismo modo que lo haríamos con la memoria o la CPU, desde la pestaña de recursos, en la opción de “Disco”.

VMware ha publicado varios documentos en los que se muestra la diferencia entre datacenters con SIOC habilitado y sin él, y lo cierto es que es una opción muy a tener en cuenta, sobre todo en entornos donde existen máquinas virtuales críticas. Quizá la mayor ventaja de esta opción, además de la priorización de acceso al almacenamiento, sea la de hacer previsible el comportamiento del acceso al almacenamiento y evitarnos sorpresas desagradables en los picos de uso para las máquinas críticas, aunque evidentemente todo esto dependerá del entorno de cada uno.

Referencias:
http://virtualscoop.org/files/gulati.pdf
http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_SIOC.pdf
www.vmware.com/pdf/vsphere4/r41/vsp_41_resource_mgmt.pdf
http://www.yellow-bricks.com/2009/02/15/project-parda/
http://www.yellow-bricks.com/2010/10/08/sioc-tying-up-some-loose-ends/
http://blogs.vmware.com/performance/2010/07/sioc.html

Hola, soy Miguel Ángel Alonso y aquí estoy como cada martes con un nuevo capítulo sobre la virtualización.

En el tema de hoy, y siguiendo la estela de continuismo de Citrix Xenserver 5.6 de la semana pasada, hablaremos sobre el Switch Distribuido (DVSC Appliance) que salió a la par con XenServer 5.6.

Esta herramienta nos dará un control muy exhaustivo a nivel de la Red de nuestros Pools, Citrix Server o VMs de nuestro entorno, mediante gráficos de flujo, políticas de control de acceso y un largo etcétera.

El switch distribuido de Citrix necesita los siguientes requerimientos a nivel de hardware:

• 2 vCpus
• 2 GB de RAM
• 16 GB de Disco

Una vez nos hemos logado en la Web de Citrix y nos hemos dirigido a la sección de descargas de XenServer, en la versión Advanced, Enterprise o Platinum podremos descargarnos la Appliance de DVS para poder ejecutarla en nuestro entorno Citrix.

Llegados a este punto vamos a ver de manera calara y concisa mediante screenshots, la manera de instalar la Appliance y poder ver de forma generalizada los diferentes apartados de esta extraordinaria herramienta.

Una vez que te hayas bajado el appliance del switch distribuido para Citrix XenServer 5.6, el siguiente paso será importar nuestra Appliance dentro de nuestro Pool o servidor Citrix que elijamos. Así que buscaremos la ruta donde la descargamos y procederemos a importarla:

En el siguiente paso del proceso de importación, elegiremos el servidor que se hará cargo de levantar nuestro vSwitch distribuido (DVSC).

En este tercer paso, seleccionaremos el almacenamiento donde residirá el DVSC, y en un cuarto y último paso que aquí no he mostrado, deberemos elegir la/s tarjetas de red que queramos para poder conectarnos a nuestra Appliance.

Y aquí, tenemos una panorámica donde podemos ver ya nuestro DVSC, importado y en fase de arranque para poder empezar a parametrizarlo.

Ahora, desde la pestaña console de nuestro DVSC, podemos ver iniciada la Appliance y la IP desde donde gestionaremos vía Web todas las opciones.

Nos conectamos vía Web y nos aparecerá en pantalla la opción para logarnos dentro de nuestro DVSC. Como password y usarname utilizaremos admin.

Esta será la primera panorámica que tendremos al conectarnos por primera vez y donde podrás ver tres apartados principales en la columna de arriba:

1. Dashboard. Visión generalizada de consumo y uso de red con gráficos.
2. Visibility&Control. Acceso de manera detallada al Status, Control de Flujo, Control de Acceso y Configuración de los Puertos.
3. Settings. Parametrización de la Appliance (IP, DNS, Servidor NTP, logs, Updates, etc).

Aquí, podemos observar una visión clara del DashBoard donde como ya indiqué anteriormente tendremos una visión global de nuestras redes con sus gráficos detallados.

En el apartado de Visibility&Control, pestaña Flow Statics, podremos ver de manera detallada el flujo por Pool, server o VMs tanto entrante, saliente o bidireccional.

En el apartado de Visibility&Control, pestaña Acces Control podremos determinar políticas de carácter global o individual para el control de acceso del flujo de nuestras redes (DNS,DHCP,PXE,etc).

En el apartado de Visibility&Control, pestaña Port Configuration, podremos configurar las políticas de QoS (Calidad de Servicio) o RSPAN que habilita la monitorización remota de multiples switches a través de nuestra red.

Finalmente, desde la sección Settings y como indiqué con anterioridad, podremos configurar los parámetros propios de nuestro Switch distribuido.

Bueno, esto ha sido todo por el momento. Espero que os haya gustado. Nos vemos la semana que viene.

Ya esta disponible online el quinto episodio en nuestro Web TV show de virtualización en español, un nuevo programa de televisión web que es audaz, innovador y dedicado en exclusiva a los profesionales de la virtualización de sistemas y el cloud computing en español.

Esta semana tenemos una gran leccion de Aena, hablaremos sobre la renuncia por parte de Paul Maritz a la presidencia de VMware, contestaremos a una gran pregunta de un usuario relacionada con el “valor añadido” de Microsoft HyperV y su modelo de licenciamiento y descubriremos una utilidad increíble que te ayudara a gestionar tu centro de datos virtualizado y/o físico desde un único punto de gestión, el servidor de vCenter de VMware.

¿Y tú qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Cuál crees que es el motivo por el que Paul Maritz ha dejado la presidencia de VMware? Deja tu comentario en virtualizacion.TV o charlemos sobre ello en twitter.

Hola amigos, soy Florián Murillo y en la vida hay veces que te rindes. En mi caso me rindo cuando tengo la sensación de que nado en sentido opuesto al curso del río.

Esto es lo que me pasa con el licenciamiento de Microsoft, nunca se si lo que conozco todavía es verdad o ha vuelto a cambiar, supongo que por eso me escondo cuando alguien me pregunta sobre licenciamiento Microsoft, hay que ser un experto dedicado al licenciamiento de Microsoft para hablar.

Algo parecido pasa con el soporte de los productos de Microsoft en vSphere, me parecía un conocimiento inalcanzable para un simple mortal como yo, hasta que hace un tiempo, en un curso de vSphere, un alumno me pasó este link:

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm

Seleccionamos la aplicación y la plataforma de virtualización y nos dice si está soportada o no.

Ya no sufro en soledad. Gracias Miguel Angel

VMware está trabajando en un nuevo servicio de consultoría para la nube por el cual será posible desplegar una nube privada en cuestión de días, para ser más exacto, en 30 días.

También está disponible, a partir de esta semana, la arquitectura de referencia de VMware vCloud, un documento de arquitectura que has de seguir, y que VMware pone a tú disposición, para crear de una forma rápida y segura una solución vCloud.

La oferta principal de consulta de VMware es un nuevo servicio llamado vCloud Accelerator Service, el cual ha sido diseñado para ayudar a clientes a planificar, diseñar, configurar y hasta desplegar una nube privada.

Y ciertamente, ya lo aviso Paul Moritz, CEO VMWare, en la conferencia del VMworld 2010 en San Francisco, el cual dijo que las empresas tienden a adoptar primero el cloud computing privado dentro de sus propios centros de datos antes de aceptar plenamente el cloud computing público con proveedores tales como Amazon, Google o Rackspace.

¿Y tú qué opinas? ¿Cuáles son tus experiencias con el cloud computing? Deja tu comentario abajo o charlemos sobre ello en twitter.

PD. Si aún no sabes que es el cloud computing, te recomiendo que veas este video para salir de dudas. A parte de gracioso, es muy educativo.

Hola a todos. Soy Miguel Ángel Alonso y aquí estoy como cada martes para contaros algo nuevo del maravilloso mundo de la virtualización.

En el tema de hoy vamos a hablar sobre una Appliance de Citrix que salió hace muy poco tiempo, a la vez que salía a la lux XenServer 5.6.

Esta Appliance llamada Web Self Service y que como bien indica su nombre, es una herramienta para la gestión servidores XenServer, vía Web con el que puedes apagar, encender, suspender tus máquinas virtuales vía remota.

Es una instalación muy sencilla y aquí te mostraré los pasos a seguir y unos screenshots donde se verán reflejadas las diferentes opciones o posibilidades de la consola Web de Citrix para Xenserver.

Aquí, podemos ver una imagen del Appliance (plantilla .XVA) que descargamos desde Citrix en su sección de XenServer y la cual importaremos en nuestro entorno XenServer.

Nos colocaremos sobre nuestro pool de servidores Citrix o sobre alguno en particular si así lo deseamos, para que con el botón derecho seleccionemos la opción de importar. Le damos la ruta de nuestro archivo .xva y haremos click en next.

Seguiremos con el asistente y elegiremos en los pasos venideros, qué servidor se hará cargo de la Appliance (Plantilla .xva), en qué LUN de almacenamiento la guardaremos y qué red será la encargada de darle salida a nuestra consola Web.

Una vez que ya está importada, la arrancaremos y te mostrará la dirección web desde donde nuestra consola podrá ser gestionada.

Aquí, vemos una primera panorámica de lo que es la página principal de nuestra consola Web Self Service. Por defecto, el usuario es admin y la contraseña viene vacía a la espera de que nosotros le otorguemos la que queramos

Una vez dentro, lo aconsejable es ir hasta la opción de install checklist y seguir estos tres pasos sencillos:

1. Conectar a nuestro POOl de Servidores
2. Añadir usuarios creados por nosotros desde la propia consola o si los queremos añadir desde nuestro Directorio Activo
3. Finalmente definir que usuarios tienen acceso y a que VMs con la opción Share (compartir)

Y desde la sección de Workspace, podremos ver un listado de todas las máquinas virtuales que tenemos en nuestro POOL de Servidores Citrix XenServercon todas las opciones que ya indiqué anteriormente.

Y finalmente, aquí, podemos ver la panorámica final del acceso a la máquina virtual elegida para poder gestionarla remotamente en función de nuestras necesidades.

Bueno, creo que es una instalación sencilla y muy interesante para la gestión remota de entornos Citrix XenServer.

Esperando de corazón que os haya gustado, me despido de vosotros hasta la semana que viene.