ну а пока объект не прочитался - следующий читаться и не будет
Чтение не проблема.
Для чтения у меня будет bcache на NVMe дисках.
J
J
Собственно, и запись в filestore можно через него же пропускать, но смысла большого не будет, потому что если журнал на том же диске, все в него и упрется.
J
Зачем что?
Dimonyga
зачем bcache ? зачем лишние сущьности ? цеф всё это сам умеет. Если используете файлстор - делайте журнал на NVMe, если блюстор - не так давно скидывал как журнал отложенной записи. При разгрузке записи - выростает и чтение, так как винт меньше дергает шпинделями по блину.
J
зачем bcache ? зачем лишние сущьности ? цеф всё это сам умеет. Если используете файлстор - делайте журнал на NVMe, если блюстор - не так давно скидывал как журнал отложенной записи. При разгрузке записи - выростает и чтение, так как винт меньше дергает шпинделями по блину.
Затем что NVMe диск побыстрее будет чем блины.
А Ceph Cache Tiers та еще история, очень ограничены пока варианты его применения.
Соответственно, держа горячие данные в кэше я разгружу механические диски и с записью тоже будет лучше чем если бы не было bcache.
Dimonyga
Затем что NVMe диск побыстрее будет чем блины.
А Ceph Cache Tiers та еще история, очень ограничены пока варианты его применения.
Соответственно, держа горячие данные в кэше я разгружу механические диски и с записью тоже будет лучше чем если бы не было bcache.
дело ваше, но чем больше сущьностей - тем ближе клаудмаус.
J
Лол.
Даже если bcache диск сдохнет, просто упадет производительность и все, никакого риска. Разве что writeback использовать с большим процентом грязных данных.
Мне вот про кэш дисков интересно все еще. Ни у кого не было таких результатов? Разобраться охота.
Mark ☢️
ну а пока объект не прочитался - следующий читаться и не будет
неверно. virtio-scsi отлично управляется с параллельными запросами
Mark ☢️
Лол.
Даже если bcache диск сдохнет, просто упадет производительность и все, никакого риска. Разве что writeback использовать с большим процентом грязных данных.
Мне вот про кэш дисков интересно все еще. Ни у кого не было таких результатов? Разобраться охота.
наркоман? если бкэшый диск сдохнет, то данные преврятятся в труху
Mark ☢️
потому что некоторые записи которые были профлушены в бкешный диск ещё могут не успеть попасть на магнитные диски
Mark ☢️
и тогда пинцет
J
наркоман? если бкэшый диск сдохнет, то данные преврятятся в труху
Во-первых, это только если использовать writeback, а во-вторых, даже если его использовать, ничего не превратится, а потеряется транзакция. Для того и пишется журнал. Запись объекта в осд повторится, но уже напрямую, без кэша.
Anonymous
Вопрос: а что, блустор уже готов для прода? :)
Anonymous
будущее неизбежно
Anonymous
будущее неизбежно
ну насколько я понимаю, unrecoverable data corrupting feature оно из-за того, что под bs нет средств восстановления
Anonymous
ну тут вопрос рисков. просто никто так и не ответил как он свой прод на filestore будет под bluestore мигрировать. никак
Anonymous
rocksdb, bluefs
Anonymous
я сознательно пилил прод на kraken, ввиду того, что миграция на luminos упрется в обновление, без перелапачивания дисков
Anonymous
недокументированно, но можно запускать разные бэкенды хранения в одном кластере одновременно
Anonymous
OSD абстрагирует бэкенд
Anonymous
почитайте про структуру osd
Anonymous
фс (ext4,btrfs,xfs) превращаются в bluefs. метаданные - в rocksdb. без форматирования всех дисков не уедете никак
Anonymous
фс (ext4,btrfs,xfs) превращаются в bluefs. метаданные - в rocksdb. без форматирования всех дисков не уедете никак
ну я про это же и говорил. Просто придется мигрировать OSD по одному/группами, куча гемора с бэкфилом)
Anonymous
и конфигами per-osd
Anonymous
хорошо если хоста 3 и дисков 20. а если 100...1000 OSD. застрелиться
Anonymous
то есть у тебя сейчас прод на блусторе?
Anonymous
да, баги в нем интересные, но работает. например каждый божий день часть дысков down, а потом через 6 сек up
Anonymous
а вот я такого не видел
Anonymous
толи supermicro, толи raid-controller, толи centos, толи kernel, толи ceph такой ))
Anonymous
может на больших иопсах в экспандер упираешься?
Anonymous
а еще какие баги были?
Anonymous
редко вываливаются карты 10Gbit
Anonymous
но это скорее поведение ядра
Anonymous
кароч если хотя бы 3 ноды, то вцелом живуче
Anonymous
ногрузка по расписанию, поэтому есть окна для бэкфилов и прочих издевательств, вроде обновления ядер
Mike
недокументированно, но можно запускать разные бэкенды хранения в одном кластере одновременно
Да почитайте доку о переезде на bluestore
Mike
Пересоздаём osd на BS. В одном кластере могут быть разные типы osd
Anonymous
то что читал я говорит о форматировании диска и разбивкой заново. вы про это?
Mike
то что читал я говорит о форматировании диска и разбивкой заново. вы про это?
Да. Полностью пересоздание osd с нуля.
Anonymous
если у наст 200 дисков, то получаем: выводим 1 диск, ждем реконфигурации, форматируем, добавляем, ждем закачки в него данных... переходим к диску номер 2.... и живые позавидуют мертвым...
Mike
Mike
Не вижу проблем
Anonymous
человеко-часы
Mike
Выводи полностью сервера
Anonymous
если локалхост, то тебе всеравно, если прод, всегда что-то может пойти не так
Mike
Выводишь сервер - перезаливаешь его с пересозданием osd и снова вводишь в кластер
Anonymous
ждешь те же объемы, только дольше
Anonymous
после размазывания к следующему хосту
Mike
если локалхост, то тебе всеравно, если прод, всегда что-то может пойти не так
Если страшно и не умеете в автоматизацию - руками. Только ошибок у человека больше, чем у скрипта
Anonymous
и не дай бог тебе завалить твой второй хост
Mike
А я не завалю, у меня три реплики.
Mike
Не вижу проблем, хоть тысяча дисков
Mike
Чем больше дисков и нод -тем быстрее ребаланс
Anonymous
с нетерпением жду твоего рассказа как ты переедешь, в твоем уютненьком бложике
Anonymous
наживую
Mike
У меня нет бложика ибо нахер он нужен
Anonymous
страничку или где ты мысли продвигаешь
Anonymous
опыт чужой интересен всегда
Anonymous
даже неудачный
Mike
с нетерпением жду твоего рассказа как ты переедешь, в твоем уютненьком бложике
Еще раз, тебе разрабы все объяснили - не веришь, не можешь - удаляй свой ceph и создавай заново с bs
Anonymous
ты в танке? я на bs. кому тут пишется этот говнотекст
Mike
ты в танке? я на bs. кому тут пишется этот говнотекст
А нафига тогда спрашивать? Те кому надо будет переезжать - переедут
Anonymous
или не переедут и будут стогнать о багах с потерей данных
Anonymous
твой потерянный локалхост никому не интересен. потеря на проде недопустима
Mike
Или не будут. Тебе то что? Хочешь для них написать инструкцию как не потерять данные - так проведи переезд и напиши.
Anonymous
я на тебе хочу проверить утверждение, что ты ничего не прогадаешь. ты ж уверен что все пройдет как надо, с автоматизацией. твой опыт им будет полезен. от меня толку мало, у меня bs
Mike
У меня есть тестовый стенд и время. И когда переедем - писать простыню не собираюсь, т.к. не имею привычки писать в бложик о всякой ерунде и раб. буднях.
Anonymous
задача этого срача подсказать тем, кто внедряет на проде ceph, перспективы обновлния на новую версию. kraken -> luminos пройдет в один заход. jewel -> luminos, с нюансами в виде вывода дисков и ввода в строй
Anonymous
и этот нюанс - дополнительный риск, который надо учитывать
J
Anonymous
тут больше про osd
Anonymous
структура osd сильно поменялась
J
структура osd сильно поменялась
Ну вроде выяснили что можно мешать Bluestore OSD с ообычными, где Filestore. Так что, потихоньку можно будет перевести.
Mike
Так разве Jewel до кракена не обновляется?
Не важно Кракен или что-то другое - вопрос в смене бакенда хранения
J
Ну я чего-то и не понял из-за чего спорить было)
Новый бекэнд, да. Пока недостаточно хорошо оттестированный. Да, есть уже возможность аккуратно переходить.
Anonymous
добавьте сюда подгулявшие диски, которые любят вываливаться в самые неподходящие моменты. у вас бывали случаи, когда во времяя бэкфилов вываливаются 2-3 диска. становится веселее )
J
Я немножко настраиваю параметры бэкфилла чтобы такого не было. И другим советую, собственно)