Единственный мастер упрощает архитектуру. MVP GFS сделали и внедрили меньше чем год. Затем уже добавили slave.

За счёт того, что master выполняет небольшой объем работы, это некритично.

В Collossus потеря мастера ячейки означает, что ячейки системы хранения может использоваться для записи до заполнения уже выделенных томов, далее она будет доступна в режиме readonly.

В SeaweedFS метаданные можно хранить в распределенной БД. Потеря master'а не даёт возможность создать новые тома.

https://habr.com/ru/company/ncloudtech/blog/551484/

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

Хабр пишет что скрыта

странно... сейчас проверил в инкогнито вкладке - открылась

И у меня сейчас тоже. Возможно пример eventual consistency)

Мастер упрощает, но ведь при этом есть leader less архитектура, которую тоже многие используют. у меня вот есть такая идея, что в DFS так делают потому, что нужно поддерживать команду листинга. например ls /путь. в AWS это listObjects, а если команда листинга не нужна, как например в KV, то там зачастую и архитектура сразу с консистентным хеширование для распределения ключей по хостам и таблица не нужна( или range партиционирование)

Есть задачи, где удобно иметь master - управление ресурсами в кластере, организация его обслуживания.

В  CockroacnDB используется range партицинирование, при этом у каждого range есть leader.

В cocroachdb есть место , где хранится информация о распределении партиции по хостам ? Должно быть. Им только места для этого меньше надо, если сравнивать и хранением привязки файлов к хостам . Что то типа : Range start, range end и связь с multi- raft группой . У них вроде партиции по размеру нарезают по 10gb? Тут возникает вопрос. Почему бы не сделать так же в ,dfs

В системных range'ах

Файлы можно привязывать к томам большого размера и томов будет гораздо меньше, чем файлов

В cockroachdb range порядка сотни мегабайт - такой размер можно достаточно быстро синхронизировать

Очень интересная статья  ! Спасибо.  А как в системах неограниченного объема происходит поиск хоста , на котором лежат данные ? Для этого нужно тогда в ключ зашивать временную метку или это как то иначе можно сделать ? Например , если у меня ключём является имя файла , то как система ищет хосты, на которых он находится ?

Спасибо за отклик) Да, очень правильный вопрос. Наверное, стоило об этом отдельно написать.

Единственный вариант, с которым я реально сталкивался на практике - это когда рядом с системой неограниченного объёма ставится система ограниченного объёма / медленнорастущая система. И в ней хранится метаинформация об адресе данных в системе неограниченного объёма (например, маппинг из имени файла в хост, на который он хранится).

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

Ещё мне интересно, как устроен лукап ключа в Minio в режиме федерации, но я не успел разобраться

а мне вот потнравился этот тред. Там автор SeaweedFS пишет:"Good to know this! The metadata layer with NewSQL storage seems exactly what SeaweedFS is already doing.

". размышля над архитектурой распределенной ФС, которая бы подходила для мелких файлов( в противоположность HDFS) я скорее пришел к похожему заключению.  https://news.ycombinator.com/item?id=13319678

Интересно, изучу

CockroachLabs организует серию вебинаров вокруг CAP теоремы.

Первый про availability - https://www.cockroachlabs.com/webinars/the-cockroach-hour-cap-theorem-series-availability

11

https://github.com/Orange-OpenSource/bmc-cache
Блин =) ну почему они не сделали тоже самое но на базе REDIS ? ;)

Хмммм, а в чем профит делать это в ядре?