Jaa

CAS ou pas CAS ?

  • Artikkeli

Avec l’arrivée de System Center 2012 Configuration Manager, beaucoup des réflexes habituels de construction d’une hiérarchie doivent être revus. J’ai eu récemment plusieurs conversations autour de l’utilisation ou non de Site Central d’Administration ou CAS, pour reprendre le vocabulaire anglais. D’autres discussions portent également sur le nombre de sites principaux (notez, au passage, le changement de vocabulaire qui passe de primaire à principal, en version française).

Dans de nombreux cas pour les clients français que je connais, le recours à un CAS ne se justifie pas.

Comme je l’avais abordé lors de la conférence des TechDays 2012, de nombreux clients utilisaient plusieurs hiérarchies ConfigMgr 2007 du fait des limitations de cette version.

Les limites supportées de la montée en charges sont globalement décrites dans une page partiellement traduite en français qui fait office de référence sur :
https://technet.microsoft.com/fr-fr/library/gg682077.aspx#BKMK_SiteAndRoleScale

La première limite est le nombre de clients que l’on peut gérer. Avec ConfigMgr 2012, une hiérarchie est limitée à la gestion de 400 000 clients et un site principal peut gérer jusqu’à 100 000 clients. Pour un grand nombre de clients français que je connais, l’effectif à gérer est bien inférieur à ces 100 000 clients, donc, quels pourraient être les raisons d’utiliser un CAS de manière à utiliser plusieurs principaux ?

Une limitation d’un site principal est de ne pouvoir gérer que jusqu’à 250 sites secondaires et, directement, 250 points de distribution. Ces nombres peuvent être un peu juste et justifier d’installer d’autres sites principaux, donc, de recourir à un CAS afin de dépasser ces limites et de garder un point central de gestion. Est-il bien nécessaire de recourir à des sites secondaires en grande quantité ? La gestion de la bande passante sur les points de distribution peut venir en aide sur des site ayant un faible nombre de clients et/ou d’une faible bande passante utilisable. En poussant le raisonnement, la disparition du pont de distribution d’agence (BranchDP) venait en aide. Elle est remplacée par l’utilisation des fonctions de Branch Cache apportées par des systèmes d’exploitation récents.

Les justifications d’utiliser un site primaire dans ConfigMgr 2007 et les versions précédentes se justifiaient par des besoins de délégation d’administration. Il faut impérativement arrêter de penser en termes d’utilisation d’un site principal pour les besoins de délégation avec ConfigMgr 2012 : il est parfaitement possible de déléguer la gestion d’une partie d’un site principal à une équipe d’administrateurs.

De manière périphérique, il est important de tenir compte que les sites principaux et le site central d’administration doivent être connectés à l’aide de liaisons d’une excellente connectivité . Une bonne partie des échanges entre sites s’effectue via de la réplication SQL qui est moins tolérante que la vétuste copie de fichiers entre sites.

Pour conclure, je préciserais deux points :

  • Depuis le service pack 1 de ConfigMgr 2012, il est possible de rajouter un CAS au-dessus d’un primaire si les besoins le justifie.
  • Lors d’une conception d’infrastructure, il faut toujours essayer de rester sur les solutions les plus simples. Au fil du temps, toute solution tend toujours à se complexifier. Il est donc, inutile de débuter sur des solutions complexes, au risque, sinon, de se retrouver avec des solutions inexploitables au bout de quelques années.

N’hésitez pas à réagir si vous n’êtes pas d’accord ou avez besoins de précisions !

Comments