Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

My talk on Hadoop stack operations engineering at OSPCon

1,882 views

Published on

My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)

Published in: Technology
  • Be the first to comment

My talk on Hadoop stack operations engineering at OSPCon

  1. 1. Наdoop на службе федерального налогового ведомства страны Александр Чистяков, ФКУ “Налог-Сервис”, главный специалист
  2. 2. Я пришел с миром! ● Меня зовут Саша ● Я работаю в Федеральном Казенном Учреждении “Налог-Сервис” на должности главного специалиста ● Я занимаюсь эксплуатацией Hadoop-кластера Федеральной Налоговой Службы
  3. 3. Вы? ● Работаете с большими данными? ● Работаете с очень большими данными? ● Работаете с очень-очень большими данными ● Кстати, как отличить просто большие данные от очень больших данных?
  4. 4. Сразу достанем и измерим ● Похвастаюсь: ● У меня МНОГО RPS* * совершенно бесполезных
  5. 5. Начнем с начала ● Ни одна крутая история не начинается со слов “мы сидели и пили кофе” ● Эта история началась со слов “все плохо” ● Повторенных не один раз
  6. 6. Насколько все было плохо? ● Полстойки BigData-решения от компании Cisco
  7. 7. Насколько все было плохо? ● Полстойки BigData-решения от компании Cisco ● RedHat Enterprise Linux 6
  8. 8. Насколько все было плохо? ● Полстойки BigData-решения от компании Cisco ● RedHat Enterprise Linux 6 ● Установленный “дистрибутив” Hadoop от компании Cloudera (на тот момент – 5.2)
  9. 9. Насколько все было плохо? ● Полстойки BigData-решения от компании Cisco ● RedHat Enterprise Linux 6 ● Установленный “дистрибутив” Hadoop от компании Cloudera (на тот момент – 5.2) ● Разработчики с полным доступом к продакшну
  10. 10. Насколько все было плохо? ● Полстойки BigData-решения от компании Cisco ● RedHat Enterprise Linux 6 ● Установленный “дистрибутив” Hadoop от компании Cloudera (на тот момент – 5.2) ● Разработчики с полным доступом к продакшну ● Два приложения: Java/YARN/HBase и Scala/Spark/HBase/Parquet
  11. 11. Кстати, зачем все это нужно? ● Система контроля НДС – сравнение налоговых деклараций контрагентов
  12. 12. Кстати, зачем все это нужно? ● Система контроля НДС – сравнение налоговых деклараций контрагентов ● ^ когда никого нет на кластере
  13. 13. Кстати, зачем все это нужно? ● Система контроля НДС – сравнение налоговых деклараций контрагентов ● ^ когда никого нет на кластере ● Визуализация несоответствий и работа с ними
  14. 14. Кстати, зачем все это нужно? ● Система контроля НДС – сравнение налоговых деклараций контрагентов ● ^ когда никого нет на кластере ● Визуализация несоответствий и работа с ними ● Обработка интерактивных запросов от налоговых инспекторов
  15. 15. Кстати, зачем все это нужно? ● Система контроля НДС – сравнение налоговых деклараций контрагентов ● ^ когда никого нет на кластере ● Визуализация несоответствий и работа с ними ● Обработка интерактивных запросов от налоговых инспекторов ● ^ в рабочее время (когда на кластере есть пользователи)
  16. 16. Подготовьте мышь к опыту ● Ценности DevOps это: ● C – Culture ● A – Automation ● M – Measurement ● S – Sharing
  17. 17. C — Culture ● Петербург – культурная столица Российской Федерации ● В петербургском филиале ФКУ “Налог-Сервис” принято обращаться друг к другу по имени-отчеству
  18. 18. A — Automation ● A – Ansible* * отстирывает в два раза лучше Вашего моющего средства!
  19. 19. Б — Безопасность ● Внутренняя сеть ФКУ не подключена к интернету ● Нельзя просто так взять и внести или вынести файлы* * но если очень хочется...
  20. 20. Рабочее место специалиста ● Плюсы: можно нормально выспаться ● Минусы: нет
  21. 21. Первые шаги ● А – Автоматизация (Ansible) ● Первый проект, в котором я делал ad hoc команды ● ansible all -a "command" --sudo --user ansible
  22. 22. Первые шаги ● А – Автоматизация (Ansible) ● Первый проект, в котором я делал ad hoc команды ● ansible all -a "command" --sudo --user ansible ● Тем не менее: описание в виде playbooks/roles ● Прямое переиспользование уже накопленного материала практически невозможно из-за особенностей Cloudera
  23. 23. Особенности Cloudera ● Управление через веб-интерфейс (!) ● Параметры хранятся в СУБД PostgreSQL (!!) ● Где-то (?) есть шаблоны для генерации конфигурации
  24. 24. Особенности Cloudera ● Управление через веб-интерфейс (!) ● Параметры хранятся в СУБД PostgreSQL (!!) ● Где-то (?) есть шаблоны для генерации конфигурации ● Сервисами управляет supervisord ● Конфигурационные файлы supervisord генерируются при каждом рестарте кластера заново в новом каталоге с новым уникальным именем (!!!)
  25. 25. Это безумие? Это Cloudera! ● Веб-интерфейс не управляет некоторыми параметрами ● Значения вида -Xmx2048m не поддерживаются из-за буквы m (только значения в байтах) ● Как быть, если нужно задать значение более 4-х гигабайт (в Int такое не поместится)?
  26. 26. Это безумие? Это Cloudera! ● Веб-интерфейс не управляет некоторыми параметрами ● Значения вида -Xmx2048m не поддерживаются из-за буквы m (только значения в байтах) ● Как быть, если нужно задать значение более 4-х гигабайт (в Int такое не поместится)? ● ^ Зачем такое может быть нужно честному человеку?
  27. 27. Укрощение строптивой ● Описали текущую конфигурацию при помощи Ansible ● Выключили веб-интерфейс
  28. 28. Укрощение строптивой ● Описали текущую конфигурацию при помощи Ansible ● Выключили веб-интерфейс ● Получили набор удивительных проблем при рестарте узла: сервис Cloudera удаляет всю конфигурацию supervisord ● Решили это переносом конфигурации в неизвестный сервису каталог
  29. 29. M — Measurement ● Church of Metrics ● В первую же неделю работы мы пронесли в закрытый контур ФНС LXC-контейнер с Grafana и Graphite/Whisper ● Обычно, увидев интерфейс Grafana, люди теряют волю и становятся адептами нашей церкви ● Так и вышло
  30. 30. П — Проблемы ● 100% утилизация системного HDD на машине с контейнером Grafana/Graphite/Whisper ● Постоянные жалобы разработчиков, которые теперь умеют смотреть на графики (научили на свою голову)
  31. 31. П — Проблемы ● 100% утилизация системного HDD на машине с контейнером Grafana/Graphite/Whisper ● Постоянные жалобы разработчиков, которые теперь умеют смотреть на графики (научили на свою голову) ● Как ни странно, жалобы имели под собой основу – одна из нод HBase не успевала записывать на системный диск логи
  32. 32. Р — Решения ● O – OpenTSDB (time series database) ● Работает как сервис поверх HBase ● А у нас уже есть HDFS и HBase
  33. 33. О — Опять проблемы ● O – OpenTSDB (time series database) ● Работает как сервис поверх HBase ● А у нас уже есть HDFS и Hbase ● Интерфейс рисования графиков в Grafana для интеграции с OpenTSDB нравится далеко не всем
  34. 34. C - CPU ● График CPU за 7 дней
  35. 35. Н - Недогруз ● График CPU за 12 часов
  36. 36. Ж — Жадность ● График утилизации дисков за 15 минут
  37. 37. Д — Дисбаланс ● График утилизации дисков за 7 дней
  38. 38. О — Отказ ● Один из дисков сломался и его никто не рвется менять (не проблема)
  39. 39. Д — Другой отказ ● supervisord в Cloudera так настроен, что после трех попыток выключает сервис ● Однажды у нас выключились 11 из 14 region серверов в HBase ● Кластер работал БЕЗ ПОТЕРИ ПРОИЗВОДИТЕЛЬНОСТИ
  40. 40. Д — Другой отказ ● supervisord в Cloudera так настроен, что после трех попыток выключает сервис ● Однажды у нас выключились 11 из 14 region серверов в HBase ● Кластер работал БЕЗ ПОТЕРИ ПРОИЗВОДИТЕЛЬНОСТИ ● ^ Помните слайд про “недогруз”?
  41. 41. Л — Локальность ● Способность region server читать данные с data node через unix socket, не задействуя сеть
  42. 42. Л — Локальность ● Была 0 на всех region servers ● На HDFS data nodes зарегистрированы по FQDN ● На HBase region servers зарегистрированы по short names ● Несовпадение имен – region servers не распознают локальность и не могут использовать unix socket
  43. 43. Л — Локальность ● Семь бед – один restart всех data nodes ● После рестарта регистрируются по коротким именам ● Делаем major compaction всех таблиц – локальность становится почти 100%
  44. 44. Л — Локальность ● Семь бед – один restart всех data nodes ● После рестарта регистрируются по коротким именам ● Делаем major compaction всех таблиц – локальность становится почти 100% ● И НИКАКОГО ПРИРОСТА ПРОИЗВОДИТЕЛЬНОСТИ!
  45. 45. Б — Безысходность ● S - Sampling ● kill -QUIT pid ● Скрипт на bash для сэмплинга заданных контейнеров ● Анализ полученных логов вручную ● Слишком частые обращения к HBase metadata ● ^ удалось быстро исправить
  46. 46. Б — Безысходность ● S - Sampling ● kill -QUIT pid ● Скрипт на bash для сэмплинга заданных контейнеров ● Анализ полученных логов вручную ● Слишком частые обращения к HBase metadata ● ^ удалось быстро исправить ● На этом хорошие новости кончились – далее в сэмплах видим код счета в приложении
  47. 47. К — Качество ● Размер кластера не так важен ● Критически важна способность алгоритма параллелиться
  48. 48. D — Docker ● Новая модная технология ● Которую мы любим и умеем ● К сожалению, стандартная сеть в Docker не позволяет развернуть YARN ● Использование OpenVSwitch (который зависает в предсказуемые, к счастью, моменты) ● Сильная фрустрация всех участников, отказ от Docker
  49. 49. S — Sharing ● Три интенсивные тренировочные сессии ● Несколько часов обучающего видео ● План создания видеотренингов и практических работ на ближайшие полгода ● Как показала практика – в рамках интенсивных трех- и пятидневных сессий запомнить нужный объем информации невозможно
  50. 50. Выводы ● Работа в федеральном проекте: ● а) позволяет посетить новые места ● б) позволяет познакомиться с новыми интересными людьми
  51. 51. Спасибо за внимание! ● Пожалуйста, ваши вопросы! ● С вами был Александр Чистяков ● http://gitinsky.com ● alex@gitinsky.com ● Кстати, мы делаем митапы в Петербурге: ● http://meetup.com/Docker-Spb, http://meetup.com/Ansible-Spb, http://meetup.com/DevOps-40

×