Está en la página 1de 29

1

Coniris13 Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales

David Cervigon 25 Feb 2010 8:20 AM Comments 0 Hola Inicio una serie de posts dedicados al montaje de plataformas de virtualizacin 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 tecnologas de virtualizacin 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 ms extrapolable posible otras situaciones y en particular, para montar las pruebas de concepto que planteamos en este post:

Pruebas de Concepto de Virtualizacin de Servidores, Escritorios y Aplicaciones Requerimientos: El Directorio Activo Requerimientos: Red Requerimientos: Almacenamiento Instalacin de los hosts de Hyper-V y el cluster Instalacin y configuracin de Virtual Machine Manager Instalacin y Configuracin de System Center Operations Manager Recuperacin ante desastres

Los temas que abordaremos en las prximas entregas sern los siguientes:

El objetivo es montar algo similar a esto:

En esta serie de posts nos centraremos en el montaje y configuracin de los hosts de virtualizacin y en System Center, ya que toda la parte de virtualizacin de escritorios ya la documentamos aqu:

Montando un escenario de Virtualizacin del Escritorio: El objetivo Montando un escenario de Virtualizacin del Escritorio: El Servidor de App-V Montando un escenario de Virtualizacin del Escritorio: El Cliente de App-V Montando un escenario de Virtualizacin del Escritorio: Virtualizando una aplicacin con el Secuenciador de App-V Montando un escenario de Virtualizacin del Escritorio: El papel de los Remote Desktop Services Montando un escenario de Virtualizacin del Escritorio: El Brker de conexiones de Windows Server 2008 R2 Montando un escenario de Virtualizacin del Escritorio: Requisitos de las Mquinas Virtuales para VDI Montando un escenario de Virtualizacin 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 situacin que tenamos 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 mquina virtual, reduciendo por tanto el nmero 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 ms aislados posible, y que pudieran ser extrados, transportados y reimplantados en otro entorno hardware diferente de la manera ms transparente posible. Lo primero es importante a la hora de probar nuevas versiones de productos y aislar fallos entre diferentes componentes. Lo segundo es ms discutible, porque transplantar el entorno no es algo que se haga todos los das, lleva tambin su tiempo y supone tambin llevarse las claves de los diferentes productos a otro sitio. Ntese que en una arquitectura real destinada a produccin, 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 prximo post, pero mi preferencia personal es tener un DC fsico y otro virtual. Por otro lado, muchos de los productos que montaremos requerirn de una o varias bases de datos para funcionar. Ahorraramos espacio y capacidad de proceso montando un nico servidor de SQL Standard o Enterprise para SCVMM, SCOM, SCDPM,

3
APP-V, pero en este caso hemos preferido que cada mquina virtual albergue su producto con su instancia de SQL (Express, salvo para SCOM que requiere un Standard o un Enterprise). El nmero de servidores y sus caractersticas, 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 nmero de servidores y sus caractersticas nos permitirn montar ms o menos cosas, y ser ms 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 apabamos con porttiles. Contamos adems con almacenamiento compartido, que nos permite servir almacenamiento tanto a hosts como directamente a las mquinas virtuales (en verde en el dibujo). Como mnimo 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 especficos, mquinas virtuales de usar y tirar, laboratorios virtuales Nodo1 y Nodo2 forman un cluster para montar mquinas virtuales en alta disponibilidad con Live Migration. Aqu corren todos los elementos del entorno de virtualizacin del escritorio (Remote Desktop Services, App-V, mquinas para VDI) No sale en la foto: Un servidor con Hyper-Server 2008 R2 que corre un par de VMs con SUSE y RedHat Montar una nube interna con un cluster de 4 nodos y haber virtualizado todo encima (el cambio a este modelo no llevara mas de 5 minutos). Estas sera obligatoriamente la nica manera de trabajar si solo contamos con dos servidores fsicos y queremos implementar HA y Live Migration. Dedicar solo un servidor para gestin y dejar los otros tres como miembros de un mismo cluster. Violar por completo las recomendaciones y buenas prcticas que se recomiendan para entornos en produccin 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, adems de para las mquinas virtuales. Las particiones padre son a todos los efectos una mquina virtual, y como tales se pueden reaprovechar, si bien es algo completamente desaconsejado en produccin. Violar el concepto de nube e instalar algunas cosas a la antigua usanza, dedicando un servidor fsico 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 virtualizacin, pero que permiten todava darles algn uso decente (DC, DNS DHCP, Consolas de administracin, etc.) adems de conectar cmodamente un monitor un ratn y un teclado.

Tambin podramos haber optado, sin afectar a la funcionalidad, por:

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)

Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualizacin: Requerimientos: El Directorio Activo

David Cervigon 25 Feb 2010 2:42 PM Comments 4 Posts anteriores:

Hola

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales

En este post vamos a intentar dar respuesta a algunas preguntas que surgen de manera frecuente a la hora de considerar los requerimientos del Directorio Activo y el/los controladores de dominio necesarios para abordar este tipo de pruebas:

4
Debo virtualizar controladores de dominio? En un laboratorio/piloto de virtualizacin aislado en su propio dominio, donde coloco el/los DCs? Si voy a a utilizar una Directorio Activo ya existente, que requerimientos son necesarios a nivel de sistema operativo de los Controladores de Dominio, nivel funcional del bosque/dominio y versin del esquema?. Si esto no se puede cambiar, que funcionalidades estn afectadas?. Que otras cosas pueden ayudar (adems de un DNS y un DHCP)?

Antes de continuar, puede que este otro post algo antiguo resulte de inters, aunque est un poco fuera de este mbito:

Arquitecturas para la nube con Hyper-V

Virtualizar controladores de dominio Lo cierto es que no hay mucho ms que contar que no est ya recogido aqu:

Running Domain Controllers in Hyper-V

Planning Considerations for Virtualized Domain Controllers Deployment Considerations for Virtualized Domain Controllers Operational Considerations for Virtualized Domain Controllers Backup and Restore Considerations for Virtualized Domain Controllers Appendix A: Virtualized Domain Controllers and Replication Issues

Donde colocar el/los DCs, si vamos a montar un nuevo Directorio Activo dedicado al entorno de virtualizacin Aqu van varias opciones, con sus pros y sus contras:

1. Un nico DC virtual. Todo lo que montemos depender de el. Si su host cae, el resto de la infraestructura
se resiente, bien hasta que dicho host reinicie, bien mientras la infraestructura de HA haga su trabajo. Como adems es la primera pieza que hay que montar, antes incluso que el cluster, el montaje se complica, sobre todo si tenemos solo dos servidores para montar el entorno. El procedimiento sera el siguiente: Si solo tenemos dos hosts y planeaos montar un cluster (es seguramente el caso ms complicado. Ver la opcin 3 como una alternativa) tenemos que: Instalar y configurar los nodos en grupo de trabajo, pero teniendo en cuenta que formarn un cluster a futuro (lo que implica poner especial atencin a la distribucin e las NICs y direccionamiento IP) Agregar el role de Hyper-V En uno de los nodos, crear la VM que ser DC, o importarla si ya la traemos preparada. Si planeamos configurarla en HA y que se pueda utilizar Live Migration, es interesante crearla directamente en una LUN de la cabina, por ahora solamente presentada a ese nodo. Hacer a las particiones padre miembros del dominio. Crear y configurar el cluster . Decidir si dejamos las cosas estar, o si dotamos a esa VM de alta disponibilidad. Este paso est muy trado por los pelos porque en algn momento tendremos que operar un cluster sin tener el DC disponible. Instalamos y configuramos el host que albergar al DC Virtual Agregamos el role de Hyper-V. Creamos o importamos el DC virtual. Hacemos a ese host miembro del dominio. Montamos el resto de servidores y nos concienciamos de que este ese nico DC constituye un punto nico de fallo.

Si contamos con un tercer host, o si no vamos a montar un cluster:

2. Dos DCs virtuales: Minimizamos los riesgos, aumentamos la disponibilidad, pero seguimos teniendo
complicado el montaje inicial.

3. En el caso de solo tener solamente dos servidores y quererlos montar en cluster, es frecuente recurrir al
truco de que la particin padre de cada nodo del cluster sea un DC (No vale montar solo uno de los nodos como DC es un error ya que se convertira en un punto de fallo que darn al traste con cualquier prueba de HA que se quiera realizar). Para hacer esto tendremos que:

5
Instalar y configurar los nodos en grupo de trabajo, pero teniendo en cuenta que formarn un cluster a futuro (lo que implica poner especial atencin a la distribucin e las NICs y direccionamiento IP) Haremos sucesivamente los DCPromo en ambas particiones padre, teniendo en cuenta las recomendaciones de Windows 2000, Windows Server 2003, and Windows Server 2008 cluster nodes as domain controllers, sobre todo en lo tocante a la configuracin del DNS Crear y configurar el cluster Crear/importar el resto de mquinas virtuales

4. Un DC fsico con uno o varios DCs virtuales adicionales. Esto es lo ms parecido a como debera montarse

en produccin. Puede dedicarse un servidor fsico a DC, DNS y DHCP o incluso un PC en el que aprovecharemos para montar todo tipo de consolas de gestin. Esto permite adems adentrarse con comodidad en el mundo de Hyper-V Server o Server Core para las particiones padre de los Hyper-V restantes donde no gozamos de interfaz grfica, y podremos hacer desde aqu la gestin remota con toda comodidad sobrante para hospedar mquinas virtuales. Pueden montarse luego DCs virtuales en otros hosts. Como se puede observar esto es un hbrido de las opciones anteriores, y una buena opcin para cuando solo se tienen tres servidores potentes.

5. Un DC montado en la particin padre de un servidor con Hyper-V, donde podemos aprovechar la potencia

Como expliqu en el post anterior, la idea inicial cuando empezamos a montar nuestro entorno de demos fue mantener el aislamiento de las diferentes piezas y su portabilidad individual. Por suerte contbamos con ms de dos servidores, con lo que la decisin fue montar un DC virtual sobre un pequeo servidor ajeno al chasis. El DC en ese servidor empez a tener ciertos problemas de rendimiento (memoria y E/S de disco) y lo transportamos a uno de los blades, almacenando su VHD en la cabina. En alguna ocasin hemos tenido que recablear, cambiar la alimentacin, etc. tanto en la cabina como en el chasis y nos hemos encontrado con que, por ejemplo, o te acordabas de las IPs de las cosas o no tenas ni DNS, ni Directorio Activo ni ms ayuda que ping a. Dormiremos mucho ms tranquilos cuando usemos ese (u otro) pequeo servidor como DC adicional, adems de como punto nico de gestin del entorno (en algn sitio hay que enchufar un monitor un teclado y un ratn). Utilizando un Directorio Activo existente Para utilizar un directorio activo ya existente hay que tener en cuenta dos aspectos:

Virtual Machine Manager 2008 R2 necesita que el nivel funcional del dominio sea como mnimo Windows 2003 Nativo El brker de conexiones de Remote Desktop Services utiliza un nuevo atributo de Windows Server 2008 (no R2) para almacenar la mquina virtual personal asignada a un usuario. Como es bien sabido, un nuevo atributo en un objeto de directorio activo supone una ampliacin del esquema. Para ms seas, estamos hablando de msTSProperty01, que se introduce en Windows Server 2008 (sin R2) en SCH37.ldf. Mis antiguos compaeros del equipo de Soporte de Windows me han prohibido expresamente, con buen criterio, contar cualquier tipo de apa para introducir nica y exclusivamente este atributo en el esquema, as es que la nica manera soportada de hacerlo es extendiendo el esquema con adprep. Es falso afirmar que para poder hacer funcionar el Connection Broker necesitas tener todos tus DCs en 2008 R2. Puedes mantener tus DCs en 2003, que la ampliacin del esquema servir para poder introducir novedades de 2008, como por ejemplo los RODCs. La interfaz de configuracin del brker de conexiones se encarga de editar y modificar este atributo, y de leerlo cuando un usuario se conecta. Y desde una consola de Active Directory Users and Computers instalada sobre cualquier R2 o Windows 7 podremos ver la pestaa correspondiente en la cuenta del usuario:

6
En resumen, podremos usar un Directorio Activo basado en Windows Server 2003, con un nivel funcional 2003 nativo, renunciando nicamente a la funcionalidad de Personal Virtual Desktop. Otras recomendaciones relacionadas con el Directorio Activo Hay varias cosas que siempre es bueno tener a mano en estas ocasiones: Las polticas de grupo de han inventado para no tener que ir mquina por mquina configurando las mismas cosas. Utilzalas desde el primer momento. Entre las miles que hay seguro que hay alguna para lo que estas buscando:

Group Policy Documentation Survival Guide Group Policy Settings Reference for Windows and Windows Server

Una CA Enterprise, y polticas de autoenrollment de certificados tanto para usuarios como para equipos a nivel de todo el dominio. Esto facilita la configuracin de todo aquello que hoy en da necesita de una PKI para funcionar. Siempre es bueno tener a mano e instalar las actualizaciones necesarias para que en todas las mquinas del dominio funcionen las Group Policy Preferences (es decir, las Group Policy client-side Extensions). Estas extensiones son particularmente tiles conseguir que grupos de mquinas queden igualmente configurados. Por ejemplo, son una buen forma de desplegar la plantilla y los elementos del men de inicio de herramientas como BGinfo de Sysinternals :-)

Group Policy Preferences Overview http://support.microsoft.com/kb/943729

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Red

David Cervigon 26 Feb 2010 4:32 PM Comments 3 Posts anteriores:


Hola

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualizacin: Requerimientos: El Directorio Activo

Poco vamos a poder contar que no est ya contemplado en la gua que se acaba de publicar aqu:

Hyper-V: Live Migration Network Configuration Guide

Vamos a ver qu uso de la red hace una infraestructura de virtualizacin basada en Hyper-V, cmo se pueden utilizar las tarjetas de red del host en diferentes escenarios y como estos requisitos se hacen ms importantes para el caso de los clsteres en las que se vaya a utilizar Live Migration. En resumen, estas son las cosas que hay que saber: Hyper-V convierte las NICs que se le asignan como un switch virtual. El resto de tarjetas siguen perteneciendo a la particin padre y se utilizan exactamente igual que en el mundo fsico. En el caso de querer utilizar NIC Teaming para agregacin de ancho de banda y/o tolerancia a fallos, podremos hacerlo con el software del fabricante de las tarjetas y bajo sus recomendaciones y soporte. La NIC resultante ser la que convirtamos en switch virtual, que funcionar a todos los efectos igual que en el caso anterior. A cambio de esta tarjeta fsica, se nos ofrece la posibilidad de crear en la particin padre una NIC virtual conectada a ese switch. Sobre esta NIC virtual, que a todos los efectos es igual que las NICs que tendremos en las mquinas virtuales, podemos definir si as lo deseamos, la VLAN ID a la que queremos que pertenezca.

La tarjeta fsica que hemos convertido en switch virtual deber estar conectada a una boca de un switch scio fsico que se habr definido como troncal (recomendado) o que tenga asignadas todas las posibles VLAN IDs que usen, tanto la particin padre, como las mquinas virtuales que tengan NICs conectadas a dicho switch virtual.

En hosts stand-alone podemos trabajar bastante bien con una o dos NICs fsicas, si el uso de red de las mquinas virtuales no va a ser intensivo. Por ejemplo: En un porttil con una sola NIC, la enlazaremos a Hyper-V y marcaremos la casilla para que la particin padre tenga una NIC virtual que vea la red corporativa a travs del switch virtual y pueda ser gestionada correctamente En un servidor con dos NICs podemos: Dedicar una NIC a gestin y la otra la convertiremos en switch virtual Convertir ambas NICs en switches virtuales y marcar la casilla solo en uno de ellos para obtener una NIC virtual con la que gestionar la particin padre. De esta manera podemos tener dos switches virtuales con los que distribuir el trfico de las mquinas virtuales, o conectar cada switch virtual a diferentes segmentos de red. Hacer un Team y trabajar como en el caso de tener una sola NIC.

Sin embargo, para los hosts que vayan a ser miembros de un cluster vamos a tener diferente tipo de trfico El de la gestin de la propia particin padre

8
El del heartbeat del cluster El derivado de las Live Migrations El asociado a los Cluster Shared Volumes El que provenga de las mquinas virtuales. Posiblemente, el asociado a las copias de seguridad

En la gua que tenis enlazada al principio del post tenis los pormenores de las diferentes combinaciones. Es evidente que en produccin vamos a necesitar que los hosts estn bien cargaditos de NICs, mxime si encima el almacenamiento es por iSCSI, pero lo cierto es que es factible configurar todo esto con una nica NIC. En estas figuras representamos varias opciones para probar en nuestro entorno de laboratorio, para el caso de que tengamos cuatro NICs y para el caso de tener solo dos. Somos conscientes de que hay ms combinaciones posibles: 4 NICs, 1 vSwitch:

4 NICs, con dos de ellas en Teaming convertidas en vSwitch

9
4 NICs, 2 vSwitches, 1 vNIC para la particin padre:

2 NICs, 1 vSwitch, 1 vNIC para la particin padre

En el caso de nuestro laboratorio, los blades de los que disponemos solo tienen 2 NICs, y adems el almacenamiento compartido es iSCSI como veremos en el siguiente post. No nos queda otro remedio que usar este ltimo modelo, pero adems utilizamos la tarjeta tambin para el trfico dirigido al almacenamiento compartido. Como todo esto es ciertamente un poco lioso, he aqu una lista de pistas y trucos que os pueden venir muy bien para acelerar el proceso de instalacin y configuracin de los hosts y minimizar los quebraderos de cabeza en fases posteriores: 1. Decide previamente el direccionamiento IP que tendrn: Las particiones padre de los hosts Los servidores virtuales La red de Hearbeat/CSV La red dedicada al almacenamiento

10 2. Renombra las NICs segn para lo que se vayan a utilizar ANTES de agregar el role de Hyper-V. Esto es
absolutamente innecesario desde un punto de vista funcional, pero creedme que ayuda. Por ejemplo 3. LAN o Produccion vSwitch1, vSwitch2, etc. para las que vayan convertirse en Switches Virtulaes Interna o HeartBeat CSV para la de los CSVs Live Migration iSCSI para comunicarnos con el almacenamiento

Se consistente con esta ordenacin en todos los hosts. Usa la misma NIC para la misma tarea en todos los hosts. suelen requerir ni puerta de enlace ni DNS, ni cliente para redes Microsoft, ni compartir archivos e impresoras. Recordemos que la red dedicada a CSVs DEBE tener esto ultimo enlazado

4. Asigna la configuracin de red segn el plan marcado. Las redes de almacenamiento y de heartbeat no 5. Durante el pequeo asistente que sale al agregar el role de Hyper-V se nos pregunta que tarjetas

queremos dedicar como switches virtuales. Si no hemos seguido el segundo paso, nos encontramos con algo as. Es mucho mejor que en la columna nombre salga algo un poco ms amigable, no?. En cualquier caso, podemos no marcar ninguna casilla y hacerlo luego desde la consola de configuracin de Hyper-V

6. Por ltimo, y muy importante, utiliza los mismos nombres para switches virtuales en todos los hosts, ya
que cuando una mquina se mueva a otro hosts se guiar por esta etiqueta para conectarse un switch virtual que se llame de la misma manera. Si no lo encuentra, se queda r desconectada. Puedes llamar tambin vSwitch1 al switch virtual en que se ha convertido la NIC que llamamos vSwitch1 en el paso 2, o

11
darle un nombre que de idea de la red fsica a la que est conectado, como en este ejemplo:

7.

Por ltimo, renombra las NICs virtuales que hayan aparecido en la particin padre como consecuencia de haber marcado la casilla citada anteriormente. En este caso, la vNIC1 es una tarjeta virtual conectada al switch virtual Laboratorio, que responde a la NIC fsica que hemos llamado vSwitch1:

12

Como decamos ms arriba, muchos de estos pasos son funcionalmente innecesarios y puede dar la impresin de que estamos complicando innecesariamente el proceso de configuracin de la red. Sin embargo ayudan mucho a familiarizarnos con el funcionamiento del sistema, y facilitarn cambios de configuracin que queramos hacer a posteriori. Y si en algn momento nos las tenemos que ver con sistemas con un gran nmero de NICs destinadas a diferentes tareas, esta metodologa puede resultar de mucha utilidad.

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Almacenamiento

David Cervigon 26 Feb 2010 4:35 PM Comments 0 Posts anteriores:


Hola

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualizacin: Requerimientos: El Directorio Activo Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Red

Sin ningn lugar a dudas, el almacenamiento es una de las piezas clave a la hora de hablar de virtualizacin. El hecho de virtualizar un servidor no implica que la carga de trabajo que corra en el vaya a tener un patrn de uso del almacenamiento diferente al que utilizara en fsico. Y lgicamente, cuanto mayor sea la densidad de mquinas

13
virtuales, mayor ser la superposicin de dichos patrones del host de virtualizacin hacia el sistema de almacenamiento. Hable de este tipo de cosas en este post acerca de los Cluster Shared Volumes:

Consideraciones sobre los Cluster Shared Volumes (CSV)

Para el caso que nos ocupa, si queremos probar las funcionalidades de HA y Live Migration necesitaremos contar con almacenamiento compartido al cual accedern los hosts por Fiber Channel y/o iSCSI NOTA: El uso de sistemas NAS basados en CIFS/NFS, si bien funciona con Hyper-V, no est oficialmente soportado por ahora. Para ms informacin al respecto, este es el post de referencia, de la mano de nuestro compaero Jos Barreto: Failover Clustering for Windows Server 2008 Hyper-V with File Server Storage En el caso de nuestro laboratorio, todo funciona a travs de iSCSI (mucho ms barato que FC) contra dos sistemas de almacenamiento. Uno de ellos est basado en Windows Storage Server 2008, que incluye el Microsoft iSCSI Target, y el otro es una cabina SAN que amablemente nos presta NetApp. Tenemos montados laboratorios similares basados tambin en cabinas Dell Equalogic, y EVAs y MSAs de HP (tengo muchas ganas de probar tambin las Lefthand). Tambin conozco casos de entornos basados en otros Targets iSCSI basados en software, como los de StarWind. El esquema que hemos seguido es el siguiente:

Todos los servidores usan sus discos locales nicamente para la particin padre. En algn caso los hemos montado arrancando directamente de la SAN, en cuyo caso los discos locales se configuran para uso del fichero de paginacin Los servidores stand-alone tienen asociadas una o varias LUNs del almacenamiento compartido, donde se almacenan la mquinas virtuales Los servidores que son miembros del cluster tienen presentadas las LUNs correspondientes al quorum y a los CSVs que utilizaremos para almacenar las mquinas virtuales. Tambin es posible configurar mquinas virtuales clusterizadas que hagan uso exclusivo de sus propias LUNs. Hay mquinas virtuales que tienen necesidades de almacenamiento particulares, y a las que servimos directamente almacenamiento compartido de las cabinas. En nuestro caso lo hacemos mediante el iniciador iSCSI del propio sistema operativo, pero tambin podramos hacerlo por pass-through, que el la nica opcin que tendramos en el caso de usar Fiber Channel. Por ejemplo La VM con SCVMM tiene una LUN para almacenar las mquinas virtuales almacenadas en la biblioteca y las plantillas

14
La VMM con Data Protection Manager tiene una LUN donde se almacenan las copias de seguridad de las mquinas virtuales La VM de MED-V tiene una LUN para albergar las mquinas virtuales que se distribuirn a los clientes (para los que no lo conozcis MED-V es la versin empresarial del XP Mode) La VM con Citrix Provisioning Server tiene una LUN dnde se almacenan los VHDs que constituyen las golden images que usan ciertas mquinas virtuales de los pools para trabajar.

La obsesin de tener todo almacenado en la SAN es sencilla de entender. Rinde estupendamente y si adems tu cabina deduplica, los ahorros de espacio son sencillamente espectaculares. Por otro lado, recordemos que queremos la mxima granularidad y aislamiento entre las piezas. Si alguien se carga algn servidor fsico, o lo cambias por otro de diferentes caractersticas, sus mquinas virtuales no estn en los discos locales. Y si alguien borra inadvertidamente alguna de las mquinas virtuales mencionadas anteriormente, sus datos crticos siguen disponibles en espera de que aprovisionemos un nuevo servidor virtual o restauremos el backup, que ser mucho ms ligero al carecer de un gran volumen de datos. La conexin de los servidores fsicos con el almacenamiento es una de las primeras tareas que hay que abordar en el montaje de estos entornos, y la experiencia dice que suele ser uno de los principales escollos tcnicos. He aqu algunas pistas y trucos que pueden hacer que el proceso sea ms sencillo: Conviene tener bien a mano los drivers recomendados por el fabricante del servidor para las NICs y/o las HBAs. Por lo general existen las versiones del fabricante del servidor, certificadas para su hardware, y las del fabricante de los propios adaptadores. Es preferible comenzar utilizando siempre los primeros. Agrega el framework de Multipath del propio sistema operativo. Esta como funcionalidad en el Server Manager. Si algn elemento del almacenamiento requiere algn elemento adicional especfico lo agregar durante su instalacin Instala a continuacin el Device Specific Module (DSM) de la cabina que vayas a utilizar. Un sntoma claro de que falta este elemento es ver el mismo disco varias veces en el administrador de discos (tenemos varios caminos al almacenamiento y no sabemos como manejar la situacin pese a tener el framework Multipath instalado) Puede ser interesante instalar tambin los Hardware Providers tanto de VDS (Virtual Disk Service) como de VSS (Volume Sahdow Copies)del almacenamiento en particular. Inicializa los discos, ponlos online y formatealos con NTFS antes se intentar utilizarlos :-)

Todas estas operaciones pueden llevarse a cabo antes o despus de haber agregado el role de Hyper-V. Se siga el orden que se siga, si que es interesante haber pensado, antes incluso de instalar los hosts, acerca de qu tipo de almacenamiento vamos a tener a nuestro disposicin y cmo vamos a utilizarlo. Como hemos dicho al principio, es una de las piezas claves a tener en cuanta a la hora de planificar lo que vamos a poder hacer y lo que no.

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Instalacin de los hosts de Hyper-V y el cluster

David Cervigon 7 Mar 2010 4:36 PM Comments 3 Posts anteriores:


Hola

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualizacin: Requerimientos: El Directorio Activo Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Red Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Almacenamiento

Una vez repasado en los post anteriores los requisitos que necesarios a nivel de directorio activo, red y almacenamiento, vamos a pasar a exponer cmo instalar los hosts con Hyper-V, tanto en configuraciones stand-

15
alone como en cluster. Si bien a estas alturas creo que escribir un paso a paso sobre cmo instalar Windows Server 2008 R2 est de ms, vamos a centrarnos en una serie de consejos prcticos que pueden ayudar a que este sea el paso ms sencillo y rpido del montaje de todo el entorno, y que agregar nuevos hosts sea cuestin de pinchar un pendrive e irnos a tomar un caf. Los interesados en el paso a paso detallado pueden consultar:

Hyper-V Getting Started Guide Hyper-V Step-by-Step Guide: Hyper-V and Failover Clustering. Live Migration Step-By-Step Deployment Guide Hyper-V R2 por debajo de una particin padre con Windows Server 2008 R2 Full. Ideal para pruebas, demos y para cuando la particin padre va a dedicarse a otras funciones (no recomendado en produccin en la mayora de los casos) Hyper-V R2 por debajo de una particin padre con Windows Server 2008 R2 Server Core. Menor consumo de recursos y superficie de ataque. La gestin se har en su mayora de forma remota, al carecer de la interfaz grfica de Windows Hyper-V Server 2008 R2: Totalmente gratuito y con el 100% de la funcionalidad relativa al hipervisor, alta disponibilidad y Live Migration. La experiencia de uso es idntica a la de Windows Server 2008 Server Core, solo que en este caso no tenemos ningn tipo de role o funcionalidad que no sea indispensable para funcionar en conjunto con Hyper-V.

Antes de nada, vamos a repasar rpidamente las tres opciones que tenemos para montar Hyper-V en un servidor:

Gran parte de la configuracin posterior puede realizarse tambin de manera centralizada desde Virtual Machine Manager, pero en este caso vamos a realizarla manualmente. Automatizacin de la instalacin de los hosts mediante un pendrive y un fichero autounattend.xml Una vez en nuestro poder los DVDs o imgenes ISO necesarias es el momento de ponerse manos a la obra con la instalacin. Si bien todos los fabricantes de servidores incluyen herramientas para poder montar medios virtuales por la red, mi experiencia es que lleva ms tiempo lograr que la conexin remota funcione bien y que los ficheros se copien por la red que lo que se tarda realmente en instalar y configurar el sistema. Por tanto solemos tener a mano uno o varios pendrives sobre los que hemos volcado todos los ficheros del medio de instalacin, de manera que, si hacemos arrancar de dicho dispositivo al servidor, la instalacin se realiza de manera mucho ms rpida en cuestin de pocos minutos. Estos son los pasos para preparar previamente el pendrive (de 4GB mnimo) en un equipo con Windows Vista/7/2008/2008 R2 1. 2. 3. 4. 5. 6. 7. 8. 9. Diskpart List Disk (identificamos aqu el numero de disco que corresponde al pendrive) Select Disk X (donde X es el nmero contenido en el paso anterior) Clean (ojo, esto es destructivo) Create Partition Primary (crea la particin en el pendrive) Active (activa la particin) Format fs=ntfs (la formatea en NTFS) Assign (presenta el dispositivo al sistema con la primera letra de unidad disponible) Exit

10. A continuacin volcamos sobre el pendrive el contenido del DVD o del ISO de Windows Server 2008 R2 Con esto tendremos ya listo un pendrive arrancable que se comportar exactamente igual que el DVD si hacemos que el servidor arranque de l. Nos pedir la configuracin de idioma, teclado, edicin de Windows Server 2008 R2 a instalar, si full o si core, el disco y la particin y el proceso terminar solicitando que introduzcamos una contrasea compleja para el administrador local. El sistema quedar instalado con un nombre aleatorio, sin ningn tipo de configuracin predefinida y sin funcionalidades ni caractersticas. Hemos quedado en que nos apetece un caf o dedicarnos a tareas un poco ms gratificantes, as es que vamos a automatizar un poco ms el proceso. El proceso de instalacin de los sistemas operativos a partir de Windows Vista buscan al principio de la instalacin un fichero autounattend.xml con las opciones de instalacin desatendida en dos sitios: el propio medio de instalacin y luego en un medio externo que puede ser un dispositivo de almacenamiento USB o un disquete. Aprovechando que en el pendrive que hemos preparado es fcil crear y copiar un fichero, colocaremos el autounattend.xml en su carpeta raz.

16

Esto es lo que vamos a automatizar en el caso de que queramos utilizar el role de HyperV incluido en Windows Server 2008 R2, usando para la particin padre una instalacin bien Full bien Server Core. Puede hacerse algo similar para Hyper-V Server 2008 R2 (descarga gratuita), si bien la instalacin del mismo ya esta bastante automatizada de por s: Gran parte del proceso de instalacin, con excepcin del disco y particin. No porque no se pueda, sino porque en un entorno como el que nos ocupa es posible que queramos tener diferentes instalaciones de diferentes sistemas (p.e. instalaciones Full, Server Core, o Hyper-V Server) en diferentes discos y particiones. Tampoco introduciremos la clave del producto, ya que lo podremos hacer posteriormente en el momento de la activacin si as lo deseamos. Aqu automatizamos: Idioma de instalacin (en los ejemplo se asume que estamos utilizando versiones en ingls, pero que queremos que el teclado, los locales y la zona horaria correspondan al espaol internacional. Edicin de Windows Server 2008 R2: Usaremos dos ejemplos: Datacenter Full y Datacenter Core. Para usar Enterprise o Standard basta con cambiar el nombre de la imagen Nombre de equipo Haremos un Join al dominio usando unas credenciales vlidas (Opcional. Por supuesto no aplica en el caso de que no tengamos un Active Directory y un DHCP configurados y funcionales)

Funcionalidades y Caractersticas que necesitaremos para trabajar, as como alguna configuracin adicional: Hyper-V Failover Cluster MultipathIO Windows Server Backup Cliente Telnet (esto es una mana personal, como herramienta bsica de testeo de conectividad a puertos Telnet servidor puerto) Habilitar el escritorio remoto para administrar remotamente el servidor. Remote Desktop Virtualization Host Agent (para conectar el servidor con el brker VDI de Remote Desktop Services)

NOTA: El proceso de instalacin tiene un reinicio. Si hemos configurado el servidor para que siempre arranque del dispositivo extrable y hemos llegado a automatizar el proceso completamente, la instalacin se llevar a cabo una y otra vez de manera iterativa mientras disfrutamos de nuestro caf. Dependiendo de la BIOS del servidor, es posible seleccionar el dispositivo extrable como medio de arranque ocasional, de modo que la instalacin contine sin problemas en el siguiente reinicio, ya desde el almacenamiento local o de la SAN del servidor. 1.- Fichero autounattend.xml para Windows Server 2008 R2 Datacenter Full. En rojo lo que tenemos que modificar para ajustarlo a cada servidor en particular:
<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <servicing> <package action="configure"> <assemblyIdentity name="Microsoft-Windows-Foundation-Package" version="6.1.7600.16385" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="" /> <selection name="Microsoft-Hyper-V" state="true" /> <selection name="Microsoft-Hyper-V-Management-Clients" state="true" /> <selection name="VmHostAgent" state="true" /> <selection name="MultipathIo" state="true" /> <selection name="TelnetClient" state="true" /> <selection name="WindowsServerBackup" state="true" /> <selection name="WindowsServerBackupCommandlet" state="true" />

17
<selection name="FailoverCluster-AdminPak" state="true" /> <selection name="FailoverCluster-FullServer" state="true" /> </package> </servicing> <settings pass="windowsPE"> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>en-US</UILanguage> </SetupUILanguage> <SystemLocale>es-ES</SystemLocale> <UserLocale>es-ES</UserLocale> <InputLocale>040a;0000040a</InputLocale> <UILanguage>en-US</UILanguage> <UILanguageFallback></UILanguageFallback> </component> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <UserData> <ProductKey> <WillShowUI>Never</WillShowUI> </ProductKey> <AcceptEula>true</AcceptEula> <FullName>Nombre</FullName> <Organization>Empresa</Organization> </UserData> <ImageInstall> <OSImage> <InstallFrom> <MetaData wcm:action="add"> <Value>Windows Server 2008 R2 SERVERDATACENTER</Value> <Key>/IMAGE/NAME</Key> </MetaData> </InstallFrom> </OSImage> </ImageInstall> </component> </settings> <settings pass="specialize"> <component name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <fDenyTSConnections>false</fDenyTSConnections> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>Servidor1</ComputerName> <RegisteredOwner>Emresa</RegisteredOwner> <TimeZone>Romance Standard Time</TimeZone> </component> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <Credentials> <Domain>Dominio</Domain> <Username>administrator</Username> <Password>password</Password> </Credentials> <JoinDomain>dominio.local</JoinDomain> </Identification> </component> </settings> <cpi:offlineImage cpi:source="wim:j:/sources/install.wim#Windows Server 2008 R2 SERVERDATACENTER" xmlns:cpi="urn:schemasmicrosoft-com:cpi" /> </unattend>

2.- Fichero autounattend.xml para Windows Server 2008 R2 Datacenter Server Core.

18
<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <servicing> <package action="configure"> <assemblyIdentity name="Microsoft-Windows-ServerCore-Package" version="6.1.7600.16385" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="" /> <selection name="FailoverCluster-Core" state="true" /> <selection name="Microsoft-Hyper-V" state="true" /> <selection name="MultipathIo" state="true" /> <selection name="WindowsServerBackup" state="true" /> <selection name="WindowsServerBackupCommandlet" state="true" /> <selection name="NetFx2-ServerCore" state="true" /> <selection name="MicrosoftWindowsPowerShell" state="true" /> <selection name="TelnetClient" state="true" /> </package> </servicing> <settings pass="windowsPE"> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>en-US</UILanguage> </SetupUILanguage> <SystemLocale>es-ES</SystemLocale> <UserLocale>es-ES</UserLocale> <InputLocale>040a;0000040a</InputLocale> <UILanguage>en-US</UILanguage> <UILanguageFallback></UILanguageFallback> </component> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <UserData> <ProductKey> <WillShowUI>Never</WillShowUI> </ProductKey> <AcceptEula>true</AcceptEula> <FullName>Nombre</FullName> <Organization>Empresa</Organization> </UserData> <ImageInstall> <OSImage> <InstallFrom> <MetaData wcm:action="add"> <Value>Windows Server 2008 R2 SERVERDATACENTERCORE</Value> <Key>/IMAGE/NAME</Key> </MetaData> </InstallFrom> </OSImage> </ImageInstall> </component> </settings> <settings pass="specialize"> <component name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <fDenyTSConnections>false</fDenyTSConnections> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>Servidor1</ComputerName> <RegisteredOwner>Nombre</RegisteredOwner> <TimeZone>Romance Standard Time</TimeZone> </component> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <Credentials>

19
<Domain>dominio</Domain> <Username>administrator</Username> <Password>password</Password> </Credentials> <JoinDomain>dominio.local</JoinDomain> </Identification> </component> </settings> <cpi:offlineImage cpi:source="wim:j:/sources/install.wim#Windows Server 2008 R2 SERVERDATACENTERCORE" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> </unattend>

Tenis ms informacin sobre todos estos temas aqui:

Step-by-Step: Basic Windows Deployment for IT Professionals Settings to Use for an Unattended Installation

Una vez terminado el proceso de instalacin, ya tendremos el servidor corriendo Hyper-V, configurado con su propio nombre, metido en el dominio y con todo lo necesario para pasar a configurar la red y el almacenamiento tal y como hemos planificado en los posts anteriores. Deberemos configurar el direccionamiento IP deseado en cada interfaz segn el uso al que se vaya a dedicar y preparar los volmenes que nos vienen desde el almacenamiento compartido. Configuracin de Hyper-V Dado que Hyper-V ya deber estar corriendo por debajo de la particin padre, solo necesitaremos crear manualmente los switches virtuales a los que conectaremos las mquinas virtuales y elegir en que carpetas del almacenamiento guardaremos los ficheros de configuracin de las mquinas virtuales, sus discos y las snapshots.

En todos los hosts: Desde el Hyper-V Manager, bien local o remotamente, vamos a la configuracin de las redes virtuales y creamos los switches virtuales, creando en ese momento o no tarjetas virtuales enlazadas a dichos switches para la particin padre:

En los servidores stand alone, es conveniente cambiar los paths por defecto donde se almacenaran los ficheros de las mquinas virtuales y las snapshots. En nuestro caso, todos esos paths apuntan a volmenes correspondientes al almacenamiento compartido, ya que en estos caso se trata de lograr la mayor

20
independencia posible de un servidor fsico dado:

Como decamos en los posts anteriores, es muy importante acostumbrarse a ser consistente con estas nomenclaturas, incluso en entornos de laboratorio. Creacin del cluster En Windows Server 2008 y Windows Server 2008 R2 es posible crear sistemas cluster con servidores bastante diferentes entre si. Sin embargo para formar un cluster con Hyper-V deberemos elegir nodos lo ms homogneos posible, dentro de que es posible cierta disparidad. En cualquier caso no ser posible tener ni Quick ni Live Migration entre sistemas con diferente fabricante de procesador (Intel y AMD) y para procesadores de diferentes familias dentro del mismo fabricante, es posible habilitar en el procesador de las mquinas virtuales el modo de compatibilidad para que los movimientos entre hosts sean posibles.

Podemos crear el cluster desde cualquier equipo en el que hayamos instalado la consola, que puede ser uno de los nodos que lo conformarn. Este es el proceso paso a paso:

21

Primeramente agregamos los servidores que conformarn el cluster y pasamos el proceso de validacin sobre ellos.

22

Una vez validado el sistema (en este ejemplo faltaban por presentar los discos y por configurar la red interna y de ah la advertencia), podemos pasar a crear al cluster en tres sencillos pasos que se reducen a elegir su nombre y su direccin IP:

Tras este proceso ya tendremos nuestro cluster activo, y si todo ha ido bien veremos en el apartado del almacenamiento el quorum y los discos presentados a ambos nodos desde la SAN como almacenamiento disponible. Solo nos queda un par de pasos: Habilitar los Cluster Shared Volumes en la consola de Failover Cluster a nivel del nombre del cluster Agregar los discos compartidos que queramos convertir en CSVs a la carpeta con ese nombre que aparecer en la consola del cluster despus de haberlos habilitado en al apartado anterior Consideraciones sobre los Cluster Shared Volumes (CSV) Pequea Guia rapida de Live Migration y Clustered Shared Volumes (y un video)

Tenis mas informacin al respecto y un video aqu:

23
Con respecto a la red, es conveniente tambin renombrar en la consola cada una de las redes y revisar si el uso que har de ellas el cluster es el que hemos planificado segn el post anterior. He aqu como queda en nuestro poco recomendado caso de tener solo dos NICs en los hosts:

Recordemos que el trafico de red correspondiente al funcionamiento de los CSVs fluye por la red de menor mtrica. Aqu esta documentado como tener control de esto:

Designating a Preferred Network for Cluster Shared Volumes Communication

Ya podemos proceder a crear las mquinas virtuales. En los servidores stand-alone podremos crearlas desde la consola de Hyper-V. Las que queramos dotar de alta disponibilidad y capacidades de Live Migration pueden crearse directamente usando la consola de Failover Cluster, ya que ambas consolas estn integradas:

24

Por ltimo, podemos definir cual va ser la red que se utilizar para el proceso de Live Migration. Este es un parmetro global, que afecta a todas las VMs de un cluster, pero que se define sobre cualquiera de ellas. En nuestro caso no hay muchas opciones

A partir de este momento ya tenemos la base montada para poder correr encima todas las mquinas virtuales que sean capaces de mover los servidores de los que dispongamos.

25

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Instalacin y Configuracin de Virtual Machine Manager

David Cervigon 29 Jun 2010 4:16 PM Comments 14 Posts anteriores:


Hola

Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Objetivo y consideraciones generales Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualizacin: Requerimientos: El Directorio Activo Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Red Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Requerimientos: Almacenamiento Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualizacin: Instalacin de los hosts de HyperV y el cluster

Hasta el momento hemos tratado diferentes aspectos de los requisitos e instalacin de Hyper-V. Con lo que tenemos hasta ahora ya podemos empezar a crear mquinas virtuales y a moverlas entre los hosts del cluster siempre que contemos con las consolas correspondientes instaladas en algn servidor Windows server 2008 R2 o un Windows 7 con las Remote Server Administration Tools (RSAT). En este post vamos a ver como realizar una instalacin y configuracin inicial de System Center Virtual Machine Manager 2008 R2. Por no llenarlo de pantallazos, he decidido simplemente publicar los mas relevantes. En este PDF he incluido todos. La instalacin de Virtual Machine Manager es bastante sencilla y rpida, y simplemente nos pedir tomar una decisin por cada uno de los componentes de su arquitectura. Lo mas sencillo es instalar todo sobre el mismo servidor, pero pueden tambin instalarse por separado den diferentes equipos. Un servidor para la base de datos, otro para el servicio, otro para el portal, la consola de gestin en los clientes y file servers para la biblioteca. Los agentes son necesarios en los host que se gestionarn, en el servidor que alberga el servicio, y en los servidores que conformen la biblioteca:

26

Opcin VMM Server.

La base de datos. VMM se apoya en una base de datos SQL. Durante el proceso de instalacin nos solicitar elegir una instancia ya existente en la red, o podemos tambin usar el SQL Express 2005 SP3 que viene incluido en el producto. En este ltimo caso, la instalacin y configuracin de SQL y la creacin de la base de datos se realizan de manera completamente desatendida.

La librera. Este componente de VMM es el encargado de mantener el conjunto de ingredientes que necesitaremos para desplegar nuevas mquinas virtuales, y constituye un almacn para plantillas y VMs que no es necesario que estn desplegadas en los hosts. ISOs, VHDs, perfiles de hardware, perfiles de software, scripts, etc. se alojan en file shares disponibles en la red, a los que se despliega el agente de Virtual Machine Manager. Es obligatorio que exista al menos una carpeta compartida en la mquina en la que se instala el servicio, por lo que tendremos que elegir donde reside su path por defecto, o proporcionar una carpeta compartida local ya existente. Si no se van a usar otro servidores para la biblioteca, y si VMM se esta montando virtualizado, hay que tener en

27
cuenta que esa carpeta crecer segn vayamos definiendo plantillas, VHDs y mquinas virtuales. En estos casos es interesante asignar por pass-thought o por iSCSI una LUN del almacenamiento, para evitar que el VHD de la propia VM de Virtual Machine Manager crezca indiscriminadamente.

El servicio de VMM. El motor principal de Virtual Machine Manager es este servicio, con su capa de PowerShell por encima. Aqu tenemos que decidir cuales son los puertos que se utilizarn (por defecto el 8100, el 80 y el 443) y especificar si correr con la cuenta LocalSystem (defecto) o con una cuenta de usuario del directorio activo, que tendremos que hacer administradora local del equipo. Los criterios para elegir entre una u otra opcin estn listados en estos enlaces, pero ser ms fcil la integracin con SCOM, y, sobre todo, habilitar la posibilidad de compartir ISOs remotamente (How to Enable Shared ISO Images for Hyper-V Virtual Machines in VMM) si se utiliza una cuenta del directorio activo.

When should I consider running my VMM Service by using a domain account? Hardening the VMM Server

Opcin VMM Administrator Console: La instalacin del servicio no incluye la consola grfica de administracin. Deber instalarse separadamente sobre el servidor, si as se desea, y sobre los equipos cliente desde los cuales se quiera administrar Virtual Machine Manager. Lo nico que nos pregunta la instalacin es el puerto que se utilizar para conectarse con el servicio, que ser el que hayamos especificado arriba. Al lanzar la consola tambin puede cambiarse, ya que se usa el clsico formato server:puerto:

28
Opcin VMM Self Service Portal: El Portal de Autoservicio se instala sobre un servidor que tenga instalado un IIS con los componentes que se citan como requisitos en el pantallazo de abajo. Tendremos que indicar cual es el servidor donde esta corriendo el servicio de VMM y su puerto, y especificar las opciones del servidor Web. Si, como es lo ms frecuente, se encuentra con un site ya definido en el puerto 80, dar un error y tenemos tres opciones para salir del paso: Usar otro puerto Usar host headers, para lo que habr que definir el nombre elegido como alias en el DNS Si no se va a utilizar ese servidor Web para otros menesteres, simplemente borramos o desactivamos el Default Web Site

Llegados a este punto ya tenemos una instalacin funcional de System Center Virtual Machine Manager:

Para poder empezar a hacer cosas con el, ser necesario:

Desplegar los agentes a los hosts con Hyper-V (http://blogs.technet.com/b/davidcervigon/archive/2008/11/21/instalaci-n-de-un-servidor-de-gesti-n-ymonitorizaci-n-de-entornos-f-sicos-y-virtuales-ii.aspx) Conectar con un VMware Virtual Center, si lo hubiera Definir los perfiles de hardware que tendrn nuestras mquinas virtuales Definir los perfiles de sistema operativo (esto representa ficheros de respuesta desatendidos de sysprep) Definir plantillas Definir Administradores delegados Definir Usuarios de Autoservicio Etc.etc.

29
Mas informacin (http://blogs.technet.com/b/davidcervigon/p/systemcenter.aspx)

TechCenter de System Center Virtual Machine Manager 2008 and Virtual Machine Manager 2008 R2