Zimbra Collaboration Suiteをインストールするためのインフラストラクチャの計画

企業における IT ソリューションの実装は設計から始まります。 この段階で、IT 管理者は、一方ではすべてのユーザーに十分な数のサーバーが存在し、他方ではこれらのサーバーの価格と品質の比率が適切になるように、サーバーの数とその特性を計算する必要があります。は最適であり、新しい情報システム用のコンピューティング インフラストラクチャを構築するコストが企業の IT 予算に深刻な穴を与えることはありません。 Zimbra Collaboration Suite をエンタープライズに実装するためのインフラストラクチャを設計する方法を考えてみましょう。

Zimbra Collaboration Suiteをインストールするためのインフラストラクチャの計画

他のソリューションと比較した Zimbra の主な特徴は、ZCS の場合、プロセッサーのパワーや RAM がボトルネックになることはほとんどないことです。 通常、主な制限はハードドライブの入出力速度であるため、データストレージに主な注意を払う必要があります。 運用環境における Zimbra の公式に記載されている最小要件は、クロック速度 4 ギガヘルツの 64 コア 2 ビット プロセッサ、システム ファイルとログ用に 10 ギガバイト、少なくとも 8 ギガバイトの RAM です。 通常、サーバーが応答的に動作するには、これらの特性があれば十分です。 しかし、10 人のユーザーに対して Zimbra を実装する必要がある場合はどうなるでしょうか? この場合、どのサーバーをどのように実装すればよいでしょうか?

まず、10 ユーザーのインフラストラクチャはマルチサーバーである必要があるという事実から始めましょう。 マルチサーバーインフラストラクチャにより、一方では Zimbra の拡張性が可能になり、他方ではユーザーが大量に流入しても情報システムの応答性の高い動作を実現できます。 通常、Zimbra サーバーが効率的にサービスを提供できるユーザーの数を正確に予測することは非常に困難です。これは、ユーザーのカレンダーや電子メールの使用量、および使用するプロトコルに大きく依存するためです。 そのため、例として 4 つのメール ストレージを実装します。 容量が不足している場合、または深刻な過剰な場合は、電源をオフにするか、別の容量を追加することが可能です。

したがって、10.000 人向けのインフラストラクチャを設計する場合は、LDAP、MTA、プロキシ サーバーと 4 つのメール ストレージを作成する必要があります。 LDAP、MTA、およびプロキシ サーバーは仮想化できることに注意してください。 これにより、サーバー ハードウェアのコストが削減され、データのバックアップと復元が容易になりますが、その一方で、物理サーバーに障害が発生すると、即座に MTA、LDAP、およびプロキシが利用できなくなるリスクがあります。 そのため、物理サーバーと仮想サーバーの選択は、緊急時にどれだけのダウンタイムを許容できるかに基づいて行う必要があります。 メールストレージは物理サーバー上に配置するのが最適です。これは、Zimbra のパフォーマンスを制限する書き込みサイクルの大部分が物理サーバー上で発生するためです。したがって、データ転送用のチャネルの数が増えると、Zimbra のパフォーマンスが大幅に向上します。

原則として、LDAP、MTA、プロキシ、ネットワークストレージサーバーを作成し、それらを単一のインフラストラクチャに結合すると、10000 ユーザー向けの Zimbra Collaboration Suite を試運転する準備が整います。 この構成の操作は非常に簡単です。

Zimbra Collaboration Suiteをインストールするためのインフラストラクチャの計画

この図は、システムのメイン ノードと、それらの間を循環するデータ フローを示しています。 この構成では、インフラストラクチャはデータ損失やサーバーの障害に伴うダウンタイムなどから完全に保護されなくなります。 これらの問題からインフラストラクチャを保護する方法を具体的に見てみましょう。

主な方法はハードウェアの冗長化です。 追加の MTA ノードとプロキシ ノードは、メイン サーバーに障害が発生した場合に、一時的にメイン サーバーの役割を引き継ぐことができます。 重要なインフラストラクチャのノードを複製することは、ほとんどの場合、優れたアイデアですが、望ましい程度に常に実現可能であるとは限りません。 顕著な例は、メールが保存されるサーバーの予約です。 現在、Zimbra Collaboration Suite オープンソース エディションは重複ストアの作成をサポートしていないため、これらのサーバーのいずれかに障害が発生した場合、ダウンタイムは避けられません。メール ストアの障害によるダウンタイムを減らすために、IT 管理者はそのバックアップ コピーを展開できます。別のサーバー上で。

Zimbra OSE には組み込みのバックアップ システムがないため、リアルタイム バックアップをサポートする Zextras Backup と外部ストレージが必要になります。 Zextras Backup は、完全バックアップおよび増分バックアップを作成するときに、すべてのデータを /opt/zimbra/backup フォルダーに保存するため、サーバーの XNUMX つが故障した場合に備えて、外部、ネットワーク、さらにはクラウド ストレージをそのフォルダーにマウントすることが合理的です。緊急時の最新のバックアップ コピーが保存されたメディアが手元にあります。 バックアップ物理サーバー、仮想マシン、またはクラウドに展開できます。 サーバーに送られるジャンクトラフィックの量を減らすために、Zimbra プロキシサーバーの前にスパムフィルターを備えた MTA をインストールすることもお勧めします。

その結果、保護された Zimbra インフラストラクチャは次のようになります。

Zimbra Collaboration Suiteをインストールするためのインフラストラクチャの計画

この構成により、Zimbra インフラストラクチャは 10.000 人のユーザーに高品質のサービスを提供できるだけでなく、緊急事態が発生した場合でも、その影響をできるだけ早く排除できるようになります。

出所: habr.com

コメントを追加します