ECS: Diferenças entre string de conexão CAS e failover de leitura do SDK com o Centera

Ao se conectar a um ECS usando o protocolo CAS (Content Addressable Storage) com JCASScript, ao executar o info , endereço de réplica vazio.

Como o failover do SDK durante as leituras se o ECS primário não estiver disponível?
O Centera e o ECS funcionam de maneira diferente ao responder ao probe inicial depois que o pool do SDK é aberto.

Centera:
Se estiver fornecendo os IPs primários do Centera na string de conexão como parte do teste inicial e depois que o pool for aberto, o Centera enviará de volta os endereços IP da réplica na resposta do teste para o SDK. O SDK usa esses IPs de réplica para failover operacional (leituras, gravações, exclusões, existem) após o failover primário ou de conexão (o Centera para ou a rede para a primária para).

Se a opção SDK lazy_pool_open é usado, então o SDK não investiga endereços secundários. Os endereços secundários são investigados se houver um failover operacional ou de rede.

ECS:
Se especificar apenas o endereço IP primário na string de conexão do aplicativo como parte da resposta inicial do probe após a abertura do pool, o ECS não retornará endereços IP de réplica na resposta do probe. O SDK não sabe sobre os endereços IP secundários. No ECS, um bucket é global e foi projetado para oferecer consistência sólida. Ao gravar objetos, o ECS busca o objeto independentemente do status de replicação. Isso fornece failover operacional (leitura, gravação, existência e exclusão) de qualquer data center virtual (VDC).

É recomendável ter endereços primários e secundários na string de conexão para failover de conexão.

O SDK primeiro investiga o primeiro IP na cadeia de conexão. Quando recebe todos os IPs primários do VDC, como parte do teste, o SDK não investiga outros IPs na cadeia de conexão (como acontece com lazy_pool). Ele usa outros IPs na string de conexão para failover de conexão.

Pools normais abertos (não usando lazy_pool open - que a Engenharia recomenda) primeiro sondar o primeiro IP na cadeia de conexão. Depois de receber a resposta, ele separa logicamente o endereço primário e investiga apenas o próximo IP secundário na conexão e mantém todos os endereços IP secundários no cache. Se não for possível acessar o VDC principal, se o Access During Outage (ADO) (tempo de espera excedido de 15 minutos) estiver ativado, ele tentará todos os IPs principais (o mesmo que Centera). Depois que todos os IPs lançam erros de rede, ele tenta o IP secundário. Depois que ocorre o tempo de espera excedido do ADO de 15 minutos, o VDC secundário dá acesso às operações de leitura, gravação, exclusão e existentes.

Se não estiver usando os IPs secundários na cadeia de conexão e se o VDC principal falhar ou perder a conectividade de rede. A string de conexão do aplicativo deve ser atualizada manualmente para incluir os IPs do VDC secundário para acessar o VDC secundário. O tempo de espera excedido do ADO de 15 minutos deve decorrer antes que as operações funcionem.