А в чем выражается "так себе". В доке не натыкался

Интересует режим чтения-записи

А в чем выражается "так себе". В доке не натыкался

Уф, я по доке сужу, там как раз про эффективность было

Known Bad Workloads The following configurations are known to work poorly with cache tiering. RBD with replicated cache and erasure-coded base:

Народ, а кто сравнивал cache tiering vs journal ssd. По удобству первый явно лучше, как со скоростью холодных данных?

Вообще это разные сущности, никак не связанные и не противопоставленные

http://docs.ceph.com/docs/master/rados/operations/cache-tiering/

RBD with replicated cache and base: RBD with a replicated base tier does better than when the base is erasure coded, but it is still highly dependent on the amount of skew in the workload, and very difficult to validate. The user will need to have a good understanding of their workload and will need to tune the cache tiering parameters carefully.

RBD with replicated cache and base: RBD with a replicated base tier does better than when the base is erasure coded, but it is still highly dependent on the amount of skew in the workload, and very difficult to validate. The user will need to have a good understanding of their workload and will need to tune the cache tiering parameters carefully.

Меня именно это. Случай интересует. В целом описание довольно абстрактное. Логично что Настройки Кеша нужно подбирать.

Меня именно это. Случай интересует. В целом описание довольно абстрактное. Логично что Настройки Кеша нужно подбирать.

Это идёт в разделе known bad workloads

Проблема в том, как работает cache tier. Хорошо, что используется bloom фильтр, но вот реализация evict/flush - печальная

функционал будут переделывать

Проблема в том, как работает cache tier. Хорошо, что используется bloom фильтр, но вот реализация evict/flush - печальная

А в чем печаль? Просто не могу найти нормальных бенчей. Обычно параметры там от балды ставят.

А погонять пока железа нет свободного.

ну вот у тебя по дефолту размер объекта - 4Mb. Ты записываешь 1Кб данных, а ceph поднимает из холодного пула в горячий - полностью весь объёкт, т.е. 4Мб

в этом и основная проблема. Операции evict/flush убивают производительность.

Так он и без кэша так делает, или я не прав?

нет

Хм

А какой тогда механизм при работе с обычным пулом rbd?

Народ, а кто сравнивал cache tiering vs journal ssd. По удобству первый явно лучше, как со скоростью холодных данных?

коллективный опыт хабра показывает, что тиеринг всегда выливается в all-flash хранилище. Если у вас традиционная война быстро/дешево - делайте раздельные пулы и классы обслуживания. Увы.

коллективный опыт хабра показывает, что тиеринг всегда выливается в all-flash хранилище. Если у вас традиционная война быстро/дешево - делайте раздельные пулы и классы обслуживания. Увы.

В последнее время опыт хабра уже совсем не торт ))) Сейчас как раз и разбито - быстрый пул ssd only, медленный - hdd. Но руки чешутся кэш пощупать .

В последнее время опыт хабра уже совсем не торт ))) Сейчас как раз и разбито - быстрый пул ssd only, медленный - hdd. Но руки чешутся кэш пощупать .

на хабре было несколько подобных инсталляций. Все они пришли к all-flash

Тут были кто делал all flash и доклад их был

Не не не. Вариант когда предлагают на один ssd поставить 5 osd. И на каждой ноде по такому принципу разбить 2 и более ssd меня не устраивает. Вариант вылета целой ноды при таком конфиге не радует

Не не не. Вариант когда предлагают на один ssd поставить 5 osd. И на каждой ноде по такому принципу разбить 2 и более ssd меня не устраивает. Вариант вылета целой ноды при таком конфиге не радует

это вам решать, на чем вы будете экономить. Я бы ставил парой SSD+HDD.

это вам решать, на чем вы будете экономить. Я бы ставил парой SSD+HDD.

ssd в этом случае под журнал?

да. Если вам действительно никак не получается сделать нормально all-flash - хотя бы журнал под SSD.

главное nobarrier туда не ставить. Это будет эпичный выстрел в ногу

Так у нас и так пул с виртуалками на ssd только. Я hdd пул хотел ускорить, с которого нарезаются доп диски для не критичных по iops данных. А вот по месту там нужно много.

Тут больше спортивного интереса.

Все таки Что то ещё на OSD ноде можно запускать?

Систему мониторинга, например которая с этим же кластером работает?

Расскажу свой небольшой опыт по SSD + HDD для RBD: много всего пробовали, в итоге самой быстрой конфигурацией оказалось запуск ОСД на Flashcache. Очень хотелось поиграться с кэш пулами, но увы, для RBD оно работает не так хорошо как хотелось бы. Особенно под базами данных и подобным. В итоге юзаем RAID10 под пулы для mission critical, HDD + SSD + Flashcache под базы данных (нужнал находится якобы на HDD, но весь живет в кэше на SSD) и простые HDD + jerasure под большие хранилища.

В последнее время опыт хабра уже совсем не торт ))) Сейчас как раз и разбито - быстрый пул ssd only, медленный - hdd. Но руки чешутся кэш пощупать .

cache-tier - штука загадочная, при r/w нагрузке и rbd смысл в нем появляется если данные полностью умещаются в кеш, т.к. если начинаем читать то, что находится не в кеше - производительность падает, всплески на запись он конечно сгладит, но точно так же (и даже лучше) их сгладят и журналы на ссд.

Насколько дурацкая идея в sds в разных DC?

ДЦ почти рядом

ДЦ почти рядом можно маршрутизировать и через 9000км. Всё в этом дело.

ДЦ почти рядом

Если латенси устроит - почему нет.

Как оно себя будет вести, если латенси будет разная между нодами?

К тому же можно попробовать поднять mirror с async синхронизацией

И два радоса?

Как оно себя будет вести, если латенси будет разная между нодами?

Нормально.

Чтобы каждая площадка со своим говорила

А что будет при развале канала? В чью сторону фенсить?

Можно в этом направлении копать: http://docs.ceph.com/docs/master/rbd/rbd-mirroring/

Это по сути HA

Если один кластер резнесен на два цод-а, с failure domain = DC. Отвалится половина кластера.

Это по сути HA

А что надо?

Распределенную хранилку с разными точками мотирования.

Можно так, риски только посчитайте, карту отказов смоделируйте.

Я правильно понимаю что вся сеть будет работать на латенси самой медленной ноды?

Да, в общем случае

Starting with version 9.0, DRBD has an auto-promote feature. That allows you arbitrarily use other cluster managers that are able to mount a file system on a shared storage device. До чего дошёл прогресс

Если нод планируется 2-е то лучше DRBD. под Ceph надо по доке от 3-х/, а в реальности желательно от 5-ти.

Это да... Как бы не пришлось опять Hadoop ставить

Чёт наши полюбили OpenTSDB

Можно в этом направлении копать: http://docs.ceph.com/docs/master/rbd/rbd-mirroring/

В комментариях ко вчерашней статье сказали, что не продакшн вариант)

А как две площадки соединять в коментах её сказали?

А как две площадки соединять в коментах её сказали?

нет конечно)

http://www.slideshare.net/Hadoop_Summit/selective-data-replication-with-geographically-distributed-hadoop?from_m_app=android

Не про цеф конечно

У нас между двумя оптика на 40 гбит

Отдельная для цефа

https://www.youtube.com/watch?v=bbPO3Qb7gzA как 50 минут рассказывать ниочем можно смотреть с 25 минуты где-то, если хочется.

Отдельная для цефа

И как?

Как переживает отвал кабеля?

Репетировали?

Пока нет, собираем только

Недавно вторую точку добавили

Идея в том чтобы они независимо работали

Эм...

То есть пулы находятся в разных точках географических

Не знаю даже как пояснить

Ну вы их между собой не реплицируете?

Нет

Ну тогда не наш кейс :(

может после тестов попробуем реплицировать

Так, а кто-нибудь про SPDK может рассказать?

только без корейских презентаций

если я правильно понял, то это только для bluestore поддерживается