阅读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???????????????????????????????????????-??????-????????????-?????????