Поделиться через

Что такое переключение на резерв и возврат на основной ресурс?

В этой статье представлен общий обзор работы переключения при отказе и возврата к исходной конфигурации в облачной среде. Для понимания автоматического переключения на резервный ресурс сначала необходимо разобраться в избыточности и репликации. Чтобы узнать об этих понятиях, прежде чем продолжать работу с этой статьей, см. статью "Избыточность", "Репликация" и "Резервное копирование".

Распространенной причиной сохранения избыточных копий как приложений, так и реплик данных является возможность выполнить отработку отказа. При резервном переключении можно перенаправить трафик и запросы от неисправных экземпляров на исправные. Затем, как только исходные экземпляры снова станут работоспособными, можно выполнить восстановление при отказе, чтобы вернуться к исходной конфигурации.

Роли экземпляров: активные и пассивные

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

Для компонента или коллекции компонентов, настроенных для отработки отказа и восстановления после сбоя, требуется несколько экземпляров. Каждый из этих экземпляров принимает определенную роль:

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

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

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

Подсказка

Некоторые решения создаются для использования активно-активного подхода, что означает, что несколько экземпляров выполняют все запросы. Для системы active-active не требуется переключение на резервный узел, так как все экземпляры активно обслуживают запросы в любое время.

Области переключения при отказе

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

  • Избыточность зоны достигается размещением копий и реплик в разных зонах доступности региона #REF!.
  • Геоизбыточность с использованием глобального балансировщика нагрузки для переключения на резервную систему между регионами.

Ниже приведена упрощенная схема, демонстрирующая общую архитектуру в обычных операциях:

Схема, на которой показана архитектура решения, использующая несколько реплик базы данных в разных зонах доступности в двух отдельных регионах.

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

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

    Схема, показывающая архитектуру решения, в которой активная реплика была повышена до новой активной реплики.

  • Отработка отказа зоны доступности может произойти, если полная зона доступности испытывает сбой. Этот тип сбоя требует, чтобы весь трафик был перенаправлен на веб-сервер в оставшейся зоне, а также гарантирует, что реплика базы данных в оставшейся зоне становится активной репликой, если это еще не так:

    Схема, показывающая архитектуру решения, в которой недоступна одна зона доступности.

  • Отказ всего региона может произойти в случае катастрофической потери всего основного региона #REF!.

    Схема, показывающая архитектуру решения, в которой один регион недоступен.

Хотя каждая из этих областей предоставляет тип переключения на резерв, они могут иметь различные требования и процессы. Кроме того, корпорация Майкрософт может отвечать за некоторые области ответственности за отказоустойчивость, например, при использовании зонально-избыточных служб, в то время как вы можете нести ответственность за отказоустойчивость в более широких областях, например, переход между регионами #REF!.

Планирование обеспечения непрерывности бизнеса и резервного переключения

Часть планирования непрерывности бизнес-процессов — разработка стратегий переключения в случае отказа, включая различные уровни, на которых можно выполнить переключение.

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

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

Имейте в виду, что включение процедур отработки отказа в планировании непрерывности бизнес-процессов требует более подробного проектирования и тестирования. Дополнительные сведения см. в статье "Что такое непрерывность бизнес-процессов, высокий уровень доступности и аварийное восстановление?".

Запланированные и незапланированные переключения при отказе

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

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

Как работает отказоустойчивость

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

  1. Обнаружение неисправности (только незапланированные резервные переключения). Автоматическая отработка отказа требует, чтобы механизм обнаруживал, когда экземпляр недоступен, что обычно основано на какой-то проверке работоспособности. Различные службы определяют свое состояние разными способами. Например, некоторые службы заранее отправляют события пульса между экземплярами. Другим пользователям требуется отдельный компонент для проверки каждого экземпляра через регулярный интервал. Часто требуется некоторое время, чтобы мониторы работоспособности обнаружили сбой экземпляра, и важно предоставить льготный период в случае, если экземпляр был просто занят и не мог реагировать.

  2. Выберите режим отказоустойчивости. В какой-то момент будет принято решение о выполнении аварийного переключения. Решение может быть принято автоматическим инструментом или вручную. Терпимость к рискам вашей организации может повлиять на то, насколько быстро это решение принято. Если у вас низкая терпимость к риску, вы можете быстро переключиться на резервный, если есть какие-либо признаки проблемы. Если у вас большая толерантность к риску, вы можете подождать, чтобы узнать, можно ли устранить проблему перед переключением.

  3. Выберите новый первичный экземпляр. Один из оставшихся экземпляров должен стать новым первичным.

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

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

  4. Перенаправление запросов. Настройте среду таким образом, чтобы запросы направлялись в работоспособные экземпляры или в новый основной экземпляр.

    Для этого может потребоваться обновить другие системы, чтобы они знали, куда отправлять запросы. Это может потребовать обновления системы балансировки нагрузки, чтобы исключить неработоспособный экземпляр. В других ситуациях система доменных имен (DNS) часто используется в качестве способа отправки запросов активному экземпляру системы. В рамках процесса отработки отказа обычно необходимо обновить записи DNS, чтобы запросы перенаправлялись в новый первичный экземпляр. DNS имеет концепцию времени жизни (TTL), которая указывает клиентам, как часто они должны проверять наличие обновленных записей DNS. Если для TTL задано большое значение, может пройти некоторое время, прежде чем клиенты получат информацию о переключении при отказе, и они могут продолжать отправлять запросы на старичный первичный сервер.

Так как процессы отработки отказа могут включать задержки, важно спланировать процедуры отработки отказа в соответствии с требованиями к простою (цель точки восстановления или RTO) и потери данных (цель точки восстановления или RPO). Дополнительные сведения см. в статье "Что такое непрерывность бизнес-процессов, высокий уровень доступности и аварийное восстановление?".

Failback

Failback — это процесс восстановления и перенаправления трафика обратно в исходный первичный экземпляр.

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

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

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

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

  • Действия по исправлению. Если какие-либо действия по исправлению были выполнены на основном экземпляре до переключения на резервную копию, возможно, они оставили основной экземпляр в неизвестном состоянии.

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

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

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

  • Толерантность к рискам. Если отработка отказа произошла из-за сбоя, допустимость организации к простою или другим рискам во время восстановления от отказа может быть ниже.

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

Переключение на резервный сервер и возврат на основной сервер в службах #REF!

Хотя важно понять, как работает отработка отказа в целом, имейте в виду, что каждая служба #REF! может по-разному выполнять процесс отработки отказа и возврат после него. Дополнительные сведения о том, как работают конкретные службы #REF! с точки зрения надежности, см. руководство по надежности каждой службы.

Многие службы #REF! автоматически обрабатывают определенные типы переключения на резервный канал. Например, при использовании служб #REF!, настроенных для зональной избыточности, корпорация Майкрософт автоматически выполняет переключение между зонами доступности. Дополнительные сведения см. в разделе Что такое зоны доступности? и руководство по надежности служб #REF!.

При использовании виртуальных машин Azure Site Recovery реплицирует виртуальные машины и их диски между зонами доступности или в другой регион #REF! и предлагает возможность выполнения отработки отказа.

При разработке собственного решения, объединяющего несколько служб #REF! вместе, требования к отработки отказа могут стать более сложными. Предположим, что вы разрабатываете решение с уровнем приложений и базой данных, и вы хотите создать многорегионную активную или пассивной архитектуру. Во время сбоя в основном регионе важно, чтобы приложение и база данных одновременно переключились в резервный регион. В зависимости от используемых служб может потребоваться спланировать собственный подход к аварийному переключению для переключения между развертываниями в каждом регионе. #REF! обеспечивает глобальную маршрутизацию трафика и балансировку нагрузки через Azure Front Door и Диспетчер трафика Azure, и вы можете выбрать технологию, которая соответствует вашим требованиям к восстановлению после сбоев. Каждая служба поддерживает мониторинг работоспособности каждого регионального экземпляра приложения, и ее можно настроить для автоматического перенаправки трафика в здоровый экземпляр.

Дальнейшие шаги

  • Last updated on