Size: a a a

SDS и Кластерные FS

2020 November 30

S

Slach in SDS и Кластерные FS
kvaps
может он индексы строил какие-нибудь?
нет
он пишет в system.metrics_log и в system.query_log (если есть какой нибудь clickhouse-exporter который по SQL метрики снимает из прометеус раз в 5 секунд)
источник

S

Slach in SDS и Кластерные FS
Dmitry Vylegzhanin
Все эти etcd любят синхронно + много писать на диск, может и КХ аффектит
нет это не аффектит
источник

k

kvaps in SDS и Кластерные FS
NO Name
Да не особо, там пишется около 1к аудиопотов 256кб/с в секунду
Сдаётся мне MooseFS / LizardFS тебе зайдёт, только на счёт отказоустойчивости не уверен. Там сервера метаданных отдельно, здесь лучше @good_developer подскажет
источник

k

kvaps in SDS и Кластерные FS
Переслано от Alex Tkachuk
Moosefs плохо работает с маленькими файлами. Ну, "плохо" - достаточно громкое заявление по многим причинам. Во первых, все ФС подобного типа "плохо" работают с маленькими файлами.
Во вторых, минимальный размер чанка - 64кб + 8кб чексумма и ещё какое то говно. Т.е. файл размером 4кб будет занимать 72кб.
В третьих, каждое обращение к файлу генерирует запрос к мастер серверу для получения метаинформации и списка чанксерверов которые содержат файл/чанк.

Мастер сервер сам по себе не параллелится, однако достаточно высокопроизводительный, что, тем не менее, делает плохою погоду когда много обращений к маленьким файлам (читай много метаопераций)
источник

S

Slach in SDS и Кластерные FS
в ClickHouse нет WAL (пока нет, в разработке эта лишняя для ch фича)
и fsync там не такой частый. только на конец записи data part (1 insert = 1 data part на одну затрагиваемую логическую партицию, новый датапарт на каждые 1м записей из 1го инсерт...)
источник

AT

Alex Tkachuk in SDS и Кластерные FS
Маленькие файлики понятие растяжимое :)
источник

AT

Alex Tkachuk in SDS и Кластерные FS
У меня например кейс был, что многие были <4 килобайт
источник

AT

Alex Tkachuk in SDS и Кластерные FS
Может у кого-то маленькие - это пара мегабайт :)
источник

k

kvaps in SDS и Кластерные FS
NO Name
Т.к. происходит удаление постоянно, то в районе 2.3ТB
Хотя возможно отказоустойчивый DRBD+NFS на таких объёмах было бы проще и разумнее
источник

AT

Alex Tkachuk in SDS и Кластерные FS
+ оно платное в HA варианте, но пока не вижу причин что бы 1к потоков по 256кб/с не переварить, это вроде не большая нагрузка
источник

NN

NO Name in SDS и Кластерные FS
Alex Tkachuk
У меня например кейс был, что многие были <4 килобайт
Не, у меня 2-3мб
источник

NN

NO Name in SDS и Кластерные FS
Тут вопрос, что у LizardFS с HA
источник

NN

NO Name in SDS и Кластерные FS
Вот, например: один мастер, два мета, 4 чанк сервера. Что будет если я перезагружу мастер?
источник

k

kvaps in SDS и Кластерные FS
kvaps
Хотя возможно отказоустойчивый DRBD+NFS на таких объёмах было бы проще и разумнее
Вариант с Proxmox + GaneshaNFS в LXC контейнере вполне рабочий если что

https://habr.com/ru/post/417473/
источник

NN

NO Name in SDS и Кластерные FS
Да я тоже думаю, про DRBD + NFS
источник

k

kvaps in SDS и Кластерные FS
NO Name
Да я тоже думаю, про DRBD + NFS
Только нужен именно user-space NFS-сервер, так стабильнее работать будет и в ядре не зависнет
источник

AT

Alex Tkachuk in SDS и Кластерные FS
NO Name
Вот, например: один мастер, два мета, 4 чанк сервера. Что будет если я перезагружу мастер?
У moosefs новые операции станут колом на несколько секунд, у lizardfs другая немного методика обеспечения ha и там затрудняюсь ответить, нужно курить/тестить
источник

k

kvaps in SDS и Кластерные FS
Alex Tkachuk
У moosefs новые операции станут колом на несколько секунд, у lizardfs другая немного методика обеспечения ha и там затрудняюсь ответить, нужно курить/тестить
У лизардфс DRBD в качестве ha, разве нет?
источник

AT

Alex Tkachuk in SDS и Кластерные FS
uRaft
источник

NN

NO Name in SDS и Кластерные FS
Да там рафт везде
источник