Meilleures pratiques du micrologiciel et calendriers de mise à jour

Le micrologiciel reçoit très peu d'attention en ce qui concerne les mises à jour. Hors de vue, hors de l'esprit.

De nombreux périphériques: contrôleurs RAID, cartes réseau, chipsets et même disques durs, bénéficient de la mise à jour. Meilleures fonctionnalités, sécurité / corrections de bugs, etc.

La plupart des SA disent: "Chaque fois qu'il se casse, mettez à jour le firmware." Mais cela peut entraîner des difficultés sur la route; Plusieurs fois, lorsque j'ai contacté Dell à propos d'un disque dur défectueux, on m'a demandé si le micrologiciel de mon disque dur était à jour. Tous mes serveurs utilisent un certain type de configuration RAID. Si j'ai déjà une panne de disque unique, devrais-je même envisager d'essayer de mettre à niveau le micrologiciel sur les autres disques ou le contrôleur RAID? Je dirais non. Mais Dell semble avoir une vision différente.

• Qu'est-ce qu'un calendrier de mise à jour réaliste pour le firmware du système?
• Avez-vous des bonnes pratiques à partager?

(Je sais que Dell a un bel utilitaire appelé Server Update Utility , qui vérifie tous les nouveaux micrologiciels sur n'importe quel serveur Dell.)

Je mets à jour le firmware dans deux cas clés.

1. Lors de la mise en place d'un serveur.
   • Lorsque je reçois le serveur, je vérifie sur le site Web HP la date de leur dernier "CD de mise à jour du micrologiciel". S'il est suffisamment nouveau, je l'exécuterai sur le serveur avant de le mettre en production.
   • Quand je réutilise un serveur. En règle générale, ce serveur est âgé de 2 à 5 ans et n'a probablement pas eu de mise à jour du firmware depuis tout ce temps. Comme je le reformate de toute façon, je mettrai à jour tous les différents micrologiciels du serveur.
2. Lorsqu'un fournisseur a identifié la nécessité de le faire.
   • Parfois, des problèmes de stabilité majeurs sont identifiés, comme une incapacité à reconstruire une matrice RAID5 après le mauvais type de panne, ou un bogue de performances majeur dans le moteur de déchargement TCP sur la carte réseau.
   • Parfois, lors de l'appel au support, le technicien du support demandera que je mette à jour le firmware. Je le ferai alors.

Il y a un troisième cas que je n'ai pas énuméré ci-dessus, car il ne s'est pas encore produit:

• Lorsque vous mettez un composant beaucoup plus récent sur un serveur plus ancien. Parfois, le BIOS du système devra être mis à jour pour le gérer.

Nous utilisons HP SIM (System's Insight Manager) pour déployer le firmware, nous le faisons par plate-forme - testez d'abord, puis développement, puis intégration, puis référence puis enfin production - généralement environ une semaine par plate-forme, nous avons donc un 5/6 libération de la semaine dans la fenêtre de production. Semble fonctionner, mais une chose que nous ne faisons JAMAIS est de déployer le firmware en même temps que d'autres mises à jour comme les pilotes / le code, etc. - économise beaucoup de pointages.

Je vais peut-être à contre-courant ici, mais s'il n'est pas cassé, ne le répare pas. Si ce n'est pas un problème de sécurité, je le laisse tranquille.

Je n'ai jamais vu Dell refuser le service pour cette raison.

Vous pouvez peut-être planifier l'utilitaire une fois par mois, puis les mettre à jour avec d'autres redémarrages?

Vous devez traiter les mises à jour du micrologiciel comme vous traitez les correctifs , bien que ces mises à jour soient généralement plus difficiles à déployer, vous pouvez donc vérifier les notes de version pour déterminer si cela en vaut la peine (mais là encore, vous pouvez également le faire pour les correctifs ). Les mises à jour du micrologiciel sont tout aussi susceptibles de contenir un nouveau bogue méchant que d'en corriger un.

La mise à jour du micrologiciel doit être effectuée lors de la mise en service (ou de la remise en service du matériel), car il est facile de le faire.

Le déploiement devrait à peu près suivre quelque chose dans ce sens:

1. Test sur machines de laboratoire
2. Déployer sur des systèmes sans importance
3. Attendez
4. Déployer sur des systèmes importants / de production

Là encore, certaines choses ne peuvent pas suivre cela. En particulier, il est assez crucial de pousser très rapidement les correctifs Microsoft vers les bureaux Windows, et les tests sont difficiles à faire rapidement sans ressources importantes.

Je mettrai généralement à jour le firmware lors de la mise en service de tout nouvel équipement d'infrastructure. Les stations de travail et les imprimantes ne sont mises à jour qu'en cas de problème spécifique tel qu'une correction de bogue requise ou un problème de sécurité. Il est moins important avec les serveurs, car dans la plupart des cas, le code du micrologiciel ne s'exécute pas au-delà du processus de démarrage ou est si simple qu'il n'y a pas grand chose à faire.

J'ai eu de mauvaises expériences avec la mise à niveau du firmware RAID sur les serveurs, car de nombreux fabricants ne garantissent pas que la configuration RAID actuelle sera viable si la version du firmware change, de même avec les disques individuels de la baie.

Ma tendance serait d'appliquer une politique "si ce n'est pas cassé, ne le répare pas" pour la plupart. Il vaut la peine de vérifier s'il est possible de récupérer après une mauvaise mise à niveau du Firemware (c'est-à-dire une ROM redondante dans les serveurs HP, ou si vous avez un clignotant EEPROM et que vous êtes prêt à l'utiliser avec une puce amovible).

Je ne peux pas parler de Dell, mais des gens du groupe de stockage IBM m'ont dit il y a de nombreuses années que les premiers niveaux de leur firmware RAID ne sont JAMAIS les meilleurs. Ils tirent d'abord sur la stabilité, puis augmentent les performances avec les futurs niveaux de régime. Malheureusement, peu d'entre nous penseraient (ou auraient peut-être le moxie) à revenir plus tard et à jouer avec le firmware RAID d'un système sain à moins qu'il n'y ait des problèmes. Donc, notre stratégie a été de mettre à niveau les niveaux du firmware RAID à chaque fois que nous configurons un nouveau serveur, en supposant que l'adaptateur RAID n'est pas un nouveau modèle de marque. De cette façon, nous obtenons au moins les meilleurs niveaux de performances disponibles à l'époque. S'il s'agit d'un nouvel adaptateur de mode, nous essayons de faire une note mentale pour revenir en arrière dans quelques mois et vérifier les mises à jour, mais nous ne sommes pas religieux à ce sujet.

Sur les cartes mères, nous ne jouons pas avec eux, sauf si le support technique du fournisseur nous le dit. Notre expérience au fil des ans a montré qu'à moins qu'il n'y ait un problème spécifique à résoudre, les risques l'emportent largement sur les avantages difficiles à mesurer.

// spk

J'ai utilisé avec succès le SUU et les produits similaires de HP et IBM. Les seuls problèmes que j'ai jamais rencontrés étaient lorsqu'un pilote de fournisseur a été utilisé pour remplacer un pilote Dell, sans raison technique, ce qui a entraîné l'échec de la mise à niveau SUU de la mise à niveau OM sur un serveur Dell. Nous avons exécuté des mises à jour du micrologiciel et des pilotes sur plusieurs centaines de serveurs au moins deux fois par an pour les garder tous à jour. Nous n'avons jamais rencontré de problèmes avec le firmware RAID.

Nous mettons à jour le firmware chaque fois que nous en avons l'occasion, ce qui est malheureusement probablement 3-4 fois par an (fenêtres de maintenance principales) pour certains systèmes.

Si vous lisez le texte descriptif qui accompagne une mise à niveau du micrologiciel Dell, vous constaterez qu'il classe la mise à jour comme critique, importante ou autre, et décrit ce que la mise à niveau corrige (pas toujours aussi clairement qu'on le souhaiterait!).

À mon avis, je n'appliquerai pas de mise à niveau du micrologiciel sans une très bonne raison. Si c'est une mise à jour critique et résout un problème que j'ai une chance raisonnable de rencontrer, alors oui, je l'appliquerai même si c'est une entreprise stressante.

Comme vous le dites, le support Dell insiste normalement pour appliquer les mises à niveau pertinentes avant de vous soutenir, et évidemment dans ce cas, vous n'avez pas beaucoup de choix. Vous pouvez comprendre que Dell ne souhaite pas perdre de temps d'ingénieur, même si je n'ai jamais connu de micrologiciel à l'origine d'un appel d'assistance.

JR

Je pense que cela dépend du type d'environnement auquel vous devez faire face. Si vous travaillez dans un environnement qui nécessite une haute disponibilité et que vous ne pouvez pas redémarrer les serveurs quand vous le souhaitez. La meilleure pratique à mon avis est de mettre en œuvre un calendrier de maintenance. Sélectionnez un délai pour chaque système, informez les utilisateurs et effectuez tous les travaux nécessaires, y compris les mises à jour du micrologiciel pendant ce délai imparti. De cette façon, vous pouvez être certain que tous vos systèmes sont à jour et minimiser l'impact sur la production en même temps. En outre, comme cela a été noté dans les commentaires plus tôt, il est nécessaire de vérifier les mises à jour du micrologiciel lorsque vous créez un nouveau serveur.