Open Stack

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 <duncan.thomas at gmail.com>:

> 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 <sxmatch1986 at 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.thomas at 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 <sxmatch1986 at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best Wishes For You!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150721/dfc66c6c/attachment.html>