Hola
Estamos preparando para las próximas semanas una serie “R2” de Webcasts sobre nuestras tecnologías de virtualización. Estos son los títulos, con las direcciones de registro para acceder a las sesiones en directo y las correspondientes grabadas, que estarán disponibles un par de días después de su realización.
Lunes 29/6/2009: Hyper-V R2: Novedades en el Hypervisor de Windows Server 2008 R2:
Con la versión R2 de Windows Server 2008 se lanza la segunda versión del Hypervisor de Microsoft (Hyper-V). En este webcast veremos las novedades de la plataforma de virtualización que nos trae este sistema operativo, como Live Migration, Clustered Shared Volumes, el soporte a nuevas funcionalidades de los actuales procesadores y las mejoras a nivel de red. También trataremos la integración de Hyper-V con las nuevas funcionalidades incluidas en los Remote Desktop Services de Windows Server 2008 para ofrecer la plataforma de una solución integrada de VDI. Durante el desarrollo de esta sesión, hablaremos también de los aspectos a tener en cuenta a la hora de licenciar entornos virtualizados. Registro gratuito para asistir al Webcast en directo Registro gratuito para asistir al Webcast grabado
Con la versión R2 de Windows Server 2008 se lanza la segunda versión del Hypervisor de Microsoft (Hyper-V). En este webcast veremos las novedades de la plataforma de virtualización que nos trae este sistema operativo, como Live Migration, Clustered Shared Volumes, el soporte a nuevas funcionalidades de los actuales procesadores y las mejoras a nivel de red. También trataremos la integración de Hyper-V con las nuevas funcionalidades incluidas en los Remote Desktop Services de Windows Server 2008 para ofrecer la plataforma de una solución integrada de VDI. Durante el desarrollo de esta sesión, hablaremos también de los aspectos a tener en cuenta a la hora de licenciar entornos virtualizados.
Miércoles 1/7/2009: Gestión de entornos virtualizados con SCVMM 2008 R2 y SCOM 2007 R2:
Uno de los aspectos más importantes de los entornos virtualizados es la gestión de los mismos. La familia de productos System Center nos permiten hacerlo de forma sencilla, unificando además la experiencia y el conocimiento de la administración de entornos físicos. En este webcast veremos como System Center Virtual Machine Manager 2008 R2 nos ayuda a gestionar nuestra plataforma heterogénea de virtualización y el entorno virtualizado que corre sobre ella, y como System Center Operations Manager 2007 R2 nos puede ayudar a automatizar decisiones como el reparto de las cargas de trabajo mientras que monitoriza la salud de nuestras soluciones y servicios independientemente de si estos corren en físico, virtual o en una mezcla de ambos entornos. Registro gratuito para asistir al Webcast en directo Registro gratuito para asistir al Webcast grabado
Uno de los aspectos más importantes de los entornos virtualizados es la gestión de los mismos. La familia de productos System Center nos permiten hacerlo de forma sencilla, unificando además la experiencia y el conocimiento de la administración de entornos físicos. En este webcast veremos como System Center Virtual Machine Manager 2008 R2 nos ayuda a gestionar nuestra plataforma heterogénea de virtualización y el entorno virtualizado que corre sobre ella, y como System Center Operations Manager 2007 R2 nos puede ayudar a automatizar decisiones como el reparto de las cargas de trabajo mientras que monitoriza la salud de nuestras soluciones y servicios independientemente de si estos corren en físico, virtual o en una mezcla de ambos entornos.
Martes 7/7/2009: Estrategias de Alta Disponibilidad y diseño del almacenamiento en entornos de virtualización:
Uno de los principales usos de la virtualización es su aplicación escenarios de continuidad del negocio. En esta sesión veremos en detalle cómo montar una solución de virtualización basada en Hyper-V, Quick Migration y Live Migration, con todo lo que hay que tener en cuenta desde el punto de vista de diseño de los sistemas de almacenamiento y de la infraestructura de red. Se tratarán también aspectos como Geo-Clustering, Guest Clustering, o el dimensionamiento y correcto reparto de las cargas de trabajo de los hosts. Registro gratuito para asistir al Webcast en directo Registro gratuito para asistir al Webcast grabado
Uno de los principales usos de la virtualización es su aplicación escenarios de continuidad del negocio. En esta sesión veremos en detalle cómo montar una solución de virtualización basada en Hyper-V, Quick Migration y Live Migration, con todo lo que hay que tener en cuenta desde el punto de vista de diseño de los sistemas de almacenamiento y de la infraestructura de red. Se tratarán también aspectos como Geo-Clustering, Guest Clustering, o el dimensionamiento y correcto reparto de las cargas de trabajo de los hosts.
Miércoles 8/7/2009: Virtualización del Escritorio con Hyper-V y Remote Desktop Services en Windows Server 2008 R2:
Los Remote Desktop Services de Windows Server 2008 R2 expanden las posibilidades de construir una solución de Virtualización del Escritorio unificando las soluciones basadas en virtualización de la presentación (Terminal Services) y VDI en un mismo conjunto de tecnologías. En esta sesión veremos cómo llevar la presentación de las aplicaciones a los escritorios de sus usuarios independientemente de dónde estén localizados y cómo el nuevo Connection Broker permite además acceder tanto a escritorios virtualizados personales como a “pools” de máquinas virtuales. Además veremos cómo podemos complementar estas soluciones con las técnicas de virtualización de aplicaciones ofrecidas por Microsoft Application Virtualization. Registro gratuito para asistir al Webcast en directo Registro gratuito para asistir al Webcast grabado
Los Remote Desktop Services de Windows Server 2008 R2 expanden las posibilidades de construir una solución de Virtualización del Escritorio unificando las soluciones basadas en virtualización de la presentación (Terminal Services) y VDI en un mismo conjunto de tecnologías. En esta sesión veremos cómo llevar la presentación de las aplicaciones a los escritorios de sus usuarios independientemente de dónde estén localizados y cómo el nuevo Connection Broker permite además acceder tanto a escritorios virtualizados personales como a “pools” de máquinas virtuales. Además veremos cómo podemos complementar estas soluciones con las técnicas de virtualización de aplicaciones ofrecidas por Microsoft Application Virtualization.
Esperamos que sean de vuestro interés.
Saludos
David Cervigón
La reciente aparición del SP2 de Windows Server 2008 hace surgir algunas dudas a la hora de aplicarlo a los entornos virtualizados y a los hosts con Hyper-V.
Lo primero de todo es mencionar que el SP2 de Windows Server 2008 no está relacionado en modo alguno con Windows Server 2008 R2, del mismo modo que el SP2 de Windows Vista no tiene nada que ver con la RC de Windows 7. Por tanto, el SP2 no introduce los cambios de funcionalidad en Hyper-V que ya se pueden observar en la Release Candidate, aunque si incluye un buen número de actualizaciones que será necesario aplicar tanto a hosts como a máquinas virtuales.
A nivel de Host (Actualizaciones para Hyper-V y la Partición Padre)
Para nuevas instalaciones, es conveniente aplicar el SP2 ANTES de habilitar el role de Hyper-V. Esto nos ahorrará trabajo y reinicios. Lo más recomendable es hacerse con un DVD “slipstreamed” que ya contenga el SP2 integrado. De esa manera la instalación recién terminada ya vendrá con el SP2, y tras habilitar el role podremos pasar directamente a la fase de configuración.
Para instalaciones ya existentes, el SP2 aporta:
En particular, el SP2 contiene todas las actualizaciones mencionadas en:
Todas estas actualizaciones debería ser consideradas para ser instaladas individualmente en el caso de no poder aplicar el SP2 a los hosts por alguna razón (por ejemplo, compatibilidad/soporte por parte del fabricante del hardware).
A nivel de máquina virtual (Actualizaciones para los guests / particiones hijas)
El SP2 conlleva una nueva versión de los componentes de integración de Hyper-V, lo que tiene ciertas implicaciones para las máquinas virtuales. La instalación del SP2 en el host no implica la actualización de los ICs en las máquinas virtuales, por lo que habrá que hacerlo manualmente de la forma habitual.
Sin embargo si instalamos una nueva VM con un DVD o ISO de Windows Server 2008 con el SP2 integrado, o si actualizamos a SP2 una VM con Windows Server 2008 no será necesario instalar los ICs. El SP2 ya lleva incluidos los nuevos componentes de integración.
Las migraciones de 2008 a 2008 SP2 pueden llevarse a cabo tranquilamente y de diferentes maneras porque los ficheros de configuración, VHDS, snapshots y estados salvados son compatibles entre versiones. Para el caso particular de hosts en cluster, el método de instalación consiste simplemente en evacuar las VMs del host a actualizar vía Quick Migration, actualizar el nodo al SP2, devolverle sus VMs si así lo deseamos, y repetir el proceso en los demás nodos en el menor tiempo posible. Un cluster puede tener nodos con diferentes niveles de Service Pack, si bien la situación no deseable.
Posts anteriores:
En este post vamos a desgranar el papel que juegan todos y cada uno de los subroles de los Remote Desktop Services de Windows Server 2008 R2 en un escenario de virtualización del escritorio. En el siguiente entraremos ya en detalle a ver cómo se configura el bróker en particular.
Antes de nada, mencionar que en Windows Server 2008 R2, el viejo nombre de "Terminal Services”, presente en nuestros sistemas operativos servidor desde los tiempos del NT 4.0, desaparece del producto en favor de los “Remote Desktop Services”. La idea es englobar bajo este paraguas todas las funcionalidades necesarias para que un cliente pueda acceder a escritorios y aplicaciones remotas de manera unificada. Este cambio de nomenclatura afecta en especial a dos roles, que son el “Remote Desktop Virtualization Host” (nuevo) y el Remote Desktop Connection Broker”, siendo para los demás prácticamente un renombrado, con ciertas salvedades en lo tocante a funcionalidad. A la izquierda los roles de Terminal Services en Windows Server 2008 y a la derecha los de Remote Desktop Services en Windows Server 2008 R2:
A las novedades incluidas en estos roles hay que sumar las del protocolo RDP 7.0 disponible por el momento únicamente en Windows 7 y Windows Server 2008 R2 (Soporte Multimonitor, Aero, Audio bidireccional, DirectX 10 / DirectShow / Multimedia Remoting…)
Remote Desktop Session Host. Virtualización de la Presentación
Este role nos ofrece dos formas diferentes de trabajar:
Para saberlo todo sobre este role:
Remote Desktop Virtualization Host
Este nuevo role consiste en una especie de “pegamento” entre los servicios de gestión de Hyper-V y el Bróker de conexiones, o lo que es lo mismo, entre lo que vemos en la consola de Hyper-V y el mundo de las conexiones RDP. Se encargará de informar acerca de las VMs disponibles en el host al broker y de llevar ciertas acciones sobre las máquinas virtuales. Arrancarlas o despertarlas si están paradas o salvadas en el momento de ser solicitadas por el usuario, o apagarlas tras un cierto tiempo de inactividad.
Este role no tiene mayor misterio ni configuración, y tiene simplemente que habilitarse en todos los servidores de Hyper-V R2 con los que queramos tratar desde el broker de conexiones, sean stand-alone o miembros de un cluster. En las instalaciones “Core” o en Hyper-V server 2008 R2, adopta el nombre de “VmHostAgent”.
Remote Desktop Licensing.
Este role se necesita para gestionar las licencias de acceso de cliente a Terminal Server (TS CALs), que para ser congruentes con el cambio de nombre ahora pasan a llamarse RDS CALs. Prefiero no detenerme mucho aquí en esta ocasión, porque si no voy a acabar siendo blanco de todas las dudas acerca del peliagudo tema de las licencias de Terminal Server y su compatibilidad entre versiones de la comunidad hispanohablante. No obstante aquí hay un montón de información al respecto:
Remote Desktop Session Broker
Es una evolución de TS Sessión broker, que hasta ahora “solo” servía para balancear carga de trabajo entre servidores de una misma granja de Terminal Servers, y reconectar a los usuarios con el servidor en el que estuviera abierta su sesión. Si imaginamos un pool de máquinas virtuales como un conjunto de servidores de Terminal Server configurados de forma idéntica y que solo pueden recibir una sesión de usuario simultánea, la idea es perfectamente extrapolable al mundo de VDI. En este role podemos configurar:
Para configurar y operar los dos escenarios de VDI, el Bróker habla con el RD Virtualization Host de los servidores con Hyper-V donde corren esas máquinas virtuales
Pondré un post dedicado a un ejemplo de cómo montar y configurar el broker en el entorno de pruebas que planteaba en el primer post de esta serie. Mientras tanto:
Remote Desktop Web Access
Como en Windows Server 2008, en R2 el RDWeb consiste en un portal en el que el administrador pone a disposición del usuario todas o algunas de las siguientes cosas.
Remote Desktop Web Access puede recolectar y publicar lo que este expuesto en:
En el primer caso, solo veremos las diferentes Remote Apps definidas en los diferentes servidores. En el segundo veremos las VMs además de todas las Remote Apps que vengan de los servidores/granjas que el broker esté manejando. Por otro lado, un mismo TD / RDSH / Broker puede estar siendo publicados en varios RDWebs diferentes, pudiéndose establecer un control bastante fino de que queremos presentar a los usuarios.
Una novedad es que para acceder al portal se requiere por defecto autenticación. De esa manera se identifica al usuario y sabemos a que VM mandarle cuando haga clic en el icono “My Desktop” y que aplicaciones enseñarle o no según su pertenencia a grupos (solo en RDSH, como hemos dicho mas arriba):
Una funcionalidad interesante de este Web es que expone todas las conexiones en un RSS. Windows 7 es capaz de consumirlos y exponerlos como elementos del menú del usuario. Al igual que los elementos del portal, no son mas que ficheritos .rdp que procesa el cliente de RDP (mstsc.exe)
Más sobre este ejemplo también en el siguiente post. Mientras:
Remote Desktop Gateway
Al igual que en el TS Gateway, este role permite un escenario de publicación segura del protocolo RDP. Es muy similar al uso de RPC sobre HTTPs que hace Outlook para comunicarse con el CAS de Exchange. En este caso le solicitamos al gateway que nos conecte con cualquier cosa que hable RPC que esté detrás. Nosotros hablamos RDP sobre HTTPS usando el puerto 443, y el gateway habla con el destino usando ya el 3389, tras llevar a cabo los chequeos de seguridad y salud pertinentes contra el Network Policy Server (NPS). Este role se pone en la DMZ, quizás junto con el RDWeb y/o se pueden publicar con ISA Server. Es una manera alternativa para conectarnos a clientes y servidores desde cualquier parte, evitando tener que levantar una VPN.
Espero que el resumen os resulte aclaratorio. En los enlaces que os he puesto tenéis bastante más información y seguro que seguirán apareciendo más cosas al respecto un futuro próximo.
Esta en Microsoft Connect (requiere iniciar sesión con vuestro Live ID)
Tengo unos cuantos entornos esperándola con los brazos abiertos. En un próximo post hablaré sobre su instalación/actualización.
Y eso será gracias al Auto Medium Dependent Interface Crossover (Auto-MDIX), que es una patente de HP. Un puerto de red solía utilizar bien MDI para conexiones “directas”, bien MDIX para conexiones “cruzadas”. Po lo general, las tarjetas de red de las estaciones usan MDI, y los hubs/switches al otro lado usan MDIX para que los cables de cobre coincidan. Tradicionalmente, si queríamos interconectar los puertos de dos dispositivos MDI-MDI o MDIX-MDIX teníamos que usar un cable cruzado construido a tal efecto.
Gracias al Auto-MDIX, muchos dispositivos de red entre los que se encuentran la gran mayoría de las tarjetas de red presentes en portátiles/sobremesas/servidores son capaces de “cruzarse” automáticamente, lo que elimina la necesidad del cable cruzado. Si nuestra tarjeta (y su driver) lo soportan, podremos usar los latiguillos de toda la vida para conectar dos equipos directamente entre si.
Eso si, lo que no puede altar en la mochila es el cable cruzado nulo, aunque para Hyper-V ya no es necesario :-)
Me pillará de seguramente de vacaciones :-)
http://www.microsoft.com/presspass/features/2009/Jun09/06-02SteveGuggenheimer.mspx
Hola.
En los dos últimos posts de esta serie dejamos montado lo que constituye la base del sistema de distribución y ejecución de aplicaciones virtualizadas. Falta la parte fundamental, que es el proceso de virtualizar la aplicación y generar el/los paquetes correspondientes, que es los que se conoce como proceso de secuenciación.
Como de costumbre, antes de continuar, os recomiendo un par de imprescindibles, si bien internet está llena de guías con pistas y trucos para secuenciar aplicaciones, tanto genéricas como de casos particulares:
Para ilustrar el proceso, voy a utilizar una aplicación que todos conocemos, y que nos lleva acompañando en las demos durante ya unos años porque ofrece un ejemplo de aplicación de esta tecnología muy jugoso. El programa Padre (Renta 2008) de la Agencia Tributaria. Así además, los más rezagados pueden aun aprovecharse de todo esto antes de que se termine el plazo para presentar la declaración del año pasado (para los que me leáis desde fuera de España, el programa Padre es una aplicación que se usa para ayudarnos en nuestra declaración anual de impuestos). Sin embargo, el éxito en la correcta secuenciación de una aplicación depende MUCHO del grado de conocimiento que se tenga de ella. Dado que de los que se trata es de meter en una especie de burbuja todo lo relativa a ellas, cuanto más sepamos del uso que hace del sistema de archivos, objetos del sistema, registro, etc. mejor seremos capaces de meter dentro todo lo que necesita para funcionar.
1.- Preparando la máquina para secuenciar e instalación del secuenciador.
La secuenciación de la aplicación la haremos en una máquina física o virtual que tendrá dos particularidades. Primero, tendrá como sistema operativo la versión “más baja” de todos aquellos sobre los que correrá posteriormente virtualizada. Generalmente se utiliza Windows XP en la que habremos definido al menos dos particiones sobre el mismo o diferentes discos. El segundo de ellos lo marcaremos con la letra Q:. La guía de recomendaciones sobre cómo configurar la estación de trabajo sobre la que secuenciamos está en apartado “Sequencer Workstation Configuration” de la guía mencionada arriba.
No voy a insistir mucho sobre la instalación del propio secuenciador, porque es un puro siguiente, siguiente, finalizar que no tiene ningún misterio.
2.- Secuenciación de la aplicación.
La secuenciación de una aplicación se lleva a cabo en cuatro fases. En tres de ellas el secuenciador monitoriza su instalación, ejecución y personalización, y en la última se genera el paquete teniendo en cuanta como será utilizado posteriormente.
Primeramente, el secuenciador nos solicita un nombre para la aplicación:
Tras ello, nos pide que lancemos el proceso de instalación de la aplicación, así como la carpeta que usaremos como directorio principal dentro de la partición Q: que tenemos preparada para ello. En este caso me estoy saltando una ”best-practice”, ya que debería haber elegido un nombre más representativo de la versión (AEAT2008, RENTA2008, etc.) para que si quiero tener diferentes versiones de la aplicación corriendo simultáneamente, cada una use su propia carpeta:
Se carga el entorno virtual, y se nos solicita que se inicie la instalación de la aplicación:
Lanzamos la instalación de la aplicación y seguimos el proceso que marque. De hecho la instalación esta sucediendo realmente en la estación donde estemos secuenciando. Tras finalizar el proceso, se descarga automáticamente el entorno virtual:
Es posible que la aplicación necesite que se agregue algún archivo en particular para que funcione correctamente. Dependencias de ejecutables o dlls, ficheros específicos de configuración, etc. Este es un punto donde cobra especial importancia el conocimiento de la aplicación. En nuestro caso, que sepamos, no se requiere nada en particular:
Cambiamos de fase, y el secuenciador nos pide que lancemos las aplicaciones que se han agregado al sistema durante el proceso de instalación y que las configuremos. En este caso el paquete tendrá tres componentes individuales, que se usarán y descargarán según se vayan o no ejecutando. La propia aplicación, la Ayuda y el Léame. Pedimos al secuenciador que las ejecute. De nuevo, este paso es importante y será más efectivo según el conocimiento que se tenga de la aplicación. Es el momento de configurar la apariencia de la aplicación y asegurarnos de que se instancian todos los componentes que pudiera contener, de modo que todo eso vaya a parar dentro del paquete. En este caso lo cierto es que no tiene demasiado misterio (podría eliminarse, por ejemplo, el mensaje de bienvenida del Renta 2008 para que no aparezca en las posteriores ejecuciones de la aplicación. Este primer uso decidirá además que partes se meten en la primera descarga mínima que hará el cliente para usar la aplicación por primera vez (es posible que en ese primer uso se utilicen ya directamente todos los ficheros y no se observe una descarga progresiva durante el uso posterior de la aplicación).
Tras esta fase de ejecución/configuración, dejamos que el secuenciador genere el paquete de la aplicación virtualizada:
Por último, deberemos personalizar el paquete. Aunque parece trivial, lo cierto es que tiene su miga. Aquí será donde “conectaremos” este paquete en particular con la configuración que hayamos elegido para nuestro sistema de distribución de aplicaciones. En la segunda imagen se observa cómo se configura el servidor de streaming, la carpeta a partir de la cual se intentará localizar el paquete (si especie de “directorio virtual” usando un paralelismo con IIS) y los sistemas operativos en los que puede funcionar el paquete. También se puede generar un MSI para distribuir la aplicación mediante cualquier técnica de despliegue de software.
Por último se elige el nombre del paquete, se salva, y en la carpeta elegida tenemos todos estos ficheros:
Por último, veamos cómo se importa todo esto en la consola del servidor de App-V mediante el asistenta para importar aplicaciones (puede hacerse también manualmente a base de los OSD y los STF):
Se nos pregunta dónde se quiere que aparezcan los iconos y los grupos de usuarios de Directorio Activo que tendrán derecho a utilizarlos. Solamente a ellos se les mostrará la existencia de la aplicación correspondiente:
Por último, el asistente de importación copiará los .OSD y las carpetas con los iconos a los lugares adecuados dentro del sistema de directorios virtuales del servidor de management de App-V. Por razones que no vienen al caso, entre las que se encuentra la vaguería, esta imagen es inconsistente con algunas de las anteriores en el nombre UNC (vamos, que esta sacado de otro servidor diferente y debiera poner \\TS-APPV\App-V-Content\… para ser consistente con lo que especifiqué aquí.
Una vez colocada cada cosa en si lugar el proceso es el que sigue. Todo este proceso se encuentra perfectamente detallado en el documento App V Application Publishing And Client Interaction:
He de reconocer que hasta la fecha he sido incapaz de montar un sistema como el descrito en estos tres post que funcionase a la primera. Fallos de sintaxis en los paths y en las URLs, olvidos a la hora de poner la lista de sistemas operativos soportados, etc. son frecuentes cuando se monta algo de este estilo. No os desaniméis, que, como todo, cuando se le pilla el tranquillo la cosa es ciertamente gratificante y te sentirás el dueño y señor de las aplicaciones que se despliegan en tu infraestructura.
En los próximos capítulos, Remote Desktop Services y VDI, que combinan muy bien con todo esto :-)