Quels sont les schémas de nommage de serveur les plus faciles à gérer et les plus intéressants? [fermé]

Je suis curieux de voir quels schémas sont utilisés pour nommer les serveurs ...

Tout d'abord, toute personne qui choisit un schéma de dénomination doit lire la RFC 1178 - "Choisir un nom pour votre ordinateur" . Les gens parlent de cette question depuis aussi longtemps que les ordinateurs ont reçu des noms, alors lisez ce que les autres ont dit avant de réinventer la roue.

Mes propres pensées - J'ai tendance à décomposer les politiques de dénomination en thèmes et schémas .

L'utilisation d'un thème (par exemple les dieux grecs, les personnages de Dr. Who, les marques de vodka) fonctionne bien dans un petit réseau. Si vous avez moins de 20 hôtes, il est probable que vous ayez plusieurs configurations matérielles - éventuellement, chaque hôte a une configuration unique. Dans de tels cas, il est bon de pouvoir considérer chaque machine comme ayant une personnalité unique, car - il y a de fortes chances - qu'elle le fasse.

L'utilisation d'un schéma (par exemple, un nom construit à partir d'éléments de l'emplacement géographique, de la position du rack, de l'ID du matériel, etc.) fonctionne bien lorsque vous avez un grand nombre de machines avec des configurations matérielles et / ou logicielles identiques. Cela fonctionne également bien si vous devez communiquer sur la machine avec des personnes qui ne s'en occupent pas quotidiennement. Par exemple, si vous devez dire au personnel du CNO de réinitialiser une machine, un nom qui les aide à la localiser dans le rack peut être meilleur que de leur faire rechercher dans les racks une machine portant une étiquette particulière.

L'utilisation d'un nom fonctionnel (par exemple mail, web, serveur de fichiers) est une bonne idée pour les machines virtuelles, mais une mauvaise idée pour les hôtes physiques selon mon expérience. Les hôtes physiques finiront souvent par exécuter plusieurs fonctions (même lorsque ce n'est pas idéal), et les fonctions individuelles changeront dans l'utilisation des ressources et les exigences au fil du temps, de sorte qu'elles seront migrées vers d'autres hôtes.

Les problèmes avec les thèmes incluent:

• Ils fournissent généralement un petit groupe de noms. Une fois que vous n'avez plus de dieux romains, passez-vous au grec? Réutilisez-vous un nom d'un hôte à la retraite qui correspond à votre thème de dénomination ou choisissez-vous un nouveau nom à partir d'un nouveau thème pour éviter les problèmes et la confusion qui peuvent survenir lors de la réutilisation de nom?
• Ils laissent votre anthropomorphiser vos machines. C'est mauvais - les ordinateurs n'aiment pas ça. Si vous traitez vos machines comme si elles avaient une personnalité distincte, vous courez le risque d'ignorer les preuves qui vont à l'encontre de vos hypothèses sur le comportement de cette machine, ainsi que de supposer parfois qu'un défaut est dû à une machine particulière parce que «c'est se comporte toujours mal ".

Les problèmes avec les régimes comprennent:

• Il en résulte des noms d'hôtes plus difficiles à retenir. C'est beaucoup moins un problème lorsque vous avez une bonne gestion des systèmes en place, mais il est parfois utile de pouvoir rappeler instantanément qu'un problème particulier s'est manifesté plus d'une fois sur une machine particulière, ou qu'une machine particulière est celle qui est responsable de effectuer une fonction particulière.
• Si le schéma change, vous devrez peut-être renommer tous vos hôtes. Cela pourrait entraîner un grand nombre de modifications DNS, de modifications de configuration, de modifications de la liste d'accès et des autorisations, etc.

Dans le monde réel, les deux systèmes sont utilisés, parfois côte à côte. Par exemple, d'après mon expérience, les clusters de calcul haute performance ont toujours des noms. Le nom est souvent attribué à un nœud principal (qui est utilisé de manière interactive), tandis que les différents nœuds de cluster auront des noms tels que compute-01, highmem-01, storage-01, etc.

Et, comme mentionné précédemment, il est courant (et utile) pour les machines virtuelles et les hôtes physiques d'avoir des schémas de nommage différents.

Dans la catégorie intéressante, il y en a une de la réponse Stack Overflow

Éléments du tableau périodique. Nous utilisons également le numéro d'élément dans l'adresse IP, donc

Hydrogène = 192.168.0.1

Hélium = 192.168.0.2

etc.

Je suis très convaincu de la possibilité de nommer les serveurs physiques en fonction de leur emplacement (c.-à-d. Code de pays / code de ville / code du centre de données / étage / rack / rack-U-hauteur) et de serveurs logiciels / VM uniquement en fonction de leur fonction ( plate-forme / fonction / cluster / itération). Je sais que cela peut rendre les noms plus longs que de les nommer d'après les sept nains ou autre chose, mais c'est un excellent moyen de vous assurer que vous êtes plus `` à l'épreuve du temps '' et traite la virtualisation de manière structurée.

Par exemple, nous avons des serveurs VMWare appelés 044LONTH72G216 (cela localise un serveur exactement dans le monde) avec des machines virtuelles de serveur invité telles que NESQLC11S08. Vous pouvez toujours leur créer des noms courts pour le travail de l'équipe informatique interne, chacun faisant référence à ces noms plus longs et plus organisés.

J'espère que cela t'aides.

Nous avons commencé par nommer nos serveurs avec un thème particulier (livres de la Bible), mais au fur et à mesure que notre équipe informatique (et le nombre de serveurs) grandissait et devenait plus spécialisée - et comme nous avions plus de roulement de personnel, nous avons découvert que tout système de nommage qui ne se rapportait pas en quelque sorte à la fonction (ou l'emplacement) du serveur est devenu déroutant.

Les gens connaissaient les serveurs sur lesquels ils travaillaient régulièrement, mais lorsqu'ils travaillaient sur un nouveau projet, effectuaient des formations croisées ou essayaient d'aider un autre administrateur avec quelque chose, les choses étaient manquées parce que "personne ne savait que les psaumes étaient un serveur de messagerie" ou similaire.

Nous sommes maintenant revenus à un schéma de nommage plus descriptif.

Nous donnons à tous nos serveurs des noms en fonction de leur rôle, c'est-à-dire de ce qu'ils font.

Donc nos serveurs ont des noms comme

- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..

D'après mon expérience, les serveurs avec des noms non lisibles par l'homme (c'est-à-dire la méthode du schéma) ne sont pas gérables. J'ai souvent vu des caractères mal tapés entraînant l'application d'un mauvais serveur xyz, parfois avec des résultats désastreux.

Un nom lisible par l'homme avec des métadonnées associées stockées dans un champ de description ou similaire semble être moins sujet aux problèmes PEBKAC.

Eh bien, certains favoris perpétuels comprennent:

• dieux grecs
• Dieux romains (parfois indiscernables des «planètes»)
• Dieux nordiques (le serveur le plus mal élevé peut être Loki)
• Princes d'ambre
• Philosophes

Nous avons commencé avec Bert et Ernie à l'époque où un cluster de 2 microVAX 3400 était un gros problème pour l'entreprise. Nous sommes restés avec Sesame Street pendant un certain temps - Bigbird, Elmo, Grover, le compte (système financier), mais nous avons finalement dû suivre un schéma. Les éléments exacts du régime dépendent de la taille de votre entreprise, nous avons dû inclure:

Emplacement (abréviation de 2 lettres pour la ville) Division (la société a été formée en fusionnant 4 sociétés, nous avions donc une abréviation de 3 lettres pour celles-ci) Fonction (PDC, courrier, impression, www, etc.) Numéro de série (I 'ai toujours aimé avoir l'année et le mois dans un numéro de série)

Personnages Simpsons :)

J'ai eu un client qui a nommé des serveurs après les lapins Playboy. Cependant, cela n'a pas été largement diffusé en dehors de l'informatique. ;-)

J'ai aimé les nommer d'après de gros chats, mais OS X est venu et a ruiné cela pour moi.

Un autre favori est les types d'alcool. JimBeam, Beefeater, Stoli, etc. Différentes classes d'alcool étaient différentes classes de serveur. Gin pour les serveurs de messagerie, whiskies pour les bases de données, le PDC était toujours Moonshine.

À partir de tous les nouveaux systèmes cette année, nous commencerons à utiliser des noms descriptifs ennuyeux (courrier, impression, etc.), mais jusqu'à présent, nous utilisions des animaux - avec différents types d'animaux à des fins différentes: oiseaux, poissons, animaux de la jungle, etc.

Musiciens dans le top 40.

Ils changent assez souvent pour continuer à en fournir de nouveaux, mais plus important encore, ils seront suffisamment cryptiques pour toute personne de plus de 12 ans.

Nous avons tendance à avoir les initiales de l'entreprise suivies de sa tâche, suivie de son numéro, c.-à-d.

GSK-WEB-12
ST-DB-3

Nous utilisons cela, qui fonctionne assez bien.

• site (2 caractères)
• dev / test / live (3/4 caractères)
• fonction (3+ caractères)
• compter (2 caractères)
• vm ou non (2 caractères)

Dans les emplois que j'ai eus, j'ai vu les tendances suivantes autres que les classiques server01, server02, etc.:

• pierres précieuses
• poisson
• fleurs
• Personnages de Star Wars
• animaux

À l'université où j'étudie, ils utilisent les noms de différents personnages des histoires d'Astérix et d'Obélix. Tels que miraculix, astmatix etc.

Nos serveurs sont tous nommés d'après des animaux de compagnie. avec une légère ventilation par type. Tous les contrôleurs de domaine portent le nom d'oiseaux. Chiens pour classer et imprimer. Chats pour serveurs d'applications.