Кращі практики вбудованого програмного забезпечення та графіки оновлення

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

Багато пристроїв: контролери RAID, NIC, чіпсети і навіть жорсткі диски отримують певну користь від оновлення. Кращі функції, безпека / виправлення помилок тощо.

Більшість SA кажуть: "Кожного разу, коли він не працює, оновлюйте програмне забезпечення". Але це може призвести до труднощів у дорозі; Кілька разів, коли я звертався до Dell з приводу невдалого жорсткого диска, мене запитували, чи прошивка мого жорсткого диска актуальна. Всі мої сервери використовують певний тип конфігурації RAID. Якщо у мене вже є одна помилка накопичувача, чи варто мені навіть розглянути спробу оновлення мікропрограмного забезпечення на інших дисках або RAID-контролері? Я б сказав, що ні. Але Dell, схоже, має інший погляд.

• Який реалістичний графік оновлення системної прошивки?
• Чи є якісь найкращі практики для спільного використання?

(Мені відомо, що Dell має гарну утиліту під назвою Сервіс оновлення сервера , яка перевіряє наявність усіх нових прошивок на будь-якому сервері Dell.)

Я оновлюю прошивку в двох ключових випадках.

1. Під час постановки сервера.
   • Коли я просто отримаю сервер, я перевіряю веб-сайт HP на дату останнього "Оновлення прошивки". Якщо він достатньо новий, я запускаю його проти сервера, перш ніж привести його до виробництва.
   • Коли я перестановлюю сервер. Зазвичай цьому серверу віком від 2 до 5 років, і, ймовірно, не було оновлень прошивки протягом цього часу. Оскільки я все-таки переформатую його, я оновлю всі різні прошивки на сервері.
2. Коли є визначений постачальник, потрібно це зробити.
   • Іноді виявляються основні проблеми зі стабільністю, наприклад, неможливість відновлення масиву RAID5 після неправильного виду відмови, або велика помилка продуктивності в двигуні завантаження TCP в NIC.
   • Іноді при зверненні до служби технічної підтримки вимагає оновити прошивку. Я буду робити це тоді.

Є третя інстанція, яку я не перераховував вище, тому що ще не сталося:

• Якщо помістити набагато новіший компонент на старший сервер. Іноді для системного BIOS знадобиться оновлення, щоб обробити його.

Ми використовуємо HP SIM (System's Insight Manager) для розгортання вбудованого програмного забезпечення, ми робимо це за допомогою платформи - спочатку тестуйте, потім розробку, потім інтеграцію, потім посилання, потім нарешті виробництво - зазвичай приблизно тиждень або близько того на кожній платформі, тому у нас є 5/6 тиждень випуск у вікно виробництва. Здається, це працює, але одне, що ми НІКОЛИ не робимо - це розгортання прошивки одночасно з іншими оновленнями, такими як драйвери / код тощо. - Економить багато вказівки пальцем.

Я можу йти проти зерна тут, але якщо воно не зламане, не виправляйте. Якщо це не питання безпеки, то я залишаю це в спокої.

Я ніколи не відмовляв Dell в обслуговуванні з цієї причини.

Можливо, ви можете запланувати утиліту раз на місяць, а потім оновити їх іншими перезавантаженнями?

Ви повинні ставитись до оновлень мікропрограмного забезпечення під час обробки патчів , хоча зазвичай ці оновлення важче розгортати, тому ви, можливо, захочете перевірити примітки до випуску, щоб допомогти вирішити, чи варто докладати зусиль (але знову ж таки, ви можете робити це і для патчів ). Оновлення мікропрограмного забезпечення так само ймовірно містять нову неприємну помилку, як і її виправити.

Оновлення мікропрограмного забезпечення слід проводити під час введення в експлуатацію (або повторного введення в експлуатацію обладнання), оскільки це простий час для цього.

Розгортання має приблизно слідувати чомусь у цьому напрямку:

1. Тест на лабораторних машинах
2. Розгортання на неважливі системи
3. Зачекайте
4. Розгортання у важливих / виробничих системах

Знову ж таки, деякі речі не можуть цього слідувати. Зокрема, досить важливо дуже швидко натиснути патчі Microsoft на робочі стільниці Windows, а тестування складно зробити швидко без значних ресурсів.

Я зазвичай оновлюю прошивку під час запуску будь-якого нового інфраструктурного обладнання. Робочі станції та принтери оновлюються лише в тому випадку, якщо є певна проблема, наприклад, необхідна помилка виправлення помилок або проблема безпеки. Це менш важливо для серверів, оскільки здебільшого код вбудованого програмного забезпечення або не виконується після завантажувального процесу, або такий простий, що мало що може піти не так.

У мене був поганий досвід з оновленням програмного забезпечення RAID на серверах, оскільки багато виробників не гарантують, що поточна конфігурація RAID буде життєздатною, якщо зміниться версія мікропрограмного забезпечення, що стосується окремих дисків у масиві.

Моя тенденція полягала б у застосуванні політики "якщо вона не зламалася, не виправляй" здебільшого. Варто перевірити, чи можна відновитись після поганого оновлення програмного забезпечення (тобто надлишкового ПЗУ на серверах HP, або якщо у вас є флешер EEPROM і готові використовувати його знімний чіп).

Я не можу говорити про Dell, але мені багато років тому люди в групі зберігання IBM сказали, що перші рівні їх прошивки RAID НІКОЛИ не найкращі. Спочатку вони стріляють на стабільність, а потім піднімають продуктивність із майбутніми рівнями оборотів. На жаль, мало хто з нас подумає (або, можливо, у моксі) повернутися пізніше і зіпсуватись з прошивкою RAID здорової системи, якщо не виникнуть проблеми. Таким чином, наша стратегія полягала в тому, щоб підвищувати рівень вбудованого програмного забезпечення RAID кожного разу, коли ми встановлювали новий сервер, припускаючи, що адаптер RAID не є новою моделлю бренду. Таким чином, ми принаймні отримуємо найкращі рівні продуктивності, доступні на той час. Якщо це новий адаптер режиму, ми намагаємось зробити зауваження, щоб повернутися через кілька місяців і перевірити наявність оновлень, але ми не релігійні щодо цього.

На материнських платах ми НЕ возимось з ними, якщо нам не підкаже техпідтримка постачальників. Наш досвід протягом багатьох років полягає в тому, що, якщо не існує конкретної проблеми, яка потребує виправлення, ризики значно перевищують важко вимірні вигоди.

// спр

Я успішно використовував SUU та подібні продукти від HP та IBM. Єдині проблеми, з якими я коли-небудь стикався, були те, коли драйвер постачальника використовувався для заміни драйвера Dell без будь-яких технічних причин, через що оновлення SUU не вдалося оновити OM на сервері Dell. Ми проводили оновлення прошивки та драйверів на декількох сотнях серверів принаймні двічі на рік, щоб підтримувати їх актуальними. Ми ніколи не стикалися з проблемами з прошивкою RAID.

Ми оновлюємо вбудоване програмне забезпечення кожного можливого шансу, який, на жаль, мабуть, 3-4 рази на рік (основні вікна технічного обслуговування) для деяких систем.

Якщо ви прочитаєте розмиття, яке супроводжує оновлення програмного забезпечення Dell, ви побачите, що оновлення класифікується як критичне, важливе чи будь-яке інше, і описується, що виправлено оновлення (не завжди так чітко, як хотілося б!).

На мою думку, я не буду застосовувати оновлення мікропрограмного забезпечення без дуже вагомих причин. Якщо це критичне оновлення і виправляє проблему, я маю обґрунтовані шанси зіткнутися, то так, я застосую це, навіть якщо це напружений бізнес.

Як ви кажете, підтримка Dell зазвичай наполягає на застосуванні будь-яких відповідних оновлень, перш ніж вони підтримуватимуть вас, і, очевидно, у цьому випадку у вас немає великого вибору. Ви можете зрозуміти, що Dell не бажає витрачати час на інженер, хоча я ніколи не знав, що прошивка стане причиною виклику підтримки.

JR

Я думаю, це залежить від типу середовища, з яким ви маєте мати справу. Якщо ви працюєте в середовищі, яке вимагає високої доступності, і ви не можете перезавантажувати сервери, коли вам потрібно. Найкраща практика, на мою думку, - це виконання графіку обслуговування. Виберіть часовий проміжок для кожної системи, повідомте користувачів та виконайте всі необхідні роботи, включаючи оновлення програмного забезпечення протягом цього відведеного часового періоду. Таким чином ви можете бути впевнені, що всі ваші системи оновлені та мінімізують вплив на виробництво одночасно. Крім того, як було зазначено в коментарях раніше, потрібно перевіряти наявність оновлень мікропрограмного забезпечення під час створення нового сервера.