C'è una differenza nel consumo di larghezza di banda tra un RODC e un RWDC?


8

La mia organizzazione ha distribuito RODC del 2008 su più piattaforme marittime. L'idea era di estendere il nostro dominio a terra sulle nostre navi per controllare meglio le politiche di sicurezza. I controller di dominio di sola lettura sono stati selezionati partendo dal presupposto che avrebbero consumato meno larghezza di banda. C'erano anche problemi di sicurezza, ma erano secondari.

La connettività Internet in mare è fornita da un collegamento satellitare molto costoso. Le velocità vanno da lente a inesistenti. La gestione di modifiche di utenti, computer, gruppi e autorizzazioni e aggiornamenti degli oggetti Criteri di gruppo è estremamente lenta.

Sto cominciando a credere che abbiamo sviluppato una visione a tunnel per quanto riguarda i controller di dominio di sola lettura e che disporre di un controller di dominio scrivibile potrebbe essere un'alternativa migliore. Sto pensando un RWDC e un RODC per nave per ridondanza. È una piccola base di utenti, ma è fondamentale avere ridondanza.

C'è molto di più in questo, ma non posso riassumere con alcuna brevità. Sono curioso di sapere se qualcuno ha mai provato la differenza nel consumo di larghezza di banda tra un RODC e un RWDC? Sostituire uno dei controller di dominio di sola lettura con un RWDC aumenterebbe significativamente il consumo di larghezza di banda? Vorrei reindirizzare il controller di dominio di sola lettura per replicare dal RWDC. Ciò significherebbe un controller di dominio che si ricollega a terra.

Dato che le cose siedono in questo momento, possono essere necessarie ore per fare cose che normalmente richiederebbero minuti. Avere amministratori a bordo delle navi che lavorano su un RWDC renderebbe la vita molto migliore. Il timore è che chiacchiere RWDC riempirebbero la pipa.

Quindi, qualcuno ha mai provato la differenza?

Risposte:


7

No, non ho mai testato la differenza nei consumi di larghezza di banda tra un RODC e un RWDC, ma lasciatemi comunque offrire alcune osservazioni:

Se la sicurezza è la "minima preoccupazione" nelle vostre considerazioni e la connettività di rete è fondamentale, le RODC potrebbero in realtà essere una scelta davvero sbagliata.

Ricorda che, dal momento che è di sola lettura , qualsiasi operazione che richiede l'aggiornamento dei dati nella directory (inclusi blocchi degli account, errori di autenticazione ecc.) Avrà esito positivo solo indirizzando nuovamente un controller di dominio scrivibile e consumando la larghezza di banda bidirezionale (originate write offsite + replicare su RODC).

Probabilmente stai meglio con 2 RWDC e un sito dedicato per nave / piattaforma.

Assicurarsi di configurare il collegamento del sito tra i siti off-shore e l'hub on-shore con le seguenti caratteristiche:

  • Configurare una pianificazione della replica che consenta la replica solo durante le ore del giorno / settimana / mese in cui si presume che la velocità di connessione sia migliore (e prezzi di accesso bassi bassi, se fluttuanti)
  • Configurare un intervallo di replica abbastanza elevato, per evitare che la testa di ponte del sito esegua il polling ogni 15 minuti durante la sua pianificazione
  • Abilita la sincronizzazione bidirezionale (nota anche come "replica reciproca" ) per riutilizzare la stessa connessione sottostante in modo bidirezionale
  • Cambia il controller di dominio utilizzato in GPMC con uno nel sito off-shore locale, quando lavori in locale (altrimenti, per impostazione predefinita, è l'emulatore PDC, si spera si trovi nel tuo sito hub)
  • Lascia le impostazioni di replica all'interno del sito come predefinite (notifica di modifica ritardata di 15 secondi), per evitare la perdita di dati in caso di perdita di un controller di dominio in un sito off-shore

1
Conterrei le operazioni che usano RSO (replicare un singolo oggetto), come aggiornamenti dinamici DNS, sincronizzazione password ecc. Quindi penso che i controller di dominio di sola lettura in generale causino più traffico.
iPath,

@iPath Sicuramente, l'elenco nella mia risposta non è esaustivo. RSO o sincronizzazione delle partizioni, non importa. Qualsiasi operazione di scrittura iniziata da un client sulla piattaforma sarà addebitato un out di connessione e, successivamente, di nuovo per la replica sul dominio di sola lettura
Mathias R. Jessen

2

I controller di dominio di sola lettura sono un'opzione TERRIBILE per le località remote con una rete pericolosa.

Inoltre, i controller di dominio di sola lettura NON devono essere distribuiti in un sito con RWDC.

L'unico motivo per cui un controller di dominio di sola lettura consumerebbe meno larghezza di banda è dovuto al fatto che nessuna replica in uscita verrebbe replicata (nessun partner di replica in uscita).

Non è possibile modificare / gestire oggetti utilizzando un controller di dominio di sola lettura con applicazioni come Utenti e computer AD o Console di gestione dei criteri di gruppo, che devono connettersi a un controller di dominio scrivibile. Non sorprende, questo è lento per te a causa della necessità di connetterti a un RWDC su un collegamento WAN lento.


I controller di dominio di sola lettura sono un'opzione terribile se è necessario eseguire l'amministrazione (ad esempio operazioni scrivibili). I controller di dominio di sola lettura sono una buona opzione in comune.
iPath,

I controller di dominio di sola lettura sono una buona opzione se hai il business case per loro e SE hai una buona connettività di rete. Se non si dispone di una buona connettività di rete, ci saranno ulteriori problemi. Un modo con bandiera rossa per sapere se hanno il business case è se vogliono mettere un RWDC nello stesso sito. In tal caso, non hanno MAI avuto un caso commerciale legittimo per un RODC. Ho visto le organizzazioni implementare RODC nel modo sbagliato così spesso è tragico, incluso inserire Utenti Autenticati o Utenti di Dominio nella Politica di replica password o nel Gruppo di replica password RODC consentito.
Greg Askew il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.