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

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

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

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

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

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

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

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

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

Области отработки отказа

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

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

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

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

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

  

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

  

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

  

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

Планирование отработки отказа и непрерывности бизнес-процессов

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

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

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

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

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

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

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

Как работает переключение при сбое

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

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

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

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

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

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

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

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

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

Возврат к исходной системе

Откат — это процесс восстановления и перенаправления трафика обратно в исходную основную инстанцию.

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

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

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

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

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

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

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

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

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

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

Отказоустойчивость и возврат после отказа в службах Azure

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

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

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

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

Дальнейшие действия

• Узнайте о общей ответственности за надежность.
• Сведения о рекомендациях по проектированию с высоким уровнем доступности в нескольких регионах в Azure Well-Architected Framework.