Setup Peer Cache in ConfigMgr Current Branch
Der Peer Cache wurde bereits in ConfigMgr Current Branch v1610 verfügbar gemacht. Diese Funktion wurde entwickelt, um die Netzwerkauswirkungen der Bereitstellung von Inhalten für Clients in verteilten Umgebungen zu verringern, und funktioniert mit allen von ConfigMgr unterstützten Pakettypen (Updates, Legacy-Pakete, Anwendungen, Images usw.).).
Hier ist eine Schritt-für-Schritt-Anleitung, die Ihnen zeigt, wie Sie den Peer-Cache in ConfigMgr Current Branch einrichten und Ihnen einige Hintergrundinformationen geben.
Die Anleitung
Die Anleitung in diesem Beitrag sind vier einfache Schritte, um es in Gang zu bringen:
- Schritt 1 – Erstellen Sie eine Sammlungsstruktur
- Schritt 2 – Konfigurieren Sie die Peer–Cache–Client-Einstellungen
- Schritt 3 – Erstellen Sie Grenzen und Grenzgruppen
- Schritt 4 – Überprüfen Sie, ob es funktioniert
Aber zuerst ein wenig Hintergrund.
ConfigMgr Peer Cache 101
Die Art und Weise Peer-Cache funktioniert, ist, dass Sie aktivieren, über Client-Einstellungen, welche Maschinen auf jeder Website, die Inhalte mit ihren Freunden teilen dürfen sollte. Diese Maschinen werden Peer-Cache-Quellen genannt. Sobald diese Computer über den Inhalt verfügen, können andere Computer in derselben Randgruppe den Inhalt von ihren „Freunden“ und nicht von einem Remote-DP herunterladen. Sie können diese Clients grundsätzlich als zusätzliche Verteilungspunkte betrachten 🙂
Peer-Cache-Quellen
Der Inhalt, den Sie für das Peer-Caching zur Verfügung haben möchten, muss vollständig in den Peer-Cache-Quellen bereitgestellt werden, sodass er sich in ihrem Cache befindet, bevor er für andere Clients verfügbar wird. Aber sobald sie es haben, gibt es keine Notwendigkeit, den Rest Bereitstellung zu warten. ConfigMgr erfährt ziemlich schnell von seinen neuen „Verteilungspunkten“.
Zwischengespeicherter Inhalt
Der Inhalt, der für das Peer-Caching verfügbar sein soll, muss vollständig in den Peer-Cache-Quellen bereitgestellt werden, sodass er sich in deren Cache befindet, bevor er für andere Clients verfügbar wird. Aber sobald sie es haben, gibt es keine Notwendigkeit, den Rest Bereitstellung zu warten. ConfigMgr erfährt ziemlich schnell von seinen neuen „Verteilungspunkten“. Ab ConfigMgr v1806 gibt der MP nur noch live / aktive Clients in Ihrem Netzwerk zurück, wie durch ihren schnellen Kanalstatus gemeldet.
Grenzgruppe
Der Peer-Cache wird pro Grenzgruppe ausgeführt.Wenn ein Client also zu einer neuen Site (neue Grenzgruppe) roamt, wird er mit verschiedenen Peer-Cache-Quellen bedient.
Sicherheit
Ab ConfigMgr v1710 werden alle Übertragungen zwischen dem Peer-Cache-Client und der aktuell verwendeten Peer-Cache-Quelle mit HTTPS durchgeführt.
Peer-Cache und BranchCache
In vielen Szenarien können Sie BranchCache alleine verwenden, ohne den Peer-Cache einzubeziehen, aber der Peer-Cache arbeitet mit BranchCache zusammen, wobei BranchCache als Backup für Pakete fungiert, aber auch für Peer-Inhalte, die der Peer-Cache nicht kann, wie ConfigMgr-Richtlinien. In diesem Beitrag finden Sie weitere Informationen zum Einrichten von BranchCache: https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/
Hier finden Sie eine kurze Zusammenfassung der BranchCache- und Peer-Caching-Funktionen:
BranchCache
- Peert nur im lokalen Subnetz (es sei denn, es wird eine Drittanbieterlösung hinzugefügt, dann kann es mehrere Subnetze umfassen)
- Unterstützt OSD nicht (es sei denn, es wird eine kostenlose Drittanbieter-Erweiterung für BranchCache hinzugefügt),
- Kann mit dem Peering von Inhalten beginnen, sobald der erste Client einige Blöcke der Datei empfängt
- Kann alle ConfigMgr-Pakettypen sowie ConfigMgr-Richtlinien /li>
- Verwendet einen separaten Cache als der ConfigMgr-Client
- Kann ConfigMgr-Inhalte verwenden, die datendedupliziert wurden, um die Auswirkungen auf das Netzwerk weiter zu reduzieren.
Peer-Cache
- Peers auf Grenzgruppenebene oder im lokalen Subnetz (konfigurierbar in der Grenzgruppe)
- Peering von Inhalten kann erst gestartet werden, wenn das gesamte Paket heruntergeladen wurde
- Kann alle ConfigMgr-Pakettypen, aber keine ConfigMgr-Richtlinien peeren
- Verwendet den ConfigMgr-Client-Cache
Ersetzt den WinPE-Peer-Cache
Peer-Cache ConfigMgr Current Branch v1610 und höher ist ein direkter Ersatz für die WinPE Peer Cache-Funktion, die in ConfigMgr Current Branch v1511 eingeführt wurde. Aber hoffentlich haben Sie Ihre ConfigMgr-Plattform auf etwas Neueres aktualisiert 🙂
Szenario
In meinem Labor habe ich zwei Standorte, New York (192.168.1.0/24) mit einem lokalen DP und Chicago (192.168.4.0/24) ohne lokalen DP.
- New York: Mit dem CM01 DP, hat fünf Kunden: W10PEER-0001 – W10PEER-0005.
- Chicago: Ohne DP, hat fünf Clients: W10PEER-0006 – W10PEER-0010.Hinweis: Um ein Labor mit mehreren gerouteten Netzwerken einzurichten, empfehle ich die Verwendung eines virtuellen Routers anstelle des typischen NAT-Switches in Hyper-V oder VMware. Es kann entweder auf Linux oder Windows basieren, und Sie finden eine Schritt-für-Schritt-Anleitung hier: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment
Schritt 1 – Erstellen einer Sammlungsstruktur
Da Sie zuerst auf jeder Site (mindestens einer) Inhalte auf einigen Computern bereitstellen müssen, habe ich eine Sammlungsstruktur erstellt, die folgendermaßen aussah:
- Peer-Cache-Quellen – Alle Sites: In dieser Sammlung habe ich zwei Maschinen aus Chicago und zwei Maschinen aus New York hinzugefügt.
- Peer-Cache-Clients – New York: Hier habe ich drei weitere Maschinen auf der New Yorker Site hinzugefügt, nur zum Testen
- Peer–Cache-Clients – Chicago: Hier habe ich drei weitere Maschinen auf der Chicago-Site hinzugefügt, wieder nur zum Testen
Dynamische Sammlung für Peer-Cache-Quellen
Wenn Sie viele Standorte haben, ist es möglicherweise einfacher, eine dynamische Sammlung zu erstellen, die automatisch gute Kandidaten für Peer-Cache-Quellen:
-- 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
In damit die Betriebssystembereitstellung eine Peer-Cache-Quelle für Inhalte verwenden kann, müssen Sie die Sammlungsvariable SMSTSPeerDownload, die auf True gesetzt ist, zu der/den Sammlung(en) hinzufügen, in der/denen Sie die Tasksequenz bereitstellen. Optional können Sie auch die Variable SMSTSPreserveContent hinzufügen, um den Computer zu zwingen, die während des OSD verwendeten Pakete im ConfigMgr-Clientcache zu belassen. Wenn Sie das Hinzufügen der Variablen SMSTSPeerDownload überspringen, wechselt der Client während des OSD immer zu einem Verteilungspunkt für die Pakete.
Schritt 2 – Konfigurieren der Peer-Cache-Client-Einstellungen
Damit ConfigMgr-Clients Inhalte mit anderen teilen können, müssen sie über die Client-Einstellungen konfiguriert werden. Sie müssen auch den ConfigMgr-Client-Cache erweitern (siehe unten).
Warnung: Verwenden Sie Peer-Caching nicht für alle Ihre Clients, sondern wählen Sie einfach einige auf jeder Site aus oder verwenden Sie zumindest eine dynamische Sammlungsabfrage, um geeignete Kandidaten zu finden. Siehe die vorhergehenden Beispiele im Abschnitt Schritt 1.
Kühle: Hinter den Kulissen heißt die Client-Einstellung CCM_SuperPeerClientConfig , und in den Protokolldateien wird auch SuperPeer erwähnt.
1. Erstellen Sie im Arbeitsbereich Administration im Knoten Clienteinstellungen eine neue benutzerdefinierte Clientgeräteeinstellung mit dem Namen Peer-Cache-Quellen.
2. Aktivieren Sie im Dialogfeld Peer-Cache-Quellen das Kontrollkästchen Clientcache-Einstellungen, und wählen Sie dann im linken Bereich Clientcache-Einstellungen aus.
3. Legen Sie im Bereich Benutzerdefinierte Geräteeinstellungen den maximalen Cache si
ze auf etwas Nützliches fest, z. B. 65 GB, und aktivieren Sie dann Peer-Caching, indem Sie die Richtlinie Enable Configuration Manager client in full OS to share content auf Yes .Hinweis: Eine vielleicht bessere Möglichkeit, die maximale Clientgröße festzulegen, ist die Verwendung eines Konfigurationselements, das sie über ein Skript dynamisch festlegt, je nachdem, wie viel freier Speicherplatz die Maschinen haben. Ein gutes Beispiel von Heath Lawson (@HeathL17) finden Sie hier: http://blogs.msdn.microsoft.com/helaw/2014/01/07/configuration-manager-cache-management .4. Stellen Sie die Clienteinstellung Peer–Cache-Quellen in der Sammlung Peer-Cache-Quellen – Alle Standorte bereit.
Schritt 3 – Erstellen von Grenzen und Grenzgruppen
Da Peer-Caching-Clients nur Freunde innerhalb einer Grenzgruppe finden, können Sie brauchen Sie eine etwas anständige Struktur von Grenzgruppen. Zur Vereinfachung meiner Tests habe ich einfach die folgenden Grenzgruppen erstellt.
- New York: Zu dem ich den 192.168.1 hinzugefügt habe.1 – 192.168.1.254 IP–Bereichsgrenze
- Chicago: Zu dem ich die 192.168.4.1 – 192.168.4.254 IP-Bereichsgrenze hinzugefügt habe
Schritt 4 – Überprüfen, ob es funktioniert
Jetzt ist es an der Zeit zu überprüfen, ob es funktioniert, und in meinem Beispiel habe ich ein 1-GB-Paket für die Peer-Cache-Sources-Sammlung bereitgestellt (mit zwei Clients an jedem Standort).
Sobald diese Clients den Inhalt hatten, stellte ich ihn auf den verbleibenden Clients in jeder Site bereit und beobachtete, was geschah, indem ich den CAS folgte.melden Sie sich bei jedem Client an.
Verhalten in New York
In den ersten Versionen von Peer Cache würde ein Client immer einen lokalen DP verwenden, wenn es einen im selben Subnetz gäbe, aber in neueren Versionen können Sie dieses Verhalten in der Grenzgruppe konfigurieren.
Wenn Sie Ihre Grenzgruppeneinstellungen auf die oben genannten ändern, erhalten Clients in New York Inhalte vom CM01 DP, obwohl ihre Peer-Caching-Freunde über den Inhalt verfügen. Dies ist die interessante Zeile im Protokoll.
Übereinstimmender DP-Speicherort gefunden 0 – http://cm01.corp.viamonstra.com/sms_dp_smspkg$/ps10007f (Ort: SUBNETZ)
Verhalten in Chicago
In Chicago gibt es keinen lokalen DP in Chicago, und die Clients erhalten den Inhalt von ihren Peer-Caching-Freunden. Unten ist CAS.Protokollbeispiel von Clients in Chicago, und wie Sie sehen können, wurde die Peer-Cache-Quelle vor dem Remote-CM01-DP (den es auch gefunden hat) eingestuft.
Abkürzung: Die Kunden in Chicago erhalten Inhalte von ihren Peer-Caching-Freunden. Dies ist die interessante Zeile im Protokoll.
Übereinstimmender DP-Standort gefunden 0 – http://w10peer-0006.corp.viamonstra.com:8003/sccm_branchcache$/ps100083 (Lokalität: PEER)
Als letzten Schliff können Sie nach 24 Stunden Wartezeit sehen, wie die Clients ihren Download-Verlauf melden, sowohl im ContentTransferManager.melden Sie sich auch an, indem Sie zum Überwachungsarbeitsbereich gehen und den Knoten Verteilungsstatus / Client-Datenquellen auswählen.
Hinweis: Die Leute von 2Pint Software haben ein Dienstprogramm veröffentlicht, mit dem Sie das Intervall einstellen können. Der Name ist Trigger Happy und Sie können ihn hier herunterladen: http://2pintsoftware.com/download/trigger-happy