ProHoster > Блог > Administrado > Ŝarĝekvilibro en Zimbra Malfermfonta Eldono uzante HAProxy

Ŝarĝekvilibro en Zimbra Malfermfonta Eldono uzante HAProxy

Unu el la ĉefaj taskoj dum konstruado de grandskalaj Zimbra OSE-infrastrukturoj estas taŭga ŝarĝbalancado. Krom tio, ke ĝi pliigas la misfunkciadon de la servo, sen ŝarĝo-ekvilibro estas neeble certigi la saman respondecon de la servo por ĉiuj uzantoj. Por solvi ĉi tiun problemon, oni uzas ŝarĝbalancilojn - softvaraj kaj aparataj solvoj, kiuj redistribuas petojn inter serviloj. Inter ili estas sufiĉe primitivaj, kiel RoundRobin, kiu simple sendas ĉiun postan peton al la sekva servilo en la listo, kaj ekzistas ankaŭ pli progresintaj, ekzemple HAProxy, kiu estas vaste uzata en komputikaj infrastrukturoj de alta ŝarĝo pro nombro da gravaj avantaĝoj. Ni rigardu kiel vi povas igi la ŝarĝbalancilon de HAProxy kaj Zimbra OSE labori kune.

Ŝarĝekvilibro en Zimbra Malfermfonta Eldono uzante HAProxy

Do, laŭ la kondiĉoj de la tasko, ni ricevas la infrastrukturon Zimbra OSE, kiu havas du Zimbra Proxy, du LDAP kaj LDAP Replica serviloj, kvar poŝto stokado kun 1000 leterkestoj ĉiu kaj tri MTA. Konsiderante ke ni traktas poŝtservilon, estos tri specoj de trafiko, kiuj bezonos ekvilibron: HTTP por elŝuti la retklienton, kaj POP kaj SMTP por sendi retpoŝton. En ĉi tiu kazo, HTTP-trafiko iros al Zimbra Proxy-serviloj kun IP-adresoj 192.168.0.57 kaj 192.168.0.58, kaj SMTP-trafiko iros al MTA-serviloj kun IP-adresoj 192.168.0.77 kaj 192.168.0.78.

Kiel jam menciite, por certigi, ke petoj estas egale distribuitaj inter la serviloj, ni uzos la ŝarĝbalancilon HAProxy, kiu funkcios sur la infrastruktura enirnodo de Zimbra funkcianta Ubuntu 18.04. Instalado de haproxy sur ĉi tiu operaciumo estas farita per la komando sudo apt-get install haproxy. Post tio vi bezonas en la dosiero /etc/default/haproxy ŝanĝi parametron EKBILITA=0 sur EKBILITA=1. Nun, por certigi, ke haproxy funkcias, simple enigu la komandon servo haproxy. Se ĉi tiu servo funkcias, tio estos klara de la eligo de la komando.

Unu el la ĉefaj malavantaĝoj de HAProxy estas, ke defaŭlte ĝi ne transdonas la IP-adreson de la konektanta kliento, anstataŭigante ĝin per sia propra. Ĉi tio povas konduki al situacioj, kie retpoŝtoj senditaj de atakantoj ne povas esti identigitaj per IP-adreso por aldoni ĝin al la nigra listo. Tamen, ĉi tiu problemo povas esti solvita. Por fari tion vi devas redakti la dosieron /opt/zimbra/common/conf/master.cf.in sur serviloj kun Postfix kaj aldonu la sekvajn liniojn al ĝi:

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

Pro tio, ni malfermos havenojn 26, 466 kaj 588, kiuj ricevos envenantan trafikon de HAProxy. Post kiam la dosieroj estas konservitaj, vi devus rekomenci Postfix en ĉiuj serviloj per la zmmtactl restart-komando.

Post tio, ni komencu agordi HAProxy. Por fari tion, unue kreu rezervan kopion de la agorda dosiero cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak. Poste malfermu la fontdosieron en tekstredaktilo /etc/haproxy/haproxy.cfg kaj komencu aldoni la necesajn agordojn al ĝi paŝon post paŝo. La unua bloko aldonos servilon kiu prenas protokolojn, fiksante la maksimuman permesitan nombron da samtempaj konektoj, kaj ankaŭ precizigante la nomon kaj grupon de la uzanto al kiu la ekzekuta procezo apartenos.

global
    user daemon
    group daemon
    daemon
    log 127.0.0.1 daemon
    maxconn 5000
    chroot /var/lib/haproxy

La cifero de 5000 samtempaj konektoj aperis ial. Ĉar ni havas 4000 leterkestojn en nia infrastrukturo, ni devas konsideri la eblecon, ke ili ĉiuj aliros sian laborretpoŝton samtempe. Krome, necesas lasi malgrandan rezervon, se ilia nombro pligrandiĝos.

Nun ni aldonu blokon kun defaŭltaj agordoj:

defaults
        timeout client 1m
        log global
        mode tcp
        timeout server 1m
        timeout connect 5s

Ĉi tiu bloko fiksas la maksimuman tempon por ke la kliento kaj servilo fermu la konekton kiam ĝi eksvalidiĝas, kaj ankaŭ fiksas la operacian reĝimon de HAProxy. En nia kazo, la ŝarĝbalancilo funkcias en TCP-reĝimo, tio estas, ĝi simple transdonas TCP-pakojn sen analizi ilian enhavon.

Poste ni aldonos regulojn por konektoj sur diversaj havenoj. Ekzemple, se la haveno 25 estas uzata por SMTP-konektoj kaj poŝto, tiam havas sencon plusendi konektojn al ĝi al la MTA-oj disponeblaj en nia infrastrukturo. Se la konekto estas sur la haveno 80, tiam ĉi tio estas http-peto, kiu devas esti plusendita al Zimbra Proxy.

Regulo por haveno 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

Regulo por haveno 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

Regulo por haveno 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

Regulo por haveno 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

Regulo por haveno 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

Bonvolu noti, ke en la reguloj por plusendi TCP-pakojn al la MTA, apud iliaj adresoj estas parametro sendi-prokurilon. Ĉi tio estas necesa por ke, laŭ la ŝanĝoj, kiujn ni antaŭe faris al la agordoj de Postfix, la originala IP-adreso de ĝia sendinto estu sendita kune kun TCP-pakoj.

Nun kiam ĉiuj necesaj ŝanĝoj estis faritaj al HAProxy, vi povas rekomenci la servon per la komando rekomenco de servo haproxy kaj komencu uzi ĝin.

Por ĉiuj demandoj rilataj al Zextras Suite, vi povas kontakti la Reprezentanton de Zextras Ekaterina Triandafilidi retpoŝte [retpoŝte protektita]

fonto: www.habr.com

Aldoni komenton