Virtualización. Algo que no debe ser tomado a la ligera.
Desde hace unos años la virtualización está ganando terreno y confianza entre los administradores y gerentes de gran cantidad de empresas. Es más, me atrevería a decir, que en su mayoría, las empresas de primera línea están considerando usos para la virtualización o incluso piensan en reservar alguna porción del presupuesto para comenzar con las pruebas o implementación. Esto sin duda incentivará al sector para continuar invirtiendo en desarrollos de mejores productos, tanto en materia de hardware como de software.
Ahora, la pregunta es: Si todo es tan bueno y parece estar solucionado. ¿Porque estoy escribiendo sobre esto?
Como toda nueva tendencia mucha gente considera solo los beneficios, , obviamente, por ser los aspectos más difundidos. Pero son pocos los que tienen en cuenta las dificultades y exigencias de una infraestructura virtualizada. Es justamente por la falta de investigación acerca de esas dificultades que comenzaron a observarse algunos problemas relacionados con las malas implementaciones de los sistemas virtuales.
Aclaro que la idea de este artículo no es plantear una discusión sobre buenas prácticas de virtualización, Sino demostrar con un ejemplo práctico como una mala implementación puede traernos más de un dolor de cabeza.
Y así empieza la historia…
En muchas empresas los domain controllers representan una molestia para el administrador, ya que o bien comparten el hardware con otras aplicaciones, reduciendo notablemente la seguridad de los mismos. O están instalados sobre hardware sobrante de dudosa confiabilidad. Por lo tanto, siempre es un excelente candidato para la virtualización.
Aquí es donde comienza el problema, quien no escucho alguna vez decir: “Lo bueno de la virtualización es que si el sistema operativo deja de funcionar restauras el archivo VHD y listo, todo solucionado”. Lo cual puede ser cierto para algunos servicios básicos, dependiendo de la antigüedad del backup de ese disco virtual. Pero cuando hablamos de un Domain Controller o cualquier otro servidor más complejo las cosas no son tan simples. Obviamente siendo un elemento crítico de nuestra infraestructura, el Active Directory cuenta con más de una medida de protección para evitar inconsistencias. Entre ellos el USN o Update Sequence Number.
Update Sequence Number e invocationID
El USN es el índice que los domain controllers incrementan cada vez que un objeto es creado, borrado o actualizado. Durante la replicación de Active Directory el USN es quien marca a partir de que cambios se debe replicar a los demás compañeros de replicación. Pero este indicador por si solo no podría realizar el trabajo, y por eso contamos con el invocationID que es quien identifica a la base de datos de cada domain controller como única, y solo es modificado en caso de una restauración del estado de sistema o system state. Luego de la cual los demás DC’s, descartaran el USN del DC restaurado y toman el actual como valido, y por lo tanto luego de la replicación nuestra infraestructura volverá a estar como antes de la falla. En la figura 1 se muestra un ejemplo sencillo de este procedimiento.
Fig.1. Actualización de USN e InvocationID restaurados de manera correcta.
Imagen tamaño completo
Como se puede observar si el proceso se lleva a cabo como es debido y el system state está dentro del Tombstone time (el tiempo máximo de validez de un backup de sistema), no tenemos ningún inconveniente luego de la restauración del equipo.
Pero veamos qué pasa en el mismo escenario cuando a partir de la caída del DC, el administrador decide reemplazar el disco virtual para ganar tiempo.
Imagen en tamaño completo
1) El administrador instala 3 DC en su oficina, uno de los cuales decide agregar sobre un equipo virtual.
2) Se crean 100 nuevos usuarios en el VDC1, los cuales replican correctamente.
3) El administrador realiza un backup del sistema tomando una copia del archivo VHD del equipo virtual.
4) Se cambian los passwords para las 100 cuentas creadas recientemente, los cambios replican correctamente.
5) El administrador apaga el DC3 para realizar tareas de mantenimiento.
6) El administrador crea 50 cuentas de equipo en el VDC1, los cuales replican correctamente al DC2
7) El VDC1 sufre una falla de la que no puede ser restaurado
8) El administrador decide restaurar el VDC1 a partir de la copia del disco virtual.
9) El DC3 vuelve a estar online.
10) Cuando el administrador vuelve a realizar cambios en el VDC1, los mismos aumentan el USN a partir de 201 y manteniendo su InvocationID (Estado del VDC1 en el momento de la copia de seguridad). Debido a esto los demás DC no reconocen la falla en el VDC1 y continúan con su replicación normal. Creando varias inconsistencias en la Base de nuestro directorio.
A partir de la Windows 2000 y posteriormente en Windows 2003 Microsoft libero un parche que ayuda a la detección y recuperación de este comportamiento en los Domain Controllers (KB 885875 para Windows 2000 y KB 875495 para Windows 2003). Pero, solo ayuda, no puede evitarlo si los cambios no son lo suficientemente significativos como para disparar la alarma del mismo.
Conclusión
Aunque tal vez no lo parezca estoy totalmente de acuerdo con la virtualización, y creo que en un futuro muy cercano será la base de la infraestructura de muchas empresas. Es por ello que, en este articulo solo intento mostrar en pocas líneas, como toda implementación debe ser llevada a cabo con un previo relevamiento de mercado para evaluar las mejores opciones siguiendo siempre de cerca las recomendaciones de los fabricantes de software.
Hoy espero haber despertado la curiosidad de aquellos que deseen comenzar a recorrer el largo camino de la virtualización de infraestructura. Si es así tengan en cuenta algunas recomendaciones: en primer lugar no olvide que los puntos planteados en este articulo no son los únicos, como estos hay muchos y deben tenerse en cuenta. Por lo tanto es fundamental mantenerse informado sobre los muchos aspectos de esta nueva tecnología, Y , principalmente no dejarse llevar por los comentarios y las tendencias del mercado.
Mas información.
How to detect and recover from a USN rollback in Windows 2000 Server(http://support.microsoft.com/kb/885875/es)
How to detect and recover from a USN rollback in Windows 2003 Server (http://support.microsoft.com/kb/875495/es)
Condiciones de soporte para virtualización de hardware no-Microsoft (http://www.support.microsoft.com/kb/897615/es)
Condiciones de soporte técnico para Virtual Server (http://www.support.microsoft.com/kb/897613/es)