Description

Cette page décrit l'architecture adopté au Cr@ns pour BCfg2. En fait c'est plus une ligne à suivre pour garder un ensemble cohérent.

Il vaut mieux avoir lu cette page au préalable.

Remarque: j'ai fait ça comme ça à la base parce que je trouvais ça assez pratique, mais si vous avez une meilleure idée n'hésitez pas. -- WikiDim

Organisation des groupes

Un profile par serveur

Comme chacun des serveurs du Cr@ns a un rôle particulier, dans la plupart des cas on aura exactement un groupe profile par serveur.

Un groupe commun

Il y a différents services que l'on veut que tous les serveurs aient, comme par exemple un serveur de mail pour envoyer des alertes et statistiques, des services de monitoring, l'authentification avec la base de données du Cr@ns, etc...

Pour ça il y a le groupe crans. Donc sauf cas exceptionnel tous les serveurs doivent posséder au moins le groupe crans.

Essayer d'abstraire les services

Tant que possible détacher la fonction réalisée par un programme du nom du programme choisi pour réaliser cette fonction.

Par exemple au lieu d'avoir un profile de la forme pour un client Toto:

Toto: serveur nfs 
      serveur ldap
      serveur postfix

On a:

Toto: serveur de fichier 
      serveur de base de données
      serveur de mail

Puis on a des définition de groupes supplémentaires qui permettent de lier ces fonctions aux implémentation choisies:

serveur de fichier: nfs 
serveur de base de données: ldap
serveur de mail: postfix

Ça permet notamment d'avoir une structure qui persiste lors d'un changement d'implémentation. Notamment dans les templates de fichier qui ne nécessitent pas de connaître le backend réel.

Les services client/serveur

Beaucoup de services se découpent en une version client qui tourne sur toutes les machines et une version serveur qui tourne sur une machine en particulier.

Là à priori deux choix possibles : avoir un groupe générique qui correspond à la partie commune. Et un groupe serveur qui surcharge le groupe simple. Par exemple:

Un groupe mail présent sur tous les serveurs, et un groupe mail-server en plus pour ceux qui font MX. Ensuite dans les fichiers de conf on fait les test sur le fait que le client possède ou non le groupe mail-server.

Ou alors un groupe pour les clients, un pour les serveurs et un pour la partie commune inclue par les deux. Le problème c'est qu'on ne peut pas définir de groupes génériques à mettre dans le groupe crans avec cette approche.

Notes

Actuellement la conf est telle que par défaut un serveur est sur le vlan adm avec accès à la base. Maintenant qu'on a du xen il pourrait être intéressant d'avoir des dom-U minimaux ne faisant tourner qu'un seul service "sensible" ne nécessitant aucun accès à la base, et du coup les isoler un peu plus du reste du réseau.

CatégoriePagePublique