ребаланс будет сжирать сеть и нагруать диски что худшит качество сервиса для килиента

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

чиста теоретически нельзя залимитирвать типа 500мбит на ноду, надо поделить на кол-во осд на ноде, и получается лимит одной осд

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

Клиент потом должен хранить у себя эту пару (volume_id, blob_id) и по ней всегда может достать блоб.

А как с3 объекты мапятся?

поверх вот этого голого боб стора есть отдельный сервис, который мапит  S3 URL в seaweed блобы. детально не смотрел, но по мне так это и не сильно нужно - как разница что хранить в базе приложения - s3 url или (volume_id, blob_id)

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

конечно есть что поправить, скажем горутина на каждую блоб-реплику, если нужен большой rps то это не очень (https://github.com/chrislusf/seaweedfs/blob/707192f966843db1c41420bdf7fa6d316d4431b3/weed/topology/store_replicate.go#L149-L152) , но дело поправимое

для s3 нужна отдельно база данных чтобы мету хранить

а что с ребалансом. объект что, навсегда закрепляется за одной нодой?

нода когда принимает объект сама разливает его на другие ноды. репилкация настраивается на уровне  volume, это если кратко 32 GB файл на ноде

если разлить на требуемое количество нод не удалось, аплоад объекта фейлится

а когда ноду убиваем

что тогда

объект остается на остальных нодах, список нод где должен быть объект клиент у мастера может получить и к ним постучаться по очереди

перемещая чуток логики на клиента сильно упрощается весь дизайн

Ну а оставшуюся-то реплику кто переналивает

Да на самом деле так... не очень сильно упрощается. В цефе том же считай тоже - из хеша объекта получается PG (считай PG==волюм)

PG мапится на ноду