Nova AZ与Cinder AZ同步的问题

在使用OpenStack云平台时，有时因业务架构需要拆分不同的Availability Zone可用域，包括计算Nova和存储Cinder，并期望可以将两个AZ对应起来。目前多数OpenStack平台或多或少采用了Ceph作为Cinder存储后端（以及Glance、Swift），并在创建虚拟机时选择从镜像创建块存储。我们希望可以通过创建不同的Cinder AZ配置不同的Ceph pool，每个pool关联不同的osd，已便达到不同用户创建的虚拟机操作系统磁盘在Ceph集群中是分开的。

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

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

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 on the compute node which results in a # NoValidHost error. return instance.availability_zone
都清楚了，接下来配置nova.conf文件，在Cinder部分添加参数
再次创建虚拟机，发现Nova的AZ和Cinder的AZ对应上啦，解决！

在Cinder中还有个参数是allow_availability_zone_fallback，目的是为了创建虚拟机时的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作为判断。