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

Надежность в Решение Azure VMware

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

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

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

Рекомендации по развертыванию в производственной среде

Решение Azure VMware развертывание требует тщательного планирования в различных сферах и часто требует использования нескольких Azure сервисов. Дополнительные сведения см. в разделе нагрузки рабочих процессов Решение Azure VMware в Azure Well-Architected Framework.

Обзор архитектуры надежности

Решение Azure VMware использует гиперконвергентную инфраструктуру (HCI) с кластерами VMware vSphere.

При развертывании Решение Azure VMware развертывается облако private с одним или несколькими кластерами. Каждый кластер содержит узлы ESXi, которые обеспечивают обработку данных, хранилище через виртуальную SAN (vSAN) и сети через VMware NSX. Существует два поколения Решение Azure VMware:

  • 1-го поколения использует специализированное оборудование без операционной системы для узлов и использует выделенные сетевые подходы. Дополнительные сведения о ключевых понятиях см. в разделе Решение Azure VMware концепции частного облака и кластера.

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

Отказоустойчивость

Решение Azure VMware предоставляет несколько механизмов обработки сбоев на уровне инфраструктуры и приложений:

  • VSphere High Availability (HA): vSphere HA отслеживает узлы ESXi и виртуальные машины. Если узел выходит из строя, он автоматически перезапускает затронутые виртуальные машины на исправных узлах. vSphere HA включен по умолчанию и резервирует вычислительные и память ресурсы для сбоя одного узла.

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

  • Сетевая отказоустойчивость: Решение Azure VMware предоставляет избыточные сетевые пути и несколько сетевых адаптеров VMkernel для обработки транзитных сбоев сети.

Устойчивость к временным сбоям

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

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

Для приложений, работающих на виртуальных машинах Решение Azure VMware, реализуйте стандартные методики для обработки временных сбоев:

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

  • Используйте шаблоны разбиения цепи для вызовов внешних служб.

  • Отслеживайте работоспособность приложений и реализуйте корректное снижение производительности.

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

Устойчивость к сбоям зоны доступности

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

Решение Azure VMware первого поколения поддерживает зоны доступности через растянутые кластеры, которые распределяют узлы ESXi между двумя зонами доступности в пределах одного региона. Майкрософт выбирает используемые зоны. Кластер выполняется в конфигурации "активный— активный" в двух зонах, а vSAN также охватывает несколько зон. Можно указать, развертывается ли каждая рабочая нагрузка в одной или двух зонах.

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

Схема, показывающая управляемый растянутый кластер vSAN, охватывающий две зоны доступности и узел-свидетель в третьей зоне доступности.

Стандартный кластер — это кластер, который не растягивается по зонам. В стандартном кластере кластер и все его узлы ESXi считаются незональными или региональными. Незональные кластеры могут размещаться в любой зоне доступности в регионе и Майкрософт выбирает зону. Если в зоне доступности региона происходит сбой, кластеры и узлы, непривязанные к зоне, могут находиться в затронутой зоне и могут столкнуться с простоем.

Решение Azure VMware 2-го поколения поддерживает зональные развертывания частных облаков. При настройке зонального частного облака каждый из его кластеров и всех узлов ESXi развертываются в одной выбранной зоне доступности.

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

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

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

Требования

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

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

  • Модели SKU хоста: Типы хостов AV36, AV36P и AV52 поддерживают растянутые кластеры. SKU AV64 не поддерживает растянутые кластеры.

Соображения

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

Себестоимость

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

Настройка поддержки зоны доступности

  • Развернуть новый кластер: При создании нового частного облака Решение Azure VMware в поддерживаемом регионе его можно настроить как расширенный кластер во время развертывания. Эта конфигурация автоматически распределяет узлы между двумя зонами доступности. Дополнительные сведения см. в статье "Развертывание растянутых кластеров vSAN".

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

  • Развернуть новый кластер: При создании нового частного облака Решение Azure VMware в поддерживаемом регионе можно выбрать его зону доступности.

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

Поведение, когда все зоны работоспособны

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

  • Операция между зонами: Виртуальные машины могут работать на узлах в любой зоне доступности. Вы можете управлять размещением виртуальных машин, используя распределенный планировщик ресурсов vSphere (DRS) и правила аффинности и антиаффинности для оптимизации требований к производительности или доступности.

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

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

  • Операция между зонами: Виртуальные машины выполняются на узлах в зоне доступности кластера.

  • Репликация данных между зонами: Данные не реплицируются в другую зону.

Поведение во время сбоя зоны

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

  • Обнаружение и реагирование: Решение Azure VMware управляет ответом на сбои зоны на уровне инфраструктуры. VSphere HA автоматически обнаруживает сбои зоны и инициирует процедуры перезапуска виртуальной машины при необходимости.

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

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

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

  • Ожидаемая потеря данных: Так как vSAN использует синхронную репликацию между зонами, во время сбоя зоны не ожидается потеря данных.

  • Распространение: vSphere DRS автоматически распределяет рабочие нагрузки виртуальных машин в здоровую зону доступности. Маршрутизация сетевого трафика через VMware NSX автоматически адаптируется к новому размещению виртуальной машины.

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

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

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

  • Ожидаемое время простоя: Если зона недоступна, кластер и его рабочие нагрузки недоступны до восстановления зоны доступности.

  • Ожидаемая потеря данных: Данные в затронутой зоне недоступны до восстановления зоны.

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

Восстановление зоны

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

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

Тестирование на сбои в зоне

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

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

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

Устойчивость к сбоям на уровне региона

Каждый кластер Решение Azure VMware развертывается в одном регионе Azure. Если регион становится недоступным, частное облако и все ресурсы в нем становятся недоступными.

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

Индивидуальные решения для нескольких регионов для повышения устойчивости

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

Ряд вариантов поддерживает различные требования к устойчивости. Дополнительные сведения см. в разделе Disaster recovery solutions for Решение Azure VMware virtual machines.

Резервное копирование и восстановление

Решение Azure VMware автоматически выполняет резервное копирование компонентов управления, таких как vCenter Server, NSX Manager и диспетчер HCX при включении. Чтобы восстановить компоненты из этих резервных копий управления, создайте запрос поддержка Azure.

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

Устойчивость к обслуживанию служб

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

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

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

Соглашение об уровне обслуживания

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

Решение Azure VMware предоставляет различные соглашения об уровне обслуживания доступности для инфраструктуры рабочей нагрузки и для операций управления.

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

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

Связанный контент

  • Last updated on