Setup Peer Cache i ConfigMgr nuvarande gren

av Johan Arwidmark /Februari 9, 2017

börjar redan tillbaka i ConfigMgr nuvarande gren v1610, Peer Cache har tillgänglig. Den här funktionen är utformad för att minska nätverkseffekten av att leverera innehåll till kunder i distribuerade miljöer och fungerar med alla pakettyper som ConfigMgr stöder (uppdateringar, äldre paket, applikationer, bilder etc.).

Här är en steg-för-steg-guide som visar hur du ställer in peer-cache i ConfigMgr nuvarande gren, samt ger dig lite bakgrundsinformation.

bild
Peer Cache i aktion, en Windows 10-distribution ladda ner WIM-filen från en peer snarare än distributionspunkten. Mycket glänsande.

guiden

guiden i det här inlägget är fyra enkla steg för att få det att gå:

  • Steg 1-Skapa en samlingsstruktur
  • steg 2 – Konfigurera Peer Cache – klientinställningar
  • steg 3-Skapa gränser och gränsgrupper
  • steg 4-verifiera att det fungerar

men först lite bakgrund.

ConfigMgr Peer Cache 101

hur Peer Cache fungerar är att du via klientinställningar aktiverar vilka maskiner på varje webbplats som ska få dela innehåll med sina vänner. Dessa maskiner kallas Peer Cache-källor. När dessa maskiner har innehållet kan andra maskiner i samma gränsgrupp ladda ner innehållet från sina ”vänner” snarare än från en avlägsen DP. Du kan i princip se dessa klienter som extra distributionspunkter

Peer Cache-källor

innehållet du vill ha tillgängligt för peer-caching måste distribueras fullt ut till peer-cachekällorna, så det finns i deras cache innan det blir tillgängligt för andra klienter. Men när de har det, finns det ingen anledning att vänta distribuera till resten. ConfigMgr lär sig om det är nya ”distributionspunkter” ganska snabbt.

cachelagrat innehåll

innehållet du vill ha tillgängligt för peer-cachelagring måste distribueras fullt ut till peer-cachekällorna, så det finns i deras cache innan det blir tillgängligt för andra klienter. Men när de har det, finns det ingen anledning att vänta distribuera till resten. ConfigMgr lär sig om det är nya ”distributionspunkter” ganska snabbt. Från och med ConfigMgr v1806 returnerar MP bara live / aktiva klienter i ditt nätverk, vilket rapporteras av deras snabba kanalstatus.

Gränsgrupp

Peer-Cache görs per gränsgrupp, så om en klient strövar till en ny webbplats (Ny gränsgrupp) kommer den att serveras med olika Peer-Cache-källor.

säkerhet

Från och med ConfigMgr v1710 görs alla överföringar mellan peer cache-klienten och peer cache-källan som den för närvarande använder med HTTPS.

Peer Cache och BranchCache

i många scenarier kan du använda BranchCache på egen hand, utan att behöva involvera Peer Cache, men Peer Cache fungerar tillsammans med BranchCache, sorts, där BranchCache fungerar som en backup för paket, men också till peer-innehåll som Peer Cache inte kan, som ConfigMgr politik. Se det här inlägget för mer information om hur du ställer in BranchCache: https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/

Här är en snabb sammanfattning av BranchCache och Peer Caching funktioner:

BranchCache

  • Peers på den lokala subnät endast (om inte lägga i en tredje part lösning, då det kan spänna flera subnät)
  • stöder inte OSD (om inte lägga i en gratis tredje part förlängning för BranchCache),
  • kan börja peering innehåll så snart den första klienten får några block av filen
  • kan peer alla ConfigMgr pakettyper, samt ConfigMgr politik
  • använder en separat cache än ConfigMgr-klienten
  • kan använda ConfigMgr-innehåll som har deduplicerats för att ytterligare minska nätverkspåverkan.

Peer Cache

  • Peers på gränsgruppsnivå eller på lokalt undernät (konfigurerbart på gränsgruppen)
  • kan inte starta peering-innehåll förrän hela paketet har laddats ner
  • kan peer alla ConfigMgr-pakettyper, men inte ConfigMgr-policyer
  • använder ConfigMgr-klientcachen

ersätter WinPE Peer Cache

Peer Cache i ConfigMgr current branch v1610 och senare är en direkt ersättning för WinPE peer cache-funktionen som introducerades i ConfigMgr current branch v1511. Men förhoppningsvis har du uppgraderat din ConfigMgr-plattform till något nyare bisexuell

Scenario

i mitt labb har jag två platser, New York (192.168.1.0/24) som har en lokal DP och Chicago (192.168.4.0/24) som inte har en lokal DP.

  • New York: med CM01 DP, har fem klienter: W10PEER-0001-W10PEER-0005.
  • Chicago: utan DP, har fem klienter: W10PEER-0006-W10PEER-0010.

Obs: För att installera ett labb med flera dirigerade nätverk rekommenderar jag att du använder en virtuell router istället för den typiska NAT-omkopplaren i Hyper-V eller VMWare. Det kan baseras på antingen Linux eller Windows, och du hittar en steg-för-steg-guide här: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment

Sites
visar upp mina Microsoft Paint-färdigheter.

Steg 1-Skapa en samlingsstruktur

eftersom du måste distribuera innehåll till några maskiner först på varje webbplats (minst en) skapade jag en samlingsstruktur som såg ut så här:

  • Peer Cache – källor-alla webbplatser: I denna samling lade jag till två maskiner från Chicago och två maskiner från New York.
  • Peer Cache Clients-New York: Här har jag lagt till tre andra maskiner på New York-webbplatsen, bara för att testa
  • Peer Cache Clients-Chicago: här har jag lagt till tre andra maskiner på Chicago-webbplatsen, igen bara för att testa

dynamisk samling för Peer Cache-källor

om du har många platser kan det vara lättare att skapa en dynamisk samling som automatiskt hittar:

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

dynamisk samling för Peer Cache-källor,

ConfigMgr OSD

för att OS-distribution ska kunna använda en peer-cache-källa för innehåll måste du lägga till variabeln smstspeerdownload collection, inställd på true, i den samling(er) som du distribuerar aktivitetssekvensen till. Alternativt kan du också lägga till variabeln SMSTSPreserveContent för att tvinga maskinen att behålla paketen som används under OSD i ConfigMgr-Klientcachen. Om du hoppar över att lägga till variabeln SMSTSPeerDownload kommer klienten alltid att gå till en distributionspunkt för paketen under OSD.

samlingsvariabler
konfigurera OS-distribution för att använda innehåll från en peer (om tillgängligt).
Peer-0003
Samlingsstruktur för Peer Cache skapad.

steg 2 – Konfigurera Peer Cache-klientinställningar

För att få ConfigMgr-klienter att dela innehåll med andra måste de konfigureras för att göra det via klientinställningar. Du måste också utöka ConfigMgr – klientcachen (se nedan).

Varning: aktivera inte peer-cachning på alla dina kunder, välj bara några på varje webbplats eller använd åtminstone en dynamisk samlingsfråga för att hitta lämpliga kandidater. Se föregående exempel i avsnittet Steg 1.

svalka: Bakom kulisserna heter klientinställningen CCM_SuperPeerClientConfig, och du kommer också att se SuperPeer som nämns i loggfilerna.

1. Skapa en ny anpassad klientenhet med namnet Peer Cache-källor i Administrationsarbetsytan i noden klientinställningar.

2. Markera kryssrutan inställningar för Klientcache i dialogrutan Peer-Cache-källor och välj sedan Inställningar för Klientcache i den vänstra rutan.

3. I fönstret anpassade Enhetsinställningar ställer du in maximal cache si
ze till något användbart, som 65 GB, och aktiverar sedan peer-caching genom att ställa in Aktivera Konfigurationshanteraren i full OS för att dela innehållspolicy till Ja.ett kanske bättre sätt att ställa in maximal klientstorlek är att använda ett konfigurationsobjekt, som via ett skript ställer in det dynamiskt beroende på hur mycket ledigt diskutrymme maskinerna har. Du hittar ett bra exempel från Heath Lawson (@HeathL17) här: http://blogs.msdn.microsoft.com/helaw/2014/01/07/configuration-manager-cache-management.

4. Distribuera Klientinställningen Peer Cache Sources till Peer Cache Sources – all Sites collection.

Peer-0004
konfigurera klientinställningarna för Peer Cache – källor

steg 3-Skapa gränser och gränsgrupper

eftersom peer caching-klienter hittar vänner inom endast en gränsgrupp, du måste ha en något anständig struktur av gränsgrupper. För enkelhet i min testning skapade jag enkelt följande gränsgrupper.

  • New York: till vilken jag lade till 192.168.1.1 – 192.168.1.254 IP range boundary
  • Chicago: till vilken jag lade till 192.168.4.1 – 192.168.4.254 IP range boundary
Peer-0005
gränsgrupper i den här guiden.

steg 4 – verifiera att det fungerar

Nu är det dags att verifiera att det fungerar, och i mitt exempel distribuerade jag ett 1 GB-paket till Peer Cache Sources-samlingen (innehållande två klienter på varje webbplats).

när dessa klienter hade innehållet distribuerade jag det till de återstående klienterna på varje webbplats och tittade på vad som hände genom att följa CAS.logga in på varje klient.

beteende i New York

i de första versionerna av Peer Cache skulle en klient alltid använda en lokal DP om det fanns en i samma delnät, men i de senaste versionerna kan du konfigurera det beteendet i gränsgruppen.

konfigurera Peer Cache-beteende

om du ändrar dina gränsgruppsinställningar till ovanstående får klienter i New York innehåll från CM01 DP, även om deras peer-cachevänner har innehåll. Detta är den intressanta raden i loggen.

matchande DP-plats hittades 0 – http://cm01.corp.viamonstra.com/sms_dp_smspkg$/ps10007f (Lokalitet: SUBNET)

bild
klienter i New York hämtade redan paket från den lokala DP, även om det finns Peer-Cache-källor tillgängliga.

beteende i Chicago

i Chicago finns det ingen lokal DP i Chicago, och klienterna kommer att få innehållet från sina peer caching-vänner. Nedan är CAS.log exempel från kunder i Chicago, och som ni kan se det rankad peer cache källa innan fjärr CM01 DP (som det också funnit).

stenografi: Kunderna i Chicago får innehåll från sina peer-caching-vänner. Detta är den intressanta raden i loggen.

matchande DP-plats hittades 0 – http://w10peer-0006.corp.viamonstra.com:8003/sccm_branchcache$/ps100083 (Lokalitet: PEER)

bild
klienter i Chicago hämtar innehåll från sina kamrater.

som en sista touch, efter att ha väntat i 24 timmar, kan du se klienterna rapportera sin nedladdningshistorik, både i ContentTransferManager.logga och också genom att gå till Övervakningsarbetsytan och välj noden distributionsstatus / Klientdatakällor.

Obs: folket på 2pint Software har släppt ett verktyg som låter dig ställa in intervallet. Namnet är Trigger Happy, och du laddar ner det här: http://2pintsoftware.com/download/trigger-happy

bild
ContentTransferManager.logga ladda upp nedladdningshistoriken.



Lämna ett svar

Din e-postadress kommer inte publiceras.