Пользователь
28 марта 2012 в 13:20

Очередная авария у Selectel

Пост создан для информации, т.к. На Хабре не нашел подробностей аварии.

Не так давно пришел тикет от Селектел о профилактике на кластере хранилища:

28 марта 2012 c 8:00 до 11:00 планируется проведение профилактических работ на одном из узлов кластера хранилища. На этом хранилище находится один или неколько дисков ваших виртуальных машин. Узнать, какие виртуальные машины будут затронуты работой, можно по uuid SR в свойствах дисков. Работы будут проходить на SR 409127d3-61a1-9c8d-ceb5-486c608c58aa.

В течение работ перерыва не планируется, однако отказоустойчивость может быть снижена.

Приносим извинения за беспокойство.


В результате сегодня сервера облака не работают. Тех поддержка молчала до последнего. И вот наконец, долгожданные новости:

Произошел сбой на одном из хранилищ.
В данный момент, наши специалисты работают над устранением неисправности.
К сожалению, точные сроки решения, пока не известны, вероятнее всего подъём займёт порядка 5 часов.
Данные на виртуальных машинах не пострадают, в худшем случае — откат на 10 минут (консистентный).
Приносим извинения за доставленные неудобства.


На данный момент управление серверами облака, которые на этом SR не доступно. Висит заглушка «Восстановление в пуле Санкт-Петербург (2) в течение 3х часов.»

UPD 13:21 (GMT+2) :
Исчезло уведомление о работах, но машину запустить не удается. Тех.поддержка говорит:

Процесс востановления продолжается, предполагаемое время окончания, чуть больше часа.
Дмитрий Лялюев @silvergh0st
карма
20,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (75)

  • +3
    Та же проблема с прекращением работы raid10 в linux. В ближайшее время предоставим всем клиентам возможность вернуться на старую конфигурацию СХД.

    (я всё ещё работаю над проблемой, подробности позже).
    • 0
      Случаем не «raid10_make_request bug: can't convert block across chunks or bigger than ...»?
      • +1
        нет.

        Пока рабочее предположение — raid1/10 deadlock, который поправили в коммите
        d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf (после 3.3)

        md/raid1,raid10: avoid deadlock during resync/recovery.
            
            If RAID1 or RAID10 is used under LVM or some other stacking
            block device, it is possible to enter a deadlock during
            resync or recovery.
            This can happen if the upper level block device creates
            two requests to the RAID1 or RAID10.  The first request gets
            processed, blocks recovery and queue requests for underlying
            requests in current->bio_list.  A resync request then starts
            which will wait for those requests and block new IO.
            
            But then the second request to the RAID1/10 will be attempted
            and it cannot progress until the resync request completes,
            which cannot progress until the underlying device requests complete,
            which are on a queue behind that second request.
            
            So allow that second request to proceed even though there is
            a resync request about to start.
            
            This is suitable for any -stable kernel.
        


        Но я не могу воспроизвести проблему в лаборатории (сейчас уже делаем 6к IOPS на полигоне, и ситуация не воспроизводится), так что проверить, «оно или нет» пока не могу.

        • 0
          Понятно. Описанная мною проблема намного веселее :(

          По поводу лаборатории: вспомните книги Вадима Зеланда и перестаньте придавать факту воспроизведения бага важность :)) Тогда он сразу выстрелит!
          • 0
            Он уже дважды выстрелил, и до момента, пока я не буду уверен, что это действительно исправляет проблему, я не буду трогать СХД. Известно, что в отсутствие синка оно работает стабильно, значит синка/рекавери в момент работы в кластере не будет.
  • +14
    Ну ребята!

    Что то вы зачастили.
    • +2
      Ровно та же проблема. После восстановления все диски машин будут перенесены. Я отчаялся решить проблему в доступных версиях ядра.
      • 0
        Беда.

        Я всем вас советую, даже несколько машин людям настроил (фактически, привел клиентов за ручку) — а теперь такая фигня.

        Надеюсь, это последний сбой в текущем году.
      • 0
        Означает ли это, что делать в ваших виртуалках RAID'ы типа mirror для резервирования практически бессмысленно? Сижу в старом пуле.
        • +4
          После аварии всем желающим будет предложено перенести диски на некластеризованное хранилище, аналогичное используемому в первом пуле.

          Что с этим делать пока не знаю, следующая попытка перевода с raid10 на комбинацию raid1 + 0 (это не одно и то же).

          В долгосрочной перспективе мы будем искать варианты принципиального решения проблемы (проприентарные решения, смена схемы построения массивов и т.д.).

          Врят ли кого-то это утешит, но подобные аварии нам крайне болезенны, т.к. мы несём одновременно имиджевые, прямые денежные (компенсации), косвенные денежные (недопоставленные услуги) и ресурсные (время специалистов на устранение) потери. Соответственно, мы приложим все усилия для устранения подобного.
          • 0
            Что с этим делать пока не знаю, следующая попытка перевода с raid10 на комбинацию raid1 + 0 (это не одно и то же).

            Как так? Знаю 1+0, знаю 0+1, но это подмножества RAID10, а не отдельные типы массивов.
            • 0
              raid10 — это отдельный модуль ядра linux, который работает несколько иначе чем совокупность модулей raid1+ raid0
            • 0
              Логически — нет. Фактически — разный код, разный модуль ядра, и даже разное поведение. с raid10 чтение идёт со всех копий, а с raid1 — только с одной (со второй копии читается только в случае аварии).
              • 0
                Тоесть чередование (как в некоторых реализациях) при чтении в raid1 не задействовано?
                • 0
                  Не задействовано, т.к. это не является задачей raid'а. А вот странная конфигурация raid10 из двух дисков (которая по надёжности есть быть обычный raid1) будет читать.
  • 0
    Блин, долго и упорно переносил ресурсы с Мастерхоста, теперь тут тоже самое, что ж за фигня такая( А по башке в итоге я получаю, потому что выбрал «плохой» хостинг.

    Какая-то компенсация будет? У меня 2 действующих интернет-магазина лежат сегодня.
    • +1
      В прошлый раз вернули все деньги, потраченные на новом облаке.
      • 0
        Это прекрасно, только компания теряет не только деньги, что потрачены на самом хостинг, но и клиентов.
        • 0
          Да кто ж спорит? Я вообще не в курсе, будет ли в этот раз компенсация.

          А серьезной компании, у которой 2 интернет-магазина нужно иметь план «Б» на такой случай.
          Чтобы за полчаса продолжить работу на резервном хостинге.

          Это не трудно автоматизировать.
          • 0
            компенсация будет. Вероятнее всего, уже в апреле (на следующей неделе). Точный размер зависит от того, сколько займёт времени оставшаяся часть восстановления.

            (Единственным плюсом ситуации является то, что flashcache полностью сохранил содержимое кеша, т.е. никаких потерь данных не планируется — будет эквивалент «принудительного отлкючения» для виртуальной машины).
          • 0
            Подскажите как автоматизировать? Или даже не автоматизировать а быстро переключиться?
            Допустим есть у меня копия сайта, но днс ведь может и больше чем пол часа обновляться
            • 0
              alias запись по идее до часа должна меняться…
            • +2
              Если меняется только A запись, а не NS сервер, выставить TTL в 5 минут, DNS обычно обновляется в течении 10ти минут.
            • 0
              Идеальный вариант, на мой взгляд — делать все автоматически. Проверять каждые 15 минут сервер, и если он не откликается — запускать скрипт распаковки бэкапов на резервном сервере и сразу переключать записи ДНС.
              У меня обновление происходит 10-30 минут, обычно. Вот тут говорят, что можно сразу все прописать через SRV и будет типа ДНС балансировка. Не проверял, не знаю.

              Понятно, что свежие бэкапы должны всегда быть. А резервный сервер можно даже выключать, когда не нужен (и не платить за него, соответственно, если мы про облака).

              Я не серьезная компания, поэтому сделал бы вот так, просто bash скриптами.

              А серьезные компании могут и железный балансировщик поставить, и вообще держать 2 сервера одинаковых на разных площадках. На эту тему информации навалом.
              • 0
                *вопрос
                А если указать у домена 4 ns записи (по 2 на хостера), при стабильной работе первой площадки на второй домен не привязан, когда падает первая привязываю домен ко второй, поднимаю всё из бэкапа и по логике имею рабочий сайт. Или я не прав?
                • 0
                  Так будет гораздо дольше.

                  Получается смена NS сервера домена, а это будет обновляться в течении суток. Однозначно не вариант.

                  Либо балансировка (разной степени сложности), либо быстро переключаем и ждем обновления.
                  • 0
                    Сорри, понял ошибку. Спасибо за инфу.
                  • 0
                    Почему сутки то?? От TTL зависит. Можно и за 10 минут менять NS и принимать посетителей на новый сервер.
                    • 0
                      Это не смена А записи. Это смена NS сервера.

                      Обычно это долго.
            • 0
              Можно пользоваться cloudflare, там смена сервера происходит очень быстро, достаточно указать новые данные и все.
              Плюс это вообще можно автоматизировать с помощью ddclient.
        • +1
          И будет продолжать терять клиентов, пока не обеспечит резервирование…
          • +2
            Именно из-за резервирования мы сейчас и столкнулись с этой проблемой. Ошибка возникает синхронно (лаг в 20 минут) на обоих узлах кластера.

            Ошибка ровно так же: /dev/md100 не исполняет запросы и не возвращает ошибки. Составляющие его диски работают без проблем. Текущее подозрение — проблемы в raid10 (модуле).
            • 0
              Я имел в виду резервирование как писали комментом выше — с возможностью переключиться на другой ДЦ. Если цена простоя действительно высока — то чего уж мелочиться…
              • +2
                Никто не умеет переключать хранилища между ДЦ. Проблема в СХД, а не в хостах виртуализации. Виртуалки между ДЦ гонять — никаких особых проблем. Проблема в репликации дисков. А текущая проблема: кластер (в котором репликация) даёт сбой почти синхронно в определённых ситуациях.
                • +1
                  Мы про то, чтобы в случае аварии продолжить работу вообще на другом хостинге с минимальными потерями.

                  Чтобы бэкапы были под рукой, скрипты для разворачивания, обновления, и т.д.

                  Если бизнес серьезный — такие вещи должны быть предусмотрены и продуманы. Даже я свои микросайты бэкаплю и сохраняю за пределами хостинга — ни на кого не надеюсь.

                  P.S. И вообще, не отвлекайтесь на нашу болтовню — работать надо!
                  • 0
                    Мне ещё пол-часа ждать окончания синка. Основная проблема именно в этом — проблема проявляется при наличии resync/checking, его невозможно отменить (стандартны idle и т.д. не работают), а появление нагрузки параллельно с ним приводит к описанной проблеме.

                    Если бы не это, то ребут узла бы никто и не заметил, в крайнем случае даунтайм на 10 минут.

                    Пока эта сволочь не досинкается, я не могу поднимать iscsi.
                    • 0
                      Как там синк? Пол-часа вроде бы прошли)
                      • +2
                        Ребут, работаю. Теперь занят.
                      • 0
                        Запускаем машины, примерно 30% запущено. Панельку откроем, как только закончится очередь.
                        • 0
                          Есть такое дело: «Машины запускаются. Панель управления отключена на время для исключения гонки условий.»
                          • 0
                            У меня та же надпись, но машина доступна уже по ssh.
                            • 0
                              Надпись вешается вручную, чтобы посторонние запросы не замедляли процесс запуска.
                • 0
                  NetApp в прошлом году хвалился насчет cross-site replication with FT
                  • 0
                    Понимаете, тут есть важный момент:

                    если у меня падает узел, то я просто ввожу в строй другой такой же и он продолжает исполнять машину.

                    А с сторами нельзя «другой такой же». Надо именно этот. Это означает, что если у нетаппа (я не клевещу, я просто предполагаю) случится бага в кластерном софте, которая затронет все узлы кластера, то они упадут ровно так же одновременно. И их нельзя будет заменить «другими».

                    В этом вся и драма. Когда у нас на одной из нод закозлил процессор (да, такое тоже бывает), даунтайм в 5 минут заметило 4 человека из 45. Просто потому, что ноду заменили и продолжили работу. А вот стор «взять и заменить» можно, только клиенты не одобрят.
                  • 0
                    да, я тоже сразу про это вспомнил
        • 0
          Как бы это меркантильно не звучало, но потеря клиентов интернет-магазина ввиду лежащего хостинга — не вина хостера. Факапы бывают абсолютно у всех, это нужно всегда учитывать. И не перекладывать свою ответственность перед клиентами на вышестоящего поставщика услуг
    • 0
      Аналогично. 2 моих инет магазина лежат, плюс сайты заказчиков.
      Мозг съедают. :(
  • +3
    Хорошо, что я оставил сервер в старом пуле…
    • 0
      Как это сделать? :) Как-то не задумывался, а сейчас вот пришлось(
      • 0
        Просто не удалял давно созданный, до «Санкт-Петербург (2)», сервер.
      • 0
        Нужно было создать машину до 17 октября 2011, и после запуска нового облака — не переходить на него.
        • 0
          Увы… не успел…
          • +1
            Не переживайте.

            Щас починят и дадут возможность перенести диски в старое хранилище.
            • 0
              Ждем-с…
        • +1
          А я дурак, перешел на новый пул и старую машину удалил.
          Заманили снапшотами =(
          • 0
            Не люблю сам себя ругать, но в старом пуле от аварий прошлого года ничего не защищает — просто стабилизировавшася конфигурация. А авария на СХД старого вида может приводить потенциально к потери части данных, бывших «в пути» на запись. В новой конфигурации такого не может быть (ок, не буду категоричным, таких мест не планировалось).

            В течение пары дней я подготовлю и протестирую СХД старого образца и предоставлю всем желающим возможность перенести на неё диски.
            • +1
              Да я понимаю… Облако — сложная гигантская система, и вам большое спасибо за проектирование и поддержку этого монстра. Лично для меня это единственный разумный вариант (финансы не позволяют держать реальные железки, а шаред-хостинги я уже забыл как страшный сон).

              Просто поспешил я сносить свою тачку со старого пула. Обратно переносить уже не буду, даже если будет возможность. Буду надеятся, что в новом пуле все исправите =)
  • +7
    Кредит доверия исчерпан практически полностью.
    • 0
      Практически?
      • 0
        Если бы amarao не объяснял тут, что случилось и какие шаги к исправлению ситуации они делают, то слово «практически» не было бы. Но в любом случае, завтра состоится серьезный разговор, что делать дальше.
  • +8
    Почему многие думают, что размещение сайта в облаке позволяет забыть об отказоустойчивости на уровне своего приложения. Если сайт для бизнеса критичен, то будте добры держать резервную копию ресурса с лагом 5 -10 минут, а не надеятся что облако никогда не упадет.
    • +4
      Абсолюто верно. Именно так я всегда стараюсь настраивать работу клиентам для более-менее важных сайтов.
      2-й дублирующий VPS в другом датацентре/городе/стране. Для синхронной репликации мастер-мастер MySQL — использую Galera или Tungsten + раз в 5 мин. rsync ФС на контент, конфиги, внетреннюю панель управления, etc… + TTL 1-5 мин. на A-type запись в DNS для доменов для оперативной (5-10 мин.) смены IP-адреса сайтов в случае необходимости. Дополнительно можно использовать 3-й VPS в качестве frontend-а c минимальными ресурсами (от 256Mb RAM) для балансировки/авто-переключения между серверами (nginx).
      Для контента можно вобще использовать распределенную ФС GlusterFS, но в этом случае получим заментое снижение производительности сайтов с большим к-вом мелких файлов, поэтому rsync раз в 5 мин. на контент сайта вполне достаточно. В итоге получаем отказоустойчивую платформу для хостинга сайта/сайтов из 2х-3х VPS в рагдных датацентрах. Round-robin DNS балансировку не желательно использовать, т.к. в случае падения одного из серверов, запросы будут продолжать поступать на не рабочий сервер. Таким образом, в случае падения основного сервера, веб-проекты продолжат работу на резервном VPS в течении 5-10 мин., а после возобновления нормальной работы основного сервера, сайты могут быть переключены обратно на основной сервер без потери данных, т.к. MySQL базы и контент на основном сервере засинхронизируются с резервного, после восстановления нормальной работы основного сервера. Если что, могу подсказать в ЛС или тут.
  • 0
    Почему, так, много, людей, ставят, так, много, лишних, запятых? :(
    • +6
      Потому что некоторые не ставят их вовсе. Закон сохранения запятых в русски языка.
  • +1
    У меня машина поднялась и работает как ни в чем не бывало.
    • +5
      Именно ради этого (не ради аварий… м...) делалась новая система — там никакие данные не теряются — они либо сохраняются на основной массив, либо на диск. Никаких «battery backed up» хардварных рейдов — по этой причине поднялось 100% затронутых аварией машин.

      Хотя это не извиняет сам факт аварий.
  • +3
    Спасибо, что подняли!!!
  • +10
    Отчёт о произошедшем:

    После прошлой аварии был найден баг в ядрах 3.1/3.2 (и подтверждён в 3.3), приводящий к падению хоста в следующей конфигурации:

    raid10 (минимум 4 диска)
    в цикле hdparm -y на два диска из этого массива
    какая-то дисковая активность на raid.

    После того как ошибка была подтверждена было принято решение о даунгрейде на 3.0 (в которой этой ошибки нет).

    В ходе даунгрейда (8:00-10:30) один хост был успешно переведён на 3.0. Тогда же была обнаружены проблемы с диском в одном из массивов (io error, pending sectors). Диск был заменён, начался ребилд.

    (всё это время клиентов обслуживала оставшаяся половинка)

    Узел был введён в кластер, но без обслуживания клиентов (в secondary режиме).

    Примерно в 11, после перехода drbd в UpToDate/UpToDate режима, оставшийся (необновлённый и планируемый к обновлению) узел показал тот самый трейс, который и планировалось устранить.

    Обслуживание клиентов переключилось на вторую половинку (обновлённую).

    В 11:15 мы столкнулись с багом (описание ниже), который, как выяснилось, был отличен от бага с падением машины, который привёл к прекращению работы raid10 на первой половинке кластера. Вторая половинка кластера в этот момент начала checking после перезагрузки (о проблемах от этого — в описании бага).

    Для решения проблемы пришлось перезагрузить хранилища, дождаться завершения rebuild/checking (самая долгая часть) и скинуть содержимое кеша (raid на SSD) на диски. После этого (примерно 16:10) начался запуск машин. К 16:30 запуск закончился. По нашим данным (за вычетом даунтайма) повреждений данных у машин не было, запустилось и работает 100% из них (возможно кому-то надо будет на консоли согласиться с запуском fsck).

    Теперь главное — что за баг?

    к сожалению, воспроизвести его в лаборатории нам не удалось (сейчас мы полностью воссоздаём весь стек устройств и точную конфигурацию и будем её мучить, чтобы достоверно поймать проблему).

    Симптомы:
    При запуске любых асинхронных операций mdadm (checking, resync) и наличии нагрузки raid10 прекращает обслуживать запросы. Это выглядит следующим образом:
    dd if=/dev/md2 of=/dev/null bs=512 count=1 iflag=direct
    просто не завершается.

    Ровно так же не завершаются все остальные запросы (от iscsi target и других компонент). Все диски, из которых состоит raid10 прекрасно работают и не показывают снижения скорости.

    Я не могу сейчас сказать условия возникновения этой проблемы, но точно могу сказать, что она воспроизводится гарантированно.

    В настоящий момент мы запретили любые самостоятельные операции raid10, подняли оба узла.

    Косвенной причиной сбоя стали профилактические работы, настоящей — неожиданная ошибка в работе raid10 (вместо того, чтобы из нескольких ненадёжных дисков сделать надёжный массив, он из нескольких надёжных дисков сделал шути-что).

    Наши меры: воспроизведение ошибки в лаборатории, изучение условий возникновения, поиск решения. В течение этого времени — сохранение статуса кво без каких-либо манипуляций над СХД, которые могут привести к запуску проверки массивов.

    Дальнейшие меры — если нам удастся локализовать и исправить ошибку, исправить её. Если нет — поиск альтернативных решений.

    Компенсация за простой машин будет предоставлена на следующей неделе.

    • 0
      Пока неясно — оно аффектит на уровне mdadm или из-за iscsi?
      • 0
        raid10 используется как PV для LVM, потом там в перемешку drbd, flashcache… До iscsi там как до луны. Проблема фокусируется на уровне (названия условные):

        md2 sda[1], sdb[2], sdc[3], sdd[4]

        md2 — не принимает и не отправляет запросы.
        sda, sdb, sdc, sdd, по-очереди и одновременно (это я ещё в прошлый раз проверил) работают с нормальной соростью.

        Интригу добавляет то, что у raid10 НЕТ queue. Другими словами, это не «застряло в очереди», это «застряло на этапе определения куда передать» или «этапе передачи».
        • 0
          Ок, попробуем у себя воспроизвести. По крайней мере если это в mdadm или pv, то точно нас аффектит. Благо, пока на 3.0 остались.
          • 0
            Ужас в том, что второй баг воспроизвёлся именно на 3.0. И это вопроизводилось достаточно много раз, чтобы говорить про совершенно точный сценарий.

            Прошлый раз я поднял всё с 5ой попытки (пока разбирался что это такое), в этот — с первой. И теперь я на 100% уверен в условиях вопроизведения (resync + activity). Другое дело, что я не знаю, какие именно моменты конфигурации к этому приводят…

            И баг с падением ядра был так точно воспроизводим, что мы (я) поверили, что это «он и есть». А баг совсем другой (dd + hdparm), и он не проявлялся на 3.0, что сегодня утром у меня не было сомнений в методе решения…
    • 0
      Неужели разработчики ядра Linux не стресс-тестируют свои решения на отладочных подсистемах, имитирующих разнообразные сбои? Вопрос риторический. Но все-таки. Тема интересная, уж извините.

      Ваша конфигурация не уникальная, а более-менее типична, как понимаю.

      Отчего им (разработчикам) не собрать стенд, на котором стоит «поддельный диск», который постоянно имитирует разные ошибки ввода/вывода?

      Ведь, очевидно, что, если они проверяют свои системы ввода/вывода в «обычных» условиях, то есть, грубо говоря, без интенсивной имитации сбоев, то это все равно, что и не проверять их вовсе. Это все равно что проверять программы архивации, отключив сжатие.

      Сделали какую-то оптимизацию. Запустили — вроде работает. _Пока нет ошибок ввода-вывода_.

      Знаю, что разработчики SQLITE используют специальную тестовую файловую систему, которая имитирует всевозможные сбои. И (гордо) заверяют, что тесты настолько жестокие, что позволяют им гарантировать, что данные не будут потеряны.

      Это не наезд, и уж тем более не на вас. Может кто-то знающий прояснит ситуацию.

      ЗЫ Речь, кстати, о ядре linux? Я не ошибся?

      • +1
        Баг с «зависающим диском» мы обнаружили и нашли метод устранить. Этот конкретный — не связан с отказом оборудования, это, вероятнее всего, внутренняя проблема md.

        Относительно поведения разработчиков… Честно — не знаю.
  • НЛО прилетело и опубликовало эту надпись здесь

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.