Комментарии 7
В чем преимущество по сравнению с бесплатной MooseFS?
у меня уже почти год в работе, 160ТБ, легкость подключения/удаления дисков/серверов, самовосстановление, возможность указания количества реплик вплоть до файла, приемлемая скорость для веба (для бекапов тем более)
у меня уже почти год в работе, 160ТБ, легкость подключения/удаления дисков/серверов, самовосстановление, возможность указания количества реплик вплоть до файла, приемлемая скорость для веба (для бекапов тем более)
Насколько стабильно? Требования прикладывания рук в рабочем режиме (при выпадании дисков, серверов, сети)? «Приемлимая скорость» в каких-нить абсолютных величинах меряется? Требовательность к сети?
Хочется распределенное хранилище из разных серверов (все под Ubuntu) сделать.
Хочется распределенное хранилище из разных серверов (все под Ubuntu) сделать.
Надежность и настоящее самовосстановление — были главными критериями при выборе. После пары лет еб… и с гластером.
Стабильность такая — ноды с данными, хоть режь, хоть коли, диски туда-сюда, всё пофигу, вообще. Сервер запросто можно положить на пару часов, ничего не будет. Всё восстановится/допишется после старта. Конечно если не ССЗБ, и не иметь реплики по одной копии. Я использую для некритичных данных двойную репликацию, для критичных тройную.
Расплата конечно есть за это — надо самому писать скрипт переключения мастер-ноды на один из слейвов.
Это в боевом применении с тремя контент-нодами и одним мастером (два слейва на паре контентных серверах держатся).
Советуют мастер с ECC памятью, остальные можно хоть тазики, ФС на дисках любая. Использую везде ext4, также тестировал с zfs, но скорость ну очень не впечатлила.
Посмотрел сейчас, 17.5 млн файлов, 41 млн чанков. Мастер съедает 8.6гига памяти.
На запись вот сейчас сделал тест, на запись 48МБ/с, чтение 35мб/с, но это в боевом окружении, отключить не могу ))))
Авторы говорят ворочают петабайтами на десятках-сотнях серверов. Пруф уже не найду.
Стабильность такая — ноды с данными, хоть режь, хоть коли, диски туда-сюда, всё пофигу, вообще. Сервер запросто можно положить на пару часов, ничего не будет. Всё восстановится/допишется после старта. Конечно если не ССЗБ, и не иметь реплики по одной копии. Я использую для некритичных данных двойную репликацию, для критичных тройную.
Расплата конечно есть за это — надо самому писать скрипт переключения мастер-ноды на один из слейвов.
Это в боевом применении с тремя контент-нодами и одним мастером (два слейва на паре контентных серверах держатся).
Советуют мастер с ECC памятью, остальные можно хоть тазики, ФС на дисках любая. Использую везде ext4, также тестировал с zfs, но скорость ну очень не впечатлила.
Посмотрел сейчас, 17.5 млн файлов, 41 млн чанков. Мастер съедает 8.6гига памяти.
На запись вот сейчас сделал тест, на запись 48МБ/с, чтение 35мб/с, но это в боевом окружении, отключить не могу ))))
Авторы говорят ворочают петабайтами на десятках-сотнях серверов. Пруф уже не найду.
Изначально система проектировалась так, чтобы показывать максимальную стабильность на наихудшем железе и сети и не требовать оперативного вмешательства руками, поскольку все наши датацентры расположены на значительном удалении (даже в других часовых поясах) от команды разработки и поддержки стораджа. Выпадающие диски и сервера заменяют местные специалисты даатцентра в обычном режиме по нашим заявкам.
После открытия третьего датацентра мы заметили, что наиболее стабильно ведет себя самый первый датацентр, в котором количество серверов перевалило за несколько десятков. Даже на совсем старых, маломощных серверах, где на один сервер для экономии навешивали несколько ролей, сеть была 1GB система работала стабильнее, чем на новой конфигурации с 9 выделенными и мощными серверами под каждую роль и сетью 2GB. По мере увеличения числа серверов новйы датацентр также быстро стабилизировался.
В первом датацентре многие сервера были разными как по числу дисков, так и по их емкости. Система нормально работает в такой конфигурации благодаря алгоритму балансировки стораджа.
Приемлемая скорость определяется бизнес-задачами у нас есть результаты сравнения произмодительности с типовым брендовым стораджем. Если интересно — пишите в сайп olegmikhalskiy
После открытия третьего датацентра мы заметили, что наиболее стабильно ведет себя самый первый датацентр, в котором количество серверов перевалило за несколько десятков. Даже на совсем старых, маломощных серверах, где на один сервер для экономии навешивали несколько ролей, сеть была 1GB система работала стабильнее, чем на новой конфигурации с 9 выделенными и мощными серверами под каждую роль и сетью 2GB. По мере увеличения числа серверов новйы датацентр также быстро стабилизировался.
В первом датацентре многие сервера были разными как по числу дисков, так и по их емкости. Система нормально работает в такой конфигурации благодаря алгоритму балансировки стораджа.
Приемлемая скорость определяется бизнес-задачами у нас есть результаты сравнения произмодительности с типовым брендовым стораджем. Если интересно — пишите в сайп olegmikhalskiy
MooseFS хранит копии данных, в то время как в статье идет речь о технологиях на основе кодов избыточночти, что гарантирует более эффективное потребление пространства и меньшую себестоимость хранения. Доступ к MooseFS осуществляется через FUSE, что с одной стороны дает простую интеграцию, а с другой — наследует узкие места FUSE. Один момент, который меня насторожил в архитектуре MuuseFS — это единственный сервер метаданных в сочетании с бэкап-серверами. Показалось узким местом в плане надежности и бесперебойной работы.
И ни слова про чексуминг в zfs, про свифт и ceph. Только махровый уродливый старый энтерпрайз. Понятно, что они будут долго мучаться, а потом подохнут в безвестности, а про новых лидеров — ни слова.
Наши инженеры экспериментировали с CEPH и Swift, в том числе меряли производительность, сравнивали удобство установки и управления. Детали можно попросить у них в индивидуальном порядке. В статью эти материалы не попали, потому что сначала хотелось сделать вводный материал, а на технические детали делать акцент в следующих публикациях. Мне кажется, что Swift и CEPH не совсем конкуренты enterprise решениям, потому что требуют значительно больших усилий по системной интеграции. Скорее, это альтернатива для наиболее крупных сервис провайдеров, у кого есть значительныве инженерные ресурсы и достаточная финансовая мотивация, чтобы вложить свои усилия в do-it-yourself проект на open source. Для небольших провайдеров и среднего бизнеса определенно нужны решения out of the box.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как обеспечить надежное хранение больших объемов данных в рамках умеренного бюджета