как s3 у кого-то сейчас в проде есть? там то хоть лучше чем с попытками использовать виртуальные машины поверх рбд?

как s3 у кого-то сейчас в проде есть? там то хоть лучше чем с попытками использовать виртуальные машины поверх рбд?

Отлично там

надеюсь

Можно и в него.

ceph это оверхед для s3. проще minio поставить. и быстрее будет.

ceph это оверхед для s3. проще minio поставить. и быстрее будет.

А по фичам цепха как оно ?

ceph это оверхед для s3. проще minio поставить. и быстрее будет.

Ты его пробовал ? Расскажи

Limits As with Minio in stand-alone mode, distributed Minio has a per tenant limit of minimum 4 and maximum 16 drives (imposed by erasure code). This helps maintain simplicity and yet remain scalable. If you need a multiple tenant setup, you can easily spin multiple Minio instances managed by orchestration tools like Kubernetes.

На каждый большой бакет приходится поднимать свой кластер. И сменить адрес ноды в кластере нельзя.

Для очень больших кластеров ceph лучше.

Для маленьких походу тож не плохо. Мне нра. Я вобще с одного нода с 3 дисками начинал. Ыыыы

Крушмап недефолтный делал чтобы копии в рамках нода мог делать

А потом ноды добавил и поменял крушмап

Суксес, УМВР

Суксес, УМВР

Сколько iops?

Сколько iops?

Нуууу. Три нода. Журналы на ссд. 10 осд. Помойму в район пары тыщ получается. На пуле сайзом три. На пуле сайзом 1 сильно больше. Вангую я вобще не правильно мерял. Михаил грит что фио с рбдшным бакендом врёт

Я тоже на живом кластере менял crushmap для организации второго ДЦ. Но пара тыщь для ssd кластера это очень мало.

Я тоже на живом кластере менял crushmap для организации второго ДЦ. Но пара тыщь для ssd кластера это очень мало.

Как померять ? Давай затещщу твоим способом

Как померять ? Давай затещщу твоим способом

fio мерял. Я клоню к тому что архитектура ceph ограничивает iops кластера.

Там буквально пару лет назад read path был не выше 3000 iops, независимо от технологии стораджа.

fio мерял. Я клоню к тому что архитектура ceph ограничивает iops кластера.

1. Как мерял ? Конкретную команду 2. Не ограничивает. Если ограничивает то хотелось бы узнать где ограничение и в сравнении (не цифры!а орхетектура) с другими

1. Как мерял ? Конкретную команду 2. Не ограничивает. Если ограничивает то хотелось бы узнать где ограничение и в сравнении (не цифры!а орхетектура) с другими

Зачем команда?

Потому что от выбора ключей критически зависит результат тестирования

Блин, ну сейчас не охота рыться в списке рассылки ceph.

Сравнивал, ха-ха. ceph с netapp. Диски одинаковые. У Ceph были существенно более высокие latency и iops меньше.

Сравнивал, ха-ха. ceph с netapp. Диски одинаковые. У Ceph были существенно более высокие latency и iops меньше.

Напоминает сравнение монги с поцгресом. А условия тестирования-то точно были одинаковые? Такие как синкать ли после каждого запроса, преаллоцирован ли образ, уровень репликации, набор серверов и дисков и тд

Потому что от выбора ключей критически зависит результат тестирования

От настроек ceph критически зависит результат. Как следствие при смене версии меняется дефолтный набор и быстродействие меняется непредсказуемо.

От настроек ceph критически зависит результат. Как следствие при смене версии меняется дефолтный набор и быстродействие меняется непредсказуемо.

Ну пока нет методики тестирования (тоесть конкретной команды) не хочу дальше продолжать беседу на тему производительности.

Методика простая - в kvm запущена виртуалка. В ней запускается fio тест. Для ceph rbd, для netapp nfs. Для клтиента, виртуалки, условия одинаковые. И на чем лежит её диск ей одинаково.

А уж не включен ли у тебя кеш для нфса ? Fscache который

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-fscache.html

Методика простая - в kvm запущена виртуалка. В ней запускается fio тест. Для ceph rbd, для netapp nfs. Для клтиента, виртуалки, условия одинаковые. И на чем лежит её диск ей одинаково.

Какой режим кеширования у виртуалки ? Надеюсь , writeback

Объем тестируемых данных был конечно-же выше доступной гипервизору и тем более виртуалке памяти. Кеш тут не поможет.

Fio на блокдевайс натравлен или на файл в фс ?

режим кеширования none

режим кеширования none

Не представляю как работает O_Direct на nfs :(

Fio на блокдевайс натравлен или на файл в фс ?

на блокдевайс

на блокдевайс

Отлично

Что в плане преаллокейта ?

Прост запись в непреаллокейченную область во всех системах тормознее

ceph это оверхед для s3. проще minio поставить. и быстрее будет.

Смотря что за объемы и вопрос к стабильности ее

На нфсе кстать какой формат то был ? Qcow2? Raw?

Смотря что за объемы и вопрос к стабильности ее

Это да, minio отроду неделя

На нфсе кстать какой формат то был ? Qcow2? Raw?

raw

Что в плане преаллокейта ?

?

?

только dd if=/dev/zero of=/dev/sdb

только dd if=/dev/zero of=/dev/sdb

Неа. Ибо в куему есть детектор нулей

И он их в зависимости от настроек делает в спарсе-дырки

И он их в зависимости от настроек делает в спарсе-дырки

на raw делает?

Надо fallocate на файл сделать. Либо в нфсе если не работает то предварительно пртотереть файл с образом нулями

на raw делает?

Именно на нем и делает

Надо fallocate на файл сделать. Либо в нфсе если не работает то предварительно пртотереть файл с образом нулями

Например в команде qemu-img create

Ну и в цефе тож надо преаллоцировать. Тем же куему-имг

ну фиг его знает, виртуалки на netapp работали существенно стабильнее и быстрее чем на ceph :)

ну фиг его знает, виртуалки на netapp работали существенно стабильнее и быстрее чем на ceph :)

Про быстрее - эт ладно. А что про стабильность ?

Помойму это точно поливание говном необоснованное. У мну виртуалки переживали рестарт кластера и недобор кворума.

ну фиг его знает, виртуалки на netapp работали существенно стабильнее и быстрее чем на ceph :)

Это, а нетапп был через ту же сеть?)

Это, а нетапп был через ту же сеть?)

netapp был через своё темное волокно 8ГБ fc, ceph через такое-же темное волокно на 10ГБ ethernet.

Хм. Вобщето задержки в сети имеют критичноедля иопсов значение

Раунд трип тайм и все такое

netapp был через своё темное волокно 8ГБ fc, ceph через такое-же темное волокно на 10ГБ ethernet.

Тебе не кажется не честным сравнивать фц и медь?)

Латенси в вм как минимум будет разным

Тебе не кажется не честным сравнивать фц и медь?)

изернет по оптике работает

может сам протокол оверхед даёт

https://www.keycodemedia.com/2017/01/01/fibre-channel-vs-ethernet-by-alex-grossman/

https://www.keycodemedia.com/2017/01/01/fibre-channel-vs-ethernet-by-alex-grossman/

Ссылка ерунда. Facebook использует iscsi и как-то не хочет в FC. У FC тоже есть задержки.

А как жить на стораджах с 36 дисками по 8Тб?

В стандартном рабочем режиме каждый демон osd потребляет около 512МВ RAM не зависимо от объема диска. При включении кэш тиринга osd входящие в кэш пул потребляют в районе 1GB RAM на каждый демон в рабочем режиме. А вот при аварии - там нужно смотреть, не факт что каждый демон начнёт кушать по гигу на терабайт. Все зависит от крашмапы. А сколько вы нод с таким объемом ставить будете? И какую отказоустойчивость планируете? Потому что без этого сразу начнётся разговор, что "ceph говно"

Не, а внатуре, на что уходит столько памяти ?

Кстате да, хороший вопрос? Кэши?

Память на ребаланс же

Память на ребаланс же

А чо так многа та

цефа не знаю, но сдаётся мне, для ускорения процесса ребаланса: единожды вгрузить в память побольше данных, ятобы поберечьь головы оставшихся дисков

Или такое чудо в CEPH не засовывают?

у меня есть близкое к такому. Ну добиваешь памяти, сколько нужно (я стараюсь минимум соотношение 1.5 соблюдать)

у меня есть близкое к такому. Ну добиваешь памяти, сколько нужно (я стараюсь минимум соотношение 1.5 соблюдать)

посмотри на стенде, сколько цеф без данных жрёт

интереса ради

как s3 у кого-то сейчас в проде есть? там то хоть лучше чем с попытками использовать виртуальные машины поверх рбд?

а что с ВМ поверх рбд не так?

как s3 у кого-то сейчас в проде есть? там то хоть лучше чем с попытками использовать виртуальные машины поверх рбд?

там неплохо. но есть нюансы и трудноуловимые трудновоспроизводимые баги.

Там есть swift api и s3 api. Бекапилки уже многие умеют так

IBM Spectrum Protect (aka tivoli) умеет очень через жопу s3, как я выяснил)

там неплохо. но есть нюансы и трудноуловимые трудновоспроизводимые баги.

угу

IBM Spectrum Protect (aka tivoli) умеет очень через жопу s3, как я выяснил)

ну это тиволи)

надо еще чем-нить проверить