Комментарии 14
в итоге подход «а давайте смотреть в сырцы приложения, чтобы понимать, что происходит и что происходит не так» оказался очень эффективным, а я был не прав.
Разве? По-моему, в итоге в данном случае эффективным оказался подход "а давайте-ка вспомним, что мы вообще с этой штукой делали". Вспомнили, что ставили другую версию, поняли, что изменения связаны именно с этим, обновили версию, всё взлетело. А вспомнили бы сразу (или документировали бы все работы, чтобы можно было посмотреть историю) — все эти приключения были бы не нужны.
Дело в том, что именно такой подход и помог вспомнить. Конечно, пытались сначала проверить, что изменялось за последние N дней. И логи паппета смотрели, и dpkg.log, syslog и так далее. Что ставилась неправильная версия ceph, знал лишь один человек, который в этой ситуации не связал это падение с тем случаем и вспомнил, когда ему задали конкретный вопрос.
Документировать все работы, наверное, возможно только если вы либо очень маленькая компания или очень большая, в которой это просто жизненная необходимость. В моем идеальном мире все документируется и каждый чих где-то записывается, но не мной :) Но вряд ли этот идеальный мир когда-то настанет
Документировать все работы, наверное, возможно только если вы либо очень маленькая компания или очень большая, в которой это просто жизненная необходимость. В моем идеальном мире все документируется и каждый чих где-то записывается, но не мной :) Но вряд ли этот идеальный мир когда-то настанет
А разве нельзя просто записывать все команды операторов на серверах и отправлять их в центр?
Можно, но это никак не покроет кейс тотального контроля, чтобы все документировать.
Честно, я не вижу в этом необходимости в средней компании. Наверное, если у вас хостинг-компания с большим количеством инженеров без разграничений прав (что вряд ли), тогда в этом есть смысл (собирать все действия операторов с серверов), чтобы потом разбираться, кто что натворил. Да и то, чтобы не наказать, наверное, а чтобы научить и показать, как надо делать. Но это зависит уже от компании.
Честно, я не вижу в этом необходимости в средней компании. Наверное, если у вас хостинг-компания с большим количеством инженеров без разграничений прав (что вряд ли), тогда в этом есть смысл (собирать все действия операторов с серверов), чтобы потом разбираться, кто что натворил. Да и то, чтобы не наказать, наверное, а чтобы научить и показать, как надо делать. Но это зависит уже от компании.
Ой, как это у вас все сложно получилось…
Меня убила Ваша фраза «В общем, такое бывает.» Я не знаю как ведут себя небольшие кластеры до 300 сотен OSD но в штатной работе на продуктивном кластере количество таких проблем как Вы описали стремится к 1-2 в год!
Даже во время штатного расширения хранилища мы очень редко ловим такие проблемы все работает штатно как и положено.
Работаем начиная с hammer сейчас у нас кластеры на jewel готовимся к миграции Luminous.
А так спасибо конечно за то что поделились своим опытом)
Меня убила Ваша фраза «В общем, такое бывает.» Я не знаю как ведут себя небольшие кластеры до 300 сотен OSD но в штатной работе на продуктивном кластере количество таких проблем как Вы описали стремится к 1-2 в год!
Даже во время штатного расширения хранилища мы очень редко ловим такие проблемы все работает штатно как и положено.
Работаем начиная с hammer сейчас у нас кластеры на jewel готовимся к миграции Luminous.
А так спасибо конечно за то что поделились своим опытом)
Блин, круто) Мне не приходилось работать с таким количестовм osd, максимум имел дело с около 100. Сейчас уже почти с ceph не работаю, но воспоминания еще достаточно свежи, что это чудо нужно постоянно дебажить и изучать, почему все идет не так, как надо. Я тогда работал с самым новым Jewel, и в кластере периодически происходило так, что osd выключались рандомно и перезапукались systemd. Чего только с ceph не происходило, я ловил множество непонятных ситуаций, когда приходилось придумывать какие-то воркэраунды или мириться с таким поведением и придумывать хитрости. Расскажу про пару вещей:
— Стораджи с 20 osd на борту. Сервер завис, нужно рестартить. После рестарта поднимается лишь часть osd. Остальные юниты failed в systemd. Ну, наверное, что-то при загрузке не так пошло. Потом нужно по какой-то причине проверить, как рестартятся osd. Делаешь
— Другой случай вообще классический. Я частично описал его в статье. В кластере появились slow requests. Анализируешь ситуацию, видишь, что все реквесты на одной osd. Смотришь
— У ceph есть официальный ansible-playbook для создания кластера, деплоя мониторов, osd и т.д. Мы им пользовались для начальной наливки кластера и потом временами, когда надо было диск заменить в сервере и засетапить нового демона osd. Но было замечено, что часто, но не всегда, в кластере после прохождения по нему плейбуком образовывалось слишком много degraded и misplaced объектов, больше, чем нужно. Жить особо не мешало, просто увеличивало время recovery. Но периодичеcки появлялись slow requests, и это стало затрагивать прод. Оказалось, что этот плейбук проходился по папкам /var/lib/ceph/*, выуживал оттуда id osd и считал, что именно они и должны быть запущены на данной ноде. Но ведь, когда диск вылетает (или вылетело два диска на разных нодах), ты наливаешь osd на новый диск и он получает минимально возможный номер в кластере, т.е. вылетевший osd.17 на z ноде, может быть потом налит на x ноде, а на z ноде останется пустая папка под 17 osd, в которую раньше монтировался диск. Поэтому ceph наливал на неиспользованном диске osd (если мог) и запускал 17й osd снова на z ноде, из-за этого менялась crush map, на x ноде валидный osd.17 делал out из кластера, потому что новая регистрация пришла с z ноды и оверрайтнула предыдущую карту. Пришлось писать мониторинг пустых папок в этой директории и оперативно их удалять :) И хорошо, если диск нормальный, а если диск битый или готовый развалиться, а его не успели еще поменять. Вот тогда будет много слоу реквестов.
В общем, приходилось много не спать, читать мануалы и немногочисленные, к сожалению, форумы и почтовую рассылку. Даже в багтрекер Ceph тикет когда-о создавал.
Так что, на моей памяти ceph — отличный продукт и клевой идеей и реализацией, но очень нестабильный. Возможно, были еще какие-то факторы, влияющие на стабильность кластеров, или это просто моя корма и везение, кто знает)
— Стораджи с 20 osd на борту. Сервер завис, нужно рестартить. После рестарта поднимается лишь часть osd. Остальные юниты failed в systemd. Ну, наверное, что-то при загрузке не так пошло. Потом нужно по какой-то причине проверить, как рестартятся osd. Делаешь
systemctl restart ceph-osd.target. Все osd выключаются, стартуют все, а в CRUSH показаны многие osd на ноде как down, хотя процессы запущены. Что за чудеса? В итоге выяснили экспериментальным путем, что при одновременном старте osd у этих самых osd начинается что-то типа race condition за то, чтобы занять порты из выделенных им диапазона, и дальше что-то идет не так, и некоторые osd некорректно регистрируются в кластере. Пришлось писать обвязку, которая стартовала osd с задержкой (sleep) на определенное количество времени в зависимости от их id.— Другой случай вообще классический. Я частично описал его в статье. В кластере появились slow requests. Анализируешь ситуацию, видишь, что все реквесты на одной osd. Смотришь
ceph osd tree, все osd UP и IN. Идешь на ноду к этой osd, а она не запущена! Понятно, почему slow requests копятся. И непонятно, почему все osd рядом, которые должны ее пинговать, не зарепортили монитору, что она down, и он ее не пометил должным образом?— У ceph есть официальный ansible-playbook для создания кластера, деплоя мониторов, osd и т.д. Мы им пользовались для начальной наливки кластера и потом временами, когда надо было диск заменить в сервере и засетапить нового демона osd. Но было замечено, что часто, но не всегда, в кластере после прохождения по нему плейбуком образовывалось слишком много degraded и misplaced объектов, больше, чем нужно. Жить особо не мешало, просто увеличивало время recovery. Но периодичеcки появлялись slow requests, и это стало затрагивать прод. Оказалось, что этот плейбук проходился по папкам /var/lib/ceph/*, выуживал оттуда id osd и считал, что именно они и должны быть запущены на данной ноде. Но ведь, когда диск вылетает (или вылетело два диска на разных нодах), ты наливаешь osd на новый диск и он получает минимально возможный номер в кластере, т.е. вылетевший osd.17 на z ноде, может быть потом налит на x ноде, а на z ноде останется пустая папка под 17 osd, в которую раньше монтировался диск. Поэтому ceph наливал на неиспользованном диске osd (если мог) и запускал 17й osd снова на z ноде, из-за этого менялась crush map, на x ноде валидный osd.17 делал out из кластера, потому что новая регистрация пришла с z ноды и оверрайтнула предыдущую карту. Пришлось писать мониторинг пустых папок в этой директории и оперативно их удалять :) И хорошо, если диск нормальный, а если диск битый или готовый развалиться, а его не успели еще поменять. Вот тогда будет много слоу реквестов.
В общем, приходилось много не спать, читать мануалы и немногочисленные, к сожалению, форумы и почтовую рассылку. Даже в багтрекер Ceph тикет когда-о создавал.
Так что, на моей памяти ceph — отличный продукт и клевой идеей и реализацией, но очень нестабильный. Возможно, были еще какие-то факторы, влияющие на стабильность кластеров, или это просто моя корма и везение, кто знает)
8 мониторов на 6 хостов? Не ошибка ли? И Реплика — 2, минимум 1 прям фейспалм…
8 мониторов — так исторически сложилось, что мониторами являются несколько compute нод опенстека и несколько стораджей. Когда-то так сделали, ну и ладно с ним.
Реплика 2 для dev окружения… что вам не нравится? Enterprise SSD диски с тройной репликой да не на проде — это больно уж круто. Диски надежные, пашут исправно, вылетают очень редко, а в подобной ситуации так я вообще не уверен, что реплика 3 вас спасла бы
Реплика 2 для dev окружения… что вам не нравится? Enterprise SSD диски с тройной репликой да не на проде — это больно уж круто. Диски надежные, пашут исправно, вылетают очень редко, а в подобной ситуации так я вообще не уверен, что реплика 3 вас спасла бы
4 года назад пытался запустить cephFS. Три старых сервера с ОЗУ 4Гб, разные диски объемом от 1Тб до 4Тб, в сумме чуть меньше 30Тб, реплика 2/1 для теста. После заливки 10Тб скорость записи упала до 100Кб/с. Начали расти slow requests, запись упала в ноль, после чего стали выпадать osd по 4Тб из-за нехватки оперативной памяти. Кластер начал перераспределять данные по оставшимся, которые так же стали останавливаться, в итоге все стало в каком-то режиме, где записанных данных было больше, чем емкость рабочих osd. Память (FB-DIMM DDR2) на тот момент докупить не могли, а диски уже были. Так красивая идея разбилась о суровую реальность.
Вам бы желательно выйти на нечётное количество мониторов… официальные рекомендации словно приказ, если хотите избегать каких-либо проблем.
docs.ceph.com/docs/master/rados/operations/add-or-rm-mons
docs.ceph.com/docs/master/rados/operations/add-or-rm-mons
Спасибо за совет, да, я видел эти рекомендации. Сейчас мониторов 5, но есть у меня предположение, что при числе мониторов, стремящихся от 0 к бесконечности, нечетность их количества не играет особой сути, и эта дока имеет ввиду: «Чуваки, не делайте 2 монитора, потому что это сплит брейн. 3 хорошо.»
It is advisable to run an odd-number of monitors but not mandatory. An odd-number of monitors has a higher resiliency to failures than an even-number of monitors. For instance, on a 2 monitor deployment, no failures can be tolerated in order to maintain a quorum; with 3 monitors, one failure can be tolerated; in a 4 monitor deployment, one failure can be tolerated; with 5 monitors, two failures can be tolerated. This is why an odd-number is advisable.То есть в случае с 8 мониторами, 8й монитор ни к селу, ни к городу, так как не увеличивает resiliency кластера) Но это не критично
Есть Ceph версии 0.94 (Hammer). 6 стораджей, 8 мониторов, по 6-8 osd на каждом сторадже, SSD диски объемом от 1 ТБ до 4 ТБ. Реплика — 2, минимум 1.
Зачем 8? Три монитора способны обрабатывать под 1к OSD без каких либо проблем.
Две реплики для dev самое оно, для prod — это выстрел в ногу. И дело не только в количестве реплик и их данных, но и в консенсусе при сбоях/ошибках объектов в rados. Я уверен на 99 %, что при size=3, у вас бы не было данной проблемы.
Немного slow requests и самопроизвольные рестарты, что для ceph не критическое событие и довольно частое.
Для ceph нет, а для клиентов к сожалению бывает критично, т.к. вызывает блокировку блоков на VM клиента.
вечером прошел некий шторм по всему кластеру и самопроизвольно перезапустилось множество osd
Вам нужно крутить параметры памяти и лимиты в ОС
В общем, такое бывает.
Не должно быть!
в таких ситуациях поступает любой админ, дело кончилось перезапуском всей ноды… Или у osd перестает что-то работать, и без перезапуска сервера она не хочет запускаться.
Так делают только Windows-админы(без обид), с Linux'ами лучше проблемы решать до перезагрузки. 90% проблем решается с чтением логов и принятие необходимых решений.
Спустя сутки админ заметил, что версия ceph неправильная, внес изменения, установил верную, перезапустил (!!!) osd (не переналивая) и ушел курить бамбук.
facepalm :). Вообщем я дальше читать не стал :)
P.S. А за опыт и его описание Спасибо, жаль что кармы нет плюсануть…
Спасибо за статью, интересно и полезно. Однако, я бы все-таки переименовал ее в «Как мы сломали Ceph» или «Вредные советы по Ceph».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как у нас сломался Ceph