Zimbra Collaboration Suiteでのメールストレージの最適化

私たちのうちのXNUMXつでは、 以前の記事は、企業で Zimbra Collabortion Suite を導入する際のインフラストラクチャ計画に特化していますが、このソリューションの運用における主な制限は、メール ストレージ内のディスク デバイスの I/O 速度であると言われています。 実際、企業の数百人の従業員が同じメール ストレージに同時にアクセスする場合、ハード ドライブからの情報の書き込みと読み取りのためのチャネル幅は、サービスの応答性の高い動作には十分ではない可能性があります。 また、Zimbra の小規模なインストールではこれが特に問題にならないとしても、大企業や SaaS プロバイダーの場合、これらすべてが電子メールの応答不能につながり、その結果、従業員の効率が低下するだけでなく、違反につながる可能性があります。 SLAの。 そのため、大規模な Zimbra インストールを設計および運用する場合は、メール ストレージのハード ドライブのパフォーマンスの最適化に特別な注意を払う必要があります。 XNUMX つのケースを見て、それぞれのケースでディスク ストレージの負荷を最適化する方法を調べてみましょう。

1. 大規模な Zimbra インストール設計時の最適化

高負荷の Zimbra インストールの設計段階で、管理者はどのストレージ システムを使用するかを選択する必要があります。 この問題を判断するには、ハード ドライブの主な負荷は、Zimbra Collaboration Suite、Apache Lucene 検索エンジン、および BLOB ストレージに含まれる MariaDB DBMS から発生していることを知っておく必要があります。 そのため、これらのソフトウェア製品を高負荷条件下で動作させるには、高速かつ信頼性の高い機器が必要です。

通常の状態では、Zimbra はハードドライブの RAID と NFS プロトコル経由で接続されたストレージの両方にインストールできます。 非常に小規模なインストールの場合は、Zimbra を通常の SATA ドライブにインストールできます。 ただし、大規模な設備の場合、これらのテクノロジーはすべて、記録速度の低下や信頼性の低下というさまざまな欠点を示しており、これは大企業にとっても、特に SaaS プロバイダーにとっても受け入れがたいものです。

このため、大規模な Zimbra インフラストラクチャでは SAN を使用するのが最適です。 現在、ストレージ デバイスに最大のスループットを提供できるのはこのテクノロジーであり、同時に大量のキャッシュを接続できるため、その使用が企業に実質的に大きなリスクをもたらすことはありません。 NVRAM を使用することをお勧めします。NVRAM は、書き込み時の速度を上げるために多くの SAN で使用されています。 ただし、電源の問題が発生した場合にメディアに修復不可能な損傷が生じたり、データが失われる可能性があるため、ディスク自体に記録されたデータのキャッシュを無効にすることをお勧めします。

ファイル システムの選択に関しては、標準の Linux Ext3/Ext4 を使用するのが最善の選択です。 ファイル システムに関連する主なニュアンスは、パラメータを使用してマウントする必要があるということです。 -ノアタイム。 このオプションを選択すると、ファイルへの最終アクセス時刻を記録する機能が無効になり、読み書きの負荷が大幅に軽減されます。 一般に、Zimbra 用の ext3 または ext4 ファイル システムを作成する場合は、次のユーティリティ パラメータを使用する必要があります。 mke2fs:

-j — ファイル システム ジャーナルを作成するには、ext3/ext4 ジャーナルを含むファイル システムを作成します。
-L 名前 - /etc/fstab で使用するボリューム名を作成するには
-O ディレクトリインデックス - ハッシュされた検索ツリーを使用して、大きなディレクトリ内のファイル検索を高速化するには
-m 2 — 大規模なファイル システムのボリュームの 2% をルート ディレクトリ用に予約する場合
-Jサイズ=400 — 大きな雑誌を作るには
-b 4096 — ブロック サイズをバイト単位で決定するには
-i 10240 - メッセージ ストレージの場合、この設定は平均メッセージ サイズに対応する必要があります。 このパラメータの値は後で変更できないため、このパラメータには細心の注意を払う必要があります。

有効にすることもお勧めします 同期 BLOB ストレージ、Lucene 検索メタデータ ストレージ、MTA キュー ストレージの場合。 Zimbra は通常ユーティリティを使用するため、これを行う必要があります。 fsync データを含む BLOB をディスクに確実に書き込むため。 ただし、Zimbra メール ストアまたは MTA がメッセージ配信中に新しいファイルを作成する場合、対応するフォルダー内で発生した変更をディスクに書き込む必要があります。 そのため、ファイルがすでにディスクに書き込まれている場合でも、 fsync、ディレクトリへの追加の記録はディスクに書き込まれる時間がなく、その結果、突然のサーバー障害により失われる可能性があります。 ご利用のおかげで 同期 これらの問題は回避できます。

2. Zimbra インフラストラクチャの実行による最適化

Zimbra を数年間使用すると、ユーザー数が大幅に増加し、サービスの応答性が日に日に低下することがよくあります。 この状況から抜け出す方法は明らかです。インフラストラクチャに新しいサーバーを追加するだけで、サービスが以前と同じくらい迅速に動作できるようになります。 一方、パフォーマンスを向上させるためにインフラストラクチャに新しいサーバーをすぐに追加できるとは限りません。 IT 管理者は、新しいサーバーの購入について、経理部門やセキュリティ部門との調整に長い時間を費やす必要があることが多く、さらに、新しいサーバーの納入が遅れたり、間違ったものを納入したりするサプライヤーに失望させられることもよくあります。

もちろん、拡張のための予備を常に持ち、誰にも依存しないように、Zimbra インフラストラクチャを予備で構築することが最善ですが、すでに間違いが犯されている場合、IT マネージャーは次のようにしてその結果を平準化することしかできません。できるだけ。 たとえば、IT 管理者は、運用中に定期的にハードドライブにアクセスするため、Zimbra のパフォーマンスに悪影響を及ぼす可能性がある Linux システム サービスを一時的に無効にすることで、生産性をわずかに向上させることができます。 したがって、次のものを一時的に無効にすることができます。

autofs、netfs - リモート ファイル システム ディスカバリ サービス
カップ — プリントサービス
xinetd、vsftpd - おそらく必要のない組み込みの *NIX サービス
ポートマップ、rpcsvcgssd、rpcgssd、rpcidmapd — リモート プロシージャ コール サービス。通常はネットワーク ファイル システムと組み合わせて使用​​されます。
dovecot、cyrus-imapd、sendmail、exim、postfix、ldap — Zimbra Collaboration Suiteに含まれる主要ユーティリティの複製
slocate/updatedb - Zimbra は各メッセージを個別のファイルに保存するため、updatedb サービスを毎日実行すると問題が発生する可能性があるため、サーバーの負荷が最も少ないときに手動で実行することができます。

これらのサービスを無効にした結果としてシステム リソースが節約されることはそれほど重要ではありませんが、不可抗力に近い状況ではこれでも非常に役立ちます。 新しいサーバーを Zimbra インフラストラクチャに追加したら、以前に無効にしたサービスを再度有効にすることをお勧めします。

また、syslog サービスを別のサーバーに移動して、動作中にメール ストレージのハード ドライブに負荷がかからないようにして、Zimbra の動作を最適化することもできます。 安価なシングルボード Raspberry Pi を含め、ほとんどすべてのコンピューターがこれらの目的に適しています。

出所： habr.com