複数のストアパーティション

メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUN よりも、多数の小さなストライプあるいは LUN のほうが、より大きな IOPS が得られます。

いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の多数のパーティション) は最適化と管理が容易です。

ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。

ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。

• 最初に、電源、ハードウェア、またはオペレーティングシステムの障害によるクラッシュからの回復と並行して、fsck コマンドが複数のファイルシステム上で動作します。HA プラットフォームで強く推奨され、必須となっているジャーナリングファイルシステムを使用している場合は、この要素は小さなものとなります。

• 次に、バックアップおよび回復手順が複数のストアパーティション上で並行して実行されます。メッセージストアではすべてのストアパーティションで単独のデータベースが使用されているため、この並行動作は mboxlist ディレクトリの垂直的スケーラビリティーにより制限されます。ストアパーティションあたりの 1 つのスレッドの実行と並行して、ストアクリーンアップ手順 (expire および purge) が実行されます。

• 最後に、ミラーリングまたは RAID 再同期手順が、小さな LUN で高速に実行されます。ここでは厳密な規則はありませんが、ほとんどの場合はストアパーティションを構成するスピンドルを 10 個までにすることをお勧めします。

ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの家庭用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。