阿里云：構(gòu)建大型云計算平臺分布式技術(shù)的實踐

　　云計算的挑戰(zhàn)與需求

　　云計算跟淘寶在業(yè)務(wù)特點上有較大的不同，其中最大的不同就在于：淘寶、天貓是由四千多個小應(yīng)用去支持的，都是分布式設(shè)計，很多情況下即使一兩個應(yīng)用宕機(jī)了，也不影響整體的服務(wù)，可以按部就班的修復(fù)。對于淘寶而言，只有交易量下降了10%以上的情況會算做是P1故障，開始計算全站不可用的時間。

　　而對于云計算的場景而言，一個云主機(jī)宕機(jī)了，對這個客戶來說就是100%的不可用，而這可能是這個客戶的全部“身家性命”。所以，云計算平臺對可靠性、穩(wěn)定性的需求是非常高的。以前我們可能網(wǎng)絡(luò)遇到問題，但是上層應(yīng)用設(shè)計得好，就把這個問題隱蔽掉了；而對于云平臺，要求是更高的可靠性，而且數(shù)據(jù)不能丟，系統(tǒng)穩(wěn)定，性能還要好——目前盡量跟用戶自己買物理機(jī)的性能差不多，另外要能夠快速定位問題，最好在用戶發(fā)現(xiàn)問題之前就先把問題解決了，讓用戶感知不到。還有就是成本要低，比用戶自己買服務(wù)器便宜是底線。

　　ECS的分布式存儲設(shè)計

　　ECS是阿里云的云服務(wù)器產(chǎn)品線，也是我們銷量最大的產(chǎn)品。其背后是分布式文件存儲，支持快照制作、快照回滾、自定義鏡像、故障遷移、網(wǎng)絡(luò)組隔離、防攻擊、動態(tài)升級等功能。ECS的管理基于一個龐大的控制系統(tǒng)，目前一個控制系統(tǒng)可以控制3600臺物理機(jī)的規(guī)模，未來計劃要做到5000臺到兩萬臺。

　　這其中，數(shù)據(jù)可靠性是極為關(guān)鍵的。阿里云以前的做法是數(shù)據(jù)寫入的時候同步寫三份到分布式存儲上的chunk server上之后才算成功，這種實現(xiàn)的開銷大，延時長，造成當(dāng)時阿里云的用戶抱怨性能不好。后來，我們做了2-3異步，即同步寫2份確保成功，異步寫第三份，IO性能上得到一定的改善。我們現(xiàn)在對這個過程再做優(yōu)化：讀寫性能優(yōu)化的關(guān)鍵在于返回成功的時間，因為吞吐率是時間的倒數(shù)，延時縮短性能就會提升。縮短延時的思路之一就是將原本過長的路程截斷以進(jìn)行縮短，同時保證數(shù)據(jù)的可靠性。其具體思路為：

　　• SSD+SATA的混合存儲方案，在chunk server上做二級存儲。這個方案目前在vm上做到的randwrite-4K-128可達(dá)5500 IOPS左右

　　• cache機(jī)制

　　• 以多線程事件驅(qū)動架構(gòu)重構(gòu)TDC和Chunk Server的實現(xiàn)，做到一個IO請求在物理機(jī)上只用一個線程完成所有工作，避免鎖和上下文切換

　　下面詳細(xì)介紹一下這幾個機(jī)制的設(shè)計。

　　IO路徑上的各層cache與寫IO的幾種模式探索

　　從應(yīng)用發(fā)出請求到數(shù)據(jù)寫入磁盤的路徑上有三層cache，依次是應(yīng)用程序的user cache(如MySQL buffer pool)、操作系統(tǒng)的緩存(如Linux page cache)、以及存儲硬件的cache(如磁盤的緩存)。

　　由此可以引申出如下幾種寫IO的模式：

　　• buffer write，寫入目標(biāo)是guest OS的page cache，通過writeback刷到硬盤的緩存，然后再通過自動刷或者sync命令觸發(fā)的方式刷到持久化存儲介質(zhì)上。這種寫方案的速度很快，缺點是數(shù)據(jù)完整性無法得到嚴(yán)密保證(取決于回寫的策略)，而且回寫有可能引起阻塞而影響服務(wù)質(zhì)量

　　• direct write，從應(yīng)用直接寫到硬件上的緩存，繞過操作系統(tǒng)的page cache。比如MySQL引擎自己有緩存機(jī)制，就可以使用direct write寫到硬盤緩存然后再通過sync命令刷到下面的存儲介質(zhì)。繞過page cache的好處是避開了回寫的影響，但數(shù)據(jù)仍然不是絕對可靠，sync完畢之前數(shù)據(jù)仍然是不安全的

　　• write+sync，寫入page cache的同時即調(diào)用sync/fsync直接寫到存儲介質(zhì)，sync返回算成功。此方式的好處是數(shù)據(jù)足夠安全，缺點是慢，具體等待時間隨著操作系統(tǒng)內(nèi)存使用情況的不同而不同

　　• O_SYNC，加了此標(biāo)簽的寫入操作會在數(shù)據(jù)寫入硬盤緩存時同步刷到碟片上

　　以上就是系統(tǒng)提供的幾種機(jī)制。以本地SAS盤作為參考，在虛擬機(jī)中以4k的塊大小做dd的寫入速度，buffer write平均在212MB/s，direct write平均在68MB/s，而direct+sync則平均在257kB/s。實際應(yīng)用中可以根據(jù)不同情況、不同應(yīng)用選擇不同的方式，一般來說 buffer write和direct write是主流，兩者加起來占據(jù)了97%的寫操作。

　　云計算環(huán)境中的IO

　　以上分析的是本地的情況，寫入的目標(biāo)是本地的硬盤緩存與存儲介質(zhì)。那么在云計算環(huán)境中，我們不僅可以選擇本地，還可以有分布式存儲。分布式存儲相當(dāng)于本地的存儲介質(zhì)，我們目前的思路是在其上加一層分布式緩存系統(tǒng)作為本地硬盤緩存的替代。相當(dāng)于整個寫IO路徑在云計算環(huán)境中變成了：

　　VM SYNC->PV前端FLUSH->后端->host->cache系統(tǒng)->分布式存儲系統(tǒng)

　　為了確保數(shù)據(jù)完整性，我們的語義全部符合POSIX，將語義由以上路徑從VM透傳IO全鏈路。

　　cache系統(tǒng)的效果

　　我們用以下指令對ECS的寫性能進(jìn)行測試：

　　./fio -direct=1 -iodepth=1 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G

　　在iodepth=1的狀態(tài)，純SATA分布式存儲只有200左右的iops，平均延時在8ms，抖動幅度(標(biāo)準(zhǔn)方差)達(dá)到7ms。

　　加入SSD cache系統(tǒng)之后，iops提升到600左右，平均延時降低到3ms，抖動幅度降低至2ms左右。

　　./fio -direct=1 -iodepth=8 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G

　　增加iodepth到8的狀態(tài)，純SATA分布式存儲的iops提升至2100左右，平均延時在7ms，抖動幅度依然是7ms左右。

　　加入SSD cache之后，iops提升到2900左右，平均延時在5ms左右，抖動幅度約為1ms。

　　以上是cache方案的兩點好處：

　　1. 加速寫請求。未來我們也會加入對讀請求的加速

　　2. 降低分布式存儲系統(tǒng)的抖動對上層應(yīng)用的影響。這種抖動在高并發(fā)的情況對延時的影響相當(dāng)大，Google的Jeff Dean于2013年2月發(fā)表于CACM上的The Tail at Scale一文詳細(xì)描述了這個影響：“如果有1%的概率請求延遲超過1S，并發(fā)100個請求，然后等待所有請求返回，延時超過1S的概率為63%”

　　ECS不同的存儲選擇

　　目前在ECS上可以有幾種實例選擇：背后是純SATA存儲集群的實例，適合大部分應(yīng)用；對于IO性能要求更高的應(yīng)用可以選擇混合存儲集群；我們未來還會推出性能更高的純SSD集群，預(yù)計將在11月/12月推出，目前的測試數(shù)據(jù)是物理機(jī)chunk server可以做到最高18萬的iops，虛機(jī)上可以把萬兆跑滿，iops在9萬左右，目前的問題就是跑滿的狀態(tài)需要消耗6顆HT CPU，這一部分還有待優(yōu)化。

　　另外，對于Hadoop、HBase、MongoDB這樣本身已經(jīng)考慮了3副本的系統(tǒng)，阿里云還提供了SATA本地磁盤和SSD本地磁盤的ECS，減少不必要的冗余以降低成本。

　　以上就是我們對云服務(wù)器產(chǎn)品ECS的一些優(yōu)化工作。云服務(wù)器理論上可以用來跑任何東西，但是通用的方案不適合做所有的事情。因此，阿里云同時提供了一些細(xì)分產(chǎn)品，在特定應(yīng)用場景下將取舍做到極致。

　　SLB、RDS與OCS的設(shè)計

　　SLB是阿里云的負(fù)載均衡產(chǎn)品，提供了4層的(基于LVS)和7層的(基于Tengine)，支持等價路由和Anycast跨機(jī)房容災(zāi)，同時具備防攻擊的特性。一臺12物理核機(jī)器的SLB的正常轉(zhuǎn)發(fā)性能在1200萬左右的pps，心跳可以做幾千臺；而同等配置的ECS(千兆網(wǎng)絡(luò))的轉(zhuǎn)發(fā)性能只有70 萬左右的pps，心跳也只能做兩臺。

　　RDS是阿里云的數(shù)據(jù)庫服務(wù)，跑在物理機(jī)上(而非虛擬機(jī))。RDS數(shù)據(jù)通道采用標(biāo)準(zhǔn)的三層架構(gòu)，每層都做到機(jī)房和部件冗余，無狀態(tài)設(shè)計；中間層提供了安全防護(hù)、流量調(diào)度和橋接的功能，管理通道以元數(shù)據(jù)庫(MySQL)為中心，消息驅(qū)動，各組件異步通信，無狀態(tài)支持熱升級，一個控制系統(tǒng)下可以管理數(shù)萬個MySQL實例。RDS依賴于很多其他團(tuán)隊開發(fā)的組件，包括用SLB做負(fù)載均衡，接ODPS做過濾分析，SLS做日志收集，OSS做備份，OAS做冷數(shù)據(jù)的備份，用精衛(wèi)做分表，以及全鏈路的控制系統(tǒng)和組件監(jiān)控。同等配置下，RDS的tps要比ECS高兩、三倍。

　　OCS是阿里云的緩存服務(wù)，基于Tair搭建，前面的Proxy負(fù)責(zé)了安全訪問控制、QoS、流控的工作。OCS目前是一個集群都在一個機(jī)房，可隨時擴(kuò)容，對用戶提供了全面的監(jiān)控數(shù)據(jù)和圖形展示。性能方面，OCS上目前99%的請求都做到了2ms以內(nèi)響應(yīng)，去年雙十一，整個OCS集群的能力做到了一秒內(nèi)可處理一億個請求。同等配置下，OCS的成本要比ECS上自建Memcached便宜一半。

　　全鏈路監(jiān)控與分析系統(tǒng)

　　監(jiān)控分析系統(tǒng)目前在RDS上用的比較重。坦白講去年RDS遇到很多問題，很大一部分問題就是閃斷：背后的機(jī)器故障時，MySQL實例會遷移，這時候如果客戶端的應(yīng)用做得好，應(yīng)用會自動發(fā)起重連的請求，保持原先的連接，但很多應(yīng)用做的時候并沒有考慮這個問題。那時候很多游戲廠商遇到這個問題，讓他們改程序也很困難，不可能一個一個幫助他們優(yōu)化，所以就需要后端幫他們的實例做保持連接和重連的工作。

　　所以我們建立起全鏈路的監(jiān)控，收集所有的SQL日志、網(wǎng)絡(luò)行為和用戶行為，注入到一個Kafka集群，然后用JStorm和Spark做實時分析，ODPS做離線分析。目前每天的SQL日志語句的量級在幾十個T，可以在秒級發(fā)現(xiàn)問題，比如發(fā)現(xiàn)請求慢了，則會給用戶提醒是否沒有建索引，而網(wǎng)絡(luò)異常、連接中斷的情況則會及時報警。

　　目前這套系統(tǒng)先用在RDS上，未來各個云產(chǎn)品需要將自己的異常分析都抽象出來注入到這個系統(tǒng)當(dāng)中，完成全產(chǎn)品線的全鏈路監(jiān)控。

　　未來工作展望

　　首先，ECS上全路徑IO還需要持續(xù)優(yōu)化，力求在全國、全球做到最好的性能。這涉及到Cache策略的優(yōu)化，帶SSD的讀寫緩存，存儲與計算分離，萬兆純SSD集群，動態(tài)熱點遷移技術(shù)，GPU支持，LXC/cgroups支持等。比如純SSD的集群，iops已經(jīng)挖掘的很高的情況，如何降低CPU消耗?Cache現(xiàn)在為了快速，往下刷的頻率是比較高的，這方面的策略能否優(yōu)化，做批量刷?以前部署的SATA集群，是否都加上SSD緩存?如果本地緩存的命中率在90%以上，是否可以做計算節(jié)點和存儲節(jié)點分離，這樣可以讓計算和存儲按自己的需求發(fā)展。未來實現(xiàn)動態(tài)的熱點遷移，可以在云計算上要實現(xiàn)更高的超配，當(dāng)一臺物理機(jī)發(fā)生比較忙的情況下，系統(tǒng)能自動將一些實例遷移到比較閑的機(jī)器上。目前淘寶的聚石塔、阿里小貸都已經(jīng)在阿里云，未來會將淘寶無縫遷移到云平臺上并降低成本，這些都是ECS上未來需要做的工作。

　　RDS方面，目前支持MySQL和SQL Server，計劃加入PostgreSQL以方便Oracle用戶往這邊遷移。容災(zāi)方面，目前是雙機(jī)房容災(zāi)，成本還比較高，是否可以通過非常高速的非易失性網(wǎng)絡(luò)存儲來存儲redo log，容量不需要大，數(shù)據(jù)存儲在分布式文件系統(tǒng)，做一個低成本的RDS方案，只是用戶需要容忍幾十秒的MySQL實例宕機(jī)重啟的時間?這需要架構(gòu)師做取舍，看我們要放棄一些什么以得到一些東西。

　　另外，全鏈路的監(jiān)控與分析系統(tǒng)，我們也需要進(jìn)一步應(yīng)用到全線云產(chǎn)品之上。未來還會推出更多的云產(chǎn)品，包括無線網(wǎng)絡(luò)加速、 AliBench服務(wù)質(zhì)量監(jiān)測(目前在內(nèi)部使用)、OCR識別服務(wù)、深度學(xué)習(xí)的CNN/DNN計算服務(wù)等。 

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/

本文標(biāo)題：阿里云：構(gòu)建大型云計算平臺分布式技術(shù)的實踐

本文網(wǎng)址：http://m.hanmeixuan.com/html/consultation/10839716447.html