82 votes

Choisir entre les noms d'hôtes significatifs et ceux qui ne le sont pas

Supposons un environnement avec un cluster géré par Puppet composé de différents serveurs - divers matériels, logiciels, systèmes d'exploitation, virtuels/dédiés, etc.

Choisiriez-vous des noms d'hôtes significatifs (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) ou préféreriez-vous des noms d'hôtes sans signification, comme les personnages d'un livre ou d'un film ?

Le problème que je vois avec les noms d'hôtes significatifs est que les noms représentent généralement un seul service et si un serveur a plus d'un objectif, cela devient vraiment désordonné (surtout si les rôles des serveurs changent souvent).

Le DNS n'est-il pas censé faire correspondre un nom de service à une adresse IP et maintenir cette correspondance ?

Quels sont les avantages et les inconvénients des deux approches et quels sont les problèmes réels que vous avez dû résoudre avec l'approche que vous avez choisie ?

98voto

MadHatter Points 77602

Il était une fois l'occasion de décider d'un système de dénomination. J'ai donc demandé à mes développeurs, qui étaient après tout les personnes qui devaient travailler avec ces noms au quotidien, s'ils préféraient fonctionnel des noms (c'est-à-dire des noms qui représentent, sous une forme codée, l'objectif de la machine) ou mnémotechnique des noms (c'est-à-dire des noms tirés d'un système de dénomination humain préexistant, qui ne contenait aucun contenu implicite sur l'objectif de la machine).

Sur 38 développeurs, 37 préféraient les noms mnémotechniques ; un seul préférait les noms fonctionnels. Je les ai donc tous nommés d'après des rivières (il y a un très grand nombre de noms possibles, et beaucoup d'entre eux sont courts, faciles à retenir et rapides à taper).

Le cerveau humain est assez bien conçu pour attacher une signification aux noms. Si vous proposez des noms mémorisables, les gens se souviendront assez rapidement de la signification de ces noms et les utiliseront. Si vous utilisez des noms tirés d'un contexte commun (par exemple, des rivières, des éléments, des étoiles, des comtés, des boissons, vous voyez le genre), cela aide les gens à reconnaître immédiatement le nom d'hôte d'une entreprise lorsqu'ils le rencontrent ; sinon, des affirmations comme "tous les courriels ont abouti sur betelgeuse "peut être un peu déroutant).

À l'inverse, mes développeurs ont estimé qu'ils avaient eu, dans leurs emplois précédents, beaucoup de mal à se souvenir exactement de ce qu'ils devaient faire. pr1ms001 était.

Mais je dois ajouter que nous avons utilisé des CNAME dans le DNS interne pour fournir une correspondance fonctionnelle entre le nom et le nom mnémonique, donc si vous avez vraiment trouvé plus facile de vous souvenir que le serveur de courrier principal du premier cluster du site PR était pr1ms001 alors le DNS vous ferait savoir que c'était actuellement orwell . De plus, cela nous permettait d'avoir de nombreux noms de fonction par machine, donc tant que vous utilisiez toujours le nom de fonction correspondant à la fonction sur laquelle vous travailliez, vous pouviez être sûr que pr1imap001 pointerait toujours vers le serveur IMAP, même si nous déplaçons cette fonctionnalité de orwell a rhine . Et quand hudson mort, nous pouvions changer le nom du remplaçant sans affecter les fonctions opérationnelles, de sorte que nous n'avons jamais eu la question "voulez-vous dire nouveau". hudson ou vieux hudson ?" confusion.

94voto

julio g Points 11

Cela dépend en grande partie du fait que vos serveurs soient pets o livestock .

Les animaux de compagnie ont des noms individuels. Ils sont distincts les uns des autres, et nous tenons à ces différences. Quand l'un d'entre eux tombe malade, nous essayons généralement de le ramener à la santé. Traditionnellement, les serveurs sont des animaux de compagnie.

Le bétail a des numéros. Ils sont pour la plupart identiques, et les différences qu'il y a ne nous intéressent pas et nous essayons généralement de les minimiser. Quand l'un d'eux tombe malade, on l'abat et on en prend un autre. Les serveurs entièrement virtualisés, en particulier les serveurs IaaS tels qu'AWS, sont du bétail.

Dans la plupart des environnements complexes, vous avez un mélange. Vos backends web, par exemple, sont presque certainement du bétail. Si vous en avez besoin de plus, vous en faites tourner quelques-uns de plus avec la configuration standard ; si vous n'en avez pas besoin d'autant, vous en désactivez certains. Vos serveurs de base de données, dans certaines configurations, sont des animaux domestiques. Il peut y avoir beaucoup de configurations spéciales sur chacun d'entre eux ; vous pouvez même les faire fonctionner sur du métal nu au lieu de les virtualiser.

Bien sûr, dans l'un ou l'autre environnement, vous pouvez nommer les SERVICES et vous adresser directement à eux. C'est une bonne pratique dans tous les cas ; vos développeurs ne devraient pas avoir besoin de connaître ou de se soucier du nom d'hôte réel d'un service. Le nom d'hôte doit être un détail purement opérationnel. Pensez donc à encoder dans les noms d'hôtes des informations utiles à votre personnel d'exploitation. Par exemple, il est souvent utile d'indiquer dans quel centre de données se trouve un serveur.

19voto

ewwhite Points 193555

Ce sujet a déjà été abordé ici...

Ma recommandation est une combinaison de noms fonctionnels et de noms mnémotechniques...

Si vous écrivez une application et qu'elle doit répondre aux besoins suivants ccts-logserver1 utilisez ce nom partout, mais faites-en un CNAME ou un alias. Le nom d'hôte réel peut être ce que vous voulez : un fruit ou un légume, une mythologie grecque ou un personnage de Seinfeld... mais cela vous donne une certaine souplesse lorsque vous devez associer des noms fonctionnels réels, tout en conservant quelque chose dont les gens peuvent se souvenir.

Pensez à l'exemple où mango le serveur de base de données échoue... mais est remplacé par quelque chose d'autre, par exemple peach . Peut-être que les processus et les applications existants ont besoin de voir cmt-prod-db1 . Vous pouvez permuter les systèmes, les construire sans conflits de noms et garder les applications (et les développeurs) heureux.

4voto

Insomnia Points 507

Là où je travaille, nous gérons plusieurs sites, plusieurs entreprises, dans plusieurs villes. Pour nous, les noms mnémotechniques ne peuvent pas fonctionner. Nous utilisons plutôt une forme abrégée qui décrit nos serveurs. Cela fonctionne bien dans notre cas car nous avons des clients qui peuvent avoir plusieurs bureaux sur différents domaines (ou un seul bureau sur plusieurs domaines, ou plusieurs bureaux sur le même domaine, ou tout cela à la fois !)

Pour nous, l'information contient Société/Domaine, ville, fonction, numéro. Ainsi, pour un contrôleur de domaine pour une société, disons Cypress à Chicago, ce serait :

CYPRCHDOM001 (Nous l'appellerons le DOM principal de Cypress dans la conversation)

CYPRCHSQL001 serait son serveur SQL, CYPRCHMGM001 serait son serveur de gestion (c'est-à-dire anti-virus, sauvegardes, etc.) et CYPRCHAPP001 serait un serveur d'applications mixtes. Facile à retenir, facile à trier, facile à enseigner.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X