Parece que está de moda convertir los domain controller. A pesar de que es una práctica no recomendada, se incrementan las "quejas" de mucha gente que intenta hacerlo. Partiendo de la base de que, en mi opinión, se tarda menos en promover un nuevo DC que en convertirlo, os dejo el link a un KB de VMware para los que aún se atrevan (o no les quede otro remedio) que convertirlo. Sólo un recordatorio: Converter sólo virtualiza un domain controller, no arregla un dominio con problemas. Para lo que sí sirve una conversión de un domain controller es para hacer aflorar o agravar los posibles "problemas" ocultos de un directorio, así que toca revisión exhaustiva el Dominio antes de la conversión (link, otro link, más una enormidad en google). Para los que os tropezáis con uno de esos Domain controller-navaja suiza (es decir, un DC que además tiene trescientas cosas más montadas encima), mi consejo es: Nueva VM, dcpromo para promoverla a DC, migración de roles (os dejo un link por aquí) y un dcpromo en la vieja para despromoverla como DC.
Un saludo.
7 comentarios:
Uhm... he de hacer referencia a Mr. Benjamin Armstrong, en su magnífico post sobre "El Dilema del Controlador de Dominio". Aquí:
http://blogs.msdn.com/virtual_pc_guy/archive/2008/11/24/the-domain-controller-dilemma.aspx
Para estas cosas, nada mejor que las fuentes....
Sí... cuando use Hyper-V en producción, mantendré los DC en físico. Respecto a hacerlo en ESX, seguiré este link:
http://support.microsoft.com/?scid=kb;en-us;888794&x=14&y=15
es que para estas cosas.....
Esto... lo hagas en ESX, en Hyper-V, en Xen o en la madre del topo, ten en cuenta éste párrafo del link que has puesto:
To help preserve the integrity of the Active Directory database if a power loss or another failure were to occur, the Active Directory directory service performs unbuffered writes and tries to disable the disk write cache on volumes hosting the Active Directory database and log files. Active Directory also works in this manner when it runs in a virtual hosting environment.
Corolario: si AD deshabilita el caché de disco, el rendimiento del almacenamiento cae.
Y no, no tiene sentido deshabilitar el caché en la VM y no hacerlo en el host, así que, donde haya un controlador de AD, no debe haber cachés de disco.
Por eso Ben sugiere poner, al menos uno, en un servidor físico (que no necesita prácticamente ningún requisito de hardware potente: cualquier máquina con dos discos en espejo y capaz de ejecutar Windows Server 2003 (o 2008, los servicios de AD nativos de 2008 son la caña) sirve.
Resumen: Si tengo I/O suficiente, puedo virtualizar un DC. cientosnosecuantosmil de Hiperví y cientoscuantosmilmas de ESX deberían ser suficientes. A unos cuantos DC que ya tengo virtualizados (y sin problemas según los señores de Microsoft que los auditan) se alegrarán de saberlo.
A ver, donde digo "Al menos uno" quiero decir exactamente eso: Un DC debería ser físico.
Todos los demás, pueden ser virtuales (yo tengo unos cuantos, y no me caben dudas de que por ahí fuera hay decenas de miles).
Esta manía mía de no explicarme...
Según tu punto de vista. Según el mío, siguiendo las buenas prácticas en lo que se refiere al servicio de hora, no es necesario mantener un servidor físico, con su consumo, sus mantenimientos HW y su cooling para ser un simple controlador de dominio. Un servidor físico que mantiene un servicio que, al menos en parte, no está redundado (como es el caso de algún que otro rol), al "romperse" (nada nos libra de una fuente fundida, una placa estropeada), requiere de intervención inmediata, que entre lo uno y lo otro, supone un par de horas. Si te pasa eso en un ESX, aún sin HA, levantarlo en otro ESX es cuestión de minutos.
Resultado: Menor coste, mayor eficiencia, menor downtime.
Esos son mis parámetros. Y como digo Groucho, si a alguien no le gustan, tengo otros.
Yo no recomiendo tener un unico DC virtualizado.
Actualmente en mi empresa se ha corrompido el directorio sysvol en un DC de una de las 2 oficinas de barcelona que esta virtualizado en un ESX.
El dominio funciona bien excepto las GPO que dan errores por tener el sysvol corrupto.
Abriendo caso con Microsft te dicen que no te dan soporte a no ser que tengas una versión en concreta de ESX que logicamente no vamos a hacer porque sale mas a cuenta montar un nuevo DC en una máquina fisica que actualizar el ESX,ya que si algo va mal puede afectar a 30 servidores de produccion que cuelgan del ESX.
Publicar un comentario