A felügyeleti csoportok megtervezése

Fontos

Az Operations Manager ezen verziója elérte a támogatás végét. Javasoljuk, hogy frissítsen az Operations Manager 2022-re.

Áttekintés

A felügyeleti csoportokhoz egy operatív adatbázis, egy vagy több felügyeleti kiszolgáló, valamint egy vagy több figyelt ügynök és eszköz tartozik. A felügyeleti csoportok összekapcsolása lehetővé teszi, hogy egyetlen közös konzolról férjen hozzá az összes riasztáshoz és más figyelési adatokhoz. A helyi felügyeleti csoportból kezdeményezheti azt is, hogy a feladatok a csatlakoztatott felügyeleti csoport felügyelt objektumain fussanak.

Az Operations Manager használatának legegyszerűbb módja, ha egyetlen felügyeleti csoportot hoz létre. Minden további csoporthoz dedikált operatív adatbázis és felügyeleti kiszolgáló szükséges. A csoportokhoz ezenfelül saját konfigurációt és felügyeleti csomagokat kell létrehozni, valamint a többi figyelési és ITSM-megoldásba is integrálni kell őket.

Minta mg önálló kiszolgáló ábrája.

Az elosztott felügyeleti csoportos rendszerek képezik az Operations Manager-telepítések 99 százalékának alapját. Ez a megoldás lehetővé teszi a funkciók és szolgáltatások több kiszolgálón való elosztását, így bizonyos jellemzőknél skálázhatóságot és redundanciát is biztosít. Minden Operations Manager-kiszolgálói szerepkört tartalmazhat, és támogatja az eszközök megbízhatósági határokon átnyúló figyelését az átjárókiszolgáló használatával.

Az alábbi ábrán az elosztott felügyeleti csoportos topológia egyik lehetséges változata látható.

Egy példa OM elosztott MG-ra.

Megjegyzés

Nincs közvetlen kommunikáció az operatív konzol és az adatbázisok között. A rendszer a TCP 5724-es porton keresztül egy konkrét felügyeleti kiszolgálóra, majd a TCP 1433-as porton (OLE DB esetében) vagy az SQL-rendszergazda által az SQL Server adatbázismotor-példányának telepítése során beállított felhasználói porton keresztül az adatbázis-kiszolgálókra irányítja az összes kommunikációt. Van azonban közvetlen kommunikáció egy alkalmazásdiagnosztikai konzol (a webkonzollal együtt) és az operatív és adattárház-adatbázisokat üzemeltető SQL Server között.

A környezetében üzembe helyezett felügyeleti csoportok integrálhatók a Microsoft Operations Management Suite (OMS) szolgáltatással, és a Log Analytics használatával tovább korrelálhat, megjeleníthet és reagálhat a teljesítményre, az eseményekre és a riasztásokra. Ez nagyobb láthatóságot biztosít azáltal, hogy egyéni kereséseket hajthat végre a teljes adathalmazon, így korrelálhatja az adatokat a helyszínen vagy a felhőben üzemeltetett rendszerek és alkalmazások között.

Az OM és a Microsoft OMS integrációjának illusztrációja.

Az Operations Managerrel való integráció kiterjed más termékekre, például a BMC Remedyre, az IBM-re, a Netcoolra vagy a szervezet által használt egyéb vállalati felügyeleti megoldásokra. Az ezekkel a megoldásokkal való együttműködés tervezésével kapcsolatban lásd: Integration with other management solutions (Integráció más felügyeleti megoldásokkal).

Felügyeleti csoport összetevői

Felügyeleti kiszolgáló

Az Operations Manager 2007-ben a felügyeleti főkiszolgáló (RMS) a felügyeleti csoport speciális felügyeleti kiszolgálójaként működött. Ez volt az első felügyeleti kiszolgáló, amelyet telepíteni kellett a felügyeleti csoportban. Az RMS volt a felügyeleti csoport konfigurációjának alkalmazásának központi eleme, amely felügyelte az ügynököket és kommunikált velük, valamint fenntartotta a kapcsolatot az operatív adatbázissal és a felügyeleti csoport többi adatbázisával. Az RMS ezenfelül az operatív konzol céljaként, valamint a webkonzolok preferált céljaként is szolgált. A System Center 2012 R2 – Operations Managerben már nem szerepel a felügyeleti főkiszolgáló szerepkör, a felügyeleti kiszolgálók ettől kezdve társviszonyban állnak egymással. Ez a konfiguráció továbbra is létezik a System Center 2016-os és újabb verzióiban – Operations Manager.

A főkiszolgáló már nem az egyetlen hiba-előfordulási pont, mivel így az összes felügyeleti kiszolgáló futtatja a korábban csak az RMS által futtatott szolgáltatásokat. A szerepkörök el vannak osztva az összes felügyeleti kiszolgáló között. Ha egy felügyeleti kiszolgáló elérhetetlenné válik, a kötelezettségei automatikusan szétosztódnak. Az RMS-emulátor szerepkör visszafelé irányuló kompatibilitást biztosít a gyökérkiszolgálóra irányuló felügyeleti csomagoknak. Ha nem rendelkezik olyan felügyeleti csomagokkal, amelyek korábban az RMS-t célozták, nem kell használnia az RMS Emulatort.

A kapacitás kiegészítése és a folyamatos rendelkezésre állás érdekében a felügyeleti csoport több kiszolgálót is tartalmazhat. Ha egy felügyeleti csoporthoz két vagy több felügyeleti kiszolgáló van hozzáadva, akkor azok automatikusan a három alapértelmezett erőforráskészlet részévé válnak, és a munkát a készlet tagjai megosztva végzik. Az egyéni erőforráskészleteknél manuálisan kell hozzáadni a tagokat. Ha az erőforráskészlet egy tagja kiesik, a készlet más tagjai átveszik az érintett tag munkaterhelését. Új felügyeleti kiszolgáló hozzáadásakor az új felügyeleti kiszolgáló automatikusan átveszi a munka egy részét az erőforráskészlet meglévő tagjaitól. Tekintse át az erőforráskészlet tervezési szempontjait , hogy többet tudjon meg a működésükről és a tervezési tervet befolyásoló javaslatokról.

Ha egy felügyeleti kiszolgáló valamilyen okból nem érhető el, alapértelmezés szerint az arra támaszkodó ügynökök automatikusan feladatátvételt fognak végrehajtani egy másik felügyeleti kiszolgálóra. A felügyeleti kiszolgálók számának és elhelyezésének kiválasztásakor figyelembe kell venni ezt a feladatátvételi képességet, ha a magas rendelkezésre állás követelmény.

Az ügynökök a felügyeleti kiszolgálókhoz csatlakozva kommunikálnak az Operations Manager többi összetevőjével. A felügyeleti kiszolgáló feladatai közé tartozik, hogy fogadja az ügynökök által küldött operatív adatokat, és beilleszti őket az operatív és adatraktár-adatbázisba.

Egy átlagos felügyeleti kiszolgáló körülbelül 3000 ügynököt kezel. A kiszolgáló tényleges teljesítményét az összegyűjtött operatív adatok mennyisége határozza meg. Általánosságban azonban elmondható, hogy minden felügyeleti kiszolgáló képes körülbelül 3000 ügynököt kezelni, még akkor is, ha ezek nagy mennyiségű operatív adatot gyűjtenek.

A felügyeleti kiszolgálók felügyeleti csoportonkénti maximális száma nincs korlátozva. Ajánlott azonban a lehető legkevesebb felügyeleti kiszolgálót használni a méretezhetőség, a magas rendelkezésre állás és a vészhelyreállítási korlátozások kezelése után.

Fontos, hogy a felügyeleti kiszolgálók, az Operations Manager-adatbázisok és az adatraktárak között jól működjön a hálózati kapcsolat, mivel a kiszolgálók gyakran küldenek adatokat ezekbe a tárolókba. Ezek az SQL Server-kapcsolatok általában több sávszélességet használnak, és érzékenyebbek a hálózati késésre is. Ezért a felügyeleti kiszolgálókat és az operatív és adattárház-adatbázisokat ugyanazon a helyi hálózaton javasolt elhelyezni, nagykiterjedésű hálózaton pedig semmi körülmények között sem. A felügyeleti kiszolgáló és az Operations Manager-adatbázist üzemeltető SQL Server-példány között legfeljebb 10 ezredmásodperc késés lehet.

Átjárókiszolgáló

Az Operations Manager megköveteli, hogy az ügynökök és a felügyeleti kiszolgálók kölcsönösen hitelesítsék egymást, mielőtt adatcsere kezdődne közöttük. A két fél közötti hitelesítési eljárás biztonsága érdekében a folyamat titkosítva zajlik. Ha az ügynök és a felügyeleti kiszolgáló ugyanabban az Active Directory-tartományban vagy olyan Active Directory-tartományokban található, amelyek megbízhatósági kapcsolatokat hoztak létre, az Active Directory által biztosított Kerberos V5 hitelesítési mechanizmusokat használják. Ha az ügynökök és a felügyeleti kiszolgálók nem ugyanabban a megbízhatósági határon belül találhatók, más mechanizmusokat kell használni a biztonságos kölcsönös hitelesítés követelményének teljesítéséhez.

Átjárókiszolgálók akkor használatosak, ha egy tűzfal választja el az ügynököket a felügyeleti kiszolgálóktól, vagy ha az ügynökök egy külön nem megbízható tartományban vannak. Az átjárókiszolgáló proxyként működik az ügynökök és a felügyeleti kiszolgáló között. Az átjárókiszolgáló nélkül az ügynökök továbbra is végezhetnek tanúsítványhitelesítést egy felügyeleti kiszolgálóval, de minden ügynökre ki kell állítani és telepíteni kell egy X.509-tanúsítványt a MOMCertImport.exe eszközzel, és mindegyikhez hozzá kell férni a felügyeleti kiszolgálóhoz a tűzfalon keresztül. Ha az ügynökök az átjárókiszolgálóval megegyező tartományban vannak, vagy egy megbízható tartományhoz tartoznak, Kerberos-hitelesítést is használhatnak. Ebben az esetben az átjárókiszolgálón és a csatlakoztatott felügyeleti kiszolgálókon van szükség tanúsítványra. Ez magában foglalja a Microsoft Azure szolgáltatott infrastruktúrájában (IaaS) futó virtuális gépek figyelését az Operations Managerrel (azaz a hibrid felhőmonitorozással), amely nem csatlakozik az Operations Manager felügyeleti csoportot támogató szerepkörökhöz, vagy üzembe helyezte az Operations Managert az Azure IaaS-ben (SQL Server üzemelteti az operatív adatbázisokat és egy vagy több, a felügyeleti kiszolgálói szerepkört futtató virtuális gépet), és figyeli a nem megbízható helyszíni számítási feladatokat.

Az alábbi ábrán egy jellemző Operations Manager rendszert láthat, amely Azure szolgáltatott infrastruktúra típusú erőforrásokat figyel.
Az OpsMgr Azure-erőforrások monitorozásának ábrája.

Az alábbi ábrán egy Azure szolgáltatott infrastruktúrában működtetett Operations Manager rendszert láthat.
Az Azure Iaasban üzemeltetett OpsMgr illusztrációja.

Az átjárókiszolgálók általában nem használják a sávszélesség-használat kezelésére, mivel az ügynököktől a felügyeleti kiszolgálóra küldött adatok teljes mennyisége hasonló, függetlenül attól, hogy átjárókiszolgálót használnak-e. Az átjárókiszolgáló célja, hogy csökkentse a nem megbízható tartományokban lévő ügynökök tanúsítványainak kezeléséhez szükséges erőfeszítéseket, és csökkentse a tűzfalakon keresztül engedélyezendő kommunikációs útvonalak számát.

  • Ha átjárókiszolgálónként több mint 2000 ügynök van, az hátrányosan befolyásolhatja a helyreállítás képességét olyan tartós szolgáltatáskimaradás esetén, amely megakadályozza, hogy az átjárókiszolgáló kommunikáljon a felügyeleti kiszolgálóval. Ha több mint 2000 ügynököt használ, javasoljuk, hogy helyezzen üzembe több átjárókiszolgálót. Ha az átjárókiszolgáló helyreállítási ideje aggodalomra ad okot, az a rendszer tesztelése annak biztosítása érdekében, hogy az átjárókiszolgáló gyorsan kiüríthesse az üzenetsort az átjárókiszolgáló és a felügyeleti kiszolgáló közötti tartós kimaradás után. Ha az átjárókiszolgáló bejövő várólistája megtelik, a rendszer prioritási sorrendben eldobja a várólistában lévő adatokat, ami azt jelenti, hogy az átjárókiszolgáló hosszabb leállása adatvesztéssel járhat.
  • Ha nagy számú ügynököt csatlakoztat az átjárókiszolgálón keresztül, javasoljuk, hogy helyezzen üzembe egy dedikált felügyeleti kiszolgálót az átjárókiszolgálók számára. Ha az összes átjárókiszolgáló egyetlen felügyeleti kiszolgálóhoz csatlakozik, és nincs hozzá más ügynök csatlakoztatva, az hosszabb üzemkimaradás esetén felgyorsíthatja a helyreállítási időt. A felügyeleti kiszolgáló tényleges terhelését a közvetlenül vagy átjárókiszolgáló révén alá tartozó ügynökök összesített száma határozza meg.
  • Ha meg szeretné akadályozni, hogy az átjárókiszolgáló kommunikációt kezdeményezjen egy felügyeleti kiszolgálóval, beleértve a magas rendelkezésre állás érdekében több felügyeleti kiszolgáló közötti feladatátvételre való konfigurálást is, az átjáró-jóváhagyási eszköz tartalmazza a /ManagementServerInitiatesConnection parancssori argumentumot. Így az Operations Manager képes megfelelni az ügyfél biztonsági szabályzatának, abban az esetben is, ha a rendszereket DMZ-ben vagy más hálózati környezetben helyezték üzembe, és kommunikációt csak az intranetről szabad kezdeményezni.

Webkonzol-kiszolgáló

A webkonzol egy böngészőből elérhető felhasználói felületet biztosít a felügyeleti csoporthoz. Nem rendelkezik az operatív konzol teljes funkcionalitásával, és csak a Figyelés és a Saját munkaterület nézethez biztosít hozzáférést. A webkonzol hozzáférést nyújt az összes olyan figyelési adathoz és feladathoz, amely az operatív konzolból a felügyelt számítógépeken lefuttatható műveletekhez kapcsolódik. A webkonzolban található adatok elérésére ugyanazok a korlátozások vonatkoznak, mint az operatív konzolban található tartalmakéra.

Jelentéskészítő kiszolgáló

Jelentéskészítés a System Centerhez – Az Operations Manager telepítve van a SQL Server Reporting Services (ezt az Operations Manager ön által használt verziója támogatja), és az Operations Manager jelentéskészítés által támogatott Reporting Services egyetlen érvényes konfigurációja a natív mód.

Megjegyzés

A System Center telepítése – Az Operations Manager Reporting Services integrálja a SQL Reporting Services-példány biztonságát az Operations Manager szerepköralapú biztonságával. Ne telepítsen más Reporting Services-alkalmazásokat a SQL Server ugyanazon példányában.

Az Operations Manager jelentéskészítő kiszolgáló összetevőit telepítheti az SQL Server 2014 vagy 2016 Reporting Servicest futtató számítógépre, vagy egy másik számítógépre is. Az optimális teljesítmény érdekében, különösen olyan vállalati környezetben, ahol a felhasználók nagy mennyiségű, párhuzamos jelentést generálnak, miközben az interaktív vagy ütemezett jelentések egyidejűleg dolgoznak fel, vertikálisan fel kell skáláznia, hogy több egyidejű felhasználót és nagyobb jelentésvégrehajtási terhelést kezeljen. Javasoljuk, hogy az Operations Manager jelentéskészítési szolgáltatás ne ugyanazon a SQL Server tárolja az adattárház-adatbázist, és telepítsen egy dedikált rendszerre.

Operatív adatbázis

Az operatív adatbázis egy SQL Server-adatbázis, amely tárolja az operatív adatokat, a konfigurációs adatokat, valamint a felügyeleti csoport figyelési szabályait. Az Operations Manager a felügyeleti csoport rendszerkritikus meghibásodási pontja, így érdemes lehet a támogatott fürtözési megoldások segítségével magas rendelkezésre állást biztosítani számára.

Az adatbázis méretének szinten tartása érdekében az Operations Manager karcsúsítási beállításai meghatározzák, hogy az adatbázis mennyi ideig őrzi meg az adatokat. Alapértelmezés szerint ez az időtartam hét (7) nap.

A jelentéskészítési célú adattárház adatbázisa

A jelentéskészítési célú adattárház olyan SQL Server-adatbázis, amely a hosszú távú jelentéskészítés céljából gyűjti és tárolja az operatív adatokat. Ezek az adatok a jelentéskészítési célú adatgyűjtési szabályoktól, valamint az operatív adatbázis adatszinkronizálási folyamataitól érkeznek. Az adatraktár karbantartását (összesítését, karcsúsítását és optimalizálását) az Operations Manager automatikusan végzi.

Az alábbi táblázatban azt láthatja, hogy az adatraktár-adatbázis első beállítását követően meddig őrzi meg a rendszer a különféle alapértelmezett adattípusokat.

Adathalmaz Aggregáció típusa Megőrzési időszak (nap)
Riasztás Nyers 400
Ügyfélfigyelési Nyers 30
Ügyfélfigyelési Napi 400
esemény Nyers 100
Teljesítmény Nyers 10
Teljesítmény Óránként 400
Teljesítmény Napi 400
Állapot Nyers 180
Állapot Óránként 400
Állapot Napi 400

Egy adatraktár egyszerre több felügyeleti csoportot is kiszolgálhat. Így a jelentések akár a szervezet összes számítógépéről származó adatokat is egységbe foglalhatják.

Az Operations Manager-adatbázishoz hasonlóan fürtözéssel az adatraktár-adatbázishoz is beállíthat magas rendelkezésre állást. Ha nincs fürtözve, gondosan figyelni kell, hogy a problémák gyorsan orvosolhatók legyenek.

ACS-gyűjtő

Az ACS-gyűjtő fogadja és feldolgozza az ACS-továbbítókról érkező eseményeket, majd ezeket az adatokat az ACS-adatbázisba küldi. Ez a feldolgozás magában foglalja az adatok szétszerelését, hogy az az ACS-adatbázis több táblájára is kiterjedjen, minimalizálja az adatredundanciát és szűrőket alkalmazzon, hogy a szükségtelen események ne legyenek hozzáadva az ACS-adatbázishoz.

ACS-adatbázis

Az ACS-adatbázis az ACS-rendszer tagjain a naplórend alapján keletkező események központi tárolója. Az ACS-adatbázis ugyanazon a gépen is lehet, mint az ACS-gyűjtő, de a lehető legjobb teljesítmény elérése érdekében érdemes mindkét összetevőt dedikált gépre telepíteni. Alapértelmezés szerint a rendszer tizennégy (14) napig őrzi meg az adatokat.

ACS-továbbító

Az ACS-továbbítókon futó szolgáltatás az Operations Manager-ügynök része. Ez a szolgáltatás az Operations Manager-ügynökkel együtt települ, de alapesetben nincs engedélyezve. A szolgáltatást egyszerre több ügynökszámítógéphez is engedélyezheti a Naplózási gyűjtés engedélyezése feladattal vagy a PowerShell segítségével. A szolgáltatás engedélyezése után minden biztonsági esemény – amellett, hogy bekerül a helyi biztonsági naplóba – elküldésre kerül az ACS-gyűjtőnek.

Kialakítási szempontok

Amikor egy vagy több felügyeleti csoport létrehozását tervezi, feltétlenül vegye figyelembe az alábbi szempontokat:

  • Kapacitásnövelés. Az Operations Manager alapértelmezés szerint nem szabja meg, hogy egy felügyeleti csoport hány ügynököt támogathat. Attól függően, hogy milyen hardvert használ, és mekkora terhelés nehezedik a felügyeleti csoportra (ha több felügyeleti csomag működik, nagyobb lesz a figyelési terhelés is), lehetséges, hogy a megfelelő teljesítmény eléréséhez több felügyeleti csoportot is létre kell hoznia.
  • Összevont nézetek. Ha több felügyeleti csoportot használ a környezet figyelésére, meg kell oldania, hogy összevont nézetben tekinthesse meg a felügyeleti csoportokra vonatkozó figyelési és riasztási adatokat. Ehhez hozzon létre egy további felügyeleti csoportot (amelynek lehetnek figyelési feladatai, de ez nem követelmény), amely hozzáfér az összes többi felügyeleti csoport adataihoz. Ezzel összekapcsolja a felügyeleti csoportokat. Az adatok összevont nézetét biztosító felügyeleti csoportot helyi felügyeleti csoportnak, az ennek adatokat átadó csoportokat pedig csatlakoztatott felügyeleti csoportoknak nevezzük.
  • Biztonság és adminisztráció. A felügyeleti csoportok biztonsági és adminisztratív okokból történő particionálása a felügyeleti jogosultságok Active Directory szervezeti egységek vagy tartományok különböző felügyeleti csoportokra való delegálásához hasonló. Sok vállalatnál több informatikai osztály is működik, amelyek egymástól elkülönülő területekért felelnek. Ez a terület lehet egy tényleges földrajzi régió vagy üzleti ágazat, például egy holding társaság egyik leányvállalata. Ha a központi informatikai osztály teljes mértékben átadja a rendszergazdai jogokat az alcsoportoknak, érdemes lehet külön-külön felügyeleticsoport-struktúrát kialakítani az egyes területeken. Ezeket a csoportokat aztán csatlakoztatott felügyeleti csoportokká, a központi informatikai adatközpontot pedig helyi felügyeleti csoporttá lehet alakítani.
  • Telepített nyelvek. Azoknak a kiszolgálóknak, amelyeken Operations Manager kiszolgálói szerepkört telepítenek, ugyanazt a nyelvet kell használniuk. Vagyis nem telepítheti a felügyeleti kiszolgálót az Operations Manager 2012 R2 angol verziójával, majd a japán verzióval telepítheti az operatív konzolt. Ha a figyelés során több nyelv használatára van szükség, külön-külön felügyeleti csoportot kell létrehoznia a különböző nyelvekhez.
  • Éles és üzem előtti funkciók. Az Operations Managerben ajánlott olyan éles implementációt használni, amely az éles alkalmazások figyelésére szolgál, és egy olyan üzem előtti implementációval, amely minimális interakciót biztosít az éles környezettel. Az üzem előtti felügyeleti csoport a felügyeleti csomagok funkcióinak tesztelésére és finomhangolására szolgál, mielőtt az éles környezetbe migrálva lenne. Ezenfelül egyes vállalatok átmeneti környezetet is használnak, ahol kipróbálják az újonnan összeállított kiszolgálókat, mielőtt éles környezetbe helyeznék őket. Az üzem előtti felügyeleti csoport az előkészítési környezet figyelésére használható, hogy biztosítsa a kiszolgálók állapotát az éles üzembe helyezés előtt.
  • Dedikált ACS-funkciók. Ha a követelmények magukban foglalják a Windows auditbiztonsági naplóesemények vagy UNIX/Linux biztonsági események gyűjtésének szükségességét, akkor a naplózási szolgáltatást (ACS) kell implementálnia. Ha a vállalat biztonsági követelményei megszabják, hogy az ACS-funkciót nem vezérelheti és felügyelheti ugyanaz az adminisztrációs csoport, mint az éles környezet többi részét, érdemes lehet dedikált felügyeleti csoportot létrehozni az ACS-funkciókhoz.
  • Vészhelyreállítási funkciók. Az Operations Managerben az Operations Manager-adatbázissal folytatott összes interakciót a rendszer a tranzakciónaplókban rögzíti az adatbázisra való véglegesítése előtt. Ezeket a tranzakciónaplókat elküldheti egy másik, Microsoft SQL Server futtató kiszolgálónak, és véglegesítheti az Ott található Operations Manager-adatbázis másolatát. Ez a lehetőség redundanciát biztosít az Operations Manager operatív adatbázisának, mivel az így a felügyeleti csoport két különböző SQL Server-példányán is megtalálható lesz. Ha szabályozott feladatátvételt kell végrehajtania, a felügyeleti csoporthoz tartozó felügyeleti kiszolgálókon beállításjegyzék-módosítást kell végrehajtani, hogy azok hivatkozzanak a másodlagos SQL Serverre, és kommunikáljanak azzal. A feladatátvételi felügyeleti csoport üzembe helyezhető, amely megfelel az elsődleges felügyeleti csoport (felügyeleti csomagok, felülbírálások, értesítési előfizetések, biztonság stb.) pontos konfigurációjának, és az ügynökök úgy vannak konfigurálva, hogy mindkét felügyeleti csoportnak jelentsenek. Ha az elsődleges felügyeleti csoport teljes egészében bármilyen okból elérhetetlenné válik, a figyelési környezet nem áll le. Így a felügyeleti csoport zavartalanul biztosítja a szolgáltatásokat, és a műveletek figyelése sem szakad meg.

Mielőtt éles környezetben helyezené üzembe a System Center Operations Managert, tervezze meg a felügyeleti csoport kialakítását. A tervezési fázis során megismerheti az informatikai szolgáltatás összetevőit (azaz az infrastruktúrát és az alkalmazásszintet), valamint az őket támogató rendszerek és eszközök számát, az incidens- és problémakezelési folyamatok integrálásának és támogatásának módját, valamint azt, hogy hogyan fogja vizualizálni a különböző incidenseszkalációs támogatási szintek, a mérnöki, a szolgáltatásfelhasználók és a felügyelet adatait.

Csatlakoztatott felügyeleti csoportok

Számos vállalat különböző földrajzi helyeken található kiszolgálókkal rendelkezik, amelyeket egyetlen központi helyen szeretne figyelni. A csatlakoztatott felügyeleti csoportok konfigurációja (amelyet az alábbi ábra illusztrál) olyan munkafolyamati eljárások gyűjteménye, amelyek együttesen hierarchikus felépítésű rendszerfelügyeleti infrastruktúrát hoznak létre.

A Csatlakoztatott felügyeleti csoport példájának ábrája.

Ezzel a konfigurációval központi állapotfigyelést alakíthat ki. Úgy tervezték, hogy támogassa a riasztások és a monitorozási adatok megtekintését, és feladatokat kezdeményez egy csatlakoztatott felügyeleti csoport felügyelt objektumán.

Az Operations Manager felügyeleti csoportjainak összekapcsolásával a központosított figyelési funkciók fenntarthatók, miközben lehetővé teszik a következőket:

  • Több felügyelt objektum figyelését teszi lehetővé, mint egy különálló felügyeleti csoport.
  • Lehetővé teszi a figyelési tevékenységek logikai üzleti egységenként (például „Marketing”) vagy fizikai helyenként (például „Róma”) történő elkülönítését.

Amikor felügyeleti csoportokat csatlakoztat, nem helyez üzembe új kiszolgálókat; Ehelyett engedélyezi a helyi felügyeleti csoport számára, hogy hozzáférjen a csatlakoztatott felügyeleti csoportban található riasztásokhoz és felderítési információkhoz. Így több felügyeleti csoport riasztásait és más figyelési adatait is megtekintheti és használhatja egyetlen operatív konzolon. Továbbá feladatokat is futtathat a csatlakoztatott felügyeleti csoportok figyelt számítógépein. A felügyeleti csoportok összekapcsolásáról bővebb információért lásd: Felügyeleti csoportok összekapcsolása az Operations Manager programban.

Telepített nyelvek

Az Operations Manager felügyeleti csoportjai csak egy telepített nyelvet támogatnak. Ha a figyelni kívánt IT-környezetben több telepített nyelv is van, minden nyelvhez külön felügyeleti csomagra van szükség.