Datasbasens storlek och prestanda
Viktigt
Den här versionen av Orchestrator har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Orchestrator 2022.
Databasens storlek är nyckeln till att förstå prestanda för System Center – Orchestrator. Runbook-servrarna, Management-servern och webbkomponenterna är alla beroende av Orchestrator-databasen för att fungera. Problem med Orchestrator-distributioner kan uppstå från en ofullständig förståelse av datatyperna i databasen och hur de hanteras.
Eftersom Runbook Designer kommunicerar med Orchestrator-databasen (via Management-servern) kan låga databasprestanda inverka negativt på kommunikationen.
Orchestrator-operatörsupplevelsen baseras på två komponenter: Orchestration-konsolen och webbtjänsten. Orchestration Console är ett Silverlight-baserat program som är beroende av webbtjänsten för anslutningen till Orchestrator-databasen. Webbtjänsten är ett IIS-program som används för att ansluta till databasen. Därför är både webbtjänsten och Orchestration Console beroende av Orchestrator-databasens prestanda.
Även om Orchestration Console är beroende av webbtjänsten har den också logik som är unik för dess funktion som användargränssnitt och dess egna prestandaegenskaper.
Konfigurationsdata och loggdata
På hög nivå innehåller Ochestrator-databasen två typer av data:
Konfigurationsdata
Orchestrator-infrastrukturen innehåller konfigurationsdata. Konfigurationsdata påverkar inte nämnvärt databasens storlek eftersom den typen av data kräver lite lagringsutrymme.
Loggdata
Orchestrator skapar olika typer av loggdata, som alla kan visas och hanteras i Runbook-designer. Lagringskraven för denna datatyp kan variera i storlek och vara stora.
I följande tabell visas de typer av inloggningsdata som du kan lagra i Orchestrator-databasen. Orchestrator lagrar även data i separata loggfiler (utanför databasen) för spårning och spårning. Mer information om alla typer av loggdata finns i Orchestrator-loggar.
| Typ av loggdata | Plats i Runbook Designer | Hanteras av loggrensning? |
|---|---|---|
| Runbook-loggar | Flikar för logg- och logghistorik | Yes |
| Aktivitetshändelser (plattform) | Fliken Händelser | No |
| Granskningshistorik | Fliken Granskningshistorik | No |
Plattformskod och domänkod
Orchestrator Runbook-aktiviteter innehåller två olika typer av kod:
Plattformskod
Det här är en gemensam kod som delas av de flesta aktiviteter och används för att köra vanliga uppgifter som utförs av Orchestrator-aktiviteter. Plattformskoden genererar vanliga publicerade data.
Domänkod
Kör en rad olika uppgifter som är specifika för varje aktivitets åtgärder, som vanligtvis inte är kopplade till själva Orchestrator-plattformen. Variationen kan vara mycket stor mellan plattformskoden och domänkoden.
Loggningsdata som genereras för en viss aktivitet kan innehålla dataelement som är enkla eller flervärdesbaserade. Varje aktivitet genererar en enda post med data med ett värde. Domänkod kan producera flera poster med data med flera värden och ansvarar därför för att fastställa vad aktiviteten gör med vanliga publicerade data som den har tagit emot från tidigare aktiviteter.
Orchestrator-Runbooks är i princip konstruerade för att överföra data mellan diskreta domänkodselement. Domänkod kan också generera aktivitetsspecifika publicerade data.
Alla Runbooks fungerar på liknande sätt: de kör aktiviteter som består av domänkod och plattformskod, de kör arbetsflöde i slingor och de använder förgreningar. Förgrening är när en Runbook anropar en annan Runbook för att utföra en viss uppgift. När en Runbook först anropas består den av en ensam tråd. När denna tråd stöter på en Runbook-aktivitet vars länkar kräver en förgrening, skapas ytterligare trådar, en tråd för varje gren. Var och en av trådarna tar emot vanliga publicerade data från den aktivitet som skapade grenen. Dessa data växelverkar med föregående aktiviteter i Runbook för att uppdatera de vanliga publicerade data som aktiviteterna prenumererar på.
Domänkod kan påverka databasens prestanda mer än flertrådsing som genereras av branchning. Det beror på att domänkod potentiellt kan generera stora mängder aktivitetsspecifika publicerade data.
Loggningsalternativ
På fliken Loggning i Egenskaper för en runbook kan du välja att lagra loggningsposter. Termen standardloggning innebär att inget av de två alternativen för publicerade data har valts, vilket motsvarar 524 byte som genereras för varje aktivitet. Loggningsalternativen avser två kategorier vanliga publicerade data:
Vanliga publicerade data
En uppsättning dataobjekt som är gemensamma för alla aktiviteter. En lista finns i Loggalternativ för Runbook.
Det här loggningsalternativet genererar 6 082 byte per aktivitet.
Aktivitetsspecifika publicerade data
En specifik datauppsättning för den aktivitet som skapats av domänkoden.
Det här loggningsalternativet genererar 6 082 byte utöver de byte som loggas av specifika aktiviteter.
[TIPS]
Det här alternativet är främst avsett att användas vid felsökning. Låt det vara avmarkerat för att begränsa loggningsstorleken.
Loggningsinställningarna kan avsevärt påverka databasens storlek och prestanda. Tänk dig ett scenario där samma Runbook-aktivitet körs två gånger, först med dataloggning på standardnivå (inga alternativ valda för publicerade data) och sedan med alternativet för loggning av vanliga publicerade data aktiverat. Själva domänkoden bör ta samma tid att slutföra. Plattformskoden kommer däremot att ta längre tid att köra eftersom den måste hantera en 12 gånger större datamängd med loggning av vanliga publicerade data aktiverat än när den kördes med bara standardloggning.
Rensa loggar
Standardalternativen som anges för loggrensningsfunktionen i Runbook-designer är konfigurerade för att ge bästa möjliga användarupplevelse för en oanvänd Orchestrator-distribution. Att ändra dessa värden kan ändra miljöns prestandaegenskaper och bör implementeras gradvis och högvattenmärket, så att effekten av ändringen kan utvärderas.
Mer information om automatisk och manuell rensning av loggar finns i Rensa Runbook-loggar.
Skapa jämförelsemått för prestanda
Om du vill skapa en enkel runbook för att testa loggningstillväxten kan du använda Standard Activity Compare Values (Jämför värden för standardaktivitet) för att skapa benchmark-värden för en Orchestrator-miljö.
Följande procedur skapar en enkel runbook som kör aktiviteten Jämför värden 10 000 gånger. Jämför värden är en mycket enkel aktivitet vars domänkod är ganska minimal. Denna Runbook kan anropas under ett antal olika omständigheter för att ge en uppfattning om allmänna prestanda för en viss Orchestrator-körningsmiljö.
Skapa en Runbook som kan användas för att skapa prestandamått för Orchestrator-miljön
Skapa en ny Runbook.
Lägg till aktiviteten Jämför värden från standardaktivitetspaletten. Dubbelklicka på aktiviteten för att konfigurera den.
Klicka på fliken Allmänt och konfigurera den här aktiviteten för att jämföra strängar (standardvärdet).
Klicka på fliken Information, skriv värdet STRING i rutan Test och välj är tom.
Klicka på Slutför för att spara uppdateringarna för aktiviteten.
Högerklicka på aktiviteten och välj Looping (Loopning).
Markera kryssrutan Aktivera och ange siffran 0 (noll ) för Fördröjning mellan försök.
Klicka på fliken Avsluta.
Ändra standardvillkoret för avslut. Klicka på Jämför värden, markera kryssrutan Visa vanliga publicerade data och välj Loop: Antal försök. Spara ändringen genom att klicka på OK.
Välj värde från det uppdaterade slutvillkoret och skriv numret 10000 (tiotusen). Spara ändringen genom att klicka på OK.
Spara uppdateringarna genom att klicka på Slutför.
Klicka på Checka in för att spara ändringarna i Orchestrator-databasen.
Du kan använda denna Runbook för att experimentera med olika Orchestrator-konfigurationer. Anta till exempel att du vill skapa riktmärken för fyra olika Runbook-servrar som distribuerats till olika datacenter.
| Datacenter | Loggningskonfiguration | Plattformskodens körtid (millisekunder) | Millisekunder per aktivitet | Skalfaktor |
|---|---|---|---|---|
| Plats 1 | Standardloggning | 819 | 82 | 1.0 (referens) |
| Plats 1 | Loggning av vanliga publicerade data | 2012 | 201 | 2.5 |
| Plats 2 | Standardloggning | 1229 | 123 | 1.5 |
| Plats 2 | Loggning av vanliga publicerade data | 3686 | 369 | 4,5 |
| Plats 3 | Standardloggning | 2457 | 426 | 3.0 |
| Plats 3 | Loggning av vanliga publicerade data | 4422 | 442 | 5.4 |
| Plats 4 | Standardloggning | 1474 | 147 | 1.8 |
| Plats 4 | Loggning av vanliga publicerade data | 2654 | 265 | 3.2 |
Lägg märke till den betydande minskning i prestanda som uppstår vid loggning av vanliga publicerade data. Det sämsta scenariot verkar vara loggning av vanliga publicerade data vid Plats 2. Vid en första anblick verkar detta vara en klar och relevant slutsats.
Det bör dock noteras att dessa siffror avspeglar extrakostnaden för plattformskoden och inte för domänkoden. Körtiderna för domänkoden kan vara betydligt längre. Till exempel kan aktiviteten Skapa virtuell dator från mall i Virtual Machine Manager Integration Pack köras i flera minuter när den virtuella datorn skapas. Om du expanderar i föregående exempel kan du överväga kostnaderna för plattformskod för en Runbook-aktivitet som tar 1 minut att köra (1 minut = 60 000 millisekunder) oavsett plats.
| Datacenter | Loggningskonfiguration | Plattformskodens körtid (millisekunder) | % domänkod | % plattformskod |
|---|---|---|---|---|
| Plats 1 | Standardloggning | 819 | 98.6% | 1.4% |
| Plats 1 | Loggning av vanliga publicerade data | 2012 | 96.7% | 3.3% |
| Plats 2 | Standardloggning | 1229 | 98.0% | 2.0% |
| Plats 2 | Loggning av vanliga publicerade data | 3686 | 93.9% | 6.1% |
| Plats 3 | Standardloggning | 2457 | 95.9% | 4.1% |
| Plats 3 | Loggning av vanliga publicerade data | 4422 | 92.6% | 7.4% |
| Plats 4 | Standardloggning | 1474 | 97.5% | 2.5% |
| Plats 4 | Loggning av vanliga publicerade data | 2654 | 95.6% | 4,4 % |
Dessa data ger oss en tydligare bild. Scenariot där loggning av vanliga publicerade data är aktiverat vid Plats 2 fortsätter att ha sämst prestanda. Men plattformskoden och loggningen svarar samtidigt bara för 6 % av den totala körtiden. Även om det här är en betydande siffra är det bästa scenariot 1,4 %. Den tid som i det här exemplet förbrukats av domänkoden överväger stort den tid som förbrukats av plattformskoden. För att ge lite perspektiv kan vi konstatera att även om vi helt skulle kunna eliminera kostnaden för plattformskoden, skulle förbättringen i Runbook-prestanda endast handla om 1,4 till 7,4 %.
De flesta verkliga scenarier kommer förstås att vara annorlunda. Aktiviteternas beteende kan ändras beroende på vad domänkoden ska utföra. Det kan till exempel ta en minut för en klonad virtuell dator från mallaktiviteten att klona en virtuell dator från Servermall A, men det tar fem minuter att klona en virtuell dator från Servermall B. Dessutom kan Runbook-servrar finnas i olika nätverk med olika prestandaegenskaper, vilket potentiellt kan påverka både prestanda för domänkod och Orchestrator-dataloggningsprestanda.
Fastställa databasens växande storlek
Databasadministratören för Orchestrator-databasen kan använda följande riktlinjer för att fastställa en strategi för databasfilens växande storlek:
Databasfilerna ökar vanligtvis inte i storlek varje gång en Runbook anropas. Filerna växer när informationen i dem når den övre gräns som angetts av databasadministratören, då storleken på filen vanligtvis ökar.
Varje gång en Runbook-aktivitet körs bör den räknas separat. Detta bör tas med i beräkningen för de slingfunktioner som kan köra samma aktivitet flera gånger.
Du kan fastställa hur mycket lagringsutrymme som krävs för varje Runbook-anrop genom att multiplicera antalet aktiviteter i Runbook med antalet tillagda byte i databasen enligt den valda loggningsnivån. Värdena är följande:
524 byte
Standardloggningskonfiguration.
6 082 byte
Loggningsnivå för vanliga publicerade data.
6 082 byte + data som loggas av aktivitet
Aktivitetsspecifik nivå för loggning av publicerade data.
Som standard rensar Orchestrator alla utom de senaste 500 loggarna för varje runbook varje natt kl. 02:00. För att fastställa vilken lagring som krävs för varje anrop av runbooken multiplicerar du den lagring som behövs för varje anrop av runbooken med 500. Om du ändrar inställningen Loggrensning multiplicerar du varje anrop med det beräknade antalet anrop per dag, vecka eller månad efter behov.
I följande tabell visas beräknade värden för storleksökning och prestanda för loggningsnivåkonfigurationerna.
| Loggningsnivå | Tillväxtfaktor för databasen | Prestandafaktor | Rekommenderat för produktion |
|---|---|---|---|
| Standardvärde | 1 | 1 | Yes |
| Vanliga publicerade data | x 11,6 | x 2,5 | Begränsad användning med planering |
| Aktivitetsspecifika publicerade data | Större än x 11,6 | Större än x 2,5 | No |
Exempel
Exempel 1
I följande tabell beskrivs överväganden för databasändring för en distribution av Orchestrator.
| Runbook-namn | Antal aktiviteter | Loggningsnivå | Anrop per dag |
|---|---|---|---|
| Runbook 1 | 50 | Standardvärde | 100 |
| Runbook 2 | 25 | Standardvärde | 50 |
| Runbook 3 | 12 | Vanliga publicerade data | 24 |
| Runbook 4 | 8 | Vanliga publicerade data | 500 |
Använd måtten för databasstorleken ovan för att beräkna hur mycket lagringsutrymme som behövs för Runbooks.
| Runbook-namn | Byte per anrop | Lagring i MB Standardloggrensning (500 anrop) |
Anrop per månad | Lagring i MB En månad (Inte standardloggrensning) |
% databaslagring efter 30 dagar |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74.5 | 9% |
| Runbook 2 | 13,100 | 6,2 | 1500 | 18,7 | 2 % |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 6 % |
| Runbook 4 | 48,656 | 23.2 | 15 000 | 696.0 | 83 % |
| Totalt: 76,7 MB | Totalt: 839,8 MB |
Det här exemplet visar tydligt hur viktigt det är att fatta välgrundade beslut om dataloggning. Runbook 4 innehåller bara åtta aktiviteter men när den är konfigurerad på loggningsnivån för vanliga publicerade data upptar den störst mängd lagringsutrymme i databasen på grund av den höga anropsfrekvensen. En bra idé kan då vara att minska loggningsnivån för Runbook 4 till standardloggningskonfigurationen.
Exempel 2
I följande tabell beskrivs överväganden för databasändring för en annan distribution av Orchestrator.
| Runbook-namn | Antal aktiviteter | Loggningsnivå | Anrop per dag |
|---|---|---|---|
| Runbook 1 | 50 | Standardvärde | 100 |
| Runbook 2 | 25 | Standardvärde | 50 |
| Runbook 3 | 12 | Vanliga publicerade data | 24 |
| Runbook 4 | 8 | Standardvärde | 500 |
En omberäkning av lagringssiffrorna för den uppdaterade konfigurationen ger helt andra resultat.
| Runbook-namn | Byte per anrop | Lagring i MB Standardloggrensning (500 anrop) |
Anrop per månad | Lagring i MB En månad (Inte standardloggrensning) |
% databaslagring efter 30 dagar |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3 000 | 74.5 | 37 % |
| Runbook 2 | 13,100 | 6,2 | 1500 | 18,7 | 9% |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 25 % |
| Runbook 4 | 4,192 | 2.0 | 15 000 | 60,0 | 29% |
| Totalt: 55,5 MB | Totalt: 203,8 MB |
Standardkonfigurationen för loggning är mycket liten (500 loggposter per runbook), men lagringskraven på 30 dagar har ändrats mycket. Lagringskostnaden för att använda loggning av vanliga publicerade data för Runbook 4 bör tas med i beräkningen eftersom denna ändring medför en minskning med 76 % av databaslagringsbehoven för 30 dagars data.
Sammanfattning
Använd följande riktlinjer för att hantera databasens storlek och prestanda:
Aktivera bara loggning av vanliga publicerade data om det behövs.
Kom också ihåg att det antal gånger en aktivitet körs avgör den mängd information som loggas. En liten Runbook med få aktiviteter som körs många gånger kan resultera i en större mängd loggade data än en större Runbook som körs ett färre antal gånger.
Aktivera inte loggning av aktivitetsspecifika publicerade data i produktionsmiljöer och bör endast användas för felsökning.
Bilda dig en uppfattning om den tid dina Runbook-tillämpningar tillbringar med bearbetning av domänkod jämfört med bearbetning av plattformskod.
Gör en uppskattning av kostnaderna för plattformskod med hjälp av de metoder som beskrivs i det här dokumentet. Använd resultatet som referens när du undersöker hur du kan förbättra Runbook-prestanda.
Identifiera möjligheter till förbättring genom att göra normaliserade jämförelser av dina prestandamätningar.