¿Hay alguna diferencia en el consumo de ancho de banda entre un RODC y un RWDC?

8

Mi organización ha implementado RODC 2008 en múltiples plataformas marítimas. La idea era extender nuestro dominio en tierra a nuestros barcos para controlar mejor las políticas de seguridad. Los RODC se seleccionaron asumiendo que consumirían menos ancho de banda. También hubo problemas de seguridad, pero estos fueron secundarios.

La conectividad a Internet en el mar es proporcionada por un enlace satelital muy costoso. Las velocidades varían de lentas a inexistentes. Administrar usuarios, computadoras, cambios de grupo y permisos y actualizaciones de GPO es extremadamente lento.

Estoy empezando a creer que hemos desarrollado una visión de túnel con respecto a los RODC y que tener un controlador de dominio grabable podría ser una mejor alternativa. Estoy pensando en un RWDC y un RODC por barco para redundancia. Es una pequeña base de usuarios, pero es fundamental tener redundancia.

Hay mucho más en esto, pero no puedo resumirlo con brevedad. Tengo curiosidad por saber si alguien ha probado alguna vez la diferencia en el consumo de ancho de banda entre un RODC y un RWDC. ¿Reemplazar uno de los RODC con un RWDC aumentaría significativamente el consumo de ancho de banda? Estaría redirigiendo el RODC para replicarlo desde el RWDC. Esto significaría que un controlador de dominio se conecta de nuevo a la costa.

Como las cosas se sientan ahora, puede tomar horas hacer cosas que normalmente tomarían minutos. Tener administradores a bordo de los barcos que trabajan en un RWDC mejoraría mucho la vida. El temor es que la charla RWDC llenaría la tubería.

Entonces, ¿alguien ha probado la diferencia?

active-directory replication rodc Dante M. DeAngelis
fuente

Respuestas:

7

No, nunca probé la diferencia en el consumo de ancho de banda entre un RODC y un RWDC, pero permítanme ofrecer algunas observaciones:

Si la seguridad es la "menor preocupación" en sus consideraciones y la conectividad de la red es primordial, los RODC podrían ser realmente una mala elección.

Recuerde que, dado que es de solo lectura , cualquier operación que requiera actualizar datos en el directorio (incluidos los bloqueos de cuentas, fallas de autenticación, etc.) solo tendrá éxito al reorientar un controlador de dominio grabable y consumir ancho de banda bidireccionalmente (originar escritura fuera del sitio + replicar en RODC).

Probablemente esté mejor con 2 RWDC y un sitio dedicado por embarcación / plataforma.

Asegúrese de configurar el enlace del sitio entre los sitios off-shore y el hub on-shore con las siguientes características:

  • Configure un cronograma de replicación que solo permita la replicación durante las horas del día / semana / mes donde se supone que la velocidad de conexión es la mejor (y los precios de acceso telefónico bajos, si fluctúan)
  • Configure un intervalo de replicación que sea bastante alto, para evitar que la cabeza de puente del sitio realice un sondeo cada 15 minutos durante su programación
  • Habilite la sincronización bidireccional (también conocida como "Replicación recíproca" ) para reutilizar la misma conexión subyacente bidireccionalmente
  • Cambie el controlador de dominio utilizado en GPMC a uno en el sitio off-shore local, cuando trabaje en las instalaciones (de lo contrario, el emulador PDC se encuentra de manera predeterminada en el sitio central)
  • Deje la configuración de replicación dentro del sitio como predeterminada (notificación de cambio demorado de 15 segundos), para evitar la pérdida de datos en caso de que pierda un DC en un sitio off-shore
Mathias R. Jessen
fuente
1
Contaría las operaciones que usan RSO (replicar un solo objeto), como actualizaciones dinámicas de DNS, sincronización de contraseña, etc. Así que creo que los RODC en general causan más tráfico.
iPath
@iPath Definitivamente, la lista en mi respuesta no es exhaustiva. RSO o sincronización de partición, realmente no importa. Cualquier operación de escritura iniciado por un cliente en la plataforma va a incurrir en una conexión de salida y, posteriormente, volver para la replicación en el RODC
Mathias R. Jessen
2

Los RODC son una opción TERRIBLE para ubicaciones remotas con una red poco fiable.

Además, los RODC NO deben implementarse en un sitio que tenga un RWDC.

La única razón por la que un RODC consumiría menos ancho de banda se debe a que no se replicarían cambios salientes (no hay socios de replicación salientes).

No puede editar / administrar objetos usando un RODC con aplicaciones como AD Users and Computers o Group Policy Management Console, necesitan conectarse a un controlador de dominio grabable. No es sorprendente que esto sea lento para usted debido a que necesita conectarse a un RWDC a través de un enlace WAN lento.

Greg Askew
fuente
Los RODC son una opción terrible si necesita realizar una administración (es decir, operaciones de escritura). Los RODC son una buena opción en común.
iPath
Los RODC son una buena opción SI tiene el caso comercial para ellos y SI tiene una buena conectividad de red. Si no tiene una buena conectividad de red, habrá problemas adicionales. Una forma de bandera roja para saber si tienen el caso comercial es si quieren poner un RWDC en el mismo sitio. Si es así, NUNCA tuvieron un caso comercial legítimo para un RODC. He visto que las organizaciones implementan los RODC de la manera incorrecta, por lo que a menudo es trágico, incluida la inclusión de Usuarios autenticados o Usuarios de dominio en la Política de replicación de contraseñas o el Grupo de replicación de contraseñas RODC permitido.
Greg Askew