Как автоматизировать администрирование 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
Дальше расскажу сколько этапов работы удалось «упаковать» в наше решение.
Prechecks. На этом этапе происходит проверка конфигурации оси, «железа», доступности репозиториев (например будет обнаружена сетевая связанность). Проверяются маунт-пойнты (например на дата-нодах), правильность прописывания всех хостнеймов, чтобы все было по FQDN и т.д. Если по какой-либо причине пречеки валятся, мы можем потом их перезапустить. А вообще каждый этап работы HDP Install может быть запущен с произвольного шага.
Common. На данном этапе идет установка пререквизитов в виде JDK, подтягивания сертификатов, настройка /etc/hosts и прочие необходимые пререквизиты, которые рекомендуются как Hortonworks (теперь это Cloudera), так и в целом необходимы для функционирования Hadoop как такового.
Data Sources. На этапе настройки дата-сорсов идет установка PostgreSQL, а также прописывание баз данных и схем для Ambari DB, Hive Metastore DB, Ranger DB. ]
Ambari. Здесь мы уже подходим непосредственно к установке кластера, раскатываются Ambari Server на управляющую, менеджмент-ноду и Ambari Agents на все остальные ноды кластера. После чего посредством использования Ambari API происходит установка наших компонентов, которые были ранее описаны в нашем конфиг-файле YAML.
HDP. Это, наверное, самый длинный этап, в котором происходит раскатка всех компонентов, а также керберизация, если это необходимо (в наших реалиях это всегда необходимо, все наши кластер керберизированы).
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.
В эту инфраструктуру входят:
Мониторинг — нас есть целый ряд разработанных нами экспортеров для 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 и наведет их на мысли по разработке своих инструментов.
