Стратегии архитектуры для самовосстановления и самовосстановления

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

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

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

Определения

Проектирование избыточности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация корректного режима деградации

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

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

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

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

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

Реализация фоновых заданий

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

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

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

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

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

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

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

Example

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

Связанные ссылки

• Шаблоны надежности
• Обработка временных сбоев
• Разработка фоновых заданий
• Шаблоны облачной разработки
• Проектирование самовосстановления

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

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