On 08/03/2016 02:17 AM, Sebastian Herbszt wrote:
> Xose Vazquez Perez wrote:
>> On 07/31/2016 09:06 PM, Sebastian Herbszt wrote:
>>
>>> Xose Vazquez Perez wrote:
>>>>
>>>> No. It's related to hardware_handler, "alua" in this case.
>>>
>>> So how does the output of 'multipath -ll' looks like for persona 1 and 2
>>> with and without 'retain_attached_hw_handler'?
>>
>> retain_attached_hw_handler is innocuous.
>> The paths grouping policy is controlled by the "path_grouping_policy" keyword,
>> multibus vs. group_by_prio. See man page.
>
> multibus should equal
>
> path_grouping_policy = group_by_prio
> prio = const
>
>> Persona 1 and 2 basically is the same, but:
>>
>> Persona 1: path_grouping_policy = multibus
>> failback = manual
>> prio = const
>>
>> Persona 2: path_grouping_policy = group_by_prio
>> failback = immediate
>> prio = alua (this is irrelevant, alua-prio is autodetected)
>> hardware_handler= "1 alua" (this is irrelevant, all hardware handlers are autodetected)
>>
>> With 3PAR-OS 3.1.3, or later, you should use "Persona 2"
>
> The above change plus
>
> retain_attached_hw_handler = yes
> detect_prio = yes
>
> should work with persona 1 and 2.
3PAR arrays are Symmetric Active/Active and with ALUA support.
- With Persona 1/Generic(UARepLun, SESLun), only one mode is supported:
o Symmetric Active/Active
{
.vendor = "3PARdata",
.product = "VV",
.pgpolicy = MULTIBUS,
.no_path_retry = 18,
},
- With Persona 2/Generic-ALUA(UARepLun, SESLun, ALUA), both of them are supported:
o Symmetric Active/Active
{
.vendor = "3PARdata",
.product = "VV",
.pgpolicy = MULTIBUS,
.no_path_retry = 18,
},
o Symmetric Active/Active + ALUA
{
.vendor = "3PARdata",
.product = "VV",
.pgpolicy = GROUP_BY_PRIO,
.pgfailback = -FAILBACK_IMMEDIATE,
.hwhandler = "1 alua",
.prio_name = PRIO_ALUA,
.no_path_retry = 18,
},
Thera are also others Symmetric Active/Active arrays with support of ALUA.
At least, EMC/SYMMETRIX and IBM/2810XIV.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
