Bonjour à tous,
Après un fil très intéressant le mois dernier sur "Les systèmes de fichiers distribués", je me permet de vous poser la question:
comment gérez-vous la scalabilité de vos serveurs de mail.
En effet, dans une architecture simple, un serveur avec 2 disques en RAID gère la messagerie pour x client.
Quelle est pour vous la meilleure manière de gérer l'accroissement du volume des données mails des clients ?
En effet, le volume de mail augmente d'année en année et même en prenant une garde au niveau de l'espace disque, tôt ou tard on arrive au max....et la longue série de migration commence.
d'après ce que j'ai pu lire voici les différentes approches:
1/scalabilité vertical: on ajoute des machines identiques pour augmenter la capacité:
avantage: simple à mettre en oeuvre inconvénient: oblige à installer un serveur d email complet (MTA, serveur POP, IMAP,repondeur....)
2/un serveur de stockage avec export NFS ou iSCSI avec une carte contrôleur disque adequat (du genre LSI MEGARAID CacheCade ou équivalent HP/DELL/NetApp....)
avantage: l'unité de stockage fait qqe To ce qui laisse voire venir inconvénient: coût (de 20K€ à 50 k€) et surtout le faible retour d'expérience (d'où mon ticket)
3/un système de fichier distribué (GLUSTER,MOOSE,CEPH,PVFS,LUSTRE.....)
avantage: cout faible, scalable
inconvénient: la haute disponibilité du serveur maître fait toujours appel à du heartbeat avec des scripts maison. les performances à très forte charge est souvent soumise à réserve.
J'ai essayé de rendre ce ticket constructif pour donner un état des lieux (... plutôt de ce que j'ai assimilé :-)) pour que l'on parte sur une base.
Comment avez-vous gérer cela de côté ?
Merci à tous
Le 15 nov. 2012 à 11:44, JC PAROLA contact@sels-ingenierie.com a écrit :
Bonjour à tous,
Après un fil très intéressant le mois dernier sur "Les systèmes de fichiers distribués", je me permet de vous poser la question:
comment gérez-vous la scalabilité de vos serveurs de mail.
En effet, dans une architecture simple, un serveur avec 2 disques en RAID gère la messagerie pour x client.
Quelle est pour vous la meilleure manière de gérer l'accroissement du volume des données mails des clients ?
En effet, le volume de mail augmente d'année en année et même en prenant une garde au niveau de l'espace disque, tôt ou tard on arrive au max....et la longue série de migration commence.
d'après ce que j'ai pu lire voici les différentes approches:
1/scalabilité vertical: on ajoute des machines identiques pour augmenter la capacité:
avantage: simple à mettre en oeuvre inconvénient: oblige à installer un serveur d email complet (MTA, serveur POP, IMAP,repondeur....)
2/un serveur de stockage avec export NFS ou iSCSI avec une carte contrôleur disque adequat (du genre LSI MEGARAID CacheCade ou équivalent HP/DELL/NetApp....)
avantage: l'unité de stockage fait qqe To ce qui laisse voire venir inconvénient: coût (de 20K€ à 50 k€) et surtout le faible retour d'expérience (d'où mon ticket)
3/un système de fichier distribué (GLUSTER,MOOSE,CEPH,PVFS,LUSTRE.....)
avantage: cout faible, scalable
inconvénient: la haute disponibilité du serveur maître fait toujours appel à du heartbeat avec des scripts maison. les performances à très forte charge est souvent soumise à réserve.
J'ai essayé de rendre ce ticket constructif pour donner un état des lieux (... plutôt de ce que j'ai assimilé :-)) pour que l'on parte sur une base.
Comment avez-vous gérer cela de côté ?
Merci à tous
Bonjour,
Très rapidement : glusterFS avec 2 filets maîtres et réplication sur les 2 en simultané. Gluster fait ça très bien, et pas la peine de se faire chier avec du heartbeat, puisque si l'un tombe, l'autre reste.
Rajoute devant les mx un lb avec de l'ipvs et un check sur les mx qui coupe un postfix dès que le point de montage saute côté client (pas souvent, mais ça arrive), et tu as tout.
Bonjour,
On 15/11/2012 11:44, JC PAROLA wrote:
Bonjour à tous,
Après un fil très intéressant le mois dernier sur "Les systèmes de fichiers distribués", je me permet de vous poser la question:
comment gérez-vous la scalabilité de vos serveurs de mail.
...
1/scalabilité vertical: on ajoute des machines identiques pour augmenter la capacité:
C'est horizontal. Vertical : tu ajoutes du hard sur une même machine (RAM, disque, ...).
avantage: simple à mettre en oeuvre inconvénient: oblige à installer un serveur d email complet (MTA, serveur POP, IMAP,repondeur....)
2/un serveur de stockage avec export NFS ou iSCSI avec une carte contrôleur disque adequat (du genre LSI MEGARAID CacheCade ou équivalent HP/DELL/NetApp....)
avantage: l'unité de stockage fait qqe To ce qui laisse voire venir inconvénient: coût (de 20K€ à 50 k€) et surtout le faible retour d'expérience (d'où mon ticket)
3/un système de fichier distribué (GLUSTER,MOOSE,CEPH,PVFS,LUSTRE.....)
Tu peux aussi distribuer au niveau applicatif : nginx par exemple, peut servir de proxy imap et proxyifier vers les bon backend IMAP/POP (http://wiki.nginx.org/ImapProxyExample).
Ça me parait beaucoup plus simple d'avoir 'n' petits backends cyrus faciles à gérer avec du RAID1, 5 ou 6, et un nginx qui distribue en front. Je vais probablement partir là dessus très bientôt (j'ai un cyrus avec 100k+ boites actuellement).
Tu peux aussi faire ça avec Perdition, un autre proxy imap.
Par contre tu n'a pas de tolérance de panne : si un backend tombe, tu perds une partie des boites jusqu'à ce que tu le remontes.
A+
M
On Thu, 15 Nov 2012 11:55:51 +0100 Michel Blanc mblanc.networks@gmail.com wrote:
Tu peux aussi distribuer au niveau applicatif : nginx par exemple, peut servir de proxy imap et proxyifier vers les bon backend IMAP/POP (http://wiki.nginx.org/ImapProxyExample).
Très bonne solution. nginx en front avec du keepalived et tu scales horizontalement avec du RrB DNS si besoin et tu offload le TLS/SSL sur ce tiers aussi. La scalabitité horizontale du tiers d'après est naturellement assuré par le tiers 1 (ou 0, çà dépend de du choix de la nomenclature que tu choisis pour nommer la répartition logique fonctionnel de chaque tiers).
Ça me parait beaucoup plus simple d'avoir 'n' petits backends cyrus faciles à gérer avec du RAID1, 5 ou 6, et un nginx qui distribue en front. Je vais probablement partir là dessus très bientôt (j'ai un cyrus avec 100k+ boites actuellement).
Ça se discute. Tu fais du shared nothing sur le tiers de stockage et soit du te colles un routage sur nginx un peu velu à gérer pour s'assurer que toto@pipo.tld tombe tjs sur le bon backend. Et tu introduis un SPOF et c'est mal. Tu peux rester dans du shared nothing sans SPOF et sans stockage complexe à gérer mais alors tu assures la synchro simplement des boites entre tes backend avec du LTMP (dovecot fait çà très bien) et un gestion de tes comptes dans un LDAP par exemple. C'est une solution intermédiaire qui me plait moyen pour le stockage. Je préfères partir sur un solution de stockage qui tienne la route en matière de répartition qui travaille du niveau blocs et qui fassent çà proprement sans te faire perdre dupliquer des blocs pour des raisons discutables et les FS distribuées font çà plutôt bien.
++
Le Thu, 15 Nov 2012 11:55:51 +0100, Michel Blanc mblanc.networks@gmail.com a écrit :
Ça me parait beaucoup plus simple d'avoir 'n' petits backends cyrus faciles à gérer avec du RAID1, 5 ou 6, et un nginx qui distribue en front. Je vais probablement partir là dessus très bientôt (j'ai un cyrus avec 100k+ boites actuellement).
Merci à tous pour ces réponses concrètes et vos retour d'expérience.
Cela m'a permis enfin de trancher. Au vue des 5k adresses mails que nous gérons, la solution de multiple backend semble pour moi la plus simple et la plus proche de ce que nous avons déjà en place.
J'avais déjà installé Perdition en me disant que du proxy IMAP/POP ne pouvait être qu'une "bonne pratique".
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 pense que cette étape est la bonne et permettra déjà d'être scalable.
Je prévoit de serveur de SPARE au cas où.
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.
concernant la partie NFS avec un OS propriétaire, le pas est encore plus dur à faire.
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à.
Un grand merci à tous
bonne fin de journée
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.
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.
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.
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.
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.
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 ;)
patpro
Le Thu, 15 Nov 2012 18:00:57 +0100, Patrick Proniewski patpro@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
On Thu, 15 Nov 2012 19:35:38 +0100 JC PAROLA contact@sels-ingenierie.com wrote:
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.
Heu, c'est juste un peu en prod chez bcp de monde de la synchro des backends via LMTP ou des système de répartition de charge via LTMP sur les MTA en front. C'est juste un peu pour çà que LMTP à été conçu, implémenté, mis en prod et enfin mis en RFC.
Le Fri, 16 Nov 2012 14:11:09 +0100, Jérôme Benoit jerome.benoit@grenouille.com a écrit :
On Thu, 15 Nov 2012 19:35:38 +0100 JC PAROLA contact@sels-ingenierie.com wrote:
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.
Heu, c'est juste un peu en prod chez bcp de monde de la synchro des backends via LMTP ou des système de répartition de charge via LTMP sur les MTA en front. C'est juste un peu pour çà que LMTP à été conçu, implémenté, mis en prod et enfin mis en RFC.
oups ! j'avais simplement lu un avis en réponse à la demande sur FRsAG.
C'est effectivement totalement opérationnel. J'avais rencontré quelque chose de similaire avec QMTP lors de la mise en place de multiples serveur de mails sous Qmail.
Merci pour ta mise au point car actuellement j'étais resté sur une copie (synchro) au niveau du système de fichier. Mais si je peux le faire avec avec LMTP c'est mieux.
Je sais Postfix gère cela très bien.
Merci à toi
On 15 nov. 2012, at 11:44, JC PAROLA wrote:
comment gérez-vous la scalabilité de vos serveurs de mail.
Ça dépend surtout de ta croissance. Chez nous (Université Lyon 2), on s'appuie sur une solution propriétaire pour le coté mailbox (Contact Office). Notre nombre de comptes est stable, autour de 45K. Seuls les quotas augmentent avec le temps. On a été très longtemps en NAS sur des baies de petite taille (2 fois 16 disques SAS en RAID 60), exportées en NFS à destination des frontaux applicatifs webmail/pop/imap.
Désormais on a déporté ce stockage sur une baie SAN/NAS EMC VNX. Cette baie sert de stockage à l'ensemble de notre infra VSphere. Nous aurions pu mettre le stockage "mail" sur les têtes NAS de la baie, mais pour des raisons pratiques nous avons préféré créer une grosse VM linux qui exporte en NFS le volume souhaité, extensible à souhait, puisque la baie en question a une volumétrie très importante. L'avantage c'est qu'à terme, le stockage sera entièrement répliqué sur notre autre campus en flux constant (VNX identique), pour assurer une reprise rapide en cas de chute d'un des deux campus. Cela nous a permis de basculer les quotas des boîtes mail étudiantes de 100 Mo à 1 Go, avec sans doute une nouvelle augmentation dans quelques semaines. On est bien sûr en sur réservation, mais on a 8 ans de recul sur les usages du mail à Lyon 2, donc on connait notre marge de manœuvre.
Pour palier l'augmentation des volumétries il y'a d'autres pistes, comme les stockages compressés/dédupliqués (ZFS par exemple, mais grosse conso de ressource), ou comme les serveurs de messagerie qui dédupliquent au niveau applicatif (je ne sais pas si ça existe dans le monde libre, par contre).
patpro
-
Frédéric de Villamil -
JC PAROLA -
Jérôme Benoit -
Michel Blanc -
Patrick Proniewski