IT運(yùn)維知識：Exchange 2010 DAG 跨站點(diǎn)轉(zhuǎn)移

2020-03-21 09:16 作者：艾銻無限 瀏覽量：

云計(jì)算提供商的網(wǎng)絡(luò)性能有哪些不同

每個(gè)云計(jì)算提供商的網(wǎng)絡(luò)連接方式各不相同，這會導(dǎo)致網(wǎng)絡(luò)性能和可預(yù)測性方面的地理差異。隨著越來越多的企業(yè)考慮將業(yè)務(wù)遷移到云平臺，尤其是軟件定義廣域網(wǎng)(SD-WAN)和多云，了解每個(gè)公共云服務(wù)提供商提供的服務(wù)以及如何進(jìn)行比較至關(guān)重要。 ThousandEyes公司在2018年進(jìn)行了一項(xiàng)基準(zhǔn)研究，對全球三個(gè)主要的公共云提供商：亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)、微軟Azure(Azure)和谷歌云平臺(GCP)的服務(wù)進(jìn)行了評估。該研究收集了有關(guān)網(wǎng)絡(luò)性能和連接架構(gòu)的數(shù)據(jù)，以指導(dǎo)用戶在規(guī)劃階段的工作。

2019年的研究提供了一個(gè)更全面的視角，在其研究名單上又增加了兩個(gè)云計(jì)算提供商：阿云和IBM云。研究報(bào)告比較了2018年和2019年的調(diào)查數(shù)據(jù)，顯示了每年發(fā)生的變化以及引發(fā)這些變化的原因。
ThousandEyes公司在四周的時(shí)間內(nèi)，定期從使用這五個(gè)公共云提供商的全球數(shù)據(jù)中心的98個(gè)用戶位置收集雙向網(wǎng)絡(luò)性能指標(biāo)，例如網(wǎng)絡(luò)延遲、數(shù)據(jù)包丟失以及抖動。此外，還研究了美國領(lǐng)先的寬帶互聯(lián)網(wǎng)服務(wù)提供商(ISP)的網(wǎng)絡(luò)性能，其中包括AT&T、Verizon、Comcast、CenturyLink、Cox和Charter。

然后，該公司分析了超過3.2億個(gè)數(shù)據(jù)點(diǎn)，以創(chuàng)建評估基準(zhǔn)。

提供商之間的網(wǎng)絡(luò)服務(wù)并不一致
ThousandEyes公司在最初的研究中發(fā)現(xiàn)，一些云計(jì)算提供商十分依賴公共互聯(lián)網(wǎng)來承載用戶流量，而其他云計(jì)算提供商則不是這樣。在2019年的研究中，云計(jì)算提供商在雙向網(wǎng)絡(luò)延遲方面總體上表現(xiàn)出相似的性能。

但是，ThousandEyes公司發(fā)現(xiàn)網(wǎng)絡(luò)架構(gòu)和連接性差異對流量在用戶與某些云計(jì)算托管區(qū)域之間的傳輸方式有著很大影響。AWS和阿里巴巴主要依靠全球互聯(lián)網(wǎng)來傳輸用戶流量。微軟Azure和谷歌云平臺使用其專用骨干網(wǎng)。IBM公司與其他公司不同，采用二者混合的方法。

ThousandEyes公司檢驗(yàn)了AWS Global Accelerator是否優(yōu)于全球互聯(lián)網(wǎng)的理論。AWS Global Accelerator于2018年11月推出，該服務(wù)采用的不是默認(rèn)的全球互聯(lián)網(wǎng)，而提供使用AWS專用骨干網(wǎng)，并向用戶收費(fèi)。盡管其在全球某些地區(qū)的網(wǎng)絡(luò)性能確實(shí)有所提高，但在其他情況下，全球互聯(lián)網(wǎng)比AWS Global Accelerator更快、更可靠。

即使在成熟的美國市場，企業(yè)用來連接每一個(gè)云計(jì)算提供商的寬帶網(wǎng)絡(luò)服務(wù)提供商(ISP)的服務(wù)也并不一致。在對6個(gè)美國網(wǎng)絡(luò)服務(wù)提供商(ISP)的網(wǎng)絡(luò)性能進(jìn)行評估后，記錄了次優(yōu)的路由結(jié)果，在某些情況下，其網(wǎng)絡(luò)延遲是預(yù)期的10倍。

地點(diǎn)至關(guān)重要
云計(jì)算提供商的服務(wù)在穿越一些國家的過濾防火墻時(shí)，通常都會遇到丟包的情況。該公司在2019年的研究中，仔細(xì)檢查了云計(jì)算服務(wù)提供商在一些國家的運(yùn)營費(fèi)用，這對在線企業(yè)而言是極具挑戰(zhàn)性的地理位置。
在世界其他地區(qū)，拉丁美洲和亞洲表現(xiàn)出所有云計(jì)算提供商最大的性能差異。例如，由于反向路徑不太理想，谷歌云平臺的托管區(qū)域從里約熱內(nèi)盧到圣保羅的網(wǎng)絡(luò)延遲是其他五家云計(jì)算提供商的六倍。但是在北美和西歐，所有五家云計(jì)算提供商均展現(xiàn)了強(qiáng)大網(wǎng)絡(luò)性能。

這項(xiàng)研究的結(jié)果證明，地點(diǎn)是主要因素，因此，企業(yè)在選擇公共云提供商時(shí)應(yīng)考慮用戶到主機(jī)區(qū)域的性能數(shù)據(jù)。
多云連接

在2018年的研究中，ThousandEyes公司發(fā)現(xiàn)AWS、谷歌云平臺、Azure的骨干網(wǎng)絡(luò)之間的廣泛連接。在2019年的研究中還有一個(gè)有趣的發(fā)現(xiàn)，在將IBM公司和阿里云添加到調(diào)查列表中時(shí)，多云連接變得不穩(wěn)定。

ThousandEyes公司發(fā)現(xiàn)IBM公司和阿里云尚未與其他提供商完全建立直接連接。那是因?yàn)樗麄兺ǔＪ褂镁W(wǎng)絡(luò)服務(wù)提供商(ISP)將其云平臺連接到其他提供商。另一方面，AWS、Azure和谷歌云平臺可以直接相互對等連接，并且不需要第三方網(wǎng)絡(luò)服務(wù)提供商(ISP)的服務(wù)進(jìn)行多云通信。

隨著多云計(jì)劃的興起，在評估多云連接性時(shí)，應(yīng)將網(wǎng)絡(luò)性能作為一項(xiàng)衡量標(biāo)準(zhǔn)，因?yàn)樗坪踉谠朴?jì)算提供商和地理邊界之間不一致。

ThousandEyes公司的綜合性能基準(zhǔn)可以作為企業(yè)確定哪個(gè)公共云提供商最能滿足其需求的指南。但還是需要謹(jǐn)慎，選擇公共云連接的用戶應(yīng)該考慮全球互聯(lián)網(wǎng)的不可預(yù)測性、如何影響性能、面臨的風(fēng)險(xiǎn)，以及運(yùn)營復(fù)雜性。用戶應(yīng)通過個(gè)案收集自己的網(wǎng)絡(luò)情報(bào)來應(yīng)對這些挑戰(zhàn)。只有這樣，他們才能從云計(jì)算提供商所提供的內(nèi)容中充分受益

 
 
Exchange Server 2010在跨站點(diǎn)部署數(shù)據(jù)庫可用性組（Database Availability Group, DAG）時(shí)，需要考慮站點(diǎn)間的轉(zhuǎn)移問題。即：一個(gè)站點(diǎn)的Exchange服務(wù)器宕機(jī)時(shí)，另一個(gè)站點(diǎn)的Exchange能否自動切換，并保證客戶端訪問的不間斷。
事實(shí)上，跨站點(diǎn)的轉(zhuǎn)移有兩種，一種是故障轉(zhuǎn)移Fail over，另一種是切換Switch over。故障轉(zhuǎn)移是服務(wù)器自動進(jìn)行的一種行為；而切換則需要管理員的人工干預(yù)才能夠完成。
在理想狀態(tài)下，總是希望實(shí)現(xiàn)Failover，因?yàn)镕ailover是不需要任何人工干預(yù)而自動進(jìn)行的，F(xiàn)ailover可以最大限度地保證服務(wù)的可用性。
Exchange組織拓?fù)?br />   郵箱數(shù)據(jù)庫
組織中配置了3個(gè)數(shù)據(jù)庫，每個(gè)數(shù)據(jù)庫有3個(gè)副本，分別位于加入DAG的3臺Exchange Server 2010郵箱服務(wù)器上。
  Client Access Array
各活動目錄站點(diǎn)中配置的Client Access Array。 郵箱數(shù)據(jù)庫上配置的Client Access Array 這里需要說明一下Client Access Array，結(jié)合Mailbox Database上的RpcClientAccessServer這個(gè)參數(shù)，可以發(fā)現(xiàn)，這個(gè)功能用于且僅用于公司內(nèi)部的Outlook客戶端使用MAPI方式進(jìn)行連接時(shí)使用。對于每一個(gè)活動目錄站點(diǎn)，可以創(chuàng)建并僅能創(chuàng)建一個(gè)Client Access Array。一旦創(chuàng)建了Client Access Array，它將自動把本站點(diǎn)所有的客戶端訪問服務(wù)器作為自己的成員，而且這個(gè)成員是不允許進(jìn)行編輯（添加或刪除）的。對于Exchange的管理員，只能對Client Access Array的名稱和FQDN進(jìn)行配置。
由于Exchange Server 2010的客戶端訪問是按照活動目錄站點(diǎn)進(jìn)行劃分的，而為了節(jié)省站點(diǎn)間的網(wǎng)路帶寬，管理員應(yīng)該盡可能使用戶訪問Exchange郵箱時(shí)，使用其所登錄站點(diǎn)的Exchange服務(wù)器。例如這里的配置，DB#3上存放的是2ndSite內(nèi)的用戶郵箱，默認(rèn)會在ExchAllinOne上被激活，而DB#3上的RPCClientAccessServer設(shè)置為2ndSite上的Client Access Array，這樣就可以保證，在正常情況下，2ndSite的用戶只需要連接到ExchAllinOne就能完成郵箱訪問，而不需要使用1stSite內(nèi)的Exchange服務(wù)器。
DAG的配置 虛擬目錄
Client Access Server上虛擬目錄的配置情況，以O(shè)WA為例，其它虛擬目錄如OAB/ECP等服務(wù)，它們與OWA所使用的主機(jī)名完全相同： 也就是說，只有PCOEExchHTCAS1和PCOEExchHTCAS2，它們組成的cas能夠在外部被客戶端訪問。而且，也只在這兩臺
服務(wù)器上啟用了Outlook Anywhere。
客戶端連接
對于一個(gè)郵箱位于DB#3上的用戶，通過AutoDiscover獲取的默認(rèn)Outlook配置如下：
  Outlook的連接狀態(tài)
  模擬服務(wù)器故障
關(guān)閉ExchAllinone，數(shù)據(jù)庫DB#3切換到1stSite的PCOEExchDAG2上。
  此時(shí)，相當(dāng)于2ndSite內(nèi)所有的Exchange服務(wù)均不再可用。結(jié)合前面提到的RpcClientAccessServer的設(shè)置情況，想像一下對于郵箱在DB#3上，并且正在使用MAPI方式連接到Exchange的用戶會出現(xiàn)什么情況？
答案是：這類用戶將無法繼續(xù)使用MAPI方式進(jìn)行連接了。
對客戶端的影響
Outlook客戶端重新發(fā)起連接，使用Outlook Anywhere方式進(jìn)行。
  注意：這種情況僅限于2ndSite不面向Internet（None-Internet-Facing）的情況，也就是在ExchAllinOne上沒有配置ExternalURL，也沒有啟用Outlook Anywhere的前提下，客戶端才能夠自動切換到Outlook Anywhere方式，并且由cas.pcoe.com實(shí)現(xiàn)客戶端訪問的代理。這就是Failover的情況，服務(wù)器自動完成切換，客戶端自動恢復(fù)連接。
如果2ndSite也是Internet-Facing的，就只能采用Switchover方式，由管理員手動干預(yù)才能夠恢復(fù)客戶端的訪問了。