1 votes

Comment répartir la distribution du courrier électronique entre 2 serveurs ou plus ?

Nous fournissons un service de marketing par courriel par le biais de notre application en ligne. Nous avons environ 30 clients. Et chacun d'entre eux a sa propre liste d'adresses (de 5 à 20 000 emails chacun).

Ce que nous voulons vraiment, c'est répartir la distribution du courrier électronique entre deux ou plusieurs serveurs. Je me demandais quel type d'approche/solutions MailChimp, Constant Contact utilise pour fournir un service de qualité ? utiliser plusieurs serveurs ? plusieurs IP ?

Notre politique en matière de spam suspend TOUT utilisateur/client qui obtient 10% de rebonds.

1voto

Newtonx Points 295

Nous avons 1 serveur à The Planet

Dual Xeon Quad Core, com 12 GB of RAM

Processor #1 Vendor: GenuineIntel
Processor #1 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #1 speed: 1995.080 MHz
Processor #1 cache size: 6144 KB

Processor #2 Vendor: GenuineIntel
Processor #2 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #2 speed: 1995.080 MHz
Processor #2 cache size: 6144 KB

Processor #3 Vendor: GenuineIntel
Processor #3 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #3 speed: 1995.080 MHz
Processor #3 cache size: 6144 KB

Processor #4 Vendor: GenuineIntel
Processor #4 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #4 speed: 1995.080 MHz
Processor #4 cache size: 6144 KB

Processor #5 Vendor: GenuineIntel
Processor #5 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #5 speed: 1995.080 MHz
Processor #5 cache size: 6144 KB

Processor #6 Vendor: GenuineIntel
Processor #6 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #6 speed: 1995.080 MHz
Processor #6 cache size: 6144 KB

Processor #7 Vendor: GenuineIntel
Processor #7 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #7 speed: 1995.080 MHz
Processor #7 cache size: 6144 KB

Processor #8 Vendor: GenuineIntel
Processor #8 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #8 speed: 1995.080 MHz
Processor #8 cache size: 6144 KB

Lorsque tous nos clients livrent des campagnes en même temps (cela se produit avant les dates commémoratives), nous recevons trop d'e-mails rejetés en raison du flux de livraison élevé. Nous faisons tourner les adresses IP sortantes de nos courriers électroniques en utilisant 45 IP. Et nous contrôlons/limitons le flux vers un hôte (ex : @hotmail, @gmail) à partir de chaque IP.

Notre approche est la suivante

  1. Notre application envoie 300 courriels à @hotmail.com à 14 heures.
  2. L'application bloque les livraisons à @hotmail.com et commence à livrer à d'autres hôtes jusqu'à ce qu'elle augmente la limite par hôte.
  3. L'application fait tourner l'IP sortante du serveur de messagerie (en utilisant 45 IP différentes) toutes les 10 minutes.

Je crains qu'avec le développement de l'entreprise et l'augmentation du nombre de clients, le flux d'envois augmente et que cette approche échoue en étant rejetée par les hôtes de destination.

0voto

The Thom Points 11

En général, une file d'attente de messages est utilisée pour quelque chose comme ça. Les commandes d'envoi de courrier électronique à des destinataires particuliers ou à des groupes de destinataires sont mises en file d'attente sur un producteur, puis un nombre quelconque de consommateurs peuvent extraire la commande suivante dans la file d'attente et la traiter.

Il existe de nombreuses possibilités de mise en œuvre, mais cela dépend de votre environnement spécifique.

Cela dit, le volume de courrier que vous envoyez n'est pas si élevé pour un seul serveur.

0voto

TomTom Points 50635

Quel est exactement le problème ici ?

Votre volume n'est pas assez élevé pour justifier une division - je veux dire, même si vos 30 clients envoient 20.000 emails à la fois, ce n'est pas tant que ça - assez pour qu'un seul serveur puissant puisse le gérer (et je ne veux pas dire super puissant - il suffit de prendre quelques disques et de former un raid pour le spool de courrier).

Vous pouvez éventuellement opter pour des serveurs d'envoi multiples pour la mise en file d'attente. Un bloc d'adresses IP pour tous les serveurs de messagerie. Soit en utilisant quelque chose comme MS Exchange pour l'envoi (Exchange est excellent pour maintenir automatiquement des fermes de serveurs), soit en utilisant un mécanisme pour regrouper les courriels entre les serveurs (de sorte que ceux destinés au même domaine finissent sur le même serveur - simplement parce que le serveur peut alors envoyer plusieurs courriels en une seule connexion TCP).

Les fournisseurs d'accès multiples ne semblent pas être un problème. N'oubliez pas que nous parlons d'un trafic beaucoup trop important pour une ligne ADSL domestique bon marché. Une fois que vous avez atteint le niveau professionnel, vos serveurs sont transférés dans un centre de données approprié. Le temps de disponibilité est alors très élevé - pour un centre approprié (attention, certains semblent vraiment bon marché). Même si les choses tombent en panne un jour dans 2 ou 3 ans, il faut être VRAIMENT gros pour que le clustering ait un sens. Et même dans ce cas, les choses peuvent vraiment mal tourner (comme dans le cas de Wikipedia, qui a également été en panne pendant un certain temps récemment).

Le problème principal sera que vous aurez besoin de serveurs dédiés construits sur mesure pour gérer le flux de courrier. Le trafic réseau n'est pas si important. Mais le spool de courrier sera très dur pour vos disques. Si vous avez vraiment des pics de 600.000 emails, un RAID 10 de 4-8 disques à haute vitesse (ou : un RAID 5 de SSD's) semble être le meilleur pari. Comme tous les systèmes transactionnels de base de données, votre limite sera l'IO. J'opterais pour un système de fichiers formaté sur mesure avec une taille de nœud non standard (64k), permettant à chaque email d'être lu/écrit sur le nœud à peu près par garantie. Notez que ceci est basé sur l'utilisation de SPIKE - si les emails ne sont pas tous envoyés en même temps, vous pouvez vous en sortir avec beaucoup moins.

L'étape suivante serait un cluster de serveurs.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X