Комментарии
Тесты всё равно надо было привести, но только в «дефолтной» конфигурации, дабы показать на что способны системы с «Рекомендуемыми разработчиком» настройками.

И… я пропустил, или в статье ничего про Гео-репликацию не сказано?
(Тоесть вопросы безопасности передачи данных, проблеммы, связанные с высоким пингом, малой скоростью и т.п.)
У меня цеф был сильно быстрее в дефолте. Никаких ручек не крутил. Но тут еще вопрос в том, что вероятно, что тест был не совсем честен, т.к. как соотнести количество PG и brick'и? Или вообще не стоит на это заморачиваться и пускай вообще все по дефолту будет?
Возможно, что были какие-то особенности с подключением glusterfs (там есть нюансы — nfs/fuse и т.п.)
И… я пропустил, или в статье ничего про Гео-репликацию не сказано?
(Тоесть вопросы безопасности передачи данных, проблеммы, связанные с высоким пингом, малой скоростью и т.п.)

Нет, вы не пропустили, тема гео-репликации и гео-распределенных кластеров не затронута в этой статье в силу отсутствия у нас подобного опыта и необходимости в подобных сетапах.
И… я пропустил, или в статье ничего про Гео-репликацию не сказано?
(Тоесть вопросы безопасности передачи данных, проблеммы, связанные с высоким пингом, малой скоростью и т.п.)

Если у вас есть подобный опыт, было бы интересно почитать о нем, хотя бы в двух словах.
Glusterfs требует постоянного слежения за ним. Оставленная без присмотра теряет файлы/делает split brain и даже не сообщает об этом, узнаешь только по факту отказа диска.
Короче, для систем где не нужно супер большие обьемы проще старый добрый rsync.
Не, ну когда файлы от 200 метров до двух гигов, то операции с метадатой сравнительно недорогие. Но когда постоянная запись кучи мелких файлов, то ни Гластер, ни Цеф не подходят. И вообще непонятно, какая кластерная ФС подходит в этом случае…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.