OpenStack Cinder源码分析之二

感谢朋友支持本博客,欢迎共同探讨交流,由于能力和时间有限,错误之处在所难免,欢迎指正!
如果转载,请保留作者信息。
博客地址:http://blog.csdn.net/gaoxingnengjisuan
邮箱地址:dong.liu@siat.ac.cn


我们继续来整理代码,来看cinder模块中的调度器。

7 scheduler/cinder/scheduler/

/cinder/scheduler/driver.py:所有调度器类都应该继承的调度器基类;

    class Scheduler(object):调度器基类;

        def get_host_list(self):从HostManager获取主机列表;#注:这个方法目前还没有进行具体应用;

        def get_service_capabilities(self):从HostManager获取服务的capabilities;#注:这个方法目前还没有进行具体应用;

        def update_service_capabilities(self, service_name, host, capabilities):更新一个服务节点的capability信息;

        def hosts_up(self, context, topic):获取所有运行了给定主题的主机列表;

        def host_passes_filters(self, context, volume_id, host,filter_properties):检测指定的主机是否通过过滤器;


/cinder/scheduler/chance.py随即选取节点调度器;

    classChanceScheduler(driver.Scheduler):随即选取节点调度器;随机选取节点调度器的实现;

        def _filter_hosts(self, request_spec, hosts, **kwargs):基于request_spec实现对主机列表的过滤;

        def _get_weighted_candidates(self, context, topic, request_spec,**kwargs):获取经过request_spec过滤的可用的主机列表;

        def _schedule(self, context, topic, request_spec, **kwargs):实现随机选取主机;

        def schedule_create_volume(self, context, request_spec,filter_properties):实现随机选取主机;远程调用实现在选取的主机上建立并导出卷;

        def host_passes_filters(self, context, host, request_spec,filter_properties):检测指定的host是否通过了过滤器的过滤;


/cinder/scheduler/filter_scheduler.pyFilterScheduler用于建立卷选取目标主机;可以应用这个调度器来指定我们要应用的卷过滤器和称重方法来实现对候选主机的过滤和称重操作;

    classFilterScheduler(driver.Scheduler):用于对主机进行过滤和称重操作的调度器;

        def schedule(self, context, topic, method, *args, **kwargs):对主机进行过滤称重操作,获取最优的主机;

        def _get_configuration_options(self):获取配置选项;

        def populate_filter_properties(self, request_spec, filter_properties):填充过滤器属性信息;

        def schedule_create_volume(self, context, request_spec, filter_properties):对主机进行过滤和称重操作,获取最优主机,并实现远程调用建立并导出卷;

        def host_passes_filters(self, context, host, request_spec,filter_properties):检测指定主机是否经过了主机过滤和称重操作,即在经过主机过滤和称重操作所获取的主机列表中查找是否有指定的主机;

        def _post_select_populate_filter_properties(self, filter_properties,host_state):在最优主机选定之后,添加附加信息到过滤器属性;

        def _add_retry_host(self, filter_properties, host):增加retry条目属性到卷的后端,当响应请求进行主机列表的重新选取时,这个条目属性将会表示某主机是否已经进行过过滤操作,如果已经进行过过滤操作,则不再进行过滤操作,这也是提高系统效率的一个措施;

        def _max_attempts(self):获取调度一个卷重试次数的最大值;

        def _log_volume_error(self, volume_id, retry):记录卷操作的错误,以辅助代码开发和调试;

        def _populate_retry(self, filter_properties, properties):添加或更新重试次数的属性值到过滤器属性中;

        def _get_weighted_candidates(self, context, request_spec,filter_properties=None):返回满足request_spec要求的主机列表,并对主机进行称重操作;

        def _schedule(self, context, request_spec, filter_properties=None):对主机进行过滤称重操作,获取最优的主机;


/cinder/scheduler/host_manager.py管理当前zone的hosts;

    class HostState(object):更新主机的可变和不可变的信息;

        def update_capabilities(self, capabilities=None, service=None):用给定的capabilities和service,更新现有的capabilities和service;

        def update_from_volume_capability(self, capability):从volume_node信息capability中获取相关数据信息来更新对应的主机信息;

        def consume_from_volume(self, volume):实现从卷的信息更新主机状态;

class HostManager(object):主机管理基类;

        def _choose_host_filters(self, filter_cls_names):实现检测默认使用的过滤器类是否都可以使用,获取系统默认使用的过滤器类中通过验证的类的列表;

        def _choose_host_weighers(self, weight_cls_names):实现检测默认使用的称重类是否都可以使用,获取系统默认使用的称重类中通过验证的类的列表;

        def get_filtered_hosts(self, hosts, filter_properties,filter_class_names=None):根据所有过滤器对主机进行过滤操作,只返回符合条件的主机列表;

        def get_weighed_hosts(self, hosts, weight_properties,weigher_class_names=None):对主机进行称重操作,返回排序后的主机列表;

        def update_service_capabilities(self, service_name, host, capabilities):根据通知更新每个服务的capabilities

        def get_all_host_states(self, context):获取所有匹配的主机;


/cinder/scheduler/manager.py调度器管理服务;

    classSchedulerManager(manager.Manager):选取一个host来建立volumes;

        def get_host_list(self, context):从HostManager获取主机列表;#注:这个方法目前还没有进行具体应用;

        def get_service_capabilities(self, context):从HostManager获取服务的capabilities;#注:这个方法目前还没有进行具体应用;

        def update_service_capabilities(self, context, service_name=None,host=None, capabilities=None, **kwargs):更新一个服务节点的capability信息;

        def create_volume(self, context, topic, volume_id, snapshot_id=None,image_id=None, request_spec=None,filter_properties=None):volume_rpcapi.create_volume是调用manager.py中的create_volume方法,该方法先从数据库中取出volume的信息,然后调用volume_utils.notify_about_volume_usage方法(是不是通知RabbitMQ?)。然后继续从volume信息中取vol_name,vol_size,并且如果入参中有snapshot_id,说明从快照创建卷,则从DB中取该snapshot的信息,如果入参中有source_volID,说明是从已有卷创建卷,则从DB中取该源卷信息,如果入参中有image_id,说明是从镜像创建卷,则从glance中获取镜像服务器信息,镜像ID,镜像位置,镜像的metadata.然后调用该类的私有方法_create_volume,该方法首先判断如果snapshot_ref,imag_id,srcvol_ref都是空,则说明是创建一个空卷,就调用driver.create_volume去创卷,如果有snapshot_ref参数,则调用driver.create_volume_from_snapshot方法去创卷,如果请求中有源卷的参数,则调用driver.create_cloned_volume去创卷(实际上就是克隆一个卷)。如果请求中有镜像参数,则调用driver.clone_image方法去创卷,如果clone_image失败,则调用普通创卷方法先创建个空卷,然后将卷状态置为downloading,然后调用_copy_image_to_volume方法把镜像内容拷贝入卷中。

        def request_service_capabilities(self, context):远程调用实现收集驱动的状态和capabilities信息,并进行信息的发布;

        def migrate_volume_to_host(self, context, topic, volume_id, host,force_host_copy, request_spec, filter_properties=None):确认host的存在性并接收指定的卷;即先确定指定的主机是否经过了过滤操作,如果经过了过滤操作,将其作为目标主机,将指定的卷迁移到目标主机上;

        def _set_volume_state_and_notify(self, method, updates, context, ex,request_spec):设置卷的状态信息,并进行通知操作;


/cinder/scheduler/rpcapi.pyscheduler管理RPC API的客户端;

    classSchedulerAPI(cinder.openstack.common.rpc.proxy.RpcProxy):scheduler管理RPC API的客户端;

        def create_volume(self, ctxt, topic, volume_id, snapshot_id=None,image_id=None, request_spec=None, filter_properties=None):远程调用实现卷的建立操作;

        def migrate_volume_to_host(self, ctxt, topic, volume_id, host,force_host_copy=False, request_spec=None, filter_properties=None):远程调用实现确认host的存在性并接收指定的卷;

        def update_service_capabilities(self, ctxt, service_name, host,capabilities):远程调用实现获取capabilities信息;


/cinder/scheduler/scheduler_options.py检测json文件的变化,如果需要要进行文件的加载;

    class SchedulerOptions(object):检测json文件的变化,如果需要要进行文件的加载;


/cinder/scheduler/simple.py简单调度器;选取拥有最少卷的主机作为目标主机;

    classSimpleScheduler(chance.ChanceScheduler):简单的主机调度器类;

        def schedule_create_volume(self, context, request_spec,filter_properties):选取拥有最少卷的主机作为目标主机;


/cinder/scheduler/filters/capacity_filter.py基于卷主机capacity使用率的CapacityFilter过滤器;

    classCapacityFilter(filters.BaseHostFilter):基于卷主机capacity使用率的CapacityFilter过滤器;

        def host_passes(self, host_state, filter_properties):如果主机有足够的capacity,返回True;根据过滤器参数filter_properties.get('size')对主机进行过滤;


/cinder/scheduler/filters/retry_filter.py过滤掉那些已经尝试过的节点;

    classRetryFilter(filters.BaseHostFilter):过滤掉那些已经尝试过的节点;

        def host_passes(self, host_state, filter_properties):跳过那些已经尝试过的节点;


/cinder/scheduler/weights/capacity.pyCapacity称重;根据主机可用的available来进行称重主机的操作;

    classCapacityWeigher(weights.BaseHostWeigher):Capacity称重;根据主机可用的available来进行称重主机的操作;

Openstack 从 Folsom 开始使用 Cinder 替换原来的Nova-Volume服务,为 Openstack 云平台提供块存储服务。 Cinder架构                                                  /- ( LDAP )                              [ Auth Manager ] ---                                     |            \- ( DB )                                     |                                     |                    cinderclient     |                   /             \   | [ Web Dashboard ]-               -[ api ] --  -- [ scheduler ] -- [ volume ] -- ( iSCSI )                   \             /   |                    novaclient       |                                     |                                     |                                     |                                   Cinder服务 API service:负责接受和处理Rest请求,并将请求放入RabbitMQ队列。Cinder提供Volume API V2, 我没有找到格式很好的在线文档,大体可以参见Openstack block storage API V1 Scheduler service: 处理任务队列的任务,并根据预定策略选择合适的Volume Service节点来执行任务。目前版本的cinder仅仅提供了一个Simple Scheduler, 该调度器选择卷数量最少的一个活跃节点来创建卷。 Volume service: 该服务运行在存储节点上,管理存储空间。每个存储节点都有一个Volume Service,若干个这样的存储节点联合起来可以构成一个存储资源池。为了支持不同类型和型号的存储,当前版本的Cinder为Volume Service如下drivers。当然在Cinder的blueprints当中还有一些其它的drivers,以后的版本可能会添加进来。 本地存储:LVM, Sheepdog 网络存储: NFS, RBD (RADOS) IBM: XIV, Storwize V7000, SVC storage systems Netapp: NFS存储;ISCSI存储则需要OnCommand 5.0和Data ONTAP 7-mode storage systems with installed iSCSI licenses EMC: VNX, VMAX/VMAXe Solidfire: Solidfire cluster Cinder服务的部署 上述的Cinder服务都可以独立部署,cinder同时也提供了一些典型的部署命令: cinder-all: 用于部署all-in-one节点,即API, Scheduler, Volume服务部署在该节点上。 cinder-scheduler: 用于将scheduler服务部署在该节点上。 cinder-api: 用于将api服务部署在该节点上。 cinder-volume: 用于将volume服务部署在该节点上。 Cinder如何支持典型存储 从目前的实现来看,Cinder对本地存储和NAS的支持比较不错,可以提供完整的Cinder API V2支持,而对于其它类型的存储设备,Cinder的支持会或多或少的受到限制,下面是Rackspace对于Private Cloud存储给出的典型配置: 1. 本地存储 对于本地存储,cinder-volume可以使用lvm驱动,该驱动当前的实现需要在主机上事先用lvm命令创建一个cinder- volumes的vg, 当该主机接受到创建卷请求的时候,cinder-volume在该vg上创建一个LV, 并且用openiscsi将这个卷当作一个iscsi tgt给export. 当然还可以将若干主机的本地存储用sheepdog虚拟成一个共享存储,然后使用sheepdog驱动。 2. EMC 3. Netapp Cinder在IT环境中的主要问题 目前版本的Cinder在IT私有云场景中,从硬件兼容性,高性能,高可靠性,水平扩展能力,应用兼容性等维度来看,Cinder还存在不少问题需要解决。Cinder依然任重道远。 1. 对共享存储的支持有限 不支持FC SAN; 支持的存储设备有限,即使对于EMC, IBM这样的的主流存储厂商,也只能支持寥寥几款存储; 2. 对存储设备的使用不够高效 Cinder卷管理的基本原则是在共享存储上创建一个lun, 然后把这个lun作为一个block device给attach到一个虚拟机上。但是对于当前主流的存储,能够支持的最大lun数量非常有限,比如我们经常使用的Huawei S3900, 最多能支持288个lun,如果一个VM平均3个卷,不管这些VM是offline还是online, 这个存储最多只能支持90个VM。 3. 存储管理带来的性能损耗 比如Cinder Volume的LVM驱动使用iSCSI export一个逻辑卷,从管理的角度来看是解决了存储共享的问题,从而能够支持比如迁移这样的功能,但是这样的设计势必会导致较大的性能损耗,和直接访 问相比,通常iSCSI export会增加30%以上的IO延迟。 4. 数据如何迁移 企业IT环境中大量的数据,一般都是存放在SAN甚至是磁带设备上的,这些数据如何无损,安全的接入到Cloud呢?VMware因此提供了RDM, KVM和XEN也支持PVSCSI, 但是Cinder没有考虑这个。 5. Cinder的调度器不完善 Cinder提供的simple scheduler基本没有实用价值,  cinder-scheduler仅能在初始放置时保证系统负载均衡,但是如果是发生了运行时负载严重不平衡,cinder就没法处理了。 6. Cinder服务的可靠性问题 cinder-api和cinder-scheduler是系统的单点,cinder并没有提供这两个服务提供任何HA和load balance设计,所以整个系统可靠性还是扩展性会比较受限制。 cinder-db如果发生不可恢复的故障,能够保证用户数据能恢复吗? 介绍内容出处:http://blog.csdn.net/luo_brian/article/details/8592692 标签:OpenStack
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值