Инфраструктура высокой доступности на базе Microsoft Azure

В этой статье мы опишем пятиэтапный контрольный список, называемый инфраструктура высокой доступности на базе Microsoft Azure

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

Что такое инфраструктура высокой доступности?

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

Высокодоступные системы гарантируют определенный процент времени безотказной работы — например, система, имеющая время безотказной работы 99,9 %, будет простаивать только 0,1 % времени — 0,365 дня или 8,76 часа в год. Число «девяток» обычно используется для обозначения степени высокой доступности. Например, «пять девяток» указывает на систему, которая находится в плюсе в 99,999% случаев.

Основные элементы высокой доступности

Для высокодоступной системы необходимы следующие три элемента:

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

Технические компоненты, обеспечивающие высокую доступность

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

• Резервное копирование и восстановление данных — система, которая автоматически выполняет резервное копирование данных во вторичное хранилище и восстанавливает их обратно в источник. Это можно использовать для настройки резервирования и аварийного переключения. Узнайте больше о системах резервного копирования Acronis Cyber Protect .
• Балансировка нагрузки — балансировщик нагрузки управляет трафиком, направляя его между несколькими системами, которые могут обслуживать этот трафик. Балансировщик нагрузки может знать, что одна из целевых систем вышла из строя, и перенаправлять трафик на другую доступную систему, таким образом реализуя мониторинг и аварийное переключение.
• Кластеризация — кластер содержит несколько узлов, которые служат одной цели, и пользователи обычно получают доступ и рассматривают весь кластер как единое целое. Каждый узел в кластере потенциально может переключиться на другой узел в случае сбоя. Настроив репликацию внутри кластера, вы можете создать избыточность между узлами кластера.

Контрольный список высокой доступности Azure из пяти шагов

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

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

1. Определите требования к доступности

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

Определите показатели доступности. Они могут включать:

• Процент времени безотказной работы
• Среднее время восстановления (MTTR
• Среднее время наработки на отказ (MTBR)
• Целевое время восстановления (RTO)
• Целевая точка восстановления (RPO)

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

Обратите внимание на соглашения об уровне обслуживания Майкрософт для служб Azure.

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

2. Спланируйте свою архитектуру высокой доступности

Начните с анализа режима сбоя (FMA).

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

Учитывайте затраты

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

Примите во внимание отказоустойчивость

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

Репликация данных

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

Документируйте всё

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

3. Выполните сквозное тестирование

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

Дополнительные тесты, которые вы можете провести, чтобы повысить уровень уверенности:

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

4. Развертывайте приложения последовательно

Любое изменение может привести к сбою

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

Учитывайте доступность в процессе ввода в работу.

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

Планирование отката

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

5. Мониторинг работоспособности приложений

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

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

Используйте ведение журналов и аудит

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

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