Migration multi-sites sous AD2003 - Architectures (specialistes)

Migration multi-sites sous AD2003 - Architectures (specialistes) - Infrastructures serveurs - Systèmes & Réseaux Pro

Marsh Posté le 19-09-2006 à 20:19:37    

Salut à tous,
 
Je fais fasse à un problème peu courant. Je me retrouve dans une PME multi-sites qui n'a jamais fonctionné en domaine. Jamais personne n'a compris l'interet de la chose et tout le monde est admin de son pc en "workgroup". C'est ingérable, pas de MAJ des antivirus, pas de politique de sécurité, pas de serveur de spool, tout le monde installe n'importe quoi sur son pc bref tout est à refaire!
 
Je vais donc attaquer une migration sous Windows 2003 Server R2. Je dois pour cela préparer des plans d'architecture. Voici la situation actuelle:
 
 
-Site A: Environ 150 PC.
-Site B: Environ 100 PC.
-Site C: Environ 80 PC.
 
Total: 330 PC.
 
Réseau:
-Liaison entre les sites à 1Mbits sur du SDSL.
-Déplacement de gens du site A vers B ou C et inversement.
 
 
 
Problèmatique:
Que serait il le mieux dans mon cas avec la contrainte des gens qui se déplacent et de mes liaisons WAN entre avoir des sous-domaines comme:
siteA.mondomaine.com
siteB.mondomaine.com
siteC.mondomaine.com
 
Ou alors avoir un seul domaine "mondomaine.com". Je veux que ce soit le plus simple possible à gérer.
 
En terme de nombres de serveurs combien en prévoieriez-vous?
 
D'avance merci!

Reply

Marsh Posté le 19-09-2006 à 20:19:37   

Reply

Marsh Posté le 20-09-2006 à 12:27:01    

Moi je pense qu'il faut 3 serveurs de domaines (1 sur chaque site). Tu désigne le serveur du SiteA comme principal et les autre secondaire et tu fait une replication d'active directory entre les serveurs. Tout le monde est dans le même domaine donc tu peut créer des OU SiteA SiteB SiteC pour faciliter l'administration des sites.
Enfin c'est comme ça que j'aurai fais ce qui n'est peut-être pas la meilleur solution.

Reply

Marsh Posté le 20-09-2006 à 13:06:36    

Ouh la... tu vas faire ca tout seul?
 
C'est un GROS projet ca.  
 
Si le coeur de métier pour chaque site est le même, ya pas de raison de faire plusieurs domaines.
Je ferais 1 seul domaine et 3 sites. (comme gegebast)
Il faut différencier le niveau logique du niveau physique.
Les sites sont gérables dans la console dssite.
 
Apres, faut prévoir minimum 1 DC par site voir plus. Ca depend du budget. Tiens compte également du positionnement des GCs.
Par contre, il n'ya pas de notion de serveur principal ou secondaire dans AD. Il faut attirbuer des roles fsmo.
 
pour les users, puisqu'ils bougent, il faudrait du profil itinérant. A toi de voir la charge reseau (moi j connais po).
 
J'insiste sur le fait que c'est un Gros projet. Ca va prendre du temps et couter de l'argent pour faire les choses bien.


Message édité par shuai le 20-09-2006 à 13:09:57
Reply

Marsh Posté le 20-09-2006 à 13:24:34    

Merci à vous 2.  
Je sais que c'est un très gros projet, le problème, c'est que pdt des années ils ont installé des PC en groupe de travail sans serveur de sauvegarde, antivirus.... En fait il faut tout refaire de A à Z.
 
J'avais pensé comme vous, faire un seul domaine et mettre un serveur par site pour faciliter la tache des itinérants.
 
Les points noires que j'ai sont les suivants:
-Quelles bandes passantes la réplication entre leus serveurs utilisent-elles (rappelle SDSL 1Mbits de liaison inter-site).
-SI le serveur du site A tombe, les gens présents sur ce site pourront-ils toujours ouvrir la session? Est-ce que ça basculer automatiquement sur le serveur du site B? Si oui où se trouvent les informations de tous ces serveurs sur leur PC?

Reply

Marsh Posté le 20-09-2006 à 14:02:54    

La bande passante utilisée pour les réplications est faible. Et tu peux toi-même définir des fréquences de réplications si tu ne veux pas que les contrôleurs se parlent sans arrêt.
 
En cas de perte d'un contrôleur, si ton archi est bien montée, les utilisateurs ne verront presque rien, à part peut-être un léger ralentissement dans les ouvertures de session.

Reply

Marsh Posté le 20-09-2006 à 18:29:50    

slt,
si ton svr SiteA tombe, les users pourront se loguer en passant par Svr SiteB ou C à condition que ta Sdsl ne tombe pas aussi. Evidement ils n'auront pas accès au service du svr SiteA comme par exemple si tu l'utilises en svr de fichiers.
Idem pour les profiles errants si tu ne penses pas à les répliquer sur les autres svr (y a du taf!) et sans profile correctement paramétré les users sont en panique c'est comme si plus rien ne marchait. Et ça si tu admin pas carré tu vas flipper en voyant des profiles errant de 100 meg se balader sur ta sdsl. Le matin qd tout le monde va se connecter ça va plier.
 
Moi je te conseille 1 svr par site +
Qd UserA est sur SiteB il se connecte sur une machineB_XpPro libre et utilise Bureau à distance pour se connecter sur sa machineA_XpPro et accèder peinard à ses applis
Si tu as le budget tu peux même mettre 1 Terminal Server sur chaque site.
Pour info avec une 4 meg je peux avoir 15 users en simultané pour faire de la bureautique.

Reply

Marsh Posté le 20-09-2006 à 18:42:17    

lecharcutierdelinux a écrit :

-Quelles bandes passantes la réplication entre leus serveurs utilisent-elles (rappelle SDSL 1Mbits de liaison inter-site).


 
C'est extremement faible, et surtout ça ne replique que les changements : tu changes le mdp d'un user, c'est pas toutes l'AD ou meme toutes les données de l'user qui vont etre transférée dans tous les sens, mais juste le mot de passe.
 

Citation :

-SI le serveur du site A tombe, les gens présents sur ce site pourront-ils toujours ouvrir la session? Est-ce que ça basculer automatiquement sur le serveur du site B?

 
 
Oui
 

Citation :

Si oui où se trouvent les informations de tous ces serveurs sur leur PC?


 
Nulle part, cette info est sur les serveurs DNS.

Reply

Marsh Posté le 20-09-2006 à 22:15:15    

1/ Mais si les PC du site A sont configurés pour aller sur le SRVA et que celui est aussi leur DNS c'est mort.... Faut au moins en mettre deux dans leurs configuration TCP/IP :
-DNS primaire SRV1
-DNS secondaire SRV2
Is It Right?
 
2/ Pour ce qui est profils errants je suis pas sur que ce soit cela que je souhaite, je veux juste qu'un utilisateur qui a l'habitude d'être sur le site A avec les données en locale sur son PC puisse faire de même en étant sur le site B ou C.
Les données j'ai décidé de les stocker en locale sur le pc et de les répliquer par un script robocopy sur un NAS.
 
3/ Effectivement y'a du boulot en perspective mais je me disais un truc, vu qu'en gros je vais utiliser mes serveurs uniquement pour la structure de active directory (scripts ouverture de session, comptes utilisateurs centralisés...) je vais peut être ajouter un vulagire pc à 1000 Euros sous Windows 2003 SRV comme deuxieme serveur sur chaque site en + du vrai serveur à 5000...
 
4/Comment ça marche au niveau des licenses ? J'ai 350 users potentiel qui peuvent s'authentifier sur les trois serveurs A, B et C selon leur déplacement/mutation...
 
 
Mais quel bordel en perspective, en tout cas, merci de votre aide précieuse! Je me suis apperçu que dans le monde microsoft Server y'avai beaucoup de gens qui connaissait les bouquins et les certifications mais très peu de monde qui sait appliquer sur des cas concrets en tenant comptes des bandes passantes, multi-sites....


Message édité par lecharcutierdelinux le 20-09-2006 à 22:23:07
Reply

Marsh Posté le 20-09-2006 à 22:21:48    

Oui c'est comme ça que ça marche.

Reply

Marsh Posté le 20-09-2006 à 22:24:18    

Désolé j'ai édité mon message pdt que tu me répondais

Reply

Marsh Posté le 20-09-2006 à 22:24:18   

Reply

Marsh Posté le 20-09-2006 à 22:40:36    

Pas grave ;)
 

lecharcutierdelinux a écrit :

2/ Pour ce qui est profils errants je suis pas sur que ce soit cela que je souhaite, je veux juste qu'un utilisateur qui a l'habitude d'être sur le site A avec les données en locale sur son PC puisse faire de même en étant sur le site B ou C.
Les données j'ai décidé de les stocker en locale sur le pc et de les répliquer par un script robocopy sur un NAS.


 
Quelle que soit le type d'install et les différents impératifs, on peut presque toujours être sur d'une chose : les données reparties en local sur les différents PC clients, c'est jamais la meilleure solution :o
 

Citation :

3/ Effectivement y'a du boulot en perspective mais je me disais un truc, vu qu'en gros je vais utiliser mes serveurs uniquement pour la structure de active directory (scripts ouverture de session, comptes utilisateurs centralisés...) je vais peut être ajouter un vulagire pc à 1000 Euros sous Windows 2003 SRV comme deuxieme serveur sur chaque site en + du vrai serveur à 5000...


 
Si t'as les sous pour ça et les licences pourquoi pas, mais ça me parrait pas essentiel.
Un systeme de disaster recovery rapide et une garantie hardware sur site genre h+4 pour les "vrais" serveurs me parait plus important en tout cas, les serveurs des autres sites pouvant l'intervalle en mode +- dégradé.
 

Citation :

4/Comment ça marche au niveau des licenses ? J'ai 350 users potentiel qui peuvent s'authentifier sur les trois serveurs A, B et C selon leur déplacement/mutation...


 
C'est pas un probleme, les CAL sont valable pour tout le domaine, et ça marche par utilisateur et/ou par poste client.


Message édité par El Pollo Diablo le 20-09-2006 à 22:40:48
Reply

Marsh Posté le 20-09-2006 à 23:10:07    

voilà comment on est organisé chez nous si ça peut t'aider.
8 sites dont le siege qui est le site principal. Tous reliés en SDSL equant 1Mb/s sauf siege 4Mb/s.
chaque site dispose d'un controleur de domaine (catalogue global) qui fait serveur de fichiers, spool, DNS, DHCP + un systeme de backup.
le DNS du site renvoie sur celui du siege si il ne sait pas résoudre le nom.
on a un seul domaine et 8 sites donc avec des replic programmées entre midi et deux heures et a partir de 19h.
aucune données en local. aucun droit admin sauf exception (1 personne et une vingtaine en power users à cause d'un log)  
L'accès internet classique est uniquement au siege et fournit tous les sites.
Les MAJ antivirus se font au siege d'abord puis sont poussés sur les sites automatiquement. pareil pour WSUS.
 
on a passé il y a quelques mois pas mal d'applis sur 2 serveurs TSE 2003 accessible par un portail (applidis de systancia).
ces deux serveurs sont aux siege accessible à everebody.
ça change la vie... plus de MAJ des applis sur les postes clients.
 
mon avis : moins t'en as sur les postes, mieux c'est.  :D  
le fait d'avoir les données en local, les droits admin pour les users et la gestion en workgroups, ça me fait totalement halluciner et me semble ingérable !
conseil pour les profils itinérant : c'est clairement la merde à gérer et les services info ont souvent plus de désir là dessus que le user lui même.


Message édité par i'm philou le 20-09-2006 à 23:11:26
Reply

Marsh Posté le 25-01-2007 à 12:03:08    

Bonjour tout le monde,
 
Quelqu'un serait-il capable de m'expliquer comment dans un seul site, le traitement des requetes est réparti entre les différents controleurs de domaines présents svp?
 
Est-ce que c'est le premier qui les traite et une fois qu'il est au maximum de sa capacité, le 2eme DC prend en charge les nvelles requetes?
 
Est-ce que les requetes des utilisateurs sont envoyées au DC le plus proche ?  
 
etc...
 
merci d'avance.

Reply

Marsh Posté le 12-02-2007 à 12:52:09    

Ma question est comment faire dans ce cas pour l'adressage ip de l'essemble du parc info ? tout le monde est dans la meme plage ip (tel que 192.168.1.X)

Reply

Marsh Posté le 27-02-2007 à 09:17:50    

jojo256 a écrit :

Bonjour tout le monde,
 
Quelqu'un serait-il capable de m'expliquer comment dans un seul site, le traitement des requetes est réparti entre les différents controleurs de domaines présents svp?
 
Est-ce que c'est le premier qui les traite et une fois qu'il est au maximum de sa capacité, le 2eme DC prend en charge les nvelles requetes?
 
Est-ce que les requetes des utilisateurs sont envoyées au DC le plus proche ?  
 
etc...
 
merci d'avance.


Je suppose que cela est déterminé à partir des couts de connexion intersites.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed