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起来后，如此结果：

这符合预期，然后我尝试创建一个卷，成功后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字段是变复杂了。