web-dev-qa-db-ja.com

サイラスをアップグレードし、メールボックスを分割する

CyrusIMAPサーバーを2.2.12から2.4.12/13にアップグレードしようとしています。

私の実際のバージョンは古いリリースなので、それを行うための良いガイドを探していることを知っています。バージョンをアップグレードしたり、新しいバージョンをインストールして構成をインポートしたりするだけではないと思いますが、間違っていますか?データベース情報を移行する必要があると思いますが、移行する方法がわかりません。

私たちのメインでユニークなCyrusサーバーは、10000人以上のユーザーとそれに対応するメールボックスを管理しています。新しい移行では、このメインサーバーをより小さなサーバーに分割して、クライアントごとにメールボックスを分割したいと考えています。 Cyrus 2.2.12からいくつかのメールボックスをエクスポートするにはどうすればよいですか?メールボックスを選択的にエクスポートしたい。

「Mailsync」ツールを見つけましたが、メールボックスで選択できるようには見えません。 Cyrusの新しいバージョンに適切に移行する方法はありますか?

1
magiza83

(約8年前、5万を超えるユーザーアカウントを古いメールサーバー(uw-imapdを実行)から、3台のサーバーで構成されCyrusを実行する新しいサーバー「ファーム」に移行しました。当時、私はl337Perlスキルを使用して古いサーバーにログインし、新しいサーバーのメールを一度に1つのユーザーアカウントでIMAP経由でコピーする移行スクリプト。OpenLDAPサーバー+ Perditionがこの前にあり、ユーザーをどこに転送するかを決定していました(古いサーバーに)サーバーまたは新しいサーバーへ)操作はダウンタイムなしでオンラインで実行されました。これはトピックから外れているので、返信を続けます。)

警告の言葉:あなたがやろうとしている仕事は少し退屈かもしれません、そしてあなたのために十分に短い返事をタイプすることも簡単ではありません。 :-)ここにあなたが考慮すべきいくつかのポイントがあります。

やるべきことがいくつかあります。 Cyrus自体のアップグレードはそれほど不可能ではありませんが、ユーザーを1つのサーバーから複数のサーバーに同時に分割するには計画が必要です。 BerkeleyDB/skiplist形式が途中で変更され、古いデータファイルをそのまま使用できないため、古いサーバーから新しいサーバーにすべてをコピーするだけでは機能しません。

ユーザー/メールボックスリストに関しては、ctl_mboxlist -dスイッチを使用して古いサーバーのユーザー/メールボックス情報をテキストファイルにダンプしてから、ctl_mboxlist -uを使用してコンテンツを新しいサーバーにロードすることをお勧めします。 。これは、Cyrusをアップグレードするだけで、同時により強力でありながら単一のサーバーに移行する場合に当てはまります。メールボックスは、Cyrusでrsyncの後にreconstruct -rfx user/*コマンドを使用してコピーできます。

同時に分割を実行したい場合は、xfermailboxcyradmコマンドで実際にメールボックスをあるサーバーから別のサーバーに移動できるかどうかを試してみてください。もしそうなら、xfermailboxを10000回呼び出して、ユーザーアカウントを好きな場所に移動するスクリプトを作成するだけです。

別のヒント:移行後に一部のユーザーがメールフォルダー/メールを見つけることができない場合は、おそらくreconstruct -rfx user/someaccountコマンドが必要です。

これまではすべて元気でダンディですが、次のことを考慮しましたか?

  • ユーザーを複数のサーバーに分割する場合、POP/IMAPログインを正しいメールサーバーにリダイレクトするためのPerditionCyrus Murderのようなものはありますか?
  • 分割する場合、OpenLDAPまたはその他の集中認証/ユーザー管理を実施していますか?
  • 分割する場合、ユーザーアカウントが実際にどこにあるかを把握するようにPostfixまたはSMTPサーバーを構成しましたか?
  • 現在、パフォーマンスの問題がありますか? 10,000のユーザーアカウントはそれほど多くはありません。ユーザーアカウントを複数のサーバーに分割する重大な理由が本当にない限り、これを慎重に再検討する必要があります。ある種の集中型ストレージ+アクティブ/パッシブフェイルオーバーモードで構成された2つのセミパワフルサーバーは、システム管理の観点から、より賢明で単純な場合があります。もちろん、ローカルディスクを備えた複数の小さなサーバーがあるとI/O負荷を分散するのに役立つ場合がありますが、十分な量を与えるとCyrusは「ありがとう」と言いますRAMそしてI/Oは本物ではないはずです問題。
  • 負荷を複数のサーバーに分割することを決定した理由がパフォーマンスの問題による場合は、Cyrusがmailboxes.dbなどにBerkeleyDBまたはSkiplistを使用しているかどうかを再確認してください。適切に調整されていないDB_CONFIGパフォーマンスが簡単に停止したり、デッドロックが発生したりする可能性があります。スキップリストはもっと心配がありません。また、CyrusでのPOP3実装は非常にエントロピーを必要とし、サーバーにハードウェアベースの乱数ジェネレーターがない場合、rngdデーモンがないか、Cyrusが/dev/urandomを使用するように構成されていないとログインが非常に遅くなる可能性があります。ランダム性のために/dev/randomの代わりに。

これが少しお役に立てば幸いです。

3

あなたは私に従うべき素晴らしい手がかりを与えてくれました。

とにかく私は私が考慮すべきアイデアに答えます:

  • 私たちはperditionを持っていますが、perditionを維持するか、nginxに変更することを検討しています。
  • LDAPがあります
  • 今のところ、これについてはよくわかりません。確認して調査する必要があります。
  • 現在、パフォーマンスの問題はありませんが、成長を続けており、より多くのクライアントがシステムにアクセスしています。ただし、クライアントまたはクライアントのグループごとに分割することをお勧めします。これは、SysAdminの観点からは退屈な作業ですが、ビジネスやSLAには適している可能性があります。他のオプションは好評です:)
  • 前にコメントしたように、パフォーマンスの問題はありません。いずれにせよ、BerkeleyDBを使用しています。

とにかく、私が成功または移行のために何をすべきかについての計画をしていることを正しく知っているので、あなたが私に提供したコマンドを試すことはできません。

確認したら戻ってきます。

どうもありがとう!

0
magiza83