The OpenNET Project / Index page

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

Обновление кластерной файловой системы LizardFS 3.13.0-rc2

10.11.2019 12:07

После годичного затишья в разработке возобновилась работа над новой веткой отказоустойчивой распределённой файловой системы LizardFS 3.13 и опубликован второй кандидат в релизы. Недавно произошла смена владельцев компании, развивающей LizardFS, было принято новое руководство, и сменились разработчики. Последние два года проект отстранился от сообщества и не уделял ему должного внимания, но новая команда намерена возродить прежние отношения с сообществом и наладить с ним тесное взаимодействие. Код проекта написан на языках С и С++ и распространяется под лицензией GPLv3.

LizardFS является распределённой кластерной файловой системой, позволяющей рассредоточить данные по разным серверам, но представить к ним доступ в форме единого большого раздела, работа с которым осуществляется по аналогии с традиционными дисковыми разделами. В монтируемом разделе с LizardFS поддерживаются POSIX-атрибуты файлов, ACL, блокировки, сокеты, каналы, файлы устройств, символические и жёсткие ссылки. Система не имеет единой точки отказа, все компоненты резервируются. Поддерживается распараллеливание операций с данными (несколько клиентов могут одновременно обращаться к файлам).

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

Данные и метаданные хранятся раздельно. Для работы рекомендуется устанавливать два сервера метаданных, работающих в режиме master-slave, и а также как минимум два сервера хранения данных (chunkserver). Дополнительно для резервирования метаданных могут применяться лог-серверы, хранящие информацию об изменении метаданных и позволяющие восстановить работу в случае повреждения всех имеющихся серверов метаданных. Каждый файл разбивается на блоки (chunk), размером до 64 МБ. Блоки распределяются по серверам хранения в соответствии с выбранным режимом репликации: стандартный (явное определение числа копий для размещения на разных узлах, в том числе в привязке к отдельным каталогам - для важных данных число копий можно увеличить, а для несущественных уменьшить), XOR (RAID5) и EC (RAID6).

Хранилище может масштабироваться до петабайтных размеров. Из областей применения упоминаются ведение архивов, хранение образов виртуальных машин, мультимедийных данных, резервных копий, использование как DRC (Disaster Recovery Center) и как хранилище в кластерах высокопроизводительных вычислений. LizardFS обеспечивает очень высокую скорость чтения файлов любого размера и при записи показывает хорошую производительность при записи целиком больших и средних файлов, когда нет постоянной модификации, интенсивной работы с открытыми файлами и разовых операций с кучей мелких файлов.

Среди особенностей ФС также можно отметить наличие поддержки снапшотов, отражающих состояние файлов в определённое время, и встроенную реализацию "корзины" (файлы не удаляются сразу и какое-то время доступны для восстановления). Доступ к разделу может быть ограничен по IP-адресу или паролю (по аналогии с NFS). Имеются механизмы квот и управления качеством сервиса, позволяющие ограничить размер и пропускную способность для некоторых категорий пользователей. Возможно создание территориально распределённых хранилищ, сегменты которых размещены в разных датацентрах.

Проект LizardFS был основан в 2013 году как форк MooseFS, и отличается, главным образом, наличием режима репликации на базе кодов коррекции ошибок Рида—Соломона (аналог raidzN), расширенной поддержкой ACL, наличием клиента для платформы Windows, дополнительными оптимизациями (например, при совмещении клиента и сервера хранения блоки по возможности отдаются с текущего узла, а метаданные кэшируются в памяти), более гибкой системой настройки, поддержкой упреждающего чтения данных, квотами на каталоги и внутренними переработками.

Релиз LizardFS 3.13.0 планируется выпустить в конце декабря. Основным новшеством LizardFS 3.13 является задействование для обеспечения отказоустойчивости (переключения master-серверов в случае сбоя) алгоритма достижения консенсуса Raft (используется собственная реализация uRaft, которая ранее применялась в коммерческих продуктах). Использование uRaft упрощает настройку и сокращает задержки при восстановлении после сбоя, но требует наличие как минимум трёх работающих узлов, один из которых используется для кворума.

Из других изменений: новый клиент на базе подсистемы FUSE3, решение проблем с корректировкой ошибок, плагин nfs-ganesha переписан на языке Си. В обновлении 3.13.0-rc2 исправлено несколько критических ошибок, делавших предыдущие тестовые выпуски ветки 3.13 малопригодными для использования (исправления для ветки 3.12 пока не опубликованы, а обновление с 3.12 на 3.13 по-прежнему приводит к полной потере данных).

В 2020 году работа будет сосредоточена на разработке Agama, нового полностью переписанного ядра LizardFS, которое, по заверению разработчиков, обеспечит увеличение производительности в три раза, по сравнению с веткой 3.12. В Agama будет осуществлён переход на событийно-ориентированную архитектуру (event driven), асинхронный ввод/вывод на базе asio, работу преимущественно в пространстве пользователя (для снижения зависимости от механизмов кэширования ядра). Дополнительно будут предложены новая отладочная подсистема и анализатор сетевой активности с поддержкой автотюнинга производительности.

В клиент LizardFS будет добавлена полная поддержка версионирования операций записи, которая повысит надёжность восстановления после сбоя, решит проблемы, возникающие при совместном доступе разных клиентов к одним данным, и позволит добиться значительного увеличения производительности. Клиент будет переведён на собственную сетевую подсистему, работающую в пространстве пользователя. Первый рабочий прототип LizardFS на базе Agama планируется подготовить во втором квартале 2020 года. В это же время обещают реализовать средства для интеграции LizardFS с платформой Kubernetes.

  1. Главная ссылка к новости (https://lizardfs.com/introduct...)
  2. OpenNews: Выпуск распределенной файловой системы GlusterFS 3.7
  3. OpenNews: Компания Versity открыла исходные тексты файловой системы ScoutFS
  4. OpenNews: В состав ядра Linux 4.6 принят код файловой системы OrangeFS
  5. OpenNews: Представлен полностью переработанный вариант распределённой файловой системы POHMELFS
  6. OpenNews: Новая версия распределённой файловой системы XtreemFS 1.5
Лицензия: CC-BY
Тип: Программы
Ключевые слова: lizardfs, cluster
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Иван (??), 12:04, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ух ты, дажен не знал о существовании данной ФС, спасибо за информацию, буду разбираться.
     
     
  • 2.15, пох. (?), 14:51, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    если до сих пор счастье этого знания тебя миновало - не торопись разбираться. Поскольку разбираться тебе придется не в технических деталях, а в административно-политических.

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

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

    Рекомендую посмотреть на gluster - возможно тебе повезет, и на твои задачи его хватит в том виде, в котором он сейчас есть. Концепция там похожая, а недоделки в предсказуемых местах, и не полностью фатальны для данных.
    lizard нужна если у тебя 1. большие файлы 2. нетбабланах (нужны EC, а не репликация) 3. клиенты не [только] под линухом. 4. ты не можешь подождать лет пять, пока гластер все это доделает или его не разгонят к чертям

     
     
  • 3.18, Иван (??), 15:05, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Спасибо за развернутый ответ.
     
     
  • 4.45, Аноним (45), 14:08, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сначала работал на гластере, глюкавое еще то было (свыше 10 лет назад), потом перешел на MooseFS, через пару лет на LizardFS. Кластер был наверное один из крупнейших на этой системе, на сотни терабайт и десятки миллионов чанков. проработал с ним несколько лет. Рабочая штука, не без изъянов, но не критичных. Незаслуженно обделенная вниманием.
     
     
  • 5.50, пох. (?), 14:58, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    традиционный вопрос - расскажите подробностей - версии, настройки redundancy goals, сколько жрал метасервер и как с этим справлялись, ну и где грабли, если они описуемы словами.

    > Незаслуженно обделенная вниманием.

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

    При том что рядом лежала работающая (если забыть о ec или купить кота в мешке) moose, и почти работающий gluster...

     
  • 2.16, пох. (?), 14:56, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а, блин, вдогонку: lightweight снапшоты и trashcan.
    У gluster первого технически не сделать нормально, а второе сделано в виде trash. В смысле, выкрасить и выбросить только.

     
     
  • 3.27, Онаним (?), 19:00, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > а, блин, вдогонку: lightweight снапшоты и trashcan.
    > У gluster первого технически не сделать нормально, а второе сделано в виде
    > trash. В смысле, выкрасить и выбросить только.

    У гластера в trashcan превращается всё хранилище после первого же серьёзного сбоя репликации.

     
     
  • 4.29, пох. (?), 20:49, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    расскажите, как вы это делаете.

    Учитывая что "сбой репликации" у него вообще в клиенте (и тоже интересно - КАК?), а в хранилище банально лежат файлы на банальной xfs или вообще ext4 - поштучно, потому что все "хранилище" - пачка EA привязанных к этим файлам, и их всегда можно руками вытащить. КАК?!

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

     
     
  • 5.33, Онаним (?), 22:28, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > расскажите, как вы это делаете.

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

     
     
  • 6.34, Онаним (?), 22:31, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С Ceph кстати тоже не пошло, упёрлись в latency на геораспределённой хранилке. Сейчас под этим добром лежит OCFS2 в итоге.
     
     
  • 7.35, Онаним (?), 22:32, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Shared LUN - не совсем то, что хотелось, хотелось распределённо данные выкорябывать, чтобы bandwidth был потенциально бесконечный, но на практике хрен он этот bandwidth занимает, упирается в latency между узлами и клиентами.
     
  • 7.36, Michael Shigorin (ok), 22:44, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > упёрлись в latency на геораспределённой хранилке

    Поищите запись/тезисы доклада Евгения Полякова на первом LinuxPiter, очень толково, насколько вообще могу судить.  Но они в итоге уже к Reverbrain/Elliptics пришли к объектным хранилкам, опять же насколько помню.

    PS: в смысле именно из-за латентности длинных соединений.

     
  • 6.37, пох. (?), 23:13, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я туда пытался рабочий набор статистики загрести, несколько сот тысяч файлов

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

    Я, честно говоря, удивился бы, если бы такое работало.

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

    Так что расскажите подробностей, что и как вы ТАК ухитрились в нем поломать, что было сконфигурено, что в результате показывал gluster volume status и heal - может кому пригодиться чтоб ТАК не делать.

     
     
  • 7.47, Онаним (?), 14:16, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да обычная реплика + шарды. Хорошо хоть страйп не сделал, из страйпа вообще упал бы потом выковыривать.
     
     
  • 8.51, пох. (?), 15:01, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в смысле, distributed-replicated, то есть эн реплик по 2 N не 2, надеюсь Уби... текст свёрнут, показать
     

  • 1.3, Онаним (?), 12:29, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Как там с POSIX-совместимостью и гарантированностью блокировок?
     
     
  • 2.4, Онаним (?), 12:37, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почитал. С блокировками всё относительно нормально, а вот с когерентностью кеша между узлами похоже никак.
     
     
  • 3.5, Онаним (?), 12:39, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Производительность, как обычно, упрётся в мастер-сервер, он один.

    В общем, "ещё одна" распределённая файловая система, не предназначенная для параллельной работы над единым набором данных. Для шардинга сойдёт, но смысл, если уже есть цеф с люстрой.

     
     
  • 4.7, Аноним (7), 13:36, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Емнип сервеов с метаданными там может быть несколько
     
     
  • 5.10, пох. (?), 14:27, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    это бэкап, он не может использоваться пока жив master. И не может, а должно, если твои данные не writeonly, потому что при превращении мастера в тыкву в нее автоматически превращается весь кластер, эти данные больше вообще взять неоткуда.

    Но узким местом при разумных нагрузках мастер не является. Точнее, он лопается раньше, чем становится узким местом - обратите внимание, что ВСЕ метаданные должны помещаться в память единственного узла, никаких других вариантов просто не предусмотрено (костыль с bdb не жизнеспособен, это уже комитеры в CoC придумали).

     
  • 5.11, Онаним (?), 14:27, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Емнип сервеов с метаданными там может быть несколько

    Да. standby. Активный один.

     
  • 4.8, пох. (?), 14:23, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ох уж эти хперты опеннет.

    производительность не упрется ни в какой мастер-сервер, потому что его, сюрприз, нету.
    metadata node не является никаким "master-server", и не посредничает в операциях.

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

    Текущую версию можно и нужно использовать как warm/cold storage для огромных файлопомоек, на которые бессмысленно тратить ресурсы san, и которые при этом нельзя ни сбэкапить, из-за размера, ни потерять.

    Соответственно, сравнивать ее можно с gluster или BeeGFS, но у тех своих тараканов полным-полно.

     
     
  • 5.9, Онаним (?), 14:27, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    metadata node внезапно используется при каждом обращении к каждому файлу. То есть если на это дело шардить и читать многогигабайтные блобы - всё будет ок. А вот если разложить там 100500 файлов - счастью будет плохеть.

    > Текущую версию можно и нужно использовать как warm/cold storage для огромных файлопомоек, на которые бессмысленно тратить ресурсы san, и которые при этом нельзя ни сбэкапить, из-за размера, ни потерять.

    Цеф, люстра. Короче лизард - около ненужно.

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

     
     
  • 6.13, пох. (?), 14:43, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > metadata node внезапно используется при каждом обращении к каждому файлу.

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

    > Цеф, люстра. Короче лизард - около ненужно.

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

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

    С гластером главная беда - что его зохавал редгад. То есть шанса на повторение истории с покупкой кем-то вменяемым и раздачей животворящих пинков девелоперам нет и не будет. Теперь у нас есть версия 3, которая как-то работает, если ни на шаг не отступать от генеральной линии редгада (в частности забыть о ec и не хранить там большие файлы), и не забыть оформить подписку, и есть версии "хочу быть как хром", в которых вообще ничего не работает, потому что макаки принципиально не умеют ничего доделывать до рабочего состояния - "зато мы написали новую версию на игогого, а то этот ваш си немодно и мы его плохо понимаем, только вы ей тоже не пользуйтесь, она немного не работает". Четыре, или сколько там уже - версии подряд "уже почти совсем полностью окончательно немного не готово".

     
     
  • 7.20, Онаним (?), 16:22, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Четыре, или сколько там уже - версии подряд "уже почти совсем полностью окончательно немного не готово".

    Yes.

     
  • 7.21, Онаним (?), 16:23, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и передает исключительно метаданные. ЧТО такое надо построить, чтобы упереться в них

    Да ничего особенного, достаточно просто ls -l на каталог с 10000-100000 файлов...

     
     
  • 8.23, Онаним (?), 16:26, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Когда метаданные шардятся - оно хотя бы слегка распараллелится NFS тоже не понр... текст свёрнут, показать
     
  • 8.25, пох. (?), 16:44, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    доктор, я когда чешу левой пяткой правое ухо через левое плечо - у меня где-то в... текст свёрнут, показать
     
     
  • 9.26, Онаним (?), 18:58, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Эксты нормально OCFS2 тяжело, но справляется NFS 4 1 тоже справляется, но ещё ... текст свёрнут, показать
     
  • 9.42, Аноним (42), 10:53, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    может и не создаться 10млн - зависит от длины имени Да и скорость create look... текст свёрнут, показать
     
     
  • 10.44, PnDx (ok), 13:02, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ext4-only Берите под такое xfs если внизу не deb Под RH OLE-образное у меня ... текст свёрнут, показать
     
     
  • 11.52, Аноним (42), 16:33, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у xfs cвои сюрпризы - достаточно посмотреть груды патчей которые вливает шапка в... текст свёрнут, показать
     
     
  • 12.54, пох. (?), 23:12, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну на вас не угодишь - два года нет патчей - аааа, проект мертв, убегаем, убега... текст свёрнут, показать
     
  • 7.22, macfaq (?), 16:24, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть какой-то сравнительный обзор Ceph, Gluster и Moose/Lizard?
     
     
  • 8.24, Онаним (?), 16:27, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот глустеръ вообще сбоку, а с Ceph интересно бы было ... текст свёрнут, показать
     
  • 8.61, SysA (?), 12:43, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Лови https sysadmin libhunt com compare-ceph-vs-moosefs ... текст свёрнут, показать
     
  • 7.31, Аноним (31), 22:01, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и не забыть оформить подписку

    э... А ты само то надеешься на их подписку? И чем поможет тебе очередной Мьяньманьян Суббараян при накрытии гластера медным тазом? Да, основные их рекомендации - это удаление вольюмов и создание новых. От под-писки редгада гемора только больше станет. Весь рэд-гад сторож сейчас в Бангалоре пячат.

     
     
  • 8.38, пох. (?), 23:25, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну можешь сам все чинить, под бодрые вопли бегающих вокруг начальников начальник... текст свёрнут, показать
     
     
  • 9.41, Аноним (31), 08:09, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Согласен, поддержка красной ненависти - хороший громоотвод, возможно Хотя нет... текст свёрнут, показать
     
     
  • 10.43, пох. (?), 10:54, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну у меня прошлый раз ушло полтора месяца с параллельным сованием костылей и по... текст свёрнут, показать
     
  • 6.40, Аноним (42), 07:25, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    daos ?
     
  • 2.53, Аноним (53), 20:18, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    POSIX-совместимость в кластерной ФС - гарантия хреновой производительности
     
     
  • 3.59, Онаним (?), 09:26, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Увы да. А несовместимость = пригодность разве что для файлопомойки, или надо городить кучу костылей.
     

  • 1.6, vitalif (ok), 13:00, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Из того, что написано в интернетах - никак не могу понять: случайная мелкая перезапись там поддерживается вообще? Или на каждую модификацию сливает 64 мб? // А сам всё никак не попробую
     
     
  • 2.17, пох. (?), 14:59, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    без ec - да. Были прецеденты использования этой штуки для раздачи томов под kvm.

    C ec, по очевидным причинам, хрень выйдет.

     
     
  • 3.28, Онаним (?), 19:02, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > без ec - да. Были прецеденты использования этой штуки для раздачи томов под kvm.

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

     
     
  • 4.30, пох. (?), 20:55, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тома под KVM можно и с гластеров раздавать, и с цефа. Тормозно только,

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

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

    > Пока что лучше нормальной выделенной хранилки iSCSI multipath

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

     
     
  • 5.32, Онаним (?), 22:24, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > вообще-то - штатное решение проксмоксы. При наличии вообще говоря отсутствия в нем
    > других, как бы намекает, что для большинства применений вполне разумно.

    С проксмоксом гластер можно. Птицы одного помёта. А вот с адекватными системами виртуализации лучше всё-таки не использовать.

    :)

    > сама хранилка из воздуха берется? Иначе возвращаемся к вопросу - из чего ее строить.

    Из LVM, если кустарно, из собственного блочного решения, если профессионально, в случае неумения - покупать правильный iSCSI SAN (не путать с кустарными NAS, где под iSCSI может быть обычное кустарное решение на файлухе типа ZFS) у тех, кто умеет в SAN.

     
     
  • 6.39, пох. (?), 23:45, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Из LVM, если кустарно

    и вот совсем не ссыкотно?

    > в случае неумения - покупать правильный iSCSI SAN

    правильный san - он FC/FCoE, а не iSCSI (есть возможность сравнить, если что). Но он, с-ка, денег стоит - два состава. А внутри, что характерно, очень похожее на ZFS. Прям вот ну оооочень похожее.

    А потом в один прекрасный день у тебя переклинивает sfp. Модную, где наклейка поверх залеплена другой, с лого производителя хранилки. И которая стоит как пять нормальных.
    И ВЕСЬ, вообще весь сторадж - ложится к хренам, со всем своим multipath и многоразовым резервированием. А потом еще пару раз в разгар рабочего дня - когда ты кумарам собираешь данные для RMA, потому что без данных они не могут, и в нерабочее время тоже не могут.

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

     
     
  • 7.46, Онаним (?), 14:13, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    FC/FCoE - ну хз. С моей т.з. де факто полутруп, так-то, вытесняется iSCSI.
    Другое дело, что iSCSI надо уметь готовить, обычные копеечные свитчи под него лучше не совать, с другим трафиком не комбинировать, и т.п.
    Ну и там тоже SFP есть :)

    У нас в этом плане решение №3, "покупать". Переклинит SFP - да похер. Два разведённых в стороны канала по несколько 10G SFP каждый, от каждой хранилки. Даже если целиком ляжет один сектор, а не просто SFP - ничего страшного не случится. _Синхронная_ репликация между дц (формально геораспределение, но регион один, поэтому latency не фатальные). multipath к набору сторейджей в разных DC, формально получается "георепликация", но latency не настолько унылы, чтобы запороть всё. Короче, максимум возможного в пределах бюджета.

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

    Никто также не гарантирует, что не придётся пинать саппорт, но за саппорт и определённый SLA платятся деньги.

    В общем, как всегда, выбор из выборов. Но по крайней мере full flash решение, с быстрыми тонкими снэпшотами, синхронной репликацией, двукратным дублированием (аналогом RAID6), распределённой тонким слоем по дискам запаской, арбитражом, multipath и ALUA, дублированием железа и связности, авто-фейловером и т.п. На коленке такое задолбаешься собирать, чтобы оно ещё и надёжно работало.

     
     
  • 8.56, Аноним (42), 08:11, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вообще уже давно есть NVMe over fabric а iSCSI даже over IB это прошлый век... текст свёрнут, показать
     
     
  • 9.57, Онаним (?), 09:24, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну давай, построй мне распределённую между ДЦ хранилку на NVMe ... текст свёрнут, показать
     
  • 7.48, PnDx (ok), 14:19, 11/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > и вот совсем не ссыкотно?

    Зря Вы так. Если не выёживаться с thin-provisioning и прочими RAID, он внутри простой как палка.
    + См. sanlockd: возрождает ну оочень старую идею. На мой вкус, достаточно перспективно.

    * FC местами тоже "маловато будет". На перспективу — таки IB.

     
     
  • 8.55, Аноним (42), 08:09, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    IB FDR стоит сейчас как грязь 500 баксов свич 200 карта Так что FC можно хор... текст свёрнут, показать
     
     
  • 9.58, Онаним (?), 09:25, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот кстати да, если есть недоверие к эзеру, проще иб взять ... текст свёрнут, показать
     
     
  • 10.60, пох. (?), 10:25, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не, не проще - то что стоит как грязь, оно и работает как грязь И драйверы у не... текст свёрнут, показать
     

  • 1.14, abi (?), 14:50, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Распределённое блочное хранилище от ноунеймов? Это будет предсказуемо.
     
     
  • 2.19, разработчик SCO из 1993го года (?), 15:46, 10/11/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Распределённое блочное хранилище от ноунеймов? Это будет предсказуемо.

    unix-like система от какого-то финского студиозуса? Это будет предсказуемо!

    P.S. а всего через пять лет меня уволили "при помощи ноги" :-( С тех пор я работаю в макдаке.

     

  • 1.62, Michael Shigorin (ok), 19:46, 29/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Туда же: омичи из bitblaze собирались открывать kfs, насколько знаю; вот что голова конторы говорит в сравнении с ceph: https://www.youtube.com/watch?v=MEZ-THg6gzo&t=49m37s
     

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



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

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