kiosaku
ну, там есть параметр вида "сколько-байтов-в-день" (утрирую) и как-бы, при превышении, ничего никто не гарантирует
edo1
самое похожее - target_max_bytes, но это не в день, а максимальный размер кэша
kiosaku
Drive Write Per Day
kiosaku
вот оно
kiosaku
dpwd
edo1
Обычно это просто характеристика ssd
kiosaku
ну, на consumer-овских дисках уже начали писать?
edo1
Ээээ. Я их не рассматривал
edo1
Хотя и для них обычно ресурс в терабайтах указан, посчитать dwpd несложно
edo1
И я не думаю, что tiering ресурс ssd будет сильно есть
edo1
Как я понимаю, после записи в лог/бд цеф зовёт fsync, так что рассматривать ssd без защиты кэша смысла нет (и производительность будет грустной, и ресурс будет жраться со страшной силой)
kiosaku
ну, я за них уже вышел на части железа
kiosaku
в плане количества записи в день
kiosaku
сдохнет - не страшно, но обидно
kiosaku
если не "просигналит"
Pavel
Как жить то собираетесь? =)
Pavel
https://youtu.be/T6zIHntybGg
edo1
пусть у нас есть два ДЦ, хотим, чтобы при выходе одного из строя всё продолжало работать
bestpractices есть как это всё организовать?
Евгений
вверх чат отлистайте на сутки
Anonymous
На пятницу вечер.
edo1
Сорри за невнимательность, я закачал себе историю этого чятика, пока только до января этого года дочитал )))
André | KreyDan |
Сорри за невнимательность, я закачал себе историю этого чятика, пока только до января этого года дочитал )))
Извините за офтоп, а как выкачать историю чата?
edo1
https://github.com/tvdstaaij/telegram-history-dump
edo1
плюс патчик отсюда:
https://github.com/vysheng/tg/issues/947
edo1
сейчас сформулирую
Евгений
да ну нафиг.
Два тезиса
- два мастер-ДЦ - это плохо, потому что проблему с линком трудно отличить от проблемы с падением
-для зеркалирования данных есть rbd-mirror
Anonymous
решение есть, но оно частичное. Это разместить часть мониторов в третью точку.
edo1
ну да, я думал +1 монитор вне дц. про rdb-mirror сейчас почитаю, может быть это то, что нужно
Sergei
Anonymous
больше вопросов возникает по архитектуре сети здесь
Anonymous
это действительно головная боль для ceph'а
Sergei
а чем три дц лучше, чем два дц + внешние мониторы?
тем что кластер в режиме size 2 min_size 1 на самом деле фактически не работает.
edo1
вот я про это и хотел спросить )
Anonymous
а чем три дц лучше, чем два дц + внешние мониторы?
Paxos любит нечетное количество всего и вся ;)
edo1
min_size 1 - опасно, этот вариант не рассматриваем
Sergei
min_size 1 - опасно, этот вариант не рассматриваем
если у вас size 2 min_size 2, то при двух дц и отвале одного из них кластер перейдет в ридонли.
edo1
если сделать min-size=2, size=3, то в случае падения одного ДЦ будет беда-беда-беда с репликацией
edo1
и всё равно в каждом ДЦ нужно место на 2 копии
Sergei
если у вас size 3 min_size 2, то при отказе одного дц кластер также перейдет в ридонли
edo1
итого кажется логичным сразу делать size=4, min_size=2
Anonymous
какие у вас мастабы?
edo1
и правилами настраивать, что две копии в одном ДЦ, две - в другом
Sergei
size 4 min_size 2 будет работать, если добавить мониторов в третий дц
edo1
масштабы - небольшие
edo1
терабайт-два-три быстрых данных и 20-30 всего
Anonymous
ну вот и отходите от этого. Я вам еще раз говорю, взаимодействие между двумя цодами - это боль на уровне сети, а не самого Ceph'а по большому счету.
Anonymous
т.к. процент сбоев именно сети будет больше
Anonymous
терабайт-два-три быстрых данных и 20-30 всего
Тогда вообще можно не заморачиваться двумя цодами
Sergei
Тогда вообще можно не заморачиваться двумя цодами
кек, а как связан объем данных и необходимость жить в разных цодах? :)
Anonymous
кек, а как связан объем данных и необходимость жить в разных цодах? :)
таким мастабом их проще сливать через rbd-mirror или даже rbd import'ом
Anonymous
чем усложнять архитектуру и тем самым поднимать риски
Sergei
таким мастабом их проще сливать через rbd-mirror или даже rbd import'ом
про поток, который пойдет в rbd-mirror не упоминалось.
впрочем, inter-DC ceph в любом случае решение сомнительное.
Anonymous
да и бекапы не кто не отменял )
edo1
что мне непонятно со схемой size=4, min_size=2
нигде нет же гарантий, что обязательные две копии не окажутся в одном ДЦ
Sergei
что мне непонятно со схемой size=4, min_size=2
нигде нет же гарантий, что обязательные две копии не окажутся в одном ДЦ
ты можешь написать crushmap такую какая тебе нужна
edo1
пример можно?
можно ли написать такие правило: блок считается записанным когда есть по реплике в разных ДЦ, потом делается ещё по реплике на ДЦ
Anonymous
у меня есть чудесные скрипты написаны на golang для rbd import, если кому надо будет, могу скинуть.
Anonymous
правда они написаны на коленке :)
Anonymous
мы с помощью него бекапы делаем.
Anonymous
edo1
min_size отлично сработает, если есть две реплики в одном ДЦ, разве нет?
Anonymous
смотря где будет первичная копия.
Anonymous
min_size =2 на весь кластер.
edo1
?
Anonymous
http://docs.ceph.com/docs/master/_images/ditaa-54719cc959473e68a317f6578f9a2f0f3a8345ee.png
edo1
так
edo1
запись в secondary и tertiary же идёт параллельно?
edo1
и как только один откликнулся "записал", клиент получает отклик
edo1
я неправильно понимаю?
Anonymous
все синхронно происходит. Пока последний не ответит, что записал
edo1
стоп-стоп-стоп. "пока последний не ответит" - это если size = min_size
edo1
или я всё не так понял?
Anonymous
min_size не учитывается при записи, он нужен только когда происходят проблемы с кластером.
edo1
а что такое "проблемы с кластером"?
Sergei
это когда вы выключили датацентр
edo1
я имею в виду как это выясняется
Sergei
что именно?
edo1
как кластер понимает, что он в degraded mode? просто по тому, что osd, к которой хотим обратиться, не в нормальном режиме?