Flink 3种部署模式、保证高可用的区别/Standalone Cluster/Yarn Cluster /Kubernetes Cluster

1 Standalone Cluster

Master-Slave架构,JobManager运行在Master节点,TaskManager运行在Slave节点,与HDFS/Hadoop无关

Active JobManager挂掉时,通过Zookeeper选举多个Standby JobManager成为Active JobManager来保证高可用

2 Yarn Cluster

2.1 Yarn Session模式:在YARN之上部署了Flink Session集群(可屏蔽底层不同的运行环境),向Yarn Session集群提交作业(不与YARN交互),多个作业共用集群资源(一个JobManager管理多个作业,作业越多则JobManager的负载越大),JobManager挂掉时会通过重启来保证高可用

2.2 Single Job模式:作业直接提交到YARN上(与YARN交互),一个作业对应一个JobManager,资源隔离,

3 Kubernetes Cluster :

----

Session模式

Session模式是预分配资源的,也就是提前根据指定的资源参数初始化一个Flink集群,并常驻在YARN系统中,拥有固定数量的JobManager和TaskManager(注意JobManager只有一个)。提交到这个集群的作业可以直接运行,免去每次分配资源的overhead。但是Session的资源总量有限,多个作业之间又不是隔离的,故可能会造成资源的争用;如果有一个TaskManager宕机,它上面承载着的所有作业也都会失败。另外,启动的作业越多,JobManager的负载也就越大。所以,Session模式一般用来部署那些对延迟非常敏感但运行时长较短的作业。

Per-Job模式

顾名思义,在Per-Job模式下,每个提交到YARN上的作业会各自形成单独的Flink集群,拥有专属的JobManager和TaskManager。可见,以Per-Job模式提交作业的启动延迟可能会较高,但是作业之间的资源完全隔离,一个作业的TaskManager失败不会影响其他作业的运行,JobManager的负载也是分散开来的,不存在单点问题。当作业运行完成,与它关联的集群也就被销毁,资源被释放。所以,Per-Job模式一般用来部署那些长时间运行的作业。

存在的问题

上文所述Session模式和Per-Job模式可以用如下的简图表示,其中红色、蓝色和绿色的图形代表不同的作业。

----

Session-Cluster模式

Session-Cluster模式需要先启动集群,然后再提交作业,接着会向yarn申请一块空间后,资源永远保持不变。如果资源满了,下一个作业就无法提交,只能等到yarn中的其中一个作业执行完成后,释放了资源,下个作业才会正常提交。所有作业共享Dispatcher和ResourceManager;共享资源;适合规模小执行时间短的作业。

Per-Job-Cluster模式

一个任务会对应一个Job,每提交一个作业会根据自身的情况,都会单独向yarn申请资源,直到作业执行完成,一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享Dispatcher和ResourceManager,按需接受资源申请;适合规模大长时间运行的作业。

end

分类:
后端
标签: