Partager via

Composants et threads pour la distribution de contenu

  • Article

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 composants principaux utilisés pour la distribution de contenu :

Nom Nom du composant Nom convivial 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 Lance des communications intersite sur des réseaux TCP/IP
Déspooler SMS_DESPOOLER Déspooler Traite les fichiers de réplication entrants à partir de sites parents ou enfants
Scheduler SMS_SCHEDULER Scheduler Crée des travaux d’expéditeur
Moniteur de notification de base de données SMS_DATABASE_NOTIFICATION_MONITOR SmsDbMon Surveille 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 écriture à la base de données Configuration Manager sur un site
Fournisseur SMS DP Fournisseur SMS DP 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 Data Transfer Service est un composant de CcmExec responsable du téléchargement de 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 des threads DistMgr pour la configuration de thread par défaut :

Diagramme montrant la hiérarchie des threads du Gestionnaire de distribution.

  • 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é au SMS_Executive démarrage du service. Le thread DistMgr principal démarre le traitement de réplication, le gestionnaire dp, le nettoyage du contenu, la surveillance des certificats DP, le déplacement de bibliothèque de contenu, le traitement des modifications de configuration IIS, la réaffectation et la mise à niveau des threads de traitement au démarrage. Il démarre également les threads de traitement de package à la demande lorsqu’une modification de package se produit

    Outre la gestion de 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/d’utilisation sur le dp, etc.).

  • Thread de traitement de 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 DistMgr principal et traite les fichiers suivants dans le DistMgr.box\incoming répertoire :

    Fichier Description
    . STA Met à jour l’état du package 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é vers le dp spécifié.
    . PUL Met à jour la réponse du package DP pull dans la PullDPResponse table de la base de données.

    Note

    Ce thread est monothread et ne crée pas de threads supplémentaires pour traiter l’un de 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 thread DistMgr principal et traite la suppression de DPs lors de la détection d’une modification d’un 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 (DP Notification) qui DistMgr.box est traité par ce thread.

    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).

    Note

    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 thread DistMgr principal 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 la taille de lot par défaut de 50 pour le nombre de contenu qu’il peut demander à un DP distant de supprimer à la fois. Toutefois, cette valeur peut être substitué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.

    Note

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

  • Thread de surveillance des certificats 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 thread DistMgr principal. Ce thread traite . Fichiers CER et configure la liaison de certificat dans IIS lorsque le mode HTTP amélioré est activé. Ce mode nécessite l’utilisation de certificats générés par Configuration Manager dans IIS.

    Note

    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 thread DistMgr principal et déplace la bibliothèque de contenu vers le nouvel emplacement après un . Le fichier CML est supprimé dans DistMgr.box.

    Note

    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 thread DistMgr principal et gère la configuration des répertoires virtuels IIS pour les points de distribution standard et d’extraction une fois les fichiers IIS supprimés DistMgr.box. Ce thread lit la IISConfigChangeThreadLimit propriété SCF (Site Control File) du composant pour SMS_DISTRIBUTION_MANAGER déterminer le nombre de threads qu’il peut commencer à effectuer simultanément des modifications IIS. La valeur par défaut de IISConfigChangeThreadLimit la 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.

    Note

    Ce thread crée davantage de 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 DistMgr principal 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 pour SMS_DISTRIBUTION_MANAGER déterminer le nombre de threads qu’il peut commencer à effectuer simultanément des réaffectations DP. La valeur par défaut de SharedDPImportThreadLimit la 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.

    Note

    Ce thread crée davantage de 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 DistMgr principal 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 à mettre à niveau. Ce thread lit la DPUpgradeThreadLimit propriété SCF (Site Control File) pour SMS_DISTRIBUTION_MANAGER le composant afin de déterminer le nombre de threads qu’il peut commencer pour effectuer simultanément des installations/mises à niveau DP. La valeur par défaut de DPUpgradeThreadLimit la 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.

    Note

    Ce thread crée davantage de threads pour effectuer le travail d’installation/de mise à niveau dp. Chaque thread de travail gère l’installation/la mise à niveau d’une 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 thread DistMgr principal. Le nombre de threads de traitement de package est déterminé par le nombre maximal de threads de packages dans les propriétés de configuration du composant de distribution logicielle. Chaque thread de traitement de package effectue le hachage du contenu du package et crée une copie compressée du contenu.

    Note

    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 du contenu à la fois. Si un tas de nouveaux packages volumineux sont créés et distribués, les threads par package peuvent bloquer dans une chaîne en attendant leur tour pour obtenir le verrou de compression.

    Selon les actions de package (ajouter/mettre à jour/supprimer), 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 les threads maximum par paramètre de package dans les propriétés de configuration du composant de distribution logicielle.

    Note

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

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 spécifique à chaque site et est accessible en cliquant avec le bouton droit sur le site sous le nœud Sites et en sélectionnant Configurer la distribution logicielle des composants>de site. Voici un aperçu de la configuration par défaut :

Capture d’écran du composant de distribution de logiciels Fenêtre Propriétés.

Dans la plupart des cas, vous ne serez concerné que par le nombre maximal de packages et le nombre maximal de threads par paramètre de package.

  • Nombre maximal de packages : spécifie le nombre maximal de packages que ConfigMgr peut 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 affectés à chaque package pendant la distribution. La valeur spécifiée doit être comprise entre 1 et 999.

La configuration par défaut du nombre maximal de packages=3 et nombre maximal de threads par package=5 peut également être référencée sur 3x5. Il s’agit de la façon dont la configuration du thread sera 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 de 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 P/S :

Le diagramme montre comment DistMgr traite trois packages en même temps lorsque la configuration de thread = 3x5.

Pour traiter chaque package individuel, un thread de traitement de package est généré par le thread DistMgr principal. Ce thread de traitement de package utilise un des trois emplacements de traitement de package à partir du nombre maximal de packages définis. 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 DPS 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 pour PkgXferMgr est définie sur 15, ce qui signifie que PkgXferMgr ne peut pas fonctionner simultanément sur plus de 15 travaux, ce qui le limite à 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 de contenu réelle vers 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, recherchez le choix des valeurs appropriées (plus d’informations ci-dessous).

Threads PkgXferMgr

Pour les adresses DEP 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 ces threads puissent 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 un backlog de travaux dans la file d’attente.

Pour les fournisseurs de services d’extraction, les threads PkgXferMgr informent le dp pull, demandant au dp collecteur de télécharger le contenu. Par conséquent, la durée de vie des threads PkgXferMgr pour les adresses IP pull est courte. PkgXferMgr démarre un autre thread pour effectuer une interrogation par tirage (basée sur l’intervalle d’interrogation configuré) pour vérifier 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. Prenons l’environnement Configuration Manager hypothétique suivant :

  • Site d’administration centrale : CS1
  • Site principal : PS1
  • Nombre de points de distribution standard signalés à PS1 : 200
  • Nombre total de packages : 1 000

Dans cet environnement, la configuration de thread par défaut (3x5) signifie que si un nouveau package doit être distribué à toutes les 200 adresses IP, nous traiterons uniquement 5 adresses IP à la fois. Une fois qu’un thread DP s’arrête, un autre thread DP se génère et le processus continue jusqu’à ce que tous les fournisseurs de services soient traités. Ce processus prendra un certain temps pour parcourir toutes les 200 adresses IP.

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 la configuration réseau entre le serveur de site et ces fournisseurs de services est-elle activée ?

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 à 200, ce qui permet à Configuration Manager d’envoyer jusqu’à cinq packages simultanément à tous les 200 DPS. Toutefois, cela signifie qu’en cas de charge moyenne supérieure à la charge moyenne, nous pouvons créer jusqu’à 1 000 threads, ce qui est de nombreux threads. D’autres threads sont généralement bons, mais pas toujours, car le travail en cours d’exécution s’appuie également sur des configurations matérielles et réseau. Trop de threads peuvent parfois entraîner des goulots d’étranglement et ralentir les choses au lieu de les améliorer.

La chose la plus importante à mémoriser lors de la configuration de ces paramètres consiste à trouver un équilibre. Pour l’exemple ci-dessus, une option raisonnable consisterait à définir la configuration du thread sur 5x100 (ou même 5 x 50 en fonction du matériel/réseau) qui permet toujours à Configuration Manager de traiter jusqu’à 100 adresses IP 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épasse pas 500.

Note

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 , et ainsi de suite.

Dans la même hiérarchie, vous pouvez rencontrer une situation où vous apportez un nouveau DP dans l’environnement et que vous devez distribuer tous les 1 000 packages au DP. Dans ce cas, la configuration de thread de 5x100 n’est pas efficace, car nous ne pouvons traiter que 5 packages à la fois, et le traitement d’un package de 1000 prend beaucoup de temps. Dans ce scénario, vous pouvez choisir d’effectuer les opérations suivantes :

  • Définissez temporairement la configuration du thread sur quelque chose comme 50 x 10 qui est plus adapté à l’exigence actuelle, mais n’est pas une bonne option dans le long terme, compte tenu de la présence de 200 adresses IP.
  • Définissez définitivement la configuration de thread sur quelque chose comme 20x25 qui offre un équilibre bien meilleur et offre des performances similaires dans un scénario où plus de packages doivent aller à une poignée de fournisseurs de services, ainsi qu’un scénario où une poignée de packages doivent aller à de nombreuses adresses IP.

Important

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

Configuration du thread d’expéditeur

Chaque site Configuration Manager (y compris le site d’administration centrale et les sites secondaires) a un expéditeur. L'expéditeur gère la connexion réseau entre un site et un site de destination et peut établir des connexions vers plusieurs sites à la fois. Pour se connecter à un site, l'expéditeur utilise l'itinéraire de réplication de fichiers vers le site pour 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 spécifique à 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 :

Capture d’écran montrant des informations sous l’onglet Expéditeur dans le site principal ConfigMgr Fenêtre Propriétés.

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 à tous pour le même site, sauf si elles sont limitées par la valeur maximale spécifiée dans chaque site.

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

Note

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 aux threads configurés pour le paramètre de site. Si le nombre total de threads d’envoi est égal au nombre configuré pour être utilisé par site et qu’un site de réception n’est pas disponible, il peut entraîner l’utilisation de tous les threads d’envoi lors de la tentative de communication avec le site indisponible et d’empêcher la communication de site à site vers d’autres sites.

Ce que cela signifie

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. En dehors du nombre total de threads pour tous les sites, vous pouvez allouer un nombre maximal de threads sous Chaque site qui peut être utilisé 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 sont disponibles 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 davantage de fichiers en même temps. Cela a également pour effet d'augmenter la demande en bande passante entre les sites.

Choisir les valeurs appropriées

Pour déterminer les valeurs appropriées pour ces paramètres, vous devez d’abord comprendre la hiérarchie Configuration Manager. Prenons l’environnement 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 de thread d’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 (supposons PS1), en laissant seulement 2 threads pour les sites restants. En dehors des 2 threads restants, l’expéditeur peut utiliser 1 pour PS2 et l’autre pour PS3 utilisant les cinq threads autorisés ne laissant aucune place pour envoyer des données simultanément à PS4. À ce stade, l’expéditeur devra 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 pourra ensuite utiliser un autre thread pour envoyer plus 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 la définition de la valeur De tous les sites sur 40.

Note

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 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 des itinéraires de réplication de fichiers pour les sites. Les contrôles de planification et de limitation du 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é Package Transfer Manager.

Pour le composant Package Transfer Manager (pour le serveur de site - >DP), les paramètres de limitation sont configurés dans les propriétés d’un point de distribution standard qui ne se trouve pas sur un serveur de site.

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

Note

Les paramètres de temps 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é :

  • Ouvrez pour toutes les priorités : Spécifie que Configuration Manager envoie des données au point de distribution sans restrictions.

  • Autorisez la priorité moyenne et élevée : Spécifie que Configuration Manager envoie uniquement des données de priorité moyenne et élevée au point de distribution.

  • Autoriser la 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

Cela permet de configurer des limites de débit pour contrôler la bande passante réseau en cours d’utilisation 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 restrictions 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 sur 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 du lien 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 les réseaux disponibles, mais divise plutôt le temps qu’il peut envoyer des données en tranches de temps. Ensuite, les données sont envoyées pendant un court bloc de temps, 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 les données pendant une période suivie d’une période égale lorsqu’aucune donnée n’est envoyée. La taille effective des donnés ou la taille des blocs de données ne sont pas gérées. En revanche, seule la durée pendant laquelle des 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 d’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.

Note

Cela s'applique même lorsque l'option Limiter la 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 :

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

Mode Pulse :

~Addres à DPNAME.CONTOSO.COM est actuellement en mode pulse, donc une seule connexion est autorisée.
~Abandon de la demande d’envoi, car une seule connexion est autorisée en mode pulse.

Sender.log affiche des entrées similaires lorsque la limitation de bande passante est configurée.