Hola
Como continuación del post anterior (Instalación de un servidor de gestión y monitorización de entornos físicos y virtuales (I)) vamos ver cómo desplegar los agentes de System Center Virtual Machine Manager 2008 a los equipos físicos que vamos a gestionar y sobre los que recaerá el trabajo de mover toda la infraestructura virtualizada. Trataré estos cuatro casos:
1.- Despliegue del agente de SCVMM2008 a un host perteneciente a un dominio o un grupo de trabajo
Desde la consola de SCVMM2008, pinchamos en la opción agregar Host y Siguiente, Siguiente finalizar. Cuando se usan las opciones de búsqueda para localizar hosts lo que sucede por debajo es que la cuenta de servicios de SCVMM2008 recorre los contenedores del Directorio Activo en los que se pueden almacenar cuentas de máquina para localizar servidores. Y en particular si se marcan las casillas de Hyper-V y Virtual Server solamente se muestra aquellos equipos para los que estén registrados los SPNs correspondientes a esas estas pilas de virtualización (podéis verlo vosotros con ADUC con la opción avanzada de ver los usuarios y equipos como contenedores):
Si, como es el caso, ese servidor no tiene Hyper-V y Virtual Server, esta acción intenta instalar la pila de virtualización correspondiente y establecer las excepciones en el Firewall. Por otro lado la casilla de reasociar el host se utiliza para aquellos servidores que ya tengan el agente desplegado, pero que estén asociados a otro servidor con SCVMM2008. Esto pone de manifiesto el hecho de que un servidor solo puede ser gestionado simultáneamente desde un único servidor de SCVMM.
También es importante destacar que si en el proceso de descubrimiento se agrega un equipo que es nodo de un cluster de Hyper-V, SCVMM2008 detecta la situación y agregará todos los nodos de golpe. Además se encargará de eliminar o agregar automáticamente los nodos que pongamos o quitemos desde la propia consola de Failover Cluster, manteniendo la consistencia del conjunto como un todo.
Por último, es importante mencionar que el host no tiene por qué pertenecer al mismo dominio donde resida SCVMM2008, ni siquiera al mismo forest, y tampoco son necesarias relaciones de confianza entre ambos. Simplemente debe haber buena resolución DNS. Para agregar un host en un dominio con el que no exista confianza, basta con desmarcar la casilla "Host is in a trusted domain" de la primera ventana del asistente, modificando eso si las credenciales para autenticarnos contra ese dominio en particular. Posteriormente se nos solicitaré el nombre FQDN del host que pretendemos agregar. Esta técnica funciona también con un hosts en un grupo de trabajo, simplemente sustituyendo el nombre del dominio por el del host en particular, con lo que de esta manera estamos forzando una autenticación contra su propia base de datos de usuarios local.
2.- Despliegue del agente de SCVMM2008 a un host en una DMZ (o también a un grupo de trabajo)
En este caso necesitamos llevar a cabo la instalación en dos pasos. Primeramente instalar manualmente el agente en el host, lo que produce un certificado que nos llevaremos y utilizaremos en SCVMM2008 para completar el proceso de asociación.
3.- Agregar un VMware VirtualCenter y hosts con VMWare ESX
Aunque esto pueda parecer complicado, lo cierto es que solo hay que tener un par de cosas en cuenta. El entorno de VMware se gestiona a través de las APIs que expone VMware VirtualCenter. Si posteriormente se agregarn hosts ESX tanto desde SCVMM2008 como desde las herramientas de VMware, la acción tendrá si reflejo en ambos sitios. Lo mismo para el borrado. Una vez iportado el entorno creado en VirtualCenter a SCVMM2008, la eliminación de un host desde cualquiera de ambas consolas se traslada a la otra igualmente.
4.- Agregar Servidores de Librería
La Librería de SCVMM2008 es realmente un compendio de carpetas compartidas distribuidas a través de la red, en cuyos servidores se despliega el agente automáticamente. Allá donde tengamos almacenados VHDs, ISOs, VMs, scripts, etc. solo habrá que compartir las carpetas correspondientes y agregar el servidor/share a la consola. Un único servidor puede contener varias carpetas compartidas que se agregarán individualmente:
Con esto ya tenemos todo en nuestra mano para que aunque el entorno virtualizado crezca como las setas en un otoño lluvioso no perdamos el control y la visión unificada sobre el mismo. No obstante nos faltaría desplegar los agentes de Operations Manager tanto a los hosts físicos como a las máquinas virtuales. Lo veremos en el próximo capítulo de esta serie.
Saludos
David Cervigón
El objetivo es instalar en un único servidor, miembro del dominio, todo lo necesario para gestionar y monitorizar un entorno heterogéneo, físico y virtual, con hosts de virtualización basados en Virtual Server 2005 R2 SP1, Hyper-V y VMware ESX: Para ello vamos a necesitar instalar:
Obviamente todos estos productos soportan arquitecturas mucho más complejas, con diferentes servidores jugando cada uno su papel. Este modelo más simple es adecuado para entornos sencillos, o de demo o prueba de concepto, similares al expuesto en mi anterior post "Cómo va montada la demo de Virtualización" (en particular así he montado la VM "SystemCenter1" que aparece en dicho esquema)
No voy a poner todos los pantallazos de instalación, sino solo aquellos más significativos.
1.- Preparación el Sistema Operativo base y del Directorio Activo
2.- Instalación de los prerrequisitos del Sistema Operativo (copiad todo esto en un .cmd, poned un "pause" al final, y simplemente haced doble clic)
servermanagercmd -i FS-FileServer servermanagercmd -i Web-Server servermanagercmd -i Web-Http-Redirect servermanagercmd -i Web-Asp-Net servermanagercmd -i Web-Windows-Auth servermanagercmd -i Web-Mgmt-Console servermanagercmd -i Web-Mgmt-Compat servermanagercmd -i NET-Framework-Core servermanagercmd -i powershell
3.- Instalación y configuración de SQL 2005 SP2 y Reporting Services
4.- Instalación de System Center Operations Manager 2007 SP1. En este caso, hay que tener en cuenta que existe una versión del producto que ya trae el SP1 integrado. Si no se usa ésta, nada mas terminar la instalación será necesario aplicar el SP1 que se puede descargar de aquí.
5.- Instalación de System Center Virtual Machine Manager 2008: Instalamos el servicio (VMM Server), el portal de autoservicio (VMM Self-Service Portal) y por último la consola, pero no directamente sino eligiendo la opción "Configure Operations Manager"
Con esto tenemos toda la infraestructura lista. Lo siguiente será empezar a desplegar agentes para que el servidor empiece a desempeñar su trabajo. Lo dejaremos para otro post, que este ya me ha llevado todo el día
Una herramienta imprescindible para configurar los servidores con Hyper-V para que se puedan administra de manera remota, así como los equipos desde los que va a llevar a cabo dicha administración. Esta desarrollada por John Howard, uno de los jefes de producto involucrados en el desarrollo de Hyper-V, en base a la información que él mismo proporcionó en estos cinco posts:
La herramienta automatiza todos los pasos para poder realizar correctamente la gestión remota de Hyper-V, aunque como dice su documentación, no sería necesario en caso de utilizar System Center Vitual Machine Manager 2008 como consola de gestión del entorno virtualizado.
Hyper-V Remote Management Configuration Utility es realmente un script wsf, y puede descargarse de aquí:
Esto, junto con el Windows 2008 Server Core Configurator que ya comentamos aquí hace unas semanas, hace que la instalación y configuración de Hyper-V en Server Core sea bastante más sencillo que hacerlo a base de tirar comandos.
Últimamente, cuando tengo la oportunidad de pillar por banda a algún conjunto de pobres incautos bien predispuestos a escucharme hablar de virtualización, cuento las cosas del revés. Es bien sabido que tener una estrategia "Del Datacenter al escritorio" ya no es cosa nueva, así es que mis presentaciones van "Del escritorio al Datacenter". Sin descartar ese puntillo ególatra de rebeldía y distinción, la cosa tiene sus razones. La primera es sorprender, porque lo que todo el mundo espera es que el chavalote de Microsoft se lance a tumba abierta a dar la matraca con Hyper-V. La segunda, es que cada día tengo más claro que eso de comparar hypervisores va a acabar siendo como comparar navegadores, con discusiones tan acaloradas como estériles. Obviamente intento no defraudar en esa parte, pero lo dejo para después del café y desde luego cierro con el verdadero meollo de la cuestión, que no es otro que la gestión de todo el embrollo.
VDI (Virtual Desktop Infrastructure) es la extrapolación directa de la vieja idea de la virtualización del servidor al mundo del cliente, creando máquinas virtuales de sistemas operativos de escritorio y albergándolas en el datacenter. Los buenos resultados conseguidos en los últimos años con la virtualización de servidores han producido una fuerte y ¿novedosa? tendencia en los últimos meses a aplicar esta aproximación como si fuese un conjuro, pero, si bien los servidores siempre han tenido una taxonomía bastante pobre, las necesidades del usuario y su escritorio son extremadamente ricas y variadas, pudiendo variar mucho entre diferentes organizaciones. Abordar el problema mediante la sustitución del escritorio físico por una máquina virtual en el CPD puede resultar muy frecuentemente tan inadecuada como cara según sean las necesidades del usuario que vaya a utilizar la infraestructura.
Los verdaderos beneficios de aplicar la virtualización se alcanzan cuando se es capaz de desligar completamente las capas de Hardware, Sistema Operativo, Aplicación, Configuración y Datos. La rotura de esas ligaduras es lo que nos permite realmente tener la flexibilidad necesaria para obtener los cacareados ahorros de costes y máximos retornos de inversión. La creación de una máquina virtual solamente rompe la relación entre hardware y sistema operativo, y además no es la única manera de lograrlo. Por tanto para empezar a hablar de virtualización, el escritorio constituye un ejemplo estupendo de que todo este negocio va mucho más allá de la mera capacidad de crear una máquina virtual e instalar dentro de ella un sistema operativo, y que hay otras tecnologías que renovadas y/o rebautizadas pueden ayudarnos a lograr los mismos resultados y además de una forma mucha más barata. A saber:
La construcción de una máquina virtual cliente y su almacenamiento en el datacenter traslada también directamente los costes de la solución de un sitio a otro. Sin embargo, la memoria, procesador y almacenamiento del datacenter son más caros que los equivalentes en el mundo del escritorio. A cambio obtenemos la flexibilidad de las nuevas posibilidades de gestión centralizada de todo el ciclo de vida del escritorio que nos ofrece la virtualización, probada con éxito en el mundo del servidor. Por tanto, antes de decidirnos por esta alternativa es conveniente cruzar el elevado coste de la solución con sus ventajas y con las necesidades reales del usuario.
Una buena infraestructura optimizada de virtualización del escritorio es aquella capaz de unificar las ventajas de todo lo anterior en usa misma arquitectura. Es decir, debe ir mucho más allá de lo que hoy entendemos por VDI, sin cambiar realmente demasiado su esquema. Ante la necesidad de un usuario a los mandos de un dispositivo, más o menos rico, de ponerse a realizar una tarea o una serie de ellas, la solución debe ser capaz de redirigirle a una máquina virtual albergada en el datacenter, a un servidor o granja de terminales, a un escritorio físico encendido en un lugar remoto, o una máquina virtual albergada a su vez en ese escritorio físico remoto. Conceptualmente, la solución es simplemente un cliente RDP que es redirigido por un bróker a un sistema con RDP habilitado. Adicionalmente, las aplicaciones pueden estar a su vez virtualizadas en uno o ambos extremos, como alternativa a la instalación de software tradicional. Y es precisamente dicho bróker el que debe implementar la lógica por la cual, dependiendo de las necesidades específicas del usuario en particular, se le remita al extremo más barato y mejor optimizado para llevar a cabo las tareas que se pretenden realizar. Algo así:
Vaya por adelantado que esta imagen es una simple ilustración de producción propia y que no esta extraída de "roadmap" alguno. Si que es cierto que ya hay brokers de este estilo en el mercado, y el de Windows Server 2008 R2 parece que va en esta línea.
Me preguntan frecuentemente acerca de este tipo de cosas. Cambios de nombre de empresas, fusiones, adquisiciones, reestructuraciones o simples consolidaciones o migraciones a una nueva versión de Windows Server acaban desembocando en una operación a gran escala sobre el o los Directorios Activos implicados.
No me voy a extender mucho en cada una de las situaciones porque su variedad y diferentes niveles de complejidad hacen que este tipo de intervenciones puedan llegar a ser extraordinariamente complicadas. Además no está exentas de riesgos, por lo que es conveniente repasar cuidadosamente la documentación y planificar mucho antes de ponerse a actuar.
Renombrados del Dominio: Esta operación consiste en una variación del namespace del dominio, pero sin afectar al esquema y a los objetos que estén presentes en el. Suele ser necesario ante la variación del nombre de una empresa, que se quiere trasladar a la infraestructura, y, lamentablemente, también ante una mala elección inicial del nombre del dominio. Para esto existe una herramienta, descargarle para Windows Server 2003 e incluida en Windows Server 2008, llamada Rendom. Aunque es un simple comando, su utilización debe ser cuidadosa, requiere planificación y preparación, y de entrada solamente es aplicable a dominios en un nivel funcional 2003 nativo o superior. Estos son los recursos imprescindibles:
Fusiones, migraciones, consolidaciones y reestructuraciones: Es un error bastante frecuente pensar que dos Forests pueden fusionarse haciendo que uno de ellos adopte el nombre del otro, o de uno de sus dominios hijo, usando los procesos mencionados en el apartado anterior. Nada más lejos de la realidad. Un Forest tiene si propio esquema a partir del cual se generan todos los objetos y sus propiedades. Todos los dominios hijos de ese Forest compartirán dicho esquema único e irrepetible, por lo que la operación de renombrado de uno de ellos para adoptar el espacio de nombres del otro no solamente no dará el fruto deseado, sino que organizará un formidable caos. Otra situación frecuente es la necesidad de simplificar la estructura de un Directorio Activo, reduciendo el número de dominios hijos, o incluso aprovechar una migración a una nueva versión de Windows Server para crear un nuevo Forest y migrar a el los objetos del antiguo (usuarios, equipos, grupos, etc.) que nos interesen. Para estas situaciones tenemos la tradicional Active Directory Migration Tool, cuya última versión es la 3.1, y que soporta realizar estas operaciones con origen o destino en Windows Server 2008. Estas herramientas y las guías correspondientes cubren bien los escenarios de migración tanto inter como intraforest:
Por último recalcar que esto no es algo que deba hacerse con alegría y desenfreno. A mayor número de dominios, sites y servidores más necesarias se hacen las tareas de planificación, e incluso en los escenarios más simples es conveniente llevar a cabo estas operaciones con cuidado.
Si te ves en una de estas, que la fuerza te acompañe.