Надежность в Azure HDInsight

В этой статье описывается поддержка надежности в Azure HDInsight и охватывает зоны доступности и восстановление между регионами и непрерывность бизнес-процессов. Более подробный обзор надежности в Azure см. в статье "Надежность Azure".

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

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

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

Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.

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

Внимание

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

Необходимые компоненты

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

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

  • Необходимо принести собственную базу данных SQL для Ambari DB и внешнее хранилище метаданных, например хранилище метаданных Hive, чтобы можно было настроить эти DOB-объекты в той же зоне доступности.

  • Кластеры HDInsight должны быть созданы с параметром зоны доступности в одном из следующих регионов:

    • Восточная Австралия
    • Южная Бразилия
    • Центральная Канада
    • Центральная часть США
    • Восточная часть США
    • Восточная часть США 2
    • Центральная Франция
    • Центрально-Западная Германия
    • Восточная Япония
    • Республика Корея, центральный регион
    • Северная Европа
    • Центральный Катар
    • Юго-Восточная Азия
    • Центрально-южная часть США
    • южная часть Соединенного Королевства
    • US Gov (Вирджиния)
    • Западная Европа
    • западная часть США 2

Создание кластера HDInsight с использованием зоны доступности

Шаблон Azure Resource Manager (ARM) можно использовать для запуска кластера HDInsight в указанной зоне доступности.

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

   "resources": [
        {
            "type": "Microsoft.HDInsight/clusters",
            "apiVersion": "2021-06-01",
            "name": "[parameters('cluster name')]",
            "location": "East US 2",
            "zones": [
                "1"
            ],
        }
   ]

Проверка узлов в одной зоне доступности между зонами

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

Снимок экрана: сведения о зоне доступности в обзоре кластера.

Получение ответа API:

 [
        {
            "location": "East US 2",
            "zones": [
                "1"
            ],
        }
 ]

Вертикальное увеличение масштаба кластера

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

Миграция зоны доступности

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

Взаимодействие с зонами вниз

Когда зона доступности выходит из строя:

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

Аварийное восстановление между регионами и непрерывность бизнес-процессов

Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с Рекомендации для разработки стратегии аварийного восстановления.

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

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

Аварийное восстановление в географическом регионе с несколькими регионами

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

Оптимизация затрат

Площадь Причина роста затрат Стратегии оптимизации
Хранилище данных Дублирование первичных данных и таблиц в дополнительном регионе Репликация только курированных данных
Исходящий трафик данных За исходящую межрегиональную передачу данных приходится платить. Просмотрите рекомендации по ценам за пропускную способность. Репликация только курированных данных для уменьшения объема исходящего трафика региона
Вычислительные ресурсы кластеров Дополнительные кластеры HDInsight в дополнительном регионе Используйте автоматизированные сценарии для развертывания дополнительных вычислительных ресурсов после сбоя основного ресурса. Используйте автомасштабирование для поддержания минимально необходимого размера вторичного кластера. Используйте более дешевые SKU виртуальных машин. Создавайте вторичные кластеры в регионах, где могут предоставляться скидки на SKU виртуальных машин.
Проверка подлинности Сценарии с несколькими устройствами в дополнительном регионе требуют дополнительных настроек доменных служб Microsoft Entra Избегайте многопользовательских установок в дополнительном регионе.

Оптимизация сложности

Площадь Причина роста сложности Стратегии оптимизации
Шаблоны чтения и записи Требование доступа для чтения и записи и в основном, и в дополнительном регионах Создайте дополнительный регион с доступом только для чтения.
Нулевые RPO и RTO Требование нулевой потери данных (RPO = 0) и нулевого времени простоя (RTO = 0) Разработайте RPO и RTO таким образом, чтобы уменьшить количество компонентов, для которых необходима отработка отказа. Дополнительные сведения о RTO и RPO см. в целях восстановления.
Бизнес-функциональность Требование полной бизнес-функциональности основного региона в дополнительном регионе Оцените, можете ли вы работать с минимальным критически важным подмножеством бизнес-функций в дополнительном регионе.
Подключение Требование, чтобы все восходящие и нисходящие системы из основного региона подключались также и в дополнительном регионе Ограничьте подключение в дополнительном регионе минимальным критически важным подмножеством.

При создании плана аварийного восстановления в нескольких регионах рассмотрите следующие рекомендации.

  • Определите минимальные бизнес-функции, необходимые при возникновении аварии и почему. Например, оцените, нужны ли вам возможности отработки отказа для слоя преобразования данных (выделен желтым) и слоя обслуживания данных (выделен синим) или вам нужна отработка отказа только для слоя службы данных.

    Слои преобразования данных и обслуживания данных

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

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

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

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

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

Обнаружение сбоев, уведомление и управление

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

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

Аварийное восстановление в географическом регионе с одним регионом

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

  • Вычислительные ресурсы (виртуальные машины): кластер Azure HDInsight. HDInsight предлагает соглашение об уровне обслуживания с уровнем доступности 99,9 %. Чтобы обеспечить высокий уровень доступности в одном развертывании, HDInsight сопровождается многими службами, которые по умолчанию находятся в режиме высокой доступности. Механизмы отказоустойчивости в HDInsight предоставляются службами высокой доступности из экосистемы Майкрософт и Apache OSS.

    Следующие компоненты инфраструктуры предназначены для обеспечения высокой доступности:

    • Активный и резервный узлы Headnode
    • Несколько узлов шлюза
    • Три узла Zookeeper Quorum
    • Рабочие узлы, распределенные по доменам сбоя и обновления

    Следующие службы также предназначены для обеспечения высокой доступности.

    • Сервер Apache Ambari
    • Серверы временной шкалы приложения для YARN
    • Сервер журнала заданий для Hadoop MapReduce
    • Apache Livy
    • HDFS
    • YARN Resource Manager
    • HBase Master

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

  • Хранилища метаданных: База данных SQL Azure. HDInsight использует Базу данных SQL Azure в качестве хранилища метаданных, что обеспечивает соглашение об уровне обслуживания 99,99 %. Три реплики данных хранятся в центре обработки данных с синхронной репликацией. В случае потери реплики другая реплика обслуживается без проблем. Активная георепликация стандартно поддерживается максимум с четырьмя центрами обработки данных. При отработке отказа вручную или в центре обработки данных первый реплика в иерархии автоматически становится доступным для чтения и записи. Дополнительные сведения см. в разделе Непрерывность бизнес-процессов и База данных SQL Azure.

  • служба хранилища: Azure Data Lake 2-го поколения или хранилище BLOB-объектов. HDInsight рекомендует в качестве базового слоя хранилища Azure Data Lake Storage 2-го поколения. Служба хранилища Azure, включая Azure Data Lake Storage 2-го поколения, предоставляет соглашение об уровне обслуживания 99,9 %. HDInsight использует службу LRS, в которой три реплики данных сохраняются в центре обработки данных, а репликация выполняется синхронно. При потере реплики другая реплика обслуживается без проблем.

  • Проверка подлинности: идентификатор Microsoft Entra, доменные службы Microsoft Entra, корпоративный пакет безопасности.

    • Идентификатор Microsoft Entra предоставляет соглашение об уровне обслуживания 99,9 %. Active Directory — это глобальная служба с несколькими уровнями внутренней избыточности и возможностью автоматического восстановления. Дополнительные сведения см. в том, как корпорация Майкрософт постоянно улучшает надежность идентификатора Microsoft Entra.
    • Доменные службы Microsoft Entra предоставляют соглашение об уровне обслуживания 99,9 %. Доменные службы Microsoft Entra — это высокодоступная служба, размещенная в глобально распределенных центрах обработки данных. Наборы реплик — это предварительная версия функции в доменных службах Microsoft Entra, которая обеспечивает географическое аварийное восстановление, если регион Azure переходит в автономный режим. Дополнительные сведения см. в разделе реплика наборов концепций и функций для доменных служб Microsoft Entra, чтобы узнать больше.
    • Azure DNS предоставляет соглашение об уровне обслуживания 100 %. HDInsight использует Azure DNS в различных местах для разрешения доменных имен.
  • Необязательные службы, такие как Azure Key Vault и Фабрика данных Azure.

Компоненты HDInsight