[ libresys ]

Après avoir vu comment virtualiser des serveurs, il est temps de se poser la question de la répartition des applications et des services réseau sur un ensemble de serveurs, qu’ils soient physiques ou virtuels. Dans cet article, je vais tenter de décrire la façon dont j’organise la répartion et le regroupement des applications et des services réseau parmi un ensemble de serveurs virtuels.

Il ne s’agit pas un ensemble de règles absolues de bonnes pratiques qu’il est possible de transposer dans tous les cas.

D’abord, parce que dans les principes suivants je privilégie la fiabilité et la stabilité du système d’information et la simplicité d’administration des serveurs, parfois au détriment de l’optimisation des performances et de la consommation des ressources physiques, que je relègue au second plan. Mes priorités ne seront probablement pas les mêmes que les votres.

Ensuite, parce qu’il y a une part de subjectivité dans les choix que je peux faire lorsqu’il s’agit de réunir au sein d’un même serveur virtuel les différents composants nécessaires au bon fonctionnement d’un service, ou au contraire de les répartir sur plusieurs serveurs virtuels.

Ceci étant dit, je vais essayer de décrire en quelques « règles » la façon dont je m’y prends pour organiser la répartition des services en serveurs virtuels.

1. Si je peux installer un service dans un serveur virtuel, je le fais. Il s’agit d’éviter autant que possible d’installer des logiciels directement sur un serveur physique. En effet, le temps passé, parfois sur plusieurs années, à peaufiner le bon fonctionnement d’un service est trop précieux pour risquer de devoir le passer à nouveau lorsque vient le moment de remplacer un serveur en fin de vie et qu’il faut réinstaller le système puis les logiciels, etc…
2. 1 service = 1 serveur virtuel. Lorsque deux services sont indépendants je les installe dans deux serveurs virtuels différents car il est important de préserver cette indépendance entres les services. Je veux notamment pouvoir arrêter ou faire évoluer un serveur sans impacter plus que nécessaire. Différemment, si deux services A et B à priori indépendants se trouvaient dans le même serveur virtuel, une intervention ultérieure sur le serveur nécessaire pour un service pourrait avoir des incidences pour l’autre service.
3. Lorsque plusieurs composants sont nécessaires au bon fonctionnement d’un service je les installe sur le même serveur virtuel. Par exemple, j’installe une application et son serveur de base de données sur le même serveur virtuel.

Dans certains cas les règles 2 et 3 pourront sembler en opposition. Je prends l’exemple simple d’une application Java/Tomcat qui, pour fonctionner, a besoin d’un serveur LDAP pour authentifier les utilisateurs et d’un serveur MySQL pour stocker ses données.

Considérons le serveur LDAP. Par sa nature, il est vraisemblablement utilisé (ou sera utilisé) par plusieurs autres applications. Aussi, il est préférable de l’installer sur un serveur virtuel dédié, afin de ne pas rendre les autres applications dépendantes du serveur de l’application A. Si en revanche, il est certain qu’il n’est utile qu’à cette application et ne doit jamais être utilisé par un autre service réseau, alors je l’installe sur le même serveur virtuel que l’application.

Considérons le serveur MySQL. S’agissant des données de l’application, j’installe le serveur MySQL dans le même serveur virtuel que l’application. Il serait évidemment possible d’utiliser un serveur MySQL distant pour y installer les bases de plusieurs applications, mais dans ce cas on rendrait les serveurs virtuels hébergeant les applications dépendants du serveur virtuel hébergeant MySQL. Aussi je préfère multiplier les serveurs de bases de données, quitte à ce que ces derniers n’hébergent qu’une seule base.

Sur la base de ce cet exemple, j’utiliserais deux serveurs virtuels : un pour LDAP, un pour l’application Java/Tomcat + MySQL.

Ces quelques « règles » présentent l’avantage d’isoler correctement les services réseau et les applications et de simplifier la maintenance globale des serveurs.

Il est malgré tout parfois nécessaire d’y faire des entorses. Par exemple, j’utilise aussi un serveur Oracle comme serveur de base de données. Dans ce cas, les restrictions imposées par la licence d’utilisation m’empêchent d’installer autant de serveurs que je voudrais et à mettre plusieurs bases sur le même serveur… même si quelle que soit la répartition le nombre de bases de données et l’utilisation qui en est faite sont les mêmes.