Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products

PowerMaxOS: Cómo configurar la preferencia de SRDF Metro para los grupos protegidos testigo

Summary: PowerMaxOS: ¿Cómo configurar la preferencia de SRDF o Metro para los grupos protegidos testigo?

This article applies to   This article does not apply to 

Instructions

Puede cambiar el sitio de preferencia indicado cuando utiliza un testigo (para un grupo de SRDF/Metro que está activo y tiene un tipo de testigo configurado ). La preferencia o lado "ganador" se representa como R1 y el lado sin preferencia o "perdedor" se representa como R2. El comando symrdf proporciona una
establecer preferencia R1 | R2
Opción que cambia el sitio de preferencia que se utilizará como parte de la decisión tomada por el testigo al determinar el sitio que permanece accesible para el host en caso de una falla. La preferencia se establece en el nivel de grupo de SRDF o Metro.
Para hacernos uso de esta característica se requiere:
  • Ambos arreglos son PowerMaxOS 5978.711 (y versiones posteriores)
  • El control de administración es Solutions Enabler 10.x o Unisphere para PowerMax 10.x (y superior)
Ejemplo de SYMCLI:
symrdf -sid 001 -sg rdfg1_SG -rdfg 1 set preference R2
Ejemplo de Unisphere para PowerMax:
Array SID > Storage > Storage Groups > rdfg1_SG > Set Metro Preference
O bien,
Array SID > Dashboard > Replication Dashboard > SRDF/Metro Storage Groups > rdfg1_SG > Set Metro Preference

Additional Information

NOTA: Cuando Metro está configurado para usar un testigo, la función del testigo es determinar qué lado de la sesión de Metro es la mejor opción para permanecer accesible para el host si se produce una falla. Los dispositivos, en el lado que se elige para permanecer accesible para el host, se informan como dispositivos R1 y los otros dispositivos laterales se informan como dispositivos R2 . Es posible que la elección que hace el testigo no se alinee con la preferencia que elige el usuario.

La razón por la que es posible que la elección no coincida es: 
Cuando ambos lados ejecutan PowerMaxOS, SRDF/Metro toma en cuenta factores adicionales para determinar el ganador recomendado (en orden de prioridad):
  1. El lado que tiene conectividad de host (requiere PowerMaxOS 10 (6079) o PowerMaxOS 5978.444.444 o posterior) Esta funcionalidad monitorea las conexiones al host que están asignadas a dispositivos SRDF/Metro para comprobar que las conexiones estén operativas.
  2. El lado que tiene un valor de escritura pendiente (WP) inferior al 80 % del límite de WP del sistema (requiere PowerMaxOS 5978.669.669 o superior)
  3. El lado opuesto del lado que tiene una falla de RAID doble. Es decir, dos ejes inactivos en un grupo RAID 5 o tres ejes inactivos en un grupo RAID 6 (requiere PowerMaxOS 10 (6079)).
  4. El lado que tiene una sección de recuperación ante desastres de SRDF/A
  5. Si la sección de recuperación ante desastres de SRDF/A está sincronizada
  6. El lado que tiene una sección de recuperación ante desastres de SRDF/A activa
  7. El lado que tiene un espejo listo en la sección de recuperación ante desastres de SRDF/A
  8. El lado que tiene más del 50 % de los directores RA o FA disponibles 
  9. El lado que es el lado preferido (si el usuario ha configurado uno) Desde PowerMaxOS 10 (6079), el administrador de almacenamiento puede especificar el lado preferido de un par de SRDF/Metro.
En versiones anteriores del entorno operativo, o cuando el administrador no ha especificado un lado preferido, el lado R1 es el ganador.
El primero de estos criterios que tiene un arreglo, y el otro no, detiene el proceso de selección. El lado con esos criterios es el ganador recomendado.
Los dos lados repiten regularmente este proceso de selección para cada grupo de SRDF/Metro a fin de garantizar que el lado ganador siga siendo el más preferible. Por lo tanto, el lado ganador puede cambiar durante la sesión de SRDF/Metro. SRDF/Metro siempre informa el lado ganador como el dispositivo R1 y el lado perdedor como R2. Por lo tanto, cada cambio en el lado ganador provoca un intercambio aparente de las personalidades R1 y R2 en la sesión.
La evaluación de los lados ganador y perdedor se produce por separado para cada grupo de SRDF/Metro que existe entre dos arreglos. Por lo tanto, en un arreglo en particular, algunos dispositivos podrían ser dispositivos R1, mientras que otros son dispositivos R2. Cuáles son R1 y cuáles son R2 depende del resultado de la evaluación de sus respectivos grupos de SRDF/Metro.

En resumen, después de configurar la preferencia de un grupo de SRDF/Metro en un lado (arreglo A), si el otro lado (arreglo B) tiene uno de los criterios anteriores que el arreglo A no tiene, la preferencia se asigna al arreglo B. 
Para explicar esto con más detalle, considere el siguiente ejemplo.
El arreglo A tiene dispositivos rdfg 100 actualmente R1, el arreglo B tiene dispositivos rdfg 100 actualmente R2.
El arreglo A tiene dispositivos rdfg 100 en una vista de enmascaramiento cuyos puertos de front-end están en línea y el switch de fabric está conectado.
El arreglo B tiene dispositivos rdfg 100 sin asignar (lo que significa que no están en ninguna vista de enmascaramiento, por lo que no están disponibles en ningún puerto de front-end).
 
Entonces, el siguiente comando regresaría: El dispositivo ya está en el estado solicitado
symrdf -sid Array A -sg <sg> set preference R2
y en el symapi.log devoluciones: el dispositivo ya está en el estado solicitado
sg <sg>: Set type Preference R2
Por lo tanto, dado que el arreglo A tiene conectividad de host para dispositivos rdfg 100 y el arreglo B no tiene conectividad de host para dispositivos rdfg 100, entonces Array A permanece como el ganador recomendado (R1), ya que los dos arreglos para rdfg 100 difieren en el criterio 1.

La opción Set Preference solo está permitida para un grupo de SRDF/Metro activo que tiene un tipo configuradode testigo. Un grupo SRDF/Metro activo puede tener diferentes combinaciones de estado de par y estado testigo.
Uso de una convención de nomenclatura de estado de pares> - <tipo> configurado - <tipo> efectivo - <estado>testigo< pararepresentar las combinaciones y
lo siguiente:
El estado del par AA es ActiveActive y AB es ActiveBias configurado El
tipo W es el testigo
eficaz El tipo W es testigo y B es el estado del testigo con polarización
N es Normal, D es Degradado y F es Fallido
La siguiente tabla informa el estado de la combinación después de un cambio de preferencia:
 
 Estado actual
 Estado después del cambio de preferencia establecida
 AA - W - W - N AA - W - W - N
 AA - W - W - D
AB - W - B - F
 AB - W - B - F
AB - W - B - F

Affected Products

PowerMaxOS 10
Article Properties
Article Number: 000209777
Article Type: How To
Last Modified: 25 Apr 2024
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.