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

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

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

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

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

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

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

1-го поколения использует специализированное оборудование без операционной системы для узлов и использует выделенные сетевые подходы. Дополнительные сведения о ключевых понятиях см. в статье о частных облаках и кластерах решения Azure VMware.
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, реализуйте стандартные методы обработки временных ошибок:

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

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

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

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

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

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

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

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

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

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

Требования

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

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

Соображения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

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

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

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

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

Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

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

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

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

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

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

Вы можете имитировать сбои зоны следующими способами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-02-19