Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Objetivo y consideraciones generales

Hola

Inicio una serie de posts dedicados al montaje de plataformas de virtualización basadas en Hyper-V y gestionadas con System Center que puede servir de base para el montaje de entornos de laboratorio, centros de demostraciones, pruebas de concepto y pilotos en los que probar en conjunto todas las tecnologías de virtualización que ofrece Microsoft. Posteriormente pueden complementarse con multitud de productos de otros fabricantes que aporten nuevas funcionalidades y ventajas sobre todo lo expuesto aquí.

Aunque la base de la que partimos es nuestro propio laboratorio y algunas experiencias de realizar este tipo de pilotos sobre el terreno, esperamos poder ofrecer diferentes alternativas para que todo lo expuesto sea lo más extrapolable posible otras situaciones y en particular, para montar las pruebas de concepto que planteamos en este post:

• Pruebas de Concepto de Virtualización de Servidores, Escritorios y Aplicaciones

Los temas que abordaremos en las próximas entregas serán los siguientes:

• Requerimientos: El Directorio Activo
• Requerimientos: Red 
• Requerimientos: Almacenamiento
• Instalación de los hosts de Hyper-V y el cluster
• Instalación y configuración de Virtual Machine Manager
• Instalación y Configuración de System Center Operations Manager
• Recuperación ante desastres

El objetivo es montar algo similar a esto:

En esta serie de posts nos centraremos en el montaje y configuración de los hosts de virtualización y en System Center, ya que toda la parte de virtualización de escritorios ya la documentamos aquí:

• Montando un escenario de Virtualización del Escritorio: El objetivo
• Montando un escenario de Virtualización del Escritorio: El Servidor de App-V
• Montando un escenario de Virtualización del Escritorio: El Cliente de App-V
• Montando un escenario de Virtualización del Escritorio: Virtualizando una aplicación con el Secuenciador de App-V
• Montando un escenario de Virtualización del Escritorio: El papel de los Remote Desktop Services
• Montando un escenario de Virtualización del Escritorio: El Bróker de conexiones de Windows Server 2008 R2
• Montando un escenario de Virtualización del Escritorio: Requisitos de las Máquinas Virtuales para VDI
• Montando un escenario de Virtualización del Escritorio: Granjas de Remote Desktop Session Hosts

La arquitectura que se muestra en el diagrama anterior no es desde luego la única que se puede utilizar, y viene dada por una serie de consideraciones generales que tuvimos en cuanta en base a la situación que teníamos cuando nos pusimos a montar el entorno, y que luego han podido ir variando en el tiempo. Muchos de los productos pueden instalarse sobre el misma máquina virtual, reduciendo por tanto el número de ellas a cambio de aumentar sus requerimientos de memoria y CPU. Pero uno de los requisitos que nos impusimos cuando empezamos a montar todo esto es que los diferentes componentes deben mantenerse entre si lo más aislados posible, y que pudieran ser extraídos, transportados y reimplantados en otro entorno hardware diferente de la manera más transparente posible. Lo primero es importante a la hora de probar nuevas versiones de productos y aislar fallos entre diferentes componentes. Lo segundo es más discutible, porque “transplantar” el entorno no es algo que se haga todos los días, lleva también su tiempo y supone también llevarse las claves de los diferentes productos a otro sitio. Nótese que en una arquitectura real destinada a producción, lo anterior puede ser o no de utilidad, pero hay otras muchas cosas que considerar.

Las principales piezas afectadas por el requerimiento anterior son el Directorio Activo y SQL. La “transportabilidad” sugiere un único DC virtual, pero esto se acaba convirtiendo en un gran único punto de fallo. Lo trataremos en detalle en el próximo post, pero mi preferencia personal es tener un DC físico y otro virtual. Por otro lado, muchos de los productos que montaremos requerirán de una o varias bases de datos para funcionar. Ahorraríamos espacio y capacidad de proceso montando un único servidor de SQL Standard o Enterprise para SCVMM, SCOM, SCDPM, APP-V, pero en este caso hemos preferido que cada máquina virtual albergue su producto con su instancia de SQL (Express, salvo para SCOM que requiere un Standard o un Enterprise).

El número de servidores y sus características, así como la existencia o no de almacenamiento compartido son dos factores decisivos a tener en cuenta. Sin almacenamiento compartido no podremos montar ni HA ni Live Migration. Y el número de servidores y sus características nos permitirán montar más o menos cosas, y ser más o menos flexibles a la hora de hacerlo.

En este caso ponemos cuatro servidores no porque sean necesarios, sino porque eso es lo que tenemos :-). En este post y en este otro nos apañábamos con portátiles. Contamos además con almacenamiento compartido, que nos permite servir almacenamiento tanto a hosts como directamente a las máquinas virtuales (en verde en el dibujo). Como mínimo es recomendable trabajar con dos servidores y acceso a almacenamiento compartido (FC y/o iSCSI)

Nosotros por nuestra parte hemos decidido utilizar los cuatro servidores con Hyper-V de esta manera:

• Srv1: Alberga los servidores virtuales de infraestructura: El Domain Controller y productos de System Center
• Srv2: Para experimentos: En el montamos dominios aparte para usos específicos, máquinas virtuales de usar y tirar, laboratorios virtuales
• Nodo1 y Nodo2 forman un cluster para montar máquinas virtuales en alta disponibilidad con Live Migration. Aquí corren todos los elementos del entorno de virtualización del escritorio (Remote Desktop Services, App-V, máquinas para VDI)
• No sale en la foto: Un servidor con Hyper-Server 2008 R2 que corre un par de VMs con SUSE y RedHat

También podríamos haber optado, sin afectar a la funcionalidad, por:

• Montar una nube “interna” con un cluster de 4 nodos y haber virtualizado todo encima (el cambio a este modelo no llevaría mas de 5 minutos). Estas sería obligatoriamente la única manera de trabajar si solo contamos con dos servidores físicos y queremos implementar HA y Live Migration.
• Dedicar solo un servidor para gestión y dejar los otros tres como miembros de un mismo cluster.
• Violar por completo las recomendaciones y buenas prácticas que se recomiendan para entornos en producción instalando algunos productos y/o los controladores de dominio en las particiones padre. Por ejemplo, se puede reutilizar el cluster para montar un SQL que albergue todas las bases de datos, además de para las máquinas virtuales. Las particiones padre son a todos los efectos una máquina virtual, y como tales se pueden reaprovechar, si bien es algo completamente desaconsejado en producción.
• Violar el concepto de nube e instalar algunas cosas a la antigua usanza, dedicando un servidor físico a ciertas tareas. Este es un buen modelo si tenemos la posibilidad de reutilizar PCs o servidores que no sean capaces de ofrecer funcionalidades de hosts de virtualización, pero que permiten todavía darles algún uso decente (DC, DNS DHCP, Consolas de administración, etc.) además de conectar cómodamente un monitor un ratón y un teclado.

Recordaros por último un consejo universal. Hagas lo que hagas intenta hacerlo simple. Huye de complicaciones innecesarias (principio KISS: Keep It Short and Simple, Keep It Simple and Stupid, o Keep It Simple, Stupid)

Saludos

David Cervigón