〓〓〓いつまでも次世代 IMAP その２〓〓〓 (437ﾚｽ)
上下前次1-新
2: 2005/04/24(日)04:18 AAS
2get
3: 2005/04/24(日)23:50 AAS
乙
4: 2005/04/26(火)02:59 AAS
即死防止
5: 2005/04/26(火)12:10 AAS
その2になるのに随分と時間がかかったな。
普及度考えるとこんなもんなのか。
6: 2005/04/26(火)21:18 AAS
NTTドコモのプロバイダーのmoperaでIMAPサービスやってるね。
7(1): 2005/04/26(火)23:35 AAS
営業マン 100 人いて会社在席時PCと外出用ノーパソが別。
受信メールが会社とノートで分かれるのが嫌で IMAP 導入しようと思うのだけど
1 人あたり 1 年で 2G くらい受信する(見積もりのPDF等がでかい)。
運用の参考になるサイトないですか？英語サイトでも可です。
8(1): 2005/04/27(水)12:37 AAS
>>7
テラbyte単位のストレージ使って、あとは普通にIMAPサーバでいいんじゃないの?
1通の容量多くても100人程度なら速いマシンなら負荷どってことないだろうし。
9(1): 2005/04/27(水)13:21 AAS
>>8
ありがと。テラは高いな…。
定期バックアップもテープに収まらないから工夫が必要そう。
100G くらいの HDD を分散させようと考え始めました。
先人たちはどういう風に構築しているんでしょう？
10(1): 2005/04/27(水)13:42 AAS
システム屋に頼むんじゃないかな
11(1): 2005/04/27(水)14:48 AAS
身も蓋もないﾚｽｷﾀ━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━!!!!
12(2): 2005/04/27(水)17:25 AAS
>>9
分散させるのはヲレ的には最悪の手段だと思う。
MaildirのようなNFSと相性のいいスプール形式にして、それに対応した
IMAP serverをつかい、スプール用のストレージにNetAppのようなNASを
使うのが楽。
バックアップはNetAppでスナップショットを切ってから差分バックアップなり
フルダンプなりすればいい。
13(1): 2005/04/27(水)17:50 AAS
オープンソースで考えてるなら、オライリーの「IMAP」くらいは読んでおいて良いかと。
14(2): 2005/04/27(水)18:05 AAS
同じく分散は勧めないかな。手間増えるだけでメリットないのでは。
1通のサイズが大きいの分かっているのなら>>12の言うようにMaildirがいいだろね。
ディスクは十分に余裕のあるサイズのを1つ使うのが楽だと思う。
内蔵でも外付けでもNASでもなんでもいいけど。
IMAPだと予想以上に社員にHDDを使われるよ。
そして「不要なメールや添付ファイルは消してくれ」と頼んでも消してくれない。
結局IMAP使う以上は最初にある程度ハードにお金かけるほうが良いかと。
15: 2005/04/27(水)19:40 AAS
>>10-14
ありがと！
O'Reilly から IMAP 本が出てるの知らなかった…。
とりあえず O'Reilly の IMAP 本を買います。
16: 2005/04/27(水)22:23 AAS
おらいりーの本はちょいと古いのでuwとcyrus(しかも1.5系)の話題中心...
17: 2005/04/27(水)23:46 AAS
7 のように会社などの大人数の所に
手軽に導入できないのが普及のネックになっているのか？
18: 2005/04/28(木)00:21 AAS
前スレでも出てたけど、同時接続数が一番の問題かな。
ディスクスペースは今時どうにでもなると思う。
CyrusのML見てると1万ユーザくらいは収容できているようだけど、
それでもパフォーマンスチューンで苦労しているようだし。
UWとかCourierあたりだとindex持たない(よね?)から、
万オーダーのユーザの収容は苦しいんじゃないかな。
19(1): 2005/04/28(木)06:40 AAS
スプールをNFSにしてIMAPサーバを複数使って負荷分散ってどうよ。
20: 2005/04/28(木)12:25 AAS
>>19
営業はサーバAで総務はサーバB使え、みたいな感じか。
状況によってはアリだろうし面白いかもしれないな。
21(2): 2005/04/28(木)18:54 AAS
それだとバックエンド側で働いているNFSサーバの性能で
パフォーマンスが制限されない?
バックアップなどの観点からも、ある程度の規模になったら
スプールする領域を分けることは必須じゃないかな。
SMTPサーバが受け取ったメールを仕分けして、
LMTP使って別々のIMAPサーバのスプールへ流し込むとか、
既に実装されている技術でもできないことはない。
22(1): 2005/04/28(木)21:33 AAS
>>21
NFSサーバの性能が問題になるほどIMAPでのディスクアクセスってすさまじいか?
もちろん、規模がとてつもなく大きくなれば話は別だけど。
23: 2005/04/28(木)22:08 AAS
>>21
確か、cyrus だとそういうことができるよね。
>>22
大規模だと、まずメモリ積め、ディスクI/Oのスループットを上げろ、って言われますけど。
24: 2005/05/01(日)02:32 AAS
>>14
無くなっては困るが、かといって参照することは
ほぼない過去メールと、それなりの頻度で参照
する過去メールとを分離することは大切。営業
職の社員は、とかくメールを削除することを嫌が
る傾向があるので、分離しないと一人当たり
数万通のメールを平気でためこんだりする。
Maildirだといくらサーチの速いファイルシステム
を使っても快適なメール環境は実現が難しいだ
ろう。そもそも、Maildirに対応したIMAPサーバで、
1ディレクトリあたり数万ファイル、容量にして数GB
に及ぶものを扱えて信頼のおける実装はあるの
だろうか。
結局のところ、cyrusやExchangeのようにDBMSを使って
1ファイル(または数ファイル)で扱う方が現実的では
ないかと思う(SunのMessaging Serverがどのような
メールボックスかは知らない)。
25(1): 2005/05/01(日)15:05 AAS
メールのデータは一つで、
あとは各人がどれを読んだか削除したかのリストを持つ、
という方式はないの？
26: 2005/05/01(日)16:59 AAS
>>25
ハードリンクを利用した方法ならある。
27: 2005/05/01(日)17:37 AAS
詳しく
28: 2005/05/01(日)17:47 AAS
これ。
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
> Cyrus IMAPDでは、MDA（Mail Delivery Agent）だとあて先ユーザーごとに配送されますが、
> LMTP経由だと複数ユーザー同時に配送されることを利用して、
> メールの保存を1通だけにして、ディスク容量を稼ぐということも行っています。
29: 2005/05/01(日)17:50 AAS
元ドキュメントはこれ。
外部ﾘﾝｸ[html]:asg.web.cmu.edu
> Single Instance Store
> If a delivery attempt mentions several recipients
> (only possible if the MTA is speaking LMTP to lmtpd),
> the server attempts to store as few copies of a message as possible.
> It will store one copy of the message per partition, and create hard links
> for all other recipients of the message.
30(1): 2005/05/01(日)22:10 AAS
なるほど。Courier 使ってるけど調べてみる。
31: 2005/05/01(日)22:19 AAS
>>30
> なるほど。Courier 使ってるけど調べてみる。
(゜Д゜)ハァ?
上下前次1-新書関写板覧索設栞歴
あと 406 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s