Настройка Ganglia для небольшого кластера Hadoop и устранение неполадок

Ganglia — это масштабируемая и распределенная система мониторинга с открытым исходным кодом для больших кластеров. Он собирает, агрегирует и предоставляет представления временных рядов десятков связанных с машиной показателей, таких как процессор, память, память, использование сети. Вы можете увидеть Ganglia в действии на UC Berkeley Grid .

Ganglia также является популярным решением для мониторинга кластеров Hadoop и HBase, поскольку Hadoop (и HBase) имеет встроенную поддержку для публикации своих метрик в Ganglia. С Ganglia вы можете легко увидеть количество байтов, записанных конкретным датодетом HDSF с течением времени, коэффициент попадания в кэш блоков для данного сервера региона HBase, общее количество запросов к кластеру HBase, время, потраченное на сборку мусора, и многие, многие другие.

Обзор основных ганглиев

Ганглии состоят из трех компонентов:

• Демон мониторинга Ganglia (gmond) — демон, который должен работать на каждом отслеживаемом узле. Он собирает локальные показатели мониторинга и объявляет их, а также (если настроено) получает и объединяет показатели, отправленные ему из othergmond.
  с (и даже от себя).
• Мета-демон Ganglia (gmetad) — демон, который периодически запрашивает один или несколько источников данных (источник данных может быть agmond или othergmetad) для получения и агрегирования текущих метрик. Агрегированные результаты хранятся в базе данных и могут быть экспортированы в виде XML другим клиентам — например, веб-интерфейсу.
• Веб-интерфейс Ganglia PHP — он извлекает объединенные метрики из мета-демона и отображает их в виде красивых динамических HTML-страниц, содержащих различные графики в реальном времени.

Если вы хотите узнать больше о gmond, gmetad и веб-интерфейсе, очень хорошее описание доступно на странице википедии Ganglia . Надеюсь, что следующая картина (показывающая примерную конфигурацию) помогает понять идею:

В этом посте я скорее остановлюсь на конфигурации Ganglia. Если вы используете Debian, пожалуйста, обратитесь к следующему руководству, чтобы установить его (просто введите пару команд). Мы используем Ganglia 3.1.7 в этом посте.

Ganglia для небольшого кластера Hadoop

Хотя Ganglia является масштабируемым, распределенным и может контролировать сотни и даже тысячи узлов, небольшие кластеры также могут извлечь из этого пользу (а также разработчики и администраторы, поскольку Ganglia — это отличный эмпирический способ изучения внутренних компонентов Hadoop и HBase). В этой статье я хотел бы описать, как мы настроили Ganglia на кластер из пяти узлов (1 ведущий и 4 подчиненных), который работает с Hadoop и HBase. Я считаю, что кластер из 5 узлов (или аналогичного размера) является типичной конфигурацией, с которой многие компании и организации начинают использовать Hadoop. Обратите внимание, что Ganglia достаточно гибок, чтобы его можно было настраивать разными способами. Здесь я просто опишу, какого конечного эффекта я хотел достичь и как это было сделано. Наши требования к мониторингу могут быть определены следующим образом:

• легко получить показатели от каждого узла
• легко получить общие показатели для всех подчиненных узлов (чтобы мы знали, сколько ресурсов используется заданиями MapReduce и операциями HBase)
• легко получить агрегированные метрики для всех мастер-узлов (пока у нас есть только один мастер, но когда кластер растет, мы будем перемещать некоторые мастер-демоны (например, JobTracker, Secondary Namenode) на отдельные машины)
• легко получить агрегированные метрики для всех узлов (чтобы получить общее состояние кластера)

Это означает, что я хочу, чтобы Ganglia видел кластер как два «логических» подкластера, например, «хозяева» и «рабы». По сути, я хотел бы видеть такие страницы:

Возможная конфигурация ганглиев

Вот иллюстративное изображение, на котором показана простая конфигурация Ganglia для 5-узлового кластера Hadoop, которая отвечает всем нашим требованиям. Итак, давайте настроим это таким образом!

Обратите внимание, что мы хотели бы сохранить как можно больше настроек по умолчанию. По умолчанию:

• gmond связывается через UDP-порт 8649 (указанный в разделах inudp_send_channel иudp_recv_channel в gmond.conf)
• gmetad загружает метрики через TCP-порт 8649 (указанный раздел intcp_accept_channel в ingmond.conf и запись data_source в gmetad.conf)

Однако одна настройка будет изменена. Мы установили способ связи между gmonds как одноадресные UDP-сообщения (вместо многоадресных UDP-сообщений). Одноадресная передача обладает следующими преимуществами по сравнению с многоадресной: она лучше для более крупного кластера (скажем, кластера с более чем сотней узлов) и поддерживается в среде Amazon EC2 (в отличие от многоадресной).

Настройка демона мониторинга ganglia (gmond)

Согласно картинке выше:

• Каждый узел работает агмонд.

Конфигурация подчиненного кластера

• Каждый узел на узлах slave1, slave2, slave3 и slave4 определяетudp_send_channel для отправки метрик на slave1 (порт 8649)
• gmond на slave1 определяетudp_recv_channel (порт 8649) для прослушивания входящих метрик и tcp_accept_channel (порт 8649), чтобы объявить их. Это означает, что этот gmond является «ведущим узлом» для этого подкластера и собирает все метрики, отправленные через UDP (порт 8649) всеми gmonds от подчиненных узлов (даже из самого себя), которые позже могут быть опрошены gmetad через TCP (порт 8649) ,

Конфигурация подкластера Masters

• Главный узел gmond определяетudp_send_channel для отправки данных на главный (порт 8649), udp_recv_channel (порт 8649) и tcp_accept_channel (порт 8649). Это означает, что он становится «ведущим узлом» для этого кластера с одним узлом, собирает все метрики из себя и предоставляет их gmetad. Конфигурация должна быть указана в файле gmond.conf (вы можете найти его в / etc / ganglia /). gmond.conf для slave1 (включены только самые важные настройки):

gmond.conf для slave2, slave3, slave4 (фактически, тот же файл gmond.conf, что и для slave1, также можно использовать):

Файл gmond.conf для мастер-узла должен быть похож на файл gmond.conf slave1 — просто замените IP-адрес slave1 на IP-адрес мастера и задайте для имени кластера «hadoop-master». Вы можете прочитать больше о разделах конфигурации и атрибутах gmond здесь .

Мета-демон Ganglia (gmetad)

Конфигурация gmetad еще проще:

• Мастер ранггметад
• gmetad определяет два источника данных:

Конфигурация должна быть указана в файле gmetad.conf (вы можете найти его в / etc / ganglia /).

Интеграция Hadoop и HBase с Ganglia

Hadoop и HBase используют класс GangliaContext для отправки метрик, собранных каждым демоном (таких как datanode, tasktracker, jobtracker, HMaster и т. Д.), В gmonds. После того, как вы успешно настроили Ganglia, вы можете отредактировать /etc/hadoop/conf/hadoop-metrics.properties и /etc/hbase/conf/hadoop-metrics.properties, чтобы объявить метрику, связанную с Hadoop и HBase, для Ganglia. Поскольку мы используем CDH 4.0.1, который совместим с выпусками Ganglia 3.1.x, мы используем недавно введенный GangliaContext31 (вместо более старого класса GangliaContext) в файлах свойств.

Конфигурация метрик для рабов

Конфигурация метрик для мастера

Должно быть таким же, как для рабов — просто используйте hadoop-master.IP.address: 8649 (вместо hadoop slave1.IP.address: 8649), например:

Не забудьте отредактировать оба файла свойств (/etc/hadoop/conf/hadoop-metrics.properties для Hadoop и /etc/hbase/conf/hadoop-metrics.properties для HBase) на всех узлах, а затем перезапустить кластеры Hadoop и HBase. Дальнейшая настройка не требуется.

Еще немного деталей

На самом деле, я был удивлен, что демоны Hadoop действительно отправляют данные куда-то, а не просто опрашивают их. Что это означает? Это означает, например, что каждый подчиненный узел выполняет несколько процессов (например, gmond, datanode, tasktracker и regionserver), которые собирают метрики и отправляют их в gmond, работающий на узле slave1. Если мы остановим gmonds на slave2, slave3 и slave4, но по-прежнему будем запускать демоны Hadoop, мы все равно получим метрики, связанные с Hadoop (но не получим метрики о памяти и использовании процессора, поскольку они должны были быть отправлены остановленными gmond). Пожалуйста, посмотрите на узел slave2 на рисунке ниже, чтобы увидеть (более или менее), как он работает (tt, dd и rs обозначают tasktracker, datanode и regionserver соответственно, в то время как slave4 был удален для повышения читабельности).

Отдельные точки отказа

Эта конфигурация работает хорошо, пока узлы не начинают выходить из строя. И мы знаем, что они будут! И мы знаем, что, к сожалению, наша конфигурация имеет как минимум две отдельные точки отказа (SPoF):

• gmond на slave1 (в случае сбоя этого узла вся статистика мониторинга всех подчиненных узлов будет недоступна)
• gmetad и веб-интерфейс на главном сервере (в случае сбоя этого узла полная система мониторинга будет недоступна. Это означает, что мы не только потеряем самый важный узел Hadoop (на самом деле его следует называть SUPER-master, поскольку он имеет так много главных демонов) установлен, но мы также теряем ценный источник информации мониторинга, который может помочь нам определить причину сбоя, посмотрев графики и метрики для этого узла, которые были сгенерированы за мгновение до сбоя)

Предотвращение SPoF от Ganglia на узле slave1

К счастью, вы можете указать столько udp_send_channels, сколько захотите, чтобы избыточно отправлять метрики другим gmond (при условии, что эти gmond указывают udp_recv_channels для прослушивания входящих метрик). В нашем случае мы можем выбрать slave2 как дополнительный ведущий узел (вместе с slave1), чтобы избыточно собирать метрики (и сообщать им gmetad

• updategmond.conf на всех подчиненных узлах и определите дополнительный разделudp_send_channel для отправки метрик на slave2 (порт 8649)
• Updategmond.conf на slave2 для defineudp_recv_channel (порт 8649) для прослушивания входящих метрик и tcp_accept_channel (порт 8649) для их объявления (те же настройки должны быть уже установлены в gmond.conf s на slave1)
• Файл updatehadoop-metrics.properties для демонов Hadoop и HBase, работающих на подчиненных узлах, для отправки своих метрик как на slave1, так и на slave2, например:

• наконец обновил data_source «hadoop-slaves» ingmetad.conf для опроса данных из двух избыточных gmond-ов (если gmetad не может извлечь данные из slave1.node.IP.address, он продолжит попытки slave2.node.IP.address):

Возможно, картина ниже не удачна (так много стрелок), но она намеревается сказать, что в случае сбоя slave1 gmetad сможет получать метрики от gmond на узле slave2 (поскольку все подчиненные узлы отправляют метрики избыточно на gmond s, работающие на slave1 и раб2).

Предотвращение SPoF от Ganglia на главном узле

Основная идея здесь не в том, чтобы размещать gmetad (и веб-интерфейс) с основными демонами Hadoop, чтобы мы не потеряли статистику мониторинга в случае сбоя главного узла (или просто его недоступности). Одна из идей заключается в том, чтобы, например, переместить gmetad (и веб-интерфейс) из slave1 в slave3 (или slave4) или просто ввести избыточный gmetad, работающий в slave3 (или slave4). Первая идея кажется вполне приемлемой, а вторая усложняет задачу для такого небольшого кластера. Я предполагаю, что еще лучшая идея состоит в том, чтобы ввести дополнительный узел (называемый «краевым» узлом, если это возможно), который запускает gmetad и веб-интерфейс (на нем также могут быть установлены базовые пакеты Hadoop и HBase, но он не запускает никаких демонов Hadoop — он действует как клиентский компьютер только для запуска заданий MapReduce и доступа к HBase). На самом деле, «пограничный» узел обычно используется для предоставления интерфейса между пользователями и кластером (например, он запускает Pig и Hive , Oozie ).

Устранение неполадок и советы, которые могут помочь

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

Начните с малого

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

Попробуйте отправить «Hello» с узла 1 на узел 2

Убедитесь, что вы можете общаться с портом 8649 на указанном целевом хосте по протоколу UDP. Netcat — это простой инструмент, который поможет вам проверить это. Откройте порт 8649 на узле 1 (позже он будет называться «ведущим узлом») для входящих соединений UDP, а затем отправьте на него некоторый текст с узла 2.

Если это не работает, дважды проверьте, открывает ли ваши правила iptables (iptables или ip6tables, если вы используете IPv6) порт 8649 для соединений UDP и TCP.

Позвольте gmond отправить некоторые данные другому gmond

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

После запуска gmonds (sudo /etc/init.d/ganglia-monitor start) вы можете использовать lsof, чтобы проверить, было ли установлено соединение:

Чтобы увидеть, действительно ли какие-либо данные отправляются ведущему узлу, используйте tcpdump для выгрузки сетевого трафика через порт 8649:

Использовать опцию отладки

tcpdump показывает, что некоторые данные передаются, но не сообщает, какие данные отправляются. Надеемся, что запуск gmond или gmetad в режиме отладки дает нам больше информации (поскольку он не запускается как демон в режиме отладки, поэтому остановите его, просто используя Ctrl + C)

Мы видим, что различные метрики собираются и отправляются на порт host = hadoop-slave1.IP.address = 8649. К сожалению, это только не говорит, были ли они доставлены успешно, так как они были отправлены по UDP …

Не смешивайте IPv4 и IPv6

Давайте посмотрим на реальную ситуацию, с которой мы столкнулись в нашем кластере (и которая была основной причиной таинственной и раздражающей неправильной конфигурации Ganglia). Сначала посмотрите на результаты lsof.

Здесь hadoop-slave2 отправляет метрики в hadoop-slave1 на правом порту и hadoop-slave1 также прослушивает на правом порту. Все почти так же, как в фрагментах предыдущего раздела, за исключением одной важной детали — hadoop-slave2 отправляет по IPv6, но hadoop-slave1 читает по IPv4! Первоначально предполагалось обновить правила ip6tables (кроме iptables), чтобы открыть порт 8649 для соединений UDP и TCP через IPv6. Но это не сработало. Это сработало, когда мы изменили имя хоста «hadoop-slave1.vls» на его IP-адрес в файлах gmond.conf (да, раньше я использовал имена хостов вместо IP-адресов в каждом файле). Убедитесь, что ваш IP-адрес правильно преобразован в имя хоста или наоборот.

Получить сводку кластера с помощью gstat

Если вам удалось отправить метрики отправки с slave2 на slave1, это означает, что ваш кластер работает. В номенклатуре Ganglia кластер — это набор хостов, которые имеют один и тот же атрибут имени кластера в файле gmond.conf, например, «hadoop-slaves». Ganglia предоставляет полезную утилиту gstat, которая печатает список хостов, представленных gmond, работающим на данном узле.

Проверьте, откуда gmetad опрашивает метрики

Запустите следующую команду на хосте, который запускает gmetad, чтобы проверить, из каких кластеров и хоста он опрашивает метрики (вы как-то grep, чтобы отобразить только полезные строки):

альтернативы

Поскольку мониторинг кластеров является довольно широкой темой, существует множество инструментов, которые помогут вам в этой задаче. В случае кластеров Hadoop, кроме Ganglia, вы можете найти ряд других интересных альтернатив. Я только кратко упомяну пару из них.

Cloudera Manager 4 (Enterprise)

Помимо значительного упрощения процесса установки и настройки кластера Hadoop, Cloudera Manager предоставляет несколько полезных функций для мониторинга и визуализации десятков метрик производительности службы Hadoop и информации, связанной с хостами, включая ЦП, память, использование диска и сетевой ввод / вывод. Кроме того, он предупреждает вас, когда вы приближаетесь к критическим порогам (сам Ganglia не предоставляет оповещений, но может быть интегрирован с системами оповещения, такими как Nagios и Hyperic). Вы можете узнать больше о ключевых функциях Cloudera Manager здесь .

Кактусы, Zabbix, Nagios, Hyperic

Пожалуйста, посетите веб-сайт Cacti, чтобы узнать больше об этом инструменте. Вот также очень интересное сообщение в блоге о графическом представлении Hadoop с Cacti . Zabbix , Nagios и Hyperic — инструменты, на которые вы также можете захотеть взглянуть.

Подтверждает

Я хотел бы поблагодарить моих коллег Павла Тексу и Артура Чечко, которые помогли мне с настройкой и отладкой Ganglia в кластере.

Справка: конфигурация Ganglia для небольшого кластера Hadoop и устранение неполадок от нашего партнера JCG Адама Кава в Hakuna MapData! блог.