Plánovaní návrhu skupin pro správu

Důležité

Tato verze Operations Manageru dosáhla konce podpory. Doporučujeme upgradovat na Operations Manager 2022.

Přehled

Skupina pro správu je charakterizovaná tak, že obsahuje jednu provozní databázi, nejméně jeden server pro správu a nejméně jednoho monitorovaného agenta a zařízení. Díky propojení skupin pro správu je možné zobrazovat a upravovat výstrahy a jiná data monitorování v jediné konzole. Z místní skupiny pro správu se navíc dají inicializovat úkoly, které pracují se spravovanými objekty připojené skupiny pro správu.

Nejjednodušší implementace Operations Manageru je jedna skupina pro správu. Každá další skupina vyžaduje přinejmenším svoji vlastní provozní databázi a server pro správu. Každá skupina se navíc musí spravovat odděleně se svými vlastními nastaveními konfigurace, sadami Management Pack a integrací s jinými řešeními pro monitorování a ITSM.

Diagram příkladu jednoúčelového serveru MG

Implementace distribuované skupiny pro správu bude základem 99 procent nasazení Operations Manageru. Umožňuje distribuci funkcí a služeb na několik serverů, čímž pro některé z těchto funkcí poskytuje škálovatelnost a redundanci. Může zahrnovat všechny role serveru Operations Manageru a podporuje monitorování zařízení přes hranice důvěryhodnosti pomocí serveru brány.

V níže uvedeném diagramu najdete jednu z možností topologie distribuované skupiny pro správu.

Diagram příkladu distribuovaného mg OM

Poznámka

Mezi konzolou Operations Console a databázemi nedochází k žádné přímé komunikaci. Veškerá komunikace se směruje na konkrétní server pro správu přes port TCP 5724 a až pak na databázové servery prostřednictvím OLE DB na port TCP 1433 nebo uživatelem definovaný port, který zadává správce SQL při instalaci instance databázového stroje SQL Serveru. Mezi konzolou Application Diagnostics (společně s webovou konzolou) a SQL Server hostující provozní databáze a databáze datového skladu však probíhá přímá komunikace.

Skupina pro správu, kterou jste nasadili ve svém prostředí, se může integrovat se sadou Microsoft Operations Management Suite (OMS) a pomocí Log Analytics můžete dále korelovat, vizualizovat výkon, události a výstrahy a reagovat na jejich výkon. Díky tomu můžete provádět vlastní vyhledávání v celé datové sadě, abyste mohli korelovat data mezi systémy a aplikacemi hostovanými místně nebo v cloudu.

Obrázek integrace OM s Microsoft OMS

Integrace s nástrojem Operations Manager se rozšiřuje na další produkty, jako jsou BMC Remedy, IBM, Netcool nebo jiná řešení pro správu podniku používaná vaší organizací. Další informace o plánování spolupráce s těmito řešeními najdete v tématu Integrace s jinými řešeními pro správu.

Součásti skupiny pro správu

Server pro správu

V Operations Manageru 2007 byl specializovaný typ serveru pro správu ve skupině pro správu, tzv. kořenový server pro správu (RMS). Zároveň to byl první server pro správu, který se do skupiny pro správu nainstaloval. Server RMS byl centrálním bodem pro správu konfigurace skupiny pro správu, správu a komunikaci s agenty a komunikaci s provozní databází a dalšími databázemi ve skupině pro správu. Navíc server RMS sloužil jako cíl pro konzolu Operations Console a byl upřednostňovaným cílem webových konzol. Z nástroje System Center 2012 R2 – Operations Manager se odebrala role kořenového serveru pro správu a všechny servery pro správy jsou teď rovnocenné. Tato konfigurace nadále existuje v nástroji System Center 2016 a novějších – Operations Manager.

RMS už není jediným bodem selhání, protože všechny servery pro správu hostují služby, které dříve hostoval jenom server RMS. Role jsou distribuovány na všechny servery pro správu. Pokud se některý server pro správu stane nedostupným, jeho zodpovědnosti budou automaticky distribuovány znovu. Role emulátoru serveru RMS zajišťuje zpětnou kompatibilitu pro sady Management Pack, které jsou určeny pro server RMS. Pokud nemáte žádné sady Management Pack, které dříve cílily na službu RMS, nebudete muset využívat emulátor služby RMS.

Skupina pro správu může obsahovat více serverů pro správu, díky čemuž je možné navýšit kapacitu a zajistit nepřetržitou dostupnost. Když se do skupiny pro správu přidají aspoň dva servery pro správu, automaticky se stanou součástí tří výchozích fondů zdrojů. Práce se pak rozdělí mezi členy fondu. V případě uživatelem definovaných fondů zdrojů se členové přidávají ručně. Dojde-li k selhání člena fondu zdrojů, ostatní členové fondu zdrojů převezmou úlohu tohoto člena. Když přidáte nový server pro správu, nový server pro správu automaticky převezme část práce od stávajících členů ve fondu zdrojů. Další informace o tom, jak tyto fondy fungují, a doporučení, která ovlivňují váš plán návrhu, najdete v tématu Aspekty návrhu fondu zdrojů .

Pokud je server pro správu z nějakého důvodu nedostupný, agenti, kteří na něm spoléhají, automaticky při selhání přejdou na jiný server pro správu. Při výběru počtu a umístění serverů pro správu by se tato možnost převzetí služeb při selhání měla zvážit, pokud je vysoká dostupnost požadavkem.

K serveru pro správu se připojují agenti, aby mohli komunikovat s ostatními komponentami Operations Manageru. Součástí práce, kterou server pro správu vykonává, je proces přebírání operačních dat, která agenti posílají, a jejich vkládání do provozní databáze a datového skladu.

Běžný server pro správu zvládne přibližně 3000 agentů. Skutečný výkon serveru se odvíjí od objemu shromážděných operačních dat. Obvykle ale každý ze serverů pro správu dokáže podporovat 3000 agentů i s relativně velkým objemem operačních dat.

Maximální počet serverů pro správu na skupinu pro správu není nijak omezený. Osvědčeným postupem je ale po vyřešení omezení škálovatelnosti, vysoké dostupnosti a zotavení po havárii používat co nejméně serverů pro správu.

Servery pro správu by měly mít dobré síťové připojení k databázi a datovému skladu Operations Manageru, protože do těchto úložišť často posílají velké objemy dat. Obecně platí, že připojení SQL Serveru využívají více šířky pásma a jsou citlivější na latenci sítě. Proto by všechny servery pro správu měly být ve stejné místní síti jako provozní databáze a databáze datového skladu a nikdy by se neměly nasazovat v síti WAN. Mezi serverem pro správu a instancí SQL Serveru hostující databázi Operations Manageru, by měla být latence kratší než 10 milisekund.

Server brány

Operations Manager vyžaduje, aby se před výměnou informací mezi servery pro správu a agenty provedlo jejich vzájemné ověření. K zabezpečení procesu ověřování mezi těmito prvky se používá šifrování. Pokud se agent a server pro správu nacházejí ve stejné doméně služby Active Directory nebo v doménách služby Active Directory, které mají vytvořené vztahy důvěryhodnosti, využívají ověřovací mechanismy protokolu Kerberos V5 poskytované službou Active Directory. Pokud agenti a servery pro správu nenaléhají ve stejné hranici důvěryhodnosti, je potřeba použít jiné mechanismy, aby se splnil požadavek na zabezpečené vzájemné ověřování.

Servery brány se používají, když brána firewall odděluje agenty od serverů pro správu nebo když jsou agenti v samostatné nedůvěryhodné doméně. Server brány slouží jako proxy mezi agenty a serverem pro správu. Bez serveru brány můžou agenti dál provádět ověřování certifikátů se serverem pro správu, ale certifikát X.509 by bylo potřeba vystavit a nainstalovat na každého agenta pomocí nástroje MOMCertImport.exe a každý z nich by vyžadoval přístup k serveru pro správu přes bránu firewall. Pokud jsou agenti ve stejné doméně jako server brány nebo pokud jsou v důvěryhodné doméně, můžou použít ověřování pomocí protokolu Kerberos. V takovém případě budou certifikát vyžadovat jenom připojené servery pro správu a server brány. To zahrnuje monitorování virtuálních počítačů spuštěných v infrastruktuře Microsoft Azure jako služby (IaaS) pomocí Operations Manageru (to znamená hybridního cloudového monitorování), které nejsou připojené ke stejné důvěryhodné říši jako role podporující skupinu pro správu Operations Manageru, nebo jste nasadili Operations Manager v Azure IaaS (virtuální počítač s SQL Server hostují provozní databáze a jeden nebo více virtuálních počítačů, které hostují roli serveru pro správu) a monitorují nedůvěryhodné místní úlohy.

Následuje ukázka nasazení Operations Manageru, které monitoruje prostředky Azure IaaS.
Obrázek nástroje OpsMgr – Monitorování prostředků Azure

Následující ukázka znázorňuje nasazení Operations Manageru hostované v Azure IaaS.
Obrázek nástroje OpsMgr hostovaného v Azure Iaas

Servery brány se obvykle nepoužívají ke správě využití šířky pásma, protože celkový objem dat odesílaných z agentů na server pro správu je podobný bez ohledu na to, jestli se používá server brány, nebo ne. Zamýšleným účelem serveru brány je snížit úsilí potřebné ke správě certifikátů pro agenty v nedůvěryhodných doménách a snížit počet komunikačních cest, které musí být povoleny prostřednictvím bran firewall.

  • Více než 2 000 agentů na server brány může nepříznivě ovlivnit schopnost obnovení v případě trvalého výpadku, který brání serveru brány v komunikaci se serverem pro správu. Pokud potřebujete více než 2000 agentů, doporučuje se mít více serverů bran. Alternativou, pokud je čas obnovení serveru brány problém, je otestovat systém, aby se zajistilo, že server brány dokáže rychle vyprázdnit frontu po trvalém výpadku mezi serverem brány a serverem pro správu. Když se navíc příchozí fronta serveru brány naplní, data ve frontě se ignorují v závislosti na jejich prioritě. To znamená, že dlouhodobý výpadek serveru brány může v tomto scénáři způsobit ztrátu dat.
  • Když se přes servery bran připojuje velké množství agentů, zvažte možnost použít pro všechny servery bran vyhrazený server pro správu. Když se všechny servery brány připojí k jednomu serveru pro správu, ke kterému nejsou připojeni žádní další agenti, může v případě trvalého výpadku zrychlit dobu obnovení. Skutečné zatížení serveru pro správu je celkový počet agentů, kteří se k němu hlásí přímo nebo prostřednictvím serverů bran.
  • Pokud chcete zabránit tomu, aby server brány zahájil komunikaci se serverem pro správu, včetně konfigurace převzetí služeb při selhání mezi několika servery pro správu kvůli vysoké dostupnosti, obsahuje nástroj pro schvalování brány argument příkazového řádku /ManagementServerInitiatesConnection. Díky tomu Operations Manager může dodržovat zásady zabezpečení zákazníka i v případě, že jsou systémy nasazené v zóně DMZ nebo jiném síťovém prostředí a komunikace se dá zahájit jenom z intranetu.

Server webové konzole

Webová konzola poskytuje rozhraní ke skupině pro správu, ke kterému se přistupuje přes webový prohlížeč. Nemá úplné funkce konzoly Operations Console a poskytuje přístup pouze k zobrazením Monitorování a Pracovní prostor. Webová konzola poskytuje přístup ke všem datům monitorování a úkolům představujícím akce, které se dají spustit pro monitorované počítače z konzoly Operations Console. Pro přístup k datům ve webové konzole platí stejná omezení jako pro přístup k obsahu v konzole Operations Console.

Server pro sestavy

Generování sestav pro System Center – Operations Manager se instaluje na SQL Server Reporting Services (kterou podporuje verze Operations Manageru, kterou používáte) a jedinou platnou konfigurací služby Reporting Services, kterou podporuje generování sestav nástroje Operations Manager, je nativní režim.

Poznámka

Instalace služby System Center – Operations Manager Reporting Services integruje zabezpečení instance SQL Reporting Services se zabezpečením na základě rolí nástroje Operations Manager. Do stejné instance SQL Server neinstalujte žádné jiné aplikace služby Reporting Services.

Komponenty serveru pro sestavy nástroje Operations Manager se dají nainstalovat na stejný server, na kterém běží služba SQL Server 2014 nebo 2016 Reporting Services, nebo na jiný počítač. Pro zajištění optimálního výkonu, zejména v podnikovém prostředí s velkoobjemovým paralelním generováním sestav uživateli při souběžném zpracování interaktivních nebo plánovaných sestav, musíte vertikálně navýšit kapacitu, abyste zvládli více souběžných uživatelů a větší zatížení provádění sestav. Doporučuje se, aby služba generování sestav Operations Manageru nebyla umístěná ve stejném SQL Server, který je hostitelem databáze datového skladu a nainstalovaný ve vyhrazeném systému.

Provozní databáze

Provozní databáze je databáze SQL Serveru, která pro skupinu pro správu udržuje všechna operační data, informace o konfiguraci a pravidla monitorování. Databáze Operations Manageru je jediným zdrojem selhání skupiny pro správu, proto je možné pro ni nastavit vysokou dostupnost pomocí podporovaných konfigurací clusteringu.

Aby tato databáze měla konzistentní velikost, Operations Manager nabízí nastavení výmazu dat, které určuje, jak dlouho se budou v databázi uchovávat data. Standardně je tato doba sedm (7) dní.

Databáze datového skladu služby Reporting

Datový sklad služby Reporting je databáze SQL Serveru, která shromažďuje a uchovává operační data pro dlouhodobé generování sestav. Tato data se zapisují přímo z pravidel, která shromažďují data pro sestavu, a z procesů synchronizace dat v operační databázi. Údržbu datového skladu, včetně agregace, výmazu dat a optimalizace, provádí automaticky Operations Manager.

Následující tabulka popisuje výchozí datové typy a dobu uchovávání po počátečním nastavení databáze datového skladu.

Datová sada Typ agregace Doba uchování (ve dnech)
Výstrahy Žádný 400
Monitorování klientů Žádný 30
Monitorování klientů Každý den 400
Událost Žádný 100
Výkon Žádný 10
Výkon Hodinově 400
Výkon Každý den 400
Stav Žádný 180
Stav Hodinově 400
Stav Každý den 400

Datový sklad může sloužit několika skupinám pro správu. Díky tomu může jedna sestava obsahovat data ze všech počítačů v organizaci.

Podobně jako databáze Operations Manageru se i databáze datového skladu dá clusterovat. Tím se zajistí vysoká dostupnost. Pokud není clusterovaný, měli byste ho pečlivě monitorovat, aby bylo možné všechny problémy rychle vyřešit.

Kolekce služby ACS

Kolekce služby ACS přijímá a zpracovává události od služby předávání ACS a potom tato data odesílá do databáze služby ACS. Toto zpracování zahrnuje demontáž dat tak, aby je bylo možné rozdělit do několika tabulek v rámci databáze služby ACS, minimalizovat redundanci dat a použít filtry, aby se do databáze služby ACS nepřidály nepotřebné události.

Databáze služby ACS

Databáze služby ACS je centrálním úložištěm pro události vygenerované zásadami auditu v rámci nasazení služby ACS. Databáze služby ACS se nachází ve stejném počítači, v němž je kolekce služby ACS. V zájmu dosažení maximálního výkonu však doporučujeme tyto součásti nainstalovat na vyhrazené servery. Data se standardně zachovávají čtrnáct (14) dní.

Služba předávání ACS

Služba, která je spuštěná ve službách předávání ACS, je součástí agenta nástroje Operations Manager. Ve výchozím nastavení je tato služba nainstalována, když je nainstalován agent nástroje Operations Manager, není však povolena. Tuto službu můžete povolit pro více počítačů s agenty najednou pomocí úlohy Povolit službu Audit Collection nebo přes PowerShell. Po povolení této služby budou všechny události zabezpečení odesílány nejen do místního protokolu zabezpečení, ale také do kolekce služby ACS.

Na co dát pozor při navrhování

Když se rozhodujete o implementaci aspoň jedné skupiny pro správu, měli byste zvážit tyto faktory:

  • Zvýšená kapacita. Operations Manager nemá žádná vestavěná omezení počtu agentů, které jedna skupina pro správu může podporovat. V závislosti na použitém hardwaru a zátěži monitorování (více nasazených sad Management Pack znamená větší zátěž monitorování) skupiny pro správu možná budete potřebovat několik skupin, abyste zachovali přijatelný výkon.
  • Souhrnné zobrazení. Když se pro monitorování prostředí použije několik skupin pro správu, musí se použít mechanismus, který bude poskytovat souhrnné zobrazení jejich dat týkajících se monitorování nebo výstrah. To se dá udělat tak, že se nasadí další skupina pro správu (která se může a nemusí podílet na monitorování), která má přístup ke všem datům ve všech ostatních skupinách. Tyto skupiny pro správu se pak označují za připojené. Skupině pro správu, která se používá pro souhrnné zobrazení dat, se říká místní skupina pro správu. Ostatní skupiny, které jí poskytují data, se nazývají připojené skupiny pro správu.
  • Zabezpečení a správa. Dělení skupin pro správu z bezpečnostních a administrativních důvodů se z hlediska zabezpečení a správy podobá delegování oprávnění správce přes organizační jednotky nebo domény služby Active Directory na různé skupiny pro správu. Součástí vaší společnosti může být více IT skupin, z nichž každá má svoji vlastní oblast zodpovědnosti. Takovou oblastí může být konkrétní geografická oblast nebo firemní oddělení. Třeba v případě holdingových společností se může jednat o jednu z dceřiných společností. Tam, kde existuje tento způsob úplného delegování správní autority z centralizované IT skupiny, může být užitečné implementovat strukturu skupin pro správu pro každou z oblastí. Pak se dají konfigurovat jako skupiny pro správu připojené k místní skupině, která je umístěná v centralizovaném datacentru IT.
  • Nainstalované jazyky. Všechny servery s nainstalovanou rolí serveru Operations Manageru se musí nainstalovat v jednom jazyce. To znamená, že nemůžete nainstalovat server pro správu pomocí anglické verze Operations Manageru 2012 R2 a pak nasadit konzolu Operations Console pomocí japonské verze. Pokud monitorování musí probíhat v několika jazycích, bude každý z jazyků operátorů potřebovat další skupinu pro správu.
  • Produkční a předprodukční funkce. V Operations Manageru se doporučuje mít produkční implementaci, která se používá pro monitorování produkčních aplikací, a předprodukční implementaci, která má minimální interakci s produkčním prostředím. Předprodukční skupina pro správu se používá k testování a ladění funkcí sady Management Pack před migrací do produkčního prostředí. Kromě toho některé společnosti používají přípravné prostředí pro servery, do kterého se po dobu zahořování umístí nově sestavené servery. Až pak se převedou do produkce. Předprodukční skupinu pro správu je možné použít k monitorování přípravného prostředí, aby se zajistil stav serverů před uvedením do produkčního prostředí.
  • Vyhrazené funkce ACS. Pokud mezi vaše požadavky patří potřeba shromažďovat události protokolu Zabezpečení auditu systému Windows nebo události zabezpečení systému UNIX/Linux, budete implementovat službu Audit Collection Service (ACS). Pokud požadavky na zabezpečení vaší společnosti stanoví, že se funkce ACS musí řídit a spravovat prostřednictvím jiné skupiny pro správu, než je ta, která spravuje zbytek produkčního prostředí, může být užitečné implementovat skupinu zabezpečení, která podporuje výhradně jenom funkci ACS.
  • Funkce pro zotavení po havárii. V nástroji Operations Manager jsou všechny interakce s databází Operations Manageru zaznamenány v protokolech transakcí před potvrzením do databáze. Tyto transakční protokoly se dají odeslat na jiný server se spuštěnou službou Microsoft SQL Server a potvrdit je do kopie databáze Nástroje Operations Manager. Tato funkce nabízí možnost poskytovat redundanci provozní databáze Operations Manageru mezi dvěma SQL Servery, které jsou součástí jedné skupiny pro správu. Když se musí provést řízené převzetí služeb při selhání, musí se na serverech pro správu ve skupině pro správu upravit registr, aby se vytvořil odkaz a navázala komunikace se sekundárním SQL Serverem. Je možné nasadit skupinu pro správu převzetí služeb při selhání, která přesně odpovídá konfiguraci primární skupiny pro správu (sady Management Pack, přepsání, odběry oznámení, zabezpečení atd.) a agenti jsou nakonfigurovaní tak, aby hlásili oběma skupinám pro správu. Pokud se primární skupina pro správu stane z nějakého důvodu nedostupná, nedochází k výpadkům monitorovacího prostředí. Toto řešení zajišťuje, že se služby skupiny pro správu nepřeruší a že nedojde k žádné ztrátě provozního monitorování.

Před nasazením nástroje System Center Operations Manager v produkčním prostředí naplánujte návrh skupiny pro správu. Během fáze plánování se seznámíte s komponentami it služeb (tj. infrastrukturou a aplikační úrovní) a počtem systémů a zařízení, které je podporují, jak se budou integrovat a podporovat procesy řízení incidentů a problémů a jak budete vizualizovat data pro různé úrovně podpory eskalace incidentů, technické inženýrství, příjemce služeb a správu.

Připojené skupiny pro správu

Mnoho firem, které mají servery na několika geografických umístěních, vyžadují centrální monitorování těchto serverů. Konfigurace připojené skupiny pro správu znázorněná na obrázku níže je sada pracovních procesů navržených tak, aby vytvářely infrastrukturu pro správu s hierarchickými systémy.

Diagram příkladu připojené skupiny pro správu

Tato konfigurace se dá použít k zajištění centralizovaného monitorování. Je navržená tak, aby podporovala zobrazení výstrah a dat monitorování a inicializovala úlohy se spravovaným objektem připojené skupiny pro správu.

Propojením skupin pro správu Operations Manageru je možné spravovat funkce centralizovaného monitorování a zároveň umožnit:

  • Monitorování většího počtu spravovaných objektů, než by bylo možné s jednou skupinou pro správu
  • Izolaci aktivit monitorování podle logických organizačních jednotek (třeba Marketing), nebo fyzických umístění (třeba Řím)

Když připojujete skupiny pro správu, nenasazujete žádné nové servery. Místo toho umožníte místní skupině pro správu přístup k upozorněním a informacím o zjišťování, které jsou v připojené skupině pro správu. Takto lze v jediné konzole Operations Console prohlížet a interagovat s veškerými výstrahami a dalšími daty monitorování z několika skupin pro správu. Kromě toho lze spouštět úlohy v monitorovaných počítačích připojených skupin pro správu. Informace o připojení skupin pro správu najdete v tématu Připojení skupin pro správu v nástroji Operations Manager.

Nainstalované jazyky

Skupiny pro správu Operations Manageru podporují jenom jeden nainstalovaný jazyk. Je-li v celém IT prostředí, které potřebujete monitorovat, více než jeden nainstalovaný jazyk, bude pro jednotlivé jazyky nutné vytvořit samostatnou skupinu pro správu.