Quelle convention de nommage utiliser pour ses serveurs ?

I. Présentation

Établir une convention de nommage afin de donner un petit nom à chacun de ses serveurs, c’est à la fois très simple à expliquer et compliquer à maîtriser.

Tout le monde comprend l’intérêt de nommer des serveurs plutôt que de retenir leur adresse IP. C’est d’ailleurs le principe de la technologie DNS, qui est au cœur d’Internet.

Mais à vouloir être trop créatif ou à vouloir mettre trop d’informations, on peut très vite s’y perdre, et la gestion de nos serveurs peut vite ressembler à un casse-tête.

Du coup, je vous vois venir, vous allez me demander comment faire pour choisir une convention pratique, facile et efficace afin de nommer vos serveurs.

Parce que soyons honnête deux minutes, avoir un serveur qui s’appelle Astérix ou SRVWEB112, c’est bien, mais quand on se pose pour la huitième fois de la journée la question du rôle précis de ce serveur (production ? test ? développement ? Et hébergement de quelle application web au juste ?), c’est qu’il est temps de faire quelque chose. 😉

II. Les serveurs ne sont plus ce qu’ils étaient

À une époque pas si lointaine que ça, les serveurs étaient physiques. On pouvait les toucher, les aligner physiquement sur des étagères dans nos salles serveurs.

C’était quelque chose de concret. Et puis la virtualisation et le cloud sont arrivés, et le monde a changé.

Mais à l’époque, lorsqu’on achetait un nouveau serveur, c’était une machine physique qui allait occuper de la place dans notre salle serveur. Ça n’arrivait pas tous les jours. Et on gardait nos serveurs parfois pendant 10 ans.

Ça a changé depuis maintenant plusieurs années. Avec l’avènement du cloud et de la virtualisation (et maintenant des containers), on peut littéralement créer de nouveaux serveurs en moins de 60 secondes, et ce de manière entièrement automatisée.

On est passé de la gestion d’une dizaine de serveurs physiques à la gestion de centaines de serveurs et containers virtuels.

Là où on configurait notre système d’information dans la durée, on monte maintenant parfois des serveurs pour quelques minutes ou heures afin de tester une application.

Et notre manière de les nommer doit évoluer afin de s’adapter à cette nouvelle réalité.

III. L’art de nommer ses serveurs

Le nom d’un serveur est un choix des plus importants pour un sysadmin, d’autant plus qu’il l’utilisera derrière au quotidien.

Sondez votre entourage si vous ne me croyez pas : si vous trouvez quelqu’un qui utilise les IPv4 et les IPv6 au lieu des hostname des serveurs, je veux bien manger ma casquette. 😊

Trêve de plaisanterie, chacun y va de sa manière pour nommer ses serveurs. Il n’y a pas de bonne ou de mauvaise manière de nommer un serveur, à partir du moment où vous êtes capables de retrouver vos petits sans vous plonger dans une documentation de 500 pages.

Voici un tour d’horizon des conventions de nommage les plus répandues. Personnellement, je suis un adepte de la méthode du berger.

A. Laisser parler sa créativité

Si vous aimez les noms de serveurs évocateurs, vous êtes servi, et c’est probablement la méthode à privilégier.

Je me souviens d’entreprises et de sysadmin qui avaient choisi des conventions de nommage originales :

  • Chaque serveur portait le nom d’un personnage du Seigneur des anneaux : Gandalf pour le serveur de fichiers par exemple.
  • Les serveurs Linux avaient tous un nom se terminant en -us : Sinus, Cosinus, Proximus, etc
  • Noms de serveurs inspirés des héros et dieux de la mythologie grecque, romaine, etc.

Le souci, c’est que dès que vous multipliez les serveurs, ça devient compliqué de se souvenir du rôle d’Astérix par rapport à Hercule. Du coup, ça vous oblige régulièrement à consulter votre documentation pour vous rappeler exactement de qui fait quoi.

Par contre l’avantage, c’est qu’un attaquant ne peut pas déduire le rôle d'un serveur à partir de son nom.

Personnellement, je ne vous conseille pas d’utiliser cette méthode, car vous pouvez vite vous mélanger les pinceaux, mais après tout, un nom de héros est toujours plus évocateur qu’un classique SRVFIC01.

B. La méthode itérative

Lorsqu’on a commencé à multiplier les serveurs (un rôle = un serveur virtuel), on a essayé d’attribuer des noms plus évocateurs à nos serveurs.

Sont donc apparus les SRVAD01, SRVFIC03, SRVWEB112, etc.

Le nom est certes évocateur et vous permet d’identifier rapidement qui fait quoi, mais si je vous demande quelle est la différence entre SRVWEB87 et SRVWEB112, vous allez bien vous creuser les méninges.

Ok, ce sont deux serveurs web. Mais tournent-ils sous Windows / IIS ? sous Linux / Apache ? Et pour quelle application ? Mystère...

Autre problème que cette méthode amène : Vous migrez SRVFIC01 et SRVFIC02 sur 2 nouveaux serveurs : SRVFIC03 et SRVFIC04. Puis vous supprimez les deux premiers, car ils sont vieillissants.

Pour un petit parc d’une cinquantaine de serveurs, c’est assez simple à suivre, mais pour un parc de serveurs conséquent, vous vous demanderez toujours s’il existe 4 serveurs de fichiers, ou seulement 2. Et si vous devez en ajouter un nouveau, faut-il l'appeler SRVFIC05, ou peut-on réutiliser SRVFIC01 ? À première vue si le serveur n'existe plus, on est tenté de dire que c'est OK. Mais peut-être y a-t-il des redirections DNS de SRVFIC01 vers SRVFIC03.

Bref, c'est mieux que la méthode précédente, mais je ne pense pas que cela soit viable sur le long terme, ou dans le cas d'une infrastructure multi cloud scalable.

C. La méthode préfixe - suffixe

Un nom du style SRVWEB112 permet de donner une information sur le rôle du serveur. Mais on est toujours dans le flou en ce qui concerne l’environnement du serveur, ainsi que sa localisation.

On utilise donc couramment des préfixes ou des suffixes pour cela. Par exemple :

  • P pour un serveur de Production
  • D pour un serveur de Développement
  • T pour un serveur de Test

On choisit aussi souvent un préfixe de 3 lettres pour indiquer la localisation du serveur : utile lorsque nos serveurs sont éparpillés sur plusieurs sites ou datacenters. Par exemple, on pourrait choisir PAR pour indiquer que le serveur est hébergé à Paris, ou BDX pour indiquer qu’il se trouve à Bordeaux.

PARPSRVWEB04
BDXTSRVFIC02

Cela permet de donner beaucoup d’informations dans le nom de votre serveur, ce qui est toujours un plus quand vous devez administrer un gros parc de serveurs, ou par exemple un parc de serveurs multi-clients. Cependant, ça implique d’avoir un document décrivant avec exactitude les différents sigles utilisés. Et l’inconvénient majeur, c’est bien sûr qu’en cas d’attaque informatique, vous transmettez de précieuses informations à votre attaquant, via le nom du serveur.

Mais personnellement, je pense que le risque en vaut quand même la chandelle.

D. La méthode du berger

Pourquoi la méthode du berger ? Car on va considérer nos serveurs comme on considère un troupeau de moutons.

On a tendance à avoir aujourd’hui de plus en plus de machines, et on démultiplie les environnements : Production, Dev, Test, Préprod, Qualification, etc...

Et contrairement à il y a quelques années, nos serveurs ont pour certains une durée de vie éphémère : parfois de l’ordre de quelques minutes, le temps de tester une nouvelle fonctionnalité avant déploiement en production.

Pour des questions de haute disponibilité, on a aussi aujourd’hui nos serveurs qui sont éparpillés chez différents providers / hébergeurs, ce qu'on appelle le multi cloud : Azure, AWS, GCP, Digital Ocean, Cloud privé, etc, ce qui complexifie la gestion.

Dans ce contexte là, pour savoir où se trouve réellement SRVVWEB112 et quel est son rôle, pas le choix, vous devrez vous taper les 500 pages de documentation interne, en priant pour qu’elle soit à jour.

On a donc une nouvelle méthode de nommage qui a vu le jour : on regroupe ainsi nos serveurs par cluster indépendant, qui correspondent à des applications.

Par exemple, pour faire tourner mon site web, disons que j’ai les serveurs suivants :

  • 2 serveurs web
  • 1 serveur de cache
  • 2 serveurs base de données

Ces serveurs vont donc appartenir au cluster applicatif « webprod ».

Et comme ils sont potentiellement hébergés aux quatre coins du monde, je vais indiquer dans leur hostname leur localisation, ainsi que le nom du provider chez qui ils sont, ce qui nous donnera :

<cluster-applicatif>-<rôle><id>-<localisation-datacenter>-<provider>.<domaine>

Dans notre cas, pour un serveur web hébergé chez AWS dans le datacenter de Paris, cela pourrait donner :

Webprod-web1-par-aws.mondomaine.com

L’avantage de cette méthode, c’est qu’elle est scalable, vous pouvez donc rapidement déployer de nouveaux serveurs pour un nouveau cluster applicatif, sans vous demander s’il s’agit du serveur web 97 ou 113.

Le second avantage que j’y vois, c’est que si vous déplacez un serveur de cluster applicatif, vous faites évoluer nécessairement son nom. Alors certes, ça demande des manipulations supplémentaires, mais vous êtes certain que le nom du serveur reflète bien son rôle actuel.

IV. Comment construire sa convention de nommage

Peu importe la manière de nommer vos serveurs, vous devrez rédiger une convention de nommage, et faire en sorte qu’elle soit partagée et connue de tous dans l’équipe.

Prenons le cas de la méthode du berger. Vous souhaitez passer le plus d’informations possible dans le hostname de votre serveur, et pour éviter les noms à rallonge, vous allez devoir utiliser des sigles.

Votre convention viendra donc expliquer quels sigles choisir.

  • Pour le rôle du serveur, vous pouvez partir sur 2 ou 3 lettres. Par exemple DC pour Domain Controller, DB pour base de données, ou FIC pour serveur de fichiers.
  • Pour la localisation physique du serveur (et donc du datacenter) 2 ou 3 lettres peuvent également correspondre : BDX pour Bordeaux, PAR pour Paris.
  • Si vous souhaitez faire apparaître le cloud provider, utiliser 3 lettres peut également être intéressant : AZU pour Azure, AWS, GCP, DIO pour Digital Ocean, etc
  • L’environnement (production, test, dev, préprod) est également important. Personnellement, je le code sur 1 lettre.
  • Le type de serveur : physique, virtuel, container, etc.
  • Vous pouvez également ajouter le code du pays (US, FR), la localisation de bâtiments

Note : vous pouvez aller encore plus loin et appliquer cette convention de nommage à tout équipement se connectant à votre système d’information : PC, smartphone, système de visioconférence, copieur, imprimante, objets connectés, etc, et identifier chaque type de terminal via un code dans le nom.

V. Conclusion

Nommer ses serveurs est un art, et il n’y a pas de bonne ou de mauvaise manière de faire : il faut trouver ce qui vous convient à vous et à votre équipe.

Personnellement, je fais le choix d’utiliser pour mes nouvelles machines la méthode du berger, afin d’organiser mes serveurs par cluster applicatif. J’y glisse également la localisation physique du serveur, ainsi que le nom du provider chez qui ce serveur se trouve actuellement, et s’il s’agit d’un serveur de production ou non.

Alors oui, ça fait des noms à rallonge, ça fait beaucoup d’informations qui peuvent être visibles dans le cas d’une attaque, mais c’est un gain de temps non négligeable au quotidien.

Quant aux attaques informatiques, que mon serveur s’appelle SRVPRODFIC01 ou Goldorak, si c’est une passoire il se fera trouer à coup sûr.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Thibault Baheux

Responsable Infrastructure IT, Geek, Manager de geeks, Je travaille au quotidien sur une infra Cloud privée / Cloud Azure, aussi bien Windows que Linux. Je me passionne pour Azure & AWS, le DevOps, la sécurité & la programmation objet (PowerShell / Python). Si je ne suis pas derrière mon clavier, vous me trouverez dans une salle de blocs ou devant un bon mur d’escalade.

thibault-baheux has 14 posts and counting.See all posts by thibault-baheux

11 thoughts on “Quelle convention de nommage utiliser pour ses serveurs ?

  • Bonjour,

    Sujet assez intéressant et toujours complexe à faire, merci pour cet article.

    Si je ne trompe pas, ITIL recommande de ne pas indiquer de localisation dans les noms des serveurs, surtout avec maintenant la virtualisation où une VM peut facilement changer de lieu.

    Merci

    Répondre
    • Hello,

      Je ne saurais pas me prononcer pour ITIL mais je vais mener quelques recherches.
      Je suis d’accord pour les vms. Perso, j’utilise la localisation dans le nom pour les machines et containers Azure & AWS : cela me permet d’un coup d’œil de savoir sur quelle région je suis : Centra-US en est une par exemple. Ou alors pour des équipements sur des sites distants : serveur RODC, firewall, etc

      Répondre
    • La localisation est quand même importante sinon tu ne sais pas facilement dans quel DC se trouve ton serveur. Mais attention qu’il ne s’agit pas d’indiquer l’adresse (dans son exemple il veut savoir dans quelles régions sont les instances Amazon, ailleurs on a des codes pour les localisations.) Of course, pour les VM, si l’information n’a pas d’importance on peut avoir une localisation qui dit virtuelle…

      Répondre
      • C’est exactement cela.
        Le code localisation type BDX pour Bordeaux, je l’utilise uniquement pour des serveurs spécifiques qui pourraient se trouver hors datacenter, en local sur un site. Il s’agit en général d’un équipement historique lié à une application en fin de vie, qui n’a pas été migré sur un DC.
        Pour une machine virtuelle, la localisation physique (l’adresse, la ville) ne m’intéresse pas. par contre, connaître la région AWS / Azure d’un point de vue réseau, ça oui. Je vais préparer un article pour approfondir le sujet car j’ai l’impression que cette notion de « région » n’est pas claire pour tout le monde.

        Répondre
  • Salut, déjà merci pour cette article

    Il faut savoir que le nommage comme tu le fais est très bien et très dangereux

    D’un côté, tu sais exactement à quoi sert un serveur, de l’autre tu indique clairement à un pirate la localisation de ton serveur, mais aussi son utilisation

    Du coup tu peux utiliser ta convention de nommage et la sécuriser, en créant un algo de modification de lettre par une autre que tu scripts. Ainsi tu chiffres et déchiffres avec ton script les noms des serveurs

    Cela permet d’avoir une convention de nommage simple et sécurisée en quelque sorte

    Répondre
    • Bien vu pour le script, je vais y réfléchir et voir comment le mettre en place 😀
      Du côté de la sécurité, peu importe le nom du serveur, si on a une infra qui ressemble à du gruyère, ce n’est qu’une affaire de minutes pour l’attaquant.
      Du coup la sécu c’est un point d’attention pour moi et je n’accepte pas la mise en place d’un nouveau service si je juge la sécurité insuffisante.
      Je vais en faire un article d’ailleurs je pense

      Répondre
  • Nommer ses serveurs ne suffit pas, il faut aussi avoir un inventaire (ou CMDB). Du coup, tu associes des propriétés comme tu l’as évoqué sans le mettre dans le nom : role, type d’OS, …

    Répondre
  • Pour le chapeau, en paille ou une casquette ?
    J’en connais quelques un qui font de la résistance 😉

    Répondre
  • Bonjour,

    Pourquoi ne pas avoir parler de zone DNS ? Cela sert à ça après tout !
    Un arbre DNS qui permet de définir ce que l’ont veut, notamment la localisation ou le provider en tant que sous zone DNS.
    Il n’est pas noté également que Windows limite un hostname à 15 caractères, ton exemple ne fonctionne donc pas dans tous les cas…

    Répondre
  • Bonsoir,
    Pour avoir travailler (écumer) plusieurs années dans des environnements de grandes tailles à travers toute la planète, je pense que la meilleure convention de nommage des serveurs, et aussi de tous les équipements informatiques, est pas de convention !
    Au vue de la quantité de serveurs, de migrations, de déménagements, de changements de rôle (le serveur de dév devient le serveur de prod, le PC sous le bureau devient le serveur de prod dans le datacenter), de leur rapidité de déploiement (Cloud) et de retrait, de virtualisation, de conteneurisation… : il faut nommer les objets avec un numéro incrémentale.
    Bon pour le DNS, il vaut mieux commencer par une lettre de l’alphabet et derrière un numéro incrémentale sur plusieurs chiffres. Aucun information ne doivent informer du rôle ou status du serveur (objets connectés) et surtout il faut se référer à une CMDB pour identifier le rôle, les dépendances, les applis, les liens, leur status… de chacun des objets du parc. Le déploiement automatisé via des outils mettra à jour automatiquement les informations du serveur dans la CMDB : déployé, en maintenance, retiré, IP, cluster, virtualisé, appli, OS… Les outils de support et de supervision auront aussi à se référer et à faire des mises à jour dans la CMDB.
    Je sais c’est moins poético-rigolo que saturne, uranus, botzaris, bolivar, paris, bordeaux… et pourquoi pas carotte, poireau, patate, platane, poirier, noix-de-coco, gigot… mais on finit aussi par ne plus connaître le rôle exact de chacun sans se référer à l’indispensable CMDB.
    J’ai déjà eu à plusieurs reprises ce genre de débat avec mes collègues et managers… mais la seule solution « gérable » et industrielle est celle que j’ai décrit précédemment.
    Bien sûr cela s’applique à de grandes organisations car pour les petits parcs, on peut toujours continuer de jouer et rêver avec des jolies noms !

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

 

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.