Composants et threads pour la distribution de contenu

Cet article vous aide à comprendre les composants et les threads pour la distribution de contenu.

Version du produit d’origine : Configuration Manager Current Branch, Microsoft System Center 2012 Configuration Manager, Microsoft System Center 2012 R2 Configuration Manager

Composants utilisés pour la distribution de contenu

Voici une liste rapide des principaux composants utilisés pour la distribution de contenu :

Nom	Nom du composant	Nom facile à retenir	Description
Gestionnaire de distribution	SMS_DISTRIBUTION_MANAGER	DistMgr	Gère le contenu et crée des travaux pour PkgXferMgr
Gestionnaire de transfert de package	SMS_PACKAGE_TRANSFER_MANAGER	PkgXferMgr	Transfère des packages vers des points de distribution
Gestionnaire de hiérarchie	SMS_HIERARCHY_MANAGER	Hman	Traite et réplique les modifications apportées à la hiérarchie de site
Expéditeur	SMS_SENDER	Expéditeur	Initialise les communications intersite sur les réseaux TCP/IP
Despooler	SMS_DESPOOLER	Despooler	Traite les fichiers de réplication entrants à partir de sites parents ou enfants
Planificateur	SMS_SCHEDULER	Planificateur	Crée des travaux de l’expéditeur
Moniteur de notification de base de données	SMS_DATABASE_NOTIFICATION_MONITOR	SmsDbMon	Surveille la base de données pour les modifications apportées à certaines tables et crée des fichiers dans les boîtes de réception des composants responsables du traitement de ces modifications
Fournisseur SMS	Fournisseur SMS	SMSProv	Fournisseur WMI (Windows Management Instrumentation) qui attribue un accès en lecture et en écriture à la base de données Configuration Manager sur un site
Fournisseur DP SMS	Fournisseur DP SMS	SMSDPProv	Fournisseur WMI (Windows Management Instrumentation) qui gère les opérations de bibliothèque de contenu sur le dp
Hôte de l’agent SMS	Hôte de l’agent SMS	CcmExec	L’hôte de l’agent SMS est le service d’agent client Configuration Manager qui héberge également des composants côté serveur, tels que le point de gestion et le point de distribution d’extraction
Service de transfert de données	DataTransferService	DTS	Le service de transfert de données est un composant de CcmExec responsable du téléchargement des fichiers via BITS.

Threads du Gestionnaire de distribution (DistMgr)

Le Gestionnaire de distribution (DistMgr) effectue diverses opérations pour distribuer du contenu aux points de distribution (DPs). Ces opérations sont gérées par les différents types de threads, et le diagramme ci-dessous explique la hiérarchie de threads DistMgr pour la configuration de thread par défaut :

• Thread DistMgr principal

  Entrée de journal pour l’identification : SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER as thread ID 3648 (0xE40)

  Ce thread est démarré par SMS_Executive au démarrage du service. Le thread main DistMgr démarre le traitement de la réplication, dp Manager, le nettoyage du contenu, la surveillance des certificats DP, le déplacement de la bibliothèque de contenu, le traitement des modifications de configuration IIS, la réaffectation dp et la mise à niveau des threads de traitement au démarrage. Il démarre également les threads de traitement de package à la demande lorsqu’un changement de package se produit

  En plus de gérer ces threads, ce thread gère également les modifications apportées au fichier de contrôle de site et met à jour les paramètres dp (configurer DP/PXE, mettre à jour les paramètres du Registre, créer des tâches de surveillance/utilisation sur le dp, etc.).

• Thread de traitement de la réplication

  Entrée de journal pour l’identification : Starting thread for processing replication, thread ID = 0x1A14 (6676)

  Ce thread est démarré par le thread main DistMgr et traite les fichiers suivants dans le DistMgr.box\incoming répertoire :

  Fichier	Description
  . STA	Mises à jour package status dans la PkgStatus table de la base de données.
  . FWD	Transfère le package spécifié au site de destination spécifié en créant un mini-travail pour envoyer le package.
  . DMD	Distribue les demandes à la demande. Cible le package spécifié sur le dp spécifié.
  . PUL	Mises à jour réponse de package pull DP dans la PullDPResponse table de la base de données.

  Remarque

  Ce thread est monothread et ne crée pas d’autres threads pour traiter ces fichiers.

• Thread du gestionnaire dp

  Entrée de journal pour l’identification : Starting the DP Manager thread, thread ID = 0x5D8 (1496)

  Ce thread est démarré par le main thread DistMgr et traite la suppression des DPS lors de la détection d’une modification de fichier de contrôle de site. Lorsqu’une modification appropriée du fichier de contrôle de site se produit, SMSDBMON supprime un fichier DPN (notification DP) dans DistMgr.box lequel ce thread traite.

  Les fichiers DPN sont utilisés pour notifier une modification dp, ce qui implique la suppression de dp (détectée par Action = 3 dans la DistributionPoints table).

  Remarque

  Ce thread est monothread et ne crée pas d’autres threads pour effectuer le travail.

• Thread de nettoyage de contenu

  Entrée de journal pour l’identification : Starting the content cleanup thread, thread ID = 0x1604 (5636)

  Ce thread est démarré par le main thread DistMgr et exécute le nettoyage du contenu. Il détermine si le nettoyage du contenu est requis en détectant le contenu orphelin de la base de données. Ce thread utilise une taille de lot par défaut de 50 pour le nombre de contenu qu’il peut indiquer à un dpd distant de supprimer à la fois. Toutefois, cette valeur peut être remplacée en définissant la clé de Registre suivante :

  SMS\Components\SMS_DISTRIBUTION_MANAGER\RemoteContentCleanupBatchSize

  La valeur DWORD peut être comprise entre 1 et 500.

  Remarque

  Ne modifiez pas cette valeur sans consulter un professionnel du support technique Microsoft. Ce thread est monothread et ne crée pas d’autres threads pour effectuer le travail.

• Thread de surveillance de certificat DP

  Entrée de journal pour l’identification : Starting the DP cert monitoring thread, thread ID = 0x7290 (29328)

  Ce thread est démarré par le main thread DistMgr. Ce thread traite . CER fichier et configure la liaison de certificat dans IIS lorsque le mode HTTP amélioré est activé. Ce mode nécessite l’utilisation de Configuration Manager certificats générés dans IIS.

  Remarque

  Ce thread est monothread et ne crée pas d’autres threads pour effectuer le travail.

• Thread de déplacement de bibliothèque de contenu

  Entrée de journal pour l’identification : Starting the content library move thread, thread ID = 0x11D6C (73068)

  Ce thread est démarré par le main thread DistMgr et déplace la bibliothèque de contenu vers le nouvel emplacement après un . Le fichier CML est supprimé dans DistMgr.box.

  Remarque

  Ce thread est monothread et ne crée pas d’autres threads pour effectuer le travail.

• Thread de traitement des modifications de configuration IIS

  Entrée de journal pour l’identification : Starting the IIS config change processing thread, thread ID = 0x408C (16524)

  Ce thread est démarré par le main thread DistMgr et gère la configuration des répertoires virtuels IIS pour les points de distribution standard et d’extraction après la suppression des fichiers IIS dans DistMgr.box. Ce thread lit la IISConfigChangeThreadLimit propriété SCF (Site Control File) du composant afin SMS_DISTRIBUTION_MANAGER de déterminer le nombre de threads qu’il peut démarrer pour effectuer des modifications IIS simultanément. La valeur par défaut de la IISConfigChangeThreadLimit propriété SCF est 50, mais elle peut être modifiée si nécessaire. Toutefois, si cette propriété SCF n’existe pas pour une raison quelconque, la valeur par défaut 50 est utilisée pour IISConfigChangeThreadLimit.

  Remarque

  Ce thread crée d’autres threads pour effectuer des modifications de configuration IIS DP. Chaque thread de travail gère la configuration des répertoires virtuels IIS d’un dp spécifique.

• Thread de réaffectation dp

  Entrée de journal pour l’identification : Starting the shared DP reassignment thread, thread ID = 0x9C0C (39948)

  Ce thread est démarré par le thread d’main DistMgr et gère les réaffectations DP pour les points de distribution standard et d’extraction lorsqu’un . Le fichier DPU est supprimé dans DistMgr.box. Ce thread lit la SharedDPImportThreadLimit propriété SCF (Site Control File) du composant afin SMS_DISTRIBUTION_MANAGER de déterminer le nombre de threads qu’il peut démarrer pour effectuer des réaffectations dp simultanément. La valeur par défaut de la SharedDPImportThreadLimit propriété SCF est 50, mais elle peut être modifiée si nécessaire. Toutefois, si cette propriété SCF n’existe pas pour une raison quelconque, la valeur par défaut 50 est utilisée pour SharedDPImportThreadLimit.

  Remarque

  Ce thread crée d’autres threads pour effectuer des réaffectations DP. Chaque thread de travail gère la réaffectation d’un DP spécifique.

• Mettre à niveau le thread de traitement

  Entrée de journal pour l’identification : Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)

  Ce thread est démarré par le thread main DistMgr et gère les installations et mises à niveau dp pour les points de distribution standard et d’extraction. Il appelle spGetDPsForUpgrade pour obtenir la liste des fournisseurs de services qui doivent être mis à niveau. Ce thread lit la DPUpgradeThreadLimit propriété SCF (Site Control File) du composant afin SMS_DISTRIBUTION_MANAGER de déterminer le nombre de threads qu’il peut démarrer pour effectuer simultanément des installations/mises à niveau dp. La valeur par défaut de la DPUpgradeThreadLimit propriété SCF est 50, mais elle peut être modifiée si nécessaire. Toutefois, si cette propriété SCF n’existe pas pour une raison quelconque, la valeur par défaut 5 est utilisée pour DPUpgradeThreadLimit.

  Remarque

  Ce thread crée d’autres threads pour effectuer un travail d’installation/mise à niveau dp. Chaque thread de travail gère l’installation/la mise à niveau d’un dp spécifique.

• Thread de traitement de package

  Entrée de journal pour l’identification : Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)

  Ces threads sont démarrés par le main thread DistMgr. Le nombre de threads de traitement de package est déterminé par le paramètre Nombre maximal de threads de packages dans les propriétés Configuration du composant de distribution de logiciels . Chaque thread de traitement de package effectue le hachage du contenu du package et crée une copie compressée du contenu.

  Remarque

  Bien que tous les threads de traitement de package s’exécutent simultanément, ils sont responsables du hachage et de la compression de la source du package. Il existe une section critique autour de la compression, ce qui signifie qu’un seul thread peut compresser le contenu à la fois. Si un ensemble de nouveaux packages volumineux sont créés et distribués, les threads par package peuvent se bloquer dans une chaîne en attente de leur tour pour obtenir le verrou de compression.

  En fonction des actions de package (ajout/mise à jour/suppression), chaque thread de traitement de package crée également :

  • Threads DP pour créer un travail Package Transfer Manager pour ajouter/mettre à jour du contenu sur un dp.
  • Threads DP pour indiquer à un point de distribution distant de supprimer du contenu de la bibliothèque de contenu.

  Le nombre de threads DP que chaque thread de traitement de package peut créer est déterminé par le paramètre Nombre maximal de threads par package dans les propriétés Configuration du composant de distribution de logiciels.

  Remarque

  Les threads de traitement de package sont multithreads et chaque thread de traitement de package crée d’autres threads pour effectuer le travail. Chaque thread de travail gère les opérations d’ajout/mise à jour/suppression pour les fournisseurs de services.

Configuration du thread Du gestionnaire de distribution

Tous les sites Configuration Manager (y compris le site d’administration centrale) permettent de configurer le nombre de threads qui peuvent être utilisés pour distribuer du contenu aux points de distribution (DPs). Cette configuration est propre à chaque site et est accessible en cliquant avec le bouton droit sur le site sous le nœud Sites et en sélectionnant Configurer ladistribution de logiciels composants > de site. Voici un aperçu de la configuration par défaut :

Dans la plupart des cas, vous êtes uniquement concerné par les paramètres Nombre maximal de packages et Nombre maximal de threads par package .

• Nombre maximal de packages : spécifie le nombre maximal de packages que ConfigMgr pouvez envoyer simultanément aux fournisseurs de services. La valeur spécifiée doit être comprise entre 1 et 50.
• Nombre maximal de threads par package : spécifie le nombre maximal de threads attribués à chaque package pendant la distribution. La valeur spécifiée doit être comprise entre 1 et 999.

La configuration par défaut nombre maximal de packages=3 et nombre maximal de threads par package=5 peut également être appelée 3x5. C’est ainsi que la configuration du thread est souvent indiquée dans le flux de travail.

Ce que cela signifie vraiment

Effet sur le gestionnaire de distribution (DistMgr)

Avec la configuration de thread par défaut 3x5, DistMgr peut traiter simultanément trois packages et utiliser jusqu’à cinq threads pour chaque package, ce qui lui permet d’utiliser jusqu’à un total de 15 threads pour effectuer le travail. Voici comment cela se décompose en supposant que nous avons plus de trois packages qui doivent être distribués à plus de 5 DPS :

Pour traiter chaque package individuel, un thread de traitement de package est généré par le main thread DistMgr. Ce thread de traitement de package utilise un emplacement de traitement de package sur trois à partir du paramètre Nombre maximal de packages . Il existe un thread de traitement de package unique par package : DistMgr ne démarre pas plusieurs threads de traitement de package pour le même package. Cela signifie que trois packages uniques utilisent trois threads de traitement de package uniques. Chacun de ces threads de traitement de package peut générer jusqu’à cinq threads DP pour distribuer le package à cinq fournisseurs de données simultanément.

Effet sur package Transfer Manager (PkgXferMgr)

Pour chaque travail PkgXferMgr créé par DistMgr, PkgXferMgr utilise un thread. La configuration de thread de 3x5 signifie que la capacité d’envoi de PkgXferMgr est définie sur 15, ce qui signifie que PkgXferMgr ne peut pas travailler sur plus de 15 travaux simultanément, la limitant à un maximum de 15 threads.

Durée d’exécution d’un thread

Threads DistMgr

L’objectif d’un thread DP est de créer un travail pour Package Transfer Manager, qui effectue ensuite la copie du contenu réel dans le dp. Les threads DP se terminent après la création du travail PkgXferMgr et, par conséquent, la durée de vie d’un thread DP est courte. En raison de cette nature, la plupart du temps, il n’est pas nécessaire de configurer une configuration de thread agressive pour accélérer la distribution de contenu. Au lieu de définir des valeurs agressives, regardez Choisir les bonnes valeurs (plus d’informations ci-dessous).

Threads PkgXferMgr

Pour les fournisseurs de données standard, étant donné que les threads PkgXferMgr effectuent le travail réel d’envoi du contenu, la durée de vie de ces threads dépend de la taille des packages. Pour les packages plus volumineux, ces threads peuvent prendre beaucoup de temps en fonction de la taille du package et de la vitesse du réseau. Bien que l’exécution de ces threads puisse prendre beaucoup de temps, la durée de vie des threads DistMgr est beaucoup plus courte, ce qui signifie que DistMgr peut mettre en file d’attente un grand nombre de travaux pour PkgXferMgr, créant ainsi un backlog de travaux dans la file d’attente.

Pour les fournisseurs de données pull, les threads PkgXferMgr informent le dp de tirage, en demandant au dp de tirage de télécharger le contenu. Par conséquent, la durée de vie des threads PkgXferMgr pour les DPs de tirage est courte. PkgXferMgr démarre un autre thread pour effectuer l’interrogation dp (en fonction de l’intervalle d’interrogation configuré) pour case activée sur la progression du travail. Toutefois, il s’agit également d’une opération rapide et ces threads ont également une courte durée de vie.

Choix des valeurs appropriées

Pour déterminer les valeurs appropriées pour ces paramètres, vous devez d’abord comprendre la hiérarchie Configuration Manager. Examinons l’environnement de Configuration Manager hypothétique suivant :

• Site d’administration centrale : CS1
• Site principal : PS1
• Nombre de points de distribution réguliers signalés à PS1 : 200
• Nombre total de packages : 1000

Dans cet environnement, la configuration de thread par défaut (3x5) signifie que si un nouveau package doit être distribué aux 200 fournisseurs de services, nous ne traiterons que 5 points de service à la fois. Une fois qu’un thread DP se termine, un autre thread DP est généré et le processus se poursuit jusqu’à ce que tous les fournisseurs de données soient traités. Ce processus prendra un certain temps pour parcourir les 200 points de service.

Pour optimiser cela, nous devons d’abord poser quelques questions :

1. Combien de packages prévoyez-vous d’être ajoutés/mis à jour/distribués simultanément en moyenne ?
2. Combien de DPs avez-vous dans le site ? Comment est la configuration réseau entre le serveur de site et ces fournisseurs de services ?

En supposant que la réponse à la première question est 5 et que la réponse à la deuxième question est 200 avec une bonne connectivité réseau, vous pouvez théoriquement définir le nombre maximal de packages sur 5 et le nombre maximal de threads par package sur 200, ce qui permet à Configuration Manager d’envoyer jusqu’à cinq packages à l’ensemble des 200 fournisseurs de services simultanément. Toutefois, cela signifie que lorsque la charge est supérieure à la charge moyenne, nous pouvons créer jusqu’à 1 000 threads, ce qui représente un grand nombre de threads. Plus de threads sont généralement bons, mais pas toujours, car le travail en cours s’appuie également sur les configurations matérielles et réseau. Un trop grand nombre de threads peut parfois entraîner des goulots d’étranglement et ralentir les choses au lieu de les améliorer.

La chose la plus importante à retenir lors de la configuration de ces paramètres est de trouver un équilibre. Pour l’exemple ci-dessus, une option raisonnable consiste à définir la configuration du thread sur 5x100 (ou même 5x50 en fonction du matériel/réseau), ce qui permet à Configuration Manager de traiter jusqu’à 100 DPS simultanément pour cinq packages différents. Avec ces paramètres, le nombre maximal de threads pouvant être générés pendant une charge élevée ne dépassera pas 500.

Remarque

En règle générale, il est recommandé que le nombre total de threads ne dépasse pas 750. Cela signifie que vous pouvez définir la configuration du thread sur 3x250, 5x150, 10x75 , etc.

Dans la même hiérarchie, vous pouvez vous trouver dans une situation où vous apportez un nouveau dp dans l’environnement et que vous devez distribuer les 1 000 packages au dp. Dans ce cas, la configuration de thread de 5x100 ne sera pas efficace, car nous ne pouvons traiter que 5 packages à la fois, et le traitement d’un 1 000 packages prendra beaucoup de temps. Dans ce scénario, vous pouvez choisir :

• Définissez temporairement la configuration du thread sur quelque chose comme 50x10 qui est plus adapté à la configuration actuelle, mais ce n’est pas une bonne option à long terme, étant donné que nous avons 200 DPS.
• Définissez de façon permanente la configuration du thread sur quelque chose comme 20x25 qui fournit un bien meilleur équilibre et offre des performances similaires dans un scénario où davantage de packages doivent aller à une poignée de DPS, ainsi qu’un scénario où une poignée de packages doivent aller à de nombreux DPS.

Importante

Il n’existe pas de recommandation définie sur les valeurs pour la configuration de thread ; elle varie pour chaque environnement et doit être définie après avoir compris votre environnement et vos exigences. N’oubliez pas de trouver un équilibre !

Configuration du thread de l’expéditeur

Chaque Configuration Manager site (y compris le site d’administration centrale et les sites secondaires) a un expéditeur. L’expéditeur gère la connexion réseau d’un site à un site de destination et peut établir des connexions à plusieurs sites en même temps. Pour se connecter à un site, l’expéditeur utilise l’itinéraire de réplication de fichiers vers le site afin d’identifier le compte à utiliser pour établir la connexion réseau. L’expéditeur utilise également ce compte pour écrire des données dans le partage du site de SMS_SITE destination.

Par défaut, l’expéditeur écrit des données dans un site de destination à l’aide de plusieurs threads simultanés. Chaque thread simultané peut transférer un objet basé sur un fichier différent vers le site de destination. Par défaut, lorsque l’expéditeur commence à envoyer un objet, il continue d’écrire des blocs de données pour cet objet jusqu’à ce que l’objet entier soit envoyé.

Tous les sites Configuration Manager vous permettent de configurer le nombre de threads qui peuvent être utilisés par le composant Expéditeur pour envoyer des données simultanément à d’autres sites. Cette configuration est propre à chaque site et est accessible à partir des Propriétés du site sous le nœud Sites en sélectionnant l’onglet Expéditeur . Voici un aperçu de la configuration par défaut :

Tous les sites : nombre maximal de communications simultanées autorisées pour cet expéditeur. La valeur par défaut est 5. Ces communications peuvent être destinées à différents sites ou toutes pour le même site, sauf si elles sont limitées par la valeur maximale spécifiée dans Par site.

Par site : nombre maximal de communications simultanées autorisées vers n’importe quel site de destination unique. La valeur par défaut est 3.

Remarque

Lors de la configuration du nombre total de threads d’envoi simultanés à utiliser lors de la communication avec d’autres sites, le nombre total de threads d’envoi doit être configuré comme un nombre supérieur à celui des threads configurés pour le paramètre par site. Si le nombre total de threads d’envoi est égal au nombre configuré pour être utilisés par site et qu’un site de réception n’est pas disponible, cela peut entraîner l’utilisation de tous les threads d’envoi lors de la tentative de communication avec le site indisponible et empêcher la communication de site à site vers d’autres sites.

Signification

La valeur spécifiée sous Tous les sites définit le nombre total de threads que l’expéditeur peut utiliser pour envoyer des données simultanément à d’autres sites. Sur le nombre total de threads pour Tous les sites, vous pouvez attribuer un nombre maximal de threads sous Par site qui peuvent être utilisés pour envoyer des données à n’importe quel site de destination. Par défaut, chaque site est configuré pour utiliser cinq threads simultanés, dont trois peuvent être utilisés lors de l’envoi de données à un site de destination. Lorsque vous augmentez ce nombre, vous pouvez augmenter le débit des données entre les sites en permettant à Configuration Manager de transférer plusieurs fichiers en même temps. L’augmentation de ce nombre augmente également la demande de bande passante réseau entre les sites.

Choisir les bonnes valeurs

Pour déterminer les valeurs appropriées pour ces paramètres, vous devez d’abord comprendre la hiérarchie Configuration Manager. Examinons l’environnement de Configuration Manager hypothétique suivant :

• Site d’administration centrale : CS1
• Site principal : PS1
• Site principal : PS2
• Site principal : PS3
• Site principal : PS4

Dans cet environnement, la configuration du thread expéditeur par défaut autorise l’utilisation d’un total de 5 threads. Sur ces 5 threads, 3 peuvent être utilisés pour l’un des 4 sites principaux de destination. Si un administrateur envoie 3 à tous ces sites, il est possible que l’expéditeur finissent par utiliser trois threads pour l’un de ces sites (disons PS1), ne laissant que 2 threads pour les sites restants. Sur les 2 threads restants, l’expéditeur peut utiliser 1 pour PS2 et l’autre pour PS3 en utilisant les cinq threads autorisés, ne laissant aucune place pour envoyer des données simultanément à PS4. À ce stade, l’expéditeur doit attendre la fin de l’un des 5 threads existants avant de pouvoir envoyer plus de données. Une fois qu’un thread existant est terminé, l’expéditeur peut utiliser un autre thread pour envoyer davantage de données aux sites PS2/PS3/PS4.

Il est recommandé de réserver 10 threads pour chaque site avec lequel l’expéditeur communiquera. Dans ce cas, le site CS1 peut communiquer avec quatre autres sites, ce qui signifie qu’une valeur par site de 10 pour quatre sites nécessite de définir la valeur Tous les sites sur 40.

Remarque

Il s’agit d’une recommandation générale et ces valeurs peuvent nécessiter un ajustement supplémentaire en fonction du nombre de packages qu’un site doit envoyer simultanément à d’autres sites.

Contrôle de la bande passante et threads

Dans Configuration Manager, vous pouvez configurer une planification et définir des paramètres de limitation spécifiques pour les points de distribution distants ainsi que pour les itinéraires de réplication de fichiers pour les sites. Les contrôles de planification et de limitation pour le point de distribution distant sont similaires aux paramètres d’une adresse d’expéditeur standard, mais dans ce cas, les paramètres sont utilisés par un composant appelé Gestionnaire de transfert de package.

Pour le composant Gestionnaire de transfert de package (pour serveur de site - >DP), les paramètres de limitation sont configurés dans les propriétés d’un point de distribution standard qui n’est pas sur un serveur de site.

Pour le composant Expéditeur (pour Serveur< de site-Serveur> de site), les paramètres de limitation sont configurés dans les propriétés de l’itinéraire de réplication de fichiers sousRéplication du fichierde configuration> de hiérarchie.

Remarque

Les paramètres d’heure sont basés sur le fuseau horaire du site d’envoi, et non sur le point de distribution.

Options de planification

Pour restreindre les données, sélectionnez la période, puis sélectionnez l’un des paramètres suivants pour la disponibilité :

• Ouvrir pour toutes les priorités : spécifie que Configuration Manager envoie des données au point de distribution sans restriction.

• Autoriser les priorités moyennes et élevées : spécifie que Configuration Manager envoie uniquement des données de priorité moyenne et élevée au point de distribution.

• Autoriser une priorité élevée uniquement : spécifie que Configuration Manager envoie uniquement des données de priorité élevée au point de distribution.

• Fermé : spécifie que Configuration Manager n’envoie aucune donnée au point de distribution.

  Vous pouvez restreindre les données par priorité ou fermer la connexion pour les périodes sélectionnées.

Options de limite de débit

Il est utilisé pour configurer des limites de débit afin de contrôler la bande passante réseau utilisée lors du transfert de contenu vers le point de distribution. Vous pouvez choisir parmi les options suivantes :

• Illimité lors de l’envoi à cette destination : spécifie que Configuration Manager envoie du contenu au point de distribution sans restriction de limite de débit.
• Mode d’impulsion : spécifie la taille des blocs de données envoyés au point de distribution. Vous pouvez également spécifier un délai entre l’envoi de chaque bloc de données. Utilisez cette option lorsque vous devez envoyer des données via une connexion réseau à faible bande passante au point de distribution. Par exemple, vous pouvez avoir des contraintes pour envoyer 1 Ko de données toutes les cinq secondes, quelle que soit la vitesse de la liaison ou son utilisation à un moment donné.
• Limité aux taux de transfert maximum spécifiés par heure : spécifiez ce paramètre pour qu’un site envoie des données à un point de distribution en utilisant uniquement le pourcentage de temps que vous configurez. Lorsque vous utilisez cette option, Configuration Manager n’identifie pas la bande passante disponible des réseaux, mais divise à la place la durée d’envoi des données en tranches de temps. Ensuite, les données sont envoyées pendant un court bloc de temps, qui est suivi de blocs de temps lorsque les données ne sont pas envoyées. Par exemple, si le taux maximal est défini sur 50 %, Configuration Manager transmet des données pendant une période suivie d’une période égale lorsque aucune donnée n’est envoyée. La taille réelle des données, ou la taille du bloc de données, n’est pas gérée. Au lieu de cela, seule la durée pendant laquelle les données sont envoyées est gérée.

Pour plus d’informations sur ces paramètres, consultez Configuration de la gestion de contenu dans Configuration Manager.

Comment cela affecte les threads Sender et PkgXferMgr

Lorsque le contrôle de bande passante est activé pour un site, le composant expéditeur ignore la configuration du thread expéditeur pour le site et n’utilise qu’un seul thread pour ce site. De même, lorsque le contrôle de bande passante est activé pour un dp, PkgXferMgr ignore la configuration du thread et n’utilise qu’un seul thread pour le dp.

Remarque

Cela s’applique même lorsque la limite de bande passante disponible (%) est définie sur 100 %.

Lorsque le contrôle de bande passante est en vigueur, PkgXferMgr.log journalisera l’une des lignes suivantes :

Planification:

~L’adresse à DPNAME.CONTOSO.COM est actuellement sous contrôle de bande passante. Par conséquent, une seule connexion est autorisée, renvoyant la demande d’envoi au pool.

Mode d’impulsion :

~Addres to DPNAME.CONTOSO.COM est actuellement en mode pulse, par conséquent une seule connexion est autorisée.
~Abandon de la demande d’envoi, car une seule connexion est autorisée en mode impulsion.

Sender.log affiche des entrées similaires lors de la configuration de la limitation de bande passante.