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

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?

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.

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.

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.

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.

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.