我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:香港跑狗图 > 调度策略 >

容器化RDS|调度策略

归档日期:06-04       文本归类:调度策略      文章编辑:爱尚语录

  看上去很简单,挑选出一个满足资源要求的节点即可,但是考虑到整合密度和数据库的业务特点并不简单,我们还需要考虑到以下几点:

  数据库的负载随着业务、时间、周期不断变化,到底是基于峰值调度还是均值调度呢?这是一个有关部署密度的问题,最好的办法就像Linux里面限定资源的方式,让我们设置Soft Limit 和Hard Limit,以Soft Limit分配资源,同时Hard Limit又能限定使用的最大资源。Kubernetes也是这么做的,它会通过 Request 和 Limit 两个阈值来进行管理容器的资源使用。

  Requst作为Pod初始分配值,Limit限定了Pod能使用的最大值。分配时采用Requst值进行调度,这里有个假设:

  有效的实现了计算资源利用率的high utilization,非常适合数据库开发或测试场景。

  当某节点运行的所有容器同时接近Limit,并有将节点资源用完的趋势或者事实(在运行的过程中,调度器会定期收集所有节点的资源使用情况,“搜集”用词不太准确,但便于理解),创建 Pod的请求也不会再调度到该节点。

  以内存为例, 当Pod的请求超出Node可以提供的内存, 会以异常的方式告知调度器, 内存资源不足

  同时,基于优先级,部分容器将会被驱逐到其他节点(例如通过重启Pod的方式),所以并不适合生产环境。

  对于长期运行的集群,在满足资源的同时还要考虑到集群中各节点资源分配的平衡性。

  类似Linux Buddy System,仅仅分配进程需要的内存是不够的,还要保障操作系统内存的连续性。

  举个例子,RDS集群有两个节点,用户向RDS申请2颗CPU和4GB内存以创建 MySQL实例,两节点资源使用情况如下:

  存储资源是有状态服务中至关重要的一环,也让有状态服务的实现难度远超无状态服务。

  除了满足请求数据库的存储资源的容量要求,调度策略必须要能够识别底层的存储架构和存储负载,在提供存储资源的同时,满足数据库的业务需求(比如数据零丢失和高可用)。

  从2017年年初开始,基于分布式存储技术,我们的RDS已经实现了计算和存储分离的架构。

  在实现数据库的数据零丢失,高可用的同时,架构变得更通用,更简单。但对企业级用户,还远远不够,cost-efficient是考量产品成熟度的重要因素。

  distribution,基于分布式存储技术实现,对 Flash 设备做了专门的 优化,提供数据冗余和弹性扩容功能;

  对于生产环境,我们会申请distribution资源。而那些不太重要的或者临时性的,譬如有的客户需要经常生成临时性的克隆库进行测试,或者扩展临时备库以应对突发的业务高峰,我们会申请local资源。

  IO密集型业务,我们会分配high类型。对于计算密集型或者重要值很高的备库,我们会分配medium类型。

  如果调度器能够实现, 将极大的提高存储资源的cost-efficient。

  这些特性带有明显的数据库业务特性,原生的Kubernetes调度器并不支持。但是,我们通过二次开发,Out of Cluster的方式实现了外置的Kubernetes storage provisoner,并通过自定义的参数和代码实现和调度器的交互。

  这样Kubernetes的调度器就可以基于RDS的业务需求,感知底层存储架构,提供满足业务需求的调度服务。

  除去需要的容量信息,需要传递给调度器如下信息(就像请CPU,Memory资源一样):

  关系型数据库是有状态服务,但要求更加复杂。比如我们提供了MySQL的Read Write Cluster(读写分离集群) 和Sharding Cluster(分库分表集群),每个数据库实例都有自己的角色。调度器必须感知集群角色以实现业务特点:

  带有明显的业务(RDS)特点,原生Kuberentes的调度策略并不能识别这些角色和关系。

  再通过我们的二次开发,将数据库的角色和业务流程集成到调度器中,以满足全部需求。

  在所有节点中找到指定 Slave 所在节点, 以确定待调度备份任务调度到哪个节点. 该需求必须满足, 不然备份任务无法成功.

  建立已运行数据库和节点的关系,在通过Affinity和Anti-Affinity公式对所有节点打分,以此决定待调度数据库是否要调度到该节点。

  以待调度数据库的角色为输入,建立已运行数据库和节点的关系,再通过 Anti-Affinity 公式对所有节点打分,以此决定待调度数据库是否要调度到该节点。

  以需求1为例,统计集群成员的分布情况,该节点上同一数据库集群的成员越多,分数越低。

  以需求2为例, 统计集群成员的分布情况, 该节点上同一数据库集群的成员越多, 分数越低。

  在设计产品和完成编码的过程中,踩坑无数。不能否认的是,站在巨人的肩膀上可以让我们看的更远。不知道Ending怎么写, 就这样吧。

本文链接:http://mikephotos.net/diaoducelue/508.html