Надежность в Виртуальные машины Azure

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

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

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

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

Для получения дополнительной информации о развертывании виртуальных машин для поддержки требований к надежности решения и о том, как надежность влияет на другие аспекты вашей архитектуры, см. Architecture best practices for Виртуальные машины and scale sets in the #REF! Well-Architected Framework.

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

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

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

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

• Region: Можно выбрать регион #REF!/c1, в котором должна работать виртуальная машина. Регион — это географическая область, которая может содержать несколько центров обработки данных, каждый из которых включает большое количество хостов.

• Availability zone:Availability zone являются физически отдельными группами центров обработки данных в каждом регионе #REF!. В регионах, поддерживающих зоны доступности, можно выбрать зону, в которой выполняется виртуальная машина. Дополнительные сведения см. в разделе "Устойчивость к сбоям зоны доступности".

• Availability set: Группа доступности — это логическая группировка виртуальных машин, которая позволяет #REF! понять, как приложение создано для обеспечения избыточности и доступности.

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

  Группы доступности также могут размещать разные виртуальные машины в различных доменах обновления, которые определяют, как платформа #REF! развертывает обновления платформы. С помощью доменов обновления можно убедиться, что одновременно перезапускается только подмножество виртуальных машин для обновлений.

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

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

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

Дополнительные сведения о доступности виртуальных машин см. в разделе Параметры доступности для виртуальных машин.

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

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

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

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

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

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

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

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

Требования

Поддержка региона: Зональные виртуальные машины можно развернуть в любом регионе, поддерживающем зоны доступности.

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

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

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

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

Между стоимостью зональной и незональной виртуальной машины нет разницы.

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

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

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

  • Создание виртуальных машин в зоне доступности с помощью портала #REF!
  • Создание виртуальной машины в зоне доступности с помощью Azure CLI
  • Создание виртуальной машины в зоне доступности с помощью Azure PowerShell

• Преобразуйте существующие виртуальные машины в зональную конфигурацию. Вы можете перейти от незональной виртуальной машины к зональной виртуальной машине. Этот процесс создает новую виртуальную машину в целевой зоне доступности и требует, чтобы виртуальная машина была остановлена во время процесса перемещения. Дополнительные сведения см. в разделе Перемещение виртуальных машин #REF! одного экземпляра из региональных зон доступности в целевые зональные зоны.

• Измените зону доступности существующей зональной виртуальной машины. Зональные виртуальные машины нельзя переместить в другую зону доступности. Вместо этого необходимо развернуть новую зональную виртуальную машину в требуемой зоне доступности.

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

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

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

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

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

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

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

• Обнаружение и ответ: Вы несете ответственность за обнаружение и реагирование на сбои зоны, влияющие на виртуальные машины.

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

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

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

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

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

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

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

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

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

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

Вы можете использовать Azure Chaos Studio для имитации потери виртуальной машины в рамках эксперимента. #REF! предоставляет встроенные ошибки для виртуальных машин, включая возможность завершения работы виртуальной машины. Эти возможности можно использовать для имитации сбоев на уровне зоны и тестирования процессов переключения на резервные ресурсы.

Кастомные мультизональные решения для обеспечения устойчивости

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

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

Вы можете рассмотреть возможность использования зонально-то зонального аварийного восстановления Azure Site Recovery (DR), если ваше приложение работает в одной зоне за раз и если вам не требуется практически мгновенное переключение на резервный сайт между зонами. Аварийное восстановление между зонами имеет некоторые важные ограничения, поэтому тщательно изучите ваши требования.

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

Виртуальные машины — это однорегиональные ресурсы. Если регион становится недоступным, виртуальная машина также недоступна.

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

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

Site Recovery — это служба, которая обеспечивает аварийное восстановление путем репликации виртуальных машин и их данных в дополнительный регион. Вы можете выбрать почти любой регион #REF! в качестве вторичного региона, в том числе сочетания несгруппированных регионов. Дополнительные сведения см. в разделе архитектуре аварийного восстановления #REF!-#REF!.

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе "Гостевые обновления" и обзор обслуживания узла.

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

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

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

Резервное копирование также поддерживает диски, подключенные к виртуальным машинам. Дополнительные сведения см. в разделе Обзор резервного копирования дисков #REF!.

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

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

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

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

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

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

• Виртуальные машины в #REF!
• Масштабируемые наборы виртуальных машин

Связанный ресурс

• Надежность в #REF!