On the way to Virtualization

El concepto es tan sencillo como genial. Una solución robusta y económica cuya única pretensión es securizar o tunelizar, el protocolo RDP y su puerto 3389.

Lo más sorprendente…  que siga siendo «El gran desconocido», sobre todo cuando invertimos en tunelizar toda una red, con otras soluciones, a veces de forma innecesaria si empleáramos RDG o Puerta de enlace de Escritorio Remoto.

RDG, es un servicio de rol que permite a los usuarios remotos autorizados conectarse a los recursos de una red privada, desde cualquier dispositivo conectado a Internet que pueda ejecutar un cliente de Conexión a Escritorio remoto (RDC).

¿Cómo funciona?

Publicamos un Web Site y desde un cliente RDP estableceremos un canal SSL con nuestro sistema de balanceo, el que sea, por ejemplo, un F5, a través de nuestro Web Site y este a su vez se hablará con el RD Gateway, para tunelizar el puerto 3389 de RDP en un canal seguro.

Para que todo esto funcione la gracia está en que las root CAs que emiten los certificados de los extremos servidor estén dados de alta como CAs de confianza en los extremos clientes, es por eso que los certificados en el RD Gateway y en los servidores a los que nos conectaremos, se sugiere tengan un certificado valido para SSL (Server Authentication) que esté firmado por una CA pública (DigiCert) que los sistemas Windows reconocen.

RDG usa el Protocolo de escritorio remoto (RDP) sobre HTTPS para establecer una conexión cifrada y segura entre usuarios remotos en Internet y los recursos de red interna en los que se ejecutan sus aplicaciones de productividad.

Antes de esta versión de Windows Server, las medidas de seguridad impedían que los usuarios remotos se conectaran a recursos de la red interna a través de firewalls y NAT. Esto se debe a que el puerto 3389, el puerto usado para las conexiones RDP, suele estar bloqueado por razones de seguridad de la red.

La Puerta de enlace de Escritorio remoto transmite en su lugar el tráfico de RDP al puerto 443, usando un túnel HTTP de Seguridad de la capa de transporte/Capa de sockets seguros (SSL/TLS). Dado que la mayoría de las corporaciones abren el puerto 443 para permitir la conectividad desde Internet, la Puerta de enlace de Escritorio remoto aprovecha este diseño de red para proporcionar conectividad de acceso remoto a través de múltiples firewalls.

¿Qué ventajas aporta RDG?

• La Puerta de enlace de Escritorio remoto permite a los usuarios remotos conectarse a recursos de una red interna a través de Internet mediante una conexión cifrada, sin necesidad de configurar conexiones de VPN.
• Un modelo de configuración de seguridad completo para controlar el acceso a recursos de red interna específicos y una conexión RDP punto a punto, en lugar de permitir a los usuarios remotos acceso a todos los recursos de la red interna.
• RDG permite a la mayoría de los usuarios remotos conectarse a recursos de la red interna que están hospedados detrás de firewalls en redes privadas, atravesando NAT. Y además con RDG no tenemos que realizar una configuración adicional para el servidor de RDG o los clientes para este entorno.
• La Administrador de RDG permite configurar directivas de autorización para definir las condiciones que deben cumplirse para que los usuarios puedan conectarse a recursos de la red interna. Por ejemplo:
  • Quién puede conectarse a recursos de la red interna (es decir, los grupos de usuarios que pueden conectarse).
  • A qué recursos de la red (grupos de equipos) pueden conectarse los usuarios.
  • Si los equipos cliente deben ser miembros de grupos de seguridad de Active Directory.
  • Si se permite la redirección de dispositivos.
  • Si los clientes deben usar autenticación con tarjeta inteligente o autenticación con contraseña, o si pueden usar cualquiera de estos métodos.
• Si nos decidimos a instalar, no olvidemos de añadir IIS para que funcione la característica Proxy RPC sobre HTTP.

Cuidado.

Aunque ReFS este soportado, hay que deshabilitar las características de integridad de las bases de datos

La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos.

Por ejemplo, si se especifica para un empleado el valor de identificador de 123, la base de datos no debe permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna employee_rating para la que se prevean valores entre 1 y 5, la base de datos no debe aceptar valores fuera de ese intervalo. Si en la tabla hay una columna dept_id en la que se almacena el número de departamento del empleado, la base de datos sólo debe permitir valores que correspondan a los números de departamento de la empresa.

Si las bases de datos que vamos a utilizar son para Exchange, NTFS a 64kb.

Para Exchange Server la deduplicación no está soportada.

Más información: http://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx

La Memoria, es uno de los aspectos más críticos que pueden existir en un entorno de virtualización, entender bien la arquitectura de memoria de Hyper-V, nos permitirá comprender mejor como aprovechar los recursos y obtener el mejor rendimiento posible, sin olvidar que junto con la CPU vs. Virtual Processor, la Red y el Almacenamiento, conforman un tanto por ciento muy grande de lo que es la virtualización.

Memoria Física del Host

Parece lógico pensar que la mayor cantidad de memoria es el parámetro más importante sobre la memoria, pero no olvidemos que la velocidad y la latencia de la memoria son siempre importantes en un host de virtualización, donde lo normal sería sacrificar si es necesario estos otros aspectos con el fin de obtener más cantidad de memoria al mismo precio, donde lo realmente importante es equilibrar la configuración del host para poder obtener el mejor coste por VM posible. Podemos obtener más memoria a menor precio con memoria más lenta y de igual forma podemos tener memoria más rápida al mismo precio reduciendo la cantidad de memoria.

¿Cómo se traslada esto al uso de la memoria en Hyper-V?,

Un ejemplo; Memoria DDR-3 a 1333 MHZ es capaz de mover 35 GB/ps, mientras que a 800 MHZ sería capaz de mover 25 GB/ps, sé que son cifras muy altas, y podemos encontrarnos con algunos otros buses en el sistema que serán cuello de botella más tarde y puede que finalmente estas cifras terminen rebajándose a 8GB/ps reales. Tengamos en cuenta en cualquier caso que en un servidor físico toda esa velocidad está al servicio de un único sistema, mientras que en un servidor de virtualización estará al servicio de hasta 384 VMs por servidor con Hyper-V.

La recomendación parece clara, evaluar cuidadosamente la elección de memoria, porque la elección que hagamos puede tener impacto en el rendimiento de la memoria, ya que por ejemplo algunos módulos de memoria pueden forzar al sistema a rebajar la velocidad del bus para todos los módulos y por tanto seria tirar el dinero mezclar memoria rápida con memoria lenta.

Si estás pensando en ampliar la memoria del servidor, ten en cuenta los bancos de memoria que quedan libres en el servidor, con la configuración de memoria que necesites para tu entorno de virtualización. Es muy posible que sea mejor negociar con tu proveedor la recompra de la memoria que tienes y adquirir la misma memoria con las prestaciones que necesitas.

Máximos de Memoria en Hyper-V

Hyper-V se presenta en dos sabores: 1.- Versión dedicada y gratuita “Hyper-V Server” que contiene todas las funcionalidades de Hyper-V pero ningún derecho de licencias. 2.- Como un rol del OS que activaremos sobre una instalación full o core. El principal benefio son las ventajas de licenciamiento, Hyper-V como rol en versión Datacenter licencia por socket todas las VMs que montes con los derechos de Windows Server incluidos. Y aunque una VM puede tener 64GB de memoria, el uso que haga de ellos dependerá del sistema operativo que corra en la VM.

En Windows Server 2008 R2 cada VM puede acceder hasta 4 procesadores virtuales, hasta 64 GB de memoria por VM y pueden estar activas por host hasta 384 máquinas virtuales. El Host, soporta 64 procesadores lógicos, 1 TB de memoria física y 512 VP por host. En CLuster CSV, 16 nodos y 1000 VM

En Windows Server 2012 cada VM puede acceder hasta 64 procesadores virtuales, hasta 1 TB de memoria por VM y pueden estar activas por host hasta 1024 máquinas virtuales. El Host, soporta 320 procesadores lógicos, 4 TB de memoria física y 2048 VP por host. En Cluster CSV, 64 nodos y 4000 VM

La reserva de memoria del host

El host y la partición padre requieren de memoria para funcionar y es muy importante asegurarnos que tienen la memoria que requieren. A parte de la propia memoria requerida por el sistema operativo de la partición padre, tenemos que tener en cuenta la memoria que consuma en pico de los agentes de antivirus, monitorización ó backup. Ya que menciono tema antivirus, asegúrate de añadir las excepciones necesarias para entornos de hyper-v y/o CSV. Hay que considerar como mejor solución que paginen las VM a que pagine el host, pese a que la paginación es un enemigo natural de la consolidación de VMs.

Ésta sería la fórmula a aplicar;

• Hyper-V requiere 300MB como hypervisor

• El sistema en la partición padre se llevará 512MB, (mejor 1024MB)

• Suma la memoria máxima de todos tus agentes instalados en el servidor, antivirus, monitorización, backup…

• Por cada VM suma 32 MB

• Por cada GB que tenga una VM por encima del primero suma otros 8MB

• Suma toda la memoria y será la cantidad a reservar para el host.

Con el resto de memoria que quede en el host será la memoria que podrás usar para las VMs, esto es así porque la memoria de las VM es de un tipo especial denominado “non-paged-pool memory” esto supone una garantía de rendimiento dado que nos garantiza que las VM siempre usaran RAM y no paginación en disco. El host puede paginar pero no por la RAM que usen las VMs.

La memoria de Paginación en las VMs

Partimos de la premisa que si un sistema operativo página es porque le falta memoria RAM y tendrá como resultado consumo en operaciones de entrada y salida (I/O) en disco Cuando virtualizamos muchas VMs en un mismo servidor y sistema de almacenamiento las I/O deben de ser de las cosas que más nos preocupen. Si una VM página en disco tendremos un impacto pequeño, pero si tenemos 1000 VDIs ó VMs y se ha dimensionado mal la memoria y un porcentaje grande de estas VMs página, el rendimiento general será bastante malo.

Un buen aliado puede ser la memoria dinámica pero no quita que tengamos cuidado a la hora de calcular la memoria real que necesitamos, si no calculamos bien puedes quedarte sin memoria y entonces veras cifras negativas de memoria disponible en las VMs y estarás sufriendo paginación. Para ello, monitoriza adecuadamente tus VM. Si el rendimiento de la paginación es crítico en tu entorno para una VM, puedes usar un VHDX fijo adicional para la paginación.

Los ficheros .bin

En cualquier momento puede ser necesario realizar operaciones que tienen repercusiones con respecto a la memoria de una VM, como por ejemplo pausar una VM o sacar una instantánea. Hyper-V es un sistema tremendamente protector que intenta a toda costa evitarte problemas especialmente los de estabilidad. Por esto Hyper-V reserva en el disco espacio para poder respaldar la memoria de la VM en disco y esto lo hace a través del fichero .BIN que en ocasiones ocupa tanto como la memoria asignada a la máquina virtual.

Entender la Memoria Dinámica

Cuando configuramos una máquina virtual hay dos formas de configurar su memoria, de forma estática o dinámica.

Configuración de memoria estática Cuando se configura una VM con memoria estática será necesario contar con toda esa memoria RAM libre en el host para poder arrancar la máquina virtual, si el host no tiene suficiente memoria RAM recibiremos un error que nos impedirá arrancar la VM en este host, pudiéndolo intentar en otro nodo del cluster si es que estamos en un cluster. De esta forma si configuramos todas las VM de un host con memoria estática la suma de la cantidad de memoria RAM de todas las VM más la memoria RAM no paginada usada por el HOST nunca podrá superar la RAM total del HOST.

Configuración de memoria dinámica

Normalmente los servidores o escritorios virtualizados no usan el 100% de la memoria asignada durante todo el tiempo, de hecho a ninguno nos gusta que ninguna de nuestras maquinas este al 90% de uso de memoria de forma constante. Hyper-V a través de la memoria dinámica nos permite aprovechar de forma inteligente la memoria no usada en las máquinas virtuales redistribuyendo esta memoria a las máquinas virtuales que la necesitan dentro del host.

Lo mejor de este sistema es que no afecta al rendimiento de forma perceptible, no entraña riesgos y no te requiere de ningún cambio de configuración en el sistema operativo de la VM para aprovechar todo su potencial. Podéis usar DM en servidores Windows Server 2008 R2 SP1 con Hyper-V o con la versión gratuita de Hyper-V; Hyper-V Server 2008 R2 SP1 y por supuesto en las versiones Windows 2012.

Las maquinas virtuales en las que activéis DM pueden ser Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2, tanto en 32 como en 64-bit. Y en la parte cliente Windows 7 en versión Enterprise y Ultimate en 32 y 64-bit, Windows 8 y 8.1.

Cosas importantes sobre la DM Hyper-V nunca paginara para crear RAM de donde no hay por lo que nunca tendréis problemas de rendimiento.

Cuando configuramos una VM con memoria dinámica indicamos 3 parámetros iniciales:

La memoria de arranque será la cantidad de memoria que la VM reclamara al HOST para arrancar y una vez la VM arranque estará completamente bloqueada para su uso. Hay dos formas de tomar la decisión de cuanta memoria asignar como memoria de arranque:

1.- Usar la tabla de memoria mínima necesaria por sistema operativo de acuerdo a fabricante.

2.- Desde mi punto de vista es mejor tomar la decisión basándonos en los datos de la monitorización, si sabemos que un servidor emplea habitualmente 2 GB no tiene sentido configurarlo con una memoria mínima de 512 MB, será mejor configurar una memoria mínima cercana al uso real.

Creo que esto nos permite un mejor y más realista dimensionamiento de los sistemas a la vez que evita al host operaciones innecesarias.

El siguiente parámetro a configurar es la memoria máxima, si bien en algunos sitios se ha leído que lo mejor es configurar la memoria máxima al máximo permitido por Hyper-V (64GB) o bien al máximo permitido por el sistema operativo de la VM si es menos de 64GB, tenemos que configurar un valor que consideramos apropiado a la carga que existe dentro de la VM y al coste que queramos repercutir a ese servicio.

El siguiente parámetro es el buffer, podemos entender esta parámetro fácilmente viéndolo como el que especifica a Hyper-V que cantidad de memoria tiene que darle de una sola vez a la VM cada vez que es necesario. Si configuramos el buffer a un 10% y una VM que tiene ocupados 1GB requiere más RAM, Hyper-V tratara de darle 100MB si están disponibles bien como memoria libre en el host o bien como memoria que puede liberarse por falta de uso en otras VMs con DM.

Si ponemos el buffer a un valor muy bajo se le entregara memoria a la VM en bloques pequeños por lo que la VM no tendera a tener mucha memoria libre, sin embargo un buffer mayor dejara holgura en la VM lo que puede ser beneficioso para algunas cargas que usan caches en RAM. Hyper-V atiende una solicitud de memoria de forma activa e inmediata en cuanto una VM lo solicita.

¿Cómo añade y quita memoria Hyper-V?

Gracias los componentes de integración (IC) que sabéis que tenéis que instalar en todas las VM que ponéis en Hyper-V por eso cuando actualizáis vuestros Hyper-V 2012 a Hyper-V 2012 R2 tenéis que actualizar siempre los IC de todas las VM para que puedan usar DM y el resto de componentes de integración.

Dentro de los IC de la VM hay un elemento que se encarga de comunicar a Hyper-V la presión de memoria que hay dentro de la VM, a este componente le llamamos “Dynamic Memory VSC” donde VSC significa Virtual Service Consumer.

Hyper-V tiene otro componente análogo llamado “Dynamic Memory VSP” donde VSP significa Virtual Service Provider este componente se encarga de escuchar la información de los VSC sobre la presión de memoria dentro de las VMs.

Finalmente Hyper-V tiene otro componente denominado “Memory Balancer” este componente se encarga de seguir la presión de memoria de todas las VMs con la información que le pasa el VSC y si es necesario y se puede reclamar la memoria no usada y también asigna memoria a las maquinas que lo necesiten.

Al añadir memoria se usa una funcionalidad que aportan los IC para añadir memoria en caliente lo que dispara el sistema de Plug and play para detectar la nueva memoria dentro del sistema operativo de la VM. DM funciona en sistemas operativos que no soportan de serie la funcionalidad de añadir memoria en caliente, esto es gracias a los IC.

Quitar memoria es un poco más difícil de entender, principalmente porque DM en realidad si lo vemos desde el punto de vista del sistema operativo de la VM nunca quita la memoria aunque en realidad la memoria física ya no está disponible para la VM. La DM en Hyper-V a la hora de quitar memoria usa una técnica denominada “balloning” o balón de memoria.

Cuando Hyper-V decide quitarle memoria a una VM por que no la usa esta memoria libre se prepara dentro de la VM y entonces gracias a un driver introducido por los IC Hyper-V hincha el balón de memoria dentro de la VM usando memoria no paginada, este balón indica al sistema operativo que esa memoria está siendo usada por el driver de forma que el sistema operativo ya no la usa para nada mas e Hyper-V puede por detrás retirar esa memoria física y asignársela a otra VM. Si usáis la herramienta rammap de sysinternals veréis lo bien que se ve como el driver bloquea la memoria.

La reclamación de la memoria no se realiza inmediatamente en cuanto la VM no la necesita salvo que otras VMs estén reclamando esa memoria y no haya más memoria libre en el sistema. Con el fin de optimizar el proceso y evitar esperas, Hyper-V recolecta la memoria libre cada 5 minutos. Otro parámetro que se puede configurar es la prioridad o peso que tendrá esta VM respecto a otras a la hora de reclamar memoria.

Presión de memoria y banda de presión

Para entender cuando una VM pide memoria tenemos que entender el concepto de presión de memoria Expresamos la presión de memoria como un %, este porcentaje se calcula dividiendo el valor de “current commit charge” por el valor de la memoria física, el porcentaje restante hasta el total de la memoria RAM física que ve la VM es el valor que llamamos “free buffer”

Cuando la presión es superior al 100% la VM estará paginando mucho y el “free buffer” será negativo.

Hyper-V ve la presión de memoria de la VM dentro del contexto de lo que denominamos banda de presión, esta banda tiene unas marcas de agua que establecen la presión mínima y máxima dentro de la VM, los datos de presión mínima y máxima se establecen en base a la información histórica de presión de memoria dentro de la VM. Si la presión actual se mantiene entre el mínimo y el máximo la memoria ni se quitara ni pondrá. La memoria se quita cuando la presión de memoria está por debajo de la presión mínima y se pide memoria cuando se excede la presión máxima.

Para que la DM funcione adecuadamente es necesario que la máquina virtual tenga bien configurada la paginación, si el fichero de paginación no es suficientemente grande Hyper-V no podrá añadir más memoria a la VM. Un ejemplo: una VM tiene en este momento 2GB asignado, está usando 1950MB y un proceso pide 100MB, lo primero que es necesario es que el sistema operativo dentro de la VM le de esos 100MB y para eso tendrá que paginar los 50 que faltan, justo después Hyper-V detectará la condición y le añadirá memoria a la VM, pero si no hay espacio en el fichero de paginación no será posible todo esto.

Otra cosa a tener en cuenta es que el sistema operativo dentro de la VM si está configurado para establecer dinámicamente el tamaño del fichero de paginación lo hará en función de la cifra de RAM que configuramos como memoria de arranque, esto implica que si queremos que dentro de una VM se pueda ejecutar un volcado de memoria completo será necesario configurar el tamaño del fichero de paginación manualmente al tamaño máximo de memoria que pueda tener la VM.

Es frecuente preguntarnos si debemos usar o no la DM en nuestras VMs, la respuesta seria que si en la gran mayoría de los casos, solo evitaremos su uso en aquellas VMs que tengan cargas donde el fabricante explícitamente no soporte este tipo de tecnológicas o donde no tengan sentido por ser cargas como bases de datos que tienden a usar toda la RAM disponible como cache de datos.

Hay un último aspecto que comentar sobre la memoria dinámica y es que el fichero .BIN puede crecer al incrementarse la cantidad de memoria debido a una operación de adición de memoria. Si no hay espacio para que el .BIN crezca no se podrá añadir más memoria http://support.microsoft.com/kb/2504962

Monitorizar la memoria

Básicamente tenemos dos grupos de contadores, los contadores del balanceador de memoria que nos hablan de la memoria que el host tiene disponible y de las operaciones de añadir y quitar memoria y por otra parte los contadores relativos a cada VM que nos hablan de la memoria que se quita y se pone y de la presión de memoria que experimenta la VM.

Para terminar

Mientras que puede parecer que la memoria es un concepto muy sencillo, hay muchos detalles interesantes de entender para poder implementar si queremos exprimir hyper-v 2.0 y 3.0 en nuestros entornos.

Para aquellos que estemos en fase de migración de nuestros DC y DA, es muy recomendable elevar los niveles funcionales del bosque y dominio a un modo nativo, con independencia de los sistemas que corran en nuestro dominio si lo pensamos hacer a modo nativo 2012. En el caso de Windows Server 2012 requiere un nivel funcional de bosque de Windows Server 2003. Es decir, que para poder agregar un controlador de dominio que ejecuta Windows Server 2012 en un bosque de Active Directory ya existente, el nivel funcional del bosque debe ser Windows Server 2003 o superior. Esto significa que los controladores de dominio que ejecutan Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 pueden funcionar en el mismo bosque, pero los controladores de dominio que ejecutan Windows 2000 Server no son compatibles y bloquearán la instalación de un controlador de dominio que ejecute Windows Server 2012 y si el bosque contiene controladores de dominio que ejecutan Windows Server 2003 o posterior, pero el nivel funcional de dicho bosque sigue siendo Windows 2000, la instalación se bloqueará igualmente.

El nuevo nivel funcional de dominio de Windows Server 2012 permite un nueva característica: la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos La directiva de plantillas administrativas KDC tiene dos configuraciones (proporcionar siempre notificaciones y error de solicitudes de autenticación sin blindar) que requieren el nivel funcional de dominio de Windows Server 2012.

El nivel funcional del bosque de Windows Server 2012 no proporciona características nuevas, pero asegura que todo dominio nuevo creado en el bosque funcione automáticamente en el nivel funcional de dominio de Windows Server 2012. El nivel funcional del dominio Windows Server 2012 no proporciona otras características nuevas además de la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos. No obstante, garantiza que cualquier controlador de dominio que se encuentre en el dominio ejecute Windows Server 2012.

Después de establecer el nivel funcional del bosque en un determinado valor, no se puede revertir o bajar el nivel funcional del bosque, salvo en las siguientes excepciones: cuando eleve el nivel funcional del bosque a Windows Server 2012, puede bajarlo a Windows Server 2008 R2. Si la papelera de reciclaje de Active Directory no está habilitada, también puede bajar el nivel funcional del bosque de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008 o de Windows Server 2008 R2 de vuelta a Windows Server 2008. Si el nivel funcional del bosque está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Después de establecer el nivel funcional del dominio en un determinado valor, no se puede revertir o bajar el nivel funcional del dominio, salvo en las siguientes excepciones: cuando eleve el nivel funcional del dominio a Windows Server 2008 R2 o Windows Server 2012 y si el nivel funcional del bosque es Windows Server 2008 o inferior, tiene la opción de revertir el nivel funcional del dominio a Windows Server 2008 o Windows Server 2008 R2. Solo se puede bajar el nivel funcional del dominio de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008, o de Windows Server 2008 R2 a Windows Server 2008. Si el nivel funcional del dominio está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Más allá de los niveles funcionales, un controlador de dominio que ejecuta Windows Server 2012 proporciona características adicionales que no están disponibles en un controlador de dominio que ejecuta una versión anterior de Windows Server. Por ejemplo, un controlador de dominio que ejecuta Windows Server 2012 puede usarse para la clonación del controlador de dominio virtual, mientras que un controlador de dominio que ejecuta una versión anterior de Windows Server no puede hacerlo. Pero la clonación de controladores de dominio virtuales y las medidas de seguridad de controladores de dominio virtuales en Windows Server 2012 no tienen ningún requisito de nivel funcional.

Los Eventos 5004 y 5014 en entornos de replica DFSR, son eventos típicos de falta de comunicación con otro miembro DFSR.

Si nuestra topología de red NO emplea IPV6, es muy recomendable desmarcar de las tarjetas de red, todo lo alusivo a TCPIPV6

http://social.technet.microsoft.com/Forums/windowsserver/en-US/d27bd902-034e-4230-9516-0ede42308193/event-5014-dfsr-error1726

Pero también es muy necesario deshabilitarlo del registro mediante la creación/modificación de las siguientes claves de registro;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value =DisableTaskOffload
Type = DWORD
Data = 1

Value =EnableTCPChimney
Type = DWORD
Data = 0

Value =EnableTCPA
Type = DWORD
Data = 0

Value =EnableRSS
Type = DWORD
Data = 0

Disable TCPIPV6
http://support.microsoft.com/kb/929852

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents to change the DisabledComponents entry – 0xffffffff

Finalmente desde línea de comandos ejecutemos los siguientes comandos netsh;

netsh int tcp set global RSS=Disabled
netsh int tcp set global chimney=Disabled
netsh int tcp set global autotuninglevel=Disabled
netsh int tcp set global congestionprovider=None
netsh int ip set global taskoffload=Disabled
netsh int tcp set global timestamps=Disabled
netsh int tcp show global

Cuando Migramos nuestra infraestructura o instalamos un Domain Controller, por defecto se replica el recurso “sysvol” con FRS, pero como es sabido a partir de ADDS 2008, sysvol tiene su replicación como DFRS, con muchas ventajas. Como decía, por defecto la replica de sysvol es mediante FRS, si queremos migrar la réplica a DFSR, tenemos que realizar unos pasos más para poder migrar este tipo de replicación a DFSR, estos pasos los tenemos que realizar por cada dominio de nuestro Forest, es decir que si tenemos mas de un dominio, tenemos que repetir estos pasos de migración en cada dominio que terminemos de migrar a 2008R2 ó 2012, los pasos son;

Prerrequisitos de Migración

1. Verificar que la replicación de AD es correcta en todos los Domain Controllers de la infraestructura.

2. Realizar el proceso de Domain Functional Level a “Windows Server 2008″ , “Windows Server 2008 R2″ ó «Windows Server 2012», según la versión que estemos implementando.

3. Verificar que el directorio SYSVOL existe en todos los Domain Controllers y el mismo esta replicando mediante FRS.

4. Backup del directorio SYSVOL.

5. Chequear que el servicio “DFS Replication Service” este instalado y corriendo con la configuración en “Automático”, dicho servicio este corriendo en todos los Domain Controllers del dominio.

Tipos de estados en el proceso de migración

Global Migration State – A complete process

Local Migration State – Process on each DC to achieve the Global Migration State

Estados Estables / Estados Globales de Migración

STATE 0 START
STATE 1 PREPARED
STATE 2 REDIRECTED
STATE 3 ELIMINATED

Estados de Transición / Estados Locales de Migración

STATE 4 Preparing
STATE 5 Waiting for initial sync to complete
STATE 6 Redirecting STATE 7 Eliminating
STATE 8 Undo redirecting
STATE 9 Undo preparing

Migracion: 0-4-5-1-6-2-7-3
Vuelta atras: 2-8-1-9-0

Cuando el estado de migración pasa a estar en estado 3, ya no hay posibilidad de volver atrás ni revertir la situación a un estado anterior, con lo cual, correr el comando que para a un estado “3″ tenemos que estar seguros que queremos para nuestra infraestructura, utilizar DFSR para replicación de nuestro SYSVOL.

Comandos de Migración

1. DfsrMig /CreateGlobalObjects

Este comando crear los “global Object” o configuración en Active Directory, para comenzar a utilizar DFSR como servicio de Replicación.

2. DfsrMig /SetGlobalState

Bajo este comando, se agrega al mismo el tipo de estado al que se quiere pasar según siguientes líneas:

0 (‘START’ state)
1 (‘PREPARED’ state)
2 (‘REDIRECTED’ state)
3 (‘ELIMINATED’ state)

3. DfsrMig /GetGlobalState

Nos detalla en qué estado Global está el proceso de migración, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

4. DfsrMig /GetMigrationState

Nos detalla en qué estado de Migración están todos los Domain Controllers, detallando cada uno y el estado del mismo, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

A continuación, los resultados y los comandos que tenemos que ir ejecutando serían estos;

Iniciar la migracion:
DFSRMig /CreateGlobalObjects
Create the ReplicationGroup, Content object, ContentSet, and Topology objects

msDFSR-GlobalSettings object under System
msDFSR-ReplicationGroup object under “msDFSR-GlobalSettings”
msDFSR-Content under
msDFSR-ReplicationGroup
msDFSR-ContentSet object under
msDFSR-Content objecte
msDFSR-Topology object under
msDFSR-ReplicationGroup object Sets GlobalState to 0

Preparar estado:

DfsrMig /SetGlobalState 1

The DFS Replication service creates the SYSVOL_DFSR folder

ROBOCOPY copies the contents of SYSVOLdomain to the location SYSVOL_DFSRdomain

Local Active Directory Objects are created. These are ‘Member’, ‘LocalSettings’, ‘Subscriber’, and ‘Subscription The migration local state is set to 5 (MIG_STATE_LOCAL_WAITING_FOR_SYNC) When DFS Replication completes Initial Sync, the Local State is set to 1 (’PREPARED’). Confirm that all domain controllers are in the ‘PREPARED’ state DfsrMig /GetMigrationState

Pasar a estado de “Redirección”

DfsrMig /SetGlobalState 2

The goal of this state is to move the live SYSVOL share from the old SYSVOL folder that NTFRS is replicating to the new SYSVOL folder that the DFS Replication service is replicating. From this point onwards, SYSVOL replication will depend on DFS Replication service Change the SYSVOL patyh in the registry to point to the new location Verify that DFS Replication global migration state is set to ‘REDIRECTED’ DfsrMig /GetGlobalState Confirm that all domain controllers are in ‘REDIRECTED’ state DfsrMig /GetMigrationState

Pasar a estado de “Eliminación”

DfsrMig /SetGlobalState 3

The goal of this state is to delete the NTFRS SYSVOL replica set and delete the old SYSVOL folder Deletes the NTFRS SYSVOL Active Directory configuration objects named ‘Subscriptions’ and ‘Settings’ Verify that the DFS Replication global migration state is set to eliminated DfsrMig /GetGlobalState

Una vez finalizado este proceso de migración, cuyo tiempo depende la cantidad de Domain Controllers que tengamos en nuestra infraestructura y la latencia de los mismos, podemos verificarlo desde nuestro Active Directory. CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=Root1,DC=es,DC=inet donde tendremos que ver, el listado de todos nuestros Domain Controllers los cuales ya estarán usando DFSR como replicación de SYSVOL.

Como ya expusimos en otro post de éste blog, Windows Server 2008 R2 soporta y admite configuración Teaming en las NIC de nuestro hardware, con el siempre condicionante de que dependía de los fabricantes de NIC el desarrollo del software de Team.

En Windows Server 2012, el Team es ahora nativo del sistema operativo, independientemente del fabricante que se encuentre en nuestro CPD.

Hay tres grandes aspectos que destacan en la solución de Team.

• Poder asociar Team NICs para el tráfico de red normal o para el entorno virtual.
• Poder trabajar en Team con NICs de diferentes fabricantes.
• Poder formar Team de hasta 32 tarjetas de red en un solo equipo.

Veamos la interfaz de usuario y las opciones que tenemos disponibles.

En  ésta imagen muestro una configuración de NIC Teaming nativa a Windows Server 2012 y quería resaltar algunos de los puntos de interes de éste nuevo concepto de Team.

Evidentemente necesitamos al menos dos tarjetas de red para crear un equipo y notar que podemos trabajar en un servidor con un máximo de 32 NICs. La creación de un grupo de NIC es muy fácil y personalmente me gusta porque el proceso de instalación respeta los nombres que se colocan en las NICs.

Una vez creado el grupo de NIC, al que he llamado Team 1, podemos seleccionar las NICs que formarán parte de ese Team.

Si ampliamos las propiedades adicionales podremos realizar cambios de configuración en base a la parametrización de red individual que necesitemos y debemos tener opciones para configurar nuestro Team más alla de conformarnos con una configuración estática del tipo; «One Size Fits All».

Como vemos en la imagen de arriba, as propiedades del Team, proporcionan una lista de todas las tarjetas disponibles en el servidor. Aquí podremos elegir qué tarjetas de red deseamos añadir a nuestra configuración de Team.

El nombre que he dado a mis tarjetas de red es uno muy al uso en laboratorios como el mío, «Test NIC 1,» Test NIC 2, y «Test NIC 3» y el Team se llama «Team 1».

A partir de aquí se presentan los detalles adicionales que se pueden configurar para nuestro Team, lo cual nos va a permitir ser muy específicos acerca de cómo el Team, equilibra la carga y se conecta a la red.

MODO TEAMING

Como podemos ver en la imagen el Team se puede configurar para trabajar en Team estático, en modo switch independiente, o LACP (Link Aggregation Control Protocol).

Static Teaming requiere configuración tanto en el switch como en el servidor para identificar los vínculos que formaran el Team. Este modelo de Team nos ofrece un switch dependiente del Teaming que formemos con nuestras NICs.

Switch Independent El modo independiente nos permite distribuir las tarjetas de red en el Team a través de múltiples conmutadores de red ó (Network Switches) en nuestro entorno.

LACP proporciona (Link Aggregation) que podríamos traducir como, la agregación de enlace y además permite la expansión y la reducción del grupo de NIC. Este es un modo de swith ó conmutación independiente del NIC Teaming.
MODO LOAD BALANCING:

Las opciones son o bien Address Hash o Hyper-V Port.

Address Hash es la forma de configurar el Team para el tráfico NLB (network load balancing) entre las NIC que forman el Team.

Hyper-V Port balancea la carga para equilibrar el tráfico que pasa por la VM.

Con Hyper-V Port, la buena noticia es que, las transacciones de cada VM tienen una tarjeta de red por separado, con la desventaja de que que cada máquina virtual sólo puede realizar transacciones a través de una tarjeta de red única. Si tienes varias tarjetas de red virtuales en la máquina virtual y se forma un team para ellas, el Hyper-V Port puede ser la mejor opción.

Para la mayoría de las configuraciones, es muy posible que la Address Hash sea la mejor opción para que la máquina virtual pueda acceder a la red, aún en el caso de que la tarjeta de red de la máquina virtual está dando fallo. Recordemos que con la tecnología Hyper-V Port, un fallo de la NIC de la máquina virtual está causando una interrupción de la comunicación entre, la máquina virtual y la red. Con Address Hash no tendremos éste problema.

STANDBY ADAPTER Ó ADAPTADOR EN ESPERA:

Como bien define su nombre, ésta solución nos permite definir un adaptador de reserva para el equipo. Hay que tener en cuenta que sólo se puede definir un adaptador de espera y además se puede asegurar que el ancho de banda asociado estará disponible incluso si una tarjeta de red de nuestro Team falla.

Fijémonos en las conexiones de red que se nos han formado. Team 1 es una asociación de NICs y notar también que las NIC agrupadas son de diferentes fabricantes.

Se puede descargar, con sus 256 páginas, desde;

• Introducing Windows Server 2012

También hay un enlace en la página principal de Microsoft Server and Cloud Platform, muy renovada en aspecto para la ocasión, y donde podemos encontrar documentación y videos con demos de las nuevas funcionalidades que incluye la nueva versión de Windows Server.