Probabilité de défaillance du châssis de lames

Dans mon entreprise, nous envisageons d’acheter des serveurs lames, plutôt que des serveurs rack. Bien sûr, les fournisseurs de technologie les rendent également très agréables. Un problème, que je lis très souvent dans différents forums, est qu’il existe une possibilité théorique que le châssis du serveur tombe en panne, ce qui aurait pour conséquence de supprimer toutes les lames. Cela est dû à une infrastructure partagée.

Ma réaction sur cette probabilité serait d’être redondante et par deux châssis au lieu d’un (très coûteux bien sûr).

Certaines personnes (notamment les fournisseurs HP) essaient de nous convaincre que le châssis est très peu susceptible d’échouer en raison de nombreuses redondances (alimentation redondante, etc.).

Une autre préoccupation de mon côté est qu’en cas de panne, des pièces de rechange pourraient être nécessaires - ce qui est difficile chez nous (Éthiopie).

Je demanderais donc à des administrateurs expérimentés ayant un serveur lame géré: quelle est votre expérience? Est-ce qu'ils disparaissent dans leur ensemble - et quelle est l'infrastructure raisonnable partagée qui pourrait échouer?

Cette question pourrait être étendue au stockage partagé. Encore une fois, je dirais que nous avons besoin de deux unités de stockage au lieu d’une seule - et encore une fois, les vendeurs disent que ces choses sont si solides qu’aucune panne n’est attendue.

Eh bien - j'ai du mal à croire qu'une infrastructure aussi critique peut être très fiable sans redondance - mais peut-être pouvez-vous me dire si vous avez des projets basés sur des serveurs performants, qui fonctionnent sans redondance dans ses composants essentiels (châssis, stockage ... )

Pour le moment, nous examinons HP - IBM semble beaucoup trop cher.

Il y a une faible probabilité de défaillance complète du châssis ...

Vous rencontrerez probablement des problèmes dans votre installation avant de subir une défaillance totale d'un boîtier de lame.

Mon expérience concerne principalement les boîtiers de lames HP C7000 et HP C3000 . J'ai également géré les solutions lames Dell et Supermicro. Le vendeur compte un peu. Mais en résumé, l'équipement HP a été excellent, Dell a fonctionné correctement et Supermicro manquait de qualité, de résilience et était simplement mal conçu. Je n'ai jamais connu d'échec du côté de HP et de Dell. Le Supermicro a eu de graves pannes, nous obligeant à abandonner la plate-forme. Sur HP et Dells, je n’ai jamais rencontré une défaillance complète du châssis.

• J'ai eu des événements thermiques. La climatisation est tombée en panne dans une installation de co-implantation, la température atteignant 46 ° C / 115 ° F pendant 10 heures.
• Surtensions et pannes de ligne: perte d’un côté de l’alimentation A / B. Pannes individuelles d’alimentation. Mes configurations de lame comportent généralement six blocs d'alimentation. Il y a donc beaucoup d'avertissements et de redondances.
• Échecs de serveur lame individuels. Les problèmes d'un serveur n'affectent pas les autres dans l'enceinte.
• Un feu dans le châssis ...

J'ai vu une variété d'environnements et ai eu l'avantage d'installer dans des conditions de centre de données idéales, ainsi que dans des endroits plus difficiles. Du côté des HP C7000 et C3000, l’essentiel est que le châssis soit entièrement modulaire. Les composants sont conçus pour minimiser l’impact d’une défaillance de composant sur l’ensemble de l’unité.

Pensez-y comme ceci ... Le châssis principal du C7000 est composé d'assemblages de fond de panier et de fond de panier avant (passif). L'enceinte structurelle maintient simplement les composants avant et arrière ensemble et supporte le poids du système. Presque toutes les pièces peuvent être remplacées ... croyez-moi, j'en ai démonté beaucoup. Les principales redondances concernent les ventilateurs / systèmes de refroidissement, l’alimentation, les réseaux et la gestion. Les processeurs de gestion ( Onboard Administrator de HP ) peuvent être associés pour la redondance, mais les serveurs peuvent fonctionner sans eux.

Boîtier entièrement peuplé - vue de face. Les six blocs d'alimentation situés en bas couvrent toute la profondeur du châssis et se connectent à un fond de panier d'alimentation modulaire situé à l'arrière du boîtier. Les modes d’alimentation sont configurables: par exemple 3 + 3 ou n + 1. Donc, l'enceinte a définitivement une redondance d'alimentation.

Enceinte entièrement peuplée - vue arrière. Les modules de réseau Virtual Connect à l'arrière disposent d'un répartiteur interne, ce qui me permet de perdre l'un ou l'autre des côtés tout en maintenant la connectivité du réseau aux serveurs. Il existe six blocs d'alimentation remplaçables à chaud et dix ventilateurs remplaçables à chaud.

Enceinte vide - vue de face. Notez qu'il n'y a vraiment rien dans cette partie de l'enceinte. Toutes les connexions sont transmises au fond de panier modulaire.

Assemblage du fond de panier enlevé. Notez les six alimentations pour l’assemblage du fond de panier central en bas.

Assemblage de midplane. C'est là que se passe la magie. Notez les 16 connexions de downplane distinctes: une pour chacun des serveurs lame. Des sockets / baies de serveurs individuels ont échoué sans tuer l'ensemble du boîtier ni affecter les autres serveurs.

Fond de panier d'alimentation. Unité 3ø en dessous du module monophasé standard. J'ai changé la répartition de l'alimentation dans mon centre de données et j'ai simplement échangé le fond de panier de l'alimentation pour gérer la nouvelle méthode d'alimentation en énergie.

Connecteur de châssis endommagé. Cette enceinte particulière a été abandonnée lors de l'assemblage, cassant les broches d'un connecteur de ruban. Cela a passé inaperçu pendant des jours et le châssis en cours de fonctionnement a attrapé FIRE ...

Voici les restes carbonisés du câble ruban du fond de panier. Cela contrôlait une partie de la surveillance de la température et de l'environnement du châssis. Les serveurs lames internes ont continué à fonctionner sans incident. Les parties touchées ont été remplacées à loisir pendant les temps morts, et tout allait bien.

Je gère un petit nombre de serveurs lame depuis huit ans maintenant et je n’ai pas encore eu de panne système qui a entraîné la mise hors ligne de plusieurs lames. Je suis devenu très proche en raison de problèmes liés à l'alimentation, mais je n'ai pas encore eu de panne du châssis non imputable à des sources extérieures.

Votre observation selon laquelle le châssis représente un point de défaillance unique est correcte, bien que ces derniers génèrent une grande quantité de redondances. Tous les systèmes lame que j'ai utilisés ont des alimentations parallèles aux lames, de multiples prises réseau passant par des chemins distincts et, dans le cas de plusieurs chemins Fibre Channel, des ports lame aux ports optiques de l'arrière de la baie. Même le système d’information du châssis avait plusieurs chemins.

Avec une ingénierie réseau appropriée (utilisation de la carte réseau redondante, MPIO pour le stockage), les événements à problème unique sont entièrement survivant. Au cours de ma période avec ces systèmes, j'ai eu les problèmes suivants, dont aucun n'a affecté plus d'une lame, le cas échéant:

• Deux blocs d'alimentation sont défaillants dans le rack de lames. Il y avait suffisamment de redondance dans les 4 autres pour supporter la charge.
• Perdre une phase pour une alimentation triphasée. Ces fournitures sont rares de nos jours, mais les deux autres phases avaient une capacité suffisante pour supporter la charge.
• Perdre une boucle de gestion inter-châssis. C'était comme ça pendant des années avant qu'un technicien vendeur ne le remarque.
• Perdre entièrement les boucles de gestion inter-châssis. Nous avons perdu l'accès à la console de gestion, mais les serveurs ont continué à fonctionner comme si de rien n'était.
• Quelqu'un a accidentellement redémarré le fond de panier réseau arrière. Tout dans ce châssis utilisait des cartes d'interface réseau redondantes, de sorte que le service n'était pas interrompu. tout le trafic s'est déplacé vers l'autre fond de panier.

Le point de TomTom sur le coût est très vrai cependant. Pour atteindre une parité de coûts complète, votre châssis de lames doit être entièrement chargé et ne pas utiliser d'éléments tels que des commutateurs de type "back-of-rack". Les racks à lames ont du sens dans les zones où vous avez vraiment besoin de densité, car votre espace est limité

Cette question pourrait être étendue au stockage partagé. Encore une fois, je dirais que nous avons besoin de deux unités de stockage au lieu d’une seule - et encore une fois, les vendeurs disent que ces choses sont si solides qu’aucune panne n’est attendue.

En fait non. Vos inquiétudes jusqu’à présent avaient un sens, cette phrase les met dans "lisez ce que vous avez sous les yeux". La haute disponibilité avec réplication complète est une fonctionnalité d'entreprise connue pour les unités de stockage. Le point essentiel est qu’une unité de stockage (SAN) est beaucoup plus complexe qu’un châssis en lame qui n’est finalement qu’un «métal stupide». Tout ce qui se trouve dans un châssis en lame peut être remplacé - tous les modules, etc., sont remplaçables et les lames individuelles Personne ne dit que le centre de la lame lui donne une grande disponibilité.

C'est très différent d'un SAN qui est censé fonctionner 100% du temps - dans un état cohérent - il y a donc des choses comme la réplication, etc.

CELA A DIT: surveillez vos chiffres. Je réfléchis à l’achat de lames depuis un certain temps déjà et elles n’ONT JAMAIS FAIT UN SENS FINANCIER. Les châssis sont tout simplement trop chers et les lames pas vraiment moins chères par rapport aux ordinateurs normaux. Je suggérerais de regarder l'architecture SuperMicro Twin comme alternative.

Les serveurs lames auxquels j'ai eu recours sont ceux d’IBM. Ceux-ci sont totalement modulaires et comportent beaucoup de redondances. Donc, si quelque chose devait échouer, ce serait l'un des composants, comme un bloc d'alimentation ou un commutateur modulaire, etc. Mais là encore, il y a une redondance.

Depuis que je suis impliqué dans les lames IBM, je n'ai jamais vu d'échec complet.

Avec les autres marques, je suppose qu'elles seraient construites de la même manière.
Ce serait une bonne idée de parler à un vendeur et de lire beaucoup.
C'est un gros investissement.

Les défaillances entraînant plusieurs pannes de serveur lame dans le même boîtier sont comparables (en termes de probabilité et de cause) à des pannes conduisant à des pannes multiples de serveur dans le même rack.

Configuration initiale pour minimiser les points de défaillance uniques (deux sources d'alimentation CA distinctes , chacune pouvant gérer la totalité de la charge, fonctionnant sur des alimentations en courant continu distinctes, de sorte que l'une ou l'autre puisse gérer la totalité de la charge; deux connexions réseau distinctes , l'une ou l'autre qui peut gérer la totalité de la charge attendue, etc.) et la différence entre quelque chose qui supprime toutes les lames d’un châssis ou tous les serveurs 2U d’un rack est très faible.

Un problème, que je lis très souvent dans différents forums, est qu’il existe une possibilité théorique que le châssis du serveur tombe en panne, ce qui aurait pour conséquence de supprimer toutes les lames. Cela est dû à une infrastructure partagée.

En effet! Il y a environ 5 ans, alors que je contrôlais deux boîtiers de lames HP Proliant p-Class, j'ai rencontré plusieurs fois des problèmes de châssis.

Certains serveurs lames ne peuvent pas être activés s'ils avaient été désactivés (les serveurs ne sont pas souvent désactivés, mais sont tout de même devenus un problème pour nous). Des serveurs se sont soudainement éteints et ne pouvaient plus être allumés. Enfin, tous les serveurs se sont éteints et ne pouvaient plus être allumés.

Si je me souviens bien, à peu près tous les problèmes ont été attribués à des fonds de panier d’alimentation de mauvaise qualité ou de fonds de panier de contrôleur. Ceux-ci ont été remplacés un certain nombre de fois et le message non spécifique et officieux que j'ai reçu de la part des techniciens était qu'ils avaient leur part de problèmes avec cette génération de boîtiers de serveurs lames.

À l'époque, j'avais décidé que l'avantage des serveurs lames ne valait tout simplement pas le risque, si j'avais quelque chose à dire lors de futurs achats.

Avance rapide à mon prochain employeur, et mon actuel, d'ailleurs. Les boîtiers HP Proliant c-Class fonctionnaient déjà, mon sentiment de chaleur était donc très important pour les lames. Au cours des 5 années où j'ai travaillé avec les boîtiers de classe C, je n'ai jamais rien vu de semblable à celui de la classe p, où un boîtier entier est tombé en panne. Ils ont fonctionné sans problèmes majeurs.

(Sauf le temps qu'une pluie d'orage a envoyé la pluie à travers le toit, 4 étages, un petit trou dans le sceau de la salle des ordinateurs, dans un câble et dans le châssis)

Les châssis DELL et HP Blade ne disposent pas d’un plan moyen redondant. C’est là que IBM Bladecenter s’avère gagnant. A ma connaissance, c'est le seul châssis lame offrant un plan médian redondant. Bien que HP propose une suite fantastique de logiciels de gestion pour les lames, nous avons acheté un Bladecenter E pour notre société simplement pour éviter un point de défaillance unique de l’ensemble du châssis.