ECS: Diferencias entre la cadena de conexión de CAS y la conmutación por error de lectura de SDK con Centera

Cuando se conecta a un ECS mediante el protocolo de almacenamiento de contenido direccionable (CAS) con JCASScript, cuando se ejecuta el info , la dirección de la réplica está vacía.

¿Cómo realiza la conmutación por error de SDK durante las lecturas si el ECS principal no está disponible?
Centera y ECS funcionan de manera diferente cuando responden al sondeo inicial después de que se abre el grupo de SDK.

Centera:
Si se suministran las direcciones IP de Centera principales en la cadena de conexión como parte del sondeo inicial y después de que se abra el pool, Centera envía de vuelta las direcciones IP de réplica en la respuesta de sondeo al SDK. El SDK utiliza estas direcciones IP de réplica para la conmutación por error operacional (lecturas, escrituras, eliminaciones, existencias) tras la conmutación por error primaria o de conexión (se detiene Centera o se detiene la red a la primaria).

Si la opción SDK lazy_pool_open y, a continuación, el SDK no sondea las direcciones secundarias. Las direcciones secundarias se sondean si hay una conmutación por error operacional o de red.

ECS:
Si se especifica solo la dirección IP primaria en la cadena de conexión de la aplicación como parte de la respuesta de sondeo inicial después de que se abre el pool, ECS no envía direcciones IP de réplica en la respuesta del sondeo. El SDK no conoce las direcciones IP secundarias. En ECS, un depósito es global y está diseñado para proporcionar una coherencia sólida. Cuando se escriben objetos, ECS recupera el objeto independientemente del estado de la replicación. Esto proporciona conmutación por error operacional (lectura, escritura, existencia y eliminación) desde cualquier centro de datos virtual (VDC).

Se recomienda tener direcciones principales y secundarias en la cadena de conexión para la conmutación por error de la conexión.

En primer lugar, el SDK sondea la primera dirección IP de la cadena de conexión. Cuando recibe todas las direcciones IP de VDC primarias, como parte del sondeo, el SDK no sondea otras direcciones IP en la cadena de conexión (como con lazy_pool). Utiliza otras direcciones IP en la cadena de conexión para la conmutación por error de conexión.

Pools normales abiertos (sin usar lazy_pool open - que Engineering recomienda) primero sondear la primera IP en la cadena de conexión. Una vez que recibe la respuesta, separa lógicamente la dirección principal y sondea solo la siguiente dirección IP secundaria en la conexión y mantiene todas las direcciones IP secundarias en la caché. Si no se puede acceder al VDC primario, si Access During Outage (ADO) (tiempo de espera agotado de 15 minutos) está habilitado, entonces prueba todas las IP primarias (igual que Centera). Después de que todas las IP arrojan errores de red, intenta con la IP secundaria. Una vez que se agota el tiempo de espera de ADO de 15 minutos, el VDC secundario otorga acceso a las operaciones de lectura, escritura, eliminación y existencia.

Si no se utilizan las direcciones IP secundarias en la cadena de conexión, y si el VDC primario falla o pierde la conectividad de red. La cadena de conexión de la aplicación se debe actualizar manualmente para incluir las direcciones IP del VDC secundario a fin de acceder al VDC secundario. Debe transcurrir el tiempo de espera de ADO de 15 minutos antes de que funcionen las operaciones.