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

Рекомендации по самовосстановлению и самовосстановлению

  • Статья

Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:

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

Связанные руководства. Временные задания фоновых заданий |

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

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

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

Определения

Термин Определение
Самостоятельное восстановление Возможность автоматической устранения проблем рабочей нагрузки путем восстановления затронутых компонентов и при необходимости отработки отказа в избыточной инфраструктуре.
Самосохранение Способность рабочей нагрузки быть устойчивой в отношении потенциальных проблем.

Основные стратегии проектирования

Проектирование для самосохранения

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

Руководство по проектированию инфраструктуры и шаблоны

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

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

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

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

Руководство по проектированию приложений и шаблоны

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

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

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

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

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

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

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

  • Настройка времени ожидания запроса: настройка времени ожидания запроса для вызовов служб или баз данных. Время ожидания подключения к базе данных обычно устанавливается в 30 секунд.

  • Шаблон gatekeeper: защита приложений и служб с помощью выделенного экземпляра узла для брокера запросов между клиентами и приложением или службой. Брокер проверяет и очищает запросы и может обеспечить дополнительный уровень безопасности, чтобы ограничить область атаки системы.

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

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

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

Фоновые задания

Фоновые задания — это эффективный способ повышения надежности системы путем развязывания задач из пользовательского интерфейса (пользовательского интерфейса). Реализуйте задачу как фоновое задание, если оно не требует ввода пользователем или обратной связи, и если оно не влияет на скорость отклика пользовательского интерфейса.

Ниже приведены распространенные примеры фоновых заданий:

  • Задания с большим объемом ЦП, такие как выполнение сложных вычислений или анализ структурных моделей.
  • Задания с интенсивным вводом-выводом, например выполнение нескольких операций хранения или индексирование больших файлов.
  • Пакетные задания, такие как регулярное обновление данных или обработка задач в определенное время.
  • Длительные рабочие процессы, например выполнение заказа или подготовки служб и систем.

Дополнительные сведения см. в рекомендациях по фоновым заданиям.

Разработка для автоматического восстановления

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

Руководство по проектированию инфраструктуры

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

  • Вычислительные ресурсы: службы вычислений Azure Масштабируемые наборы виртуальных машин и большинство платформ как службы (PaaS) можно настроить для автоматической отработки отказа.

  • Базы данных: реляционные базы данных можно настроить для автоматической отработки отказа с помощью таких решений, как отказоустойчивые кластеры SQL Azure, группы доступности AlwaysOn или встроенные возможности со службами PaaS. Базы данных NoSQL имеют аналогичные возможности кластеризации и встроенные возможности для служб PaaS.

  • Хранилище. Используйте избыточные параметры хранения с автоматической отработкой отказа.

Руководство по проектированию приложений и шаблоны

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

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

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

  • Деградировать корректно: иногда вы не можете обойти проблему, но вы можете обеспечить сокращенную функциональность. Рассмотрим приложение, которое отображает каталог книг. Если это приложение не может получить эскиз обложки, просто используйте изображение-заполнитель. Иногда работа приложения может не зависеть от целых подсистем. Например, для веб-сайта электронной коммерции, показывающее рекомендации по продукту, вероятно, меньше, чем заказы на обработку. Более корректное снижение может также включать операции автоматической отработки отказа. Когда база данных автоматически выполняет отработку отказа в реплику из-за проблемы с основным экземпляром, производительность снижается в течение короткого времени.

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

  • Шаблоны тестов: включите тестирование шаблонов, которые вы реализуете в рамках стандартных процедур тестирования.

  • Используйте контрольные точки для длительных транзакций: контрольные точки могут обеспечить устойчивость при сбое длительной операции. При перезапуске операции, например, если она была выбрана другой виртуальной машиной, она может возобновиться с последней контрольной точки. Рекомендуется реализовать механизм, который записывает сведения о состоянии задачи через регулярные интервалы. Сохраните это состояние в устойчивом хранилище, которое может получить доступ к любому экземпляру процесса, выполняющего задачу. Если процесс завершен, работа, выполняемая им, может быть возобновлена из последней контрольной точки с помощью другого экземпляра. Существуют библиотеки, которые предоставляют эти функции, такие как NServiceBus и MassTransit. Они прозрачно сохраняют состояние, в котором интервалы соответствуют обработке сообщений из очередей в Служебная шина Azure.

Автоматическое самовосстановление действий

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

Упрощение функций Azure

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

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

Рекомендации

Ознакомьтесь с рекомендациями по каждому шаблону. Убедитесь, что шаблон подходит для рабочей нагрузки и бизнес-требований перед реализацией.

Пример

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

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности