Службы высокого уровня доступности, поддерживаемые Azure HDInsight
Чтобы обеспечить оптимальный уровень доступности для компонентов аналитики, решение HDInsight было разработано на основе уникальной архитектуры, которая обеспечивает высокую доступность (HA) критически важных служб. Корпорация Майкрософт разработала некоторые компоненты этой архитектуры, чтобы обеспечить автоматическую отработку отказа. Другие компоненты — это стандартные компоненты Apache, которые развертываются для поддержки конкретных служб. В этой статье описывается архитектура модели службы высокой доступности в HDInsight, способ поддержки отработки отказа для служб HA и рекомендации по восстановлению после других прерываний работы служб.
Примечание.
Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.
Инфраструктура высокой доступности
HDInsight предоставляет настраиваемую инфраструктуру, которая обеспечивает высокий уровень доступности четырех основных служб с возможностью автоматического перехода на другой ресурс.
- Сервер Apache Ambari
- Сервер временной шкалы приложения для Apache YARN
- Сервер журнала заданий для Hadoop MapReduce
- Apache Livy
Эта инфраструктура состоит из множества служб и компонентов программного обеспечения, некоторые из которых разработаны корпорацией Майкрософт. Следующие компоненты являются уникальными для платформы HDInsight:
- ведомый контроллер отработки отказа,
- ведущий контроллер отработки отказа,
- ведомая служба высокого уровня доступности,
- ведущая служба высокого уровня доступности.
Существуют также другие службы высокого уровня доступности, которые поддерживаются компонентами Apache с открытым кодом. Эти компоненты также присутствуют в кластерах HDInsight:
- Hadoop File System (HDFS) NameNode
- YARN ResourceManager
- HBase Master
В следующих разделах содержатся дополнительные сведения о том, как эти службы работают вместе.
Службы высокого уровня доступности HDInsight
Корпорация Майкрософт предоставляет поддержку четырех служб Apache, перечисленных в следующей таблице в кластерах HDInsight. Чтобы отличить их от служб высокого уровня доступности, поддерживаемых компонентами Apache, они называются службами высокого уровня доступности HDInsight.
| Service | Узлы кластера | Типы кластера | Характер использования |
|---|---|---|---|
| Сервер Apache Ambari | Активный головной узел | Все | Отслеживает кластер и управляет им. |
| Сервер временной шкалы приложения для Apache YARN | Активный головной узел | Все, кроме Kafka | Хранит сведения об отладке заданий YARN, выполняющихся в кластере. |
| Сервер журнала заданий для Hadoop MapReduce | Активный головной узел | Все, кроме Kafka | Поддерживает данные отладки для заданий MapReduce. |
| Apache Livy | Активный головной узел | Spark | Обеспечивает простое взаимодействие с кластером Spark через интерфейс RESTFUL |
Примечание.
Кластеры Корпоративного пакета безопасности (ESP) HDInsight в настоящее время обеспечивают высокий уровень доступности только для сервера Ambari. Сервер временной шкалы приложения, сервер журнала заданий и Livy работают только в headnode0 и не переключаются на headnode1 при отработке отказа Ambari. База данных временной шкалы приложения также находится на узле headnode0, а не на сервере Ambari SQL.
Архитектура
Каждый кластер HDInsight имеет два головных узлах в активном и резервном режимах соответственно. Службы HDInsight HA выполняются только на головных узлах. Эти службы всегда должны выполняться на активном головном узле, а останавливаться и переводиться в режим обслуживания на резервном головном узле.
Чтобы обеспечить правильное состояние служб HA и обеспечить быструю отработку отказа, HDInsight использует Apache ZooKeeper, который является службой координации для распределенных приложений, для проведения активных выборов головного узла. HDInsight также предоставляет несколько фоновых процессов Java, которые координируют процедуру отработки отказа для служб HDInsight HA. Эти службы: главный контроллер отработки отказа, контроллер отработки отказа в подчиненном режиме, главный ха-служба и служба slave-ha-ha-service.
Apache ZooKeeper
Apache ZooKeeper — это высокопроизводительная служба координации для распределенных приложений. В рабочей среде ZooKeeper обычно выполняется в реплика режиме, где реплика оделенная группа сервера ZooKeeper формирует кворум. Каждый кластер HDInsight имеет три узла ZooKeeper, которые позволяют трем серверам ZooKeeper формировать кворум. В HDInsight есть два кворума ZooKeeper, параллельно взаимодействующих друг с другом. Один кворум решает активный головной узел в кластере, на котором должны выполняться службы HDInsight HA. Другой кворум используется для координации служб высокой доступности, предоставляемых Apache, как описано в последующих разделах.
ведомый контроллер отработки отказа,
Ведомый контроллер отработки отказа выполняется на каждом узле в кластере HDInsight. Этот контроллер отвечает за запуск агента Ambari и slave-ha-service на каждом узле. Он периодически опрашивает первый кворум ZooKeeper об активном головном узле. При изменении активных и резервных головных головок контроллер отработки отказа в подчиненном режиме выполняет следующие действия:
- обновляет файл конфигурации узла;
- перезапускает агент Ambari.
Ведомая служба slave-ha-service отвечает за остановку служб HDInsight HA (кроме сервера Ambari) в резервном головном узле.
ведущий контроллер отработки отказа,
Ведущий контроллер отработки отказа работает на обоих головных узлах. Оба ведущих контроллера отработки отказа взаимодействуют с первым кворумом ZooKeeper, чтобы назначить головной узел, на котором они выполняются в качестве активного головного узла.
Например, если ведущий контроллер отработки отказа на головном узле 0 выиграл, будут выполнены следующие изменения.
- Головной узел 0 становится активным.
- Ведущий контроллер отработки отказа запускает сервер Ambari и службу master-ha-service на головном узле 0.
- Другой ведущий контроллер отработки отказа останавливает сервер Ambari и службу master-ha-service на головном узле 1.
Служба master-ha-service работает только на активном головном узле, она останавливает службы HDInsight HA (кроме сервера Ambari) на резервном головном узле и запускает их на активном головном узле.
Процесс отработки отказа
Монитор работоспособности работает на каждом головном узле, а также на ведущем контроллере отработки отказа, чтобы отправлять уведомления о пульсе в кворум ZooKeeper. В этом сценарии головной узел считается службой HA. Монитор работоспособности проверяет, является ли каждая служба высокой доступности работоспособной и готова ли она к работе по определению лидера. Если да, этот головной узел конкурирует на выборах. Если нет, он выходит из выборов до тех пор, пока он не станет готов снова.
Если резервный головной узел когда-либо достигает лидерства и становится активным (например, в случае сбоя с предыдущим активным узлом), его главный контроллер отработки отказа запускает все службы высокой доступности HDInsight на нем. Главный контроллер отработки отказа останавливает эти службы на другом головном узле.
В случае сбоев службы HDInsight HA, например при сбое или неработоспособности, ведущий контроллер отработки отказа должен автоматически перезапускать или прекращать работу служб в соответствии с состоянием головного узла. Пользователям не следует вручную запускать службы HDInsight на обоих головных узлах. Вместо этого нужно разрешить переход на другой ресурс автоматически или вручную, чтобы помочь восстановить службу.
Случайное вмешательство вручную
Службы ВЫСОКОЙ доступности HDInsight должны выполняться только на активном головном узле и автоматически перезапускаться при необходимости. Поскольку отдельные службы высокой доступности не имеют собственного монитора работоспособности, отработка отказа не может быть активирована на уровне отдельной службы. Отработка отказа обеспечивается на уровне узла, а не на уровне службы.
Известные проблемы
При запуске службы высокой доступности вручную на резервном головном узле она не будет останавливаться до следующей отработки отказа. Когда службы HA выполняются на обоих головных узлах, могут возникнуть следующие проблемы: недоступность пользовательского интерфейса, ошибки вызова исключений Ambari, зависание заданий YARN, Spark и Oozie.
Когда служба высокой доступности на активном головном узле останавливается, она не перезапускается, пока не произойдет следующая отработка отказа или перезапустится ведущий контроллер отработки отказа/master-ha-service. Когда одна или несколько служб HA останавливаются на активном головном узле, особенно когда останавливается сервер Ambari, пользовательский интерфейс Ambari становится недоступен, а также могут возникнуть другие проблемы, например сбои в выполнении заданий YARN, Spark и Oozie.
Службы высокого уровня доступности Apache
Apache обеспечивает высокий уровень доступности для HDFS NameNode, YARN ResourceManager и HBase Master, которые также доступны в кластерах HDInsight. В отличие от служб HDInsight HA, они поддерживаются в кластерах ESP. Службы Apache HA взаимодействуют со вторым кворумом ZooKeeper (описанным в предыдущем разделе), чтобы выбрать активные/резервные состояния и выполнить автоматический перенос на другой ресурс. В следующих разделах подробно описано, как работают эти службы.
Hadoop Distributed File System (HDFS) NameNode
Кластеры HDInsight на основе Apache Hadoop 2.0 или более поздней версии обеспечивают высокий уровень доступности NameNode. На головных узлах, которые настроены для автоматического перехода на другой ресурс, выполняются два NameNodes. NameNodes используют ZKFailoverController для взаимодействия с ZooKeeper, чтобы определить состояние "активно/в ожидании". ZKFailoverController выполняется в обоих головных узлах и работает так же, как главный контроллер отработки отказа.
Второй кворум ZooKeeper не зависит от первого кворума, поэтому активный NameNode может не работать на активном головном узле. Если активный NameNode неисправен или неработоспособен, резервный NameNode выигрывает выборы и становится активным.
YARN ResourceManager
Кластеры HDInsight на основе Apache Hadoop 2.4 или более поздней версии поддерживают высокий уровень доступности YARN ResourceManager. Существует два ResourceManager, RM1 и RM2, которые выполняются на головном узле 0 и головном узле 1 соответственно. Как и NameNode, YARN ResourceManager YARN также настроен для автоматического перехода на другой ресурс. Другой ResourceManager автоматически выбирается для работы в качестве активного при отключении или отсутствии отклика текущего активного ResourceManager.
YARN ResourceManager использует внедренный ActiveStandbyElector в качестве средства обнаружения сбоев и определения лидера. В отличие от HDFS NameNode, для YARN ResourceManager не требуется отдельная управляющая программа ZKFC. Активный ResourceManager записывает свои состояния в Apache ZooKeeper.
Высокий уровень доступности ResourceManager YARN не зависит от NameNode и других служб HDInsight HA. Активный ResourceManager может не работать на активном головном узле или головном узле, где запущен активный NameNode. Дополнительные сведения о высокой доступности YARN ResourceManager см. в статье Высокий уровень доступности ResourceManager.
HBase Master
Кластеры HDInsight HBase поддерживают высокий уровень доступности HBase Master. В отличие от других служб высокого уровня доступности, которые выполняются на головных узлах, образцы HBase Master выполняются на трех узлах ZooKeeper, где один является активным, а два других находятся в режиме ожидания. Как и в NameNode, HBase Master координирует работу с Apache ZooKeeper для определения лидера и выполняет автоматический переход на другой ресурс, если на текущем активном хозяине возникают проблемы. В любой момент времени существует только один активный HBase Master.
Следующие шаги
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по