В физической среде — да, SSD с power loss protection хватает. В виртуальной среде не факт, нужно чтобы все уровни корректно отработали. То есть если вы подадите такой SSD в виртуальную машину и укажете io=threads + cache=writeback|unsafe то nobarrier в гостевой машине создает риски, а если cache=writethrough|none или гостевая система нормально выдает flush — то опять всё становится нормально
При построении облака провайдер сервиса понимает все эти факторы, поэтому экстремальных кейсов у него вряд ли будет — то есть посланый flush гипервизор нормально отадресует на сторадж, поэтому если вы отправили в виртуальной машину flush на диск и получили на него ответ — то данные сохранены. Главное, чтобы ваша виртуальная машина этот flush сделала.
У вас неверное (очень) представление о работе ceph.
Начиная со слов «после 2 копий отпуская сессию».
И стенд с которого снимались графики как раз и был настроен под 3/2, и
Ага. Но ему это не слишком помогает. Либо куча фрагментирована либо еще что то. И jemalloc не используют. В определенных условиях оно крашит осд через несколько часов работы
«oom_score_adj» — у вас есть десяток процессов OSD которые примерно одинаково загружены и примерно одинаково потребляют память и есть незначительные потребители типа cron/sshd/что-то ещё. Если вы убиваете какую-то OSD, это всё равно что её терминирует OOM-killer. Просто пройдет это мягче. А завершение ssd и высвобождение 50MB RAM вам ничего не даст, потому что у вас OSD (например!) весит 7GB RSS.
Вы точно знаете, что ваши процесс точно-точно не начнут потреблять памяти больше, чем вы ожидаете? В случае с сефом это крайне критично — если если у вас падает по OOM OSD, это ещё более нагружает остальные узлы. Ну и всё осложняется архитектурой сефа. Фактически, если у вас упала одна OSD по OOM — у вас всё еще всё сравнительно нормально. Но если её перезапуск убивает другую, то пора «напрягаться». Потому что как только вылетит сразу две OSD в разных доменах отказа — всё, у вас проблемы с доступностью данных.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
Не имеет значения причина отказа. Приедет экскаватор и перекопает коммуникации, откажет коммутатор, сетевики совершат непреднамеренный теракт в процессе настройки своего оборудования, ядро свалится в kernel panic. Как «все реки текут вниз», так и все отказы приводят к одному и тому же финалу: offline OSD => start OSD => PG peering => Recovery.
Начиная со слов «после 2 копий отпуская сессию».
И стенд с которого снимались графики как раз и был настроен под 3/2, и
Ага. Но ему это не слишком помогает. Либо куча фрагментирована либо еще что то. И jemalloc не используют. В определенных условиях оно крашит осд через несколько часов работы
делаем shutdown / suspend клиентов (нет клиентов — нет нагрузки — нет дегрейдов — не будет рекавера)
опционально — делаем osd nodown
шатдауним сеф
обратное включение:
включаем оборудование
дожидаемся что все osd запустились
снимаем noout (и nodown если он стоял)
запускаем клиентов
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.