Что подвесило систему: баг или вспышка на Солнце?



    Исходные данные: три системы БД Oracle, которые активно обмениваются между собой данными через механизм распределенных транзакций Oracle. В один прекрасный момент на всех серверах админы стали наблюдать возникновение очередей при попытке приложения выполнить вставки/обновления данных. Тут же послали сигналы для немедленного завершения процессов, которые блокировали работу пользователей. После получаса разбирательств было принято решение перезагрузить все три системы. Далее запустили процедуры по очистке зависших распределенных транзакций, которые находились в статусах COLLECTING и PREPEARED. Подробности о том, что делать в этом случае, можно зачитать в документе: How To Resolve Stranded DBA_2PC_PENDING Entries [ID 401302.1]. После того, как системы привели в работоспособное состояние, начался разбор полетов.

    Главный вопрос – что стало причиной сбоя системы? Да, во время инцидента была выявлена система (одна из трех), которая на этапе первичной диагностики работала с аномалиями (назовем ее система Х). Логин в ОС проходил, но подключиться к БД было невозможно. Причем данные системы оповещения health check фиксировали, что с системой Х полный порядок и во время зависания внимания на нее особо не обращали. Проблемы первоначально фиксировались в двух других системах (назовем их Y и Z), поэтому все внимание было на них.

    Начали сбор диагностики. Что-то уже было сделано до и во время зависания. Забегая вперед, скажу, что очень помогли скриншоты профилей удаляемых процессов из системы мониторинга, как раз перед их удалением.

    1. На системах Y и Z из истории активных сессий выгрузили статистику удаленных в первую очередь процессов. Процессы до их удаления фигурировали в истории активных сессий, каждый из них ожидал SQL*Net message from dblink из удаленной системы X. И тут появилась первая аномалия. После отметки времени 12:32:08 строки истории активных сессий в столбцах статистик потребленного CPU, DB time (TM_DELTA_CPU_TIME, TM_DELTA_DB_TIME) показывали пустые данные.
    2. Анализ трассировочных файлов БД и listener системы X. В alert.log БД последняя временная метка до перезапуска системы — Time: 06-SEP-2017 12:27:18. В журнале listener — Wed Sep 06 12:27:18 2017. В директории с трассировочными файлами последнее изменение файла NMON было в 12:26.
    3. История активных сессий на системе X показывала, что последняя запись из диапазона 12:20 – 14:00 была сделана фоновыми процессами в 12.27.33. В нашем случае сервер Oracle перестал сохранять данные истории, начиная с 12:27:33.

    4. Очевидно, что-то произошло с БД на стороне системы X. Решили посмотреть детально статистику со стороны ОС (CPU, ввод-вывод и т.п.) сервера X.



      Наблюдались значительные ожидания Wait % – когда пользовательские процессы ожидали возможности записи/чтения данных с диска (также наблюдалось полное отсутствие kernel write/read system calls, сетевого ввода-вывода и падение RunQueue). Время наступления событий ожидания – также 12:28.
    5. С БД и ОС разобрались. Решили посмотреть на нижележащий уровень – файловую систему и СХД. На системе хранения ничего не обнаружили, а вот на Veritas вывод команды errpt показал такую картину (лишнее убрано):
      BC3BE5A3   0906140317 P S SRC            SOFTWARE PROGRAM ERROR
      A6DF45AA   0906140317 I O RMCdaemon      The daemon is started.
      BC3BE5A3   0906140217 P S SRC            SOFTWARE PROGRAM ERROR
      D221BD55   0906140217 I O perftune       RESTRICTED TUNABLES MODIFIED AT REBOOT
      B258EF25   0906140117 T S VxDRV:vxdmp    Messages reported by vxdmp driver
      B258EF25   0906140117 T S VxDRV:vxdmp    Messages reported by vxdmp driver
      B258EF25   0906140117 T S VxDRV:vxdmp    Messages reported by vxdmp driver
      … удалено...<
      B258EF25   0906122817 T S VxDRV:vxdmp    Messages reported by vxdmp driver
      B258EF25   0906122817 T S VxDRV:vxdmp    Messages reported by vxdmp driver

    Промежуточный итог


    Основной причиной возникновения проблем явился отказ в обслуживании системы X в районе 12:27(28) местного серверного времени. Это прямо видно из журналов БД, слушателя, трассировочных файлов, данных истории активных сессий и журналов ФС Veritas. Также подтверждается отсутствием активности после отметки 12:32 на системах Y и Z при сетевых ожиданиях процессов во время вставки данных и фиксации распределенных транзакций. Данные процессы блокировали другие сессии, что приводило к формированию больших очередей процессов на сервере Y. Блокирующие сессии впоследствии были завершены аварийно.

    Различие временных меток остановки обслуживания на Y, Z и X связано с отставанием сервера X на ~4 минуты от других систем. Если вычесть эту дельту из времени окончания активности процессов на Y и Z (см. выше п.1), получим 12:27 (28) – цифры последней активности, которые показывают журналы БД, слушателя и история активных сессий на системе X.

    Если восстановить последовательность событий, то цепочка такая: недоступность системы X-> появление очередей на Y и Z –> потом — удаление администраторами блокирующих процессов и дальнейшее лавинообразное развитие ситуации с зависанием распределенных транзакций оставшихся компонентов системы.

    Итак, похоже дело в файловой системе VxFS от Veritas (ФС) на которой располагались файлы БД, трассировочные файлы БД и слушателя. ФС впала в «спячку» и остальные процессы ожидали, пока операция ввода-вывода будет завершена. Решили воспроизвести проблему с помощью команды fsfreeze на тестовых системах – очень похожая картина. Поиском на сайте вендора Veritas обнаружили описание бага с похожими симптомами: Doc Id: 3898129 с симптомами: File system hang can be observed sometimes due to IO's hung in DRL.

    Неожиданное


    На следующий день открываю новостную ленту – а там сообщения о вспышках на Солнце 6 сентября. За 7 сентября заголовки новостей пестрили сообщениями о том, как эта аномалия повлияла на системы связи, людей и т.д.

    06.09.2017 14:05, rg.ru, «Ученые: Мощнейшая вспышка на Солнце окажет воздействие на Землю»
    06.09.2017 14:44, rbc.ru, «Астрономы зарегистрировали самую мощную за 12 лет вспышку на Солнце»
    06.09.2017 15:34, rg.ru, «Видео: Из-за мощной вспышки на Солнце Москва увидит полярное сияние»
    06.09.2017 23:54, rg.ru, «Ученые рассказали о последствиях мощнейшей вспышки на Солнце»

    Некоторые считали, что необходимо наряду с багом в ФС Veritas рассматривать и эту версию как рабочую. Тогда я не придал этому особого значения.

    На днях решил все-таки плотно разобраться с этим вопросом. В интернете вышел на сайт Лаборатории рентгеновской астрономии солнца (ФИАН), на котором публикуется статистика солнечной активности со спутника GOES-15. Открываю я страницу с данными за 6 сентября – и что же? На КДПВ всплеск активности по вспышке C2.7  как раз попадает на время начала проблем с работой сервера X, причем очень близко к максимуму вспышки – 12:34. Я проверил еще раз время – не UTC ли? Нет, время местное. Ну, не может такого быть. Совпадение?

    Однако дополнительный поиск вывел на статью на Geektimes: Космическое излучение может влиять на системы.

    Оказывается, такое редко, но бывает. Подобные события называются «нарушением в результате единичного события» (single-event upset, SEU). Чаще всего происходят на большой высоте или околоземной орбите, но случаются и на Земле. Цитата:

    Хотя существуют довольно яркие примеры сбоев техники, SEU остаются исключительно редким феноменом. Но специалисты обращают внимание, что электронные микросхемы всё чаще используются в различных бытовых приборах. Плотность транзисторов на чипах возрастает, как и их количество. Из-за этого вероятность встречи с «космическим сбоем» растёт с каждым годом. Производители электротехники изучают проблему.

    Похоже, солнечная активность вполне может влиять на стабильность и устойчивость информационных систем. Что будет с их надежностью при дальнейшей миниатюризации технических процессов и более плотной упаковке чипов? Вопрос.

    На этом всё.
    Берегите себя!

    Александр Кардаполов, сервисный инженер компании «Инфосистемы Джет»
    Инфосистемы Джет 125,13
    Компания
    Поделиться публикацией
    Комментарии 35
    • +3
      Неожиданно. Интерсно, станет ли это фундаментальной проблемой по дальнейшему наращиванию мощностей
      • 0
        Фундаментальной — вряд ли, так как относительно легко обходится тройным дублированием критически важных систем. До тех пор, пока сбой будет возникать лишь в одной копии системы — «голосованием большинства» сбой будет нивелирован. Многоядерные процессоры, например, могут быть сконфигурированы для дублирования ядер, выполняющих критический код, незадействованными ядрами.
        • 0
          Увы, если бы все было бы так просто, то БЭВМ спутников по производительности мало бы уступали наземным. По факту сейчас они на уровне первых пней.

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

          Теперь давайте рассмотрим вопрос: что такое критический код. Допустим у нас сложная расчетная задача, какой код становится критическим важным? Очевидно весь. Но также очевидно, что если мы будем сравнивать каждую операцию, то скорость вычислений = скорость узла сравнения.

          А если вспомнить, что из-за ограниченности точности представления чисел с плавающей запятой, у нас итоговый результат всех вычислений будет разный. И как в этом случае устраивать голосование?

          • 0
            Голосование может быть произведено без принимающего решение выделенного центра: каждый элемент принимает решение самостоятельно, и соглашается что был не прав в своих вычислениях, если они не совпадают с большинством. Ситуация когда работа нарушена настолько, что мнение большинства игнорируется, должно приводить к сработке watchdog'а который перезапустит элемент.
            Насколько я понимаю, БЭВМ спутников специально делаются большими (и поэтому медленными), чтобы минимизировать воздействие высокоэнергетического проникающего излучения. Когда у вас 14нм техпроцесс, один шальной протон может изменить результат операции, а если транзисторы у нас в десятки раз больше (и соответственно выше токи), то и воздействие в сотни раз ниже, потребуется одновременное попадание нескольких частиц.
            Насчёт различий в результатах операций с плавающей точкой — если не ошибаюсь, это особенности работы ядер видеокарт, а не традиционных математических сопроцессоров, результаты вычислений которых детерминированы согласно IEEE 754.
            • +1
              P.S. нашёл статью в которой говорится об аномальном увеличении радиационной стойкости 65нм техпроцеса относительно более «толстых» техпроцессов. Было бы интересно узнать, как ведёт себя электроника с дальнейшим утончением техпроцесса.
      • +2

        В мире довольно много информационных систем. В них регулярно возникают сбои без всяких вспышек на Солнце. Теория вероятностей подсказывает нам, что вероятность, с которой подобный сбой совпадет по времени с какой-нибудь вспышкой, отлична от нуля (предполагаю, что попросту равняется единице). Поэтому делать выводы из единичного совпадения я бы не стал. :)

        • +1
          Поэтому и заголовок такой :)
          Хотя я голосую за всплеск солнечной активности.
          • –1
            Утверждения «вероятность события А равна единице» и «событие А происходит безусловно» эквивалентны
            • 0

              Вполне рабочая версия, ещё пару лет назад с коллегой на пальцах считали, что раз в пару ECC как раз защищает от альфа частиц, а если сильная солнечная активность, то вполне в одном блоке два бита могло выбить — тогда проверка четности прошла и сбой. Так что вполне вероятное событие. Иначе для чего тогда ЕСС?

              • 0

                Если на солнце произойдет такая вспышка, что до размещенного на земле оборудования будут долетать альфа-частицы, то работоспособность этого оборудования уже никого волновать не будет. :)

            • +2
              Меня не покидает чувство дежавю. По-моему, я эту статью уже раньше читал.
              • 0
                Рады внимательным читателям :). Действительно, черновой вариант поста по недосмотру был размещен ранее и провисел тут несколько минут. Сейчас исправили ошибки.
                • 0
                  Да нет, давно что-то такое было. Думаю и untilx подтвердит.
                  • 0
                    У меня публикация засветилась в RSS 29 декабря, была тут. Висела довольно долго, если я правильно помню, даже какое-то обсуждение было. Ну, перенесли и пёс с ней.
                • 0

                  Может про электронную почту и скорость света? https://m.geektimes.ru/post/241460/

                • +8
                  Следующая статья: «Как убедить клиентов и свое руководство в том, что виноваты не мы а вспышки на солнце».
                  • +10
                    Я им всё время говорю, что это вспышки на Солнце, а они мне: «Руки из жопы»…
                    • 0
                      Похоже на то! На что только не идут интеграторы, чтобы аргументировать недостаточное качество ПО.
                    • 0
                      Ага, только проблема в том, что это фотоны достигают Земли за 8 мин, а вот остальные частицы долетают гораздо позже.
                      • 0
                        Те частицы, которые пробиваются к самой Земле — высокоэнергичные, т.е. летят со скоростью близкой к скорости света.
                        • 0
                          Но позвольте!
                          Чтобы достичь Земли от Солнца с упомянутой вами скорость света, требуются как раз эти восемь с чем-то минут!

                          Или я неправильно прочитал ваш комментарий. :)
                          • 0
                            Да, именно так.
                            • +2
                              Рентгеновское излучение Солнца 5 и 6 сентября 2017 года по данным спутника GOES-15. То есть это данные по рентгеновскому излучению, которые регистрируются на спутнике (не на Солнце!). Уточнял этот момент лично у Богачева Сергея Александровича.
                        • +3
                          Спасибо. Теперь каждый раз перед началом дебагов буду заходить на сайт лаборатории и проверять, не было ли вспышек.
                          • 0
                            На википедии пишут, что солнечная активность, наоборот, снижает количество ошибок. Правда, без пруфов.

                            The average rate of cosmic-ray soft errors is inversely proportional to sunspot activity. That is, the average number of cosmic-ray soft errors decreases during the active portion of the sunspot cycle and increases during the quiet portion. This counterintuitive result occurs for two reasons. The sun does not generally produce cosmic ray particles with energy above 1 GeV that are capable of penetrating to the Earth's upper atmosphere and creating particle showers, so the changes in the solar flux do not directly influence the number of errors. Further, the increase in the solar flux during an active sun period does have the effect of reshaping the Earth's magnetic field providing some additional shielding against higher energy cosmic rays, resulting in a decrease in the number of particles creating showers. The effect is fairly small in any case resulting in a ±7% modulation of the energetic neutron flux in New York City. Other locations are similarly affected.[citation needed]
                            • 0
                              Так это про более/менее активную часть цикла, а не про вспышки. Вполне возможно, вспышки могут порождать частицы с энергией более 1 GeV.
                              • +1
                                Возможно, автор этой «теории» оздаравливается радиацией, лечит зубы ртутью и т.д…
                                • 0
                                  Ну а что, про русскую мафию в зарубежных газетах в 90х писали же «закаленные ГУЛАГом».
                              • 0
                                Спасибо за ссылку на сайт и идею. Теперь буду знать, что писать в объяснительных.
                                • 0

                                  Ну можно ведь защитить ram чем то вроде карбида вольфрама либо другими веществами, благо планки памяти на сегодня относительно маленькие(можно экранировать только сверху и торцов, для экономии). Должно выйти рентабельно для важных серверов, где простой — деньги.

                                  • 0
                                    От солнечных вспышек защитить можно, но остаются очень высокоэнергетические частицы космического излучения. Там только глубоко под землю закапывать.
                                  • 0
                                    errpt -a посмотреть бы вместе с саппортом веритас

                                    ну а вообще и повера (т.к. это аикс) и их память имеют хорошую систему диагностики ошибок, так что влияние радиации довольно маловероятно — не видно ошибок железа.
                                    • 0
                                      Скажите пожалуйста, а зачем у вас используется VxFS, если есть Oracle ASM?
                                      • +1
                                        Если смотреть в развитии.

                                        Функционал Volume manager (VM) предлагаемый Veritas очень стабильный, и, как это говорят mature. На рынке давно, еще до рождения ASM и становления других VM. Несмотря на существующие проблемы (ошибки в ПО), которых немного — свою работу делает на отлично.

                                        Можно почитать здесь о преимуществах Veritas (да и вообще VM) в сравнении со статической разбивкой дисков: habrahabr.ru/post/204240

                                        Кросс-платформенный, у ASM этого нет. Для текущей платформы — без альтернатив.
                                        • 0
                                          Спасибо.
                                          Да, кросс-платформенности в ASM не хватает, при миграциях на другую платформу приходится прибегать к костылям.

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

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