Share via

Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualización: Requerimientos: El Directorio Activo

  • Article

Posts anteriores:

Hola

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:

  • ¿Debo virtualizar controladores de dominio?
  • En un laboratorio/piloto de virtualización 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 versión del esquema?. Si esto no se puede cambiar, ¿que funcionalidades están afectadas?.
  • ¿Que otras cosas pueden ayudar (además de un DNS y un DHCP)?

Antes de continuar, puede que este otro post algo antiguo resulte de interés, aunque esté un poco fuera de este ámbito:

Virtualizar controladores de dominio

Lo cierto es que no hay mucho más que contar que no esté ya recogido aquí:

Donde colocar el/los DCs, si vamos a montar un nuevo Directorio Activo dedicado al entorno de virtualización

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 además 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 sería el siguiente:
    • Si solo tenemos dos hosts y planeaos montar un cluster (es seguramente el caso más complicado. Ver la opción 3 como una alternativa) tenemos que: 
      • Instalar y configurar los nodos en grupo de trabajo, pero teniendo en cuenta que formarán un cluster a futuro (lo que implica poner especial atención a la distribución 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 traído por los pelos porque en algún momento tendremos que operar un cluster sin tener el DC disponible.
    • Si contamos con un tercer host, o si no vamos a montar un cluster:
      • 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.
  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 partición 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 convertiría en un punto de fallo que darán al traste con cualquier prueba de HA que se quiera realizar). Para hacer esto tendremos que:
    • Instalar y configurar los nodos en grupo de trabajo, pero teniendo en cuenta que formarán un cluster a futuro (lo que implica poner especial atención a la distribución 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 configuración del DNS
    • Crear y configurar el cluster
    • Crear/importar el resto de máquinas virtuales
  4. Un DC físico con uno o varios DCs virtuales adicionales. Esto es lo más parecido a como debería montarse en producción. Puede dedicarse un servidor físico a DC, DNS y DHCP o incluso un PC en el que aprovecharemos para montar todo tipo de consolas de gestión. Esto permite además 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 gráfica, y podremos hacer desde aquí la gestión remota con toda comodidad
  5. Un DC montado en la partición padre de un servidor con Hyper-V, donde podemos aprovechar la potencia sobrante para hospedar máquinas virtuales. Pueden montarse luego DCs virtuales en otros hosts. Como se puede observar esto es un híbrido de las opciones anteriores, y una buena opción para cuando “solo” se tienen tres servidores potentes.

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 contábamos con más de dos servidores, con lo que la decisión fue montar un DC virtual sobre un pequeño 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 ocasión hemos tenido que recablear, cambiar la alimentación, 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 tenías ni DNS, ni Directorio Activo ni más ayuda que “ping –a”. Dormiremos mucho más tranquilos cuando usemos ese (u otro) pequeño servidor como DC adicional, además de como punto único de gestión del entorno (en algún sitio hay que enchufar un monitor un teclado y un ratón).

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 mínimo Windows 2003 Nativo
  • El bróker de conexiones de Remote Desktop Services utiliza un nuevo atributo de Windows Server 2008 (no R2) para almacenar la máquina virtual personal asignada a un usuario. Como es bien sabido, un nuevo atributo en un objeto de directorio activo supone una ampliación del esquema. Para más señas, estamos hablando de msTSProperty01, que se introduce en Windows Server 2008 (sin R2) en SCH37.ldf. Mis antiguos compañeros 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 ampliación del esquema servirá para poder introducir novedades de 2008, como por ejemplo los RODCs. La interfaz de configuración del bróker 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 pestaña correspondiente en la cuenta del usuario:

image image

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 políticas de grupo de han inventado para no tener que ir máquina por máquina configurando las mismas cosas. Utilízalas desde el primer momento. Entre las miles que hay seguro que hay alguna para lo que estas buscando:
  • Una CA Enterprise, y políticas de autoenrollment de certificados tanto para usuarios como para equipos a nivel de todo el dominio. Esto facilita la configuración de todo aquello que hoy en día necesita de una PKI para funcionar.
  • Siempre es bueno tener a mano e instalar las actualizaciones necesarias para que en todas las máquinas del dominio funcionen las Group Policy Preferences (es decir, las Group Policy client-side Extensions). Estas extensiones son particularmente útiles conseguir que grupos de máquinas 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 :-)

Saludos

David Cervigón

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    February 26, 2010
    Gracias David (y demás ingenieros) por toda esta información. Sería fenomenal que todo esto quedara plasmado en un White Paper u otro documento, y publicado en el downloads de Microsoft como información para montar labs, por ejemplo. Entiendo que este White Paper -con un punto de vista tal vz diferente- no llega al nivel que vosotros mostráis con estos post: Deploying a Virtualized Session-Based Remote Desktop Services Solution (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=8d454921-72d6-45b4-b6ba-ac1c26d337bd) Un saludo :-)

  • Anonymous
    February 26, 2010
    The comment has been removed

  • Anonymous
    March 03, 2010
    Un consejillo el PDC emulator en el DC Fisico. Por GPO desabilitar el servicio de sincronización de tiempo de hyper-v en la OU de los DCs