- PVSM.RU - https://www.pvsm.ru -
Перемещение вычислений в сторону данных может приводить к снижению временных затрат на порядки за счёт исключения необходимости перемещения самих данных в сетевой среде. Этой цели служит класс RADOS, вызовы к которому могут выполняться функциями librados.
Асинхронная система сообщений существенно снижает накладные расходы сетевого уровня Ceph, а применение абстракций NetworkStack делает возможной реализацию различных протоколов стека (POSIX/ SPDK/ DPDK/ RDMA).
Для достижения максимальной производительности и внутренней гибкости Ceph можно применять встроенные в библиотеку librados
вызовы функций, доступные для большинства языком программирования, например, для C, C++, Python, PHP и Java. С этой целью вы сначала устанавливаете инструменты разработки. Например, для Debian- дистрибутивов:
$ sudo apt-get install build-essential
$ sudo apt-get install librados-dev
Затем в своём приложении вы:
ceph.conf
для получения мониторов(Пример приложения [1])
Порой приложение требует атомарности выполняемой операции, состоящей из нескольких действий, например, из записи собственно данных и их атрибутов. То есть, если в процессе выполнения атомарной (неделимой) последовательности действий происходит какое- либо прерывание или некий сбой, отвергаются все уже выполненные действия. Реальной записи или изменения не происходит. Долгое время разработчики Ceph не теряли надежды на поддержку атомарности за счёт средств btrfs, поскольку её реализация в рамках xfs приводит к снежному кому проблем, самой малой из которых является необходимость, как минимум, дублированной записи. В конце концов, начиная с выпуска Kraken для лежащего в основе OSD хранилища было принято решение по умолчанию отказываться от файлового хранения с применением POSIX файловых систем и применять упрощённую файловую систему BlueFS для хранения собственно данных и RocksDB для хранения метаданных и, возможно, отложенных записей (WAL, write-ahead log). Данное хранилище получило название BlueStore (указывающая на Blочную природу хранилища, изначально имевшего незатейливое название NewStore). Подробнее... [2]
Теперь, имея в руках полноценную реализацию транзакций, не отягощённую избыточными накладными расходами, мы со спокойной совестью можем их использование в своих приложениях. Посмотрим как меняется скелет нашей программы:
ceph.conf
для получения мониторов(Пример приложения [3])
Ещё одной достойной функциональностью librados
является организация приложений наблюдатель- уведомитель (watch — notify).
Работа наблюдателя организуется путём обратного вызова (callback). При создании наблюдателя через вызов соответствующей функции вы передаёте в таком вызове двумя параметрами ссылки на необходимые функции обратного вызова. Первая применяется для выполнения действия в случае получения уведомления, а вторая используется когда что-то пошло не так, в ней вы производите необходимые действия по отработке ошибок.
Например, таким образом вы создаёте моментальный снимок некоторого объекта. Клиент, которому требуется выполнить такой снимок, отправляет всем находящимся в ожидании для данного объекта клиентам (watcher) уведомления (выступая в качестве notifier), в котором он сообщает, что может сбросить свой кэш данного объекта и выполнить проверку на непротиворечивость данных.
(Пример приложения [4])
Библиотека librados
работает с объектами, хранящимися в распределённой системе хранения RADOS
(Reliable Autonomic Distributed Object Store), в основе которого лежат демоны хранения объектов (OSD, Object Storage Daemon), каждый из которых обслуживает некое собственное хранилище (например, уже упоминавшееся BlueStore [2]).
Одним из примечательных свойств OSD является возможность локальной обработки хранимых в нём данных методами класса RADOS
. Это открывает широкие возможности революционного увеличения производительности распределённой обработки хранимых данных, поскольку избавляет вас от необходимости обмена самими данными для такой обработки.
Например, вы можете вычислять хеш-значения и контрольные суммы данного объекта, осуществлять их проверку. Вы можете выполнять поиск в таких данных и их анализ, выставляя результаты, скажем, в метаданных самого объекта.
Одним из простейших способов такой разработки является применение языка сценариев Lua [5], который, начиная с выпуска Kraken встроен в класс RADOS
. Данный сценарий, как правило, в виде строк JSON (скажем, в программе с применением librados
на Python) передаётся в имеющийся объект класса RADOS
, где он и исполняется.
Пример приложения изменения в объекте всех строчных букв на прописные [6]. Отметим, что по умолчанию исполнение сценариев Lua в OSD отключено, для включения такой возможности необходимо внести приведённые в примере изменения в файлы настроек OSD.
К сожалению, в настоящее время функциональные возможности языка сценариев Lua достаточно ограничены. Для решения более сложных задач вам придётся скомпилировать исходный код Ceph со встроенным в него классом RADOS
, написанным, например, на C или C++. В Примере приложения вычисления MD5 объекта [7] приводятся пошаговые инструкции построения такого решения, а также сопоставляются результаты времён его работы в сравнении с аналогичным приложением, исполняющимся на клиенте, находящимся не на узле OSD и вынужденном считывать данные с OSD и записывать в него результат расчёта. результат сравнения даёт преимущество в абсолютных затратах времени в два порядка.
Поскольку данный метод обработки может приводить в случае ошибок к утрате данных и нарушению работы самого OSD, естественно, все применяемые методы должны быть тщательно проверены и иметь всеобъемлющие средства обработки ошибок.
Дополнительные средства для распределённой обработки данных предоставляет имеющаяся в Ceph система асинхронного обмена сообщениями. Например, таким образом реализован механизм применения RDMA [8] в реализации Mellanox.
Первоначально AsyncMessenger
, судя по всему, разрабатывался в качестве расширения epoll
, призванного полностью вытеснить SimpleMessenger
, являющийся первоначальной системой обмена сообщений и лежащей в основе сетевого протокола Ceph. Такая потребность вызвана тем фактом, что для каждой пары участников однорангового взаимодействия (peering) в SimpleMessenger
создаются 4 потока (по два с каждой стороны). С ростом числа участников это приводит к экспоненциальному росту общего числа потоков (thread) в узлах участников.
В настоящее время все три метода реализуют сетевой протокол Ceph, при этом применяя один общий рабочий пул.
В протоколе AsyncMessenger
участвуют сервер и клиент. Сервер выполняет инициализацию, привязывается к file descriptor (fd) и осуществляет ожидание уведомлений по нему (listen). В отличие от определённых POSIX методов select() и poll(), epoll [9]
предоставляет механизм обработки сообщений со сложностью O(1), в отличие от O(n) для SimpleMessenger
, исключая перебор событий, не имеющих активных fd. AsyncMessenger
применяет библиотеку libevent
, предоставляемую средствами epoll.
Обработка события осуществляется сервером по получению уведомления на fd, либо по тайм- ауту. Помимо этого сервер может добавлять ожидание fd, принимать соединения, добавлять приём fd и осуществлять взаимодействие.
Клиент инициирует установление соединения и устанавливает его для выполнения взаимодействия. Весь обмен сетевого уровня приложений обрабатывается машиной состояний AsyncConnection
. Статья Wei Jin [10] акцентирует основные моменты данного типа взаимодействия.
Дальнейшим развитием механизма AsyncMessenger
является развитие абстракции NetworkStack
, которая позволяет осуществлять распределённую поддержку различных сетевых стеков (Posix/ DPDK/ RDMA), а также встроенной в BlueStore поддержки SPDK.
Данный уровень абстракции реализует понятия ServerSocket
и ConnectedSocket
, причём первый ожидает поступления запросов, а второй собственно и осуществляет чтение и запись всех данных. Основные моменты реализации приложений с применением данных абстракций приводятся в статье Стек асинхронной системы сообщений Ceph [11] того же Wei Jin.
Материалы:
Автор: OlegBou
Источник [23]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/vy-sokaya-proizvoditel-nost/257917
Ссылки в тексте:
[1] Пример приложения: http://onreader.mdl.ru/MasteringCeph/content/Ch05.html#03
[2] Подробнее...: http://onreader.mdl.ru/MasteringCeph/content/Ch03.html
[3] Пример приложения: http://onreader.mdl.ru/MasteringCeph/content/Ch05.html#0301
[4] Пример приложения: http://onreader.mdl.ru/MasteringCeph/content/Ch05.html#0302
[5] Lua: http://www.lua.org/pil/contents.html
[6] Пример приложения изменения в объекте всех строчных букв на прописные: http://onreader.mdl.ru/MasteringCeph/content/Ch06.html#02
[7] Примере приложения вычисления MD5 объекта: http://onreader.mdl.ru/MasteringCeph/content/Ch06.html#03
[8] RDMA: http://onreader.mdl.ru/MasteringCeph/content/AppA.html#01
[9] epoll: https://ru.wikipedia.org/wiki/Epoll
[10] Статья Wei Jin: http://onreader.mdl.ru/MasteringCeph/content/AppA.html#03
[11] Стек асинхронной системы сообщений Ceph: http://onreader.mdl.ru/MasteringCeph/content/AppA.html#04
[12] Полное руководство Ceph: http://onreader.mdl.ru/MasteringCeph/content/index.html
[13] Книга рецептов Ceph: http://http://onreader.mdl.ru/CephCookbook/content/index.html
[14] Proxmox. Полное руководство. 2е изд: http://onreader.mdl.ru/MasteringProxmox.2ed/content/index.html
[15] Книга рецептов Proxmox: http://onreader.mdl.ru/ProxmoxCookbook/content/index.html
[16] Стек протоколов Mellanox OFED: http://onreader.mdl.ru/CephCookbook/content/MellanoxOFED.html
[17] Контейнеризация при помощи LXC: http://onreader.mdl.ru/ContainerizationWithLXC/content/index.html
[18] Zabbix. Полное руководство. 2е изд.: http://onreader.mdl.ru/MasteringZabbix.2ed/content/Ch04.html
[19] Пример системы виртуализации: http://onreader.mdl.ru/CephCookbook/content/VirtualizationExample.html
[20] Рекомендуемые розничные цены CPU Intel Xeon E5 v4/v3: http://onreader.mdl.ru/CephCookbook/content/Ch08.html#iCPUprices
[21] Обзор рекомендуемых аппаратных средств: http://onreader.mdl.ru/SDDC/content/Ch01.html#01
[22] sddc.mdl.ru: http://sddc.mdl.ru
[23] Источник: https://habrahabr.ru/post/330908/
Нажмите здесь для печати.