Você pode alterar o local de preferência indicado ao usar uma testemunha (para um grupo do SRDF/Metro que está ativo e tem um tipo configurado de testemunha). O lado de preferência ou "vencedor" é representado como R1 e o lado de não preferência ou "perdedor" é representado como R2. O comando symrdf fornece um
definir preferência R1 | R2
Opção que altera o local de preferência a ser usado como parte da decisão tomada pela testemunha ao determinar o local que permanece acessível ao host em caso de falha. A preferência é definida no nível do grupo SRDF ou Metro.
Para nos tornar deste recurso é necessário o seguinte:
- Ambos os arrays são PowerMaxOS 5978.711 (e superior)
- O controle de gerenciamento é o Solutions Enabler 10.x e/ou Unisphere for PowerMax 10.x (e versões posteriores)
Exemplo de SYMCLI:
symrdf -sid 001 -sg rdfg1_SG -rdfg 1 set preference R2
Exemplo do Unisphere for PowerMax:
Array SID > Storage > Storage Groups > rdfg1_SG > Set Metro Preference
Ou
Array SID > Dashboard > Replication Dashboard > SRDF/Metro Storage Groups > rdfg1_SG > Set Metro Preference
Nota: Quando o Metro é configurado para usar uma testemunha, a função da testemunha é determinar qual lado da sessão Metro é a melhor opção para permanecer acessível ao host em caso de falha. Os dispositivos, no lado escolhido para permanecer acessível ao host, são relatados como dispositivos R1 e os dispositivos do outro lado são relatados como dispositivos R2 . A escolha feita pela testemunha pode não estar de acordo com a preferência escolhida pelo usuário.
O motivo pelo qual a escolha pode não se alinhar é:
Quando ambos os lados executam o PowerMaxOS, o SRDF/Metro leva em consideração fatores adicionais para determinar o vencedor preferencial (em ordem de prioridade):
- O lado que tem conectividade de host (requer PowerMaxOS 10 (6079) ou PowerMaxOS 5978.444.444 ou posterior) Essa funcionalidade monitora as conexões com o host que são mapeadas para dispositivos SRDF/Metro para verificar se as conexões estão operacionais.
- O lado que tem um valor de gravação pendente (WP) inferior a 80% do limite de WP do sistema (requer PowerMaxOS 5978.669.669 ou posterior)
- O lado oposto do lado que tem uma falha de RAID duplo. Ou seja, dois eixos estão inativos em um grupo RAID 5 ou três eixos estão inativos em um grupo RAID 6 (requer PowerMaxOS 10 (6079)).
- O lado que tem um trecho de DR SRDF/A
- Se o trecho de DR do SRDF/A está sincronizado
- O lado que tem um trecho de DR SRDF/A ativo
- O lado que tem um espelho pronto no trecho de DR do SRDF/A
- O lado que tem mais de 50% dos diretórios RA ou FA disponíveis
- O lado que é o lado preferencial (se o usuário tiver definido um) No PowerMaxOS 10 (6079), o administrador de armazenamento pode especificar o lado preferencial de um par SRDF/Metro.
Em versões anteriores do ambiente operacional, ou quando o administrador não tiver especificado um lado preferencial, o lado R1 será o vencedor.
O primeiro desses critérios que um array tem, e o outro não, interrompe o processo de seleção. O lado com esse critério é o vencedor preferencial.
Os dois lados repetem regularmente esse processo de seleção para cada grupo do SRDF/Metro a fim de garantir que o lado vencedor continue sendo o mais preferível. Portanto, o lado vencedor pode mudar durante a sessão do SRDF/Metro. O SRDF/Metro sempre relata o lado vencedor como o dispositivo R1 e o lado perdedor como R2. Portanto, cada switch no lado vencedor causa uma troca aparente das personalidades R1 e R2 na sessão.
A avaliação dos lados vencedor e perdedor ocorre separadamente para cada grupo do SRDF/Metro existente entre dois arrays. Portanto, em um array específico, alguns dispositivos podem ser dispositivos R1, enquanto outros são dispositivos R2. Quais são R1 e quais são R2 dependem do resultado da avaliação de seus respectivos grupos SRDF/Metro.
Então, em resumo, depois de definir a preferência de um grupo do SRDF/Metro para um lado (Array A), se o outro lado (Array B) tiver um dos critérios acima que o Array A não tem, a preferência será atribuída ao Array B.
Para explicar isso melhor, considere o exemplo a seguir.
O array A tem dispositivos rdfg 100 atualmente R1, o array B tem dispositivos rdfg 100 atualmente R2.
O array A tem rdfg 100 dispositivos em uma visualização de mascaramento cujas portas front-end estão on-line e o switch de fabric conectado.
O array B tem rdfg 100 dispositivos não atribuídos (o que significa que não está em nenhuma visualização de mascaramento, portanto, não está disponível em nenhuma porta front-end).
Em seguida, o comando abaixo retornaria: O dispositivo já está no estado solicitado
symrdf -sid Array A -sg <sg> set preference R2
e no symapi.log retorna - O dispositivo já está no estado solicitado
sg <sg>: Set type Preference R2
Portanto, como o array A tem conectividade de host para dispositivos rdfg 100 e o array B não tem conectividade de host para dispositivos rdfg 100, o raio ArA permanece como o vencedor preferencial (R1), pois os dois arrays para rdfg 100 diferem no critério 1.
A opção
de preferência definida só é permitida para um grupo ativo do SRDF/Metro que tenha um
Typ e de Witness configurado. Um grupo ativo do SRDF/Metro pode ter diferentes combinações de Pairstate e Witness Status.
Usando uma convenção de nomenclatura de
<Pairstate> - <Configured Type> - <Effective Type> - <Witness Status>
para representar as combinações e:
Pairstate AA é ActiveActive e AB é ActiveBias
Configured Type W é Witness
Effective Type W é Witness e B é Bias
Witness Status N é Normal, D está degradado e F está com falha
A tabela a seguir informa o status da combinação após uma alteração de preferência:
|
Status atual
|
Status após definir alteração de preferência
|
| AA - W - W - N |
AA - W - W - N |
|
AA - W - W - D
|
AB - W - B - F
|
|
AB - W - B - F
|
AB - W - B - F
|