2014 年

2014-04-30

Mail2000電子郵件系統-兩岸三地多主機架構案例分享
專案經理 王東祈

客戶背景
某科技集團是國際上知名電腦零件專業供應商。研發總部遍佈兩岸三地,在全球有超過10,000名員工及多達600位研發人員,開發之產品申請世界專利並通過之件數超過1,700件。在原先的電子郵件系統架構下,其下兩岸的四個主要據點有不同的Domain Name個別管理。由於據點眾多,各據點間聯繫時經常需透過電子郵件做為溝通工具,且來往信件常伴有各種大容量附檔,加上該集團郵件帳號數約3,000個左右,故每日郵件收發量相當驚人。

集團佈署遍及兩岸 管理問題日漸浮現
該集團原有的電子郵件系統為Exchange搭配Outlook Client,在兩岸四個主要據點都由獨立的Exchange Server進行郵件發送。在進入2014年後,由於集團開始推動集中化的管理思維,同時管理上面臨微軟龐大的授權維護成本壓力下,集團內部也開始思考去微軟化(No Microsoft)的工程。在這樣的背景之下,該集團開始尋找取代Microsoft Exchange及Outlook的方案,其新系統須滿足5項主要的需求:

1.集團網域統一政策:配合集團未來發展政策,雖然需要統一郵件地址名稱,但轉換期間仍可對應舊有的四個郵件地址,再逐漸完全替代。
2.高效能的郵件收發:由於集團據點分布在不同地區,必須滿足在兩岸多據點之間大量信件的傳遞穩定。
3.彈性整合內部系統:集團內部長久以來存在多台目錄服務伺服器(Active directory system, AD)需要整合五台AD Server的資料,彙整並設計符合集團通訊錄的整體需求。
4.替換現有郵件軟體:員工長期以來已習慣使用 Outlook,需要提供可以取代Outlook的使用者端郵件工具軟體(Mail User Agent, MUA),並可支援行事曆及通訊錄同步功能。
5.新舊系統平行運作:到完全替代舊系統前,仍必須滿足內部少部分員工的使用習慣,因此系統需要具備與 Exchange 系統共同運作的並行解決方案。

原規劃方案設計以佈署單主機運作架構為主,但遇上架構瓶頸,讓團隊重新思考
在本次專案中,該集團需要做單一電子郵件地址的統一管理,由於Mail2000電子郵件系統(以下簡稱Mail2000)的產品設計就是以承載大量郵件收發的高效能郵件系統,因此單主機的架構已可符合客戶每日使用模式且更可節省成本,故在專案的初期原先以規劃單主機的架構為主要方向。
在舊有的郵件架構中,兩岸各個主要據點都有一台郵件主機進行服務,兩岸的使用者會透過各點的郵件主機行使每日收發信服務。然而,在統一架構後,兩岸使用者集中透過在台北的Mail2000主機進行收發信,在這樣的集中架構下,衍生出單主機運作下隱藏風險。
由於集團內部使用者常常會需要寄送夾帶大附檔的設計圖,且在單一主機的架構下,每個使用者都會透過台北的主機來進行收發信,因此在網路流量的需求上會比原本分散的架構來得吃重。
再者因為該集團在大陸的據點眾多,根據實際的統計,雖然郵件主機建立於台灣,但使用者的比例在大陸與台灣地區約為3:1,也就是有75%的使用者必須使用跨海峽的網路連線,在專線的成本過高且一般Internet的連線又會遇到不可預知的網路連線問題,單主機的架構勢必無法順利運作,因此在這樣的環境下開始規劃多主機的架構。

總結上述內容,在單主機架構時所遭遇的問題總共有3點:
1. 頻寬不足問題:經過實際檢測後,單一主機架構下,至少需要超過30MB的頻寬連線速度,才能維持穩定的網路連線品質,但提高專線頻寬的成本過高。
2.網路環境問題:在Internet連線的架構下,大陸各點當地的網路連線品質不一,因此難以分析問題與改善。
3.兩岸連線問題:兩岸之間的Internet連線有許多不可預期的因素可能導致連線速率過慢。

佈署多主機運作架構  維繫良好郵件品質
由於各點Internet的連線品質以及兩岸之間連線有許多不可預期因素等問題,最好的解決辦法便是將各點設有獨立的主機來進行信件收發,而Mail2000針對各點需要獨立主機同時也要統一政策管理的架構,提供的多主機架構(User DataBase Server,UDB)正是可以滿足此一需求的郵件管理解決方案。
在UDB中,每台郵件主機可以個別存放domain、user、server路徑相關資料且提供收發信等相關程式服務,在整體上各主機會確認彼此網域及使用者帳號資訊。故利用UDB架構可順利將該集團的使用者依據主要四個據點劃分在四台不同的主機上,由於各台主機僅處理所屬的使用者收發信行為,因此可解決單主機架構之下所發生的網路頻寬相關問題。
在UDB的架構之下,對於該集團的郵件運作行為可以分為幾點來說明。首先針對收發信的部分分為以下情況,其一為外寄內信件:外寄內信件進到Spam後,由於統一郵件地址的原故,所有帶有統一後的郵件地址之外寄內信件都會先由位於台北的控制台主機(Master)收下,由於UDB上的所有主機會記住彼此間的使用者資訊,故由Master收到信件後再依照送收件者所在主機分配送信;其二,內寄內信件由各台主機間直接傳送。而至於外寄信件,則會將信件送往位於台灣的Spam代為發送。最後為信件備份,所有郵件主機的收發信件將統一由建置於台灣的MailBase進行備份。

第二點為公用通訊錄。該集團的公用通訊錄建立方式,必須先設計查詢過濾(Filter)規則,然後由Mail2000對多台AD Server查詢建立而成,故UDB內的所有主機獨立進行這項工作以達到Server上的公用通訊錄建立。

 

 

第三點針對Webmail及MUA使用進行以下說明:在統一集團政策之下,郵件登入的網址也是統一的,系統端的部份,若在內部網路的話,透過DNS設定可以指向個別的主機,但如果使用者由外部網路登入的話,都會先導向Master主機,再由Master主機判斷該名使用者帳號位於何處進行轉移;用戶端的部份,在Thunderbird的使用上,使用者會連向帳號所在的主機信行收發信及通訊錄和行事曆同步。
在導入UDB的架構後,順利達成該集團對於郵件系統的轉換管理需求,然而在UDB架構下仍有些先天的限制。首先,UDB並無法統一由單台主機進行所有管理功能,換句話說,管理者無法由一台主機對其他主機進行管理的工作,故在管理上的概念會是每一台主機各自管理;其次,在資料分享的功能上,例如行事曆各主機共享機制,仍有架構上的瓶頸,仍有待技術實現。

Openfind提供完整方案  解決客戶五大需求
在本次專案可順利成功置換了原有的Exchange Server,其主要原因在於Mail2000對於該集團的各項需求均可提供完整的解決方案,對應原有的5項主要需求分別說明:

1.集團網域統一政策:配合集團政策統一郵件地址名稱,但仍可對應舊有的四個郵件地址
對應方案:將主機設定為新統一域名後的郵件地址,並將舊有郵件地址設成網域別名,如此一來不管寄件者所填入的郵件地址為何,Mail2000都可以認得新舊的網域,並根據帳號所在位置分配信件。
2.高效能的郵件收發:須滿足在兩岸之間大量信件的傳遞穩定
對應方案:利用Mail2000 UDB架構來取代舊有Exchange Server,各台Mail2000 Server僅處理所負責據點的信件,在運行後順利滿足超過3000名使用者每日超過80 GB的信件使用流量。
3.彈性整合內部系統:整合五台AD Server資料,匯整符合集團需求的通訊錄
對應方案:該集團雖有五台AD Server但實際上對應的是四個Domain,且在統一集團的需求下須建立許多跨不同Domain的群組帳號,故利用客製的方式,依據與該集團約定好的AD規則,產生一本建立於統一集團架構下的通訊錄,並以兩小時的頻率定期更新。
4.替換現有郵件軟體:提供可以取代Outlook並支援行事曆及通訊錄同步
對應方案:提供Mail2000與Thunderbird之間的通訊錄(CardDav)及連絡人(CalDav)同步功能,成功推動以Thunderbird取代Outlook,協助該集團達成去微軟化的企業需求。
5.新舊系統平行運作:由於集團內部的需求仍有少部分的VIP帳號會繼續使用Exchange,未來的新系統必須與Exchange共存。
對應方案:利用Mail2000「郵件總監」功能設定路由規則,將VIP帳號信件以Gateway的方式傳遞,成功與其建立並行關係,且提供未來繼續使用Outlook的使用者可以通訊錄同步Mail2000的方式(Outlook Plug-in)。

置換後,管理者滿意對於現行架構的運作效,Mail2000友善的Web操作介面管理功能也能提供管理者在處理絕大部分的管理問題時更簡單及快速的管理方式;使用者端除了維持原本的使用習慣外,同時Mail2000原有功能完整的Webmail也提供使用者不同的收發信選擇,以及Mail2000的行動裝置的操作介面,更提高使用者在外信件往來的便利性。針對集團或兩三地的郵件管理需求,Mail2000 UDB 提供兼具「系統效能、政策管理、彈性架構」的郵件管理解決方案。