IT運維知識：Exchange 2010 DAG 跨站點轉移

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

云計算提供商的網絡性能有哪些不同

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

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

然后，該公司分析了超過3.2億個數據點，以創建評估基準。

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

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

ThousandEyes公司檢驗了AWS Global Accelerator是否優于全球互聯網的理論。AWS Global Accelerator于2018年11月推出，該服務采用的不是默認的全球互聯網，而提供使用AWS專用骨干網，并向用戶收費。盡管其在全球某些地區的網絡性能確實有所提高，但在其他情況下，全球互聯網比AWS Global Accelerator更快、更可靠。

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

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

這項研究的結果證明，地點是主要因素，因此，企業在選擇公共云提供商時應考慮用戶到主機區域的性能數據。
多云連接

在2018年的研究中，ThousandEyes公司發現AWS、谷歌云平臺、Azure的骨干網絡之間的廣泛連接。在2019年的研究中還有一個有趣的發現，在將IBM公司和阿里云添加到調查列表中時，多云連接變得不穩定。

ThousandEyes公司發現IBM公司和阿里云尚未與其他提供商完全建立直接連接。那是因為他們通常使用網絡服務提供商(ISP)將其云平臺連接到其他提供商。另一方面，AWS、Azure和谷歌云平臺可以直接相互對等連接，并且不需要第三方網絡服務提供商(ISP)的服務進行多云通信。

隨著多云計劃的興起，在評估多云連接性時，應將網絡性能作為一項衡量標準，因為它似乎在云計算提供商和地理邊界之間不一致。

ThousandEyes公司的綜合性能基準可以作為企業確定哪個公共云提供商最能滿足其需求的指南。但還是需要謹慎，選擇公共云連接的用戶應該考慮全球互聯網的不可預測性、如何影響性能、面臨的風險，以及運營復雜性。用戶應通過個案收集自己的網絡情報來應對這些挑戰。只有這樣，他們才能從云計算提供商所提供的內容中充分受益

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