Arquitecturas para la nube con Hyper-V
Hola
Continuando con las nubes, y tras que se haya anunciado hoy entre otras cosas la oferta de Microsoft para las nubes públicas y privadas en la Microsoft Management Summit de Las Vegas, me animo con este post que llevaba un tiempo pendiente de ver la luz. Lo cierto es que el título fue lo primero que se me ocurrió, aunque ahora me parece un poco bastante pretencioso. Pero es que si no, no rima :-).
Se trata de ver diferentes opciones para montar la infraestructura de virtualización sobre la que construiremos nuestros servicios, sobre todo en lo tocante a la monitorización y a la gestión de identidades. Resumiendo, qué opciones tenemos a lo hora de diseñar nuestro Directorio Activo de cara a albergar los servidores con Hyper-V y toda su gestión. Lógicamente esto son solo ideas, y adaptarlas a la realidad puede tener su complejidad.
Antes de seguir es importante tener una cosa en cuenta. Considerando a Hyper-V como mera capa de software con tareas de Hypervisor, es de cajón que no puede pertenecer a un dominio. Sin embargo, la partición padre de la que proviene, el Windows Server 2008 o Hyper-V Server en la que hemos activado Hyper-V como role y donde residen componentes claves de la pila de virtualización como red, almacenamiento, drivers y componentes de administración, puede ser un servidor miembro de un dominio o un servidor stand-alone (workgroup). Su pertenencia a un dominio es condición necesaria para el uso de ciertas funcionalidades avanzadas, como el host clustering que nos permite HA, Quick Migration y Live Migration, y es ciertamente conveniente si queremos hacer uso de una gestión de identidades, configuración y administración medianamente consistentes y unificadas.
MiNube.Local – El forest de Hyper-V
En primer lugar, vamos a ver el caso que mejor pone de manifiesto el concepto de nube. Una infraestructura totalmente independiente que contiene única y exclusivamente los servidores de Hyper-V y lo necesario para gestionarla:
Como puede observarse, tenemos la imprescindible capa de almacenamiento en la que se apoyan todos los servidores de virtualización. Los grupos de 16 hosts vienen a representar clústeres de 16 nodos, el máximo soportado a fecha de hoy en Windows server 2008 x64. ¿Deben de ser todos los servidores miembros de un cluster y dotar a la máquinas virtuales de HA y capacidades de migración?. Definitivamente no. Seguramente alberguemos entornos de pruebas y desarrollo en los que no necesitemos esas capacidades, o incluso sistemas en producción que ya implementes sus propios mecanismos de tolerancia a fallos y escalabilidad horizontal. Por ejemplo, una granja de frontales web trabajando en balanceo de carga (NLB o balanceadores hardware) es posible que no lo precise. Otro ejemplo es el guest clustering de Exchange CCR. Directamente en este entorno no se soporta que los nodos del cluster virtuales sean máquinas virtuales HA en un host cluster.
Lo segundo destacable de la figura es que la pila de gestión y los controladores de dominio de MiNube.Local son físicos. Aunque cuanto mayor sea el número de hosts y el número de DCs los potenciales problemas tienden a minimizarse, no es una mala idea reservarse algún DC físico. No se va a necesitar además responder a un gran volumen de cambios o autenticaciones en este sentido. Los servidores de gestión no se montan sobre la propia infraestructura a la que se supone que van a monitorizar por la misma razón por la que un huevo de la cesta no debe ser el encargado de vigilar si la cesta se cae o no.
Sin embargo es posible también crear una mini-nube dentro de la nube orientada únicamente a albergar los servicios de directorio, gestión y monitorización, aparte de los que albergaran el resto de los servicios:
Sobre esta base implantaremos soluciones completamente virtualizadas. A imagen y semejanza de lo que se lleva haciendo mucho tiempo en hosting y housing, no tenemos ningún tipo de dependencia con la infraestructura de virtualización. Hay podemos albergar el/los dominios internos de nuestra empresa, los frontales de nuestros dominios externos, o incluso hospedar soluciones de empresas asociadas, o interesadas en subcontratar/externalizar servicios en nuestra infraestructura.
Como haríamos en un entorno físico, siempre existe la posibilidad de plantearse el establecimiento de relaciones de confianza entre estos dominios, o establecer federaciones entre ellos. Esto puede resultar de utilidad para delegar la administración, o incluso para utilizar los mismos productos de monitorización y gestión que se utilizan para la nuestra nube. En nuestro caso, los productos de la familia System Center, Virtual Machine Manager, Operations Manager y Data Protection Manager.
Nebulizando el dominio existente con Hyper-V
Este es si duda uno de los escenarios más inmediatos, y por tanto el más frecuente. Ir integrando la virtualización en lo ya existente y que seguramente tenga ya mucha historia “física” recorrida. En este caso nuestra nube interna quedará reducida a un conjunto de máquinas, seguramente agrupada en una Unidad Organizativa propia, que albergarán un subconjunto de los servidores/clientes presentes en el directorio.
Aquí esta representado un dominio único, donde tenemos controladores de dominio y servidores de gestión tanto físicos como virtuales, y los servicios se construirán igualmente sobre infraestructura física y/o virtual. Lo más normal hoy en día es encontrarse que para un mismo servicio, ciertos componentes están virtualizados y otros permanecen todavía directamente sobre el hierro.
Esta foto facilita bastante la gestión al encontrase todo bajo el mismo paraguas desde el punto de vista de gestión de la seguridad e identidades. Una de las principales bazas que juega Microsoft en el mundo de la virtualización es ofrecer un conjunto de herramientas de gestión adaptadas que permiten la administración de todo el ciclo de vida de la infraestructura de manera unificada, independientemente de si es física, virtual, o esta mezclada.
La nube como dominio de recursos
Entre la opción de montar una verdadera nube aislada lógicamente y erigirnos en hosters internos y la de simplemente poner el vaporizador en lo que ya tenemos, existe una alternativa que se ha venido utilizando tradicionalmente (¿recordáis lo dominios de cuentas y de recursos que se estudiaban en NT?). Podemos usar un dominio del forest que dedicaremos en exclusiva a Hyper-V y su gestión. Repasando conceptos, un dominio en Directorio Activo supone una frontera de seguridad y contiene su propio conjunto de objetos (equipos, usuarios, políticas, etc.), pero comparte con el resto de dominios que conforman el bosque el mismo esquema y configuración, existiendo entre ellos por defecto relaciones de confianza. Esto permite un buen aislamiento de cada uno de los dominios, sin llegar a complicar demasiado el trabajo conjunto como en el primer caso, en el que existe más estanqueidad.
En el fondo, esta opción es un caso particular de la anterior, en la que violamos el principio de mantener las cosas los más sencillas posibles (forest único, dominio único). Sin embargo todos sabemos que muchas veces existen razones para ello, y en ocasiones fuera del ámbito técnico:
Bueno, todo este rollo para llegar a la conclusión de que podemos elegir entre multiforest, multidominio o dominio único. Pues menuda novedad, y además las combinaciones expuestas pueden pecar hasta de simplistas. Pero lo importante de todo esto es que la decisión de virtualizar esta muy ligada a la creciente necesidad de poner orden en los actuales datacenters, o incluso rediseñarlos. Y ese suele ser un buen momento para plantearse este tipo de cambios, e incluso decidir que servicios pueden pasarse a la “nube pública”. Y por supuesto hablar de qué se virtualiza y qué no, clústeres o no clústeres, almacenamiento, VLANs, recuperación ante desastres y centros de respaldo, etc.
¿Como os lo estáis planteando vosotros?
Saludos