Microsoft, su tecnología y yo

Licenciamiento en entornos virtualizados

DavidCervigon — Mon, 16 Nov 2009 00:40:55 GMT

Hola

He actualizado tres posts que tenía al respecto con la última información y las dudas más frecuentes.

y en forma de presentación:

Licenciamiento en Entornos Virtualizados.pptx

Espero que os resulte de utilidad

David Cervigón

Licenciamiento en entornos virtualizados: La Gestión

DavidCervigon — Mon, 16 Nov 2009 00:37:00 GMT

NOTA: Escrito originalmente el 8/2/2009 y modificado el 16/10/2009 para incluir la diferenciación entre las versiones Enterprise y Datacenter de la Server Management Suite y las dudas más frecuentes que nos han transmitido acerca de este tema en el último año

Continuo con la serie de licenciamiento en entornos virtualizados. Antes de nada, un breve resumen de lo que he publicado al respecto hasta la fecha:

Todo el mundo coincide que uno de los principales retos que supone la virtualización, si no el mayor, es la variación y el crecimiento sin control de la infraestructura. Es famosa la sentencia de Thomas Bittman en la que, parafraseando al famoso anuncio, viene a decir que la virtualización sin control no sirve para nada. De hecho, es un poco más duro afirmando que en ese caso, es todavía más peligrosa que no plantearse virtualizar en absoluto.

La estrategia de Microsoft en torno a la virtualización se puede resumir de manera sencilla. Dotar a su sistema operativo servidor de un hipervisor (Hyper-V) que pasaría a convertirse en una mera "commodity" del mismo, y enriquecer y adaptar su familia de productos de gestión (System Center) para las nuevas necesidades que el mundo de la virtualización introduce en las infraestructuras. Además, otras tecnologías que llevan presentes más tiempo en el mercado, como son Terminal Server y Softgrid, evolucionan para continuar ofreciendo alternativas muy válidas para gran número de entornos a la hora de "virtualizar " el escritorio del usuario, y a la vez que convergen con la posibilidad de albergarlos en el datacenter, convirtiéndose en la vía de acceso a máquinas virtuales de escritorio corriendo sobre un hipervisor o incluso a "Blade PCs".

Centrándonos en los productos de la familia de System Center, vamos a ver como aplica cada uno de ellos tanto a Hyper-V (u otros hipervisores) como a las máquinas virtuales que corren encima:

System Center Virtual Machine Manager: Uno de los últimos productos llegados a la familia, tiene por objeto gestionar la infraestructura de virtualización (Hyper-V, ESX y Virtual Server 2005 R2 SP1), gran parte de las operaciones y el aprovisionamiento de las máquinas virtuales, las conversiones P2V y V2V, y los permisos y vías de acceso que tendrán los usuarios a sus máquinas virtuales.
System Center Configuration Manager: Ofrece la centralización de la configuración tanto de hosts como de VMs, sus actualizaciones, técnicas avanzadas de despliegue de software y de sistemas operativos, etc.
System Center Operations Manager: Es el sistema de monitorización del estado de salud y gestión de servicios de principio a fin, ofreciendo también multitud de informes de auditoria y análisis de rendimiento. En lo tocante a todo aquello que afecte a la infraestructura virtualizada, conecta con SCVMM2008 en temas como los Performance and Resource Optimization (PRO) Tips, informes específicos y vistas del estado actual de todo el entorno.
System Center Data Protection Manager: Permite la protección continua de los datos almacenados en un buen número de productos de Microsoft (Sistema Operativo, Carpetas compartidas, Exchange, SQL, Sharepoint, Virtual Server, Hyper-V), y en el caso de los entornos virtuales nos permite la protección tanto a nivel de host (backup de VMs), como a nivel de VM (copia de seguridad de los datos que haya dentro de la VM).

Antes de pasar a ver a grandes rasgos cómo se licencia todo esto, aclaremos tres conceptos:

ML = Management License. La hay de cliente y de servidor, y representa el derecho a ser gestionado por cada uno de estos productos. Salvo Virtual Machine Manager, que "se engancha al host de virtualización) el resto de productos pueden gestionar tanto clientes como servidores, sean físicos o virtuales.
OSE = Operating System Environment. Es decir, una instalación de un cierto Sistema Operativo, sea en físico o en virtual.
Device = Dispositivo = Equipo físico, sea servidor o cliente.

Como de costumbre, para un estudio de tallado de precios y de cómo todo esto puede aplicar en nuestro caso, es conveniente contactar con nuestro distribuidor o con las persona con las que tratemos habitualmente este tipo de asuntos. Además, la web de referencia es esta http://www.microsoft.com/systemcenter/en/us/management-suites.aspx.

Licenciamiento por separado (seguramente no te interese licenciar así, y menos en entornos virtualizados)

SCOM, SCCM y SCDPM:
- La instalación de cada "Management Server" (la consola, vamos) tiene su propio coste, que puede incluir o no la instancia de SQL necesaria para su funcionamiento. Es independiente de que la instalación se realice en físico o en virtual.
- Cada OSE requerirá que se adquiera una ML. Es decir deberemos pagar por cada servidor o cliente que vayamos a gestionar (es decir, por cada agente que desplegamos). Es independiente de que el OSE sea físico o virtual.
SCVMM2008:
- La instalación de cada Management Server no tiene coste alguno. Puede usarse una edición "Express" de SQL, que también es gratuito, si no tenemos adquirido SQL.
- Cada "Device" requerirá que se adquiera una ML. Es decir, cada host que agregamos al entorno de SCVMM2008 tiene un coste, independientemente de que sea un Virtual Server, un Hyper-V o un VMware ESX/ESXi.

Las Server Management Suites. (Estas son las buenas)

Como lo anterior se dispara en costes a medida que en un mismo servidor alberga una cantidad considerable de OSEs (en este caso virtuales), podemos licenciar conjuntamente las Management Licenses de estos cuatro productos de la familia System Center con las Server Management Suites:

Server Management Suite Enterprise (SMSE). Asociando una ML de la SMSE a un host físico podemos gestionarlo a el y a 4 instancias virtuales de Windows Server
Server Management Suite Datacenter (SMSD). Licenciando cada procesador del servidor físico con una ML de la SMSD, podemos gestionar el servidor físico e ilimitadas instancias virtuales de Windows Server desde SCVMM, SCOM,SCCM y SCDPM.

Los "Management Servers" con SCOM, SCVMM y SCDPM (las consolas) siguen teniendo su propio coste, que puede incluir o no la instancia de SQL necesaria para su funcionamiento. Es independiente de que la instalación se realice en físico o en virtual. Sin embargo, pueden instalarse gratuitamente tantos Management Servers de SCVMM como se quiera.

Como vemos, existe un paralelismo entre la SMSE y Windows Server Enterprise, y entre la SMSD y Windows Server Datacenter. Si hemos asignado un cierto número de licencias de Enterprise necesitaremos un número equivalente de SMSEs asociadas a ese host para gestionar todo el conjunto desde los cuatro productos de la familia System Center. Si por el contrario hemos optado por licenciar los procesadores del host para gozar de ilimitadas instancias virtuales de Windows Server, necesitaremos licenciar los procesadores del host con la SMSD.

Nuevamente, este modelo de licenciamiento de la gestión es independiente de la tecnología de virtualización elegida. Por tanto, un buen licenciamiento del entorno de virtualización, y sobre todo si lo que se va a virtualizar es Windows Server, consiste principalmente en la combinación de dos licencias:

Elegir la correspondiente a la edición de Windows Server (Enterprise o Datacenter) adecuada para el host de virtualización en función del número de máquinas virtuales con Windows Server que vayan a correr encima. Recordemos que esto es además independiente del fabricante del hipervisor que hayamos elegido para ello.
Cubrir cada host con la SMSE o SMSD, para poder gestionar con libertad y de manera unificada tanto el entorno físico como el virtual.

Es importante mencionar dos cosas:

Que estas suites pueden estar asociadas a hosts que no estén dedicados a virtualización, sino que todavía sean una carga de trabajo física.
Las SMSE/SMSD son Server Management Licenses, y por tanto no aplican a instancias virtuales de Windows Client. La SMSE/SMSD no permiten la gestión de las instancias virtuales de Windows Client. Estas pueden adquirirse por separado o como parte de las VDI Suites

Saludos

David Cervigón

Licenciamiento en entornos virtualizados: VDI

DavidCervigon — Sun, 15 Nov 2009 20:56:00 GMT

NOTA: Escrito originalmente el 18/12/2008 y modificado el 15/10/2009 para incluir las nuevas VDI Suites y las dudas más frecuentes que nos han transmitido acerca de este tema en el último año

Hola

Como de costumbre cuando escribo sobre estos temas, es importante aclarar que dada la naturaleza perecedera de un blog y lo complejos que resultan en ocasiones los modelos de licenciamiento, la información que sigue debe tomarse como una mera referencia y acudir a nuestro distribuidor o contacto comercial habituales en busca de la última información y precios.

Cuando se habla de virtualizar escritorios Windows y llevárselos en forma de máquinas virtuales a vivir sobre un host en el datacenter, es importante tener en cuenta el modelo de licenciamiento que aplica a estos entornos. Al igual que sucede con Windows Server esto también es cierto a la hora de licenciar Windows Client:

Los sistemas operativos Windows se licencian por dispositivo. Dado que una máquina virtual no lo es, tenemos que licenciar el dispositivo en el que corre dicha máquina virtual, o el dispositivo desde el que se accede a ella.
Su licenciamiento es independiente del fabricante de la solución de virtualización que sustente la solución.

Pongamos, y perdonad la “maldad”, que somos usuarios de un Mac o un Linux pero tenemos una máquina virtual con Windows para trabajar. En ese caso, seguimos teniendo adquirir una licencia de Windows para ese dispositivo y estaremos en situación perfectamente legal. Según el EULA de Windows (si nunca leíste un EULA, aquí están los End User License Agreements de todos los productos de Microsoft):

En lugar de usar el software directamente en el dispositivo con licencia, podrá instalar y usar el software solamente en un sistema de hardware virtual (o emulado de cualquier otro modo) en el dispositivo con licencia.

Pero, ¿que sucede si queremos llevarnos las instancias virtuales de Windows XP, Vista o 7 a correr sobre un hypervisor en el datacenter?. En este caso tenemos dos opciones:

Adquirir tantas versiones FPP (Full Product Package), o “cajas”, de Windows como máquinas virtuales se vayan a montar e instalar las una a una en cada máquina virtual con su propia clave y activación independiente. Además de ser caro y tedioso, las licencias irían a parar no a las VMs si no al servidor físico, de donde no podrían moverse. Adicionalmente a esto, el EULA dice que no se pueden licenciar dispositivos con más de dos procesadores. Esta vía no es desde luego nada recomendable en casi todos los escenarios.
Adquirir una licencia de Windows Virtual Enterprise Centralized Desktop (VECD) para el dispositivo desde el cual vamos a acceder a esa instancia virtual de Windows Client. VECD resulta más barato y otorga derechos adicionales que detallaremos a continuación.

Virtual Enterprise Centralized Desktop (VECD)

VECD es una suscripción anual que se asocia al dispositivo desde el que vamos a acceder a la infraestructura de VDI. En función de la naturaleza de dicho dispositivos podemos optar entre dos tipos de licencias VECD:

VECD para Software Assurance: Válido para dispositivos que estén cubiertos por Software Assurance como parte del contrato que el cliente tenga suscrito con Microsoft
Windows VECD: Para dispositivos que no estén cubiertos por SA, lo cual incluye las versiones OEM de Windows y los Thin Clients

Los precios de estas suscripciones dependen nuevamente del tipo de contrato que tenga el cliente, pero se puede estimar que Windows VECD es entre 4 y 5 veces más caro que VECD for SA, donde ya se reconoce la inversión el cliente en la plataforma Windows.

En ambos casos, la suscripción anual es re-asignable a otro dispositivo de acceso de las mismas características pasados 90 días, y nos da derecho a acceder desde dicho dispositivo a hasta 4 instancias virtuales concurrentes de Windows corriendo en máquinas virtuales en el datacenter. Además estas instancias virtuales pueden moverse libremente entre diferentes hosts de virtualización. Toda la información la tenemos aquí:

El proceso para licenciar VDI no consiste por tanto en el recuento de máquinas virtuales, sino en el de los dispositivos físicos desde el que se accede. Solo tenemos que clasificarlos entre cubiertos o no con Software Assurance y adquirir las versiones de VECD que correspondan a cada uno de los dos grupos.

Durante el último año, estamos detectando una grave confusión en la venta de soluciones basadas en VDI. Si alguien durante el hipotético análisis del ahorro de costes de la centralización del escritorio con VDI te dice que puedes usar “el Windows que ya tienes” para instalar las máquinas virtuales, invítale amablemente a abandonar tus oficinas, porque, o no sabe de lo que habla, o sencillamente te está queriendo engañar. En estos casos, “el Windows que ya tienes” se refiere a las licencias que el cliente adquiere mediante un contrato de volumen. Como es bien sabido, dichas licencias solo otorgan derechos de actualización a la versión de Windows adquirida, siendo ilegal instalarlos en equipos sin sistema operativo, como es el caso de una máquina virtual. Generalmente se adquieren equipos a través de un fabricante determinado con sus licencias OEM de Windows, y se usa la licencia de actualización para plataformarlos con la imagen corporativa deseada. Y dado que las versiones OEM van asociadas al equipo, tampoco pueden utilizarse para instalar la máquina virtual.

Una vez analizado el requisito clave del licenciamiento de VDI, vamos a ver en qué consisten las VDI Suites que Microsoft a anunciado en Octubre de 2009 para complementar (no sustituir) VECD.

Las VDI Suites

Las nuevas VDI Suites son una pieza opcional, y adicional a VECD. Son también subscripciones anuales asociadas al dispositivo de acceso a la máquina virtual. Esto es lo que incluyen:

VDI Suite Standard

Microsoft Hyper-V Server 2008 R2 como hypervisor (que en cualquier caso es una descarga gratuita)
Los derechos de gestionar las máquinas virtuales desde System Center Virtual Machine Manager, System Center Operations Managers y System Center Configuration Manager. Dicho de otro modo, incluye las Client Management Licenses de SCVMM, SCOM y SCCM para las 4 instancias virtuales a las que podemos acceder desde el dispositivo licenciado con VECD (insito, esto es adicional y complementario a VECD, que es un requisito)
Dado que para pasar por el Connection Broker que se incluye en los Remote Desktop Services de Windows Server 2008 R2 es necesario una RDS CAL, esta se se incluye, pero limitada única y exclusivamente a acceder a la infraestructura de VDI.
Microsoft Desktop Optimization Pack. Entre todas las herramientas que este paquete incluye, lo más atractivo en entornos de VDI es que aquí va incluido Microsoft Application Virtualization

VDI Suite Premium. Además de todo lo incluido en la VDI Suite Standard se incluye:

Una RDS CAL para acceder de forma ilimitada a los Remote Desktop Services de Windows Server 2008 R2 (el clásico Terminal Server), bien a escritorios completos, bien a aplicaciones remotas.
El uso del Microsoft Application Virtualization para Terminal Services, con lo que las aplicaciones corriendo en las sesiones del servidor pueden a su vez estar virtualizadas con App-V

Obviamente, la versión Premium está pensada para aquellos clientes que deseen combinar las dos estrategias de centralización de escritorios más frecuentes. Hosted Virtual Desktops (VDI) y Server Based Based Desktops (Remote Desktop Services) y que en ambos casos quieran potenciar la solución con la virtualización de aplicaciones. La inclusión de las licencias de cliente de los productos mencionados de la familia de System Center tienen como propósito no descuidar la gestión del sistema corriendo dentro de la máquina virtual. Seguimos necesitando gestionar y operar correctamente los sistemas operativos virtualizados. Adicionalmente, y solamente si los hosts van a albergar únicamente VMs con Windows Client, podemos desplegar los agentes de los productos mencionados también a los hosts.

¿Puede usarse una VDI Suite para soluciones basadas en otras soluciones de virtualización que no sean Hyper-V?. Por supuesto que si, solo que en ese caso necesitaremos un desembolso adicional, en el hypervisor, en el broker, y en otros componentes.

Conclusión:

Como ya hemos comentado por aquí en más de una ocasión, Virtualización del Escritorio es mucho más que VDI, siendo este último una de las opciones para alcanzar el objetivo. Si queremos montar una solución de virtualización del escritorio que incluya VDI necesitaremos:

Mandatorio: VECD for SA o Windows VECD para los dispositivos de acceso
Opcional: VDI Suite Standard y/o Premium

Y lo anterior es independiente del fabricante de la solución de virtualización elegida. Lamentablemente, sospecha de cualquiera que te diga que no necesitas VECD para una infraestructura de VDI

Referencias:

http://www.microsoft.com/windows/enterprise/solutions/virtualization/improve-flexibility.aspx
http://www.microsoft.com/virtualization/en/us/products-desktop.aspx
http://www.microsoft.com/licensing/
http://www.microsoft.com/windows/enterprise/products/mdop/default.aspx
http://ladylicensing.spaces.live.com/Blog/cns!87F95F1B5B21B01E!1965.entry
Antiguo, pero útil:

http://download.microsoft.com/download/e/4/4/e4442c9f-30d9-41f3-9876-82bbfc5aa4e6/windows_vista_enterprise_centralized_desktop.pdf
http://download.microsoft.com/download/d/5/f/d5f15b1e-a8e4-4e2c-b85f-d69d3f132cb1/VECD_Licensing_Guide_090208.pdf
Este último lo han traducido mis compañeros de marketing y contiene una lista de escenarios de uso más frecuentes. Os lo dejo a continuación:

Saludos

David Cervigón

Licenciamiento en entornos virtualizados: Windows Server

DavidCervigon — Sun, 15 Nov 2009 12:01:00 GMT

NOTA: Escrito originalmente el 31/10/2008 y modificado el 15/10/2009 para incluir los cambios introducidos en Windows Server 2008 R2 y las dudas más frecuentes que nos han transmitido acerca de este tema en el último año.

Hola

Cuando uno adquiere una licencia de Windows Server 2008 R2, esta adquiriendo los siguientes derechos:

Standard: Los derechos de ejecución de una instancia física de Windows Server 2008 R2 Standard y los derechos de ejecución de una instancia virtual de Windows Server 2008 R2 Standard sobre el servidor licenciado
Enterprise: Los derechos de ejecución de una instancia física de Windows Server 2008 Enterprise y los derechos de ejecución de cuatro instancias virtuales de Windows Server 2008 R2 Enterprise sobre el servidor licenciado
Datacenter: Los derechos de ejecución de una instancia física de Windows Server 2008 R2 Datacenter y los derechos de instalación de ilimitadas instancias virtuales de Windows Server 2008 R2 Datacenter sobre el servidor cuyos procesadores hemos licenciado

Nótese que la diferencia entre Standard/Enterprise y Datacenter es que los dos primeros se licencian por servidor, y el segundo se licencia por procesador (físico, no por número de cores). Es importante recalcar que Microsoft no licencia sus sistemas operativos para otra cosa que no sean dispositivos físicos, bien sean servidores o procesadores. En otras palabras, no se puede asignar una licencia de Windows (Server o Client) a una máquina virtual.

Otro error frecuente en torno a todo esto es confundir los derechos que os otorga el licenciamiento con las capacidades técnicas del producto. Hyper-V tiene exactamente las mismas capacidades en las tres ediciones de Windows Server y no está limitado a la ejecución de un número particular de máquinas virtuales. Las diferencias radican solamente en las capacidades de la edición de Windows, en lo tocante al soporte de número de procesadores, cantidad de memoria RAM, o funcionalidades de alta disponibilidad no presentes en la Standard

Consideraciones importantes:

Este modelo de licenciamiento es independiente del software de virtualización utilizado.
- Cualquier servidor físico que sobre el que vaya a correr una instancia virtual de Windows Server debe ser licenciado independientemente del Hypervisor que se vaya a utilizar. En este caso no estamos ejerciendo nuestros derechos de instalación física y solamente se hace uso de los derechos de ejecución de las instancias virtuales a las que la edición licenciada de derecho.
- El derecho de ejecución de la instancia física no se puede intercambiar por una instancia virtual. Es decir, no puedo usar mis derechos de instalación física para instalar dos instancias virtuales en Standard o cinco en Enterprise sobre un dispositivo que corra un hypervisor independiente de Windows Server.
Derechos de Downgrade. Siempre puede instalarse en las máquinas virtuales una versión o edición inferior a la que hayamos licenciado.
Un servidor físico puede tener asociadas varias licencias de Windows Server, incluso de diferentes versiones. Por ejemplo si en un servidor licenciado con Windows Server Enterprise queremos sobrepasar las 4 instancias incluidas en la licencia, podemos adquirir otra licencia de Enterprise para ese servidor y utilizar los derechos de sus cuatro instancias virtuales para la quinta, sexta, séptima y octava máquinas virtuales.
En un sistema con alta disponibilidad, es posible que un movimiento de una o varias máquinas virtuales entre servidores nos deje en un estado irregular desde el punto de vista de licenciamiento.
Las derechos de uso se aplican únicamente a instancias en ejecución. Esto es obvio para la instalación física pero no así para las instancias virtuales. Una máquina virtual que no esté en ejecución no computa, lo cual aplica al gran número de máquinas virtuales paradas que pueden permanecer pre-configuradas en una librería. Solo computan a efectos de licencias en cuanto se pongan en marcha sobre un cierto servidor físico.

Después de todo esto, la duda suele ser qué edición nos conviene más, si la edición Enterprise, o olvidarnos del licenciamiento y adquirir Datacenter. La clave es, por supuesto, el número de procesadores de los servidores físicos que vamos a utilizar como hosts de virtualización, el ratio de servidores virtuales por servidor físico, y también la situación de partida. Si partimos de una situación en la que vamos a empezar a crecer en servicios virtualizados, si vamos a consolidar servidores físicos con Windows Server, o incluso si no vamos a virtualizar Windows Server.

Escenarios de licenciamiento

Nuevos entornos. La siguiente calculadora nos ayuda a hacer las cuentas para salir de dudas. Lo que no incluye lógicamente son nuestros planes de crecimiento. Así es que ante la duda, o unos pocos euros de diferencia, lo preferible es usar Datacenter y olvidarse de las instancias que queramos echarle encima al host. Para hacernos una idea:
- En equipos con 2 procesadores físicos, nos sale mas barato Datacenter a partir de 8 instancias virtuales de Windows Server. Para menos, asignaremos una o dos licencias de Enterprise al servidor físico.
- En equipos con 4 procesadores físicos, nos sale mas barato Datacenter a partir de 16 instancias virtuales de Windows Server. Para menos, asignaremos entre una o cuatro licencias de Enterprise al servidor físico.

Consolidaciones: Lo normal en una organización que vaya a abordar un proyecto de consolidación mediante virtualización de servidores es que parta de una base de un cierto número de servidores con Standard, una menor cantidad de servidores con Enterprise (en función de escalabilidad o roles no incluidos en Standard como por ejemplo el cluster o las entidades certificadores) y pocos o ningún servidor con Datacenter. Si consolidamos, por ejemplo, 12 servidores departamentales con Standard en 12 VMs sobre un host hay que tener en cuenta que, según lo explicado anteriormente, las 12 licencias Standard pasan a estar asociadas a dicho host, no al cada una de las VMs. Lo que se puede hacer en estos casos es actualizar alguna de las licencias Standard a Enterprise o Datacenter, asociarlas al nuevo host y prescindir de las licencias que ya no necesitamos. Esto además posiblemente nos permita aumentar sin coste alguno las instancias virtuales de Windows Server sobre el servidor licenciado. Es importante tener en cuenta que este ejercicio depende mucho del tipo de licencias que se hayan adquirido en función de la modalidad de contrato que se tenga establecido con Microsoft. Dependiendo de ello, este modelo de licenciamiento puede suponer una inversión o incluso en ocasiones un ahorro de costes.

En este tipo de ejercicios de consolidación se suele uno encontrar ante un problema adicional. ¿Que sucede con las versiones OEM?. ¿Es legal hacer un P2V de una versión OEM de Windows Server?. El razonamiento es sencillo. Las versiones OEM “nacen y mueren” con el servidor físico con el que las adquirimos, ya que no pueden ser traspasadas a otro ni siquiera del mismo fabricante. Dado que si lo virtualizamos la licencia pasará a estar asociada al servidor físico que aloje la VM resultante, estaremos violando el acuerdo de licencia. Pero por otro lado es posible que en el servidor destino, licenciado con Enterprise o Datacenter, tengamos derecho a correr nuevas instancias de Windows Server. Estrictamente hablando deberíamos reinstalar esa VM con una versión de Windows Server para usar diferente clave y podríamos tener problemas con los sistemas de activación, pero ahí queda la cosa.

Hyper-V como role de Windows Server vs. Microsoft Hyper-V Server 2008 R2

De todo lo anterior se extrae un conclusión importante. A la hora de virtualizar Windows Server, Microsoft gana exactamente lo mismo virtualices con Hyper-V o con cualquier otra solución del mercado, ya que precios y licenciamiento son independientes del hypervisor elegido. Al incluir un hypervisor como un role dentro de Windows Server 2008 y Windows Server 2008 R2, Microsoft permite que virtualizar o no sea una decisión en manos exclusivamente del cliente, y que además dicha decisión no suponga una inversión adicional en software, al estar incluida dentro del sistema operativo.

Adicionalmente, y siguiendo esta misma línea, Microsoft pone gratuitamente a disposición de todo el mundo Microsoft Hyper-V Server 2008 R2, que incluye todo lo necesario para montar un host de virtualización, con toda la funcionalidad de Hyper-V R2, incluyendo HA, Live Migration, CSVs y el mismo soporte de hardware que un Windows Server 2008 R2 Enterprise. Sin embargo, al tratarse se una descarga gratuita, no otorga ninguna clase de derecho adicional desde el punto de vista de licenciamiento, por lo que todo lo que corra por encima debe licenciarse acorde. Así es que desde un punto de vista exclusivamente de licencias:

Usaremos el role de Hyper-V de una edición Enterprise/Datacenter para virtualizar Windows Server
Usaremos Microsoft Hyper-V Server 2008 R2 para virtualizar cualquier cosa que no se beneficie de este modelo de licenciamiento. En particular Windows Client o distribuciones comerciales de Linux

Sin embargo desde un punto de vista técnico, operativo y de arquitectura, la nube interna debe ir licenciada con Windows Server 2008 Datacenter. En este tipo de entornos el ejercicio consiste simplemente en contar procesadores, licenciarlos, y disfrutar no solo de la virtualización sino de todas las funcionalidades incluidas en el sistema operativo Windows Server

¿Tiene sentido este modelo?. ¿Es realmente más sencillo de lo que parece?. Yo creo que si. Parece que la tendencia a futuro en el datacenter es pagar en base al consumo de recursos, bien los alberguemos dentro de la organización, bien sea un tercero el que nos los preste. Al llevarlo a una simple cuenta de CPUs, este modelo de licenciamiento es definitivamente mucho más compatible con este esquema que el tradicional pago por instalación del sistema operativo.

Saludos

David Cervigón

Consideración importante para clusteres de Windows Server 2008

DavidCervigon — Thu, 12 Nov 2009 09:44:37 GMT

Hola

Se están dando algunos casos de clústeres de Windows Server 2008 en los que los procesos RSH (Resource Monitor Host) se caen o entran en estados de “deadlock”, lo que en los casos más graves puede acabar produciendo fallos en los recursos existentes en cada uno de los grupos. En otras circunstancias los procesos se reinician y el problema puede llegar a pasar desapercibido.

En el par de casos que me ha tocado vivir, los afectados principales han sido los recursos de disco y el propio nombre del cluster. Esto produce la caída de cualquier cosa que dependa de esos discos, con el agravante de que al no estar disponible el network name el uso de la consola de gestión se hace complicada, sobre todo en remoto. Y a mayor número de nodos, mayor probabilidad de encontrarnos el problema, y mayor complicación a la hora de resolverlo.

Una vez experimentados estos síntomas, cuando nos ponemos a rascar, nos encontramos este tipo de información en el visor de sucesos y en el log del cluster:

Event ID: 1146 - The cluster resource host subsystem (RHS) stopped unexpectedly. An attempt will be made to restart it. This is usually due to a problem in a resource DLL. Please determine which resource DLL is causing the issue and report the problem to the resource vendor
Cluster.log: Múltiples ocurrencias de ERROR_RESOURCE_CALL_TIMED_OUT(5910)

En los casos en los que el sistema es capaz de recuperarse solo, hay otra manera de detectar el problema, también bastante sutil. Cuando falla el monitor de un recurso, el sistema lo marca para que se ejecute en un proceso diferente, lo que dispara el numero de procesos RSH.exe que podemos ver en el task manager. Si ejecutamos este comando, podemos ver en que recursos tenemos esa casilla marcada (SeparateMonitor = 0x1), y si no lo hemos hecho a propósito puede que haya estada afectada por el problema:

cluster res /prop |findstr SeparateMonitor

La solución

Paradójicamente, la solución al problema está oculta detrás de un paquete de recomendaciones que se viene aplicando a problemas de lentitud de red en Windows Vista y en Windows Server 2008, curiosamente debido a las optimizaciones de red incluidas en estos sistemas operativos (TCP Offload, Receive-side scaling (RSS), TCP Window Scaling Auto Tunning, etc.).

Así es que para prevenir/resolver este problema hay que seguir estos pasos en todos los nodos del cluster

Aplicar el fix mencionado en http://support.microsoft.com/default.aspx?scid=kb;EN-US;967224, para asegurarnos de que los cambios que hagamos en el paso siguiente tengan el resultado esperado.
Ejecutar:

Netsh int tcp set global RSS=Disabled
Netsh int tcp set global chimney=Disabled
Netsh int tcp set global autotuninglevel=Disabled
Netsh int tcp set global congestionprovider=None
Netsh int tcp set global ecncapability=Disabled
Netsh int ip set global taskoffload=disabled
Netsh int tcp set global timestamps=Disabled

Adicionalmente, y dado que no vamos a usar esas opciones a nivel de sistema operativo, pueden deshabilitarse también a nivel de opciones avanzadas del driver de la tarjeta de red:

Una vez aplicados los cambios en todos los nodos, los reiniciamos ordenadamente para que estos apliquen, y comprobamos que todos los servicios que corran encima lo estén haciendo correctamente. Es posible que queramos volver a poner los valores “SeparateMonitor” a cero, como era el defecto. Lo podemos hacer con el comando cluster.exe, o bien por la interfaz gráfica (última casilla de la imagen , marcada es 1 y desmarcada es 0):

Espero que esto os pueda ahorrar algún disgusto, acompañado de unas cuantas horas de agobio en clústeres que estén corriendo algún tipo de servicio crítico en vuestra organización.

AGRADECIMIENTOS ESPECIALES:

A un par de clientes, y en especial a toda su gente que se ha estado pegando con el problema con paciencia y dedicación.
A mis compañeros de soporte, en especial a Elena, Ángel, Rafa, Alberto y sobre todo a Haneet Kumar, que es quien se ha estado pegando con estos casos a nivel mundial y ha sido capaz de ligar síntomas con causas y soluciones.

Saludos

David Cervigón

Disponible Exchange 2010 para subscriptores a TechNet / MSDN

DavidCervigon — Mon, 09 Nov 2009 19:11:42 GMT

Hola

En el TechEd de Berlín se ha anunciado la disponibilidad general de Exchange 2010, y ya está disponible para descarga para los subscriptores a TechNet o MSDN.

La versión de evaluación esta igualmente disponible, tanto el .iso como en forma de VHD ya configurado, aquí:

http://www.microsoft.com/exchange/2010/en/us/try-it.aspx

Tengo pendiente instalarlo en el laboratorio e intentarlo conectar con mi suscripción a BPOS, con la ayuda de mi compañero Oscar Maqueda. En éste post de su blog tenéis más información acerca de precios y versiones de evaluación.

Ya iremos contando si el tiempo lo permite.

Saludos

David Cervigón

Security Compliance Management Toolkit

DavidCervigon — Sun, 01 Nov 2009 19:31:05 GMT

Hola

Se ha actualizado el Security Compliance Management Toolkit que ya se encuentra disponible junto con el resto de “Solution Accelerators”.

En el se incluyen las guías de seguridad de los recién llegados Windows 7 e Internet Explorer 8, que se suman a los ya existentes acerca de Windows XP, Windows Server 2003, Windows Server 2008 y Office 2007.

Para cada uno de estos sistemas se adjuntan una serie de plantillas de seguridad, que se dividen en dos escenarios. Los clientes (o servidores) empresariales y entornos que denominan Specialized Security, Limited Functionality (SSLF), donde se prima más la seguridad que la funcionalidad. Nuestro trabajo consistirá en partir de la que consideremos más adecuada e implementar las baterías de pruebas necesarias para garantizar que no rompemos con ello alguna funcionalidad, y de ser así, estar en mejor situación para valorar nuestros riesgos otras posibles contramedidas para mitigarlos.

También hay dos herramientas para hacer llegar esta configuración a los clientes/servidores elegidos. La primera es el GPOAccelerator, para hacerlo mediante políticas de grupo, y la otra son los DCM Configuration Packs de System Center Configuration Manager.

La guía general explica la filosofía del proceso, basada en decidir cuales son las políticas de seguridad que realmente necesitamos para nuestra organización e implementar las herramientas de monitorización y configuración necesarias para que se mantengan de esa manera. Sin embargo, además de para llevar a cabo este ejercicio, toda esta información constituye un buen repositorio de información acerca de la seguridad de nuestros sistemas operativos y de los rincones donde se configura cada cosa.

Espero que os sea útil.

David Cervigón

Scripts a porrillo para configurar y gestionar los Remote Desktop Services y VDI

DavidCervigon — Thu, 29 Oct 2009 17:26:17 GMT

Hola

En el script center correspondiente de TechNet hay un montón de scripts para automatizar la construcción de escenarios de Virtualización del Escritorio basados en Remote Desktop Services y VDI.

Remote Desktop Services Scripts

Esto complementa estupendamente todo lo que conté en su día aquí, y que tengo que continuar complementando con más escenarios. Una vez lo sabes hacer a mano, lo suyo es automatizar.

Saludos

David Cervigón

Métodos para actualizar un cluster de Hyper-V a Hyper-V R2

DavidCervigon — Thu, 29 Oct 2009 16:31:22 GMT

Hola

El otro día cuando publicamos los enlaces con la información acerca de migraciones a R2 se me olvidó mencionar este punto. Que hacer si se tiene un cluster de Hyper-V (Windows Server 2008) y lo queremos actualizar a Hyper-V R2 para tener CSVs y Live Migration (Windows Server 2008 R2).

En este artículo se plantean tres métodos para llevar a cabo la migración a gusto del consumidor.

How to upgrade Windows Server 2008 systems that have the Hyper-V role installed to Windows Server 2008 R2

Personalmente, en todos los clústeres que he migrado he utilizado el primer método. Se trata de asegurarse de que las VMs no tienen ni estados salvados ni snapshots, y que están paradas antes de iniciar la actualización de la partición padre. Cuando los nodos se han terminado de migrar, hay que actualizar los componentes de integración. Si necesitamos mantener snapshots y/o estados guardados, los pasos a seguir están detallados en el KB.

La migración de las VMs de sus LUNs individuales al CSV, si así lo deseamos, puede hacerse por un proceso manual de exportación importación, o mediante la funcionalidad “Quick Storage Migration” de Virtual Machine Manager R2. Generalmente lo más rápido es aprovisionar una nueva LUN grande en la SAN, convertirla en CSV y liberar el espacio de las LUNs individuales una vez realizada la migración de la VM, quitando el disco correspondiente del cluster, “despresentándolo” desde la cabina y eliminando la LUN.

Saludos

David Cervigón

Disponible el cliente RDP 7.0 para Windows XP SP3 y Windows Vista

DavidCervigon — Thu, 29 Oct 2009 13:11:36 GMT

Hola

Esta es una buena noticia para todos los interesados en acceder a escenarios de Virtualización del Escritorio basados en Remote Desktop Services y/o VDI, desde equipos basados en estos sistemas operativos. Esto incluye a los Thin Clients basados en Windows XP (bajo soporte específico del fabricante).

KB969084: Description of the Remote Desktop Connection 7.0 client update for Remote Desktop Services (RDS) for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

Las mejoras que incorpora RDP 7.0 están detalladas en el artículo. En el blog del grupo de producto advierten de una regresión del bug corregido en KB968358, por lo que si se está afectado por este problema mi consejo es esperar a que se resuelva.

Aquí lo veis instalado y funcionando en una VM que simula ser un thin client

Saludos

David Cervigón

Windows Virtual PC y Windows XP Mode listos para descarga en la Web

DavidCervigon — Thu, 22 Oct 2009 08:40:06 GMT

Hola

Si hace unos días ya contamos que lo estaba para los subscriptores a TechNet y MSDN, hoy se puede descargar gratuitamente desde la Web de Microsoft, a la vez que en las tiendas ya se puede comprar Windows 7 en caja o preinstalado.

http://www.microsoft.com/windows/virtual-pc/download.aspx

Saludos

David Cervigón

Libro electrónico gratuito sobre Windows Server 2008 R2

DavidCervigon — Wed, 21 Oct 2009 22:45:00 GMT

Hola

Un e-book de más de 150 páginas sobre las novedades de Windows Server 2008 R2

Free e-book offer that features Windows Server 2008 R2 (XPS, 28MB)
Free e-book offer that features Windows Server 2008 R2 (PDF, 11MB)

Claro que como de costumbre, todo lo que uno pueda querer saber de 2008 R2 lo encontrará aquí:

http://technet.microsoft.com/en-us/windowsserver/2008/default.aspx

Saludos

David Cervigón

Hyper-V Machine Recovery Tool

DavidCervigon — Wed, 21 Oct 2009 22:17:58 GMT

Hola

Hace ya algunos meses contamos cómo importar manualmente máquinas virtuales perdidas o que no se hubieran exportado previamente con la consola de Hyper-V.

Cómo registrar a mano Máquinas Virtuales en Hyper-V

Desde entonces lo he utilizado en algunas ocasiones cómo método de emergencia para llamar al orden y poner firmes máquinas virtuales rebeldes que se empeñan en ocultarse a los servicios de gestión de Hyper-V. Sin embargo se ve que hay quien ha refinado mi cutre-script creando una herramienta un poco más sencilla y cómoda de utilizar:

Hyper-V Machine Recovery Tool

Como se puede observar, no tiene mucho misterio. Le das el path de la VM perdida y se encarga de generar los enlaces simbólicos en la carpeta que usa el servicio VMMS:

Espero que os sea útil

Saludos

David Cervigón

Cómo cargarse unos años-persona de trabajo en décimas de segundo

DavidCervigon — Wed, 21 Oct 2009 20:54:53 GMT

Hola

Hace unos días me llegó un testimonio de uno de vosotros, que supongo prefiere permanecer en el anonimato y que no tiene desperdicio. Al margen de demostrar una templanza y recursos envidiables para resolver finalmente la situación de forma satisfactoria, me viene al pelo para recordar tres viejas buenas prácticas que deberían ser elevadas a la categoría de dogma:

1.- NO uses Snapshots en producción. Una Snapshot NO es un método apropiado de backup

2.- NO uses discos de crecimiento dinámico ni diferenciales para cosas importantes.

3.- NO desprecies el engorroso trabajo de hacer backups. NUNCA realices operaciones de mantenimiento en una infraestructura en producción sin asegurarte de que TODO lo que importa tiene una copia de seguridad UTILIZABLE.

Os recomiendo su lectura, que además transmite muy bien la tensión del momento:

David,

Ayer me pasó algo que tengo que contarte. No sé si tendrás tiempo con tanto tour, pero para cuando tengas un rato...

El caso es que quería actualizar nuestro servidor de Hyper-V y pasarlo de WS 2008 a R2. En él reside una granja de servidores para un proyecto (8 máquinas) más otras tres de infraestructura interna (el CSS de los ISA, TFS para el código de los desarrolladores y el SQL 2008 donde reside este código). Además quería aprovechar para aplicar el SP1 al SQL 2008. Total, que planeo todo el proceso y echo a tó qusqui de la oficina a las seis. Empiezo a apagar máquinas y me asalta una duda: ¿y si me cargo la granja de servidores con el upgrade? Pues nada, pincho un disco USB y exporto ahí todas las máquinas.

En estas que me doy cuenta que al SQL le quedan sólo 1,5 GB libres en disco y aprovecho, mientras se exportan las máquinas, para hacerle un expand. Hyper-V manager, edit disk, lo selecciono, veo que es dinàmico (¿qué raro, yo nunca uso discos dinámicos en producción...?), lo paso de 16 a 20 GB y justo cuando está hecho... HOSTIA, SI TIENE UN SNAPSHOT!!! Pruebo a arrancar la máquina y... NO ARRANCA!!! Sudor frío, improperios varios... pánico. ME HE CARGADO EL TRABAJO DE UN EQUIPO DE UNAS 10 PERSONAS ENTRE 6 Y 12 MESES! Sobra decir que no tenía copias de seguridad (esto tiene disculpa, pero es muy larga de explicar y no viene al caso), excepto la copia local del código que pueda haber en las máquinas de la granja. Pero... ¿y si esa copia local no es buena? ¿Y si no se puede recuperar? Tengo que arreglar esto antes de mañana a las 08:00.

Después de un momento de duda, recordé que los AVHD de los snapshots no son más que discos diferenciales con la extensión cambiada. Lo que debía estar pasando era que el AVHD sabía que el disco padre que veía era distinto del que tenía que ver y, claro, no podía arrancar. ¿Pero qué era lo que le hacía saber que no era “su” disco? ¿La fecha? ¿El tamaño? ¿Alguna firma o ID?

Me bajé las especificaciones del formato VHD (gloriosos estándares), creé algunos VHD de prueba con los mismos tamaños y, con la ayuda de algunos editores hexadecimales, pude comprobar que cambiaban muy pocos bytes de la cabecera (más algunos en el interior, pero invocaría a los dioses para que no fueran importantes, que fueran de relleno). Lo que cambiaba era sólo el tamaño actual del disco (00 00 00 04 00 00 00 00 para 16 GB, 00 00 00 05 00 00 00 00 para 20 GB) mientras que el tamaño original permanecía intacto, la geometría del disco era siempre la misma para el mismo tamaño de disco y luego habría que calcular el checksum (grandiosa calculadora en modo programador de WS 2008). Logro editar todo esto, lo copio al final del fichero (la cabecera de los VHD se repite al final) y guardo copia de todo por si tengo que volver a empezar. Más tarde caí en la cuenta que la cabecera debía ser muy parecida entre el VHD padre y el AVHD (cambiaría sólo el tipo de disco, dinámico en el primero y diferencial en el segundo), así que aproveché para comparar y... sí, estaba en lo correcto, coincidían.

Moment of truth. Le doy al botón de arrancar la máquina... y la muy bonita va y lo hace!!! Lágrimas, confort... la autoestima vuelve a sus niveles de siempre.

Luego aproveché para eliminar el snapshot del SQL y del TFS, pasar los discos a tamaño fijo (si ése hubiera sido el caso no habría tenido el problema, puesto que la expansión de uno físico se hace en otro disco, no en el mismo como es el caso de los dinámicos), aplicar SP1 y updates, actualizar BIOS, firmwares y drivers del host... Lo que no pude hacer fue el upgrade a la R2 del host, porque te avisa que hay una incompatibilidad con los saved state entre las versiones 1 y 2 de Hyper-V, cosa que provoca incompatibilidades entre snapshots online y podría volver a perder el trabajo, esta vez por perder las máquinas. Aunque hubieran sido recuperables (tenía los backups), preferí no sudar más coger el coche e irme para casa.

Y todo este rollo te lo cuento por si crees útil usarlo en tu blog, porque si alguien más se encuentra en esta situación (a) sepa que no ha lugar decir “esto sólo me puede pasar a mí, mira que soy burro” y (b) tenga una solución a mano.

En fin, suerte con el tour y, de paso, gracias por el blog y por esos posts de cómo montar escenarios para probar tecnologías, que son algo muy difícil de encontrar.

Saludos.

Saludos

David Cervigón

Migraciones a Windows Server 2008 R2

DavidCervigon — Tue, 13 Oct 2009 09:27:15 GMT

Hola

Una duda frecuente es cómo migrar a Windows Server 2008 R2 servidores con versiones anteriores, ya que esta nueva versión existe única y exclusivamente para x64.

En el primer enlace se explican las vías soportadas de actualización, entra las que no se encuentra, como era de esperar, la de servidores x86 a x64 que tienen que ser migrados usando estrategias específicas, que son las que se explican en el segundo enlace.

Espero que os resulten de utilidad

Saludos

David Cervigón