网站制作资源抽象层

资源抽象层主要是将下层的物理硬件资源统一进行抽象,抽象成和单个物理硬件无关的资源集合,上层无须关心物理机器的型号,只需专注于具体的资源即可。
 
资源抽象层需要重点做好以下三件事。第一,收集和管理具体物理资源;
 
第二,重新封装抽象的硬件资源属性,使之成为上层可以使用的一个实体,既可以是容器也可以是虚拟机或者资源集合;
 
第三,数据存储问题。做业务少不了要在本机存储数据,这样机器就成为“有状态”的,不利于全局调度资源。为了能够全局调度,需要解决三个场景下的问题:是数据不需要永久本地存储但是会实时写到本地的,如应用的日志;二是需要永久存储的如DB数据;三是分布式存储场景中,要做到存储与计算分离。


 
资源的收集和管理
 
资源的收集就是收集物理机的资源,例如当前型号的机器有多少可用的CPU、内存、磁盘等信息,它可以分为四个方面的内容。
 
第一,资源的信息管理。有多少,用了多少,还有多少;
 
第二,大量物理机器的集群管理。除了通常几十万台的机器管理功能外,还有一部分的任务管理,如负责接收 Master创建容器的任务等。
 
第三,资源的合理分配策略和算法。上层的资源请求最终会在每台物理机上进行分配,那么如何能?这里有根合理的分配策略和算法支撑。
 
第四,资源的信息管理就是要实现一个CMDB,能管理物理机和 vhost I的关联关系,必须能管理上万台甚至十几万台规模的机器集群。这样的机器集群管理框架目前可选的比较少,我们选择的是 Mesos,主要基于以下两方面的考虑。一是 Mesos目前相对比较成熟,主流的大公司使用较多,在实际场景中的使用规模已达5万台左右;二是 Mesos扩展性比较好,本身是轻量级的,可以灵活定制各种 Framework满足业务需要。
 
我们分析一下为什么Msos能管理这么大的集群,它的资源分配策略以及它是如何灵活创建各种容器和配置网络的。 Mesos的集群架构。
 
Mesos的模块化设计使得它的集群管理本身可做的事情并不多: Master仅仅把从Save收集的资源数据汇报给 Framework; Master和 Slave通过消息交互消息,不需要一直保持长连接。随着 Slave规模的扩大, Master的压力并不会显著增长。 Master本身的高可用是通过ZK( Zookeeper)来保证的,整个集群的架构设计非常清晰。
 
当集群规模很大时,资源的管理和分配策略就会非常重要。分配策略对于最大化充分利用物理资源非常关键,所以要自己定制 Framework以便更精细化地分配资源。目前我们设计了4个分配策略。
 
(1)最大内存剩余优先分配策略。即集群中内存剩余最多的优先分配,目的是充
 
(2)最大CPU剩余优先分配策略。类似于内存分配,根据剩余的CPU数优先分配给对CPU资源需求大的任务;
 
3)最大最小资源公平分配策略。这种分配是根据当前任务申请的资源,要查看当前集群中的每台机器、每种资源的使用量是否饱和,优先把任务分配给当前最空闲的机器;
 
(4)根据资源分配指定分配策略。这种方式比较灵活,就是可以根据用户的需要把任务分配到指定的机器上执行,例如可以给一些机器打上标签,让某类任务在这些带有标签的机器上执行。
 
从上面的介绍可以知道网站制作Framework的修改需要比较灵活的支持,而当前 Mesos的 Framework的更新还比较麻烦。如果要更新 Framework的代码,就需要重启每个Slave的 execute,进而可能要停止 Slave上的任务,这在生产环境中是很难接受的。有鉴于此,我们对 Framework进行了无状态设计,在代码实现上,改用动态语言如Groovy来编写需要经常修改的逻辑,这样Govy实现的代码就可以动态加载而不需重启任务,对 Framework的功能进行调整就非常方便了。
本文地址:http://www.hy755.cn//article/4544.html
相关文章:
最新文章: