| |
| 2.4, Аноним (-), 11:25, 28/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Звучит как "какой компьютер из TOP500 лучше всего подходит для сидения вконтактике?"
| | |
| 2.5, sabakka (?), 12:09, 28/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Для хранения мелких файлов подходит?
канешн, в all-flash конфигурации ;)
| | |
|
| 1.6, Аноним (-), 12:18, 28/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Я почему спросил, например cephfs ещё сырая и для хранения мелких файлов не подходит, как и файлов вообще.
| | |
| |
| 2.7, feem (?), 12:31, 28/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
ceph то как раз из всех открытых кластерных систем одна из самых стабильных и более менее все хорошо с производительностью(хотя люстра конечно побыстрее будет). Очень много коммерческих решений сейчас на ней делают компании.
| | |
| |
| 3.8, Аноним (-), 12:46, 28/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
suse коммерческие решения на btrfs продаёт, но почему-то пользоваться тем бртфсом дураков мало находится
| | |
| |
| 4.23, Аноним (-), 09:53, 30/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> мало находится
Благодаря фэйсбуку btrfsом пользуется вся планета.
| | |
|
| 3.9, Аноним (-), 13:37, 28/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
я не про ceph, а cephfs - задача хранить множество мелких ts файлов для hls.
| | |
|
| 2.10, Stax (ok), 14:20, 28/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Пользуясь случаем, тоже спрошу у местных экспертов. Похожая задача, мелкие/средние файлы (от нуля байт до 20 мб, полный разброс); сотни миллионов, в день возникают десятки/сотни тысяч новых, все нужно считывать (+ регулярно считывать старые). Доступ на запись через REST API, на чтение крайне желательно через NFS, но на крайняк REST API покатит (особенности кэширования - файл обычно считывается несколько раз в течении короткого времени, кэширование NFS в ОС работает лучше, чем webdav+squid для кэширования). Файлы (в случае успешной запси) более никогда не модифицируются.
Ну, типичные требования - чтобы непрерывно держало нагрузку без простоев, несколько реплик от потери данных, эффективная off-site репликация/бэкап (чтобы быстро понимало, какие изменения переслать, а-ля zfs send). Чудес производительности не требуется, типичная нагрузка сейчас 20-30 Мб/с (но практически постоянно). Требования корректности (ответить "на живых репликах объекта нет" в крайнем случае можно, вернуть объект с битыми данными нельзя).
Пробовали cephfs (с раздачей по nfs), не понравилось, в первую очередь восстановление при проблемах с нодами/сетью. Много различных неприятных эффектов, пришлось отказаться. Желательно что-то такое, что даже при временном отделении нод друг от друга с последующим соединением не побьет данные и не потребует трудоемкого восстановления с простоем.
| | |
| |
| |
| 4.16, Stax (ok), 16:09, 28/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
Гмм а он будет легче в плане восстановления?
Сейчас уточнил, у нас был не cephfs, а ceph block device + xfs на нем + nfs на чтение (там, где писали была возможность подключить этот block device, а вот там, где читают - возможности нет).
Еще желательно сжатие. Файлы сжимаются хорошо (zfs сейчас показывает коэффициент 2.44). ceph требует исключительно btrfs в качестве фс под ним для сжатия, так? Но btrfs это свои глюки - пробовали с ним, очень быстро пришлось поменять на xfs.
| | |
|
| 3.20, Лютый жабист (?), 06:20, 29/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
А зачем для этой задачи ФС? Просто складывать в NOSQL (Cassandra самая лютая, но можно и MongoDB).
| | |
| |
| 4.22, Stax (ok), 15:10, 29/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Эти слова бесконечно далеки от конечного решения. Во-первых, с Cassandra связываться не будем - под такую нагрузку внедрять подобный NoSQL можно только вместе с людьми, которые будут его поддерживать. Mongo тут вообще не в тему - она не соответствует исходным требованиям, если их внимательно прочесть.
Есть Hadoop и Hbase, но в голом виде их использовать также нельзя. Во-первых хранить много мелких объектов раздельно как "файлы" на Hadoop нельзя, он для этого не предназначен. Нужно их объединять группами в архивы и прочее, там свои заморочки. Т.к. файлы должны размазываться равномерно, архивы нужно постоянно менять, могут выплыть заморочки. Мы плотно работаем с HBase и хорошо представляем, сколько неприятностей кроется, если идти по этому пути :) Решаемых, но время, время...
В HBase класть так просто тоже не выйдет. Слишком неравномерный размер объектов, слишком большой разброс. См. https://www.quora.com/Is-HBase-appropriate-for-indexed-blob-storage-in-HDFS и еще https://issues.apache.org/jira/browse/HBASE-11339
Hadoop/Hbase это такие штуки, которые могут начать себя КРАЙНЕ плохо вести, если с ними делать неправильные вещи. Поэтому делать что попало не стоит.
Вообще какая-то прослойка над Hadoop - это вероятное решение, но пока неясно, какая именно и что проще внедрить.
Решения с POSIX layer, при всем оверхеде, которые они несут, привлекательны тем, что строго разделяют проблемы самого хранения от проблем его использования. Т.к. с последним уже все отлажено, все проблемы, которые могут возникнуть - проблемы самого хранилища.
| | |
| |
| 5.26, Аноним (-), 12:47, 01/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> с Cassandra связываться не будем
т.е., scylladb тоже не катит?
| | |
|
|
| |
| 4.25, Stax (ok), 22:26, 30/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
Любопытно :)
Выглядит вкусно, eventual consistency, конечно, штука опасная, но в этом конкретном случае проблем не представляет.
Спасибо, посмотрим.
| | |
| |
| 5.27, Аноним (-), 12:48, 01/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Ещё glusterfs есть, но когда я его щупал (очень давно), это был лютый глючный пц, м.б. после перехода к rh его допилили до чего-то пристойного.
| | |
|
|
|
|
| 1.12, Аноним (-), 15:17, 28/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хоть бы картинку новую вставили. А то так и позорятся с рисунком времен 1.4
| | |
| 1.21, Аноним (-), 12:00, 29/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Из других улучшений можно отметить поддержку SELinux в клиенте Lustre
Такое улучшение что клиент может поймать deadlock, причем Intel это не волнует.
> улучшение производительности
Тесты показывают падение производительности по сравнению с 2.5
> и эффективности выполнения четвёртой фазы проверки целостности ФС в утилите LFSCK,
Уже перестала ловить deadlock на OSS ?
> поддержку работы серверов и клиентов на системах с Red Hat Enterprise Linux 7.x,
Зашибись - но 7.x был с времен 2.6.
> возможность выполнения клиентом операций множественного изменения метаданных из многопоточных приложений.
Спорное улучшение - хорошо работает когда у тебя MDT не догружен, плохо когда работает когда клиентов много. Требует очень много памяти на recovery. Если раньше можно было в 12G уложиться - теперь на сервера меньше 64G ставить смысла нету.
Хвала Интел!
| | |
|
