Как автоматизировать администрирование Hadoop, чтобы не было мучительно больно

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Хабр! Меня зовут Александр Черемухин, я тимлид администраторов Hadoop в Big Data МТС. Мы прошли довольно длинный эволюционный путь в автоматизации администрирования и хотелось бы им поделиться с сообществом. Возможно наш опыт пригодится и другим специалистам, работающим с Hadoop.


Примечание: об этом решении Саша рассказал на прошедшем митапе администраторов Hadoop, если вам больше нравится формат видео — смотрите его тут. Ну а если вам ближе текст — читайте дальше.

Общая картина

Все это время мы использовали (и используем пока что) дистрибутив HDP (Hortonworks Data Platform). Исторически у нас есть версия 2.6.5, то есть вторая ветка, и все новые установки у нас уже установлены на версии 3.

Есть тут и свои особенности. Например у нас есть кластеры как на baremetal, большие прод-кластера мы все запускаем на «железе» и кластеры в облаке (OpenStack), которые мы используем либо для каких-то тестовых установок.

Как было изначально

Когда Big Data МТС только начиналась, кластеры в большей степени устанавливались вручную. Даже несмотря на то, что дистрибутив HDP предоставляет довольно мощные средства администрирования кластеров в виде Ambari.

Если детальнее, то установка кластеров ранее выглядела так: Сначала настраивалось все окружение на нодах в виде Java, PostgreSQL, настраивались хостнеймы и так далее, подкручивались системные настройки. Затем (опять же вручную) настраивался репозиторий (мы используем Artifactory в качестве кэширующих репозиториев), после чего ставились Ambari Server и Ambari Agents.

Ambari состоит из Ambari Server и Ambari Agents, которые ставятся на каждую ноду кластера. Собственно, Ambari Agent и управляет непосредственно нодой и сервисом HDP, который на ней находится.

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

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

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

Автоматизируй это

Нас эти сложности утомили, и мы решили разработать инструмент для автоматизированной раскатки кластеров. Название нашлось само собой — HDP Install, простое, но зато сразу понятно о чем речь. HDP Install — это программа написанная на Go c использованием Ansible, которая является своеобразным оркестратором и валидатором конфигов, которые мы подаем на вход. Под капотом используются на всех этапах (о которых чуть ниже) ansible-playbook и ansible-roles.

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

В результате полного цикла работы HDP Install мы получаем уже готовый работающий кластер с установленным окружением – JDK, PostgreSQL, настроенные дата-сорсы для Ranger, например, для Hive Metastore, для того же самого Ambari и так далее. Кроме того, готовый кластер уже настроен для нашей инфраструктуры, то есть это произведена интеграция с LDAP, Active Directory и так далее.

Как работает HDP Install

Дальше расскажу сколько этапов работы удалось «упаковать» в наше решение.

  1. Prechecks. На этом этапе происходит проверка конфигурации оси, «железа», доступности репозиториев (например будет обнаружена сетевая связанность). Проверяются маунт-пойнты (например на дата-нодах), правильность прописывания всех хостнеймов, чтобы все было по FQDN и т.д. Если по какой-либо причине пречеки валятся, мы можем потом их перезапустить. А вообще каждый этап работы HDP Install может быть запущен с произвольного шага.

  2. Common. На данном этапе идет установка пререквизитов в виде JDK, подтягивания сертификатов, настройка /etc/hosts и прочие необходимые пререквизиты, которые рекомендуются как Hortonworks (теперь это Cloudera), так и в целом необходимы для функционирования Hadoop как такового.

  3. Data Sources. На этапе настройки дата-сорсов идет установка PostgreSQL, а также прописывание баз данных и схем для Ambari DB, Hive Metastore DB, Ranger DB. ]

  4. Ambari. Здесь мы уже подходим непосредственно к установке кластера, раскатываются Ambari Server на управляющую, менеджмент-ноду и Ambari Agents на все остальные ноды кластера. После чего посредством использования Ambari API происходит установка наших компонентов, которые были ранее описаны в нашем конфиг-файле YAML.

  5. HDP. Это, наверное, самый длинный этап, в котором происходит раскатка всех компонентов, а также керберизация, если это необходимо (в наших реалиях это всегда необходимо, все наши кластер керберизированы).

  6. Postconf. Заключительный этап, в котором на основании ранее заполненного конфиг-файла прописываются необходимые параметры, базовые хипы для Hive, Name Node, Data Node так далее, интеграция с LDAP и прочие базовые конфиги, которые необходимы для функционирования.

Profit!

В результате мы получаем работающий кластер, у которого (благодаря использованию HDP Install) есть следующие плюсы:

  • Переиспользуемость. Уже успешную, зарекомендовавшую себя конфигурацию мы можем использовать повторно, раскатав, либо на новом «железе» (по требованию), либо в OpenStack. Тут же мы получаем и возможность автоматизации подъема кластеров в облаке.

  • Повторяемость конфигурации. Мы можем хранить ее, например, в Git и отдавать продуктам Big Data для какого-то использования. Опять-таки, любой продукт Big Data может взять HDP Install, и воспользоваться им для раскатки своего какого-нибудь тестового или dev-кластера.

  • Минимизация ручного труда и человеческого фактора. Для нас это пожалуй самый большой плюс, ведь с HDP Install сложнее ошибиться.

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

Катим кластер на прод

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

На этой схеме мы в центре видим как раз только что установленный HDP-кластер, который мы сделали с помощью HDP Install.
На этой схеме мы в центре видим как раз только что установленный HDP-кластер, который мы сделали с помощью HDP Install.

В эту инфраструктуру входят:

  • Мониторинг нас есть целый ряд разработанных нами экспортеров для Prometheus, который мы используем для мониторинга. Также мы используем такие экспортеры, как GMX Exporter, практически на все важные компоненты кластера.

  • filebeat — для отправки логов ELK.

  • Разработанные нами системы бэкапов, например, бэкап fsimage.

  • Ряд пререквизитов в виде, например, Python virtualenvs — для того чтобы наши дата-инженеры, дата-сайентисты могли комфортно работать и выполнять свои задачи.

  • Кейтабы для Kerberos разложенные по дата-нодам и по эйч-нодам — для того чтобы регламентные задачи могли отрабатывать.

  • Ряд задач требует другие версии Spark, не только 2.3.2 (которая входит в стек HDP), а еще и Spark 2.4.4, это тоже должно присутствовать рядом с кластером.

  • Кроме того, нужна вменяемая система конфигурирования настроек именно самого кластера, потому что лезть каждый раз в Ambari для того чтобы руками подтюнить какой-то параметр — это не дело.

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

Что за пайплайны для кластеров?

Пайплайн представляет из себя, Git-репозиторий для каждого кластера (мы используем GitLab), который содержит в себе blueprint.json, в котором находятся параметры этого кластера. Кроме того, есть отдельный репозиторий Common, который содержит в себе единый blueprint универсальных настроек для кластера. Мы стараемся стандартизировать все наши ноды, поэтому такие вещи, как, например, пути на дата-нодах до файлов HDFS, или пути до YARN или до юзер-кэшей - прописаны в Common. Какие-то базовые, не меняющиеся настройки хипов, тоже прописаны там.

Топология кластера описывается в специальном файлике inventory.ini, в котором все ноды типизированы по функционалу — по нейм-нодам, дата-нодам, Kafka-нодам и так далее.

Для того чтобы прокидывать настройки, прописанные в blueprint, до кластера, мы разработали небольшую утилиту и назвали ее ambacfg, (Ambari-конфигурирование), которая валидирует, парсит blueprint, вычленяет из него обновленные настройки и применяет их на кластере через API.

Пайплайны, имеют функционал раскатки необходимого окружения на серверы. Например если где-то забыли установить JDK, то он будет раскатан. Если нам необходима установка какого-нибудь дополнительного virtualenv по требованию дата-инженеров, то мы прописываем это в настройках пайплайна, и этот virtualenv будет раскатан на всех нодах, где его до сих пор не было.

Для всего этого мы используем Jenkins, и Ansible «под капотом». Все хранится в Git, что дает нам очень много бонусов, и flow его выглядит как на картинке ниже. Например, нам захотелось увеличить heapsize Hive-сервера. В любой непонятной ситуации увеличивай heapsize, ага.

Мы делаем новую ветку в Git, вносим в нее изменения, допустим, мы увеличили heap Hive-сервера, после чего создается merge request, кто-нибудь из нашей команды или несколько человек ревьюит этот merge request, и апрувит, если все хорошо, после чего происходит commit master, и пайплайн побежал автоматически.

Этот пример, конечно, очень простой, и показывает собственно работу ambacfg, когда он берет новую настройку из blueprint, вычленяет ее и применяет на кластере. Здесь можно применять не только настройки кластера, но и всего окружения. Предположим, какой-то другой команде Big Datа потребовалось новое Python-окружение — они могут сделать нам merge request с описанием того что им нужно (версия Python, пакеты), мы его ревьюим, если все хорошо то подтверждаем и пайплайн “побежал”.

Или другой пример, предположим у нас появилась новая техучетка, под которой должны бежать какие-то новые регламентные процессы. Команда продукта может в наш корпоративный Vault, который мы используем для всех реденшенов, залить свой keytab-файл, залить нам merge request на раскатку этого keytab-файла, keytab-файл после коммита в мастер — побежит.

Как работает пайплайн

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

  • Первый этап – тесты. Здесь происходит валидация корректности всех настроек. Если blueprint или конфиг по каким-то причинам сломался — тесты не пройдут.

  • Configure — применение настроек Common и настроек конкретного кластера. На данном этапе вначале применяются настройки кластера из blueprint репозитория Common, после чего применяются настройки конкретного кластера, который бежит в данный момент.

  • Prechecs — это проверка окружения именно со стороны операционной системы, доступность репозиториев, корректность хостнеймов, есть ли все маунт-пойнты, и все такое прочее.

  • Prepare — установка зависимостей, Java, Kerberos, при необходимости накатка каких-то RPM-пакетов и так далее. Это всегда будет раскатано автоматически на всех новых нодах, которые мы добавляем.

  • Deploy — установка сопутствующего ПО, которое необходимо уже нам. Это Prometheus для мониторинга, filebeat для ELK и HA Proxy для обеспечения high availability некоторых сервисов (например Ranger).

  • Postconf — конфигурирование этих компонентов. Здесь происходит раскатка конфигов для filebeat, для GMX-экспортеров и так далее.

  • После чего происходит последний, пользовательский шаг — раскатка необходимых virtualenvs для Python.

После прокатки этого пайплайна, мы можем быть уверены, что необходимые компоненты HDP раскатаны и указаны все необходимые нам конфиги самого Hadoop и HDP, а все дата-ноды, эйч-ноды и остальные ноды кластера приведены в нужное состояние. Версия JDK соответствует, все нужные экспортеры разложены, filebeats разложены с нужной конфигурацией и так далее.

Польза пайплайнов

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

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

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

Итоги

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

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

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

Источник: https://habr.com/ru/company/ru_mts/blog/569762/

Интересные статьи

Интересные статьи

Выгрузка пользователей из 1C ЗУП в Битрикс24 или правдивая история о том как настроить интеграцию 1С-Битрикс24 с ЗУП без 1С-ника.В жизни так бывает, причём бывает чаще чем хотелось бы, хоть в целом и ...
Жить в режиме бесконечного цейтнота как минимум грустно, а как максимум — вредно для здоровья. Пропустив дедлайн по одной задаче, ты двигаешь все остальные и в итоге пост...
Я давно знаком с Битрикс24, ещё дольше с 1С-Битрикс и, конечно же, неоднократно имел дела с интернет-магазинами которые работают на нём. Да, конечно это дорого, долго, местами неуклюже...
С вопросом корректности в англоязычных странах всегда все сложно. Потому что существует куча неписанных правил, когда нужно обращаться формально, а когда можно позволить себе небольши...
На Хабре много статей про поиск работы, собеседования, составление грамотного резюме, переезды и т.д. Но совсем почти не освещен такой вопрос как процесс увольнения. Как вести себя при увольнении...