Hadoop framework is a popular solution to such tasks as distributed data storage and running. Map/Reduce tasks on cluster. High scalability, mature ecosystem and large community make Hadoop one the most popular framework in distributed data processing. But the more responsibility you put on it, the more important it becomes to provide its fault-taulerance and high availability. This presentation will be useful to those, who have already been using Hadoop. For the rest it will be interesting to learn some architectural solutions applied in Hadoop. In my presentation I will cover aspects of high availability implementation for Hadoop. Besides, I will talk on: – “The zoo” we have to deal with; – Why we should provide high availability: points of system failure and its consequences; – Tools and solutions to such problems; – Our practical experience of implementation: preparation, deploy, testing.

2. О чем доклад?
✦Основные узлы и компоненты Hadoop
✦Зачем обеспечивать высокую доступность
кластера
✦Как постичь дзен Hadoop
High Availability (HA)
✦Наш опыт внедрения HA

3. Что будет в докладе
5полезных
ссылок
2
72слайда
про
Hadoop
2картины
Ложкина
5блок-схем
4
1
КО
5классных
советов
истории
факапов
sequence
diagrams

4. Компоненты кластера

5. Hadoop "на пальцах"
Hadoop Distributed FileSystem
Файловая система
● Иерархическая
● Распределенная
● С репликацией
Yet Another Resource Negotiator
Вычислительные ресурсы кластера
● Набор нод
● Ядра (vCores)
● RAM
Программный комплекс

6. HDFS

7. HDFS

8. HDFS: узлы и роли
NameNode
✦ Центральный узел кластера
✦ Хранит индекс FS
✦ Предоставляет API для манипуляций с ним
✦ Знает, где лежат данные

9. HDFS

10. HDFS: узлы и роли
DataNode
✦ Принимает read/write запросы к содержимому
файлов HDFS
✦ Хранит содержимое файлов на своей дисковой
подсистеме

11. HDFS: запрос с отказом DataNode

12. NameNode отправляет клиента на “живую” реплику файла

13. HDFS: запрос с отказом NameNode

14. HDFS: выводы
✦Выход из строя датанод не критичен,
пока есть хотя бы одна, хранящая
копию данных
✦Выход из строя неймноды ведёт к
полной недоступности HDFS

15. YARN

16. YARN

17. YARN: узлы и роли
ResourceManager
✦ Запущен на одной машине кластера
✦ Принимает пользовательские запросы на
запуск программ в кластере
✦ Делит ресурсы кластера между программами
✦ Просит ресурсы у конкретных NodeManager

18. YARN

19. YARN: узлы и роли
NodeManager
✦ Запущен на “рабочих” машинах кластера
✦ Принимает запросы на создание JVM с
заданным размером HEAP и резервированием
виртуальных ядер
✦ Исполняет пользовательский код в этих JVM

20. YARN: запуск программы пользователя

21. YARN: отказ ResourceManager
Вспоминаем картинку про
менеджера и разработчика

22. YARN: выводы
✦Выход из строя NodeManager’ов
приводит к потере части ресурсов
кластера
✦Выход из строя ResourceManager’а
приводит к невозможности запуска
чего-либо на кластере

24. Опыт Badoo по эксплуатации
Hadoop до HA

25. До HA: edit-logs && fsimage
При старте, NN производит combine своих edit-
логов с транзакциями
○ если NN долго не перезапускалась, то
restart мог достигать нескольких часов
Решение:
○ перезапуск NN не реже чем раз в месяц
○ ручное поэтапное подсовывание edit-логов
○ использовать свежий Hadoop :)
○ правильно настроить edit-logs

26. До HA: совсем грустно
Однажды мы не смогли подняться из edit-логов
1. Пропатчили код восстановления
2. Сделали binary-патч одного jar-файла
3. Скопировали все edit-логи на отдельную
машину
4. Восстановились с патченным кодом
5. Скопировали snapshot обратно
6. …
7. PROFIT!
8. Downtime - почти сутки

27. В итоге, зачем нужен HA?

28. При HA Риски без HA
✦Fault-tolerance
✦Низкий downtime
✦Не теряем $$$
✦Крепкий сон
✦HDFS => набор
несвязных
бинарей
✦Вместо
вычислительного
кластера - куча
несвязных машин

30. Hadoop в Badoo
✦Инсталляция из 67 машин
✦Ёмкость HDFS ~ 850 Tb, 50M объектов
✦CPU: 2700 cores
✦RAM: 10 Tb

31. Hadoop в Badoo: ETL
✦ ETL-процессы
Загрузили много данных из внешних
источников, посчитали свёртки, выгрузили в
аналитическую БД
✦ > 700 заданий в сутки
✦ Десятки Tb на чтение

32. Hadoop в Badoo: Deep storage
✦ Deep storage для хранения исторических данных
✦ “Backup” данных из аналитической базы
✦ По некоторым источникам есть история за
несколько лет
✦ > 600 Tb занятого дискового пространства

33. Hadoop в Badoo: deep storage
Кластер “чихает” - выпадают ноды :)

34. Hadoop в Badoo: realtime
✦Многие считают, что Hadoop и realtime -
несовместимо
✦Но при правильных инструментах это не
так :)
✦Keywords: Apache Spark, Storm, Samza

35. Hadoop в Badoo: realtime
✦Потоковая агрегация событий
✦> 600 типов событий
✦Входная мощность: 350K событий/сек
✦Выходная мощность: 100К метрик/сек
✦Доклад

36. Цена downtime
✦ Недоступность части данных для аналитиков к
началу business time
✦ Деградация графиков для realtime
✦ Невозможность получения оперативной
статистики

37. И что же делать?

38. High Availability в теории
✦Hot standby
✦Round-robin request balancing
✦Шардинг

39. High Availability в теории
✦Hot standby - используется в
Hadoop для резервирования SPOF
(NameNode, ResourceManager)
✦Шардинг - Federated NameNode

40. HA HDFS: общая схема

41. HA HDFS: общая схема
✦Пользовательские запросы по-
прежнему обслуживает одна
активная NN
✦Есть реплика, читающая
журнал с транзакциями

42. HA HDFS: компоненты failover

43. HA HDFS: компоненты (Zookeeper)
Zookeeper
Распределённая система с функционалом:

lock-service

leader election

иерархическое хранение конфигураций
В рамках HDFS HA:

выбирает активную NN

предоставляет для неё лок

оповещает об изменении статуса NN

44. HA HDFS: компоненты (ZKFC)
ZKFailoverController (ZKFC)
Вспомогательный сервис для автоматического
failover’а

запускается на машинах NN

мониторит живость локальной NN

слушает уведомления от Zookeer

производит failover

45. HA HDFS: компоненты (Journal Node)
✦ Реплика состояния NameNode
✦ Распределённость
✦ Отсутствие SPOF
✦ Запись в самую медленную реплику не тормозит
общий процесс

46. Механизм failover
https://issues.apache.org/jira/browse/HDFS-2185

47. HDFS failover: summary
✦Активная NN держит лок в ZK
✦Если лок пропал, то произвольный
ZKFC пытается сделать свою NN
активной в ZK
✦Если удалось - переводит остальные
NN в standby, а локальную делает
active

48. HA YARN: общая схема

49. HA YARN: общая схема
✦ResourceManager’ы используют
механизм leader-election,
предоставляемый YARN
✦Для репликации состояния мастера
используется хранилище Zookeeper
✦Контроллер failover’а встроен в сам
демон RM, и не требует отдельного
приложения

50. HA: внедрение
✦Research ~ 5 дней
✦Инсталляция на dev-кластере: 2 дня
✦Стрельбы/проверка
работоспособности – 2 дня
✦Адаптация клиентов – 2 дня

51. HA: внедрение
✦С момента внедрения – не было
даунтаймов дольше 10 секунд
✦Переключения между “мастерами”
иногда случаются
✦Но не оказывают существенного
влияния

52. С другой стороны баррикад
(настройка клиентов)

53. HDFS: клиентский API
✦ Native API
клиенты - в основном - JAVA
JAVA-клиенты знают про конфигурацию HA
✦ WebHDFS
HTTP-based, для любого языка
клиенты не знают, какая NN активная

54. WebHDFS: standby NN
curl http://stanbynn.domain:50070/webhdfs/v1/?op=LISTSTATUS
{
"RemoteException":
{
"exception":"StandbyException",
"message":"Operation category READ is not supported in
state standby"
}
}
Standby-нода не обслуживает клиентские запросы
http://$host:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus

55. WebHDFS: вариант 1

56. WebHDFS: вариант 1
Pro:
1. Просто, как валенок
Cons:
2. Лишний HTTP-вызов
3. Имплементация под
каждый ЯП
(у нас их много :)

57. WebHDFS: вариант 2
Программный балансировщик

прокси перед NN

проверяет апстримы через URL
http://$host:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus
Более одного варианта:

Nginx

HAProxy

ваш любимый

59. WebHDFS: вариант 3 (hardware balancer)
✦ В Badoo - на входе в каждый ДЦ
✦ Маршрутизирует весь трафик
✦ Имеет функции и возможности тюнинга,
превосходящие программный балансер
✦ Умеем его готовить
✦ Применили для WebHDFS

60. Советы из опыта эксплуатации

61. HDFS: rock your NameNode
✦ Простое правило:
1М файлов = 1 Gb heap size для NN
✦ В противном случае наблюдается деградация
✦ Не влезли в RAM одного хоста - добро
пожаловать в Federated HDFS (мы пока не
доросли до него)

62. HDFS: rock your NameNode
✦ Вдохновлялись статьей от Hortonworks
✦ Асинхронное логирование операций с HDFS (у
нас их > 3K RPS)
✦ Достаточное число потоков для обработки API
запросов
✦ Выключили atime (как и в обычных FS на
наших серверах)

63. YARN: tune NodeManager
✦ Увеличили HEAP size
✦ В мирное время не требуется, но у нас
приложения Spark используют его для обмена
промежуточными данными

64. HDFS: datanode
✦ Т.к. репликация
программная, то нет
большого смысла
использовать RAID
✦ JBOD - наш друг: сила
в шпинделях!

65. HDFS: выбор диска для блоков

66. HDFS: выбор диска для блоков
✦ By default - Round Robin
✦ Но на первом диске - OS => он заведомо меньше
✦ Всегда образуется перекос
✦ Решение 1: настройка для датаноды
AvailableSpaceVolumeChoosingPolicy
✦ Решение 2: Hadoop 3 + междисковый балансер

67. Человек против машины
Может ли один аналитик уложить кластер?

68. Нет ничего невозможного!
✦ Пишет 4-х этажный SQL
✦ Запускаем, ждём 5 минут
✦ Забиваем IN/OUT eth на датанодах
✦ Забиваем свитч
✦ Залезаем в iowait
✦ PROFIT!

69. How to avoid
✦ На датанодах - 10Gb eth
или:
✦ Стараемся уважать data-locality
(работаем с данными по месту их физического
хранения)

70. Что вы узнали
✦ Из каких базовых сервисов состоит Hadoop
✦ Какие там существуют SPOF
✦ С помощью каких средств они устраняются
✦ Какие действия предпринять для адаптации
клиентов кластера к HA

71. Полезные материалы
✦ https://tech.badoo.com
✦ Доклад Badoo про использование Hadoop
✦ Инструкции по настройке HA
✦ Тюнинг NameNode

72. Кажется, я обещал 2 картины?

73. Спасибо!
krash@corp.badoo.com
krash3@gmail.com