ECS: Unterschiede zwischen CAS-Verbindungszeichenfolge und SDK-Lese-Failover bei Centera

Wenn Sie eine Verbindung zu einem ECS über das CAS-Protokoll (Content Addressable Storage) mit JCASScript herstellen und die info ist die Replikatadresse leer.

Wie führt das SDK ein Failover während Lesevorgängen durch, wenn der primäre ECS nicht verfügbar ist?
Centera und ECS funktionieren unterschiedlich, wenn sie auf den ersten Test reagieren, nachdem der SDK-Pool geöffnet ist.

Centera:
Wenn die primären Centera-IPs in der Verbindungszeichenfolge als Teil des ersten Tests und nach dem Öffnen des Pools angegeben werden, sendet Centera die Replikat-IP-Adressen in der Testantwort an das SDK zurück. Das SDK verwendet diese Replikat-IPs für betriebliches Failover (Lesen, Schreiben, Löschen, Vorhanden) beim Primär- oder Verbindungs-Failover (Centera-Stopps oder Netzwerk zu primären Stopps).

Wenn die SDK-Option lazy_pool_open verwendet wird, führt das SDK keine Tests zu sekundären Adressen durch. Sekundäre Adressen werden geprüft, wenn ein Betriebs- oder Netzwerk-Failover vorliegt.

ECS:
Wenn Sie nur die primäre IP-Adresse in der Anwendungsverbindungszeichenfolge als Teil der anfänglichen Testantwort nach dem Öffnen des Pools angeben, sendet ECS keine Replikat-IP-Adressen in der Testantwort zurück. Das SDK kennt die sekundären IP-Adressen nicht. In ECS ist ein Bucket global und so konzipiert, dass er starke Konsistenz bietet. Wenn Objekte geschrieben werden, ruft ECS das Objekt unabhängig vom Replikationsstatus ab. Dies bietet betriebliches Failover (Lesen, Schreiben, Bestehen und Löschen) von jedem virtuellen Rechenzentrum (VDC).

Für das Verbindungs-Failover werden primäre und sekundäre Adressen in der Verbindungszeichenfolge empfohlen.

Das SDK testet zunächst die erste IP-Adresse in der Verbindungszeichenfolge. Wenn alle primären VDC-IPs empfangen werden, prüft das SDK als Teil des Tests keine anderen IPs in der Verbindungszeichenfolge (wie bei lazy_pool). Es verwendet andere IP-Adressen in der Verbindungszeichenfolge für Verbindungs-Failover.

Normale, offene Pools (nicht mit lazy_pool open - was das Engineering empfiehlt) zuerst die erste IP in der Verbindungszeichenfolge prüfen. Sobald die Antwort empfangen wird, trennt es die primäre Adresse logisch und prüft nur die nächste sekundäre IP in der Verbindung, während alle sekundären IP-Adressen im Cache bleiben. Wenn das primäre VDC nicht erreicht werden kann, werden bei aktivierter Option Access During Outage (ADO) (15-Minuten-Timeout) alle primären IPs (wie bei Centera) versucht. Nachdem alle IP-Adressen Netzwerkfehler ausgelöst haben, versucht es die sekundäre IP. Sobald das 15-minütige ADO-Timeout auftritt, bietet das sekundäre VDC Zugriff auf Lese-, Schreib-, Lösch- und Existenzvorgänge.

Wenn die sekundären IP-Adressen in der Verbindungszeichenfolge nicht verwendet werden und wenn das primäre VDC ausfällt oder die Netzwerkverbindung verliert. Die Verbindungszeichenfolge der Anwendung muss manuell aktualisiert werden, um die sekundären VDC-IPs für den Zugriff auf das sekundäre VDC einzuschließen. Das ADO-Timeout von 15 Minuten muss verstreichen, bevor Vorgänge ausgeführt werden können.