Концепции высокой доступности и аварийного восстановления в SharePoint Server
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 2016 2019 Subscription Edition 
SharePoint в Microsoft 365
Высокая доступность и аварийное восстановление являются одним из наиболее высоких приоритетов при создании плана и определении характеристик системы для фермы SharePoint Server. Другие аспекты плана, такие как высокая производительность и мощность, сводятся на нет, если серверы не являются высокодоступными или восстановление фермы невозможно.
Для разработки и реализации эффективной стратегии, которая обеспечивает эффективную и бесперебойную работу, вы должны понимать основные принципы высокой доступности и аварийного восстановления. Эти принципы также важно оценить, чтобы выбрать оптимальные технические решения для вашей среды SharePoint.
Введение в управление непрерывностью бизнес-процессов
Управление непрерывностью бизнеса — это процесс или программа управления, которая определяет, оценивает и помогает управлять рисками для обеспечения дальнейшего функционирования организации. Управление непрерывностью бизнеса направлено на создание и поддержание плана обеспечения непрерывности бизнеса, который является схемой дальнейшего выполнения операций в случае прерывания обычных рабочих операций в результате возникновения неблагоприятных условиях. Эти условия могут относиться к природным, техногенным или и тем, и другим. План обеспечения непрерывности создается на основе следующих анализов и входных данных:
Анализ влияния на бизнес
Анализ угроз и рисков
Определение сценариев влияния
Набор документированных требований по восстановлению
В результате создается проектное решение или определенные функции, план реализации, план тестирования и приемки, а также план или график технического обслуживания.
Примером может служить набор для аварийного восстановления и защиты данных и приложений, который предлагает Майкрософт в качестве программы управления непрерывностью бизнеса.
Очевидно, что информационные технологии (ИТ) являются важным аспектом планирования непрерывности бизнеса для многих организаций. Тем не менее, обеспечение непрерывности бизнеса является более комплексным, так как включает в себя все операции, которые необходимо выполнять для обеспечения бесперебойного ведения дел организацией сразу же после серьезных аварий. План обеспечения непрерывности бизнеса включает (помимо прочего) следующие элементы:
политики, процессы и процедуры;
возможные варианты и ответственность за принятие решений;
человеческие ресурсы и производственные объекты;
информационная технология.
Несмотря на то что высокая доступность и аварийное восстановление часто отождествляются с управлением непрерывностью бизнеса, они на самом деле являются подмножеством концепций управления непрерывностью бизнеса.
Описание высокой доступности
Для определенного приложения или службы высокая доступность в итоге измеряется в переводе на впечатления и ожидания конечных пользователей. Материальное и воспринимаемое влияние простоев на бизнес может выражаться в единицах потери информации, повреждении имущества, снижении производительности, скрытых издержках, договорных убытках или потере деловой репутации.
Основная цель решения для обеспечения высокой доступности заключается в сведении к минимуму или устранении последствий простоев. В этом случае надежной стратегией является оптимальная балансировка бизнес-процессов и соглашений об уровне обслуживания (SLA) с техническими возможностями и затратами на инфраструктуру.
Платформа считается высокодоступной в соответствии с соглашением и ожиданиями пользователей и заинтересованных лиц. Доступность системы может рассчитываться следующим образом:
Действительное время безотказной работы/ожидаемое время безотказной работы X 100 %
Итоговое значение часто выражается в отрасли в количестве цифр «9», которое обеспечивается решением; это необходимо для выражения объема безотказной работы в минутах в год или, наоборот, для выражения объема простоя в минутах в год.
| Количество цифр «9» | Процент доступности | Общий годовой объем простоев |
|---|---|---|
| 2 |
99 % |
3 дня 15 часов |
| 3 |
99,9 % |
8 часов 45 минут |
| 4 |
99,99 % |
52 минуты 34 секунды |
| 5 |
99,999 % |
5 минут 15 секунд |
Планированные и незапланированные простои
Перебои в работе системы могут быть ожидаемыми и запланированными либо являться результатом незапланированного сбоя. Простои не должны восприниматься отрицательно, если осуществляется соответствующее управление ими. Существуют два основных типа прогнозируемых простоев:
Плановое обслуживание. Временной интервал предварительно обговаривается и координируется для выполнения таких плановых задач по техническому обслуживанию, как исправление программного обеспечения, обновление оборудования, обновление паролей, автономная переиндексации, загрузка данных или тренировка процедур аварийного восстановления. Хорошо продуманные рабочие процедуры, вероятнее всего, обеспечивают сведение к минимуму времени простоя и предотвращение каких-либо потерь данных. Запланированные мероприятия по техническому обслуживанию можно рассматривать как инвестиции, необходимые для предотвращения других (возможно, более серьезных) сценариев незапланированных перебоев в работе или смягчения их последствий.
Незапланированные отключения. Могут возникать сбои на уровне систем, инфраструктуры или процессов, которые являются незапланированными или неконтролируемыми, а также сбои которые можно спрогнозировать, однако вероятность их возникновения слишком низка, или сбои, последствия которых считаются допустимыми. Надежные решения высокой доступности обнаруживают эти типы отказов, обеспечивают автоматическое восстановление после сбоя и последующее восстановление отказоустойчивости.
При формировании соглашения об уровне обслуживания для обеспечения высокой доступности необходимо рассчитать отдельные ключевые показатели эффективности для проведения запланированных мероприятий по техническому обслуживанию и незапланированных простоев. Такой подход позволяет сопоставить инвестиции в запланированные процедуры по обслуживанию и преимущества предотвращения незапланированных простоев.
Сниженная доступность
Высокая доступность не должна рассматриваться с точки зрения «все или ничего». Как правило, вполне допустимыми считаются ситуации, когда система является частично доступной для конечного пользователя, функциональность ограничивается, а производительность снижается (как альтернатива полному выходу системы из строя). Эти различные степени доступности включают следующие:
Операции только чтения и отложенные операции. На протяжении периода технического обслуживания или во время поэтапного аварийного восстановления извлечение данных по-прежнему возможно, но новые рабочие процессы и операции фоновой обработки могут быть временно приостановлены или поставлены в очередь.
Задержка данных и время отклика приложений. В результате превышения рабочей нагрузки, формирования очереди обработки или частичного отказа платформы ограниченные аппаратные ресурсы могут быть перегружены или их размер может не соответствовать требованиям. В результате может ухудшаться работа пользователей с функциями системы, но при это рабочие операции могут по-прежнему выполняться менее эффективным способом.
Частичные, временные или предстоящие сбои. Корректность логики приложения или аппаратного стека, которая обеспечивает выполнение повторных попыток или самостоятельное исправление при обнаружении ошибки. Эти типы неполадок могут восприниматься конечным пользователем как задержки данных или низкая степень отклика приложений.
Частичный сквозной сбой. Запланированные или незапланированные отключения могут возникать плавно на уровне вертикальных слоев стека решения (инфраструктура, платформы и приложение) или на уровне горизонтальных слоев между различными функциональными компонентами. Пользователи могут наблюдать частичное успешное выполнение операций или ухудшение их выполнения в зависимости от затрагиваемых функций или компонентов.
Приемлемость этих условно оптимальных сценариев следует рассматривать в рамках спектра ухудшенной доступности, приводящей к полному отключению, а также в рамках промежуточных этапов поэтапного аварийного восстановления.
Количественная оценка простоев
Когда возникает простой (либо запланированный, либо незапланированный), основная бизнес-цель заключается в возврате системы в рабочее состояние и сведении к минимуму потери данных. Каждая минута простоя ведет к возникновению прямых и косвенных затрат. При возникновении незапланированных сбоев необходимо сбалансировать время и усилия, необходимые для определения причин появления сбоя, определения текущего состояния системы и действий, необходимых для восстановления после сбоя.
В предварительно заданной точке любого перебоя необходимо принять или найти бизнес-решение для прекращения расследования простоя или выполнения задач обслуживания, восстановить систему после сбоя, возвратив ее в рабочее состояние, и (при необходимости) обеспечить восстановление отказоустойчивости.
Цели восстановления
Избыточность данных это ключевой компонент решения базы данных высокой доступности. Транзакционные действия на основном экземпляре SQL Server синхронно или асинхронно применяются к одному или нескольким вторичным экземплярам. При возникновении сбоев возможен откат транзакций, находящихся в рабочем состоянии, или эти транзакции могут быть потеряны на вторичных экземплярах в связи с задержками распространения данных.
Можно оценить влияние и определить цели восстановления с точки зрения того, сколько времени требуется для возврата в работу и какая временная задержка возникла при восстановлении последней транзакции:
Целевое время восстановления (RTO). Это длительность простоя. Начальная цель — вернуть систему в режим "в сети" по крайней мере в емкости только для чтения, чтобы упростить исследование сбоя. Однако основной целью является восстановление полного обслуживания до такой степени, что могут выполняться новые транзакции.
Целевая точка восстановления (RPO). Это часто называют мерой допустимой потери данных. Это интервал времени или задержка между последней зафиксированной транзакцией данных до сбоя и последними данными, восстановленными после сбоя. Фактическая потеря данных может отличаться в зависимости от рабочей нагрузки в системе во время сбоя, типа сбоя и типа используемого решения для обеспечения высокой доступности.
Примечание.
Связанная цель — цель уровня восстановления (RLO). Эта цель определяет степень детализации, с которой вы должны иметь возможность восстановления данных. Необходимо ли восстановить всю ферму, веб-приложение, семейство веб-сайтов, сайт, список, библиотеку или элемент. Дополнительные сведения см. в статье Plan for backup and recovery in SharePoint Server.
Значения RTO и RPO следует использовать как цели, которые определяют допустимые простои и уровни потери данных, а также как показатели мониторинга эффективности доступности.
Обоснование рентабельности инвестиций и альтернативных издержек
Затраты компании на обеспечение простоев могут носить финансовый характер или принимать форму добровольного участия клиента. Эти расходы могут возникнуть с течением времени или в определенный момент интервала сбоя. В дополнение к прогнозированию расходов на сбои с учетом определенного времени восстановления и точки восстановления данных можно также рассчитать инвестиции в бизнес-процессы и инфраструктуру, необходимые для достижения целей RTO и RPO или предотвращения отключения всех систем. К этим разделам инвестирования относятся следующие:
Предотвращение простоев. Комплексное предотвращение расходов на восстановление после сбоя возможно в том случае, если перебой изначально не возникает. Инвестиции включают расходы на отказоустойчивую инфраструктуру и резервированную аппаратуру, распределение рабочих нагрузок по изолированным точкам отказа и плановые простои для проведения профилактического обслуживания.
Автоматизация восстановления. Если система выходит из строя, можно значительно смягчить последствия простоев с точки зрения качества обслуживания клиентов путем автоматического и прозрачного восстановления.
Использование ресурсов. Вторичная или резервная инфраструктура может находиться в режиме ожидания простоя. Эти ресурсы можно также использовать для выполнения задач только чтения или для оптимизации общей производительности системы за счет распределения рабочих нагрузок по всем доступным устройствам.
Для данных целей RTO и RPO необходимые инвестиции в обеспечение доступности и восстановление в сочетании с предполагаемыми расходами на простой могут выражаться в единицах времени. Во время действительного простоя это позволяет принимать экономически обоснованные решения на основе прошедшего времени простоя.
Мониторинг работоспособности функции обеспечения доступности
С оперативной точки зрения во время действительного простоя вы не должны пытаться оценить все значимые переменные и рассчитать рентабельность инвестиций или альтернативные издержки в режиме реального времени. Вместо этого следует отслеживать задержку данных на экземплярах в режиме ожидания в качестве прокси для ожидаемого RPO.
В случае выхода из строя необходимо также ограничить изначальное время, затрачиваемое на поиск исходной причины во время простоя. Напротив, следует сосредоточиться на проверке работоспособности среды восстановления, а затем использовать подробные системные журналы и дополнительные копии данных для последующего анализа.
Планирование аварийного восстановления
Попытки обеспечения высокой доступности связаны с предотвращением отключений, а попытки аварийного восстановления связаны с действиями, направленными на восстановление высокой доступности после отключения.
Следует определить процедуры аварийного восстановления и соответствующие обязательства (по мере возможности) до действительного отключения. На основе активного мониторинга и оповещений следует принимать решение о выполнении автоматизированного или ручного аварийного переключения и плана восстановления в соответствии с предустановленными пределами RTO и RPO. Надежный план аварийного восстановления должен включать следующее:
Детализация отказа и восстановления. В зависимости от местоположения и типа отказа можно предпринять корректирующие действия на различных уровнях (то есть центр обработки данных, инфраструктура, платформа, приложения или нагрузки).
Изучение исходного материала. Базовые и наиболее актуальные журналы мониторинга, журналы событий и диагностические запросы должны быть доступны для соответствующих пользователей.
Координация зависимостей. Какие зависимости систем и бизнес-операций существуют в стеке приложений и между заинтересованными сторонами?
Дерево принятия решений. Предопределенное повторяемое подтвержденное дерево решений, которое включает обязанности ролей, приоритеты сбоев, критерии отказоустойчивости с учетом целей RPO и RTO и заданные действия по восстановлению.
Проверки. Что необходимо сделать для обеспечения возврата системы к обычной работе после выполнения действий по восстановлению после сбоя?
Документации. Фиксация всех вышеперечисленных функций в наборе документов с достаточной степенью детализации, которая гарантирует, что третья сторона сможет выполнить план восстановления с минимальной помощью. Этот тип документации обычно называют "журналом регистрации" или "бухгалтерской кулинарией".
Тренировки восстановления. Регулярно приводите в действие план аварийного восстановления для установления базовых ожиданий целей RTO и учета чередования размещения основного производственного сайта на основном сайте и на каждом из сайтов для аварийного восстановления.
См. также
Понятия
Выбор стратегии аварийного восстановления для SharePoint Server
Другие ресурсы
Какие рабочие нагрузки можно защитить с помощью Azure Site Recovery?