Современные информационные технологии / 2.
Вычислительная техника и программирование
студент А.Е. Димитров.
НТУУ «КПИ имени Игоря Сикорского», Украина
Docker, как средство виртуализации Hadoop
процессов
Что вы делаете, когда ваш бизнес зависит не только от того,
как запустить Hadoop в конфигурации многопользовательского режима, надежно и масштабируемо,
но также и выжать максимальную эффективность из системы? Для Altiskale -
поставщика Hadoop сервиса, специально предназначенного для рабочих нагрузок
Hadoop, ответ был прост - запустить Hadoop на Docker контейнерах.
Просто, но, конечно же, нелегко, объяснил лидер Altiscale
Насер Манеш, оркестровый продуктовый руководитель в компании, который поделился
опытом работы с Hadoop и Docker на конференции Strata + Hadoop World.
Запуск Docker в производстве - это кровоточащий край, как
оказалось. Запуск петабайтно-маштабируемого Hadoop кластера на Docker, в
производстве, это совершенно другой зверь.
Почему Докер?
В качестве приложения с платформой как услуга (PaaS),
ориентированной на нагрузку, облако данных Altiscale Data Cloud обеспечивает
то, что компания называет «Hadoop dialtone». Пользователи могут загружать
данные в распределенную файловую систему Hadoop ( HDFS) с помощью различных
механизмов и API, ориентированных на большой объем данных и событий, и
развертывания MapReduce, Pig, Hive и других приложений для непосредственного
использования этих данных без необходимости развертывания или настройки Hadoop.
Хотя компания позволяет пользователям отслеживать
производительность работы на основе показателей инфраструктуры, таких как
потребление памяти и процессора, все же она абстрагирует понятие узлов,
кластеров и других проблем на уровне инфраструктуры. Это дает компании
возможность разделять и распределять ресурсы по своему усмотрению. Фактически,
получение этого права на распределение ресурсов является ключевым фактором,
определяющим маржу компании и, таким образом, имеет решающее значение. В
результате оптимизация этого аспекта технологической платформы компании
является бизнес-мандатом.
Виртуализация хорошо известна для решения проблем с
разделением / распределением для облачных провайдеров, но накладные расходы,
которые она приносит, смертельны для рентабельности Altiscale.
«Каждый процессорный цикл, который идет на ваш гипервизор, -
это деньги, потраченные впустую», - говорит Манеш. «Тоже самое можно сказать и
про каждый байт ОЗУ».
Контейнерные технологии, такие как Docker, были
привлекательными для Altiscale за их способность предлагать легкую изоляцию и
виртуализацию, что приводило к сокращению накладных расходов, более быстрым
развертываниям и перезагрузкам, а также упрощенным миграциям.
Docker на Hadoop или Hadoop на Docker?
Одним из первых решений, которые потребовались решить
инженерам Altiscale, было: запустить Docker в Hadoop или запустить Hadoop на
Docker.
Запуск Docker в среде Hadoop позволил бы компании
использовать преимущество YARN, менеджер ресурсов кластера, представленный в
Hadoop 2.0. Это было бы идеально, так как команда Altiscale хорошо знает YARN и
является участником проекта с открытым исходным кодом. Огромные возможности
управления ресурсами YARN позволили бы системам Altiscale просто попросить
Hadoop запускать и управлять контейнерами, устраняя большую архитектурную
сложность. К сожалению, как стало известно команде, получение Docker на Hadoop
для работы потребует поддержки как в YARN, так и в Docker, что потребует
времени для материализации.
Запуск Hadoop в контейнерах Docker, с другой стороны,
предоставил немедленную возможность для компании избавится от зависимостей при
добавления новых функций в любой проект. И в то время как результирующее
решение будет более сложным, не используя YARN - системы Altiscale должны были
бы управлять контейнерами Docker и поддерживать их напрямую - Манеш и его
команда обнаружили, что это является одновременно повторяемым и
автоматизируемым.
Подход Hadoop на Docker позволил Altiscale перенести процессы
DataNode HDFS и NodeManager YARN - традиционно спаренные на каждом из
подчиненных узлов в своих кластерах Hadoop - в отдельные контейнеры.
Развертывание этих процессов в качестве контейнеров обеспечило бы Altiscale ряд
важных преимуществ, в том числе предоставление компании высокой степени гибкости
при распределении этих процессов по всей их инфраструктуре, позволяя независимо
управлять ресурсами вычислений и памяти для каждого процесса и поддерживая
большую общую эластичность и гибкоскть.
Какие возникли проблемы
Altiscale столкнулась с долей проблем во время попытки
поднятия и настройки такой архитектуры, её запуском и масштабированием. По
словам Манеша, многие из них были эксплуатационными:
«Хотя Docker получает большую видимость от сообществ
разработчиков и DevOps, его операционная зрелость по-прежнему оставляет желать
лучшего», - сказал Манеш. «Он не дружественный к эксплуатации».
«Большинство проблем, которые мы испытывали, связаны с тем,
что Docker не был разработан для поддержки долгосрочных контейнеров, которые
необходимы для поддержки производственных систем, в отличие от приложений в
разработке. Поддержка там отсутствует.»
Манеш изложил несколько проблем, с которыми сталкивался
Altiscale:
·
Для Docker требуется
отдельная оркестровка, настройка и автоматизация.
·
Журналирование затруднено в
распределенной среде Docker. Вещи, должны были работать - например,
использование syslog для сбора журналов – не работают, потому что записи
журнала, специфичные для контейнера, не отделены от объектов операционной
системы хоста.
·
Сеть была совершенно
болезненной. Docker тяжело выполняет стандартные сетевые задачи Linux, такие
как управление IP-адресами и использование iptables. Инженеры Altiscale нашли
множество условий гонки в том, как IP стек Docker-а пытается выделить ресурсы,
что приводит к разочаровывающему опыту, когда некоторые вещи работают в одном
случае, но не работают в остальных.
«Из-за этих проблем мы испытали пару серьезных неудач», -
говорит Манеш. «Нам приходилось три раза реорганизовывать процесс запуска наших
узлов».
«Некоторые из вещей, с которыми мы столкнулись, - это
проблемы, с которыми разработчики не столкнутся на ноутбуках», - добавил он.
«Они отображаются только на реальных серверах с реальными BIOS, 12 дисками,
тремя сетевыми картами и т. д., и только затем они начинают проявляться в
реальном режиме. Пришлось потратить довольно много времени, чтобы найти и
обойти эти проблемы».
Путь к производству
В настоящее время процент контейнеризованных узлов
по-прежнему остается небольшим по сравнению с физическими узлами, так как
компания постепенно развертывает новую архитектуру.
Манеш отмечает, что, хотя значительная часть работы началась
с запуском этого проекта, инженеры Altiscale не внесли изменений в ядро Docker,
которое оставалось бы запатентованным.
«Мы старались держаться подальше от этого. Докер будет
продолжать развиваться и двигаться вперед. Мы не хотим поддерживать свою
собственную версию».
Docker более популярен среди разработчиков, но менее применим
к производственным системам, поэтому его эксплуатация в больших масштабах –менее
применимая практика.
Література:
1.
Пехуру Радж; Дьева С. Шелладхурай; Винод Сінгх Learning Docker. - Packt
Publishing, 2015 р. - 240 с
2.
Е. Моует. Використання Docker. Розробка і впровадження програмного
забезпечення за допомогою технології контейнерів. 2017 р. - 300 с.
3.
https://conferences.oreilly.com/strata/big-data-conference-ca-2015/public/schedule/detail/38521
4.
https://thenewstack.io/running-hadoop-docker-production-scale/