Question Gestion d'un environnement Active Directory avec des milliers de sous-réseaux


La plupart d'entre nous savons qu'il est nécessaire de créer des objets de sous-réseau et de les associer aux objets de site de nos annuaires actifs. Cela permet de conserver les clients sur le site A en s’authentifiant auprès des contrôleurs de domaine du site A, en obtenant les références DFS correctes, etc.

Comment gérer cela dans un environnement avec des milliers de sous-réseaux? Littéralement, milliers de sous-réseaux en constante évolution, ajoutés et supprimés.

Idéalement, la réponse ne devrait pas être «embaucher 50 administrateurs».


5
2017-09-20 17:41


origine


Comment gérez-vous cela techniquement ou logistiquement? - joeqwerty
Cela ressemble à un travail pour Powershell et à la délégation d’une interface aux parties responsables. - Jeff Ferland
@joeqwerty - Sur le plan technique, elle est gérée avec une ancienne base de données CMDB qui s'appuie sur une intervention humaine manuelle pour maintenir son intégrité et sa cohérence, ce qui signifie que la base de données CMDB peut ou peut refléter avec exactitude la réalité à un moment donné. J'espère utiliser au moins quelque chose comme OpsWare pour introduire par programme des informations dans la CMDB. Dans un environnement si complexe, je cherche à en exclure les humains chaque fois que cela est possible. - Ryan Ries


Réponses:


Vous n'avez pas besoin de créer un nouveau sous-réseau pour chaque sous-réseau de couche 3 créé par les utilisateurs du réseau.. Au lieu de cela, créez des sous-réseaux correspondant aux allocations d'adresses IP pour l'ensemble du site.

Voici un exemple rapide.

Disons que vous avez deux sites. Appelons-les "New York" et "Mountain View". La totalité de l’allocation IP à New York est 10.187.128.0/22. Mountain View a 10.187.132.0/22, mais il a aussi quelques vieux objets crus en 10.244.0.0/16.

Les gars du réseau vont diviser toutes ces adresses en minuscules sous-réseaux de / 29, il y en aura des milliers, mais ils sont tous contenus dans ces blocs de super-réseau.

Dans AD, cependant, le site de New York n’a besoin que du sous-réseau défini et le site de Mountain View n’a besoin que des deux sous-réseaux définis. Ils couvrent toutes les adresses IP possibles dans leurs blocs respectifs.


7
2017-09-20 17:52



C'est une bonne réponse et me donne quelques idées. Mais si je vous disais que 10.187.50.0/26 était en Allemagne, 10.187.50.64/26 au Mexique, 10.187.50.128/26 au Canada, et ainsi de suite? - Ryan Ries
Ensuite, vous aurez probablement besoin de sites différents pour ceux-là aussi. - Michael Hampton♦
@RyanRies Si vous me l'aviez dit, je vous demanderais de redéfinir votre réseau. - pauska
@RyanRies Si vous avez dit cela, je vous dirais de m'envoyer un message. J'ai un tas d'anciens PA de 10 bases avec des antennes "pipe-bomb" qui ont été soudées à de longs poteaux en acier et des supports pour être accrochés au plafond d'un entrepôt. Ils sont très robustes et constituent un outil impressionnant et légèrement ironique pour convaincre les mauvais administrateurs réseau. Je serais honoré que vous en utilisiez un pour ces méritants. - HopelessN00b


En supposant que vous "ayez réellement besoin" de ces sous-réseaux et que vous ne puissiez pas le faire, comme le suggère @MichaleHampton dans son excellente réponse ...


Si vous n'aimez pas l'idée d'embaucher 50 administrateurs AD, vous frappez vos administrateurs de réseau avec l'objet le plus dur et le plus émoussé le plus proche jusqu'à ce qu'ils cessent de prendre des décisions de conception aussi terribles.

Vraiment, je peux penser à aucune justification terrestre pour des milliers de ["vrais"] sous-réseaux* Voir "note de bas de page"Au-delà de la curiosité de voir à quel point un laboratoire ou un environnement de test peut être perturbé, quiconque parvient même à approcher ce nombre de ["réels"] sous-réseaux constitue une société multinationale massive dotée d'une capitalisation boursière supérieure à le PIB de la plupart des pays, ou est un grand fournisseur de services Internet / hébergé / fournisseur de services Internet national / transnational. Et dans les deux cas, ils emploient littéralement des dizaines de personnes pour régler le problème.

Il est tout simplement impossible que vous soyez capable de gérer cela autrement. Embauchez des dizaines de personnes pour régler le problème ou modifiez la conception du réseau pour ... sucer moins ... et même être gérable à distance par moins d'un peloton d'administrateurs système.

Honnêtement, n'essaie même pas. Il comporte "échec", "épuisement" et "idée terrible". Essayer, c'est comme réarranger les chaises longues sur le Titanic après avoir heurté l'iceberg. Toutes les améliorations que vous pourrez réaliser seront bientôt éclipsées et annulées en coulant dans plusieurs milliers de pieds d’eau glacée. Vous passerez donc probablement mieux à vous allonger sur les chaises longues, à siroter un verre d’alcool et à fumer et à profiter des derniers instants. avant d'être englouti par une mort certaine. (Et je ne peux pas dire si je suis métaphorique ou pas, FWIW, je connais 3 types d'informatique qui ont eu une crise cardiaque avant 35 ans à cause de ce genre de folie.)

Et, bien sûr, si vous ne pouvez pas changer les mentalités de vos supérieurs ou de votre équipe réseau, eh bien, vous ne pouvez pas épouser une entreprise dans un pays de ma connaissance, votre meilleure option pourrait donc être de partir. Aucun travail ne vaut la peine d'avoir une crise cardiaque au début de votre trentaine.

*Note de bas de page:

Par "vrais" sous-réseaux, j'entends les sous-réseaux réellement utilisés en tant que tels. Je travaille dans des environnements de services hébergés avec des milliers de clients, où chaque client obtient un sous-réseau simple et plat qui n'est pas réellement géré ou modifié par le fournisseur de services hébergé, mais cela ne semble certainement pas être votre cas d'utilisation. Si c'est le cas, faites-le moi savoir et je pourrai ajuster ma réponse, car c'est assez facile à gérer avec une base de données * AMP (ou un produit de type * AMP).


4
2017-09-20 18:35





"Apprendre à écrire" est une bonne réponse. Vraisemblablement, quelqu'un fait ces choses avec un plan, qui est créé à l'avance? Travailler à partir de leur plan pour créer / modifier / etc ces sites et sous-réseaux dans AD en même temps.

Quelques réflexions supplémentaires - si cela évolue constamment, est-ce que cela inclut les bureaux des utilisateurs dans ces sous-réseaux? Si ce n'est pas le cas, vous n'avez même pas vraiment besoin de le faire. Si tel est le cas, quelqu'un gère-t-il déjà le changement constant d'adresses IP, d'étendues DHCP, etc.? Peut-être pourriez-vous leur déléguer.

Une autre idée à prendre en compte: si ces sous-réseaux ne se trouvent pas toujours sur des liaisons de réseau étendu (c’est-à-dire que les sous-réseaux qui pourraient être super-réseaux ensemble sont bien connectés aux connexions LAN à haut débit), il suffit de faire correspondre les sites et les sous-réseaux avec les super-réseaux. les choses au niveau du sous-réseau. (modifier - c'est la même chose que Michael Hampton dit dans sa réponse et lien.)


3
2017-09-20 17:54





En plus de la réponse fournie par Michael Hampton, j'aimerais ajouter ce qui suit:

Il existe des scénarios dans lesquels vous devez réfléchir à la manière dont vous souhaitez que l'authentification et l'accès aux ressources fonctionnent lorsque vous configurez ADS & S, puis vous devez configurer ADS & S en conséquence. À titre d’exemple, supposons que j’ai trois emplacements géographiquement dispersés:

Bureau principal: Cleveland - 192.168.1.0/24 - Connexion Ethernet haut débit au bureau satellite et dispose de deux contrôleurs de domaine. Connexion WAN à faible vitesse au site DR.

Site DR: Akron - 192.168.2.0/24 - Connexions WAN à faible vitesse au bureau principal et au bureau satellite et dispose de deux contrôleurs de domaine. La réplication AD est limitée aux heures creuses.

Bureau satellite: Canton - 192.168.3.0/24 - Connexion Ethernet haute vitesse au bureau principal - N'a pas de DC. Connexion WAN à faible vitesse au site DR.

Maintenant, si je crée un site pour chaque emplacement comportant des contrôleurs de domaine et associe uniquement ces sous-réseaux à ces sites, les clients du bureau satellite tentent par défaut d'établir une affinité pour les contrôleurs de domaine du site de récupération d'urgence et de s'y authentifier, ainsi que d'accéder aux ressources utilisant Informations ADS & S (telles que DFS) en raison du fait que le site de reprise après sinistre est le site AD le plus proche de ces clients (du point de vue de la couche 3), ce qui n'est pas ce que je souhaite en raison de la connexion WAN à faible vitesse et du fait que la réplication AD se produit uniquement après les heures normales de travail et qu'AD sera probablement incohérent entre le bureau principal et le site de reprise après incident (à l'exception des modifications qui déclenchent une réplication urgente)

Je voudrais donc créer et associer le sous-réseau 192.168.3.0/24 au site principal. Cela permet aux clients du bureau satellite d'établir une affinité avec les contrôleurs de domaine, de s'authentifier sur ceux-ci et d'accéder aux ressources du site du bureau principal via la connexion Ethernet haut débit, ce que je veux.


1
2017-09-20 19:03