I think that volume types and AZs do quite different jobs, and should be used for different things.
AZs are (in my opinion/understanding) about failure domains - ideally they'd be mapped to redundancy in power/networking/etc - failures in one AZ /shouldn't/ bring down a different AZ. This can't easily be entirely implemented on Openstack, since we have a single rabbit server/cluster. single database, common API endpoint, etc. Good engineering can reduce the impact of single AZ failure of any of these - redundant load balancers spreading requests across API nodes in multiple AZs, clustered rabbit, clustered DB, but it is far from trivial. I believe the AZ concept is imported from Amazon. I'd expect a cinder AZ to map on to a Nova AZ. Volume types are for differentiating storage. I'd generally expect (though there are no rules about it) that for most installations, the same volume types will be available in every AZ. You could certainly use volume types to identify redundant storage within one AZ, or there are scheduler hints to achieve the same effect. I think that you/we should work on making these concepts clearer to new-comers and admins, and help developers keep the distinction. On 20 July 2015 at 09:35, hao wang <sxmatch1...@gmail.com> wrote: > Thanks Duncan. I was thinking if we can use volume_type instead of > available_zone totally. I mean whatever you have, one or many c-vol node, > you can just use volume_type to schedule volume creation on different > backends without using AZs at all. I also think available_zone is useless > if there is only one c-vol node existing. So is it possible that we remove > it from cinder? > Or we should tell admin/users clearly that the available_zone should be > used under multiple c-vol nodes situation. > > 2015-07-20 6:36 GMT+08:00 Duncan Thomas <duncan.tho...@gmail.com>: > >> So this has come up a few times. My question is, does having one node >> serving several backends really form multiple AZs? Not really, the c-vol >> node becomes a single point of failure. >> >> There might be value in moving the AZ setting into the per-backend >> configurables, if it doesn't work there already, for testing if nothing >> else, but I do worry that it encorages people to misunderstand or worse >> intentionally fake multiple AZs. >> >> >> On 19 July 2015 at 05:19, hao wang <sxmatch1...@gmail.com> wrote: >> >>> Hi stackers, >>> >>> I found now cinder only can configure one storage_availability_zone for >>> cinder-volume. If using multi-backend in one cinder-volume node, could we >>> have different AZ for each backend? So that we can specify each backend as >>> a AZ and create volume in this AZ. >>> >>> Regards, >>> Wang Hao >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> -- >> Duncan Thomas >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > Best Wishes For You! > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev