Документация по надежности Azure

  • Статья

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

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

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

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

Сведения о принципах надежности и надежности и архитектуре в службах Microsoft Azure см. в статье Microsoft Azure Well-Architected Framework: надежность.

Требования к надежности

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

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

Diagram showing the shared responsibility model for Azure business continuity.

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

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

Создание надежности

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

В следующем списке проверка рассматривается область планирования надежности.

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

RTO и RPO

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

  • Целевое время восстановления (RTO) — это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента.

  • Целевая точка восстановления (RPO) — это максимальная продолжительность потери данных, которая является приемлемой во время аварии.

RTO и RPO являются нефункциональными требованиями к системе и должны определяться бизнес-требованиями. Для получения этих значений рекомендуется провести оценку рисков и четко определить стоимость простоев или потери данных.  

Регионы и зоны доступности

Регионы и зоны доступности являются частью уравнения надежности. Регионы имеют несколько физически отдельных зон доступности. Эти зоны доступности подключены высокопроизводительной сетью с задержкой менее 2 мс между физическими зонами. Низкая задержка помогает данным оставаться синхронизированными и доступными при неправильном выполнении действий. Эту инфраструктуру можно использовать стратегически при разработке приложений и инфраструктуры данных, которые автоматически реплика te и обеспечивают непрерывные службы между зонами и регионами.

Службы Microsoft Azure поддерживают зоны доступности и позволяют управлять облачными операциями в оптимальном уровне доступности при поддержке стратегии восстановления между регионами и непрерывности бизнес-процессов.

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

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

Зависимости службы Azure

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

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

Службы Azure создаются для надежности, включая высокий уровень доступности и аварийное восстановление. Нет служб, зависящих от одного логического центра обработки данных (чтобы избежать отдельных точек сбоя). Нерегиональная служба, указанная в продуктах глобальной инфраструктуры Azure, — это службы, для которых нет зависимости от определенного региона Azure. Службы, не являющиеся региональными, развертываются в двух или более регионах, и при наличии регионального сбоя экземпляр службы в другом регионе продолжит работу для клиентов. Некоторые нерегионарные службы позволяют клиентам указывать регион, в котором будет развернута базовая виртуальная машина ( виртуальная машина). Например, виртуальный рабочий стол Azure позволяет клиентам указать расположение региона, в котором находится виртуальная машина. Все службы Azure, в которых хранятся данные клиента, позволяют клиенту указывать определенные регионы, в которых будут храниться их данные. Исключением является идентификатор Microsoft Entra, имеющий географическое размещение (например, Европа или Северная Америка). Дополнительные сведения о местонахождении хранилища данных см. на карте расположения данных.

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

Следующие шаги