Magas rendelkezésre állás és vészhelyreállítás

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.

System Center – Az Operations Manager kiszolgálói és funkciói esetleg meghibásodhatnak, ami hatással van az Operations Manager működésére. Az adott meghibásodás során elveszett adatok mennyisége, illetve meghibásodott funkciók száma az egyes meghibásodási forgatókönyvek szerint eltérő. Ez a sikertelen funkció szerepkörétől és a sikertelen funkció helyreállításához szükséges időtől függ.

Magas rendelkezésre állás

A magas rendelkezésre állás iránti igények az Operations Manager operatív- és adattárház-adatbázisai, az átjáró- és felügyeleti kiszolgálók, valamint a meghatározott tevékenységprofilok felügyeleti csoportjába épített redundanciával szolgálhatók ki. Ilyen számítási feladatok például a hálózati eszközök figyelése, a platformfüggetlen figyelés és a felügyeleti csoportspecifikus számítási feladatok, amelyeket korábban a gyökérszintű felügyeleti kiszolgáló kezelt.

A több kiszolgáló, egyetlen felügyeleti csoport konfigurációja SQL Server Always On-t használhatja az Operations Manager-adatbázisok magas rendelkezésre állásának és szolgáltatásfolytonosságának biztosításához. A felügyeleti kiszolgáló hibatűrését legalább két felügyeleti kiszolgáló biztosítja, valamint a UNIX-kiszolgálók, Linux-kiszolgálók és hálózati eszközök figyelésére szolgáló erőforráskészletek használatával. Az ügynökalapú Windows-kiszolgálók konfigurálhatók elsődleges és másodlagos felügyeleti kiszolgálóval az ügynökkommunikáció átirányítására, ha egy felügyeleti kiszolgáló meghibásodik.

Az RMS-emulátor is áthelyezhető másik felügyeleti kiszolgálóra, ha az RMS-emulátort futtató felügyeleti kiszolgáló elérhetetlenné válna.

Az operatív konzol kapcsolatai magas rendelkezésre állásúvá tehetők az adatelérési szolgáltatások magas rendelkezésre állásának konfigurálásával. Ez a Microsoft Hálózati terheléselosztás (NLB) telepítésével vagy hardveralapú terheléselosztók vagy DNS-alias használatával végezhető el. A rendszer egy vagy több felügyeleti kiszolgálót ad hozzá az NLB-készlet tagjaként, és a konzol megnyitásakor a terheléselosztásos felügyeleti kiszolgálók DNS-ben regisztrált virtuális nevére kell hivatkozni.

Megjegyzés

Az Operations Manager webkonzol-kiszolgálója nem támogatja a hálózati Load Balancer.

Több átjárókiszolgáló is telepíthető a bizalmi kapcsolatok határán túl annak érdekében, hogy a bizalmi kapcsolat határán túl telepített ügynökök számára redundáns átjárót biztosítsanak. Akárcsak egy elsődleges és egy vagy több másodlagos felügyeleti kiszolgáló esetén, az ügynökök az átjárókiszolgálók között is képesek a feladatátvételre. Továbbá több átjárókiszolgáló is használható az ügynök nélkül felügyelt számítógépek és felügyelt hálózati eszközök által okozott terhelés elosztásához.

Az ügynök–átjáró feladatátvételen felül az átjárókiszolgálók úgy is beállíthatók, hogy feladatuk átvétele a felügyeleti kiszolgálók között történjen a felügyeleti csoportban (amennyiben több felügyeleti kiszolgáló is elérhető).

Bár SQL Server Reporting Services támogatja a kibővített üzemi modellt, amely lehetővé teszi több jelentéskészítő kiszolgálópéldány futtatását, amelyek egyetlen jelentéskészítő kiszolgáló adatbázisával osztoznak, az Operations Manager nem támogatja. Az Operations Manager Reporting egyéni biztonsági bővítményt telepít az előtér-összetevők beállításának részeként, amely nem replikálható a webfarmban.

Vészhelyreállítás

A vészhelyreállítás olyan intézkedésekhez kapcsolódik, amelyek biztosítják, hogy a műveletek folytathatók legyenek katasztrofális meghibásodás esetén (például az elsődleges infrastruktúrát üzemeltető teljes adatközpont elvesztése). Ez egy fontos elem, amelyet figyelembe kell venni minden üzemelő példányban, és a vészhelyreállítás tervezése során hozott döntések hatással vannak arra, hogy az Operations Manager hogyan tudja továbbra is támogatni a kritikus informatikai szolgáltatások teljesítményének és rendelkezésre állásának proaktív monitorozását és jelentéskészítését. Ez a témakör a vészhelyreállítás és a rugalmasság érdekében követendő javasolt stratégiával és a zökkenőmentes helyreállítás biztosítása érdekében elvégzendő lépésekkel foglalkozik.

Bár a magas rendelkezésreállási és vészhelyreállítási megoldások védelmet nyújtanak a rendszerhibák és a rendszervesztés ellen, nem szabad a véletlen, nem szándékos vagy rosszindulatú adatvesztés vagy -sérülés elleni védelemre támaszkodniuk. Ezekben az esetekben előfordulhat, hogy biztonsági másolatot kell készíteni a másolt vagy a nem használt replikációs másolatról a visszaállítási műveletekhez. Sok esetben egy visszaállítási művelet a vészhelyreállítás legmegfelelőbb módja, például alacsony prioritású jelentési adatbázis vagy elemzési adatok esetén. A többhelyes vészhelyreállítás rendszer- vagy alkalmazásszintű megvalósításának költsége sok esetben messze meghaladja az adatok értékét. Olyan esetekben, amikor az adatok rövid távú értéke alacsony, és az adatokhoz való hozzáférés szükségessége súlyos üzleti hatás nélkül késleltethető, ha egy hiba vagy a hely vészhelyreállítása túlzott, fontolja meg egyszerű biztonsági mentési és visszaállítási folyamatok használatát a vészhelyreállításhoz, ha a költségmegtakarítás ezt indokolja.

Az üzemen kívüli idő tűréshatárának és következményeinek ismerete segít meghozni azokat a döntéseket, amelyek alapján megfelelően megtervezhető az Operations Manager architektúrája, valamint indokolható a vészhelyreállítás támogatásának bonyolultsága és költsége. Emellett vegye figyelembe, hogy az informatikai szervezet milyen mértékben képes az adatvesztés monitorozására anélkül, hogy üzleti következményekkel jár. Ezt leginkább két fogalom írja le, a szolgáltatások helyreállítási időkorlátja (RTO) és az adatok helyreállítási időkorlátja (RPO).

Az Operations Manager két leggyakrabban alkalmazott vészhelyreállításiterv-konfigurációja a következő:

• A másodlagos adatközpontban üzembe helyezett duplikált felügyeleti csoport létrehozása, amely az elsődleges felügyeleti csoport méretezése és konfigurálása során ismétlődik.
• További kiszolgálók üzembe helyezése egy másodlagos adatközpontban az operatív és az adattárház-adatbázis támogatására, hidegtartalék konfigurációban telepített felügyeleti kiszolgálókkal, amelyek csak akkor lesznek a felügyeleti csoport aktív tagjai, ha szükségessé válik a helyreállítási műveletek végrehajtása.

Ismétlődő felügyeleti csoport üzembe helyezése akkor lehetséges, ha nincs tűréshatár az állásidőre; ez azonban a legösszetettebb lehetőség. A kettő közötti konfigurációnak konzisztensnek kell lennie, hogy ha megszakítja a elemet, ne legyen különbség a figyelt, a riasztásban vagy a jelentésben szereplő, a megjelenített és végül az eszkalált elemek között. Az integrációnak más monitorozási platformokkal vagy ITSM-platformokkal, például a System Center - Service Manager, Remedy vagy ServiceNow platformokkal is léteznie kell, és valószínűleg aktív/passzív állapotban kell konfigurálnia az incidensek, konfigurációelemek stb. duplikálásának elkerülése érdekében. Az ügynökök mindkét felügyeleti csoportban futnak, ezért adatduplikációra kerül sor.

A következő diagram erre a forgatókönyvre mutat be egy példát.

Ha nincs szükség azonnali helyreállításra az Operations Manager üzemelő példányához, és el szeretné kerülni a duplikált felügyeleti csoport összetettségét, másik lehetőségként további felügyeleticsoport-összetevőket is üzembe helyezhet a másodlagos adatközpontban a felügyeleti csoport működésének megőrzése érdekében. Minimális megoldásként megfontolandó egy, az operatív és adattárház-adatbázisok helyreállítását kettő vagy több adatközpont között biztosító SQL Server 2014 vagy SQL Server 2016 Always On rendelkezésre állási csoport kialakítása, amelyben egy kétcsomópontos feladatátvevő fürtpéldány (FCI) van telepítve az elsődleges adatközponthoz, és egy önálló SQL Server a másodlagos adatközponthoz egyetlen Windows Server feladatátvevő fürt (WSFC) részeként. Az Always On rendelkezésre állási csoport másodlagos replikája a nem fürtözött, önálló példányra kerül, ahogyan a következő ábra szemlélteti.

Ebben a példában egy vagy több windowsos kiszolgálót kell üzembe helyeznie ugyanazzal a hardverkonfigurációval és számítógépnévvel, majd újra kell telepítenie a felügyeleti kiszolgálói szerepkört a /Recover paraméterrel. Íme egy példa:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

További információ: Az Operations Manager telepítése a parancssorból.

Ez idő alatt az ügynökök várólistára küldik az összegyűjtött adatokat (riasztásokat, eseményeket, teljesítményt stb.), amíg folytatni nem tudják a kommunikációt egy felügyeleti kiszolgálóval a felügyeleti csoportban. Ezzel a módszerrel elkerülhető az SQL Server újabb példányainak telepítése, és az adatbázisoknak a legutóbbi ismert helyes biztonsági másolatból történő visszaállítása. Ebben a helyreállítási forgatókönyvben azonban valószínűleg hosszabb késéssel tér vissza egy működőképes állapotba, mivel a minimális monitorozási funkció folytatásához szükséges többi szerepkört is üzembe kell helyeznie. Ha ez a módszer nem elfogadható, akkor a másodlagos adatközpontban üzembe helyezhet felügyeleti kiszolgálókat a készenléti helyreállításhoz. Távolítsa el őket a három elsődleges erőforráskészlet tagjaként – minden felügyeleti kiszolgáló erőforráskészlete, értesítései és AD-hozzárendelése. Ez magában foglal minden egyéni erőforráskészletet is, amely magában foglalhatja az elsődleges adatközpontban üzemeltetett felügyeleti kiszolgálókat, és a helyreállítási terv részeként továbbra is működnie kell. A System Center Adatelérési szolgáltatást, a System Center konfigurációkezelő szolgáltatást és a Microsoft-figyelőügynök szolgáltatást le kell állítani, az indítás típusát Kézi vagy Letiltva értékre állítva, és csak vészhelyreállítás esetén kell elindítani.

Ha egy felügyeleti kiszolgáló támogatja az integrációt (közvetlenül a felügyeleti kiszolgálón üzemeltetett összekötőn vagy egy másik System Center-termékből, például a VMM-ből, az Orchestratorból vagy Service Manager), ezt manuális vagy automatikus helyreállítási lépésekkel kell megtervezni az integráció konfigurációjától és a helyreállítási lépések sorozatától függően. Ez biztosítja, hogy a felügyeleti kiszolgáló minden más függősége rögzítve legyen és megtervezve legyen a vészhelyreállítási terv implementálásakor.

Amikor egy hely elérhetetlenné válik, akkor az ügynök átadja a feladatokat egy másik hely felügyeleti kiszolgálójának, feltéve hogy az ügynök feladatátvételi konfigurációja ezt megengedi. Konfigurálja újra a Windows-ügynököket úgy, hogy csak az elsődleges adatközpontban lévő felügyeleti kiszolgálókat gyorsítótárazsák, amelyeket kezelniük kell, hogy megakadályozzák, hogy feladatátvételt kíséreljenek meg a másodlagos adatközpontban lévő felügyeleti kiszolgálóra, ami csak késlelteti a helyreállítást és a jelentéskészítést. Ez akkor érhető el, ha az ügynököt manuálisan, automatikusan üzembe helyezi egy szkripttel (például VBScript vagy még jobb, PowerShell), hogy előre konfigurálja a telepítés során, vagy az üzembe helyezés után, ha leküldi az ügynököt a konzolról, ismét egy, a vállalati konfigurációkezelési megoldással felügyelt szkriptelt módszerrel.

Az Operations Manager Azure virtuális gépekre telepítve alternatív vészhelyreállítási megoldásként segíthet a felügyeleti csoport folyamatos működésének fenntartásában. A SQL Server azure-beli virtuális gépen is üzembe kell helyezni, nem hibrid konfigurációban, mivel a felügyeleti kiszolgáló és az Operations Manager-adatbázisokat üzemeltető SQL Server közötti késés negatívan befolyásolja a felügyeleti csoport teljesítményét.

Vegye figyelembe a Microsoft Azure monitorozási hatókörét, hálózati topológiáját és hálózati kapcsolatát (azaz helyek közötti VPN vagy ExpressRoute), az integrációs pontokat (azaz ITSM-megoldásokat, más System Center-termékeket, harmadik részből származó bővítményeket stb.), a konzolhozzáférést, a szabályozási vagy vonatkozó jogszabályokat vagy szabályzatokat, és így tovább, hogy megfelelően megtervezhesse ezt a forgatókönyvet az Azure IaaS-en vagy más nyilvános felhőszolgáltatókon belül.