Wysoka dostępność i odzyskiwanie po awarii

Ważne

Ta wersja programu Operations Manager osiągnęła koniec wsparcia technicznego. Zalecamy uaktualnienie do programu Operations Manager 2022.

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 zakres funkcjonalności utraconych z powodu awarii różnią się w zależności od scenariusza awarii. Zależy to od roli funkcji kończącej się niepowodzeniem i czasu potrzebnych do odzyskania funkcji kończącej się niepowodzeniem.

Wysoka dostępność

Potrzeby związane z wysoką dostępnością są rozwiązywane przez tworzenie nadmiarowości w grupie zarządzania dla operacyjnych baz danych i baz danych magazynu danych programu Operations Manager, serwerów bram i serwerów zarządzania oraz konkretnych 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 SQL Server Zawsze włączone 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 przekierowywania komunikacji agenta, jeśli serwer zarządzania ulegnie awarii.

Emulator RMS również można przenieść na inny serwer zarządzania na wypadek sytuacji, w której serwer zarządzania hostujący emulator RMS będzie niedostępny.

Połączenia konsoli Operacje mogą być wysoce dostępne, konfigurując wysoką dostępność dla usług Data Access Services. Można to zrobić, instalując równoważenie obciążenia sieciowego (NLB) 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

Load Balancer sieci nie jest obsługiwana dla serwera konsoli sieci Web programu Operations Manager.

Można wdrożyć wiele serwerów bramy na granicy zaufania, aby zapewnić nadmiarowe ścieżki działania dla agentów, którzy znajdują się poza tą granicą zaufania. Agenci mogą przechodzić do trybu failover między podstawowym serwerem zarządzania a jednym lub wieloma pomocniczymi serwerami zarządzania i w taki sam sposób mogą również przechodzić w tryb failover między serwerami bramy. Ponadto wiele serwerów bramy umożliwia rozproszenie obciążenia zarządzania dla komputerów zarządzanych bez agentów i zarządzanych urządzeń sieciowych.

Oprócz zapewniania nadmiarowości dzięki trybowi failover między agentem a bramą, serwery bramy można również skonfigurować do przechodzenia w tryb failover między serwerami zarządzania w grupie zarządzania, jeśli dostępnych jest wiele serwerów zarządzania.

Chociaż SQL Server Reporting Services obsługuje model wdrażania skalowalny w poziomie, który umożliwia uruchamianie wielu wystąpień serwera raportów współużytkujących 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 awarii katastrofalnej (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ę w każdym wdrożeniu, a decyzje podejmowane podczas planowania odzyskiwania po awarii wpływają na to, jak program Operations Manager będzie mógł kontynuować aktywne monitorowanie i raportowanie wydajności i dostępności krytycznych usług IT. Ta sekcja koncentruje się na zalecanej strategii dotyczącej odzyskiwania po awarii i odporności, a także krokach, które należy podjąć, aby zapewnić sprawne odzyskiwanie po awarii.

Rozwiązania wysokiej dostępności i odzyskiwania po awarii systemu zapewniają ochronę przed awarią systemu lub utratą systemu, ale nie należy ich polegać na ochronie przed przypadkową, niezamierzoną lub złośliwą utratą lub uszkodzeniem danych. W takich przypadkach tworzenie kopii zapasowych kopii skopiowanych lub opóźnionej replikacji może być konieczne w przypadku operacji przywracania. W wielu przypadkach operacja przywracania jest najbardziej odpowiednią formą odzyskiwania po awarii. Przykładem takiej sytuacji może być baza danych raportów o niskim priorytecie 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 krótkoterminowa wartość danych jest niska i konieczność uzyskania dostępu do danych może być opóźniona bez poważnego wpływu na firmę, jeśli awaria lub odzyskiwanie po awarii lokacji nadmierne, rozważ użycie prostych procesów tworzenia kopii zapasowych i przywracania na potrzeby odzyskiwania po awarii, jeśli oszczędności są uzasadnione.

Zrozumienie wpływu i tolerancji przestojów może pomóc w podjęciu decyzji, które są wymaganym elementem prawidłowego projektowania architektury dla programu Operations Manager oraz poziomu złożoności, a także kosztów związanych z obsługą odzyskiwania po awarii. Ponadto należy wziąć pod uwagę zakres monitorowania utraty danych, które organizacja IT może tolerować bez powodowania konsekwencji biznesowych. Najlepiej opisać to przy użyciu dwóch pojęć: celu czasu odzyskiwania (RTO, Recovery Time Objective) oraz celu punktu odzyskiwania (RPO, Recovery Point Objective).

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

• Utworzenie zduplikowanej grupy zarządzania wdrożonej w pomocniczym centrum danych, która duplikuje skalę i konfigurację podstawowej grupy zarządzania.
• Wdrożenie dodatkowych serwerów w pomocniczym centrum danych do obsługi operacyjnej bazy danych oraz bazy danych magazynu danych, z serwerami zarządzania wdrożonymi w konfiguracji rezerwy w stanie zimnym, które nie biorą udziału w grupie zarządzania, dopóki nie trzeba wykonać akcji odzyskiwania.

Wdrożenie zduplikowanych grup zarządzania jest opcją, gdy nie ma tolerancji na przestój; jest to jednak 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, zgłoszonym lub zgłoszonym, a na koniec eskalacją. 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ą agentami wieloadresowymi między obiema grupami zarządzania, więc wystąpi duplikacja danych.

Poniższy diagram jest przykładem takiego 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. Jako minimum rozważ wdrożenie grupy dostępności programu SQL Server 2014 lub 2016 Always On, aby zapewnić odzyskiwanie operacyjnej bazy danych i bazy danych magazynu danych między co najmniej dwoma centrami danych, gdzie wystąpienie klastra trybu failover (FCI, Failover Cluster Instance) o dwóch węzłach jest wdrożone w podstawowym centrum danych, a autonomiczne wystąpienie programu SQL Server w pomocniczym centrum danych jako część jednego klastra trybu failover systemu Windows Server (WSFC, Windows Server Failover Cluster). Replika pomocnicza dla grupy dostępności Always On powinna znajdować się w wystąpieniu autonomicznym innym niż FCI, 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. W tym podejściu unika się 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 ta metoda nie jest dopuszczalna, możesz wdrożyć serwery zarządzania w pomocniczym centrum danych, aby zapewnić odzyskiwanie w stanie 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 oraz Microsoft Monitoring Agent powinny zostać zatrzymane i ustawione na tryb ręczny lub wyłączone i uruchamiane wyłącznie w przypadku scenariusza 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), należy zaplanować wykonanie czynności ręcznego lub automatycznego 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 do wdrożenia planu odzyskiwania po awarii.

Jeśli jedna lokacja przejdzie w tryb offline, agent przejdzie w tryb failover na serwerze zarządzania w innej lokacji, zakładając, że konfiguracja trybu failover agenta pozwala na takie działanie. Skonfiguruj ponownie agentów systemu Windows do buforowania tylko serwerów zarządzania w podstawowym centrum danych, które powinny nimi zarządzać, aby zapobiec próbie 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 agent zostanie wdrożony ręcznie w zautomatyzowany sposób za pomocą skryptu (na przykład VBScript lub jeszcze lepiej, programu PowerShell) w celu wstępnego skonfigurowania 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 utrzymać ciągłość grupy zarządzania. Konieczne będzie również wdrożenie SQL Server na maszynie wirtualnej na platformie Azure, a nie w konfiguracji hybrydowej, ponieważ opóźnienie między serwerem zarządzania a SQL Server hostem baz danych programu Operations Manager negatywnie wpłynie na wydajność grupy zarządzania.

Należy wziąć pod uwagę 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.