====== Choix techniques ====== Choix techniques que l'on évite de remettre en question sans raison valable. ===== Où met-on les ML ? ===== Problématique : * ML requiert un SMTPd et un HTTPd (archives, inscription par la majorité des utilisateurs, ...) or un HTTPd n'a rien à faire sur un serveur mail. * Un MTA est de toutes façons nécessaire sur web (recovery mdp Drupal, ...) mais si vérolé ou si besoin d'une intervention, on perd tout alors que les mails fonctionnent toujours… Le top serait un LXC dédié juste aux ML, avec son propre MTA qui émet partout sur Internet. Seulement : ressources limitées (une seule machine, IO perfectibles, quantité de RAM "limitée", un /27 d'infra) donc bof. Il est cohérent de mettre tout le service de ML sur le MTA. Cela coupe le lien de dépendance web<->mail et si mail tombe en panne, c'est logique que ML ne fonctionnent plus. En revanche, il est dommage de ne plus avoir de ML (archives, nouvelles inscriptions) si l'on a besoin d'éteindre web. Et puis dommage que mail soit un LXC qui contient uniquement un "MTA à alias" (et les alias sont nécessaires pour la communication et pour la pérennité (president@ mieux que l'email perso d'un président d'un instant T). . ===== Combien de MySQL ? ===== Plusieurs services ont besoin de MySQL (exemple : web, netlib.re, zabbix, ...). Comme on est limité en IO, n'est-il pas pertinent d'avoir un seul serveur MySQL ? Un serveur MySQL sur int aurait sa place puisqu'on a dit que ext = frontend et int = backend. Ce serveur serait donc le backend de stockage de toutes les app en frontend. Non car sinon dépendance entre VM -> on cherche à éviter ça dans la nouvelle infra. Par contre, rien n'empêche, si on multiplie les services qui ont recours à MySQL, de mutualiser un serveur MySQL sur ext et un serveur MySQL sur int. ===== puppet.arn-fai.net dans /etc/hosts ? ===== L'idée est que puppet gère une entrée dans tous les /etc/hosts vers lui-même. Comme ça, si ns0 tombe, on ne perd pas l'usage de puppet. La flexibilité est assurée par puppet puisqu'on peut changer l'entrée en masse. Non. D'abord car c'est une circonstance exceptionnelle. Pour qu'une telle panne arrive : il faut que ns0 tombe, que alsace.ttnn tombe pendant qu'on est en train de renuméroter l'infra ... Improbable. Et cette entrée peut vite être oubliée ... Fausse bonne idée. ===== Puppet en mode automatique ? ===== Puppet agent peut être lancé automatiquement et vérifier/appliquer la conf toutes les 30 minutes. On utilise cette fonctionnalité ? Non. cssh fait l'affaire. On est pas obligé d'attendre 30 mns ou de faire un mix "auto + je lance l'agent pour tester". On se donne du temps de réflexion avant d'appliquer. Et puppet-agent ne tourne pas toutes les 30 minutes pour rien (les changements de la base commune à toutes les VM et tous les LXC seront rares). Il y a aussi que si on est en train d'expérimenter sur un fichier il va pas se faire écraser subitement avant qu'on ait pu le mettre dans puppet ou autre. ===== VG dans VM d'infra ? ===== Chaque VM est un LV sur services. À l'intérieur d'une VM, on utilise des LV pour séparer les LXC entre eux et du root de la VM. Fait-on un VG "root" et un VG "LXC" avant de partir sur des LV ou fait-on un seul VG qui contient tout ? Non. On fait un seul VG qui contient tous les LV. Les VM ne contiennent rien. Donc pas la peine de faire des LV pour séparer / de /usr de /var de ... Perte d'espace inutile. Donc pas la peine de faire deux VG. De plus, des VG dans les VM empêchent de faire un simple lvresize sur services puis un simple lvresize/resize2fs. ===== Wiki sur l'infra ? ===== Non, car si l'infra tombe, on n'a plus la doc pour debug. Actuellement, le wiki est hébergé sur notre machine virtuelle chez Tetaneutral.net.