Osvědčené postupy pro kolekce v Configuration Manager

Platí pro: Configuration Manager (Current Branch)

Některé pokyny ke správě kolekcí můžou být rozporuplné. Z důvodů výkonu byste například měli omezit počet kolekcí, které se často aktualizují. Často se ale kolekce aktualizují, protože většina funkcí Configuration Manager závisí na kolekcích. Při návrhu a konfiguraci kolekcí a vyhodnocování kolekcí pečlivě zvažte dopad na výkon i obchodní požadavky.

Pro kolekce v Configuration Manager použijte následující osvědčené postupy.

Konfigurace časového období údržby pro aktualizace

Můžete nakonfigurovat časové intervaly údržby pro kolekce zařízení, abyste omezili časy, po které Configuration Manager můžou na tato zařízení instalovat software. Pokud nakonfigurujete časové období údržby tak, aby bylo příliš malé, je možné, že klient nenainstaluje důležité aktualizace softwaru. Tento stav ponechá klienta zranitelný vůči problémům, které aktualizace zmírní.

Důležité aspekty, které byste měli mít na paměti při plánování časových období údržby:

• Výchozí maximální doba běhu aktualizace softwaru je 60 minut.
• Když Configuration Manager vypočítá, jestli se aktualizace může nainstalovat, přičte k maximální době běhu pět minut, aby se zohlednilo restartování.
• Zbývající doba trvání časového období údržby musí být delší než maximální doba běhu aktualizace softwaru plus pět minut.

Vyhněte se častému vyhodnocování kolekcí

Úplné vyhodnocení kolekce vyhodnocuje nejen cílovou kolekci, ale také všechny kolekce, které kolekce omezuje, pokud dojde k aktualizaci. Kolekce bez plánu se také stále vyhodnocuje, pokud se aktualizuje její limitující kolekce. Je tedy možné, že se některé kolekce vyhodnocují častěji, než očekáváte.

V zaneprázdněném Configuration Manager prostředí můžete zvýšit výkon vyhodnocování kolekcí tím, že plánujete horizontální navýšení kapacity, abyste se vyhnuli opakovaným vyhodnocením kolekcí. V hlubokém stromu můžete snížit frekvenci vyhodnocování kolekcí, protože kolekce sestupují hlouběji ve stromu, protože vyhodnocení kolekcí vyšší úrovně také spustí vyhodnocení kolekcí na nižší úrovni.

Vysvětlení grafu vyhodnocení kolekce

Mějte na paměti, jak funguje graf vyhodnocení kolekce, abyste mohli navrhnout vhodnou strukturu kolekce. Nespoléhejte na úplné vyhodnocení kolekce, abyste vždy aktualizovali všechny kolekce. Pokud se přírůstkově aktualizovaná kolekce aktualizuje podle plánu, odkazování na kolekce, které nejsou povolené pro přírůstkové aktualizace, se nemusí aktualizovat. Vzhledem k tomu, že k aktualizacím pravděpodobně došlo během přírůstkového vyhodnocení, úplné vyhodnocení nemusí aktualizovat kolekci a ukončit tak graf vyhodnocení kolekce pro daný cyklus. V takovém případě nedochází k žádným vyhodnocením kolekcí odkazů. Další informace najdete v tématu Graf vyhodnocení kolekce.

Omezení přírůstkových aktualizací

Povolení přírůstkových aktualizací pro mnoho kolekcí může způsobit zpoždění hodnocení. Nejlepší je omezit počet přírůstkově aktualizovaných kolekcí na 200. Přesné číslo závisí na:

• Celkový počet kolekcí
• Frekvence přidaných a měněných nových prostředků v hierarchii
• Počet klientů v hierarchii
• Složitost pravidel členství v kolekcích v hierarchii

Pokud cyklus přírůstkového vyhodnocování trvá déle než nakonfigurovaná frekvence aktualizací, pak Configuration Manager neustále zpracovává vyhodnocení kolekcí, což by mohlo mít vliv na výkon systému. Snižte počet přírůstkově aktualizovaných kolekcí nebo prodlužte dobu mezi cykly přírůstkového hodnocení.

Vzhledem k potenciálním dopadům přírůstkových kolekcí je důležité mít zásady nebo postup pro vytváření kolekcí a přiřazování plánů aktualizací. Příklady aspektů zásad:

• Přírůstkové aktualizace používejte pouze pro kolekce, které se používají pro otázky týkající se zabezpečení, nastavení klienta a časových období údržby. Tyto aktualizace kolekce ovlivňují chování klienta a přístup k prostředkům.
• U aplikací bez schválení licencování inzerujte aplikace do existujících kolekcí a pomocí globálních podmínek omezte dostupnost.
• Vytvořte přehled vhodných období pro jiné kolekce, které mají naplánované úplné aktualizace kolekcí.

Vyhněte se vyhodnocování velkých stromů z CAS

V Configuration Manager prostředí nevyhodnocuje lokalita centrální správy (CAS) členství v kolekci. Primární lokality jsou jediné weby, které vyhodnocují kolekce. Sekundární lokality fungují jako proxy servery, které používají pouze data replikovaná z primární lokality.

Pokud chce cas požádat o aktualizaci kolekce, odešle požadavek do každé primární lokality. Primární lokality vyhodnocují kolekci a odesílají výsledky zpět do casu. Výsledky vyhodnocení kolekce se zobrazí až poté, co se všechny pokyny k vyhodnocení kolekce replikují do všech lokalit, všechny weby vyhodnotí všechny kolekce a všechna data se vrátí do cas a zkombinují se.

Následující diagram znázorňuje tok, když cas požádá o ruční aktualizaci kolekce:

Aktualizace kolekce z cas s více primárními lokalitami může být časově náročná. Pokud se kolekce nevyhodnocuje včas, je lákavé požadavek zopakovat.

Jakmile vlákno vyhodnocení kolekce začne a načte graf vyhodnocení, bude vyhodnocení pokračovat, dokud graf vyhodnocení kolekce nebude prázdný. Vlákno se pak ukončí a bude k dispozici pro další vyhodnocení. Pokud se ale během vyhodnocování kolekcí podprocesu ve frontě nachází jiný cyklus vyhodnocení kolekce, vlákno se okamžitě restartuje, aby se pokusilo vyhodnotit cyklus "zmeškaný".

Každá metoda vyhodnocení běží ve vlastním vlákně. Je možné, že v rámci vlákna se Configuration Manager může pokusit o graf stejné kolekce více než jednou. Configuration Manager pak druhý a pozdější požadavek zahodí.

Pokud chcete těmto scénářům zabránit, vyhněte se ručnímu vyhodnocování velkých stromů, zejména při práci z CAS s více lokalitami.

Zvažte hloubku kolekce a křížové odkazy.

Abyste dosáhli rovnováhy mezi obchodními požadavky a výkonem, je důležité pochopit strukturu kolekcí, kterou vytvoříte, a její závislosti na jiných kolekcích. Pokud vytvoříte kolekci s pravidly, která odkazují na jednu nebo více kolekcí, které také odkazují na jiné kolekce, vyhodnotí se všechny tyto kolekce a vytvoří členství v kolekci.

Pravidla zahrnutí a vyloučení kolekce v Configuration Manager usnadňují odkazování na kolekce než psaní vlastního dotazu WQL. Pokud ale použití zahrnutí a vyloučení kolekcí vede k vysokému výkonu, můžete místo toho použít metodu dotazu WQL. Použijte následující ukázkové dotazy a nahraďte ID XYZ0003F ukázkové kolekce ID kolekce, kterou chcete zahrnout nebo vyloučit.

Zahrnout:

Select * from SMS_R_System where SMS_R_System.ResourceId in (select ResourceID from SMS_CM_RES_COLL_XYZ0003F)

Vyloučit:

Select * from SMS_R_System where SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_XYZ0003F)

Monitorování vyhodnocení kolekce pomocí CEVieweru

Pomocí Prohlížeče vyhodnocení kolekce (CEViewer) můžete sledovat, kolik kolekcí se vyhodnocuje a jak dlouho trvá aktualizace jednotlivých kolekcí. CEViewer je ve složce CD.Latest na serveru lokality.

Tip

Od verze Configuration Manager 2010 je tato funkce integrovaná v konzole nástroje . Další informace najdete v tématu Postup zobrazení vyhodnocení kolekce.

Pokud chcete provést podobnou kontrolu ručně s SQL, můžete použít následující dotaz:

SELECT [t2].[CollectionName], [t2].[SiteID], [t2].[value] AS [Seconds], [t2].[LastIncrementalRefreshTime], [t2].[IncrementalMemberChanges] AS [IncChanges], [t2].[LastMemberChangeTime] AS [MemberChangeTime]
FROM (
    SELECT [t0].[CollectionName], [t0].[SiteID], DATEDIFF(Millisecond, [t1].[IncrementalEvaluationStartTime], [t1].[LastIncrementalRefreshTime]) * 0.001 AS [value], [t1].[LastIncrementalRefreshTime], [t1].[IncrementalMemberChanges], [t1].[LastMemberChangeTime], [t1].[IncrementalEvaluationStartTime], v1.[RefreshType]
    FROM [dbo].[Collections_G] AS [t0]
    INNER JOIN [dbo].[Collections_L] AS [t1] ON [t0].[CollectionID] = [t1].[CollectionID]
    inner join v_Collection v1 on [t0].[siteid] = v1.CollectionID
    ) AS [t2]
WHERE ([t2].[IncrementalEvaluationStartTime] IS NOT NULL) AND ([t2].[LastIncrementalRefreshTime] IS NOT NULL) and (refreshtype='4' or refreshtype='6')
ORDER BY [t2].[value] DESC