
私のサーバーには数日以内にいっぱいの特定のパーティション(/ var)があります。私はすべてのユーザーメールが送信される忙しいメールサーバーを運営しています。
ただし、今後はより多くの電子メールに対応するためにストレージ容量を増やす必要があります。
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 796M 556K 796M 1% /run
/dev/sda6 254G 32G 209G 14% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 4.0K 5.0M 1% /run/lock
none 3.9G 80K 3.9G 1% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda1 188M 66M 114M 37% /boot
/dev/sda7 1.6T 1.2T 364G 76% /var
だから、オンラインで多くの情報を確認し、いくつかの提案を受けました。
私が最初に触れたのは、LVMパーティショニングを使用することでした。したがって、サーバーに2番目のハードドライブを追加してから、LVMを使用して2つのハードドライブを1つの論理パーティションにマージできます。このタスクを正確に実行する方法を読んでいる間に1つのドライブに障害が発生した場合は、データが失われて簡単に回復する方法がないことがわかりました。これにより、2番目のオプションが見つかりました。
2つ目は、複数のディレクトリを1つにマージできる統合ファイルシステムを使用することです。これまで、私はUnionfs、aufs、mhddfs、overlayfsの実装に触れました。この場合、2番目のハードドライブを起動したり、ルートディレクトリのように人口の少ないパーティションからいくつかのスペースを借りることができます。
主流のLinuxカーネルに追加された後、ローカルホストでoverlayfsを試してみました。
多くのオプションがあり、本番にとって重要なメールサーバーでどのソリューションを選択するのかわかりません。いくつかのアドバイスを聞きたいです。ありがとうございます。
答え1
まず、ここでファイルシステムの上書き/結合は正解ではありません。これは、ほとんどのデータを含む読み取り専用ファイルシステムがあり、書き込み可能なファイルシステムの上にいくつかの制限されたカスタマイズが必要な状況です。例えば、LiveCDは、オーバーレイファイルシステムを使用して、書き込み可能なファイルシステムの感覚を可能にする。またはメディアが読み取り専用であるにもかかわらず)。
LVMはあなたが望むことがほとんど確実であり、必ずしも信頼できないわけではありません(複製を介してRAID設定を実行できます)。または、新しい(より大きな)ハードドライブを挿入して/var
上部に置くこともできます。ただし、/var/mail
デフォルトのメール保存ディレクトリをここに置き、残りはそのままにしておくことをお勧めします。
理想的には、同じサイズのハードドライブを複数持ち、上部のハードドライブ/var/mail
でRAID 10またはRAID 5/6を実行し、ユーザーに古い電子メールを含むハードドライブをクリーンアップさせることを検討する必要があります。サーバー(この状況は、ほとんどのメールプロバイダがサーバーのメールストレージに制限がある理由の一部です。)
答え2
最善の方法は、少なくとも2台の大型ドライブ(4TB以上)を追加し、RAID-1またはRAID-10の一種を使用することです。 「ミッションクリティカル」サービスにストレージ冗長性がない場合は、次のことができます。間違っています。
2つのドライブのみを追加する場合は、RAID-1を使用してください。 4つ以上の場合はRAID-10を使用してください。メールの保存には多くのI/O帯域幅が必要で、RAID-5はRAID-1/RAID-10よりはるかに遅いので、メールにはRAID-5またはRAID-6を使用しないことをお勧めします(RAID-6ははるかに遅い)。 。
mdadm
、およびを含むRAID-1 / RAID-10を実装する方法はいくつかありますlvm
。これらのいずれかを使用してRAIDアレイを作成し、必要なファイルシステムにフォーマットしてからマウントできます/var/mail
。ファイルシステムが拡張をサポートしている限り、後で必要に応じてより多くのドライブを追加することもできます(例:xfsにはxfs_growfs
ext2/3/4にありますresize2fs
)。
別のオプションはを使用することですbtrfs
。 RAID と同様の機能をネイティブにサポートし、より多くのストレージドライブを追加すると、ファイルシステムが自動的に拡張されます。また、エラーの検出と修正、スナップショット、サブボリューム、透過的なファイル圧縮などをサポートしています。
ZFSはbtrfs(私が個人的に使用する)と似た機能を持っていますが、メインラインカーネルの一部ではないという欠点です(おそらくCDDLとGPLの間のライセンスの非互換性のためには発生しません)。パッチまたはDKMSモジュールとしてのみ使用できます。最近では大きな問題ではありませんが、より多くの作業を行う必要があります。
私の提案はbtrfsまたはzfsを使用することです。 IMOの最近では、すでに使用していて、その技術の多くの経験と投資がない場合、通常の古いmdadmやlvmを使用する理由はありません。
このサイトには、mdadm、lvm、btrfs、および/またはzfsなどを設定する方法を詳しく説明する多くの質問と回答があります。
それにもかかわらず、RAIDまたはRAIDに似たファイルシステムを実装する方法に関係なく、ダウンタイムを最小限に抑えながら、古いメールを新しいファイルシステムに転送する必要があります。すべての場合において、プロセスは次のようになります。
新しいドライブを取り付けます。ホットスワップ可能なベイがない場合は、少しダウンタイムが必要です。
新しいRAIDおよび/またはファイルシステムの設定
次のようにインストールしてください。
/var/mail.new
同期
/var/mail/
先/var/mail.new/
このプロセスを完了する時間があるまで(可能な限り勤務時間外)、手順4を必要なだけ繰り返すことができます。ステップ1で発生する可能性があるダウンタイムを除いて、これまでユーザーに表示されるダウンタイムはありません。せいぜい、ジョブが
rsync
実行されたときにシステムが通常より少し遅いことに気づいたでしょう。MTA(sendmail、exim、postfix、またはその他)およびpop / imapデーモンおよびその他の書き込みを停止します
/var/mail/
。メールを読むためにシェルにログインしているユーザーがいる場合(例:muttを使用)、ログアウトするように指示します。完了したら、以前に再度ログインしないようにしてください。つまり、書き込みを中止し、
/var/mail
後で手順13で再開する必要があります。最後の実行以降のすべての変更を同期するには、最後の
rsync
from/var/mail/
toを実行してください。/var/mail.new/
mv /var/mail /var/mail.old
mkdir /var/mail
マウントを解除して
/var/mail.new
から再度マウントします/var/mail
(おそらくmount --move /var/mail.new /var/mail
Austin Hemmelgarnが述べたように)。所有権と権限を確認し、まったく同じであることを
/var/mail.old
確認してください。/var/mail
これは次の方法で簡単に行うことができます。
chmod --reference=/var/mail.old /var/mail
(Linuxでは標準の
--reference
GNUバージョンが必要です。)chmod
再起動後、常に新しいファイルシステムをマウントするように
/etc/fstab
編集されました。/var/mail
MTA、pop、imap サービスを再起動し、ユーザーが再度ログインできるようになりました。正しく機能しているかどうかを慎重に監視してください。
余暇に新しい設定が正常に機能し、古いメールディレクトリが不要になったことを確認したら、そのメールディレクトリ
/var/mail.old
とその内容の両方を削除できます。
ちなみに、これを行うと1TB以上の空き容量が確保されます/var
。これは必要なものより多い可能性があります。