Minimierung von Ausfallzeiten ElastiCache durch die Verwendung Multi-AZ mit Valkey und Redis OSS

Es gibt eine Reihe von Fällen, in denen OSS ElastiCache für Valkey und Redis möglicherweise einen primären Knoten austauschen muss. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls eines primären Knotens oder einer Availability Zone.

Dieser Austausch führt zu einigen Ausfallzeiten für den Cluster, aber wenn er aktiviert Multi-AZ ist, wird die Ausfallzeit minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Read Replicas übertragen. Es ist nicht erforderlich, einen neuen primären Knoten zu erstellen und bereitzustellen, da dies transparent ElastiCache gehandhabt wird. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.

ElastiCache gibt auch den DNS-Namen (Domain Name Service) des hochgestuften Replikats weiter. Auf diese Weise ist in Ihrer Anwendung, falls sie in den primären Endpunkt schreibt, keine Endpunktänderung erforderlich. Wenn Sie aus individuellen Endpunkten lesen, müssen Sie den Leseendpunkt des zum primären Knoten heraufgestuften Replikats in den Endpunkt des neuen Replikats ändern.

Im Falle eines geplanten Knotenaustauschs, der aufgrund von Wartungs- oder Self-Service-Aktualisierungen eingeleitet wird, beachten Sie Folgendes:

Sie können die Aktivierung Multi-AZ über die ElastiCache Management Console AWS CLI, die oder die ElastiCache API vornehmen.

Die Aktivierung ElastiCache Multi-AZ auf Ihrem Valkey- oder Redis OSS-Cluster (in der API und CLI, Replikationsgruppe) verbessert Ihre Fehlertoleranz. Dies gilt insbesondere in Fällen, in denen der read/write primäre Cluster Ihres Clusters nicht mehr erreichbar ist oder aus irgendeinem Grund ausfällt. Multi-AZ wird nur auf Valkey- und Redis OSS-Clustern mit mehr als einem Knoten in jedem Shard unterstützt.

Aktivieren Multi-AZ

Sie können die Multi-AZ Option aktivieren, wenn Sie einen Cluster (API oder CLI, Replikationsgruppe) mithilfe der ElastiCache Konsole oder der ElastiCache API erstellen oder ändern. AWS CLI

Sie können die Option Multi-AZ nur auf Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) aktivieren, für die mindestens ein Read Replica verfügbar ist. Cluster ohne Read Replicas bieten keine hohe Verfügbarkeit oder Fehlertoleranz. Weitere Informationen zum Erstellen eines Clusters mit Replikation finden Sie unter Erstellen einer Valkey- oder Redis OSS-Replikationsgruppe. Weitere Informationen zum Hinzufügen einer Read Replica zu einem Cluster mit Replikation finden Sie unter Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert).

Aktivieren Multi-AZ (Konsole)

Sie können es Multi-AZ mithilfe der ElastiCache Konsole aktivieren, wenn Sie einen neuen Valkey- oder Redis OSS-Cluster erstellen oder indem Sie einen vorhandenen Cluster mit Replikation ändern.

Multi-AZ ist standardmäßig auf Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) aktiviert.

Multi-AZ Wird aktiviert, wenn ein Cluster mithilfe der Konsole erstellt wird ElastiCache

Weitere Informationen zu diesem Vorgang finden Sie unter Erstellen eines Valkey-Clusters (Clustermodus deaktiviert) (Konsole). Stellen Sie sicher, dass Sie über ein oder mehrere Replikate verfügen und aktivieren Sie es Multi-AZ.

Aktivierung Multi-AZ auf einem vorhandenen Cluster (Konsole)

Weitere Informationen zu diesem Prozess finden Sie unter „Ändern eines Clusters“ Unter Verwendung der ElastiCache AWS-Managementkonsole.

Aktivieren Multi-AZ (AWS CLI)

Im folgenden Codebeispiel wird das verwendet AWS CLI , um es Multi-AZ für die Replikationsgruppe zu aktivierenredis12.

Für Linux, macOS oder Unix:

aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Für Windows:

aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

Die JSON-Ausgabe dieses Befehls sollte in etwa folgendermaßen aus.

{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

Weitere Informationen zu diesen Themen finden Sie in der AWS CLI -Befehlsreferenz:

Aktivieren Multi-AZ (ElastiCache API)

Im folgenden Codebeispiel wird die ElastiCache API verwendet, um die Replikationsgruppe zu aktivieren Multi-AZ redis12.

https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Weitere Informationen zu diesen Themen finden Sie in der ElastiCache -API-Befehlsreferenz:

Fehlerszenarien mit Multi-AZ Antworten

Vor der Einführung von Multi-AZ, ElastiCache Erkennung und Ersetzung der ausgefallenen Knoten eines Clusters, indem der ausgefallene Knoten neu erstellt und bereitgestellt wurde. Wenn Sie die Option aktivieren Multi-AZ, führt ein ausgefallener primärer Knoten ein Failover auf das Replikat mit der geringsten Replikationsverzögerung durch. Das ausgewählte Replikat wird automatisch zum primären Knoten heraufgestuft. Dies ist sehr viel schneller, als einen neuen primären Knoten zu erstellen und neu bereitzustellen. Bei diesem Vorgang dauert gewöhnlich nur wenige Sekunden, bis Sie wieder in den Cluster schreiben können.

Wenn diese Option aktiviert Multi-AZ ist, wird der Status des Primärknotens ElastiCache kontinuierlich überwacht. Sollte der primäre Knoten ausfallen, wird abhängig von der Art des Ausfalls eine der folgenden Aktionen durchgeführt.

Fehlerszenarien, wenn nur der Primärknoten ausfällt

Wenn nur der primäre Knoten ausfällt, wird das Read Replica mit der geringsten Replikationsverzögerung wird zum primären Cluster heraufgestuft. Ein Ersatz-Read Replica wird dann in derselben Availability Zone wie der ausgefallene primäre Knoten erstellt und bereitgestellt .

Wenn nur der primäre Knoten ElastiCache Multi-AZ ausfällt, wird Folgendes ausgeführt:

Nachdem das neue Replikat verfügbar ist, beachten Sie die folgenden Effekte:

Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:

Fehlerszenarien, wenn der Primärknoten und einige Read Replicas (Lesereplikate) fehlschlagen

Bei Ausfall des primären Clusters und mindestens einer Read Replica wird das verfügbare Replikat mit der geringsten Replikationsverzögerung zum primären Cluster heraufgestuft. Zudem werden in denselben Availability Zones, in der sich die ausgefallenen Knoten und das zum primären Cluster heraufgestufte Replikat befanden, neue Read Replicas erstellt und bereitgestellt.

Gehen Sie wie folgt vor, wenn der Primärknoten und einige Read Replicas ausfallen: ElastiCache Multi-AZ

Nehmen Sie die folgenden Änderungen an Ihrer Anwendung vor, wenn die neuen Knoten verfügbar sind:

Fehlerszenarien, wenn der gesamte Cluster ausfällt

Bei einem umfassenden Ausfall werden in denselben Availability Zones, der sich die Originalknoten befanden, alle Knoten neu erstellt und bereitgestellt.

In diesem Szenario gehen alle Daten im Cluster aufgrund des Ausfalls eines jeden Knotens im Cluster verloren. Ein solches Ereignis ist selten.

Wenn der gesamte Cluster ElastiCache Multi-AZ ausfällt, gehen Sie wie folgt vor:

Da jeder Ersatzknoten denselben Endpunkt wie der Knoten hat, der durch ihn ersetzt wird, müssen in Ihrer Anwendung keine Endpunktänderungen vorgenommen werden.

Weitere Informationen zum Suchen der Endpunkte einer Replikationsgruppe finden Sie in den folgenden Themen:

Es wird empfohlen, den primären Knoten und die Read Replicas in verschiedenen Availability Zones zu erstellen. Dadurch wird der Grad der Fehlertoleranz erhöht.

Testen des automatischen Failovers

Nachdem Sie das automatische Failover aktiviert haben, können Sie es mithilfe der ElastiCache Konsole AWS CLI, der und der ElastiCache API testen.

Beim Testen ist Folgendes zu beachten:

Testen des automatischen Failovers mit dem AWS-Managementkonsole

Verwenden Sie das folgende Verfahren, um das automatische Failover mit der Konsole zu testen.

Testen Sie das automatische Failover mit dem AWS CLI

Mithilfe des AWS CLI Vorgangs test-failover können Sie das automatische Failover auf jedem Multi-AZ aktivierten Cluster testen.

Im folgenden Beispiel wird der verwendet AWS CLI , um das automatische Failover auf der Knotengruppe redis00-0003 im Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu testen. redis00

aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id 0003

aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id 0003

Die Ausgabe des vorhergehenden Befehls sieht in etwa wie folgt aus.

{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m5.large", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

Verwenden Sie den Vorgang, um den Fortschritt Ihres Failovers zu verfolgen. AWS CLI describe-events

Weitere Informationen finden Sie hier:

Testen Sie das automatische Failover mithilfe der API ElastiCache

Sie können das automatische Failover auf jedem Cluster testen, der Multi-AZ mithilfe des ElastiCache API-Vorgangs TestFailover aktiviert ist.

Das folgende Beispiel testet das automatische Failover auf der Knotengruppe redis00-0003 in der Replikationsgruppe (auf der Konsole im Cluster) redis00.

https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Verwenden Sie den ElastiCache DescribeEvents API-Vorgang, um den Fortschritt Ihres Failovers zu verfolgen.

Weitere Informationen finden Sie hier:

Einschränkungen bei Multi-AZ

Beachten Sie die folgenden Einschränkungen für Multi-AZ: