http://sebgoa.blogspot.com/2015/06/building-s3-object-store-with-docker.html

22 дек. 2015 г., в 13:55, Igor Levchuk написал(а):

glusterfs

2015-12-22 13:53 GMT+02:00 Vasiliy P. Melnik :

...

Всем привет.

Есть сторедж с исходными картинками, из этого стореджа апач выдергивает картинки и ресайзит под заданные параметры. Размер стореджа на текущий момент 1.5 терабайта, будет увеличиваться

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

Есть понимание чего нужно: нужен кластер, чтобы данные раскидать по серверам, масштабируемость стореджа, нужна точка входа локальная на каждом сервере, который отдает контент, нужен доступ к физическим файлам - бекапы делать

Сейчас есть мысли перейти на ceph, еще смотрели гластерфс. У кого на чем построено?

-- Regards, Igor Levchuk

У меня от ceph не самые приятные воспоминания остались. оно реально валится от малейшего чиха, так, что костей не соберешь. glusterfs - да, вещь.

вот блин - нет в жизни совершенства :)

кстати, я тут подумал - а зачем огород вообще городить, решение должно

...

быть дубовым и тупым.

есть кучка серверов, есть куча файлов. нужна некая база, которая привяжет файл к одному или нескольким серверам. файл в таком случае может храниться на обычной файловой системе. скрипт отдачи файла выполнит простой запрос select node from nodefiletable where name=filename. запросит файл с ноды, сделает ресайз, отдаст клиенту. все тупо и надежно, как в танке, можно обеспечить какую угодно избыточность, просто раскладывая файл сразу на несколько нод.

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

C обычной ФС вылезет потребность в костылях "файл не нашелся" и вообще непонятно как определять "файлы все есть?" и "а в них всё ок, картинка сломалась или такой залили?"

Поэтому, учитывая "надо этим управлять" я бы подумал над запихиванием файлов в контейнеры "управляемого" размера - грубо говоря, зип-архивы по 500М - это и "раз плюнуть" вычитать-проверить-пропихнуть по сети, и 1ТБ - это 2000 файлов.

Т.к. сомневаюсь, что файлы там "оч нужно" часто удалять - решение выглядит весьма удобным. Удаление - это будет просто отметка в БД, и по мере достижения "удалить Х% в контейнере" - нужно будет распаковать - грохнуть - упаковать. 500М - легко распаковываются на рамдиск и пакуются обратно.

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

Зип или другой формат без сжатия - практически "прочитать заголовок+прочитать чуть больше". Идея в контейнере с чексумами, в принципе - .iso+checksum или вообще что-то своё - это аж ни разу не сложно написать. Просто zip - к нему есть куча библиотек и всё такое.

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

наличие - ну это больше вопрос к обслуживанию , потому как потеря некоторых

...

файлов не критична в принципе, просто нужен некий механизм бесперебойности Это так кажется. Пока "нужное" не посеется/не исказится.

под "не критично" я имел ввиду как раз "не критично" - понятно что терять нельзя, но никто не умрет, если что.

есть портал про продаже недвижимости, есть загруженные картинки, которые надо где-то хранить, сейчас картинки в монге лежат, как оказалось не самый лучший вариант - отгребли кучу проблем, сейчас думаем на что перейти, и переходить ли вообще. Очень большая проблема это что-то делать с этим стореджом, все таки полтора тера. на кеше стоит нгинкс, за ним пара бекэндов которые отдают контент, картинки проходят некоторую модификацию, но нгинкс достаточно сильно разгружает бекэнды. Одна точка входа на запись - это не проблема, а вот на чтение хотелось бы иметь данные на каждом бэкэнде, для распределения нагрузки и опять же сохранности данных. Лично я ставил на тест гластер, мое личное имхо - сыровато еще, хотя то, что за дело взялась ридхет вселяет надежду. Не хочется сидеть пробовать все что есть на рынке - все таки на тестовое окружение охудит примерно неделя, и то тест без нагрузки боевой получается. Зачем наступать на грабли 22 декабря 2015 г., 17:38 пользователь Maksym Tulyuk написал:

Привет!

А можно уточнить задачу? In my humble opinion, MongoDB и GlusterFS это разные вещи предназначенные для разных задач.

Максим

...

On 22 Dec 2015, at 12:53, Vasiliy P. Melnik wrote:

Всем привет.

Есть сторедж с исходными картинками, из этого стореджа апач выдергивает картинки и ресайзит под заданные параметры. Размер стореджа на текущий момент 1.5 терабайта, будет увеличиваться

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

Есть понимание чего нужно: нужен кластер, чтобы данные раскидать по серверам, масштабируемость стореджа, нужна точка входа локальная на каждом сервере, который отдает контент, нужен доступ к физическим файлам - бекапы делать

Сейчас есть мысли перейти на ceph, еще смотрели гластерфс. У кого на чем построено?

On Wed, Dec 23, 2015 at 10:10:45AM +0200, Alexander V Soroka wrote:

Привет !

что-то давно не было про политику :)

История, она такая... :-)

https://site.ua/yuriy.gudimenko/2031-treskovye-voyny-18%2B/

Вроде и красиво - но тупой и примитивный шантаж, который вполне можно было закончить разносом гордых островков с Б-52. Ну, по крайне мере - наше правительство решало бы так :). -- Best regards, Paul Arakelyan.

Я не совсем понимаю почему решили, что проблема в MongoDB? Она очень хорошо маштабируется путем добавления новых сервером

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

27 декабря 2015 г., 18:44 пользователь Andrii Stesin написал:

поставить ферму микросервисов, которые будут отдавать из фермы стораджей картинки, nginx в качестве балансера, ы?

чего уж так сразу микро? :) можно и обычных, просто хотелось иметь много точек входа и сразу копию данных на всех бекэндах, их просто аж целых два. На текущий момент лучше всего подходит gluster , но вот то, что она работает через fuse , да еще и написали индусы - как-то стремает Вот сижу думаю, что наверное надо просто складывать на фс, а потом ночью разливать рсинком по другим серверам, чтобы просто иметь резервную копию.

2015-12-27 18:42 GMT+02:00 Vasiliy P. Melnik :

...

...

Я не совсем понимаю почему решили, что проблема в MongoDB? Она очень хорошо маштабируется путем добавления новых сервером

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

просто она создает больше проблем, чем дает плюшек

спасибо - почитаю архив, не догадался. 27 декабря 2015 г., 22:54 пользователь Lystopad Aleksandr написал:

Hello, Vasiliy P. Melnik!

On Sun, Dec 27, 2015 at 06:58:19PM +0200 basil@vpm.net.ua wrote about "Re: [uanog] cluster storage for content":

...

27 декабря 2015 г., 18:44 пользователь Andrii Stesin написал:

...

поставить ферму микросервисов, которые будут отдавать из фермы стораджей картинки, nginx в качестве балансера, ы?

чего уж так сразу микро? :)

можно и обычных, просто хотелось иметь много точек входа и сразу копию данных на всех бекэндах, их просто аж целых два. На текущий момент лучше всего подходит gluster , но вот то, что она работает через fuse , да еще и написали индусы - как-то стремает

Вот сижу думаю, что наверное надо просто складывать на фс, а потом ночью разливать рсинком по другим серверам, чтобы просто иметь резервную копию.

Василий, привет! Спроси в рассылке nginx-ru, там регулярно подобные темы, но более конкретно обсуждают, я думаю подобный вопрос лучше там задавать.

-- Lystopad Aleksandr

“починить” - это восстановить из backup или изменить данные в базе данных? MongoDB решает как минимум три важные проблемы: - простой и понятный интерфейс для программистов (JSON) - “простая” масштабируемость путем добавления серверов - изменение “scheme” путем изменения кода, без изменения данных на сервере ИМХО _дешевле_ купить сервак с дисками на 1.5TB и проводить на нем эксперименты чем переписывать код Максим

On 27 Dec 2015, at 17:42, Vasiliy P. Melnik wrote:

Я не совсем понимаю почему решили, что проблема в MongoDB? Она очень хорошо маштабируется путем добавления новых сервером

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

просто она создает больше проблем, чем дает плюшек

Today Dec 27, 2015 at 23:36 Vasiliy P. Melnik wrote:

ой, та тестить есть где. Просто вот столкнулся с конкретной проблемой: хотел обновить монго - до сих пор стоит 2.4, решил сделать дамп, дамп выпадает на 99%, в интернете пишут, что надо --repair. На починку надо винт на 3 тера - в два раза больше, чем база весит. Ну ок, допустим починил, дальше надо все таки выгрузить. Каждое действие - сутки, пару суток. А все это время система должна работать, что с дельтой делать? систему на запись тоже нельзя останавливать.

Тут лучше replica set сделать, если ещё нет: https://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/ Добавить пустую реплику 2.6, а она сама всё перетянет при initial sync: https://docs.mongodb.org/manual/tutorial/resync-replica-set-member/ Потом переключать роли и синк в обратную сторону: https://docs.mongodb.org/manual/release-notes/2.6-upgrade/#upgrade-a-replica... Дальше можно перейти на 3.0 со сменой движка, а потом и 3.2: https://docs.mongodb.org/manual/release-notes/3.0-upgrade/#change-replica-se... -- WNGS-RIPE

Today Dec 28, 2015 at 03:49 Andrii Stesin wrote:

народ, сорри за глупый воприс, но вы шо - картинки в базе данных (в монге) блобами держите? я верно понял?

Я - нет, а "портал про продаже недвижимости" у топикстартера - да. Просто в MongoDB или как GridFS - этого уже он не указывал. И с дополнительными условиями "на кеше стоит нгинкс" и "картинки проходят некоторую модификацию" - это вполне оправданно. Работать с терабайтами мелких файлов как с файлами очень геморно в плане массово копировать/синхронизировать/переносить, а с отдачей выходит трэш кеша VFS, куча stat-ов и большой random i/o. Потому и делают разный софт, что пакует для хранения это в большие blob-ы. -- WNGS-RIPE

Здравствуйте, выяснилась интересная особенность - при настройке слейва по типу мастер-slave база на слейве занимает больше места, чем на мастере. Попробую как через replica set будет себя вести база. 28 декабря 2015 г., 0:48 пользователь Oleksandr V. Typlyns'kyi < astral@wangsamp.km.ua> написал:

Today Dec 27, 2015 at 23:36 Vasiliy P. Melnik wrote:

...

ой, та тестить есть где. Просто вот столкнулся с конкретной проблемой: хотел обновить монго - до сих пор стоит 2.4, решил сделать дамп, дамп выпадает на 99%, в интернете пишут, что надо --repair. На починку надо винт на 3 тера - в два раза больше, чем база весит. Ну ок, допустим починил, дальше надо все таки выгрузить. Каждое действие - сутки, пару суток. А все это время система должна работать, что с дельтой делать? систему на запись тоже нельзя останавливать.

Тут лучше replica set сделать, если ещё нет:

https://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/ Добавить пустую реплику 2.6, а она сама всё перетянет при initial sync: https://docs.mongodb.org/manual/tutorial/resync-replica-set-member/ Потом переключать роли и синк в обратную сторону:

https://docs.mongodb.org/manual/release-notes/2.6-upgrade/#upgrade-a-replica... Дальше можно перейти на 3.0 со сменой движка, а потом и 3.2:

https://docs.mongodb.org/manual/release-notes/3.0-upgrade/#change-replica-se...

-- WNGS-RIPE