Комментарии 26
У нас стоит варниш, варнишу бекендами подцеплены 4 апача радосгейтвеев. Приложение сначала лезет в варниш, если там облом, то раундробином ломится напрямую в апачи. Эта штука жмет 20000 рпс без проблем по синтетическим тестам jmeter c access логом за месяц. Внутри полмиллиона фоточек, рабочая нагрузка на фронтенд около 300 рпс.
Мне ничего не понятно, но когда читаешь, а тем более произносишь — звучит круто :)
Спасибо, интересно.
У меня вопрос по тестированию: есть ли цифры нагрузочного тестирования по IO?
У меня вопрос по тестированию: есть ли цифры нагрузочного тестирования по IO?
Вот хорошая статья про бенчи. Наблюдаем у себя подобные цифры.
Другой вопрос, что тут на разных этапах много разного I\O и надо разобраться сначала, что именно интересует. Также все надо настраивать конкретно под задачу.
Другой вопрос, что тут на разных этапах много разного I\O и надо разобраться сначала, что именно интересует. Также все надо настраивать конкретно под задачу.
Если говорить конкретно про radosgw, то тут правильнее говорить о RPS, то есть сколько запросов в секунду способна эта система прожевать.
Я брал лог-файл с фронтенда за месяц, загружал его в jmeter и получал цифры до 20000 запросов в секунду на чтение на реальные объекты.
Это синтетический тест, зависит от настроек apache2, сетевого стека, количества памяти и камней для компонентов.
Тут все кэшами подперто, все очень быстро.
На запись все очень сильно печально, открывается коннект к фронтенду и делается upload пост-запросом для каждого объекта со всеми вытекающими.
Я брал лог-файл с фронтенда за месяц, загружал его в jmeter и получал цифры до 20000 запросов в секунду на чтение на реальные объекты.
Это синтетический тест, зависит от настроек apache2, сетевого стека, количества памяти и камней для компонентов.
Тут все кэшами подперто, все очень быстро.
На запись все очень сильно печально, открывается коннект к фронтенду и делается upload пост-запросом для каждого объекта со всеми вытекающими.
Я читал эту статью, спасибо. К сожалению в моём проекте таких показателей тестов недостаточно, чтобы работать с данными.
В общем, вариантов построения ceph множество. Типы и способы подключения дисков, файловые системы, кеширование, вынесение журналов и многое другое. Тут необходимо думать, выбирать и тестировать.
Но, на днях видел инициативу в сообществе о создании некоего калькулятора основанного на замерах конкретных конфигураций — www.spinics.net/lists/ceph-users/msg01738.html
Но, на днях видел инициативу в сообществе о создании некоего калькулятора основанного на замерах конкретных конфигураций — www.spinics.net/lists/ceph-users/msg01738.html
Nginx при аплоаде использует буферизацию перед тем, как отдать контент бэкенду. Теоретически, могут возникнуть проблемы при больших файлах или потоках. Но, дело вкуса и ситуации, nginx тоже работает.Ну так не надо так делать: php-fpm.org/wiki/Features#Accelerated_upload_support
Честно, особо не разбирался ) Спасибо за ссылку.
Есть вопросы про multipart upload и про то, где nginx этот временный файл положит )))
Есть вопросы про multipart upload и про то, где nginx этот временный файл положит )))
Вот сюда: nginx.org/en/docs/http/ngx_http_core_module.html#client_body_temp_path
Multipart одним куском в реальности-то приходит. Думаю, так одним куском и кладётся.
Multipart одним куском в реальности-то приходит. Думаю, так одним куском и кладётся.
Путь к нему будет находиться в переменной $request_body_file, как её передать на бэкенд — уже решать вам. Можете передать в теле запроса, можете передать в теле в формате json, а можете как переменную окружения, как в примере по ссылке.
Кстати как по надежности ceph? Я гдето квартал назад поставил на сервера для тестирования последнюю версию, даже без особой нагрузки одна из нод выпала через месяц. Что не есть гуд.
Надо понимать, что в такой системе recovery — это постоянный и обычный процесс, в том и фишка. Она так и придумывалось и проектировалась. Самое главное, чтобы это не сказывалось на производительности системы и сохранности данных, тут этого добились. Особенность ceph в том, что оно само узнает о проблеме, само восстанавливается в автоматическом режиме, что никак не сказывается на работе всего кластера. Если и требуется вмешательство админа, то это в пределах одной-двух утилит в консоли.
В разумных пределах и без фанатизма, конечно же. Например, при степени репликации n^2, дисков делать больше пяти, мониторы резервировать, собирать все на нормальном железе, обеспечить нормальную сеть, мониторить все точки.
При такой степени активности разработчиков можно понадеяться на выпуск совсем стабильной версии очень скоро. Пока вот прям «стабильности» не наблюдается, если оценивать с точки зрения enterprise. Нет, оно работает, но, например биллинг или финансовое что-то складывать — я бы не стал, честно. Ну и альтернатив нет с таким же функционалом, с такой же простотой настройки и надежностью.
В разумных пределах и без фанатизма, конечно же. Например, при степени репликации n^2, дисков делать больше пяти, мониторы резервировать, собирать все на нормальном железе, обеспечить нормальную сеть, мониторить все точки.
При такой степени активности разработчиков можно понадеяться на выпуск совсем стабильной версии очень скоро. Пока вот прям «стабильности» не наблюдается, если оценивать с точки зрения enterprise. Нет, оно работает, но, например биллинг или финансовое что-то складывать — я бы не стал, честно. Ну и альтернатив нет с таким же функционалом, с такой же простотой настройки и надежностью.
Elliptics смотрели?
Было дело ))
— непонятный черный ящик,
— документации ноль на тот момент,
— своеобразное чувство юмора у программистов,
Оно как-то проработало несколько месяцев, потом стало ломаться. Из-за чего ломаться, как чинить — непонятно. Я даже не осилил, как проверить его консистентность, допустим. Ну или вообще понять, где там что с нагрузкой и балансировкой. Вроде какие-то логи и утилиты есть, но сплошная белиберда ) Спросить не у кого. У самих разработчиков — нда-паранойя, максимум, что можно добиться: «используйте эту крутую штуку, мы используем и все круто». Например, вот.
Вообще продукты от самизнаетекого очень неряшливо и непонятно написаны. Есть ощущение, что опенсорсят они базовый функционал и какие-то проблемные огрызки для тестирования и патчей, на остальное забивают. Ну и для всех этих продуктов есть аналоги. Более удобные и приятные, зачастую.
— непонятный черный ящик,
— документации ноль на тот момент,
— своеобразное чувство юмора у программистов,
Оно как-то проработало несколько месяцев, потом стало ломаться. Из-за чего ломаться, как чинить — непонятно. Я даже не осилил, как проверить его консистентность, допустим. Ну или вообще понять, где там что с нагрузкой и балансировкой. Вроде какие-то логи и утилиты есть, но сплошная белиберда ) Спросить не у кого. У самих разработчиков — нда-паранойя, максимум, что можно добиться: «используйте эту крутую штуку, мы используем и все круто». Например, вот.
Вообще продукты от самизнаетекого очень неряшливо и непонятно написаны. Есть ощущение, что опенсорсят они базовый функционал и какие-то проблемные огрызки для тестирования и патчей, на остальное забивают. Ну и для всех этих продуктов есть аналоги. Более удобные и приятные, зачастую.
Вот, кстати видео. Там на седьмой минуте ржака. Вот у них все так и работает. «Требует некоторой оптимизации или давайте перепишем rsync».
они запустили отдельную компанию под elliptics: reverbrain.com
может кто-то имел с ними дело?
может кто-то имел с ними дело?
У всех крупных проектов, вылет нод, дисков, рекавери режим — это ежедневная реальность и лично мной воспринимается как нормальная работа. Просто надо тщательно мониторить — в том числе и сам мониторинг ( это важно ) и резервировать.
В сценарии с rados узкое место в виде единственного mds имеет место быть?
Пообщался в привате с автором — я бы честно говоря убрал бы из названия статьи кусочек «за 15 минут») Конечно есть новые технологии, есть инноваторы, но никто не отменял стандартные штатные методы. Ну не катит это всё для хай-лоада — как не крути. Не катит. Мы тут посчитали — у меня получается 800Мб в сек запись, уже не вариант — пытались тестировать pNFS — тоже не вариант. Только параллелить и сваливать на разные бэки — и + 10Гбсек. Вот так.
Честно говоря, никак не пойму, откуда у вас такие скорости. 800 мегабайт в секунду на запись. И уж тем более 10 гигабайт в секунду.
SSD диск ентерпрайз класса жмет мегабайт 500 при линейной записи. R0 из двух ентерпрайз SAS 15К — теоретически может раскочегариться до 700-800, опять же линейной записи. Практически — ну нет. Другие рейды — до 400 мегабайт линейной записи.
А есть еще файловая система, файлы и блоки разного размера, фрагментация. Запись почти всегда нелинейная. На выходе имеем на запись 250-300 мегабайт в секунду в среднем, на дорогом оборудовании. Это еще надо подключить и раздать потом, нужна распределенная файловая система. Что в среднем на 10-30% медленнее работает, чем традиционные файлухи.
Что вы пишите, как и куда? В кэш?)
Highload тут при чем? 20000 обработанных запросов в секунду — вполне себе highload.
SSD диск ентерпрайз класса жмет мегабайт 500 при линейной записи. R0 из двух ентерпрайз SAS 15К — теоретически может раскочегариться до 700-800, опять же линейной записи. Практически — ну нет. Другие рейды — до 400 мегабайт линейной записи.
А есть еще файловая система, файлы и блоки разного размера, фрагментация. Запись почти всегда нелинейная. На выходе имеем на запись 250-300 мегабайт в секунду в среднем, на дорогом оборудовании. Это еще надо подключить и раздать потом, нужна распределенная файловая система. Что в среднем на 10-30% медленнее работает, чем традиционные файлухи.
Что вы пишите, как и куда? В кэш?)
Highload тут при чем? 20000 обработанных запросов в секунду — вполне себе highload.
Спросите топикстартера — я с ним общался — скорости релаьные и постоянные. tns-counter.ru — ж
Ответил ниже.
Так, давай по порядку. Цель топика, как не сложно догадаться из названия, быстро поднять RADOS Gateway. Как я уже написал чуть выше, возможных конфигураций ceph множество и за один топик ну не описать все, тем более в режиме гайда. Ну а как ты хотел?
Теперь по твоему варианту, давай более предметно. Допустим у тебя есть 100 серверов, которые дампят файлы на хранилище раз в 15 минут. Ожидаемый объем одного такого файла 1ГБ. Грубый просчет тогда такой: 1ГБ за 15 минут это 1,3 МБ/c c одного сервера или 130 МБ/c со 100. Допустим ты хочешь иметь три реплики — умножаем на три получаем 390 МБ/c.
Вот тут есть грамотные тесты с правильным кешированием ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/. То есть контроллер с пробросом 6-и 7200RPM SATA дисков + журналы osd на ssd выдают что-то около 100 МБ/c на диск при XFS, который рекомендуют в продакшн.
Я не знаю что у тебя хранилище сейчас, но если интересны плюшки Сeph, то есть смысл попробовать собрать 3 сервера с 6-12 шпинделями и одним ssd на каждом + правильный контроллер.
Теперь по твоему варианту, давай более предметно. Допустим у тебя есть 100 серверов, которые дампят файлы на хранилище раз в 15 минут. Ожидаемый объем одного такого файла 1ГБ. Грубый просчет тогда такой: 1ГБ за 15 минут это 1,3 МБ/c c одного сервера или 130 МБ/c со 100. Допустим ты хочешь иметь три реплики — умножаем на три получаем 390 МБ/c.
Вот тут есть грамотные тесты с правильным кешированием ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/. То есть контроллер с пробросом 6-и 7200RPM SATA дисков + журналы osd на ssd выдают что-то около 100 МБ/c на диск при XFS, который рекомендуют в продакшн.
Я не знаю что у тебя хранилище сейчас, но если интересны плюшки Сeph, то есть смысл попробовать собрать 3 сервера с 6-12 шпинделями и одним ssd на каждом + правильный контроллер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эластичное избыточное S3-совместимое хранилище за 15 минут