Nastavení velikosti a výkonu databáze
Určení velikosti databáze je klíčem k pochopení výkonu nástroje System Center – Orchestrator. Všechny servery sady Runbook, server pro správu a webové komponenty závisí na databázi nástroje Orchestrator pro své operace. Problémy s nasazeními nástroje Orchestrator mohou vzniknout z neúplného porozumění typům dat v databázi a jejich správě.
Vzhledem k tomu, že Runbook Designer komunikuje s databází nástroje Orchestrator (prostřednictvím serveru pro správu), bude nízký výkon databáze bránit této komunikaci.
Prostředí operátoru orchestratoru je založeno na dvou komponentách: konzola Orchestraation a webová služba. Konzola Orchestraation je aplikace založená na technologii Silverlight, která závisí na webové službě pro její připojení k databázi nástroje Orchestrator. Webová služba je aplikace IIS, která se připojuje k databázi. Webová služba i konzola Orchestration jsou tedy závislé na výkonu databáze Nástroje orchestrator.
Zatímco konzola Orchestration Console je závislá na webové službě, má také logiku jedinečnou pro svou funkci jako uživatelské rozhraní a její vlastní charakteristiky výkonu.
Konfigurační data a data protokolu
Databáze nástroje Orchestrator na vysoké úrovni obsahuje dva druhy dat:
Konfigurační data
Infrastruktura nástroje Orchestrator obsahuje konfigurační data. Tato data nejsou v kontextu růstu databáze problém, protože požadavky na úložiště pro tento typ dat jsou malé.
Data protokolu
Orchestrator vytváří různé typy dat protokolu, z nichž všechny je možné zobrazit a spravovat v nástroji Runbook Designer. Požadavky na úložiště pro tato data se mohou lišit ve velikosti a můžou být velké.
Následující tabulka uvádí typy dat protokolu, která lze uložit v databázi nástroje Orchestrator. Orchestrator také ukládá data do samostatných souborů protokolů (mimo databázi) pro trasování auditu a trasování. Další informace o všech typech dat protokolu najdete v tématu Protokoly nástroje Orchestrator.
| Typ dat protokolu | Umístění v nástroji Runbook Designer | Spravuje se pomocí vyprázdnění protokolu? |
|---|---|---|
| Protokoly runbooků | Karty Historie protokolů a protokolů | Ano |
| Události aktivit (platforma) | Karta Události | No |
| Historie auditu | Karta Historie auditu | No |
Kód platformy a kód domény
Aktivity runbooku nástroje Orchestrator obsahují dva různé typy kódu:
Kód platformy
Jedná se o společný kód sdílený většinou aktivit a slouží ke spouštění běžných úloh prováděných aktivitami nástroje Orchestrator. Kód platformy generuje společná publikovaná data.
Kód domény
Spouští různé úlohy specifické pro akce pro každou aktivitu, které obvykle nejsou přidružené k samotné platformě Orchestrator. Potenciálně může existovat velká variace mezi kódem platformy a kódem domény.
Data protokolování generovaná pro danou aktivitu mohou obsahovat datové prvky, které jsou s jednou nebo více hodnotami. Každá aktivita vytvoří jeden záznam dat s jednou hodnotou. Kód domény může vytvořit více záznamů dat s více hodnotami a je proto zodpovědný za určení toho, co aktivita dělá s běžnými publikovanými daty, která přijala z předchozích aktivit.
Runbooky orchestratoru jsou v podstatě navržené tak, aby předávaly data mezi diskrétními prvky kódu domény. Kód domény může také volitelně generovat publikovaná data specifická pro aktivitu.
Všechny runbooky mají základní podobnost v tom, že spouštějí aktivity, které se skládají z kódu domény a kódu platformy, smyčují pracovní postupy a větví. Větvení je, když runbook volá jiné runbooky k provedení konkrétní úlohy. Při prvním vyvolání runbooku se skládá z jednoho vlákna. Když toto vlákno narazí na aktivitu runbooku, jejíž propojení vyžadují větev, vytvoří se další vlákna, jedno pro každou větev. Každé vlákno přebírá jako vstup společná publikovaná data z aktivity, která vytvořila větev. Tato data korelují zpět s předchozími aktivitami v runbooku, aby se aktualizovala běžná publikovaná data, ke kterým se aktivity přihlašují.
Kód domény může mít vliv na výkon databáze více než více vláken generovaných větvením. Důvodem je to, že kód domény může potenciálně generovat velké objemy publikovaných dat specifických pro aktivitu.
Možnosti protokolování
Karta Protokolování na kartě Vlastnosti runbooku umožňuje volitelně ukládat položky protokolování. Výchozí protokolování výrazu označuje, že není vybrána žádná ze dvou publikovaných možností dat, což odpovídá 524 bajtům vygenerovaným pro každou aktivitu. Možnosti protokolování poskytují dvě kategorie běžných publikovaných dat:
Společná publikovaná data
Sada datových položek společná pro všechny aktivity. Seznam najdete v možnostech protokolu runbooku.
Tato možnost protokolování generuje 6082 bajtů pro každou aktivitu.
Publikovaná data specifická pro aktivity
Sada dat, která jsou specifická pro aktivitu, která je volitelně vytvořena kódem domény.
Tato možnost protokolování generuje 6082 bajtů kromě bajtů protokolovaných konkrétními aktivitami.
Tip
Tato možnost je vybraná především pro účely ladění. Chcete-li omezit růst protokolování, ponechte nezaškrtnutou možnost.
Nastavení možností protokolování může výrazně ovlivnit výkon a zvýšit růst databáze. Představte si scénář, kdy se stejná aktivita runbooku spouští dvakrát, nejprve s protokolováním dat na výchozí úrovni (nejsou vybrány žádné možnosti publikovaných dat) a pak je nastavena s vybranými běžnými publikovanými daty. Dokončení kódu domény by mělo trvat stejnou dobu. Spuštění kódu platformy ale bude trvat déle, protože musí podporovat 12krát větší množství běžného protokolování publikovaných dat, než to dělá pouze s výchozím protokolováním.
Vymazání protokolů
Výchozí možnosti určené pro funkci vyprázdnění protokolu v nástroji Runbook Designer jsou nakonfigurované tak, aby poskytovaly nejlepší uživatelské prostředí pro předem připravená nasazení nástroje Orchestrator. Změna těchto hodnot může změnit charakteristiky výkonu prostředí a měla by být implementována postupně a s vysokou mezemi, aby bylo možné vyhodnotit účinek změny.
Další informace o automatickém a ručním vymazání protokolů najdete v protokolech vyprázdnění runbooků.
Vytvoření srovnávacích testů výkonu
Pokud chcete vytvořit jednoduchý runbook pro testování růstu protokolování, můžete k vytvoření srovnávacích testů prostředí Orchestratoru použít standardní hodnoty porovnání aktivit.
Následující postup vytvoří runbook, který spustí aktivitu Porovnat hodnoty 10 000krát. Porovnání hodnot je jednoduchá aktivita, jejíž kód domény je minimální. Tento runbook lze vyvolat za různých okolností, aby charakterizuje celkový výkon daného prostředí modulu runtime orchestratoru.
Vytvoření runbooku, který lze použít k srovnávacímu testování prostředí nástroje Orchestrator
Vytvořte nový runbook.
Přidejte aktivitu Porovnat hodnoty z palety Standardní aktivita. Poklikáním na aktivitu ji nakonfigurujte.
Vyberte kartu Obecné a nakonfigurujte tuto aktivitu tak, aby porovnávala řetězce (výchozí hodnota).
Vyberte kartu Podrobnosti, zadejte hodnotu STRING do testovacího pole a vyberte je prázdná.
Výběrem možnosti Dokončit uložte aktualizace aktivity.
Klikněte pravým tlačítkem myši na aktivitu a vyberte Smyčka.
Zaškrtněte políčko Povolit a zadejte číslo 0 (nula) pro zpoždění mezi pokusy.
Vyberte kartu Konec.
Změňte výchozí podmínku ukončení. Vyberte Porovnat hodnoty, zaškrtněte políčko Zobrazit společná publikovaná data a vyberte Smyčka: Počet pokusů. Chcete-li uložit tuto změnu, vyberte OK .
Vyberte hodnotu z aktualizované podmínky ukončení a zadejte číslo 10000 (deset tisíc). Chcete-li uložit tuto změnu, vyberte OK .
Chcete-li tyto aktualizace uložit, vyberte Dokončit .
Výběrem možnosti Vrátit se změnami uložte změny do databáze nástroje Orchestrator.
Tento runbook lze použít k experimentování s různými konfiguracemi nástroje Orchestrator. Můžete například vytvořit srovnávací runbooky pro určení výkonu čtyř serverů runbooků nasazených do různých datových center.
| Datové centrum | Konfigurace protokolování | Doba běhu kódu platformy (milisekundy) | Milisekundy na aktivitu | Koeficient |
|---|---|---|---|---|
| Umístění 1 | Výchozí protokolování | 819 | 82 | 1.0 (odkaz) |
| Umístění 1 | Protokolování běžných publikovaných dat | 2012 | 201 | 2.5 |
| Umístění 2 | Výchozí protokolování | 1229 | 123 | 1.5 |
| Umístění 2 | Protokolování běžných publikovaných dat | 3686 | 369 | 4.5 |
| Umístění 3 | Výchozí protokolování | 2457 | 426 | 3,0 |
| Umístění 3 | Protokolování běžných publikovaných dat | 4422 | 442 | 5.4 |
| Umístění 4 | Výchozí protokolování | 1474 | 147 | 1.8 |
| Umístění 4 | Protokolování běžných publikovaných dat | 2654 | 265 | 3.2 |
Všimněte si významného snížení výkonu platformy způsobeného protokolováním běžných publikovaných dat. Nejhorší scénář se zdá být protokolování běžných publikovaných dat v umístění 2. Na povrchu se zdá, že to je jasný a relevantní závěr.
Je však třeba poznamenat, že tyto údaje odrážejí režijní náklady na kód platformy, nikoli kód domény. Moduly runtime kódu domény můžou být delší. Například vytvoření virtuálního počítače z aktivity šablony v integračním balíčku nástroje Virtual Machine Manager může běžet několik minut při vytváření virtuálního počítače. Rozšířením předchozího příkladu zvažte náklady na kód platformy u aktivity runbooku, která trvá 1 minutu spuštění (1 minuta = 60 000 milisekund) bez ohledu na umístění.
| Datové centrum | Konfigurace protokolování | Doba běhu kódu platformy (milisekundy) | % kódu domény | % kódu platformy |
|---|---|---|---|---|
| Umístění 1 | Výchozí protokolování | 819 | 98.6% | 1.4% |
| Umístění 1 | Protokolování běžných publikovaných dat | 2012 | 96.7% | 3.3% |
| Umístění 2 | Výchozí protokolování | 1229 | 98.0% | 2.0% |
| Umístění 2 | Protokolování běžných publikovaných dat | 3686 | 93.9% | 6.1% |
| Umístění 3 | Výchozí protokolování | 2457 | 95,9 % | 4.1% |
| Umístění 3 | Protokolování běžných publikovaných dat | 4422 | 92,6 % | 7.4% |
| Umístění 4 | Výchozí protokolování | 1474 | 97.5% | 2,5 % |
| Umístění 4 | Protokolování běžných publikovaných dat | 2654 | 95.6% | 4.4% |
Jasnější obrázek začíná vycházet z dat. Scénář, kdy je protokolování běžných publikovaných dat povolené v umístění 2, je stále nejhorším výkonem. Kód platformy a protokolování ale představují pouze 6 % celkového modulu runtime. I když se jedná o významnou hodnotu, nejlepší scénář je 1,4 %. V podstatě čas strávený v kódu domény v příkladu výrazně převáží čas strávený spuštěním kódu platformy. Pokud byste to mohli zcela eliminovat náklady na kód platformy, viděli byste pouze vylepšení výkonu runbooku v rozsahu 1,4 % až 7,4 %.
Většina scénářů z reálného světa se bude lišit. Chování aktivity se může změnit v závislosti na tom, co má kód domény udělat. Například klonování virtuálního počítače z aktivity šablony může trvat jednu minutu, než klonuje virtuální počítač ze šablony serveru A, ale klonování virtuálního počítače ze šablony serveru B trvá 5 minut. Servery runbooku se také můžou nacházet v různých sítích s různými charakteristikami výkonu, což může potenciálně ovlivnit výkon kódu domény a výkon protokolování dat nástroje Orchestrator.
Určení růstu databáze
Správce databáze pro databázi Nástroje orchestrator může použít následující pokyny k určení strategie růstu souborů databáze:
Obecně platí, že soubory databáze se nezvětší při každém vyvolání runbooku. Soubory se zvětší, když data obsažená v nich dosáhnou určitého vysokého vodoznaku nakonfigurovaného správcem databáze, kdy se soubor obecně rozšíří.
Pokaždé, když se aktivita runbooku spustí, by se měla počítat jednotlivě, což by se mělo zvážit, když funkce smyčky můžou způsobit, že se jedna aktivita spustí vícekrát.
Pokud chcete určit úložiště potřebné pro každé vyvolání runbooku, vynásobte počet aktivit v runbooku počtem bajtů přidaných do databáze podle vybrané úrovně protokolování. Tyto hodnoty jsou následující:
524 bajtů
Výchozí konfigurace protokolování
6082 bajtů
Úroveň protokolování běžně publikovaných dat
6082 bajtů + data zaprotokolovaná podle aktivity
Úroveň protokolování publikovaných dat specifická pro konkrétní aktivitu
Orchestrator ve výchozím nastavení vyprázdní všech 500 protokolů pro každý runbook v noci v 2:00. Pokud chcete určit úložiště potřebné pro každé vyvolání runbooku, vynásobte úložiště potřebné pro každé vyvolání runbooku o 500. Pokud změníte nastavení vyprázdnění protokolu, vynásobte každé vyvolání odhadem počtu volání za den, týden nebo měsíc podle potřeby.
Následující tabulka ukazuje odhady růstu a výkonu pro konfigurace na úrovni protokolování.
| Úroveň protokolování | Faktor růstu databáze | Faktor výkonu | Doporučeno pro produkční prostředí |
|---|---|---|---|
| Výchozí | 1 | 1 | Ano |
| Běžná publikovaná data | 11,6x | 2,5x | Omezené použití s plánováním |
| Publikovaná data specifická pro aktivity | Větší než 11,6x | Větší než 2,5x | No |
Příklady
Příklad 1
Následující tabulka popisuje aspekty velikosti databáze pro nasazení nástroje Orchestrator.
| Název runbooku | Počet aktivit | Úroveň protokolování | Volání za den |
|---|---|---|---|
| Runbook 1 | 50 | Výchozí | 100 |
| Runbook 2 | 25 | Výchozí | 50 |
| Runbook 3 | 12 | Běžná publikovaná data | 24 |
| Runbook 4 | 8 | Běžná publikovaná data | 500 |
Pomocí výše popsané velikosti databáze můžete odhadnout požadavky na úložiště pro runbooky.
| Název runbooku | Bajty na volání | Úložiště v MB Výchozí vymazání protokolu (500 volání) |
Vyvolání za měsíc | Úložiště v MB Jeden měsíc (Výchozí vymazání protokolu) |
% úložiště databáze po 30 dnech |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74,5 | %9 |
| Runbook 2 | 13,100 | 6,2 | 1 500 | 18.7 | 2 % |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 6 % |
| Runbook 4 | 48,656 | 23.2 | 15 000 | 696.0 | 83 % |
| Celkem: 76,7 MB | Celkem: 839,3 MB |
Tento příklad jasně ilustruje důležitost rozhodování o protokolování dat. Runbook 4 obsahuje pouze osm aktivit, ale při konfiguraci na úrovni protokolování běžně publikovaných dat využívá většinu úložiště v databázi kvůli vysoké frekvenci vyvolání. Na základě těchto výsledků můžete raději snížit úroveň protokolování sady Runbook 4 na výchozí konfiguraci protokolování.
Příklad 2
Následující tabulka popisuje aspekty velikosti databáze pro jiné nasazení nástroje Orchestrator.
| Název runbooku | Počet aktivit | Úroveň protokolování | Volání za den |
|---|---|---|---|
| Runbook 1 | 50 | Výchozí | 100 |
| Runbook 2 | 25 | Výchozí | 50 |
| Runbook 3 | 12 | Běžná publikovaná data | 24 |
| Runbook 4 | 8 | Výchozí | 500 |
Přepočítání údajů o úložišti pro aktualizovanou konfiguraci vede k výrazně odlišným výsledkům.
| Název runbooku | Bajty na volání | Úložiště v MB Výchozí vymazání protokolu (500 volání) |
Vyvolání za měsíc | Úložiště v MB Jeden měsíc (Výchozí vymazání protokolu) |
% úložiště databáze po 30 dnech |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74,5 | 37% |
| Runbook 2 | 13,100 | 6,2 | 1 500 | 18.7 | %9 |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 25 % |
| Runbook 4 | 4,192 | 2.0 | 15 000 | 60.0 | 29 % |
| Celkem: 55,5 MB | Celkem: 203,3 MB |
I když se výchozí konfigurace protokolování (500 položek protokolu na runbook) nemění, 30denní požadavky na úložiště se výrazně změnily. Náklady na úložiště při používání protokolování běžně publikovaných dat pro Runbook 4 by se měly pečlivě zvážit, protože výsledkem této změny je snížení 76% požadavků na úložiště databáze za 30 dnů.
Shrnutí
Ke správě velikosti a výkonu databáze použijte následující pokyny:
Protokolování běžně publikovaných dat povolte jenom v případě potřeby.
Nezapomeňte, že počet spuštění aktivit určuje objem protokolovaných dat. Malý runbook s několika aktivitami může několikrát způsobit více protokolování dat, než větší runbook spustí méněkrát.
Nepovolujte protokolování publikovaných dat specifických pro aktivitu v produkčních prostředích a měly by se používat jenom pro účely ladění.
Zjistěte, kolik času runbooky tráví spouštěním kódu domény v porovnání se spuštěným kódem platformy.
Odhad nákladů na kód platformy pomocí technik popsaných v tomto dokumentu Použijte je jako vodítko při hledání míst ke zlepšení výkonnosti sady Runbook.
Identifikujte příležitosti pro zlepšení vytvořením normalizovaných porovnání svých měření.