小さなパーティションを1つの大きなディレクトリにマージするための推奨方法

小さなパーティションを1つの大きなディレクトリにマージするための推奨方法

私のサーバーには数日以内にいっぱいの特定のパーティション(/ 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_growfsext2/3/4にありますresize2fs)。

別のオプションはを使用することですbtrfs。 RAID と同様の機能をネイティブにサポートし、より多くのストレージドライブを追加すると、ファイルシステムが自動的に拡張されます。また、エラーの検出と修正、スナップショット、サブボリューム、透過的なファイル圧縮などをサポートしています。

ZFSはbtrfs(私が個人的に使用する)と似た機能を持っていますが、メインラインカーネルの一部ではないという欠点です(おそらくCDDLとGPLの間のライセンスの非互換性のためには発生しません)。パッチまたはDKMSモジュールとしてのみ使用できます。最近では大きな問題ではありませんが、より多くの作業を行う必要があります。

私の提案はbtrfsまたはzfsを使用することです。 IMOの最近では、すでに使用していて、その技術の多くの経験と投資がない場合、通常の古いmdadmやlvmを使用する理由はありません。

このサイトには、mdadm、lvm、btrfs、および/またはzfsなどを設定する方法を詳しく説明する多くの質問と回答があります。

それにもかかわらず、RAIDまたはRAIDに似たファイルシステムを実装する方法に関係なく、ダウンタイムを最小限に抑えながら、古いメールを新しいファイルシステムに転送する必要があります。すべての場合において、プロセスは次のようになります。

  1. 新しいドライブを取り付けます。ホットスワップ可能なベイがない場合は、少しダウンタイムが必要です。

  2. 新しいRAIDおよび/またはファイルシステムの設定

  3. 次のようにインストールしてください。/var/mail.new

  4. 同期/var/mail//var/mail.new/

  5. このプロセスを完了する時間があるまで(可能な限り勤務時間外)、手順4を必要なだけ繰り返すことができます。ステップ1で発生する可能性があるダウンタイムを除いて、これまでユーザーに表示されるダウンタイムはありません。せいぜい、ジョブがrsync実行されたときにシステムが通常より少し遅いことに気づいたでしょう。

  6. MTA(sendmail、exim、postfix、またはその他)およびpop / imapデーモンおよびその他の書き込みを停止します/var/mail/。メールを読むためにシェルにログインしているユーザーがいる場合(例:muttを使用)、ログアウトするように指示します。完了したら、以前に再度ログインしないようにしてください。

    つまり、書き込みを中止し、/var/mail後で手順13で再開する必要があります。

  7. 最後の実行以降のすべての変更を同期するには、最後のrsyncfrom /var/mail/toを実行してください。/var/mail.new/

  8. mv /var/mail /var/mail.old

  9. mkdir /var/mail

  10. マウントを解除して/var/mail.newから再度マウントします/var/mail(おそらくmount --move /var/mail.new /var/mailAustin Hemmelgarnが述べたように)。

  11. 所有権と権限を確認し、まったく同じであることを/var/mail.old確認してください。/var/mail

    これは次の方法で簡単に行うことができます。

    chmod --reference=/var/mail.old /var/mail

    (Linuxでは標準の--referenceGNUバージョンが必要です。)chmod

  12. 再起動後、常に新しいファイルシステムをマウントするように/etc/fstab編集されました。/var/mail

  13. MTA、pop、imap サービスを再起動し、ユーザーが再度ログインできるようになりました。正しく機能しているかどうかを慎重に監視してください。

  14. 余暇に新しい設定が正常に機能し、古いメールディレクトリが不要になったことを確認したら、そのメールディレクトリ/var/mail.oldとその内容の両方を削除できます。

ちなみに、これを行うと1TB以上の空き容量が確保されます/var。これは必要なものより多い可能性があります。

関連情報