閱讀1007 返回首頁    go 阿裏雲 go 技術社區[雲棲]

1 合久必分（一）：多功能集群

1       合久必分（一）：多功能集群

1.1   基本情況

資源使用量：1.1W台

1.2   特點

隨著廣告對MaxCompute的深入使用，有兩個重要場景的需求單一物理集群已經很難滿足了

1、有些任務不能接受MaxCompute的長時間不可用：如結算和反作弊相關任務；

2、算法做LR迭代經常因為資源問題Fail：MR和PS/XLib放一起時經常出現大的等待

1.3   構架調整

因此，這期間我們專門新建了“小時集群”和“AON集群”，並為這兩類集群定製了個性化策略；

1.4   小時集群

1.4.1   為什麼要搞小時集群？

   其實就兩個原因：

1、舊在雲端原計劃2015.11月完成全部下線，基本處於無法維護狀態，Hadoop小時集群也維護困難；因此要來個“再登月”；

2、 運行在小時集群上的任務對產出時間敏感，如果在一個小時內不能完成很可能會造成資損和投訴；    因此小時集群主要需要解決的就是一個跨集群容災問題。

1.4.2   架構設計

這版設計主要出自無謂大師之手

  1. 小時Project：具有小時功能的project（可多個），project屬於一個單獨的Quota Group；
  2. 小時日誌：在傳統的TT日誌保存project之外，有另外一份同樣的數據寫到小時Project（日誌雙寫）
  3. 一個小時計算集群（主集群）
  • 小時集群也跟著大集群的升級周期，PE對計算集群的優先級分類，小時計算集群優先級最高，灰度發布放在最後
  • 小時集群可能在共享集群；但在共享的小時集群裏Quota不超賣（min=max），同時可以利用虛擬資源分離機器
小時Project跨集群複製：除了小時計算集群之外，需要一個共享的計算集群     通過Replication Task將數據從小時計算集群實時複製到共享計算集群上，包括Table和Volume數據     通過PE工具，每天將Resource數據從小時集群複製到共享計算集群     共享MaxCompute控製集群、前端集群和Tunnel集群

1.4.3   可用性保障

  1. MaxCompute前端：當前具備兩個前端集群，分布在兩個不同的機房。MaxCompute客戶端所在的Gateway（在雲端Gateway）默認安裝VIP Server，當一個集群異常時，可以通過VIP Server的配置，將流量引到正常的前端集群。不可用時間在10分鍾以內
  2. Tunnel：MaxCompute具備多個Tunnel集群，分布在不同的機房。需要TT使用支持自動路由功能的Tunnel SDK，並且PE可以通過VIP Server切換集群
  3. MaxCompute控製集群：
  • 使用MaxCompute的兩個控製集群，調度數據放在OTS上
  • 控製集群切換可以使用AdminConsole或專門的PE工具
  • 控製集群切換會導致正在運行的作業失敗。保障快速切換，作業快速失敗，依賴上層天網的自動重調
計算集群的切換，通過AdminConsole，可以快速切換計算集群（1分鍾以內）
  • 計算服務不可用，切換到另外一個集群，數據可以正常訪問

5、存儲集群不可用預案

小時集群遷移MaxCompute需要較高的可用性，在應用存儲集群不可用時的TT雙寫MaxCompute project目前是不推薦的；因此設計了如下兩個方案

說明：方案1和方案2是可並存的，可以由業務方自己選擇；

 

方案1【當前方案】

方案2【可選的長遠方案】

示意圖

    

說明

1、綠色部分表示當前已經存在的任務或者數據；
2、重點就是原始日誌在tt上再收集一份topic，小時和天級任務走兩套獨立的流程；
3、alimama_hour中的表lifecycle設置成3天，而alimama_ods中的表數據維護現有不變；
4、synctask是MaxCompute的後台任務，對使用方是透明的，做為災備用；數據同步是準實時完成的，根據數據量大小來看基本會在5Min內完成；當出現存儲(AY58B)不可用時後台可以直接切換到AY87A，用戶程序不需要做任務改動；但有可能需要重置tt的點位完成tt日誌的上周期的收集；

1、有小時功能特性的日誌不直接收集到alimama_ods中，先進alimama_hour，
2、每天針對log_hour（隻是代稱，實際對應著一份pv/click等數據）會有一個merge任務把小時任務匯總到天維度；
3、天級任務處理對你依然是天級的log_day數據；
4、其他天級的數據還直接由tt寫進alimama_ods（圖中未畫）；

優點

1、簡單；
2、改動量最少，對現有任務不會造成影響 ；

1、功能劃分更明確合理；長遠來看應該用這種方案；
2、下遊任務直接可以（也應該）依賴mergeTask；

缺點

對線上機器會增加額外的tt收集壓力，少量tt空間占用；

由於當前log_day類的數據已經有太多任務在使用，方案對上線時間點也有較高的要求；因此會涉及到較多任務的改動；項目風險會被拉大；不適合與小時集群遷移合到一起來做；

 

 

1.4.4   故障恢複

當小時計算集群存儲服務發生故障時，可能產生的數據不一致需要人工介入做故障恢複：

  1. MaxCompute Job產生的數據或中間數據：有問題作業需要全部重跑；

 

1.4.5   單點問題

由於整個雲解決方案涉及到的係統眾多，因此暫不可能完全無單點，如下部分是潛在風險；

  1. MaxCompute外部依賴：OTS
  2. MaxCompute外部依賴：BUC、UMM、AAS等阿裏雲服務
  1. 數據依賴：TimeTunnel
  2. 調度依賴：天網

最後更新：2017-06-06 11:01:43

  上一篇：go  曾優雅擊退史上最凶狠的DDoS攻擊，AliGuard的高性能從何而來？
  下一篇：go  H5???????????????????????????????????????-??????-????????????-?????????