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

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

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

Регионы Azure, используемые для решения, являются критически важным выбором. В руководстве по выбору регионов Azure описано, как выбрать и работать в нескольких географических регионах. Использование регионов и зон доступности в решении также влияет на несколько основных компонентов платформы Well-Architected Framework:

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

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

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

• Операционное превосходство: Сложная архитектура требует больше усилий для развертывания, настройки и управления ими. Для высокодоступного решения может потребоваться также спланировать отработку отказа в дополнительный набор ресурсов. Переключение на резерв, возврат на основное и прозрачное перенаправление трафика могут быть сложными, особенно когда требуются ручные шаги. Рекомендуется автоматизировать процессы развертывания и управления. Дополнительную информацию см. в руководствах по столпу операционной эффективности, включая OE:05 Инфраструктура как код, OE:09 Автоматизация задач, OE:10 Дизайн автоматизациии OE:11 Практики развертывания.

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

Определения

Узнайте, как организованы регионы и зоны доступности в Azure

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

Регионы Azure имеют различные конфигурации, которые также называются архитектурами регионов.

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

На следующей схеме показано несколько примеров регионов Azure. Регионы 1 и 2 поддерживают зоны доступности.

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

Существует два способа использования зон доступности в решении:

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

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

Службы Azure поддерживают один или оба этих подхода. Решения PaaS для платформы как услуги обычно поддерживают избыточное между зонами развертывание. Решения инфраструктуры как услуги (IaaS) обычно поддерживают зональные развертывания. Дополнительные сведения о работе служб Azure с зонами доступности см. в службах Azure с поддержкой зоны доступности.

Корпорация Майкрософт пытается использовать подходы, которые являются наименее разрушительными во время развертываний обновлений служб. Например, корпорация Майкрософт стремится развертывать обновления в одном поясе доступности одновременно. Этот подход может снизить влияние, которое может повлиять на активную рабочую нагрузку, так как рабочая нагрузка может продолжать выполняться в других зонах во время обновления. Однако это в конечном счете ответственность группы рабочей нагрузки, чтобы гарантировать, что их рабочая нагрузка продолжает функционировать во время обновлений платформы. Например, когда вы используете масштабируемые наборы виртуальных машин с гибким режимом оркестрацииили большинство служб Azure PaaS, Azure интеллектуально размещает ваши ресурсы, чтобы уменьшить влияние обновлений платформы. Рассмотрите возможность чрезмерной подготовки, которая развертывает больше экземпляров ресурса, чтобы некоторые экземпляры оставались доступными при обновлении других экземпляров. Дополнительные сведения о развертывании обновлений Azure см. в разделе "Рекомендации по безопасному развертыванию".

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

Дополнительные сведения о том, как Azure использует регионы и зоны доступности, см. в регионах Azure и зонах доступности.

Понимание совместной ответственности

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

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

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

Определение ключевых требований к бизнесу и рабочей нагрузке

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

Толерантность к риску

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

В следующей таблице перечислены некоторые распространенные риски, которые следует учитывать в облачной среде.

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

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

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

Цели уровня обслуживания

Вы должны понимать ожидаемый целевой уровень обслуживания (SLO) вашего решения. Например, у вас может быть бизнес-требование, что решение должно соответствовать 99,9% времени простоя.

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

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

Место расположения данных

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

Расположение пользователя

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

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

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

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

Бюджет

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

Сложность

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

Пример сценария

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

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

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

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

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

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

Подход к развертыванию 1. Локально избыточные развертывания

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

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

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

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Локально резервные развертывания с резервным копированием в разных регионах

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

При реализации этого подхода необходимо тщательно рассмотреть RTO и RPO.

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

• Точка восстановления: Частота резервного копирования определяет объем потери данных, который может возникнуть, как точка восстановления. Обычно можно управлять частотой резервных копий, чтобы обеспечить соответствие RPO.

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Подход к развертыванию 2. Зональные (закрепленные) развертывания

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

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

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

При использовании зональной модели развертывания вы берете на себя множество обязанностей:

• Необходимо развернуть ресурсы в каждой зоне доступности и настроить и управлять этими ресурсами по отдельности.

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

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

• Если в зоне доступности происходит сбой, необходимо обработать отказ, чтобы перенаправить трафик к ресурсам в другой зоне доступности.

Активное пассивное развертывание в нескольких зонах доступности иногда называется аварийное восстановление в регионе или аварийное восстановление метро.

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

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

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

Подход к развертыванию 3: Развертывание избыточное по зонам

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

Уровень хранилища также распространяется по нескольким зонам доступности. Копии данных вашего приложения распределяются по нескольким зонам доступности с помощью синхронной репликации. Когда приложение вносит изменения в данные, служба хранилища записывает изменения в несколько зон доступности. Транзакция считается завершенной только после завершения всех этих изменений. Этот процесс гарантирует, что каждая зона доступности всегда имеет up-to-date копии данных. Если в зоне доступности происходит сбой, для доступа к тем же данным можно использовать другую зону доступности.

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

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Этот подход возможен с множеством служб Azure, включая масштабируемые наборы виртуальных машин Azure, Службу приложений Azure, Функции Azure, Службу Azure Kubernetes (AKS), службу хранилища Azure, SQL Azure, служебную шину Azure и многие другие службы. Для получения полного списка служб, поддерживающих резервирование зон, см. в разделе "Служба зон доступности и региональная поддержка".

Развертывания с зональной избыточностью и резервным копированием по разным регионам

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

При реализации этого подхода необходимо тщательно рассмотреть RTO и RPO.

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

• Точка восстановления: Частота резервного копирования определяет объем потери данных, который может возникнуть, как точка восстановления. Обычно можно контролировать частоту резервных копий для соответствия RPO.

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Подход к развертыванию 4. Развертывание в нескольких регионах

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

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

Архитектура с несколькими регионами сложна, и существует множество способов разработки решения с несколькими регионами. Для некоторых рабочих нагрузок имеет смысл, чтобы несколько регионов одновременно обрабатывали запросы (активно-активные развертывания). Для других рабочих нагрузок лучше назначить один основной регион и использовать один или несколько дополнительных регионов для резервирования (активно-пассивные развертывания). В этом разделе основное внимание уделяется второму сценарию, в котором один регион активен, а другой — пассивным. Дополнительные сведения о решениях с несколькими регионами active см. в разделе "Шаблон меток развертывания" и "Геодокум".

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

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

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

Асинхронная репликация данных

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

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Синхронная репликация данных

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

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

В следующей таблице перечислены некоторые проблемы с точки зрения архитектуры.

Архитектура регионов

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

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

Объедините подходы с несколькими зонами и регионами

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

Как службы Azure поддерживают подходы к развертыванию

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

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

Примеры вариантов использования

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

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

Contoso, Ltd., является крупной производственной компанией. Компания реализует бизнес-приложение для управления некоторыми компонентами финансовых процессов.

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

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

Внутреннее приложение

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

Бизнес-требования: Для этой рабочей нагрузки эффективность затрат является основной проблемой. Компания "Четвертый Кофе" оценила влияние простоев на бизнес и решила, что приложению не нужно уделять внимание устойчивости или производительности. Компания принимает риск того, что сбой в зоне доступности Azure или регионе может временно сделать приложение недоступным.

Предлагаемые подходы:

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

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

Миграция устаревших приложений

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

Бизнес-требования: Производительность является приоритетом для этого приложения. Устойчивость также важна, и приложение должно продолжать работать, даже если центр обработки данных Azure испытывает сбой.

Предлагаемый подход:

• Fabrikam должно сначала попробовать развертывание с избыточностью между зонами . Они должны убедиться, что производительность соответствует их требованиям.

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

Приложение для здравоохранения

Компания Lamna Healthcare внедряет новую электронную систему медицинских записей на платформе Azure.

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

Предлагаемые подходы:

• Развертывание в нескольких зонах и регионах, если существует несколько регионов, которые соответствуют требованиям к размещению данных Lamna.

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

Банковская система

Woodgrove Bank выполняет свои основные банковские операции из большого решения, развернутого в Azure.

Бизнес-требования: Эта система критически важна. Любые сбои могут привести к серьезным финансовым последствиям для клиентов. В результате Woodgrove Bank имеет очень низкую устойчивость к риску. Система нуждается в самом высоком уровне надежности, и архитектура должна снизить риск любых сбоев, которые могут быть устранены.

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

Программное обеспечение как услуга

Proseware, Inc., создает программное обеспечение, которое компании по всему миру используют. База пользователей компании широко распределена по географическому расположению.

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

Предлагаемые подходы:

• Развертывание с несколькими зонами в нескольких регионах обычно является хорошим выбором для поставщика программного обеспечения как службы (SaaS), особенно если оно используется в шаблоне меток развертывания.

• Развертывание с избыточностью между зонами с помощью глобального решения для ускорения трафика, например Azure Front Door.

Дальнейшие шаги

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

• Базовые зонально-избыточные высокодоступные веб-приложения
• высокодоступное веб-приложение с несколькими регионами
• многорегиональное приложение n-уровня
• Многоуровневое веб-приложение, созданное для обеспечения высокой доступности и аварийного восстановления

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

• Azure Site Recovery: включение аварийного восстановления виртуальной машины Azure между зонами доступности
• Azure NetApp Files. Общие сведения о репликации между зонами Azure NetApp Files
• Избыточность службы хранилища Azure