Имеется несколько миллионов файлов, занимающих порядка 1Тб. То есть, средний размер файла — около 250Кб. Файлы только добавляются. Скорость добавления — небольшая. Порядка 25Мб/день. Скорость чтения — порядка 5Мб/с.
Сейчас они хранятся на одном сервере и его ресурсы подходят к концу. Хочется:
1) избавится от единой точки отказа.
2) сделать решение масштабируемым хотя бы в 10 раз.
3) для этого есть 3 сервера, на которых сильно загружен процессор, но диски и память свободны.
4) чтобы в случае выхода из строя одного из серверов, всё восстанавливалось само.
Какие варианты я рассмотрел:
1) ceph. Cephfs — слишком сырая (о чём они сами пишут). Если использовать как блочное устройство, то нужно ядро 3.4+ (а у меня rhel6 — ядро 2.6) + скорость одиночных запросов там не очень быстрая. Плюс они плохо уживаются с другими приложениями на одном сервере.
2) drbd. С его помощью можно избавится от единой точки отказа. Но с масштабированием у него всё плохо. Максимум 3 реплики. В режиме master-master может требовать ручного вмешательства при падении одного из серверов для решения проблем split-brain. Понятия кворум не знает.
3) glusterfs. Есть ощущение, что проект сырой, как и ceph. На форуме видел топик «у меня в последней стабильной версии 3.3.1 зависла фс. Что делать?» — без ответа неделю. На хабре тоже была два поста от одного автора про настройку glusterfs. Во втором автор пишет, что пришлось перейти на новую версию, так как старая зависала по непонятным причинам и решения не удалось найти.
4) iscsi+lvm+gfs2. Есть подозрения, что в режиме master-master, много времени может уходить на локи. Во время тестов, листинг новосозданного маленького файла, занимал 0.5с. Как я понимаю, это в основном время захвата лока на чтение. Этот вариант пока нравится больше всех.
5) cassandra. Из прочитанного про неё, пришёл к выводу, что это больше БД, нежели хранилище данных. Пытается побольше всего в памяти держать и т.д. Нет полной recovery — оно происходит только при чтении данных, или при ручном запуске команды.
Может у уважаемого хабрасообщества есть ещё варианты на примете или есть опыт, который может развеять (или закрепить) мои опасения?
Идеального решения из опенсорса на данный момент нет. Хотите надежность и стабильность — drbd, хотите масштабируемость — glusterfs и ceph. И блочные устройства ceph точно работают на ядрах 3.2, сам пробовал. Glusterfs мне очень нравится, вот прямо очень-очень, весьма красивый продукт, и развивается Red Hat'ом. Но и ceph и glusterfs не порадовали меня скоростью «ребилда» после смерти и восстановления одной из нод. Правда я пытался их использовать для хранилища виртуалок, в вашем случае может быть этот момент не будет столь критичен. Пока что остановился на drbd — быстро и стабильно. Да, пару раз приходилось править split-brain, ничего страшного в этом нет.
Средний
