Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
Сообщение от opennews (??) on 29-Мрт-18, 23:35
Подготовлен (https://github.com/leo-project/leofs/releases/tag/1.4.0) новый выпуск распределённого отказоустойчивого хранилища объектов LeoFS (http://leo-project.net/leofs/index.html), совместимого с клиентами, использующими API Amazon S3 и REST-API, а также поддерживающего режим работы в роли NFS-сервера. Имеются оптимизации для хранение как мелких, так и очень больших объектов, присутствует встроенный механизм кэширования, возможна репликация хранилищ между дата-центрами. Среди целей проекта отмечается достижение надёжности 99.9999999% за счёт избыточного реплицирования дубликатов и исключения единой точки отказа. Код проекта написан на языке Erlang и распространяется (https://github.com/leo-project/leofs/) под лицензией Apache 2.0. LeoFS состоит из трёх компонентов: -  LeoFS Storage (https://leo-project.net/leofs/docs/architecture/leo_storage/) - обслуживает операции добавления, извлечения и удаления объектов и метаданных, отвечает за выполнение репликации, восстановления и формирования очереди запросов клиентов. -  LeoFS Gateway (https://leo-project.net/leofs/docs/architecture/leo_gateway/) - обслуживает HTTP-запросы и перенаправляет ответы клиентам с использованием  REST-API или S3-API, обеспечивает кэширование наиболее востребованных данных в памяти и на диске. -   LeoFS Manager (https://leo-project.net/leofs/docs/architecture/leo_manager/) - отслеживает работу узлов LeoFS Gateway и LeoFS Storage, ведёт мониторинг состояния узлов и проверяет контрольные суммы. Гарантирует целостность данных и высокую доступность хранилища. Основные новшества LeoFS 1.4.0: -  Поддержка сборки с использованием  Erlang/OTP 20 (https://www.opennet.dev/opennews/art.shtml?num=46740); -  Поддержка типа сервисов "notify" для systemd; -  Возможность мониторинга состояния узлов хранения (leo_storage) при помощи SNMP; -  Оправка администратору сводки сообщений об ошибках при запуске; -  Переработана система уведомлений о медленной обработке данных, чтобы избежать узких мест; -  В управляющий интерфейс (leofs-adm) добавлена операция recover-disk  для увеличения производительности восстановления в случае выхода дисков из строя. URL: https://github.com/leo-project/leofs/releases/tag/1.4.0 Новость: https://www.opennet.dev/opennews/art.shtml?num=48357
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–4 +/–
Сообщение от Anonim (??) on 29-Мрт-18, 23:35
https://habrahabr.ru/company/oleg-bunin/blog/313364/ Поначалу мы паниковали, пробовали расставлять по коду leofs метрики, пробовали понять, что происходит, коллега Чистяков не спал ночами. Мы пытались выяснить, не хочет ли кто-нибудь из питерских Erlang’истов потрогать это палочкой. Питерские Erlang’исты оказались разумными людьми, они не стали трогать это палочкой.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+12 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 01:27
	> Этот доклад — расшифровка одного из лучших выступлений на профессиональной конференции по эксплуатации и devops Как испоганилось айти, если это -- лучший  доклад. Это бред сумасшедшего, а не доклад. "Все дерьмо, я мы дартаньяны, несмотря на то, что много лет доим заказчика и за его счёт играемся с тем, о чём понятия не имеем". Тьфу. Басни про хетцнер это про танцора, у которого сплошные проблемы в жизни.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+7 +/–
	Сообщение от Stax (ok) on 30-Мрт-18, 04:05
	Даже комментировать противно. Где багрепорт в списке рассылки или официальном гитхабе https://github.com/leo-project/leofs/issues ? Что вообще делать пытались, кроме как "трогать палочкой"? Если не было желания писать багрепорт или как-то разбираться в проблеме - почему не попытались тупо на месяц арендовать N самых простых серверов в том же датацентре, создать там второй кластер, перенести туда данные, грохнуть имеющийся и пересоздать с нужным количеством узлов, скопировать данные назад и отдать железку? Вместо очевидных действий занимались какой-то фигней (нанимали переводчика, серьезно?? пусть английский разработчиков не идеален, но они на нем ведут и разработку, и рассылку и всегда готовы ответить) и ждали, пока все навернется. Ну-ну. PS эксплуатирую LeoFS в продакшене и *крайне* доволен простотой, надежностью и производительностью. Хотя по результатам тестирования и внедрения пришлось написать несколько багрепортов, чтобы лучше автоматически разруливались некоторые нестандартные ситуации. Все критичное разработчики поправили достаточно оперативно. С ними очень легко общаться, хоть большинство и японцы.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	15. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
	Сообщение от RudW0lf on 30-Мрт-18, 09:44
	Сразу видно что комментаторы выше доклад не смотрели. Цитата вырвана из контекста. Минутой ранее в докладе говорилось, что ребята пошли в саппорт этого самого проэкта, где их просто послали, а поскольку они его держали в проде они испытали неюллюзорный батхерт. После этого попытались обратиться к знакомым с языком специалистам и те вежливо отказали. Вообще насколько я понимаю исходный посыл первого комментария - опенсорц проэкт без комьюнити - это уг,и ставить его себе на прод то еще приключение. Есть люди которые используют это в проде на хотябы 100+ узлов?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	17. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+3 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 10:53
	Кластер поехал. Эти спецы начали отключать-подключать ноды в надежде, что "само пройдёт". Я б их ещё дальше послал
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+3 +/–
	Сообщение от Stax (ok) on 30-Мрт-18, 12:15
	> Сразу видно что комментаторы выше доклад не смотрели. Цитата вырвана из контекста. Читал - и как уже написал, комментировать противно. > Минутой ранее в докладе говорилось, что ребята пошли в саппорт этого > самого проэкта, где их просто послали, а поскольку они его держали Ну-ка а давайте теперь проверим их слова. Официально саппорт есть в списке рассылки https://groups.google.com/forum/#!forum/leoproject_leofs , и еще, разумеется, есть багтрекер (еще с 2013 года) https://github.com/leo-project/leofs/issues - где же багрепорты от этих товарищей? Или их так "послали", что вычистили и следы от заведенных ими багов? > в проде они испытали неюллюзорный батхерт. После этого попытались обратиться к > знакомым с языком специалистам и те вежливо отказали. > Вообще насколько я понимаю исходный посыл первого комментария - опенсорц проэкт без > комьюнити - это уг,и ставить его себе на прод то еще Какой именно комьюнити требуется? В список рассылки пишут, но не много, в основном с вопросами, связанными с первыми установками. Кто-то сразу пишет в issue tracker вопросы по установке. Но в целом (особенно в текущих версиях) там все очень гладко и ставится без вопросов. Поддержка заявлена и в рассылке, и на багтрекере. Еще есть комьюнити Project FiFO (http://project-fifo.net/). Там для хранения данных используется LeoFS. Некоторые используют LeoFS в его составе как готовый продукт и общаются чисто в рамках того комьюнити. > приключение. Есть люди которые используют это в проде на хотябы 100+ > узлов? Тут, похоже, есть некоторое непонимание, зачем данная штука. Она НЕ предназначена для хранения данных на 100+ узлов. Хотя вполне может обслуживать 100+ узлов, обрабатывающих данные, но хранить их предполагается на меньшем количестве. Строго говоря, явного ограничения нет - но я бы делал на ней кластеры на 6-12 узлов, может до 20. При большом количестве узлов будут некоторые неприятности как минимум при их обслуживании, но я не хочу заострять на этом внимание (проблемы известны, со временем поправят). (это я про узлы хранения - для обслуживания 100+ узлов обработки данных, вероятно, еще потребуется немаленькая пачка узлов-шлюзов. Именно они держат нагрузку по запросам, к счастью, их очень легко масштабировать) Это штука, когда вам надо хранить (раздавать, использовать) большое количество объектов, в том числе маленьких (картинки, документы), при этом нужна производительность и отказоустойчивость.  В отличие от конкурирующих решений, она очень проста, надежна и высокопроизводительна на маленьких объектах. Т.е. туда можно кидать и 100 МБ объекты, и 10 КБ объекты, и все будет хорошо. Нужно закинуть миллиард объектов со средним размером 50 КБ - не вопрос, все будет достаточно быстро. Чуть подробнее отпишу ниже, где спрашивают про сравнение с lustre. Работать с ней на уровне PUT/GET/DELETE через обычный REST API либо же получая всю функциональность (пользователи/бакеты и т.п.) через S3-совместимый API. Хорошие биндинги для S3 есть для всех популярных языков, есть интеграция с другими системами (напр. Hadoop умеет обращаться к S3), многие продукты либо нативно, либо через s3cmd или s3-fuse позволяют "просто подключить" это хранилище и хранить в нем данные. Локально и значительно дешевле амазона. Был вот у вас NAS, на котором находятся данные, с которыми работают приложения, вы его переросли - перестало хватать места/скорости/захотелось отказоустойчивости. Вы убеждаетесь, что все ваши приложения умеют обращаться или по REST, или имеют биндинги к S3, ставите эту штуку и наслаждаетесь. (NFS-доступ по ряду причин я бы не назвал production-ready, там есть много ограничений, в которые можно упереться).
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	20. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
	Сообщение от XoRe (ok) on 30-Мрт-18, 12:28
	> Ну-ка а давайте теперь проверим их слова. Официально саппорт есть в списке рассылки https://groups.google.com/forum/#!forum/leoproject_leofs , и еще, разумеется, есть багтрекер (еще с 2013 года) https://github.com/leo-project/leofs/issues - где же багрепорты от этих товарищей? Или их так "послали", что вычистили и следы от заведенных ими багов? Они позвонили по телефону в техподдержку компании Rakuten, которая пишет этот leofs. Тут лучше подойдет другая цитата с того доклада: > Технический руководитель команды setup нанял переводчика с японского, и мы позвонили в Токио. В 8 утра. Поговорить с компанией Rakuten. Компания Rakuten поговорила с нами час, и простите меня, я буду ее ругать, потому что так со мной еще не обращались в моей жизни, а я 20 лет в бизнесе… Компания Rakuten поговорила с нами час, выслушала внимательно наши проблемы, почитала наши баг-репорты в их трекере, после чего сказала: «Знаете, у нас закончилось время, спасибо, извините».
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+3 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 12:35
	Не понимаю, как у них вообще хватило наглости звонить (!) в техподдержку компании, не имея контракта, по которому им должны были предоставить эту поддержку. Может их там ещё в седалище должны были облобызать? Как только начал используешь чужой софт за здорово живём — ты сам себе техподдержка.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	84. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от XoRe (ok) on 02-Апр-18, 09:43
	> Не понимаю, как у них вообще хватило наглости звонить (!) в техподдержку > компании, не имея контракта, по которому им должны были предоставить эту > поддержку. Может их там ещё в седалище должны были облобызать? Как > только начал используешь чужой софт за здорово живём — ты сам > себе техподдержка. А почему вы решили, что у них не было контракта?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Stax (ok) on 30-Мрт-18, 12:45
	Я видел эту цитату. Еще раз. Багрепорт в трекере где??? Не говоря уж про то, что Rakuten - огромный холдинг. Конкретно финансированием разработки LeoFS занимается Технологический Институт Rakuten (RIT). Поддержкой напрямую они не занимаются! За поддержкой нужно обращаться к разработчикам. Которые, в принципе, конечно, работают в RIT, но это все-таки разные понятия.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	46. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+2 +/–
	Сообщение от 1 (??) on 30-Мрт-18, 15:31
	>почитала наши баг-репорты в их трекере
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	55. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 16:31
	С опенсорсным проектом вам никто ничего не должен даже при наличии комьюнити, а шанс, что из этого комьюнити кто-то шарит менее 1%, и естественно они заняты полезным делом и на форуме не сидят.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	34. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Николай Гаврилов on 30-Мрт-18, 13:20
	Это опенсорс, дружище. Хочешь чтоб дело сдвинулось с места - выдели ресурсы. Деньги дай, или сам помоги, своими руками. Когда мне надо продвинуть и решить какой-то баг, то я сам занимаюсь этим. Почему другие горазды только на форумах ныть?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	36. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 13:24
	Согласен. Эксплуататор продакшонов блин. Хоть раз донат кинул, или только эксплуатирует и клянчит?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	14. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+2 +/–
	Сообщение от asand3r on 30-Мрт-18, 09:10
	Слушал я доклад этого дядьки вместе с еще каким-то толстяком на Highload'e. Вещали они про MySQL и PostreSQL. Даже досмотреть сил не хватило - невозможно такое г* слушать.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	50. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 16:17
	Они некомпетентны? Позорят отрасль?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 11:10
	Anonim пишется через "y" Это пост рекламы своей неинтересной статьи или ненужной компании? Спасибо.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	26. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 13:00
	> мастер-нода теперь не знает, где у нее какие файлы лежат. Хмммм... Как-то это странно. Такое может быть в какой-нибудь пре-альфа версии, но чтобы японцы выкатили такое в продакшон - не могу в это поверить.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	39. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Stax (ok) on 30-Мрт-18, 13:34
	>> мастер-нода теперь не знает, где у нее какие файлы лежат. > Хмммм... Как-то это странно. Такое может быть в какой-нибудь пре-альфа версии, но > чтобы японцы выкатили такое в продакшон - не могу в это > поверить. Я вам секрет открою - в LeoFS *ВСЕ* узлы знают, где какие файлы лежат. Без каких-либо внеших запросов. Просто потому, что узел определяется функцией над именем файла, использующей хэш (RING). И "мастер-нода" требуется только для запуска узла и распространения новой версии RING при изменениях узлов, ну и статистику с узлов собирает - а в остальном в обработке данных никак не участвует. Текущий RING знают все узлы, при добавлении/убирании узлов он меняется и новая версия распространяется. После чего выполняется операция rebalance, во время которой объекты перемещаются между узлами для соответствия новому RING'у. Перемещения, по возможности, минимальные, т.к. это consistent hash. Все узлы всегда знают не только текущий, но и предыдущий RING, что позволяет до окончания операции корректно обслуживать чтение / запись. Думаю, "мастер-нода теперь не знает, где у нее какие файлы лежат" надо понимать как - добавив новый узел, мы создали новый RING, но или еще не распространили его на другие узлы (тут надо смотреть, почему. В принципе, это неплохо логируется и показывется, где какая дата и версия RING, плюс есть ручные инструменты типа команды dump-ring - можно на всех узлах сдампить его в текстовые файлы и хоть вручную посмотреть), или еще не сделали rebalance. Но в любом случае, мастер-нода знает, где что лежит :) Просто команда whereis, показывающая "где что лежит" (по факту просто применяющая хэш к имени и спрашивающая статус этого объекта на полученных узлах) использует новый созданный RING, а не предыдущий, согласно которому данные еще могут лежать (до окончания rebalance). Это вообще мелочи и особо ничего не значит.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+4 +/–
	Сообщение от Не олег on 30-Мрт-18, 13:07
	Этот ваш олег, мягко говоря, не самый авторитетный источник...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+24 +/–
Сообщение от Roskompozor atakuet on 30-Мрт-18, 02:30
Скоро Amazon заблочат на территории РФ с помощью blackhole, что вызовет сбои в работе миллионов сервисов во всем мире. В следствии чего (как и обещал Жаров) "вражеский запад" отключит нас от интернетов. Готовимся... https://roskomsvoboda.org/37531/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 03:52
	Ну да, во всем мире, на территории определенного государства.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	38. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–2 +/–
	Сообщение от ansel on 30-Мрт-18, 13:29
	Статью не читал да? https://en.wikipedia.org/wiki/Black_hole_(networking)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	63. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от YetAnotherOnanym (ok) on 30-Мрт-18, 18:46
	Типа, отключить приём анонсов с глючного или находящегося под контролем злоумышленников роутера - это прямо такая проблема? Вот, в Пакистане админы накосячили, какое-то время дофига трафика на Ютюб  лилось к ним и там дропалось, провайдерам в других странах хватило пары часов чтобы спохватиться и почистить роуты.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	8. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+1 +/–
	Сообщение от Вонни Бух и Потчк on 30-Мрт-18, 04:36
	Все в чебурашконеты?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 12:34
	К сожалению нет. Амазоном пользуются обычно мобильные игры и приложения.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	37. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 13:26
	Скоро вероятно загонят. Все идет к логической развязке.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	40. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–2 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 13:58
	Скоро это минимум через 10 лет. Бюрократическая машина очень медленная.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	44. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+11 +/–
	Сообщение от flex (??) on 30-Мрт-18, 15:04
	Дурак ты, Вася. У нас РКН 8 млн. сайтов заблокировал без решения суда, попутно блокируя все что висит на одном IP, ты про какую-то машину сказки рассказываешь. Депутат единоросии чтоль? Или из криокамеры вышел?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	45. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–15 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 15:18
	Сколько лет закон Яровой принимается и когда запустится? Почему не работает закон о мессенжерах и анонимайзерах? Пока эти две вещи не заработают, никого от интернета не отключат. Физлиц я бы уже давно отключил от мирового интернета на месте властей. Им он просто не нужен и никак не повлияет на российскую экономику.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	48. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+24 +/–
	Сообщение от Евгений Канавалов on 30-Мрт-18, 16:09
	Ну привет тебе, простой обыватель. Давай по порядку. > Сколько лет закон Яровой принимается и когда запустится? Меньше 2х лет назад приняЛИ и подписаЛИ. Летом 2016го. Запустится через 2 месяца - 1го июня 2018 года, как и планировалось во время принятия закона (внезапно). С небольшой поправкой. Пол года на звонки и СМС, месяц для всего остального. С наращиванием до задуманных 6 месяцев интернета к 2020му. Лично устанавливал и тестил оборудование для нашего провайдера в декабре. В декабре-январе, кстати, большинство провайдеров начали поднимать цены, многие впервые за все время своей деятельности, ну и мы не исключение. > Почему не работает закон о мессенжерах и анонимайзерах? Ну почему же не работает. Во-первых, работает, и весьма неплохо. Скайп, Ватсап, Вайбер - слышал про такие мессенджеры? И десятки других популярных, успешно прогнулись и сотрудничают с РКH/ФCБ, прослушивают трафик. На первых порах этого достаточно. Гулaг не сразу строился. Во-вторых, в некоторых случаях проще пyкнyть, чем сделать. Пока непонятно как будут блокировать P2P-мессенджеры. Пока VPN невозможно положить. Пока большинство провайдеров даже не имеет DPI-оборудования. А когда заимеет, там уже другие протоколы VPN/шифрования подтянутся. Уже есть вещи, способные лихо завернуть любой DPI, и успешно обходят блокировки даже в Китае. Гонка технологических вооружений пока в нашу пользу, с большим отрывом. Если что и может случиться, так это тот самый рубильник, который  отсечет нас от общего инета. Предпосылки и намеки со стороны известных государственных чинyш уже есть. > Пока эти две вещи не заработают, никого от интернета не отключат. Наивно. > Физлиц я бы уже давно отключил от мирового интернета на месте властей. Им он просто не нужен и никак не повлияет на российскую экономику. Блин, знал бы что тролль, даже не стал бы отвечать. :(
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	56. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+1 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 16:41
	Почему тролль? Я уехал, теперь можете смело отключать интернет. Я только за.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	73. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
	Сообщение от YetAnotherOnanym (ok) on 31-Мрт-18, 09:32
	Экспортный тролль, значит.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	66. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 20:25
	Никакой DPI не нужен. Можно если много трафика на один IP и это не ютуб, тогда блокировка.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	68. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+1 +/–
	Сообщение от Аноний on 30-Мрт-18, 21:33
	Ну толсто же.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	85. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 03-Апр-18, 15:43
	> Лично устанавливал и тестил оборудование для нашего провайдера в декабре. Ну вот! А то - ZOG, правительство, власти, рептилоиди угнетают простых граждан. Вот он, тоже простой человек, который все это "угнетение" и делает. И ещё обвиняет в своих действиях каких-то абстрактных чинуш. Вот скажи, мил человек, зачем ты "Гулаг", как ты выразился, строишь?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

16. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
Сообщение от evkogan on 30-Мрт-18, 10:35
Пошел читать коменты в надежде узнать как оно относительно люстры. В результате увидел только ссылку на статью позора. Где нищеброод, сознается, что он еще и т.пой. Массово совать фалы в BLOB, делают только не выпустившиеся студенты и то не все. А сказать нас предупреждали, что так нельзя, но мы самые умные и потом мужественно решали самолично состряпанные проблемы, ну-ну... После этого говорить, что система плоха, на основании доклада этого автора уже смешно. Тем более что я ни разу не зная что и как в этой леофс понимаю, что просто отключить 2 новых УЖЕ добавленных сервера, это гарантированно получить проблемы плюс к уже имеющимся. А про сравнить с люстрой кто-то что-то сказать может?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+8 +/–
	Сообщение от Stax (ok) on 30-Мрт-18, 12:56
	> А про сравнить с люстрой кто-то что-то сказать может? Это не аналог люстры и не предназначено для больших кластеров. Это объектный сторейдж. Есть у вас до фига каких-то данных в виде множества мелких сущностей и ваши приложения с этим работают. Вы хотите их хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле - вот это то, что нужно. А если ваш софт уже умеет S3 (многое из коробки умеет; если это что-то свое, то дописать совсем несложно, благо реализации S3 есть почти для всего и они достаточно удобные в использовании), то обойдетесь минимум изменений. Альтернативный вариант: вы уже используете S3 в амазоне, храните до фига, вам стало дорого. Хотите локально хранить и обрабатывать, и чтобы вышло дешевле. Из плюсов: оно достаточно просто (но логично) устроено и из-за этого надежно. Данные хранятся в append-only файлах, которые не побьются логически при проблемах с питанием, старые данные не перезапишутся от проблем файловой системы и т.п. Формат там элементарный, любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты. Т.е. данные вы не потеряете, в худшем случае хоть руками по нужному смещению возьмете объект (хотя если он будет большой, то только 5 МБ кусок, и придется сделать это несколько раз, а потом сделать им всем cat). Это я к тому, что принцип "простота = надежность" тут актуален в полной мере. Метаданные хранятся рядышком в LevelDB базе, что позволяет использовать огромные винчестеры, пихать туда кучу мелких объектов и сохранять высокую скорость. В особо запущенных ситуациях можно хранить метаданные на SSD, тогда будет совсем шоколадно. Аналоги тут - Ceph, Swift, Riak CS, Minio. Совсем на пальцах могу сравнить. +/- тут по сравнению с LeoFS. + Ceph - за ним стоит редхат. У Ceph есть другие режимы работы, помимо объектного сторейджа, например RDB. У Ceph больше коммьюнити, есть заявленная коммерческая поддержка. - Ceph - устроен значительно сложнее, чем LeoFS. Если у вас будут проблемы с данными.. вам сильно не повезло. Восстанавливать вручную сложно, долго, дорого. Можно за деньги, дорого. Также есть сильное подозрение (частично подтвержденное небольшим опытом эксплуатации), что все режимы Ceph, кроме того же объектного сторейджа это не очень надежно. Проблема не в них как таковых, а в том, что когда вы сделаете виртуальный RDB, а потом попытатесь сделать вид, что это-таки настоящий block device, то те, кто работают с этим потом в случае минорных проблем сети (моргнуло питание, перегрузились свитчи, зависла железка и т.п.) несколько не ожидают особенностей поведения виртуального block device, что приводит к серьезным последствиям. - Ceph - нет multi-DC репликации. Режим совместимости с S3 - это не приоритетный, по уровню поддержки уступает LeoFS. + Swift - если у вас OpenStack, то берите и не сомневайтесь. Неплохой уровень поддержки S3 и совместимости с разным софтом, практически на уровне LeoFS. - Swift - если у вас НЕ OpenStack, то Swift для вас это будет пачка лишних сервисов и сущностей. Также у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС, в результате если у вас будет до фига (например, 100 миллионов) объектов на узел, у вас с производительностью будет жопа. Потому что ФС будет хранить кучу мелких файлов, размазывая информацию (каталоги и inode) по всему диску, во-первых сильно тормозя, во-вторых большой объем тонко размазанных метаданных не получается кэшировать, т.к. кэширование этого дает огромный оверхед. В LeoFS отдельно лежащие метаданные во-первых работают очень быстро и на ЖД, во-вторых легко кэшируются в памяти, ну и в случае чего можно на SSD. - / + Swift - там совершенно иной принцип репликации, но это тема для отдельных разговоров. Совсем на пальцах: Swift нуждается в постоянной рассылке данных для репликации. После даунтайма узла на него "пропущенные" объекты сами не придут, пока не пройдет очередная волна репликации, рассылающая все данные всем, кому требуется. LeoFS не нуждается в постоянных фоновых репликациях и не потребляет сетевого трафика на повторные репликации тех же данных, за исключением ситуации, когда потерялись данные на узле (умер узел или вылетел диск), тогда шлют данные только на этот узел. При временном же выключении узла остальные узлы ведут список объектов, которые должны были попасть на него, и практически сразу же после возвращения узла в строй перешлют на него эти объекты. Т.е. не нужно ждать репликации всей системы, чтобы вернуть узел в 100% консистентное состояние. Разумеется, есть и минусы, при очень больших даунтаймах сохранение списка дает некоторую нагрузку. + RiakCS - хороший уровень функциональности, была коммерческая поддержка. В некотором роде устроен проще LeoFS т.к. фактически просто хранит объекты поверх RiakKV, базы ключ:значение. Т.е. фактически крупные объекты разбиваются на куски, распределяются по серверам и там записываются в большую пачку LevelDB баз. - RiakCS - разделение на свободную и коммерческую версию, и вообще компания Basho разорилась :(. Также значительно медленнее, чем LeoFS при использовании жестких дисков, т.к. хранить в LevelDB и данные, и метаданные не очень хорошо по производительности по сравнению с подходом LeoFS, когда там только метаданные, а данные в append-only файле. - RiakCS - поддержка multi-DC была только в коммерческой версии, не в свободной(а они разорились). В LeoFS multi-DC бесплатно. Minio - вот тут не могу сказать, но это очень новый продукт, что (лично для меня) сразу огромный минус. По фичам и планам там все весьма интересно. Если созреет, будет очень хорошей альтернативой.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	28. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от Moomintroll (ok) on 30-Мрт-18, 13:07
	> любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты Т.е. LeoFS не предлагает готовую тулзу? Даже несмотря на то, что "Формат там элементарный"?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	35. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
	Сообщение от Stax (ok) on 30-Мрт-18, 13:23
	>> любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты > Т.е. LeoFS не предлагает готовую тулзу? Даже несмотря на то, что "Формат > там элементарный"? :) Висит в багтрекере, но у них не хватает рук. Официальная утилита же должна быть нормальной, удобной и фичастой, а это уже не несколько часов. А задач важных много. Некоторые пользователи от них крупных фич хотят (server-side encryption, erasure coding, поддержку 3 и более датацентров одновременно и т.п.), с другой стороны баги известные есть, с третьей документация неидеальна (по использованию еще ничего, а вот техническая про нутрянку - как что хранится и работает, для лучшего понимания, какие действия делать в случае проблем - слабовата). Но если хочется убедиться, что "формат элементарный", вот совсем уж наколеночная тулза для листинга AVS-файла. После небольшой модификации может и сохранять объекты из него: https://github.com/mocchira/leofs_utils/blob/master/tools/li... Ну а вообще, изначально я имел ввиду "написать самому" имено с точки зрения, что оно достаточно просто, что можно обращаться даже по принципу "сделай все сам", если совсем припрет. Вообще без какого-либо кода от разработчиков.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	41. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от Andrey Mitrofanov on 30-Мрт-18, 14:20
	>> А про сравнить с люстрой кто-то что-то сказать может? > Это не аналог люстры и не предназначено для больших кластеров. Это объектный > сторейдж. Есть у вас до фига каких-то данных в виде множества > мелких сущностей и ваши приложения с этим работают. Вы хотите их > хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле > - вот это то, что нужно. А если ваш софт уже > умеет S3 (многое из коробки умеет; если это что-то свое, то > дописать совсем несложно, благо реализации S3 есть почти для всего и > они достаточно удобные в использовании), то обойдетесь минимум изменений. PohmelFS с японцами, шашками и амазоном вместо яндекса?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	43. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+1 +/–
	Сообщение от Alexander (ok) on 30-Мрт-18, 15:03
	opennet - торт! Спасибо, Stax! Имхо, ваши комментарии вполне на отдельную статью тянут.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	70. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от RomanCh (ok) on 30-Мрт-18, 22:37
	> opennet - торт! Спасибо, Stax! Имхо, ваши комментарии вполне на отдельную статью > тянут. Аккуратнее доверяйте комментариям в интернетах. См. рядышком каммент #69 где я смею выражать сомнения в авторитетности автора относительно заключений конкретно по Ceph.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	47. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
	Сообщение от evkogan on 30-Мрт-18, 15:58
	Спасибо, отличное описание. Если оформите как статью будет здорово. Прежде чем написать вопрос погуглил, хотя искал сравнение с люстрой, ничего не нашлось, если бы вылезло сравнение с CEPH заметил бы. Просто чисто объектные хранилища мне не очень интересны, но общее понимание что есть что и куда смотреть лучше в случае чего пригодится.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	69. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от RomanCh (ok) on 30-Мрт-18, 22:35
	Мм, рассказ тут не про Ceph, но когда набрасываете, то извольте конкретно излагать. > Ceph - устроен значительно сложнее, чем LeoFS. Базовый комплект необходимый для работы - 3 сервера-монитора (можно один, если вы - герой мозга) и условно неограниченное количество OSD серверов на которых хранятся данные. mon сервера хранят "карту сети", osd хранят данные и проводят операции с ними же, никаких серверов под метаданные не нужно. Сложно? Вроде нет. Для дополнительных плюшек (s3/rados-gateway/iscsi и т.п) нужны будут отдельные сервера обслуживающие эти сервисы, но это нормально и в целом адекватно - архитектура наращивается по мере необходимости. >  Если у вас будут проблемы с данными.. вам сильно не повезло. Восстанавливать вручную сложно, долго, дорого. Можно за деньги, дорого. В каких режимах использования Ceph и как конкретно вы добивались "проблем с данными" на Ceph? И каких конкретно проблем? И что конкретно не получилось восстановить? Единственный зафиксированный у нас случай когда таки проблема _могла быть_, это когда погорячились и выдернули сбойный диск раньше чем с него унесли все данные. На нём осталось некоторое количество данных без копий в остальном кластере. Но это получилось только потому что: в этом пуле была избыточность 2 (т.к. резервный кластер, в продных везде 3), коллеги поспешили. Проблемный диск потом подключили к другому серверу, экспортировали с него (штатной утилитой) недонесённые данные, импортировали в кластер и всё в порядке. Ceph вам вполне конкретно пишет какие данные и где потерялись, и где он их пытался искать. На диске у него данные хранятся как каталоги в которых лежат никаким особым образом не кодированные куски данных что вы в него пихнули. Мне вполне сложно понять что можно в этом не понять. Потому пруф на проблему неописуемой сложности, или вы сказочник. > Также есть сильное подозрение (частично подтвержденное небольшим опытом эксплуатации) все режимы Ceph, кроме того же объектного сторейджа это не очень надежно Есть сильное подозрение что вы свои фантазии выдаёте со слишком авторитетным видом, слабо подчёркивая что это ваши фантазии на очень скромном опыте. > Проблема не в них как таковых, а в том, что когда вы сделаете виртуальный RDB, а потом попытатесь сделать вид, что это-таки настоящий block device, то те, кто работают с этим потом в случае минорных проблем сети (моргнуло питание, перегрузились свитчи, зависла железка и т.п.) несколько не ожидают особенностей поведения виртуального block device, что приводит к серьезным последствиям. Звучит как полная ерунда. Извините, но это самое мягкое что могу подобрать для характеристики ваших слов. Возможно ваш негативный опыт обусловлен какими-то ранними/тестовыми версиями, неудачным выбором ФС поверх RBD, плохим железом, чем-то ещё, не знаю. RBD'шки с образами от десятков гигабайт, до десятков терабайт спокойно переживают рестарты машин на которых они собраны, промежуточных сетей, клиентов которые в них пишут, OSD на которых хранятся данные и т.п. (я тут хочу сказать что хранить данные в Ceph в многотерабайтных RBD это вообще неправильно, но такая ситуация сложилась из экстренных требований бизнеса) Опять же, формулировка "серьёзным последствиям" звучит конечно очень внушительно, но не более чем статья со швабры в начале обсуждения. Конкретики чуть-чуть намазать нельзя было? Ну типа какого характера в итоге проблема была, как добились, почему не чинилось? Ну и вы говорили про "все режимы", а как же режим CephFS? Или не проверяли? > нет multi-DC репликации. Извините, я наверное на швабру просто не хожу практически совсем, потому отстал от мира и не вполне понимаю о чём вы тут речь ведёте, в чём суть "репликации"? На всяк случай, вдруг речь об этом: в Ceph можно сделать столько копий сколько попросите, и разложить их строго по тем дискам/хостам/стойкам/рядам/комнатам/ЦОДам/континентам (там по дефолту 10 градаций), по скольким вам это захочется сделать. Что-то вроде: "первую копию на SSD ЦОДа А, вторую копию на SSD ЦОДа Б, третью на медленные и большие диски ЦОДов В и Г, а четвёртую мы отправим в другое полушарие". Или этого недостаточно и нужна какая-то доп.магия? PS Я против LeoFS ничего не имею, хотя бы потому что ничего о ней не знаю. Не нравится когда с авторитетным видом рассказывают ерунду. PPS Ceph у нас около 2 Пб, потому чуть-чуть представляю о чём говорю.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	74. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+1 +/–
	Сообщение от Stax (ok) on 31-Мрт-18, 11:03
	> Мм, рассказ тут не про Ceph, но когда набрасываете, то извольте конкретно > излагать. Тоже не хотелось бы, но пару вещей прокомментирую. >> Ceph - устроен значительно сложнее, чем LeoFS. > Базовый комплект необходимый для работы - 3 сервера-монитора (можно один, если вы > - герой мозга) и условно неограниченное количество OSD серверов на которых > хранятся данные. mon сервера хранят "карту сети", osd хранят данные и > проводят операции с ними же, никаких серверов под метаданные не нужно. > Сложно? Вроде нет. Для дополнительных плюшек (s3/rados-gateway/iscsi и т.п) нужны будут > отдельные сервера обслуживающие эти сервисы, но это нормально и в целом > адекватно - архитектура наращивается по мере необходимости. Например, вот это https://github.com/ceph/ceph/tree/master/systemd - в особенности то, как оно интегрируется с udev - на порядок сложнее LeoFS. И вообще, все познается в сравнении. Там 3 простых типа узла, для (продакшен!) настройки каждого достаточно прописать или поменять 3-4 строки в конфиге и все будет работать как часы. Данные хранятся в обычном каталоге. Но дело не только в установке, само хранение данных в LeoFS очень простое. А вот вам вопрос на засыпку: в руководстве по установку Ceph написано "отключите selinux". Это что вообще за фокусы, почему в 2018 году программа этого требует? > В каких режимах использования Ceph и как конкретно вы добивались "проблем с > данными" на Ceph? И каких конкретно проблем? И что конкретно не > получилось восстановить? Единственный зафиксированный у нас случай когда таки проблема > _могла быть_, это когда погорячились и выдернули сбойный диск раньше чем > с него унесли все данные. На нём осталось некоторое количество данных > без копий в остальном кластере. Но это получилось только потому что: > в этом пуле была избыточность 2 (т.к. резервный кластер, в продных > везде 3), коллеги поспешили. Проблемный диск потом подключили к другому серверу, > экспортировали с него (штатной утилитой) недонесённые данные, импортировали в кластер > и всё в порядке. В режиме RBD, но это не так важно. Вот подумайте над тем, что вы только что написали: вас сам факт, что данные не чексаммятся и при наличии одной копии объекта оно даже не знает, корректная ли она - не смущает? А при наличие двух живых и различающихся - как выбирает? Вот в LeoFS данные между копиями всегда сверяются относительно эталонной, возникаюшей при сохранении объекта (когда вычисляется ETag, который возвращается клиенту в ответ на операцию). В режиме strict все данные проверяются и на всех чтениях. Даже если вы унесете диск, на котором среди неповрежденных данных была последняя копия, вы все равно можете ВЕРНУТЬ его и взять с него эту копию. И она проверится по контрольным суммам, что не поверждена перед репликацией. Да, разумеется на операции PUT в S3 и REST режимах можно еще хоть на клиенте вычислить эти контрольные суммы и сразу передать заголовок, и он проверит, что данные не побились на передаче, если вы совсем параноик. >> Также есть сильное подозрение (частично подтвержденное небольшим опытом эксплуатации) все режимы Ceph, кроме того же объектного сторейджа это не очень надежно > Есть сильное подозрение что вы свои фантазии выдаёте со слишком авторитетным видом, > слабо подчёркивая что это ваши фантазии на очень скромном опыте. Т.е. утверждение на оф. сайте, что CephFS тот же NOT PRODUCTION READY это ок? Или то, что сам Ceph открыто предлагают ставить на Btrfs, который и сам по себе разваливается - это ок? > Возможно ваш негативный опыт обусловлен какими-то ранними/тестовыми версиями, неудачным > выбором ФС поверх RBD, плохим железом, чем-то ещё, не знаю. В 2014 году - тестовые? А когда же тогда стабильные? Я не помню, что там поверх было, но либо Ext4, либо XFS, других вариантов-то нет. Скорее Ext4. Но дело тут вот в чем. Вы посмотрите, как внутри хранит данные LeoFS. У вас есть большой линейный файл, заголовок-данные, заголовок-данные.. В заголовке - полная контрольная сумма объекта, который собственно "данные". Для больших объектов чуть хитрее, но ненамного: они разрезаются на куски (по возможности еще на S3 клиенте, но можно и на шлюзе), для каждого куска та же контрольная сумма, плюс заголовочный объект, по которому видно размер/куски/общая контрольная сумма. Все как на ладони, все прошито контрольными суммами, ETag'ами оригинального объекта. Никаких потерь на множество файлов и размазанные метаданные. На ФС, на которой это лежит ему по большому счету вообще по фигу, хоть рекомендуют XFS, но на практике разницы нет. Большие файлы append-only формата имеют очень серьезные плюшки. Это я к тому, что тут и "неудачный выбор" не сделать, и если "плохое железо" и т.п., пострадать особо не выйдет. А для Ceph есть и нюансы с ФС, которая под хранилищем, и больше нюансов в эксплуатации. Говорю же, там все сложнее. > RBD'шки с образами от десятков гигабайт, до десятков терабайт спокойно переживают рестарты > машин на которых они собраны, промежуточных сетей, клиентов которые в них > пишут, OSD на которых хранятся данные и т.п. (я тут хочу > сказать что хранить данные в Ceph в многотерабайтных RBD это вообще > неправильно, но такая ситуация сложилась из экстренных требований бизнеса) Это да. Неправильно, но иногда есть требования. > Опять же, формулировка "серьёзным последствиям" звучит конечно очень внушительно, но не > более чем статья со швабры в начале обсуждения. Конкретики чуть-чуть намазать > нельзя было? Ну типа какого характера в итоге проблема была, как > добились, почему не чинилось? Почему не чинилось? Чинилось. Но блоки в конечном итоге в RBD оказались некоторые побитые в итоге (немного). Когда это приходилось на метаданные фс, фс грустила. > Ну и вы говорили про "все режимы", а как же режим CephFS? > Или не проверяли? Нет, отметка "not production ready" отговорила. >> нет multi-DC репликации. > Извините, я наверное на швабру просто не хожу практически совсем, потому отстал > от мира и не вполне понимаю о чём вы тут речь > ведёте, в чём суть "репликации"? У вас есть основной ДЦ, пусть с 4 копиями данных. У вас есть второй ДЦ, пусть с 3 копиями данных. И там, и там идет работа с данными. Нужно, чтобы в обоих кластерах данные синхронизировались. Нужно, чтобы система не паниковала и не тормозила ни в одном из ДЦ, когда между серверами пропадает коннект, проседает до 100 мбит и другие реальности жизни. > На всяк случай, вдруг речь об этом: в Ceph можно сделать столько > копий сколько попросите, и разложить их строго по тем дискам/хостам/стойкам/рядам/комнатам/ЦОДам/континентам Первое же руководство говорит, что там только синхронная репликация и ему нельзя объяснить, что вот это локально и должно работать, а вот это между ДЦ, высоколатентно и может проседать. И когда это случится, записям в это время будет довольно грустно. В LeoFS и RiakCS именно репликация двух кластеров между ДЦ как отдельная система. > (там по дефолту 10 градаций), по скольким вам это захочется сделать. Ну, не знаю зачем 10 градаций, по-моему "сервер", "стойка" и "ДЦ" более чем достаточно. > Что-то вроде: "первую копию на SSD ЦОДа А, вторую копию на > SSD ЦОДа Б, третью на медленные и большие диски ЦОДов В > и Г, а четвёртую мы отправим в другое полушарие". > Или этого недостаточно и нужна какая-то доп.магия? Судя по документации, так делать категорически нельзя. > PS Я против LeoFS ничего не имею, хотя бы потому что ничего > о ней не знаю. Не нравится когда с авторитетным видом рассказывают > ерунду. Я могу и не ерунду, просто надо понимать, что с LeoFS я успел плотно поработать, кое-какие вещи помог там доработать даже, а Ceph несколько лет как не интересуюсь. Мне на уровне концепций тамошняя исключительная простота (то, что то ли я никак не могу вам правильными словами объяснить, то ли вы мыслите совсем в другом ключе и не хотите понимать, утверждая что "ceph тоже несложный") очень понравилась. Я прекрасно понимаю, что у Ceph есть своя - и немалая - ниша, но там, где хватает LeoFS, есть реальные причины предпочесть его. Так что не надо спрашивать меня про Ceph, хотите спросить про LeoFS - спрашивайте.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	77. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от RomanCh (ok) on 31-Мрт-18, 13:47
	> Например, вот это https://github.com/ceph/ceph/tree/master/systemd - в особенности то, как оно интегрируется с udev - на порядок сложнее LeoFS. Что "вот это"? Список юнитов systemd вас испугал, или наличие *готовых* (вам велосипедить не надо) юнитов в продукте является отягчающим обстоятельством? А зачем вы туда вообще полезли, что бы пугать детишек? Вам для эксплуатации в базовом комплекте нужно знать только про ceph-osd@.service и про ceph-mon@.service. И то, на уровне "у них есть команды stop, start, restart". Как оно внутри работает с udev, linux kernel, ктулху и прочим вас вообще не должно колыхать. Нас во всяком случае не трогает, потому что оно "просто работает". > Там 3 простых типа узла, для (продакшен!) настройки каждого достаточно прописать или поменять 3-4 строки в конфиге и все будет работать как часы Ceph внезапно два типа узла (я про это уже писал), в настройках вообще ничего можно не менять если собираете наколенный кластер для хранения нескольких тер данных на 3-5 нодах. Сетапите по инструкции и используете закрыв глаза. И даже будет отказоустойчиво. > А вот вам вопрос на засыпку: в руководстве по установку Ceph написано "отключите selinux". А давайте мы будем обсуждать исходные претензии к СХД и тому как оно "плохо/сложно" работает и какие у него проблемы, а не тот вопрос который вам показался удобным что бы уйти от неудобной ситуации. (но вообще вы в очередной раз передёргиваете, к сожалению http://docs.ceph.com/docs/kraken/start/quick-start-preflight...) > данные не чексаммятся и при наличии одной копии объекта оно даже не знает, корректная ли она - не смущает? Вообще-то знает. Вы очевидно читали что я написал по диагонали и потому ничего не поняли. Более того, есть механизм (deep) scrub, но про него вы видимо тоже ничего не знаете. Проводить краткую лекцию по Ceph не собираюсь, но обращаю внимание что вы опять уходите от прямого вопроса: какие конкретно были проблемы и почему они были с вашей ТЗ не решаемы и якобы упирались в деньги? > Вот в LeoFS ... Рад за них, и никому не говорю что "плохо, не используйте!", потому что ничего о нём не знаю. И советую вам делать то же самое - не рассуждать о том в чём не разбираетесь. > Т.е. утверждение на оф. сайте, что CephFS тот же NOT PRODUCTION READY это ок? Или то, что сам Ceph открыто предлагают ставить на Btrfs, который и сам по себе разваливается - это ок? Оба этих сильных заявления выявляют необходимость актуализации ваших представлений о Ceph и том что они официально рекомендуют. ;-) > В 2014 году Ясно. Делать столь сильные заявления в IT базируясь на 3-4летнем опыте. Это действительно сильно и смело. Только неразумно. > Но дело тут вот в чем. Вы посмотрите, как внутри хранит данные LeoFS. Да нет же, не буду я ваших слонов покупать, мне и со своими хорошо. Уймитесь! > А для Ceph есть и нюансы с ФС, которая под хранилищем Нюанс там один, и он очень сложный для адекватного админа - ФС должна быть пригодна для хранения большого объёма данных. Да, наверное если поставить на ext2 то будут "нюансы", но это явный приступ героизма. > Судя по документации, так делать категорически нельзя. Странную вы какую-то документацию читаете. В сухом остатке имеем один пункт который реально можно подтвердить - отсутствие той самой высокоуровневой репликации, на которую у разработчиков Ceph затачивания явно не было. Но в описаной вами ситуации использования Ceph через RBD вам она ничем не помогла бы. Все остальные проблемы выглядят мягко говоря слегка надумаными. > а Ceph несколько лет как не интересуюсь. Ну так и не стоит делать выводов в духе "там всё сложна-ломается" и тут же сравнивать с тем что вы используете те же N лет и потому знаете как облупленное. Именно об этом посыл предыдущего мессаджа, да и этого. Не стоит пытаться выглядеть авторитетным там где вы таковым не являетесь, в конце концов нельзя быть авторитетным во всём, но нормальный специалист от этого страдать не должен. > Так что не надо спрашивать меня про Ceph Так не надо про него рассказывать небылицы которые может и были актуальны, но несколько лет назад. А вот теперь, более конструктивно о теме топика, коли вы выступаете как человек который хорошо в нём разбирается. В двух словах - потенциально можно загнать туда несколько сот Тб видеофайлов, при условии что со свежими файлами постоянно идёт работа (редактирование) и к ним нужен Posix FS доступ, а старые могут в рандомном порядке запрашиваться пользователем. И в ситуации "один ЦОД лёг" не получить тыкву в данных или split brain после восстановления?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	78. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от Stax (ok) on 31-Мрт-18, 14:45
	> Что "вот это"? Список юнитов systemd вас испугал, или наличие *готовых* (вам > велосипедить не надо) юнитов в продукте является отягчающим обстоятельством? А зачем Вы действительно не понимаете или только делаете вид? Вопрос не в наличии, а в том, что внутри. > start, restart". Как оно внутри работает с udev, linux kernel, ктулху > и прочим вас вообще не должно колыхать. Нас во всяком случае От грамотного админа во-первых все-таки требуется понимание, как оно работает с udev и прочим. Как там внутри реализовано - можно не знать, а как оно взаимодействует с системной - знать надо. Во-вторых, само наличие таких зависимостей это усложнение системы. Это и есть минус. > (но вообще вы в очередной раз передёргиваете, к сожалению http://docs.ceph.com/docs/kraken/start/quick-start-preflight...) От того, что здесь это написано чуть более мягкими словами, факт, что предлагают отключить не меняется. Как внешний сервис, сами демоны ceph все равно не ограничены политикой selinux по умолчанию. Раз требуется отключать, значит он куда-то лезет в более системные вещи, нарываясь на то, что запрещено по умолчанию. Сам факт этого не очень плох (хотя то, что с пакетами не дают соответствующей политики selinux немного печалит); но это еще один признак усложнения системы. >> данные не чексаммятся и при наличии одной копии объекта оно даже не знает, корректная ли она - не смущает? > Вообще-то знает. Вы очевидно читали что я написал по диагонали и потому > ничего не поняли. Более того, есть механизм (deep) scrub, но про Расскажите, можно со ссылкой на документацию. Где там хранятся контрольные суммы объектов и как именно они проверяются? > него вы видимо тоже ничего не знаете. Проводить краткую лекцию по scrub, который просто считает сумму на лету исключительно для сравнения с другими репликами? Еще раз, кейз: есть две живых копии, одна искажена. Как именно это найдется? > прямого вопроса: какие конкретно были проблемы и почему они были с > вашей ТЗ не решаемы и якобы упирались в деньги? Потому что так вопроса не стояло. И вообще, нерешаемых проблем при достаточном желании не существует. Но решения бывают оптимальные и неоптимальные. > Рад за них, и никому не говорю что "плохо, не используйте!", потому > что ничего о нём не знаю. И советую вам делать то > же самое - не рассуждать о том в чём не разбираетесь. А я не говорю, что плохо. Я указываю на конкретные проблемы. Сложность и отсутствие внятных контрольных сумм. Про сложность вы понимать не хотите, ок, проехали. Про контрольные суммы хотя бы чуть более полноценно прокомментируете? Не обязательно своими словами, можно ссылкой на документацию, где есть внятный ответ - я не запарюсь, прочту. >> В 2014 году > Ясно. Делать столь сильные заявления в IT базируясь на 3-4летнем опыте. Это > действительно сильно и смело. Только неразумно. Ну как есть. Я же не вызываюсь комментировать новые инсталляции ceph и решать в них проблемы :) Этим можете вы заняться. >> Судя по документации, так делать категорически нельзя. > Странную вы какую-то документацию читаете. Т.к. фичи нет, то в документации про нее напрямую и не написано - логично? А так находится например https://tracker.ceph.com/projects/ceph/wiki/Can_Ceph_Support... > В сухом остатке имеем один пункт который реально можно подтвердить - отсутствие > той самой высокоуровневой репликации, на которую у разработчиков Ceph затачивания явно > не было. Но в описаной вами ситуации использования Ceph через RBD > вам она ничем не помогла бы. Конечно, не помогла. Но RBD это уже не от хорошей жизни. > Ну так и не стоит делать выводов в духе "там всё сложна-ломается" Вы просто не хотите понять. Вообще про что угодно можно сказать "не сложно", если хорошо разобраться. Но с точки зрения структуры хранения и работы с данными LeoFS устроен проще и надежнее. Также, рассуждая логически, есть основания считать, что LeoFS будет сильно быстрее (именно как объектный сторейдж), особенно на маленьких объектах; но возможности провести осмысленный бенчмарк у меня нет, а в целом это видимо никому не интересно. Т.к. и тот, и другой способны обеспечить "достаточную" производительность при правильном подходе и другие факторы тут куда важнее этих циферок. > и тут же сравнивать с тем что вы используете те же > N лет и потому знаете как облупленное. Совсем не так долго использую, на самом деле (годик, наверное). > В двух словах - потенциально можно загнать туда несколько сот Тб видеофайлов, > при условии что со свежими файлами постоянно идёт работа (редактирование) и > к ним нужен Posix FS доступ, а старые могут в рандомном > порядке запрашиваться пользователем. И в ситуации "один ЦОД лёг" не получить > тыкву в данных или split brain после восстановления? Я тут в другом ответе давал комментарии про Posix FS доступ через NFS. Вкратце: нет, на таких нагрузках это не будет работать, надо использовать через S3 API. Несколько сот ТБ само по себе не проблема, есть вопросы про размер объектов и то, какими кусками идет их изменение (всегда заливка новой версии объекта целиком? Или вообще всегда идет сохранение объекта с новым именем, старые через какое-то время удаляются?). Про ЦОД, split brain и прочее - надо все рассматривать конкретнее. Параметры консистентности R/W/D настраиваются, чтобы получить нужный баланс между консистентностью и доступностью, от полной консистентности до полной доступности. В режиме Multi DC репликация между ДЦ это отдельный канал со своими независимыми настройками репликации R/W/D. Приложения не знают про то, произошла ли Multi DC репликация, операции в каждом ДЦ работают возвращают результат на основе параметров R/W/D в этом ДЦ. Давайте тогда задам встречный вопрос про ceph. Вижу вот такие баги https://bugzilla.redhat.com/show_bug.cgi?id=1457767 - становится страшно. Есть потребность хранить объекты, средний размер 70 КБ, на узел с 4 дисками по 6 ТБ влезают 300 млн таких объектов. Все нормально будет, никаких проблем с производительностью? Потому что на решении, которое было до LeoFS, в какой-то момент от количества сущностей в файловой системе оно начало еле ползать на операциях с метаданными типа листинга (доступ к объекту по конкретному имени норм). Из-за того, что слишком большое количество объектов в ФС это огромные расходы на метаданные, которые не влезают в кэш. Где-то на 50 млн становится заметны подтупливания, а когда >100 млн, совсем грустно. С 300 млн просто тоска-печаль. Если ставить современный Ceph последней версии и все правильно настроить - никаких проблем не ожидается?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	80. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от RomanCh (ok) on 31-Мрт-18, 17:01
	> Вы действительно не понимаете или только делаете вид? Вопрос не в наличии, а в том, что внутри. Внутри всё работает так как обещали. Или вы дома каждый утюг и монитор разобрали что бы убедиться что понимаете как оно взаимодействует внутри себя? Всё остальное больше похоже на риторические упражнения в духе "а нет, всё равно я вас переговорю!" Вместо убедительных примеров "была ситуация А, я с ней вступил в проблему Б", вы начинаете из пальца высасывать какие-то потенциальные проблемы которые когда-то могут произойти если Луна будет в Козероге при свете Венеры. У меня на работе более чем достаточно реальных задач которые нужно решать. Чем мы и занимаемся, не пытаясь зачем-то (зачем?) разобраться с тем что в целом сносно документированно (все интересующие вопросы всегда получалось разрешить), работает ожидаемым образом, не выкидывая коленца и есть не просит. Я вот например сильно сомневаюсь что вы хорошо разбираетесь в кишках ерлангового кода LeoFS, давайте теперь буду говорить "ну, вы не понимаете как там что взаимодействует" и прочую ерунду. Потенциальных проблем много в любой системе сложней Hello world!, и в LeoFS уверен, тоже. Ещё раз напомню что этот бугурт тред не про то что Ceph-супер-не-имеет-проблем, или про то что LeoFS-плох-ужасен-не-используйте. А про то что вы взялись кидаться заявлениями из которых подтвердить можно только одно, и то - оно относится не к багам, а к отсутствующим фичам. > Потому что так вопроса не стояло. И вообще, нерешаемых проблем при достаточном желании не существует. Ну короче начался слив. На самом деле разобраться было можно, но не стали. Я не говорю что это плохо, иногда действительно проще применить другое решение чем разбираться с тем что "не пошло". Я говорю что плохо на основании такого опыта делать глубоко идущие выводы. > Т.к. фичи нет, то в документации про нее напрямую и не написано - логично? А, т.е. вы опять меня читали по диагонали. Я вам сказал что "да, такой фичи нет", вы мне: "нет, фичи нет!" О_о И то про что я вам писал, и что вы прокомментировали как "категорически нельзя" было несколько про другое, и в этой ссылке про это же написано, но к слову никакой "категоричности" тут не наблюдается. Т.е. снова передёргивание. > Вы просто не хотите понять. Нет, это просто вы не хотите понять что оказались в некрасивой ситуации когда выяснилось что большая часть из того что вы наговорили конкретно про Ceph - ерунда :) Как про остальное - не знаю. Но дело ваше, можете и дальше жить с данными N-летней давности в голове. Дальше эту тему обмусоливать не вижу смысла. > Вкратце: нет, на таких нагрузках это не будет работать, надо использовать через S3 API. Ясно, спасибо. С переделкой в объектное хранилище в принципе и Ceph заработает так как надо. Идея найти что-то требующее минимального перекраивания архитектуры. Хотя скорее всего это нереально. > Давайте тогда задам встречный вопрос про ceph Непонятно к чему этот вопрос. То что будет проблема на огромном количестве мелких объектов - никто никогда не спорил. Не только в листинге объектов, но и банально inode могут закончиться и приплыли. Именно потому там и пилят BlueStore, и даже какие-то каскадёры с ЛОРа его у себя используют (несмотря на ужасные огораживания и предупреждения стреляющие прям из утилит типа "это может оказаться write only решение"). Но нам не актуально т.к. мы используем Ceph как СХД а не как хранилище метрик (что само по себе странно но в целом не противоречит концепции объектного хранилища, наверное). Ещё раз - проблемы есть, они есть везде. Но это не те проблемы с которых вы начали. На этом я пожалуй заканчиваю этот тредик, я думаю интересующимся достаточно инфы что бы самим изучать предмет, а не руководствоваться "авторитетными комментариями" в интернетах.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	81. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
	Сообщение от Stax (ok) on 31-Мрт-18, 18:58
	> Я вот например сильно сомневаюсь что вы хорошо разбираетесь в кишках ерлангового > кода LeoFS, давайте теперь буду говорить "ну, вы не понимаете как > там что взаимодействует" и прочую ерунду. Не разбираюсь - но в том-то и фишка, что оно "со стороны" в достаточной степени просто, чтобы понимать достаточно. >> Т.к. фичи нет, то в документации про нее напрямую и не написано - логично? > А, т.е. вы опять меня читали по диагонали. Я вам сказал что > "да, такой фичи нет", вы мне: "нет, фичи нет!" О_о И Вы лучше дайте ответ про контрольные суммы - на вопросы из предыдущего комментария. А то некрасиво получается, говорите, что они есть, а показать это в документации не хотите. Я вот так читаю документацию, что их нет. И нет, то, как оно сравнивает одну реплику относительно другой не интересно. Интересно, как оно сравнивает с эталоном - тем, что изначально было записано. >> Вы просто не хотите понять. > Нет, это просто вы не хотите понять что оказались в некрасивой ситуации > когда выяснилось что большая часть из того что вы наговорили конкретно > про Ceph - ерунда :) Как про остальное - не знаю. Что именно, про сложность и что из-за этого сложно будет восстанавливать? >> Вкратце: нет, на таких нагрузках это не будет работать, надо использовать через S3 API. > Ясно, спасибо. С переделкой в объектное хранилище в принципе и Ceph заработает > так как надо. Идея найти что-то требующее минимального перекраивания архитектуры. Хотя > скорее всего это нереально. Если у вас такие хитрые потребности (хранить многогигабайтные объекты), я бы смотрел на что-то другое, только и всего. Хотя вон Project FiFo использует LeoFS для хранения образов VM и снапшотов и им нравится - когда там выбирали хранилище, LeoFS оказался самым быстрым (во всяком случае, сильно обгонял RiakCS). Просто с моей точки зрения это несколько сомнительно. >> Давайте тогда задам встречный вопрос про ceph > Непонятно к чему этот вопрос. То что будет проблема на огромном количестве > мелких объектов - никто никогда не спорил. Не только в листинге В смысле? Это я из реальной задачи, между прочим. Есть файлы (картинки, бинарники, не важно), разброс 0 байт - 20 мегабайт. Распределение такое, что среди них много мелких. Средний размер выходит 70 КБ, нужно, чтобы быстро работало и с мелкими объектами, но и не тормозило на крупных. Вот прямо сейчас на каждом узле LeoFS лежит что-то типа 160 млн объектов (заполнение узлов где-то 50%) и по скорости все очень быстро. Вообще никаких проблем с айнодами, записью, чтением и т.п. И ему реально по фигу, на какой FS это находится физически. На каждом из 4 дисков находится по 64 контейнера (каждый контейнер это AVS-файл + LevelDB база из нескольких файлов), метаданные легко кэшируются и не дают оверхеда на ФС. Я, в целом, не имею понятия, насколько это бы хорошо лежало в Ceph при тех же ресурсах. В файловой системе или в Swift - нереально. > не актуально т.к. мы используем Ceph как СХД а не как > хранилище метрик (что само по себе странно но в целом не > противоречит концепции объектного хранилища, наверное). Ну имхо это несколько странная идея, хранить метрики в объектном хранилище, имхо для этого лучше NoSQL базу взять, HBase к примеру. Впрочем, думаю, возможно все.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	82. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
	Сообщение от alexk (??) on 01-Апр-18, 16:42
	Главная проблема ceph - это все же контрольные суммы данных. Bluestore появился совсем недавно, а до этого вам могли вернуть совсем не те данные что вы записали. Для хранилища данных очень больших объемов декларация о том что оно production ready без этой опции - это крайняя степень оптимизма.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	71. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–2 +/–
	Сообщение от kvaps (ok) on 30-Мрт-18, 22:43
	> Это не аналог люстры и не предназначено для больших кластеров. Можно поподробнее, почему нет? Насколько возможна расширяемость LeoFS и во что можно упереться при использовании ее в больших кластерах? > до фига каких-то данных в виде множества мелких сущностей > хранить распределенно, чтобы отказоустойчиво и быстро Как раз это больше всего и привлекает. В статье заявлена поддержка nfs - возможно ли и насколько резонно использование LeoFS в качестве классической POSIX-совместимой файловой системы? > у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС Как в этом случае поступает LeoFS? Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли? PS: Большое спасибо за ваши ответы :)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	72. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от RomanCh (ok) on 30-Мрт-18, 23:02
	> Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли? Не так. Ceph замечательно работает например на 3х нодах ProxMox, который хранит в нём диски виртуалок тем самым организуя отказоустойчивость и прозрачную миграцию виртуалки с ноды на ноду - никакие данные носить не нужно, всё уже есть. Другое дело что Ceph может работать на кластерах с заметным объёмом показывая в целом неплохой результат. За LeoFS ничего не скажу, потому что ничего не знаю, и в отличии от автора того камента со "сравнениями" не буду обсуждать то в чём совсем не разбираюсь.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	75. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+1 +/–
	Сообщение от Stax (ok) on 31-Мрт-18, 11:20
	> Можно поподробнее, почему нет? > Насколько возможна расширяемость LeoFS и во что можно упереться при использовании ее > в больших кластерах? Например, система репликации построена так, что другие серверы знают (помнят), где чего при попытке записи не записалось. Что, с одной стороны, позволяет очень быстро сделать все данные на сервере, который вновь включился в строй корректными, но с другой может дать оверхед при слишком большом даунтайме. Большой кластер - больший риск даунтайма. Есть еще разные ограничения, которые в принципе планируется снять, но в данный момент это не так приоритетно т.к. под большие кластеры никто не затачивает. Например, невозможность одновременного восстановления двух потерявших данные узлов, только последовательно. Также тестовые конфигурации разработчиков не покрывают большие кластеры, а там могут быть свои засады. И т.п. Вообще говоря о больших кластерах, лучше оперировать не числом узлов, а конкретными цифрами, сколько объектов хочется хранить, какой средний размер, какое распределение по размеру (совсем грубо хотя бы), какую нагрузку R и W требуется держать. И спросить разработчиков, оперируя этими цифрами. Какие у вас задачи-то? >> до фига каких-то данных в виде множества мелких сущностей >> хранить распределенно, чтобы отказоустойчиво и быстро > Как раз это больше всего и привлекает. В статье заявлена поддержка nfs > - возможно ли и насколько резонно использование LeoFS в качестве классической > POSIX-совместимой файловой системы? Там есть множество ограничений как серьезных, которые вряд ли будут в ближайшее время менять - нет поддержки блокировок, нет поддержки прав, не знаю как (возможно, никак?) работает rewrite части объекта и т.п. Так и менее серьезных, которые поправят, но которые могут отравить жизнь на текущем этапе - не выйдет сделать листинг каталога с тысячами (и больше) файлов, могут быть отвалы коннекта определенных проблемах, падение скорости при записи больших (сотни МБ) файлов и т.п. Принципиально NFS поверх object storage хорошо сделать сложно. Разработчики пытаются, не готов сказать, получится ли. Хотелось бы. В некоторых режимах, например простые open/read конкрентых файлов по NFS в принципе все работать нормально; видимо, под это в первую очередь и писалось. Можете попробовать еще s3fs-fuse. Но по хорошему, я настоятельно рекомендую S3 API. И фич до фига сразу будет, и работает все отлично. >> у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС > Как в этом случае поступает LeoFS? Append-only файл формата заголовок-данные-заголовок-данные и т.п., где в заголовке неизменяемая часть, и отдельно небольшая LevelDB, хранящая смещение каждого объекта, индексы для префиксного поиска, статус объекта (актуален/удален) и т.п. > Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь > для больших кластеров и предназначен. Не так ли? Про Ceph тут рядом другой товарищ может отписать лучше :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	76. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от kvaps (ok) on 31-Мрт-18, 11:28
	Благодарю, очень исчерпывающе!
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	31. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	–1 +/–
	Сообщение от Gilneas on 30-Мрт-18, 13:13
	Мда. Вот смотрю я на тебя и вижу человека, который не может похвастаться широкими познаниями в предмете. Но других почему-то называешь тупыми. Парадокс.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	51. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+1 +/–
	Сообщение от evkogan on 30-Мрт-18, 16:21
	> Мда. Вот смотрю я на тебя и вижу человека, который не может > похвастаться широкими познаниями в предмете. Но других почему-то называешь тупыми. Парадокс. Я действительно не очень разбираюсь в объектных хранилищах. Ну не интересны они мне и пока не нужны. И первоначально подумал что это аналог люстры с доп фичами, а не объект-хранилка, со сбору прицепленым NFS. Но при этом моих знаний вполне хватает, чтобы понять что уже с первых строк авторы той статьи делают явно неправильную архитектуру. У нас для внутреннего использования делали пару систем куда заливались файлики с хранением всей сопутствующей инфы в БД Оракл (ну вот стоит он работает и спецы есть, от еще одной базы ему хуже не будет). Так там нагрузки и объемы на порядки меньшие, но никто даже не подумал хранить файлы (они там все априори больше 1Мб) в БЛОБах, лежат себе в папочке, а в БД ссылки. И все работает без проблем. Более того автор той статьи не отрицает, что им говорили что будет плохо, но они сделали и получили проблемы. В ЛеоФС я не разбираюсь, я о ней узнал сегодня. Но я разбираюсь в стораджах и системах кластеризации разных. Ну если Вы уже добавили новые сервера и на них должна была пройти репликация, а в результате получились проблемы, то просто на горячую эти сервера дергать нельзя. Лучше станет врядли, а вот хуже может очень даже стать. И хуже таки стало. Причем в стаье так и не сказал, сумели ли они восстановить данные и как? В чем странность моей позиции, если я говорю что не доверяю суждениям данного автора? Вы придрались к одному слову, ну хотите я извинюсь и скажу, что так говорить не хорошо. Но при этом подход я остаюсь при мнении, что автор сам сознательно создает себе проблемы и потом с ними борется, что вся его статья, это одно сплошное доказательство, что надо делать в соответствии с бест-практис, а все его проблемы это доказательство, что бест-практис верны. А как назвать человека, который делает анти бест-практис в продакшене, это каждый может решить сам.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	60. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 17:25
	Главное что ты знаешь как лучше.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

23. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
Сообщение от Moomintroll (ok) on 30-Мрт-18, 12:40
А есть какое-нибудь сравнение с Ceph? Вот Ceph я знаю уже давно — крупный и зрелый проект, а про LeoFS узнал только сейчас... Есть ли у LeoFS какие-лио преимущества перед Ceph? Почему люди (например, вон те, с болью) выбирают LeoFS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+3 +/–
	Сообщение от Stax (ok) on 30-Мрт-18, 13:05
	> А есть какое-нибудь сравнение с Ceph? > Вот Ceph я знаю уже давно — крупный и зрелый проект, а > про LeoFS узнал только сейчас... > Есть ли у LeoFS какие-лио преимущества перед Ceph? Почему люди (например, вон > те, с болью) выбирают LeoFS? Подробно описал выше. Пробовал Ceph. В итоге (без боли!) выбрал LeoFS. Если совсем упрощенно: у вас достаточно много денег, вам нужен коммерческий контракт - берите Ceph. У вас не так много денег, вы хотите что-то, что устроено максимально просто, но при этом достаточно быстро, и даже если вы (вдруг) вообще все на хрен там разломаете, чтобы ваши данные были легко доступны - берите LeoFS. За счет простоты он надежнее, вполне приятно ставится и обслуживается (особенно последние версии). Также, если вам позарзез нужна расширенная функциональность Ceph - берете, разумеется, Ceph. Но не стоит забывать, что там могут быть свои проблемы по сравнению с использованием в режиме обычного Object Storage. Если вам нужна хорошая совместимость с S3 из коробки, которую разработчики ставят в приоритет - лучше взять LeoFS (но это немного субъективно). Если вам нужна multi-DC репликация - точно берете LeoFS. (но это вообще сложная тема и там могут быть свои проблемы в любом случае).
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

30. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
Сообщение от Аноним (??) on 30-Мрт-18, 13:09
Интересно, есть ли у нее место не в промышленном применении?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+1 +/–
	Сообщение от Stax (ok) on 30-Мрт-18, 13:20
	> Интересно, есть ли у нее место не в промышленном применении? Оно вполне подходит для небольшой компании, которой нужно хранить например несколько ТБ данных с требованием отказоустойчивости (т.е. не хотим полагаться на RAID, хотим, чтобы при вылете сервера данные не потерялись и продолжало работать). Способно жить на совершенно консьюмерском железе (т.е что-нибудь типа Xeon E3, 32 гига и 4 диска - вполне себе ок для узлов хранения, если нет больших нагрузок). При не очень большом объеме данных и не слишком большом числе узлов отлично будет жить на гигабитной сети, упираясь в нее в какой-то степени только при восстановлении утерянного узла. Минимальный надежный продакшен-кластер я бы собирал минимум на 6 узлах конфигурации как выше (имхо, с фактором репликации 3 иметь меньше 6 узлов несколько странно), пару шлюзов кинуть на имеющиеся серверы, где собственно будут обрабатываться данные (им, кроме некоторого количества проца - пропорционального количеству запросов - ничего не требуется. Памяти гиг за глаза, хотя можно больше под кэш). Два управляюших узла запустить в виртуалках, контейнерах или прямо на хосте на имеющихся серверах инфраструктуры. Они не потребляют ресурсов, от них требуется только доступность - чтобы не выключались оба сразу, хоть один работал (если недоступны оба, нагрузку PUT/GET кластер продолжит держать, но нельзя будет перезапускать другие узлы и делать некоторые другие операции). На ЕЩЕ меньших масштабах лучше, вероятно, не думать о распределенных системах вообще. Для тестирования все узлы можно без проблем запускать на одной машине. Еще есть Project FiFo, где LeoFS работает в солярисовских (точнее, SmartOS) зонах.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	49. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 16:15
	Спасибо за подробный ответ!
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	79. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 31-Мрт-18, 15:02
	А не пробовал от reverbrain хранилище? И вроде как в блогах хорошо описывает, и тесты вменяемо показывает, но нигде не попадалось применение в продакшене.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

32. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	–1 +/–
Сообщение от Аноним (??) on 30-Мрт-18, 13:16
А какие минусы у Amazon AWS, и аналоги есть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
Сообщение от Аноним (??) on 30-Мрт-18, 16:22
Недоверяю я этим облакам. Хранить данные на компе чужого дяди (не важно - заморского или своего). Может лучше Nextcloud поднять?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+/–
	Сообщение от Аноним (??) on 30-Мрт-18, 16:23
	При том что если так хочется, можно арендовать заморский VPS, и там поднять свое облако.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	67. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4..."	+2 +/–
	Сообщение от Аноним (??) on 30-Мрт-18, 20:28
	> При том что если так хочется, можно арендовать заморский VPS, и там > поднять свое облако. Тебе сказали не хотят дяде отдавать свои данные, а ты говоришь хранить на компе дяди.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема