FAQ sur le dimensionnement et les performances des sites Configuration Manager

Séparez les boîtes de réception Configuration Manager et les fichiers SQL Server sur au moins deux volumes différents. Cette séparation vous permet d’optimiser les tailles d’allocation de cluster pour les différents types d’E/S qu’ils effectuent.

Pour le volume hébergeant vos boîtes de réception de serveur de sites, utilisez NTFS avec des unités d’allocation de 4K ou 8K. ReFS écrit 64 Ko, même pour les petits fichiers. Configuration Manager a de nombreux petits fichiers, de sorte que ReFS peut produire une surcharge de disque inutile.

Pour les disques contenant des fichiers de base de données SQL Server, utilisez le format NTFS ou ReFS, avec des unités d’allocation de 64 Ko.

Les tableaux modernes de disques SSD et d’Azure Stockage Premium peuvent fournir des IOPS élevées sur un seul volume, avec peu de disques. En règle générale, vous ajoutez d’autres lecteurs à un tableau pour un stockage supplémentaire, et non pour un débit supplémentaire. Si vous utilisez des disques physiques basés sur une broche, vous aurez peut-être besoin de plus d’IOPS que vous ne pouvez générer sur un seul volume. Vous devez allouer 60 % de l’espace disque et des E/S par seconde recommandés pour le fichier .mdf , 20 % pour le fichier .ldf et 20 % pour les fichiers temporaires de journaux et de données. Les fichiers .ldf et temp peuvent tous résider sur un seul volume avec 40 % (20 % + 20 %) de vos IOPS allouées.

SQL Server versions antérieures à SQL Server 2016 créées par défaut un seul fichier de données temporaire. Vous devez en créer davantage pour éviter SQL Server verrous et d’attendre l’accès à un seul fichier. Les opinions de la communauté varient sur le meilleur nombre de fichiers de données temporaires à créer, de quatre à huit. Les tests révèlent peu de différence entre quatre et huit, ce qui vous permet de créer quatre fichiers de données temporaires de taille égale . Vos fichiers de données tempdb doivent avoir jusqu’à 20 à 25 % de la taille de votre base de données complète.

Lorsqu’il est configurable, définissez la mémoire du contrôleur RAID sur 70 % d’allocation pour les opérations d’écriture et 30 % pour les opérations de lecture. En général, utilisez une configuration de tableau RAID 10 pour la base de données de site. RAID 1 est également acceptable pour les sites à petite échelle avec des exigences d’E/S faibles, ou si vous utilisez des disques SSD rapides. Avec des baies de disques plus volumineuses, configurez les disques de rechange pour remplacer automatiquement les disques défaillants.

Exemple : Ordinateur physique avec disques physiques

Les instructions de dimensionnement pour un serveur de site colocalisé et SQL Server avec 100 000 clients sont de 1 200 IOPS pour les boîtes de réception des serveurs de site et de 5 000 IOPS pour les fichiers SQL Server.

La configuration de disque obtenue peut ressembler à ceci :

1. N’inclut pas les disques de rechange recommandés.
2. Cette valeur provient de l’exemple de configurations de disque.

Hyper-V offre des performances similaires à celles d’un serveur physique, si les ressources matérielles (cœurs de processeur et stockage direct) sont 100 % dédiées à la machine virtuelle. L’utilisation de fichiers de disque .vhd ou .vhdx de taille fixe a un impact minimal de 1 à 5 % sur les performances d’E/S. L’utilisation de fichiers de disque .vhd ou .vhdx à développement dynamique a un impact jusqu’à 25 % sur les performances d’E/S pour la charge de travail Configuration Manager. Si vous avez besoin de disques en développement dynamique, compensez en ajoutant des performances d’IOPS supplémentaires de 25 % au tableau.

Lorsque vous exécutez votre Configuration Manager serveur de site ou SQL Server à l’intérieur d’une machine virtuelle, isolez les lecteurs du système d’exploitation hôte Hyper-V du système d’exploitation et des lecteurs de données de la machine virtuelle.

Pour plus d’informations sur l’optimisation des machines virtuelles, consultez Optimisation des performances des serveurs Hyper-V.

Exemple : serveur de site basé sur une machine virtuelle Hyper-V

Les instructions de dimensionnement pour un serveur de site colocalisé et SQL Server avec 150 000 clients sont de 1800 IOPS pour les boîtes de réception de serveur de site et de 7 400 IOPS pour les fichiers SQL Server.

La configuration de disque obtenue peut ressembler à ceci :

1. N’inclut pas les disques de rechange recommandés.
2. . vhdx de taille fixe pour le lecteur de machine virtuelle dédié au volume sous-jacent.
3. Cette valeur provient de l’exemple de configurations de disque.

Commencez par lire les Configuration Manager forum aux questions sur Azure.

Les machines virtuelles IaaS (Infrastructure as a Service) Azure qui tirent parti des disques basés sur Stockage Premium peuvent avoir des IOPS élevées. Sur ces machines virtuelles, configurez des disques supplémentaires pour les besoins d’espace disque prévus, plutôt que pour les IOPS supplémentaires.

Le stockage Azure est intrinsèquement redondant et ne nécessite pas plusieurs disques pour la disponibilité. Vous pouvez entrelacer des disques dans le Gestionnaire de disques ou espaces de stockage pour fournir de l’espace et des performances supplémentaires.

Pour plus d’informations et des recommandations sur la façon d’optimiser les performances Stockage Premium et d’exécuter des serveurs SQL Server dans des machines virtuelles IaaS Azure, consultez :

• Optimiser les performances des applications

• Conseils sur les disques

Exemple : serveur de site basé sur Azure

Les instructions de dimensionnement pour un serveur de site colocalisé et SQL Server avec 50 000 clients sont huit cœurs, 32 Go et 1 200 IOPS pour les boîtes de réception des serveurs de site, et 2800 IOPS pour les fichiers SQL Server.

Votre machine Azure obtenue peut être un DS13v2 (huit cœurs, 56 Go) avec la configuration de disque suivante :

1. Cette valeur provient de l’exemple de configurations de disque.
2. Les conseils Azure permettent de placer TempDB sur le lecteur D: ssd local, étant donné qu’il ne dépassera pas l’espace disponible et autorise une distribution d’E/S disque supplémentaire.

Exemple : serveur de site basé sur Azure (pour une augmentation instantanée des performances)

Le débit du disque Azure est limité par la taille de la machine virtuelle. La configuration dans l’exemple Azure précédent peut limiter l’expansion future ou des performances supplémentaires. Si vous ajoutez des disques supplémentaires lors du déploiement initial de votre machine virtuelle Azure, vous pouvez augmenter la taille de votre machine virtuelle Azure pour augmenter la puissance de traitement à l’avenir, avec un investissement initial minimal. Il est beaucoup plus simple de planifier à l’avance pour augmenter les performances du site à mesure que les exigences changent, au lieu de devoir effectuer ultérieurement une migration plus complexe.

Modifiez les disques dans l’exemple Azure précédent pour voir comment les IOPS changent.

DS13v2

1. Les disques sont entrelacés à l’aide de espaces de stockage.
2. Cette valeur provient de l’exemple de configurations de disque. La taille de la machine virtuelle limite les performances.
3. Les conseils Azure permettent de placer TempDB sur le lecteur D: ssd local, étant donné qu’il ne dépassera pas l’espace disponible et autorise une distribution d’E/S disque supplémentaire.

Si vous avez besoin de plus de performances à l’avenir, vous pouvez mettre à niveau votre machine virtuelle en DS14v2, ce qui doublera le processeur et la mémoire. La bande passante disque supplémentaire autorisée par cette taille de machine virtuelle augmente également instantanément les IOPS de disque disponibles sur vos disques précédemment configurés.

DS14v2

1. Les disques sont entrelacés à l’aide de espaces de stockage.
2. Cette valeur provient de l’exemple de configurations de disque. La taille de la machine virtuelle limite les performances.
3. Les conseils Azure permettent de placer TempDB sur le lecteur D: ssd local, étant donné qu’il ne dépassera pas l’espace disponible et autorise une distribution d’E/S disque supplémentaire.

Les deux peuvent fonctionner correctement, en supposant que le serveur unique est de taille appropriée ou que la connectivité réseau est suffisante entre les deux serveurs.

Les SQL Server à distance nécessitent le coût initial et opérationnel d’un serveur supplémentaire, mais sont typiques parmi la majorité des clients à grande échelle. Cette configuration présente les avantages suivants :

• Options de disponibilité de site accrues, telles que SQL Server Always On
• Possibilité d’exécuter des rapports lourds avec moins d’auditions sur le traitement du site
• Récupération d’urgence plus simple dans certaines situations
• Gestion de la sécurité plus facile
• Séparation des rôles pour la gestion des SQL Server, par exemple avec une équipe DBA distincte

Les SQL Server colocalisées nécessitent un serveur unique, et sont typiques pour la plupart des clients à petite échelle. Cette configuration présente les avantages suivants :

• Réduire les coûts des machines, des licences et de la maintenance
• Moins de points de défaillance dans le site
• Meilleur contrôle pour la planification des temps d’arrêt

Par défaut, SQL Server utilise toute la mémoire disponible sur votre serveur, ce qui peut priver le système d’exploitation et d’autres processus sur l’ordinateur. Pour éviter les problèmes de performances potentiels, il est important d’allouer de la mémoire à SQL Server explicitement. Sur les serveurs de site colocalisés avec SQL Server, assurez-vous que le système d’exploitation dispose de suffisamment de RAM pour la mise en cache des fichiers et d’autres opérations. Assurez-vous qu’il reste suffisamment de RAM pour SMSExec et d’autres processus Configuration Manager. Lorsque vous exécutez SQL Server sur un serveur distant, vous pouvez allouer la majorité de la mémoire à SQL, mais pas à la totalité. Passez en revue les instructions de dimensionnement pour obtenir des conseils initiaux.

SQL Server allocation de mémoire doit être arrondie à go entier. En outre, à mesure que la RAM augmente pour atteindre de grandes quantités, vous pouvez laisser SQL Server avoir un pourcentage plus élevé. Par exemple, lorsque 256 Go ou plus de RAM est disponible, vous pouvez configurer SQL Server jusqu’à 95 %, car cela conserve encore beaucoup de mémoire pour le système d’exploitation. La surveillance du fichier de page est un bon moyen de s’assurer qu’il y a suffisamment de mémoire pour le système d’exploitation et les processus Configuration Manager.

Vous pouvez rencontrer des problèmes de contention de mémoire s’il y a plus de 16 cœurs physiques et pas assez de RAM sur votre SQL Server. La charge de travail Configuration Manager fonctionne mieux quand au moins 3 à 4 Go de RAM par cœur sont disponibles pour SQL. Lorsque vous ajoutez des cœurs à votre SQL Server, veillez à augmenter la RAM en quantité proportionnelle.

En général, les groupes de disponibilité ont un effet négligeable sur les performances du système lorsque la mise en réseau est suffisante entre les serveurs réplicas. Vous pouvez avoir une croissance rapide du fichier .ldf du journal de base de données dans un environnement de groupe de disponibilité occupé. Toutefois, l’espace du fichier journal est automatiquement libéré après une sauvegarde de base de données réussie. Ajoutez un travail SQL Server pour la base de données Configuration Manager afin d’effectuer une sauvegarde, par exemple toutes les 24 heures, et une sauvegarde .ldf toutes les six heures. Pour plus d’informations sur les groupes de disponibilité et les Configuration Manager, notamment sur les stratégies de sauvegarde SQL Server, consultez Préparer l’utilisation d’un groupe de disponibilité SQL Server Always On.

SQL Server compression n’est pas recommandée pour la base de données Configuration Manager. Bien qu’il n’y ait aucun problème fonctionnel lié à l’activation de la compression sur une base de données Configuration Manager, les résultats des tests ne montrent pas beaucoup d’économies de taille par rapport à l’impact potentiel sur les performances du système.

Tous les secrets de la base de données Configuration Manager sont déjà stockés en toute sécurité, mais l’ajout de SQL Server chiffrement peut ajouter une autre couche de sécurité. Il n’existe aucun problème fonctionnel avec l’activation du chiffrement sur votre base de données, mais il peut y avoir une dégradation des performances jusqu’à 25 %. Par conséquent, chiffrez avec prudence, en particulier dans les environnements à grande échelle. N’oubliez pas également de mettre à jour vos plans de sauvegarde et de récupération pour vous assurer que vous pouvez récupérer correctement les données chiffrées.

Pour connaître les versions prises en charge de SQL, consultez Prise en charge des versions SQL Server. Du point de vue des performances, toutes les versions prises en charge de SQL Server répondent aux critères de performances requis. Toutefois, SQL Server 2016 ou version ultérieure a tendance à surperformer SQL Server 2014 dans certains aspects de la charge de travail Configuration Manager. En outre, l’exécution SQL Server 2014 au niveau de compatibilité SQL Server 2012 (110) améliore les performances en général. Au moment de l’installation, Configuration Manager bases de données s’exécutant sur SQL Server 2014 sont définies sur le niveau de compatibilité 110. SQL Server 2016 ou version ultérieure est défini sur ce niveau de compatibilité par défaut SQL Server version, par exemple 130 pour SQL Server 2016. La mise à niveau de SQL Server en place ne met pas à jour les niveaux de compatibilité tant que vous n’avez pas installé la prochaine version principale Configuration Manager Current Branch.

Si vous constatez des délais d’expiration inhabituels ou des lenteurs sur certaines requêtes SQL sur SQL Server 2016 ou version ultérieure, par exemple lors de l’utilisation de RBAC dans la console Administration, essayez de modifier le niveau de compatibilité SQL Server sur la base de données Configuration Manager sur 110. L’exécution au niveau de compatibilité SQL Server 110 sur SQL Server 2014 et versions ultérieures de SQL Server est entièrement prise en charge. Pour plus d’informations, consultez Délais d’expiration des requêtes SQL ou Console lente sur certaines requêtes de base de données Configuration Manager.

Depuis janvier 2018, vous devez éviter les versions SQL Server suivantes, en raison de divers problèmes connus liés aux performances ou d’autres problèmes potentiels :

• SQL Server 2012 SP3 CU1 à CU5
• SQL Server 2014 SP1 CU6 à SP2 CU2
• SQL Server 2016 RTM à CU3, SP1 CU3 à CU5

Oui, mettez à jour les index aussi souvent qu’une fois par semaine et les statistiques aussi souvent qu’une fois par jour pour améliorer les performances SQL Server. Des scripts tiers et des informations supplémentaires disponibles auprès des communautés Configuration Manager et SQL Server peuvent vous aider à optimiser ces tâches.

Dans les grands sites, certaines tables SQL Server, telles que CI_CurrentComplianceStatusDetails, HinvChangeLog, peuvent être volumineuses, en fonction de vos modèles d’utilisation. Vous devrez peut-être réduire ou modifier votre approche de maintenance pour eux un par un.

SQL Server Express n’a pas d’impact significatif sur les performances sur les sites secondaires, et elle est appropriée pour la plupart des clients. Il est également facile à déployer et à gérer. Il s’agit de la configuration recommandée pour presque tous les clients, quelle que soit leur taille.

Il existe une situation dans laquelle une installation complète SQL Server peut être nécessaire. Si vous avez un grand nombre de points de distribution, de packages ou de sources dans votre environnement, il est possible de dépasser la limite de taille de 10 Go de SQL Server Express. Si le nombre de packages multiplié par le nombre de points de distribution est supérieur à 4 000 000, par exemple 2 000 DP avec 2 000 éléments de contenu, envisagez d’utiliser des SQL Server complètes sur vos sites secondaires.

Laisser votre paramètre à 0 (utiliser tous les processeurs disponibles) est optimal pour les performances de traitement globales dans la plupart des circonstances.

De nombreux administrateurs Configuration Manager suivent les instructions fournies dans Recommandations et instructions pour l’option de configuration « degré maximal de parallélisme » dans SQL Server. Sur la plupart des grands matériels modernes, ce guide aboutit à un paramètre maximal suggéré de huit. Toutefois, si vous exécutez de nombreuses requêtes plus petites par rapport à votre nombre de processeurs, il peut être utile de la définir sur un nombre plus élevé. Le fait de vous limiter à huit n’est pas nécessairement le meilleur paramètre sur les sites plus volumineux lorsque davantage de cœurs sont disponibles.

Sur les serveurs SQL Server avec plus de huit cœurs, commencez par un paramètre 0 et apportez des modifications uniquement si vous rencontrez des problèmes de performances ou un verrouillage excessif. Si vous devez modifier MaxDOP parce que vous rencontrez des problèmes de performances à 0, commencez par une nouvelle valeur au moins supérieure ou égale au nombre minimal recommandé de cœurs pour le dimensionnement SQL Server de ce site. Le fait d’être inférieur à cette valeur a presque toujours des conséquences négatives sur les performances. Par exemple, un SQL Server distant pour un site client de 100 000 nécessite au moins 12 cœurs. Si votre SQL Server a 16 cœurs, commencez à tester votre paramètre MaxDOP avec la valeur 12.

Veillez à désactiver la protection antivirus sur n’importe quel système. Dans les environnements sécurisés et à volume élevé, nous vous recommandons de désactiver la surveillance active pour optimiser les performances.

Pour plus d’informations sur les exclusions antivirus recommandées, consultez Exclusions antivirus recommandées pour Configuration Manager 2012 et les serveurs de site, systèmes de site et clients Current Branch.

La modification de quelques paramètres IIS clés, tels que la longueur de la file d’attente WsusPool et la limite de mémoire privée WsusPool, peut améliorer les performances WSUS, même sur des installations plus petites. Pour plus d’informations, consultez Matériel recommandé.

Vérifiez également que les dernières mises à jour sont installées pour le système d’exploitation exécutant WSUS :

• Windows Server 2012 : toute mise à jour cumulative non « Sécurité uniquement » publiée en octobre 2017 ou version ultérieure. (KB4041690)
• Windows Server 2012 R2 : toute mise à jour cumulative non « Sécurité uniquement » publiée en août 2017 ou version ultérieure. (KB4039871)
• Window Server 2016 : toute mise à jour cumulative non « Sécurité uniquement » publiée en août 2017 ou version ultérieure. (KB4039396)

Consultez le guide complet pour Microsoft maintenance de WSUS et Configuration Manager SUP.

L’analyse traditionnelle des performances des serveurs fonctionne efficacement pour les Configuration Manager générales. Vous pouvez également tirer parti des différents packs d’administration System Center Operations Manager pour Configuration Manager, SQL Server et Windows Server pour surveiller l’intégrité de base de vos serveurs. Vous pouvez également surveiller directement les compteurs Windows Analyseur de performances (PerfMon) que Configuration Manager fournit. Surveillez les backlogs dans les différentes boîtes de réception à la recherche de signes avant-coureurs de problèmes de performances de site potentiels ou de backlogs.

Voir aussi

• Recommandations en matière de dimensionnement et de performances du site
• Configuration Manager questions fréquentes (FAQ) sur Azure