Nova AZ与Cinder AZ同步的问题丨湖南建立网站丨长沙建立网站丨建
本文摘要: 在使用OpenStack云服务平台时,有时因业务架构需要拆分不同的Availability Zone可用域,包括计算Nova和存储Cinder,并期望可以将两个AZ对应起来。目前多数OpenStack平台多多少少采用了Ceph作为Cinder存储后端(以及Glance、Swift),并在创建vm虚拟机时选择
在使用OpenStack云服务平台时,有时因业务架构需要拆分不同的Availability Zone可用域,包括计算Nova和存储Cinder,并期望可以将两个AZ对应起来。目前多数OpenStack平台多多少少采用了Ceph作为Cinder存储后端(以及Glance、Swift),并在创建vm虚拟机时选择从镜像创建块存储。我们希望可以通过创建不同的Cinder AZ配置不同的Ceph pool,每个pool关联不同的osd,已便达到不同用户创建的vm虚拟机电脑操作系统磁盘在Ceph集群中是分开的。

我们启动多个cinder-volume实例,配置不同的storage_availalibility_zone,期望是选择vm虚拟机的AZ时可以匹配Cinder里的AZ,例如:

storage_availability_zone=AZ1
查看源码/usr/lib/python2.7/site-packages/nova/conf/cinder.py中的设定,发现一个关键参数cross_az_attach,初始值为True,这代表着vm虚拟机的磁盘可以跨域绑定。

cfg.BoolOpt('cross_az_attach',            default=True, help=""" Allow attach between instance and volume in different availability zones.If False, volumes attached to an instance must be in the same availabilityzone in Cinder as the instance availability zone in Nova.This also means care should be taken when booting an instance from a volumewhere source is not "volume" because Nova will attempt to create a volume usingthe same availability zone as what is assigned to the instance.If that AZ is not in Cinder (or allow_availability_zone_fallback=False incinder.conf), the volume create request will fail and the instance will failthe build request.By default there is no availability zone restriction on volume attach. """), ]
顺藤摸瓜,继续查看/usr/lib/python2.7/site-packages/nova/virt/block_device.py,发现如果cross_az_attach为True,则传给Cinder的availability_zone为空!!!如果cross_az_attach为False,那么nova会给Cinder传递实例的availability_zone。

def _get_volume_create_az_value(instance): """Determine az to use when creating a volume    Uses the cinder.cross_az_attach config option to determine the availability    zone value to use when creating a volume.    :param nova.objects.Instance instance: The instance for which the volume        will be created and attached.    :returns: The availability_zone value to pass to volume_api.create    """ # If we're allowed to attach a volume in any AZ to an instance in any AZ, # then we don't care what AZ the volume is in so don't specify anything. if CONF.cinder.cross_az_attach: return None # Else the volume has to be in the same AZ as the instance otherwise we # fail. If the AZ is not in Cinder the volume create will fail. But on the # other hand if the volume AZ and instance AZ don't match and # cross_az_attach is False, then volume_api.check_attach will fail too, so # we can't really win. :) # TODO(mriedem): It would be better from a UX perspective if we could do # some validation in the API layer such that if we know we're going to # specify the AZ when creating the volume and that AZ is not in Cinder, we # could fail the boot from volume request early with a 400 rather than # fail to build the instance pute node which results in a # NoValidHost error. return instance.availability_zone
都清楚了,接下去配置nova.conf文件,在Cinder部分添加参数
再次创建vm虚拟机,发现Nova的AZ和Cinder的AZ对应上啦,解决!

在Cinder中还有个参数是allow_availability_zone_fallback,目的是为了创建vm虚拟机时的Nova AZ在Cinder中不会有时不报错,而是使用Cinder中default_availability_zone或者storage_availability_zone进行创建。代码在/usr/lib/python2.7/site-packages/cinder/volume/flows/api/create_volume.py中

if availability_zone not in self.availability_zones: if CONF.allow_availability_zone_fallback:                original_az = availability_zone                availability_zone = (                    CONF.default_availability_zone or CONF.storage_availability_zone)                LOG.warning(_LW("Availability zone '%(s_az)s' " "not found, falling back to " "'%(s_fallback_az)s'."),                            {'s_az': original_az, 's_fallback_az': availability_zone}) else:                msg = _("Availability zone '%(s_az)s' is invalid.")                msg = msg % {'s_az': availability_zone} raise exception.InvalidInput(reason=msg)
但是目测这个参数和cross_az_attach有冲突,因为使用cross_az_attach的情况下选择一个Cinder里没有的但是Nova中含有的AZ,创建结果还是失败的,终会以cross_az_attach作为判断。

相关内容