После неудачной попытки с 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) настроил себе в заббиксе красивые картинки. Теперь если что-то торимозит - я не бегаю по серверам, а запускаю один экран и всё сразу видно:
я знаю кунг-фу, ушу, айкидо, джиу-джитсу, и много других страшных слов. Но ты превосходишь любого в их количестве
>Пришлось перейти с apache на nginx+php-fpm.
Давно бы так :)
А с репликацией и в постгресе тоже не всё так радужно, по слухам.
Давно бы так :)
А с репликацией и в постгресе тоже не всё так радужно, по слухам.
ну разница сказалась из-за keep-alive соединений, в основном. На фронтэнде 5 тредов нгинкса и каждый из них открывает 4 соединения. На этом и жрались ресурсы апача. А тут nginx фронтэнда подключается к nginx бэкэнда и тот уже без keep-alive (всё равно всё локально) работает с php-fpm
Через unix sockets хоть?
неа, tcp/ip
если локально, то зачем дополнительные tcpip ? переключай на сокеты смело.
З.ы. а я же говорил пробуй на php-cgi перейти, как видишь ресурсы освободились.
З.ы. а я же говорил пробуй на php-cgi перейти, как видишь ресурсы освободились.
я знал, что они освободятся. Просто в тот момент они не нужны были =). А тут за счёт ещё одного эффекта - выигрыш составил не в полтора раза, а в 3 =).
Разницы между tcpip и socket по скорости почти нет. Но я уже наталкивался на багу nginx с сокетами. Правда при использовании модуля proxy, а не fastcgi. На данный момент бага не поправлена. Поэтому не хочу проверять, есть ли эта бага в модуле fastcgi ради мифических процентов скорости.
Разницы между tcpip и socket по скорости почти нет. Но я уже наталкивался на багу nginx с сокетами. Правда при использовании модуля proxy, а не fastcgi. На данный момент бага не поправлена. Поэтому не хочу проверять, есть ли эта бага в модуле fastcgi ради мифических процентов скорости.
Эм, погоди. proxy это который proxy_pass? он не работает с сокетами, для этого fastcgi_pass
В последней версии nginx уже есть SPDY было бы интересно посмотреть как оно себя ведет в реальности...
подозреваю, что для реактора будет медленее http. Тут итак всё разнесено на разные домены, поэтому загрузка идёт параллельно.
Ты вскользь про канал сказал: а хетз не расширяет клиентам каналы (1-10гбпс)?
хетцнер до 1Гбит расширяет. Но он там стоит дороговато
А не интересовался как фб и вк с такими задачами справляются?
подозреваю, что что-то похожее и возможно самописное. Там не сложно написать то =)
Примерно так - http://api.yandex.ru/elliptics/
Только у них тоже свои велосипеды.
Сорри за некропостинг, но вдруг ещё надо)
Только у них тоже свои велосипеды.
Сорри за некропостинг, но вдруг ещё надо)
а как отдаются картиночки обратно из свифта? там же нет структуры каталогов и вообще..
я просто вижу несколько вариантов, но хочу услышать рабочий непосредственно)
чем подробнее, тем лучше
я просто вижу несколько вариантов, но хочу услышать рабочий непосредственно)
чем подробнее, тем лучше
вся мета-информация о картинке хранится в БД. Отдаются через пхп. Запросом в БД узнаём какую именно картинку надо отдать, получаем её из свифта, отдаём. Nginx кэширует частозапрашиваемые картинки. При желании, можно соптимайзить, чтобы пхп делал редирект на свифт (чтобы nginx его обрабатывал), но вломы =).
По поводу структуры каталогов:
1) они её условно-поддерживают. Можно делать листинг внутри одного каталога и т.д.
2) в моём случае она совершенно не нужна =)
По поводу структуры каталогов:
1) они её условно-поддерживают. Можно делать листинг внутри одного каталога и т.д.
2) в моём случае она совершенно не нужна =)
http://habrahabr.ru/post/180415/
а ты варниш используешь?
а ты варниш используешь?
я про ceph писал в админских историях =). Сырой и тормозной.
варниш на реакторе - не использую. В другом проекте - использую.
варниш на реакторе - не использую. В другом проекте - использую.
С ты пробовал монтировать свифт с помошью cloudfuse? Чета он у меня неприятно и непонятно падает
Не использую. Я бы вообще не рекомендовал использовать файловую систему для облачных хранилищ. Ибо добавляет тормозов/разсогласованности, а никаких плюсов не несёт (кроме очень небольшого облегчения работы с файлами). Намного лучше мета-данные хранить в БД, а в облачном хранилище только обезличенные данные, которые вытаскивать через rest-интерфейс когда надо.
Эт я понимаю, понял уже все минусы, только выхода особого нет. У радивы SSD на 40 гб. Для того чтобы перепилить радиву под рест надо будет оче дохуя трудозатрат. Какие есть альтернативы хранения тысяч аудиофайлов?
А эти файлы не поместятся на одном винте чтоль? =)
Ну в виртуалку винт не воткнешь, иначе не было бы таких проблем
На виртуалке свифт не поднимешь. Да и свифт сделан для того, чтобы запускать его как минимум на 5 нодах.
вернее, свифт ты поднимешь, но как только он начнёт хоть как-то серьёзно использоваться - тебя админы виртуалки сгонят с неё =). Ты топологию свою расскажи. Где у тебя винт с данными, где ты хочешь доступ к нему иметь?
заббикс-хуябикс...
Чтобы написать коммент, необходимо залогиниться