好爽又高潮了毛片免费下载,国产97在线 | 亚洲,亚洲一区二区三区AV无码,特级AAAAAAAAA毛片免费视频

異地機房，兩地雙活，WDM波分互聯。

缺少了大容量、高速率的波分互聯，結構功能便難以實現了。

*部分：WDM復制鏈路

1.1 鏈路類型

鏈路，來根線連接起來，不就可以了么？沒問題，光纖連起來，這就是鏈路。

當你在同一個機房，你可以直接婁十芯光纖連接，很簡單。

如果是一座樓內，甚至一個園區內，管井你可以隨便用，鋪設一根48芯光纜，沒多少錢。

問題是本地和遠端相隔太遠，出了園區，你就不能隨便在兩個樓之間飛一根線了，必須租用電信部門提供的各種線路了，當然，點對點無線傳輸也是個可以考慮的路子，如果兩樓之間相隔不太遠且視覺直達，到可以考慮這種方式。

電信部門有各種鏈路或者共享鏈路提供出租，zui原始的一種就是裸光纖，兩地之間直接通過電信部門部署好的光纜，其中分出兩根纖芯給你。當然，電信部門會有中繼站，負責對光信號的路徑交叉及信號增強中繼。因為不可能任意兩點間都恰好有光纖直連，必須通過中繼和交叉。有了裸光纖，你兩端跑什么信號什么協議什么速率就隨你了，只要光模塊的波長功率合適，兩端就可以連通。

裸光纖不能走太遠距離，一個是價格太貴另一個是電信部門也不可能租給你用，因為距離太遠的時候，光纜資源越來越稀缺，不可能讓你獨占一根，實際上近距離傳輸也很少有人用裸光纖了，尤其是大城市，因為光纖資源很稀缺，除非互聯網這種體量的用戶，其他基本都是租用與別人貢獻的某種虛擬鏈路（簡單說就是電路、通道資源）。上到電信部門的IP網，或者直接上到SDH同步環網，不同的方式和速率，價格也不同。

（存儲設備一般都支持iSCSI協議復制，那么此時可以接入使用以太網作為zui終連接方式的比如ADSL、GEPON等，如果僅支持FC協議復制，要么增加一個FC轉IP路由器再接入IP網，要么使用局端提供的FC協議轉換設備直接上SDH同步網。）

裸光纖一來資源緊張，二來它租賃的價格也不低。zui重要的它容量大，可以使用波分進行擴容。使用DWDM設備是可以在一路光纖上目前復用高達80路光波的。對于現在電信的骨干網，就是這樣的結構，2根88芯光纜，上80路DWDM，每路跑10G，可以跑上6個T的互聯帶寬。

1.2何為WDM

所謂的波分復用(WDM， Wavelength Division Multiplexing)其本質上也是頻分復用而已。WDM是在1根光纖上承載多個波長(信道)系統，將1根光纖轉換為多條通道Channel，當然每條Channel獨立工作在不同波長上，這樣極大地提高了光纖的傳輸容量。就像是調速公路上不同的車道。

由于WDM系統技術的經濟性與有效性，使之成為當前光纖通信網絡擴容的主要手段。波分復用技術作為一種系統概念，通常有3種復用方式，即1310 nm、1490 nm和1550nm波長的波分復用、粗波分復用(CWDM，Coarse Wavelength Division Multiplexing)和密波分復用(DWDM，Dense Wavelength Division Multiplexing)。

第1種相對簡單一些，通過FWDM就能實現，在EPON、GPON以及三網融合中非常常用。

這次主要說的是后面2種，CWDM，DWDM。因為這兩種在擴展的容量大，粗波分能擴展到16通道，密波分擴展20、40、80都可以。以當前主流技術，每個通道能跑單向10Gbps。以下面這種為例16CH的CWDM做成雙纖的傳輸，便能達到160G。

40波 在DWDM

粗波分、密波分的核心是無源的波分，他不帶電，也是透明的，你可以傳SDH、ATM、IP、FC都可以。相當于他提供車道，你開什么車都可以，只要走對道路了。他要求的只有一個，波長對應。像交換機上的光模塊，如果要走波分，組建波分系統的時候就要注意波長了。現在不管是千兆的SFP，還是萬兆的SFP+、舊的XFP，都有粗波分、密波分波長的光模塊，由于波分上要求更高更精細了，（普通模塊波長寬度60nm，而粗波的波長示要15nm，密波波長要求1.6nm），波分光模塊的價格是普通光模塊婁倍。

普通的光模塊是不能走上波分的。就像你開飛機上道，會壓別人的道，這是不允許的。要用就單獨自己2芯光纖傳輸吧。

波長為1563.86nm 的10G DWDM光模塊。

在存儲上，一般還是用FC，當然也有IP-SAN的，就看你的配置了。IP的一般是1.25G和10G，FC和1xFC的1G、2xFC的2G、4xFC的4G、8xFC的8G，波分可以讓你傳。

接下來就要控制的就是業務數量了，你有多少路10G，或者多少路8G，這個在波分上需要做夠通道。

兩機房業務都接進波分后，兩機房的波分就需要用裸光纖來連接，實現傳輸。回歸光纖傳輸zui基本的問題：光功率。直接會關系到傳輸好壞。主要由光模塊的收發光強、線路及跳接和波分的衰減來決定。這需要計算。

飛宇光電 2U機架式 OEO

飛宇光電 1U機架式 EDFA

當鏈路距離很遠，鏈路衰減好的情況下，超過60KM，就需要加放大器或中繼器，對于粗波，按現在術要用OEO中繼。對于密波，則有一種偉大的放大器叫EDFA，他可以把所有通道的光一起放大，超遠距還會設計色散、噪聲、非線性效應等。

當傳輸很重要的時候，我們還需要做線路保護，因為有時候地方施工，你的線路很可能會被挖斷！上年啊里杭州的光纖就被斷過一次。在波分層面，可以通過多租一條不同路由的線路，分別上2套不同的波分作備份。也可以通過光纖線路切換設備來實現，好處是可以減少1套波分設備，壞處是1他增加損耗了2是他也有可能會壞。

配置波分鏈路，需要專業做波分的公司來弄。我在公司負責波分鏈路設計，從初學到現在，深有體會。

上面說的基本都是物理層的東西

接下來更貼近鏈路層的內容

1.3 長肥管道效應鏈路的時延除了與距離有關之外，還與鏈路上的各個局端中繼和轉換設備數量有關。光在光纖中傳播靠的是全反射，等效速度為每秒20萬千米，而更多時延則是由信號轉換和中繼設備引入的，電信運營商的網絡可分為接入網和骨干網，本地的信號比如以太網或者FC，先被封裝成接入設備所允許的信號，比如GPON等，再視專線類型，上傳到以太網交換機、路由器或者直接到局端骨干網入口設備比如OTN。在這種高時延鏈路之下，每發送一個數據包，要等待較長時間才能得到ack，此時如果源端使用同步復制，性能將非常差，鏈路帶寬根本無法利用起來，太高時延的鏈路必須使用異步復制。應用端同步IO模式+同步復制，這種場景是吞吐量zui差的場景，異步IO+同步復制，效果其實尚可，的還是異步復制（不管同步還是異步IO）。不管是異步復制還是同步復制，如果使用了FCP或者TCP這種有滑動窗口的傳輸協議，那么難免會遇到傳輸卡殼，TCP有個zui大可容忍未ACK的buffer量，傳輸的數據達到這個buffer，就必須停止發送，而必須等待ack返回，只要一卡殼，鏈路上這段時間內就不會有數據傳送，嚴重降低了傳輸帶寬，為此，專業一點的存儲設備都要支持多鏈接復制，向對端發起多個tcp鏈接，在一條鏈接卡殼的時候，另一條正在傳輸數據，這個與數字通信領域常用的多VC/隊列/緩沖道理是一樣的，一個VC由于某種策略導致卡殼的時候，其他VC流量一樣會利用起底層鏈路的帶寬。

 第二部分：雙活數據中心

    2.1 雙活并發訪問的底層機制從存儲系統的視角來看雙活數據中心，怎么個雙活法？應用首先得雙活，應用不雙活，就無所謂雙活數據中心。也就是多個實例可以共同處理同一份數據，而不是各處理各的（互備，或者說非對稱雙活）誰壞了對方接管，支持多活的應用典型比如Oracle RAC、各類集群文件系統等，這些應用的每個實例之間是可以相互溝通的，相互傳遞各種鎖信息及元數據信息，從而實現多活。一般來講，這類多活應用，其多個實例一定要看到同一份數據，如果這同一份數據有多個副本，那么一定要保證著多個副本之間是時刻一樣的（有些互聯網應用除外，不要求實時一致性），這與多核心多路CPU的Cache Coherency思想是一樣的（具體可以看本公眾號zui早的一篇文章”聊聊CAPI“，所以冬瓜哥一直認為底層通了，一通百通）。所以，要么讓這多個應用實例所在的主機通過網絡的方式共享訪問同一個數據卷，比如使用SAN（多活數據庫比如Oracle RAC，或者共享式集群文件系統，這兩類多活應用需要訪問塊設備）或者NAS（有些非線編集群應用可以使用NAS目錄），用這種方式，數據卷或者目錄只有*的一份而且天生支持多主機同時訪問。在這個基礎上，如果將這份數據卷鏡像一份放到遠端數據中心的話，而且保持源卷和鏡像卷時刻*一致（同步復制），那么多活應用就可以跨數據中心部署了，多活應用看到的還是同一份數據，只不過本地實例看到本地的數據卷，遠端實例看到遠端的數據卷，數據卷在底層用同步復制實現*一致，這與在本地多個應用實例看到*一份數據卷副本的效果是一模一樣的，這也就做到了多活，能夠在整個數據中心全部當掉時，短時間內幾乎無縫業務接管。

    但是，實現這種雙活，也就是讓存儲系統在底層實現“源卷和鏡像卷時刻一致”，并不是那么簡單的事情。首先，傳統容災數據復制技術里，業務是冷啟動（災備端應用主機不開機）或者暖啟動（災備端應用主機開機但是應用實例不啟動，比如Windows下對應的服務設置為“手動”啟動），這個極大節省了開發難度，災備端存儲系統所掌管的鏡像卷，不需要掛起給上層應用提供數據IO，而只需要接收源卷復制過來的數據即可。而多活場景下，應用實例在災備端也是啟動而且有業務IO的，那就意味著，源卷和鏡像卷都要支持同時被寫入，而且每一筆寫入都要同步到對端之后才能ACK，這種方式稱之為“雙寫”，以及“雙向同步”，只有這樣，才能做到兩邊的實例看到的底層數據卷是一模一樣的，而不是其中某個實例看到的是歷史狀態，而其他實例看到了狀態，后者是不能發生的，否則應用輕則數據不一致，重則直接崩潰。這種雙寫雙向同步，看似簡單，同步不就行了么？其實，不了解底層的人可能也就到這一步了，然后就去出去裝逼去了，殊不知，很多坑你都沒有填，說不定哪天就把自己給裝死了。

    存儲端實現雙寫雙向同步的*個難點在于，如何保障數據的時序一致性。與單副本本地多活應用系統相比，雙副本多活，也就是雙活數據中心，兩邊的應用實例各自往各自的副本寫入數據，如果A實例像A卷某目標地址寫入了數據，那么當這份更新數據還沒來得及同步到B卷之前，B實例如果發起針對同一個目標地址的讀操作，B卷不能響應該IO，因為B卷該目標地址的數據是舊數據。B卷如何知道A實例已經在A卷寫入了數據呢？這就需要復雜的加鎖機制來解決，A端的存儲系統收到A實例寫入A卷的IO之后，不能夠ACK給A卷，它需要先向B端的存儲系統發起一個針對該目標地址的Exclusive排他鎖，讓B端存儲系統知道有人要在A端寫數據了，然后才能向A卷中寫入數據，如果B端的B卷針對此目標地址正在執行寫入操作（由B實例發起，但是通常不會出現這種情況，應用實例之間不會出現兩個以上實例同時寫入某目標地址的操作，因為多活應用實例之間自身也會相互加鎖，但是存儲系統依然要考慮這種情況的發生），則此次加鎖不成功，A端存儲系統會掛住A實例的寫操作，直到能夠加鎖成功為止，這里可以定期探尋也可以spin lock，不過在這么遠距離上去spin lock恐怕性能會很差，所以不會使用spin lock的模式。加鎖之后，B端如果收到B實例針對該目標地址的讀或者寫IO，都不能夠響應，而是要掛住，此時B端存儲系統要等待A端存儲系統將剛才那筆針對A卷的寫IO發送過來之后，才能夠返回給B實例，這樣，存儲系統任何時刻都能保證對A實例和B實例展現同樣的數據副本。同理，B卷被B實例寫入時，也需要執行相同的過程，對A存儲的A卷對應地址加鎖，然后后臺異步的將數據同步到A端。

     第二個難點，就是如何克服高時延鏈路導致的IO性能降低。通過上面的描述，大家可以看到上文中有個坑沒被填，也就是A存儲在何時給A實例發送寫成功ACK？是在向B端加鎖成功后，還是在A實例寫入的數據被*同步到的B端之后？如果是后者，那就是傳統的同步復制技術了，把這塊數據同步到B端，是需要一定時間的，如果使用的是TCPIP方式傳輸，根據上文中的分析，還會出現卡殼，等待傳輸層ACK等，時延大增，性能當然差。但是如果A端在向B端加鎖成功后立即給A發送寫ACK，那么時延就可以降低，此時雖然數據還沒有同步到B，但是B端已經獲知A端有了數據這件事情，如果B實例要訪問B端的這份數據，B存儲會掛住這個IO，一直等到A將數據復制過來之后才會返回給B實例，所以不會導致數據一致性問題。也就是說，這種方式，擁有異步IO的性能效果，以及同步IO的數據一致性效果，兩者兼得。而代價，則是丟失數據的風險，一旦數據還沒有同步到B端之前，鏈路或者整個A端故障，那么B端的數據就是不完整且不一致的，要性能就注定要犧牲一致性和RPO。

     第三個難點：解決死鎖問題。如果某個應用不按照規律來，該應用的兩個實例在兩邊分別同時發出針對同一個目標地址的寫IO操作給兩邊的存儲控制器，兩邊會同時向對方發起加鎖請求，這個過程中由于鏈路時延總是存在的，鎖ack總會延時收到，導致兩邊同時對該地址加了鎖，結果誰都無法寫入，這便是死鎖。解決這個問題就得找一個單一集中地點來管理鎖請求，也就是讓其中一個存儲控制器來管理全部鎖請求，那么無疑該存儲控制器一定會比對端更快的搶到鎖，不過這也不是什么大問題，本地訪問永遠先于對端訪問，這無可厚非。

    綜上所述，雙活或者多活數據中心方案里，存儲系統的實現難點在于鎖機制。與多CPU體系（也是一種多活體系結構）相比，多CPU在針對某個進程寫入數據到Cache時，是不向其它節點加鎖的，而只是廣播，如果多個進程同一時刻并發寫入同一個目標地址，那么就發送多個廣播，誰先后到，覆蓋先到的，此時CPU不保證數據一致性，數據或被撕裂或被循環覆蓋，這個場景需要程序遵守規則，寫前必須搶到鎖，而這個鎖就是放在某個目標地址的一個集中式的鎖，程序寫前使用舉例來講spin lock來不斷測試這把鎖是否有人搶到，沒搶到就寫個1到這個地址，而spin lock本身也必須是原子操作，spin lock對應的底層機器碼中其實包含一條lock指令，也就是讓cpu會在內部的Ring以及QPI總線上廣播一個鎖信號，鎖住所有針對這個地址的訪問，以協助該進程搶到鎖，保證搶鎖期間不會有其他訪問亂入。存儲系統其實也可以不加鎖，如果上層應用真的兩邊并發同時訪問同一個地址，證明這個應用實現的有問題，但是存儲系統為了保證數據的一致性，不得不底層加鎖，因為誰知道哪個應用靠不靠譜，多線程應用很多，程序員們已經駕輕就熟，但是多實例應用，非常少，出問題的幾率也是存在的。

    冬瓜哥很少提及具體產品，因為冬瓜哥認為底層通一通百通，不需要了解具體產品實現，所有實現都逃不出那套框架。但是為了迎合大家口味，冬瓜哥還是提一提產品比較好。可以肯定的是，HDS的雙活，是確保將數據*同步到對端之后（同時向對端加鎖），才返回本端應用寫ACK信號；而EMC Vplex所謂的“基于目錄的緩存一致性”，則是使用了加鎖完便ACK方式，這也就是其號稱“5ms時延做雙活”的底層機制。至于其他家的雙活，逃不出這兩種模式，愛是誰是誰，愛抄誰抄誰，冬瓜哥就不操心了。不過，“基于目錄的緩存一致性”其實是出自CPU體系結構里的學術名詞，EMC很善于包裝各種市場和技術概念，連學術名詞都不放過。不過，雙活的這種一致性機制，與多核或者多CPU實現機制的確是同樣思想，在MESI協議中，某個節點更新了數據，會轉為M態（Modify），并向其他所有節點發起Probe操作作廢掉其他節點中對應的cache line，這一點和上述思想是一致的，只不過M態的數據一般不用寫回到主存，而是呆在原地，其他節點入有訪問，則M態cache的owner節點返回數據，而不是將數據同步到所有其他節點上（早期某些基于共享總線的CPU體系結構的確是這樣做的）。

     2.2 雙活與Server-SAN能從雙活扯到ServerSAN？是的，ServerSAN本身也是多活的，其實現機制類似于傳統存儲系統的雙活方案，只不過其有分布式的成分夾雜在里面。目前主流ServerSAN實現方式是將一個塊設備切片比如切成幾個MB大小的塊，然后用Hash算法來均衡放置到所有節點中，每個切片在其他節點保存一到兩份鏡像，主副本和鏡像副本保持*同步，不復制完不發送ack。由于時刻同步，所以ServerSAN可以承載多活應用，每個節點上都可以跑一個應用實例，所有實例看到時刻相同的存儲空間，可以并發寫入多個鏡像副本，為了防止某些不守規矩的應用，多節點間也要實現分布式鎖，也要解決死鎖，所以一般使用集中式鎖管理，比如zookeeper之類。如果把ServerSAN多個節點拆開放到多個數據中心，這就是多活數據中心了。所以你能看到，ServerSAN本身與雙活數據中心都是同樣的思想。