Sdílet prostřednictvím

Výkon portálu Service Manager

  • Článek

 

Publikováno: červenec 2016

Platí pro: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Výkon pro role serveru a funkce portálu System Center 2012 – Service Manager je ovlivňován různými faktory. Obecně platí, že existují tři oblasti, kde se na portálu Service Manager pozitivní a negativní dopad na výkon projevuje nejvíce:

  • Rychlost reakce konzoly Konzola Service Manager. Jde o dobu od okamžiku, kdy v konzole provedete nějakou akci, do okamžiku, kdy ji konzola dokončí.

  • Doba vkládání dat pro konektory. Jde o dobu, jakou trvá, než portál Service Manager naimportuje data při synchronizaci konektoru.

  • Doba dokončení pracovních postupů. Jde o dobu, jakou trvá, než pracovní postupy automaticky provedou nějakou akci.

Výkon konektoru

Počáteční synchronizace konektoru může trvat poměrně dlouhou dobu, u rozsáhlé počáteční synchronizace s nástrojem System Center Configuration Manager například 8 až 12 hodin. Při počáteční synchronizaci konektoru můžete očekávat snížení výkonu u všech rolí serveru a procesů portálu Service Manager. K tomu dochází z důvodu toho, jakým způsobem jsou data postupně vkládána do databáze portálu Service Manager, která je databází systému Microsoft SQL Server. Přestože nelze proces počáteční synchronizace konektoru urychlit, můžete počáteční synchronizaci naplánovat a zajistit tak, aby byl proces synchronizace dokončen dříve, než bude portál Service Manager zprovozněn v produkčním prostředí.

Po dokončení počáteční synchronizace portál Service Manager pokračuje v synchronizaci rozdílů, což však nemá měřitelný dopad na výkon.

Výkon pracovních postupů

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

Z hlediska výkonu pracovních postupů je třeba vzít v úvahu následující:

  • Za normálních okolností jsou pracovní postupy spuštěny a dokončeny během jedné minuty. Když jsou role serveru portálu Service Manager výrazně zatíženy, pracovní postupy se nedokončí tak rychle jako za normálních okolností.

  • Kromě toho je systém dále zatěžován při vytváření nových pracovních postupů, jako je například nový odběr oznámení. Se vzrůstajícím počtem nově vytvářených pracovních postupů se prodlužuje také doba potřebná pro běh každého pracovního postupu.

Když je systém intenzivně zatěžován (například v případě, že je vytvářen velký počet nových incidentů a kdy každý incident generuje mnoho pracovních postupů), může být výkon negativně ovlivněn.

Výkon pracovních postupů na portále System Center 2012 – Service Manager se v porovnání s verzí System Center Service Manager 2010 zvýšil, protože nová sada Management Pack ManagmentHostKeepAlive zlepšila odezvu zpracování pracovních postupů, takže téměř všechny pracovní postupy jsou zpracovány během jedné minuty.

Dopad používání skupin, fronty a role uživatele na výkon

Používání skupin a rolí uživatelů byste měli plánovat již v rané fázi. Skupiny doporučujeme vytvářet co nejméně a také je doporučujeme vytvářet pro co nejmenší obor. Pak také platí, že byste před vytvořením skupiny měli nejprve naplnit databázi daty ze služby Active Directory Domain Services (AD DS), nástroje System Center Configuration Manager a nástroje System Center Operations Manager.

Správci často vytvářejí skupiny, aby měli jistotu, že budou mít uživatelé přístup pouze k určeným skupinám. Například v jednom scénáři můžete chtít vytvořit pouze podmnožinu incidentů, například incidentů, které se týkají počítačů používaných pracovníky oddělení lidských zdrojů. V takovém scénáři můžete chtít, aby mohli zobrazovat nebo upravovat skupinu citlivých serverů pouze konkrétní pracovníci. Pokud pak budete chtít povolit tento typ přístupu, bude nutné vytvořit skupinu pro všechny uživatele a skupinu pro citlivé počítače a pak zajistit, aby role zabezpečení měla přístup jak ke skupině Všichni uživatelé, tak ke skupině Citlivé servery. Vytvoření skupiny obsahující všechny uživatele bude mít nevyhnutelně dopad na výkon, protože portál Service Manager provádí časté kontroly, aby zjistil, zda nedošlo ke změnám skupiny. Tato kontrola ve výchozím nastavení probíhá každých 30 sekund. V případě velmi velkých skupin kontrola změn značně zatěžuje systém, což může výrazně prodloužit dobu odezvy.

Řešení 1: Můžete ručně zadat, jak často má portál Service Manager kontrolovat změny, a to úpravou klíče registru. Výrazného zvýšení výkonu můžete dosáhnout například tak, že změníte frekvenci kontroly skupin z 30 sekund na 10 minut. Fronty a cíle na úrovni služby jsou ale zvláštní typy skupin, které používají stejný interval dotazování skupinových výpočtů. Výsledkem zvýšení hodnoty intervalu dotazování budou delší doby pro výpočty front a cílů na úrovni služby.

System_CAPS_ICON_caution.jpg 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 Editor registru a přejděte ke klíči HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

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

  3. Zadejte pro ni interval v milisekundách. Výsledek se vynásobí šesti. Chcete-li například nastavit interval na 10 minut, zadejte 600000.

  4. Restartujte službu System Center Management.

    Poznámka


    V portálu System Center 2012 R2 Service Manager se služba System Center Management přejmenovala na Microsoft Monitoring Agent.

Řešení 2: Pomocí skriptu prostředí Windows PowerShell můžete přidat objekty typu, například Uživatelé, do role uživatele. V podstatě má analytik, který je přihlášen v rámci této role, přístup ke všem objektům, které mají typ Uživatel. Pokud použijete tuto metodu, můžete eliminovat potřebu vytvářet velmi rozsáhlé skupiny (Všichni uživatelé) a provádět kontroly náročné na prostředky, pomocí kterých portál Service Manager stanovuje členství v této skupině. Na serveru pro správu portálu Service Manager můžete spuštěním následujícího skriptu prostředí Windows PowerShell přidat typ Uživatel do role NázevRole. Tento ukázkový skript Bude nutné upravit pro vaše prostředí.

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

  • Upravte následující skript podle potřeby a spusťte jej:
# 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."  
}

Výkon zobrazení

Při vytváření zobrazení naplánujte, že se budou v systému, kdykoli to bude možné, využívat „typické“ třídy. Většina tříd objektů, například třída pro správu incidentů, má dva typy: „typický“ a „pokročilý“. Typický typ objektu obsahuje jednoduché odkazy na malou podmnožinu dat, která se vztahuje k položce. Pokročilý typ obsahuje mnoho složitých odkazů na data, která se vztahují k určité položce. Typické typy jsou jednoduché projekce; pokročilé typy jsou komplexní projekce. Nejpokročilejší typy objektů se používají k naplnění různých polí ve formulářích, která byste normálně nechtěli mít zobrazena v zobrazení. Kdykoli vytvoříte zobrazení založené na pokročilém typu objektu a otevřete zobrazení, portál Service Manager zadává dotazy databázi a je čteno velké množství dat. Velmi malý objem načtených data je pak však skutečně zobrazen nebo použit.

Pokud narazíte na problémy s výkonem u zobrazení, která jste definovali při používání pokročilých typů objektů v zobrazení, přepněte na používání typických typů. Další možností je vytvořit si své vlastní typy projekce, které obsahují pouze data, která se mají pro zobrazení použít. Další informace naleznete v příspěvku na blogu Vytváření zobrazení, ve kterých se používají související kritéria vlastností (typové projekce): Příklad softwarových zobrazení na blogu technického týmu portálu SCSM.

Výkon databáze portálu Service Manager

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

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

  • V počítači, který je hostitelem databáze portálu Service Manager, byste mít procesor alespoň s 8 jádry.

  • Lepšího výkonu databáze můžete dosáhnout oddělováním souborů protokolu a datových souborů na samostatné fyzické disky (pokud je to možné). Dalších výhod můžete dosáhnout přesunutím databáze tempdb na jinou fyzickou jednotku RAID, než na které se nachází databáze portálu Service Manager. Pokud je to možné, používejte k hostování vaší databáze portálu Service Manager diskový systém RAID 1+0.

  • Výkon může negativně ovlivňovat to, že je databáze portálu Service Manager vytvořena s menší velikostí a je nastavena na automatické zvětšování, zejména po malých přírůstcích.

Pokud potřebujete pomoc při posuzování velikosti databáze a vytvořit databázi s velikostí, která bude co nejblíže ke konečné velikosti, doporučujeme vám seznámit se s Service Managerpomocným nástrojem pro změnu velikosti portálu, který je součástí sady dokumentace Pomůcky úloh nástroje Service Manager (SM_job_aids.zip). To vám pomůže zvýšit výkon snížením četnosti případů, kdy se musí databáze automaticky zvětšovat.

Podobně lze použít také všechny ostatní osvědčené postupy pro databázi s vysokým výkonem. Pokud máte například k dispozici vynikající diskový subsystém, můžete těžit z rozdělení skupin tabulek příslušných skupin souborů a z jejich přesunutí na různé fyzické jednotky.

Výkon serveru pro správu portálu Service Manager

Výkon serveru pro správu portálu Service Manager je ovlivňován především počtem aktivních souběžných konzol Konzola Service Manager. Vzhledem k tomu, že se serverem pro správu mají interakci všechny role portálu Service Manager, zvažte přidání dalších serverů pro správu, pokud máte v plánu používat velký počet současně spouštěných konzol. Pro server pro správu byste měli mít 8 GB paměti RAM. Pro každý server pro správu byste měli mít procesor alespoň se 4 jádry (za předpokladu 10 až 12 aktivních konzol na jádro procesoru).

Výkon konzoly portálu Service Manager

Výkon konzoly Konzola Service Manager je ovlivňován především počtem formulářů, které mají vaši analytici obvykle otevřené, a množstvím dat, která jsou načítána pro zobrazení. V počítači, kde je nainstalována konzola Konzola 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. V počítači, ve kterém je nainstalována konzola Konzola Service Manager, byste měli mít procesor alespoň se 4 jádry. Vzhledem k tomu, že konzola Konzola Service Manager je aplikace koncového uživatele, doporučujeme ji v případě, že si všimnete nadměrné spotřeby prostředků, restartovat. Konzola Konzola Service Manager intenzivně ukládá informace v mezipaměti, což může přispívat k celkovému objemu využívané paměti.

Výkon databáze datového skladu portálu Service Manager

Výkon datového skladu je přímo ovlivňován řadou různých faktorů, včetně počtu souběžných serverů pro správu Service Manager odesílajících data, objemu uložených dat nebo období uchovávání dat, rychlosti změny dat a četnosti zpracování ETL (extrakce, transformace a načítání). Množství dat, které je uloženo v datovém skladu, se průběžně zvyšuje. Je důležité zajistit archivaci dat, která nejsou nezbytně potřeba. Dalším faktorem, který má vliv na výkon datového skladu, je nastavení BatchSize procesů ETL.

Lepšího výkonu můžete dosáhnout oddělováním souborů protokolu 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 jeden disk. Podobně můžete dosáhnout lepší propustnosti tím, že přesunete databázi tempdb na jiný fyzický disk než ostatní databáze. A konečně můžete také dosáhnout zlepšení tím, že umístíte různé databáze na vlastní fyzické disky. Pokud je to možné, používejte k hostování datového skladu diskový systém RAID 1+0. Obecně byste měli mít v počítači, kde jsou nainstalovány databáze datového skladu, minimálně 8 GB paměti RAM. Pokud máte další zdroje dat datového skladu z nástroje Operations Manager nebo Configuration Manager, měli byste zvýšit množství paměti RAM pro databáze. Zlepšení lze dosáhnout použitím většího množství paměti v počítači se systémem SQL Server, který je hostitelem datového skladu, a to zejména v případě, že jsou databáze DataMart a databáze úložiště na stejném serveru. Pokud však máte ve své topologii nasazení 4 000 počítačů nebo méně, budou 4 GB paměti dostačující. V počítači, ve kterém je nainstalována databáze datového skladu, byste měli mít procesor alespoň s 8 jádry. Ještě větší počet jader přinese zlepšení jak z hlediska výkonu procesů ETL, tak i z hlediska výkonu sestav.

Výkon může negativně ovlivňovat to, že jsou všechny databáze v systému vytvořeny s menší velikostí a jsou nastaveny na automatické zvětšování, zejména po malých přírůstcích. Pokud potřebujete posoudit velikost databáze a vytvořit databázi s velikostí, která bude co nejblíže ke konečné velikosti, doporučujeme vám seznámit se s Service Managerpomocným nástrojem pro změnu velikosti portálu, který je součástí sady dokumentace Pomůcky úloh nástroje Service Manager (SM_job_aids.zip). To vám pomůže zvýšit výkon snížením četnosti případů, kdy se musí databáze automaticky zvětšovat.

Service Manager má integrovanou podporu pro skupiny souborů. Toho můžete využít umístěním skupin souborů na samostatné pevné disky. Další informace o osvědčených postupech pro skupiny souborů naleznete v dokumentaci k systému SQL Server.

Výkon serveru datového skladu portálu Service Manager

Výkon serveru datového skladu je ovlivňován počtem serverů pro správu portálu Service Manager, které jsou zaregistrovány k datovému skladu, rozsahem nasazení a počtem zdrojů dat. Obecně byste měli mít pro server datového skladu minimálně 8 GB paměti RAM. Pokud však bude k dispozici další paměť pro pokročilé scénáře nasazení, kde více než jeden server pro správu portálu Service Manager vkládá data do datového skladu, lze tím dosáhnout zvýšení výkonu. Pokud je nutné z hlediska výkonu dělat kompromisy, vaší nejvyšší prioritou by měla být paměť pro počítač se systémem SQL Server. Aby se zabránilo problémům s výkonem, měl by být k dispozici procesor alespoň s 8 jádry.

Výkon samoobslužného portálu

Samoobslužný portál byl navržen k poskytování snadného přístupu k incidentu a podání žádosti o služby. Není navržen tak, aby mohl současně obsluhovat tisíce uživatelů.

Testování výkonnosti portálu Samoobslužný portál bylo zaměřeno na scénáře obvyklého „pondělního rána“. Konkrétně, aby bylo zajištěno, že v pondělí ráno se v rozmezí 5 až 10 minut budou moci přihlásit stovky uživatelů a otevřít incidenty při zachování přijatelného času odezvy (4 až 5 sekund). Tohoto cíle bylo dosaženo pomocí minimálního hardwaru, který je doporučen v tomto dokumentu.

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

Neexistuje žádný konkrétní počet cílů na úrovni služby, které jsou podporovány v portálu Service Manager. Pokud má například organizace obvykle jen několik incidentů, může podporovat více cílů na úrovni služby, než kolik by mohla v ostatních případech. Větší objem incidentů by však mohl vyžadovat buď méně cílů na úrovni služby, nebo příslušné škálování na další hardware a software. Doporučujeme, abyste pro obvyklou konfiguraci portálu Service Manager pro 50 000 počítačů nevytvářeli více než pět cílů na úrovni služby. Mohli byste případně vytvořit také více cílů na úrovni služby. Jelikož se ale podmínky mezi organizacemi výrazně liší, společnost Microsoft nemůže poskytnout konkrétní doporučení ohledně počtu cílů na úrovní služby, které byste neměli překročit. Pokud konfigurace vašeho nasazení vykazuje nedostatečný výkon v důsledku počtu cílů na úrovni služby, doporučujeme vám horizontální rozšíření na více systémů podle rozsáhlejšího scénáře nasazení, jak je popsáno v části Konfigurace pro scénáře nasazení této příručky.