Сегодня термин «БОЛЬШИЕ ДАННЫЕ» у всех на слуху.
После появления в Интернете и прессе многочисленных публикаций, связанных с обработкой «больших данных», интерес к этой теме постоянно растет. Системы управления базами данных с
с использованием технологии NoSQL. Все понимают, что для построения систем «БОЛЬШИХ ДАННЫХ» необходимо обладать внушительными аппаратными ресурсами.
Еще важнее уметь оптимально использовать вычислительные ресурсы системы и эффективно их масштабировать.
Это неизбежно меняет подходы к построению систем обработки данных.
Если раньше системы строились по принципу централизации хранилища данных, с которым работает набор мощных вычислительных серверов, то сейчас этот подход постепенно отходит на второй план.
Появляется все больше систем, построенных на основе кластера из большого количества стандартных серверов средней мощности.
В такой системе нет централизованного хранилища.
Для работы с данными внутри кластера используется модульная распределенная система хранения, использующая локальные дисковые ресурсы каждого сервера.
Если раньше масштабирование осуществлялось путем добавления дисков в централизованную систему хранения и модернизации вычислительных серверов, то теперь эти же вопросы решаются простым добавлением в кластер стандартных узлов.
Этот подход получает все большее распространение.
При эксплуатации таких систем часто встречаются проблемы нехватки вычислительных ресурсов на некоторых узлах.
Бывают ситуации, когда нагрузка на узлы кластера распределяется неравномерно — одна часть узлов простаивает, а другая перегружена различными задачами.
Эти проблемы можно решить «экстенсивно», добавляя в кластер всё больше и больше узлов — что, кстати, и делают многие.
Однако можно применить «интенсивный» подход, оптимизируя распределение ресурсов между разными задачами и разными узлами кластера.
Так или иначе, в последнее время возникла острая потребность в системе, способной быстро и гибко перераспределять доступные ресурсы в ответ на изменение условий нагрузки.
На практике для реализации вышеперечисленных функций система должна обеспечить выполнение трех основных условий:
- Обеспечить возможность объединения вычислительных ресурсов отдельных серверов в общий набор.
- Обеспечьте возможность запуска произвольного приложения на произвольном узле кластера.
- Обеспечить возможность выделения вычислительных ресурсов из общего набора под каждую задачу отдельно в определенном объеме.
Идея создания системы управления кластером с обобщенными вычислительными ресурсами была реализована некоторое время назад Apache Foundation в продукте под названием MESOS. Данный продукт позволяет обеспечить выполнение первого условия – объединить вычислительные ресурсы нескольких аппаратных серверов в один распределенный набор ресурсов, организовав кластерную вычислительную систему.
В двух словах, как это работает: сервис MESOS запускается на каждом узле кластера и может работать в двух режимах — mesos-master и mesos-slave. Таким образом, каждый узел кластера получает либо роль мезо-подчиненного, либо роль мезо-ведущего, либо обе роли по месту, что тоже возможно.
Мезо-ведомые узлы предназначены для запуска приложений по команде, полученной от мезо-ведущего узла.
узлы mesos-master управляют процессом запуска приложений на узлах кластера, обеспечивая тем самым выполнение второго условия — они позволяют запускать произвольное приложение на произвольном узле кластера.
Узлов Mesos-master обычно 2 или 3 для обеспечения отказоустойчивости.
Поскольку по умолчанию обе роли выполняются на узле одновременно, рекомендуется отключить роль mesos-master на большинстве узлов.
Взаимодействие между mesos-slave и mesos-master узлами осуществляется с помощью Apache Zookeeper. Функционал системы Apache MESOS можно гибко расширять за счет интеграции в MESOS сторонних приложений в качестве фреймворков.
Ключевой подход Apache MESOS заключается в том, что мезо-ведомые узлы учитывают имеющиеся на них свободные аппаратные ресурсы — ЦП и ОЗУ — информируя мезо-мастер-узлы об их количестве.
В результате мезо-мастер имеет полную информацию о вычислительных ресурсах, доступных на мезо-подчиненных узлах.
При этом он не только выдает подчиненному узлу команду на запуск приложения, но и способен принудительно устанавливать объем вычислительных ресурсов, которые может иметь это приложение.
Эта проблема решается с помощью механизма контейнеризации приложений.
Процесс начинается в т. н.
контейнер – закрытая операционная среда.
Основой контейнера является файл-образ, в котором установлено ядро ОС, развёрнута корневая ФС, все необходимые системные библиотеки и так далее.
При запуске контейнера запускается ядро системы из образа.
После этого само приложение запускается в заранее подготовленной для него специальной операционной среде.
Получается что-то вроде виртуальной машины для одного процесса.
Здесь важно то, что использование контейнеризации позволяет выделить для каждого контейнера фиксированный объем оперативной памяти и фиксированное количество ядер ЦП (в том числе дробных, менее 1 – 0,5 ядер, например).
Таким образом, мы можем обеспечить выполнение третьего условия — реализуем возможность выделять под каждую задачу определенное количество вычислительных ресурсов из общего набора.
Следует отметить, что изначально Apache MESOS решал заявленные проблемы, используя собственные алгоритмы контейнеризации приложений, но после появления на рынке докер-продукта последний полностью заменил встроенные инструменты контейнеризации Apache MESOS. Так или иначе, на данный момент интеграция докера в решения с Apache MESOS получила широкое распространение и является стандартом де-факто.
Позиции Docker в этой области еще больше укрепились благодаря сервису docker Hub — системе бесплатного распространения контейнерных приложений, чем-то схожей по идеологии с известным сервисом git-hub. С помощью этого сервиса разработчики могут публиковать свои приложения в формате готовых Docker-контейнеров, которыми многие, кстати, активно пользуются в последнее время.
Теперь, если на каком-то мезо-ведомом узле заканчиваются ресурсы, об этом немедленно «становится известно» мезо-мастер-узлу, и он не может запустить приложение на таком ведомом узле.
В этом случае мезос-мастер будет вынужден искать другой, менее загруженный мезос-слейв.
Это приводит к тому, что задачи, более требовательные к доступности вычислительных ресурсов, будут «переложены» на менее загруженные узлы кластера.
Таким образом, мы получаем полноценный кластер с обобщенными ресурсами, который может задавать определенное количество ресурсов, выделяемых приложению для работы.
К сожалению, очевидным недостатком решений на базе Apache MESOS является их ориентированность на одновременное выполнение одной копии приложения на отдельном узле кластера, без мониторинга состояния приложения и без поддержания его функциональности на долгосрочной основе.
Однако недавно эту проблему решила компания MESOSPHERE. На рынок были выведены продукты MARATHON и CHRONOS. Эти продукты позволяют контролировать запуск приложений в среде Apache MESOS. Взаимодействуя через Apache Zookeeper с mesos-master, они встраиваются в его структуры как фреймворки, обеспечивая системе новый функционал.
MARATHON предназначен для запуска приложений, которые должны работать непрерывно в течение длительного времени.
Он предоставляет возможности масштабирования и мониторинга производительности запущенных с его помощью приложений.
В набор стандартных функций MARATHON входит возможность одновременного запуска экземпляра приложения на всех узлах кластера, запуска приложения на определенной части узлов кластера, регулирования количества копий приложения, запускаемых на одном узле кластера и т.д. CHRONOS в свою очередь , обладая схожим функционалом, ориентирован на запуск одноразовых задач по расписанию.
Оба этих приложения имеют собственный интерфейс управления, который осуществляется с помощью протокола HTTP и технологии REST API. По сути, MARATHON встает между пользователем и месос-мастером, принимая запрос на запуск приложения через REST API в формате JSON. В запросе пользователь может, помимо прочего, настроить общее количество запускаемых экземпляров приложения в масштабе кластера, количество экземпляров приложения на узел, объем системных ресурсов, выделяемых каждому экземпляру приложения и т. д.
Как упоминалось выше, многие разработчики начинают распространять свои приложения в виде Docker-контейнеров.
В частности, компания «МЕЗОСФЕРА» успешно применила этот подход, в результате чего рассматриваемые в этой статье приложения MARATHON и CHRONOS на данный момент доступны в виде готовых контейнеров.
Их использование упрощает процесс обслуживания этих подсистем, позволяет легко перемещать их между узлами кластера, существенно ускоряет процесс обновления версий и так далее.
Опыт собственных разработок, а также опыт сторонних компаний позволяет рассматривать данный подход как наиболее вероятную тенденцию развития технологий в данной отрасли.
Подводя итог, можно сказать, что в нашем распоряжении имеется технология, которая на практике способна решить задачи, сформулированные в начале статьи, выполняя три основных требования: обеспечение возможности прозрачного использования обобщенных вычислительных ресурсов ИТ-системы.
, обеспечивающие возможность запуска произвольных задач на произвольном узле системы и устанавливающие механизм назначения определенного количества вычислительных ресурсов из общего набора кластеров для каждой задачи в отдельности.
В заключение не лишним будет отметить, что эффективность описанного в статье подхода подтверждена успешным опытом внедрения и эксплуатации решений, разработанных с использованием описанных выше технологий, несколькими петербургскими ИТ-компаниями.
Технологии, рассматриваемые в этой статье, описаны более подробно.
Здесь .
Теги: #linux #it-инфраструктура #Системное администрирование #docker #DevOps #большие данные #конфигурация Linux #Apache #mesos #mesосфера
-
Обзоры Новой Игровой Клавиатуры Logitech G15
19 Dec, 24 -
Stm32 + Cmsis + Stm32Cubeide
19 Dec, 24 -
Очевидное Рядом
19 Dec, 24 -
Радио-Т №30. Бобук, Умпутун И Росновский :)
19 Dec, 24 -
Openoffice.org Pro 3.0.1 От Инфра-Ресурса
19 Dec, 24 -
Смс Против «Зеленой Змеи»
19 Dec, 24
