Wysoka dostępność i odzyskiwanie po awarii

Program System Center — serwery i funkcje programu Operations Manager mogą potencjalnie zakończyć się niepowodzeniem, wpływając na funkcjonalność programu Operations Manager. Ilość danych i funkcji utraconych podczas awarii różni się w każdym scenariuszu awarii. Zależy to od roli funkcji, która kończy się niepowodzeniem, a czas potrzebny na odzyskanie funkcji zakończonej niepowodzeniem.

Wysoka dostępność

Wymagania dotyczące wysokiej dostępności są rozwiązywane przez utworzenie nadmiarowości w grupie zarządzania dla baz danych operacyjnych i baz danych magazynu danych programu Operations Manager, bramy i serwerów zarządzania oraz określonych obciążeń. Obciążenia te obejmują monitorowanie urządzeń sieciowych, monitorowanie międzyplatformowe i obciążenia specyficzne dla grupy zarządzania, które były wcześniej zarządzane przez główny serwer zarządzania.

Wiele serwerów, konfiguracja pojedynczej grupy zarządzania może korzystać z programu SQL Server Always On w celu zapewnienia wysokiej dostępności i ciągłości usług baz danych programu Operations Manager. Odporność na uszkodzenia serwera zarządzania jest zapewniana przez posiadanie co najmniej dwóch serwerów zarządzania i używanie pul zasobów do monitorowania serwerów z systemem UNIX, serwerów z systemem Linux i urządzeń sieciowych. Serwery z systemem Windows oparte na agencie można skonfigurować przy użyciu podstawowego i pomocniczego serwera zarządzania w celu przekierowania komunikacji agenta, jeśli serwer zarządzania zakończy się niepowodzeniem.

Emulator usługi RMS można również przenieść na inny serwer zarządzania, jeśli serwer zarządzania hostem emulatora usługi RMS stanie się niedostępny.

Połączenia konsoli Operacje można zapewnić wysoką dostępność, konfigurując wysoką dostępność dla Usługi programu Access danych. Można to zrobić, instalując równoważenie obciążenia sieciowego firmy Microsoft lub używając sprzętowego modułu równoważenia obciążenia lub aliasu DNS. Co najmniej jeden serwer zarządzania jest dodawany jako elementy członkowskie puli równoważenia obciążenia sieciowego, a podczas otwierania konsoli należy odwołać się do nazwy wirtualnej zarejestrowanej w systemie DNS serwerów zarządzania ze zrównoważonym obciążeniem.

Uwaga

Moduł równoważenia obciążenia sieciowego nie jest obsługiwany dla serwera konsoli sieci Web programu Operations Manager.

Wiele serwerów bramy można wdrożyć na granicy zaufania, aby zapewnić nadmiarowe ścieżki dla agentów, którzy znajdują się na tej granicy zaufania. Podobnie jak agenci mogą przejść w tryb failover między podstawowym serwerem zarządzania i co najmniej jednym pomocniczym serwerem zarządzania, mogą również przejść w tryb failover między serwerami bramy. Ponadto wiele serwerów bramy może służyć do dystrybucji obciążenia zarządzania komputerami zarządzanymi bez agenta i zarządzanymi urządzeniami sieciowymi.

Oprócz zapewnienia nadmiarowości za pośrednictwem trybu failover bramy agenta serwery bramy można skonfigurować do przełączania w tryb failover między serwerami zarządzania w grupie zarządzania, jeśli dostępnych jest wiele serwerów zarządzania.

Chociaż usługi SQL Server Reporting Services obsługują model wdrażania skalowalny w poziomie, który umożliwia uruchamianie wielu wystąpień serwera raportów, które współużytkuje pojedynczą bazę danych serwera raportów, nie jest obsługiwana w programie Operations Manager. Raportowanie programu Operations Manager instaluje niestandardowe rozszerzenie zabezpieczeń w ramach konfiguracji składników frontonu, których nie można replikować w farmie sieci Web.

Odzyskiwanie po awarii

Odzyskiwanie po awarii odnosi się do środków podjętych w celu zapewnienia, że operacje można wznowić w przypadku katastrofalnej awarii (na przykład utraty całego centrum danych, które hostuje podstawową infrastrukturę). Jest to ważny element, który należy wziąć pod uwagę we wszystkich wdrożeniach, a decyzje podejmowane podczas planowania odzyskiwania po awarii mają wpływ na sposób, w jaki program Operations Manager będzie mógł nadal obsługiwać aktywne monitorowanie i raportowanie wydajności i dostępności krytycznych usług IT. Ta sekcja koncentruje się na zalecanej strategii odzyskiwania po awarii i odporności oraz czynności, które należy podjąć w celu zapewnienia sprawnego odzyskiwania.

Chociaż rozwiązania wysokiej dostępności i odzyskiwania po awarii systemu zapewnią ochronę przed awarią systemu lub utratą systemu, nie powinny one być oparte na ochronie przed przypadkową, niezamierzoną ani złośliwą utratą lub uszkodzeniem danych. W takich przypadkach tworzenie kopii zapasowych kopii z opóźnieniem może być konieczne do użycia na potrzeby operacji przywracania. W wielu przypadkach operacja przywracania jest najbardziej odpowiednią formą odzyskiwania po awarii. Przykładem może być baza danych raportowania o niskim priorytcie lub dane analizy. W wielu przypadkach koszt włączenia odzyskiwania po awarii w wielu lokacjach na poziomie systemu lub aplikacji znacznie przewyższa wartość danych. W przypadkach, w których bliska wartość danych jest niska i potrzeba uzyskania dostępu do danych może być opóźniona bez poważnego wpływu na firmę, jeśli awaria lub nadmierne odzyskiwanie lokacji, rozważ użycie prostych procesów tworzenia kopii zapasowych i przywracania w przypadku odzyskiwania po awarii, jeśli są uzasadnione oszczędności kosztów.

Zrozumienie wpływu i tolerancji przestojów pomoże w podejmowaniu decyzji, które należy zrozumieć, aby prawidłowo zaprojektować architekturę programu Operations Manager oraz poziom złożoności i kosztów wymaganych do obsługi odzyskiwania po awarii. Ponadto należy wziąć pod uwagę zakres monitorowania utraty danych, które organizacja IT może tolerować bez powodowania konsekwencji biznesowych. Jest to najlepiej opisane w dwóch kategoriach: cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO).

Dwie najbardziej typowe konfiguracje projektowania odzyskiwania po awarii dla programu Operations Manager to:

• Utworzenie zduplikowanej grupy zarządzania wdrożonej w pomocniczym centrum danych, które duplikuje się w skali i konfiguracji podstawowej grupy zarządzania.
• Wdrażanie dodatkowych serwerów w pomocniczym centrum danych w celu obsługi operacyjnej bazy danych i bazy danych magazynu danych z serwerami zarządzania wdrożonym w konfiguracji rezerwy w stanie zimnym, które nie uczestniczą w grupie zarządzania do czasu konieczności wykonania akcji odzyskiwania.

Wdrażanie zduplikowanych grup zarządzania jest opcją, gdy nie ma tolerancji na przestój; jednak jest to najbardziej złożona opcja. Konfiguracja między obydwoma elementami musi być spójna, dzięki czemu po przecięciu nie ma różnicy między monitorowanym, alertem lub zgłoszonym, prezentowanym i ostatecznie eskalowanym. Integracja z innymi platformami monitorowania lub platformami ITSM, takimi jak System Center — Service Manager, Remedy lub ServiceNow, również musi istnieć i być może skonfigurowana w stanie aktywnym/pasywnym, aby uniknąć duplikowania zdarzeń, elementów konfiguracji itd. Agenci będą wieloadresowi między obydwoma grupami zarządzania, więc będą duplikować dane.

Na poniższym diagramie przedstawiono przykład tego scenariusza projektowego.

Jeśli natychmiastowe odzyskiwanie nie jest konieczne w przypadku wdrożenia programu Operations Manager i chcesz uniknąć złożoności zduplikowanych grup zarządzania, możesz też wdrożyć dodatkowe składniki grupy zarządzania w pomocniczym centrum danych, aby zachować funkcjonalność grupy zarządzania. Rozważ wdrożenie co najmniej zawsze włączonej grupy dostępności programu SQL Server 2014 lub 2016 w celu zapewnienia odzyskiwania baz danych operacyjnych i baz danych magazynu danych między co najmniej dwoma centrami danych, w których w podstawowym centrum danych wdrożono wystąpienie klastra trybu failover z dwoma węzłami oraz autonomiczny program SQL Server w pomocniczym centrum danych w ramach jednego klastra trybu failover systemu Windows Server (WSFC). Replika pomocnicza dla zawsze włączonej grupy dostępności będzie znajdować się w autonomicznym wystąpieniu spoza klastra trybu failover, jak pokazano na poniższym diagramie.

W tym przykładzie należy wdrożyć co najmniej jeden serwer z systemem Windows z tą samą konfiguracją sprzętu i nazwą komputera, a następnie ponownie zainstalować rolę serwera zarządzania przy użyciu /Recover parametru. Oto przykład:

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

Aby uzyskać więcej informacji, zobacz instalowanie programu Operations Manager w wierszu polecenia.

W tym czasie agenci będą kolejkować zebrane dane (alerty, zdarzenia, wydajność itd.), dopóki nie będą mogli wznowić komunikacji z serwerem zarządzania w grupie zarządzania. Takie podejście pozwala uniknąć instalowania nowych wystąpień programu SQL Server i przywracania baz danych z ostatniej znanej dobrej kopii zapasowej. Jednak w tym scenariuszu odzyskiwania prawdopodobnie będzie dłuższe opóźnienie w powrocie do stanu możliwego do działania, biorąc pod uwagę, że konieczne będzie wdrożenie innych ról niezbędnych do wznowienia minimalnej funkcjonalności monitorowania. Jeśli takie podejście nie jest akceptowalne, możesz wdrożyć serwery zarządzania w pomocniczym centrum danych na potrzeby odzyskiwania w trybie wstrzymania. Usuń je jako elementy członkowskie trzech pul zasobów podstawowych — wszystkie serwery zarządzania Pula zasobów, Powiadomienia i Przypisanie usługi AD. Obejmuje to również dowolną niestandardową pulę zasobów, która może obejmować serwery zarządzania hostowane w podstawowym centrum danych i muszą nadal działać w ramach planu odzyskiwania. Usługi System Center Data Access, System Center Configuration Management i Microsoft Monitoring Agent powinny zostać zatrzymane i ustawione na ręczne lub wyłączone i uruchomione tylko w scenariuszu odzyskiwania po awarii.

Jeśli serwer zarządzania obsługuje integrację (za pośrednictwem łącznika hostowanego bezpośrednio na serwerze zarządzania lub z innego produktu System Center, takiego jak VMM, Orchestrator lub Service Manager), konieczne będzie zaplanowanie wykonania ręcznych lub automatycznych kroków odzyskiwania w zależności od konfiguracji integracji i sekwencji kroków odzyskiwania. Dzięki temu wszelkie inne zależności od serwera zarządzania są przechwytywane i planowane w momencie wdrożenia planu odzyskiwania po awarii.

Jeśli jedna lokacja przejdzie w tryb offline, agent przejdzie w tryb failover na serwer zarządzania w innej lokacji, zakładając, że konfiguracja trybu failover agenta na to zezwala. Skonfiguruj ponownie agentów systemu Windows do buforowania tylko serwerów zarządzania w podstawowym centrum danych, które powinny zarządzać nimi, aby uniemożliwić im próbę przejścia w tryb failover na serwer zarządzania w pomocniczym centrum danych, co spowoduje tylko opóźnienie odzyskiwania i raportowania. Można to zrobić, jeśli ręcznie wdrożysz agenta w zautomatyzowany sposób za pomocą skryptu (na przykład VBScript lub jeszcze lepiej, programu PowerShell), aby wstępnie skonfigurować podczas instalacji, lub po wdrożeniu, jeśli wypchniesz agenta z konsoli, ponownie przy użyciu metody skryptowej zarządzanej przy użyciu rozwiązania do zarządzania konfiguracją przedsiębiorstwa.

Program Operations Manager można wdrożyć na maszynach wirtualnych platformy Azure jako alternatywną opcję odzyskiwania po awarii, aby zachować ciągłość grupy zarządzania. Konieczne będzie również wdrożenie programu SQL Server na maszynie wirtualnej na platformie Azure, a nie w konfiguracji hybrydowej, ponieważ opóźnienie między serwerem zarządzania a programem SQL Server hostem baz danych programu Operations Manager negatywnie wpłynie na wydajność grupy zarządzania.

Rozważ zakres monitorowania, topologię sieci i łączność sieciową z platformą Microsoft Azure (czyli sieć VPN typu lokacja-lokacja lub ExpressRoute), punkty integracji (czyli rozwiązania ITSM, inne produkty Programu System Center, dodatki trzeciej części itd.), dostęp do konsoli, przepisy lub odpowiednie przepisy lub zasady itd., aby prawidłowo zaprojektować ten scenariusz w usłudze Azure IaaS lub innych dostawców chmury publicznej.