Thanks Duncan! It make me clearer about AZ, and I agree with you that we should work on making users/admins know how to use AZ and volume_type correctly.
2015-07-20 17:27 GMT+08:00 Duncan Thomas <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >> >>> 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 <[email protected]> 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: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> -- >>> Duncan Thomas >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?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: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > -- > Duncan Thomas > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
