После неудачной попытки с ceph и советов забить на это, как от гуру-школьников на реакторе, так и на / админские истории :: openstack swift :: ceph и все все все :: разное

После неудачной попытки с ceph и советов забить на это, как от гуру-школьников на реакторе, так и на хабре, я уже почти опустил руки.

В это время тестировался gfs2. Но он оказался: во-первых, плохо масштабируемым; во-вторых, достаточно медленным; в-третьих, ооочень сложным и глючным. Явно не расчитан на "commodity hardware".

Я пустился в размышления - почему же это так сложно и тормознуто. Ведь задача простая - хранить файл в нескольких копиях на разных серверах + как-нибудь сохранить где именно он хранится. При желании, это реализуется достаточно просто и быстро даже вручную.

И тут я понял основную ошибку - я искал файловую систему. А в ней не просто хранение, но ещё и система прав и лок файлов. Они мне не были нужны, поэтому я отказался от понятия файловой системы. И тут же обнаружил Openstack Swift. Это простое хранилище данных.

- Работает через REST-интерфейс (обычный http).
- В случае падения одной из нод, работает без проблем дальше.
- Используется в wikimedia для хранения всяких картинок.

В общем, проект достаточно зрелый. Хотя информации о нём достаточно мало - возможно из-за того, что для работы с ним надо менять код и вместо файловых методов использовать сетевые. Развернул, обнаружил несколько особенностей, которые не сильно повлияли на дальнейшие действия:
1) при большом количестве файлов, он может добавлять порядка 50 файлов в секунду. Для больших скоростей нужен ссд. Ну в обычное время у меня добавляется несколько файлов в минуту. Поэтому до этого предела ещё далеко.
2) полностью рабочая нода - это 15 разных демонов. Вначале немного охреневаешь от такого изобилия. Но со временем понимаешь, что всё чётко и стройно. Просто они, следуя философии unix, разделили разные функции на разные демоны. Во время первоначальной синхронизации, я отключил некоторые демоны и скорость возросла раза в два.
3) первоначальная заливка всего контента заняла порядка 2 недель неспешного копирования. Днём копирование отрубалось, чтобы не мешать реактору работать.

Итак, результаты:
1) уже 3 недели все новые картинки заливались в свифт. При чтении иногда они брались с диска, иногда - из свифта.
2) с начала этой недели картинки читались только из свифта. Они ещё писались на диск на всякий случай, но не читались
3) с сегодняшнего утра всё полностью перешло на свифт. На диск больше не пишется и не читается. В последний раз забэкаплю и на след.неделе удалю с боевых серверов.

Таким образом, я избавился от одной из трёх точек отказа. Ура!

Ну и всякие дополнительные мелочи:
1) во время переноса свифта обнаружил, что картиночный сервер упирается в канал 100Мбит в часы пик. Вовремя я начал чесаться по поводу его переноса... =)
2) следующая точка отказа, которую надо будет устранять, - mysql. Раньше думал, что придётся переходить на postgresql, ибо в мускуле всё плохо с репликацией, failover и вообще версия 5.5 (которая появилась после покупки ораклом) у них очень плохая вышла. Коммуна была расстроена и считала, что оракл убьёт мускуль. Но в феврале этого года вышла версия 5.6, которая удивительно хорошо работает - быстрее 5.5, добавлены фичи для репликации из коробки, для php выпустили плагин с load-balancing и failover. В общем, похоже мускуль воскрес из мёртвых и мне это нравится, ибо не хочется переучиваться на постгрю.
3) написал хостеру, что наблюдаю днём пакетлост 0.1%, а по вечерам наблюдаю пакет-лост 0.5%. На удивление, не послали нахрен, а начали разбираться. Хоть и достаточно вяло.
4) после того, как перешёл на swift, на серверах стало нехватать памяти (всего 16Гб). Пришлось перейти с apache на nginx+php-fpm. Из-за того, что фротэнд держал с бэкэндами keel-alive соединения, получил выигрыш в памяти в 3 раза - 300 Мб вместо 1Гб.
5) настроил себе в заббиксе красивые картинки. Теперь если что-то торимозит - я не бегаю по серверам, а запускаю один экран и всё сразу видно: