Sergei
когда в очередные 10 секунд придет мониторинг и проверит, можно ли записать на диск хоть что-нибудь.
J
Ну а так интересно читать. Аристы, 240Гбит со стойки)
Mark ☢️
Mark ☢️
Типичный бэд сектор именно в данных осд
Mark ☢️
и как бы на диске обычно не только ледяные данные лежат
Бэд сектор можеи оказаться именно там
Mark ☢️
Либо надо в мониторинге весь диск перепрочитывать
Mark ☢️
Смарт говно. Не работает
Sergei
Бэд сектор можеи оказаться именно там
ну и пусть окажется. если мы его найдем - то диск еще не окончательно мертв и можно сделать ему out, но не заменять физически до тех пор пока все данные не отреплицируются.
Mark ☢️
ну и пусть окажется. если мы его найдем - то диск еще не окончательно мертв и можно сделать ему out, но не заменять физически до тех пор пока все данные не отреплицируются.
Да. И этот бед сектор означает замену диска. Чем раньше заменят диск тем меньше вероятность проеба 3 реплик
Mark ☢️
Типэ
Mark ☢️
Поэтому скруб помогает
Sergei
помогает. но если мы нашли бэд всего лишь на одном секторе - с большой вероятностью остальные данные норм читаются.
это значит что мы можем сначала отреплицировать данные, а потом выкинуть диск.
гораздо хуже если три диска с интервалом в 5 секунд просто вылезают из кластера в никуда без возможности возврата. это крайне высокий шанс потери данных, если дисков в кластере заметно меньше, чем PG/osd
Mark ☢️
О. А в цефе можно настроить чтобы выбирал для пг осд с разным временем наработки?
J
О. А в цефе можно настроить чтобы выбирал для пг осд с разным временем наработки?
Да, если придумаешь как это в краш карте оформить.
Sergei
я думаю можно обмазаться скриптами и крашмапами
J
Типа заранее придется диски на группы разбить.
Sergei
троллейбус.жпг
Mark ☢️
Ну прчему б и нет
J
Типа эти побольше наработали, а эти поменьше.
И ничо не троллейбус. Краш карты писать весело и удобно)
Mark ☢️
В хецнере принципиально делают софтрэйд из старого и нового диска
J
В хецнере принципиально делают софтрэйд из старого и нового диска
Интересно, строили математические модели какие-нибудь или типа эмпирически вывели такое правило)
Mark ☢️
Дак еблану понятно что одинаковые диски при одинаковой нагрузке упадут почти одновременно
Mark ☢️
Боян. Поэтому 6 рейд придумали жи
Mark ☢️
Ибо часто
J
Ну, в общем, можно скрипт который берет время работы из смарта для всех дисков, делит их на группы, генерирует краш карту и применяет ее.
Ракетная наука, да.
Mark ☢️
А чо прикольно.
Denis
крэш карта !
Mark ☢️
Лопата
Mark ☢️
Mark ☢️
Mark ☢️
Mark ☢️
Годнота же!
Mark ☢️
Дак да. Но прикольно же
Mark ☢️
Днищеёбство
J
Mark ☢️
Как диски
Mark ☢️
Это просто контроллер сата и не более
J
Ну тогда вообще не очень понятно)
Stanislav
почему на FC коммутаторы не стекируют?
Потому что вместо резерва ты получаешь одну большую точку отказа в случае глюка контролплейна. В фц вообще нет агрегирования, там мпио. Как раз аналог описанной схемы на оспф.
Anonymous
Потому что вместо резерва ты получаешь одну большую точку отказа в случае глюка контролплейна. В фц вообще нет агрегирования, там мпио. Как раз аналог описанной схемы на оспф.
Это был риторический вопрос.
Я пытаюсь найти схему которая будет выполнять примерно тоже самое на ceph - обеспечивать отказоустойчивость кластерой сети. Пока наиболее перспективным решением выглядит схема с OSPF.
Sergei
Anonymous
технически вам необязателен OSPF на хостах.
Можете подробнее рассказать? Как я понял схему с OSPF - хост анонсирует в две сети свой /32 адрес и по падению этой сети другие хосты переключатся на другую сеть. Оставив вопросы времени переключения и OSPF как точки отказа получаем работающую схему и то, что на хосте все-таки должен быть OSPF.
Могу представить как реализовать это настраивая каждый порт на L3 свитчах, но подобная схема мне нравится еще меньше.
J
По этой моей колхозной схеме поясню что OSPF + BFD использовать стоит для минимального времени переключения.
Anonymous
По этой моей колхозной схеме поясню что OSPF + BFD использовать стоит для минимального времени переключения.
Спасибо за схему. Буду тестировать.
Вопрос - а на чем поднят OSPF?
Sergei
@alexk24 , а зачем вам две полностью независимые фабрики?
J
Спасибо за схему. Буду тестировать.
Вопрос - а на чем поднят OSPF?
bird, от него ничего же и не требуется по сути.
Настроил разок и работает.
Anonymous
@alexk24 , а зачем вам две полностью независимые фабрики?
ну чтобы хотябы коммутатор обновить можно было.
количество хостов - пара десятков. понимаю что при Х стоек - отвал одного коммутатора на пару минут - не такая уж потеря.
Anonymous
ну и в целом на мой вгляд две фабрики - все-таки надежнее. тот же STP временами может сюрпризов доставить, а в топологии с фабриками проблемы ограничиваются одной фабрикой.
Anonymous
я бы вообще предпочел mpio на уровне ceph но как понимаю оно несколько вне идеологии ceph
Sergei
ну чтобы хотябы коммутатор обновить можно было.
количество хостов - пара десятков. понимаю что при Х стоек - отвал одного коммутатора на пару минут - не такая уж потеря.
ну так и в случае одной фабрики отказ одного комутатора - не проблема.
тезис про "отказ всей фабрики" - да, наверное...
Sergei
Anonymous
ну в некоторых случаях фабрика=коммутатор.
J
я бы вообще предпочел mpio на уровне ceph но как понимаю оно несколько вне идеологии ceph
Ну это пока не впилили, хотя и хотят.
Это можно на уровне TCP сделать, так то.
J
mptcp можно попробовать, но никогда с ним не работал, а только статейки читал)
Anonymous
деньги. деньги 😊
Anonymous
IB с помойки 😊
Sergei
Anonymous
Жизнь - боль 😊
Mark ☢️
опять сетевики
Mark ☢️
забодали
Mark ☢️
давайте ещё про спиннеры и крипту
J
А тут прикладная задача обсуждается и не в отрыве от цефа)
Anonymous
Сорри. Но я именно в контексте ceph. С сетевиками это обсуждать по большей части бесполезно.
Mark ☢️
Mark ☢️
)
J
В петухи записал(
Mark ☢️
нет, я не это имел в виду
J
Да я понял)
Михаил
Я смотрю тут новые люди.
Надо же и свой вариант приветствия завести.
Вот как вы смотрите на такую схему?
http://kernelpanik.net/running-ceph-on-zfs/
J