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

System Center – Az Operations Manager kiszolgálói és funkciói esetleg meghiúsulhatnak, ami hatással van az Operations Manager funkcióira. A hibák során elveszett adatok és funkciók mennyisége minden hibaforgatókönyvben eltérő. Ez a sikertelen funkció szerepkörétől és a sikertelen funkció helyreállításához szükséges időtartamtól függ.

Magas rendelkezésre állás

A magas rendelkezésre állási igények kielégítéséhez redundanciát kell építeni az Operations Manager üzemeltetési és adattárház-adatbázisainak, az átjáró- és felügyeleti kiszolgálóknak, valamint adott számítási feladatoknak a felügyeleti csoportjába. Ezek a számítási feladatok közé tartoznak a hálózati eszközök monitorozása, a platformfüggetlen monitorozás és a felügyeleti csoportspecifikus számítási feladatok, amelyeket korábban a gyökérkezelési kiszolgáló kezelt.

A több kiszolgálóból álló egyetlen felügyeleti csoport konfigurációja az SQL Server Always On használatával biztosítja az Operations Manager-adatbázisok magas rendelkezésre állását és szolgáltatásfolytonosságát. 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 egy elsődleges és másodlagos felügyeleti kiszolgálóval konfigurálhatók az ügynökkommunikáció átirányítására, ha egy felügyeleti kiszolgáló meghibásodik.

Az RMS Emulator áthelyezhető egy másik felügyeleti kiszolgálóra is, ha az RMS Emulatort futtató felügyeleti kiszolgáló elérhetetlenné válik.

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észlethez, és a konzol megnyitásakor a terheléselosztásos felügyeleti kiszolgálók DNS-ben regisztrált virtuális nevére kell hivatkozni.

Több átjárókiszolgáló is üzembe helyezhető egy megbízhatósági határon, hogy redundáns útvonalakat biztosítson a megbízhatósági határt átlépő ügynökök számára. Ahogyan az ügynökök feladatátvételt végezhetnek egy elsődleges felügyeleti kiszolgáló és egy vagy több másodlagos felügyeleti kiszolgáló között, az átjárókiszolgálók között is feladatátvételt végezhetnek. Emellett több átjárókiszolgáló is használható az ügynök nélküli számítógépek és a felügyelt hálózati eszközök kezelésének számítási feladatainak elosztásához.

Az ügynökátjáró feladatátvételén keresztüli redundancia biztosítása mellett az átjárókiszolgálók úgy is konfigurálhatók, hogy feladatátvételt végezzenek a felügyeleti csoport felügyeleti kiszolgálói között, ha több felügyeleti kiszolgáló is elérhető.

Bár az 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 egyéni biztonsági bővítményt telepít az előtérbeli összetevők beállításának részeként, amely nem replikálható a webfarmon.

Katasztrófaelhárí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 minden üzembe helyezés során figyelembe kell venni, é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ését. Ez a szakasz a vészhelyreállítás és a rugalmasság ajánlott stratégiájára, valamint a zökkenőmentes helyreállítás biztosításához szükséges lépésekre összpontosít.

Bár a HA és a DR megoldások védelmet nyújtanak a rendszerhibák és a rendszervesztés ellen, nem szabad a véletlen, a nem szándékos vagy a 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 a helyreállítási művelet a katasztrófa utáni helyreállítás (DR) legmegfelelőbb formája. Ilyen lehet például egy alacsony prioritású jelentéskészítési adatbázis vagy elemzési adat. A többhelyes vészhelyreállítás rendszer- vagy alkalmazásszinten való engedélyezésének költsége sok esetben jóval meghaladja az adatok értékét. Azokban az 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 az egyszerű biztonsági mentési és visszaállítási folyamatokat a DR-hez, ha a költségmegtakarítás ezt indokolja.

Az állásidő hatásának és tűrésének megértése segít a szükséges döntések meghozatalában az Operations Manager architektúrájának megfelelő kialakítása, valamint a vészhelyreállítás támogatásához szükséges összetettség és költségszint megfelelő kialakítása érdekében. Emellett vegye figyelembe, hogy az informatikai szervezet milyen mértékű adatvesztést tud monitorozni anélkül, hogy az üzleti következményeket okozna. Ez a legjobban két kifejezésben írható le: a helyreállítási idő célkitűzése (RTO) és a helyreállítási pont célkitűzése (RPO).

Az Operations Manager két leggyakoribb vészhelyreállítási tervezési konfigurációja a következő:

• A másodlagos adatközpontban üzembe helyezett ismétlődő felügyeleti csoport létrehozása, amely méretezi és konfigurálja az elsődleges felügyeleti csoportot.
• További kiszolgálók üzembe helyezése egy másodlagos adatközpontban az operatív és adattárház-adatbázis támogatásához, hideg készenléti konfigurációban üzembe helyezett felügyeleti kiszolgálókkal, és nem vesznek részt a felügyeleti csoportban, amíg helyreállítási műveleteket nem kell végrehajtani.

Ismétlődő felügyeleti csoport üzembe helyezése akkor lehetséges, ha nincs tűréshatár az állásidőre vonatkozóan; azonban ez a legösszetettebb lehetőség. A konfigurációknak mindkét fél között konzisztensnek kell lenniük, hogy amikor átállás történik, ne legyen különbség a figyelt, riasztott, jelentett, megjelenített és végül eszkalált elemek között. Más monitorozási platformokkal vagy ITSM-platformokkal( például System Center – Service Manager, Remedy vagy ServiceNow) való integrációnak is léteznie kell, és valószínűleg aktív/passzív állapotban kell konfigurálnia az incidensek, konfigurációelemek stb. duplikációjának elkerülése érdekében. Az ügynökök több helyhez kötötté válnak mindkét felügyeleti csoport között, így az adatok duplikációja is létrejön.

Az alábbi diagram egy példa erre a tervezési forgatókönyvre.

Ha nincs szükség azonnali helyreállításra az Operations Manager üzembe helyezéséhez, és el szeretné kerülni egy ismétlődő felügyeleti csoport összetettségét, a felügyeleti csoport funkcióinak megőrzése érdekében másik lehetőségként további felügyeleticsoport-összetevőket is üzembe helyezhet a másodlagos adatközpontban. Legalább érdemes implementálni egy SQL Server 2014-es vagy 2016-os Always On rendelkezésre állási csoportot az operatív és adattárház-adatbázisok helyreállításához két vagy több adatközpont között, ahol egy kétcsomópontos feladatátvevő fürtpéldány (FCI) van üzembe helyezve az elsődleges adatközpontban, és egy különálló SQL Server a másodlagos adatközpontban egyetlen Windows Server feladatátvevő fürt (WSFC) részeként. Az Always On elérhetőségi csoport másodlagos replikája a nem FCI önálló példányon található, amint az alábbi ábra mutatja.

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

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 sorba rendezik az összegyűjtött adatokat (riasztások, események, teljesítmény stb.), amíg a felügyeleti csoport egy felügyeleti kiszolgálójával folytatják a kommunikációt. Ez a megközelítés elkerüli az SQL Server új példányainak telepítését és az adatbázisok visszaállítását a legutóbbi ismert jó biztonsági mentésből. 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 megközelítés nem elfogadható, felügyeleti kiszolgálókat helyezhet üzembe a másodlagos adatközpontban a készenléti helyreállításhoz. Távolítsa el őket a három elsődleges erőforráskészletből: Minden Felügyeleti Kiszolgáló Erőforráskészlet, Értesítési Erőforráskészlet és AD-hozzárendelési Erőforráskészlet. 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 is, és a helyreállítási terv részeként továbbra is működnie kell. A System Center Data Access, a System Center Configuration Management és a Microsoft Monitoring Agent szolgáltatást le kell állítani, manuálisan vagy letiltva kell beállítani, és csak vészhelyreállítási forgatókönyvben 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éken, például a VMM-en, az Orchestratoron vagy a Service Manageren keresztül), 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 sorrendjétől függően. Ez biztosítja, hogy a felügyeleti kiszolgáló egyéb függőségeinek rögzítése és megtervezése a vészhelyreállítási terv implementálásához szükséges.

Ha egy webhely offline állapotba kerül, az ügynök feladatátvételt fog végrehajtani egy másik helyen lévő felügyeleti kiszolgálóra, feltéve, hogy az ügynök feladatátvételi konfigurációja ezt lehetővé teszi. 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árazza, hogy elkerüljék az átváltást egy másodlagos adatközpontban lévő felügyeleti kiszolgálóra, ami csak késleltetné a helyreállítást és a jelentéskészítést. Ez akkor valósítható meg, ha az ügynököt manuálisan, automatizált módon helyezi üzembe egy szkripttel (például VBScript vagy még jobb, PowerShell) a telepítés során történő előre konfiguráláshoz, 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 az Azure-beli virtuális gépeken is üzembe helyezhető alternatív vészhelyreállítási lehetőségként a felügyeleti csoport folytonosságának fenntartása érdekében. Az SQL Servert egy 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 kapcsolatait (azaz helyek közötti VPN- vagy ExpressRoute-), integrációs pontokat (azaz ITSM-megoldásokat, más System Center-termékeket, külső bővítményeket stb.), konzolhozzáférést, szabályozási vagy vonatkozó jogszabályokat vagy szabályzatokat stb., hogy megfelelően megtervezze ezt a forgatókönyvet az Azure IaaS-en vagy más nyilvános felhőszolgáltatókon belül.