Nastavení Peer Cache v ConfigMgr Aktuální Větve

Johan Arwidmark /9. února 2017

Spuštění již zpět v ConfigMgr Aktuální Větve v1610, Peer Cache má k dispozici. Tato funkce je navržen tak, aby snížení dopadu sítě doručování obsahu klientům v distribuovaných prostředích, a pracuje se všemi typy balíčků, které ConfigMgr podporuje (aktualizace, legacy balíčků, aplikace, obrázky atd.).

zde je podrobný průvodce, který vám ukáže, jak nastavit vzájemnou mezipaměť v aktuální větvi ConfigMgr, a také vám poskytne nějaké informace o pozadí.

obrázek
Peer Cache v akci, Windows 10 pro nasazení ke stažení soubor WIM z peer, spíše než distribuční bod. Velmi lesklé.

Průvodce

průvodce v tomto příspěvku jsou čtyři jednoduché kroky, aby si to jít:

  • Krok 1 – Vytvořit kolekci struktura
  • Krok 2 – Konfigurace Peer Cache nastavení Klienta
  • Krok 3 – Vytvořit hranice a hranice skupiny
  • Krok 4 – Ověření, že to funguje

Ale nejdřív trochu pozadí.

ConfigMgr Peer Cache 101

způsob, jakým Peer Cache funguje, je to, že prostřednictvím nastavení klienta povolíte, jaké stroje na každém webu by měly mít možnost sdílet obsah se svými přáteli. Tyto stroje se nazývají Peer Cache zdroje. Jakmile tyto stroje mají obsah, mohou ostatní Stroje ve stejné hraniční skupině stahovat obsah od svých „přátel“ spíše než ze vzdáleného DP. V podstatě můžete vidět, tyto klienty, jako další distribuční body 🙂

Peer Cache Zdrojů

obsah, který chcete mít k dispozici pro ukládání do sdílené mezipaměti, musí být plně nasazen do peer cache zdrojů, takže se nachází v jejich vyrovnávací paměti, než je k dispozici pro ostatní klienty. Ale jakmile ji mají, není třeba čekat nasazení na zbytek. ConfigMgr se dozví o nových „distribučních bodech“ poměrně rychle.

obsah v mezipaměti

obsah, který chcete mít k dispozici pro peer caching, musí být plně nasazen do zdrojů peer cache, takže je umístěn v jejich mezipaměti, než bude k dispozici pro ostatní klienty. Ale jakmile ji mají, není třeba čekat nasazení na zbytek. ConfigMgr se dozví o nových „distribučních bodech“ poměrně rychle. Počínaje ConfigMgr v1806, MP vrátí pouze živé / aktivní klienty ve vaší síti, jak uvádí jejich rychlý stav kanálu.

hraniční skupina

Peer Cache se provádí na hraniční skupinu, takže pokud se klient potuluje na nový web (nová hraniční skupina), bude obsluhován s různými zdroji Peer Cache.

zabezpečení

počínaje ConfigMgr v1710 se všechny přenosy mezi klientem peer cache a zdrojem peer cache, který právě používá, provádějí pomocí HTTPS.

Peer Cache a BranchCache

V mnoha případech můžete použít BranchCache na to vlastní, bez nutnosti zapojení Peer Cache, ale Peer Cache funguje společně s BranchCache, druh, kde BranchCache funguje jako záloha pro balíčky, ale také peer obsah, který Peer Mezipaměti, jako ConfigMgr politiky. Viz tento příspěvek pro více informací o nastavení BranchCache: https://deploymentresearch.com/setup-branchcache-for-configmgr-current-branch/

zde je rychlý přehled funkcí BranchCache a Peer Caching:

BranchCache

  • Vrstevníky na lokální podsíti, pouze (pokud přidání v řešení třetí strany, pak to může být rozložen na více podsítí)
  • nepodporuje OSD (pokud přidání v bezplatné rozšíření třetích stran pro BranchCache),
  • Může začít peering obsahu, jakmile první klient obdrží několik bloků souboru
  • Může peer celý balíček ConfigMgr typy, stejně jako ConfigMgr politiky
  • Používá samostatný cache než ConfigMgr klienta
  • Lze využít ConfigMgr obsah, který má být deduplicated dat k dalšímu snížení dopadu sítě.

Peer Cache

  • Vrstevníky na hranice na úrovni skupiny nebo na místní podsíti (konfigurovatelné na hranici skupiny)
  • Nelze spustit peering obsahu, dokud celý balíček byl stažen
  • Může peer celý balíček ConfigMgr typy, ale ne ConfigMgr politiky
  • Používá ConfigMgr klienta mezipaměti

Výměna WinPE Peer Cache

Peer Cache v ConfigMgr Aktuální Větve v1610 a později je přímá náhrada za WinPE Peer Cache funkce, která byla zavedena v ConfigMgr Aktuální Větve v1511. Ale doufejme, že jste upgradovali ConfigMgr platformy na něco novější 🙂

Scénáře

V mé laboratoři, mám dva weby, New York (192.168.1.0/24), který má místní DP, a Chicago (192.168.4.0/24), který nemá místní DP.

  • New York: s CM01 DP má pět klientů: W10PEER-0001-W10PEER-0005.
  • Chicago: bez DP, má pět klientů: W10PEER-0006-W10PEER-0010.

Poznámka: pro nastavení laboratoře s více směrovanými sítěmi doporučuji použít virtuální směrovač místo typického přepínače Nat v Hyper-V nebo VMWare. To může být založena buď na Linuxu nebo Windows, a můžete najít krok-za-krokem průvodce zde: https://deploymentresearch.com/285/Using-a-virtual-router-for-your-lab-and-test-environment

Stránky
Ukazuje z mého Malování dovednosti. 🙂

Krok 1 – Vytvořit kolekci strukturu

Vzhledem k tomu budete potřebovat k nasazení obsahu na několik strojů, první v každém místě (alespoň jeden), jsem vytvořil kolekci strukturu, která vypadala takhle:

  • Peer Cache Zdrojů – Všechny Lokality: Do této sbírky jsem přidal dva stroje z Chicaga a dva stroje z New Yorku.
  • Peer Cache Klienty – New York: Tady jsem přidal tři další stroje v New Yorku stránky, jen pro testování
  • Peer Cache Klienty – Chicago: Tady jsem přidal tři další stroje v Chicago, opět jen pro testování

Dynamické Kolekce pro Peer Cache Zdrojů

Pokud máte mnoho místa, možná zjistíte, že je jednodušší vytvořit dynamické kolekce, která automaticky najde dobré kandidáty za to, že Peer Cache Zdrojů:

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

Dynamické kolekce pro Peer Cache Zdrojů,

ConfigMgr OSD

V pořadí pro Nasazení operačního systému k použití peer cache zdroj pro obsah, musíte přidat na SMSTSPeerDownload kolekce proměnné, nastavte na hodnotu True, sběr(s) nasazujete pořadí úloh. Volitelně můžete také přidat proměnnou SMSTSPreserveContent, aby stroj udržel balíčky použité během OSD v mezipaměti klienta ConfigMgr. Pokud přeskočíte přidání proměnné SMSTSPeerDownload, klient během OSD vždy přejde do distribučního bodu pro balíčky.

proměnné kolekce
konfigurace nasazení OS pro použití obsahu z peer (pokud je k dispozici).
Peer-0003
struktura Sbírka pro Peer Cache vytvořen.

Krok 2 – Konfigurace Peer Mezipaměti Klienta nastavení

, Aby se ConfigMgr Klientům sdílet obsah s ostatními, musí být nakonfigurován tak, aby tak učinit prostřednictvím Nastavení Klienta. Musíte také rozšířit mezipaměť klienta ConfigMgr (viz níže).

varování: neumožňují peer caching na všechny své klienty pro, stačí vybrat několik na každém webu, nebo alespoň použít dynamický dotaz kolekce najít vhodné kandidáty. Viz předchozí příklady v části Krok 1.

chlad: V zákulisí se nastavení klienta jmenuje CCM_SuperPeerClientConfig a v souborech protokolu se také zobrazí SuperPeer.

1. V administračním pracovním prostoru v uzlu nastavení klienta vytvořte nové vlastní nastavení klientského zařízení s názvem Peer Cache Sources.

2. V dialogovém okně zdroje mezipaměti Peer zaškrtněte políčko Nastavení mezipaměti klienta a v levém podokně vyberte nastavení mezipaměti klienta.

3. V podokně Nastavení vlastního zařízení nastavte maximální mezipaměť si
ze na něco užitečného, například 65 GB, a poté povolte peer caching nastavením povolit klienta Configuration Manager v plném operačním systému pro sdílení obsahu na Ano.

Poznámka: možná, že lepší způsob, jak nastavit maximální velikost klienta je pomocí konfigurační položky, které přes skript nastaví dynamicky v závislosti na tom, kolik volného místa na disku stroje. Dobrý příklad od Heath Lawson (@HeathL17) najdete zde: http://blogs.msdn.microsoft.com/helaw/2014/01/07/configuration-manager-cache-management.

4. Nasazení nastavení klienta Peer Cache Sources do Peer Cache Sources – kolekce všech webů.

Peer-0004
Konfigurace nastavení klienta pro Peer Cache Zdrojů

Krok 3 – Vytvořit hranice a hranice skupiny

Od ukládání do sdílené mezipaměti klienty najde přátele, a to v rámci hranice skupiny, musíte mít trochu slušné struktury okrajových skupin. Pro jednoduchost v mém testování jsem jednoduše vytvořil následující hraniční skupiny.

  • New York: ke kterému jsem přidal 192.168.1.1 – 192.168.1.254 rozsah IP adres hranice
  • Chicago: Do které jsem přidal na 192.168.4.1 – 192.168.4.254 rozsah IP adres hranice
Peer-0005
Hranice Skupiny v této příručce.

Krok 4 – Ověření, že to funguje

Nyní je čas ověřit, je to práce, a v mém příkladu jsem nasazen jako 1 GB balíček Peer Cache Zdrojů kolekce (obsahující dva klienty, v každém místě).

jakmile tito klienti měli obsah, Nasadil jsem ho zbývajícím klientům na každém webu a sledoval, co se stalo, sledováním CAS.přihlaste se ke každému klientovi.

Chování v New Yorku

V původních verzích Peer Mezipaměti, klient by se vždy použít místní DP, jestli tam byl jeden ve stejné podsíti, ale v posledních verzích lze konfigurovat chování na hranici skupiny.

Konfigurace Peer Cache chování

Pokud změníte hranice nastavení skupiny výše, klienti v New Yorku jsou stále obsahu z CM01 DP, i když jejich ukládání do sdílené mezipaměti přátelé mají obsah. To je zajímavý řádek v protokolu.

odpovídající DP umístění nalezeno 0 – http://cm01.corp.viamonstra.com/sms_dp_smspkg$/ps10007f (lokalita: PODSÍTĚ)

obrázek
Klienti v New Yorku už byli stahování balíčků z místního DP, i když tam jsou Peer Cache dostupných Zdrojů.

chování v Chicagu

v Chicagu neexistuje místní DP v Chicagu a klienti získají obsah od svých přátel v mezipaměti. Níže je CAS.log příklad od klientů v Chicagu, a jak můžete vidět, že zařadil peer cache zdroj před vzdáleným CM01 DP (který také našel).

zkratka: Klienti v Chicagu získávají obsah od svých přátel v mezipaměti. To je zajímavý řádek v protokolu.

Odpovídající DP umístění nalezeno 0 – http://w10peer-0006.corp.viamonstra.com:8003/sccm_branchcache$/ps100083 (Lokalita: PEER)

obrázek
Klientům v Chicagu, stahovat obsah ze svých vrstevníků.

Jako poslední krok, po čekání po dobu 24 hodin, můžete vidět, klienty, zprávy o jejich historii stahování, a to jak v ContentTransferManager.přihlaste se a také přejděte do monitorovacího pracovního prostoru a vyberte uzel stav distribuce / zdroje dat klienta.

Poznámka: lidé na 2Pint Software vydal nástroj, který vám umožní nastavit interval. Název je Spoušť Šťastný, a ke stažení je tady: http://2pintsoftware.com/download/trigger-happy

obrázek
ContentTransferManager.protokol nahrávání historie stahování.



Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.