大規模な Zimbra OSE インフラストラクチャを構築する際の主なタスクの XNUMX つは、適切なロード バランシングです。 サービスの耐障害性を高めるだけでなく、負荷分散がなければ、すべてのユーザーに対してサービスの同じ応答性を保証することは不可能です。 この問題を解決するには、サーバー間でリクエストを再分散するソフトウェアおよびハードウェア ソリューションであるロード バランサーが使用されます。 その中には、次のすべてのリクエストをリスト内の次のサーバーに送信するだけの RoundRobin のようなかなり原始的なものと、より高度なもの (たとえば、HAProxy など) があり、これは高負荷のコンピューティング インフラストラクチャで広く使用されています。多くの重要な利点。 HAProxy ロードバランサーと Zimbra OSE がどのように連携できるかを見てみましょう。
したがって、問題の条件によれば、1000 つの Zimbra プロキシ、192.168.0.57 つの LDAP および LDAP レプリカ サーバー、それぞれ 192.168.0.58 個のメールボックスを持つ 192.168.0.77 つのメール ストア、および 192.168.0.78 つの MTA を備えた Zimbra OSE インフラストラクチャが与えられます。 メール サーバーを扱っていることを考えると、Web クライアントをダウンロードするための HTTP、電子メールを送信するための POP および SMTP という XNUMX 種類のトラフィックを受信することになり、バランスを取る必要があります。 この場合、HTTP トラフィックは IP アドレス XNUMX および XNUMX の Zimbra プロキシ サーバーに送信され、SMTP トラフィックは IP アドレス XNUMX および XNUMX の MTA サーバーに送信されます。
すでに述べたように、サーバー間でリクエストを均等に分散するために、Ubuntu 18.04 を実行している Zimbra インフラストラクチャの入力ノードで実行される HAProxy ロード バランサーを使用します。 このオペレーティング システムに haproxy をインストールするには、次のコマンドを使用します。 sudo apt-get install haproxy。 その後、ファイル内で必要になります /etc/default/haproxy パラメータの変更 有効=0 на 有効=1。 ここで、haproxy が動作していることを確認するために、次のコマンドを入力してください。 サービスハプロキシ。 このサービスが実行されている場合は、コマンドの出力から明らかです。
HAProxy の主な欠点の XNUMX つは、デフォルトでは接続されたクライアントの IP アドレスを送信せず、独自の IP アドレスに置き換えることです。 これにより、攻撃者が送信した手紙を IP アドレスで識別してブラックリストに追加できないという状況が発生する可能性があります。 ただし、この問題は解決できます。 これを行うには、ファイルを編集する必要があります /opt/zimbra/common/conf/master.cf.in Postfix サーバー上で次の行を追加します。
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このため、HAProxy からの受信トラフィックを受信するポート 26、466、および 588 を開きます。 ファイルが保存されたら、zmmtactl restart コマンドを使用してすべてのサーバーで Postfix を再起動します。
その後、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 接続とメール転送に使用されている場合、そのポートへの接続をインフラストラクチャ内にある MTA に転送するのが合理的です。 接続がポート 80 上にある場合、これは Zimbra プロキシに転送する必要がある http リクエストです。
ポート 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 checkTCP パケットを MTA に転送するルールでは、アドレスの横にパラメータがあることに注意してください。 送信プロキシ。 これは、Postfix 設定に対して以前に行った変更に従って、送信者の元の IP アドレスも TCP パケットとともに送信されるようにするために必要です。
HAProxy に必要な変更がすべて加えられたので、次のコマンドを使用してサービスを再起動できます。 サービスハプロキシの再起動 そして使い始めてください。
Zextras Suite に関するすべての質問については、Zextras Ekaterina Triandafilidi の代表者に電子メールでお問い合わせください。 [メール保護]
出所： habr.com