LINUX.ORG.RU

История изменений

Исправление vertexua, (текущая версия) :

Гластер на 25 реплик не рассчитан

Я не эксперт по гластеру, но если паттерн работы с файлом «1 раз записал, 100000000 раз прочитал», то похоже это технически очень простой юзкейс. Пишешь сколько угодно медленно, ждешь сохранения заданого пользователем количества реплик чтобы признать запись успешной, остальное асинхронно реплицируется. При чтении достаточно прочитать блок со случайной (близкой, ненагруженой, что-то в этом духе) машины и отправить, лишь сверив контрольную сумму метаданных блока. Плюс там чуть повозиться с тем, что блок большой, а файлы - маленькие, но это решается и может быть упакование групп горячих файлов в блок с последующим кешированием например на SSD или в памяти. Если такое кеширование реализовать, то может и 25 реплик на изначальной распреледенной ФС не нужно.

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

Исправление vertexua, :

Гластер на 25 реплик не рассчитан

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

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

Исходная версия vertexua, :

Гластер на 25 реплик не рассчитан

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

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