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


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

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

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

Внимание

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

Предварительные условия

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

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

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

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

    • Восточная Австралия
    • Южная Бразилия
    • Центральная Канада
    • Центральная часть США
    • Восточная часть США
    • Восточная часть США 2
    • Центральная Франция
    • Центрально-Западная Германия
    • Восточная Япония
    • Республика Корея, центральный регион
    • Северная Европа
    • Центральный Катар
    • Юго-Восточная Азия
    • Центрально-южная часть США
    • южная часть Соединенного Королевства
    • Правительство США, Вирджиния
    • Западная Европа
    • западная часть США 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 в настоящее время не поддерживают миграцию существующих экземпляров кластера для поддержки зон доступности. Однако вы можете повторно создать кластер и выбрать другую зону доступности или регион во время создания кластера. Вторичный резервный кластер в другом регионе и другой зоне доступности можно использовать в сценариях аварийного восстановления.

Опыт зонирования вниз

Когда зона доступности перестает работать

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

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

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

Для восстановления после сбоя компания Microsoft использует модель общей ответственности. В этой модели корпорация Майкрософт гарантирует, что доступны базовые инфраструктуры и службы платформы. Однако многие службы Azure не делают автоматической репликации данных и не обеспечивают возврат из вышедшего из строя региона для перекрестной репликации в другой доступный регион. Для этих услуг вы отвечаете за настройку плана аварийного восстановления, который подходит для вашей рабочей нагрузки. Большинство служб, работающих на платформе 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.

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

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

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

    • Сервер Apache Ambari
    • Серверы временной линии приложения для YARN
    • Сервер журнала заданий для Hadoop MapReduce
    • Apache Livy
    • HDFS (распределенная файловая система Hadoop)
    • YARN Resource Manager (Менеджер ресурсов YARN)
    • HBase Master

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

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

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

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

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

Компоненты HDInsight