云計算的挑戰(zhàn)與需求
云計算跟淘寶在業(yè)務特點上有較大的不同，其中最大的不同就在于：淘寶、天貓是由四千多個小應用去支持的，都是分布式設計，很多情況下即使一兩個應用宕機了，也不影響整體的服務，可以按部就班的修復。對于淘寶而言，只有交易量下降了10%以上的情況會算做是P1故障，開始計算全站不可用的時間。
而對于云計算的場景而言，一個云主機宕機了，對這個客戶來說就是100%的不可用，而這可能是這個客戶的全部“身家性命”。所以，云計算平臺對可靠性、穩(wěn)定性的需求是非常高的。以前我們可能網絡遇到問題，但是上層應用設計得好，就把這個問題隱蔽掉了；而對于云平臺，要求是更高的可靠性，而且數據不能丟，系統穩(wěn)定，性能還要好——目前盡量跟用戶自己買物理機的性能差不多，另外要能夠快速定位問題，最好在用戶發(fā)現問題之前就先把問題解決了，讓用戶感知不到。還有就是成本要低，比用戶自己買服務器便宜是底線。
ECS的分布式存儲設計
ECS是阿里云的云服務器產品線，也是我們銷量最大的產品。其背后是分布式文件存儲，支持快照制作、快照回滾、自定義鏡像、故障遷移、網絡組隔離、防攻擊、動態(tài)升級等功能。ECS的管理基于一個龐大的控制系統，目前一個控制系統可以控制3600臺物理機的規(guī)模，未來計劃要做到5000臺到兩萬臺。
這其中，數據可靠性是極為關鍵的。阿里云以前的做法是數據寫入的時候同步寫三份到分布式存儲上的chunk server上之后才算成功，這種實現的開銷大，延時長，造成當時阿里云的用戶抱怨性能不好。后來，我們做了2-3異步，即同步寫2份確保成功，異步寫第三份，IO性能上得到一定的改善。我們現在對這個過程再做優(yōu)化：讀寫性能優(yōu)化的關鍵在于返回成功的時間，因為吞吐率是時間的倒數，延時縮短性能就會提升。縮短延時的思路之一就是將原本過長的路程截斷以進行縮短，同時保證數據的可靠性。其具體思路為：
• SSD+SATA的混合存儲方案，在chunk server上做二級存儲。這個方案目前在vm上做到的randwrite-4K-128可達5500 IOPS左右
• cache機制
• 以多線程事件驅動架構重構TDC和Chunk Server的實現，做到一個IO請求在物理機上只用一個線程完成所有工作，避免鎖和上下文切換
下面詳細介紹一下這幾個機制的設計。
IO路徑上的各層cache與寫IO的幾種模式探索
從應用發(fā)出請求到數據寫入磁盤的路徑上有三層cache，依次是應用程序的user cache(如MySQL buffer pool)、操作系統的緩存(如Linux page cache)、以及存儲硬件的cache(如磁盤的緩存)。
由此可以引申出如下幾種寫IO的模式：
• buffer write，寫入目標是guest OS的page cache，通過writeback刷到硬盤的緩存，然后再通過自動刷或者sync命令觸發(fā)的方式刷到持久化存儲介質上。這種寫方案的速度很快，缺點是數據完整性無法得到嚴密保證(取決于回寫的策略)，而且回寫有可能引起阻塞而影響服務質量
• direct write，從應用直接寫到硬件上的緩存，繞過操作系統的page cache。比如MySQL引擎自己有緩存機制，就可以使用direct write寫到硬盤緩存然后再通過sync命令刷到下面的存儲介質。繞過page cache的好處是避開了回寫的影響，但數據仍然不是絕對可靠，sync完畢之前數據仍然是不安全的
• write+sync，寫入page cache的同時即調用sync/fsync直接寫到存儲介質，sync返回算成功。此方式的好處是數據足夠安全，缺點是慢，具體等待時間隨著操作系統內存使用情況的不同而不同
• O_SYNC，加了此標簽的寫入操作會在數據寫入硬盤緩存時同步刷到碟片上
以上就是系統提供的幾種機制。以本地SAS盤作為參考，在虛擬機中以4k的塊大小做dd的寫入速度，buffer write平均在212MB/s，direct write平均在68MB/s，而direct+sync則平均在257kB/s。實際應用中可以根據不同情況、不同應用選擇不同的方式，一般來說 buffer write和direct write是主流，兩者加起來占據了97%的寫操作。
云計算環(huán)境中的IO
以上分析的是本地的情況，寫入的目標是本地的硬盤緩存與存儲介質。那么在云計算環(huán)境中，我們不僅可以選擇本地，還可以有分布式存儲。分布式存儲相當于本地的存儲介質，我們目前的思路是在其上加一層分布式緩存系統作為本地硬盤緩存的替代。相當于整個寫IO路徑在云計算環(huán)境中變成了：
VM SYNC->PV前端FLUSH->后端->host->cache系統->分布式存儲系統
為了確保數據完整性，我們的語義全部符合POSIX，將語義由以上路徑從VM透傳IO全鏈路。
cache系統的效果
我們用以下指令對ECS的寫性能進行測試：
./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，抖動幅度(標準方差)達到7ms。
加入SSD cache系統之后，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. 降低分布式存儲系統的抖動對上層應用的影響。這種抖動在高并發(fā)的情況對延時的影響相當大，Google的Jeff Dean于2013年2月發(fā)表于CACM上的The Tail at Scale一文詳細描述了這個影響：“如果有1%的概率請求延遲超過1S，并發(fā)100個請求，然后等待所有請求返回，延時超過1S的概率為63%”
ECS不同的存儲選擇
目前在ECS上可以有幾種實例選擇：背后是純SATA存儲集群的實例，適合大部分應用；對于IO性能要求更高的應用可以選擇混合存儲集群；我們未來還會推出性能更高的純SSD集群，預計將在11月/12月推出，目前的測試數據是物理機chunk server可以做到最高18萬的iops，虛機上可以把萬兆跑滿，iops在9萬左右，目前的問題就是跑滿的狀態(tài)需要消耗6顆HT CPU，這一部分還有待優(yōu)化。
另外，對于Hadoop、HBase、MongoDB這樣本身已經考慮了3副本的系統，阿里云還提供了SATA本地磁盤和SSD本地磁盤的ECS，減少不必要的冗余以降低成本。
以上就是我們對云服務器產品ECS的一些優(yōu)化工作。云服務器理論上可以用來跑任何東西，但是通用的方案不適合做所有的事情。因此，阿里云同時提供了一些細分產品，在特定應用場景下將取舍做到極致。
SLB、RDS與OCS的設計
SLB是阿里云的負載均衡產品，提供了4層的(基于LVS)和7層的(基于Tengine)，支持等價路由和Anycast跨機房容災，同時具備防攻擊的特性。一臺12物理核機器的SLB的正常轉發(fā)性能在1200萬左右的pps，心跳可以做幾千臺；而同等配置的ECS(千兆網絡)的轉發(fā)性能只有70 萬左右的pps，心跳也只能做兩臺。
RDS是阿里云的數據庫服務，跑在物理機上(而非虛擬機)。RDS數據通道采用標準的三層架構，每層都做到機房和部件冗余，無狀態(tài)設計；中間層提供了安全防護、流量調度和橋接的功能，管理通道以元數據庫(MySQL)為中心，消息驅動，各組件異步通信，無狀態(tài)支持熱升級，一個控制系統下可以管理數萬個MySQL實例。RDS依賴于很多其他團隊開發(fā)的組件，包括用SLB做負載均衡，接ODPS做過濾分析，SLS做日志收集，OSS做備份，OAS做冷數據的備份，用精衛(wèi)做分表，以及全鏈路的控制系統和組件監(jiān)控。同等配置下，RDS的tps要比ECS高兩、三倍。
OCS是阿里云的緩存服務，基于Tair搭建，前面的Proxy負責了安全訪問控制、QoS、流控的工作。OCS目前是一個集群都在一個機房，可隨時擴容，對用戶提供了全面的監(jiān)控數據和圖形展示。性能方面，OCS上目前99%的請求都做到了2ms以內響應，去年雙十一，整個OCS集群的能力做到了一秒內可處理一億個請求。同等配置下，OCS的成本要比ECS上自建Memcached便宜一半。
全鏈路監(jiān)控與分析系統
監(jiān)控分析系統目前在RDS上用的比較重。坦白講去年RDS遇到很多問題，很大一部分問題就是閃斷：背后的機器故障時，MySQL實例會遷移，這時候如果客戶端的應用做得好，應用會自動發(fā)起重連的請求，保持原先的連接，但很多應用做的時候并沒有考慮這個問題。那時候很多游戲廠商遇到這個問題，讓他們改程序也很困難，不可能一個一個幫助他們優(yōu)化，所以就需要后端幫他們的實例做保持連接和重連的工作。
所以我們建立起全鏈路的監(jiān)控，收集所有的SQL日志、網絡行為和用戶行為，注入到一個Kafka集群，然后用JStorm和Spark做實時分析，ODPS做離線分析。目前每天的SQL日志語句的量級在幾十個T，可以在秒級發(fā)現問題，比如發(fā)現請求慢了，則會給用戶提醒是否沒有建索引，而網絡異常、連接中斷的情況則會及時報警。
目前這套系統先用在RDS上，未來各個云產品需要將自己的異常分析都抽象出來注入到這個系統當中，完成全產品線的全鏈路監(jiān)控。
未來工作展望
首先，ECS上全路徑IO還需要持續(xù)優(yōu)化，力求在全國、全球做到最好的性能。這涉及到Cache策略的優(yōu)化，帶SSD的讀寫緩存，存儲與計算分離，萬兆純SSD集群，動態(tài)熱點遷移技術，GPU支持，LXC/cgroups支持等。比如純SSD的集群，iops已經挖掘的很高的情況，如何降低CPU消耗?Cache現在為了快速，往下刷的頻率是比較高的，這方面的策略能否優(yōu)化，做批量刷?以前部署的SATA集群，是否都加上SSD緩存?如果本地緩存的命中率在90%以上，是否可以做計算節(jié)點和存儲節(jié)點分離，這樣可以讓計算和存儲按自己的需求發(fā)展。未來實現動態(tài)的熱點遷移，可以在云計算上要實現更高的超配，當一臺物理機發(fā)生比較忙的情況下，系統能自動將一些實例遷移到比較閑的機器上。目前淘寶的聚石塔、阿里小貸都已經在阿里云，未來會將淘寶無縫遷移到云平臺上并降低成本，這些都是ECS上未來需要做的工作。
RDS方面，目前支持MySQL和SQL Server，計劃加入PostgreSQL以方便Oracle用戶往這邊遷移。容災方面，目前是雙機房容災，成本還比較高，是否可以通過非常高速的非易失性網絡存儲來存儲redo log，容量不需要大，數據存儲在分布式文件系統，做一個低成本的RDS方案，只是用戶需要容忍幾十秒的MySQL實例宕機重啟的時間?這需要架構師做取舍，看我們要放棄一些什么以得到一些東西。
另外，全鏈路的監(jiān)控與分析系統，我們也需要進一步應用到全線云產品之上。未來還會推出更多的云產品，包括無線網絡加速、 AliBench服務質量監(jiān)測(目前在內部使用)、OCR識別服務、深度學習的CNN/DNN計算服務等。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.ezxoed.cn/
本文網址：http://www.ezxoed.cn/html/consultation/10839716447.html
相關文章
