स्केलेबल मेल सिस्टम आर्किटेक्चर

इस लेख में, हम एक बड़े मेल सिस्टम के स्केलेबल आर्किटेक्चर को लागू करने के विकल्पों में से एक पर विचार करते हैं।

6 दिसंबर 2012 को, Google ने Google Apps के मुफ्त संस्करण के लिए नए खाते पंजीकृत करना बंद कर दिया।

हमारी कंपनी के ग्राहकों को लगातार अपनी साइटों की सेवा के लिए ई-मेल की आवश्यकता होती है।
पहले, हमने उनके लिए Google Apps स्थापित किए थे, लेकिन 6 दिसंबर के बाद, बाजार पर पेश किए गए समाधानों का अध्ययन करने के बाद, हमने फैसला किया कि यह हमारी अपनी मेल प्रणाली बनाने का समय था।

जैसा कि आप जानते हैं कि भूख खाने से आती है। यदि आप अपना खुद का कुछ बनाने का फैसला करते हैं, तो यह विकास के अवसरों को तुरंत बिछाने के लायक है।
डिज़ाइन किए गए मेल सिस्टम के लिए, निम्न आवश्यकताओं को तैयार किया गया था:

• स्केलेबिलिटी (डोमेन की असीमित संख्या में सेवा, मेलबॉक्सों की कुल मात्रा 100 टेराबाइट्स या अधिक है);
• गलती सहिष्णुता (सभी मध्यवर्ती सेवाओं को डुप्लिकेट किया जाना चाहिए);
• एक्स्टेंसिबिलिटी (सिस्टम में नए नोड जोड़ना आसान और सरल होना चाहिए)।

हम पत्र के लिए एक भंडार का चयन करके शुरू किया ...

वास्तव में, चुनाव छोटा था:

• dovecot / cyrus maildir / मेलबॉक्स के माध्यम से फाइल सिस्टम में भंडारण के साथ;
• डेटाबेस में भंडारण के साथ dbmail।

"बॉक्स से बाहर" प्रदान की गई सेवाओं की संख्या का मूल्यांकन करने के साथ-साथ उपयोग की बारीकियों की जांच करने के बाद, हमने dbmail का फैसला किया।
यहाँ dbmail प्रदान करता है कि उपहार की एक छोटी सूची है:

• IMAP, POP3 के माध्यम से मेलबॉक्स तक पहुंच;
• मेल छँटाई के लिए छलनी स्क्रिप्ट;
• smtp और lmtp प्रोटोकॉल के माध्यम से मेल प्राप्त करना;
• cli और SQL प्रश्नों के माध्यम से प्रशासन।

पोस्टफ़िक्स को एमटीए के रूप में चुना गया था। चूंकि हम लंबे समय से इसके साथ काम कर रहे हैं, हम विश्वास के साथ इसे बहुत तेज, लचीला और आसानी से अनुकूलन कार्यक्रम मानते हैं। इसके अलावा, dbmail वेबसाइट पर पोस्टफ़िक्स + dbmail बंडल सेट करने के लिए एक निर्देश है।

एक लोड बैलेंसर सभी समय का सबसे अच्छा प्रॉक्सी चलाता है: नगेंक्स।
मेलबॉक्स के लिए वेब इंटरफ़ेस किसी भी दर्जनों उपलब्ध कार्यक्रमों द्वारा प्रदान किया जा सकता है। शुरुआत के लिए, RoundCube का उपयोग करने का निर्णय लिया गया था।

परिणामस्वरूप, निम्नलिखित प्रोजेक्ट आर्किटेक्चर उभरने लगे:

1. सबसे आगे, हमारे पास nginx चल रहे मेल मॉड्यूल के साथ सक्षम है, यह SMTP, IMAP, POP3 प्रोटोकॉल का उपयोग कर क्लाइंट से कनेक्शन स्वीकार करता है और, उपयोगकर्ता नाम और पासवर्ड के आधार पर, वांछित सर्वर से कनेक्शन को जोड़ता है।
2. रक्षा की गहराई में, कई पोस्टफ़िक्स और डीबमेल हैं, जिनमें से प्रत्येक अपने स्वयं के डोमेन का कार्य करता है।

बाहरी दुनिया के लिए, यह सब एक बड़े मेल सर्वर जैसा दिखता है।

सिद्धांत रूप में, स्केलेबिलिटी हासिल की जाती है, अब कार्य कार्यान्वित करना है।

सिस्टम का प्रत्येक मॉड्यूल इसके OpenVZ कंटेनर में काम करेगा। लोड बढ़ने पर, हम कंटेनरों को नए भौतिक सर्वरों में क्लोन / माइग्रेट करेंगे।

अलग-अलग कंटेनरों में हमने विभिन्न मेल फिल्टर, dbmail और संदेश भंडारण के साथ MySQL डाटाबेस में पोस्टफिक्स को एक कंटेनर में रखा होगा, क्योंकि dbmail को प्रोसेसर को ज्यादा लोड नहीं करना चाहिए, और dbmail और mysql के बीच स्थानांतरित डेटा की मात्रा बड़ी होगी (भंडारण में डेटा का दोहराव) पत्र MySQL मास्टर-दास प्रतिकृति तंत्र के माध्यम से लागू किया जाएगा, प्रत्येक dbmail मॉड्यूल के लिए एक हॉटबैक मॉड्यूल का आयोजन)।

इसके अलावा, सुविधा के लिए, अलग-अलग कंटेनरों में आप एक राउंड क्यूब और पूरे सिस्टम के एक नियंत्रण कक्ष के साथ वेब सर्वर का चयन कर सकते हैं।

सभी कंटेनर एक दूसरे के साथ एक स्थानीय नेटवर्क पर ग्रे पतों के साथ संवाद करते हैं।
यह केवल नेगनेक्स कंटेनरों को वास्तविक इंटरनेट पते देने की योजना बनाई गई थी।
नगीनेक्स की स्थापना और विन्यास के दौरान, यह पता चला कि वह प्राधिकरण के बिना एसएमटीपी सत्रों को प्रॉक्सी नहीं कर सकता था। इस समस्या के समाधान ने परियोजना की प्रारंभिक रूप से नियोजित वास्तुकला को थोड़ा बदल दिया, जिसके कारण लचीलापन और व्यापकता बढ़ गई। हमने nginx के माध्यम से SMTP ट्रैफ़िक को प्रॉक्सी करने से इनकार कर दिया, और निर्णय लिया कि पोस्टफ़िक्स मॉड्यूल सीधे इसे प्राप्त करेंगे।

सिस्टम के सभी पोस्टफिक्स-मॉड्यूल समान बनाए गए थे, जिनमें से प्रत्येक का अपना वास्तविक आईपी-पता है, और हम यह निर्धारित करते हैं कि ट्रांसपोर्ट_मैप के माध्यम से मेल भेजने के लिए कौन सा डीबीएम-मॉड्यूल है।
नतीजतन, कोई भी पोस्टफिक्स मॉड्यूल सिस्टम में किसी भी डोमेन के लिए मेल को स्वीकार कर सकता है, विभिन्न फ़िल्टर लागू कर सकता है और इसे वांछित भंडारण तक पहुंचा सकता है।
वे DNS में राउंड-रॉबिन रिकॉर्ड के माध्यम से संतुलित होंगे:

nginx1 IN A 1.1.2.1 nginx2 IN A 1.1.2.2 postfix1 IN A 1.1.1.1 postfix2 IN A 1.1.1.2 postfix3 IN A 1.1.1.3 mx1 IN A 1.1.1.1 IN A 1.1.1.2 IN A 1.1.1.3 mx2 IN A 1.1.1.2 IN A 1.1.1.3 IN A 1.1.1.1 mx3 IN A 1.1.1.3 IN A 1.1.1.2 IN A 1.1.1.1 imap IN A 1.1.2.1 IN A 1.1.2.2 pop3 IN A 1.1.2.1 IN A 1.1.2.2 smtp IN CNAME mx1 _spf IN TXT "v=spf1 ip4:1.1.1.1 ip4:1.1.1.2 ip4:1.1.1.3 ?all" 

क्लाइंट के डोमेन में, आवश्यक प्रविष्टियाँ जोड़ी जाती हैं:

 @ IN MX 10 mx1.dbmail.io. @ IN MX 20 mx2.dbmail.io. @ IN MX 30 mx3.dbmail.io. @ IN TXT "v=spf1 a mx include:_spf.dbmail.io -all" 

उपयोगकर्ता के ईमेल क्लाइंट pop3.dbmail.io या imap.dbmail.io से मेल प्राप्त करने के लिए कॉन्फ़िगर किए गए हैं, और smtp.dbmail.io के माध्यम से मेल भेजते हैं

केवल dbmail-मॉड्यूल डुप्लिकेट और अद्वितीय नहीं रहे, लेकिन वे प्रत्यक्ष इंटरनेट से उपलब्ध नहीं हैं, इसलिए उन पर अभी तक गतिशील भार संतुलन की कोई आवश्यकता नहीं है।
यदि मॉड्यूल के संसाधन बाहर निकलते हैं, तो प्रत्येक dbmail मॉड्यूल कई डोमेन के लिए मेल संग्रहीत करता है,
कुछ डोमेन को एक अलग मॉड्यूल में ले जाया जा सकता है।

और भविष्य में, कुछ समर्पित क्लस्टर डेटाबेस में मेल स्टोर करने के लिए स्विच करने और dbmail मॉड्यूल को एकजुट करने की योजना है।

परिणाम एक ऐसी स्केलेबल फॉल्ट-टॉलरेंट और एक्सपेंडेबल मेल सिस्टम है:

हमारे मेल सिस्टम के सभी तत्व मानक प्रोटोकॉल के अनुसार एक दूसरे के साथ संवाद करते हैं और जैसा कि कल्पना करने के लिए भोला था, सब कुछ तुरंत और बिना बैकअप के निर्माण की आवश्यकता के बिना काम करना चाहिए था।
दुर्भाग्य से, डिजाइन को एक फ़ाइल के साथ समाप्त करना पड़ा।
निम्नलिखित लेखों में ट्यूनिंग और डीबगिंग का इतिहास पढ़ें।