ファームウェアのベストプラクティスと更新スケジュール
ファームウェアのアップデートに関しては、ほとんど注意が払われていません。視界の外、心の外。
多くのデバイス：RAIDコントローラー、NIC、チップセット、さらにはハードドライブでさえ、更新することでいくつかのメリットを得られます。より良い機能、セキュリティ/バグ修正など.
ほとんどSAと言う、「壊れたときはいつでも、ファームウェアをアップデートしてください。」しかし、これは将来の問題につながる可能性があります。故障したハードドライブについてDellに連絡するとき、私は尋ねられましたハードドライブのファームウェアが最新の場合。すべてのサーバーで何らかのRAID構成が使用されています。すでに単一のドライブに障害が発生している場合、残りのドライブまたはRAIDコントローラーのファームウェアをアップグレードすることを検討する必要がありますか？私はノーと言いますが、デルは別の見方をしているようです。
- システムファームウェアの現実的な更新スケジュールはどのようなものですか？
- 共有するベストプラクティスはありますか？
（Dellには Server Update Utility と呼ばれる素晴らしいユーティリティがあり、Dellサーバー上のすべての新しいファームウェアをチェックすることを知っています。）
2つの主要なインスタンスでファームウェアを更新します。
- サーバーのステージング時
- サーバーを入手したら、HPのWebサイトで最新の「Firmware Update CD」の日付を確認します。十分に新しい場合は、本番環境に移行する前にサーバーに対して実行します。
- サーバーを転用するとき。通常、このサーバーは2〜5年前のものであり、おそらくその間ずっとファームウェアの更新はありません。とにかくそれを再フォーマットしているので、サーバー上のさまざまなファームウェアをすべて更新します。
- 特定されたベンダーがいる場合、そうする必要がある。
- 誤った種類の障害の後にRAID5アレイを再構築できない、NICのTCPオフロードエンジンの主要なパフォーマンスバグなど、重大な安定性の問題が確認されることがあります。
- ときどきサポートを依頼すると、サポート技術者からファームウェアの更新を要求されることがあります。私はそうします。
上記に挙げていない3つ目のインスタンスがあります。これはまだ発生していないためです。
- はるかに新しいコンポーネントを古いサーバーに配置する場合。時々、システムBIOSはそれを処理するために更新する必要があります。
HP SIM（システムのインサイトマネージャー）を使用してファームウェアを展開します。最初にテスト、次に開発、次に統合、次に参照、最後に本番稼働まで、プラットフォームごとに行います。通常、プラットフォームごとに約1週間程度なので、5/6生産ウィンドウへの週リリース。動作しているように見えますが、私たちが絶対にやらないことの1つは、ドライバー/コードなどの他の更新と同時にファームウェアをロールアウトすることです。
私はここで穀物に反対するかもしれませんが、それが壊れていない場合は修正しないでください。セキュリティの問題でない場合は、そのままにしておきます。
そのため、デルはサービスを拒否していません。
おそらく、ユーティリティを1か月に1回スケジュールしてから、他の再起動で更新できますか？
パッチを扱うようにファームウェアの更新を扱うですが、これらの更新は通常展開が難しいため、リリースノートを確認して、努力する価値があるかどうかを判断するのに役立つ場合があります（ただし、繰り返しますが、パッチに対してもこれを行う）。 ファームウェアのアップデートには、バグを修正するのと同じくらい、新しい厄介なバグが含まれている可能性があります。
ファームウェアの更新は、簡単に行うことができるので、試運転（またはハードウェアの再試運転）時に行う必要があります。
展開はおおまかに次のように行われます。
- ラボマシンでテストする
- 重要でないシステムに配備する
- 待つ
- 重要な/本番システムに展開する
繰り返しになりますが、これに従えないものもあります。特に、MicrosoftパッチをWindowsデスクトップに迅速にプッシュすることは非常に重要であり、重要なリソースなしにテストを迅速に行うことは困難です。
通常、新しいインフラストラクチャ機器を使用開始するときにファームウェアを更新します。ワークステーションとプリンターは、必要なバグ修正やセキュリティ問題などの特定の問題がある場合にのみ更新されます。ほとんどの場合、ファームウェアコードはブートプロセスを超えて実行されないか、非常に単純であるため、問題が発生することはほとんどありません。
ファームウェアバージョンが変更された場合、アレイ内の個々のディスクと同じように、現在のRAID構成が実行可能であることが保証されていないため、サーバーでのRAIDファームウェアのアップグレードに関して悪い経験がありました。
私の傾向は、「壊れていない場合は修正しない」というポリシーを大部分適用することです。不正なファームウェアのアップグレードから回復できるかどうかを確認することは価値があります（つまり、HPサーバーでは冗長ROM、またはEEPROMフラッシャーがあり、リムーバブルチップを使用する用意があるかどうか）。
デルについて話すことはできませんが、何年も前にIBMストレージグループ内の人々から、RAIDファームウェアの最初のレベルは決して最高のパフォーマンスを発揮するとは言われていませんでした。彼らはまず安定性を狙って撃ち、次に将来の回転レベルでパフォーマンスを上げます。残念ながら、問題がなければ、後で戻って正常なシステムのRAIDファームウェアを混乱させると考える人（またはおそらくmoxieを持っている人）はほとんどいません。したがって、私たちの戦略は、RAIDアダプターがブランドスパンキンの新しいモデルではないと想定して、新しいサーバーをセットアップするたびにRAIDファームウェアレベルをアップグレードすることでした。このようにして、少なくとも現時点で利用可能な最高のパフォーマンスレベルを取得します。それが新しいモードのアダプターである場合、数か月後に戻って更新を確認するように精神的な注意を払うようにしますが、それについては信心深くありません。
マザーボードでは、ベンダーのテクニカルサポートからの指示がない限り、それらを台無しにしないでください。長年にわたる私たちの経験では、修正が必要な特定の問題がない限り、リスクは測定が困難な利点をはるかに上回っています。
// spk
私はSUUとHPおよびIBMの同様の製品を使用して成功しています。私が今までに遭遇した唯一の問題は、ベンダーのドライバーがDellドライバーを置き換えるために使用されたときであり、技術的な理由がなかったため、SUUアップグレードがDellサーバーでのOMアップグレードに失敗しました。数百台のサーバーでファームウェアとドライバーの更新を少なくとも年に2回実行して、それらすべてを最新の状態に保ちました。 RAIDファームウェアの問題に遭遇したことはありません。
ファームウェアを入手するたびに更新しますが、一部のシステムでは、残念ながら年に3〜4回（メジャーメンテナンスウィンドウ）です。
それはあなたが対処しなければならない環境の種類に依存すると思います。高可用性を必要とする環境で作業していて、必要なときにサーバーを再起動できない場合。私の意見では、ベストプラクティスはメンテナンススケジュールを実装することです。各システムの時間枠を選択し、ユーザーに通知し、この割り当てられた時間枠の間にファームウェアの更新を含むすべての必要な作業を実行します。このようにして、すべてのシステムが最新であることを確認し、本番環境への影響を最小限に抑えることができます。また、前のコメントで述べたように、新しいサーバーを構築するときにファームウェアの更新を確認する必要があります。
デルのファームウェアのアップグレードに伴う説明を読むと、アップデートが重要、重要、またはその他に分類されており、アップグレードで修正される内容が説明されています（必ずしも期待するほど明確ではありません！）。
私の見解では、非常に正当な理由がない限り、ファームウェアのアップグレードは適用しません。それが重要なアップデートであり、私が遭遇する合理的な可能性がある問題を修正した場合、はい、ストレスの多いビジネスであっても適用します。
おっしゃるように、デルのサポートは通常、サポートが提供される前に関連するアップグレードを適用することを要求します。明らかにその場合、選択肢は多くありません。デルがサポートコールの原因となるファームウェアを知らなかったとしても、エンジニアの時間を無駄にしたくないと理解できます。
JR