Comunicaciones y Sistemas

Microsoft Windows Server – Migración DHCP Role – Parte II

Índice del contenido

En el siguiente post continuamos con la implementación del servicio de DHCP en nuestro entorno. Tal y como indicábamos en el post anterior, tras el proceso de migración, vamos a implementar un entorno de alta disponibilidad (failover) para nuestro servicio DHCP.

Esta funcionalidad la tenemos disponible desde la versión de Windows Server 2012 en adelante.

Tipos de implementaciones disponibles

Activo-Activo (Load balance): Nuestros dos nodos tendrán un papel activo en la asignación de direccionamiento IP en nuestra red, repartiendo la carga 50% entre ambos (este porcentaje es personalizable).

Activo-Pasivo (Host-Stand by): Uno de nuestros dos nodos, será identificado como maestro durante la implementación, teniendo un papel activo durante el desempeño de esta función. El nodo secundario quedará en un modo “espera”, el cual será activado en cualquier momento que nuestro nodo activo entre en un estado “down”, por un reinicio o apagado del mismo.

Configuración del rol

A continuación, indicamos los pasos necesarios para la configuración del rol:

Entorno

Disponemos de un servidor DHCP Windows Server 20120 R2 con un ámbito (o varios) en activo.

Hemos desplegado la característica en otro servidor (desde el mismo asistente para la integración de roles y características) y vamos a unificar ambos servicios en alta disponibilidad Activo-Activo.

Iniciamos el proceso de configuración del entorno de Failover para nuestro DHCP. En nuestro servidor en producción, hacemos clic derecho sobre IPv4 y localizamos la opción “Configure Failover”.

Iniciaremos un asistente de despliegue en el cual se nos solicitarán distintos parámetros según nuestras necesidades

Por defecto, al configurar el failover, se aplica sobre todos los ámbitos, aunque esto puede ser selectivo según las necesidades.

En el siguiente paso, se nos solicitará identificar el servidor “Partner” para establecer la relación con él. Se trata de la maquina sobre la que replicaremos nuestros ámbitos.

En este caso práctico, seleccionaremos la maquina dc2.it.lab

Confirmada la conectividad con nuestro “partner”, nos dirigirá al paso más interesante del proceso, donde configuraremos el comportamiento de la característica. Localizaremos los siguientes apartados:

  • Relationship Name: Nombre de la relación entre servidores. Nombre identificativo.
  • Maximum client Lead time: valor que establece cuanto tiempo ha de pasar hasta renovar una concesión de direccionamiento por parte de un nodo, sin negociar con el otro en caso de inactividad de cualquiera de las partes. También especifica el tiempo que aguantará un nodo sin su partner activo, antes de tomar la propiedad de un scope.
  • Mode: Tipo de failover a configurar.
  • State Swichover Interval: Desactivado por defecto. Este parámetro establece cuanto tiempo queda el servidor en inactivo sea marcado como “desconectado”. By default, este estado se ha de configurar de forma manual.
  • Enable Message Authentication (Shared Secret): Contraseña que se establece entre ambos servidores para su comunicación.

Los tipos de “failover” han sido identificados al iniciar este post.

En este caso práctico, aplicaremos una configuración activo-activo con 50% de carga por cada servidor.

Configuramos el “Shared Secret” y continuamos con el proceso. Finalizamos la configuración del failover.

Confirmamos que la configuración ha sido satisfactoria.

Comprobamos la disponibilidad de los ámbitos en ambos servidores.

Comprobamos vía mmc los ámbitos de ambos servidores, además de la configuración de la característica de Failover.

Información a tener en cuenta

  • En el caso de disponer de vLANS, no olvidéis configurar en vuestros switches la entrada para el registro “IP Helper Address”, sea de forma individual o en un pequeño pool, pues hemos de identificar de igual manera a este servidor DHCP y permitir al mismo desde a las distintas subredes disponibles en nuestro entorno.
  • Recordad tener autorizado el segundo servidor DHCP en vuestro entorno de AD.
  • En caso de tener atributos personalizados en nuestro ámbito, deberán de configurarse previamente en el servidor DHCP secundario (registros FTP, etc..), de caso contrario, durante el proceso de validación se obtendrá un error de sincronización.
Comparte

No es sólo un blog

Noticias y avances sobre
tecnología

Con la unión de Sothis y Nunsys conseguimos...
La integración de Microsoft Power Platform y SAP...
¿Cómo complementar el CRM para enfocar el hecho...
En una sociedad cada vez más digitalizada, la...
Evolucionar el concepto de CRM (Customer Relationship Management)...
¿Por qué automatizar los gastos de los empleados?...

¡Gracias!

Tu formulario se ha enviado correctamente-