Choisir entre des noms d'hôtes significatifs et sans signification [fermé]


79

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

Souhaitez-vous choisir des noms d’hôtes significatifs (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) ou préférez-vous des noms d’hôte sans signification tels que des 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 que si un serveur a plusieurs objectifs, il devient vraiment compliqué (surtout si les rôles de serveur changent souvent).

Le mappage d'un nom de service sur une adresse IP et le maintien de ce mappage n'est-il pas ce que le DNS est censé faire?

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


10
Si vous contrôlez DNS, vous pouvez toujours faire les deux.
Jscott

16
Je vais le laisser ici: RFC 1178
mercredi

Bien que superficiellement une question d’opinion, les réponses sont basées sur des faits et reposent sur des sondages empiriques et sur la fonction cognitive humaine (comment le cerveau humain se souvient des choses). A mon avis, cette question devrait être rouverte.
dotancohen

Réponses:


98

Il était une fois l'occasion de choisir un schéma de nommage. J’ai donc demandé à mes développeurs, qui après tout étaient ceux qui devaient travailler avec ces noms au quotidien, s'ils préféraient des noms fonctionnels (c'est-à-dire des noms qui représentent, sous une forme codée, les nom de la machine) ou des noms mnémoniques (c’est-à-dire des noms tirés d’un schéma de nommage humain préexistant, qui ne contenait aucun contenu implicite concernant le but de la machine).

Sur 38 développeurs, 37 noms mnémoniques préférés; un seul nom fonctionnel préféré. Je les ai donc toutes nommées après les rivières (il existe une très grande réserve de noms possibles, dont beaucoup sont courts, faciles à mémoriser et rapides à taper).

Le cerveau humain est assez bien conçu pour attribuer une signification à des noms. Si vous fournissez des noms mémorables, les gens vont rapidement se rappeler à quoi ils servent et les utiliser. Si vous utilisez des noms tirés de certains fondements communs (par exemple rivières, éléments, étoiles, comtés, boissons, vous en avez l'idée), cela aide les utilisateurs à reconnaître immédiatement le nom d'hôte d'une entreprise lorsqu'ils le rencontrent; sinon, des déclarations telles que "tous les courriels ont fini betelgeuse" peuvent être un peu déroutantes).

Inversement, mes développeurs ont eu le sentiment qu’ils avaient déjà eu du mal à se souvenir de ce qu’ils occupaient auparavant pr1ms001.

Mais je dois ajouter que nous avons utilisé les CNAME dans le DNS interne pour fournir un nom fonctionnel au mappage de noms mnémoniques. Par conséquent, si vous trouviez vraiment plus facile de vous souvenir que le serveur de messagerie principal du premier cluster du site PR était pr1ms001, le DNS vous faire savoir que c'était actuellement orwell. De plus, cela nous donne plusieurs noms fonctionnels par machine. Ainsi, tant que vous utiliserez toujours le nom fonctionnel correspondant à la fonction sur laquelle vous travailliez, vous pouvez être sûr que pr1imap001cela pointe toujours vers le serveur IMAP, même si nous déplacions cette fonctionnalité. de orwellà rhine. Et quand hudsonnous sommes décédés, nous avons pu changer le nom du remplaçant sans affecter les fonctions opérationnelles, de sorte que nous n’ayons jamais eu la phrase «veux-tu dire nouvelle hudsonou ancienne hudson? confusion.


7
Vous pensez peut-être cela, mais mes développeurs ont dit que le schéma mnémonique était préférable, que quelque chose de plus soit communiqué, car ils ont tous construit leurs propres tableaux d'état internes indiquant où se trouve l'endroit, et il est plus facile de construire ce type de mémoire sur des noms qui le cerveau humain aime se souvenir.
MadHatter

11
Vous auriez dû les nommer d'après les volcans d'Islande.
Chloé

1
+1 pour "piscine des fleuves";)
Konerak

2
C'est une idée géniale et je la vole.
SpacemanSpiff

1
Je conviens que nommer les serveurs de cette manière représente davantage un travail avec un système de construction automatique, mais je remarque que le but de leur construction est de permettre à d'autres personnes de les utiliser - et les données ci-dessus proviennent des personnes qui ont dû les utiliser . Peut-être que ce qu’ils veulent a changé, mais je pense que nos décisions concernant l’administration du serveur devraient reposer sur plus que ce qui rend notre travail facile.
MadHatter

93

Cela dépend en grande partie de savoir si vos serveurs sont petsou livestock.

Les animaux obtiennent des noms individuels. Ils sont distincts les uns des autres et nous nous soucions de ces différences. Quand on est malade, on essaie généralement de le soigner. Traditionnellement, les serveurs étaient des animaux domestiques.

Le bétail reçoit des chiffres. Ils sont pour la plupart identiques et, quelles que soient les différences, nous ne nous en soucions pas et essayons généralement de les minimiser. Quand on tombe malade, on le dépose et on en prend un autre. Les serveurs entièrement virtualisés, en particulier les serveurs IaaS tels qu'AWS, constituent du bétail.

Dans la plupart des environnements complexes, vous avez un mélange. Vos serveurs Web, par exemple, sont presque certainement du bétail. Si vous avez besoin de plus d’informations, vous pouvez en ajouter quelques unes avec la configuration standard; si vous n'en avez pas besoin, 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 configuration spéciale sur chacun; vous pouvez même les exécuter sur du métal nu au lieu de la virtualisation.

Bien sûr, dans les deux environnements, vous pouvez nommer SERVICES et les adresser directement. C'est une pratique exemplaire dans tous les cas. vos développeurs ne devraient pas avoir besoin de savoir ou de se préoccuper 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 à coder des informations utiles pour le personnel de votre système d’exploitation dans les noms d’hôte. Par exemple, il est souvent utile d'indiquer le datacenter dans lequel se trouve un serveur.


22
Les animaux domestiques ou le bétail - c'est une bonne façon de le dire.
Michael Hampton

5
J'ai récemment retrouvé l'article dans lequel j'ai découvert ce concept dans: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets
Thaeli

Merci @Ian Je suis à la recherche du dernier jour de cet article, échec du référencement hein
Rudolf Olah,

18

Cela a été couvert ici avant ...

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

Si vous écrivez une application et qu'elle doit être adressée ccts-logserver1, utilisez toujours ce nom, mais faites-en un CNAME ou un alias. Le vrai nom d’hôte peut être ce que vous voulez: un fruit ou un légume, la mythologie grecque ou le caractère de Seinfeld ... mais il vous donne une certaine flexibilité lorsque vous devez associer de vrais noms fonctionnels, tout en gardant quelque chose dont les gens se souviennent.

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


4

Où je travaille, nous gérons plusieurs sites, plusieurs sociétés, dans plusieurs villes. Pour nous, les noms mnémoniques ne peuvent pas fonctionner. Au lieu de cela, nous utilisons un formulaire abrégé qui décrit nos serveurs. Cela fonctionne bien dans notre cas car nous avons certains 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 ce qui précède!)

Pour nous, les informations contiennent Société / Domaine, ville, fonction, numéro. Donc, pour un contrôleur de domaine pour une entreprise, dit Cypress à Chicago, ce serait:

CYPRCHDOM001 (Nous appelons cela le principal DOM de Cypress en conversation)

CYPRCHSQL001 serait son serveur SQL, CYPRCHMGM001 en serait la gestion (antivirus, sauvegardes, etc.) et CYPRCHAPP001 serait un serveur d'applications mixtes. Facile à retenir, facile à trier, facile à enseigner.


1
Alors, comment vous rappelez-vous quelles applications fonctionnent sur CYPRCHAPP001 par opposition à CYPRCHAPP003? J'admets que c'est également un problème de noms mnénomiques, mais si vous choisissez des noms fonctionnels, soyez tout aussi précis.
un CVn

2
@ MichaelKjörling Les détails de grain précis de ce qui se trouve sur un serveur n'appartiennent pas à un nom, mais à une sorte de documentation. Si quelqu'un a besoin de savoir ce qui fonctionne sur CYPRCHAPP001, il lit la documentation. CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc sera un abus de langage lorsque la société déplacera son logiciel de gestion de la paie vers une solution hébergée.
Wulfhart

2
@Wulfhart Je suis d' accord avec votre point, mais ce qui ne va pas d'avoir CNAMEs pour pointofsale, payrolletc.? De cette façon, seuls les administrateurs système n'ont pas à se préoccuper de savoir exactement où le logiciel de paie est exécuté. pour tout le monde, ça marche. Vous voulez déplacer quelque chose dans un autre centre de données? Aucun problème du tout. Vous souhaitez déplacer la base de données du système de point de vente sur son propre serveur dédié? Il suffit de mettre à jour le pointofsale-databaseCNAME pour qu'il pointe vers le nouvel emplacement. Etc.
un CVn

1
Supposons que vous deviez remplacer une machine: une fois que vous avez créé CYPRCHSQL002 et que vous l’avez testé, supprimez-vous simplement le nom CYPRCHSQL001 (qui ne doit jamais être remplacé), ou renommez-vous les noms 002 à 001 après avoir supprimé l’ancien 001, ou quelque chose de ce type; autre?
nickgrim

@ MichaelKjörling Cela me semble une excellente idée. Par "les détails n'appartiennent pas à un nom", je voulais dire pas dans le nom d'hôte de la machine.
Wulfhart

2

La seule condition requise pour les noms d'hôte est qu'ils doivent être uniques sur le réseau.

La signification ne doit pas uniquement concerner la fonction des serveurs. L'emplacement peut être très utile si vous devez faire face à des périphériques physiques. Savoir si un périphérique est virtuel ou physique peut également être utile. Être capable de faire la différence entre un périphérique réseau, un serveur linux et une boîte de dialogue Windows peut être très pratique pour déterminer quel outil utiliser pour se connecter.

Pour y remédier, essayez d’inscrire ces informations dans le nom du périphérique comme suit:

L ou T - En direct ou Test P ou V - Physique ou virtuel S ou N - Serveur ou réseau (nous n’avons aucun serveur Linux) un numéro séquentiel pour garantir l’unicité. Code de pays ISO 3166-1 de trois lettres indiquant l’emplacement du périphérique. est situé.

Nous utilisons ensuite CNAMES dans DNS pour mapper divers noms de services avec le nom d’hôte.

J'ai des sentiments mitigés à ce sujet. Cela permet certainement de gagner du temps en recherchant l'emplacement d'un certain appareil. D'autre part, il est beaucoup plus difficile de se rappeler ce que fait un serveur lorsqu'il reçoit son nom d'hôte, par rapport à notre système précédent qui utilisait des pierres précieuses. Les pierres précieuses n’entraînaient aucun sens, mais elles étaient faciles à retenir car chaque personne pouvait créer ses propres relations.

Je suppose que le seul conseil serait d’adopter un schéma car la plus grande confusion s’est produite lors de la transition d’un système à l’autre.


Je ne suis pas d’accord avec ceci: "Savoir si un périphérique est virtuel ou physique peut aussi être utile" dans le contexte d’une discussion sur les noms . Bien sûr, ces informations sont utiles, mais ce n’est pas la première chose à savoir sur un serveur en lisant son nom. En outre, P2V ou V2P rompt votre schéma ou nécessite de renommer le serveur, ce qui peut empêcher d'autres éléments.
Mfinni

1
Selon mon expérience, le P2V ou le V2P casse tout un tas de choses et devrait être évité autant que possible - nous le faisons, ce n’est donc pas un problème avec notre convention de nommage. La convention de dénomination doit répondre aux besoins de celui qui la conçoit - dans l'organisation dans laquelle je travaille, elle a été conçue par l'équipe qui gère tous les serveurs et équipements de réseau, et ceux-ci veulent pouvoir dire ce qui précède. Ce n'est peut-être pas juste pour vous, mais tout peut faire l'objet d'un débat. La seule exigence technique est l'unicité.
dimanche
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.