1 / 35

校園郵件服務與儲存系統建置經驗分享

校園郵件服務與儲存系統建置經驗分享. 校園資訊安全與儲存技術研討會 2007/05/28 台灣大學 計算機中心 程式設計師 張傑生. jsc@ntu.edu.tw. 大綱. 台灣大學電子郵件系統現況 系統規劃與軟硬體選擇 效能調教建議 維運常見問題 SPAM 問題討論 面對態度 處理方式 儲存系統討論 Performance and high availability Backup and restore 結論與討論. 台灣大學電子郵件系統現況. 帳號數目： 七萬六千餘 畢業生終身保留服務 每年以七千筆成長 全校統一位址

keefe-levine
Download Presentation

校園郵件服務與儲存系統建置經驗分享

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 校園郵件服務與儲存系統建置經驗分享 校園資訊安全與儲存技術研討會 2007/05/28 台灣大學 計算機中心 程式設計師 張傑生 jsc@ntu.edu.tw

  2. 大綱 • 台灣大學電子郵件系統現況 • 系統規劃與軟硬體選擇 • 效能調教建議 • 維運常見問題 • SPAM 問題討論 • 面對態度 • 處理方式 • 儲存系統討論 • Performance and high availability • Backup and restore • 結論與討論

  3. 台灣大學電子郵件系統現況 • 帳號數目： • 七萬六千餘 • 畢業生終身保留服務 • 每年以七千筆成長 • 全校統一位址 • name@ntu.edu.tw • b95123456@ntu.edu.tw • 與既有帳號系統、人事資料庫、學籍資料庫整合 • 帳號自動建立、更新、刪除 • 與既有 single sign on 系統結合

  4. 建置目標與精神 • Scalable • 因應未來帳號數量、服務種類、信箱容量之持續成長 • Customizable • 結合既有 single sign on 認證系統 • 與校內帳號系統、人事資料庫、學籍資料庫整合，並完成自動化作業。 • 定期產生各式統計報表 • Flexible • 系統元件必須具備可隨時抽換、更替之彈性 • relay, anti-virus, anti-spam, webmail, pop3 • Cost efficient • KISS principle • Keep it simple and straightforward. • Simple is beauty.

  5. 軟體選擇考量 • Open source solution is our final choice. • Why not adopt commercial packages? • Legacy issues • Can not provide reference sites with equal size • Large email providers use their own solution • Google/Hotmail/Yahoo/Hinet • Price • Charge by account number • Proprietary storage format • Database schema, mail folder format • 無法回頭的不歸路 • Source code not available • Not willing/able to modify to meet our requirements • 削足適履 • 更改既有工作流程，以符合該軟體要求。 • 無法結合既有單一身份認證系統。 • 無法自動化，必須手動匯入更新資料。 • 教育單位的社會責任，推廣免費好用的 solutions.

  6. 硬體選擇考量 • x86 • 中信局 • 避免特定廠商、專屬零件之羈絆 • 保留系統轉移、維修彈性

  7. 系統架構與使用軟體 ClamAV SpamAssassin Amavisd-new Horde/IMP Postfix Courier-imap Apache FreeBSD / Linux

  8. 效能調教建議 – DNS server • Mostly ignored bottleneck • Busy mail servers may issue dozens of requests per seconds • Reverse and forward dns check • Sender, receiver domain check • RBL • Being DOSed by RFC2136 Dynamic Update Protocol • Windows servers

  9. 效能調教建議 – 軟體選擇 • MTA • Postfix • Proven to be fast and scalable. • Human readable configuration files. • Pop3 and Imap4 daemon • Courier-Imap • Dovecot • Cache and index support • Obvious performance improvement not seen so far. • Under active development • Potential and worthy to put an eye on.

  10. 效能調教建議 – 軟體選擇 • Mail storage format • Maildir • Lock free • NFS friendly • Webmail client • Horde/IMP • Openwebmail • Support only mbox format • Not scalable • Inactive development • Last releases • v2.51 (2005/02/28) • v2.52 (2006/05/02)

  11. 效能調教建議 – 硬體 • Layer 4 switch • High performance storage • 透過 Layer 4 switch 與 NFS server • Load balance • High availability • Webmail、pop3、mail storage 主機特別需要 • Relay 主機透過 DNS multi MX record 即可達成

  12. 效能調教建議 – Storage • Consider the access time comparison • CPU < 1ns (1GHz = 1ns) • Memory 50-80ns • Disk 5ms • Milli second = 10-3 • Nano second = 10-9 • Focus your investment on your storage, not focus on CPU clock rate. • IDE/SATA vs SCSI • 10k vs. 15k rpm • RAID 01 vs. RAID5 vs. RAID6 • Directly connected vs. NFS • Depend on your architecture.

  13. 目前遭遇問題與維運負擔 – 系統端 • SPAM • 被誤認為 SPAM source! • 使用者自辦 mailing list. • AOL, Yahoo • Mail forwarding • 到處寫信解釋 • Free email providers, ISP • RBL • Performance of Webmail • Especially on large folders

  14. 目前遭遇問題與維運負擔 – 使用者端 • 要求比照 Yahoo, Hotmail, Google Mail • 提升信箱容量 • 提供友善易用之網頁介面 • 搶救誤刪信件 • 查詢郵件記錄 • 各式諮詢問題 • 安裝、設定、使用

  15. SPAM 問題討論 • SPAM 判斷 • 迥異於病毒判斷，並非黑白分明。 • 常見誤判情況 • 不合乎標準的信件發送軟體送出 • Encoding, header, no valid sender/recipient • 被列入黑名單的IP送出。 • 電子郵件管理權責 • 是否能完全決定對於 SPAM 的處理方式 • 是否能取得使用者授權進行「內容判讀」 • 受到監督責難 • 相較於免費電子信箱，投訴無門？

  16. 台灣大學對於 SPAM 的處理政策 • 處理原則 • 盡量不刪除使用者信件，避免爭議。 • 權衡郵件系統負擔與使用者觀感。 • 處理方式 • Tagging instead of removal. • 希望達到一般免費信箱的作法. • 必須顧及各種不同使用方式 • POP3 and Webmail

  17. SPAM 處理技術 • 採用方式 • Server end • Greylisting • Scoring and tagging • Remove if reaching threshold • Client end • More effort on end users. • Decide how to post-process SPAM mails themselves. • 軟體選擇 • Open Source Software • 免費開放程式可修改 • 穩定彈性避免被綁死 • 教育單位的社會責任 • 推廣便宜好用的 free solutions.

  18. Greylisting • RFC821要求 • MTA必須具備store and forward功能，有責任持續嘗試送信直到成功。 • 利用廣告信發送軟體「Fire and Forget」的特性（缺陷）加以防堵。 • 有效克服廣告信發送業者「Hit and Run」。 • 基本上屬於與廣告信發送業者「鬥法」的smart trick。

  19. Scoring and Tagging • Software we use • SpamAssassin • Scoring based on various tests • Content inspection • Realtime Black List • Message Digest • SPAM URI Realtime Black List • User defined rules. • Black/White user/ip list. • Tagging if suspected. • Removal if over some threshold.

  20. Tagging Example

  21. Rule Setting Examples of Outlook Express and Webmail

  22. SPAM 處理檢討 -- Greylisting • 誤檔情況 • 不符合 retry 規範的電子郵件寄送 • 網頁程式直接發送信件 • 某些電子報、銀行信用卡通知。 • Some old/rarely seen MTAs. • 定期檢視系統記錄，列出例外名單。 • 附贈優點 • 有效降低 mail gateway 系統負荷 • 減少需要處理的信件量 • 降低郵件通過 mail gateway 的處理延遲

  23. 儲存系統建置 • 傳統解決方式 • 主機透過 SCSI 介面外接 RAID • SCSI or IDE/SATA disks • 物美價廉 • 25萬/TB for SCSI RAID • 6萬/TB for IDE/SATA RAID • 風險分散 • 缺乏成長性，難以擴充。 • 無法集中管理維護 • 資料儲存政策 • SCSI RAID for online production services • IDE/SATA RAID for backup

  24. 集中式高階儲存系統建置考量 • 目的 • 建置穩定且高效能之儲存系統， 提供 email, web, database, grid computing 等服務使用。 • 需求 • Performance • Stable and resist to abnormal instances • Immediately available after unclean reboot • Being responsive and manageable while overloading • QoS support to provide granular service level • Scalability and expansibility • Expand and shrink file partition online without intervene the os. • Attach new disk shelf online and be usable immediately without shutting down the system.

  25. 集中式高階儲存系統建置考量 • 需求 • Easy to Manage • Status monitoring • Disk usage, network usage, cpu loading • Backup and restore • Snapshot in seconds • Fast recovery to previous status in seconds • 規格 • Storage Area Network(SAN) vs. Network Attached Storage(NAS) • 分享方式 • Fibre channel or network • Do not underestimate the cost of fiber switch and cable deployment. • 好消息，許多設備都已同時提供 SAN 與 NAS 功能。 • 以最常使用功能為優先考量。 • 保留系統後續擴充性。 • 預算 • High end systems equal to high price. • 70萬/TB for FC Disks

  26. 集中式高階儲存系統使用狀況 • 提供 mission critical services 使用 • Email, web page, database • 配合 layer4 switch 建構 load balance and high availability 環境 • 目前最常使用功能 • Snapshot and recovery • 幫助使用者救回誤刪信件、檔案 • 隱憂 • Single point of failure • 大量不正常存取拖慢系統效能，影響其他服務。

  27. 結論 • 系統規劃必須預留後續擴充空間 • 盡量避免受制於單一軟體、產品、廠商 • 關切 SPAM 問題，但是不要期待找到完美解決方案。 • 正視 Storage 對於系統整體效能扮演關鍵角色。

  28. 討論 • 郵件委外之可能性 • Gmail university program, 國內某大 ISP • 免費、超大容量、友善介面 • 帳號管理、維護 • 如何並存於既有 single sign on 系統 • 帳號名單與信件內容之隱私權保障 • 系統記錄追查 • 責任歸屬、法律問題

  29. 討論 • 謝謝大家 • 請大家不吝指教 • 投影片未來將放在個人網頁提供下載

More Related