Issuu on Google+


參考過同學及學長的呈現方式,截圖的類型都大致相同,故在此不再重複以實際 圖片來做報告,將以理想的建置目標、最後成果以及所遭遇的難題歸納作為此報 告的重點部分。

這張經過裁切的部分是分散在各區塊的 Exchange 伺服器,分別是綠色區塊的 總公司、粉紅色區塊的 DMZ 及黃色區塊的(消失的)分公司(?)。

這個狀態是最初的概念,不只在總公司內部及 DMZ 的伺服器都具備高可用性外, 還可以利用 Site to Site VPN 做到異地備援,但實際建置過程的困境以及時限問 題造成了分公司部分的裁減,來降低設定的複雜度,才能順利完成基礎的實驗。


I. 用戶端存取伺服器(CAS)的附載平衡(NLB) II. 單一叢集信箱伺服器(SCC)與 iSCSI-SAN 存放區

I. 邊際傳輸伺服器(ETS)的訂閱與發行 郵件的過濾以及防毒

I. 三大角色伺服器(CAS、HTS、MBX) 依序被刪減的原因


CAS 這部分結果跟預期的大同小異,困難點在於 1.NLB 的正常運作 2.與 AD 資料庫的聯繫 這會造成需要"砍掉重練"的狀況 兩種要注意 NLB 狀況 1.再製後的虛擬主機網卡並未移除重裝,導致 NLB 建置 發生"介面已使用"的問題

sol-再製後須做 NLB 的伺服器必須將網卡解除安裝後重 新探索安裝。

2.NLB 叢集 IP 在實體主機以外的範圍皆無法正常運作 sol-MultiCast 型態的 NLB 連接在實體裝置 switch 上封 包的廣播探索會被阻擋,將實體裝置換成 hub 就能 解決此問題。 Exchange 每種伺服器與 AD 架構的關係都非常密切,當伺服器對 AD 架構要求 資料時,被給予錯誤資料將會導致伺服器被孤立,無法達到高可用性。


MBX 這部分用到較多的虛擬叢集 IP,相對的對 DNS 是否能正確解析的依賴性 也更為提高,伺服器開機的順序也很重要,DNS 不正常工作、資料不正確或是 開機順序不正確皆會導致嚴重錯誤,實驗在這邊因兩種原因分別砍掉重練一次。

ETS 的訂閱與發行關連到三個工作區塊的合作,重點在前牆須以"SMTP 伺服器" 來發行兩台 ETS 伺服器(開放來回流量),外部 Mail Server 才能跟 DNS 查詢到 兩筆 MX 紀錄後達到 ETS 的高可用性,使其一伺服器失敗後郵件能正常收發, 而 HTS 對 ETS 訂閱部分就相對簡單。 郵件防毒由於安裝了 ForeFront Security for Exchange,預期會有伺服器附載 壓力的問題,取消掃毒引擎更新後到實驗結束都一切正常。


總公司內部已有的兩台 CAS(NLB)向 CA 申請 mail.ibon.com 名稱發行憑證, 分公司 CAS3 的預想作法有

1.透過 VPN 加入總公司的 CAS(NLB)叢集 ans-不可行,無法找到現有 NLB 叢集。

2.獨立像 CA 申請 mail2.ibon.com 憑證發行 ans-完成後用戶端可以連結到 mail2 網址登入 ,CAS3 可以運作但仍會將用戶端導向 mail, 且當 CAS1、2 都無法提供服務時,CAS3 還是 會將用戶端導向到已經失效的 mail 上。 結論:分公司沒有建置 CAS 的必要。

由於郵件防毒只建立在 ETS 上,為了避免分公司 HTS 收到其他不明郵件,預想 只開放與總公司 DMZ 區內的 ETS 做傳送及接收,但分公司的 HTS 無法經由 VPN 成功訂閱到位於總公司 DMZ 區的兩台 ETS。 結論:分公司沒有建置 HTS 的必要。


最後是 MBX(SCC)與異地待命連續複寫(SCR)的結合,關於這部分參考了許多官 方網站的手冊,大多數都是提到 SCR 與 CCR 的合併使用,以 SCR 與 SCC 使用 方式及參考資料都非常少,整個過程都是在 Power Shell 下以指令完成,而實際 上操作要將總公司的信箱資料庫複寫到分公司的 MBX 資料庫時,卻出現"資料 庫位於非主機機架上的存放區"而無法執行成功的訊息,算是唯一很可惜在最後 時限只好放棄掉的部分。 關於 SCR 的運作方式,只是將資料庫以複寫方式備份到其他站台的資料庫,當 總公司站台內的資料庫完全毀損之後,在尤其他站台以手動執行指令的方式將資 料庫還原到總公司,所以只有備份效果,並沒有達到備援。


以整個班級的實驗進度表來看,我是最早開始架設伺服器,也一直測試到最後一 天驗收完才停機的人,這要感謝董娘阿伻(羿伻)提早開始架設 AD,到實驗中期 配合到 ISA Server 的防火牆規則開放更是由瑞廷一手擔當,讓我不必擔心規則 這部分,關於分公司架設郵件三合一伺服器的可能性,也是由再珉組長提議,再 一起深入研究的,SCR 這技術也是由守拙的口頭報告中得知,只可惜最後還是 沒有實現。

在實驗開始前分配到 Exchange 這部分,還以為是可以獨立作業完成的,沒想 到與各部分都有相依性及關聯性,團隊合作真的讓事情變得簡單,也感謝其他組 同為 Exchange 責任區的技術鼎力支援,整個過程基本上算是沒有卡關,只是 我還是忙到最後一刻,驗收的技巧也是很重要的,當天的凌晨都在佈置驗收環境, 方便老師跟著驗收流程順利驗收完畢,整個過程學到了很多,也發覺自己距離帶 領一個團隊的資格還有一段距離,還要學的還有很多,不只是技術層面,最後才 能成為獨當一面的高級網路工程師。

最後謝謝幾位 MS 課程老師的詳盡教導。 -Writed by 鈜予


MSLAB