Výkon nástroje System Center – Service Manager

Výkon rolí a funkcí serveru system Center – Service Manager má vliv na různé faktory. Obecně platí, že existují tři oblasti, kde je pozitivní a negativní výkon nejvýraznější v Service Manageru:

• Odezva konzoly Service Manageru Jedná se o dobu, kterou trvá od okamžiku, kdy v konzole provedete nějakou akci, dokud se neskončí.

• Čas vložení dat pro konektory Takto dlouho trvá, než Service Manager naimportuje data při synchronizaci konektoru.

• Doba dokončení pracovního postupu Jedná se o dobu potřebnou k automatickému použití nějaké akce pracovním postupům.

Výkon konektoru

Počáteční synchronizace konektoru může trvat značné množství času; Například 8 až 12 hodin pro rozsáhlou počáteční synchronizaci s Configuration Managerem. Vzhledem k tomu, že se konektor zpočátku synchronizuje, můžete očekávat, že během této doby dojde k omezení výkonu pro všechny role a procesy serveru Service Manageru. K tomu dochází kvůli tomu, jak se data vkládají postupně do databáze portálu Service Manager, což je databáze Microsoft SQL Serveru. I když nemůžete urychlit počáteční proces synchronizace konektoru, můžete naplánovat počáteční synchronizaci a zajistit, aby se proces synchronizace dokončil dobře, než se Service Manager vloží do produkčního prostředí.

Po dokončení počáteční synchronizace Service Manager pokračuje v synchronizaci rozdílů, které nemají měřitelný dopad na výkon.

Výkon pracovního postupu

Pracovní postupy jsou automatické procesy, ke kterým dochází. Zahrnují odesílání e-mailových oznámení, další krok aktivace žádosti o změnu a automatické použití šablony.

Mezi aspekty výkonu pracovního postupu patří:

• Pracovní postupy se obvykle spouštějí a končí do jedné minuty. Pokud jsou role serveru Service Manageru pod velkým zatížením, pracovní postupy se nedokončí tak rychle jako obvykle.

• Kromě toho při vytváření nových pracovních postupů, například nového odběru oznámení, se do systému umístí další zatížení. S rostoucím počtem nových pracovních postupů, které vytvoříte, se zvýší i doba trvání každého pracovního postupu.

Pokud je systém zatížený velkým zatížením , pokud se například vytváří velký počet nových incidentů a každý incident generuje mnoho pracovních postupů, může to mít negativní dopad na výkon.

Vliv skupin, front a rolí uživatelů na výkon

Měli byste plánovat skupiny a role uživatelů v rané fázi. Skupiny byste měli vytvářet střídmě a vytvářet je pro nejmenší možný rozsah. Před vytvořením skupin byste pak měli nejprve naplnit databázi daty ze služby Doména služby Active Directory Services (AD DS), Configuration Manageru a nástroje System Center Operations Manager.

Správci často vytvářejí skupiny, aby měli uživatelé přístup jenom k určeným skupinám. V jednom scénáři můžete například chtít vytvořit podmnožinu incidentů, například incidenty, které ovlivňují počítače používané pracovníky lidských zdrojů. V tomto scénáři můžete chtít, aby mohli zobrazit nebo upravit skupinu citlivých serverů jenom konkrétní pracovníci. Pokud chcete tento typ povolit pro přístup, musíte vytvořit skupinu pro všechny uživatele a skupinu pro citlivé počítače a pak zajistit, aby role zabezpečení má přístup ke skupinám Všichni uživatelé i Citlivé servery. Vytvoření skupiny obsahující všechny uživatele má za následek dopad na výkon, protože Service Manager často kontroluje, jestli ve skupině nedošlo ke změnám. Tato kontrola se ve výchozím nastavení provádí jednou za 30 sekund. U velké skupiny kontrola změn vytváří velké zatížení systému a může výrazně zpomalit dobu odezvy.

Řešení 1: Ručně můžete určit, jak často Service Manager kontroluje změny skupiny úpravou klíče registru. Pokud například změníte frekvenci kontroly skupiny z 30 sekund na 10 minut, výrazně zvýšíte výkon. Fronty a cíle na úrovni služby jsou však speciální druhy skupin, které používají stejný interval dotazování na výpočet skupiny. Zvýšení hodnoty intervalu dotazování tedy vede k delším časovým obdobím pro výpočty cílů na úrovni fronty a služby.

Upozornění

Nesprávná úprava registru může vážně poškodit systém. Před prováděním změn registru byste měli v počítači zálohovat veškerá cenná data.

Ruční zadání intervalu kontroly změn skupiny

1. Spusťte regedit a přejděte na HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

2. Vytvořte novou hodnotu DWORD s názvem GroupCalcPollingIntervalMilliseconds.

3. Jako hodnotu zadejte interval v milisekundách. Výsledek se vynásobí 6. Pokud například chcete nastavit interval na 10 minut, zadejte 6 00000.

4. Restartujte službu System Center Management.

Řešení 2: Pomocí skriptu Prostředí Windows PowerShell můžete do role uživatele přidat objekty typu, například Uživatelé. Analytik, který je přihlášený v této roli, má v podstatě přístup ke všem objektům, které mají typ rovnající se "Uživatel". Pokud použijete tuto metodu, eliminujete potřebu velké skupiny ("Všichni uživatelé") a nákladnou kontrolu, že Service Manager provádí určení členství v této skupině. Na serveru pro správu Portálu pro správu můžete spustit následující skript Prostředí Windows PowerShell, který přidá typ "uživatel" do role RoleName. Tento ukázkový skript pro vaše prostředí musíte upravit.

Spuštění skriptu Prostředí Windows PowerShell pro přidání objektů do role uživatele

• Podle potřeby upravte následující skript a spusťte ho:

#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}  

Zobrazení výkonu

Při vytváření zobrazení naplánujte použití "typických" tříd v systému, kdykoli je to možné. Většina tříd objektů má například dva typy: "typická" a "pokročilá". Typický typ objektu obsahuje jednoduché odkazy na malou podmnožinu dat, která souvisí s položkou. Rozšířený typ obsahuje mnoho složitých odkazů na data, která souvisejí s položkou. Typické typy jsou jednoduché projekce; pokročilé typy jsou komplexní projekce. Většina pokročilých typů objektů se používá k naplnění různých polí ve formulářích, které byste normálně nechtěli zobrazit v zobrazení. Kdykoli vytvoříte zobrazení založené na rozšířeném typu objektu a při otevření zobrazení se Service Manager dotazuje na databázi a načte se velké množství dat. Velmi málo načtených dat se ale zobrazuje nebo používá.

Pokud narazíte na problémy s výkonem zobrazení, která jste definovali při použití pokročilých typů objektů v zobrazeních, přepněte na používání typických typů. Alternativně můžete vytvořit vlastní typy projekce, které obsahují jenom data, na která potřebujete vytvořit zobrazení.

Výkon databáze portálu Service Manager

Výkon databáze portálu Service Manager je přímo ovlivněn různými faktory, včetně počtu souběžných konzol Service Manageru, které čtou nebo zapisují data, intervalu kontroly změn skupiny a dat vložených konektory. Další informace jsou k dispozici v tomto dokumentu. Tady je několik klíčových bodů:

• Pro server pro správu, který je hostitelem databáze Portálu pro správu, byste měli mít minimálně 8 gigabajtů (GB), abyste mohli mít přijatelnou dobu odezvy v typických scénářích.

• Na počítači, který je hostitelem databáze portálu Service Manager, byste měli mít alespoň 8 jader procesoru.

• Pokud je to možné, můžete dosáhnout lepšího výkonu databáze oddělením souborů protokolů a datových souborů na samostatné fyzické disky. Další výhody můžete dosáhnout přesunutím databáze tempdb na jinou fyzickou jednotku RAID než databázi Service Manageru. Pokud je to možné, použijte diskový systém RAID 1+0 k hostování databáze Service Manageru.

• Výkon může být negativně ovlivněn, pokud je databáze Service Manageru vytvořená s menší velikostí a je nastavená na automatické zvětšování, zejména malými přírůstky.

Nápovědu k posouzení velikosti databáze najdete v nástroji Pomocník pro změnu velikosti portálu Service Manager, který je součástí sady dokumentace k úlohě Service Manageru (SM_job_aids.zip), a vytvořte databázi s velikostí, která je blíž ke konečné velikosti. To pomůže výkonu snížením počtu, kolikrát se databáze musí automaticky zvětšovat.

Podobně platí i všechny ostatní osvědčené postupy pro vysoce výkonnou databázi. Pokud například můžete využít výhod nadřazeného diskového subsystému, můžete využít rozdělení skupin tabulek v příslušných skupinách souborů a jejich přesunutí na jinou fyzickou jednotku.

Výkon serveru pro správu Service Manageru

Výkon serveru pro správu portálu Service Manager je primárně ovlivněn počtem aktivních souběžných konzol Service Manageru. Vzhledem k tomu, že všechny role Portálu pro správu komunikují se serverem pro správu, zvažte přidání dalších serverů pro správu, pokud plánujete mít velký počet souběžných konzol. Pro server pro správu byste měli mít 8 GB paměti RAM. Za předpokladu, že máte 10 až 12 aktivních konzol na jádro procesoru, měli byste mít alespoň 4 jádra procesoru na jeden server pro správu.

Výkon konzoly Service Manageru

Výkon konzoly portálu Service Manager je primárně ovlivněn počtem formulářů, které mají vaši analytici obvykle otevřené a množství dat načtených zobrazeními. V počítači, na kterém je nainstalovaná konzola portálu Service Manager, byste měli mít 4 GB paměti RAM. Pokud máte zobrazení, která načítají velké množství dat, budete potřebovat další paměť RAM. Pro počítač, na kterém je nainstalovaná konzola portálu Service Manager, byste měli mít alespoň 4jádrový procesor. Vzhledem k tomu, že konzola Service Manageru je aplikace koncového uživatele, doporučujeme ji restartovat, pokud se zobrazí nadměrná spotřeba prostředků. Konzola Service Manageru agresivně ukládá informace do mezipaměti, což může přispět k celkovému využití paměti.

Výkon databáze datového skladu Service Manageru

Výkon datového skladu je přímo ovlivněn různými faktory, včetně počtu souběžných serverů pro správu Service Manageru odesílajících data, objemu uložených dat nebo doby uchovávání dat, rychlosti změny dat a extrakce, transformace a frekvence načítání (ETL). Množství dat uložených v datovém skladu se v průběhu času zvyšuje. Zajištění archivace nepotřebných dat je důležité. Dalším faktorem, který ovlivňuje výkon datového skladu, je nastavení BatchSize procesů ETL.

Lepšího výkonu dosáhnete oddělením souborů protokolů a datových souborů na samostatné fyzické disky. Měli byste se však vyhnout umístění více než jednoho souboru protokolu na disk. Podobně můžete dosáhnout lepší propustnosti tím, že databázi tempdb umístíte na jiný fyzický disk než ostatní databáze. Nakonec můžete využít výhod tím, že umístíte různé databáze na příslušné fyzické disky. Pokud je to možné, použijte diskový systém RAID 1+0 k hostování datového skladu. Pro počítač, na kterém jsou nainstalované databáze datového skladu, byste obecně měli mít minimálně 8 GB paměti RAM. Pokud máte další zdroje dat datového skladu z Operations Manageru nebo Configuration Manageru, měli byste zvýšit velikost paměti RAM pro databáze. V počítači s SQL Serverem, který je hostitelem datového skladu, získáte větší využití paměti, a ještě více, pokud jsou databáze Datamart a Úložiště na stejném serveru. Pokud ale máte v topologii nasazení 4 000 nebo méně počítačů, stačí 4 GB. V počítači, na kterém je nainstalovaná databáze datového skladu, byste měli mít alespoň 8 jader procesoru. Další jádra vám pomůžou s výkonem ETL i sestav.

Výkon může být negativně ovlivněn, pokud jsou všechny databáze v systému vytvořeny s menší velikostí a nastaveny na automatické zvětšování, zejména malými přírůstky. Podívejte se na nástroj Pomocník pro změnu velikosti Service Manageru, který je součástí sady dokumentace (SM_job_aids.zip) k posouzení velikosti databáze a vytvoření databáze s velikostí, která je blíž ke konečné velikosti, což pomůže snížit výkon snížením počtu, kolikrát se databáze musí automaticky zvětšovat.

Service Manager obsahuje integrovanou podporu pro skupiny souborů. Z toho můžete těžit tak, že umístíte skupiny souborů na samostatné pevné disky. Další informace o osvědčených postupech pro skupinu souborů najdete v dokumentaci k SQL Serveru.

Výkon serveru datového skladu Service Manageru

Výkon serveru datového skladu má vliv na počet serverů pro správu Portálu pro správu, které jsou zaregistrované v datovém skladu, velikosti nasazení a počtu zdrojů dat. Obecně byste měli mít minimálně 8 GB paměti RAM pro server datového skladu. Výkon ale bude výhodný tím, že bude mít další paměť pro pokročilé scénáře nasazení, kdy do datového skladu vloží více než jeden server pro správu Service Manageru data. Pokud potřebujete odpočinout výkon, měla by nejvyšší priorita být pro paměť pro počítač s SQL Serverem. Abyste zabránili problémům s výkonem, měli byste mít alespoň 8 jader procesoru.

Výkon samoobslužného portálu

Samoobslužný portál je navržený pro snadný přístup k vytváření incidentů a žádostí o služby. Není navržená tak, aby zpracovávala tisíce uživatelů současně.

Testování výkonnosti samoobslužného portálu se zaměřilo konkrétně na typické scénáře "pondělí ráno", aby se zajistilo, že se stovky uživatelů v pondělí ráno můžou přihlásit během 5 až 10 minut a otevřít incidenty s přijatelnou dobou odezvy (méně než 4 až 5 sekund). Tento cíl byl dosažen s minimálním hardwarem doporučeným v tomto dokumentu.

Výkon cíle na úrovni služby

Neexistuje žádný konkrétní počet cílů na úrovni služeb, které Service Manager podporuje. Pokud má například organizace obvykle málo incidentů, může podporovat více cílů na úrovni služeb, než by jinak mohla být schopná. Větší objem incidentů ale může podle potřeby vyžadovat méně cílů na úrovni služeb nebo horizontální navýšení kapacity dalšího hardwaru a softwaru. Doporučujeme vytvořit maximálně pět cílů na úrovni služby pro typickou konfiguraci Service Manageru 50 000 počítačů. Možná byste mohli vytvořit další cíle na úrovni služby. Vzhledem k tomu, že se podmínky výrazně liší od organizace po organizaci, Microsoft nemůže poskytnout konkrétní doporučení pro počet cílů na úrovni služeb, které byste neměli překročit. Pokud vaše konfigurace nasazení trpí nízkým výkonem v důsledku počtu cílů na úrovni služby, doporučujeme škálovat na více instancí pomocí scénáře dalšího většího nasazení, jak je popsáno v článku Konfigurace scénářů nasazení tohoto průvodce.

Další kroky

• Další informace o konfiguracích hardwaru a softwaru pro scénáře nasazení Service Manageru najdete v doporučených scénářích topologie nasazení.