MSNLoop
MVP Yannick Plavonil

Catégories


Étiquettes


MSNLoop

Documentation technique destinée aux professionnels de l'informatique qui ont recours aux produits, outils et technologies Microsoft pour gérer et déployer Windows.

MSNLoop

Architecture Configuration Manager 2012 R2

Yannick PlavonilYannick Plavonil

Voici un guide ou plutôt un aide mémoire pour la réalisation de l’architecture et le déploiement de System Center Configuration Manager 2012 R2 pour des environnements complexes avec un accent sur la haute disponibilité et l’optimisation des performances. Ceci comprend donc l’optimisation SQL que vous soyez déjà en production ou pas, configuration des rôles dépendamment de la quantité d’utilisateurs à gérer, la gestion de contenu avancée, et les environnements avec plusieurs domaines. Tout reste basé sur les bonnes pratiques et les expériences à date.

Considérations SQL Server

Design et Installation
  • Il est préférable d’installer SQL sur le serveur de site primaire, à moins d’être dans une grande entreprise (raisons politiques).
  • SQL en local signifie aussi un meilleur contrôle de la base de donnée, éventuellement pour du support/requêtes.
  • La version SQL standard suffit sans problème pour une installation d’un site primaire. Et cette version fait partie de votre licence. Vous pouvez installer cette version sur autant de serveurs souhaités tant qu’elle est utilisée pour Configuration Manager. Donc c’est possible de l’installer sur un MP Replica pour alléger la charge de la base de données principale.
  • La taille de la BD est d’environ 5Mb par client.
  • Toujours limiter la mémoire SQL.
  • 1 fichier de base de données par core, sans dépasser 8 fichiers. Le mieux c’est de le faire dès le début, car après l’installation il est impossible d’avoir les performances optimales.
  • 1 fichier temDB pour chaque 2 CPU.
Base de données de site
  • Dans le cas d’une moyenne entreprise et au-delà, précréer la BD manuellement ou avec un script utilisé en interne chez Microsoft pour avoir un contrôle total.
  • Activer la tâche de maintenance « Rebuild Index ». L’expérience montre qu’elle n’est pas si efficace dans certaines situations. Dans ce cas, utiliser le script Microsoft « UpdateIndex.sql » 1 fois par semaine en utilisant un job SQL.
Reporting Server
  • Autogrowth; mettre un seuil pour le reporting et limiter la taille des logs (pour ne pas avoir de mauvaise surprise)
  • Recovery mode = simple (par défaut il est sur Full, donc tant qu’un backup n’est pas effectué les fichiers de log ne sont pas supprimés)

Disposition des disques

Faire l’allocation NTFS de taille 64KB pour les volumes SQL
Sur un SAN, c’est primordial d’avoir d’excellentes performances IOPS

Disque Controleur # de Disques Partitions
0 0 4 OS
1 1 4 tempDB
2 1 4 fichiers Log
3 1 6 BD ConfigMgr
4 2 6 BD ConfigMgr
5 2 8 Programmes
6 x x ContentLib
Disposition typique
Site moyen ou coût élevé
C:\OS
D:\Program
E:\Content library
F:\ Fichiers BD (100GB)
G:\TempDB (50 GB)
H:\ BD Logs (50GB)
Combiner tempBD et les fichiers Log sur 1 partition
Combiner les fichiers bases de données sur 1 partition
Combiner le reste (non OS) sur 1 partition
Toujours planifier l’espace disque pour le ContentLibrary et autre sauvegarde de fichiers

Systèmes de site

Considérations pour la haute disponibilité

Dans 99% des cas, l’environnement Configuration Manager n’est pas un système critique pour une entreprise contrairement à la messagerie, etc. Mais les points suivants sont bons à savoir

  • SQL 2012 Always On n’est pas supporté.
  • Le Mirroring SQL n’est pas supporté (fonctionne jusqu’au jour ou vous ferez une mise à niveau « dbupgrade » et là panique il faut réinstaller)
  • L’utilisation d’un cluster SQL n’est pas nécessaire et ne garantit pas une continuité totale si le site primaire tombe.

Rôles avec instance multipes

Management point
Distribution point
State migration point
System Health Validator point
Application Catalog website/web service point
Software update point
Reporting service point

Rôles uniques

Site server
Asset Intelligence synchronization point
Endpoint Protection point
Enrollment point
Enrollment proxy point
Fallback status point
Out of band service point

http://technet.microsoft.com/en-us/library/hh846246.aspx

Performance

Lorsque SQL est installé localement, c’est essentiel d’alléger la charge sur le serveur primaire en séparant les rôles face au client sur d’autres serveurs:

  • Management point
  • Distribution point
  • Application Catalog web service point
  • Application Catalog website point
  • Software update point

Tous les autres rôles peuvent être installé sur le serveur de site primaire
Pensez à utiliser le replica SQL sur les Management points (moyenne entreprise et au-delà)

Dimensionnement

< 2000 clients
< 20000 clients
< 100K clients
> 100K clients
1 serveur: BD SQL, tous les rôles, Site primaire
1 serveur: BD SQL, Primary site, SMS provider, Endpoint Protection
2+ serveurs: Management Point, Software Update, Distribution Point, Application Catalog
1 serveur: BD SQL, Primary site, SMS provider, Endpoint Protection
4+ serveurs: Management Point, Software Update, Distribution Point, Application Catalog
1 CAS
2 PSS
Management Point / SQL replica
  • Les MP ne tiennent pas compte de l’emplacement réseau contrairement aux DP donc les clients d’un site distant peuvent communiquer avec n’importe lesquels. Si c’est une contrainte, ajouter un site secondaire.
  • Limite de 10 MP par site primaire, 1 MP pour site secondaire.
  • Le replica SQL est envisageable au-delà de 15000 clients, car il améliore les performances et la tolérance aux pannes, et sans exiger une licence supplémentaire.
  • BD de 3Go suffit, pas besoin des prérequis du site
  • Le replica SQL nécessite « SQL transactional replication », « SQL Agent » et un partage pour stocker les données du replica
Distribution Points
  • Considérer le Cloud DP pour les bureaux distant sans l’infrastructure adéquate.
  • Si le cloud DP est utilisé, ajouter un record DNS pour le cloud DP.
  • On peut configurer les alertes d’utilisation du cloud DP dans les propriétés.
  • Considéer le Brand Cache lorsqu’on ne peut pas mettre de DP local
  • Depuis le SP1 vous pouvez contrôler le trafic dans les options du DP
OSD
  • Utiliser MDT 2012 SP1/ MDT 2013 pour construire toutes vos images Windows de référence. Le fichier WIM obtenu peut ensuite être utilisé par n’importe quel outil de déploiement sur ??le marché. MDT peut entièrement automatiser l’injection de patchs, logiciels et autres réglages.
  • Considérer Windows Server 2012 R2 pour les DP, il y a de bonne performance pour le PXE.
  • Considérer Windows Server 2012 R2 (WDS) pour supporter les machines UEFI.
  • Utiliser des clés USB en FAT pour supporter les machines UEFI.
SUP
  • Depuis le SP1, on peut ajouter plusieurs SUP. Mais faire ceci si nécessaire, 1 SUP suffit dans la plupart des cas.
  • Le changement d’un SUP à un autre engendre du traffic (5MB) par les clients.
  • Les clients sont associés à 1 seul SUP jusqu’à ce que celui-ci échoue.
  • Une BD partagée pour les SUP représente une faille en cas de panne.
  • Voir WUAHandler pour les changements.
  • Un NLB WSUS est mieux pour la fault tolerance.

Forêts / Domaines multiples

3 scenarios:

Quand il n’y a pas de trust on utilise un compte pour le publishing dans AD et pour la création des objets dans le conteneur Systems Manangement.
Pour les découvertes le « path n’est pas le même et on utilise toujours le compte ad. (LDAP://contoso.com/DC=contoso,DC=com)
On peut utiliser un startup script (GPO) pour installer le client. Extension du schéma requise.

Considération des sites secondaires

Yannick Plavonil est un consultant, spécialisé dans les solutions de gestion et déploiement Windows en entreprise. Activement impliqué dans les communautés, il a reçu le titre Microsoft Most Valuable Professional (MVP). Ses domaines d'expertise comprennent les outils de déploiements Windows, MDT, WinPE, USMT, WDS, ConfigMgr et Intune.

Commentaires 0
Il n'y a actuellement aucun commentaire.