Y a-t-il une différence de consommation de bande passante entre un RODC et un RWDC?


8

Mon organisation a déployé des contrôleurs de domaine en lecture seule 2008 sur plusieurs plates-formes maritimes. L'idée était d'étendre notre domaine à terre sur nos navires pour mieux contrôler les politiques de sécurité. Les contrôleurs de domaine en lecture seule ont été sélectionnés en supposant qu'ils consommeraient moins de bande passante. Il y avait aussi des problèmes de sécurité, mais ils étaient secondaires.

La connectivité Internet en mer est assurée par une liaison satellite très coûteuse. Les vitesses varient de lentes à inexistantes. La gestion des utilisateurs, des ordinateurs, des modifications de groupes et d'autorisations et des mises à jour des objets de stratégie de groupe est extrêmement lente.

Je commence à croire que nous avons développé une vision tunnel en ce qui concerne les contrôleurs de domaine en lecture seule et qu'avoir un contrôleur de domaine accessible en écriture pourrait être une meilleure alternative. Je pense à un RWDC et un RODC par navire pour la redondance. Il s'agit d'une petite base d'utilisateurs, mais il est essentiel d'avoir une redondance.

Il y a beaucoup plus à cela, mais je ne peux pas le résumer avec brièveté. Je suis curieux de savoir si quelqu'un a déjà testé la différence de consommation de bande passante entre un RODC et un RWDC? Le remplacement d'un des RODC par un RWDC augmenterait-il considérablement la consommation de bande passante? Je redirigerais le RODC pour répliquer à partir du RWDC. Cela signifierait un contrôleur de domaine se connectant de nouveau au rivage.

Dans l'état actuel des choses, cela peut prendre des heures pour faire des choses qui prennent normalement quelques minutes. Avoir des administrateurs à bord des navires travaillant sur un RWDC améliorerait la vie. La crainte est que le bavardage de RWDC remplisse le tuyau.

Alors, quelqu'un a-t-il déjà testé la différence?

Réponses:


7

Non, je n'ai jamais testé la différence de consommation de bande passante entre un RODC et un RWDC, mais permettez-moi néanmoins de faire quelques observations:

Si la sécurité est le "moindre souci" dans vos considérations et que la connectivité réseau est primordiale, les RODC pourraient en fait être un très mauvais choix.

N'oubliez pas que, comme il est en lecture seule , toute opération qui nécessite la mise à jour des données dans l'annuaire (y compris les verrouillages de compte, les échecs d'authentification, etc.) ne réussira qu'en ciblant un contrôleur de domaine accessible en écriture et en consommant de la bande passante dans les deux sens (origine écriture hors site + répliquer sur RODC).

Vous êtes probablement mieux avec 2 RWDC et un site dédié par navire / plate-forme.

Assurez-vous de configurer le lien de site entre les sites off-shore et le hub on-shore avec les caractéristiques suivantes:

  • Configurer un calendrier de réplication qui autorise uniquement la réplication pendant les périodes de la journée / de la semaine / du mois où la vitesse de connexion est supposée être la meilleure (et les prix des appels bas, s'ils fluctuent)
  • Configurer un intervalle de réplication assez élevé pour empêcher la tête de pont du site d'interroger toutes les 15 minutes au cours de sa planification
  • Activer la synchronisation bidirectionnelle (également appelée «réplication réciproque» ) pour réutiliser la même connexion sous-jacente dans les deux sens
  • Remplacez le contrôleur de domaine utilisé dans GPMC par un sur le site off-shore local, lorsque vous travaillez sur site (sinon il est par défaut l'émulateur PDC, si tout va bien situé sur votre site hub)
  • Laissez les paramètres de réplication intra-site par défaut (notification de modification différée de 15 secondes), pour éviter la perte de données en cas de perte d'un contrôleur de domaine sur un site offshore

1
Je compterais les opérations qui utilisent RSO (répliquer un seul objet), comme les mises à jour dynamiques DNS, la synchronisation des mots de passe, etc. Je pense donc que les RODC en général génèrent plus de trafic.
iPath

@iPath Certainement, la liste dans ma réponse n'est pas exhaustive. RSO ou synchronisation de partition, n'a pas vraiment d'importance. Toute opération d'écriture initiée par un client sur la plate - forme sera encourra une connexion out et ensuite de retour pour la réplication sur le RODC
R. Mathias Jessen

2

Les RODC sont une option TERRIBLE pour les sites distants avec un réseau douteux.

De plus, les contrôleurs de domaine en lecture seule ne doivent PAS être déployés sur un site disposant d'un RWDC.

La seule raison pour laquelle un contrôleur de domaine en lecture seule consommerait moins de bande passante est qu'aucune modification sortante ne serait répliquée (aucun partenaire de réplication sortante).

Vous ne pouvez pas modifier / gérer des objets à l'aide d'un contrôleur de domaine en lecture seule avec des applications telles que Utilisateurs et ordinateurs AD ou Console de gestion des stratégies de groupe, ils doivent se connecter à un contrôleur de domaine accessible en écriture. Sans surprise, cela est lent pour vous car vous devez vous connecter à un RWDC via une liaison WAN lente.


Les contrôleurs de domaine en lecture seule sont une option terrible si vous devez effectuer l'administration (c'est-à-dire des opérations accessibles en écriture). Les contrôleurs de domaine en lecture seule sont une bonne option en commun.
iPath

Les RODC sont une bonne option SI vous avez une analyse de rentabilisation pour eux, et SI vous avez une bonne connectivité réseau. Si vous n'avez pas une bonne connectivité réseau, il y aura des problèmes supplémentaires. Une façon de signaler si elles ont l'analyse de rentabilisation est de savoir si elles souhaitent placer un RWDC sur le même site. Dans l'affirmative, ils n'ont JAMAIS eu de justification commerciale légitime pour un contrôleur de domaine en lecture seule. J'ai vu des organisations implémenter le RODC dans le mauvais sens si souvent que c'est tragique, y compris en mettant des utilisateurs authentifiés ou des utilisateurs de domaine dans la stratégie de réplication de mot de passe ou le groupe de réplication de mot de passe RODC autorisé.
Greg Askew
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.