Oppsett Peer Cache I ConfigMgr Nåværende Gren
Av Johan Arwidmark /februar 9, 2017
Starter allerede tilbake i ConfigMgr Nåværende Gren v1610, Peer Cache har vært tilgjengelig. Denne funksjonen er utviklet for å redusere nettverkspåvirkningen ved å levere innhold til klienter i distribuerte miljøer ,og fungerer med alle pakketyper Som ConfigMgr støtter(oppdateringer, eldre pakker, programmer, bilder etc.).
Her er en trinnvis veiledning som viser deg hvordan du konfigurerer peer cache I ConfigMgr Current Branch, samt gir deg litt bakgrunnsinformasjon.
Guiden
guiden i dette innlegget er fire enkle trinn for å få det til å gå:Trinn 1-Lag en samling struktur
Men først, litt bakgrunn.
ConfigMgr Peer Cache 101
Måten Peer Cache fungerer, er at du aktiverer, via klientinnstillinger, hvilke maskiner på hvert nettsted som skal få lov til å dele innhold med sine venner. Disse maskinene kalles Peer Cache Kilder. Når disse maskinene har innholdet, kan andre maskiner i samme grensegruppe laste ned innholdet fra sine «venner» i stedet for fra en ekstern DP. Du kan i utgangspunktet se disse klientene som ekstra distribusjonspoeng 🙂
Peer Cache Kilder
innholdet du vil ha tilgjengelig for peer caching må være fullt distribuert til peer cache kilder, så det er plassert i deres cache, før det blir tilgjengelig for andre klienter. Men når de har det, er det ikke nødvendig å vente distribusjon til resten. ConfigMgr lærer om det nye «distribusjonspunkter» ganske raskt.
Bufret Innhold
innholdet du vil ha tilgjengelig for peer-bufring, må distribueres fullt ut til peer-bufferkildene, så det er plassert i bufferen før det blir tilgjengelig for andre klienter. Men når de har det, er det ikke nødvendig å vente distribusjon til resten. ConfigMgr lærer om det nye «distribusjonspunkter» ganske raskt. FRA Og Med ConfigMgr v1806 returnerer MP bare live/aktive klienter på nettverket ditt, som rapportert av deres raske kanalstatus.
Boundary Group
Peer Cache gjøres per boundary group, så hvis en klient streifer til et nytt område( ny boundary group), vil det bli servert med Ulike Peer Cache Kilder.
Sikkerhet
Alle overføringer mellom peer cache-klienten og peer cache-kilden den bruker, gjøres MED HTTPS.
Peer Cache og BranchCache
i mange scenarier kan Du bruke BranchCache på egen hånd, uten å måtte involvere Peer Cache, Men Peer Cache fungerer sammen med BranchCache, liksom, Hvor BranchCache fungerer som en sikkerhetskopi for pakker, men også til peer-innhold Som Peer Cache ikke kan, som ConfigMgr-retningslinjer. Se dette innlegget for mer info om å sette Opp BranchCache: https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/
her er en rask oppsummering Av BranchCache og Peer Caching funksjoner: Støtter IKKE OSD (med mindre du legger TIL en gratis tredjepartsutvidelse for BranchCache),kan starte peering innhold så snart den første klienten mottar noen blokker av filen
/li>
Peer Cache
- Peers på grensen gruppenivå eller på lokale subnett (konfigurerbar på grensen gruppen)
- kan ikke starte peering innhold før hele pakken er lastet ned
- Bruker ConfigMgr klient cache
Kan peer alle ConfigMgr pakketyper, men Ikke ConfigMgr policyer
Erstatte WinPE Peer Cache
Peer Cache i configmgr current branch v1610 og senere er en direkte erstatning for winpe peer Cache-funksjonen som ble introdusert i configmgr current branch v1511. Men forhåpentligvis har du oppgradert Din ConfigMgr-plattform til noe nyere 🙂
Scenario
i laboratoriet mitt har jeg To nettsteder, New York (192.168.1.0/24) som har en lokal DP, Og Chicago (192.168.4.0/24) som ikke har en lokal DP.New York: Med CM01 DP, har fem klienter: W10PEER-0001 – W10PEER-0005.Chicago: Uten DP, har fem klienter: W10PEER-0006-W10PEER-0010.
Merk: for å sette opp et laboratorium med flere rutede nettverk anbefaler jeg å bruke en virtuell ruter i Stedet for den typiske nat-bryteren I Hyper-V eller VMWare. Den kan være Basert På Enten Linux eller Windows, og du finner en trinnvis veiledning her: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment
Trinn 1 – Lag en samlingsstruktur
siden du må distribuere innhold til noen få maskiner først på hvert nettsted (minst en), opprettet jeg en samlingsstruktur som så slik ut:
- Peer Cache Kilder – Alle Nettsteder: I denne samlingen la jeg til to maskiner Fra Chicago, og to maskiner Fra New York.
- Peer Cache Clients – New York: her la jeg til tre andre maskiner i New York – området, bare for testing
- Peer Cache Clients-Chicago: her la jeg til tre andre maskiner i Chicago området, igjen bare for testing
Dynamisk Samling For Peer Cache Kilder
Hvis du har mange steder, kan du finne det lettere å lage en dynamisk samling som automatisk finner gode kandidater for Å være Peer Cache Kilder:
-- 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
for at os-distribusjon skal kunne bruke en peer cache-kilde for innhold, må du legge til smstspeerdownload collection-variabelen, satt til true, til samlingen(e) du distribuerer oppgavesekvensen til. Du kan også legge Til variabelen SMSTSPreserveContent for å tvinge maskinen til å beholde pakkene som brukes under OSD i ConfigMgr – klientbufferen. Hvis Du hopper over å legge Til smstspeerdownload-variabelen, vil klienten alltid gå til et distribusjonspunkt for pakkene under OSD.
Trinn 2-Konfigurer Peer Cache Client settings
For Å få ConfigMgr-Klienter til å dele innhold med andre, må De konfigureres til å gjøre det via Klientinnstillinger. Du må også utvide ConfigMgr client cache (se nedenfor).
Advarsel: ikke aktiver peer caching på alle klientene dine for, bare velg noen på hvert nettsted, eller bruk i det minste en dynamisk samlingsspørring for å finne passende kandidater. Se de foregående eksemplene I Trinn 1-delen.
Kjølighet: Bak kulissene heter klientinnstillingen CCM_SuperPeerClientConfig, og Du vil også se SuperPeer nevnt i loggfilene.
1. I Administrasjon-arbeidsområdet, i Klientinnstillinger-noden, oppretter du en ny egendefinert klientenhetsinnstilling kalt Peer Cache Sources.
2. Merk Av For Klientbufferinnstillinger i Dialogboksen Node – Hurtigbufferkilder, og velg Deretter Klientbufferinnstillinger i venstre rute.
3. I Ruten Egendefinerte Enhetsinnstillinger angir Du Maksimal cache si
ze til noe nyttig, for eksempel 65 GB, og aktiverer deretter peer-caching ved å angi Aktiver Konfigurasjonsbehandling-klienten i FULL OS for å dele innholdspolicy Til Ja.
Merk: en kanskje bedre måte å angi maksimal klientstørrelse på er å bruke et konfigurasjonselement, som via et skript setter det dynamisk avhengig av hvor mye ledig diskplass maskinene har. Du finner et godt eksempel Fra Heath Lawson (@HeathL17) her: http://blogs.msdn.microsoft.com/helaw/2014/01/07/configuration-manager-cache-management.
4. Distribuer Klientinnstillingen Peer Cache Sources til Peer Cache Sources – all Sites-samlingen.
Trinn 3 – Lag grenser og grensegrupper
siden peer caching klienter finner venner bare innenfor en grensegruppe må du ha en noe anstendig struktur av grensegrupper. For enkelhet i testingen opprettet jeg enkelt følgende grensegrupper.
- New York: som jeg la til 192.168.1.1 – 192.168.1.254 IP range boundary
- Chicago: som jeg la til 192.168.4.1 – 192.168.4.254 IP range boundary
Trinn 4 – Verifisere at det fungerer
nå er det på tide å bekrefte at det fungerer, Og i mitt eksempel distribuerte jeg en 1 GB-pakke til Peer Cache Sources-samlingen (som inneholder to klienter på hvert nettsted).
Når disse klientene hadde innholdet, distribuerte jeg det til de gjenværende klientene på hvert nettsted, og så på hva som skjedde ved å følge CAS.logg på hver klient.
Oppførsel i New York
i De første versjonene Av Peer Cache, ville en klient alltid bruke en lokal DP hvis det var en på samme delnett, men i nyere versjoner kan du konfigurere denne oppførselen på grensegruppen.
hvis du endrer innstillingene for grensegruppen til DET ovennevnte, får klienter I New York innhold FRA CM01 DP, selv om deres peer-caching-venner har innholdet. Dette er den interessante linjen i loggen.
Matchende DP-plassering funnet 0- http://cm01.corp.viamonstra.com/sms_dp_smspkg$/ps10007f(Lokalitet: SUBNET)
Oppførsel I Chicago
I Chicago er det ingen lokal DP I Chicago, og klientene vil få innholdet fra sine peer caching venner. Nedenfor er CAS.logg eksempel fra klienter I Chicago, og som du kan se det rangert peer cache kilde før den eksterne CM01 DP (som den også fant).
Stenografi: Kundene i Chicago får innhold fra sine peer caching venner. Dette er den interessante linjen i loggen.
Matchende DP-plassering funnet 0 – http://w10peer-0006.corp.viamonstra.com:8003/sccm_branchcache$/ps100083(Lokalitet: PEER)
som en siste berøring, etter å ha ventet i 24 timer, kan du se klientene som rapporterer nedlastingsloggen, både i ContentTransferManager.logg og også ved å gå Til Overvåking arbeidsområdet og velg Distribusjonsstatus / Klient Datakilder node.
Merk: folkene på 2pint-Programvaren har gitt ut et verktøy som lar deg sette intervallet. Navnet Er Trigger Happy, og du laster det ned her: http://2pintsoftware.com/download/trigger-happy
