[SCCM 2012] Faites les bons choix : Ais-je vraiment besoin d’un CAS ?

Avec la sortie de System Center 2012 Configuration Manager, les débats commencent à arriver et bien que les ressources anglaises ne manquent pas j’ai décidé de mettre ma pierre à l’édifice. Cette nouvelle version du produit introduit de nombreux changements comme :

• L’introduction d’un nouveau rôle appelé Central Administration Site (CAS)
• Le changement du modèle de réplication intersites pour utiliser un nouveau système spécialement conçu pour le produit et utilisant le Broker de SQL Server
  • Note : Pour ceux qui ne sont pas à jour par rapport aux changements apportés entre la Bêta 2 et la Release Candidate, le produit n’utilise plus la réplication SQL Server.
  • La modification des limites de supportabilité pour chaque composant.

Commençons donc par un rappel :

• On parle de hiérarchie quand une infrastructure ConfigMgr est composée de plusieurs sites primaires. Si une infrastructure est constituée d’un site primaire et de sites secondaires, elle n’est pas considérée comme une hiérarchie puisque les sites secondaires ne se sont pas acteurs dans l’administration de la solution.
• Le Central Administration Site (CAS) est un nouveau rôle dédié qui doit être installé lorsque l’entreprise a fait le choix d’implémenter une hiérarchie. Il coordonne par exemple la réplication entre les différents sites primaires. Il permet en outre :

• • De donner une vision globale de l’infrastructure (Reporting, Inventaire…)
  • De centraliser l’administration des tâches (télédistribution, etc…)

Il est à noter qu’aucun client ne peut y être rattaché et qu’il ne traitera aucune donnée cliente.  Il est possible de se connecter avec une console d’administration pour opérer des actions mais ce n’est en aucun cas un site primaire. Le CAS ne peut être que le parent de sites primaires.

• Le site primairepermet de gérer des clients sur un réseau bien connecté. Il offre les mécanismes nécessaires à l’administration des clients (rattachement, traitement des données clientes…). Il est possible de se connecter avec une console d’administration pour opérer des actions. Le site primaire peut être installé dans deux modes :

• • En mode Autonome (Standolone) : Dans ce mode de configuration, le site primaire n’est pas rattaché à un CAS et ne peut donc pas faire partie d’une hiérarchie. Le choix est structurant puisqu’un site primaire installé en mode standalone ne peut pas être rattaché à un CAS après installation. Il peut néanmoins être le parent de sites secondaires.
    NOTE : Il est possible de rattacher un CAS à un site autonome depuis le SP1 du produit. Ce scénario ne s'applique que pour l'extension d'un site autonome en hiérarchie et l'installation d'un nouveau CAS.
  • Joint à une hérarchie : Dans ce cas de figure, le site primaire est enfant d’un CAS et participe donc à la réplication de données dans une hiérarchie. En supplément, le site primaire peut être le parent d’un site secondaire.

• Le site secondaire est un relai ; il fait office de proxy pour les données clientes afin de limiter l’impact sur le réseau sur un site distant. Il permet aussi de contrôler la distribution du contenu sur des clients qui disposent d’une bande passante limitée. Contrairement à ConfigMgr 2007, les sites secondaires participent maintenant à la réplication de données intersites pour notamment faciliter la restauration en cas de désastre. Les sites secondaires sont donc équipés d’une version Express de SQL Server. Un site secondaire ne peut être que l’enfant d’un site primaire.
• Le Système de site est un serveur participant à l’infrastructure ConfigMgr. Un système de site dispose de rôles symbolisant sa fonction dans l’infrastructure et ne peut être rattaché qu’à un seul serveur de site.
• Le point de distribution (DP) est un rôle de système de site qui fait office de relais pour que les clients puissent accéder au contenu/sources (Applications, mises à jour, packages, images de système d’exploitation…)

Voici les limites de supportabilité pour chaque rôle :

• La hiérarchie peut supporter jusqu’à 400 000 clients si la base de données du CAS a été installé sur une infrastructure SQL Server Edition Enterprise. Lors de l’utilisation de l’édition Standard, la hiérarchie est limitée à 50 000 clients.

Note : Une fois la base de données du CAS installée sur une édition standard de SQL Server, la mise à jour de l’infrastructure vers l’édition Enterprise ne suffit pas à rehausser la limite de supportabilité. Ceci est dû au partitionnement de la base de données généré lors de son installation sur l’édition inférieure.

La hiérarchie supporte jusqu’à 25 sites primaires enfants.

• Le site primaire (qu’il soit joint à une hiérarchie ou autonome) supporte :
  • Jusqu’à 100 000 clients lorsque le serveur de base de données est déporté
  • Jusqu’à 50 000 clients lorsque le serveur de base de données est mutualisé
  • Jusqu’à 250 sites secondaires enfants.
  • Management Point :
    • Chaque Management Point peut supporter jusqu’à 25 000 clients. Il faut d’ailleurs 4 Management Points pour supporter 100 000 clients.
    • Chaque site primaire peut supporter jusqu’à 10 Management Points.
• Distribution Point
  • Chaque point de distribution peut supporter jusqu’à 4000 clients
  • Chaque site primaire supporte jusqu’à  250 points de distribution (PXE inclut)
  • Au total, le site primaire supporte jusqu’à 5000 points de distribution incluant ses points de distribution et les points de distribution des sites secondaires qui lui sont rattachés.
  • Chaque site secondaire peut supporter jusqu’à 5 000 clients.
    • Management Point :
      • Chaque site primaire ne peut supporter qu’un seul Management Point.

On en vient donc au sujet principal, Ais-je vraiment besoin d’un CAS ? Dois-je installer plus d’un site primaire ? Comme expliqué plus haut, le choix est décisif et ne doit pas être pris à la légère. Pour répondre à ces questions, vous pouvez utiliser les arguments suivants :

• Je dois gérer plus ou je vais gérer (dans un futur proche) plus de 100 000 clients
• J’ai une infrastructure multinationale avec les contraintes suivantes :

• Je dois donner un point local d’administration ; il est tout de même recommandé de gérer l’administration de manière centralisée.
• Les utilisateurs doivent avoir un accès direct à la console sans passer par un serveur de rebond (TSE/RDS)
• Raisons légales : Des applications business ne peuvent être distribuées et hébergées à partir d’un autre site que celui dans le pays cible.
• Je dois gérer des raisons politiques (se référer au point ci-dessus)

• J’ai des besoins importants en matière de Reporting qui peuvent impacter la base de données opérationnelles du site primaire. Je vais donc utiliser le CAS pour décharger mon site primaire. Ce scénario est à prendre dans de rares cas où la charge d’utilisation des fonctionnalités de Reporting est impressionnante. Certaines personnes sont amenées à faire ce qu’on peut déjà voir dans d’autres produits comme System Center Operations Manager en séparant la base de données opérationnelle de la base de données utilisée pour les rapports (à la manière d’un Data Warehouse).
• Je dois répartir prévoir un scénario de continuité de service du serveur de site. Notez que pour la majorité des rôles de système de site, il existe des solutions haute disponibilité (NLB, Cluster, rôle installable sous forme de multiples instances...). Dans un scénario de haute disponibilité du serveur de site, vous pouvez prévoir deux sites primaires reliés à un CAS. 
  • Si le CAS venait à devenir indisponible, l’administration reste possible à partir des sites primaires. L’impact est donc limité
  • Lorsqu’un site primaire subit un désastre, vous pouvez imaginer changer les clients de site pour assurer une continuité de service. Il est à noter que cette solution semble apporter des inconvénients et que le changement de site ne se fait pas sans conflit notamment au niveau des déploiements qui auraient pu être créé. Bien souvent, la solution la plus viable reste la restauration de site.

Il n’est plus nécessaire de déployer plus d’un site primaire si :

• Vous devez gérer des notions de langue. Le produit est devenu neutre de langue et le déploiement des langues régionales est devenu plus aisé.
• Vous souhaitez séparer les droits de sécurité et le contrôle de certains clients (postes de travail et serveur)
• Vous souhaitez déployer des stratégies (paramétrages des agents du client) différentes. Celles-ci ne sont plus déployées au niveau du site mais des collections.
• Vous souhaitez faire du routage de contenu pour distribuer les sources. Il est maintenant possible de router le contenu entre deux sites secondaires si l’un d’eux a une bande passante plus importante que l’autre.

L’équipe produit et la communauté qui gravite autour estime que 95% des entreprises n’ont pas besoin d’installer une hiérarchie avec un CAS et de multiples sites primaires. Ce discours peut ne pas être suivi par les équipes Microsoft sur le terrain (MCS, etc…) mais pourquoi il vaut mieux éviter d’installer un CAS ?

• Le coût matériel (64 GB de ram, 16 cores etc… Je vous invite à vous référer à la configuration recommandée)
• Le coût des licences :
  • Les éventuelles licences SQL Server Enterprise Edition (Les licences Standard sont inclues)
  • Les licences pour le systèmes d'exploitation des serveurs de site.

• Le coût de maintenance et de gestion apporté par les mécanismes de réplication intersites
• TOUT le contenu (pour chaque applications, packages, mises à jour, images de systèmes d’exploitation, etc…) créé sur les sites primaires enfants est stocké sur le CAS dans la librairie de contenu. Il faut donc prévoir l’espace disque nécessaire correspond à la charge de sources créée sur les sites enfants (Voir : http://blogs.technet.com/b/configmgrdogs/archive/2012/05/01/troubleshoot-configmgr-2012-sccmcontentlib-disk-i-o.aspx )

Est-ce bien raisonnable de se rajouter autant de contraintes si vous ne répondez pas aux arguments cités plus haut ?