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.

Source : https://www.it-connect.fr/