第一期Tech Talk 會議內容整理 | U刻
-
第一期Tech Talk 會議內容整理
欄目：技術分享
10月12日，由UCloud主辦的首期Tech Talk在滬舉行，Tech Talk是UCloud面向使用者做深度技術交流的首次嘗試，會議分為雲硬碟、虛擬網路、雲主機三個議題方向。深度技術分享之外，三位講師也通過互動溝通為UCloud使用者答疑解惑。
議題一：雲硬碟架構升級和效能提升詳解
雲盤為雲伺服器提供高可用、高可靠、持久化的資料塊級隨機儲存，其效能和資料可靠性尤為重要。UCloud根據以往的運營經驗，在過去一年裡重新設計了雲盤的底層架構，在提升普通雲盤效能的同時，完成了對NVME高效能儲存的支援。UCloud塊儲存研發部負責人彭晶鑫作為開場分享，從IO路徑優化、元資料分片、支援NVME等技術維度著手，詳細講解了UCloud雲硬碟的架構升級和效能提升策略。
IO路徑優化
過去，IO讀寫需要經過三層架構，請求首先通過網路，訪問proxy代理伺服器（proxy主要負責IO的路由獲取、快取、讀寫轉發以及IO寫操作的三份複製），最後到達後端儲存節點。老的架構裡，每一次讀/寫IO都需要經過2次網路轉發操作。
為了降低延時，優化後的方案將proxy負責的功能拆分，定義由client負責IO的路由獲取、快取，以及將IO的讀寫傳送到主chunk當中，由主chunk負責IO寫的三份複製。架構升級之後，IO的讀寫只需經過兩層架構，尤其對於讀IO而言，一次網路請求可直達後端儲存節點，其時延平均可降低0.2-1ms。
元資料分片
分散式儲存會將資料進行分片，從而將每個分片按多副本打散儲存於叢集中。老架構中，UCloud支援的分片大小是1G。但是，在特殊場景下（如業務IO熱點侷限在較小範圍內），1G分片會使普通SATA磁碟的效能非常差，並且在SSD雲盤中，也不能均勻的將IO流量打撒到各個儲存節點上。所以新架構中，UCloud將元資料分片調小，支援1M大小的資料分片。
分片過小時，需要同時分配或掛載的元資料量會非常大，容易超時並導致部分請求失敗。這是由於元資料採用的是預分配和掛載，申請雲盤時系統直接分配所有元資料並全部load到記憶體。
例如，同時申請100塊300G的雲盤，如果按1G分片，需要同時分配3W條元資料；如果按照1M分片，則需要同時分配3000W條元資料。
為了解決效能瓶頸，團隊採用放棄路由由中心元資料節點分配的方式。該方案中，Client 端和集群后端採用同樣的計算規則R（分片大小、pg個數、對映方法、衝突規則）；雲盤申請時，元資料節點利用計算規則四元組判斷容量是否滿足；雲盤掛載時，從元資料節點獲取計算規則四元組； IO時，按計算規則R（分片大小、pg個數、對映方法、衝突規則）計算出路路由元資料然後直接進行IO。通過這種改造方案，可以確保在1M資料分片的情況下，元資料的分配和掛載暢通無阻，並節省IO路徑上的消耗。
對NVME高效能儲存的支援
NVME充分利用 PCI-E 通道的低延時以及並行性極大的提升NAND固態硬碟的讀寫效能和降低時延，其效能百倍於HDD。目前常用的基於NAND的固態硬碟可支援超10W的寫IOPS、40-60W的讀IOPS以及1GB-3GB讀寫頻寬，為支援NVME，軟體上需要配套的優化設計。
首先，傳統架構採用單執行緒傳輸，單個執行緒寫 IOPS達6W，讀IOPS達8W，難以支援後端NVME硬碟幾十萬的IOPS以及1-2GB的頻寬。為了利用NVME磁碟的效能，需要將單執行緒傳輸改為多執行緒傳輸，系統定期上報執行緒CPU以及磁碟負載狀態，當滿足某執行緒持續繁忙、而有執行緒持續空閒情況時，可將選取部分磁碟分片的IO切換至空閒執行緒，目前5個執行緒可以完全發揮NVME的能力。
此外，在架構優化上，除了減少IO路徑層級以及更小分片外，UCloud在IO路徑上使用記憶體池、物件池，減少不停的new delete，同時儘量用陣列索引，減少查詢消耗，並避免字串比較以及無謂的拷貝，最終充分地發揮NVME磁碟效能。
議題二：灰度釋出在UCloud虛擬網路中的應用
第二個議題是由技術專家徐亮講解如何利用ServiceMesh技術在虛擬網路控制面以及利用可程式設計交換機在轉發面實現灰度釋出。
ServiceMesh實現控制麵灰度
在控制面，早期灰度釋出採用APIGW的方式實現。APIGW通常僅部署在使用者流量的入口，完全灰度釋出就需要完整地部署兩套系統。但在微服務化的時代，任何一個微服務發生變更都需要完整地部署兩套系統，這不僅成本高且嚴重影響產品變更速度。ServiceMesh以類似於將APIGateway部署到本地，同時提供集中化控制的方式，完美地解決了這些問題。
UCloud的輕量級ServiceMesh平臺基於Istio，繼續使用Envoy代理，修改Pilot在保留完整的DSL支援的基礎上實現了脫離K8S執行。
因此網路團隊對Pilot做了高度訂製，從而更能滿足自身的需求。
- 訂製方案一：按賬號灰度。在GRPC或者HTTP請求中新增⾃自定義Header x-ucloud-routeby，x-ucloud-routeby採用Cookie的編碼格式，在其中包含賬戶資訊，配置Envoy根據該Header進行策略路由。
- 訂製方案二：採用顯式代理而不是IPTables透明引流的方式和Envoy整合，支援HTTP 1.0、HTTP 2.0和gRPC。在配置了Envoy的Proxy Port情況下，通過Envoy接入ServiceMesh；如果配置域名且沒有配置Envoy的Proxy，則自動採用ETCD gRPC naming and discovery的方式； 如果配置IP地址和埠，則直連指定地址；
訂製方案三：採用docker-compose管理container實現sidecar。新方案中仍然採用container的方式打包和部署微服務，但採用Host的網路方式簡化了現存服務的網路通訊方式。通過採用docker-compose管理container實現sidecar，實現了一個簡單的服務管理、版本管理、叢集管理、路由策略管理層，為叢集中的每臺Node（VM或物理伺服器）生成docker-compose配置檔案，從而部署和管理每臺Node的服務。
可程式設計交換機實現轉發麵灰度
在轉發麵灰度的方案選擇上，團隊採用了可程式設計交換機（基於Barefoot Tofino晶片）來實現灰度閘道器，替換普通交換機實現強灰度能力。
灰度閘道器最大提供64個100G的介面提供6.4T頻寬，PPS效能可達4400兆，延遲為us級別，能夠很好支援網路寬頻的高效能要求。灰度閘道器可以提供：一致性雜湊ECMP的能力；可以基於任意定製欄位（包括內層虛擬網路地址以及租戶ID）計算雜湊；在計算雜湊前優先應用灰度規則，可以根據任意欄位定製灰度規則，最小粒度可以做到按TCP流來灰度。
轉發麵灰度示例
有了上述這些新工具，可以通過部署新的策略實現更加細粒的灰度釋出，具體方案為：可程式設計交換機BGP宣告叢集VIP引流，根據選擇欄位計算一致性雜湊後將流量量分發給後端伺服器，並按照選擇欄位（VNI、源地址、目的地址）配置灰度規則。
灰度步驟如下：
- 按VM的粒度將流量量切換到灰度後端伺服器器
- 切換完成後立刻自動迴歸測試，根據路由表自動生成監測地址列表，並Ping檢測網路互通性
- 測試通過則逐步增加灰度的VM地址
- 直到整個VPC的流量量全部切換到灰度後端伺服器器
- 再切換一個新的VPC，直到所有分片內的VPC都切換到新的灰度後端伺服器
- 完成灰度釋出
議題三：雲主機連續快照備份設計解析
最後是邱模炯總監介紹秒級自動連續快照的後臺設計細節。
OpenStack快照方案的不足
在早期的雲主機快照方案中，UCloud嘗試採用了OpenStack的internal snapshot和external snapshot兩種方案，也是KVM虛擬化自帶的快照方案，這兩種方案均比較複雜，難以符合雲平臺的需要。
內建快照（internal snapshot）是原始磁碟和快照耦合在同一個檔案，實現複雜，不方便進行快照的操作，此外這種方案不支援raw格式，合併麻煩， 對效能有較大影響。
外接快照（external snapshot）的快照檔案和原始磁碟檔案分離， 進行快照操作後，原始磁碟映像將處於“只讀”狀態，新的寫操作都會寫入到新的快照檔案中。這種快照方式解決了內建快照的大部分問題，也是目前KVM虛擬化主流快照方案。但是實現仍然複雜，對效能有影響。設想1000個快照的情況下對效能的影響， 快照的管理。
不管內建快照還是外接快照，都需要使用者理解較多快照原理才能操作，而且對源雲主機是有影響的，另外備份也受雲主機所在軟硬體環境的穩定性影響。考慮到這些方面，UCloud採用了完全不同的做法，重新設計了獨立的快照備份系統。
UCloud資料方舟快照方案
虛擬化層本身足夠複雜且使用麻煩，而緊耦合的設計無法在不影響源主機的前提下又能追求快速恢復和足夠細粒度的快照點 。複雜和緊耦合，是影響快照效能和體驗的根源。
資料方舟可以自動進行秒級連續快照，無需使用者觸發也無需使用者管理這些快照。恢復速度也足夠快，1T硬碟可以達到10分鐘級別。使用者無需理解複雜概念，運維也無需理解複雜的虛擬化。資料方舟背後的基本設計理念是，極簡體驗和異構解耦。
實時IO與異構解耦
為了免去使用者定期製作快照的繁瑣事項，讓資料可以恢復到任意一秒，UCloud通過記錄實時IO的方式，將虛擬機器所有的寫IO按順序的引入流方式，同步到資料方舟的備份叢集中，資料恢復時，再將這些IO流反推回來，恢復到本地盤或者雲盤裡面，實現備份叢集與本地盤的異構解耦。這種方案下快照對原有業務路徑侵入小，不影響源主機的執行，且備份獨立可靠，不受原有軟硬體約束，容易運維。
但是，秒級快照會造成較大的吞吐量，假如1000臺雲主機以10MB每秒的速度寫入1年，那麼將會產生近300P的資料量，這將產生大量的儲存量且幾乎無法恢復出快照盤。
海量隨機IO和巨大儲存量優化
UCloud通過IO合併以及 SSD扛住隨機IO，另外通過分層儲存和定期預合併的方式，來減少實時IO引來的儲存量。首先，將實時的IO用SSD記錄下來，但在真正的儲存硬碟中，將資料分成秒級、小時級、天級和基準資料。只由第一層去接納實時的IO流，下面四層做分層和合並。這樣儲存量理論上只跟雲主機盤的大小相關，成正比例的關係，而不是和雲主機產生IO的速度成比例關係。
快速恢復優化
儲存伺服器一般會採用特殊配置，每臺伺服器會配置12塊硬碟，12塊盤理論上的讀寫速度是單塊12倍，因此，可以將這些資料按磁碟定址範圍，進行分片，每個粒度的資料按分片分散式儲存於容量儲存層的叢集上。
那麼，在恢復快照結果的時候，就可以對前述秒/小時/天/base等各層資料的各自分片進行併發合併。通常恢復一個1T盤大小，在物理上多臺伺服器的幾十塊硬碟同時讀取，所以恢復速度很快，可以達到10分鐘級別。
恢復出來的快照結果需要轉存回業務儲存上，通常是雲盤叢集和本地盤。
- 對於雲盤叢集，由於雲盤也是分片的，可以把資料方舟的分片併發寫到雲盤叢集，極大降低快照結果寫入雲盤的耗時。對於本地盤，無法利用分散式叢集的能力，本地盤則採用了copy on read模式，無需整個快照結果寫完就可以啟動雲主機。
以上就是Tech Talk第一期的內容回顧。Tech Talk後面也會繼續舉辦，歡迎參加。
Post Views: 3
*本平臺所釋出文章資訊，版權歸UCloud所有，如需轉載請註明出處！
0
ofollow,noindex" target="_blank">檢視TA的所有文章