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

    С учетом роста данных в наше время все чаще говорится о программно-определяемых и распределенных хранилищах данных, причем немало внимания традиционно уделяется открытой платформе С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 кажутся вам наиболее важными?

    RedSys

    20,00

    Компания

    Поделиться публикацией
    Комментарии 18
      0
      А ещё Ceph можно сделать быстрым, используя Infiniband (RDMA). тык 1, тык 2.
        +9
        «Вывод 1: Сeph полностью заменяет все решения по резервному копированию»
        Это серьезно?
        Я дальше читать пока не буду, а то подгорает…
          0
          Самолет в виде бонуса — автомобиль, он же может перемещаться по летному полю.
          Ну да, подгорает
            0
            Да уж…

            Для тех кто не понял — данные могут теряться не только из-за сбоя системы хранения, но и из-за злонамеренных/идиотских действий. И тогда rm -rf /any_folder будет чистой совестью реплицирован на весь кластер.

            Так что бэкап бэкапом, а высокая доступность высокой доступностью.
              0
              Да классической схемы резервной копии и восстановления после сбоя или к моменту во времени нету и едва ли это нужно для всего кластера, который может быть очень и очень большим. От злонамеренных действий, логических ошибок в структурах хранения в результате программных ошибок и прочего резервирование конечно не спасёт, спасёт от аппаратного сбоя или физического повреждения узла.
                0
                Да нужно было просто сделать запрет на удаление и модификацию загруженных объектов — вот вам и бэкап :-)
                  0
                  Ок, положим я получил локального рута на нодах, грохнул конфиг цефа и ребутнул кластер. Как Вас этот чудо запрет спасет от увольнения?
                    0
                    Не ну от rm -rf, то на клиентской стороне защитит.

                    А вообще тег sarcasm нужно было мне поставить.
              0
              Нет конечно, это не серьёзно, а скорее провокационно. Ceph конечно не заменяет решения для резервного копирования всего (баз данных, почтовых очередей и т.п.), речь скорее о том, что объёмы которые обычно находятся в Ceph не подходят для обычных «автомобилей» т.е. систем резервного копирования – это дорого и долго. В Ceph нет бэкапов в классическом понимании – есть другие способы обеспечить сохранность данных – резервирование разнесение узлов – про что и написано в разделе с «провокационным» заголовком. Это конечно не классический бэкап – восстановить состояние хранилища к прошедшему моменту времени или восстановить ошибочно удалённый объект не получиться (если «корзина» удерживающая удалённые объекты не предусмотрена в решении, которое использует Ceph).
                0

                Самый простой способ оправдать ошибку — объявить ее намеренной. Особенно в интернете. Провокация, эксперимент, etc.


                У организации, которую вы представляете на хабре, такой же уровень понимания разницы между резервным копированием данных и резервированием элементов хранилища? Если да — то я бы никому не рекомендовал с вами иметь дело.


                Да, тоже подгорело. Сначала такую пургу льют в уши бизнесу, а потом он приходит с этим бредом к нам.

              0
              То, что ceph умеет все вышенаписанное, это известно всем, кто собственно слышал про него. Интересней как прикладной софт, внезапно, вместо Postgres начал использовать rados. Обычно именно этот вопрос интересует, как прозрачно переехать из какой-либо субд в хранилище.
              Как уже выше заметили, совершенно не раскрыт вопрос, как защищаться от аналога rm -rf / data или delete from table —where 1=2
                0
                Никто из присутствующих не в курсе, можно ли сделать копию версионируемого бакета с сохранением идентификаторов версий в новый бакет/другой кластер?

                Это на тему «Бекапы не нужны»:
                Сейчас мы имеем волшебную ситуацию когда в Ceph Jewel репликация работает некорректно и «воскрешает» удаленные версии (не объекты помеченные как удаленные, а именно удаленные конкретные версии документов). Обновить Jewel до Luminous на бою очень боязно (бекапов то нет), потому что апгрейд stage кластера развалил его чуть более чем полностью (что не удивительно, кластер старенький, часть данных протерялось, часть индексов не соответствует действительности, потому что он уже пережил несколько минорных обновлений чтобы починить то что сломали в предыдущих версиях)
                  0
                  При внедрении Сeph резервное копирование получается как бы «в виде бонуса». Просто задаем при настройке параметры репликации – количество копий и локации их размещения.

                  Когда уже переведутся «инженеры», которые считают что реплику или снепшот можно хотя бы близко называть «бекапом» данных.
                    +1
                    Никогда…
                    Более животрепещущий вопрос: `когда на фразу «это ни разу не бэкап» они перестанут оправдываться и доказывать свою правоту?`
                      0
                      Никогда…

                      От этого и больно.
                    0
                    Какая-то очередная маркетинговая статья. Да ещё с ошибками про бэкапы…
                    Что, нет нормальных технарей написать с какими проблемами столкнулись и как решали?
                      +1
                      Как говорил один футбольный комментатор: «Я сейчас закончу вообще все!».

                      > Вывод 1: Сeph полностью заменяет все решения по резервному копированию
                      Не вводите людей в заблуждение! Никакая супер-мега-отказоустойчивая хранилка никогда не была и не будет решением для бэкапов. Почитайте про одного облачного провайдера Cloud Mouse, и то, как бесславно они закончили свой путь. У них был Цеф и не было бэкапов. Действительно, зачем бэкапы, когда есть Цеф? Разве что-то может в Цефе пойти не так? Конечно же, нет, думали они. Разве в Цефе могут быть баги? Конечно нет, думали они.

                      Я сам лично имел опыт с Цефом, когда в нем что-то шло очень сильно не так (собственно, был серьезный баг в самом Цефе, пришлось за кучу денег вызывать Red Hat). И бэкапов у нас тоже не было, вернее до них просто не дошли руки. Не повторяйте наших ошибок.

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

                      > катастрофоустойчивая конфигурация, которая просто не требует дополнительного резервного копирования при наличии – 3-4 копий данных на разных дисках и серверах. Работает такая система гарантировано лучше, чем любое аппаратное решение

                      И такая система не только работает лучше, но и стоит больше чем, наверное, добрая часть аппаратных решений на рынке. При огромных объемах данных репликация становится чрезмерно дорогостоящим удовольствием, несмотря на все ее очевидные преимущества. Сколько данных вы храните?

                      И последнее. Вас ждет множество сюрпризов с Цефом, которые заставят вас изменить точку зрения, высказанную в статье.
                        0
                        Я б добавил про производительность при замене больших хардов.
                        Колом встает все что может — синхронизация ж :(

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое