構建大型雲計算平臺分佈式技術的實踐

構建大型雲計算平臺分佈式技術的實踐 做者 章文嵩 發佈於 2014年7月23日 | 本文基於章文嵩博士在2014年7月18日的全球架構師峯會ArchSummit上的主題演講《構建大型雲計算平臺分佈式技術的實踐》整理而成。 演講者簡介 章文嵩博士是阿里集團的高級研究員與副總裁，主要負責基礎核心軟件研發和雲計算產品研發、推動網絡軟硬件方面的性能優化、搭建下一代高可擴展低碳低成本電子商務基礎設施。他也是開放源碼及Linux內核的開發者，著名的Linux集羣項目LVS（Linux Virtual Server）的創始人和主要開發人員。LVS集羣代碼已在Linux 2.4和 2.6的官方內核中，保守估計全世界有幾萬套LVS集羣系統在運行着，創造了近十億美金的價值。加入阿里前，他是 TelTel的首席科學家與聯合創始人，曾爲國防科技大學計算機學院副教授。他在設計和架構大型系統、Linux操做系統、系統軟件開發、系統安全和軟件開發管理上有着豐富的經驗。章文嵩博士在2009年加入阿里以後，前後負責淘寶的核心繫統研發與阿里巴巴集團的基礎研發，2013年10月開始同時負責阿里雲的系統研發與阿里巴巴集團的基礎研發工做。 本演講主要分爲五個部分： 1.  雲計算的挑戰與需求 2.  ECS的分佈式存儲設計 3.  SLB、RDS與OCS的設計 4.  全鏈路監控與分析系統 5.  將來工做展望 雲計算的挑戰與需求 雲計算跟淘寶在業務特色上有較大的不一樣，其中最大的不一樣就在於：淘寶、天貓是由四千多個小應用去支持的，都是分佈式設計，不少狀況下即便一兩個應用宕機了，也不影響總體的服務，能夠循序漸進的修復。對於淘寶而言，只有交易量降低了10%以上的狀況會算作是P1故障，開始計算全站不可用的時間。 而對於雲計算的場景而言，一個雲主機宕機了，對這個客戶來講就是100%的不可用，而這多是這個客戶的所有「身家性命」。因此，雲計算平臺對可靠性、穩定性的需求是很是高的。之前咱們可能網絡遇到問題，可是上層應用設計得好，就把這個問題隱蔽掉了；而對於雲平臺，要求是更高的可靠性，並且數據不能丟，系統穩定，性能還要好——目前儘可能跟用戶本身買物理機的性能差很少，另外要可以快速定位問題，最好在用戶發現問題以前就先把問題解決了，讓用戶感知不到。還有就是成本要低，比用戶本身買服務器便宜是底線。 ECS的分佈式存儲設計 ECS是阿里雲的雲服務器產品線，也是咱們銷量最大的產品。其背後是分佈式文件存儲，支持快照製做、快照回滾、自定義鏡像、故障遷移、網絡組隔離、防攻擊、動態升級等功能。ECS的管理基於一個龐大的控制系統，目前一個控制系統能夠控制3600臺物理機的規模，將來計劃要作到5000臺到兩萬臺。 這其中，數據可靠性是極爲關鍵的。阿里雲之前的作法是數據寫入的時候同步寫三份到分佈式存儲上的chunk server上以後纔算成功，這種實現的開銷大，延時長，形成當時阿里雲的用戶抱怨性能很差。後來，咱們作了2-3異步，即同步寫2份確保成功，異步寫第三份，IO性能上獲得必定的改善。咱們如今對這個過程再作優化：讀寫性能優化的關鍵在於返回成功的時間，由於吞吐率是時間的倒數，延時縮短性能就會提高。縮短延時的思路之一就是將本來過長的路程截斷以進行縮短，同時保證數據的可靠性。其具體思路爲： ·         SSD+SATA的混合存儲方案，寫入的時候在本地的兩個SSD上作同步寫，第三份異步的同步到後面的chunk server上。這個方案作到的randwrite-4K-128可達5500 IOPS左右 ·         cache機制 ·         以多線程事件驅動架構重構TDC和Chunk Server的實現，作到一個IO請求在物理機上只用一個線程完成全部工做，避免鎖和上下文切換 下面詳細介紹一下這幾個機制的設計。 IO路徑上的各層cache與寫IO的幾種模式探索 從應用發出請求到數據寫入磁盤的路徑上有三層cache，依次是應用程序的user cache（如MySQL buffer pool）、操做系統的緩存（如Linux page cache）、以及存儲硬件的cache（如磁盤的緩存）。 由此能夠引伸出以下幾種寫IO的模式： ·         buffer write，寫入目標是guest OS的page cache，經過writeback刷到硬盤的緩存，而後再經過自動刷或者sync命令觸發的方式刷到持久化存儲介質上。這種寫方案的速度很快，缺點是數據完整性沒法獲得嚴密保證（取決於回寫的策略），並且回寫有可能引發阻塞而影響服務質量 ·         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%的寫操做。 雲計算環境中的IO 以上分析的是本地的狀況，寫入的目標是本地的硬盤緩存與存儲介質。那麼在雲計算環境中，咱們不只能夠選擇本地，還能夠有分佈式存儲。分佈式存儲至關於本地的存儲介質，咱們目前的思路是在其上加一層分佈式緩存系統做爲本地硬盤緩存的替代。至關於整個寫IO路徑在雲計算環境中變成了： 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的狀態，純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的狀態，純SATA分佈式存儲的iops提高至2100左右，平均延時在7ms，抖動幅度依然是7ms左右。 加入SSD cache以後，iops提高到2900左右，平均延時在5ms左右，抖動幅度約爲1ms。 以上是cache方案的兩點好處： 1.  加速寫請求。將來咱們也會加入對讀請求的加速 2.  下降分佈式存儲系統的抖動對上層應用的影響。這種抖動在高併發的狀況對延時的影響至關大，Google的Jeff Dean於2013年2月發表於CACM上的The Tail at Scale一文詳細描述了這個影響：「若是有1%的機率請求延遲超過1S，併發100個請求，而後等待全部請求返回，延時超過1S的機率爲63%」 ECS不一樣的存儲選擇 目前在ECS上能夠有幾種實例選擇：背後是純SATA存儲集羣的實例，適合大部分應用；對於IO性能要求更高的應用能夠選擇混合存儲集羣；咱們將來還會推出性能更高的純SSD集羣，預計將在11月/12月推出，目前的測試數據是物理機chunk server能夠作到最高18萬的iops，虛機上能夠把萬兆跑滿，iops在9萬左右，目前的問題就是跑滿的狀態須要消耗6顆HT CPU，這一部分還有待優化。 另外，對於Hadoop、HBase、MongoDB這樣自己已經考慮了3副本的系統，阿里雲還提供了SATA本地磁盤和SSD本地磁盤的ECS，減小沒必要要的冗餘以下降成本。 以上就是咱們對雲服務器產品ECS的一些優化工做。雲服務器理論上能夠用來跑任何東西，可是通用的方案不適合作全部的事情。所以，阿里雲同時提供了一些細分產品，在特定應用場景下將取捨作到極致—— SLB、RDS與OCS SLB是阿里雲的負載均衡產品，提供了4層的（基於LVS）和7層的（基於Tengine），支持等價路由和Anycast跨機房容災，同時具有防攻擊的特性。一臺12物理核機器的SLB的正常轉發性能在1200萬左右的pps，心跳能夠作幾千臺；而同等配置的ECS（千兆網絡）的轉發性能只有70萬左右的pps，心跳也只能作兩臺。 RDS是阿里雲的數據庫服務，跑在物理機上（而非虛擬機）。RDS數據通道採用標準的三層架構，每層都作到機房和部件冗餘，無狀態設計；中間層提供了安全防禦、流量調度和橋接的功能，管理通道以元數據庫（MySQL）爲中心，消息驅動，各組件異步通訊，無狀態支持熱升級，一個控制系統下能夠管理數萬個MySQL實例。RDS依賴於不少其餘團隊開發的組件，包括用SLB作負載均衡，接ODPS作過濾分析，SLS作日誌收集，OSS作備份，OAS作冷數據的備份，用精衛作分表，以及全鏈路的控制系統和組件監控。同等配置下，RDS的tps要比ECS高兩、三倍。 OCS是阿里雲的緩存服務，基於Tair搭建，前面的Proxy負責了安全訪問控制、QoS、流控的工做。OCS目前是一個集羣都在一個機房，可隨時擴容，對用戶提供了全面的監控數據和圖形展現。性能方面，OCS上目前99%的請求都作到了2ms之內響應，去年雙十一，整個OCS集羣的能力作到了一秒內可處理一億個請求。同等配置下，OCS的成本要比ECS上自建Memcached便宜一半。 全鏈路監控與分析系統 監控分析系統目前在RDS上用的比較重。坦白講去年RDS遇到不少問題，很大一部分問題就是閃斷：背後的機器故障時，MySQL實例會遷移，這時候若是客戶端的應用作得好，應用會自動發起重連的請求，保持原先的鏈接，但不少應用作的時候並無考慮這個問題。那時候不少遊戲廠商遇到這個問題，讓他們改程序也很困難，不可能一個一個幫助他們優化，因此就須要後端幫他們的實例作保持鏈接和重連的工做。 因此咱們創建起全鏈路的監控，收集全部的SQL日誌、網絡行爲和用戶行爲，注入到一個Kafka集羣，而後用JStorm和Spark作實時分析，ODPS作離線分析。目前天天的SQL日誌語句的量級在幾十個T，能夠在秒級發現問題，好比發現請求慢了，則會給用戶提醒是否沒有建索引，而網絡異常、鏈接中斷的狀況則會及時報警。 目前這套系統先用在RDS上，將來各個雲產品須要將本身的異常分析都抽象出來注入到這個系統當中，完成全產品線的全鏈路監控。 將來工做展望 首先，ECS上全路徑IO還須要持續優化，力求在全國、全球作到最好的性能。這涉及到Cache策略的優化，帶SSD的讀寫緩存，存儲與計算分離，萬兆純SSD集羣，動態熱點遷移技術，GPU支持，LXC/cgroups支持等。好比純SSD的集羣，iops已經挖掘的很高的狀況，如何下降CPU消耗？Cache如今爲了快速，往下刷的頻率是比較高的，這方面的策略可否優化，作批量刷？之前部署的SATA集羣，是否都加上SSD緩存？若是本地緩存的命中率在90%以上，是否能夠作計算節點和存儲節點分離，這樣可讓計算和存儲按本身的需求發展。將來實現動態的熱點遷移，能夠在雲計算上要實現更高的超配，當一臺物理機發生比較忙的狀況下，系統能自動將一些實例遷移到比較閒的機器上。目前淘寶的聚石塔、阿里小貸都已經在阿里雲，將來會將淘寶無縫遷移到雲平臺上並下降成本，這些都是ECS上將來須要作的工做。 RDS方面，目前支持MySQL和SQL Server，計劃加入PostgreSQL以方便Oracle用戶往這邊遷移。容災方面，目前是雙機房容災，成本還比較高，是否能夠經過很是高速的非易失性網絡存儲來存儲redo log，容量不須要大，數據存儲在分佈式文件系統，作一個低成本的RDS方案，只是用戶須要容忍幾十秒的MySQL實例宕機重啓的時間？這須要架構師作取捨，看咱們要放棄一些什麼以獲得一些東西。 另外，全鏈路的監控與分析系統，咱們也須要進一步應用到全線雲產品之上。將來還會推出更多的雲產品，包括無線網絡加速、 AliBench服務質量監測（目前在內部使用）、OCR識別服務、深度學習的CNN/DNN計算服務等。