ECS : Chaînes de connexion CAS et différences de basculement de lecture du SDK avec Centera

Lors de la connexion à ECS à l’aide du protocole CAS (Content Addressable Storage) avec JCASScript, lors de l’exécution de info , l’adresse du réplica est vide.

Comment le SDK bascule-t-il pendant les lectures si l’ECS principal n’est pas disponible ?
Centera et ECS fonctionnent différemment lorsqu’ils répondent à l’examen initial une fois le pool du SDK ouvert.

Centera :
Si vous fournissez les adresses IP Centera principales dans la chaîne de connexion dans le cadre de l’exploration initiale et après l’ouverture du pool, Centera renvoie les adresses IP du réplica dans la réponse de l’examen au SDK. Le Kit de développement logiciel (SDK) utilise ces adresses IP de réplica pour le basculement opérationnel (lectures, écritures, suppressions, existantes) lors d’un basculement principal ou d’un basculement de connexion (arrêts Centera ou arrêts réseau vers principal).

Si l’option SDK lazy_pool_open est utilisé, le SDK n’explore pas les adresses secondaires. Les adresses secondaires sont analysées en cas de basculement opérationnel ou réseau.

ECS:
Si vous spécifiez uniquement l’adresse IP principale dans la chaîne de connexion de l’application dans le cadre de la réponse initiale de l’examen après l’ouverture du pool, ECS ne renvoie pas les adresses IP du réplica dans la réponse d’examen. Le SDK ne connaît pas les adresses IP secondaires. Dans ECS, un bucket est global et conçu pour fournir une forte cohérence. Lors de l’écriture d’objets, ECS extrait l’objet, quel que soit l’état de réplication. Cela permet un basculement opérationnel (lecture, écriture, existence et suppression) à partir de n’importe quel datacenter virtuel (VDC).

Il est recommandé d’avoir des adresses principales et secondaires dans la chaîne de connexion pour le basculement de connexion.

Le SDK explore d’abord la première adresse IP de la chaîne de connexion. Lorsqu’il reçoit toutes les adresses IP du VDC principal, dans le cadre de l’exploration, le SDK ne sonde pas les autres adresses IP de la chaîne de connexion (comme avec lazy_pool). Il utilise d’autres adresses IP dans la chaîne de connexion pour le basculement de connexion.

Pools normaux ouverts (n’utilisant pas lazy_pool open - ce que l’ingénierie recommande) sonde d’abord la première adresse IP de la chaîne de connexion. Une fois qu’il reçoit la réponse, il sépare logiquement l’adresse principale et sonde uniquement l’adresse IP secondaire suivante dans la connexion et conserve toutes les adresses IP secondaires dans le cache. Si le VDC principal n’est pas accessible, si l’option Access During Outage (ADO) (délai d’expiration de 15 minutes) est activée, il essaie toutes les adresses IP principales (de la même manière que Centera). Une fois que toutes les adresses IP ont généré des erreurs réseau, il essaie l’adresse IP secondaire. Une fois le délai d’expiration ADO de 15 minutes écoulé, le VDC secondaire donne accès aux opérations de lecture, d’écriture, de suppression et existantes.

Si vous n’utilisez pas les adresses IP secondaires dans la chaîne de connexion, et si le VDC principal échoue ou perd la connectivité réseau. La chaîne de connexion de l’application doit être mise à jour manuellement pour inclure les adresses IP du VDC secondaire permettant d’accéder au VDC secondaire. Le délai d’expiration ADO de 15 minutes doit s’écouler avant que les opérations fonctionnent.