Configuration du Cache des homologues dans la Branche actuelle de ConfigMgr
À partir de la branche actuelle de ConfigMgr v1610, le Cache des homologues a été disponible. Cette fonctionnalité est conçue pour aider à réduire l’impact réseau de la livraison de contenu aux clients dans des environnements distribués, et fonctionne avec tous les types de paquets pris en charge par ConfigMgr (mises à jour, paquets hérités, applications, images, etc.).
Voici un guide étape par étape qui vous montre comment configurer le cache des homologues dans la branche actuelle de ConfigMgr, ainsi que quelques informations de base.
Le Guide
Le guide de cet article comprend quatre étapes simples pour le faire fonctionner:
- Étape 1 – Créer une structure de collection
- Étape 2 – Configurer les paramètres du client de cache des pairs
- Étape 3 – Créer des limites et des groupes de limites
- Étape 4 – Vérifier que cela fonctionne
Mais d’abord, un peu d’arrière-plan.
ConfigMgr Peer Cache 101
La façon dont fonctionne le cache des pairs est d’activer, via les paramètres du client, les machines de chaque site qui devraient être autorisées à partager du contenu avec leurs amis. Ces machines sont appelées sources de cache homologues. Une fois que ces machines ont le contenu, d’autres machines du même groupe de limites peuvent télécharger le contenu de leurs « amis » plutôt que d’un DP distant. Vous pouvez essentiellement voir ces clients comme des points de distribution supplémentaires 🙂
Sources de cache des homologues
Le contenu que vous souhaitez avoir disponible pour la mise en cache des homologues doit être entièrement déployé sur les sources de cache des homologues, il est donc situé dans leur cache, avant qu’il ne devienne disponible pour d’autres clients. Mais une fois qu’ils l’ont, il n’est pas nécessaire d’attendre le déploiement pour le reste. ConfigMgr apprend assez rapidement ses nouveaux « points de distribution ».
Contenu mis en cache
Le contenu que vous souhaitez avoir disponible pour la mise en cache des homologues doit être entièrement déployé sur les sources de cache des homologues, de sorte qu’il se trouve dans leur cache, avant qu’il ne devienne disponible pour d’autres clients. Mais une fois qu’ils l’ont, il n’est pas nécessaire d’attendre le déploiement pour le reste. ConfigMgr apprend assez rapidement ses nouveaux « points de distribution ». À partir de ConfigMgr v1806, le MP ne renvoie que des clients actifs /actifs sur votre réseau, comme indiqué par leur statut de canal rapide.
Groupe de limites
Le cache des homologues est effectué par groupe de limites, donc si un client se déplace vers un nouveau site (nouveau groupe de limites), il sera servi avec différentes sources de cache des homologues.
Sécurité
À partir de ConfigMgr v1710, tous les transferts entre le client de cache homologue et la source de cache homologue qu’il utilise actuellement se font avec HTTPS.
Cache des homologues et BranchCache
Dans de nombreux scénarios, vous pouvez utiliser BranchCache seul, sans avoir besoin d’impliquer le Cache des homologues, mais le Cache des homologues fonctionne avec BranchCache, en quelque sorte, où BranchCache fonctionne comme une sauvegarde pour les paquets, mais aussi pour le contenu des homologues que le Cache des homologues ne peut pas, comme les stratégies ConfigMgr. Voir cet article pour plus d’informations sur la configuration de BranchCache : https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/
Voici un résumé rapide des fonctionnalités de mise en cache de BranchCache et de ses homologues:
BranchCache
- Peers sur le sous-réseau local uniquement (à moins d’ajouter une solution tierce, il peut alors couvrir plusieurs sous-réseaux)
- Ne prend pas en charge OSD (à moins d’ajouter une extension tierce gratuite pour BranchCache),
- Peut commencer à peering du contenu dès que le premier client reçoit quelques blocs du fichier
- Peut peer tous les types de paquets ConfigMgr, ainsi que les stratégies ConfigMgr
- Utilise un cache distinct de celui que le client ConfigMgr
- Peut utiliser le contenu ConfigMgr qui a été dédupliqué pour réduire davantage l’impact sur le réseau.
Cache des pairs
- Les pairs au niveau du groupe de limites ou sur le sous-réseau local (configurable sur le groupe de limites)
- Ne peut pas démarrer le peering du contenu tant que le paquet entier n’a pas été téléchargé
- Peut peer tous les types de paquets ConfigMgr, mais pas les stratégies ConfigMgr
- Utilise le cache client ConfigMgr
Remplaçant le cache des pairs WinPE
dans la branche actuelle ConfigMgr v1610 et les versions ultérieures, elle remplace directement la fonctionnalité de cache de pairs WinPE introduite dans la branche actuelle ConfigMgr v1511. Mais j’espère que vous avez mis à niveau votre plate-forme ConfigMgr vers quelque chose de plus récent 🙂
Scénario
Dans mon laboratoire, j’ai deux sites, New York (192.168.1.0/24) qui a un DP local et Chicago (192.168.4.0/24) qui n’a pas de DP local.
- New York: Avec le CM01 DP, compte cinq clients : W10PEER-0001- W10PEER-0005.
- Chicago: Sans DP, a cinq clients: W10PEER-0006-W10PEER-0010.
Remarque: Pour configurer un laboratoire avec plusieurs réseaux routés, je recommande d’utiliser un routeur virtuel au lieu du commutateur NAT typique dans Hyper-V ou VMware. Il peut être basé sur Linux ou Windows, et vous trouverez un guide étape par étape ici: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment
Étape 1 – Créer une structure de collection
Puisque vous devez d’abord déployer du contenu sur quelques machines dans chaque site (au moins une), j’ai créé une structure de collection qui ressemblait à ceci:
- Sources de cache de pairs – Tous les sites: Dans cette collection, j’ai ajouté deux machines de Chicago et deux machines de New York.
- Clients de Cache de pairs – New York: Ici j’ai ajouté trois autres machines sur le site de New York, juste pour tester
- Clients de Cache de pairs – Chicago: Ici j’ai ajouté trois autres machines sur le site de Chicago, encore une fois juste pour tester
Collection dynamique pour les Sources de Cache de pairs
Si vous avez de nombreux emplacements, vous trouverez peut-être plus facile de créer une collection dynamique qui trouve automatiquement de bons candidats pour être des sources de cache de pairs:
-- For all potential peer cache source machines but VMsselect SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceId = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ("3","6","4","5","7","15","16","17","23") and (SMS_G_System_NETWORK_ADAPTER.AdapterType = "Ethernet 802.3" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1) and SMS_R_System.IsVirtualMachine = "False"-- For all potential peer cache source machines including VMs (for lab)select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceId = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ("3","6","4","5","7","15","16","17","23") and (SMS_G_System_NETWORK_ADAPTER.AdapterType = "Ethernet 802.3" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1)-- For all potential peer cache source machines including VMs (for lab), limited to hard drive sizeselect SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_DISK on SMS_G_System_DISK.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ("3","6","4","5","7","15","16","17","23") and SMS_G_System_NETWORK_ADAPTER.AdapterType = "Ethernet 802.3" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1 and SMS_G_System_DISK.Size > 102398
ConfigMgr OSD
Pour que le déploiement du système d’exploitation utilise une source de cache homologue pour le contenu, vous devez ajouter la variable de collection SMSTSPeerDownload, définie sur True, à la collection vers laquelle vous déployez la séquence de tâches. En option, vous pouvez également ajouter la variable SMSTSPreserveContent pour forcer la machine à conserver les paquets utilisés pendant OSD dans le cache client ConfigMgr. Si vous ignorez l’ajout de la variable SMSTSPeerDownload, le client se rendra toujours à un point de distribution des paquets pendant l’OSD.
Étape 2 – Configurer les paramètres du client du cache des homologues
Pour que les clients ConfigMgr partagent du contenu avec d’autres, ils doivent être configurés pour le faire via les Paramètres du Client. Vous devez également étendre le cache client ConfigMgr (voir ci-dessous).
Avertissement : N’activez pas la mise en cache par les pairs sur tous vos clients, choisissez-en quelques-uns sur chaque site ou utilisez au moins une requête de collecte dynamique pour trouver des candidats appropriés. Voir les exemples précédents dans la section Étape 1.
Fraîcheur: Dans les coulisses, le paramètre client est nommé CCM_SuperPeerClientConfig, et vous verrez également SuperPeer mentionné dans les fichiers journaux.
1. Dans l’espace de travail Administration, dans le nœud Paramètres client, créez un nouveau paramètre de périphérique client personnalisé nommé Sources de cache homologues.
2. Dans la boîte de dialogue Sources du cache des homologues, cochez la case Paramètres du cache client, puis dans le volet de gauche, sélectionnez Paramètres du cache client.
3. Dans le volet Paramètres de périphérique personnalisés, définissez le cache maximal si
ze sur quelque chose d’utile, comme 65 Go, puis activez la mise en cache par les pairs en définissant la stratégie Activer le client Configuration Manager dans le système d’exploitation complet pour partager le contenu sur Oui.
Remarque : Une meilleure façon de définir la taille maximale du client consiste à utiliser un élément de configuration, qui, via un script, le définit dynamiquement en fonction de l’espace disque libre dont disposent les machines. Vous trouverez un bon exemple de Heath Lawson (@HeathL17) ici: http://blogs.msdn.microsoft.com/helaw/2014/01/07/configuration-manager-cache-management.
4. Déployez le paramètre client Sources de cache d’homologues dans la collection Sources de cache d’homologues – Tous les sites.
Étape 3 – Créez des limites et des groupes de limites
Puisque les clients de mise en cache des homologues trouvent des amis dans un groupe de limites uniquement, vous devez avoir une structure quelque peu décente de groupes de limites. Pour simplifier mes tests, j’ai simplement créé les groupes de limites suivants.
- New York : Auquel j’ai ajouté le 192.168.1.1 – 192.168.1.254 Limite de plage IP
- Chicago : À laquelle j’ai ajouté la limite de plage IP 192.168.4.1–192.168.4.254
Étape 4 – Vérifier que cela fonctionne
Maintenant, il est temps de vérifier que cela fonctionne, et dans mon exemple, j’ai déployé un package de 1 Go dans la collection de sources de cache homologues (contenant deux clients dans chaque site).
Une fois que ces clients ont eu le contenu, je l’ai déployé sur les clients restants de chaque site et j’ai regardé ce qui s’est passé en suivant les SAE.connectez-vous à chaque client.
Comportement à New York
Dans les versions initiales du cache des homologues, un client utiliserait toujours un DP local s’il en existait un dans le même sous-réseau, mais dans les versions récentes, vous pouvez configurer ce comportement sur le groupe de limites.
Si vous modifiez les paramètres de votre groupe de limites par rapport aux paramètres ci-dessus, les clients de New York obtiennent du contenu du DP CM01, même si leurs amis de mise en cache des homologues ont les paramètres ci-dessus.
contenu. C’est la ligne intéressante du journal.
Emplacement DP correspondant trouvé 0 – http://cm01.corp.viamonstra.com/sms_dp_smspkg$/ps10007f(Localité:
Comportement à Chicago
À Chicago, il n’y a pas de DP local à Chicago, et les clients obtiendront le contenu de ses amis de mise en cache homologues. Ci-dessous est CAS.exemple de journal des clients à Chicago, et comme vous pouvez le voir, la source de cache des pairs est classée avant le DP CM01 distant (qu’il a également trouvé).
Raccourci: Les clients de Chicago reçoivent du contenu de leurs amis de mise en cache. C’est la ligne intéressante du journal.
Emplacement DP correspondant trouvé 0-http://w10peer-0006.corp.viamonstra.com:8003/sccm_branchcache$/ps100083(Localité: PEER)
En guise de touche finale, après avoir attendu 24 heures, vous pouvez voir les clients rapporter leur historique de téléchargement, à la fois dans le ContentTransferManager.connectez-vous et accédez également à l’espace de travail de surveillance et sélectionnez le nœud État de la distribution / Sources de données client.
Remarque: Les gens de 2Pint Software ont publié un utilitaire qui vous permet de définir l’intervalle. Le nom est Trigger Happy, et vous le téléchargez ici: http://2pintsoftware.com/download/trigger-happy
