Be virtual, My friend

El perfecto Thin Client

2012-01-09T19:19:00.003+01:00

Sorprendido me he quedado cuando he encontrado esta pequeña maravilla: el HDMI Dongle de Allways Innovating. Aunque está orientado al entorno doméstico/personal, la aplicación para entornos VDI me vino de inmediato a la cabeza. Primero veamos una imagen del juguete en cuestión:

Pues sí. Es justo lo que parece. Un dongle que conectamos a un monitor/televisor por HDMI, lo alimentamos por USB y.. ¡¡ voilá!!! todo un Android ICS (IceCream Sandwich) listo para funcionar. El juguete en cuestión viene equipado con lo siguiente:

Procesador Dual Cortex-A9 OMAP4, con velicidades de 1 a 1.8 Ghz
de 256 a 1 GB de RAM dependiendo del modelo
Almacenamiento MiniSD
SOporte Full HD y decodificación H.264
Wi-Fi 802.11 b/g/m, Bluetooth 2.1
Soporte NFC
Control de voz
Acelerómetro en el mando a distancia.

Las tripas del juguete nos muestran la simplicidad del dispositivo:

Y aquí el mando a distancia:

Nada más verlo, me imaginé conectándolo a mi televisor, asociando el teclado bluetooth y descargando el cliente PCoIP o ICA HDX.... el resto ya podéis imaginarlo.

Aquí os dejo un vídeo demostrativo de una demostración del juguete en cuestión en un televisor del hotel, hecha por Grègoire Gentil, CEO de la compañía.

Aparte del factor de forma, el uso de android como sistema operativo del thin client nos permite ofrecer un entorno autónomo, libre de licencias, sin plataforma de gestión propietaria y a un coste ridículo, a la vez que permitimos a nuestro usuario el uso de correo e internet (como poco) en su thin client (que sincronizará con su smartphone o tablet). Allways Innovating estima el coste entre los 50 y 80€, dependiendo de la configuración.

La portabilidad del mismo permite a los usuarios móviles acceder a su entorno profesional desde, por ejemplo, el televisor de un hotel.

No hace fata decir que será mi próximo gadget.

VNXe - Una agradable sorpresa

2011-11-29T11:44:00.001+01:00

Nunca he sido un fan de EMC. Siempre me pareció que estacompañía, junto con otras, era el exponente de un almacenamiento sin términomedio: O excesivamente simple o extremadamente complejo. Adicionalmente, suelomirar con desconfianza las gamas de productos incompatibles entre sí, ya quesiempre me pareció todo un desperdicio tener que “jubilar” una unidad aúnusable porque cierta característica no estaba disponible. Si hay que migrar unalmacenamiento se migra… pero tener que migrarlo porque el actual no soportacierto tipo de disco o cierta característica me saca de quicio.

Por otro lado, el tema de los “añadidos” tampoco ayudaba atranquilizar mi conciencia (con el consiguiente impacto en mis merecidas nochesde descanso): Por un lado compras el disco puro y duro. Si quieres iSCSI, añadetal modulito… si quieres CIFS, añade tal otro…. Si quieres deduplicar, ponletal appliance. Al final te das cuenta de que el módulo del CIFS no se entiendecon el de disco, sino que simplemente es un **ux + ***ba que usa la SAN comodispositivo, sin más relación entre ellos que la que tiene un servidor Windows conla SAN subyacente… con iSCSI, tres cuartas partes de lo mismo…. Lo quesignifica que no hay integración real entre protocolos, sino que estos sonaddendums colgados sobre un disco…. Un bug en la SAN y todo el edificio se cae.

La deduplicación es caso aparte, para peor…. Pones en mediode tus servidores y el disco un cacharro que en tiempo real (en algunos casos)deduplica o que de manera batch le da un repasón a la sopa de bits de la SANeliminando duplicidades. Pánico me da pensar qué pasa si el deduplicador falla(fallo físico o un bug) o si la SAN lo hace… entre ambos dispositivos no hayuna relación íntima que de coherencia a todo el montaje. Por supuesto, esta esla humilde opinión del que suscribe, totalmente discutible.

Filesystem vs RAW disk.

Que la SAN sólo entienda de RAIDs y que el dispositivo añadidola use como tal plantea una dependencia que, a mi parecer, no es nadatranquilizadora en entornos multiprotocolo. Son elementos no integrados en elque uno de ellos (el añadido) tiene consciencia limitada del otro (La SAN) y elotro ve al añadido como un cliente más al que servir disco. De ahí que lassoluciones basadas extremo a extremo en filesystem siempre me hayan parecidomás atractivas.

En el entorno filesystem la propia SAN gestiona el discocomo un sistema de ficheros, con todas las medidas de protección y corrección deerrores que un filesystem puede ofrecer, siendo consciente esta de todas lasoperaciones que realizamos a nivel superior: Cuando ofrece LUNs, es la propiaSAN la que crea la LUN como un fichero en su filesystem y la que exporta víaiSCSI o FC a los host conectados, controlando extremo a extremo (desde elfirmware del disco hasta las reservas SCSI) la comunicación. Cuando ofrece CIFSo NFS, la propia SAN es la que habla ese idioma, coordinando todas las accionesdesde el cálculo de la paridad del RAID hasta el oplock CIFS. Cuando deduplica,la SAN es consciente de la estructura y arquitectura del dato, de donde lo poney donde ha de ir a buscarlo.

Con esto no reniego de la SAN tradicional. Evidentemente hayentornos donde el rendimiento es crucial y los IOPS son la única cuestión endisputa. Nadie discute (salvo los PDF delos fabricantes afectados) que la simplicidad (y gestionar bits y bites es mássencillo que gestionar todo un filesystem) suele traducirse en rendimiento. UnaSAN tradicional suele requerir de menos mecanismos de mejora de rendimiento(cachés, algoritmos de lectura, etc) que permiten volcarse en una única labor:servir streams de datos vía FC o iSCSI, dejando los niveles superiores deorganización a los host. Evidentemente hay un modelo de SAN para cadanecesidad.

Vamos con VNX..

Tras la adquisición de Isilon, EMC presenta la series VNXe yVNX, donde en boca de los analistas, unifica Clariion y Celerra, presentando unproducto dentro de la categoría denominada Almacenamiento Unificado. EMC presentael producto en tres versiones, cuyas diferencias se ilustra en la siguientetabla.

Como puede observarse, la serie VNX está orientada a cubrirlas necesidades de almacenamiento independientemente de los requerimientos detamaño o tecnología.

EMC se lo ha tomado en serio con VNX, ofreciendo un rango demodelos que cubre desde lo más elemental (unidades departamentales y/o SMB)hasta configuraciones multipetabyte.

Centrándonos en VNXe, además de las característicasdescritas, existen una serie de bundles de software que implementancaracterísticas avanzadas que compiten con el rey del almacenamiento unificado,NetApp.

Al tajo..

Por aquí os dejo un par de vídeos disponibles sobre la configuración de la unidad.

El primero describe cómo configurar la unidad una vez instalada físicamente, mediante el uso de la utilidad "Connection nUtility"

Algo que resulta de agradecer es la configuración sin requerir acceso por consola. Así mismo, la posibilidad de guardar la configuración en un usb para aquellos dispositivos a los que no tengamos acceso a través del mismo segmento LAN supone una gran ventaja.

En segundo, veamos nuestro primer contacto con EMC Unisphere...

Para los acostumbrados a lidiar directamente con menús/CLI de configuración, el asistente de VNX puede parecer en extremo simple, pero salvo en la configuración de los pools (donde la VNXe impone sus criterios), resulta rápido y efectivo, guiando la entrada de los datos de configuración sin (casi) posibilidad de error.

Nótese la capacidad de configurar desde el asistente parámetros avanzados de los iSCSI targets y Servidores de ficheros como la interfaz que dedicamos e incluso la VLAN.

Una vez configurada, veamos uno de los aspectos más sorprendentes de la unidad: La capacidad de integrarse con los entornos que van a hacer uso del almacenamiento.

El siguiente vídeo muestra la asignación de almacenamiento a un entorno vSphere

La integración con vcenter resulta más que interesante a efectos de simplicidad de instalación y de configuración optimizada. Resulta interesante resaltar la posibilidad de decidir qué uso le daremos al datastore creado pudiendo permitir la creación o no de snapshots. Así mismo, la integración queda patente en la capacidad de la unidad para "ver" las VM que alberga.

Os invito a navegar por Youtube en la cantidad de vídeos demostrativos de las capacidades de la unidad (Buscad VNXe).

Mi impresión.

Rápida, sencilla, eficiente y BARATA! Una unidad VNXe3100 con doble controladora y el pack básico de software, equipada con doce discos SAS de 15K revoluciones ronda los 14K.

Rendimiento bajo iSCSI.

El rendimiento es fenomenal, incluso combinando cargas iSCSI y CIFS. Veeam machaca todos los días la infraestructura sin impacto aparente en el rendimiento. En procesos de clonado de VM, la unidad, con una sola interface por controladora dedicada a iSCSI, y la carga de producción, mueve del orden de 1GBytes por minuto, lo que nos da unos 230Mbit por segundo.

Rendimiento bajo CIFS.

También resulta impresionante, en especial cuando el acceso habitual de los usuarios coincide con procesos de copia (un backup con CA Arcserve y/o una copia sobre una unidad Iomega PX4.

Gestión.

La verdad es que para cualquier techie, la unidad es decepcionantemente simple de configurar (lo que supongo que tendrá sus consecuencias con el fine tunning, que por suerte no me ha tocado hacer). Respecto al CLI (Command Line Interface), parece que la unidad no lo ofrece directamente, sino a través de un aplicativo instalable en un equipo de gestión Windows o Linux (e incluso bajo ESX), el VNXe Unisphere CLI... no obstante, en las opciones de servicio, existe la posibilidad de activar ssh... no es que permita hacer demasiado, pero el banner de acceso es digno de verse. Otro aspecto sin duda sin desperdicio es como apagar la unidad (reproduzco literalmente):

"How to power cycle the VNXe system safely"

ID:	emc263167
Usage:	1
Date Created:	03/08/2011
Last Modified:	05/23/2011
STATUS:	Approved
Audience:	Customer

Knowledgebase Solution

Question:	How to power cycle the VNXe system safely
Environment:	Product: VNXe Series
Environment:	Product: VNXe3300
Environment:	Product: VNXe3100
Problem:	sp_power_cycle_dae
Problem:	sp_power_cycle_recovery
Problem:	Power cycle the system
Fix:	Power-cycle the entire VNXe system to attempt to resolve minor or moderate problems with the storage processors (SPs), I/O connections, disk-array enclosures, the system software, and other system components. Make sure that all system components are firmly seated in their proper position, and that all latches are closed and retaining screws are secure before you power cycle the system. This procedure involves placing the SPs in Service Mode. All hosts will lose access to the system. Ensure all host operations that require the VNXe system have completed to prevent data loss. Overview - This procedure involves doing the following in this order: 1. Place both SPs in Service Mode. 2. Disconnect the power cables from the power supplies on the disk-processor enclosure (DPE) to power down the SPs. 3. Disconnect the power cables from the power supplies on each disk-array enclosure (DAE) to power them down. 4. Reconnect the power cables to the power supplies on each DAE to power them up. 5. Reconnect the power cables to the power supplies on the DPE to power up the SPs. 6. Reboot each SP to return them to Normal Mode. Prerequisites Before performing this procedure, it is recommended that you disconnect all network shares and iSCSI virtual disks from each host to prevent data loss. Once the system is fully powered-up, you can reconnect the hosts to these storage resources. Warning! Working with hardware may cause electrostatic discharge that could damage your hardware. Before working with any hardware, read the following VNXe online Help topic: "Precautions to follow before removing or replacing a component." Procedure To power-cycle the entire system: 1. In Unisphere, click Settings > Service System. 2. Enter the Service password to access the Service System page. 3. Under System Components, expand Storage System. 4. Select the SP acting in the non-primary role. For assistance in determining which SP is primary and which is non-primary, see VNXe online Help topic "Determine a Storage Processor’s role" or reference Knowledgebase article emc265521. If your system has one SP, the name is SP A. 5. Under Service Actions, select Enter Service Mode. 6. Click Execute service action to place the SP in Service Mode. 7. In the confirmation dialog box, click OK. Do not perform any actions in Unisphere until this operation has completed. 8. Wait at least 10 minutes while the SP enters Service Mode. 9. Select the SP and the Mode field indicates that the SP is in Service Mode. By default, the Service System page will refresh every 60 seconds to display the current status and mode of the SP. Also, the Fault LED on the SP flashes amber and blue. For information about the LEDs, see VNXe online Help topic, LED indications. If your system has one SP, skip to step 15. 10. Under System Components, select the SP acting in the primary role. 11. Under Service Actions, select Enter Service Mode. 12. Select Execute service action to place the SP in Service Mode. 13. Wait at least 10 minutes while the SP enters Service Mode. 14. Select the SP and the Mode field indicates that the SP is in Service Mode. 15. Close your web browser to exit Unisphere. The next steps involve physically working with the VNXe system hardware. Optionally print this topic so that you can read the steps from a printed copy. 16. Disconnect the power cables from the DPE power supplies. 17. Wait at least 60 seconds to ensure each SP has fully powered-down. The green Power Status LED on each SP turns off. 18. Disconnect the power cables from the DAE power supplies. 19. Reconnect the power cables to each DAE power supply to power them up. 20. Reconnect the power cables to each DPE power supply to power up both SPs. 21. Wait at least 10 minutes while both SPs power up. The green Power Status LED on each SP turns on. The Fault LED on each SP flashes amber and blue to indicate that the SP is still in Service Mode. 22. Go to your computer and open a web browser. 23. Log in to Unisphere. 24. Enter the address for Unisphere. Because both SPs are in Service Mode, you can only log in with the Service password and only certain pages will be accessible. 25. Enter the Service password to log in to the Service System page. 26. Under System Components, expand Storage System. 27. Reboot SP A and wait 20 minutes for it to return to Normal Mode. When both SPs are in Service Mode, always return SP A to normal operation first, to avoid management software conflicts. Once SP A is operating normally, you can return SP B to normal operation. 28. Reboot SP B and wait 20 minutes for it to return to Normal Mode. For more information on rebooting an SP, see VNXe online help topic "Reboot a Storage Processor." 29. When both SPs are in Normal Mode, refresh your browser, or follow the on-screen instructions, to bring the system software out of Service Mode and restore Unisphere to full functionality. 30. Log in to Unisphere with your regular user account to gain access to all pages. If power-cycling the system does not fix the problem, go to the EMC Online Support website page for all support options. Also, see VNXe online help topic, "Getting assistance and information."

Como he dicho.... Sin desperdicio. !Procurad no tener que apagarla a menudo!

Resumen.

La serie VNX(e) es una buena compra, y un producto a evaluar tanto si tenéis necesidades de consolidación en oficinas remotas como en entornos centrales medios o grandes.

Hasta otra.

Nuevo Blog: Openredes - Networking Open Source

2011-11-03T10:21:00.002+01:00

De la mano de Herminio Noguera Ruiz nos llega Openredes, un blog focalizado en networking Opensource, con una clara preferencia por Vyatta, un router basado en software que personalmente recomiendo. ¡¡Sin desperdicio!!

Citrix VDI in a Box - Parte I

2011-10-30T17:34:00.000+01:00

Si ha habido un producto disgresor y con una orientacióndiametralmente opuesta a la de los “espadas” en esto de la virtualización deldesktop, ha sido Kaviza VDI in a Box. En pocas palabras, frente a la necesidad de infraestructuras más o menospesadas que engloban las propuestas de fabricantes como Citrix, VMware y otros,Kaviza apostó por la simplicidad.

Conocí kaviza de la mano de Guise Bule, uno de los grandes en esto de los virtual desktops, y de su compañia, tuCloud, que me invitaron a conocer y evaluar VDI in a Box cuando todavía era Kaviza. No sólo me invitaron a conocer el producto (cosa que jamás podré agradecer lo suficiente) sino a revisar su implementación como plataforma IaaS/DaaS en sus clientes, entre los que se cuenta el Laboratorio Nacional Lawrence Livermore (Lawrence Livermore National Laboratory), donde VDI in a Box gestiona un parque de más de 2000 desktops simultáneos que dan soporte a 5000 usuarios.

El producto se presentaba como un simple appliance virtualque contenía todo lo necesario para echar a andar un entorno VDI clásico,aportando la novedad de que no requería de infraestructura compartida. Por otrolado, y bajo la filosofía de ¿para qué entrar en una guerra que es difícilganar?, llegaron a un acuerdo con Citrix para usar HDX como protocolo depresentación de alto rendimiento, sin olvidar RDP para entornos menos exigentesen lo que a presentación se refiere. Por otro lado, en lugar de apostar porinfraestructuras de virtualización centralizadas, heredadas de los entornos deservidor y que el transcurso del tiempo ha demostrado que no siempre soneficientes, Kaviza apostó por el VDI distribuído, donde para nada se hablaba de entornoscentralizados (tipo VMware View, Xendesktop o similares) sino en una malla deinfraestructuras independientes sincronizadas entre sí, con infraestructura debajo coste y sin tecnología compartida… básicamente algo en la filosofía deldesktop de usuario: máximo rendimiento al menor coste.

Kaviza fue adquirida por Citrix este año, dentro de laimpresionante campaña de adquisiciones de esta última, entre las que contamos,además a Netviewer, EMS-Cortex, cloud.com, Ringcube y Sharefile.

Citrix ha renombrado el producto como Citrix VDI in a Box, ylo ha posicionado en el tramo SMB, creando incluso una línea de negocio, dondeha colocado a KrishnaSubramanian, anterior CCO de Kaviza, como responsable de la unidad.

Arquitectura de VDI-in-a-box.

A diferencia del resto de productos, VDI-in-a-box gestionahosts, no infraestructuras. Cada hypervisor dentro de un despliegueVDI-in-a-box está gestionado individualmente por un appliance, que toma elcontrol del mismo y lo incorpora al Grid, unidad única de gestión del entorno.Cada appliance gestiona y controla el hypervisor , integrando los recursos delmismo dentro del conjunto de los hypervisores, asegurándose adicionalmente deque ese hypervisor ofrece las VM, plantillas y configuraciones del conjunto dela infraestructura. A este conjunto, VDI-in –a-box le llama Grid.

Despliegue típico de Citrix VDI in a Box

El grid es una entidad conjunta de gestión, por lo que noimporta en qué appliance configuremos qué parámetro o característica para quetodo el Grid quede configurado. Cuando definimos una imagen de un desktop, estaes automáticamente replicada a los servidores miembros. Así mismo, el Grid estolerante a fallos, y no depende de ninguno de sus miembros para sobrevivir(salvo, evidentemente, del último). Comparemos ahora con una estructuratradicional que ofrezca el mismo nivel de tolerancia:

Despliegue típico VDI

Grid vs Entornos tradicionales.

Como observamos, los productos tradicionales requieren deuna total interrelación entre distintos subsistemas externos totalmente alentorno VDI. Tradicionalmente, el bróker VDI no “habla” directamente con loshypervisores (algunos, de hecho, no lo permiten), sino con la plataforma degestión de virtualización, que para alcanzar el entorno de redundanciarequerido, ha de usar productos de alta disponibilidad y/o almacenamientocompartido (clásico cluster, que tampoco ofrece el nivel tolerancia requerido:las bases de datos y la configuración siguen estando en un solo sitio). Asímismo, es necesario cierto nivel de tolerancia en los brokers, ya sea mediantesu clusterizado o mediante la réplica de la base de datos.

Por otro lado, existe la dependencia del bróker respecto aDirectorio Activo. Si este no autentica a un usuario que intenta acceder a sudesktop, no hay credenciales cacheadas que valgan…. Aunque posteriormente eldesktop sí te deje acceder con ellas. También el uso mandatorio que algunosbrokers realizan de Active Directory incrementa la complejidad de los entornos,especialmente aquellos donde AD no se usaba o donde sólo se usaba por lascapacidades de gestión del desktop (Despliegue o control con GPO’s), que dentrodel mundo VDI pueden no ser necesarias. Recordemos que Active Directoryrequiere CAL (ClientAccess Licenses)

Al gestionar una infraestructura común, el uso dealmacenamiento compartido es poco menos que mandatorio: Ya sea SAN o NAS, tantolas templates, las imágenes y los propios desktops deben ser accesibles portodos los hipervisores. Evidentemente un entorno tan crítico como el desktopdel usuario debe tener cierta protección en lo que al almacenamiento se refiere.

Todos estos elementos complican la gestión e incrementan loscostes, lo que a veces obliga a integrar el entorno VDI dentro de nuestroentorno de virtualización de servidores, lo que no suele ser buena idea, comoapunté en la serie Repensando VDIcuando hablé de, entre otras cosas, de los requerimientos de entrada/salida deun entorno VDI.

VDI in a box, en resumen, opera en un modo muy similar aactive directory: Ningún servidor es imprescindible para el funcionamientodel entorno, algo a mi parecer muy deagradecer.

Gestión.

Otro de los aspectos diferenciales de VDI in a Box es lacapacidad de gestión. Al eliminar elementos compartidos, se elimina,consecuentemente, su gestión. No hay SAN/NAS que gestionar (si quieres que nola haya, claro), ni servidores de gestión de infraestructura virtual (vCenter,SCVMM or XenCenter)… simplemente desktops y usuarios. Esto tiene capitalimportancia cuando hay que delegar loa gestión del entorno VDI a personal nofamiliarizado con la infraestructura virtual. Al no compartir másinfraestructura que la red, los administradores del entorno virtual como losdel almacenamiento no tienen que dedicar tiempo extra a la supervisión de lainfraestructura de escritorios. En pocas palabras, cada uno a lo suyo y en losuyo.

Seguiremos hablando de VDI in a Box…

Google presenta Remote Desktop para Chrome

2011-10-10T17:00:00.002+02:00

El viernes pasado Google presentó la beta de Chrome RemoteDesktop , un plug-in para chrome que permite acceder a la consola de un equiporemoto desde otro sin necesidad de instalar un agente.

La versión actual requiere la presencia de un usuario a amboslados de la conexión, es decir, tando del equipo controlador como delcontrolado. La conexión está autenticada por una clave de un solo uso que segenera en el extremo controlado y que debe ser comunicada al usuario del extremocontrolador. Según indica Google, esta aplicación no es más que un demostradorde tecnología que demuestra las capacidades de Chrome, pero no deja de parecerun “aviso a navegantes”, especialmente después de probarlo y observar que elrendimiento es superior a otras tecnologías de control remoto.

Para los más versados en las intimidades de desarrollo,parece que este plugin se basa en una conexión P2P establecida con libjingle, combinadocon una implementación de PseudoTcpen libjingle para proveer conexiones estables, todo sobre SSL. En lo referentea la presentación, usa protobuf para datos estructurados y framing y losgráficos con codificados mediante el formato VP8.

Independientemente de la tecnología, queda claro que Googleha desplegado todo su arsenal de armas en Chrome para demostrar que lo suyo nosólo es la nube.

La tecnología en sí no es nueva: Ericom, Citrix, Installfreey ThinVNC (por nombrar algunos que ya disponen de cliente) ofrecen algosimilar. Otros, como VMware, están trabajando en ello. Lo curioso es que todasestas compañías trabajan en cierta manera para el sistema operativo, por lo queno es de extrañar que ofrezcan el producto. Sin embargo, Google, salvo por Android y Chrome OS, nunca se ha embarcado en este “percal”, fijando su objetivo claramente en la red... Entonces ¿A qué viene esto?

Por lo pronto, LogmeIN y Teamviewer ya tienen un competidora la altura (por mi experiencia, hasta superior), aunque no creo que laintención de Google sea, precisamente, embarcarse en este mercado. ¿Estaremos alas puertas de un Windows en la nube de mano de Google?

Virtualización de Aplicaciones / Parte 2

2011-09-27T13:38:00.001+02:00

Tras un par de semanas peleándome con unos cuantos brokers de vDesktops que me han consumido hasta el extremo, volvemos con las aplicaciones virtuales.

Decíamos que la virtualización de aplicaciones mantiene una íntima relación con los entornos VDI, especialmente si requerimos que tanto las aplicaciones como los perfiles de usuario se independicen del sistema operativo del vDesktop con objeto de evitar personalizaciones que nos eviten reproducir en entorno virtual los problemas de los entornos físicos. Por otro lado, la necesidad de que el usuario acceda al software que necesita cuando lo necesita y donde lo necesita puede ser solventada sin necesidad de instalar todas las aplicaciones en la imagen maestra.

Como efecto colateral, y dependiendo del producto usado, podemos darle al usuario una versión "para llevar" de una aplicación y sus configuraciones; es decir, el usuario puede llevarse en un pen drive su outlook con su configuración o sus PST. Adicionalmente, virtualizar las aplicaciones en modo de aislamiento permite el movimiento de esta entre un entorno de desktop virtual y desktop físico.

En mi caso particular, y en el de más de un cliente, la coexistencia de múltiples entornos de trabajo (Desktop virtual, el irrenunciable desktop físico y el portátil), junto con la necesidad de instalación de aplicaciones no corporativas o de uso personal, la posibilidad de virtualizar, por ejemplo, Google Chrome (con sus capacidades offline) hacen de esta opción una manera fácil y simple de mantener para permitir desktops limpios de configuraciones y aplicaciones de usuario.

Profundizando, si ejecutamos la aplicación virtualizada en una unidad de red (y hemos configurado el VOS para que use la misma carpeta que el ejecutable), nos bastará un simple copy para mantener actualizado el VOS (que al fin y al cabo es lo que nos interesa) en un dispositivo extraible o nuestro portátil. Si usamos dropbox, podemos mantener nuestras vApps disponibles en cada uno de nuestros dispositivos.

En un entorno más corporativo, podemos usar ficheros sin conexión para el mismo fin.

Con un poco de trabajo (siempre digo que para eso nos pagan), podemos separar nuestro perfil, tanto de usuario como de aplicaciones), del PC que usamos.

Virtualizar las aplicaciones con productos como Cameyo puede ser una manera de reducir los costes de implementación de infraestructura de desktop virtual.

En mi particular caso, tengo versiones virtuales con Cameyo del vSphere client (un ENORME paquete con todas las versiones desde la 2.5 a la 5), putty (por esa mala costumbre de guardar los host en el registro que tiene este), Bitvse Tunnelier (lo uso cono "gateway" SSH). En el paso de el putty virtualizado, descansa en mi dropbox, con lo que consigo mantenerlo replicado entre todos mis desktops. Así mismo, y en otro escenario de aplicación quizá más mundano, mantengo una copia local de mi correo usando un Thunderbird virtualizado, que descarga periódicamente mis cuentas (profesionales y particulares) de Google (La nube mola, pero la nube con copia local mola más).

Os animo a probar Cameyo. Desde luego no es ThinApp.... pero da el tipo.

Un saludo.

Nota técnica: instalado en agente Kaviza en Windows 7

2011-09-26T13:21:00.002+02:00

Para los que tenéis plantilla optimizada para VDI donde esté desactivado el firewall y Media Center, recordaros que es necesario que tanto el firewall (y los servicios de los que depende) estén en ejecución cuando instaléis el agente de desktop virtual de Kaviza.

Este se compone de dos elementos: Uno, el Agende VDI de Citrix y el propio de Kaviza.

El componente de Citrix requiere que el Firewall de Windows esté en ejecución, y el agente de Kaviza requiere que el componente Media Center esté instalado.

De no estar el firewall activado, la instalación del Agente VD de Citrix fallará, dando las habitualmente claras, concisas y nada extensas a las que Citrix nos tiene habituados.

Un abrazo.

Virtualización de Aplicaciones / Parte 1

2011-09-07T15:04:00.002+02:00

Junto con la de servidores, la llamada virtualización deaplicaciones es uno de las tecnologías que en estos últimos años ha acaparadomás post y notas técnicas. La tecnología VDI también ha impulsado la evoluciónde las soluciones que permiten ejecutar una aplicación sin instalarlapreviamente.

Quien, como yo hasta hace poco, reinstalaba su PC cadacierto tiempo, conoce la sensación de pérdida de tiempo que supone lainstalación de las aplicaciones. En casi cualquier sistema operativo, prácticamente todas las aplicacionesmodifican el o el estado del mismo, o su configuración o sus archivos. En elparticular caso de Windows, la instalación de una aplicación suponemodificaciones en las dll registradas, controles, entradas del registro y unabuena cantidad de modificaciones en el árbol de ficheros. Así mismo, estasmodificaciones no sólo afectan a la aplicación, sino al estado global delsistema, lo que puede impedirnos la instalación de otras o alterar sufuncionamiento. Por ejemplo, mantener distintas versiones del browser deinternet es a menudo imposible.

Por otro lado, una vez instalada, y como una buena novia,desinstalarla suele dejar trazas en nuestro sistema (basta echar un ojo alsiempre creciente – como la prima de riesgo – directorio c:\windows\winsxs paracomprobarlo), y en ocasiones estas trazas pueden interferir con futurasaplicaciones.

En entornos VDI, este comportamiento supone un dolor decabeza adicional, ya que estas dificultades pueden obligarnos a tener quetrabajar con múltiples imágenes maestras, cada una con la configuraciónnecesaria, lo que puede convertirse en una auténtica pesadilla a la hora deactualizar copias maestras.

Tradicionalmente, soluciones como Citrix Metaframe (hoyXenApp) y Terminal services nos ayudaban en este problema: Desplegábamos laaplicación en los desktops mediante una sesión con el servidor que lahospedaba. Esto desplaza el “problema” a una ignota granja de servidores endonde los nunca totalmente considerados ingenieros Citrix/TS toreaban el problema como buenamente podían(hay aplicaciones que deberían ser usadas como prueba de cargo en un juiciocontra sus desarrolladores) la coexistencia. Muchas veces, para bien o paramal, no hay más remedio que añadir servidores a la granja.

Por otro lado, aparecieron soluciones basadas en elstreaming de la aplicación al desktop bajo demanda. Este es el caso de SoftGrid(renombrada App-V tras ser adquirida por Microsoft). Softgrid actúa comoservidor de los ejecutables y ficheros relacionados con las aplicaciones,desplegando su entorno completo de ejecución (aplicación, dlls y demás) en elcliente según fuera requerido.

Desafortunadamente, siempre hay aplicaciones, ya por diseño,ya por requerimientos, que no son susceptibles de ser desplegadas por estemedio y siempre terminan instaladas en el PC local, o lo que es peor, en un VDIdedicado y personalizado (que requiere otra serie de medidas, como son elbackup específico)

Frente a estas tecnologías, que desplazan de una u otramanera los problemas inherentes a la instalación de aplicaciones hacia elservidor, nace otra visión.

¿Qué una aplicación modifica el sistema? Pues usemos una capa deabstracción entre la aplicación y el sistema que recree los requerimientosespecíficos de la aplicación durante su ejecución y que estos desaparezcan aldejar de utilizar la misma. Es lo que normalmente es conocido como“virtualización de aplicaciones”, aunque yo veo más acertado denominarlo como“empaquetado del entorno de ejecución”.

Este método requiere de la ejecución de una delgada capa desoftware que recree el entorno que la aplicación instalada espera encontrar:dll, entradas de registro y modificaciones del filesystem.

Esta capa “aprende” las modificaciones durante el pasoprevio de la paquetización: es decir, la instalación de la aplicación serealiza sobre un sistema operativo “limpio” y es monitorizada por un aplicativoque toma una “foto” del sistema antes de la instalación y otra después,comparando ambos entornos. El diferencial se empaqueta en un archivo que, ademásde este, incluye la capa de software antes mencionada. Dependiendo del productousado, el resultado será un ejecutable o un ejecutable más un archivo quecontiene ese diferencial.

Cuando ejecutamos este, el Appvisor (llamemos así a la capade abstracción del sistema operativo tal como lo hace el “hypervisor” delhardware) genera en base al contenido del archivo de imagen diferencial elentorno que la aplicación espera, y procede a ejecutarla. El AppVisor introduceconceptos como el registro virtual (lo que le permite añadir las entradas yconfiguraciones que la aplicación espera encontrar y/o espera escribir) y unsistema de ficheros virtual (donde la aplicación encuentra y/o escribe lo queespera encontrar y espera escribir). La suma de estos dos conceptos es lo queviene siendo llamado VOS o Virtual Operating System.

En lo referente al registro virtual, el appvisor simplemente“incrusta” las claves de registro que ha generado la aplicación de forma queesta pueda encontrarlas tal y como si estuviesen en el registro del sistema. Enlo referente al filesystem, el appvisor hace algo parecido al chroot de unix:Cambia el path relativo del filesystem virtual a absoluto… es decir, si ejecutamos nuestra aplicación virtual enc:\app\virtual\app1 y la aplicación fue instalada en c:\archivos deprograma\app1, el hypervisor hace ese “chroot” para que la aplicación encuentrelos ficheros que necesita (ejecutables, dll, etc) donde espera encontrarlos.

Como resumen, vaya esta gráfico:

Sin ánimo de entrar en polémicas sobre cuál de lasaproximaciones descritas es la mejor, suena evidente el hecho de que estaúltima no requiere de servidores o infraestructura externa al propio desktoppara ejecutar una aplicación virtual y así evitar el inconveniente de lasinstalaciones locales.

Modos de interacción con el sistema.

Adicionalmente, el appvisor suministra varios modos deinteracción con el sistema que ejecuta la aplicación virtual, basadas en lapermanencia de los cambios que está puede o no realizar en el sistema operativodonde se ejecuta.

Modo integrado: En este modo, los cambios que la aplicaciónhaga tanto en el filesystem (en lo referente a archivos de datos generados porla misma, no por sus dll o ejecutables) se realizan en el sistema operativoreal. Esto permite, por ejemplo, que se graben entradas de registro o ficherosde datos que permanecerán en sistema operativo tras cerrar la aplicación. En unejemplo real, un Outlook virtualizado dejaría el PST en el disco duro delWindows donde lo ejecutemos. Así mismo, las modificaciones que la aplicaciónrealice al sistema (ficheros o registro) quedarían plasmadas en el sistema. Porotro lado, la aplicación virtualizada tendría acceso a los archivos del sistema(Un Outlook virtualizado, por ejemplo, podría acceder a un documento existentepara enviarlo como fichero adjunto). Si ese Outlook descargase un adjunto,podría hacerlo en el filesystem del sistema operativo.

Modo Mixto: En este modo, la app virtual tiene acceso delectura al filesystem real, pero todos los cambios que realice en el mismo,sólo se reflejarán en el VOS. Por seguir el ejemplo del Outlook, este podráadjuntar ficheros existentes, pero si descarga un adjunto, este se almacenaráen el VOS. Lo mismo aplica a entradas de registro.

Modo aislado: En este modo la aplicación virtual no tienevisibilidad del sistema operativo. Sólopodrá acceder a los archivos contenidos en el VOS. Los datos generados por lamisma serán almacenados en el VOS. En este modo, el Outlook virtual no podríaacceder a un documento previamente almacenado en el disco del PC ni podría escribir en el mismo.

Veamos todo esto en una tabla resumen:

Modo	Visibilidad del sistema	Modificación de la app virtual	Modificación del sistema	Nuevos elementos
Mixto	Completa(*)	VOS	VOS	VOS
Integrado	Completa(*)	VOS	Sistema	Sistema
Aislado	No visible	VOS	No accesible	VOS

(*) En caso de coincidencia de un elemento en la aplicaciónvirtual y en el sistema operativo, prevalece siempre el contenido del filesystemdel VOS. Ejemplo Outlook: Si existe en el sistema la carpeta c:\attach ytambién existe en el VOS, prevalecerá el contenido de este último.

Cada producto implementa estas características con ligerasvariaciones, pero básicamente todas las aproximaciones son similares.

VOS. ¿Cómo gestiona el filesystem?

Bien. Vamos a centrarnos en el sistema de ficheros. Una aplicación “real”, es decir, instalada enel sistema operativo, toma como referencia la unidad lógica (nuestro C:, D:etc) del sistema donde se ejecuta para interacturar con los datos. Es decir…sabe que está instalada en c: o d: y que los datos han de ser guardados enestas unidades. En lo referente a lainstalación, este path suele ser inamovible: Si movemos la aplicación dec:\Program Files\app1 (que es donde la instalamos) a d:\program files\app2, lomás probable es que perdamos un par de horas en un académicamente instructivo pernada práctico paseo por el registro y por las utilidades de Windows pararendirnos horas más tarde. El appvisor “engaña” a la aplicación mostrándole unao varias unidades lógicas que, dependiendo del modo de empaquetado (ver tablaanterior) puede o no coincidir con las existentes en el sistema operativoreal. En modo integrado, por ejemplo, laaplicación modificará el fichero “c:\windows\system\readme.txt” en sulocalización original. En modo mixto, no podrá acceder a ese fichero, ya que elappvisor le “redirigirá” a la carpeta contenida en el VOS, y en modo aislado,no podrá acceder a ese fichero. El appvisor introduce un filtro que,dependiendo del modo, redirigirá hacia el sistema operativo real o a unacarpeta que contiene el sistema operativo virtual. Esta localización variarádependiendo del modo y el producto. Veamos un gráfico.

Esta imagen ilustra un posible escenario aislado. Como puedeobservarse, la aplicación virtual al ser ejecutada e invocada por el appvisor,crea una estructura de directorios bajo la carpeta donde hayamos copiado elejecutable (esto también puede variar) y despliega el filesystem virtual. Apartir de ese momento, la app virtual verá el contenido de la carpeta VOS comoel filesystem del sistema.

Esto nos permite, por ejemplo, llevarnos nuestro manido Outlookvirtual (con sus pst) en un pen drive…. O colgarlo de una unidad de red. ¿No osparece que para VDI esta última posibilidad resulta de interés?

Jugando con los diferentes modos, conseguiremos mayor omenos visibilidad de los archivos generados por la app virtual desde otrasaplicaciones (virtualizadas o no)

El lado oscuro.

Por supuesto, tiene sus contras. No todas las aplicacionesadmiten ser virtualizadas, o requieren de especiales opciones de instalación otuneo posterior del paquete para que funcionen. Los productos que requierenactivación (especialmente los de Microsoft) suelen requerir de tunningespecífico.

Así mismo, cuidado con los updates. En muchos casos,actualizar una aplicación no puede ser delegado a su propio mecanismo deactualización y es posible que se requiera el despliegue de una nueva versiónde la aplicación virtualizada. También el licenciamiento puede verse afectao,especialmente si no disponemos de licenciamiento enterprise (una sola key oactivación para toda la compañía) y la aplicación pide esta durante el procesode instalación (léase Office 2003 retail, por ejemplo).

Productos comerciales.

Tenemos los siguientes (hasta donde yo sé, claro).

Appzero
Argo Application installer
BoxedApp
Cameyo
InstallFree
JauntePE
Microsoft v-App (Modo standalone)
Ringcube MojoPack
Symantec Workspace Virtualization
VMware ThinApp
LanDesk Application Virtualization
MoleBox

Ya está bien por hoy. En el próximo post hablaré de laíntima relación entre la tecnología de desktop virtual y la virtualización deaplicaciones.

Perlas de PIPO E2H: Corriendo Xen en ESXi5

2011-09-03T22:52:00.000+02:00

Pues sí, el gran José Luis Gómez Ferrer de Couto nos regala una perla sobre como instalar XenServer con soporte para VM windows en ESXi. Hasta la versión 4 de vSphere, era posible virtualizar incluso el mismo ESX, siempre que no requirieramos de las extensiones de virtualización dentro de la VM (Intel-VT o AMD-vt). Recordemos que estas extensiones son necesarias para la ejecución de máquinas virtuales de 64 bits, tanto en ESX como en Xen. Por otro lado, Hyper-V lo necesita obligatoriamente, por lo que al menos por esta razón, Hyper-V no era virtualizable. Entre las nuevas características de ESXi 5.0 parece estar la de permitir que un guest acceda a estas extensiones. Tal y como nos describe José, esta característica se activa añadiendo la línea vhv.allow=TRUE al fichero /etc/vmware/config de nuestro ESXi.

Por supuesto, acabo de instalar Xen en mi lab y creado una VM de prueba... que ha funcionado perfectamente. Aprovecharé esta característica para ponerme con Xenserver, que lo tengo de lado desde hace bastante.

Mis felicitaciones a José por su estupendo blog.

Repensando VDI - Parte III y final

2011-09-02T12:50:00.000+02:00

Bueno… como vimos en los post anteriores, ya tenemos en lamano el diseño de una solución VDI para nuestro proyecto en particular. Ahora,antes de lanzarnos a hacer pedidos parémonos a reflexionar.

Para unos doscientos desktops disponemos encima de la mesade tres servidores de alta gama, una SAN en la que hemos perdido un entretenidorato en diseñar nuestra SAN teniendo en cuenta aspectos como los IOPS.

Por otro lado, y como parte de un buen diseño, vemos que lagranularidad en la escalabilidad de la solución se nos torna baja. Me explico…para 10 desktops más, hemos de adquirir un equipo similar, con un coste que osrecuerdo roza los 14K.

Además, y desde el punto de vista de la gestión, hemosañadido la gestión de la SAN y del almacenamiento, lo que dependiendo deldepartamento de IT del cliente, supone una nueva carga de trabajo, querequerirá cierta monitorización y ajustes durante la vida del entorno.

Todo esto que resumo en unas cuantas líneas supone un nuevosistema crítico en el entorno del cliente, con los mismos, si no mayores,requerimientos de gestión y monitorización que su entorno de servidores…. Y todopara un entorno, el de PCs, que no requiere, en un entorno de desktop físico,de tanto nivel de administración y conocimiento de las tecnologías implicadas.

Keep it simple

Quizá debamos revisar nuestra concepción de un entorno comoel que nos ocupa. Empecemos por los servidores.

Es indiscutible, al menos bajo los parámetros tradicionales,que la densidad es el secreto del éxito en un entorno VDI. Es decir, cuántosmás VM “metamos” en un servidor, mejor… ¿mejor?. Servidores más grandes son máscaros, y ante el fallo de uno, el impacto es mayor: Enel ejemplo en el queestamos trabajando en el que hemos añadido un tercer servidor sólo por si acaso(recordemos que la pregunta no es si fallará, sino cuando lo hará). Este tercerservidor además nos permite asumir sin paradas las tareas de mantenimiento dela infraestructura, lo que sigue obligándonos a desconectar a cien usuarios deuno de ellos para que se conecten a otro. Así mismo, y tal y como recordamosantes, la granularidad es baja: Ampliamos nuestra infraestructura por mor a launiformidad de entornos de 100 en 100 desktops.

Por otro lado, el almacenamiento. Según nuestros cálculos,necesitamos al menos 15 discos para satisfacer el hambre de IOPS de nuestrainstalación. Nos vemos dimensionando una SAN de un coste respetable (discos de15K, multipath, etc) únicamente por las necesidades de IOPS….

Servidores: Enanos vs Gigantes

Si incrementamos el número de nodos, disminuyendo a la parla especialización del hardware (nada de memoria ECC, SATA en lugar de SAS,Placas base de desktop con procesadores de alto rendimiento) observamos que, aigual número de cores y memoria, la factura baja sustancialmente… más que nadaen lo referente a la redundancia. Si sustituimos cada nodo de los antesdescritos por 4 0 5 Core I7 980/990 con 24 Gb de RAM, el importe de la facturaen lo referente a servidores descenderá bastante, manteniendo (e inclusodecrementando) el número de desktops por core. El coste de la redundancia (eseservidor extra) también se reduce (ya que la configuración propuesta cuestaposiblemente entre tres y cinco veces menos).

Almacenamiento: Divide y vencerás.

Respecto al almacenamiento…. Olvidémonos de la SAN. Discos localesSSD de hasta un Tb en / si queremos, configuración RAID. Hoy en día un discoSSD de 500 Gb (que nos va a dar más IOPS que TODA una SAN tradicional) de 500 MB/sec de lectura/escritura, ronda los1200€… más que suficiente para un entorno de 20-30 desktops por servidor. Discos algo más modestos del orden de 300 Gbcon ratios de 270/205 MB/s de lectura y escritura rondan los 50 0€.

Un equipo de estas características (dependiendo de siponemos o no el disco SSD en RAID) puede oscilar entre los 2000 y 3000€. Sivolvemos al coste de los servidorespropuestos (13K por servidor x 3), vemos que con el mismo presupuesto (39000€),podremos adquirir entre 13 y 19 de estos equipos, suministrando entre78 cores/ 312 Gb de RAM y 114 cores con 459 Gb de RAM comparados con los 72Cores y 288 Gb de RAM de la solución inicial. En lo referente alalmacenamiento, la solución SSD proveeentre 3000 y 6000 IOPS por microservidor frente a 3500-4000 para toda lainfraestructura del ejemplo inicial.

¡Almacenamiento local! ¿Vade retro?

No tiene porqué. Hay cierta tendencia a reevaluar el valordel almacenamiento local, sobre todo con SSD, en entornos VDI. Citrix yaplantea usar los discos locales de los servidores como caché para eliminaraccesos a la SAN/NAS (Intellicache),y otras tecnologías más disruptivas como nutanixya hablan directamente de sustituir a la SAN/NAS como almacenamiento de runtimede entornos de virtual desktops.

Caso aparte es el de Kaviza,recientemente adquirida por Citrix, que con su concepto de Grid elimina lanecesidad de almacenamiento compartido.

Brokers.

Xendesktop.

Mediante el uso de Intellicaché, nos podemos plantear el usode un servidor NFS que almacene las gold copy para que posteriormente Intellicachelas despliegue en los SSD locales: Cualquier NAS tipo IOMEGAStorcenter, TheCus o similar, que nossuministran NFS a costes inferiores a los 1200€ resulta suficiente. TambiénWindows 2008 nos ofrece un servidor NFS de alto rendimiento, con el añadido deque esta misma máquina puede usarse para los perfiles de los usuarios.

Kaviza.

Kaviza parte de la premisa de que no existe almacenamientocompartido, aunque puede usarse. El controlador de Kaviza se instala en cadauno de los equipos como una máquina virtual, se agrupan entre ellos en un grid,y hagas lo que hagas en uno de ellos, se replica al grid sin configuraciónadicional. Así mismo el grid se encarga de proveer de tolerancia a fallos,redirigiendo al usuario de un nodo al otro en caso de caída del primero. Estacaracterística nos permite reducir el número de microservers, al no sernecesarios más de uno o dos para proveer de tolerancia a fallos al entorno. Asímismo, el grid se encarga de replicar las gold images entre todos sus miembrossin necesidad de configuración extra.

Otra ventaja de kaviza es el hecho de no requerir plataformade gestión de hypervisor (vCenter o similar) ya que habla directamente con cadahypervisor.

En el caso de kaviza, los microservers irían equipados conun disco adicional SATA para almacenar el appliance y las gold copys (no vamosa desperdiciar SSD en eso, ¿no?)

Ya hablaré sobre kaviza en mayor profundidas en futuros post.

El hypervisor.

Bueno, este entorno evidentemente eleva el número delicencias de los hipervisores, aunque en determinado caso, el de ESX, nos puedereducir la cuenta gracias al maravilloso licenciamiento que nos ha calzadoVMware… básicamente porque cada host se mantiene en los límites de memoria dela edición más económica (que además no incluye nada que necesitemos,incluyendo vMotion o HA).

Foto final

Pues venga, dibujemos el entorno final:

A simple vista se percibe la sencillez del modelo. Es un modelo en una sola capa, y que escala añadiendo unidades adicionales a un coste limitado. Cada ampliación incrementa los IOPS globales del sistema con una granularidad elevada (15-25 desktops), y a un coste totalmente mantenible. Eliminamos la SAN y la red FC de la ecuación, creando un entorno simple de gestionar, y dependiendo del broker elegido, puede ser mantenido por personal no experto en entornos virtuales.

Evolución del modelo.

Sobre este modelo se me ocurre que, al ser la unidad de crecimiento tan económica.... ¿porqué no plantearnos un entorno distribuído?

No hace demasiado demostraba a alguien que en un entorno VDI el movimiento de datos entre el puesto local (ficheros, corta y pega, etc) puede suponer un gran impacto en la infraestructura de acceso a los VDI. Su uno de nuestros usuarios decide subir desde su PC una imagen ISO de 2 Gb desde su disco local, el resto de los usuarios lo van a sufrir a menos que establezcamos mecanismos de control de ancho de banda más o menos avanzados para impedirlo. En escenarios donde hay grandes grupos de usuarios que acceden a los VDI contra el centro de datos, el ancho de banda y los protocolos de display remoto deben ser exprimidos al máximo para facilitar una experiencia de usuario cercana a la que está habituado. Mientras nadie se plantea localizar servidores de gama alta en oficinas de 20-30 usuarios, este entorno (especialmente con los brokers nombrados), nos permiten desplegar "caches" locales a costes razonables, eliminando la necesidad de dispositivos de control de ancho de banda y mejorando la experiencia del usuario al acceder a los desktops a velocidad LAN.

Este tipo de arquitecturas no debieran de sorprendernos... sin ir más lejos ya hace mucho que los accesos a internet utilizan proxyes o las centralitas IP cuelgan de una central.

Conclusión.

Alguien que conozco siempre me dice que hay más de una manera de coger un pájaro, y no deberíamos olvidar que la tecnología no debiera estar limitada a los pdf de los fabricantes. ¡Nos pagan para pensar!

vSphere 5.0 Listo para descarga..

2011-08-25T10:28:00.002+02:00

... ¡¡ Al fin !! vSphere 5 ya es descargable.... ¿A qué esperamos?

Herramienta de interés: SpecOps Gpupdate

2011-08-16T16:56:00.004+02:00

Para todos los que os peleáis más o menos habitualmente con las GPO (en especial a los que las actualizais con cierta frecuencia), os recomiendo SpecOps GPupdate... un "plugin" para la consola de "Active directory Users and Computers", que, entre otras cosas, permite forzar un gpupdate de las políticas de manera centralizada. Además ofrece otras funciones, como Apagar remotamente sistemas, encenderlos (supongo que con Wake On LAN), forzar un Windows Update o Reiniciarlos. Y lo mejor.... ¡tiene versión free!

Sin desperdicio.

Nota técnica: Autoconfiguración de Máquinas virtuales.

2011-08-16T11:22:00.008+02:00

Las capacidades de cloning de vSphere no son un secreto. La posibilidad de desplegar una nueva máquina virtual desde otra definida como plantilla, con las opciones de personalización definidas previamente como "Customization Specification" suponen un gran ahorro de tiempo y de nivel deautomatización de despliege.

Una "Customization Specification" no es más que un fichero de respuestas sysprep "inyectado" en la VM destino para que está se configure de determinada manera, en especial en lo relacionado al nombre, pertenencia al dominio o configuración IP.

Sin embargo, sysprep puede dejarnos el trabajo a medias. Me explico.

Si nuestra VM origen tiene, por ejemplo, varios discos duros con unas asignaciones de letras determinadas, estas desaparecerán con el sysprep, siendo sustituidas por las asignaciones por defecto. Si hemos modificado cosas como el swap, (tamaño o localización), también estas configuraciónes se revertirán a sus valores por defecto.

Evidentemente no es nada que no pueda ser solucionado con powershell, GPOs o con intervención manual. Sin embargo, hay entornos donde modificar las GPO no depende de nosotros, o powershell no puede ser usado por normativa interna. El caso que nos ocupa es el siguiente:

Por definición los servidores del entorno que nos ocupa deben tener la siguiente configuración de disco:

C: Arranque
D: Datos
S: swap
T: Temporales de sistema y usuarios.

Además, el archivo de swap debe tener un tamaño fijo de 1.5 veces la RAM del sistema.

Por otro lado, el escritorio de la VM debe estar organizado de la siguiente manera:

Icono "Computer": Debe tener como etiqueta el nombre del sistema

Fondo de pantalla: Con BGInfo. debe actualizarse cada vez que se loguea un usuario.

En este caso, en el que el cliente usa McAfee ePO, eliminamos el GUID del agente para que pueda registrarse correctamente en la consola. Así mismo, deshabilitamos el firewall en el perfil de Dominio.

Por requerimientos de la instalación, no podemos usar ni GPOs ni powershell.

Vaya, todo un problema. Por suerte podemos echar mano de las herramientas de línea de comando de Windows 2008R2 (insuperables) y de nuestros maravillosos archivos .bat (o .cmd)

¿Qué hicimos?

Respecto a la máquina virtual, decidimos equiparla con dos controladoras SCSI, una de ellas LSILOGIC y la otra Paravirtual, para aprovechar las ventajas del driver sintético de disco, quedando el disco de arranque en la primera, y el resto de los discos en la segunda. Así mismo, definimos el disco dedicado a temporales como no persistente, lo que nos permite, por una parte, limpiar nuestro servidor cada vez que lo apaguemos, y por otra, evitar que el disco de temporales crezca en exceso quitándonos las ventajas del thin provisioning (recordad que el espacio borrado no se recupera de manera automática)

En primer lugar, crear una customization specification con las siguientes características:

Destaco en rojo los dos parámetros necesarios para el caso que os propongo: El autologin count, que nos permitirá que el usuario administrador de loguee automáticamente tras acabar el despliegue UNA SOLA VEZ, y el GUI run once command, que nos permitirá que en ese login se ejecute nuestro script. Sobra decir que este debe estar previamente en la VM plantilla.

Código, código...

Aquí va el código del script.

:vars
set tdrive=t
set sdrive=s
@echo off
:start

if a%1 == a/install goto install
@echo Personalizando
:mktemp
@if not exist %tdrive%:\temp.usr\%username% mkdir %tdrive%:\temp.usr\%username%
@reg add HKCU\environment /v TMP /t REG_EXPAND_SZ /d "%tdrive%:\temp.usr\%username%" /f > nul
@reg add HKCU\environment /v TEMP /t REG_EXPAND_SZ /d "%tdrive%:\temp.usr\%username%" /f > nul
set temp=%tdrive%:\temp.usr\%username%
set tmp=%tdrive%:\temp.usr\%username%
:MyPcIcon
@reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D} /ve /t REG_SZ /d %computername% /f > nul
@reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel /t REG_DWORD /v {20D04FE0-3AEA-1069-A2D8-08002B30309D} /d 0 /f > nul
:Background
c:\tools\bginfo /timer:0 /nolicprompt c:\tools\omt.bgi
goto end
:install
:fwdomdisable
@echo Desactivar firewall en dominio
@netsh advfirewall set domainprofile state off
:tempdrive
@echo Configurando disco temporal y de swap a %tdrive%:\
wmic computersystem where name="%computername%" set AutomaticManagedPageFile=False
@if exist %sdrive%:\pagefile.sys wmic pagefileset where name="%sdrive%:\\pagefile.sys" delete > nul

@echo select volume 5 > c:\tools\swapdrive.dsk
@echo assign letter %sdrive% >> c:\tools\swapdrive.dsk
@diskpart /s c:\tools\swapdrive.dsk > nul

@echo select volume 3 > c:\tools\tempdrive.dsk
@echo assign letter %tdrive% >> c:\tools\tempdrive.dsk
@diskpart /s c:\tools\tempdrive.dsk > nul

@echo Setting Configurando variables TEMP y TMP del sistema
@reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TEMP /t REG_SZ /d "%tdrive%:\temp.sys" /f > nul
@reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TMP /t REG_SZ /d "%tdrive%:\temp.sys" /f > nul
:swapfile
@echo setting System swap

@for /f "tokens=*" %%a in ('wmic computersystem get TotalPhysicalMemory^ /Value ^| find "="') do (set var.%%a)
@set vargb1=%var.TotalPhysicalMemory:~0,-7%
@set /a vargb2=%vargb1%/1024
@set /a swapsize=%vargb2%*1024
@set /a swapsize=%swapsize%+(%swapsize%/2)
@echo Configurando swap a %swapsize% MB
@wmic computersystem where name="%computername%" set AutomaticManagedPageFile=False > nul
@wmic pagefileset create name="%sdrive%:\pagefile.sys"
@wmic pagefileset where name="%sdrive%:\\pagefile.sys" set InitialSize=%swapsize%,MaximumSize=%swapsize% > nul
@if exist c:\pagefile.sys wmic pagefileset where name="c:\\pagefile.sys" delete > nul
:McAfee
@echo detecting MCAfee Products
@reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent" /v AgentGUID > nul
if errorlevel 1 goto reboot
if errorlevel 0 goto deleteGUID
:deleteGUID
@echo Detectado ePO¡¡ - Borrando GUID
@reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent" /v AgentGUID > nul
:REBOOT
shutdown /r /t 0
:end

El script contiene dos secciones, que se invocarán dependiendo del parámetro que le pasemos al invocarlo.

Si no le pasamos ninguno, el script se limitará a verificar que los directorios temporales del usuario existen y a configurar las variables de entorno del sistema (Sí, sé que en lugar de set podía haber utilizado xset) Así mismo, renombra el icono "Computer" y se asegura de que éste se muestre en el escritorio.

La segunda parte sólo se ejectuta si el script es invocado con el parámetro "/install".

Etiqueta :vars

Aquí definimos las variables que vamos a utilizar: %sdrive% para la letra del disco de swap y %tdrive% para las letras del disco temp

Etiqueta :fwdomdisable

En esta parte, desactivamos el firewall en el perfíl "Dominio" mediante netsh advfirewall

Etiqueta :tempdrive

Esta etiqueta elimina el pagefile existente (nos libera espacio del disco C). Para ello, dejamos al sistema temporalmente sin swap y procedemos a borrar el pagefile.sys que, por defecto, tendrá la máquina en C:

En esta fase, aprovechamos para "reordenar" los discos según especificaciones, con los valores especificados en %tdrive y %sdrive. Para ello, echaremos mano de diskpart y su capacidad de recibir órdenes desde un fichero (parámetro /s). Este fichero lo hemos creado "on the fly". Los números de volumen (3 y 5) dependerán de cada sistema. En el que nos ocupa, los discos creados para temp y swap ocupaban el 3 y el 5 respectivamente). Una vez asignadas las letras correspondientes, modificamos las variables TMP y TEMP del sistema.

Etiqueta :swapfile

Ahora a lo gordo... esta parte del script creamos el nuevo archivo de swap. Para ello, utilizamos el comando wmic (que nos dá acceso a la instrumentación de windows desde línea de comando) y las capacidades "aritméticas" del CMD de Windows.

Etiqueta :McAfee

Aquí detectamos si existe la entrada de registro del ePO de McAfee. Si existe (lo detectamos con errorlevel) saltamos a la etiqueta :deleteGUID que la borrará, forzando al agente a generar una nueva.

Etiqueta :REBOOT

Forzamos un reboot del sistema

Etiqueta :end

¡Esto es todo, amigos!

Resumen.

Este script es sólo un esqueleto, y pueden añadirse más funciones (instalación de software, por ejemplo o de roles del servidor) de forma que una vez desplegada nuestra nueva VM la tarea manual sea la mínima posible.

Esto es todo por ahora.... ¡¡ Buena semana!!

Nuevo link: PiPo e2H

2011-08-13T13:11:00.003+02:00

Añado a mi lista de links de interés el blog PiPo e2H, mantenido por José Luis Gómez Ferrer de Couto, blogger, arquitecto de sistemas y vExpert 2011. Os aseguro que no tiene desperdicio.

Un saludo

Citrix adquiere RingCube

2011-08-11T10:35:00.003+02:00

La cosa va de compras. Citrix ha adquirido Ringcube, y con esta adquisición añade vDesk a su portfolio de producto. vDesk permite la gestión de perfiles de usuario (o Persona en la terminología View), permitiendo independizar el entorno del usuario del desktop. Junto con la adquisición de Kaviza, Citrix confirma su intención de convertirse en líder de la tecnología VDI. Junto con el más que nombrado nuevo licenciamiento de vSphere, creo que Citrix dará mucho que hablar.

Os dejo la referencia de Brian Madden en su blog, así como la nota de prensa de Citrix.

Un saludo.

Gracias a...

2011-08-09T17:02:00.001+02:00

... Javier de Rada por la corrección en el logo!

De nubes, truenos, paraguas y chubasqueros.

2011-08-09T10:42:00.005+02:00

De todos es sabido, rumoreado twiteado y blogizado el reciente incidente en la nube europea de Amazon. Parece ser que un rayo se llevó por delante parte de la infraestructura eléctrica de uno de los proveedores locales, afectando negativamente a varios clientes de Amazon... los servidores, en la nube o no, tienen la mala costumbre de requerir electricidad.

Este incidente reabre el debate sobre Nube sí Nube no. Tendemos a ser extremistas en cuestiones como ésta, decantándonos por un bando u otro en base a nuestros intereses o afinidades, por lo que se genera un debate que, sin llegar a tachar de artificial, considero que no centra la cuestión real.

Hay un viejo adagio que dice que la pregunta adecuada no es si un sistema va a fallar, sino cuándo lo hará. Podemos completarlo con un "¿y estás preparado para que cuando falle haga el menor daño posible?". La nube, lejos de ser un concepto abstracto y metafísico, no es más que un sistema. Grande, distribuido, pero un sistema. Y falla. Muchas veces, por su propia naturaleza, el fallo pasa más o menos inadvertido, otras, como es el caso, no. Algunas veces el fallo es producido por factores externos, ponderables o no, otras, por fallo técnico (ya sabéis, la tecnología falla), y otras, por fallo humano (seguimos siendo el factor con más probabilidades de fallo de un sistema).

Lo que la nube no varía en ningún caso es la relación entre disponibilidad y coste: Es decir, cuánto más disponible queramos que sea un sistema, más nos costará.... a nosotros y a los Cloud Providers. No olvidemos eso. Y cuanto más les cueste a ellos, más nos cobrarán. Por otro lado, la nube es un negocio de escala, es decir, necesita muchos usuarios/clientes para que sea rentable. Si concentras muchos usuarios en un mismo sistema.... hay más afectados en caso de fallo.

¿A qué viene este cúmulo de obviedades? Simplemente a que cuando movemos nuestros servicios a la nube hemos de tenerlas en cuenta. Una nube barata, evidentemente, estará más expuesta a paradas de servicio... una nube resiliente y con gran capacidad de tolerancia de impactos, evidentemente, no será tan barata. También es verdad que un pool de servidores web quizá no necesite las mismas medidas que un exchange clusterizado. Pero es importante que tengamos claro qué servicio ha de ir a qué tipo de nube... y evaluar los costes. Como en las atmosféricas, en la nube digital también hay cirros, cúmulos y estratos...

Repensando VDI - Parte II

2011-08-08T11:53:00.003+02:00

En el post anterior de esta serie os proponía una reflexión sobre los despliegues VDI. En este, vamos a aplicar las ideas expuestas a un caso particular.

Escenario.

Hagamos números para un despliegue de VDI de unos 200 desktops con capacidad de tolerancia a fallos de al menos la mitad de la infraestructura. Tenemos tres gold images (copias maestras) de unos 40 Gb y pretendemos utilizar tecnología de linked clones para al menos el 80% (unos 160 desktops). El resto, son desktop completos.

Localizaciones.

El 100% de los usuarios accederán desde las 3 oficinas de la compañía, (aproximadamente, 60 usuarios por localización), aunque se estima que diez usuarios requerirán acceso más o menos constante desde localizaciones móviles. A corto plazo, se pretende extender el número de oficinas (entre 3 y 15 personas) en varios países europeos.

Aplicaciones.

Aparte de las ofimáticas (Microsoft Office y Open Office en algunos casos), hay que añadir el ERP corporativo, bases de datos Access para algunos departamentos, tres aplicaciones específicas del negocio basadas en web.

Otras actividades.

La navegación web y las descargas de ciertos documentos y archivos debe ser fluída, ya que gran parte de la actividad de la compañía se basa en el procesamiento de datos externos.

Experiencia de usuario.

En lo referente a la experiencia de usuario, nuestro entorno requerirá que al menos un 10% de nuestros usuarios dispongan de audio bidireccional para telefonía IP (disponemos, por ejemplo, de un Asterisk usando softphones), y al menos unos 15 usuarios requerirán de capacidades medias de manipulación de gráficos (composición de documentos ricos y/o manipulación de imágenes). La impresión (sí, señor, el eterno dolor de cabeza) se realiza en impresoras conectadas a servidores de impresión IP. El uso de dispositivos USB se limita a pen-drives y, opcionalmente, alguna cámara digital para la adquisición de fotografías previamente tomadas con estas. Se requiere de interacción entre determinados puestos locales y los desktops virtuales, al menos durante el primer año. Esta interacción se basa en el traspaso de datos entre la aplicación de un cliente y los empleados de la compañía desplazados al mismo.

Servidores.

Para ello utilizaremos tres host con las siguientes características

- 2 Procesadores de 12 cores

- 96 Gb de RAM

- 2 Fiber channel dual de 4 Gb

- RAID 1 x 3 discos de 73

El equipo seleccionado es un dell R715, equipado con dos Opteron 6180SE de 12 cores, doble fuente de alimentación.

Según el configurador de Dell (por poner un ejemplo), cada host nos cuesta unos 13.072€ (Calculemos un +- 15% entre descuentos y preferencias de configuración)

Con esta configuración, en la que minimizamos el número de host para evitar problemas con el licenciamiento, ya sea del hypervisor o plataforma de gestión, el coste de los host se eleva a 39.216€, lo que nos supone, aproximadamente, unos 196€ por desktop en lo referente a los servidores.

Almacenamiento.

Pasemos al almacenamiento. Una cabina de gama media-alta, con soporte FC y su correspondiente switch puede rondar los 30.000-40.000€ (dependiendo, claro, del fabricante).

Los IOPS (Input/Output Operations per Second)

Los IOPS (Input/Output Operations per Second) también serán determinantes a la hora de configurar el número de discos y los RAIDs correspondientes. Sumerjámonos en el siempre interesante mundo del almacenamiento.

Los discos.

Como referencia, tengamos en cuenta los IOPS medios de los discos actualmente en el mercado:

RPM	IOPS
SSD	4000-6000
15.000	170-180
10.000	110-130
7.200	70-78
5.400	45-50

Para los que nos gusta calcular estas cosas, si queremos tener una estimación de IOPS de nuestros discos, usaremos los siguientes parámetros para evaluar los IOPS de nuestros discos)

Velocidad de rotación: Número de revoluciones por minuto que dan los platos de los discos. Este parámetro está íntimamente relacionado con los otros dos que usaremos para el cálculo: Latencia Media y Tiempo medio de búsqueda.

Latencia media: Es el tiempo que tarda un sector del disco determinado en posicionarse bajo la cabeza de lectura/escritura del disco.

Tiempo medio de búsqueda: Es el tiempo medio que la cabeza tarda en posicionarse sobre un sector determinado para escribir o leer.

IOPS aproximados= Divide 1 por la suma de la latencia media del disco en milisegundos (aL) más el tiempo médio de búsqueda del disco también en miligegundos (aS)

IOPS=1/(aL+aS)

El gran Scott Lowe nos lo explica claramente en este post publicado en TechRepublic., Así mismo en el siguiente artículo en zdnet hay más datos interesantes sobre las RPM.

El RAID

Adicionalmente, hemos de contar con la posible penalización en escritura que el RAID de nuestra cabina nos imponga. Es importante tener claro que el RAID nos penalizará en escritura, mientras que puede (dependiendo del tipo de RAID) beneficiarnos en escritura. En un RAID0, por ejemplo, las operaciones de lectura se realizarán a la velocidad de uno de los discos de la SAN, ya que al estar los datos almacenados en un solo disco, estos nos serán devueltos a la velocidad del mismo. En un RAID 5, sin embargo, son todos los discos del RAID los que nos devuelven el dato, ya que este está dividido entre ellos).

A efectos de escritura, la siguiente tabla ilustra las distintas penalizaciones que, desde el punto de vista de la escritura, nos imponen los diferentes tipos de RAID.

Tipo de RAID	Penalización
RAID 0	0 (Una sola escritura en un disco)
RAID 1	2 (Dos escrituras en dos discos)
RAID 5	4 (lectura dato existente, lectura de paridad, escritura de nuevo dato, escritura de paridad)
RAID 6	6 (lectura de dato existente, lectura de paridad 1, lectura paridad 2, escritura de nuevo dato, escritura de paridad 1, escritura de paridad 2)
RAID 10	2 (igual que RAID 1)
RAID DP	2 (Escritura de dato, Escritura de paridad)

(Se admiten correcciones, opiniones y demás sobre el contenido de esta tabla)

Para más información: Niveles de RAID Estándar, Niveles de RAID no estándar según Wikipedia… recordad que cada fabricante puede “aliñar” los niveles de RAID para obtener un máximo rendimiento.

Para calcular el rendimiento de nuestra SAN el número de discos es crucial. No nos dará los mismos IOPS un volumen de 500Gb formado por 3 discos que por 6.

También el uso del disco es determinante. Me refiero al porcentaje de lecturas frente al de escrituras. No es lo mismo, a efectos de IOPS de la SAN, que el 80% del tiempo nos lo pasemos escribiendo y el 20% leyendo que al contrario (por aquello de las penalizaciones de escritura y beneficios de lectura)

Para no entrar en demasiadas controversias sobre las lecturas y escrituras que genera o no un Virtual Desktop (que dependerán, evidentemente, del diseño de la VM y del “opinador” en cuestión), estimemos un porcentaje de 80% de lecturas por un 20% de escrituras

Para calcularlo, usemos las siguientes fórmulas:

IOPS Brutos= Nº de discos(nD) * los IOPS de cada disco individual(iD)

IOPS Netos=((IOPS brutos * Porcentaje de escritura)/Penalización tipo RAID)+(IOPS Brutos * Porcentaje de lectura)

En base a estos datos, podemos definir una fórmula que nos indique cuántos discos necesitamos para calcular cuántos discos y en qué tipo de RAID hemos de montarlos para obtener un nivel de IOPS determinado.

Nº de discos=((IOPS * Porcentaje de lectura + (IOPS * Porcentaje de escritura * Penalización RAID)/IOPS individuales de cada disco)

Os dejo por aquí otro post que profundiza en los niveles de RAID.

Caches y otras hierbas…

Por si no fuese poco, a todo el lío que os he montado, añadid los caches, etc. Los fabricantes, conscientes de las limitaciones de las IOPS en entornos RAID, intentan minimizar el impacto de estas mediante el uso de Caches. Los que hayáis trabajado con RAID5 (con o sin SAN) estáis acostumbrados al concepto de cache, es decir, la controladora escribe en un caché de RAM alimentado por batería, difiriendo la escritura en el tiempo, de forma que podamos trabajar a velocidades RAM en lugar de a velocidades RAID. El problema es que la RAM se queda corta, así que no es extraño oir hablar de caches en flash, o directamente de un pool de discos SSD donde escribimos (por aquello del tamaño), y la SAN, posteriormente, mueve el contenido de los SSD/Flash a los RAID.´

El impacto de estos métodos en el rendimiento del RAID no son predecibles a priori, ya que dependerá de tamaño del caché, su tecnología y el método que use la SAN para mover los datos del caché a los discos. Vuestro comercial de almacenamiento seguro que dispone de un par de toneladas de PDFs que os lo aclararán.

A lo que íbamos.

Después de tamaño rollazo sobre el tema del almacenamiento (insisto y soy pesado con esto porque si en entornos de servidores es CRUCIAL para alcanzar altos ratios de consolidación, en VDI no os quiero contar), veamos como aplica esto a nuestro caso…

Estimando los requerimientos de IOPS entre 10 y 20 por Desktop (dependerá del sistema operativo, las aplicaciones, dónde se almacenen perfiles y datos y la arquitectura de la VM maestra – en negrita para destacar su importancia), nuestros 200 desktops requerirán de entre 2000 y 4000 IOPS, más incluso dependiendo de las operaciones de encendido, procesos de escaneo de antivirus y operaciones de despliegue masivo.

Si dimensionamos para la media, tendremos unas necesidades de entre 2000 IOPS y hasta 4000 si dimensionamos para el pico. Ahora es el momento de usar la formulita que os dejé para calcular cuántos discos necesitaríamos, me sale (ser admiten correcciones), que para dimensionar al pico (es decir, a 4000), necesito entre 18 y 36 discos de 15000 RPM y 178 IOPS. Una cantidad nada despreciable… Añadidle que los discos vayan en FC… ¿Porqué y no iSCSI? Si estimamos un rango de 10-20 IOPS por segundo en los desktops (más teórico que práctico) y descartamos el pico (lo que implica que en determinados momentos el I/O se habrá colapsado), tendremos que cada host puede generar constantemente unos 1000/2000 IOPS de media. Si el pico (arranque de VDIs, por ejemplo) se elevase al doble (unos 3000 IOPS) la latencia inherente a iSCSI (no olvidemos que sigue siendo IP, además de ser SCSI) puede resultar determinante. No obstante, y para que no se diga, en determinadas configuraciones iSCSI puede obtener rendimientos envidiables (véase 1,000,000 IOPS with iSCSI - That's Not a Typo...) También es verdad que una SAN de esas características no está al alcance de cualquiera…. Salvo que deseemos “montárnosla” por nuestra cuenta.. Ya sea con un servidor Windows Server y el Target iSCSI o con soluciones Open tipo Nexenta, Open-e o similares... opciones nada desdeñables y de las que escribiré otro día.

Bueno. Ya hemos acabado nuestro diseño, y salvo el coste de lo ya definido, ¿ya estamos listos para el despliegue? pues va a ser que la respuesta, en el próximo post.

Licenciamiento vSphere 5.0: Dos pasos p'alante, un paso p'atras... (Actualizado)

2011-08-05T01:01:00.004+02:00

Pues sí, el rumor se confirma. VMware, después de escuchar a los clientes que se ve que no escuchó antes de la brillante idea del cambio de licenciamiento, parece haber dado un paso atrás de los dos (y alguno más) que dió para adelante. Aquí el PDF descriptivo y preceptivo.

Parece que la cosa queda como sigue:

- vSphere Standard: Hasta 32 Gb por licencia de procesador.

- vSphere Enterprise: Hasta 64 Gb por licencia de procesador.

- vSphere Enterprise Plus: Hasta 96 Gb por licencia de procesador.

Además, las VM "tarificarán" hasta un máximo de 96 GB. es decir, que esa VM que todos tenemos en nuestro CPD y lab de casa con 1 TB de RAM "sólo" nos descontará 96GB del Pool de memoria. Gracias, VMware. Este tema me tenía preocupadísimo.

Amplío este punto a petición de un lector:

Imaginemos que tenemos 16 licencias de vSphere Standard. Esto, según el nuevo licenciamiento nos da la posibilidad de usar hasta 512 GB de vRAM. Imaginemos que tenemos 20 máquinas virtuales con 4 GB de vRAM. Esto significa que de nuestros 512 GB licenciados nos quedan 20x4, es decir, 80 GB de vRAM. Ahora creamos una de esas máquinas más que normales en nuestro CPD (sic) de 128 GB de RAM. Según el licenciamiento anterior, de nuestros 432 GB (es decir, 512 - 80), nos quedarían 304. Con el nuevo licenciamiento, la máquina de 128 GB sólo descontará 96 GB, con lo cual nos quedarían 336.

Como dije antes, ya me quedo más tranquilo.

Como "buena" noticia, la edición Free permitirá 32 GB por procesador.

Mi reflexión al respecto.

Evidentemente a algún cliente "gordo" no le sentó bien eso de tener que pagar 70000US$ por su máquina de 1 TB de RAM. ¿qué queréis que os diga? Lo entiendo perfectamente.

Pero el problema de origen, el tarificar por CPU Y por RAM sigue existiendo. Menos gordo, pero aún existe. De hecho, sólo nos han dado un par de años, hasta que las VM que hoy tienen 4 Gigas requieran de 8.

Así mismo, se han cepillado la edición Advanced, como pretendieron con vSphere 4.

He decidido dejar de ponerme negativo con este tema y pasar a ser parte de la solución, así que voy a proponerle a VMware nuevos modos de licenciamiento creativo:

Por vRAM: Es decir, monta todas las licencias que quieras en todos los server que quieras, pero paga por la vRAM, no por las pCPU.
Por VM. Ya lo tienen para vSphere for Desktops: a tanto por VM, cobrando las, por ejemplo, 10 primeras de un tirón. Nada de vRAM ni de CPUs.
Por Core: A tanto por core (ya que les preocupa tanto el nº de cores creciente). Nada de vRAM ni pCPU.

Adicionalmente, que cobren por separado las características que consideren oportunas.

Un licenciamiento de este tipo permite al cliente elegir cómo gestionar sus costes a nivel de cluster (ojo, no de datacenter), sin necesidad de irte a soluciones de chargeback para calcular cuanto imputas a una unidad de negocio. Así tendrás máquinas por las que pagarás por los recursos que usan (genial para producción), máquinas por las que pagarás por su mera existencia (genial para entornos de desarrollo), máquinas que pagarás por "derrama" de la infraestructuran que usa (genial para cuando imputas costes en base a la infraestructura.

Muchos estáis recibiendo correos, llamadas o visitas de vuestro partner o de la propia VMware para hablaros de las "excelencias" del modo de licenciamiento. Como vengo haciendo cuando hablo de este tema, plantearos no sólo si os afecta ahora... sino cómo os va a afectar en tres años.

Pensad además en que el modelo de licenciamiento de VMware empaquetaba diferentes en base a las características del producto: HA, VDR, vMotion, etc... En su momento, parecía lógico que pagásemos por una característica independientemente de cuanto la usemos. En el muevo modelo, los pools de memoria NO PERMITEN la mezcla de ediciones. Es decir, que si has comprado Enterprise Plus porque necesitas el AutoDeploy y te quedas sin vRAM, no puedes comprar un Standard para añadir 32 GB más, SINO que HAS DE SEGUIR COMPRANDO ENTERPRISE PLUS, escalando de 96 en 96 GB, y pagando OTRA VEZ Auto Deploy, Policy Driven Storage y Storage DRS.... Buscando símil en el mundo físico, es como si comprases un servidor con 96 GB y cuando vas a ampliarlo, el vendedor de turno te dice: Sólo puedes ampliarlo de 96 en 96 y además te llevas otros diez discos, otra RSA y otra tarjeta 10G por el módico precio de agarrate bien la cartera. Tú le dirás: A ver... pero si sólo necesito 32 GB... y el vendedor te responde: Lentejas.

Pregunta: ¿tanto les costaba sacar bundles de RAM a, por ejemplo, 500€ los 16GB adicionales? Se ve que sí.

Un saludo.

PD. Mi cliente de los VDI... a ese todavía le toca pagar más CPUs de las que tiene con este nuevo licenciamiento.

Licenciamiento vSphere 5.0: VMware "reflexiona"

2011-07-29T20:29:00.005+02:00

- Noticia sin confirmación oficial -

Update: Por aquí también sopla...

Según leo en el blog Gabe's virtual World de Gabrie van Zanten parece que tras consultar con sus clientes, VMware ha "reflexionado" sobre el "creativo" (me refiero a beneficios, claro) modo de licenciamiento inicialmente programado. Entiendo que el enfado de alguno de sus clientes y el "ruido" web (entre cuyos caceroleros me cuento) les ha hecho reevaluar el modo en que sus clientes utilizan sus productos y que penalizar a los mismos por usar las características más avanzadas no iba a ser bienvenido.

Parece que el "Update 1" del licenciamiento de vSphere 5 queda como sigue:

vShpere 5 Essentials: 24 GB de vRAM
vSphere 4 Essentials Plus: 32 Gb de vRAM

Ambas ediciones están limitadas a 192 Gb de RAM, independientemente del número de CPUs licenciadas.

vSphere 5 Standard: 32 GB de vRAM (Gabe indica que esto es una suposición suya)
vSphere 5 Enterprise: 64 GB de vRAM
vSphere 5 Enterprise: 96 GB de vRAM

Así mismo, parece que el máximo por VM que "cuenta" contra nuestros pools de vRAM es de 96GB, lo que quiere decir que una máquina de 256GB contará como su consumiera sólo 96GB

Tan pronto se confirme oficialmente, publicaré los nuevos escalados por ediciones y, cómo no, mi opinión al respecto, que por el momento me reservo.

Un saludo.

Repensando VDI - Parte I

2011-07-29T00:02:00.003+02:00

Si observamos el estado actual de las soluciones VDI, podemos constatar un par de hechos

La densidad de Desktops por server es crucial.
A partir de un determinado volumen, Las soluciones requieren de infraestructura datacenter.

El primer punto es evidente: Hay que rentabilizar las inversiones en hardware (servidores y almacenamiento) y las software (licencias y mantenimientos).

Es evidente que, por un lado, el incremento de cores en los procesadores y la mejora continua de arquitecturas, y por otro, la reducción del precio de las memorias, favorecen densidades de 80-100 desktops por server, cuando no hace demasiado, hablar de 50 desktops por server hacía temblar a más de un experto. Todas estas innovaciones permiten reducir la factura de los servidores y, consecuentemente, el coste del software asociado (Ya sean licencias de hypervisor, sistemas de gestión de la infraestructura, etc).

Respecto al segundo punto, y siguiendo el paradigma actual de “todo al datacenter”, requerimos de servicios centralizados como son el almacenamiento, la seguridad o las comunicaciones, por no hablar del backup, restore e infraestructura de protección ante desastres y/o continuidad de negocio.

Respecto al primer punto, el elevar el ratio a niveles de 90:1 debido al mayor rendimiento de CPUs y memorias genera, por otro lado, el problema de la congestión de I/O, es decir, la lucha por el acceso a disco y en menor manera, a la red.

Por muy Windows XP, 7 o Linux que sean, siguen siendo máquinas virtuales con requerimientos de acceso a disco. A diferencia de una sesión de terminal server (o citrix XenApp), la sesión de un usuario no implica una instancia más de la aplicación en un sistema operativo server (que suelen estar más optimizados en lo referente al I/O que uno de desktop), sino TODO el conjunto del sistema operativo se instancia para dar servicio a un único usuario. De ahí que, a igual hardware, un servidor de terminales pueda albergar muchísimos más usuarios simultáneos que ese mismo servidor ejecutando una infraestructura VDI. Básicamente la diferencia se encuentra en cuántos recursos (Disco, RAM y CPU) se requieren en el entorno VDI frente al escenario con Terminal Services o Citrix XenApp

Esta sobrecarga de I/O se puede ver incrementada con las habituales aplicaciones o servicios asociadas al desktop: Antivirus, updates (tanto de OS como de aplicaciones, aunque en algunos escenarios se desactive), o por operaciones vinculadas al entorno VDI como el despliegue de nuevos desktops o el refresco de los mismos. Es cierto también que las tecnologías de linked clones disminuyen el acceso a disco eliminando el uso que supone replicar una y otra vez un disco maestro. Recomiendo la lectura del documento “Windows 7 IOPS for VDI: Deep Drive” de Jim Moyle para una visión detallada de la relación entre desktops Windows 7 y los IOPS generados. Recomiendo la lectura adicional de un caso de aplicación donde los IOPS fueron determinantes. Está publicado aquí.

Desde el punto de vista del coste de un despliegue VDI, satisfacer los requerimientos de IO de la infraestructura puede resultar una sorpresa bastante cara.

Aprovechar la infraestructura actual de virtualización (es decir, host y almacenamiento) puede redundar en una pérdida de rendimiento dramática del entorno de servidores y afectar, como no, a la infraestructura VDI.

En algunos proyectos, el estudio de costes saltó hecho añicos cuando en mitad del despliegue hubo que plantear la adquisición de una unidad de almacenamiento específica para el entorno VDI (Y no de las entry level, precisamente). Aún dedicando una unidad SAN/NAS de almacenamiento exclusivamente a VDI, los problemas de rendimiento puede que no desaparezcan, dándose la paradoja de que se requiera una SAN más avanzada para el entorno VDI que la desplegada para los servidores.

Seguimos otro día.

Un saludo.

Licenciamiento vSphere (suma y sigue)

2011-07-26T13:41:00.004+02:00

Rescato de la vblogosfera eeste post de Bernd Harzog en The Virtualization Practice donde nos dá otro punto de vista (más) sobre el impacto del nuevo licenciamiento de vSphere. Recomiendo su lectura. Por otro lado, me voy a permitir comentar algunas de sus reflexiones:

"Vertical Equity. Here VMware has always been fair. The Editions of vSphere that are targeted at the SMB and SME markets (while missing many of the nice high end features in the Enterprise Editions) are considerably less expensive than the full enterprise editions that large enterprises use. Therefore small businesses who can arguably afford to pay less for a virtualization platform are afforded this option by VMware. Of course this ignores the question of why SMB’s and SME’s who can get Hyper-V for free should pay anything for vSphere, but that is another article entirely."

Evidentemente, con un modelo que penaliza la densidad, la reflexión es obvia. Evidentemente en los pequeños entornos de virtualización (que no en las pequeñas empresas), la "amenaza" del incremento del coste del licenciamiento abre la caja de pandora de "¿porqué no cambiar el hypervisor")

"Horizontal Equity. Here is where things start to get tricky. VMware makes the point that the vRAM entitlements are large enough to handle the needs of “most” of their customers. However it is already clear that customers who have pushed the envelope on density just a bit, or who have virtualized lots of memory heavy applications will have to pay a lot more for vSphere 5 than they paid for vSphere 4. So this boils down to whether or not a customer with 4,000 VMware hosts who is pushing the envelope on density is the “same” as a customer who is not. It also gets down to who should benefit as the customer drives up density. It would seem that the benefit of driving up density is a benefit of the platform and that the customer having paid once for the platform should not have to pay more to get the maximum benefit from it. The vSphere 5 licensing therefore fails this test."

Sólo imagino un sector de cliente donde el licenciamiento, suba o baje, les dá un poco igual: Los proveedores de servicios Cloud. Básicamente porque repercutirán el coste.... como efecto perverso, puedo imaginar que es una forma sutil de forzar al cliente final a ir hacia modelos Cloud.... con los clientes importantes de VMware.

"Compliance should be easy. When it comes to vSphere 5 licensing that means that it should be easy to figure out how many licenses you need right now and how many you will need into the future. If you have one vSphere environment all pointing to one vCenter then this is not so hard. If, as is the case with many enterprises, there are multiple disparate virtual data centers owned and run by different groups, then consolidated reporting and analysis could be almost impossible. This is also an area where “pooling of vRAM” just does not work. If the test group has purchased N vSphere 5 licenses that have a certain amount of vRAM associated with them, they are not going to let another group use “their” vRAM just because it is technically in the same pool. The new licensing therefore also fails this test."

Evidentemente el modelo Cloud no afecta al licenciamiento... es decir, salvo que os vayáis al futuro SKU para branch offices (que creo limita el número de host y empieza en un paquete de 10 branch offices) el tema de Pools separados (no sólo por vCenters, sino por ediciones) puede llegar a elevar perniciosamente el número de licencias. Las que antes usabas en común.... ahora las adquieres por separado.

"Desirable behavior should not be penalized. In this context desirable could mean many different things. For example, for a performance critical application, ensuring that the application met its response time goals would be highly desirable. In order for this to be achieved, it may make sense to allocate 20% more memory to the application that it uses at its peak in order to ensure that memory bottlenecks never occur. In this case meeting the desired goal of applications performance is in fact inhibited by this new licensing as this new licensing will in the aggregate make being conservative about memory allocations more expensive. This also gets back to the previous point about who should benefit when the customer pushes the density envelope. Clearly it is in VMware’s interest for customers to do this, as it improves the overall value of the vSphere story. For VMware to slap a tax on density therefore seems to make no sense. The new licensing therefore fails this test as well."

Cosas como las reservas preventivas incrementan su coste. Si antes no sobresuscribias memoria, pero dedicabas la definida en la VM por motivos técnicos o de rendimiento (Oracle en Linux, p.e. se llevaba mal con el balloning), ahora tiene otro coste.... el precio por gb de VMware según la edición.

"Promote growth. This is where the new vRAM entitlements may in fact be a fatal mistake for VMware. Because it may turn out that with this new pricing, adding new applications to an existing environment (increasing density) may become much more expensive than it was before. It may also turn out that virtualizing the next 60% of applications that are not virtualized yet may be more expensive than anticipated, since those applications are likely to be more memory intensive than what has been virtualized to date. The new vSphere licensing clearly fails this test."

Básicamente VMware te castiga cada vez que usas sus capacidades de gestión de memoria. Cuanto más ahorres en recursos más pagarás en licencias.

En cuanto a las conclusiones del artículo, totalmente de acuerdo. VMware protege a sus grandes clientes de su intención de facturar más por su infraestructura virtual, penalizando a los más grandes.

Y me uno a la recomendación: Que cada usuario analice cómo le afecta o afectará el nuevo licenciamiento, y tome sus decisiones en base a sus conclusiones.

Un saludo.

Entornos mixtos ¿vade retro, Satanás?

2011-07-26T10:32:00.005+02:00

Parece que el nuevo licenciamiento de vSphere 5 ha abierto la caja de pandora del coste de las infraestructuras virtuales, al menos en lo concerniente a los productos de infraestructura, como es, en el caso que nos ocupa, el Hypervisor y la suite de productos asociadas. Hasta el momento, el incremento de la capacidad tanto de proceso como de memoria en los host permitía en algunos escenarios el aprovechamiento intensivo de la inversión en software, incrementando ratios de consolidación en aquellos entornos menos críticos (tanto en el aspecto tecnológico como financiero) de forma que no obligasen a la adquisición ni de servidores ni de licencias de Hypervisor. Es decir, IT ofrecía un "más por menos", suministrando servicios ya a la compañía, ya a sí misma sin el coste de infraestructura. Entre estos servicios están los propios de infraestructura (monitorización, gestión de red, gestión y monitorización de sistemas, etc) que no suponían al departamento de IT una distracción de caros recursos de producción para sus necesidades internas.

Otro aspecto donde el "más por menos" es intensamente aprovechado es el de los entornos de desarrollo, test y preproducción. La capacidad de generar servidores para nuestros entornos de prueba (normalmente con licencias de desarrollador de los productos, o licenciamientos especiales para pruebas, como Technet de Microsoft), junto con la capacidad de eliminar la necesidad de hardware para los mismos, ha sido, durante muchos años, un sólido argumento para la implantación de la virtualización de servidores en las compañías. De hecho estos entornos fueron y siguen siendo los primeros candidatos a ser virtualizados, precisamente porque son donde primero se observan los ahorros de la virtualización y el aumento de eficiencia en el entorno IT. Si antes tenías entornos limitados de test (normalmente confinados a máquinas abandonadas en el almacén o a nuevos servidores de gama baja), ahora puedes disponer de un "hueco" en la infraestructura virtual para estos entornos. Puedes prescindir de ese servidor SQL u Oracle donde aplicabas todas las configuraciones de la compañía (con los problemas que conlleva al no ser el entorno de desarrollo igual al de producción... no olvidemos que no todos podemos consolidar nuestras bases de datos en un solo servidor), generando y creando escenarios idénticos al de producción (a veces una simple copia o clonado del mismo) para probar el código con el nuestro departamento de desarrollo mantiene actualizadas nuestras aplicaciones.

No sólo el departamento de desarrollo se beneficia de los entornos de test. Sistemas también... ¿o es que nadie ha dudado en aplicar un fix a un sistema operativo porque no puede probar antes el impacto que tiene? En los entornos físicos, aplicar un fix o un service pack requiere de una buena dosis de backup, cruzada de dedos y algo de suerte.... o tener otro servidor idéntico, configurarlo como el de producción, aplicar el fix y rezar porque los resultados sean extrapolables. La virtualización también ha cambiado esto. Normalmente el proceso que he descrito se resume en la creación de un sandbox aislado (donde la aplicación de un fix o configuración puede alterar un entorno entero... exchange sin ir más lejos), clonar los sistemas implicados, aplicar el fix en los mismos, probar y después decidir si lo aplicas a producción.

El divertido mundo de las actualizaciones de versiones también sacó su tajada. ¿quién no ha montado un entorno paralelo con la siguiente versión de lo que sea (oracle, exchange, directorio activo, windows server, etc) en una plataforma virtual? Probar nuestras bases de datos SQL 2005 en SQL2008 nunca fué tan fácil.... y tan libre de riesgos.

También la evaluación de productos, pruebas de concepto y entornos asociados podían encontrar un hueco en nuestra infraestructura. No todo el mundo dispone (o quiere disponer) de un entorno separado para estas actividades, ya sea porque su coste no lo justifica (el presupuesto de IT es como las opiniones, cada uno tiene una), ya sea porque la evaluación no lo justifica (si para probar 10 virtual desktops hemos de forzar a nuestro presupuesto el incluir hardware, igual nos echamos atrás).

Por último, no olvidemos a todos esos Nagios, Cactis, syslogs servers, Fileservers de IT, NAS virtuales, etc... que encontraban un hueco - sin coste - en nuestra infraestructura virtual.

Otro escenario es el de "VDI Excepcional". Me refiero a esos entornos donde se mantiene un pequeño pool de desktops con un propósito específico (usuarios móviles, factorías de software, etc) que se sirven con Terminal server, con la edición free de Xendesktop o con brokers de bajo coste como SeedsFoundation y que acomodamos en un "huequito" de nuestra plataforma sin más coste que las CAL de TS. Conozco más de un entorno así corriendo en un resource pool.

Si todo lo descrito, que antes no requería inversión o esta era muy limitada, ahora tiene coste, evidentemente hemos de plantearnos o el prescindir de estos entornos.... o llevarlos a plataformas en las que el coste no venga dado por la manera en que usamos los recursos virtuales.

Matrimonios por interés.

Eso es lo que define nuestra relación con un producto o tecnología. Más allá de las preferencias como tecnólogos, es el interés económico el que nos lleva a usar de manera más o menos continuada un producto o tecnología. Por un lado, el uso que hagamos del mismo fomentará la expansión y desarrollo de la misma (eso que llaman presión del mercado), y por otro, el trato que recibes del fabricante (características, soporte y precio), por otro. Mientras esta relación sea beneficiosa para ambos (el win-win de los anglosajones), la relación no solo no se estancará, sino que crecerá. El usuario estará contento (y consecuentemente hará publicidad del producto) y el fabricante también (tendrá beneficios y podrá dedicarse a mejorar el producto o a sacar nuevos). Si uno de los dos pierde (el cliente deja de estar conforme con soporte, características o precio o al fabricante no le sale rentable), esa relación se altera.

Veamos ejemplos:

Oracle: Hubo un tiempo en que una base de datos que se preciara corría en Oracle. Rendimiento, soporte y homogeneidad eran el argumento. Cuando comenzó a aparecer competencia (Y hablo de Microsoft) Oracle decidió mantener su política de precios (En aquella época, entre tiers, cpus, site licences y demás, necesitabas un Cray MP para calcular el precio de tu implementación Oracle). ¿resultado? La compentencia (Microsoft, MySQL, PostGRE e incluso DB2) aprovecharon el hueco (en base a precio o ausencia del mismo) para meterse en el datacenter. En la actualidad no es extraño (de hecho lo sorprendente es lo contrario) torpezarse un Oracle, un par de SQL Servers y algún MySQL en nuestros datacenters, cada uno dedicado a su entorno sin que por ello se hayan abierto los infiernos. Hoy Oracle tiene licenciamientos desde 450€ anuales y compite con Microsoft en entornos antes impensables.

Linux: ¡¡Cómo no citarlo!! Por un lado el espíritu bohemo rebelde de la comunidad, el crecimiento de los costes, las funcionalidades y la aparición de ofertas de soporte serias, han supuesto que parte de la carga de sistemas propietarios (Windows, Aix, etc) se desplacen al sistema operativo del pingüino. Las herramientas cruzadas (ODBCs, JDBCs, SOAP, etc) permiten que aplicaciones basadas no sólo en sistemas operativos diferentes, sino incluso en lenguajes diferentes, se interrelacionen sin excesivos problemas, manteniendo los costes limitados)

Citrix: Tras años de posición preponderante en el mercado del SBC (Server Based Computing) donde la competencia no llegaba o no existía (Terminal Services, Tarantella o similares), hoy tampoco resulta extraño vernos con entornos mixtos XenApp y RDS y alguna otra solución dando servicio a entornos diferentes dentro de la misma organización.

¿Y en los hypervisores?

Hubo un tiempo (no hace demasiado) en que el "moverte" de hypervisor podía suponer un impacto en la operatividad de los sistemas, básicamente porque las características de uno no estaban disponibles en otros. Así mismo, VMware destacaba por su madurez y rendimiento, lo que justificaba la inversión en licencias, formación y conocimiento. Eran tiempos donde el live migration fuera de ESX suponía un riesgo. Así mismo, las grandes diferencias en estabilidad de las VM, gestión del almacenamiento de las mismas y las herramientas de gestión decantaban claramente la balanza en pro de VMware, justificando la inversión (nada despreciable ni antes ni ahora) en licencias. En esos momentos, la incertidumbre debida a las características de Hyper-V y Xen justificaban la recomendación de ESX como única plataforma viable en entornos predecibles, ya sean producción o no.

Todo ha ido cambiando: Live Migration ya no asusta a nadie (Tanto en entornos Hyper-V como Xen), la estabilidad y compatibilidad ya casi no se cuestionan, el compromiso de los grandes con sus plataformas de hypervisor es innegable y cada vez más tenemos claro qué características necesitamos y cuales no.

vSphere 5, como ya comenté en un post anterior, nos obliga ahora a pagar con la Memoria Virtual Asignada (vRAM), organizada en pools de memoria licenciada de una misma manera, lo que hace que muchos de los entornos antes descritos ahora compitan en presupuesto con la intocable producción. Ya no es cuestión de meter más host, de scale-up (pocos nodos grandes) o scale-out (muchos nodos pequeños). Ya es cuestión de que tu densidad de host YA tiene precio. Y si no la tiene hoy porque eres el feliz licenciatario de ediciones Enterprise + de vSphere, lo tendrá. (mira hacia el futuro y a tu densidad de VM. Calcula tu tendencia. No mires SOLO cuánto te va a costar hoy ya que tienes 3/4 años para amortizar).

La solución pasa o por prescindir de ciertos entornos, o por ir a un entorno mixto vSphere y Xen/Hyper-V.

En este escenario, es posible plantearse que todos los roles no directamente involucrados en la producción, o que no tengan una clara relación entre tecnología y negocio (o dicho de otra manera, inversión y retorno de la misma vía facturación) se desplacen a entornos de coste contenible o que al menos no escalen por el uso sino por el crecimiento del hardware subyacente).

Conozco varios casos donde estos entornos ya existen, ya sera vSphere + XenServer, o vSphere + Hyper-V.... o los tres, donde vSphere lleva la producción, XenServer VDI y parte de preproducción y Hyper-V el desarrollo y test. La aparición y maduración de herramientas de gestión como System Center Virtual Machine Manager (que incluso permite integrar los ESX existentes) o XenCenter, hacen que el gestionar los entornos mixtos cada vez sea más fácil. Así mismo, otros fabricantes del ecosistema VMware ya disponen o están adaptando las herramientas de gestión de infraestructura virtual a entornos multi-hypervisor (y esto lo sé de muy buena tinta). También hay herramientas de terceros, como Acronis Backup & Recovery Virtual edition nos permiten una migración de ida y vuelta de VM's entre entornos... a un precio significativamente más reducido que el derivado del licenciamiento de VMware.

Resumen.

Somos tecnólogos, no compradores pasivos de tecnología. Y el mercado y los productos avanzan gracias a nosotros que los compramos e implementamos.

¿Qvo Vadis, VMware?

2011-07-22T13:40:00.004+02:00

vSphere 5 ya está aquí... y entre las novedades que nos aporta, aparece un nuevo modelo de licenciamiento donde, adicionalmente al tradicional basado en CPU's, ahora tendremos que licenciar la memoria virtual asignada (no la física) que nuestra infraestructura use.

No voy a entrar en pegar excels o cálculos que, depende de cómo se hagan, defenderán la postura oficial o la postura del sector crítico... en el que me incluyo.

El hecho que parece que todo el mundo obvia es que el impacto preocupante no es el inmediato; es decir, que si tendremos que pagar más o menos por nuestra infraestructura actual. Creo que el problema viene con lo que pagaremos SI decidimos migrar a vSphere 5, camino que NO tiene marcha atrás en el momento de que actualizamos datastores al tan aclamado VMFS5. Es decir, si el sobrecoste (si existe) es asumible hoy, quizá no lo sea dentro de un año.

La decisión de VMware de monetizar el cómo usamos la memoria RAM (después de años de proclamar y presumir - entre los voceros me incluyo - que la sobresuscripción ahorraba costes) me parece cuando menos controvertida, en especial porque para licenciar más allá de los límites de cada edición tenemos que pagar por CPU's que no usamos y por características que YA hemos pagado: Es decir, si tienes licencias para cuatro CPUs donde ya pagas vMotion, HA, FT y demás, tienes que volver a pagarlas en base a la memoria RAM.

Si eres de los que exprimes tu infraestructura jugando con la sobresuscripción para incluir en esta entornos no monetizables (es decir, sin impacto directo en la cuenta de resultados de tu empresa), vas a pasar a un modelo donde, por ejemplo, el entorno de pruebas donde evalúas el Service Pack 1 de SQL 2008 cuesta dinero. Esos 2,4,8 0 16 Gb van contra tu pool (pagado a precio de oro, según la edición que tengas). Tampoco que queda la opción de montar un ESXi gratuito para estos entornos, ya que estás limitado a 8 Gb (¿pasamos del free al free evaluation?). Ahora tu entorno VDI no basado en View, si lo migras, va a crecer en paquetes de 100 VDIs (Genial granularidad), y vas a tener que comprar nuevas licencias (sí, no hay actualización de vSphere 4.1 a vSphere 5.0 for desktops!!) al "módico" precio de 6500 US$.

Qué quieren Uds. que les diga.... esto suena a buscar venta de licencias por donde sea. Si no puedes pagarlas, pues ya sabes.

Este tipo de comportamientos no es nuevo: Oracle lo intentó en su momento (por debajo de 30000US$ ni te cogían el teléfono), olvidando que en IT no hay matrimonios eternos, y que contra el vicio de pedir existe la virtud del no dar. De un entorno de producción donde no entraba una base de datos que no fuera Oracle pasamos a entornos mixtos sin ningún problema. La tecnología, precisamente por la nueva realidad mixta que aparece, avanzó, y el uso cada vez más amplio de conocimiento externo no obligó a las compañías a triplicar su staff de DBAs (incluso ayudó a limitarlo).

Si recordáis, cuando salió vSphere 4, VMware ofreció la edición Advanced para los clientes que migraban desde ESX 3.0 únicamente, obligando a estos a saltar a enterprise. El mercado se revolvió y al final tuvo que mantenerla. En vSphere 5 parece no existir advanced... veremos lo que dice el mercado.

La realidad es que a los clientes Enterprise Plus con ELA esto no les va a afectar demasiado. Incluso si superan la cantidad de memoria licenciada, vSphere 5 se limitará a darles un aviso, y dudo que los SEAL de VMware ocupen el CPD para exigir el pago... (lo mismo que Microsoft con sus EA, que no nos cae encima si en vez de 10000 Licencias de Windows 7 usamos 12500)... Lástima que para el resto de los mortales, con ediciones NO enterprise plus, vSphere parece que no nos dejará encender más VM.

Otra realidad es que, pese a los esfuerzos de VMware, vSphere (y sus correpondientes suscripciones) sigue siendo, con inmensa diferencia, el core de su facturación, ya sea porque el resto de los productos no terminan de encajar.... o porque sean extremadamente caros (que digo yo que el precio tendrá algo que ver).

Lo curioso de todo esto es que mucha gente estaría más de acuerdo con un licenciamiento per-vm... o con las dos opciones, lo que si se correspondería más razonablemente, al menos bajo mi punto de vista, con un modelo pay per use.

Otro anuncio curioso es que VMware no va a continuar con desarrollos orientados a la gestión de múltiples hypervisores. La razón esgrimida es que"no hay interés".... entiendo que por parte de su departamento comercial.... abrir la caja de pandora de los entornos mixtos debe ser que no les encaja en el modelo de "te cobro por lo que se me ocurra".

¿Alternativas? Bueno, la primera, seguir con vSphere 4 durante los 7 años teóricos que VMware mantendrá el soporte. Teóricos porque no me sorprendería que el resto de los productos comenzaran a presentar "pérdidas de funcionalidad" SI usas vSphere 4. Visto lo visto con las limitaciones de ESXi 5.0 free, no me sorprendería. La segunda... los entornos mixtos.

Entornos mixtos: Ya pasamos la época de que todos los problemas de una aplicación derivaban de la plataforma virtual. Diseñar un entorno mixto, donde VMware lleve la producción (ojito con la sobresuscripción de memoria, que cuenta como vRAM), y XenServer los VDI y Xenserver o Hyper-V los entornos de desarrollo no es ningún disparate. Prácticamente todos los fabricantes mantienen políticas similares de soporte respecto a entornos virtuales (especialmente Microsoft y Oracle) así que tendremos los mismos problemas de siempre..... pero pagando menos, y sin usar funcionalidades que, en entornos de desarrollo, probablemente no necesitemos. Ya existen productos de terceros para gestionar entornos mixtos.... y más que saldrán.

Si Microsoft y Citrix aprovechan este huecazo que les deja esta nueva VMware facilitando migración de VHD a VMDK y viceversa creo que se harán con un buen pedazo del pastel, que hoy, por cierto, ya no es el que era: VMware... recuerda que ya NO tienes el 80% del mercado....

Por último, el esfuerzo "evangelizador" de VMware en redes sociales, junto con la opinión y casos de éxito de reconocidos bloggers no hace más que confirmar que este cambio no gusta a nadie.... ni siquiera a los clientes ELA.

El futuro: ¿Y vSphere 6 cómo se licenciará?

VDI... ¿De qué estamos hablando? - Parte II

2010-04-30T10:54:00.009+02:00

¿Y ahora dónde estamos?

Con esto de lo virtual, muchas de las cosas que conocíamos han cambiado. Ni los servidores son lo que eran, ni parece que los desktop tampoco.

La virtualización del desktop, es decir, coger un sistema operativo cliente, instalarlo en una máquina virtual y usarlo como de un desktop físico se tratara tampoco es nada nuevo. Por allá por el 99, con las primeras betas de VMware Workstation unop ya hacía sus pinitos virtualizando un XP bajo RedHat linux para usarlo como entorno de pruebas de aplicaciones portadas de Linux a Windows (¡¡un sistema de control de un telescopio, ni más ni menos!!).

Componentes de una solución de desktop virtual.

Tomando la diferenciación que hice en el post anterior respecto a los "tipos" de Desktop Virtual que percibo, necesitaremos los siguientes ingredientes para "cocinar" nuestra infraestructura:

Hosted Virtual Desktop (Desktop Virtual Hospedado)

1. Licenciamiento "VDI aware" del Sistema operativo de desktop a usar.

2. Hardware de servidor con muchos cores y mucha memoria.

3. Hypervisor (más o menos gratuíto)

4. Plataforma de gestión de los desktop virtuales. (gestiona las copias maestras, asigna los accesos y provisiona los desktops. Más o menos caro, según fabricante)

5. Almacenamiento Enterprise (compartido o no. Gigabyte caro en comparación con el Gigabyte de un desktop)

6. Broker de conexiones (El elemento que permite conectar a nuestros usuarios con el desktop que le corresponde, y suministra el protocolo de presentación - del que hablaremos en la tercera parte de esta serie - y que se licencia de maneras variopintas)

Virtualización en el desktop Cliente - (Client Desktop Virtualization)

1. Hardware de cliente "VDI-aware". Esto, por el momento, nos obliga a adquirir equipos con tecnología que nos permita desplegar desplegar y gestionar ese desktop virtualizador. No se requiere únicamente la presencia de extensiones que faciliten la virtualización asistida por hardware. Como ejemplo, la respuesta de Intel se llama vPro ... la de AMD... Buena pregunta.

2. Licencia NO OEM del sistema operativo de desktop (sustancialmente más cara que la incorporada en el equipo. Entiendo, y algún pajarito así me lo confirma) que esto puede cambiar en breve.

3. Hypervisor de Cliente y/o Sistema operativo Host. Dependiendo de si el hypervisor de cliente es tipo 2 o tipo 1 (ver Hypervisores en Wikipedia), tendremos que adquirir (desde coste cero en el caso de Linux a algunos dólares en otros) una licencia de sistema operativo que nos permita ejecutar el hypervisor en nuestro desktop.

4. Plataforma de gestión. Sí, no nos escapamos de ella. Se ocupará de la gestión del hardware del desktop, del despliegue y gestión de las imágenes de desktop virtuales y de la gestión del hypervisor de cliente.

5. Almacenamiento. La posibilidad de concurrencia de tareas de I/O, ya sea por la actividad propia del hypervisor, la paralelización de la ejecución de las imágenes virtuales con otros procesos (despliegue de imágenes, seguridad embebida en el hypervisor, etc), requerirá de discos más rápidos (o más inteligentes) en los desktops, para evitar retrasos en el acceso a disco.

Como aspectos comunes, añadamos una licencia de antivirus (o dos, si el hypervisor es tipo 2), especialmente en entornos donde el sistema operativo virtualizado sea Windows.

A cambio de todo esto, y de su consecuente factura.. ¿qué obtenemos?

La virtualización ofrece al desktop una serie de ventajas sobre las soluciones aplicadas y descritas en la primera parte del artículo. Hagamos un breve repaso.

El sistema operativo cliente sigue siendo el mismo: Ventaja evidente. No es necesario adaptar al usuario a nuevos entornos (Citrix/Terminal Services sí requería que el usuario supiese un poco de qué iba el tema). Tampoco es necesario "mezclar" los tradicionales mundos de Sistemas (Un terminal server no es más que un Windows Server que hay que administrar como tal) con el de Desktop (Windows XP tiene su propia problemática, bastante diferenciada de la de los servidores), con lo cual, a priorí, tanto el cambio organizativo dentro del departamento IT como de la percepción subjetiva del usuario, es mínimo).

Hardware totalmente estándard en los desktop: El hardware virtual es homogéneo, lo que reduce los esfuerzos de maquetación y definición de "gold copies". No más toneladas de drivers, archivos de sysprep personalizados, u hora tras hora actualizando.

Despliegue rápido: Así mismo, la propia naturaleza de la máquina virtual (un fichero en disco), junto con las opciones de personalización del sistema opertativo (en el mundo Windows, sysprep, por ejemplo) simplifica in extremis el despliegue de nuevos desktops a velocidades y con una simplicidad sin precedentes.

Rendimiento: Los desktop virtuales, en cualquiera de sus variantes, suministran un rendimiento más que aceptable para las aplicaciones empresariales (negocio y/u ofimática).

Eliminación del desktop inteligente: En el modelo de Desktop hospedado (es decir, el que se ejecuta en un datacenter), el PC puede ser eliminado de la mesa del usario, substituyéndolo por un terminal (sí, tan terminal como una VT220), eliminado gran parte (no todos) de los costes asociados tradicionalmente al PC. También aporta su toque "verde" (Green/IT) al disminuir el consumo eléctrico y las emisiones de dióxido de carbono. En el aspecto presupuestario, aparte de que el terminal suele ser más económico que el PC (con "suele" quiero decir que hay muchos que lo son, pero otros que no), las reduciones de costes de mantenimiento, energía, junto con un alargamiento substancial de la vida del activo (no es necesario cambiar el terminal cada cuatro años, ya que lo que cambia es la máquina virtual) reduce los costos de almacenaje, reciclado y las provisiones por amortización.

No obstante, la propia naturaleza del entorno virtual hace que otros procesos y productos que deben instalarse en ese desktop virtual (para mantener la funcionalidad de ese desktop) creen nuevos problemas asociados a la "virtualidad" del entorno. Lo dicho, nuevas tecnologías, nuevos problemas. Reflejemos algunos.

Licenciamiento: Este es el primero y más evidente de los nuevos problemas. En un entorno físico, es bastante probable que el fabricante os incluyese la licencia de Windows en el PC que le compramos... en el virtual, y siguiendo los licenciamientos que Microsoft ofrece para entornos virtuales, ahora pasamos a pagar un derecho de uso anual que puede costarnos entre 23 y 110$ por año, dependiendo de nuestro acuerdo de licenciamiento con Microsoft (aquí un link explicatorio). A este coste hemos de añadir, ya sea nuestra infraestructura hospedada o no, el coste de la solución de virtualización (Hypervisor de cliente, Broker, etc), que puede llegar hasta los 130$ por virtual desktop. Así mismo, dada la "virtualidad" del desktop (ahora está y, voilá, ahora no está) el número de licencias a adquirir puede resultar difuso. Lo mismo se extiende a las aplicaciones y demás software.

Provisionamiento - Proceso administrativo: Vaya, hasta ahora, los departamentos de compras tenían "tiempo" para asimilar los costes y demás que implican un nuevo puesto de trabajo.... pero ¿ahora que los podemos crear en cuestión de segundos?. ¿Cómo resolvemos el papeleo de la adquisición y asignación de licencias, inclusión en inventario, etc.. ? Los modelos de licenciamiento deben adpatarse a la realidad de un entorno desktop cambiante y "on demand". Por otro lado, la imputación de coste del PC a la unidad de negocio también debe redefinirse. Si les convencimos para que apostaran por Virtual Desktop como solución a los problemas del desktop (no incluyo el económico, ya que está por ver que efectivamente esto sea más barato), debemos demostrárselo de alguna manera. (¿Pay per use, imputación de costes por consumos, etc?)

Provisionamiento - Procesos técnicos: Antes, si un usuario requería un PC para mañana, el usuario se "fastidiaba" y se esperaba las dos semanas de rigor para su adquisición, y el problema se solucionaba con aprox. unos 600€ (el coste, más o menos, de un desktop corporativo). En un entorno virtual, el añadir un desktop más a una infraestructura sobrecargada puede implicar varios miles de euros. El método de "compro cuando necesito" bastante habitual en sistemas no se adapta demasiado bien a este entorno cambiante. Las previsiones (y la adaptación a ellas) alcanzan en este entorno una importancia crucial. ASí mismo el hardware a usar para virtualizar desktops debe tener en cuenta estas premisas: Altamente escalable, Alta granularidad en el coste (es preferible crecer de 1000 en 100 euros que de 10000 en 10000), lo que hace a plataformas como los "big nodes" poco ideales para este entorno, haciendo de mis odiados blades una plataforma adaptable para esta "misión". En lo concerniente al almacenamiento, tecnologías cono SATA, Deduplicación y cloning se hacen fundamentales, tanto por coste como por funcionalidad. En lo que al Desktop Virtual Local se refiere, el transferir una imagen de unos cuantos gigas para actualizar la imagen local de la VM tampoco deja de ser un problema.

Seguridad vs Rendimiento: Evidentemente, un desktop conlleva un antivirus, pero... ¿evaluamos correctamente la carga de trabajo que supone un antivirus en una máquina virtual?. Si un escaneo programado de antivirus puede "bloquear" mi PC físico... ¿qué no hará en un virtual? Evidentemente, el efecto es distinto dependiendo de la tecnología que usemos. En un entorno hosted, un escaneo de antivirus en nuestros 300 desktops virtuales en simultáneo puede suponer una carga estresante para nuestra infraestructura, que puede afectar a la operatividad del usuario. En un virtual desktop local, la concurrencia de dos escaneos en dos máquinas virtuales (o el de una sola) puede afectar negativamente a la otra, y, consecuentemente, a la experiencia del usuario.

En un entorno de Virtual Desktop hospedado, una solución pasa por desplazar la seguridad del desktop al perímetro: Mantener aisladas las redes de desktops virtuales utilizando un UTM (Unified Threat Management) para garantizar la seguridad del desktop. Si a esto le añadimos la facilidad de despliegue del desktop en caso de infección (no desinfectas el desktop, lo re-creas), y salvando el aspecto de la identidad del usuario (de la que hablaremos en otro capítulo), es posible obtener un entorno más ligero y con un esquema centralizado (y perimetral) de seguridad.

En el Virtual Desktop Local, la cosa se complica, ya que desplazar la seguridad hacia el perímetro no siempre es la solución, y no siempre es implementable.

Inciativas como vSafe, de VMware (aunque desconozco si ya hay algún producto que haga uso de este API) prometen: Desplazar la seguridad hacia el hypervisor (que al fin y al cabo está incluso por debajo de los root kits) suena interesante. De esta manera podríamos "vacunar" a la infraestructura, y no a la VM. Esta podría ser la solución común tanto para los hosted virtual desktops como para los locales.

Interacción con el usuario: Por un lado, el uso de dispositivos de usuario (como un pen drive, un scaner o una impresora, un iPod/Pad o una blackberry) depende en gran manera de la capacidad de implementar USB sobre IP (en caso de los hosted) o de usar directamente mediante un arbitrador los puertos USB del host. Otros dispositivos, como puenden ser grabadoras de CD/DVD presentan algunos problemas, en especial en el caso de los hosted virtual desktops: el mapeo USB via IP puede inducir latencias que son normales en IP, pero no están soportadas en USB. Yo, en algún caso, ¡¡¡he tenido que utilizar iSCSI para solucionarlo!!!. Por suerte, hay productos y tecnologías en el mercado que, poco a poco, van solucionando esta problemática.

El problema de la identidad: Este punto podría dar lugar a un capítulo de esta serie en exclusiva, pero prometí que serían sólo tres, y la presentación será la temática del tercer y último de esta serie. Entendamos como identidad del usuario no sólo sus credenciales de acceso, sino al conjunto de configuraciones e información relacionada con él (su configuración de correo, su perfil de usuario, su carpeta "Home" o su fondo de pantalla). Mientras que en entornos Unix suele bastar con redireccionar la carpeta home del usuario a un servidor NFS, en el entorno Windows no es tan sencillo. Aunque existe la posibilidad de redirigir las carpetas de usuario a un servidor de ficheros, muchas aplicaciones requieren de DLL's o ejecutables que no se almacenan en el perfil del usuario, y que consecuentemente, no funcionan al cambiar de PC. Aquí es donde la virtualización de aplicaciones (yo prefiero llamarla containerización) resulta de ayuda. Conseguir que una aplicación se ejecute en lugar de instalarse, y que la configuración específica del usuario se almacene en una unidad de red abre inmensas posibilidades en entornos desktop sin persistencia. Otras soluciones pasan por implementar desktops no persistentes a nivel de sistema operativo pero sí a nivel de configuraciones de usuario (vease el modelo de VMware Composer), pero personalmente ya he pillado algún que otro fallo, y el proceso en sí me parece demasiado agresivo. Eso, evidentemente, aplica a los desktop virtuales hospedados.... ¿pero qué pasa con los locales?

Creo que pasa por soluciones tipo Microsoft Mesh o Dropbox, que ahora solucionan el problema a nivel de ficheros, pero aplicada a la identidad del usuario. Imaginemos un servicio que permitiera almacenar nuestras preferencias de aplicación y configuraciones específicas en la "nube"....

Pienso que el problema de la identidad debe solucionarlo el sistema operativo, no la plataforma de virtualización. Los SS.OO y las aplicaciones, deben enfrentar seriamente el concepto de identidad flotante, como concepto independiente del hardware (real o no) de la máquina donde se hospeden. Me atrevería a decir incluso que deberían tener en cuenta hasta la ausencia de inteligencia en la máquina, es decir, que nuestra identidad en Windows XP, por ejemplo, pudiese ser compartida por Office 2010 web edition.

Seguimos en unos días.

Un saludo.

VDI... ¿De qué estamos hablando? - Parte I

2010-04-28T07:29:00.005+02:00

Efectivamente, esta es la pregunta. Cuando hablamos de Virtual Desktop Infrastructure... ¿de qué hablamos? Respondamos a esta pregunta al final del tercer post de esta serie.

Desde mi punto de vista, y acepto correcciones, aprecio, al menos, dos aproximaciones al concepto de desktop virtual.

La primera la denominaré, siguiendo la nomenclatura inglesa, Hosted Virtual Desktop. Entiendo por ello a un conjunto de máquinas virtuales que se ejecutan en un host más o menos central (Siempre es posible su distribución geográfica) a los que los usuarios acceden a través de un protocolo de presentación remoto (léase RDP, CTX, HDX, PCoIP, etc).

A la segunda, siguiendo el anglicismo más o menos extendido, la nominaremos Desktop Virtualization. Según mi entender, se basa en la ejecución del puesto cliente de un hypervisor de tipo 1 (es decir, sin sistema operativo más o menos funcional debajo) que permitirá la ejecución de una o varias máquinas virtuales en el desktop del usuario.

Por una de esas casualidades de este mundo en el que vivimos, ayer "conocí" a Guise Bule, un experto en esto de VDI con el que, durante unas horas, intercambiamos via email nuestras impresiones sobre la tecnología VDI, y he de reconocer que este artículo va dedicado a él. Reconozco sin ningún tipo de reparo que me ha hecho evaluar mis opiniones sobre el Desktop Virtual.

En este momento, el futuro del desktop del usuario está en evaluación. Tras dos o tres decenas en las que Microsoft consiguió arrancar la inteligencia del host para llevarlo a la mesa del usuario (cosa que le agradezco profundamente) nos vamos dando cuenta de que gran parte del esfuerzo que invertimos el personal de IT va dirigido al mantenimiento de un elemento ajeno a los sistemas centrales, pero que actúa como "puerta" entre el usuario y estos. Como ejemplo baste decir que da igual la maravillosa infraestructura Exchange que hayamos montado si el usuario no consigue que Windows arranque y le permita acceder a Outlook (o a Explorer, si usa webmail). Desde cierto punto de vista (más fílosófico que técnico), esto suena a franco retroceso: Potenciamos e invertimos en los servicios centrales para terminar dependiendo de algo que casi se ha convertido en un electrodoméstico: El PC.

No hace demasiado, soluciones del tipo Citrix o Terminal Server surgieron como alternativa al "poder" del PC del usuario: Mediante la instalación de un cliente de presentación remota conseguimos que el frontal al usuario de las aplicaciones se mantuviera en un entorno controlado, y convertimos al PC en un casi tonto terminal de un sistema central que el personal de IT cuidaba y administraba como el resto de los servidores. Tuve la suerte en esa época de participar en un par de proyectos bastante importantes relacionados con la implantación de este tipo de infraestructuras, y de vivir en primer plano la lucha constante que el personal de IT mantenía (antes de la implantación de Citrix) porque los PC funcionasen. Hablo de épocas de Windows 3.11 y Windows 95.

Descubrí en ese momento que la implantación de Citrix Metaframe simplemente diluía el problema en el caso de que el usuario usase un PC. Sólo desaparecía en el momento que al usuario se le instalaba un WinTerminal (alguno de mis lectores sabrá de qué hablo). Incluso en este último caso, y cumpliendo mi máxima de que las nuevas tecnologías sólo traen nuevos problemas, aparecía el problema de la gestión de los WinTerminals: Configuración de sesiones, actualizaciones, etc.

Aún asumiendo los inconvenientes de este tipo de solución, nos encontrábamos que la centralización de aplicaciones en un terminal server nos obligó a la creación de un nuevo rol. Hasta entonces, existía una clara diferencia entre el personal de sistemas (que administraba sistemas operativos y aplicaciones "core") y el de helpdesk (que implantaba y mantenía las aplicaciones "edge", es decir, las que usaba el usuario). A partir de la implementación de los terminal servers, fué necesario, o bien crear una nueva figura de "Administrador de aplicaciones de desktop en servidores", o traspasar a los administradores de sistemas la responsabilidad de hacer, por ejemplo, que Office se ejecutase sin problemas en un servidor de terminales. Aunque tuve la suerte de participar como consultor y no como implantador en esos proyectos, reconozco lo agonizante que puede resultar ver 30 o 40 instancias de Word, Excel o Access en el gestor de tareas de un servidor Windows. Por otro lado, no todas las aplicaciones funcionaban correctamente en una sesión Terminal Server... de hecho ni siquiera estaban diseñadas para ello (algunas versiones de Office, por ejemplo), y en algunos casos, el fallo de una instancia de una de las aplicaciones instaladas en el Terminal Server ocasionaba el colapso completo del servidor.

Como anécdota recuerdo que en una posición anterior en una gran compañía, recriminaba al responsable de implantación de aplicaciones en entorno Citrix (título oficinal del profesional en cuestión) que me diera tiempos de implantación de nuevas aplicaciones de un mes. Tras visitarle para invitarle al café de la negociación, me enseñó la granja Citrix, y las configuraciones especiales que tenía que aplicar a más de una aplicación y al sistema cada vez que añadía una. En ese momento le entendí.

En esos momentos no había otra opción, y más de un cliente reportaba una disminución de incidencias de hasta el 60%... número nada despreciable en un entorno, el desktop, que dejaba de estar bajo control en el mismo momento en que se lo instalabas al usuario.

En más de un caso recuerdo que el cliente decidió trasladar TODAS sus aplicaciones (ofimáticas y de negocio) a una granja Citrix, e instruyó a su proveedor de Desktops para que le maquetara los mismos con el cliente ICA instalado.... y una partición de recuperación accesible mediante clave... para que todos los problemas que tuviesen que resolver sus técnicos de campo se resolviesen remaquetando el PC.

Durante bastante tiempo, este tipo de soluciones cubrieron la demanda de un entorno de usuario estable y funcional.... hasta que recordamos que ese PC, por muy tonto que fuese, seguía ejecutando Windows. Y que era infectable por virus que ya no atacaban al PC a través de medios extraíbles, sino a través de la red. Recuerdo una infección de Blaster que paramos con reglas en el switch de nivel tres de la delegación en España de una multinacional... filtrando el tráfico que llegaba por la red corporativa. Hubo que volver a focalizarse en el PC del usuario.

Gestión del desktop.

Los inconvenientes de los servicios centralizados en un terminal server disuadieron a muchos clientes sobre su implementación. Al fin y al cabo, si la aplicación X falla o afecta al S.O., mejor que sólo bloquee el PC del usuario que el servidor donde acceden 30 o 40. Pero claro.... ¿Quién y cómo cuida el desktop?. Controlar el funcionamiento de los desktops, desplegar y actualizar antivirus, mantener inventario del parque y mantener actualizado y configurado el S.O. requería de nuevas aplicaciones: Gestores del Desktop.

Un gestor de desktop no es más que un servidor que recoje datos del parque de desktops. Previamente habrá sido necesario desplegar el agente del gestor, que no es más que, por un lado el chivato que indica al servidor el estado del mismo, y por otro, el ejecutor que instala con privilegios elevados los componentes o actualizaciones que el gestor de desktop considera oportunas. Si hablamos de antivirus centralizado, aplicamos el mismo procedimiento.

Puede darse, y de hecho me he encontrado algún caso, que el coste del S.O., el agente de gestión del desktop, la parte proporcional del Gestor de Desktops, el antivirus, la parte proporcional del gestor de antivirus centralizado, y el plataformado inicial de los PC's del usuario ronden entre el 80 y el 115% del coste del hardware. Nunca me he visto en la necesidad de justificar esto ante un CFO (Director Financiero), pero no debe ser una experiencia agradable.

Renovación tecnológica.

Aparte de la Ley de Moore (esa que dice que cada 18 meses la potencia de los ordenadores se duplica, y que tanto Intel como AMD se encargan de cumplir), las exigencias de los usuarios - que al fin y al cabo son las de negocio - obligan a "repasar" el parque de PC's cada 3 o 4 años. La aplicaicón de un Service Pack de Windows (véase caso del SP3) puede convertir un PC perfectamente operativo con 512 Mb de RAM en una tortuga antediluviana tras la actualización.... Y las release notes no decían nada al respecto. No culpo a los fabricantes, al fin y al cabo deben vender, y para ello deben mejorar su producto... lo que normalmente implica más recursos. No miremos sólo a Windows. Por poner un ejemplo, miremos la diferencia entre Ubuntu 8.04 y Ubuntu 9.10.

Por un lado, IT no puede esperar a la evaluación de un determinado Service Pack o Update, porque normalmente ciertas aplicaciones lo requieren. Por otro, la evaluación de impacto de una actualización no suele tener cabida en las tareas de mantenimiento, y pocas compañías disponen de departamentos especializados.

Conclusión.

Fácil. Una mañana nos despertamos y descubrimos que el 40 - 80% de los recursos humanos de IT se dedican al desktop.... y que un temible 60% del presupuesto de IT se lo "come" los tropecientos PC's de los usuarios.

Seguimos en el próximo episodio.

Herramienta: labs.vmware.com

2010-03-09T15:51:00.001+01:00

VMware, al igual que otros fabricantes, ha abierto un sitio web donde se publican una serie de herramientas y utilidades basadas en APIs de sus productos. Este sitio está disponible en http://labs.vmware.com/ .

Un saludo.

Herramienta: vmCLient

2010-03-09T15:38:00.003+01:00

Eric Sloof "fellow vExpert" y reconocido profesional en esto de lo virtual, ha desarrollado una herramienta llamada vmClient, que en resumidas cuentas, es una consola minimalista que nos permite acceder a las consolas y a algunas herramientas de administración de la máquina virtual.

Más información aquí. Ni que decir tiene que ya está cargada en mi desktop y funcionando.

Un saludo;

Consulta Técnica: Conversión de máquinas linux.

2010-03-09T13:37:00.002+01:00

Hace unos días nos preguntaban:

"Hola Jose Luis, bucando,buscando por ahi, he llegado a tu blog.

Estoy intentando vistualizar en ESXi una maquina física con Suse Linux 7.2 y kernel 2.2.19. Tiene unas viejas aplicaciones en cobol que se configuraron hace años, estan emuladas con ibcs porque originariamente eran para Unix Sco. y no tengo ni idea de como montarlas en un entorno nuevo.

Lo he intentado con vmware converter stand alone sin exito. Alguna ayuda, por favor?????

Gracias anticipadas."

La conversión de máquinas linux con converter nunca ha sido un tema simple. Quiero decir que cuando funciona, lo hace a la primera... pero cuando no...

He aquí mi receta, al menos la que me ha funcionado en varias ocasiones:

1. Clonado de la máquina física.

Para el proceso de clonado, yo uso Ghost For Linux. Sé que hay otras herramientas (a gusto del consumidor), e incluso con un dd directamente desde un CD de arranque con linux, pero a mi, casi siempre, Ghost for Linux me ha dado buenos resultados. Frente a dd, permite compresión de la imagen de destino, y con un poco de suerte, sólo te vuelca el espacio de disco usado, no el disco entero.

Ghost for linux tiene una interface algo rebuscada, por lo que aconsejo hacer alguna prueba antes. Sobra decir que has de sacar la imagen sobre un disco USB o similar.

2. Conversión en máquina virtual - Fase 1.

Una vez tengas la imagen de la máquina virtual en un disco USB, vamos a convertir esa imagen en una máquina virtual. Para ello, necesitaremos VMware Workstation, VMware Player o cualquier producto soportado por VMware Converter como máquina virtual a convertir.

Esta VM debería tener la siguiente configuración:

- Disco 0: Un disco de igual o mayor capacidad que la del servidor original a convertir. La controladora debe ser IDE o Buslogic.... En destribuciones antiguas no se suele encontrar el driver LSI.

- CD: La imagen ISO de Arranque de Ghost For Linux

- USB0: El disco USB donde hemos sacado la imagen del servidor a convertir.

Opcional: En caso de no poder/querer usar la opción de mapeo USB, siempre podemos mapear el disco USB en modo RAW a la VM a crear.

Una vez configurado el hardware virtual de la VM, procederemos a arrancarla desde el CD virtual (es decir, con la imagen de Ghost for Linux)

Tras arrancar, Clonaremos la imagen que sacamos en el disco USB sobre el disco 0 de la VM.

3. Arranque de la VM.

Una vez convertida la VM, cruzamos los dedos y arrancamos la máquina virtual. Si todo va bien, la VM debería arrancar sin problemas..... pero si al arrancarla nos da un "kernel panic" es posible (y más que probable) que el driver de disco IDE o Buslogic no esté configurado. Ahora vendrá la parte divertida.

En este momento es buena idea tener a mano un rescue disk de la distribución linux que nos ocupa, o en su defecto, un Live CD de cualquier distribución. Reconfiguraremos la VM para que el CD virtual apunte a la imagen ISO o CD de recuperación, y rearrancaremos la máquina haciendo que esta arranque desde este CD o ISO.

Una vez arrancado y en la lshell, procederemos a montar el disco 0 en, por ejemplo, /mnt/sysimage. Una vez hecho esto, hagamos un chroot a /mnt/sysimage.

naveguemos entonces dentro del nuevo root a la carpeta /etc, y allí encontraremos el fichero modules.conf . Editaremos la línea del alias correspondiente a la controladora de disco original del servidor físico, substituyéndola por el driver Buslogic.

Ahora cambiemos al directorio /boot y, mediante el comando mkinitrd, regeneremos el ramdisk de arranque. (mkinitrd -f -v /boot/initrd-[versión]-img [versión]

Reiniciemos la máquina virtual, desconectemos el CD y, con un poco de suerte, la máquina arrancará a la perfección.

Es buen momento para isntalar las vmware-tools en la VM.

4. Conversión en máquina virtual - Fase 2.

Ahora, y tras apagar la VM, usaremos el converter para pasar nuestra VM a los ESX.

Este no es un proceso infalible, especialmente si usas LVM o si el driver Buslogic no está en el disco original de la máquina. Pero a mí me ha funcionado en unas cuantas ocasiones. Te dejo un par de Links que serán seguro de ayuda.

Un saludo

Linux P2V

How to P2V a Linux machine

Consulta Técnica: View y Thin Clients

2009-11-17T06:59:00.005+01:00

Nos pasan la siguiente consulta:

"Hola JL,

Estoy leyendo tu blog con mucho interés y tengo unas dudas sobre VDI.

Estoy viendo la posibilidad de implantar thin clients en mi empresa y me surge la siguiente duda:

Si pongo thin clients con windows embedded con el view client de vmware, necesitaré un antivirus para proteger los thin clients, ya que no dejan de ser unos mini-pcs con windows?

También he pensado en poner thin clients con linux, que suponemos que tienen el vmware-view-open-client, pero he visto que no soportan la redirección de USB, lo cual es un problema. Sabes si esto es así en estos clientes?

También he pensado en reutilizar los pcs actuales, quitandoles el HD y arrancando por PXE y ejecutando el cliente vmware-view-open-client desde una sesión de LTSP. ( https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall http://www.jaimebalmes.org/php/mod/resource/view.php?id=409 )

Por otra parte, qué platafoma de gestión nos recomiendas para gestionar los thin clients sena linux o windows?

Muchas gracias por tu tiempo.

Saludos."

Efectivamente. Si utilizas Thin clients basados en Windows XP (sea o no embedded) sigue siendo un Windows XP, eso sí, con menos "superficie" de exposición a virus y demás, lo que no implica que debamos prescindir del Antivirus, ya que en un entorno mixto, como dice el maestro Ros, la podemos liar parda. Por otro lado, un entorno de thin clients Linux nos obligará a prescindir de la redirección USB de View, olbligándonos a ir a productos de terceros, salvo que el fabricante disponga de licencia de VMware para la redirección de USB.

Mi recomendación sobre la plataforma de gestión de los Thin Clients es clara: Ninguna. Nunca he terminado de entender eso de migrar a Virtual Desktop para sustituir SMS o System Center por un Thin client management. El uso de clientes basados en linux o Windows obliga, en mayor o menor medida, a disponer de una plataforma de gestión de los mismos, y mi recomendación es que la gestión tire a inexistente. Es un hecho que la plataforma del Thin Client variará substancialmente su precio dependiendo de si el cliente corre o no Windows (Normalmente la gestión de clientes basados en Windows suele ser más cara e implica mayor nivel de gestión).

Tanto en un caso como en otro, el Thin Client puede convertirse en un punto de fallo dentro de la infraestructura View, ya que su propia "inteligencia" lo hace - eso sí, bastante menos - susceptible a fallos en los procesos de actualización y configuración.

Respecto a la opción de convertir PC's en Thin Clients, además de la que comentas (LSTP), dispones de Thin Station, una minidistribución altamente configurable, que incluso dispone de configuradores Web donde "montarte" tu cliente ligero desde ella (los TS-O-MATIC). En el mirror de Dinamarca (DK) incluso te permite integrar el cliente View de VMware. Estos ts-o-matic te permiten crear desde imágenes ISO a imágenes PXE para el arranque. Recomiendo fervientemente esta distribución como iniciación de bajo o nulo coste al mundo del Virtual Desktop.

Si lo que buscas es una solución robusta, sin intervención en el thin client del usuario, que permita redirección USB, compatibilidad con VMware View, en la que despreocuparte ABSOLUTAMENTE del dispositivo y a un coste unitario realmente interesante, te recomiendo los SUN Ray de SUN Microsystems. En mi compañía (y en varios clientes) tenemos la solución funcionando en menos de dos horas. Es realmente elegante y ciertamente potente. Las características incorporadas en la versión 5 (aceleración multimedia, aceleración flash, USB Mapping) junto con las ventajas de siempre (hot desking, multiple monitors - hasta 8, creo recordar) hacen de SUN Ray, al menos para mí, la solución Thin client perfecta. Por no necesitar, no necesitan IP del entorno corporativo. El terminal SUN Ray (DTU para los amigos) es simplemente eso: Un terminal del servidor SUN Ray. Las conexiones con los virtual desktop se realizan desde este, y no desde el terminal, es decir, el SUN Ray client no es más que una pantalla y un teclado extra del servidor SUN Ray (que puede correr tanto en Solaris como en Linux). Te invito a verlo cuando quieras.

Un cordial saludo.

Nota Técnica: VMware View Open Client

2009-10-26T12:43:00.004+01:00

Como supongo que sabéis, VMware ha "liberado" hace ya un tiempo el cliente View (o VDM) para Linux, lo que permite tanto a los forofos y/o usuarios de este sistema operativo como a los fabricantes de Thin Clients acceder a los entornos View desde este sistema operativo.

Entrecomillo "liberar" ya que el cliente en cuestión tiene ciertas peculiaridades, que destaco:

No soporta redirección USB. En la distribución estándar del cliente "faltan" los componentes de la redirección de dispositivos USB, que entiendo que requerirán de licencia OEM al efecto.
Es pelín exclusivo: No tenemos control sobre la ventana del desktop virtual, ya sea para cambiar el tamaño o alternarla con el deskop físico.
Presenta algunos "problemillas" con el teclado: Tiene como buena "costumbre" obligarnos a usar el teclado US en lugar del que tengamos configurado.

Dado que de último uso Ubuntu en mi flamante Sony Vaio VGN-P11z (el vista que trae de serie hace desesperadamente lento al cacharro en cuestión, y Windows 7 no mejoró mucho las expectativas de rendimiento me decidí a "Ubuntear" el portátil, ya que todo mi entorno de trabajo se encuentra en el desktop virtual) el uso del cliente View se volvió necesario, así que me decidí a intentar superar las limitaciones antes expuestas, al menos las concernientes al desktop.

El VMware View Open Client, al igual que su contrapartida en Windows, requiere de un cliente de terminal server previamente instalado en el equipo, en el caso de Linux, rdesktop, así que me dediqué a investigar cómo el cliente View interacciona con rdesktop. Para ello, procedí a realizar lo siguiente:

1. Renombré el binario de rdesktop, localizado en /usr/bin/rdesktop a /usr/bin/rdesktop.bin:

# mv /usr/bin/rdesktop /usr/bin/rdesktop.bin

2. Creé un archivo /usr/bin/rdesktop.wrapper con el siguiente contenido:

#!/bin/bash
echo $* > $HOME/rdesktop.parms
/usr/bin/rdesktop.bin $*

en $* el shell nos suministrará la línea de comandos que View Client le pasa a rdesktop

3. Hice un link simbólico entre el archivo rdesktop.wrapper y rdesktop:

# ln -s /usr/bin/rdesktop.wrapper /usr/bin/rdesktop

Tras lo cual, ejecuté el cliente de vmware view (vmware-view).

Tras conectarme, procedí a examinar el contenido del fichero $HOME/rdesktop.parms, encontrando lo siguiente:

-z -K -g 1280x1024 -X 65012445 -u jlmedina -d bato-its -p - -a 24 -r sound:local :3389 10.0.10.18

Si consultamos las opciones de rdesktop (via man rdesktop) observamos lo siguiente:

-z: Activar compresión RDP

-K: No anular las asignaciones de teclas del Window Manager. Por defecto (es decir, sin esta opción activada) rdesktop intercepta todas las pulsaciones. Esta opción es la que nos impide minimizar la ventana del virtual desktop mediante la pulsación de ctrl+alt+enter

-g: Resolución de la ventana de virtual desktop. Por defecto, VDM ocupa toda la pantalla disponible.

-X: Ejecuta rdesktop dentro de una ventana existente. El comportamiento por defecto de VDM es ejecutar la ventana de rdesktop sobre una ventana invisible que no es minimizable.

-u : Usuario con el que conectarse

-d: Dominio al que pertenece el usuario

-p: password suministrada al cliente VDM

-a: Profundidad de color. Por defecto, VDM utiliza el máximo soportado por VDM, que es 24 bits.

-r: Dispositivos redirigidos. Por defecto, sólo el sonido

el resto corresponde a la IP y puerto del desktop a conectarse.

Por lo pronto, las opciones que parecen "molestarnos", es decir, la de no poder salir de la ventana del Virtual Desktop, son las siguientes:

-K, es decir, la que nos desactiva el ctrl+alt+enter

-X, que ejecuta el rdesktop en una ventana no "resizable".

Si nos limitamos a eliminar estas dos opciones, nos encontraremos con los siguientes "problemillas":

El teclado seguirá estando en inglés EEUU
El virtual desktop se presentará por defecto en modo ventana

Para solucionarlo, deberíamos pasar a rdesktop los siguientes parámetros:

-f: Activa el modo full sreen
-k es: configura el teclado por defecto a español.

Ahora bien... ¿Cómo eliminar opciones y añadirlas a los parámetros que el cliente view pasa a rdesktop?

Como antes dijimos, la variable $* almacena los parámetros que vmware-view pasa a rdesktop, así que aprovecharemos esto para eliminar los parámetros que nos molestan y añadir los que nos faltan. Para ello, volvamos a mi fichero rdesktop.wrapper:

#!/bin/bash

echo $* > $HOME/rdesktop.parms

/usr/bin/rdesktop.bin $*

lo modificaremos para que quede como sigue:

#!/bin/sh

parms=`echo $* awk '{print $1,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17}'`

/usr/bin/rdesktop.bin -k es -f $parms

Básicamente lo que he hecho es, mediante el comando awk, eliminar de la línea de parámetros los que me molestan, y después añadir "a pelo" los que necesito. En este caso, eliminaría los que destaco en rojo:

-z -K -g 1280x1024 -X 65012445 -u -d -p - -a 24 -r sound:local:3389

De esta manera conseguiremos un cliente view funcionando en pantalla completa, que nos permite volver al desktop pulsando ctrl+alt+enter y con teclado en castellano(*)

Espero que os sea útil.

(*) Es posible pasar a rdesktop el código de teclado mediante variable de entorno, pero lamento reconocer que no lo conseguí.

VMworld 2009

2009-08-28T08:52:00.002+02:00

Como ya os adelanté, tenía previsto asistir al VMworld 2009 en San Francisco, aprovechando la invitación de TechTarget para formar parte del tribunal que juzgará los VMworld Awards 2009, pero circunstancias imprevistas de indole familiar me lo impiden. Otro año será.

Un saludo.

J. L. Medina.

Más sobre VDI

2009-08-27T15:19:00.006+02:00

Visto que esto de actualizar el blog siempre requiere un tiempo que no tengo, y como compensación, os dejo un "Whitepaper" que he realizado sobre el tema de los desktops virtuales titulado Virtual Desktop: El futuro de la informática de usuario corporativa, que es lo que me tiene ocupado de último. Espero que os resulte de interés.

Virtual Desktop: El futuro de la informática corporativa de usuario

View more documents from jlmedinan.

Un saludo.

Actualización: Licencia del documento.

Debido a varias consultas al respecto, he decidido ponerlo bajo licencia Creative Commons, según se detalla a continuación:

Virtual Desktop: El futuro de la informática de usuario corporativa by José Luis Medina is licensed under a Creative Commons Reconocimiento-Compartir bajo la misma licencia 3.0 Unported License.
Based on a work at bevirtual.blogspot.com.

View 3.10 y SUN Rays

2009-08-07T08:59:00.003+02:00

Reconozco que para los entornos VDI tengo debilidad por los clientes ligeros. De hecho, cuanto más ligeros (es decir, cuanta menos inteligencia tengan dentro) más atractivos me resultan.

El cliente más ligero que he encontrado hasta el momento son los de la serie SUN Ray de SUN Microsystems. Es lo más parecido a un terminal VT100 (seguro que alguno os acordáis) o a un terminal X que conozco. Los terminales SUN Ray no ejecutan más que un cliente ALP (Appliance Link Protocol) que les conecta al servidor de gestión de los mismos (normalmente un SO Solaris o Linux) que es donde ejecutaremos el entorno que queramos. Sun Ray nació como alternativa de alto rendimiento a X como protocolo de display remoto, pero ya sea por una equivocada comercialización, o por falta de aceptación del mercado, nunca triunfaron demasiado.

Pero es en el entorno VDI donde creo que pueden mostrar todo su poder, precisamente por la falta de inteligencia del elemento situado sobre la mesa del usuario.... no es más que una extensión del monitor, ratón teclado, puerto USB y/o serie del host al que se conecta. Empecemos describiendo la arquitectura de la solución:

- SUN RAY Terminal: Dispositivo de usuario al que conectamos pantalla, ratón y monitor.
- SUN Ray Server: Servidor central que suministra las sesiones y el acceso del SUN Ray Terminal
- VMware View Server: Borker de conexiones de VMware a los Virtual Desktop
- Virtual Center + ESX Server: Infraestructura virtual que soporta los virtual desktop.

¿Cómo funciona todo esto?

Bien. Tal y como hemos dicho, el terminal SUN Ray no dispone de más inteligencia que la que tiene un terminal "tonto" de los de antes. No dispone de Sistema Operativo, Cliente RDP o cualquier otra cosa que nos permita conectarnos a cualquier sistema. Los que conozcáis los terminales Wyse o HP sabréis que estos disponen de cliente RDP, ICA y demás. Estos no. Lo único que hacen al iniciarse es buscar un SUN Ray Server al que conectarse.

Una vez localizado, el SUN Ray server asigna (de manera más o menos oculta) una sesión del Solaris o Linux que tenga instalado.

En una instalación básica de SUN Ray Server, simplemente nos mostrará un Desktop. Aquí es donde empieza toda la adaptación.

Además del SUN ray Server, debemos tener instalados los siguientes componentes del software de SUN Ray:

- SUN ray Conector for Windows: No es más que una implementación del cliente RDP para este entorno:
- SUN Ray Conector for VMware VDM: Es la interface que permite acceder a la pantalla del Login de VMware View.

Es importante señalar que, por el momento, no es posible configurar el SUN Ray server para que se establezca la conexión con el desktop virtual a través del broker. De hecho, VMware View ha de configurarse en modo "Conexión Directa" para que todo este "invento" funcione.

Una vez instalado todo lo anterior, hemos de configurar el servidor SUN Ray en modo "Kiosk". Este modo evita que cuando conectemos la estación SUN Ray el solaris o el linux del servidor nos muestre la pantalla de login y password típica de Unix. Este modo "autologuea" a la SUN Ray y le permite ejecutar cualquier "plugin" o "conector" (vease los requerimientos) de manera transparente. En el caso que nos ocupa, configuraremos el modo kiosco para que utilice el conector VDM.

Como paso intermedio, es necesario instalar en el Solaris/Linux el certificado de VDM... sin él no conectaremos con el broker.

Tras esto, y si nada ha salido mal, deberíamos poder encender nuestra SUN ray y acceder a nuestros Virtual Desktop.

Esta solución es la que hemos elegido en Bató para los PC de la Oficina. Comparados con otros terminales de bajo/medio coste, la velocidad de presentación es sensiblemente superior (hasta un 20%) y nos ofrecen una serie de ventajas que nosotros consideramos fundamentales:

- Si cerramos la sesión en un terminal y nos vamos a otro, volvemos a estar donde estábamos.
- Instalarlos no requiere más que sacarlos de la caja y conectarlos.... y sin preocuparse por el nivel de firmware... tan pronto lo conectas, se actualiza.

- La velocidad de presentación del video en pantalla es lo suficientemente buena para que nuestro financiero no se queje de lo mal que va youtube!!!

Si alguien quiere probarlos y necesita una mano más técnica, que no dude en contactarme.

Un saludo

VMworld'09

2009-07-29T12:33:00.003+02:00

Hasta el momento, nunca había planeado asistir a un VMworld... básicamente por aquello de las veintitantas horas de avión... pero este año, la gente de Techtarget me ha invitado a formar parte del tribunal que otorga los VMworld Awards... y no supe/pude decir que no... así que el 30 de agosto estaré en San Francisco en el VMworld, actuando de juez, y, porqué no, disfrutando de unas cervezas con los vExpert del otro lado del charco.

Os iré contando.

vSphere 4.0: Mis razones para... (I)

2009-05-19T05:59:00.002+02:00

Con este post que tenía a medio hacer hace bastante tiempo comienzo una serie (que prometo terminar) sobre mi particular percepción respecto a vSphere 4.0. Como remarco en el título, lo aquí recogido es mi opinión personal (y por tanto profesional) sobre vSphere 4.0. Los lectores de este blog (si aún me queda alguno después de mi dejadez) son libres de estar o no de acuerdo, y espero que ejerzan esta libertad opinando al respecto. Empecemos:

... No implementar VMware FT en producción:

Sí, leeis bien. Todo un vExpert desaconsejando VMware FT en producción. Como muchos sabéis, Vmware FT permite la ejecución en simultáneo de dos máquinas virtuales haciendo exactamente lo mismo, es decir, una actúa como sombra de la otra en otro host distinto. A priori esto suena bien: si cae un host, la VM sobreviviente recoge la carga de la primera sin impacto para los usuarios. La pregunta es si merece asumir las limitaciones que impone FT para evitar 30 segundos de pérdida de servicio. Mi respuesta es que depende. FT no te va a proteger de una corrupción de datos, ni de la pérdida de los mismos. Si el servicio que nos interesa se cae en la VM primaria, también se caerá en la máquina "shadow". FT no garantiza más que la operación de una VM (ojo que digo VM, no servicio) en caso de caída del host que la aloja. No con esto quiero quitar méritos a FT: Como obra de ingeniería es impresionante. Como medida de continuidad del servicio no deja de ser un paso más. FT puede transmitir la falsa sensación de que se ha elevado el nivel de servicio, y quizá en algunos casos lo haga, haciendo que el responsable de sistemas baje la guardia. No creo que por el momento implemente FT en bases de datos críticas o servidores de correo: La penalización de una única CPU y el desaprovechamiento del nodo donde se ejecuta la VM "espejo" no compensan, al menos, por el momento. Nada como una buena replicación de log de transacciones en una base de datos, a ser posible diferido, como para garantizar la disponibilidad.

... Implementar los vNetwork Distributed switchs: Bonding, load balancing, MACs, etc... Demasiados términos que suenan propios de los chicos de networking. Los distributed switches (en especial el Nexus 1000v de Cisco) acercan a los responsables de networking a un área de la virtualización que, hasta ahora, consideraban extraña: los switches virtuales. Con los Distributed Switches el networking virtual es, por fin, networking, y puede caer en las manos de quien mejor lo controla: La gente de red. Para bien o para mal la virtualización ha caido en la parte de sistemas, olvidando que una parte fundamental del entorno virtual es la red. Ahora este aspecto del entorno virtual se vuelve amigable para los chicos de la red.

... Implementar DPM (si deja de ser experimental): En grandes proyectos de virtualización, el consumo eléctrico tiene su peso. Si a las ventajas inherentes a eliminar toneladas de hierro le añadimos que el hierro con el que virtualizamos también consume lo justo... miel sobre hojuelas.

Paro por el momento.

Un saludo.

Para Javier.

2009-05-19T04:17:00.004+02:00

No hace mucho, recibí este comentario en este blog al que, últimamente, he de reconocer que no presto la atención que debiera. Lo reproduzco porque creo que tiene valor para todos nosotros.

"Hola.He caído por aquí, como quien no quería la cosa, por un comentario de David Cervigón en su blog. Ya estás en mis favoritos.Lo que me impulsa a escribirte es que me has hecho reflexionar en mis pensamientos negativos que últimamente he tenido. Estoy en una empresa de tamaño pequeño (hablando de IT) de la automoción, y ya ves cómo está el patio últimamente en ese sector. Ahora estoy en un ERE, con lo que me toca "descansar" 2 días a la semana. Como consecuencia de eso, mi actitud está siendo la de "que les dén...", vamos, que me da igual lo que pase, que se caigan servidores, que haya problemas en la red, etc. He intentado "jugar" un poco con la virtualización (Hyper-V, vmWare ESXi, ...) pero en 3 días no saco mucho tiempo, sobre todo si hay que mantener el resto del negocio y de las tareas habituales, y si no hay presupuesto.Por eso lo de la reflexión. Me ha gustado tus comentarios, lo del no tener miedo, no preocuparse de los dineros, sino planear qué hace falta y meterse a ello. No es que me vaya a cambiar la vida, pero bueno, has conseguido al menos despertar algún pensamiento positivo en mi cabeza. Espero al próximo miércoles, cuando vuelvo al trabajo, para empezar a planificar y poner en marcha algunas de esas ideas / proyectos / pruebas que desde hace tiempo he querido hacer.Gracias,Javier."

La nuestra es una profesión ingrata. Nadie se acuerda del informático, sea técnico o director, salvo cuando las cosas fallan. Esta profesión requiere de cierta actitud personal para superar la desidia o indiferencia del resto de la compañía. Cuando todo funciona, somos los privilegiados, normalmente fuera de convenio, que ganamos más pasta que los demás. Cuando las cosas fallan, somos los mantas que no hacemos bien nuestro trabajo. Llevo ya unos cuantos años en esto y sé lo duro y difícil que resulta a veces este trabajo. Sé lo angustioso que resulta tener que tomar decisiones sabiendo que no tengo todos los conocimientos o la información necesaria para tomarlas (Todos hemos dudado ante un "Este proceso es irreversible. ¿Está Ud. seguro de continuar?"). Todos hemos dejado horas de sueño, y algún que otro impacto más o menos dañino en nuestra vida personal, por hacer que algo funcione. Todos hemos llorado, para dentro o para fuera, cuando no conseguíamos que algo funcionase tras horas o días de intentarlo.

Entiendo a Javier, igual que entiendo a otros compañeros que, tras partirse la espalda, se encuentran con un ERE, un traslado indeseado, una subida de sueldo que consideran inmerecida, o un ascenso a un tercero que creen merecer.

La vida es básicamente injusta. Es una frase que me gusta decir. Pero creedme que, cada vez que consigo que algo que falla funcione, cada vez que añado una funcionalidad nueva a un sistema, cada vez que cumplo una fecha estimada en un proyecto, me siento orgulloso de haber elegido una profesión ingrata como esta, independientemente de lo que cobre o no por hacerlo.

Esta es una profesión para ser humilde. Para aprender de todos. No de todos los que saben más que nosotros. De todos: desde el becario que llega, pasando por el usuario que se nos queja, siguiendo por nuestro jefe, y acabando por el externo al que han contratado para que nos ayude. Lo importante no es tener razón, sino que las cosas funcionen, gracias o a pesar de nosotros.

Quizá alguno piense que hablo desde una posición privilegiada. Hoy en día quizá ya no toco la tecla como antes, pero sigo siendo, y me sigo sintiendo técnico. Y me guardo mi pequeño hueco de pinchateclas resuelveincidencias. Porque es lo que he sido siempre, y espero no dejar de serlo. Porque me costó mucho llegar a serlo.

No, no somos héroes, pero quiero pensar que cada uno de nosotros se va a la cama cada noche pensando que ha hecho lo mejor que ha podido.

Alguien que conocí una vez, hace muchos años, me dijo: "J. o esto te gusta o estás jodido".

Por suerte, después de veinte años, me sigue gustando.

Un abrazo.

PD. He de reconocer que este post no es sólo para Javier. Hoy nuestra gente ha terminado de montar nuestra infraestructura de test y pruebas en nuestras nuevas oficinas. Son seis servidores Dell T605 donde ejecutamos las nuevas versiones de los hipervisores y nuevas configuraciones y productos que hay en el mercado, en parte como autoformación, y en parte como evaluación para alguno de nuestros clientes. El "CPD" de desarrollo y evaluación de nuestra compañía está en un cuarto de baño reconvertido, donde nuestra gente ha conseguido meter estás máquinas (y su electrónica de red, SAI's y demás aditamentos) después de un impecable trabajo de evaluación de infraestructuras (espacio físico, disipación de calor, etc, etc). Nuestros sistemas de producción están hospedados fuera de la oficina (con producción me refiero a los internos, entornos demo para clientes y alguna que otra cosilla que ya os contaré). Han trabajado duro para conseguirlo. Han metido horas que nadie les va a pagar. Pero hoy, cuando han terminado (y creedme que han empleado soluciones realmente creativas), sonreian satisfechos. Vaya por ellos también. Me siento orgulloso de este equipo de profesionales.

¿Oracle buenos días?

2009-04-20T19:04:00.002+02:00

Así me respondía esta mañana uno de mis contactos en SUN... evidentemente el anuncio por sorpresa de hoy da pié a este tipo de bromas. Contra todo pronóstico (al menos de los gurús del sector), una empresa de Software como Oracle adquiere un fabricante de Hardware como SUN. No hace mucho comentaba con otro de mis contactos en SUN que lo de que les comprara IBM no tenía buena pinta. No puedo imaginar otro interés en SUN por parte de IBM que los clientes de la primera. Resultaba trágico pensar que SUN Microsystems, con su peculiar (correcta o no) manera de hacer las cosas terminara fagocitada por el Gigante Azul.... y mira como son las cosas, el mismo gigante que empezó vendiendo hierro y ahora también tiene software, se encuentra con su némesis inversa: Un tradicional fabricante de software que termina metiéndose a vender hardware. Evidentemente a IBM poca gracia le debe hacer esto: Ni su hardware (y de paso las ventas del mismo) son lo que eran, ni su software ha sabido salir del nicho hardware de la compañía.

Parece que Oracle ha acertado: Unido a su imponente motor de base de datos, toma el control de Java, se deshace de MySQL (que empezaba a cosquillearle por los bajos), y se posiciona en el mercado del hardware con una tecnología avanzada (tanto en el mundo SPARC como en el x64).. y voilá!!... ¿Sólo esto? No. VMware debería poner sus barbas a remojo: Tanto SUN como Oracle demuestran interés en el mercado de la virtualización. SUN con VirtualBox, un hypervisor de tipo 2, y un (ya muy retrasado) xVM, clon de Xen que promete.... junto con una plataforma de gestión completa. Por otro lado, Oracle también hizo sus pinitos (Gracias al gato del CEO de Oracle, que escribe hypervisores cosa mala) con un repintado Xen y una incipiente plataforma de Gestión. Ahora las dos grandes preguntas son:

¿Estaremos ante el tercer gran player en esto de lo virtual?
¿Cuánto se va a pagar por Citrix?

Un saludo.

¡¡Cómo anda el patio!!

2009-04-16T07:22:00.002+02:00

Cisco comienza a vender servidores (ya os contaré que tal), IBM, HP y alguno más deja de vender equipamiento Cisco en la línea Blade. IBM amenaza con comprar SUN y resulta que queda en nada.

Cisco decide meterse en el fregado de servidores con la excusa de que no encuentra un "fabric server" adaptado a sus necesidades..... y de paso se quita el estigma de salir al mercado de servers y almacenamiento de mano de un tercero ( Algunos ya sabéis que si queréis comprar un conmutador Fiber channel para vuestra fastuosa SAN debéis pedírselo al fabricante de la misma, no a Cisco).

A este revuelo se añada vSphere 4.0. Para muchos quizá sólo sea una nueva versión: Para otros resulta ser toda una incursión de VMware en el mundo de las infraestructuras. Partiendo de la base de que el Nexus 1000V de Cisco puede comportarse como una tarjeta más del Nexus 5000 de Core, la cosa va cambiando. El VMware Fault Tolerance (VMware FT) supondrá un enorme cambio en la concepción de el alta disponibilidad: Básicamente compite con los clusters de Microsoft y de Symantec/Veritas. De último llueven las estadísticas sobre rendimiento, certificando que, en la inmensa mayoría de los casos, la penalización del hypervisor no supone un inconveniente para los entornos de producción... o dicho de otra manera, esto de lo virtual resulta que mola.

Y aún habrá más. Este año será crítico en cuanto a las tecnologías de dentro del CPD. Más competidores (no deéis de poner el ojo en Windows Server 2008 R2 o en las siguientes versiones de XenServer).

Añadid a lo que os cuento la presíon presupuestaria que vivimos: Nos aprietan desde arriba para reducir los costes. Y no sólo a los que trabajáis en cliente final, también a nosotros los que os vendemos cosas. Este año, y probablemente el que viene, serán los de la creatividad y la revisión de lo que hemos hecho hasta ahora.

Dejo estas opiniones a vuestra reflexión.

Un saludo.

IT en tiempos de crisis

2009-03-03T12:15:00.003+01:00

Aunque este post se salga un poco de lo habitual en este blog, una conversación que tuve en la sobremesa de ayer me ha hecho reflexionar sobre la oportunidad de escribirlo.

Todos sabemos que estos tiempos son tiempos de recortes. El que más y el que menos habrá recibido indicaciones, más o menos directas, sobre la conveniencia de contener y recortar los presupuestos, tanto de gasto como de inversión (OPEX y CAPEX que dicen los anglosajones), de su departamento de IT. Tampoco es un secreto que, a bote pronto, hay dos grandes partidas donde la tijera amenaza con ejercer: Personal y proyectos.

La partida de personal suele verse afectada (y ya lo está siendo en algunas grandes empresas) por la parte de subcontratación. Todos sabemos que, en la mayor parte de las grandes empresas (motor de la inversión IT por otra parte) la práctica totalidad del personal técnico (y con esto me refiero a los que administran y operan los servidores) son externos. En algunas, las partidas en este concepto han ido creciendo en estos años de bonanza económica como respuesta al incremento en complejidad y número de sistemas y aplicaciones que el negocio ha demandado.

En lo referente a proyectos ocurre más o menos lo mismo. Las inversiones propuestas el año pasado (renovación de parque, ampliaciones, actualizaciones) se consideran, de pronto, prescindibles en un entorno empresarial preocupado por la caja.

Básicamente, al requerimiento de "Más (o al menos lo mismo) por menos" se tiende a recortar en estos aspectos.

En estos tiempos, el peor enemigo del presupuesto IT es el miedo al cambio. El no implementar tecnologías por el miedo infundado al impacto en el entorno IT. Como dijo alguien a quien respeto enormemente, nos pagan para asumir riesgos. Y forma parte de nuestro trabajo el evaluar los riesgos tanto técnicamente como económicamente, y decidir si son asumibles. Y mi experiencia a ambos lados de la mesa (como cliente final y como consultor) me dice que si como profesionales nos dejamos llevar por el "si funciona no lo toques", uno, tarde o temprano dejará de funcionar, y dos, alguien vendrá a exigirnos cuentas de nuestras decisiones no tomadas. Como ejemplo, miremos los downgrades de entorno Host a entorno Wintel: Muchas compañías no lo hicieron por miedo infundado a que un servidor Wintel no pudiese ser tan buen servidor web como un AIX o un Solaris. Otras investigaron, evaluaron y migraron. El tiempo ha demostrado que las segundas, apostando por la evolución del mercado, han conseguido mantener unos presupuestos IT más acordes a los tiempos.

Dicho esto, mi conclusión: Invertir en tecnologías que suponen reducción de costes a corto y medio plazo (de 1 a 2 años) es la mejor manera de, por un lado, hacer más por menos, y por otro, mantener el nivel de servicio e integridad de nuestras estructuras.

¿En qué reducir costes?, evidentemente la pregunta no tiene una respuesta genérica, pero dejadme apuntar algunas respuestas:

Infraestructuras: Espacio en el CPD que tenemos alquilado. Reducción de consumo eléctrico en nuestro CPD. Reducción o paralización de las ampliaciones de aire acondicionado. Reducción de los requerimientos de remote hands en los servidores del datacenter.
Red: reducción o eliminación de los planes de ampliación de los puntos de red. Decomisión de electrónica de red sin uso o potencialmente descartable y eliminación de los contratos de mantenimiento.
Mantenimiento: Eliminación de servidores fuera de garantía, eliminación de excesos en máquinas y electrónica fuera de garantía.
Almacenamiento: Selección de nuevas tecnologías, uso de deduplicación, eliminación de SAN fuera de garantía, reducción de la infraestructura Fiber channel.
Copia de seguridad: Búsqueda de alternativa a la cinta. ¿externalización?, reevaluación de las políticas de copia de seguridad (¿podemos sobrevivir sin un full diario?)
Política de compras: Evaluación de nuevos proveedores (tanto de servicios como de hardware), modificación de los estándares de compra. Racionalización de las compras.
Informática de usuario: Limitación de nuevas adquisiciones de PC's, soluciones de informática centralizada.
Racionalización de las inversiones y renovaciones en seguridad y gestión de sistemas: No eliminarlos... racionalizarlos.
Organización departamental: Gestión del equipo humano, gestión efectiva del conocimiento. Reasignación de funciones.
Análisis en profundidad de la relación entre IT y el Negocio: Idoneidad de las soluciones aportadas. Análisis del ratio coste/beneficio en las mismas.
Creatividad: ¿Qué puede aportar IT al Negocio (y no hablo de migrar a Windows Vista, a la última versión del antivirus o a poner un logo de la compañía en el explorer)?
Plan de choche de mejoras inmediatas: Diseñar un plan de choque que mejore la percepción de IT y/o aporte medidas claras de contención de coste a negocio.

Supongo que a ninguno de vosotros os toma esto de sorpresa. Ahora sólo falta ir a por ello. Dejemos el miedo a lo desconocido a un lado y empecemos a pensar por nuestra cuenta, usando nuestros conocimientos y capacidad. Cuidado con los informes de costes de Gartner y demás: La contabilidad americana no es la española, ni los costes e inversiones se manejan de la misma manera. El "lo bueno viene de fuera" quizá tenga sentido respecto a algunas tecnologías, pero este país tiene memorables casos de reducción de costes que merece la pena estudiar.

PD. ¿Os habéis dado cuenta de que no he nombrado la virtualización ni una sola vez?

Un saludo.

¿Qué significa para mí ser VMware vExpert?

2009-02-28T11:00:00.002+01:00

Como anunció VMware, el hecho de ser nominado vExpert no implica que el nominado sepa más que nadie, o que simplemente los nominadores piensen que sabe más o es mejor que nadie. No ha sido la intención de VMware (y que conste que no hablo en su nombre) discriminar a nadie.

Para algunos, el vExpert es el merecido reconocimiento de VMware a una labor de "evangelización" y/o comunicación en todo lo referente al mundo de la virtualización, eso sí, centrado en sus productos.

En mi caso particular, lo considero un reconocimiento a casi diez años de pelea contínua intentando demostrar que esto de convertir PCs o Servidores en programas tiene sentido. Aún recuerdo cuando recibí el correo de VMware, allá por 1.999 en el que me anunciaban que me dejaban ser betatester de VMware Workstation. Aún recuerdo como me impresionó ver abrirse un Windows 95 en una ventana de mi RedHat 4/5. En ese momento supe que esto de la virtualización (Los PCeros, en aquel momento no sabíamos ni cómo se escribía la palabra en cuestión) me iba a gustar. Como buen teki (Técnico para el resto de los humanos) me dejé arrastrar por lo que atraía mi atención.

Pasó el tiempo, y por aquel 2001 cayó en mis manos el VMware GSX. Aquello ya era más serio: No se montaba como aplicación, sino ya como servicio. Me duró un mes, hasta que empecé a tocar ESX 1.0. Creo que la primera instalación en semi-pre-producción en este país la hice yo (admito divergencias sobre este punto)... Y mis ojos volvieron a brillar cuando conseguí que un IBM xSeries 440 arrancara el ESX y levantara máquinas virtuales. Seguía teniendo la misma mirada incrédula que allá por el 99.

Quien me conoce desde hace años sabe como empecé: Programando Cobol y ensamblador en un Phillips 3500. De ahí pasé a sistemas (Lo siento, el desarrollo siempre me aburrió mucho), y de sistemas, a Comms... Chico Cisco. Por estas cosas de la vida (y de la empresa donde trabajaba) tuve que implementar un directorio activo para un gran cliente, así que tocó estudiar. Y durante un tiempo me dediqué a proyectos Microsoft.... hasta que un día encontré mi hueco y me centré en la virtualización de lleno. Durante todo el tiempo previo siempre usé máquinas virtuales, hasta el punto de hacérseme incómodo el trabajar con máquinas físicas. Costó mucho convencerme a mí mismo de que aquello era apto para producción (para bien o para mal conozco ambos lados de la tecnología: El lado del que la vende y el lado del que la explota). Costó muchas pruebas y mucho tiempo: Sólo en el 2003 me atreví a "meterle" ESX en producción a un cliente. Eso sí, fué un Oracle 8, con 2000 usuarios conectados..... porque el cluster físico se había caído. Y cuando el ESX pudo con ello, volví a sonreir incrédulo.

¿Y sabéis una cosa? Hoy, después de unos cuantos ESX montados, después de todos los proyectos en los que he tenido la suerte de participar... después de evangelizar, tanto fuera como desde este blog.. aún me sorprende ver un Windows 2003 arrancar dentro de un ESX.

¿A qué viene este rollo que os suelto? A que, en cierta manera, la nominación (el "award" que dicen los americanos) es una recompensa (yo lo considero así) a todo ese tiempo, a todo ese esfuerzo.

No diré que no me considero merecedor del "Award". Totalmente al contrario. Y de todas las medallas, chapas y/o certificaciones que pueda tener, esta es de las más preciadas.

Un saludo.

Congratulations! You have received a VMware vExpert Award!

2009-02-25T13:28:00.002+01:00

Vaya con el correo que se me coló en la carpeta del Spam:

"Congratulations! On behalf of VMware, we would like to thank you for all the work you’ve done giving back to the virtualization community and sharing your expertise with others. We are pleased to present you with the VMware vExpert Award for 2009. VMware is giving this award to individuals who have contributed significantly to the community of VMware users over the past year.

VMware vExpert award winners will receive:

* An award certificate and gift

* Access to a private vExpert community

* vExpert logo to display on website or email signature

* Free subscription to conference session materials on VMworld.com

* Access to exclusive online events and other opportunities to participate in activities

* Inclusion in public vExpert directory

The vExpert award duration is one year (through February, 2010)."

He de reconocer que encontrarme en la misma lista que monstruos de esto de lo virtual como Scott Herold, Eric Siebert o Eric Sloof, entre otros, le infla a uno el ego (si no lo tenía ya suficientemente inflado)

Por último, agradeceros a los que me habéis nominado el haberlo hecho.

Un abrazo.

El que faltaba...

2009-02-23T23:56:00.005+01:00

Parece que ya estamos todos. Citrix ofrece "gratis" Xenserver Enterprise. Evidentemente, la jugada tiene sentido: El que se mueve no sale en la foto. Tras una inversión millonaria (500.000.000 US$) por un producto que les ha dado bastante menos del 30% de esa inversión, con Microsoft jugando por su cuenta (lo que quiere decir normalmente en contra del resto) y tras descubrir que tanto Oracle como SUN también sacaban su Xen particular, Citrix se ve obligada a liberar Xen Enterprise.

Parece que Citrix sólo hace negocio con XenServer en entornos VDI... básicamente por su inigualable ICA... y su (supongo) negativa a dejar que su protocolo de presentación se integre con otros brokers.

Eso sí, algunos, lo suficientemente curiosos como para investigar, han descubierto lo siguiente:

La edición "free" de Xen Enterprise no incluye:

HA: Parece que la clusterización ha desaparecido del XenServer Enterprise y ha aparecido con Essentials, que sí es de pago. (entre 1.500 y 6.000 US$ por server).
Workflow Studio: También desaparece de la versión enterprise y "aparece" en Essentials
StorageLink: Los modulos de integración con el almacenamiento también saltan a Essentials.
Workload Balancing: Otra "transmutación".

Otra de las cosas anunciadas (y que curiosamente suena bastante menos), es la presentación de Citrix Essentials for Hyper-V. Supongo que no le hará demasiada gracia a Microsoft.

Como comenté en un post anterior... ¿Cuánto aguantarán los presupuestos de desarrollo de empresas como Citrix el mantener un Hypervisor gratis... especialmente con la que está cayendo?

Como postdata, una curiosidad:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1  xe_license sku_type="XE Enterprise" version="5.0.0" productcode="5f49-fbcc-054f-f13a-7b80-c22f" serialnumber="289fc986-3338-6768-80cf-7b29b00f7197" sockets="64" expiry="1240527600.000000" human_readable_expiry="2009-04-23" name="XenServer Free Virtualization" address1="" address2="" city="" state="" postalcode="" country="" company="" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)  iD8DBQFJlX+1or8EvHqMeKcRAnNUAJ4nqJXkN2yH18A+d1ayYCD6HgNtCwCffscj YK1tVghW0HB7p81IoKyLMOU= =3zXt -----END PGP SIGNATURE-----

Este es el archivo de licencia que acompaña al download "gratuito". Fijaos en la fecha de expiración....

un saludo.

Containerización

2009-01-26T02:02:00.012+01:00

Aprovechando un excelente post de David Cervigón, titulado "Los cimientos de la nube", aprovecho para hablaros un poco sobre este concepto que, cada día, va dejando de ser ciencia ficción y se va convirtiendo en la única alternativa viable a los desbordantes costes de infraestructura que supone un datacenter.

Hay una triste realidad que empieza a aparecerse claramente a los responsables de infraestructuras del datacenter: Lo más barato son los servidores. Mientras con 200k llenamos unos cuantos racks con máquinas (ya sean blades o no), la inversión necesaria para refrigerar un datacenter supone fácilmente muchas veces esa cantidad. No es extraño que el coste de la refrigeración (sumando el coste del equipo y el de la electricidad que consume tanto el equipo como ) supere con creces el coste del servidor.

Si además tenemos en cuenta el coste de provisionamiento de los mismos, la cosa se disparata: Compra el servidor, busca sitio en el CPD para instalarlo, solicita cableados (fibras y red), tensión eléctrica... Estos inconvenientes no sólo aplican a los servidores, sino al almacenamiento, infraestructura de red, etc.

El coste del cableado no es precisamente desdeñable. Conozco casos donde el coste oscila desde unos 200 € la conexión a más de 1000 €. No digo que el cable cueste esto: Digo que ponerlo en marcha se acerca a estos costes.

La instalación de un servidor en determinado rack también puede resultar una odisea: Si tenéis la suerte (o la pasta) de mantener unos racks prístinos y limpios de cables cruzados, no tenéis latiguillos en modo gordiano (de los que sólo puedes deshacerte con un hacha) y además resulta que tienes las U bien asignadas, no sigas leyendo: Para todos los demás, la pesadilla de "¿Cómo meto un servidor sin llevarme por delante el resto?" es una realidad palpable.

Mi compañía esta actualmente trabajando en un proyecto para uno de los CPD más grandes de este país donde toda esta tormenta es una realidad. Hay partes de ese datacenter donde es virtualmente imposible colocar una máquina más sin una parada de servicio que, por supuesto, la compañía no puede permitirse.

Así mismo, los tiempos de provisionamiento de nueva infraestructura son dispares: Desde que se adquiere un nuevo pool de servidores, almacenamiento y red hasta que este se provisiona, puede pasar cerca de un mes: Los servidores pueden estar en una semana, el almacenamiento se instalará después de los servidores, por aquello de saber a qué troncal de fibra deben conectarse, y la red Dios dirá. Y negocio no espera.

Estamos trabajando en la idea de racks consolidados para los servidores y el almacenamiento. La idea es que el proveedor no suministre servidores, sino racks completamente equipados con un número determinado de máquinas preenrracadas, su electrónica de red y su red SAN. El punto de contacto con el resto del CPD se limita a dos conexiones 10G para la red, 4 tomas de 16 amperios y 4 puertos FC de 4 Gbit/sec.

En el caso del almacenamiento, las conexiones se limitan a dos puertos Gbit (para la gestión de cabinas si fuese necesario), 4 puertos FC de 4 Gb y otras cuatro tomas de 16 Amperios.

En el rack de servidores estamos evaluando la posibilidad de usar Infiniband. Mediante dos tarjetas por equipo, conseguimos un ancho de banda acumulado de hasta 40 Gbit/Sec con latencia despreciable, conectados a un router Infiniband que nos ofece 4 10Gb Ethernet de salida y 4 FC de 4 Gb. La simplificación de cableado dentro del propio rack mejora su climatización y su mantenimiento, así como la reducción de conexiones al exterior (12, contra las 60-96 de configuraciones anteriores). Por otro lado, Cisco Systems nos ofrece Datacenter Ethernet (Ethernet sin pérdidas), pero lo de FCoE (Fiber Channel over Ethernet) no termina de convencerme.

En este caso, el proveedor de hardware, Sun Microsystems, suministra los racks así diseñados con P/N propio, lo que simplifica, además, el proceso de compra.

El cliente obtendrá un entorno más ordenado a un precio más asequible, (las ventas del proveedor suben en importe puntual aunque se distancien en el tiempo), una enorme reducción de coste de infraestructura. (no necesita ampliar su electrónica de red de core a trompicones, sino de manera ordenada), requiere menos suelo (racks llenos de potencia y no de U's vacías), y menos cooling (los racks vienen preacondicionados para un cooling óptimo).

Fig.1. Rack Tradicional

Fig. 2. Container

En este ejemplo, el container sólo consolida el I/O, y aún así, supone un considerable ahorro. Si evolucionamos la idea del container hacia la de isla (lo que supone romper con el esquema tradicional de pasillo caliente, pasillo frío) obtenemos soluciones como las de APC, que a continuación ilustro:

Fig. 3. Islas de APC. (Dibujan mejor que yo)

En este esquema, además de consolidar el I/O, es posible consolidar la extracción de calor, y en vez de tener que refrigerar a 19 grados todo un CPD, es posible centrar el frío en "islas" de calor. En este ejemplo, la containerización incluye otro de los aspectos problemáticos del datacenter: El cooling. He visitado fuera de España algunos CPD organizados de esta manera, y creedme que se agradecer no ponerse el polar para entrar.

Fig 3. CPD organizado en islas

Fig. 4. Islas de APC en el Datacenter.

Como podéis observar, el CPD se convierte en una caja de cemento que alberga islas semi-autosuficientes donde se concentran el "hierro" y la electricidad. El datacenter se convierte únicamente en proveedor de protección contra el entorno, electricidad y extracción de calor.

¿Y si damos un paso más?. Mirad por ejemplo el proyecto BlackBox de SUN. Básicamente se trata de un container (esta vez literalmente) que alberga todos los elementos necesarios: Las máquinas, la UPS, el cooling (por agua), la disipación de calor y la protección medioambiental.

Fig. 5. Imágenes del SUN Blackbox

Bajo este concepto, el datacenter como edificio deja de tener sentido. Imaginad una explanada, con una pequeña caseta que alberge las tomas eléctricas para los containers y la conexión de red. Quizá suene fantástico, pero con CPDs a un coste de 170 Millones por 2000m2 útiles, y corriendo los tiempos que corren, quizá no sea del todo un disparate.

Pronto SUN me dará la oportunidad de "curiosear" por uno de sus containers... os daré más detalles.

Una cosa más. La virtualización nos dá la posibilidad de realizar este tipo de agrupamientos sin demasiado impacto. Y como siempre digo, pensad en global y actuad en local.

Un saludo.

Virtualization Industry Survey 2008: The results - Part 1

2009-01-20T09:39:00.003+01:00

Desde virtualization.info, el blog de mi respetado Alessandro Perilli, nos llega el resultado de una encuesta sobre el impacto de la virtualización en los entornos corporativos. Alessandro ha recopilado 1050 respuestas y ha publicado el informe estadístico sobre las mismas. El informe completo lo podéis consultar aquí

Las conclusiones que yo extraigo del informe, reforzadas por mi propia experiencia, son las siguientes:

Q1 - La virtualización resulta económicamente interesante para compañías de tamaño medio alto.

Evidentemente, los evangelistas, técnicos, integradores no hemos encontrado la manera de entrar en la PYME. La pregunta es si la virtualización es apta para este segmento de empresa.

Q2 - En EEUU y en Europa virtualizamos más que en el resto del mundo. Dejando aparte las diferencias económicas, es posible extraer la conclusión de que en los entornos donde el parámetro "coste" es más importante, la virtualización más o menos masiva encaja en un esquema de contención (e incluso reducción) de costes

Q4 - Los impulsores de la virtualización siguen siendo los Técnicos, o al menos, los perfiles con un conocimiento técnico más amplio. Los CIO, reponsables entre otras cosas del presupuesto de IT y los SLA no apuestan por la virtualización como una tecnología que pueda a) reducir costes, b) garantizar los SLA. Esta tendencia, según cuentan los analistas, cambiará a lo largo del 2009.

Q3 - Evidentemente, otra vez, los evangelistas, técnicos, expertos y demás no conseguimos hablar el idioma del negocio para configurar la virtualización como una ventaja presupuestaria y una ganratía adicional de disponibilidad.

Q4 - La virtualización se impone en producción. Se percibe que se han quedado atrás los tiempos en que las máquinas virtuales eran vistas como una fuente de problemas y de deconfianza. Cada vez, y ahí aporto mi experiencia, explotación se siente más cómoda con las máquinas virtuales.

Q5 - La virtualización parece que se extiende de manera masiva por los entornos corporativos.

Q6 - Respecto al hypervisor seleccionado, parece que los ganadores son VMware ESX y Microsoft Hyper-V. Sin entrar en los números de los dos más resaltables, queda claro que el resto de los hypervisores ocupan un pequeño nicho. Los "players" son VMware y Microsoft.

Q7: Resulta impresionante el rango de VM que se indica en la estadística. 50 máquinas virtuales ya resulta un buen porcentaje de los servidores de una compañía... que decir de mil. Resulta curioso el salto del gráfico entre la barra de 500-1000 y la de más de 1000. ¿Interpretaciones? Las grandes corporaciones apuestan claramente por la virtualización.

Q8: Nada sorprendente: La virtualización se aplica en consolidación de servidores y entornos de demo y formación. Aún nos cuesta a los que sabemos de esto convencer a desarrollo.... Por otro lado, confirma que VDI aún necesita desarrollarse, y que la virtualización da una respuesta acertada al mantenimiento de aplicaciones legacy.

Q9: Vaya... el mayor dolor de cabeza parece ser la proliferación de VMs, la planificación de capacidad de la infraestructura virtual y la elección del hypervisor. Lo dicho: Nuevas tecnologías, nuevos problemas.

Q10: Costes, siempre costes. Estoy seguro de que ese 25% son clientes de VMware...

Evidentemente estos números están sujetos a interpretación (por ejemplo, cuantos Hyper-V hay en los entornos de 1 a 50 VM y cuantos ESX hay en los entornos de 500 a más de 1000 VM), pero sin entrar en detalles, este estupendo informe debería hacernos reflexionar... y avanzar.

Un saludo.

¿Cómo se licencia Windows Server en entornos virtuales?

2008-12-23T22:14:00.003+01:00

Sigue habiendo polémica con el licenciamiento. Ya sea por desconocimiento o intencionadamente, se sigue diciendo que ESX es más caro que Hyper-V porque Microsoft permite que si instalas un standard uses otra licencia en virtual sobre esa máquina, o que si usas Enterprise puedes ejecutar hasta 4 instancias sobre esa máquina... o si licencias datacenter tienes buffet libre... Nada como recurrir a las fuentes:

Windows Server 2008: Microsoft Licensing FAQ for Windows Server 2008:

Q. Do the virtualization licensing rights of Windows Server 2008 apply when used with non-Microsoft software virtualization technologies?
 A: Yes. The use rights apply regardless of the virtualization product being used.

Windows Server 2003: Página 7 del documento “Licensing Microsoft Windows Server 2003 R2 to Run with Virtualization Technologies”

"If you have assigned a single license of Windows Server Standard Edition to the server running ESX, then you may run one instance at a time of Windows Server Standard Edition. If you have assigned a single license of Windows Server Enterprise Edition to the server running ESX, then you may run up to four instances at a time of Windows Server. You may not run a fifth instance under the same Enterprise Edition license because that right requires that the fifth instance be running hardware virtualization software and software managing and servicing the OSEs on the server. However, Datacenter Edition permits unlimited running of instances in virtual OSEs."

Conclusión:

Cualquier modo de licenciamiento que afecte a los productos Microsoft afecta a cualquier otro software de virtualización.

Actualización: Como respuesta a mi duda sobre la simultaneidad de uso:

Lo que no tengo yo tan claro es que si usas un 2008 con Hyper-V y creas una VM, puedas usar SIMULTANEAMENTE los servicios de ambas máquinas: la del contenedor y la del contenido; es decir, si puedes usar un IIS en el Windows 2008 con un sitio web a la vez que lo usas en la VM.

Tampoco se aclaran si también las CAL (File server, print server, etc) también se multiplican por 2, por 4 o infinitamente.

El Gran David Cervigón nos aclara:

"Hola

Si, puedes usar simultáneamente los servicios de todas las instancias, sean físicas o virtualesLo de las Client Access CALs depende del modo elegido:

Link de referencia 1 Licenciamiento de Windows 2008
Link de referencia 2 CALs

Saludos"

Un abrazo para David y nuestro agradecimiento por la clarificación.

Para lo que nos interesa:

1 VM Windows Server cuesta lo mismo con Hyper-V que con ESX 3i: Una licencia de Windows Server Standard
4 VM Windows Server cuestan lo mismo con Hyper-V que con ESX 3i: Una licencia de Windows Enterprise
Barralibre de Windows Server cuesta lo mismo con Hyper-V que con ESX 3i: LAs CPU del host licenciadas con Windows Server Datacenter.

Nota técnica: Conversión de Domain Controllers

2008-12-21T11:00:00.003+01:00

Parece que está de moda convertir los domain controller. A pesar de que es una práctica no recomendada, se incrementan las "quejas" de mucha gente que intenta hacerlo. Partiendo de la base de que, en mi opinión, se tarda menos en promover un nuevo DC que en convertirlo, os dejo el link a un KB de VMware para los que aún se atrevan (o no les quede otro remedio) que convertirlo. Sólo un recordatorio: Converter sólo virtualiza un domain controller, no arregla un dominio con problemas. Para lo que sí sirve una conversión de un domain controller es para hacer aflorar o agravar los posibles "problemas" ocultos de un directorio, así que toca revisión exhaustiva el Dominio antes de la conversión (link, otro link, más una enormidad en google). Para los que os tropezáis con uno de esos Domain controller-navaja suiza (es decir, un DC que además tiene trescientas cosas más montadas encima), mi consejo es: Nueva VM, dcpromo para promoverla a DC, migración de roles (os dejo un link por aquí) y un dcpromo en la vieja para despromoverla como DC.

Un saludo.

VMware vSphere: Supuesto nombre para VI 4.0

2008-12-20T09:03:00.003+01:00

Parece que el rumor vBlogosférico parece confirmarse: VMware VI 4.0 se llamará VMware vSphere. Aunque parece que el nombre no triunfa entre otros evangelistas de esto de lo virtual (vease la opinión de Scott Lowe al respecto), debo reconocer que me parece ciertamente adecuado. Teniendo en cuenta que la batalla ya no debería centrarse en el hypervisor (la infraestructura), sino en todo lo que la rodea. Bajo esta premisa, el nombre Sphere (teniendo en cuenta no sólo ESX, sino el resto de productos, vCenter, vCenter Stage Manager, vCenter Lifecycle Manager, vCenter AppSpeed y demás) aspiran a "cerrar el círculo" (o la esfera) alrededor de los servidores me parece ciertamente adecuado. Por otro lado, lo mío no es el marketing, así que puedo estar perfectamente equivocado.

Un saludo.

¿Jumbo frames en iSCSI?

2008-12-18T16:25:00.003+01:00

Bien es sabido y cacareado por la blogosfera que VMware no da soporte a configuraciones iSCSI o NFS en ESX con jumbo frames (frames ethernet de 9000 bytes) (por otra parte, tampoco encuentro la negativa explícita de VMware al respecto). Hoy, curioseando por la web, me encuentro en este documento titulado VMware VDI Storage Considerations la siguiente frase:

"iSCSI solutions can use either the built-in iSCSI software initiator or a hardware iSCSI HBA. The use of software initiators increases the CPU load on the VMware ESX, while HBAs offload this processing time to a dedicated card (as FC HBAs do). To increase the throughput of the TCP/IP transmissions, iSCSI should use jumbo frames. A frame size of 9000 bytes is recommended."

No hace falta que describa la cara que se me ha quedado....

Licenciamiento de sistemas operativos Microsoft en entornos VDI

2008-12-18T07:37:00.003+01:00

El maestro David Cervigón ha publicado un post sin desperdicio sobre cómo licenciar sistemas operativos Windows en entornos VDI. Muchos de vosotros me habéis preguntado cómo se licencia Windows en entornos de desktop virtualizado. Y nada mejor que la respuesta de un experto para aclararos las dudas.

Un abrazo.