Главная » Хабрахабр » Сeph как подключаемое хранилище: 5 практических выводов из крупного проекта

Сeph как подключаемое хранилище: 5 практических выводов из крупного проекта

С учетом роста данных в наше время все чаще говорится о программно-определяемых и распределенных хранилищах данных, причем немало внимания традиционно уделяется открытой платформе Сeph. Сегодня мы хотим рассказать о тех выводах, к которым мы пришли в процессе реализации проекта по хранению данных для одного крупного российского ведомства.

Чисто теоретически плюсов у таких решений много: можно использовать любые диски, система работает на любых серверах (даже весьма старых), пределов масштабированию практически нет. Когда речь заходит о хранении данных разных типов, конечно, сразу приходит на ум распределенное хранилище данных. Именно поэтому внедрение такой системы было запущено несколько лет назад в одном из крупных российских ведомств с подразделениями не только во всех регионах Российской Федерации, но даже во всех более-менее крупных городах.

Этому решению был целый ряд причин:
• Сeph представляет собой достаточно зрелый продукт, и уже на сегодняшний день есть инсталляции Сeph на петабайты информации.
• Развитием занимается большое сообщество (в том числе и мы), а значит для хранилища будут появляться новые функции и улучшения.
• У Сeph уже имеется хорошее API с поддержкой различных языков программирования. После анализа доступных решений выбор был сделан в пользу Сeph. Нет, конечно, систему нужно дорабатывать, но в случае со специфическими задачами заказчика, вести дополнительную разработку пришлось бы все равно, так почему не сделать это на базе бесплатного продукта?
• Наконец, санкции. Это было важно, потому что продукт, очевидно, нужно было допиливать для соответствия требованиям и ожиданиям заказчика.
• Лицензии ничего не стоят. Другое дело, Open Source. Государственные компании должны быть застрахованы от того, что в следующий момент времени кому-то придет в голову идея наложить на них ограничения, и поэтому полагаться на зарубежный и особенно американский продукт оказывается опасно.

Сначала хранилище было запущено в центральном регионе, а потом мы тиражировали решение, подключая региональные ЦОД. Практические выводы
Внедрение Сeph происходило постепенно на протяжении нескольких месяцев. Как показывает практика, сотрудникам просто некогда разбираться, что это за файлы, категорировать их и обрабатывать своевременно – информация успевает накапливаться быстрее. С появлением каждого нового узла сети производительность хранилища возрастала, несмотря на увеличение потоков данных внутри него, обеспечивающих передачу информации из региона в регион.
Особенностью работы любой крупной организации является потребность сохранять разнородную информацию, которая часто представляет собой бинарные файлы. Например, на базе распределенного хранилища.
И в процессе реализации такого проекта мы сделали несколько выводов по использованию Сeph: И чтобы не потерять потенциально важные для операционной деятельности данные, необходимо организовать их грамотное хранение.

При внедрении Сeph резервное копирование получается как бы «в виде бонуса». Вывод 1: Сeph полностью заменяет все решения по резервному копированию
Как показала практика, резервное копирование для большинства неструктурированной информации и вовсе не производится, так как реализовать его крайне сложно. В случае если у заказчика есть несколько ЦОДов, получается катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Просто задаем при настройке параметры репликации – количество копий и локации их размещения. Работает такая система гарантировано лучше, чем любое аппаратное решение, по крайней мере пока речь идет о больших объемах данных и территориально-распределенных системах.

Если в каких-то случаях это было не так, реконфигурирование Сeph позволяло добиться этой скорости. Вывод 2: При больших инсталляциях производительность Сeph на 99% равна производительности сети.
Когда мы переносили данные из БД PostgreSQL (об этом чуть ниже) в хранилище на базе Сeph, скорость «заливки» в большинстве случаев равнялась пропускной способности сети передачи данных. Достаточно правильно распределить диски и настроить кластеризацию информации. Конечно, тут речь не идет о соединениях в 100 Гбит/с, но при стандартных для территориально-распределенных инфраструктур каналов данных вполне реально добиться дот Сeph производительности на уровне 10 Мбит/с, 100 Мбит/с или 1 Гбит/с.

Кроме параметров репликации решение также позволяет задать уровни доступа, правила сохранения данных и так далее. Вывод 3: Главное – правильно провести настройку Сeph с учетом особенностей деятельности компании
Кстати, о настройках – самая большая часть экспертизы в работе Сeph требуется на этапе конфигурирования системы. Последний будет работать с несколько большими задержками и меньшей скоростью, но такая «концентрация» информации по месту принадлежности создает оптимальные условия для работы организации. Например, если у нас есть мини-вычислительные центры по всей России, мы можем организовать оперативный доступ к документам и файлам, созданным в своем регионе, а также доступ ко всем корпоративным документам откуда угодно.

То есть оказалось, что в удаленных мини-ЦОД достаточно содержать просто администратора Linux, так как поддержка очередного сегмента Сeph не требует никаких дополнительных знаний. Вывод 4: Когда он уже настроен, управлять Сeph может любой администратор Linux
Пожалуй, одна из самых приятных особенностей Сeph заключается в том, что система работает без лишнего участия человека, когда она уже настроена.

Поэтому при занесении объекта в хранилище можно сохранять мета-данные, служащие индексом. Вывод 5: Дополнение Сeph внешней системой индексации делает хранилище удобным для контекстного поиска
Как известно, внутри Сeph нет индекса, который можно использовать для поиска по контексту. Конечно, это дополнительная система, но зато такой подход позволяет быстро находить информацию по контексту среди огромных объемов неструктурированных данных. Их объем достаточно мал, и поэтому с ними легко справляется обычная реляционная СУБД.

После запуска Сeph возникла задача мигрировать данные из множества БД, не останавливая при этом сервисы и бизнес-процессы и обеспечивая целостность информации.
Чтобы сделать это, нам пришлось внести свой вклад в развитие Open Source-проекта Сeph и создать модуль миграции pg_rbytea, исходный код которого можно найти по ссылке (https://github.com/val5244/pg_rbytea). Несколько слов о переносе данных
Большой проект подразумевает множество этапов, но самым интересным для нас, пожалуй, был процесс переноса огромных массивов данных из PostgreSQL в новое хранилище. Разработанный модуль позволяет одномоментно мигрировать данные без остановки БД, используя абстракцию объектного хранилища Rados, поддержке которой реализована в Сeph на нативном уровне. Суть решения заключалась в том, чтобы одномоментно перенести данные из указанной БД в хранилище Сeph. Фактически все те файлы и объекты, которые непонятно как хранить из-за их огромного суммарного объема и нечеткой структуры. Кстати, об этом мы делали доклад на PG Conf в начале 2018 года (https://pgconf.ru/2018/107082).
На первом этапе в хранилище были перемещены различные бинарные данные, необходимые для функциональной работы подразделений ведомства. Здесь снова сыграло роль наличие удобного API, который позволяет создать подключаемый сервис для различных информационных систем. Далее запланирован перенос на Сeph различного медийного контента, хранение оригиналов документов, которые создаются перед распознаванием и вложений из корпоративных писем.
Чтобы все это работало поверх хранилища были разработаны RESTful-сервисы, которые позволили использовать Сeph для интеграции в системы заказчика. Так Сeph и стал основным хранилищем, претендующим на все новые и новые объемы и типы информации в рамках организации.

Некоторые из них используют специальные оптимизации, другие – работают со сжатием или применяют Erasure Coding. Заключение
На рынке представлены разные распределенные хранилища данных, в том числе коммерческие решения и другие продукты с открытым исходным кодом. Грамотно настроенная система Сeph позволяет обеспечить оптимальную работу при минимальном присмотре со стороны локальных администраторов на местах. Однако мы на практике убедились в том, что Сeph идеально подходит для действительно распределенных сред и огромных хранилищ, потому что в этом случае производительность системы ограничивается лишь скоростью работы каналов связи, и вы экономите огромные деньги на лицензиях по количеству серверов или по объему данных (смотря с каким продуктом сравнивать). И это серьезное преимущество, если вы введете территориально-распределенное внедрение.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] WiX.Py: cобираем MSI пакет «в три строчки»

Хотите собирать инсталлер, описывая его простыми и понятными терминами, в несколько строк? Нет времени и желания изучать километровые файлы WiX, чтобы собрать MSI инсталлер для своего проекта, погружаясь при этом в бездны MSDN? Ну тогда вам под кат! Есть клиническая ...

[Из песочницы] Определяем спелость арбуза с помощью Keras: полный цикл, от идеи до программы на Google Play

С чего все началось Все началось с Эппл Маркета — я обнаружил, что у них есть программа, позволяющая определить спелость арбуза. Программа… странная. Чего стоит, хотя бы, предложение постучать по арбузу не костяшками пальцев, а… телефоном! Тем не менее, мне ...