在应用OpenStack云服务平台时，有时候因业务流程构架必须分拆不一样的Availability Zone能用域，包含测算Nova和储存Cinder，并期待能够将2个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 pute 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做为分辨。