Quels sont les avantages réels des serveurs de consoles série (avec le matériel serveur moderne)?


13

Je travaille dans un nouvel environnement qui fait un usage intensif des serveurs de console série pour la gestion des serveurs. Ils sont complétés par des PDU commutées pour la gestion de l'alimentation. Ils n'utilisent pas les capacités DRAC des serveurs existants.

J'ajoute de nouveaux équipements HP ProLiant au site et je suis curieux de savoir les avantages des consoles série par rapport aux technologies ILO / ILOM / DRAC disponibles sur les serveurs modernes. Il s'agit d'un environnement Linux qui évoluera pour inclure davantage de systèmes Windows. Je vais utiliser un mélange de lames et de DL380. Supposons des versions entièrement sous licence / activées de l'OIT / DRAC sur tout équipement futur.

J'ai configuré des consoles série dans le passé et les ai trouvées particulièrement utiles pour l'équipement réseau. Je suis confus quant à leur avantage ou leur utilité dans un environnement où les serveurs auront une gestion intégrée des lumières éteintes.


1
Je voudrais souligner que la plupart, sinon toutes les unités de gestion, permettent l'accès au port série via l'interface de ligne de commande de l'IMU accessible via ssh ou telnet. Souvent, si une licence "avancée" est requise pour une console graphique via l'IMU, elle n'est pas nécessaire pour accéder au port série de cette façon. Ainsi, ce que vous voulez généralement demander, "pourquoi est-ce que je veux utiliser un boîtier séparé connecté au connecteur du port série physique plutôt que d'utiliser l'accès de l'IMU au port série?
cjs

Réponses:


8

J'ai configuré des consoles série dans le passé et les ai trouvées particulièrement utiles pour l'équipement réseau.

Dans le cas d'un équipement réseau. parfois, une console série est le seul moyen de gérer à distance l'appliance.

Je suis curieux de connaître les avantages des consoles série par rapport aux technologies ILO / ILOM / DRAC disponibles sur les serveurs modernes.

J'ai ce débat exact avec mes collègues. Je penche vers les technologies iLO / DRAC, tandis que d'autres veulent s'en tenir aux anciennes consoles série.

Voici quelques avantages des consoles série par rapport aux nouvelles technologies iLO / DRAC / IPMI.

  1. Il est vrai que iLO, DRAC et certaines implémentations IPMI prennent en charge KVM sur LAN. Cependant, dans tous les cas que j'ai vus, le KVM sur réseau local nécessite le téléchargement d'un package logiciel Java via mon navigateur, qui ouvre ensuite un client de type VNC au serveur distant. Ce logiciel a tendance à être bogué, lent et peu fiable. Certains de ces logiciels ignorent les paramètres réseau de mon navigateur et de mon système (comme le paramètre PROXY).

    une. Certains fournisseurs peuvent utiliser l'une des différentes implémentations IPMI pour différents modèles de matériel, et chacun a ses propres bizarreries funky (je parle de VOUS, Supermicro). Donc, vous pourriez avoir 100 serveurs tous du même fournisseur, mais il y a 3-4 puces IPMI / BMC différentes.

  2. Certaines personnes aiment la simplicité des consoles série. Apprendre à configurer les consoles série peut être une courbe d'apprentissage abrupte, mais une fois que vous les faites fonctionner, elles sont généralement assez solides et cohérentes.

  3. Si votre organisation dispose déjà d'une infrastructure de console série existante (par exemple avec tous les câbles, les adaptateurs DB9 avec les bons brochages, etc.), l'utilisation de consoles série sur un nouveau matériel peut être plus simple que la configuration de l'iLO / DRAC sur de nouveaux serveurs.

  4. FreeBSD et Linux ne peuvent avoir qu'une seule console principale et n'impriment que certains messages (comme l'invite FSCK) sur la console principale. Vous devez choisir la console série ou la console VGA (par exemple le clavier / vidéo / souris connecté et, par extension, le KVM sur LAN); pas les deux.

  5. IPMI expose certaines informations puissantes au réseau, donc placer IPMI sur votre réseau doit être fait avec soin. De nombreux magasins placent IPMI sur un réseau séparé, non routable et sécurisé. Un tunnel VPN ou SSH peut être utilisé pour accéder en toute sécurité aux services IPMI, mais regardez simplement certaines des solutions louches que certains d'entre nous doivent faire juste pour accéder à la console IPMI.


2
Un avantage supplémentaire: la cohérence de l'accès. Ayant travaillé dans un environnement où nous avions l'OIT, Drac, ILOM et IPMI, ainsi que de vrais serveurs d'accès à la console série, il y avait quelque chose à dire sur la possibilité d'utiliser un seul outil pour accéder à chaque système de la même manière, à chaque fois, peu importe ce que le système était réellement.
Travis Campbell

4

Ceinture et bretelles? La carte iLo / DRAC / SupII (aussi utile soit-elle!) Est encore un autre appareil informatique sanglant avec son propre firmware et ses bogues; cela peut vous gêner. L'accès série, en particulier pour les systèmes d'exploitation orientés console comme U * x, peut toujours être utile, en particulier en cas d'urgence.

Maintenant, pour Windows, il est presque inutile pour la plupart des applications sysadmin.


Bien que, selon l'un de mes amis consultants Windows, il soit possible d'exécuter Windows sans interface graphique et de n'avoir qu'une interface de ligne de commande. Je n'ai pas vu cela en personne, donc c'est juste du ouï-dire pour moi, mais je pense que si ce n'était pas pour l'omniprésence de Linux, cela ne serait jamais arrivé.
Red Tux

Cela s'appelle Windows Server Core. C'est probablement une réponse à Linux; mais comme si peu de composants Windows peuvent être configurés à l'aide de fichiers texte, c'est un PITA pour faire beaucoup de choses. Il encourage la configuration et la gestion à distance (généralement une bonne chose) mais il réduit le nombre de choses que vous pouvez faire facilement sur la console (pas une grande chose à mon avis.) Cela me rappelle le vieux Netware, à certains égards.
mfinni

1
Et Core est TOUJOURS une interface utilisateur graphique - c'est un bureau graphique avec rien , mais deux fenêtres CMD. Ce n'est pas comme si vous pouviez vous connecter à Core via série et faire de la merde - donc mon argument est le même, AFAIK.
mfinni

Sérieusement? Wow, c'est un échec ...
Red Tux

4

Je suis en train de passer un contrat pour une entreprise qui utilise DRAC en conjonction avec des consoles série.

La société en question n'a pas dépensé d'argent pour obtenir du matériel DRAC de niveau entreprise avec console distante, mais iDRAC6 Express offre toujours certains avantages, le plus fort étant la possibilité de surveiller à distance l'état du matériel et d'effectuer l'installation du micrologiciel.

Si je comprends bien, l'iDRAC Express utilise un port Ethernet partagé (eth0 sur la carte mère). Si vous êtes dans la situation où vous en avez besoin pour une utilisation en production, vous n'avez aucune chance de déplacer votre accès DRAC à un réseau hors bande (OOB), ce qui est la meilleure pratique. À l'aide d'un serveur de console, vous pouvez au moins avoir accès à un réseau OOB, même si la présence de ce port partagé sur le réseau commun a toujours des conséquences sur la sécurité.


J'achète généralement du matériel avec des licences complètes OIT ou DRAC, afin de pouvoir obtenir la séparation nécessaire entre les réseaux en tirant parti de la carte réseau de gestion dédiée. Toutes choses égales par ailleurs, choisiriez-vous une carte réseau DRAC dédiée plutôt qu'une console série?
ewwhite

1
Toutes choses égales par ailleurs, probablement. Mis à part les avantages que j'ai mentionnés, la capacité de faire du vélo à distance est excellente. Le KVM distant est également très pratique, et de nombreux DRAC prennent en charge la présentation de support virtuel à distance (présentant le serveur distant un ISO sous forme de CD-ROM). Vous ne pouvez pas obtenir cela avec une connexion série.
Matt Simmons

1
La plupart de ces cartes fournissent également de bons rapports d'état du serveur sur lequel elles vivent, ce qui est également très agréable. J'ai même écrit quelque chose à SSH dans tous nos contrôleurs de gestion de châssis Dell et jeté le statut (pour trouver des disques morts dans des matrices RAID, un mauvais PS, etc.), jusqu'à ce que nous obtenions un véritable outil de gestion central.
mfinni

mfinni: Avez-vous étudié OpenManage?
Matt Simmons

@MattSimmons - La console de gestion Dell ressemble actuellement à une bête immature immature, et se superpose trop à SCOM et au plug-in Dell VMware, qui sont tous deux dans un avenir proche. J'étudie OME comme un arrêt décent pour les correctifs du firmware et la gestion de la lumière.
mfinni

3

Pour moi, le principal avantage serait de capturer des oops / journaux de plantage. Avec les goûts de l'OIT, vous perdez tout ce qui sort de l'écran. La console série vous permet de collecter le tout et de l'enregistrer sans utiliser d'appareil photo.


1
Le BIT peut effectuer une relecture sur console, je crois. Ou s'il s'agit d'un vilain crash qui ne déclenche pas le redémarrage du minuteur de surveillance, les restes sont généralement affichés à l'écran lorsque vous vous connectez.
ewwhite

Vous avez raison, ewwhite, mais je pense que vous devez le configurer spécifiquement de cette façon.
gWaldo

@ewwhite C'est mon point "les restes" :). Et je ne connaissais pas la fonctionnalité de relecture, merci pour l'information.
Paweł Brodacki

1
D'accord, c'est une situation. Proposez-vous des consoles série utilisées conjointement avec la technologie de l'OIT? Je suppose que je ne suis pas habitué aux plantages qui laissent des traces qui ne peuvent être récupérées que par la sortie de la console (par rapport à un journal IML, des journaux système, etc.)
ewwhite

Je n'ai pas du tout l'habitude de planter des systèmes, mais j'aime être préparé. J'aime l'approche bell & bretelles. Bien sûr, si une solution unique fonctionne et que vous êtes à l'aise avec elle, et qu'il y a tellement de systèmes, qu'économiser 20 minutes de configuration sur un est un avantage tangible, alors il peut être raisonnable d'en choisir une. Sinon, j'irais pour les deux. Pour certaines personnes / utilise une approche / un outil sera plus pratique que l'autre.
Paweł Brodacki

2

Je pense que vous devez évaluer le problème que vous essayez de résoudre avec une console série, KVM sur IP ou iLO.

  1. Console série: fondamentalement bonne si vous avez besoin d'un accès hors bande à la ligne de commande de l'iLO. Au cours de mes six années en tant qu'ingénieur système, je n'en ai jamais eu besoin. Dans une certaine mesure, cela est encore moins utile dans un environnement virtuel. Étant donné que vous pouvez SSH dans le périphérique iLO, cela n'est utile que dans une situation où vous avez besoin d'accéder à iLO et la connexion réseau peut être en panne, ou l'iLO ne répond pas.
  2. KVM sur IP: fondamentalement bon si vous ne disposez pas d'iLO advanced ou si vous ne souhaitez pas utiliser de proxy via un KVMoIP pour accéder à vos serveurs. J'aime l'idée d'avoir un endroit où je peux aller pour accéder à la console à tous mes serveurs, au lieu d'avoir à établir des connexions individuelles avec chaque serveur. Cette solution est idéale lorsque vous avez une tonne de serveurs physiques. Un autre bonus est que vous n'avez pas à payer pour un iLO avancé chaque fois que vous obtenez un nouveau serveur.
  3. iLO Avanced: fournit toutes les fonctionnalités dont vous avez besoin pour accéder à votre serveur à distance. Le véritable inconvénient est simplement le manque de gestion centrale (au moins par lui-même). Bien sûr, vous avez également accès à des éléments comme un matériel défectueux.

Cela dit, tous ces éléments peuvent être combinés en une solution massive, ou vous pouvez choisir. La plupart des consoles KVMoIP ou série modernes sont actuellement combinées en une seule unité, vous pouvez donc en théorie avoir une console KVMoIP et série connectée au même commutateur. Il mange cependant deux ports de console (un pour le port série et l'autre pour le KVM). À mon humble avis, brancher sur le port série n'est pas une énorme victoire. Vous feriez mieux avec soit l'iLO avancé, KVMoIP ou les deux


D'accord, utilisez donc la fonctionnalité série pour vos périphériques réseau et la fonctionnalité IP-KVM pour les serveurs? Y a-t-il un besoin de toujours utiliser la série pour le côté serveur des choses?
ewwhite

Je suis désolé, dites-vous que le port série de votre iLO est branché sur la console série? Je supposais en quelque sorte que vous aviez une console série / KVM légèrement plus récente. Signifiant avocat par exemple, fait une console série et KVM dans le même commutateur.
Eric C. Singer

L'entreprise utilise des consoles série uniquement qui utilisent les ports série du serveur. Il n'y a aucune fonctionnalité GUI ou ILO.
ewwhite

Pour les utilisateurs HP: la console série peut être utilisée après le démarrage même si vous n'avez pas iLO Advanced, ce qui peut être utile dans certaines situations. Bien sûr, vous devez le configurer à l'avance.
GreenReaper

0

Une chose qui n'a pas été mentionnée jusqu'ici mais qui est plutôt implicite est la possibilité de directement SSH d'un système dans la console d'un hôte sans avoir besoin d'une application spéciale (souvent écrite en Java) pour afficher la console distante. Ainsi, il est plus facile de mettre un système dans un colo derrière une boîte de saut ssh et ssh dans le système via la console série. Cela est dû au fait que souvent plusieurs ports TCP sur le serveur de console série peuvent être associés à des ports série physiques sur la boîte. De plus, certains serveurs de console série vous permettent d'installer des clés SSH et n'autorisent que les connexions utilisant ces clés ssh préinstallées. Ceci est très utile lorsque vous devez placer un serveur de console ssh sur Internet directement dans les situations où vous avez besoin d'un moyen externe (à votre réseau) pour accéder aux routeurs de périphérie et à d'autres équipements / systèmes.

Les serveurs de console SSH-Serial ne sont pas le dernier mot dans l'administration des systèmes, tout comme iDRAC et d'autres outils similaires ne sont pas le dernier mot, ce sont plutôt des outils qui répondent à un besoin spécifique et peuvent souvent se compléter.


Tous les systèmes de l'OIT que je connais fournissent un accès au port série sur le réseau; vous pouvez simplement ssh dans un système sur le réseau de gestion et à partir de là ssh / telnet / quoi que ce soit dans l'unité de gestion et tapez quelque chose le long de la "console 1" pour accéder au port série.
cjs
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.