The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0

29.03.2018 23:21

Подготовлен новый выпуск распределённого отказоустойчивого хранилища объектов LeoFS, совместимого с клиентами, использующими API Amazon S3 и REST-API, а также поддерживающего режим работы в роли NFS-сервера. Имеются оптимизации для хранение как мелких, так и очень больших объектов, присутствует встроенный механизм кэширования, возможна репликация хранилищ между дата-центрами. Среди целей проекта отмечается достижение надёжности 99.9999999% за счёт избыточного реплицирования дубликатов и исключения единой точки отказа. Код проекта написан на языке Erlang и распространяется под лицензией Apache 2.0.

LeoFS состоит из трёх компонентов:

  • LeoFS Storage - обслуживает операции добавления, извлечения и удаления объектов и метаданных, отвечает за выполнение репликации, восстановления и формирования очереди запросов клиентов.
  • LeoFS Gateway - обслуживает HTTP-запросы и перенаправляет ответы клиентам с использованием REST-API или S3-API, обеспечивает кэширование наиболее востребованных данных в памяти и на диске.
  • LeoFS Manager - отслеживает работу узлов LeoFS Gateway и LeoFS Storage, ведёт мониторинг состояния узлов и проверяет контрольные суммы. Гарантирует целостность данных и высокую доступность хранилища.

Основные новшества LeoFS 1.4.0:

  • Поддержка сборки с использованием Erlang/OTP 20;
  • Поддержка типа сервисов "notify" для systemd;
  • Возможность мониторинга состояния узлов хранения (leo_storage) при помощи SNMP;
  • Оправка администратору сводки сообщений об ошибках при запуске;
  • Переработана система уведомлений о медленной обработке данных, чтобы избежать узких мест;
  • В управляющий интерфейс (leofs-adm) добавлена операция recover-disk для увеличения производительности восстановления в случае выхода дисков из строя.


  1. Главная ссылка к новости (https://github.com/leo-project...)
  2. OpenNews: Релиз LeoFS 1.2.0
  3. OpenNews: Выпуск распределённого отказоустойчивого хранилища LeoFS 1.1.2
  4. OpenNews: Значительное обновление файловой системы Bcachefs
  5. OpenNews: Выпуск распределенной файловой системы GlusterFS 3.7
  6. OpenNews: Представлена LittleFS, компактная файловая система для встраиваемых устройств
Лицензия: CC-BY
Тип: Программы
Ключевые слова: leofs, replication
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Anonim (??), 23:35, 29/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    https://habrahabr.ru/company/oleg-bunin/blog/313364/

    Поначалу мы паниковали, пробовали расставлять по коду leofs метрики, пробовали понять, что происходит, коллега Чистяков не спал ночами. Мы пытались выяснить, не хочет ли кто-нибудь из питерских Erlang’истов потрогать это палочкой. Питерские Erlang’исты оказались разумными людьми, они не стали трогать это палочкой.

     
     
  • 2.4, Аноним (-), 01:27, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +12 +/
    > Этот доклад — расшифровка одного из лучших выступлений на профессиональной конференции по эксплуатации и devops

    Как испоганилось айти, если это -- лучший  доклад. Это бред сумасшедшего, а не доклад. "Все дерьмо, я мы дартаньяны, несмотря на то, что много лет доим заказчика и за его счёт играемся с тем, о чём понятия не имеем". Тьфу. Басни про хетцнер это про танцора, у которого сплошные проблемы в жизни.

     
  • 2.7, Stax (ok), 04:05, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Даже комментировать противно. Где багрепорт в списке рассылки или официальном гитхабе https://github.com/leo-project/leofs/issues ? Что вообще делать пытались, кроме как "трогать палочкой"? Если не было желания писать багрепорт или как-то разбираться в проблеме - почему не попытались тупо на месяц арендовать N самых простых серверов в том же датацентре, создать там второй кластер, перенести туда данные, грохнуть имеющийся и пересоздать с нужным количеством узлов, скопировать данные назад и отдать железку?

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

    PS эксплуатирую LeoFS в продакшене и *крайне* доволен простотой, надежностью и производительностью. Хотя по результатам тестирования и внедрения пришлось написать несколько багрепортов, чтобы лучше автоматически разруливались некоторые нестандартные ситуации. Все критичное разработчики поправили достаточно оперативно. С ними очень легко общаться, хоть большинство и японцы.

     
     
  • 3.15, RudW0lf (?), 09:44, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сразу видно что комментаторы выше доклад не смотрели. Цитата вырвана из контекста. Минутой ранее в докладе говорилось, что ребята пошли в саппорт этого самого проэкта, где их просто послали, а поскольку они его держали в проде они испытали неюллюзорный батхерт. После этого попытались обратиться к знакомым с языком специалистам и те вежливо отказали.
    Вообще насколько я понимаю исходный посыл первого комментария - опенсорц проэкт без комьюнити - это уг,и ставить его себе на прод то еще приключение. Есть люди которые используют это в проде на хотябы 100+ узлов?
     
     
  • 4.17, Аноним (-), 10:53, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кластер поехал. Эти спецы начали отключать-подключать ноды в надежде, что "само пройдёт". Я б их ещё дальше послал
     
  • 4.19, Stax (ok), 12:15, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Читал - и как уже написал, комментировать противно Ну-ка а давайте теперь прове... текст свёрнут, показать
     
     
  • 5.20, XoRe (ok), 12:28, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они позвонили по телефону в техподдержку компании Rakuten, которая пишет этот le... текст свёрнут, показать
     
     
  • 6.22, Аноним (-), 12:35, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не понимаю, как у них вообще хватило наглости звонить (!) в техподдержку компании, не имея контракта, по которому им должны были предоставить эту поддержку. Может их там ещё в седалище должны были облобызать? Как только начал используешь чужой софт за здорово живём — ты сам себе техподдержка.
     
     
  • 7.84, XoRe (ok), 09:43, 02/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не понимаю, как у них вообще хватило наглости звонить (!) в техподдержку
    > компании, не имея контракта, по которому им должны были предоставить эту
    > поддержку. Может их там ещё в седалище должны были облобызать? Как
    > только начал используешь чужой софт за здорово живём — ты сам
    > себе техподдержка.

    А почему вы решили, что у них не было контракта?

     
  • 6.24, Stax (ok), 12:45, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я видел эту цитату. Еще раз. Багрепорт в трекере где???

    Не говоря уж про то, что Rakuten - огромный холдинг.
    Конкретно финансированием разработки LeoFS занимается Технологический Институт Rakuten (RIT). Поддержкой напрямую они не занимаются! За поддержкой нужно обращаться к разработчикам. Которые, в принципе, конечно, работают в RIT, но это все-таки разные понятия.

     
  • 6.46, 1 (??), 15:31, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >почитала наши баг-репорты в их трекере
     
  • 4.55, Аноним (-), 16:31, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    С опенсорсным проектом вам никто ничего не должен даже при наличии комьюнити, а шанс, что из этого комьюнити кто-то шарит менее 1%, и естественно они заняты полезным делом и на форуме не сидят.
     
  • 3.34, Николай Гаврилов (?), 13:20, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это опенсорс, дружище. Хочешь чтоб дело сдвинулось с места - выдели ресурсы. Деньги дай, или сам помоги, своими руками. Когда мне надо продвинуть и решить какой-то баг, то я сам занимаюсь этим. Почему другие горазды только на форумах ныть?
     
     
  • 4.36, Аноним (-), 13:24, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Эксплуататор продакшонов блин. Хоть раз донат кинул, или только эксплуатирует и клянчит?
     
  • 2.14, asand3r (?), 09:10, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Слушал я доклад этого дядьки вместе с еще каким-то толстяком на Highload'e. Вещали они про MySQL и PostreSQL. Даже досмотреть сил не хватило - невозможно такое г* слушать.
     
     
  • 3.50, Аноним (-), 16:17, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Они некомпетентны? Позорят отрасль?
     
  • 2.18, Аноним (-), 11:10, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Anonim пишется через "y"

    Это пост рекламы своей неинтересной статьи или ненужной компании?

    Спасибо.

     
  • 2.26, Аноним (-), 13:00, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > мастер-нода теперь не знает, где у нее какие файлы лежат.

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

     
     
  • 3.39, Stax (ok), 13:34, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я вам секрет открою - в LeoFS ВСЕ узлы знают, где какие файлы лежат Без каких... текст свёрнут, показать
     
  • 2.29, Не олег (?), 13:07, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Этот ваш олег, мягко говоря, не самый авторитетный источник...
     

  • 1.5, Roskompozor atakuet (?), 02:30, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +24 +/
    Скоро Amazon заблочат на территории РФ с помощью blackhole, что вызовет сбои в работе миллионов сервисов во всем мире. В следствии чего (как и обещал Жаров) "вражеский запад" отключит нас от интернетов. Готовимся...

    https://roskomsvoboda.org/37531/

     
     
  • 2.6, Аноним (6), 03:52, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, во всем мире, на территории определенного государства.
     
     
  • 3.38, ansel (?), 13:29, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Статью не читал да?

    https://en.wikipedia.org/wiki/Black_hole_(networking)

     
     
  • 4.63, YetAnotherOnanym (ok), 18:46, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Типа, отключить приём анонсов с глючного или находящегося под контролем злоумышленников роутера - это прямо такая проблема? Вот, в Пакистане админы накосячили, какое-то время дофига трафика на Ютюб  лилось к ним и там дропалось, провайдерам в других странах хватило пары часов чтобы спохватиться и почистить роуты.
     
  • 2.8, Вонни Бух и Потчк (?), 04:36, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все в чебурашконеты?
     
     
  • 3.21, Аноним (-), 12:34, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению нет. Амазоном пользуются обычно мобильные игры и приложения.
     
  • 3.37, Аноним (-), 13:26, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Скоро вероятно загонят. Все идет к логической развязке.
     
     
  • 4.40, Аноним (-), 13:58, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Скоро это минимум через 10 лет. Бюрократическая машина очень медленная.
     
     
  • 5.44, flex (??), 15:04, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Дурак ты, Вася. У нас РКН 8 млн. сайтов заблокировал без решения суда, попутно блокируя все что висит на одном IP, ты про какую-то машину сказки рассказываешь. Депутат единоросии чтоль? Или из криокамеры вышел?
     
     
  • 6.45, Аноним (-), 15:18, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –15 +/
    Сколько лет закон Яровой принимается и когда запустится? Почему не работает закон о мессенжерах и анонимайзерах? Пока эти две вещи не заработают, никого от интернета не отключат. Физлиц я бы уже давно отключил от мирового интернета на месте властей. Им он просто не нужен и никак не повлияет на российскую экономику.
     
     
  • 7.48, Евгений Канавалов (?), 16:09, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +24 +/
    Ну привет тебе, простой обыватель. Давай по порядку.

    > Сколько лет закон Яровой принимается и когда запустится?

    Меньше 2х лет назад приняЛИ и подписаЛИ. Летом 2016го. Запустится через 2 месяца - 1го июня 2018 года, как и планировалось во время принятия закона (внезапно). С небольшой поправкой. Пол года на звонки и СМС, месяц для всего остального. С наращиванием до задуманных 6 месяцев интернета к 2020му. Лично устанавливал и тестил оборудование для нашего провайдера в декабре. В декабре-январе, кстати, большинство провайдеров начали поднимать цены, многие впервые за все время своей деятельности, ну и мы не исключение.

    > Почему не работает закон о мессенжерах и анонимайзерах?

    Ну почему же не работает. Во-первых, работает, и весьма неплохо. Скайп, Ватсап, Вайбер - слышал про такие мессенджеры? И десятки других популярных, успешно прогнулись и сотрудничают с РКH/ФCБ, прослушивают трафик. На первых порах этого достаточно. Гулaг не сразу строился.

    Во-вторых, в некоторых случаях проще пyкнyть, чем сделать. Пока непонятно как будут блокировать P2P-мессенджеры. Пока VPN невозможно положить. Пока большинство провайдеров даже не имеет DPI-оборудования. А когда заимеет, там уже другие протоколы VPN/шифрования подтянутся. Уже есть вещи, способные лихо завернуть любой DPI, и успешно обходят блокировки даже в Китае. Гонка технологических вооружений пока в нашу пользу, с большим отрывом. Если что и может случиться, так это тот самый рубильник, который  отсечет нас от общего инета. Предпосылки и намеки со стороны известных государственных чинyш уже есть.

    > Пока эти две вещи не заработают, никого от интернета не отключат.

    Наивно.

    > Физлиц я бы уже давно отключил от мирового интернета на месте властей. Им он просто не нужен и никак не повлияет на российскую экономику.

    Блин, знал бы что тролль, даже не стал бы отвечать. :(

     
     
  • 8.56, Аноним (-), 16:41, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему тролль Я уехал, теперь можете смело отключать интернет Я только за ... текст свёрнут, показать
     
     
  • 9.73, YetAnotherOnanym (ok), 09:32, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Экспортный тролль, значит ... текст свёрнут, показать
     
  • 8.66, Аноним (-), 20:25, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Никакой DPI не нужен Можно если много трафика на один IP и это не ютуб, тогда б... текст свёрнут, показать
     
     
  • 9.68, Аноний (?), 21:33, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну толсто же ... текст свёрнут, показать
     
  • 8.85, Аноним (-), 15:43, 03/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот А то - ZOG, правительство, власти, рептилоиди угнетают простых граждан ... текст свёрнут, показать
     

  • 1.16, evkogan (?), 10:35, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пошел читать коменты в надежде узнать как оно относительно люстры.
    В результате увидел только ссылку на статью позора. Где нищеброод, сознается, что он еще и т.пой. Массово совать фалы в BLOB, делают только не выпустившиеся студенты и то не все. А сказать нас предупреждали, что так нельзя, но мы самые умные и потом мужественно решали самолично состряпанные проблемы, ну-ну...
    После этого говорить, что система плоха, на основании доклада этого автора уже смешно. Тем более что я ни разу не зная что и как в этой леофс понимаю, что просто отключить 2 новых УЖЕ добавленных сервера, это гарантированно получить проблемы плюс к уже имеющимся.

    А про сравнить с люстрой кто-то что-то сказать может?

     
     
  • 2.25, Stax (ok), 12:56, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > А про сравнить с люстрой кто-то что-то сказать может?

    Это не аналог люстры и не предназначено для больших кластеров. Это объектный сторейдж. Есть у вас до фига каких-то данных в виде множества мелких сущностей и ваши приложения с этим работают. Вы хотите их хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле - вот это то, что нужно. А если ваш софт уже умеет 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 - вот тут не могу сказать, но это очень новый продукт, что (лично для меня) сразу огромный минус. По фичам и планам там все весьма интересно. Если созреет, будет очень хорошей альтернативой.

     
     
  • 3.28, Moomintroll (ok), 13:07, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты

    Т.е. LeoFS не предлагает готовую тулзу? Даже несмотря на то, что "Формат там элементарный"?

     
     
  • 4.35, Stax (ok), 13:23, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты
    > Т.е. LeoFS не предлагает готовую тулзу? Даже несмотря на то, что "Формат
    > там элементарный"?

    :) Висит в багтрекере, но у них не хватает рук. Официальная утилита же должна быть нормальной, удобной и фичастой, а это уже не несколько часов. А задач важных много. Некоторые пользователи от них крупных фич хотят (server-side encryption, erasure coding, поддержку 3 и более датацентров одновременно и т.п.), с другой стороны баги известные есть, с третьей документация неидеальна (по использованию еще ничего, а вот техническая про нутрянку - как что хранится и работает, для лучшего понимания, какие действия делать в случае проблем - слабовата).

    Но если хочется убедиться, что "формат элементарный", вот совсем уж наколеночная тулза для листинга AVS-файла. После небольшой модификации может и сохранять объекты из него: https://github.com/mocchira/leofs_utils/blob/master/tools/listup_avs.rb

    Ну а вообще, изначально я имел ввиду "написать самому" имено с точки зрения, что оно достаточно просто, что можно обращаться даже по принципу "сделай все сам", если совсем припрет. Вообще без какого-либо кода от разработчиков.

     
  • 3.41, Andrey Mitrofanov (?), 14:20, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> А про сравнить с люстрой кто-то что-то сказать может?
    > Это не аналог люстры и не предназначено для больших кластеров. Это объектный
    > сторейдж. Есть у вас до фига каких-то данных в виде множества
    > мелких сущностей и ваши приложения с этим работают. Вы хотите их
    > хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле
    > - вот это то, что нужно. А если ваш софт уже
    > умеет S3 (многое из коробки умеет; если это что-то свое, то
    > дописать совсем несложно, благо реализации S3 есть почти для всего и
    > они достаточно удобные в использовании), то обойдетесь минимум изменений.

    PohmelFS с японцами, шашками и амазоном вместо яндекса?

     
  • 3.43, Alexander (ok), 15:03, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    opennet - торт! Спасибо, Stax! Имхо, ваши комментарии вполне на отдельную статью тянут.
     
     
  • 4.70, RomanCh (ok), 22:37, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > opennet - торт! Спасибо, Stax! Имхо, ваши комментарии вполне на отдельную статью
    > тянут.

    Аккуратнее доверяйте комментариям в интернетах. См. рядышком каммент #69 где я смею выражать сомнения в авторитетности автора относительно заключений конкретно по Ceph.

     
  • 3.47, evkogan (?), 15:58, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, отличное описание.
    Если оформите как статью будет здорово.
    Прежде чем написать вопрос погуглил, хотя искал сравнение с люстрой, ничего не нашлось, если бы вылезло сравнение с CEPH заметил бы.
    Просто чисто объектные хранилища мне не очень интересны, но общее понимание что есть что и куда смотреть лучше в случае чего пригодится.
     
  • 3.69, RomanCh (ok), 22:35, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мм, рассказ тут не про Ceph, но когда набрасываете, то извольте конкретно излага... текст свёрнут, показать
     
     
  • 4.74, Stax (ok), 11:03, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тоже не хотелось бы, но пару вещей прокомментирую Например, вот это https git... текст свёрнут, показать
     
     
  • 5.77, RomanCh (ok), 13:47, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что вот это Список юнитов systemd вас испугал, или наличие готовых вам вел... текст свёрнут, показать
     
     
  • 6.78, Stax (ok), 14:45, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы действительно не понимаете или только делаете вид Вопрос не в наличии, а в т... текст свёрнут, показать
     
     
  • 7.80, RomanCh (ok), 17:01, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Внутри всё работает так как обещали Или вы дома каждый утюг и монитор разобрали... текст свёрнут, показать
     
     
  • 8.81, Stax (ok), 18:58, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не разбираюсь - но в том-то и фишка, что оно со стороны в достаточной степени ... текст свёрнут, показать
     
  • 5.82, alexk (??), 16:42, 01/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Главная проблема ceph - это все же контрольные суммы данных. Bluestore появился совсем недавно, а до этого вам могли вернуть совсем не те данные что вы записали. Для хранилища данных очень больших объемов декларация о том что оно production ready без этой опции - это крайняя степень оптимизма.
     
  • 3.71, kvaps (ok), 22:43, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Это не аналог люстры и не предназначено для больших кластеров.

    Можно поподробнее, почему нет?
    Насколько возможна расширяемость LeoFS и во что можно упереться при использовании ее в больших кластерах?

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

    Как раз это больше всего и привлекает. В статье заявлена поддержка nfs - возможно ли и насколько резонно использование LeoFS в качестве классической POSIX-совместимой файловой системы?

    > у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС

    Как в этом случае поступает LeoFS?

    Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли?

    PS: Большое спасибо за ваши ответы :)

     
     
  • 4.72, RomanCh (ok), 23:02, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли?

    Не так. Ceph замечательно работает например на 3х нодах ProxMox, который хранит в нём диски виртуалок тем самым организуя отказоустойчивость и прозрачную миграцию виртуалки с ноды на ноду - никакие данные носить не нужно, всё уже есть. Другое дело что Ceph может работать на кластерах с заметным объёмом показывая в целом неплохой результат.

    За LeoFS ничего не скажу, потому что ничего не знаю, и в отличии от автора того камента со "сравнениями" не буду обсуждать то в чём совсем не разбираюсь.

     
  • 4.75, Stax (ok), 11:20, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Например, система репликации построена так, что другие серверы знают помнят , г... текст свёрнут, показать
     
     
  • 5.76, kvaps (ok), 11:28, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Благодарю, очень исчерпывающе!
     
  • 2.31, Gilneas (?), 13:13, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мда. Вот смотрю я на тебя и вижу человека, который не может похвастаться широкими познаниями в предмете. Но других почему-то называешь тупыми. Парадокс.
     
     
  • 3.51, evkogan (?), 16:21, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Мда. Вот смотрю я на тебя и вижу человека, который не может
    > похвастаться широкими познаниями в предмете. Но других почему-то называешь тупыми. Парадокс.

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

    Но при этом моих знаний вполне хватает, чтобы понять что уже с первых строк авторы той статьи делают явно неправильную архитектуру.
    У нас для внутреннего использования делали пару систем куда заливались файлики с хранением всей сопутствующей инфы в БД Оракл (ну вот стоит он работает и спецы есть, от еще одной базы ему хуже не будет). Так там нагрузки и объемы на порядки меньшие, но никто даже не подумал хранить файлы (они там все априори больше 1Мб) в БЛОБах, лежат себе в папочке, а в БД ссылки. И все работает без проблем.
    Более того автор той статьи не отрицает, что им говорили что будет плохо, но они сделали и получили проблемы.
    В ЛеоФС я не разбираюсь, я о ней узнал сегодня. Но я разбираюсь в стораджах и системах кластеризации разных. Ну если Вы уже добавили новые сервера и на них должна была пройти репликация, а в результате получились проблемы, то просто на горячую эти сервера дергать нельзя. Лучше станет врядли, а вот хуже может очень даже стать. И хуже таки стало. Причем в стаье так и не сказал, сумели ли они восстановить данные и как?
    В чем странность моей позиции, если я говорю что не доверяю суждениям данного автора? Вы придрались к одному слову, ну хотите я извинюсь и скажу, что так говорить не хорошо. Но при этом подход я остаюсь при мнении, что автор сам сознательно создает себе проблемы и потом с ними борется, что вся его статья, это одно сплошное доказательство, что надо делать в соответствии с бест-практис, а все его проблемы это доказательство, что бест-практис верны.
    А как назвать человека, который делает анти бест-практис в продакшене, это каждый может решить сам.

     
     
  • 4.60, Аноним (-), 17:25, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Главное что ты знаешь как лучше.
     

  • 1.23, Moomintroll (ok), 12:40, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А есть какое-нибудь сравнение с Ceph?

    Вот Ceph я знаю уже давно — крупный и зрелый проект, а про LeoFS узнал только сейчас...

    Есть ли у LeoFS какие-лио преимущества перед Ceph? Почему люди (например, вон те, с болью) выбирают LeoFS?

     
     
  • 2.27, Stax (ok), 13:05, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А есть какое-нибудь сравнение с Ceph?
    > Вот Ceph я знаю уже давно — крупный и зрелый проект, а
    > про LeoFS узнал только сейчас...
    > Есть ли у LeoFS какие-лио преимущества перед Ceph? Почему люди (например, вон
    > те, с болью) выбирают LeoFS?

    Подробно описал выше. Пробовал Ceph. В итоге (без боли!) выбрал LeoFS.

    Если совсем упрощенно: у вас достаточно много денег, вам нужен коммерческий контракт - берите Ceph.
    У вас не так много денег, вы хотите что-то, что устроено максимально просто, но при этом достаточно быстро, и даже если вы (вдруг) вообще все на хрен там разломаете, чтобы ваши данные были легко доступны - берите LeoFS. За счет простоты он надежнее, вполне приятно ставится и обслуживается (особенно последние версии).

    Также, если вам позарзез нужна расширенная функциональность Ceph - берете, разумеется, Ceph. Но не стоит забывать, что там могут быть свои проблемы по сравнению с использованием в режиме обычного Object Storage.
    Если вам нужна хорошая совместимость с S3 из коробки, которую разработчики ставят в приоритет - лучше взять LeoFS (но это немного субъективно). Если вам нужна multi-DC репликация - точно берете LeoFS. (но это вообще сложная тема и там могут быть свои проблемы в любом случае).

     

  • 1.30, Аноним (-), 13:09, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно, есть ли у нее место не в промышленном применении?
     
     
  • 2.33, Stax (ok), 13:20, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно, есть ли у нее место не в промышленном применении?

    Оно вполне подходит для небольшой компании, которой нужно хранить например несколько ТБ данных с требованием отказоустойчивости (т.е. не хотим полагаться на RAID, хотим, чтобы при вылете сервера данные не потерялись и продолжало работать). Способно жить на совершенно консьюмерском железе (т.е что-нибудь типа Xeon E3, 32 гига и 4 диска - вполне себе ок для узлов хранения, если нет больших нагрузок). При не очень большом объеме данных и не слишком большом числе узлов отлично будет жить на гигабитной сети, упираясь в нее в какой-то степени только при восстановлении утерянного узла.

    Минимальный надежный продакшен-кластер я бы собирал минимум на 6 узлах конфигурации как выше (имхо, с фактором репликации 3 иметь меньше 6 узлов несколько странно), пару шлюзов кинуть на имеющиеся серверы, где собственно будут обрабатываться данные (им, кроме некоторого количества проца - пропорционального количеству запросов - ничего не требуется. Памяти гиг за глаза, хотя можно больше под кэш). Два управляюших узла запустить в виртуалках, контейнерах или прямо на хосте на имеющихся серверах инфраструктуры. Они не потребляют ресурсов, от них требуется только доступность - чтобы не выключались оба сразу, хоть один работал (если недоступны оба, нагрузку PUT/GET кластер продолжит держать, но нельзя будет перезапускать другие узлы и делать некоторые другие операции).

    На ЕЩЕ меньших масштабах лучше, вероятно, не думать о распределенных системах вообще.

    Для тестирования все узлы можно без проблем запускать на одной машине. Еще есть Project FiFo, где LeoFS работает в солярисовских (точнее, SmartOS) зонах.

     
     
  • 3.49, Аноним (-), 16:15, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за подробный ответ!
     
  • 3.79, Аноним (-), 15:02, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А не пробовал от reverbrain хранилище? И вроде как в блогах хорошо описывает, и тесты вменяемо показывает, но нигде не попадалось применение в продакшене.
     

  • 1.32, Аноним (-), 13:16, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А какие минусы у Amazon AWS, и аналоги есть?
     
  • 1.52, Аноним (-), 16:22, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Недоверяю я этим облакам. Хранить данные на компе чужого дяди (не важно - заморского или своего). Может лучше Nextcloud поднять?
     
     
  • 2.53, Аноним (-), 16:23, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При том что если так хочется, можно арендовать заморский VPS, и там поднять свое облако.
     
     
  • 3.67, Аноним (-), 20:28, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > При том что если так хочется, можно арендовать заморский VPS, и там
    > поднять свое облако.

    Тебе сказали не хотят дяде отдавать свои данные, а ты говоришь хранить на компе дяди.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру