/ Flickr / Ivan Bandura / CC
На прошлой неделе HPE опубликовали информацию о проблеме с сетевыми адаптерами. После установки обновления виртуальные машины показывали сообщение Disconnected network status. Другой симптом — невозможность определить сетевой адаптер в ROM-Based Setup Utility (RBSU).
«Установка неисправных драйверов приводила образы прошивки сетевых адаптеров в нерабочее состояние, — отмечают представители HPE. — В этом случае единственным выходом становилась замена оборудования. Поддержка HPE активно помогает пользователям»
Был способ избежать этой участи, однако им могли воспользоваться только те, кто уже обновил драйверы, но еще не перезагрузил хосты. Для этого нужно было запустить систему онлайн-обновления фирменного ПО HPE.
Не все ProLiant оказались под ударом: проблемы возникали у серверов HPE ProLiant с VMware ESXi 5.5, 6.0 или 6.5 после установки или обновления драйверов QLogic до версии 2.713.30 из July Service Pack или образа July HPE Custom ESXi.
Драйвера, вызывавшие проблему, — это net-bnx2x_2.713.30.v55.7-1OEM.550.0.0.1331820 и net-bnx2x_2.713.30.v60.7-1OEM.600.0.0.2494585 для Flex-10 530 серии и 630-х FlexFabric.
На данный момент «проблемные» образы ESXi для ESXi 6.5 или 6.5 U1 в списке загрузок VMware были заменены. HPE также удалила оригинальный July Service Pack для ProLiant — он был заменен на SPP 2017.07.2.
/ Service Pack for ProLiant (SPP) / HPE
Резиденты The Register говорят, что такие ситуации возникают из-за того, что программировать кастомные прошивки дешевле, чем делать специальные кремниевые чипы. Это и может приводить к появлению разного рода багов и необходимости большего числа апдейтов.
Они также отмечают, что во избежание подобных ситуаций производителю стоит проводить проверку на наличие устаревших конфигураций, работа прошивки с которыми не тестировалась. И сообщать об этом при установке, параллельно предлагая способы решения проблемы.
Отметим, что подобная ситуация с обновлениями для серверов ProLiant и проблемами с сетевыми адаптерами происходила и ранее. Последний раз такое случалось в 2014 году.
P.S. О чем еще мы пишем в «Первом блоге о корпоративном IaaS»:
Комментарии (16)
Karpion
08.10.2017 18:30+21) Чем дольше живу — тем лучше понимаю, почему при И.В.Сталине за такие фокусы репрессировали. Причем репрессировали и непосредственно виновных, и их начальников, а заодно ближайших сотрудников — за то, что не следили за теми, кто работает рядом. Страшнее всего то, что бренды требуют высокую цену за свои изделия, платят хорошую зарплату, а за косяки никто не отвечает (и эта безответственность прописана в лицензионных соглашениях, а государство не запрещает законами прописывать безответственность).
А нам тут в конце 198*-х и в 199*-х рассказывали, что безответственность и наплевательство — это характерные черты коммунизма; при капитализме такого не бывает и быть не может.
2а) Поражает кретинизм разработчиков, которые заложили в сетевые адаптеры возможность залить новую прошивку и не предусмотрели тот самоочевидный факт, что залить могут сколь угодно дефектную прошивку. А всего-то надо было — добавить функцию «сбросить залитую прошивку и вернуться к заводской»: для этого надо иметь джампер на сетевой карте. Ну и приложить немного мозгов — с чем, очевидно, большой дефицит.
2б) Ну или есть давно опробованный вариант: в сетевом адаптере вообще нет энергонезависимой памяти, при выключении прошивка сбрасывается. А при загрузке драйвера (того, который грузится в ядро операционки) прошивка заливается заново.
(Наверно, энергонезависимая память всё-таки нужна — там д.б. загрузчик прошивки, принимающий прошивку и размещающий её в памяти. Но это д.б. в неизменном ПЗУ.)
3) Я вообще не понимаю, зачем надо было менять прошивку сетевого адаптера. Неужели в изначальной прошивке были такие сильные косяки, что потребовалось менять прошивку? А почему программисты, допустившие эти косяки, не ответили за бракоделье?
4) А какого фига эти обновления вообще запустились на старых системах — тех, которые не тестировались на совместимость? У разработчиков совсем мозгов нет?DaylightIsBurning
08.10.2017 21:20+2Зачем за такое расстреливать? Если у вас критический сервис — нужно разворачивать fault-tollerant систему. Любое оборудование может отказать. А уж апдейт софта вообще всегда рисковая операция. Если обновляете софт и не готовы к тому, что обновление может привести к отказу системы — ССЗБ.
Karpion
08.10.2017 23:23А зачем вообще расстреливают преступников? Очевидно же: для вразумления всех тех, кто остался в живых и знает про расстрел.
Fault-tollerant система нужна. Вот только это означает удвоение расходов на железо; вероятно, и на софт. А ещё надо следить за тем, чтобы разные компоненты системы обновлялись по очереди, и чтобы интервал между обновлениями был достаточен для тестирования.
Кстати, никакое тестирование не может гарантировать работоспособность. Т.е. может оказаться, что обновление рушит систему после того, как всё уже обновили — интервала тестирования оказалось недостаточно.
Именно для этого и надо вразумлять разработчиков. особенно тех, кто на высокой зарплате.
И наконец: Обновление софта не должно приводить к окирпичиванию железа. Никогда, ни при каких условиях. А если привело — то маналула разработчикам.DaylightIsBurning
09.10.2017 01:41+1Вот только это означает удвоение расходов на железо
Не обязательно удвоение. Может быть удоражние на 5%, а может и на 200%. Зависит от конкретной системы.
А ещё надо следить за тем, чтобы разные компоненты системы обновлялись по очереди
Если применение требует — обязательно, других способов нет. Даже расстрелы не обеспечат 100% надёжности — это физически невозможно. При этом каждая следующая «девятка» надёжности увеличивает стоимость, и обычно нелинейно.
может оказаться, что обновление рушит систему после того, как всё уже обновили
Значит нужно предусмотреть план отступления на такой случай.
Именно для этого и надо вразумлять разработчиков. особенно тех, кто на высокой зарплате.
Их вразумляют — премии там не выплачивают, повышение задерживают. Но перестараться нельзя — станут излишне осторожными — это не продуктивно, нужен баланс.
Обновление софта не должно приводить к окирпичиванию железа. Никогда, ни при каких условиях.
Но ошибки случаются. Нет способов обеспечить такую невозможность. Только снизить вероятность, это не бесплатно.
для вразумления всех тех, кто остался в живых и знает про расстрел.
Помогает ли? Нет конечно! Только сдерживает энтузиазм и провоцирует крайнюю консервативность. Может и в школе за ошибки сразу расстреливать — сразу обучение намного эффективней пойдёт?! Ну или за переход дороги в неположенном месте! Или за опечатки в газетах! Наказание должно быть адекватным, иначе от него больше вреда чем пользы. Перестраховки стоят очень дорого. Если за ошибки будут расстреливать — оборудование будет обходится в разы если не на порядки дороже. Лучше уже fault-tollerant систему собрать, если применение требует. А если не требует — можно и потерпеть отказы.
Единственный способ избежать катастрофу — это распределение рисков. Сколько не расстреливай — факапы будут. Чем больше мы будем полагаться на супер надёжные компоненты — тем больше ущерба будет от того, что не предусмотрены действия в случае нештатной работы. Надёжной может быть система, а не компоненты. HP не обещает супер-надёжности своих серверов. Они говорят, что сделают что могут в условиях ограниченных ресурсов, но предупреждают, что клиенты со своей стороны должны быть тоже готовы… Задача HP — обеспечить лучшее качество за свои деньги. Лучшее не значит абсолютное. Если клиенты посчитают, что HP не справляются — они перейдут к решениям других вендоров.Karpion
09.10.2017 19:13Представим себе, что на высокооплачиваемую должность разработчика претендуют два человека — некомпетентный наглец и компетентный образованный человек. Вот они оба приходят к нанимателю, и каждый обещает добиться каких-то результатов.
Компетентный образованный человек знает про возможные трудности. Его обещания скромны — он честно рассказывает о том, что любое дело может не получиться.
А что обещает некомпетентный наглец? О-о-о, он не стесняется в своих обещаниях! Он знает, что его знания откровенно недостаточны — и он надеется просто дорваться до высокооплачиваемой должности и усидеть на ней сколько получится, эксплуатируя прежние наработки. А потом уволят — на ладно, можно будет искать себе новое место.
Итак, начальник (который сам некомпетентный, ибо учился MBA, а не технологиям) принимает на работу некомпетентного наглеца. И дальше всё происходит ожидаемым путём — сколько-то времени работает, потом факап. Некомпетентный наглец пытается оправдаться — и с некоторой вероятностью у него это получится, а значит, у него будет шанс устроить следующий факап. Т.б. что начальник совершенно не хочет признаваться в собственной некомпетентности, проявленной при выборе сотрудников.
Но даже если некомпетентный наглец останется без премии и повышения — его это не пугает. Одно то, что он получает зарплату — для него уже незаслуженная удача. Даже увольнение ля него не очень страшно — он уже получил немалые деньги.
Вывод: наказание за факап д.б. сравнимо с размеров нанесённого ущерба и/или с размером полученной зарплаты. Т.е. либо неимоверной величины штраф, либо тюремное заключение, либо расстрел. Порка плетьми, отрубание частей тела, повешение и утопление в выгребной яме тоже годятся. А вот лишение премии, отказ в повышении и даже увольнение — не годятся.
Не годятся потому, что никак не побудят следующего некомпетентного наглеца отказаться от попыток занять эту должность.
Рассмотрим с этой т.з. ошибки в школе.
Какой тут ущерб? Нулевой.
Какая зарплата у ученика? Нулевая.
Всё понятно?
И с опечатками в газете аналогично — ущерб там небольшой. Да и зарплаты невеликие.
В принципе, можно и не расстреливать. Надо просто обязать HP за ейный счёт заменить всё окирпиченное оборудование. И оплатить простой. Дальше акционеры сами порвут директоров. А следующие директоры будут относиться к делу внимательнее.
И речь тут вовсе не о супер-надёжности. Речь всего лишь о том, чтобы пресекать очевидные косяки разработчиков. Я допускаю, что новая прошивка м.б. глючной и неработоспособной. Но вот железка должна продолжать работать (например, продолжать позволять обновление прошивки) независимо от того, какую прошивку туда залили в прошлый раз.
И кстати — оборудование у HP реально на порядок дороже, чем у noname. Так что и качество д.б. аналогично выше — особенно в отношении глупых косяков.
PS: В принципе, было бы нормально обязать HP в течении года в каждой своей рекламе рассказывать про этот косяк и побуждать покупателей не полагаться на надёжность компонентов, а обеспечивать надёжность самостоятельно. Заодно покупатели задумаются: если надёжность надо обеспечивать своими силами, а для этого надо иметь образованных сисадминов, то не дешевле ли будет вообще отказаться от брендового железа? Ведь способы обеспечения надёжности одинаковы и для брендов, и для noname. А если нет разницы — зачем платить дороже?DaylightIsBurning
09.10.2017 20:12А потом уволят — на ладно, можно будет искать себе новое место.
Ну и всё. На новое место с повышением его уже не наймут — репутация. А если найму — значит наниматель ССЗБ, что не смог распознать пустое бахвальство. При чём тут расстрелы за ошибки?
начальник (который сам некомпетентный, ибо учился MBA, а не технологиям
На хорошей MBA учат как распознать пустое бахвальство, так что начальник с MBA в этом плане вполне компетентен.
начальник совершенно не хочет признаваться в собственной некомпетентности
Это вообще фундаментальная проблема, решается правильной настройкой институтов. Расстрелы тут ни причём.
наказание за факап д.б. сравнимо с размеров нанесённого ущерба и/или с размером полученной зарплаты
Нет. Наказание за факап должно быть таким, что бы достигнуть оптимума функциивероятность_ущерба*размер_ущерба - утраченная_выгода_от_перестраховки
лишение премии… никак не побудят следующего некомпетентного наглеца отказаться от попыток занять эту должность.
Расстрелы тоже — примеры были. Кроме того расстрелы тормозят развитие и стоят дорого. Вообще эта проблема решается не расстрелами, а грамотной системой сдержек и мотиваций. Если начальник мотивирован нанимать тех, кто компетентен и проводить независимые перепроверки оценок полученных разными подчинёнными — всё будет ок. Компании тоже могут быть устойчивыми к ошибкам. Некомпетентные наглецы в нормальной структуре не смогу делать карьеру — репутация. Второй раз им просто ресурсы/власть не дадут в руки.
Расстрелы — это типичное простое (и неэффективное) решение сложной проблемы.
Надо просто обязать HP за ейный счёт заменить всё окирпиченное оборудование
Можно просто не покупать оборудование HP. Считаете, что оно для Вас недостаточно надёжное — покупайте то, которое Вам подходит. Этого достаточно, что бы акционеры повлияли на менеджмент. HP контракт нарушили? Нет. Если Вы хотите, что бы Вам компенсировали потери в случае неполадок — заключайте соотв. контракт со своим вендором. Или просто купите страховку.
оборудование у HP реально на порядок дороже, чем у noname. Так что и качество д.б. аналогично выше
С чего вдруг? Стоимость и надёжность могут быть связаны нелинейно. Да и вообще цена не только от надёжности зависит.
было бы нормально обязать HP в течении года в каждой своей рекламе рассказывать про этот косяк
Было бы нормально, если бы человек, который закупает оборудование перед принятием решение узнавал, какие факапы были у каких вендоров, оценивал их частоту, серьёзность и т.п.
не дешевле ли будет вообще отказаться от брендового железа
Некоторые так и делают, например google, backblaze…
Jef239
08.10.2017 22:30Для возвращения к заводской прошивке нужно иметь двойной объем флэш-памяти. То есть на несколько долларов больше себестоимости каждой платы. Чтобы добраться до джампера — надо иметь физический доступ к платам. То есть в условиях ДЦ — неудобно.
Намного лучше это все предусмотреть в софте. Перед обновлением платы — выкачиваем старую прошивку. Если новая не заработала — значит заливаем обратно старую.
А вот наличие загрузчика, который не испортить при заливке прошивки — критично. Как я понял, тут или не было загрузчика — или не было софта, способного залить прошивку в плату с голым загрузчиком, то есть неопределившуюся в BIOS.
Контроль версий тоже не всегда спасает. Была замечательная история, как сгорели три ГЛОНАССа. На ракете сменили бак. Расчетчики — считали горючее по старому баку. Контроль — тоже считал по старому баку. И всё, «остатки разгонного блока и спутников упали в акватории Тихого океана в 1,5 тыс. км северо-западнее Гонолулу». А контроль версий — был. И показывал, что все хорошо, просто одного сбоя хватило, чтобы информация о версии не дошла ни до расчетчиков, ни до контроля.
Так что контроль версий — палка о двух концах. Может спасти, может не спасти, может дать лишнюю проблему (когда не обновим то, что надо обновлять). Третье — особенно неприятно в условиях цейтнота.
P.S. Вторая флэшка не всегда спасает. У нас была веселуха — сбой питания при апдейте. Вторая флэшка с заводской прошивкой есть, но запускается лишь при активизации контакта или сбое питания во время загрузки. А контакт — на пузе припаянной к плате микросхемы. Отпаять — так проще новую припаять, чем эту к жизни возвращать. Сбои ей делать — так вся схемотехника делалась так, чтобы сбоев не было. А сверху этот контакт повесить нельзя, сверху там экран.
xl-tech
08.10.2017 22:24+1Тут та же история что с обновлениями ОС, сначала на тестовый контур, потом в продакшн, нарушил правило — получил простой.
GnuriaN
09.10.2017 00:53+1т.е. тестовый контур, должен содержать в себе, весь перечень оборудования, что есть в рабочей системе? Эм… где взять столько денег и оборудования?
xl-tech
09.10.2017 01:23Да, это сложно, но если выбрать одного вендора и планомерно обновлять оборудование, то вполне возможно. Есть и другой выход, не ставить обновления драйверов / прошивок в течении определенного срока после их выхода :)
navion
10.10.2017 11:32Резиденты The Register говорят, что такие ситуации возникают из-за того, что программировать кастомные прошивки дешевле, чем делать специальные кремниевые чипы.
Вы хотели написать FPGA?
Londoner
Чёрт возьми, айтишный мир становится всё более хрупким, а известнейшие бренды, раньше отличавшиеся надёжностью, стремительно приближаются к поделкам с алибабы. Как дальше жить?
justhabrauser
Да так же, как и всегда — бэкап, бэкап и еще раз бэкап. Как завещал товарищ Ленин.
GnuriaN
А если "небольшая" компания и бюджета на все не хватает? Покупать заведомо дешевые решения и отказываться от "надежных" брендов?
А чем поможет бэкап, если у серверов вышли из строя "железки"?
Actee
В данном случае все вроде как поправили достаточно быстро. В этом и смысл — ошибки бывают у всех, но скорость реагирования разная. За счёт масштаба компании для неё намного выгоднее очень быстро находить решения.
d-stream
В данном контексте — держать на складе необновленные запасные серверы/сетевые платы?