Comments 159
Не уверен, что недоступность одной-нескольких виртуальных машин — это тема топика для Хабра…
Лично я очень хотел узнать, что происходить — обновлял Хабр каждые 3 минуты, пока не ответила поддержка.
Можно будет убрать в черновики, после разрешения ситуации.
Можно будет убрать в черновики, после разрешения ситуации.
В одном из пулов облака произошла ошибка при переключении узлов кластера. Наши специалисты работают над решением этой проблемы.
Сомневаюсь, что речь идет об одной-нескольких.
Тоже зацепило
Когда вел «трансляцию» горевшего хостинг.уа тоже как бы был не повод для топика на хабре, но он был очень интересен многим.
Вроде починили
«Произошёл сбой при переключении узлов. Вероятнее всего, может понадобится перезагрузка виртуальной машины. Сохранённые на диск данные не должны были пострадать. Подробности позже, извините за созданные затруднения. „
«Произошёл сбой при переключении узлов. Вероятнее всего, может понадобится перезагрузка виртуальной машины. Сохранённые на диск данные не должны были пострадать. Подробности позже, извините за созданные затруднения. „
Какое-то странное у Селектела облако, должно ведь мигрировать в случае аварии или ещё чего.
Ну это в теории, а когда сталкиваешься с реалиями линий связи, коммутации, кэширования, всё выходит совсем негладко.
Никому маркетинговая клюква ничего не должна :)
Клюква не клюква, но я недавно пережил небольшой хабраэффект — и даже не заметил.
Поломки везде бывают, а вот устраняют их по-разному. Тем более, это недавно запустили.
Поломки везде бывают, а вот устраняют их по-разному. Тем более, это недавно запустили.
Пережить хабраэффект — облаком быть не обязательно.
Поломки действительно везде бывают, но как бы облако и позиционируют как их частичное решение.
Поломки действительно везде бывают, но как бы облако и позиционируют как их частичное решение.
Миграция между хостами, а не между хранилищами. А проблема была взаимодействии узлов кластера и хостов. Не сработал multipath, не переключилось, пришлось всё делать силком.
А какой тип мультипасинга используете?
host-based round-robin (хост при старте случайным образом выбирает приоритет и его использует, при отказе переключается на соседа). Так как flashcache кеширует IO, то multipath не может обнаружить отказ рейда (его 512 байт закешированы), а запись просто тупо stuck из-за того, что данные синхронно пиру отсылаются. В предполагаемом сценарии при отказе пира просто включается standalone, но тут не отказ, тут просто «нулевая скорость» (причём не по всем запросам — часть работает, часто нет).
понял, спасибо
а почему не multibus + выбор по service-time? На тестах он у меня давал лучшую производительность.
Плюс, в теории, в подобной ситуации при мультибасе будет лишь деградация сервиса, а не полный отказ в обслуживании. Хотя, конечно, врядли кто-то это тестировал.
Плюс, в теории, в подобной ситуации при мультибасе будет лишь деградация сервиса, а не полный отказ в обслуживании. Хотя, конечно, врядли кто-то это тестировал.
Тут проблема в другом — из-за того, что запись идёт по протоколу C, мы имеем проблему — drbd пиру отсылает, а тот просто тупит. Соединение не рвёт, ошибку не возвращает. В результате затыкаются оба (то есть переключайся/не переключайся проблема остаётся). Ну и финальный удар под дых: проблема воспроизводится на обоих хостах в кластере.
«привязка» в хосту вызвана тем, что у каждого хоста свой read cache, таким образом, на серверах кластера образуются разные кеши (и повышается эффективность, т.к. меньше вытеснение).
Впрочем, на фоне бунтующего mdadm это всё ерунда…
«привязка» в хосту вызвана тем, что у каждого хоста свой read cache, таким образом, на серверах кластера образуются разные кеши (и повышается эффективность, т.к. меньше вытеснение).
Впрочем, на фоне бунтующего mdadm это всё ерунда…
значит не облако ни разу
У нас три машины умерло :(
Trust must be earned
Слышал про одного сисадмина, работающего на крутую американскую компанию. Так вот ему сказали — если по Вашей вине положится сервак — увольнение с последующим запретом на въезд в Америку
Слышал про одного сисадмина, работающего на крутую американскую компанию. Так вот ему сказали — если по Вашей вине положится сервак — увольнение с последующим запретом на въезд в Америку
По поводу запрета на въезд — скорее всего вранье. Даже, если сервер у админа упадет, то он нанес ущерб компании, но не государству.
По бразильской системе!
У нас бы так. Сервак лег — запрет на проживание в России. Yahooo. :)
«Говорят что кур доят».
Нужно блог открывать который будет называться «Слышал ...».
Нужно блог открывать который будет называться «Слышал ...».
Зачётный у автора топика ник.
Да это разве авария, по сравнению с недавними событиями у одного их именитого конкурента )
Начат запуск машин
И снова все радостно пи****сь
Однако не все узлы были затронуты. Мне повезло. Моя ВМ не заметила проблем.
03:20 Включилось. Надеюсь, насовсем.
Виноваты. Данные сохранили без повреждений, а вот связь между СХД и хостами, да, поломалась, причём дважды.
Сейчас починили, пострадавшие машины запустили.
Подробнее я напишу завтра утром, ок? Пока мне нужно прийти в себя и выспаться.
Сейчас починили, пострадавшие машины запустили.
Подробнее я напишу завтра утром, ок? Пока мне нужно прийти в себя и выспаться.
05:10 обнаружил, что «ничего не работает», судя по графикам машина вырубилась около 4х
05:25 выключили панель управления облаком, в поддержке говорят о сроках восстановления 0.5-3 часа
05:25 выключили панель управления облаком, в поддержке говорят о сроках восстановления 0.5-3 часа
UFO just landed and posted this here
Один из пулов недоступен. Утро начинается, начинаются звонки клиентов. Хорошее воскресенье :(
Ничего не известно на счет сроков восстановления?
Ничего не известно на счет сроков восстановления?
Если вначале говорилось о максимальном сроке 3 часа, то сейчас даже о времени молчат.
Рад, что отправился спать, а не продолжил сидеть, ожидая, когда произойдет чудо…
Рад, что отправился спать, а не продолжил сидеть, ожидая, когда произойдет чудо…
Я все на домашний сервер переношу. Похоже, дело серьезное.
Только что ответили на тикет:
«По предварительным оценкам специалистов, работы будут окончены в течении двух часов.»
«По предварительным оценкам специалистов, работы будут окончены в течении двух часов.»
у них рассылки массовые, по ходу ))
А вообще — обещали до 3 часов, уже 6 прошло и еще 2 часа хотят делать…
Эх, плохо в России со сроками
А вообще — обещали до 3 часов, уже 6 прошло и еще 2 часа хотят делать…
Эх, плохо в России со сроками
Саппорт не боги, они говорят то, что я или дежурный администратор сказали. Был момент, когда почти запустились, потом проблема повторилась. Пришлось идти на полный ресинк (~350 минут).
Отсюда и танцы со сроками.
Если бы у нас был детальный план предстоящей аварии, там бы первым пунктом было «отменить аварию».
Отсюда и танцы со сроками.
Если бы у нас был детальный план предстоящей аварии, там бы первым пунктом было «отменить аварию».
amarao, я вас прекрасно понимаю, но в таких ситуациях мы оказываемся меж двух огней: с одной стороны — пользователи, не получающие сервис, с другой — осознание, что у вас-то ситуация один в один такая же — разгневанные пользователи, не получающие сервис.
От этого и становится очень грустно.
От этого и становится очень грустно.
Дополняя тему — у них лежит приложение ВК, так что оплата хостинга голосами невозможна.
мою не затронуло, но управлялка не доступна.
А ведь самое обидное, как я понимаю, что инженеры селектела даже не могут злобный тикет накатать вендору, т.к. используют бесплатный гипервизор, а не коммерческое решение. Максимум — скромный багрепорт.
А ведь самое обидное, как я понимаю, что инженеры селектела даже не могут злобный тикет накатать вендору, т.к. используют бесплатный гипервизор, а не коммерческое решение. Максимум — скромный багрепорт.
(я не в позиции что-то доказывать, но) А чем «злобный тикет» будет отличаться от «скромного багрепорта» в контексте «поднять прямо сейчас?».
Временем реакции. При коммерческом решении с купленной техподдержкой время реакции строго регламентировано, и в течении N часов вендор должен дать ответ (если, конечно, не сэкономили и не купили классическую «next business day»)
Я так понимаю, у Selectel дописано столько всего своего, что вендор уже ничем не поможет.
Смотря где сбой. Мы, к сожалению, подробностей не знаем.
Если накрылась сто раз переписанная управляющая ИС — то да.
А если сбой в системах хранения данных, в FC-сети, в ядре гипервизора либо каких-нибудь других атомарных компонентах то оперативная поддержка вендора может быть очень кстати.
Если накрылась сто раз переписанная управляющая ИС — то да.
А если сбой в системах хранения данных, в FC-сети, в ядре гипервизора либо каких-нибудь других атомарных компонентах то оперативная поддержка вендора может быть очень кстати.
Сбой на уровне рейда (mdadm, raid10). При совмещении ресинка и IO «залипает» и перестаёт обслуживать любое IO.
Интересно потом будет почитать описание причин и методов исправления.
Мы натыкались на похожие грабли после замены одного HDD внутри рейда mdadm в условиях сильной нагрузки на I/O
Мы натыкались на похожие грабли после замены одного HDD внутри рейда mdadm в условиях сильной нагрузки на I/O
Кто в качестве SAS контроллера стоит?
Я такое видел на «интеллектуальных» контроллерах от HP, там под выскоим IO залипало напрочь. Решилось заменой контроллера.
Я такое видел на «интеллектуальных» контроллерах от HP, там под выскоим IO залипало напрочь. Решилось заменой контроллера.
LSI, но мы используем HBA, а рейды на базе mdadm. Судя по всему, либо HP использует внутри mdadm, либо у нас одинаковая проблема.
… Причём речь идёт не просто про высокое IO. Я перед запуском эту штуку в хвост и в гриву нагружал, довёл до 150мс avio при нагрузке в 4 раза выше планируемой. Проблема появилась при синхронном checking'е и IO.
… Причём речь идёт не просто про высокое IO. Я перед запуском эту штуку в хвост и в гриву нагружал, довёл до 150мс avio при нагрузке в 4 раза выше планируемой. Проблема появилась при синхронном checking'е и IO.
В контексте «поднять прямо сейчас» наверное, ничем, разве что SLA вендора подразумевает, что в таких случаях мчится на помощь закрепленный за заказчиком специалист вендора в течение часа.
А вот в контексте «это бага и ее надо починить, иначе будет вылезать периодически» очень даже. Если, например, эта бага мало проявляет себя (специфична для редких сочетаний софта-железа-конфигов-фазы луны), то в «бесплатном» багтрекере она будет болтаться месяцами, а то и годами. В случае коммерческого саппорта ее поправят в индивидуальном порядке с более высоким приоритетом.
А вот в контексте «это бага и ее надо починить, иначе будет вылезать периодически» очень даже. Если, например, эта бага мало проявляет себя (специфична для редких сочетаний софта-железа-конфигов-фазы луны), то в «бесплатном» багтрекере она будет болтаться месяцами, а то и годами. В случае коммерческого саппорта ее поправят в индивидуальном порядке с более высоким приоритетом.
Сказать честно — не верю. Мы имели дело с вендорами — и время эскалации проблемы «до программиста» занимает столько времени, что разницы с фиксом бага в багтрекере нет никакой (за горизонтом событий).
«мчится специалист», это спасибо. Можно даже не мчаться, а из дома, как я, например. Проблема в том, что баг, который мы нашли не может исправить человек на месте. Оно явно где-то в районе
притаилось.
С точки зрения прикрытия задницы — вендоры работают на ура. Вот сейчас я в дерьме и показать на крайнего некого. Был бы вендор — я был бы не при делах и можно было бы слёзно рассказывать про то, как квалифицированная поддержка Electronic Foobar Storage Systems (EFSS) буквально за час приехала, за три диагностировала, за час получила консультацию от HQ, но решение заняло ещё 5 часов на внедрение.
И типа они молодцы, и мы не виноваты.
То есть я никогда в жизни не поверю, что такого уровня баги могут исправляться кем-либо за единицы часов ночью.
Более того, тут ситуация ещё серьёзнее: Допустим, что EFSS'ое решение падает примерно таким же образом. Не важно что там — лицензия не туда загрузилась, в ферале оказалось 29 дней или БПР (будущий президент России) принял решение о переводе часового пояса на 3.141 часа влево… Так вот, если оно падает, то в случае с вендором мы должны сидеть и ждать.
В данном случае, когда степень и глубина той жопы, куда мы попали оказалась понятна, прорабатывалось два сценария — один с ребилдом (дождаться и посмотреть), второй — перевод СХД на резервные мощности в поштучном контролируемом режиме. При этом мы могли расковырять конструкцию до самых потрошков — до самого того raid10 внизу, с отключением кешей, кластеризации, управления томами и т.д. В худшем случае я мог поднять сильно другую версию дистрибутива и подцепить массив туда. То есть пути отступления были.
В случае с вендором мы не можем туды лазить и не знаем как оно устроено. При том, что у всех там внутри в итоге тривиальный рейд, разобрать конструкции над ним мы не можем. И это означает, что мы становимся на 100% зависимы от сообразительности сотрудника российской службы поддержки EFSS.
«мчится специалист», это спасибо. Можно даже не мчаться, а из дома, как я, например. Проблема в том, что баг, который мы нашли не может исправить человек на месте. Оно явно где-то в районе
amarao@x220:/media/media/git/linux/drivers/md$ wc -l raid10.c
3462 raid10.c
притаилось.
С точки зрения прикрытия задницы — вендоры работают на ура. Вот сейчас я в дерьме и показать на крайнего некого. Был бы вендор — я был бы не при делах и можно было бы слёзно рассказывать про то, как квалифицированная поддержка Electronic Foobar Storage Systems (EFSS) буквально за час приехала, за три диагностировала, за час получила консультацию от HQ, но решение заняло ещё 5 часов на внедрение.
И типа они молодцы, и мы не виноваты.
То есть я никогда в жизни не поверю, что такого уровня баги могут исправляться кем-либо за единицы часов ночью.
Более того, тут ситуация ещё серьёзнее: Допустим, что EFSS'ое решение падает примерно таким же образом. Не важно что там — лицензия не туда загрузилась, в ферале оказалось 29 дней или БПР (будущий президент России) принял решение о переводе часового пояса на 3.141 часа влево… Так вот, если оно падает, то в случае с вендором мы должны сидеть и ждать.
В данном случае, когда степень и глубина той жопы, куда мы попали оказалась понятна, прорабатывалось два сценария — один с ребилдом (дождаться и посмотреть), второй — перевод СХД на резервные мощности в поштучном контролируемом режиме. При этом мы могли расковырять конструкцию до самых потрошков — до самого того raid10 внизу, с отключением кешей, кластеризации, управления томами и т.д. В худшем случае я мог поднять сильно другую версию дистрибутива и подцепить массив туда. То есть пути отступления были.
В случае с вендором мы не можем туды лазить и не знаем как оно устроено. При том, что у всех там внутри в итоге тривиальный рейд, разобрать конструкции над ним мы не можем. И это означает, что мы становимся на 100% зависимы от сообразительности сотрудника российской службы поддержки EFSS.
Так и есть, если осознанно взяли риски на себя, то и отдуваться и разгребать говно/кишки придется полностью самостоятельно. Это два, как правило, не пересекающихся пути.
У меня же весьма много положительного опыта оперативного решения проблем вендорами, даже такими толстыми и неповоротливыми, как MS, Cisco, Checkpoint и т.п. Есть примеры, когда специалист MS реально ночевал у заказчика, всю ночь херача проблему и добиваясь результата к утру.
Про более мелких так вообще молчу (у них нет выбора, приходится бороться с гигантами за счет скорости и гибкости), от моих запросов на багфикс/фича-реквест до получения апдейта проходит порой неделя-две. Ну, это когда есть хорошие аргументы для ускорения, типа крупной поставки у данного заказчика.
У меня же весьма много положительного опыта оперативного решения проблем вендорами, даже такими толстыми и неповоротливыми, как MS, Cisco, Checkpoint и т.п. Есть примеры, когда специалист MS реально ночевал у заказчика, всю ночь херача проблему и добиваясь результата к утру.
Про более мелких так вообще молчу (у них нет выбора, приходится бороться с гигантами за счет скорости и гибкости), от моих запросов на багфикс/фича-реквест до получения апдейта проходит порой неделя-две. Ну, это когда есть хорошие аргументы для ускорения, типа крупной поставки у данного заказчика.
Ну, в реальности у нас пара вендоров на тесте стоит, но пока что по производительности оно просто рядом не ночевало (хотя товарищи клянутся, что всё быстро и хорошо в лаборатории и даже показывали).
С цисковцами у нас были серьёзные проблемы по реагированию. Настолько серьёзные, что мы выкинули их софт (речь про кино), и поставили опенсорсный с их железом работать.
ЗЫ Я и сам к 7 утра нашёл правильный вариант решения. Дальше там было только «ждать ресинка».
С цисковцами у нас были серьёзные проблемы по реагированию. Настолько серьёзные, что мы выкинули их софт (речь про кино), и поставили опенсорсный с их железом работать.
ЗЫ Я и сам к 7 утра нашёл правильный вариант решения. Дальше там было только «ждать ресинка».
Нда. Только я собрался к ним переезжать.
Пойду поищу хорошие зарубежные VPS.
Пойду поищу хорошие зарубежные VPS.
Как-то кажется, что у облачного хостинга больше потенциальных точек отказа.
Все относительно.
На шаред хостинге у меня просто тормозило постоянно. Не умирало раз в полгода, я ежедневно еле шевелилось.
На домашнем сервере хорошо — но зависимость от провайдера и электриков очень пугает.
А вот на облаке мне комфортно. И с какой то стороны даже хорошо, что если пиз***ся, то у всех и сразу. А саппорт будет круглосуточно чинить и починит! Цинично, но факт.
А в случае арендуемого выделенного сервера могут ваньку долго валять.
Вот по этой совокупности рассуждений я никуда и не уйду с облака. Ну и конечно, меня более чем устраивает цена и скорость. Бэкапы есть — развернуть свои сайты дома мне надо минут 15.
На шаред хостинге у меня просто тормозило постоянно. Не умирало раз в полгода, я ежедневно еле шевелилось.
На домашнем сервере хорошо — но зависимость от провайдера и электриков очень пугает.
А вот на облаке мне комфортно. И с какой то стороны даже хорошо, что если пиз***ся, то у всех и сразу. А саппорт будет круглосуточно чинить и починит! Цинично, но факт.
А в случае арендуемого выделенного сервера могут ваньку долго валять.
Вот по этой совокупности рассуждений я никуда и не уйду с облака. Ну и конечно, меня более чем устраивает цена и скорость. Бэкапы есть — развернуть свои сайты дома мне надо минут 15.
Правильный сценарий использования облака: распределённая система из нескольких поставщиков. Упал один узел? Нагрузка пошла на другого.
Унификация инфраструктуры (не смотря на то, что производители IaaS вяло об этом думают, но ничего не делают, уровень унификации Linux на разных IaaS очень велик — так что развёртывание довольно просто) позволяет не тратить особые усилия на каждый инстанс, а разворачивать его тривиально (apt-get packages, scp -r root@origin:/etc/foobar /etc/).
Это, кстати, касается всех сервисов. От почты до jabber'а.
Унификация инфраструктуры (не смотря на то, что производители IaaS вяло об этом думают, но ничего не делают, уровень унификации Linux на разных IaaS очень велик — так что развёртывание довольно просто) позволяет не тратить особые усилия на каждый инстанс, а разворачивать его тривиально (apt-get packages, scp -r root@origin:/etc/foobar /etc/).
Это, кстати, касается всех сервисов. От почты до jabber'а.
И вводим в систему ещё две потенциальных точки отказа — мониторинг и балансировщик/коммутатор, которые тоже надо где-то держать. А главное как-то обеспечить зеркалирование в реалтайме, чтобы резервный узел мог заменить основной прозрачно для пользователей, без потери совершенных ими транзакций.
Интересно, писать на Хабр из-за каждой несиправности у хостера — это нормально? Могли бы привыкнуть уже, что «облака» умеют «падать» :)
P.S. После изучения вопроса мне начинает казаться, что основная фишка «облака» — это предоставление ресурсов по мере необходимости, а не повышение надежности, как многие думают.
P.S. После изучения вопроса мне начинает казаться, что основная фишка «облака» — это предоставление ресурсов по мере необходимости, а не повышение надежности, как многие думают.
Безусловно, опрос про Сеть бросает вам вызов? гораздо полезнее.
Я исходил из мысли, что страдающим пользователям нужно место где обсудить проблему, иначе они заколебут техподдержку и решение вопроса затянется дольше, чем могло бы.
На мой взгляд, так и есть. Мощный сервер за смешные деньги.
Я исходил из мысли, что страдающим пользователям нужно место где обсудить проблему, иначе они заколебут техподдержку и решение вопроса затянется дольше, чем могло бы.
мне начинает казаться, что основная фишка «облака» — это предоставление ресурсов по мере необходимости
На мой взгляд, так и есть. Мощный сервер за смешные деньги.
Опрос он на то и опрос — я задал вопрос и получил интересующий меня ответ :)
Скорее не «мощный сервис за смешные деньги», а «90% времени нам не нужен мощный сервер, но иногда посетители набегают». «Облако» может оперативно выделить ресурсы и сгладить пик нагрузки, а в остальное время ресурсов потребляется меньше и оплата ниже (если тарификация по затратам процессорного времени).
Скорее не «мощный сервис за смешные деньги», а «90% времени нам не нужен мощный сервер, но иногда посетители набегают». «Облако» может оперативно выделить ресурсы и сгладить пик нагрузки, а в остальное время ресурсов потребляется меньше и оплата ниже (если тарификация по затратам процессорного времени).
Я так и не понял, уже можно поднимать машину обратно или еще могут что-то поломать в процессе починки?
Вчера вроде уже поднимали затронутые машины…
Вчера вроде уже поднимали затронутые машины…
Оно сразу обратно поломалось и с тех пор ничего особо не работает.
Лично у меня управление сервером просто отключено.
Лично у меня управление сервером просто отключено.
Разве основная крутость облака это не «зависимость от оборудования отдельных узлов»? А если мои машины в облаке падают также, как арендуемое железо или vps обычный, какой смысл в облаке?
Никто не придумал как сделать HA для хранилища.
HA подразумевает следующее «упали на одной железке, запустились на другой». И это работает для хостов виртуализации. Однако, никто не знает как это сделать для хранилища. Мы не можем запустить «на другом хранилище» (вас же интересуют данные со старого?) — и когда падает кластер, то мы не можем «просто воткнуть новый узел и продолжить работать».
HA подразумевает следующее «упали на одной железке, запустились на другой». И это работает для хостов виртуализации. Однако, никто не знает как это сделать для хранилища. Мы не можем запустить «на другом хранилище» (вас же интересуют данные со старого?) — и когда падает кластер, то мы не можем «просто воткнуть новый узел и продолжить работать».
Как это? В случае DRBD это решается с помощью 3-peer решения: primary / primary в режиме C как и раньше, и с него на hotspare делается drbd синк в режиме A/B.
www.drbd.org/users-guide-8.3/s-three-way-repl.html
www.drbd.org/users-guide-8.3/s-three-way-repl.html
я думаю яндекс и гугл смеются от таких слов (как и вендоры таких решений)
Последние следы аварии устранили.
Извините, люди.
Компенсация будет, завтра буду воевать за размер. Сейчас сделали так, чтобы ситуация не воспроизвелась. Решать по сути будем с максимальным приоритетом.
Ещё раз извините.
Извините, люди.
Компенсация будет, завтра буду воевать за размер. Сейчас сделали так, чтобы ситуация не воспроизвелась. Решать по сути будем с максимальным приоритетом.
Ещё раз извините.
У меня пинугется, но ничего не работает. Через панель консоль я не могу увидеть ни одним браузером.
Перезагрузка не помогает — что делать? Машина 8075
Перезагрузка не помогает — что делать? Машина 8075
Подробности сейчас напишу в тикет, если вкратце, на консоли ubuntu просит нажать 'F' для исправления ошибок на диске.
А можно узнать, как в итоге вылечили эффект? Просто ребилд последовательно?
Дали отсинкаться (отчекаться) без нагрузки, после этого заработало. resync шёл параллельно.
А вот, что говорят об уведомлениям по таким авариям:
habrahabr.ru/company/selectel/questions/775/
Не понял, при чем тут локальные проблемы о которых они не могут знать, если проблема была глобальной и об этом писали в админке (как на скриншоте в посте).
habrahabr.ru/company/selectel/questions/775/
Не понял, при чем тут локальные проблемы о которых они не могут знать, если проблема была глобальной и об этом писали в админке (как на скриншоте в посте).
Это явное совпадение: у человека ночью работала машина, да и надписи в панели он явно не видел.
Сбой был только на новом облаке, и то вроде, коснулся не всех машин.
P.S. Если я ничего не путаю — саппорт снаружи ему и не перемонтирует ничего в ro — это ж внутри ОС делается.
Сбой был только на новом облаке, и то вроде, коснулся не всех машин.
P.S. Если я ничего не путаю — саппорт снаружи ему и не перемонтирует ничего в ro — это ж внутри ОС делается.
У нас, к сожалению, нет системы targeting'а системного notice по пулам/хранилищам, так что пришлось писать всем, в том числе большинству клиентов, которых это совершенно не касалось (ну только периодически отключаемая панелька).
Моя виртуалка «сама» включилась ^_^
Итак, что произошло.
Если в кратце — по-очереди (с интервалом в 10 минут) остановились raid10 массивы на обоих серверах, обеспечивающих кластер хранилища. Поверх этих массивов у нас находится flashcache (кеширующий слой) и drbd, работающий по протоколу С (синхронный режим записи).
Система была настроена по следующему алгоритму: если падает одно из хранилищ, второе продолжает работать. Какое из хранилищ живо, какое нет, определяется с помощью multipathd на хостах виртуализации.
Базовые тесты, которые мы прогоняли перед запуском включали в себя: падение одного из узлов (crash), потерю питания, вынимание (смерть) большего числа дисков, чем может пережить raid10, смерть рейда кеширующих ssd (тоже raid10), случайный админ, набравший 'reboot', вынимание сетевого кабеля и его «тыкание» туда/обратно (защита от split brain). Все эти тесты прошли и у (меня) была уверенность, что система достаточно живучая для наших нужд.
В эту ночь запустился обычный raid checking. Невинный процесс, который в фоновом режиме проверяет целостность рейдов. Хранилища в первом пуле и сейчас продолжают потихоньку этот процесс (около 2-5мб/с). Модуль ядра, выполняющий проверку, следит, чтобы latency не сильно возрастало, так что клиенты в нормальном режиме этого процесса замечать не должны.
Однако, возникла проблема (наша текущая гипотеза — баг в модуле ядра) — и наличие агрессивного IO (около 25 IOPS на каждый диск массива) одновременно с процессом проверки привело к остановке IO на массиве. Полностью. Настолько, что dd if=/dev/md10 of=/dev/null bs=512 count=1 просто «зависал». При этом со всех нижележащих дисков чтение напрямую было успешным и происходило на нормальной скорости. Это привело к тому, что iscsi target (а вслед за ними все остальные в цепочке) на io не получали ни успеха, ни ответа. Дополнительно ситуация осложнялась тем, что обычный «проверяльщик» multipath проверяет первые 512 байт диска на читаемость. Догадайтесь, были ли эти 512 байт кешированы в flashcache или нет… Ещё ситуацию запутывало то, что часть запросов (тех, кто был в ssd-кеше) обслуживалась нормально, и некоторое время запросы на запись тоже приходили без проблем. В какой-то момент кеш ssd переполнялся и возникала проблема с его скидыванием. Из-за синхронного режима drbd остановка (не ошибка, а именно остановка) привела к остановке обоих пиров. В теории проблему можно было решить всего лишь отключив «больного» пира (что мы и сделали в начале). Это помогло ненадолго, после чего проблема повторилась на втором (что ещё раз говорит о проблеме в модуле ядра, а не в железе). Именно в этот момент большинство клиентов заметило проблему. Поскольку запись была полностью парализована, мы не могли вернуть на место предыдущий пир, который поднялся к этому времени (и продолжил проверять диск как ни в чём ни бывало). Произошёл первый «глобальный ребут». У нас примерная скорость подъёма машин составляет примерно 2-3с на машину (машина стартует дольше, операция старта идёт в параллель). Где-то на 300 машинах скорость синхронизации начала стремительно падать (на самом деле она уже была 0, а «уменьшение среднего» было лишь случайным эффектом). Почти синхронно проблема повторилась на втором пире (который к этому времени тоже был перезагружен). Было принято решение попробовать обновить ядро, ситуацию это не исправило. Начали рисоваться планы «ручного восстановления». В это время мой помощник предложил «дать доребилдиться». Дали (350 минут). За это время я успел даже чуть вздремнуть (т.к. время уже подползло к 7 утра). На всякий случай — речь идёт не про «ребилд» в случае выхода диска из строя, а «ежемесячной» проверке живости всех дисков массива. Этот процесс шёл на всех 10ых рейдах, из которых собрано хранилище (на обоих хранилищах сразу) со скоростью примерно 200-250Мб/с.
К часу дня процесс закончился, ещё 10 минут занял ручной подъём обвязки кластера, ещё 5 минут перезагрузка пула (поскольку пострадали все машины во втором пуле, то не было смысла вручную исправлять и разбираться с мнением multipathd о том, кто жив, кто нет). Начался запуск. К 2 часам дня старт закончился и начался ручной разбор разного рода fsck, просящих нажать кнопочку на экране.
Выводы и принятые меры.
1) Как локальное решение «на ближайшие дни» — запрещён запуск resync рейдов.
2) В ближайшее время будет предусмотрен сценарий «не работает, но не сообщает об ошибке» для raid'а (и других блочных устройств в стеке — flashcache, lvm, drbd и т.д.)
3) Параллельно будет построен эквивалентный (дисков будет меньше и без SSD) стенд, где мы попытаемся воспроизвести ситуацию и заняться поиском конфигурации, в которой она не проявляется. Текущее наше предположение, raid0 поверх raid1 не должен себя так вести.
4) Заслать багрепорт (если п.3 будет успешным).
Извинения:
Виноваты. Мы понимаем, что так делать нельзя и приложим все усилия для исправления ситуации.
Компенсации:
В качестве компенсации принято решение вернуть 100% средств, потраченных на пострадавшие виртуальные машины.
Если в кратце — по-очереди (с интервалом в 10 минут) остановились raid10 массивы на обоих серверах, обеспечивающих кластер хранилища. Поверх этих массивов у нас находится flashcache (кеширующий слой) и drbd, работающий по протоколу С (синхронный режим записи).
Система была настроена по следующему алгоритму: если падает одно из хранилищ, второе продолжает работать. Какое из хранилищ живо, какое нет, определяется с помощью multipathd на хостах виртуализации.
Базовые тесты, которые мы прогоняли перед запуском включали в себя: падение одного из узлов (crash), потерю питания, вынимание (смерть) большего числа дисков, чем может пережить raid10, смерть рейда кеширующих ssd (тоже raid10), случайный админ, набравший 'reboot', вынимание сетевого кабеля и его «тыкание» туда/обратно (защита от split brain). Все эти тесты прошли и у (меня) была уверенность, что система достаточно живучая для наших нужд.
В эту ночь запустился обычный raid checking. Невинный процесс, который в фоновом режиме проверяет целостность рейдов. Хранилища в первом пуле и сейчас продолжают потихоньку этот процесс (около 2-5мб/с). Модуль ядра, выполняющий проверку, следит, чтобы latency не сильно возрастало, так что клиенты в нормальном режиме этого процесса замечать не должны.
Однако, возникла проблема (наша текущая гипотеза — баг в модуле ядра) — и наличие агрессивного IO (около 25 IOPS на каждый диск массива) одновременно с процессом проверки привело к остановке IO на массиве. Полностью. Настолько, что dd if=/dev/md10 of=/dev/null bs=512 count=1 просто «зависал». При этом со всех нижележащих дисков чтение напрямую было успешным и происходило на нормальной скорости. Это привело к тому, что iscsi target (а вслед за ними все остальные в цепочке) на io не получали ни успеха, ни ответа. Дополнительно ситуация осложнялась тем, что обычный «проверяльщик» multipath проверяет первые 512 байт диска на читаемость. Догадайтесь, были ли эти 512 байт кешированы в flashcache или нет… Ещё ситуацию запутывало то, что часть запросов (тех, кто был в ssd-кеше) обслуживалась нормально, и некоторое время запросы на запись тоже приходили без проблем. В какой-то момент кеш ssd переполнялся и возникала проблема с его скидыванием. Из-за синхронного режима drbd остановка (не ошибка, а именно остановка) привела к остановке обоих пиров. В теории проблему можно было решить всего лишь отключив «больного» пира (что мы и сделали в начале). Это помогло ненадолго, после чего проблема повторилась на втором (что ещё раз говорит о проблеме в модуле ядра, а не в железе). Именно в этот момент большинство клиентов заметило проблему. Поскольку запись была полностью парализована, мы не могли вернуть на место предыдущий пир, который поднялся к этому времени (и продолжил проверять диск как ни в чём ни бывало). Произошёл первый «глобальный ребут». У нас примерная скорость подъёма машин составляет примерно 2-3с на машину (машина стартует дольше, операция старта идёт в параллель). Где-то на 300 машинах скорость синхронизации начала стремительно падать (на самом деле она уже была 0, а «уменьшение среднего» было лишь случайным эффектом). Почти синхронно проблема повторилась на втором пире (который к этому времени тоже был перезагружен). Было принято решение попробовать обновить ядро, ситуацию это не исправило. Начали рисоваться планы «ручного восстановления». В это время мой помощник предложил «дать доребилдиться». Дали (350 минут). За это время я успел даже чуть вздремнуть (т.к. время уже подползло к 7 утра). На всякий случай — речь идёт не про «ребилд» в случае выхода диска из строя, а «ежемесячной» проверке живости всех дисков массива. Этот процесс шёл на всех 10ых рейдах, из которых собрано хранилище (на обоих хранилищах сразу) со скоростью примерно 200-250Мб/с.
К часу дня процесс закончился, ещё 10 минут занял ручной подъём обвязки кластера, ещё 5 минут перезагрузка пула (поскольку пострадали все машины во втором пуле, то не было смысла вручную исправлять и разбираться с мнением multipathd о том, кто жив, кто нет). Начался запуск. К 2 часам дня старт закончился и начался ручной разбор разного рода fsck, просящих нажать кнопочку на экране.
Выводы и принятые меры.
1) Как локальное решение «на ближайшие дни» — запрещён запуск resync рейдов.
2) В ближайшее время будет предусмотрен сценарий «не работает, но не сообщает об ошибке» для raid'а (и других блочных устройств в стеке — flashcache, lvm, drbd и т.д.)
3) Параллельно будет построен эквивалентный (дисков будет меньше и без SSD) стенд, где мы попытаемся воспроизвести ситуацию и заняться поиском конфигурации, в которой она не проявляется. Текущее наше предположение, raid0 поверх raid1 не должен себя так вести.
4) Заслать багрепорт (если п.3 будет успешным).
Извинения:
Виноваты. Мы понимаем, что так делать нельзя и приложим все усилия для исправления ситуации.
Компенсации:
В качестве компенсации принято решение вернуть 100% средств, потраченных на пострадавшие виртуальные машины.
Вопрос. А почему проверка ребилда запускается синхронно на нодах?
Мне кажется логичным, что её лучше делать циклически — нода A закончила проверку, запускать на ноде B.
Мне кажется логичным, что её лучше делать циклически — нода A закончила проверку, запускать на ноде B.
Раньше никто об этой проблеме не задумывался — даже на самых загруженных наших хранилищах запуск проверки не добавлял больше 1мс к latency. И тут не должен был, если бы не внезапный «стоп операций».
Спасибо за подробный рассказ.
Учитывая то, что у меня в продуктиве крутится подобная схема на mdadm (правда, без flashcache. К своему стыду, первый раз об этой технологии услышал) стало как-то не по себе. Хотя очень надеюсь что используемое у меня решение мультипачинга на основе multibus не даст полного отказа в обслуживании в случае залипания одного хранилища.
Надеюсь, если баг в реализации raid10 подтвердится, разработчикам улетит баг-репорт?
Учитывая то, что у меня в продуктиве крутится подобная схема на mdadm (правда, без flashcache. К своему стыду, первый раз об этой технологии услышал) стало как-то не по себе. Хотя очень надеюсь что используемое у меня решение мультипачинга на основе multibus не даст полного отказа в обслуживании в случае залипания одного хранилища.
Надеюсь, если баг в реализации raid10 подтвердится, разработчикам улетит баг-репорт?
«Текущее наше предположение, raid0 поверх raid1 не должен себя так вести.» — не факт.
Ловил похожие грабли на простом raid1 на 2.6.35-2-pve (практически дефолтный сетап Proxmox 1.9/kvm), тяжелое IO в виртуалках и запустившийся по крону на хосте процесс проверки рейда — и те же симптомы.
Ловил похожие грабли на простом raid1 на 2.6.35-2-pve (практически дефолтный сетап Proxmox 1.9/kvm), тяжелое IO в виртуалках и запустившийся по крону на хосте процесс проверки рейда — и те же симптомы.
Меня снова не зацепило…
Uptime виртуалки дошел до 128 дней.
Uptime виртуалки дошел до 128 дней.
Вас и не могло зацепить.
Проблема в новом облаке, которое открыли 13 февраля.
Судя по вашему аптайму — вы на него не переехали.
Проблема в новом облаке, которое открыли 13 февраля.
Судя по вашему аптайму — вы на него не переехали.
Что за рейд у вас такой?
Либо я такой дурак, либо лыжи опять не едут…
Ещё не закончился месяц, а у Селектел новая авария. На этот раз лежат сервера и на новом и на старом облаке.
Sign up to leave a comment.
У Selectel авария