Высокая доступность и аварийное восстановление

Важно!

Поддержка этой версии Operations Manager завершена. Мы рекомендуем выполнить обновление до Operations Manager 2022.

System Center — серверы и компоненты Operations Manager могут привести к сбою, что может повлиять на функциональные возможности Operations Manager. Объем данных и функциональные возможности, утраченные при сбое, различаются в каждом случае отказа. Это зависит от роли компонента, завершиющегося сбоем, и от времени, необходимого для восстановления неработоспособности функции.

Высокий уровень доступности

Для обеспечения высокой доступности создается избыточность группы управления для рабочих баз данных и баз данных хранилища данных Operations Manager, шлюза и серверов управления, а также конкретных рабочих нагрузок. Эти рабочие нагрузки включают мониторинг сетевых устройств, мониторинг на разных платформах и рабочие нагрузки, относящиеся к группе управления, которые ранее управлялись корневым сервером управления.

В многосерверной конфигурации группы управления можно использовать SQL Server Always On для обеспечения высокой доступности и непрерывности обслуживания баз данных Operations Manager. Отказоустойчивость сервера управления обеспечивается наличием по меньшей мере двух серверов управления и использованием пулов ресурсов для мониторинга серверов UNIX, серверов Linux и сетевых устройств. Серверы Windows на базе агента можно настроить с основным и дополнительным сервером управления для перенаправления взаимодействий агента на случай сбоя сервера управления.

Эмулятор корневого сервера управления можно также перенести на другой сервер управления, если сервер управления, на котором размещен эмулятор RMS, становится недоступным.

С помощью настройки высокого уровня доступности служб доступа к данным можно обеспечить высокую доступность подключений консоли управления. Это можно сделать, установив балансировку сетевой нагрузки Майкрософт (NLB) или используя аппаратные подсистемы балансировки нагрузки или псевдоним DNS. Один или несколько серверов управления добавляются в пул NLB в качестве участников, и при открытии любой консоли вы ссылаетесь на виртуальное имя серверов управления с балансировкой нагрузки, зарегистрированное в DNS.

Примечание

Сетевой Load Balancer не поддерживается для сервера веб-консоли Operations Manager.

В границах доверия можно развернуть несколько серверов шлюзов для реализации избыточных путей для агентов в пределах границы доверия. Агенты могут выполнять отработку отказа между основным сервером управления и одним или несколькими серверами управления. Аналогично они могут выполнять отработку отказа между серверами шлюзов. Кроме того, можно использовать несколько серверов шлюзов для распределения рабочей нагрузки управления компьютерами, управляемыми без агентов, и управляемыми сетевыми устройствами.

Кроме того, для обеспечения избыточности за счет отработки отказа агента или шлюза серверы шлюзов могут быть настроены для отработки отказа между серверами управления в группе управления, если доступно несколько серверов.

Хотя SQL Server Reporting Services поддерживает модель горизонтального развертывания, которая позволяет запускать несколько экземпляров сервера отчетов, которые совместно используют одну базу данных сервера отчетов, она не поддерживается Operations Manager. Operations Manager Reporting устанавливает пользовательское расширение безопасности в рамках установки интерфейсных компонентов, которые невозможно реплицировать в веб-ферме.

Аварийное восстановление

Аварийное восстановление — это меры, которые предпринимаются для того, чтобы иметь возможность продолжить работу в случае катастрофического сбоя (например, в случае полной потери ЦОД, где размещена основная инфраструктура). Это важный элемент, который необходимо учитывать при любом развертывании, и решения, принятые при планировании аварийного восстановления, влияют на то, как Operations Manager сможет продолжать поддерживать упреждающий мониторинг и отчеты о производительности и доступности критически важных ИТ-служб. В этом разделе основное внимание уделяется рекомендованной стратегии аварийного восстановления, обеспечению устойчивости и мерам, способным обеспечить плавное восстановление.

Хотя решения высокого уровня доступности и аварийного восстановления обеспечивают защиту от сбоев или потери системы, на них не следует полагаться для защиты от случайной, непреднамеренной или вредоносной потери или повреждения данных. В таких случаях для операций восстановления может потребоваться использовать резервные копии скопированных или отложенных копий репликации. Во многих случаях операция восстановления является наиболее подходящей формой аварийного восстановления. Один из примеров — база данных отчетов с низким приоритетом или данные анализа. Во многих случаях затраты на включение многосайтового аварийного восстановления на уровне систем или приложений намного превосходят ценность получаемых данных. В случаях, когда ценность данных в краткосрочной перспективе низкая, а доступ к данным можно отложить без серьезных последствий сбоя для бизнеса, а аварийное восстановление сайта является избыточным, оцените целесообразность использования простого резервного копирования и процессов аварийного восстановления, если экономия затрат делает такой подход целесообразным.

Понимание влияния и допустимого простоя поможет сформулировать решения, понимание которых необходимо, чтобы правильно спроектировать архитектуру Operations Manager, а также определить уровень сложности и затраты, связанные с поддержкой аварийного восстановления. Кроме того, необходимо учитывать приемлемый для ИТ-организации объем потери данных мониторинга без последствий для бизнеса. Это лучше всего описывается двумя понятиями: целевое время восстановления (RTO) и целевая точка восстановления (RPO).

Ниже приведены две наиболее распространенные конфигурации аварийного восстановления для Operations Manager:

  • Создание повторяющейся группы управления, развернутой в дополнительном центре обработки данных, которая дублирует основную группу управления в масштабе и конфигурации.
  • Развертывание дополнительных серверов во вторичном ЦОД, чтобы обеспечить поддержку рабочей базы данных и базы данных хранилища данных; при этом серверы управления устанавливаются в конфигурации холодного резерва и не участвуют в группе управления до тех пор, пока не потребуется выполнить действия восстановления.

Развертывание повторяющейся группы управления является вариантом, если нет допустимого времени простоя; однако это самый сложный вариант. Конфигурация между ними должна быть согласованной, чтобы при обрезке не было никакой разницы в том, что отслеживается, оповещается или сообщается, представляется и, наконец, обостряется. Интеграция с другими платформами мониторинга или платформами ITSM, такими как System Center — Service Manager, Remedy или ServiceNow, также должна существовать и, возможно, настроена в активном или пассивном состоянии, чтобы избежать дублирования инцидентов, элементов конфигурации и т. д. Агенты будут размещаться в обеих группах управления, следовательно, данные будут дублироваться.

На следующей схеме приводится пример этого сценария разработки.

Схема повторяющихся MG.

Если для развертывания Operations Manager не требуется немедленное восстановление и вы хотите избежать сложности повторяющихся групп управления, можно также развернуть дополнительные компоненты группы управления в дополнительном центре обработки данных, чтобы сохранить функциональные возможности группы управления. Как минимум, рассмотрите возможность реализации группы доступности SQL Server 2014 или 2016 AlwaysOn, чтобы обеспечить восстановление рабочей базы данных и базы данных хранилища данных в двух и более ЦОД, где экземпляр отказоустойчивого кластера с двумя узлами развернут в основном ЦОД, а автономный SQL Server — во вторичном ЦОД в составе отказоустойчивого кластера Windows Server (WSFC). Вторичная реплика группы доступности AlwaysOn будет размещена в отдельном экземпляре, отличном от FCI, как показано на следующей схеме.

Схема простой конфигурации аварийного восстановления.

В этом примере потребовалось бы развернуть один или несколько экземпляров Windows Server с той же аппаратной конфигурацией и именем компьютера и переустановить роль сервера управления с помощью параметра /Recover. Рассмотрим пример:


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

Дополнительные сведения см. в статье Установка Operations Manager из командной строки.

В течение этого времени агенты будут ставить в очередь собранные данные (оповещения, события, производительность и т. д.), пока они не смогут возобновить обмен данными с сервером управления в группе управления. Такой подход позволяет избежать установки новых экземпляров SQL Server и восстановления баз данных из последней проверенной рабочей резервной копии. Однако в этом сценарии восстановления, скорее всего, будет более длительная задержка при возвращении в работоспособное состояние, так как вам потребуется развернуть другие роли, необходимые для возобновления минимальной функциональности мониторинга. Если такой подход неприемлем, можно развернуть серверы управления во вторичном центре обработки данных для восстановления в режиме ожидания. Удалите их в качестве участников трех основных пулов ресурсов: пулов ресурсов всех серверов управления, уведомления и назначения AD. Сюда же относится любой пользовательский пул ресурсов, который может включать серверы управления, размещенные в основном ЦОД, которые должны продолжать функционировать в рамках плана восстановления. Службы доступа к данным System Center, управления конфигурацией System Center и Microsoft Monitoring Agent должны быть остановлены и настроены для запуска вручную или отключены и запущены только в сценарии аварийного восстановления.

Если сервер управления поддерживает интеграцию (через соединитель, размещенный непосредственно на сервере управления или из другого продукта System Center, например VMM, Orchestrator или Service Manager), это необходимо запланировать с помощью действий по ручному или автоматическому восстановлению в зависимости от конфигурации интеграции и последовательности шагов восстановления. Это гарантирует, что любая зависимость на сервере управления будет зафиксирована и учтена в плане, когда потребуется реализовать план аварийного восстановления.

Иллюстрация сложной конфигурации аварийного восстановления.

Если один из сайтов отключается от сети, агент выполнит аварийное переключение на сервер управления на другом сайте, предполагая, что конфигурация аварийного переключения агента допускает это. Измените конфигурацию агентов Windows так, чтобы кэшировать только серверы управления в основном ЦОД, которые должны управлять этими агентами и не допускать аварийного переключения на сервер управления в дополнительном ЦОД, что лишь отсрочит восстановление и отчетность. Это можно сделать, если вы вручную развернете агент автоматически с помощью скрипта (например, VBScript или, что еще лучше, PowerShell) для предварительной настройки во время установки, или после развертывания, если вы отправляете агент из консоли, снова используя скриптовый метод, управляемый с помощью корпоративного решения для управления конфигурацией.

В качестве альтернативного метода аварийного развертывания в целях обеспечения непрерывности группы управления можно развернуть Operations Manager на виртуальных машинах Azure. Необходимо также развернуть SQL Server на виртуальной машине в Azure, а не в гибридной конфигурации, так как задержка между сервером управления и SQL Server размещения баз данных Operations Manager негативно скажется на производительности группы управления.

Рассмотрите область мониторинга, топологию сети и сетевое подключение к Microsoft Azure (vpn-подключение типа "сеть — сеть" или ExpressRoute), точки интеграции (то есть решения ITSM, другие продукты System Center, надстройки третьей части и т. д.), доступ к консоли, нормативные или соответствующие законы или политики и т. д., чтобы правильно разработать этот сценарий в Azure IaaS или других поставщиках общедоступных облачных служб.