La guía definitiva para la virtualización de controladores de dominio

Hola

La han publicado aquí:

• Running Domain Controllers in Hyper-V

Aunque esté centrada en Hyper-V, huelga decir que la mayor parte de los puntos que se citan son independientes de la pila de virtualización. Para los que andéis escasos de tiempo, he aquí un resumen rápido, que como de costumbre no exime de la lectura del documento original.

• Espera una pérdida de rendimiento de entre un 2% a un 12% comparado con un DC físico.
• Almacenamiento:
  • Cuidado con el problema de seguridad que puede suponer el acceso a los VHDs de las máquinas virtuales correspondientes a DCs.
  • No utilizar discos diferenciales, por los riesgos que supone desde un punto de vista operativo como por una cuestión de rendimiento.
  • Utilizar VHDs de tamaño fijo, o mejor aún discos pass-through. En estos últimos, las snapshots están deshabilitadas por defecto, lo que es francamente deseable para un DC virtual, por lo que nos llevamos rendimiento y fiabilidad por el mismo precio.
  • Colocar la base de datos y los logs en discos diferentes y que no coincidan con el de sistema operativo, tal y como se recomienda para un DC físico.
  • No de debe obtener un VHD de un DC a partir del VHD de otro DC, ni siquiera usando Sysprep. Si se quiere utilizar una plantilla, que sea la de un servidor miembro, generalizado con Sysprep, al que le haremos seguir el proceso de un DCPROMO.
• Mucho cuidado con las conversiones P2V de un DC físico. Deben realizarse siempre Offline y evitar en todo momento la concurrencia en la red del servidor físico y su imagen virtual.
• No usar la sincronización horaria con el host, dejando esta tarea en manos del servicio Win32Time como es costumbre en todo DC.
• Configura correctamente las acciones que se deben de llevar a cabo cuando se arranque y apague el host:
  • El DC virtual debe arrancar automáticamente cuando arranque el host.
  • El DC virtual debe apagarse (shutdown) automáticamente cuando se apague el host (por defecto la acción es salvar el estado).
• Cuidado con las acciones Pausar, Salvar, Instantánea, Exportar e Importar sobre un DC Virtual. Deben evitarse a toda costa, o en caso de ser necesarias, ser conscientes de lo que pueden suponer.
  • Cualquier acción que permita la vuelta atrás en el tiempo de un DC virtual es especialmente peligrosa.
  • En caso de ser necesario que un DC esté apagado, pausado o salvado, nunca se debe sobrepasar el periodo de Tombstone definido para el dominio (180 días en 2003 o superior, 60 en 2000).
  • Ninguno de estos medios pueden ni deben sustituir a una copia de seguridad del Controlador de dominio usando un método soportado.
  • Para curarnos en salud, en un dominio con DCs virtuales puede habilitarse la Strict Replication Consistency`para evitar la introducción e el AD de objetos desactualizados.
• Usa la misma estrategia de backup para los DCs virtuales que para los reales. Como protección adicional, puede obtenerse un backup del VHD usando el sistema de VSS del host. En el caso de tenerlo que restaurar, sigue estrictamente este diagrama de flujo:

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Muy bueno. Le agregaria solo una cosa David a esta lista. En caso de tener un ambiente Hyper-V de Failover Clustering, el DC siempre tiene que quedar afuera del cluster. En caso de que por alguna razon tenes que mover de maquina fisica al DC o alguna otra tarea que requiera el DC reiniciarse o apagarse, no se puede acceder de nuevo a la consola de clustering ya que necesita del DC para poder funcionar. Y puede llegar a ser un verdadero problema poner todo en funcionamiento de nuevo. Saludos! Augusto

• Anonymous
  February 02, 2009
  En ese caso habría que tener dos DCs uno en cada nodo del cluster, porque si no, en caso de fallar el nodo donde está el DC, hacemos un pan como unas tortas en cuanto a HD se refiere. Nota: yo sigo echando en falta mención a la asignación de memoria y área de swap en máquinas virtuales.