Le Thu, 15 Nov 2012 18:00:57 +0100,
Patrick Proniewski <pat...@patpro.net> a écrit :

> On 15 nov. 2012, at 17:02, JC PAROLA wrote:
> 
> > Concernant la redondance des données, je vais vois si le Postfix
> > présent sur le MX est capable de délivrer les mails entrant sur 2
> > serveurs différents ce qui m'éviterais une synchronisation des
> > données par rsysnc ou autre.
> 
> Je ne suis pas persuadé que Postfix sache faire ça nativement, quant
> à le bricoler soit-même c'est prendre le risque d'un comportement
> étrange en cas de panne d'un des backends (distribution en boucle sur
> les autres ?). Tu auras un résultat plus fiable et pérenne si tu
> délègues la synchronisation aux backends.

Effectivement, je n'ai jamais rien rencontré de stable à ce sujet non
plus.

Dans la liste des réponses, certains ont évoqués dovecot et LMTP pour
faire ce type d'opération mais rien de bien sûr pour de la Prod.

> 
> Par contre, comment envisages-tu de régler ton problème
> d'augmentation de volumétrie si au lieu de répartir ta volumétrie par
> ajout de backends, tu dupliques tous tes fichiers sur chaque nouvelle
> machine ? Quand un backend sera plein, les autres aussi, et ton
> problème sera multiplié par le nombre de serveur. Ou alors je n'ai
> pas bien compris la démarche.

en fait j'ai des backend de Prod, quand ils sont pleins, j'en ouvre un
autre (et je migre quelques domaines pour les soulager) : ceci pour la
notion de scalabilité horizontale.

mais je dois gérer le cas ou un backend tombe. Il faut donc que je
récupère des données de ma dernière sauvegarde et les placent sur les
backend restant ou sur un backend de secours....d'où l'idée de
synchroniser chaque backend de Prod avec un backend de Seccours
> 
> > Je prévoit de serveur de SPARE au cas où.
> 
> Ça ne sert à rien d'acheter une machine de spare. Si tu n'as pas de
> contention en terme de clim ou d'EDF/UPS, autant le faire tourner en
> prod aussi. Et si tu n'as pas de contention en terme de charge, ça ne
> sert à rien de s'encombrer d'une machine en plus. Ou alors tu as
> l'habitude d'acheter du matériel bas de gamme qui tombe souvent en
> panne. C'est alors un tout autre modèle d'investissement.

tous le matos est neuf de chez HP avec Raid 1 hard HP et je n'ai jamais
eu de souci majeur.

Concernant la place en datacenter, j'ai plusieurs baies et tous les
sereur de Prod sont sauvegardés sur un serveur externe.

Quand un serveur lâche (au niveau hard), je prend mon serveur de spare,
j'installe les services nécessaires (si ce n'est déjà fait) et bouge la
data...et cela prends pas mal de temps et de stress sans compter les
clients qui se plaignent.

C'est de là qui est venu l'idée de synchroniser tous les serveurs de
Prod sur un de Secours.
> 
> > Au vue du nombre de serveur de mail, à ce niveau, ce sera moins
> > lourd à gérer que de monter une FS distribué mais je garde cette
> > option pour de plus grand volume.

Je suis d'accord avec toi mais le nombre de machine pour la partie mail
va nettement augmenter. Par exemple avec GLUSTER il faut mini 4
serveurs (2 META DATA + 2 DATA) plus de backend pour les services
POP/IMAP/SMTP.

Je pense qu'effectivement ma volumétrie n'est pas suffisante
actuellement
> > 
> > concernant la partie NFS avec un OS propriétaire, le pas est encore
> > plus dur à faire.
> 
> de mon coté, les OS sont tous en linux, la partie propriétaire c'est
> l'application de bureau virtuel (serveur POP/IMAP/WebMail/partage de
> documents/...). Nous pourrions utiliser le même montage avec une
> solution de messagerie libre. En plaçant notre serveur NFS sur une
> baie ultra-redondée, on a un SPOF logiciel si le Linux du serveur NFS
> tombe en panne, mais côté matériel on est plutôt bien bordé. Cela
> dit, je comprends qu'en terme d'investissement ce n'est pas
> comparable.
> 

c'est vrai, je n'ai jamais fait de calcul approfondie pour connaitre le
ROI d'une telle solution...mais c'est vraie que lorsque tu rajoute le
terme "baie ultra-redondée" la balance penche vraiment vers la partie
bais de stockage.

> 
> > Il est évident que la gestion du RAID 5/6 et les double alim
> > permettre de s'affranchir du SPOF et mettre en place un PRA entre 2
> > sites se fait très bien mais on en est pas encore là.
> 
> double alim ou pas, tu n'es pas à l'abris d'une carte mère qui saute,
> ou d'une mise à jour de l'OS qui casse quelque chose. Ton SPOF existe
> forcément, c'est seulement la probabilité qu'il te morde qui est
> moins grande ;)
> 

j'aime bien l'approche :-), je suis dans la même optique.

Si je te suis bien donc dans le cas d'une scalabilité horizontale, pas
la peine de tout redonder (pas de n+n), restons en n+1 avec les data
sur un serveur externe et en cas de crash (matos, mise à jour
désastreuse .....) on remonte tout ça avec une petite interruption de
quelques heures.

Si on veut plus de redondance, il faut passer sur du FS distribué ou
baie de stockage.

merci 
> 
> patpro


-- 



Jean-Christophe PAROLA
CTO

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à