ECS: Differenze tra la stringa di connessione CAS e il failover di lettura SDK con Centera

Quando ci si connette a un ECS utilizzando il protocollo CAS (Content Addressable Storage) con JCASScript, quando si esegue info , l'indirizzo di replica è vuoto.

In che modo viene eseguito il failover dell'SDK durante le letture se l'ECS primario non è disponibile?
Centera ed ECS funzionano in modo diverso durante la risposta alla sonda iniziale dopo l'apertura del pool SDK.

Centera:
Se si forniscono gli indirizzi IP primari di Centera nella stringa di connessione come parte del probe iniziale e dopo l'apertura del pool, Centera invia nuovamente all'SDK gli indirizzi IP di replica nella risposta del probe. L'SDK usa questi IP di replica per il failover operativo (letture, scritture, eliminazioni, esistenti) al momento del failover primario o di connessione (arresti Centera o dalla rete agli arresti primari).

Se l'opzione SDK lazy_pool_open , l'SDK non esegue il probe di indirizzi secondari. Gli indirizzi secondari vengono analizzati in caso di failover operativo o di rete.

ECS:
Se si specifica solo l'indirizzo IP primario nella stringa di connessione dell'applicazione come parte della risposta probe iniziale dopo l'apertura del pool, ECS non restituisce gli indirizzi IP di replica nella risposta probe. L'SDK non è a conoscenza degli indirizzi IP secondari. In ECS, un bucket è globale ed è progettato per fornire una solida coerenza. Quando si scrivono oggetti, ECS recupera l'oggetto indipendentemente dallo stato di replica. Ciò fornisce il failover operativo (lettura, scrittura, esistenza ed eliminazione) da qualsiasi data center virtuale (VDC).

Per il failover della connessione è consigliabile avere indirizzi primari e secondari nella stringa di connessione.

L'SDK analizza prima il primo IP nella stringa di connessione. Quando riceve tutti gli IP VDC primari, come parte del probe l'SDK non esegue il probe di altri IP nella stringa di connessione (come con lazy_pool). Utilizza altri IP nella stringa di connessione per il failover della connessione.

Pool normali aperti (non in uso lazy_pool open - consigliato da Engineering) esegue prima il probing del primo IP nella stringa di connessione. Una volta ricevuta la risposta, separa logicamente l'indirizzo primario ed esegue il probing solo dell'IP secondario successivo nella connessione e mantiene tutti gli indirizzi IP secondari nella cache. Se non è possibile raggiungere il VDC primario, se Access During Outage (ADO) (timeout di 15 minuti) è abilitato, tenta tutti gli IP primari (come Centera). Dopo che tutti gli IP generano errori di rete, tenta l'IP secondario. Una volta che si verifica il timeout ADO di 15 minuti, il VDC secondario dà accesso alle operazioni di lettura, scrittura, eliminazione ed esistenza.

Se non si utilizzano gli indirizzi IP secondari nella stringa di connessione e se il VDC primario ha esito negativo o perde la connettività di rete. La stringa di connessione dell'applicazione deve essere aggiornata manualmente per includere gli IP del VDC secondario per accedere al VDC secondario. Il timeout ADO di 15 minuti deve trascorrere prima che le operazioni funzionino.