云计算服务
服务器租用
DDOS 防护
虚拟主机
域名服务
基础设施
关于我们
1.文档编写目的
Apache DolphinScheduler（简称DS）是一个分布式去中心化，易扩展的可视化DAG工作流任务调度平台。在生产环境中需要确保调度平台的稳定可靠性及任务负载均衡，本篇文档主要针对DS集群的高可用及稳定性进行测试验证。
1.CM和CDH版本为5.16.2
2.集群启用Kerberos
3.DolphinScheduler版本为1.3.8
4.集群HDFS和Yarn服务已启用HA
5.操作系统为RedHat7.6
2.测试场景说明
DS的API服务主要是用于为前端UI层提供服务，前端界面也是我们使用DS的一个重要入口，需要确保服务的高可用。
通过模拟API服务故障，验证API服务是否可以正常运行。
MasterServer采用分布式无中心设计理念，MasterServer主要负责 DAG 任务切分、任务提交监控，并同时监听其它MasterServer和WorkerServer的健康状态。MasterServer服务启动时向Zookeeper注册临时节点，通过监听Zookeeper临时节点变化来进行容错处理。
通过模拟MasterServer服务故障，验证集群的DAG调度及监控是否正常运行。
WorkerServer也采用分布式无中心设计理念，WorkerServer主要负责任务的执行和提供日志服务。WorkerServer服务启动时向Zookeeper注册临时节点，并维持心跳。
通过模拟WorkServer服务故障，验证集群的DAG在运行过程中是否会受到影响。
基于该场景主要测试在集群高负载的进行任务调度的情况下，验证DAG任务是否能够合理的分配到相应的worker节点运行。
3.高可用测试
3.1 API管理角色的高可用性测试
测试前置：在测试API角色之前需要确保DS集群中已部署了两个API角色，否则在测试的过程中模拟API故障则会直接导致DS的前端页面无法正常访问。
说明：测试阶段就未引入Haproxy或F5实现前端页面访问的负载均衡，因此本测试用例均是直接访问相应的API地址来进行验证。
1.确认两个API服务均正常运行
2.访问192.168.0.120的API服务的前端在项目中运行一个调度
3.登录192.168.0.120节点，找到API服务的进程，并kill掉该进程，模拟服务异常
ps -ef |grep ApiApplicationServer
确认服务120节点的API服务已停止
4.登录192.168.0.121节点的API服务，确认作业在120节点上启动的作业是否已成功运行
在121节点的API前端界面上可以看到，在120节点上提交的DAG已成功运行，并未收到120节点API服务异常而终止任务。
3.2Master管理角色的高可用性测试
测试前置：Master服务采用分布式无中心模式，MasterServer服务启动时向Zookeeper注册临时节点，通过监听Zookeeper临时节点变化来进行容错处理。为了测试Master服务的高可用，需要确保集群中的Master角色在2个以上。本次的测试环境有3个Master服务
1.在API的WEB UI上连续的提交多个DAG工作流
可以看到连续提交多个DAG时，DAG会被提交到不同的Master节点上。
2.登录到192.168.0.120的Master节点上，找到该服务的进程并Kill掉
ps -ef |grep master
当前存在的Master服务为2个
3.通过刷新WEB界面可以看到，出现“恢复被容错的工作流”
可以看到开始被分配到120节点的DAG工作流，因为该节点的Master服务故障， 工作流被恢复到另外两个Master节点运行。最终可以看到所有的提交的两个工作流均成功运行。
当120节点的服务器负载很高时，提交的所有DAG工作流均被分配到其他两个Master节点
在连续提交三个DAG后，分配
3.3Worker角色的高可用性测试
测试前置：对于DS的Worker角色来说，主要是用来执行Master分配的Task任务，因此在此环节做Worker的高可用测试，则必须确保Worker节点在2个以上。本次测试环境Worker节点共有3个：
1.通过DS的前端界面运行两个DAG工作流
2.将192.168.0.120和192.168.0.121节点的Worker服务杀掉
确认只有一个Worker节点
3.查看作业也运行成功
3.4Worker节点的性能负载测试
负载均衡即通过路由算法（通常是集群环境），合理的分摊服务器压力，达到服务器性能的最大优化。
DolphinScheduler-Master 分配任务至 worker,默认提供了三种算法:
加权随机（random），在符合的 worker 中随机选取一台平滑轮询（roundrobin），通过为每台 worker 都有两个权重，即 weight（预热完成后保持不变），current_weight（动态变化），每次路由。都会遍历所有的 worker，使其 current_weight+weight，同时累加所有 worker 的 weight，计为 total_weight，然后挑选 current_weight 最大的作为本次执行任务的 worker，与此同时，将这台 worker 的 current_weight-total_weight。线性负载（lowerweight），通过每台worker的load平均值和可用物理内存，判断worker是否参与负载。默认配置为线性加权负载。
参考：
https://dolphinscheduler.apache.org/zh-cn/docs/latest/user_doc/load-balance.html
本次测试通过拉高集群中两个worker节点的负载方式，验证提交的DAG工作流，任务是否会分配到高负载的Worker节点上。
1.本次选择120和122节点，在两个节点上运行脚本，将该节点的负载拉高
2.通过WEB界面向DS集群中连续提交几个DAG工作流
3.持续观察worker节点的负载情况
当worker的负载过高时，相应的任务就会提交到负载低的worker节点
4.总结
1.在DS集群中部署多个API服务，通过Haproxy或F5负载均衡的方式，可以保障前端WEB界面的高可用及负载均衡。
2.在DS集群中Master服务是一个分布式的无中心的管理节点，在提交DAG任务时会根据Master所在节点的负载情况来选择相对负载低的节点提交，可以很好的做到Master服务的负载均衡及高可用。
3.在DS集群中Worker服务有多重负载规则，本次测试使用默认的线性负载方式，通过所有Worker节点对自己所在服务器的load 平均值和可用内存情况，来选择最优的worker节点来运行Task作业，有效且合理的分摊了服务的压力，达到服务器性能最大优化。
.png)
.png)
