С учетом роста данных в наше время все чаще говорится о программно-определяемых и распределенных хранилищах данных, причем немало внимания традиционно уделяется открытой платформе Сeph. Сегодня мы хотим рассказать о тех выводах, к которым мы пришли в процессе реализации проекта по хранению данных для одного крупного российского ведомства.
Когда речь заходит о хранении данных разных типов, конечно, сразу приходит на ум распределенное хранилище данных. Чисто теоретически плюсов у таких решений много: можно использовать любые диски, система работает на любых серверах (даже весьма старых), пределов масштабированию практически нет. Именно поэтому внедрение такой системы было запущено несколько лет назад в одном из крупных российских ведомств с подразделениями не только во всех регионах Российской Федерации, но даже во всех более-менее крупных городах.
После анализа доступных решений выбор был сделан в пользу Сeph. Этому решению был целый ряд причин:
• Сeph представляет собой достаточно зрелый продукт, и уже на сегодняшний день есть инсталляции Сeph на петабайты информации.
• Развитием занимается большое сообщество (в том числе и мы), а значит для хранилища будут появляться новые функции и улучшения.
• У Сeph уже имеется хорошее API с поддержкой различных языков программирования. Это было важно, потому что продукт, очевидно, нужно было допиливать для соответствия требованиям и ожиданиям заказчика.
• Лицензии ничего не стоят. Нет, конечно, систему нужно дорабатывать, но в случае со специфическими задачами заказчика, вести дополнительную разработку пришлось бы все равно, так почему не сделать это на базе бесплатного продукта?
• Наконец, санкции. Государственные компании должны быть застрахованы от того, что в следующий момент времени кому-то придет в голову идея наложить на них ограничения, и поэтому полагаться на зарубежный и особенно американский продукт оказывается опасно. Другое дело, Open Source.
Практические выводы
Внедрение Сeph происходило постепенно на протяжении нескольких месяцев. Сначала хранилище было запущено в центральном регионе, а потом мы тиражировали решение, подключая региональные ЦОД. С появлением каждого нового узла сети производительность хранилища возрастала, несмотря на увеличение потоков данных внутри него, обеспечивающих передачу информации из региона в регион.
Особенностью работы любой крупной организации является потребность сохранять разнородную информацию, которая часто представляет собой бинарные файлы. Как показывает практика, сотрудникам просто некогда разбираться, что это за файлы, категорировать их и обрабатывать своевременно – информация успевает накапливаться быстрее. И чтобы не потерять потенциально важные для операционной деятельности данные, необходимо организовать их грамотное хранение. Например, на базе распределенного хранилища.
И в процессе реализации такого проекта мы сделали несколько выводов по использованию Сeph:
Вывод 1: Сeph полностью заменяет все решения по резервному копированию
Как показала практика, резервное копирование для большинства неструктурированной информации и вовсе не производится, так как реализовать его крайне сложно. При внедрении Сeph резервное копирование получается как бы «в виде бонуса». Просто задаем при настройке параметры репликации – количество копий и локации их размещения. В случае если у заказчика есть несколько ЦОДов, получается катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Работает такая система гарантировано лучше, чем любое аппаратное решение, по крайней мере пока речь идет о больших объемах данных и территориально-распределенных системах.
Вывод 2: При больших инсталляциях производительность Сeph на 99% равна производительности сети.
Когда мы переносили данные из БД PostgreSQL (об этом чуть ниже) в хранилище на базе Сeph, скорость «заливки» в большинстве случаев равнялась пропускной способности сети передачи данных. Если в каких-то случаях это было не так, реконфигурирование Сeph позволяло добиться этой скорости. Конечно, тут речь не идет о соединениях в 100 Гбит/с, но при стандартных для территориально-распределенных инфраструктур каналов данных вполне реально добиться дот Сeph производительности на уровне 10 Мбит/с, 100 Мбит/с или 1 Гбит/с. Достаточно правильно распределить диски и настроить кластеризацию информации.
Вывод 3: Главное – правильно провести настройку Сeph с учетом особенностей деятельности компании
Кстати, о настройках – самая большая часть экспертизы в работе Сeph требуется на этапе конфигурирования системы. Кроме параметров репликации решение также позволяет задать уровни доступа, правила сохранения данных и так далее. Например, если у нас есть мини-вычислительные центры по всей России, мы можем организовать оперативный доступ к документам и файлам, созданным в своем регионе, а также доступ ко всем корпоративным документам откуда угодно. Последний будет работать с несколько большими задержками и меньшей скоростью, но такая «концентрация» информации по месту принадлежности создает оптимальные условия для работы организации.
Вывод 4: Когда он уже настроен, управлять Сeph может любой администратор Linux
Пожалуй, одна из самых приятных особенностей Сeph заключается в том, что система работает без лишнего участия человека, когда она уже настроена. То есть оказалось, что в удаленных мини-ЦОД достаточно содержать просто администратора Linux, так как поддержка очередного сегмента Сeph не требует никаких дополнительных знаний.
Вывод 5: Дополнение Сeph внешней системой индексации делает хранилище удобным для контекстного поиска
Как известно, внутри Сeph нет индекса, который можно использовать для поиска по контексту. Поэтому при занесении объекта в хранилище можно сохранять мета-данные, служащие индексом. Их объем достаточно мал, и поэтому с ними легко справляется обычная реляционная СУБД. Конечно, это дополнительная система, но зато такой подход позволяет быстро находить информацию по контексту среди огромных объемов неструктурированных данных.
Несколько слов о переносе данных
Большой проект подразумевает множество этапов, но самым интересным для нас, пожалуй, был процесс переноса огромных массивов данных из PostgreSQL в новое хранилище. После запуска Сeph возникла задача мигрировать данные из множества БД, не останавливая при этом сервисы и бизнес-процессы и обеспечивая целостность информации.
Чтобы сделать это, нам пришлось внести свой вклад в развитие Open Source-проекта Сeph и создать модуль миграции pg_rbytea, исходный код которого можно найти по ссылке (https://github.com/val5244/pg_rbytea). Суть решения заключалась в том, чтобы одномоментно перенести данные из указанной БД в хранилище Сeph. Разработанный модуль позволяет одномоментно мигрировать данные без остановки БД, используя абстракцию объектного хранилища Rados, поддержке которой реализована в Сeph на нативном уровне. Кстати, об этом мы делали доклад на PG Conf в начале 2018 года (https://pgconf.ru/2018/107082).
На первом этапе в хранилище были перемещены различные бинарные данные, необходимые для функциональной работы подразделений ведомства. Фактически все те файлы и объекты, которые непонятно как хранить из-за их огромного суммарного объема и нечеткой структуры. Далее запланирован перенос на Сeph различного медийного контента, хранение оригиналов документов, которые создаются перед распознаванием и вложений из корпоративных писем.
Чтобы все это работало поверх хранилища были разработаны RESTful-сервисы, которые позволили использовать Сeph для интеграции в системы заказчика. Здесь снова сыграло роль наличие удобного API, который позволяет создать подключаемый сервис для различных информационных систем. Так Сeph и стал основным хранилищем, претендующим на все новые и новые объемы и типы информации в рамках организации.
Заключение
На рынке представлены разные распределенные хранилища данных, в том числе коммерческие решения и другие продукты с открытым исходным кодом. Некоторые из них используют специальные оптимизации, другие – работают со сжатием или применяют Erasure Coding. Однако мы на практике убедились в том, что Сeph идеально подходит для действительно распределенных сред и огромных хранилищ, потому что в этом случае производительность системы ограничивается лишь скоростью работы каналов связи, и вы экономите огромные деньги на лицензиях по количеству серверов или по объему данных (смотря с каким продуктом сравнивать). Грамотно настроенная система Сeph позволяет обеспечить оптимальную работу при минимальном присмотре со стороны локальных администраторов на местах. И это серьезное преимущество, если вы введете территориально-распределенное внедрение.
Когда речь заходит о хранении данных разных типов, конечно, сразу приходит на ум распределенное хранилище данных. Чисто теоретически плюсов у таких решений много: можно использовать любые диски, система работает на любых серверах (даже весьма старых), пределов масштабированию практически нет. Именно поэтому внедрение такой системы было запущено несколько лет назад в одном из крупных российских ведомств с подразделениями не только во всех регионах Российской Федерации, но даже во всех более-менее крупных городах.
После анализа доступных решений выбор был сделан в пользу Сeph. Этому решению был целый ряд причин:
• Сeph представляет собой достаточно зрелый продукт, и уже на сегодняшний день есть инсталляции Сeph на петабайты информации.
• Развитием занимается большое сообщество (в том числе и мы), а значит для хранилища будут появляться новые функции и улучшения.
• У Сeph уже имеется хорошее API с поддержкой различных языков программирования. Это было важно, потому что продукт, очевидно, нужно было допиливать для соответствия требованиям и ожиданиям заказчика.
• Лицензии ничего не стоят. Нет, конечно, систему нужно дорабатывать, но в случае со специфическими задачами заказчика, вести дополнительную разработку пришлось бы все равно, так почему не сделать это на базе бесплатного продукта?
• Наконец, санкции. Государственные компании должны быть застрахованы от того, что в следующий момент времени кому-то придет в голову идея наложить на них ограничения, и поэтому полагаться на зарубежный и особенно американский продукт оказывается опасно. Другое дело, Open Source.
Практические выводы
Внедрение Сeph происходило постепенно на протяжении нескольких месяцев. Сначала хранилище было запущено в центральном регионе, а потом мы тиражировали решение, подключая региональные ЦОД. С появлением каждого нового узла сети производительность хранилища возрастала, несмотря на увеличение потоков данных внутри него, обеспечивающих передачу информации из региона в регион.
Особенностью работы любой крупной организации является потребность сохранять разнородную информацию, которая часто представляет собой бинарные файлы. Как показывает практика, сотрудникам просто некогда разбираться, что это за файлы, категорировать их и обрабатывать своевременно – информация успевает накапливаться быстрее. И чтобы не потерять потенциально важные для операционной деятельности данные, необходимо организовать их грамотное хранение. Например, на базе распределенного хранилища.
И в процессе реализации такого проекта мы сделали несколько выводов по использованию Сeph:
Вывод 1: Сeph полностью заменяет все решения по резервному копированию
Как показала практика, резервное копирование для большинства неструктурированной информации и вовсе не производится, так как реализовать его крайне сложно. При внедрении Сeph резервное копирование получается как бы «в виде бонуса». Просто задаем при настройке параметры репликации – количество копий и локации их размещения. В случае если у заказчика есть несколько ЦОДов, получается катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Работает такая система гарантировано лучше, чем любое аппаратное решение, по крайней мере пока речь идет о больших объемах данных и территориально-распределенных системах.
Вывод 2: При больших инсталляциях производительность Сeph на 99% равна производительности сети.
Когда мы переносили данные из БД PostgreSQL (об этом чуть ниже) в хранилище на базе Сeph, скорость «заливки» в большинстве случаев равнялась пропускной способности сети передачи данных. Если в каких-то случаях это было не так, реконфигурирование Сeph позволяло добиться этой скорости. Конечно, тут речь не идет о соединениях в 100 Гбит/с, но при стандартных для территориально-распределенных инфраструктур каналов данных вполне реально добиться дот Сeph производительности на уровне 10 Мбит/с, 100 Мбит/с или 1 Гбит/с. Достаточно правильно распределить диски и настроить кластеризацию информации.
Вывод 3: Главное – правильно провести настройку Сeph с учетом особенностей деятельности компании
Кстати, о настройках – самая большая часть экспертизы в работе Сeph требуется на этапе конфигурирования системы. Кроме параметров репликации решение также позволяет задать уровни доступа, правила сохранения данных и так далее. Например, если у нас есть мини-вычислительные центры по всей России, мы можем организовать оперативный доступ к документам и файлам, созданным в своем регионе, а также доступ ко всем корпоративным документам откуда угодно. Последний будет работать с несколько большими задержками и меньшей скоростью, но такая «концентрация» информации по месту принадлежности создает оптимальные условия для работы организации.
Вывод 4: Когда он уже настроен, управлять Сeph может любой администратор Linux
Пожалуй, одна из самых приятных особенностей Сeph заключается в том, что система работает без лишнего участия человека, когда она уже настроена. То есть оказалось, что в удаленных мини-ЦОД достаточно содержать просто администратора Linux, так как поддержка очередного сегмента Сeph не требует никаких дополнительных знаний.
Вывод 5: Дополнение Сeph внешней системой индексации делает хранилище удобным для контекстного поиска
Как известно, внутри Сeph нет индекса, который можно использовать для поиска по контексту. Поэтому при занесении объекта в хранилище можно сохранять мета-данные, служащие индексом. Их объем достаточно мал, и поэтому с ними легко справляется обычная реляционная СУБД. Конечно, это дополнительная система, но зато такой подход позволяет быстро находить информацию по контексту среди огромных объемов неструктурированных данных.
Несколько слов о переносе данных
Большой проект подразумевает множество этапов, но самым интересным для нас, пожалуй, был процесс переноса огромных массивов данных из PostgreSQL в новое хранилище. После запуска Сeph возникла задача мигрировать данные из множества БД, не останавливая при этом сервисы и бизнес-процессы и обеспечивая целостность информации.
Чтобы сделать это, нам пришлось внести свой вклад в развитие Open Source-проекта Сeph и создать модуль миграции pg_rbytea, исходный код которого можно найти по ссылке (https://github.com/val5244/pg_rbytea). Суть решения заключалась в том, чтобы одномоментно перенести данные из указанной БД в хранилище Сeph. Разработанный модуль позволяет одномоментно мигрировать данные без остановки БД, используя абстракцию объектного хранилища Rados, поддержке которой реализована в Сeph на нативном уровне. Кстати, об этом мы делали доклад на PG Conf в начале 2018 года (https://pgconf.ru/2018/107082).
На первом этапе в хранилище были перемещены различные бинарные данные, необходимые для функциональной работы подразделений ведомства. Фактически все те файлы и объекты, которые непонятно как хранить из-за их огромного суммарного объема и нечеткой структуры. Далее запланирован перенос на Сeph различного медийного контента, хранение оригиналов документов, которые создаются перед распознаванием и вложений из корпоративных писем.
Чтобы все это работало поверх хранилища были разработаны RESTful-сервисы, которые позволили использовать Сeph для интеграции в системы заказчика. Здесь снова сыграло роль наличие удобного API, который позволяет создать подключаемый сервис для различных информационных систем. Так Сeph и стал основным хранилищем, претендующим на все новые и новые объемы и типы информации в рамках организации.
Заключение
На рынке представлены разные распределенные хранилища данных, в том числе коммерческие решения и другие продукты с открытым исходным кодом. Некоторые из них используют специальные оптимизации, другие – работают со сжатием или применяют Erasure Coding. Однако мы на практике убедились в том, что Сeph идеально подходит для действительно распределенных сред и огромных хранилищ, потому что в этом случае производительность системы ограничивается лишь скоростью работы каналов связи, и вы экономите огромные деньги на лицензиях по количеству серверов или по объему данных (смотря с каким продуктом сравнивать). Грамотно настроенная система Сeph позволяет обеспечить оптимальную работу при минимальном присмотре со стороны локальных администраторов на местах. И это серьезное преимущество, если вы введете территориально-распределенное внедрение.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какие преимущества Сeph кажутся вам наиболее важными?
43.9% Открытый исходный код18
53.66% Активная работа сообщества22
41.46% Отсутствие лицензионных платежей17
24.39% Наличие готовых «кейсов» использования в разных сферах10
31.71% Никакие13
Проголосовал 41 пользователь. Воздержались 22 пользователя.
