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.

Thibault Baheux Responsable Infrastructure IT

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, la sécurité IT, le management de projets & 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.

See Full Bio