host字段变复杂了

声明:

本博客欢迎转载,但请保留原作者信息!

作者:李人可

团队:华为杭州OpenStack团队


讨论的是openstack中卷的host属性。

印象中。社区H版本号对于volume的host值表示的就是相应cinder-volume服务的host配置项,默觉得GuestOS的hostname。比方单板A上的cinder-volume创建了卷V,那么V的host就是A。同一时候,把该host值作为rpc转发的topic,即cinder-scheduler组件已不同的host为单位进行区分,调度确定到详细哪个host后,再下发消息。这样的方式跟nova模块非常类似。nova-scheduler也是以底下nova-compute所在的host为区分。

但cinder另外还支持host字段携带后端存储名称,即“host@backname”这样的形式。见例如以下代码:

    if CONF.enabled_backends:
        for backend in CONF.enabled_backends:
            host = "%s@%s" % (CONF.host, backend)
            server = service.Service.create(host=host,
                                            service_name=backend)
            launcher.launch_server(server)

即表示一个host能够对接多个不同存储后端,host名分别为“host@backend1”,host@backend2等,然后分别启动一个独立的cinder-volume以相应。

 我认为nova也是能够这么玩耍的,一个host上理论上也能够存在多个hypervisor。也能够同一时候执行多个nova-compute,这也是数据表compute_nodes中node字段的含义吧。

这里有个非常严重的问题,由于rpc的消息转发依赖卷的host字段。假设单板A上已经创建了非常多卷。如今非常不幸的事情发生了,单板A宕机且长时间不能恢复!

这样一来。整个数据中心岂不是傻眼了,全部想操作原本由A创建的卷都宣告失败,挂不了卷。删不了卷等等。为了避免这么可怕的事情发生。能够如此改动,让多个cinder-volume服务对接同一个后端存储,同一时候统一host字段。这么一来,即使当中有个别单板发生宕机。其它正常单板也能够处理cinder-api发送过来的rpc消息。相当于把cinder-scheduler到cinder-volume之间的通信模型转变成为类似cinder-api到cinder-scheduler之间的通信模型,所谓负载均衡。

当然这么改依靠的是cinder-volume的状态无关性,也会带来一些不兼容的其它小问题,但都应该不算问题了,全加起来也比上述的问题来的轻。

不知道社区怎样看待此问题。

再来看Juno,相同是cinder-volume的启动脚本:

    if CONF.enabled_backends:
        for backend in CONF.enabled_backends:
            CONF.register_opts([host_opt], group=backend)
            backend_host = getattr(CONF, backend).host
            host = "%s@%s" % (backend_host or CONF.host, backend)
            server = service.Service.create(host=host,
                                            service_name=backend)
            launcher.launch_service(server)

有点变化的是,J版本号支持配置项中对详细backend域设置host值,而非统一值。这就比H版本号添加了一点灵活性。

比方我能够这样玩。在后端是LVM的单板上,cinder.conf这么配:

enabled_backends=lvm
[lvm]
host=lirenke

然后当cinder-volume起来后,如此结果:

host字段变复杂了_第1张图片

这符合预期,然后我尝试创建一个卷,成功后show下。依照H版本号。这个host也应是lirenke@lvm,只是:



奇葩的事情出现了,为啥在后面又加了“#LVM_iSCSI”,什么玩意儿。

rpc使用topic又是什么字段了呢?不知道。于是乎仅仅能看下J版本号源代码了。

原来。J版本号引入了pool的概念。即存储池子。一个cinder-volume管辖的领域内能够有多个pool。即一个backend和pool是一对多的关系。资源上报须要依照pool为单位上报,而非原来的host。再进一步讲,cinder-scheduler中保存的host_state对象单位变成了pool。

完整的host名称(即volume对象的host属性)为: host@backend#pool

查看cinder-scheduler下发给cinder-volume的rpc topic,使用了backend级别,即取到‘#’号之前的字符串。如“lirenke@lvm”。

至于pool名称的选取,在LVM的代码中,使用volume_backend_name的配置项,默认值即为LVM_iSCSI。

假设有driver连默认值都没有,那么就会使用__pool”来做名称。

在调度模块通过方法:

hosts = self.host_manager.get_all_host_states(elevated)

来获取全部hosts时。事实上返回的对象不是先前的HostState对象了,而是PoolState对象。PoolState对象的host属性做过特殊处理,把实际host的值和pool的名称做了结合,所以刷新到数据库的volume对象host属性值,就变成了host#pool_name。这就是为什么我创建的卷host属性会是“lirenke@lvm#LVM_iSCSI”。

注意的是,在数据库查询API方法如volume_get_all_by_host,传入的是初始的hostname。实现的时候已经做了模糊处理,即传入lirenke。也会把lirenke@**。lirenke@**#**给查出来,不影响正常逻辑。

host,backend。pool三个概念easy让人困惑。灵活性的确是添加了。可是不是这样做就攻克了上述严重的HA问题呢?似乎能够解决。原理一样,能够让两个cinder-volume取同样的host,同样的backend。不同的pool,但这么做事实上跟后端存储driver的实现强相关了,框架这么实现给了driver一定灵活性。没有能通吃全部后端的配置。

先讨论到这。其隐藏的灵活性有待进一步体会和实践,总之,host字段是变复杂了。


你可能感兴趣的:(host字段变复杂了)