ну вот записали вы в osd и он тут же отвалился

ну норм. у меня еще есть.

не факт что они консистентны

не факт что они консистентны

факт. потому что когда мы пишем на кластер (а не на osd), запись считается произведенной при совершившейся записи на кворум в PG. то есть в случае 3:2 минимум на 2 osd.

должны быть некие consistency group с одним и тем же журналом

должны быть некие consistency group с одним и тем же журналом

кому должны?

http://tracker.ceph.com/issues/13295 вот типа такого

у вас 3 osd для pg (в pgmap). вы подключаетесь к лидеру. пишете в него объект. он пишет к себе, подключается к двум другим, дожидается ответа хотя бы от одного, отвечает вам "ок". в момент ответа "ок" в кластере есть уже минимум две копии объекта на разных osd. теперь один из osd падает. например, бывший primary. теперь osd обслуживается двумя osd, на одном из них есть актуальный объект, на другом - нет (или есть неактуальный). они сравнивают версии и неактуальный докатывается до актуального. выбирается новый osd для обслуживания этой pg. на нем нет объектов. он копирует их с оставшихся двух osd.

где здесь грязное чтение?

http://tracker.ceph.com/projects/ceph/wiki/Consistency_groups/2

это не для основной функциональности (не для распределенного блокдевайса).

хлебом не корми, дай про цеф поговорить :3

хлебом не корми, дай про цеф поговорить :3

Это не я! Оно само

с точки зрения ceph грязного чтения тут нет. с точки зрения файловой системы поверх тут никак гарантий нет. ибо эти две сущности никак не связаны

Или может я)

с точки зрения ceph грязного чтения тут нет. с точки зрения файловой системы поверх тут никак гарантий нет. ибо эти две сущности никак не связаны

у файловой системы есть свой журнал. блокдевайс под файловой системой ведет себя корректно, грязное чтение не делает, ненастоящую запись не делает, восстановление убитых не делает.

Всем доброго дня! Коллеги, а есть у кого-то хорошие статьи по возможностям кластеризации мастера? На почитать-поосваивать.

ну ок) оставим этот спор для экспериментаторов. по факту никаких гарантий я для себя не вижу. Плюс ещё замаунтится ненароком в несколько мест и точно все.

ну ок) оставим этот спор для экспериментаторов. по факту никаких гарантий я для себя не вижу. Плюс ещё замаунтится ненароком в несколько мест и точно все.

сдуру можно и хрен сломать

а если fio randwrite запустить на диск, так вообще! стораджа никуда не годятся по устойчивости к randwrite и dd if=/dev/urandom

гладко было на бумаге (с)

а потом 20 человек неделю бд чинят сидят с воплями она же не должна так работать)

а потом 20 человек неделю бд чинят сидят с воплями она же не должна так работать)

возможно что-то не так в консерватории. если вы можете разломать rbd так, что он говорит, что ему хорошо, а на самом деле ему плохо - расскажите как, это интересный опыт.

и нет, кейс "мы вырубили один osd на горячую" к такому не приводит.

мб это как раз кейс "мы дёрнули 2 диска из кластера с двойной репликой" ?)

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

Перманентно все сломано в разных местах, постоянно сеть флапает, самое время накатить на сетевой рейд файлуху с бд и жить счастливо ;-)

Перманентно все сломано в разных местах, постоянно сеть флапает, самое время накатить на сетевой рейд файлуху с бд и жить счастливо ;-)

rbd не очень для многих регионов.

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

То есть вы гоняете рбд трафик между дц, а виноват в глюках цеф?!

А то что гланды через задницу удалить не удобно это гланды виноваты?

То есть вы гоняете рбд трафик между дц, а виноват в глюках цеф?!

ну справедливости ради, от абстрактного софта в вакууме я ожидаю деградацию и замедление в случае мульти-дц, а не "работать не будет совсем".

а кто виноват? это распределенный блок девайс

а кто виноват? это распределенный блок девайс

а вы расскажите таки, как сделать грязное чтение/несовершенную запись?

рбд трафик не вагонами же возить

я добивался перехода в ридонли/peering путем внедрения задержек и пакетлосса

но не грязных чтений

ну справедливости ради, от абстрактного софта в вакууме я ожидаю деградацию и замедление в случае мульти-дц, а не "работать не будет совсем".

Срравдливости ради локальная сеть и интернет разные вещи и обеспечение мульти дц отдельный функционал, который обычно отдельно заявлен

Срравдливости ради локальная сеть и интернет разные вещи и обеспечение мульти дц отдельный функционал, который обычно отдельно заявлен

локальная сеть тоже вполне может лоссить. и что называть локальной? :) вся сеть наша. просто до группы хостов пинг 3 мс, а до группы - 120 мкс.

я уже не вспомню, но такое точно встречали. эксперименты там закончились все пошло в прод, оставили только radosgw для cdn с картинками

работает ок

бд локально с нативной репликацией

бд локально с нативной репликацией

+

поверх фронтендов ipvs

+pyball

фронтенд нджиникс на стероидах с lua

а что за проект, если не секрет?

Lua для проверки здоровья бекендов и выставления веса для ipvs

часть работает тут flamp.ru

остальное секрет)

пробовали прямо с фронтенда по офсету писать в rbd (lua) без радосгв. тоже работает но возни много

пробовали прямо с фронтенда по офсету писать в rbd (lua) без радосгв. тоже работает но возни много

а зачем в rbd, кстати? :) если объекты не очень большие, то можно сразу в rados, там тоже есть сдвиги по оффсету.

а так посоны кодят сразу и в амазон можно идти если все совсем упало

и работает быстрее по задержке немножко

радосгв не очень хорошо работал, году в 2012

правда, это всё же для извращенцев немного

радосгв не очень хорошо работал, году в 2012

не в радосгв, а в радос через librados

там file-like api

http://docs.ceph.com/docs/master/rados/api/python/

возня ненужная. можно но зачем)

возня ненужная. можно но зачем)

если вам дороги микросекунды и лень делать другое решение - то rados over ssd вполне шустёр.

хотя aerospike быстрее

всё равно все в итоге в другом месте упирается. в бекенд, например. или в сеть

всё равно все в итоге в другом месте упирается. в бекенд, например. или в сеть

от приложения зависит.

нету пока пока доклада по bluestore с конфы линукс питер(

Господа, а нет ли простого способа развернуть Ceph в качестве бекенда к PV в самом Kubernetes?

Т.е. что-то вроде этого: https://github.com/ceph/ceph-docker/tree/master/examples/kubernetes но без "WARNING: This example does not survive Kubernetes cluster restart! The Monitors need persistent storage. This is not covered here."

пока извращенцев не было)

однако всё равно остается вопрос, а что же у тебя будет под ногами в качестве дисков?

А чем диски на хостах плохи для хранения? Или ты не про это?

я про то, что я слабо себе представляю как работает сущность OSD в докере

отдавать ей диск целиком в этот докер? а зачем тогда докер?)

и тут до меня дошло, что можно не отдавать весь диск, а отдать папку, тогда можно ограничить объем и получить отказоустойчивость)

Господа, а нет ли простого способа развернуть Ceph в качестве бекенда к PV в самом Kubernetes?

внутри самого куба? А зачем?

в общем-то можно, через маппинг

Я пытаюсь развернуть Kubernetes в Azure, и есть подозрение, что использовать ажуровские диски для персистентных данных как PV не получится. Для PV остаётся Azure File (который SMB) либо что-то кастомное (Ceph?). Сомневаюсь, что на SMB можно держать хоть какую базу данных.

Я хочу решение для PV, которое позволит перекидывать их между нодами в случае чего. По идее Ceph RBD + ext4, монтируемый эксклюзивно, это то, что может мне подойти.

Собственно, я бы попробовал Ceph, но я с ним никогда не работал, и как-то неохота потратить пару недель чтобы разобраться как его деплоить и поддерживать.

Kubernetes supports several types of Volumes: ... azureDisk

это не то что требуется?

Ага, это оно, но есть ряд ньюансов

Например на небольших виртуалках количетсво дисков, которые можно так подключить сильно ограничено —- всего 2 диска, на минимальной приличной виртуалке (1 ядро, 3.5 ГБ RAM)

Плюс судя по отзывам, azureDisk просто не работает: http://dev.haufe.com/state-of-kubernetes-on-azure/

Я хочу решение для PV, которое позволит перекидывать их между нодами в случае чего. По идее Ceph RBD + ext4, монтируемый эксклюзивно, это то, что может мне подойти.

тогда вам нужен другой вариант - покупаете себе отдельно машины под ceph, а из куба подключаетесь к ним

можно цеф в том же ажуре завести

тогда вам нужен другой вариант - покупаете себе отдельно машины под ceph, а из куба подключаетесь к ним

Чтобы иметь для Ceph свою быструю сеть/выделенные ресурсы CPU/RAM?

А без Kubernetes насколько реально не вникая в детали Ceph развернуть его на отдельных машинах, скажем, с убунтой/дебианом?

Я понимаю, что для продакшена с Ceph скорее всего нужна отдельная команда девопсов под него, но на потыкать/примерить, мне бы подошел вариант а-ля apt-get install <ceph> и пошаговой конфигурацией. Можно это как-то без особого геморроя сделать?

Для ceph у нас теперь отдельный канал)

@ceph_ru

@Sn00p мы таки сделали отдельный канал

?

?

Будем рады видеть всех любителей ceph

А без Kubernetes насколько реально не вникая в детали Ceph развернуть его на отдельных машинах, скажем, с убунтой/дебианом?

вполне реально, я разворачивал. Тут @SinTeZoiD грозился выложить подробный ман.

вполне реально, я разворачивал. Тут @SinTeZoiD грозился выложить подробный ман.

Ну там общие рекомендации. Будут для тех, кто уже поставил

Но ман похоже надо

Тоже

@rutsky по поводу персистент дисков в азуре вот issue https://github.com/Azure/acs-engine/issues/258 то есть рекомендуют до версии 1.5.3 обновиться руками. как раз собираюсь попробовать

@rutsky по поводу персистент дисков в азуре вот issue https://github.com/Azure/acs-engine/issues/258 то есть рекомендуют до версии 1.5.3 обновиться руками. как раз собираюсь попробовать

Спасибо, полезная информация

@rutsky по поводу персистент дисков в азуре вот issue https://github.com/Azure/acs-engine/issues/258 то есть рекомендуют до версии 1.5.3 обновиться руками. как раз собираюсь попробовать

А вы как деплоете Kunernetes в Azure? Используя ACS-Engine?