Composants et threads pour la distribution de contenu

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

Version du produit d’origine :   Branche actuelle du gestionnaire de configuration, gestionnaire de configuration Microsoft System Center 2012, Microsoft System Center 2012 R2 Configuration Manager
Numéro de la base de connaissances initiale :   4482728

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 les packages vers les 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 intersites sur des réseaux TCP/IP
Déspouleur SMS_DESPOOLER Déspouleur 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 Observe 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 du gestionnaire de configuration au niveau d’un site
Fournisseur de service de distribution de SMS Fournisseur de service de distribution de 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 de l’agent client du gestionnaire de configuration qui héberge également les composants côté serveur tels que le point de gestion et le point de distribution de l’extraction
Service de transfert de données DataTransferService TRANSFORMATION Le service de transfert de données est un composant de CcmExec chargé de télécharger des fichiers via BITS.

Threads du gestionnaire de distribution (DistMgr)

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

Hiérarchie de 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é par SMS_Executive le démarrage du service. Le thread principal DistMgr démarre le traitement de la réplication, le gestionnaire DP, le nettoyage de contenu, la surveillance du certificat DP, le déplacement de la bibliothèque de contenu, le traitement des modifications de configuration IIS, le 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’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 de Registre, créer des tâches de surveillance/d’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 principal DistMgr et traite les fichiers suivants dans le DistMgr.box\incoming répertoire :

    Fichier Description
    . STATION Met à jour l’état du package dans la PkgStatus table de la base de données.
    . FWD Transfère le package spécifié vers le 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 de package DP pull dans le PullDPResponse tableau de la base de données.

    Notes

    Ce thread est à thread unique et ne crée pas d’autres threads 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 principal DistMgr et traite la suppression du DPs lors de la détection d’une modification de fichier de contrôle de site. Lorsqu’une modification de fichier de contrôle de site appropriée se produit, SMSDBMON supprime un fichier DPN (notification DP) dans DistMgr.box le cadre du traitement par ce thread.

    Les fichiers DPN sont utilisés pour avertir un changement de DP, qui implique la suppression du DP (détecté par action = 3 dans le DistributionPoints tableau).

    Notes

    Ce thread est à thread unique 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 principal DistMgr et exécute le nettoyage de contenu. Il détermine si le nettoyage de 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 contenus qu’il peut demander de supprimer à la fois un DP distant. 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.

    Notes

    Ne modifiez pas cette valeur sans consulter le support technique Microsoft. Ce thread est à thread unique 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 thread principal DistMgr. Ce thread traite . CER (fichiers) 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 le gestionnaire de configuration dans IIS.

    Notes

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

    Notes

    Ce thread est à thread unique 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 principal DistMgr et gère la configuration des répertoires virtuels IIS pour les points de distribution standard et pull après la suppression des fichiers IIS DistMgr.box . Ce thread lit la IISConfigChangeThreadLimit propriété du fichier de contrôle de site (SCF) du SMS_DISTRIBUTION_MANAGER composant pour déterminer le nombre de threads qu’il peut démarrer pour effectuer les 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 de 50 est utilisée pour IISConfigChangeThreadLimit .

    Notes

    Ce thread crée un plus grand nombre de threads pour effectuer les modifications de configuration IIS DP. Chaque thread de travail gère la configuration des répertoires virtuels IIS d’un point de distribution 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 principal DistMgr et gère les réaffectations DP pour les points de distribution standard et pull lorsqu’un *. * Le fichier DPU est supprimé DistMgr.box . Ce thread lit la SharedDPImportThreadLimit propriété du fichier de contrôle de site (SCF) du SMS_DISTRIBUTION_MANAGER composant pour déterminer le nombre de threads qu’il peut démarrer pour effectuer les 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 de 50 est utilisée pour SharedDPImportThreadLimit .

    Notes

    Ce thread crée un plus grand nombre 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 principal DistMgr et gère les installations et les mises à niveau de DP pour les points de distribution standard et pull. Il appelle spGetDPsForUpgrade pour obtenir la liste des DPS qui doivent être mis à niveau. Ce thread lit la DPUpgradeThreadLimit propriété du fichier de contrôle de site (SCF) du SMS_DISTRIBUTION_MANAGER composant pour déterminer le nombre de threads qu’il peut commencer à effectuer des installations ou des mises à niveau DP simultanément. 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 de 5 est utilisée pour DPUpgradeThreadLimit .

    Notes

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

    Notes

    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 de package. Il y a une section critique sur la compression, ce qui signifie qu’un seul thread peut compresser le contenu à la fois. Si un paquet de nouveaux packages volumineux est créé et distribué, les threads par package peuvent bloquer dans une chaîne en attendant que le verrou de compression soit activé.

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

    • DP threads pour créer un travail du gestionnaire de transfert de package pour l’ajout/la mise à jour de contenu sur un DP.
    • Threads DP pour demander à un point de distribution distant de supprimer le 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 de configuration du composant de distribution de logiciels .

    Notes

    Les threads de traitement de package sont multi-thread et chaque thread de traitement de package crée un plus grand nombre de threads pour effectuer le travail. Chaque thread de travail gère les opérations d’ajout/de mise à jour/suppression pour le DPs.

Configuration du thread du gestionnaire de distribution

Tous les sites gestionnaire de configuration (y compris le site Administration centrale) permettent de configurer le nombre de threads qui peuvent être utilisés pour distribuer le contenu aux points de distribution. Cette configuration est propre à chaque site et peut être accessible en cliquant avec le bouton droit sur le site sous le nœud sites et en sélectionnant Configurer la Configure Site Components > distribution logicielledes composants de site. Voici un aperçu de la configuration par défaut :

Fenêtre Propriétés du composant de distribution de logiciels

Dans la plupart des cas, vous ne vous inquiétez que sur 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 au DPS. 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 lors de 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 le nombre maximal de threads par package = 5 peut également être référencée dans 3x5. Il s’agit de la façon dont la configuration de thread est souvent dénoté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 trois packages simultanément et utiliser jusqu’à cinq threads pour chaque package, ce qui permet d’utiliser jusqu’à 15 threads pour effectuer le travail. Voici comment cela s’arrête en supposant que nous avons plus de trois packages qui doivent être distribués à plus de 5 DPs :

Configuration du thread = 3x5

Pour traiter chaque package individuel, un thread de traitement de package est généré par le thread principal DistMgr. Ce thread de traitement de package utilise un des trois emplacements de traitement de package du 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 utiliseront trois threads de traitement de package uniques. Chacun de ces threads de traitement de package peut engendrer jusqu’à cinq threads DP pour distribuer simultanément le package à cinq DPs.

Effet sur le gestionnaire de transfert de package (PkgXferMgr)

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

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

Threads DistMgr

Le but d’un thread DP est de créer un travail pour le gestionnaire de transfert de package, qui effectue 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, cherchez à choisir les valeurs appropriées (plus d’informations ci-dessous).

Threads PkgXferMgr

Pour standard STD, é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 un certain temps en fonction de la taille du package et de la vitesse du réseau. Bien que ces threads prennent 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 une file d’attente de travaux dans la file d’attente.

Pour le DPs pull, les threads PkgXferMgr informent le DP de type pull, invitant le DP à télécharger le contenu. Par conséquent, la durée de vie des threads PkgXferMgr pour l’extraction de DPs est courte. PkgXferMgr démarre un autre thread pour effectuer une interrogation DP (en fonction de la fréquence d’interrogation configurée) pour vérifier la progression de la tâche. 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 du gestionnaire de configuration. Nous allons étudier l’environnement gestionnaire de configuration hypothétique suivant :

  • Site Administration centrale : CS1
  • Site principal : PS1
  • Nombre de points de distribution réguliers pour 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é à tous les 200 DPS, nous ne traiterons que 5 DPS à la fois. Une fois qu’un thread DP s’arrête, un autre thread DP est généré et le processus se poursuit jusqu’à ce que tous les DPs soient traités. Cette procédure nécessite un certain temps pour parcourir tous les 200 DPs.

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

  1. Combien de packages prévoyez-vous d’ajouter/mettre à jour/distribuer simultanément en moyenne ?
  2. Combien de DPs disposez-vous sur le site ? Quelle est la configuration réseau entre le serveur de site et ces DPs ?

En supposant que la réponse à la première question est de 5, et que la réponse à la deuxième question est de 200 avec une connectivité réseau appropriée, 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 au gestionnaire de configuration d’envoyer jusqu’à cinq packages simultanément à 200 DPS. Toutefois, cela signifie que lorsqu’il y a plus de charge moyenne, nous pouvons créer jusqu’à 1000 threads, ce qui est un grand nombre de threads. D’autres threads sont généralement corrects, mais pas toujours, étant donné que le travail en cours d’exécution s’appuie également sur des configurations matérielles et réseau. Un trop grand nombre de threads peut parfois causer des goulots d’étranglement et ralentir les choses au lieu de les améliorer.

La chose la plus importante à garder à l’esprit 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 toujours au gestionnaire de configuration 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 au cours d’une charge élevée ne dépasse pas 500.

Notes

En règle générale, il est recommandé que le nombre total de threads n’excède 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, il se peut que vous rencontriez un nouveau DP dans l’environnement et que vous deviez distribuer tous les packages 1000 vers le 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 package 1000 prendra beaucoup de temps. Dans ce scénario, vous pouvez choisir l’une des deux méthodes suivantes :

  • Définissez temporairement la configuration du thread sur une valeur telle que 50x10 qui est plus adaptée à l’exigence actuelle, mais n’est pas une option intéressante dans le long terme, sachant que nous disposons de 200 DPS.
  • Définissez de façon permanente la configuration du thread comme 20x25 , ce qui offre un équilibre bien supérieur et offrira des performances similaires dans un scénario où d’autres packages doivent accéder à une poignée de DPS, ainsi qu’un scénario dans lequel un petit nombre de packages doivent accéder à de nombreux services d’accès aux services.

Important

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

Configuration des threads des expéditeurs

Chaque site gestionnaire de configuration (y compris le site 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 le routage de réplication de fichiers 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 destination SMS_SITE .

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 sur le site de destination. Par défaut, lorsque l’expéditeur commence à envoyer un objet, il continue à écrire des blocs de données pour cet objet jusqu’à ce que l’intégralité de l’objet soit envoyé.

Tous les sites gestionnaire de configuration 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 :

Propriétés de site de la base de ConfigMgr

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 à un même site, sauf en cas de limitation par la valeur maximale spécifiée dans chaque site.

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

Notes

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 plus élevé que 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é 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 d’empêcher la communication de site à site à d’autres sites.

Signification

La valeur spécifiée dans 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 peuvent être utilisés pour envoyer des données à un site de destination. Par défaut, chaque site est configuré pour utiliser cinq threads simultanés, trois pouvant ê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 activant le gestionnaire de configuration pour transférer davantage de fichiers en même temps. L’augmentation de ce nombre augmente également la demande de bande passante réseau 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 du gestionnaire de configuration. Nous allons étudier l’environnement gestionnaire de configuration hypothétique suivant :

  • Site Administration centrale : CS1
  • Site principal : PS1
  • Site principal : PS2
  • Site principal : PS3
  • Site principal : PS4

Dans cet environnement, la configuration de threads d’expéditeur par défaut autorise l’utilisation d’un total de 5 threads. À partir de ces 5 threads, 3 peut être utilisé pour l’un des 4 sites principaux de destination. Si un administrateur envoie 3 à tous ces sites, il est possible que l’expéditeur utilise trois threads pour l’un de ces sites (disons PS1), en ne laissant que 2 threads pour les sites restants. Parmi les 2 derniers threads, sender peut utiliser 1 pour PS2 et l’autre pour la PS3 utilisant les cinq threads autorisés ne laissant pas de place pour l’envoi de données en même temps à PS4. À ce stade, l’expéditeur doit attendre que l’un des 5 threads existants se termine avant de pouvoir envoyer davantage de données. Une fois le thread existant terminé, l’expéditeur est en mesure d’utiliser un autre thread pour envoyer des données supplémentaires aux sites PS2/PS3/PS4.

Il est recommandé de geler 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écessitera de définir la valeur de tous les sites sur 40.

Notes

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

Contrôle de bande passante et threads

Dans le gestionnaire de configuration, 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 au 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 le DPde site Server >), 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 de l’expéditeur (pour le serveur de site de site Server <-> Site Server), les paramètres de limitation sont configurés dans les propriétés de l’itinéraire de réplication de fichiers sous la Hierarchy Configuration > réplication de fichierde configuration de la hiérarchie.

Notes

Les paramètres de temps sont basés sur le fuseau horaire du site d’envoi, pas 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: indique que le gestionnaire de configuration envoie des données au point de distribution sans aucune restriction.

  • Autoriser la priorité moyenne et haute: indique que le gestionnaire de configuration envoie uniquement des données de haute priorité à un point de distribution.

  • Autoriser uniquement la haute priorité: indique que le gestionnaire de configuration envoie uniquement les données à priorité haute au point de distribution.

  • Closed: indique que le gestionnaire de configuration 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

Cette commande permet de configurer des limites de taux pour contrôler la bande passante réseau utilisée lors du transfert de contenu vers le point de distribution. Vous pouvez choisir l’une des options suivantes :

  • Unlimited lors de l’envoi vers cette destination: indique que le gestionnaire de configuration envoie le contenu au point de distribution sans aucune restriction de limite de débit.
  • Mode impulsion: spécifie la taille des blocs de données qui sont 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 vers le point de distribution. Par exemple, vous pouvez avoir des contraintes pour envoyer 1 Ko de données toutes les cinq secondes, indépendamment de la vitesse de la liaison ou de son utilisation à un moment donné.
  • Limité à des taux de transfert maximaux 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, le gestionnaire de configuration n’identifie pas la bande passante disponible pour les réseaux, mais il divise le temps qu’il peut envoyer des données en tranches de temps. Les données sont ensuite envoyées pour une courte période de temps, suivie de blocs de temps pendant lesquels les données ne sont pas envoyées. Par exemple, si le taux maximal est défini sur 50%, le gestionnaire de configuration transmet les données pendant une période de temps, suivie d’une période égale lorsqu’aucune donnée n’est envoyée. La taille réelle des données, ou 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 la rubrique configuration de la gestion de contenu dans le gestionnaire de configuration.

Impact de l’expéditeur et des threads PkgXferMgr

Lorsque le contrôle de bande passante est activé pour un site, le composant de l’expéditeur ignore la configuration du thread de l’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.

Notes

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 enregistre l’une des lignes suivantes :

Planification

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

Mode impulsion :

~ Addr à DPNAME. CONTOSO.COM est actuellement en mode impulsion, une seule connexion est donc 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 lorsque la limitation de bande passante est configurée.