بڑے پیمانے پر Zimbra OSE کے بنیادی ڈھانچے کی تعمیر کے دوران اہم کاموں میں سے ایک مناسب بوجھ توازن ہے۔ اس حقیقت کے علاوہ کہ یہ سروس کی غلطی برداشت کو بڑھاتا ہے، لوڈ بیلنسنگ کے بغیر تمام صارفین کے لیے سروس کی یکساں ردعمل کو یقینی بنانا ناممکن ہے۔ اس مسئلے کو حل کرنے کے لیے، لوڈ بیلنسرز استعمال کیے جاتے ہیں - سافٹ ویئر اور ہارڈویئر حل جو سرورز کے درمیان درخواستوں کو دوبارہ تقسیم کرتے ہیں۔ ان میں کافی قدیم ہیں، جیسے راؤنڈ رابن، جو ہر بعد کی درخواست کو فہرست میں اگلے سرور کو آسانی سے بھیجتا ہے، اور اس سے بھی زیادہ جدید بھی ہیں، مثال کے طور پر HAProxy، جو کہ زیادہ بوجھ والے کمپیوٹنگ انفراسٹرکچر میں بڑے پیمانے پر استعمال ہوتا ہے۔ اہم فوائد کی تعداد. آئیے اس پر ایک نظر ڈالتے ہیں کہ آپ HAProxy لوڈ بیلنسر اور Zimbra OSE کو ایک ساتھ کیسے کام کر سکتے ہیں۔
لہذا، ٹاسک کی شرائط کے مطابق، ہمیں Zimbra OSE انفراسٹرکچر دیا گیا ہے، جس میں دو Zimbra Proxy، دو LDAP اور LDAP ریپلیکا سرورز، 1000 میل باکسز کے ساتھ چار میل اسٹوریج اور تین MTAs ہیں۔ یہ دیکھتے ہوئے کہ ہم ایک میل سرور کے ساتھ کام کر رہے ہیں، اسے تین قسم کی ٹریفک موصول ہوگی جس میں توازن کی ضرورت ہے: ویب کلائنٹ کو ڈاؤن لوڈ کرنے کے لیے HTTP، نیز ای میل بھیجنے کے لیے POP اور SMTP۔ اس صورت میں، HTTP ٹریفک آئی پی ایڈریس 192.168.0.57 اور 192.168.0.58 کے ساتھ Zimbra پراکسی سرورز پر جائے گی، اور SMTP ٹریفک IP ایڈریس 192.168.0.77 اور 192.168.0.78 والے MTA سرورز پر جائے گی۔
جیسا کہ پہلے ہی ذکر کیا جا چکا ہے، اس بات کو یقینی بنانے کے لیے کہ درخواستیں سرورز کے درمیان یکساں طور پر تقسیم ہوں، ہم HAProxy لوڈ بیلنسر استعمال کریں گے، جو Ubuntu 18.04 پر چلنے والے Zimbra انفراسٹرکچر انگریس نوڈ پر چلے گا۔ اس آپریٹنگ سسٹم پر ہاپروکسی کو انسٹال کرنا کمانڈ کا استعمال کرتے ہوئے کیا جاتا ہے۔ sudo apt-get install haproxy. اس کے بعد آپ کو فائل میں ضرورت ہے۔ /etc/default/haproxy پیرامیٹر تبدیل کریں فعال = 0 پر فعال = 1. اب، یہ یقینی بنانے کے لیے کہ ہاپروکسی کام کر رہی ہے، صرف کمانڈ درج کریں۔ سروس haproxy. اگر یہ سروس چل رہی ہے تو یہ کمانڈ کے آؤٹ پٹ سے واضح ہو جائے گا۔
HAProxy کے اہم نقصانات میں سے ایک یہ ہے کہ یہ پہلے سے طے شدہ طور پر کنیکٹنگ کلائنٹ کے IP ایڈریس کو منتقل نہیں کرتا ہے، اس کی جگہ اسے خود لے لیتا ہے۔ یہ ایسے حالات کا باعث بن سکتا ہے جہاں حملہ آوروں کی طرف سے بھیجی گئی ای میلز کو بلیک لسٹ میں شامل کرنے کے لیے IP ایڈریس کے ذریعے شناخت نہیں کیا جا سکتا ہے۔ تاہم، یہ مسئلہ حل کیا جا سکتا ہے. ایسا کرنے کے لیے آپ کو فائل میں ترمیم کرنے کی ضرورت ہے۔ /opt/zimbra/common/conf/master.cf.in پوسٹ فکس والے سرورز پر اور اس میں درج ذیل لائنیں شامل کریں:
26 inet n - n - 1 postscreen
-o postscreen_upstream_proxy_protocol=haproxy
466 inet n - n - - smtpd
%%uncomment SERVICE:opendkim%% -o content_filter=scan:[%%zimbraLocalBindAddress%%]:10030
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=
-o smtpd_data_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o syslog_name=postfix/smtps
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_upstream_proxy_protocol=haproxy
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_filter=[%%zimbraLocalBindAddress%%]:10027
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_options=speed_adjust
588 inet n - n - - smtpd
%%uncomment SERVICE:opendkim%% -o content_filter=scan:[%%zimbraLocalBindAddress%%]:10030
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=%%zimbraMtaSaslAuthEnable%%
-o smtpd_tls_security_level=%%zimbraMtaTlsSecurityLevel%%
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_data_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o syslog_name=postfix/submission
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_upstream_proxy_protocol=haproxy
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_filter=[%%zimbraLocalBindAddress%%]:10027
%%uncomment LOCAL:postjournal_enabled%% -o smtpd_proxy_options=speed_adjust
اس کی وجہ سے، ہم 26، 466 اور 588 بندرگاہیں کھولیں گے، جو HAProxy سے آنے والی ٹریفک وصول کریں گی۔ فائلوں کے محفوظ ہونے کے بعد، آپ کو zmmtactl restart کمانڈ کا استعمال کرتے ہوئے تمام سرورز پر پوسٹ فکس کو دوبارہ شروع کرنا چاہیے۔
اس کے بعد، آئیے HAProxy کو ترتیب دینا شروع کریں۔ ایسا کرنے کے لیے پہلے سیٹنگ فائل کی بیک اپ کاپی بنائیں cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. پھر سورس فائل کو ٹیکسٹ ایڈیٹر میں کھولیں۔ /etc/haproxy/haproxy.cfg اور قدم بہ قدم اس میں ضروری ترتیبات شامل کرنا شروع کریں۔ پہلے بلاک میں ایک سرور شامل کیا جائے گا جو لاگز لیتا ہے، بیک وقت کنکشنز کی زیادہ سے زیادہ اجازت شدہ تعداد کو ترتیب دیتا ہے، اور ساتھ ہی اس صارف کا نام اور گروپ بھی بتاتا ہے جس سے عملدرآمد کا عمل تعلق رکھتا ہے۔
global
user daemon
group daemon
daemon
log 127.0.0.1 daemon
maxconn 5000
chroot /var/lib/haproxy
بیک وقت 5000 کنکشن کا اعداد و شمار ایک وجہ سے ظاہر ہوا۔ چونکہ ہمارے انفراسٹرکچر میں ہمارے پاس 4000 میل باکسز ہیں، ہمیں اس امکان پر غور کرنے کی ضرورت ہے کہ وہ سب ایک ہی وقت میں اپنے کام کے ای میل تک رسائی حاصل کریں گے۔ اس کے علاوہ، ان کی تعداد میں اضافہ کی صورت میں ایک چھوٹا سا ریزرو چھوڑنا ضروری ہے۔
اب آئیے پہلے سے طے شدہ ترتیبات کے ساتھ ایک بلاک شامل کریں:
defaults
timeout client 1m
log global
mode tcp
timeout server 1m
timeout connect 5s
یہ بلاک کلائنٹ اور سرور کے لیے کنکشن کی میعاد ختم ہونے پر اسے بند کرنے کے لیے زیادہ سے زیادہ ٹائم آؤٹ سیٹ کرتا ہے، اور HAProxy کے آپریٹنگ موڈ کو بھی سیٹ کرتا ہے۔ ہمارے معاملے میں، لوڈ بیلنسر TCP موڈ میں کام کرتا ہے، یعنی یہ TCP پیکٹوں کو ان کے مواد کا تجزیہ کیے بغیر آسانی سے منتقل کرتا ہے۔
اگلا ہم مختلف بندرگاہوں پر کنکشن کے لیے قواعد شامل کریں گے۔ مثال کے طور پر، اگر پورٹ 25 کو SMTP کنکشنز اور میل کے لیے استعمال کیا جاتا ہے، تو اس سے کنکشن ہمارے انفراسٹرکچر میں دستیاب MTAs کو بھیجنا سمجھ میں آتا ہے۔ اگر کنکشن پورٹ 80 پر ہے، تو یہ ایک HTTP درخواست ہے جسے Zimbra Proxy کو بھیجنے کی ضرورت ہے۔
پورٹ 25 کے لیے اصول:
frontend smtp-25
bind *:27
default_backend backend-smtp-25
backend backend-smtp-25
server mta1 192.168.0.77:26 send-proxy
server mta2 192.168.0.78:26 send-proxy
پورٹ 465 کے لیے اصول:
frontend smtp-465
bind *:467
default_backend backend-smtp-465
backend backend-smtp-465
server mta1 192.168.0.77:466 send-proxy
server mta2 192.168.0.78:466 send-proxy
پورٹ 587 کے لیے اصول:
frontend smtp-587
bind *:589
default_backend backend-smtp-587
backend backend-smtp-587
server mail1 192.168.0.77:588 send-proxy
server mail2 192.168.0.78:588 send-proxy
پورٹ 80 کے لیے اصول:
frontend http-80
bind *:80
default_backend http-80
backend http-80
mode tcp
server zproxy1 192.168.0.57:80 check
server zproxy2 192.168.0.58:80 check
پورٹ 443 کے لیے اصول:
frontend https
bind *:443
default_backend https-443
backend https-443
mode tcp
server zproxy1 192.168.0.57:80 check
server zproxy2 192.168.0.58:80 check
براہ کرم نوٹ کریں کہ TCP پیکٹ کو MTA کو بھیجنے کے قواعد میں، ان کے پتوں کے آگے ایک پیرامیٹر ہوتا ہے۔ بھیجنے کی پراکسی. یہ ضروری ہے تاکہ، پوسٹ فکس سیٹنگز میں ہم نے پہلے کی گئی تبدیلیوں کے مطابق، اس کے بھیجنے والے کا اصل IP ایڈریس TCP پیکٹ کے ساتھ بھیجا جائے۔
اب جب کہ HAProxy میں تمام ضروری تبدیلیاں کر دی گئی ہیں، آپ کمانڈ کا استعمال کرتے ہوئے سروس کو دوبارہ شروع کر سکتے ہیں۔ سروس haproxy دوبارہ شروع اور اسے استعمال کرنا شروع کریں۔
Zextras Suite سے متعلق تمام سوالات کے لیے، آپ Zextras Ekaterina Triandafilidi کے نمائندے سے ای میل کے ذریعے رابطہ کر سکتے ہیں۔ [ای میل محفوظ]
ماخذ: www.habr.com