UCloud可用區的設計理念及功能圖文詳解
從2014年起UCloud 開始致力為分佈在各個地區的資料中心建設高可用、高頻寬的同城環網,將北京的多個主力機房的內網互相打通;其後在完善環網之餘,先後對華北、華南、華東、亞太等地的網路架構進行了升級最佳化,完成了各地的雙星型pop點建設。這種設計理念充分考慮了機房內網連線的高速性、穩定性、冗餘能力和可擴充套件性,之後各地只需選址新建機房並連入pop點即可。
此次UCloud 可用區的設計,是在原有工作基礎上進行了網路基礎架構的系統性升級,相比原同城環網,內網表現更加高速穩定。與此同時,伴隨著產品層面的系統級重構,可用區也提供了各雲產品的跨機房內網互通能力。
地域(Region)是指根據地理位置不同將同一地區的雲服務組成合集。目前,UCloud全球共有7個地域,其中國內有北京一、北京二、浙江、上海、廣東五個地域,海外兩個地域分別設在香港和美國加州。
可用區(Availability Zones)則是指在同一個地域之內的一組資料中心群,即可用區是由多個資料中心組成,一個地域內一般會有多個可用區。可用區在設計上相互獨立,是不同地點的資料中心,在物理和電力上都相互隔離,有獨立的安全保障,單個資料中心的故障影響範圍被隔離在單個可用區範圍內。同時,同一地域內的可用區之間透過高速、穩定、低延遲的網路互相連線,內網互通。
為了實現多機房的容災部署,按傳統方式,企業往往需要增加額外的容災機房,在計算、網路和儲存裝置上增加上千萬元的成本。另外,企業還要解決機房間的專線部署和複雜的運維問題。這樣的成本和複雜度是一般企業所難以承受的。
- 使用者可以把應用部署在多個可用區中執行,實現高可用性的應用架構。即使某個可用區的基礎設施發生故障(例如,例項硬體故障、儲存故障或網路中斷),部署在另一個可用區的應用可以不受影響、繼續執行。
- 使用者可以將業務中的同種資源(例如主機)隨機地建立在兩個可用區內,由於可用區間的內網通訊延時只有約1.5ms,當一個可用區故障後,另一個可用區的主機仍可不受影響地繼續執行,從而保證了業務的持續性。
- 值得一提的是,隨著基礎網路的改造,跨地域的內網通訊質量也獲得了提升,例如使用UCloud提供的跨域內網通道,北京到廣州地域的內網延遲僅約30ms,這為建設兩地三中心的容災方案提供了物理上的保證。
可用區設計之初,UCloud吸取了之前本行業內的一些經驗教訓,確保為使用者提供更流暢的產品體驗,著重體現了以下幾點:
- 提供在原有產品上的無縫升級能力;
- 確保可用區的核心功能有出色的使用體驗;
- 設計出解決使用者痛點的特色功能,例如混合雲的網元互通、共享頻寬的自由分組等。
其中,產品的無縫升級能力一直是UCloud重點強調的設計理念,因為如此才能保證既有使用者的權益,讓他們隨著UCloud的成長而不斷獲利。
以EIP(Elastic IP,又稱彈性 IP) 跨可用區漂移這個功能為例,AWS和部分國內雲服務提供商,雖然具有EIP跨可用區使用的能力,但為此需要申請專門的EIP,並需要將原主機上繫結的IP銷燬,再綁上新申請的IP方能達到目的。使用不方便之餘,舊有IP也無法再找回;若有備案等原因導致IP無法替換,則原有資源就無法享受到EIP漂移的便利。
然而,UCloud設計方案之初,便考慮了已有使用者的立場和便利性,確保其存量IP都能自由使用IP漂移等所有可用區功能。防火牆的設計也是秉承著同樣的理念。 如UCloud特色的共享頻寬,原本只限定在單一機房內使用,隨可用區上線,該功能也新增了自由編組能力,可以滿足使用者更加靈活豐富的使用場景。而存量的共享頻寬,都可無縫的繼續使用和擴充套件。
1.1 外網EIP,支援跨可用區繫結
隨著網路底層的重新設計,使用者的外網IP(EIP)可以在一個地域內的任何可用區使用。為了保證業務連續性,IP地址經常有保留的必要(如備案要求或者應用呼叫需要)。當需要重新規劃可用區間的資源分佈時,外網IP支援從一個可用區的資源上解綁,並在另一個可用區內使用。
1.2 頻寬管理,支援多個EIP跨可用區及自由分組
同時,UCloud特有的外網IP頻寬管理產品“共享頻寬”的形態也有了很大的演進。共享頻寬是一種多個外網IP共享網路頻寬總量的頻寬模式。相比每個IP需要單獨指定和購買頻寬,多IP共享頻寬大大提高了頻寬使用效率,節省了使用者成本。
現在,新形態的共享頻寬支援使用者將一個地域內的所有EIP自由地分組計算。例如,可以將某10個EIP劃分為一個共享頻寬組,共享50M的頻寬,其他5個EIP歸屬於另一個共享頻寬組,共享30M的頻寬。而對於核心業務使用的某IP地址,為了保證其頻寬不被其餘業務搶佔,該IP仍可以使用獨立的頻寬計費方式。這種UCloud特有的獨立頻寬和共享頻寬協同使用的模式,進一步地滿足了使用者多樣的場景需求,保證了使用者業務的穩定性,同時也降低了使用者成本。
1.3 ULB負載均衡,支援掛載跨可用區後端
一個地域內的網路設計,除了跨可用區的內網通訊保障外,還提供了網路產品層面的高度靈活性。負載均衡(ULB)本次也支援了在一個地域內自由使用,ULB支援同時掛載不同可用區內的後端例項,為實現跨可用區的資源平衡和容災在技術上鋪平了道路。
可用區和混合雲方案結合,也可以產生1+1>2的效果,創造更大的價值。UCloud提供物理雲、託管雲、專線等多種雲接入方式,支援使用者創造公私結合的混合雲方案,解決使用者分步驟平滑上雲的痛點。所以,在同一地域內(例如北京),UCloud也提供了多個可供選擇的託管雲接入機房以及多個專線接入點,這些接入點都有完善的冗餘和容災設計。
在可用區未上線前,混合雲的接入位置和公有云資源的位置存在一定的耦合關係,給使用者使用帶來了限制。例如,使用者將自有伺服器託管到UCloud北京C資料中心,則預設只能與北京C的公有云形成互通。這種混合雲模式對使用者業務擴充套件造成不便,若其在北京D又部署了公有云資源,則需要單獨搭建轉發叢集,才能與C的託管雲互通,增加了維護成本。
隨著可用區上線,使用者將混合雲就近接入到任一位置,都能把其私有資源和該地域內所有可用區的公有云資源直接打通。這種一攬子解決的接入方案,提供了將混合雲和公有云部署解耦的能力,大大減少了使用者在上雲過程中所耗費的精力和產生的顧慮。
傳統方式的跨資料中心容災,對使用者而言是一個成本高昂且費事費力的任務。使用者需要在兩個資料中心都部署一套同樣的系統,並透過資料中心間的專線進行資料同步等工作。對外則需要透過DNS解析等方式,在災備時將業務從一處切換到另一處。
地域和可用區的產品特性,結合UCloud的跨域內網高速連線,可以為使用者構建更高層次的容災設計和完整的兩地三中心解決方案。
由於EIP和ULB可以在地域級別存在,一個地域內可以部署一套EIP和ULB,並以此固定地向外提供服務。ULB後端可以掛載來自兩個可用區的資源。因而可以將後端業務中使用的主機、資料庫、記憶體快取等分散地分佈於多個可用區內,這樣就構成了同城內雙活的兩個中心(生產中心和同城災備中心)。這兩個中心具有基本同等的業務處理能力,資料透過跨可用區自身的內網進行實時同步。日常情況下,兩個中心可同時分擔業務和管理系統的執行,並可切換執行或同時執行;災難情況下,可在基本不丟失資料的情況下進行災備應急切換,保持業務連續執行。
此外,UCloud提供的跨域內網高速連線(UDPN),可以為相對地理位置較遠的兩個地域(如北京和廣東)的公有云之間提供高速而穩定的內網連線。使用UDPN後,北京到廣州的內網延遲可以穩定在30ms左右,而UDPN的成本比使用者自建北京-廣州的專線成本低很多,這為部署“兩地三中心”中的異地災備中心,創造了基礎設施層面的條件。
同時,UDB資料庫產品支援跨可用區的資料實時同步能力,透過將主庫和從庫分別部署在不同的可用區內,支援業務節點和資料節點的熱備能力;還可用透過跨域的內網連線實現多地的資料節點冷備。相比原來的叢集,具備的指數級的容災能力提升。
使用者可以在另一地域,建立一套輕量級的災備系統,並與主地域進行內網打通,備地域的資料進行跨地域的主從同步。當主地域發生故障時,備地域的系統可以按既定計劃拉起,並暫時提供服務。
UCloud 可用區帶來的更多更具體的特性提升,可參見下表。
雲重度使用者,其有大量的伺服器資源,因歷史原因和系統設計,無法全部上雲,為享受雲端計算技術的紅利,他們選擇UCloud的混合雲方案,其自有的伺服器接入UCloud北京的混合雲接入點,同時在北京的B、C、D等多機房部署了公有云業務,兩者透過北京地區的內網環網打通。
出於其自身業務和管理的需要,中手遊託管雲採用分批分專案的方式,分別接入了北京B、C、D等地的託管接入點,公有云資源也平均分佈於北京B、C、D等處。這就造成北京B機房的託管雲和北京C機房的公有云、北京D機房的託管雲和北京B機房的公有云通訊等需求。為應對這類通訊需要,中手遊使用了UCloud為其搭建的轉發叢集,但是轉發叢集存在一定的運維成本,而且流量有突發等情況,原有叢集面臨轉發能力限制和擴容需求。且隨其專案的增多,叢集管理的複雜度也相應上升。UCloud 可用區的推出,很好地幫助中手遊解決了該痛點。
伴隨著網路架構的升級,混合雲和跨可用區的公有云直接可以透過內網高速互通,吞吐率和穩定性直接透過UCloud基礎架構進行保障,其效能不再依賴轉發叢集,也讓中手遊的運維成本降低至零。
可用區整體上線也體現了UCloud強大的運營系統和運營能力。為支援可用區,UCloud現有的所有產品和基礎設施都需要進行大幅度的重構。而UCloud現已為3萬多家企業級使用者提供公有云服務,上面執行著海量的服務和資料。如何在不影響使用者業務的情況下,進行全系統級的複雜重構?這就要求整個底層的業務運營系統設計,能滿足無縫、透明的要求。唯有如此,底層功能大大小小的每一次迭代,才不會影響使用者的資料安全和業務安全。
除運營系統設計外,UCloud還擁有專業的運營團隊和豐富的運營經驗。在功能實際上線前,預先設計了詳細周密的釋出計劃,經過了數次釋出演練和壓力測試,此外還有監控分析系統,不斷實時監測實施狀況並反饋,並分析潛在風險點。
而數萬量級的使用者,根據業務特性、資源種類、地域分佈等,被細化拆分成上百組使用者組。這些群組按事先設計的計劃表,按序分批上線功能。上線前後,售前售後團隊保持全程跟蹤,保證使用者最快的適應和使用功能。
除保證功能升級對使用者業務無影響外,UCloud還透過合理的技術方案,努力讓原有的存量機房都具有產品持續升級的能力。確保不同階段建設的機房,儘管底層的物理實現存在差異,但都能在產品層面上向同一個方面不斷演進,維護原有使用者的利益。
雲端計算是一個飛速發展的行業,新產品新特性不斷湧現,UCloud依靠強大的雲平臺運營能力,讓每位使用者安全、便利的享受雲端計算帶來的好處,跟上雲時代的步伐。
可用區體現了雲服務商的更高層次的基礎設施設計能力,是一個IaaS服務商發展到一定規模和階段後必然的選擇。UCloud透過完善複雜的系統設計和細粒度灰度控制,向使用者安全平滑地交付了可用區這一重大功能,為使用者基於雲平臺搭建更靈活更可靠的業務系統提供了底層保障。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69901823/viewspace-2916055/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 圖文詳解23種設計模式設計模式
- cookie與session的區別(圖文詳解)CookieSession
- Wgpu圖文詳解(03)緩衝區BufferGPU
- 高可用架構設計全面詳解(8大高可用方案)架構
- Java Stream函數語言程式設計案例圖文詳解Java函數程式設計
- 長文圖解:詳解金字塔原理如何應用於架構設計圖解架構
- 架構與思維:瞭解Http 和 Https的區別(圖文詳解)架構HTTP
- JuiceFS 目錄配額功能設計詳解UI
- SSM 實現支付寶支付功能(圖文詳解+完整程式碼)SSM
- Python中集合的概念及基本操作詳解!Python
- Java泛型詳解,史上最全圖文詳解!Java泛型
- PopClip使用教程圖文詳解
- 一文詳解微服務架構的資料設計微服務架構
- 針織毛衫的概念及設計
- 一文詳解 OceanBase 2.0 的“全域性索引”功能索引
- 分頁機制圖文詳解
- mysql資料庫的安裝(圖文詳解)MySql資料庫
- 圖文詳解 HDFS 的工作機制及其原理
- Keepalived 高可用詳解
- CentOS 7安裝教程(圖文詳解)CentOS
- 圖文並茂詳解 NAT 協議!協議
- Jenkins安裝部署使用圖文詳解(非常詳細)Jenkins
- 一文詳解自動駕駛的執行設計域(ODD)自動駕駛
- 設計模式詳解設計模式
- Mybatis 一級快取和二級快取原理區別 (圖文詳解)MyBatis快取
- 影像處理之濾鏡、圖文排版的開發詳解,從入門到起飛
- EventBus 3.0+ 原始碼詳解(史上最詳細圖文講解)原始碼
- Dart 非同步程式設計詳解之一文全懂Dart非同步程式設計
- OSPF協議的多區域配置,圖文講解協議
- 專訪UCloud葉理燈:雲端計算會成為人工智慧的基礎設施Cloud人工智慧
- Apache Superset 1.2.0教程 (三)—— 圖表功能詳解Apache
- Java中的設計模式詳解Java設計模式
- 詳解apollo的設計與使用
- 事務隔離級別(圖文詳解)
- ZooKeeper最全詳解(萬字圖文總結)
- 微服務最全詳解(圖文全面總結)微服務
- 常用負載均衡詳解(圖文總結)負載
- LL圖文詳解mysql中with...as用法huxMySqlUX