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

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

Высокая доступность

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

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

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

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

Примечание.

Балансировщик сетевой нагрузки не поддерживается для сервера веб-консоли 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, также должна существовать и, возможно, настроена в активном или пассивном состоянии, чтобы избежать дублирования инцидентов, элементов конфигурации и т. д. Агенты будут многодомными между обеими группами управления, поэтому будут повторяться данные.

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

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

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

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 Data Access, System Center Configuration Management и 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 или других общедоступных облачных поставщиков.