故障处理:OpenStack对接商业存储NetApp cinder调度规则问题

问题描述:

最近在云平台存储资源使用超过60%多了,准备进行对商业存储NetAPP扩容。

OpenStack环境NetApp后端SAS backend扩容了两个新的pool,vol3和vol4,测试创建云硬盘无法调度到新扩容的pool(vol3和vol4)上。

 

【环境信息】

 

cinder后端对接了NetApp 商业存储,NFS协议。目前客户使用时创建了一个nas的volume-type,然后nas后端对接了2个逻辑pool,分别是vol1,vol2,容量均为10T 。 

 

变更信息:今天客户扩容NetApp,在nas的后端新增加了两个pool vol3/vol4,容量均为5T 。 

 

【问题现象】

 

本次扩容后,创建nas类型的云硬盘无法调度到vol3/vol4上去。

 

【处理过程】

 

  1. 复现问题,默认未开启debug日志,打开debug日志,进行复现分析
  2. 查看日志, 创建nas类型云盘,cinder在调度时,可以调度到vol1, vol2, vol3, vol4。 然而在选择后端存储创建云盘时会选择 vol1或者vol2,并不会选择客户扩容的vol3或者vol4。
  3. 查看源码了解到cinder的进一步确认cinder调度规则:

 

 

 

具体实现代码如下:

 

def calculate_virtual_free_capacity(total_capacity,

 

                                    free_capacity,

 

                                    provisioned_capacity,

 

                                    thin_provisioning_support,

 

                                    max_over_subscription_ratio,

 

                                    reserved_percentage):

 

    """Calculate the virtual free capacity based on thin provisioning support.

 

 

 

    :param total_capacity:  total_capacity_gb of a host_state or pool.

 

    :param free_capacity:   free_capacity_gb of a host_state or pool.

 

    :param provisioned_capacity:    provisioned_capacity_gb of a host_state

 

                                    or pool.

 

    :param thin_provisioning_support:   thin_provisioning_support of

 

                                        a host_state or a pool.

 

    :param max_over_subscription_ratio: max_over_subscription_ratio of

 

                                        a host_state or a pool

 

    :param reserved_percentage: reserved_percentage of a host_state or

 

                                a pool.

 

    :returns: the calculated virtual free capacity.

 

    """

 

 

 

    total = float(total_capacity)

 

    reserved = float(reserved_percentage) / 100

 

 

 

    if thin_provisioning_support:

 

        free = (total * max_over_subscription_ratio

 

                - provisioned_capacity

 

                - math.floor(total * reserved))

 

    else:

 

        # Calculate how much free space is left after taking into

 

        # account the reserved space.

 

        free = free_capacity - math.floor(total * reserved)

 

    return free

 

由源码可知:

 

cinder调度策略是: 先过滤出所有可用的host, 然后排序。

 

目前默认的排序策略是按照容量排序,具体原理是:

 

如果后端存储是精简的,按照总容量排序,

 

如果后端存储是厚置备的,按照剩余可用容量排序。

 

 

 

通过查看debug日志可知当前环境NetApp的后端为精简配置,且超售20倍。

 

{u'reserved_percentage': 10

 

u'max_over_subscription_ratio': 20.0

 

u'thin_provisioning_support': True

 

u'provisioned_capacity_gb': 0.01}

 

 

 

 

 

【结论】

 

本次无法调度到vol3,vol4上的原因是:扩容的vol3和vol4总容量,比vol1和vol2小导致的。由于NetApp默认配置为精简thin,vol1和vol2总容量为10T, vol3和vol4总容量为5T,因此不会调度到新扩容的vol3和vol4。

 

 

 

【解决方案】

 

调整NetApp后端的所有pool容量一致。

 

本次将vol3,vol4的容量扩容到10T后,再次测试创建云硬盘,云硬盘成功调度到vol

 

3和vol4上。

 

【总结和建议】

 

  对于同一个后端配置多个精简pool的情况下,建议所有pool总容量保持一致。

 

 

 

 

上一篇:Hadoop集群搭建


下一篇:BigData:基于python编程—根据中国各个城市地理坐标+人口、GDP大数据进行标记中国地图、热点图、动态图