Если говорить конкретно про radosgw, то тут правильнее говорить о RPS, то есть сколько запросов в секунду способна эта система прожевать.
Я брал лог-файл с фронтенда за месяц, загружал его в jmeter и получал цифры до 20000 запросов в секунду на чтение на реальные объекты.
Это синтетический тест, зависит от настроек apache2, сетевого стека, количества памяти и камней для компонентов.
Тут все кэшами подперто, все очень быстро.
На запись все очень сильно печально, открывается коннект к фронтенду и делается upload пост-запросом для каждого объекта со всеми вытекающими.
Вот хорошая статья про бенчи. Наблюдаем у себя подобные цифры.
Другой вопрос, что тут на разных этапах много разного I\O и надо разобраться сначала, что именно интересует. Также все надо настраивать конкретно под задачу.
Ну, то есть так и есть — основная проблема в том, что если памяти у name-node не хватит, то при избытке собственно места, мы ничего с ним сделать не сможем. Если мы говорим про петабайты и BIgData, то ceph умеет, а для hadoopfs — надо заморочиться )))
Другой вопрос, что cephfs еще сыровата, мягко говоря. Как бы не пришлось заморочиться еще больше )))))
Проще, сильно проще. Ну а вот сейчас поправьте меня, могу ошибаться.
Метаданные хадуп хранит на name-node, она одна, и все лежит в памяти. То есть количество файлов на файловой системе жестко ограничено размером памяти одной ноды с метаданными? Это — точка отказа и потенциальный bottleneck.
ceph скалируется по-всякому. Можно любое блочное устройство подцепить любого размера, все будет работать. Также у ceph есть и другие способы использования, помимо cephfs
— блочное устройство rbd. Эта штука давно в продакшн и везде впиливается. KVM умеет его как underlying, из софта — openstack, opennebula, proxmox, тот же hadoop.
— radosgw — почти полная совместимость с amazonS3 и swift.
То есть, имея свой кластер ceph, можно использовать его по-разному. И ничего ничему мешать не будет.
Чего выжать-то? Это скорость для клиента? Да лааадно. Файлуха столько не жмет никакая распределенная.
С полками другие проблемы — это гибкость и масштабируемость. Ну вот кончилось у вас место, дальше что? Или вам по пику два дня в месяц надо пережить на 100 гб больше, чем у вас есть?
Файлуха распределенная как-будто не глючит? ocfs2 да жесть же. gfs2? такая же. Весь кластер в коллтрейс — да легко ))
А если полка свалится? С проприетарным контроллером )) С вашей инфой что будет, пока эта полка по сервисам ездит 4 месяца?
Надо понимать, что если уже есть полка, то надо ее использовать по-максимуму, тут цеф не подойдет. Он для тех, кто не хочет больше полок.
ceph решает это другими методами. Есть куча osd, на них лежат размазанные кусочки объектов в репликации ^2 (или как настроить).
osd вылетел — цеф автоматом сам восстановит данные от соседа. Если восстановить не сможет, значит у вас ошибка в архитектуре. Причем объекты размазываются псевдорандомно, не так, что
osd.0 это копия osd.1, а osd.2 — > osd.3. Файл, как видит его клиент, может быть размазан одновременно по 4 дискам. а может и по двум. Или по трем. Причем ceph все время мониторит доступность и скорость дисков и чуть-чего начнет рекавери сам.
Вероятность потери данных есть, для этого и придуманы уровни репликации. А если учесть, что osd — это простой блокдевайс с обычной файлухой, то какова вероятность того, что у вас что-то случится одновременно с двумя или тремя дисками с обычной файлухой так, что нельзя восстановить?
Если система сложная, то надо сначала продумать и настроить расположение сервисов, CRUSH-карту распределения объектов, веса хранилищ и уровни репликации для пулов.
На один сервер все ставить они вроде как не рекомендуют, или хотя бы в kvm. Журнал надо однозначно на ssd.
Плюс что-то надо сделать с mds, тоже на быстрый диск и много cpu, самое слабое звено. XFS заменить на btrfs.
С такими допущениями у нас проблем нет вроде со скоростью, все сопоставимо, есть проблемы с количеством файлов в этой штуке.
А какой релиз, кстати, для них вполне нормально даже в минорном релизе что-нибудь громадное пофиксить и допилить.
Почему relatime? noatime?
Разработчиков Linux $1200000 Новосибирск на Джинне пока не ищут.
Я бы тоже не искал,
Во-первых, я в рублях указывал, во-вторых в Новосибирске (ну и пунктуация кое-где еще глаз печалит)
В-третьих, верстка вообще уплыла и выглядит как в реферате по информатике за 11 класс.
mount -t ceph node01:6789:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret,noatime
Почему монтирование с одним монитором? Надо все указывать.
mon1,mon2,mon3:/ /mnt/cephfs
Иначе, если откажет монитор, клиент повешается, иногда вместе с ядром.
— не рекомендуется маунтить туда, где крутится сам osd
— mds в данном конкретном случае очень важная штука, ей надо подкрутить ресурсов, она при большом количестве файлов жрет их очень много.
— журнал лучше убрать подальше от всего хозяйства, он прямо и четко влияет на производительность.
— btrfs лучше, чем xfs, ext4 тоже можно, но она самая медленная )
— много чего еще из нюансов.
cephfs еще сырой и имеет много нюансов, не отраженных (либо неявно отраженных) в документации. Если эти нюансы не учитывать, то будет все стоять колом.
Вкратце — из ceph мы используем активно:
radosgw: key-object хранилище аля amazonS3. Тут вопросов и нареканий нет, работает как часы. Здесь лежит контент, забирают его по http ссылкам, складывать можно тоже по http, либо напрямую тулзами для amazonS3. Очень классная штука. Мы вообще забыли, что с фоточками и прочим маленьким, но многочисленным контентом могут быть проблемы. Объектов тысяч 500, скажем.
rdb: это простой blockdevice, его можно использовать, как хранилище образов виртуальных машин, например. Надо понимать, что это, фактически, просто блочное устройство, если надо что-то разделяемое поверх, то еще надо и файлуху специальную. Тут тоже вроде все хорошо, если без фанатизма.
cephfs сейчас уже норм, но на самом деле нет )) В роадмапах говорят, что этому скоро уделят внимание, но пока, к сожалению в продакшн ее рано. Медленно и сыро. Может залипнуть, может ядро подвесить, может клиента и все намертво. Там проблемы с метаданными большие. Ну это опять же, если с фанатизмом подходить, на мелких объемах вроде все классно ))
Фанатизм, о котором я упомянул ))) Вот прямо сейчас у меня есть 150 миллионов файлов и я не совсем знаю, что дальше с ними делать )) Традиционная файлуха только работает. Остальное — не вывозит.
Глустер, конечно, цефу проигрывает по бенчам и легкости настройки и администрирования, а функционала сильно меньше.
Ну, практически дешевле выйдет все равно держать спеца линуксоида ))
Виндовозников больше, они более узкоспециализированы. Спец по БД вряд ли сядет и с наскоку осилит ексчейндж во всей его красе, например.
А линуксоид и почту, и бдшку, и файлопомойку может. Обучить его гораздо проще, без всяких курсов и собраний томов документации.
Конечно, переделывать рабочую экосистему никто не будет, но что-то новое делать, я бы уже подумал несколько раз. С другой стороны, линуксоид может единосекундно взять и крепко накосячить, мануалов толстенных не особо много.
Слаще морковки есть еще много еды. Бывает более лучше, дешевле и производительней. Я не про домохозяек и не про CS.
Я к тому, что базу данных, например, на тормозящем проприетарном ядре будет запустить более хуже, чем на открытом и оптимизированном.
Поддержу, Postgresql и Postgis — сильно проще. Поиск ближайших из коробки, кстати, не так давно релизнули.
В России этими проблемами занимается Олег Бартунов, вот его презентация на эту тему.
zfs работает мягко говоря ниочень ))) Gluster тоже, в связке будет наверное бомба, только в плохом смысле этого слова _)
Есть вопросы про multipart upload и про то, где nginx этот временный файл положит )))
Я брал лог-файл с фронтенда за месяц, загружал его в jmeter и получал цифры до 20000 запросов в секунду на чтение на реальные объекты.
Это синтетический тест, зависит от настроек apache2, сетевого стека, количества памяти и камней для компонентов.
Тут все кэшами подперто, все очень быстро.
На запись все очень сильно печально, открывается коннект к фронтенду и делается upload пост-запросом для каждого объекта со всеми вытекающими.
Другой вопрос, что тут на разных этапах много разного I\O и надо разобраться сначала, что именно интересует. Также все надо настраивать конкретно под задачу.
Или это шина прокачивет? Тогда при чем тут GPFS?
Менее чем неделю — это круто. Будем менее, чем неделю стоять без данных ога.
Другой вопрос, что cephfs еще сыровата, мягко говоря. Как бы не пришлось заморочиться еще больше )))))
Метаданные хадуп хранит на name-node, она одна, и все лежит в памяти. То есть количество файлов на файловой системе жестко ограничено размером памяти одной ноды с метаданными? Это — точка отказа и потенциальный bottleneck.
ceph скалируется по-всякому. Можно любое блочное устройство подцепить любого размера, все будет работать. Также у ceph есть и другие способы использования, помимо cephfs
— блочное устройство rbd. Эта штука давно в продакшн и везде впиливается. KVM умеет его как underlying, из софта — openstack, opennebula, proxmox, тот же hadoop.
— radosgw — почти полная совместимость с amazonS3 и swift.
То есть, имея свой кластер ceph, можно использовать его по-разному. И ничего ничему мешать не будет.
С полками другие проблемы — это гибкость и масштабируемость. Ну вот кончилось у вас место, дальше что? Или вам по пику два дня в месяц надо пережить на 100 гб больше, чем у вас есть?
Файлуха распределенная как-будто не глючит? ocfs2 да жесть же. gfs2? такая же. Весь кластер в коллтрейс — да легко ))
А если полка свалится? С проприетарным контроллером )) С вашей инфой что будет, пока эта полка по сервисам ездит 4 месяца?
ceph решает это другими методами. Есть куча osd, на них лежат размазанные кусочки объектов в репликации ^2 (или как настроить).
osd вылетел — цеф автоматом сам восстановит данные от соседа. Если восстановить не сможет, значит у вас ошибка в архитектуре. Причем объекты размазываются псевдорандомно, не так, что
osd.0 это копия osd.1, а osd.2 — > osd.3. Файл, как видит его клиент, может быть размазан одновременно по 4 дискам. а может и по двум. Или по трем. Причем ceph все время мониторит доступность и скорость дисков и чуть-чего начнет рекавери сам.
Вероятность потери данных есть, для этого и придуманы уровни репликации. А если учесть, что osd — это простой блокдевайс с обычной файлухой, то какова вероятность того, что у вас что-то случится одновременно с двумя или тремя дисками с обычной файлухой так, что нельзя восстановить?
Если система сложная, то надо сначала продумать и настроить расположение сервисов, CRUSH-карту распределения объектов, веса хранилищ и уровни репликации для пулов.
Плюс что-то надо сделать с mds, тоже на быстрый диск и много cpu, самое слабое звено. XFS заменить на btrfs.
С такими допущениями у нас проблем нет вроде со скоростью, все сопоставимо, есть проблемы с количеством файлов в этой штуке.
А какой релиз, кстати, для них вполне нормально даже в минорном релизе что-нибудь громадное пофиксить и допилить.
Почему relatime? noatime?
Я бы тоже не искал,
Во-первых, я в рублях указывал, во-вторых в Новосибирске (ну и пунктуация кое-где еще глаз печалит)
В-третьих, верстка вообще уплыла и выглядит как в реферате по информатике за 11 класс.
Вот здесь правильные цифры, мы их наблюдаем в продакшне. Ну не год, но полгода будет, да.
Вот rbd как раз позволяет гонять туда сюда образы, kvm например, с даунтаймами меньше секунды под нагрузкой.
Почему монтирование с одним монитором? Надо все указывать.
mon1,mon2,mon3:/ /mnt/cephfs
Иначе, если откажет монитор, клиент повешается, иногда вместе с ядром.
— не рекомендуется маунтить туда, где крутится сам osd
— mds в данном конкретном случае очень важная штука, ей надо подкрутить ресурсов, она при большом количестве файлов жрет их очень много.
— журнал лучше убрать подальше от всего хозяйства, он прямо и четко влияет на производительность.
— btrfs лучше, чем xfs, ext4 тоже можно, но она самая медленная )
— много чего еще из нюансов.
cephfs еще сырой и имеет много нюансов, не отраженных (либо неявно отраженных) в документации. Если эти нюансы не учитывать, то будет все стоять колом.
Мы для себя выбрали radosgw, полет отличный.
Вкратце — из ceph мы используем активно:
radosgw: key-object хранилище аля amazonS3. Тут вопросов и нареканий нет, работает как часы. Здесь лежит контент, забирают его по http ссылкам, складывать можно тоже по http, либо напрямую тулзами для amazonS3. Очень классная штука. Мы вообще забыли, что с фоточками и прочим маленьким, но многочисленным контентом могут быть проблемы. Объектов тысяч 500, скажем.
rdb: это простой blockdevice, его можно использовать, как хранилище образов виртуальных машин, например. Надо понимать, что это, фактически, просто блочное устройство, если надо что-то разделяемое поверх, то еще надо и файлуху специальную. Тут тоже вроде все хорошо, если без фанатизма.
cephfs сейчас уже норм, но на самом деле нет )) В роадмапах говорят, что этому скоро уделят внимание, но пока, к сожалению в продакшн ее рано. Медленно и сыро. Может залипнуть, может ядро подвесить, может клиента и все намертво. Там проблемы с метаданными большие. Ну это опять же, если с фанатизмом подходить, на мелких объемах вроде все классно ))
Фанатизм, о котором я упомянул ))) Вот прямо сейчас у меня есть 150 миллионов файлов и я не совсем знаю, что дальше с ними делать )) Традиционная файлуха только работает. Остальное — не вывозит.
Глустер, конечно, цефу проигрывает по бенчам и легкости настройки и администрирования, а функционала сильно меньше.
Виндовозников больше, они более узкоспециализированы. Спец по БД вряд ли сядет и с наскоку осилит ексчейндж во всей его красе, например.
А линуксоид и почту, и бдшку, и файлопомойку может. Обучить его гораздо проще, без всяких курсов и собраний томов документации.
Конечно, переделывать рабочую экосистему никто не будет, но что-то новое делать, я бы уже подумал несколько раз. С другой стороны, линуксоид может единосекундно взять и крепко накосячить, мануалов толстенных не особо много.
Я к тому, что базу данных, например, на тормозящем проприетарном ядре будет запустить более хуже, чем на открытом и оптимизированном.
В России этими проблемами занимается Олег Бартунов, вот его презентация на эту тему.