618 Tech Talk|400%儲存容量增長背後的成長之路
雲妹導讀:
2020 年的京東 618 大促期間,京東智聯雲物件儲存容量新增同比增長400%,流量同比上漲200%,物件儲存服務穩定,完美完成了大促重保任務,為此次京東 618 大促累計下單金額超2692億元的新紀錄提供了堅實的保障。
“我的系統現在執行的挺好的,遷移到雲上需要花費一定的人力還會帶來一定的風險,我為什麼要遷移到雲上面呢?”
這是京東在推動集團各個業務“上雲”時總會被問到的一個問題。相信,這也是很多企業在選擇業務遷移“上雲”時不斷問自己的一個問題。
經過17年的發展,京東618不斷跨上一個個新的臺階,而海量使用者的瀏覽和海量訂單的產生和交付,對後端的支撐系統提出了極高的要求。京東智聯雲作為作為支撐京東618的重要技術中臺,要面臨數百億訪問流量、每秒數百萬次的高併發請求,以及數十億的實時訊息推送,保證全天核心服務不降級、無重大事故,這一切都對京東智聯雲帶來了極大的挑戰。
物件儲存作為京東智聯雲重要的產品之一,在這次618中也起到了及其重要的作用。作為線上服務,京東智聯雲物件儲存不僅為影片、直播等重要資料等儲存和下載提供服務支援,同時也為離線計算平臺提供儲存支援,可以說是京東618大促的核心依賴,物件儲存的穩定性極大的影響了顧客618“買買買”的體驗,必須保證萬無一失。
01 資源彈性伸縮
彈性伸縮的核心需求是在資源池裡面有足夠的資源來滿足業務的增長,在傳統IDC時代,客戶都會規劃好業務的最大增量,留下足夠的buffer資源來應對它,三倍的業務增長至少需要預留200%的buffer。
雲上的物件儲存是一個多租戶系統,彈性伸縮本質上做的事情就是把多個使用者的buffer統一的管理起來,然後按需分配給需要的客戶。
在傳統的IDC時代,京東影片儲存在內部的分散式儲存系統中,每次大促都需要提前兩個多月開始備戰。
下面是一個使用傳統IDC時代618前夕準備的Checklist:
但在使用物件儲存之後,基於物件儲存彈性擴充套件到特性,整個備戰過程變得非常簡單:
02 成本降低
很多企業在把本地到儲存遷移到雲上之後,都會感嘆一件事情,在排除運維相關的人力成本之外,使用雲還是比自己維護一套儲存系統成本更低。接下來我們來看看為什麼使用雲上物件儲存時客戶的成本會降低?
架構最佳化提高資源利用率
首先,在使用雲物件儲存系統之前,很多使用者使用類似Ceph之類的系統來儲存自己的資料,這類系統有一個問題就是,如果整體使用率超過了80%可能會導致部分的寫入失敗或者寫入效能降低,在實際維護的過程中,需要維護較低的水位線。
雲物件儲存系統基於自研儲存系統,在整體使用率接近95%的時候還能保證寫入的可用性和效能。
更合理的機型降低物理儲存成本
在傳統的IDC時代,業務自己維護自己的儲存系統,由於本身儲存需求相對不大,儲存成本在整體成本中佔比較小,一般不大會有太大的動力去最佳化儲存的成本,以下幾個情況會非常常見:
- 使用低密度伺服器,由於儲存規模不足,為了保證可靠性,必須使用更多的節點,這樣每個節點的儲存量就會很低
- 使用老舊的伺服器,同樣由於規模的原因,很長時間都沒有擴容的需求,也就無需採購新的伺服器,導致整體物理成本偏高
- 由於規模的原因,沒有動力去使用新技術/新硬體
和私有的儲存不同,物件儲存是一個快速發展的,大規模的儲存系統,5%的成本降低就能帶來非常可觀的收益,因此我們做了很多工作來降低成本。比如採用更合理的儲存機型別,根據客戶自己業務的特點,定製更合理的機型。
較低的閒置率
在使用雲物件儲存系統之前,為了應對一些日常的促銷等,私有的儲存系統必須要維持足夠的Buffer,要應對一倍的流量突增必須維護一倍的Buffer,這決定了整個叢集的空閒率超過50%。
雲上的物件儲存是一個多租戶的系統,多個租戶會共用一個資源池子,由於多個租戶涉及到不同的行業,業務高峰衝突的機率較小,物件儲存系統不需要為每個使用者留足夠的Buffer,假設最多10%的業務在同一時間流量業務增長一倍,物件儲存系統只需要維護10%的buffer就可以滿足需求,較大的降低了閒置率。
IO資源複用
IO資源更細的劃分的話,會包括儲存/IOPS/頻寬三個維度,每塊磁碟的儲存/IOPS/頻寬都是相對確定的,但是單個業務很難說同時把三種資源全部用掉。
物件儲存是一個多租戶的系統,透過後臺的排程,把不同型別的業務的混合的排程到磁碟上,保證這三個維度的IO資源能儘量的被使用。
京東有一個大資料分析的系統,本身只有數百TB的資料,但是在峰值會產生數百Gb的讀寫頻寬,在遷移到物件儲存之前,需要大量的機器來抗著數百Gb的峰值頻寬,導致儲存資源被大量浪費。在遷移到物件儲存後,由於物件儲存上有大量的相對較冷的資料,透過合理的排程,大資料分析系統複用了這些資料所對應的頻寬,節省了大量的成本。
運維成本降低
儲存系統本身是一個很複雜的系統,需要專業的運維人員來維護,而使用雲物件儲存之後,運維人員主要精力集中在業務上,可以極大的降低運維的人力
03 高可用性保證
儘管在過去兩年多里面,京東零售和京東智聯雲有過多次成功的合作經驗,但是在商場影片把本地資料刪除使用雲作為唯一的資料之前,還是有一定的擔心,物件儲存現在是足夠高可用麼?物件儲存在未來一直是高可用的麼?接下來讓我們一起來探討下物件儲存在可用性保障上走的一些工作。
物件儲存架構圖
整體來說,物件儲存包括業務層(綠色部分),資料儲存(黃色部分),後設資料儲存(藍色部分)三個部分組成,其中業務層是多節點無狀態服務,保證高可用。
資料儲存和後設資料儲存都是有狀態服務,其中資料儲存儲存物件資料的切片,後設資料儲存儲存物件名字到資料切片ID之間的對映。
物件儲存高可用核心思路如下:
- 基於Raft構建高可用的資料儲存和後設資料儲存叢集,部署上都跨多個AZ部署
- 基於多個高可用資料/後設資料叢集構建更高可用的Data/Meta服務,叢集級別故障對使用者影響可控
- 資料和後設資料能寫入到任何一個可用的物理叢集,保證寫永遠可用
- 資料/後設資料都不會修改,確保資料只要存在就能讀到正確的資料,提高讀讀可用性
- 多個叢集做藍綠部署,降低程式/人工操作的影響範圍
下面我們一一來揭秘物件儲存在各種異常情況下是如何保證高可用性。
Q
硬體故障
1、如果磁碟/機器/交換機故障怎麼辦
2、如果機房停電怎麼辦
A
物件儲存的資料和後設資料都是三副本儲存,並且三副本放在三個不同的機房,確保以下:
1、如果有單節點(磁碟/機器/交換機/機房)故障,不會有任何影響
2、如果有兩個節點故障,可能會導致部分複製組不可寫入,物件儲存會透過多叢集的機制來解決這個問題,寫入會寫到其他的可用的叢集,不影響客戶端寫入
3、如果有超過三個節點故障,可能會導致部分資料暫時不可訪問,不影響使用者寫入
Q
網路故障
1、物件的資料是放在多個機房,如果機房之間的光纖被挖斷了怎麼辦
2、如果某個機房和其他機房之間的網路斷了,形成了孤島怎麼辦
3、物件儲存提供公網訪問,如果部分公網IP被攻擊/封禁怎麼辦
A
1、物件儲存資料和後設資料都分佈在三個機房,如果有一個機房不可訪問,其他兩個機房可用形成多數派依舊可以提供服務
2、對於單機房和其他節點失聯,形成資料孤島的情況
- 已經寫入的資料在孤島機房內部有副本,可以讀取
- 孤島內部寫入
i. 資料會寫入到WriteCache中,保證寫入成功
ii. 後設資料會寫入到孤島內部Backup Meta叢集中,後設資料最終需要和孤島外部後設資料合併
3、公網故障,透過域名解析把流量導到其他區域,走內網訪問
Q
SPOF
1、是否會出現少數幾個節點故障,導致整個物件儲存不可用
A
1、物件儲存資料和後設資料服務都是基於多個叢集的,任意一個叢集的故障不會影響物件儲存的寫入
2、物件儲存資料/後設資料不可修改,因此只要資料存在就是可以讀的,不存在某些Master類節點故障導致叢集不可讀
Q
誤操作
1、在日常運維過程中,是否會出現誤操作,導致物件儲存不可用
A
1、物件儲存資料和後設資料都是由多個叢集組成,多個叢集做藍綠部署
2、任何時候操作只能在一個叢集上進行,確保任何錯誤影響的範圍是一個叢集,而不會影響整個物件儲存
Q
程式Bug
1、物件儲存在未來升級過程中,是否會引入新的Bug導致物件儲存不可用
A
1、從研發測試流程上,降低Bug機率
2、全量上線生產環境之前會在預釋出環境和灰的環境執行足夠的時間
3、生產環境遵循藍綠部署,一次只更新一個叢集,確保不會導致整個叢集不可用
多租戶隔離
部分業務在使用雲之前,會擔心兩個方面事情:
- 私密的資料被非授權的方案
- 其他使用者的操作會影響到自己的業務
物件儲存作為一個多租戶的系統,對多租戶之間的資料和訪問都做了嚴格的隔離,確保不會發生資料洩露以及訪問互相影響等問題。
資料安全
在接入集團使用者的過程中,我們經常會被問到以下三個問題:
- 我們的業務資料是非常重要的,是否可能被其他使用者非授權訪問到?
- 我們的業務資料是非常重要的,但是我們的資料儲存在雲的磁碟上,員工是否會透過磁碟直接訪問或者篡改我們的資料?
- 如果有駭客黑進入了內網,是否能直接訪問磁碟或者內部系統來訪問我們的業務資料?
作為一個面向企業使用者的儲存系統, 資料安全是物件儲存的最基礎的需求之一,因此,我們的物件儲存也會從多個方面來保障使用者的資料安全。
使用者資料可能從兩個地方被訪問:
- 透過物件儲存提供的介面訪問,對於此類訪問,物件儲存提供嚴格的認證鑑權機制,以及審計機制,保證使用者的訪問一定被授權,非授權的訪問一定會被發現
- 直接從磁碟訪問,對於此類問題,物件儲存提供完整的加密體系,保證資料無法被訪問
認證授權
京東智聯雲物件儲存實現了面向請求公鑰私鑰的認證體系,使用者的私鑰只有使用者自己知道,可以做到類似一次請求一個密碼的功能,保證的使用者身份無法被偽造。
同時,支援豐富的授權機制,可以透過時間,訪問IP等多個維度對請求授權,進一步保障了使用者資料對安全。
加密體系
京東智聯雲物件儲存支援客戶端和服務端兩個方面對加密。
客戶端加密是指客戶在上傳資料到雲上之前提前對資料做加密,客戶自己維護加密金鑰,我們是無法透過任何方式獲取到使用者的原始資料。
服務端加密是基於託管KMS的加密方式,物件儲存對每個物件生成唯一的金鑰,並且使用AES256對該物件加密,之後儲存用KMS加密後的金鑰而拋棄金鑰原文,這樣從物件儲存本身沒有任何辦法來解密該物件。
KM服務本身使用了符合國家規範的硬體安全模組(HSM)保護您的金鑰的機密性和完整性,您的純文字金鑰不會以任何形式儲存到任何儲存中,且該金鑰不會傳輸到KMS服務區域之外。
審計
對物件儲存/金鑰系統的每次訪問,物件儲存都會記錄下訪問的詳細資訊,提供給使用者去發現預期外的訪問。
訪問隔離
作為一個多租戶的系統,物件儲存有豐富的流控限速功能,並且對每個使用者/bucket生效,確保使用者之間不會互相影響。
今年618大促已經是物件儲存第五次支援京東零售大促了,這是一次例行的支援卻也是一個全新的起點。從本次618開始,京東影片等重要資料放棄了在本地的備份,也就是說物件儲存成為了這些業務的唯一儲存。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69912185/viewspace-2700345/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 我的Python成長之路Python
- 618 Tech Talk|高併發場景下的資料訪問速度如何保障?
- 我的技術成長之路
- 前端菜雞的成長之路前端
- 移動端長按儲存、取消長按儲存圖片
- “雙碳”背後的硬核儲存(上)
- “雙碳”背後的硬核儲存(下)
- 「Golang成長之路」面向“物件”Golang物件
- 「Golang成長之路」面向介面Golang
- JDV背後的技術-助力618
- 「Golang成長之路」內建容器Golang
- 「Golang成長之路」面向介面篇Golang
- 架構思考-業務快速增長時的容量問題架構
- 服裝紡織業的成長之路
- 程式設計師的自我成長之路程式設計師
- Java程式設計師的成長之路Java程式設計師
- 手遊破億月流水背後:一位90後製作人的成長思考
- Java成長之路--一個非科班生的進階之路Java
- 「Golang成長之路」基礎語法Golang
- 「Golang成長之路」物件導向篇Golang物件
- 「Golang成長之路」內建容器篇Golang
- 「Golang成長之路」併發之GoroutineGolang
- 物聯網架構成長之路架構
- 「Golang成長之路」併發任務的控制Golang
- 面試-執行緒池的成長之路面試執行緒
- 如何延長儲存伺服器上資料的儲存時間?伺服器
- 麵包第一股:桃李麵包逆勢增長背後的隱憂
- 網站滲透測試公司的成長之路網站
- 阿里P7架構師的成長之路阿里架構
- 「Golang成長之路」併發之Channel下Golang
- 「Golang成長之路」併發之Channel上Golang
- 「Golang成長之路」基礎語法篇Golang
- IDC:敏捷基礎設施推動分散式儲存穩健增長敏捷分散式
- 200%銷售額增長 10%付費轉化率 遊戲化營銷成618標配?遊戲
- 2023~某熊的成長之路:擁抱更大的世界
- 2023中國企業級儲存市場:整體韌性成長,領域此消彼長
- 騰訊雲升級多個雲端儲存解決方案 以智慧化儲存助力企業增長
- IDC:軟體定義儲存與超融合儲存系統穩態發展 推動市場增長