大家周四好。
昨天寫(xiě)的HDS的ORACLE雙活文章，好像閱讀量還是蠻高的。很多讀者也在后臺(tái)回復(fù)了很多建議，這里選登一下。
這個(gè)確實(shí)是西瓜哥寫(xiě)錯(cuò)了，圖上有明確標(biāo)示，是每秒的交易數(shù)量，不是每分鐘。SORRY。
這個(gè)我覺(jué)得可以理解，因?yàn)镠DS只是模擬網(wǎng)絡(luò)環(huán)境，距離都是模擬出來(lái)的，因此這個(gè)組網(wǎng)就不奇怪了。
還有一些網(wǎng)友反饋，目前HDS VSP G1000還不能同時(shí)支持GAD和異構(gòu)虛擬化，因此不能利舊，這個(gè)不免比較遺憾。另外，也有網(wǎng)友說(shuō)華為的雙活支持采用iSCSI盤(pán)做仲裁，這樣鏈路的成本更低，而HDS必須用FC鏈路。
既然大家對(duì)雙活這么感興趣，西瓜哥今天又看了HDS VSP G1000在WMware和Microsoft的虛擬化環(huán)境下的測(cè)試報(bào)告，把要點(diǎn)一塊分享給大家。
首先來(lái)看看vSphere的情況。
這個(gè)是組網(wǎng)拓?fù)鋱D。這回仲裁陣列采用較為低端的HUS-150，服務(wù)器用的是HDS自己的刀片服務(wù)器。
這個(gè)是軟件的名稱(chēng)和版本的情況。
這是各個(gè)軟件模塊的位置。我們看到HDLM多路徑軟件安裝在ESXi上。
這個(gè)是RAID的配置情況。里面的command device(HDS術(shù)語(yǔ))就是vmware HA集群用到的仲裁盤(pán)，EMC術(shù)語(yǔ)好像叫g(shù)atekeeper。
HDS測(cè)試了11種故障的場(chǎng)景，具體西瓜哥就不解釋了，看下表吧。
我主要講兩點(diǎn)比較特別的場(chǎng)景：
1、仲裁站點(diǎn)不能訪(fǎng)問(wèn)。如果主從站點(diǎn)都不能訪(fǎng)問(wèn)仲裁站點(diǎn)，那么這個(gè)時(shí)候?yàn)榱吮ＷC數(shù)據(jù)的完整性，雙活會(huì)停止，系統(tǒng)選舉某一個(gè)站點(diǎn)來(lái)提供服務(wù)。這里可以看到，仲裁的機(jī)制還是非常重要的。
2、如果某臺(tái)ESXi到存儲(chǔ)的路徑全部中斷(包括本地存儲(chǔ)和遠(yuǎn)程存儲(chǔ))，而主機(jī)的網(wǎng)絡(luò)是正常的，這種情況下最糟糕(因?yàn)檎麄€(gè)站點(diǎn)故障是可以自己恢復(fù))，因?yàn)楸仨毷止ぬ幚怼Mware不會(huì)在另外一個(gè)站點(diǎn)把VM起來(lái)，而需要手工把故障主機(jī)shutdown，然后在其他機(jī)器才能重啟VM。這個(gè)處理機(jī)制和微軟不同。
最后我們?cè)賮?lái)看一下微軟Hyper-V環(huán)境下的情況。
硬件配置基本差不多。
這是軟件的情況，我們看到，把SQL SERVER也跑在環(huán)境里了。可惜沒(méi)有測(cè)試性能。
測(cè)試的場(chǎng)景和VMware基本一樣，結(jié)果也差不多。唯一的區(qū)別就是有個(gè)場(chǎng)景微軟的集群方式處理方法不同，在某個(gè)Hyper-V的所有存儲(chǔ)路徑都出現(xiàn)故障的情況下，其VM可以在另外一個(gè)站點(diǎn)自動(dòng)重啟，而VMware必須手工去處理。
高端存儲(chǔ)支持雙活功能，主要的應(yīng)用場(chǎng)景就是ORCLE這樣的數(shù)據(jù)庫(kù)雙活，其次就是vmware和微軟的云數(shù)據(jù)中心的雙活。當(dāng)然，后面這種雙活可以支持更遠(yuǎn)的距離，甚至到300KM(采用WAN優(yōu)化器)，因?yàn)閂MWARE HA可以支持存儲(chǔ)的復(fù)制往返RTT時(shí)延高達(dá)5ms，而一般數(shù)據(jù)庫(kù)要求RTT時(shí)延在1ms以下。
我個(gè)人比較傾向存儲(chǔ)本身實(shí)現(xiàn)雙活，而不是采用外部虛擬化網(wǎng)關(guān)的方式，特別是高端存儲(chǔ)。隨著EMC高端將要集成vplex，華為的V3(包括中高端)也將支持雙活，相信這種無(wú)需外置網(wǎng)關(guān)的雙活方案會(huì)很快普及，會(huì)成為容災(zāi)的主導(dǎo)解決方案。
今天就聊到這。See you next time.
京公網(wǎng)安備 11010502049343號(hào)