История изменений
Исправление mrPresedent, (текущая версия) :
glusterfs - весьма простое решение при указанных вводных, монтируется как любое другое блочное устройство, но, как говорится, есть нюанс.
Вам нужно определиться с архитектурой (distributed, replicated, dispersed, etc) и учесть пропускную способность. Возможно, этот подход для Вашей задачи неприменим. Если ноды географически разнесены, затея контрпродуктивна даже если 80% операций - чтение (скорость лежит до момента fdatasync всех реплик). Архитектурно присутствуют жесткие требования по идентичному объему bricks. При использовании механизмов гео-репликации скорость работы гео-распределенного хранилища стабилизируется (два независимых SAN регулярно синхронизируются с помощью rsync), т.е в единый момент времени нет консистентности, один пул видит файл, второй - еще нет.
Все то же самое актуально для Ceph, не считая отсутствия требований к объему osd.
По части общих временных данных, я решал похожую задачу с помощью двух пулов gluster, один геораспределенный для статических данных, второй - внутренний, хранящий базу stdb. Могут возникнуть нюансы с блокировками, не знаю, насколько это актуально для вашего приложения.
Если нет требований к высокой доступности и отказоустойчивости, а требуется лишь построить масштабируемое хранилище, возможно, Вам будет достаточно nfs или zfs (тут я вообще некомпетентен).
Исправление mrPresedent, :
glusterfs - весьма простое решение при указанных вводных, монтируется как любое другое блочное устройство, но, как говорится, есть нюанс.
Вам нужно определиться с архитектурой (distributed, replicated, dispersed, etc) и учесть пропускную способность. Возможно, этот подход для Вашей задачи неприменим. Если ноды географически разнесены, затея контрпродуктивна даже если 80% операций - чтение (скорость лежит до момента fdatasync всех реплик). Архитектурно присутствуют жесткие требования по идентичному объему bricks. При использовании механизмов гео-репликации скорость работы гео-распределенного хранилища стабилизируется (два независимых SAN регулярно синхронизируются с помощью rsync), т.е в единый момент времени нет консистентности, один пул видит файл, второй - еще нет.
Все то же самое актуально для Ceph, не считая отсутствия требований к объему osd.
По части общих временных данных, я решал похожую задачу с помощью двух пулов gluster, один геораспределенный для статических данных, второй - внутренний, хранящий базу stdb. Могут возникнуть нюансы с блокировками, не знаю, насколько это актуально для вашего приложения.
Если нет требований к высокой доступности и отказоустойчивости, а требуется лишь построить масштабируемое хранилище, возможно, Вам будет достаточно zfs (тут я вообще некомпетентен).
Исправление mrPresedent, :
glusterfs - весьма простое решение при указанных вводных, монтируется как любое другое блочное устройство, но, как говорится, есть нюанс.
Вам нужно определиться с архитектурой (distributed, replicated, dispersed, etc) и учесть пропускную способность. Возможно, этот подход для Вашей задачи неприменим. Если ноды географически разнесены, затея контрпродуктивна даже если 80% операций - чтение (скорость лежит до момента fdatasync всех реплик). Архитектурно присутствуют жесткие требования по идентичному объему bricks. При использовании механизмов гео-репликации скорость работы гео-распределенного хранилища стабилизируется (два независимых SAN регулярно синхронизируются с помощью rsync).
Все то же самое актуально для Ceph, не считая отсутствия требований к объему osd.
По части общих временных данных, я решал похожую задачу с помощью двух пулов gluster, один геораспределенный для статических данных, второй - внутренний, хранящий базу stdb. Могут возникнуть нюансы с блокировками, не знаю, насколько это актуально для вашего приложения.
Если нет требований к высокой доступности и отказоустойчивости, а требуется лишь построить масштабируемое хранилище, возможно, Вам будет достаточно zfs (тут я вообще некомпетентен).
Исходная версия mrPresedent, :
glusterfs - весьма простое решение при указанных вводных, монтирует как любое другое блочное устройство, но, как говорится, есть нюанс.
Вам нужно определиться с архитектурой (distributed, replicated, dispersed, etc) и учесть пропускную способность. Возможно, этот подход для Вашей задачи неприменим. Если ноды географически разнесены, затея контрпродуктивна даже если 80% операций - чтение (скорость лежит до момента fdatasync всех реплик). Архитектурно присутствуют жесткие требования по идентичному объему bricks. При использовании механизмов гео-репликации скорость работы гео-распределенного хранилища стабилизируется (два независимых SAN регулярно синхронизируются с помощью rsync).
Все то же самое актуально для Ceph, не считая отсутствия требований к объему osd.
Если нет требований к высокой доступности и отказоустойчивости, а требуется лишь построить масштабируемое хранилище, возможно, Вам будет достаточно zfs (тут я некомпетентен).