DAXCluster-Komponenten

Ein Amazon DynamoDB Accelerator (DAX) -Cluster besteht aus AWS Infrastrukturkomponenten. In diesem Abschnitt werden diese Komponenten und ihre Zusammenarbeit beschrieben.

Knoten

Ein Knoten ist der kleinste Baustein eines DAX-Clusters. Jeder Knoten führt eine Instance der DAX-Software aus und unterhält ein einzelnes Replikat der zwischengespeicherten Daten.

Sie können Ihren DAX-Cluster auf zwei Arten skalieren:

• Durch Hinzufügen weiterer Knoten im Cluster. Dies erhöht den Gesamt-Lesedurchsatz des Clusters.

• Durch das Verwenden eines größeren Knotentyps. Größere Knotentypen bieten mehr Kapazität und können den Durchsatz erhöhen. (Sie müssen einen neuen Cluster mit dem neuen Knotentyp erstellen.)

Jeder Knoten in einem Cluster hat denselben Knotentyp und führt dieselbe DAX-Caching-Software aus. Eine Liste der verfügbaren Knotentypen finden Sie unter Amazon-DynamoDB-Preise.

Cluster

Ein Cluster ist eine logische Gruppierung von einem oder mehreren Knoten, die DAX als Einheit verwaltet. Einer der Knoten im Cluster wird als primärer Knoten ausgewiesen und die anderen Knoten (falls vorhanden) sind Read Replicas.

Der primäre Knoten ist für Folgendes verantwortlich:

• Erfüllen der Anwendungsanforderungen für zwischengespeicherte Daten.

• Handhaben der Schreiboperationen in DynamoDB.

• Bereinigen von Daten aus dem Cache, entsprechend der Bereinigungsrichtlinie des Clusters.

Wenn Änderungen an zwischengespeicherten Daten auf dem primären Knoten vorgenommen werden, werden die Änderungen mithilfe von DAX Replikationsprotokollen an alle Read-Replica-Knoten weitergegeben. Nachdem die Bestätigung von allen Lesereplikaten eingegangen ist, löscht DynamoDB die Replikationsprotokolle vom Primärknoten.

Ein DAX Cluster kann bis zu 11 Knoten pro Cluster unterstützen (der primäre Knoten plus maximal 10 Read Replicas).

Read Replicas sind verantwortlich für Folgendes:

• Erfüllen der Anwendungsanforderungen für zwischengespeicherte Daten.

• Bereinigen von Daten aus dem Cache, entsprechend der Bereinigungsrichtlinie des Clusters.

Im Gegensatz zu dem primären Knoten schreiben Lesereplikate jedoch nicht in DynamoDB.

Read Replicas dienen zwei zusätzlichen Zwecken:

• Skalierbarkeit. Wenn Sie über eine große Anzahl von Anwendungs-Clients verfügen, die gleichzeitig auf DAX zugreifen müssen, können Sie weitere Replicas für die Leseskalierung hinzufügen. DAX verteilt die Last gleichmäßig auf alle Knoten im Cluster. (Eine weitere Möglichkeit zur Erhöhung des Durchsatzes ist die Verwendung größerer Cache-Knoten-Typen.)

• Hohe Verfügbarkeit. Beim Ausfall eines primären Knotens, schaltet DAX automatisch auf eine Read Replica um und bestimmt sie zum neuen primären Knoten. Wenn ein Replica-Knoten ausfällt, können andere Instances im DAX-Cluster nach wie vor für die Bearbeitung von Anfragen verwendet werden, bis der ausgefallene Knoten wiederhergestellt werden kann. Für maximale Fehlertoleranz sollten Sie Read Replicas in separaten Availability Zones (Verfügbarkeitszonen) bereitstellen. Diese Konfiguration stellt sicher, dass Ihr DAX-Cluster weiterhin ausgeführt werden kann, auch wenn die gesamte Availability Zone nicht mehr verfügbar ist.

Wichtig

Für die Produktionsnutzung empfehlen wir dringend, DAX mit mindestens drei Knoten zu verwenden, in dem die Knoten in verschiedene Availability Zones platziert werden. Drei Knoten sind aus Gründen der Fehlertoleranz für einen DAX-Cluster erforderlich.

Ein DAX-Cluster kann für Bereitstellungs- oder Testarbeitslasten mit nur einem oder zwei Knoten bereitgestellt werden. Cluster mit einem und zwei Knoten sind nicht fehlertolerant, und wir empfehlen nicht, weniger als drei Knoten für den Produktionseinsatz zu verwenden. Wenn bei einem Cluster mit einem oder zwei Knoten Software- oder Hardwarefehler auftreten, kann der Cluster nicht mehr verfügbar sein oder zwischengespeicherte Daten verlieren.

Wichtig

Ein DAX Cluster unterstützt maximal 500 DynamoDB-Tabellen. Wenn Sie mehr als 500 Tabellen verwenden, kann es bei Ihrem Cluster zu einer Verschlechterung der Verfügbarkeit und Leistung kommen.

Regionen und Availability Zones

Ein DAX Cluster in einer AWS Region kann nur mit DynamoDB-Tabellen interagieren, die sich in derselben Region befinden. Stellen Sie daher sicher, dass Sie Ihren DAX-Cluster in der richtigen Region starten. Wenn Sie DynamoDB-Tabellen in anderen Regionen haben, müssen Sie auch DAX Cluster in diesen Regionen starten.

Jede -Region ist darauf ausgelegt, vollständig von den anderen -Regionen getrennt zu sein. Innerhalb jeder Region gibt es mehrere Availability Zones. Durch das Starten Ihrer Knoten in verschiedenen Availability Zones können Sie eine größtmögliche Fehlertoleranz zu erreichen.

Wichtig

Platzieren Sie nicht alle Ihre Cluster-Knoten in eine einzige Availability Zone. Bei dieser Konfiguration ist Ihr DAX-Cluster bei einem Ausfall einer Availability Zone nicht mehr verfügbar.

Für die Produktionsnutzung empfehlen wir dringend, DAX mit mindestens drei Knoten zu verwenden, in dem die Knoten in verschiedene Availability Zones platziert werden. Drei Knoten sind aus Gründen der Fehlertoleranz für einen DAX-Cluster erforderlich.

Ein DAX-Cluster kann für Bereitstellungs- oder Testarbeitslasten mit nur einem oder zwei Knoten bereitgestellt werden. Cluster mit einem oder zwei Knoten sind jedoch nicht fehlertolerant. Für die Produktionsnutzung empfehlen wir daher die Nutzung von mindestens drei Knoten. Wenn bei Clustern mit einem oder zwei Knoten Software- oder Hardwarefehler auftreten, ist der Cluster möglicherweise nicht mehr verfügbar oder es gehen zwischengespeicherte Daten verloren.

Parametergruppen

Parametergruppen werden verwendet, um Laufzeiteinstellungen für DAX Cluster zu verwalten. DAXverfügt über mehrere Parameter, mit denen Sie die Leistung optimieren können (z. B. die Definition einer TTL Richtlinie für zwischengespeicherte Daten). Eine Parametergruppe ist eine benannte Sammlung von Parametern, die Sie einem Cluster zuweisen können. Dadurch stellen Sie sicher, dass alle Knoten in diesem Cluster identisch konfiguriert werden.

Sicherheitsgruppen

Ein DAX Cluster wird in einer Amazon Virtual Private Cloud (AmazonVPC) -Umgebung ausgeführt. Diese Umgebung ist ein virtuelles Netzwerk, das Ihrem AWS Konto zugewiesen und von anderen isoliert istVPCs. Eine Sicherheitsgruppe fungiert als virtuelle Firewall für Sie und ermöglicht es IhnenVPC, den ein- und ausgehenden Netzwerkverkehr zu kontrollieren.

Wenn Sie einen Cluster in Ihrem startenVPC, fügen Sie Ihrer Sicherheitsgruppe eine Eingangsregel hinzu, um eingehenden Netzwerkverkehr zuzulassen. Die Eingangsregel gibt das Protokoll (TCP) und die Portnummer (8111) für Ihren Cluster an. Nachdem Sie diese Regel zu Ihrer Sicherheitsgruppe hinzugefügt haben, VPC können die Anwendungen, die in Ihrem System ausgeführt werden, auf den DAX Cluster zugreifen.

Cluster ARN

Jedem DAX Cluster wird ein Amazon-Ressourcenname (ARN) zugewiesen. Das ARN Format ist wie folgt.

arn:aws:dax:region:accountID:cache/clusterName

Sie verwenden den Cluster ARN in einer IAM Richtlinie, um Berechtigungen für DAX API Operationen zu definieren. Weitere Informationen finden Sie unter DAXZugriffskontrolle.

Cluster-Endpunkt

Jeder DAX-Cluster stellt einen Cluster-Endpunkt für die Anwendung bereit. Durch den Zugriff auf den Cluster mithilfe des Endpunkts muss Ihre Anwendung die Hostnamen und Portnummern einzelner Knoten im Cluster nicht kennen. Ihre Anwendung "kennt" automatisch alle Knoten im Cluster, auch wenn Sie Read Replicas hinzufügen oder entfernen.

Das folgende Beispiel zeigt einen Cluster-Endpunkt in der Region us-east-1, der nicht für die Verwendung der Verschlüsselung beim Transit konfiguriert ist.

dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Das folgende Beispiel zeigt einen Cluster-Endpunkt in derselben Region, der für die Verwendung der Verschlüsselung beim Transit konfiguriert ist.

daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Knotenendpunkte

Jeder der einzelnen Knoten in einem DAX Cluster hat seinen eigenen Hostnamen und seine eigene Portnummer. Das folgende Beispiel zeigt einen Knotenendpunkt.

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

Ihre Anwendung kann direkt auf einen Knoten zugreifen, indem sie seinen Endpunkt nutzt. Allerdings empfehlen wir, dass Sie den DAX-Cluster als Einzeleinheit behandeln und stattdessen mithilfe des Cluster-Endpunkts darauf zugreifen. Der Cluster-Endpunkt schützt Ihre Anwendung davor, eine Liste von Knoten pflegen zu müssen und diese Liste auf dem neuesten Stand zu halten, wenn Sie dem Cluster Knoten hinzufügen oder entfernen.

Subnetzgruppen

Der Zugriff auf DAX Clusterknoten ist auf Anwendungen beschränkt, die auf EC2 Amazon-Instances in einer VPC Amazon-Umgebung ausgeführt werden. Sie können Subnetzgruppen verwenden, um Cluster-Zugriff von EC2 Amazon-Instances aus zu gewähren, die in bestimmten Subnetzen ausgeführt werden. Eine Subnetzgruppe ist eine Sammlung von Subnetzen (normalerweise privat), die Sie für Ihre Cluster festlegen können, die in einer Amazon-Umgebung ausgeführt werden. VPC

Während Sie einen DAX-Cluster erstellen, müssen Sie eine Subnetzgruppe angeben. DAX verwendet diese Subnetzgruppe, um ein Subnetz und IP-Adressen in diesem Subnetz auszuwählen, die dann den Knoten zugeordnet werden.

--Ereignisse

DAX zeichnet wichtige Ereignisse innerhalb Ihres Clusters auf, wie beispielsweise einen Fehlschlag beim Hinzufügen eines Knotens, einem erfolgreich hinzugefügten Knoten oder Änderungen an Sicherheitsgruppen. Durch die Überwachung wichtiger Schlüsselereignisse, können Sie den aktuellen Status Ihrer Clusters erfahren und, je nach Ereignis, in der Lage sein, Abhilfemaßnahmen zu ergreifen. Sie können auf diese Ereignisse zugreifen, indem Sie die Aktion AWS Management Console oder die DescribeEvents Aktion in der Verwaltung verwenden. DAX API

Sie können auch beantragen, dass Benachrichtigungen an ein bestimmtes Amazon Simple Notification Service (AmazonSNS) -Thema gesendet werden. So erfahren Sie es sofort, wenn ein Ereignis im DAX-Cluster auftritt.

Wartungsfenster

Jeder Cluster hat ein wöchentliches Wartungsfenster, in dem Systemänderungen vorgenommen werden können. Da die Änderungen nacheinander angewendet werden, wird ein vorhandener Knoten ersetzt und ein neuer Knoten mit den angewendeten Änderungen wird dem Cluster hinzugefügt. Während dieses Zeitraums kann es in Ihrer Anwendung zu vorübergehenden Fehlern oder Drosselungen kommen. Daher empfehlen wir, dass Sie das Wartungsfenster auf die niedrigste Nutzungszeit legen und diesen Zeitplan bei Bedarf regelmäßig anpassen. Sie können einen Zeitraum mit einer Dauer von bis zu 24 Stunden festlegen, in dem alle angeforderten Wartungsaktivitäten durchgeführt werden sollten.

Wenn Sie bei der Erstellung oder Änderung eines Cache-Clusters kein bevorzugtes Wartungsfenster angeben, DAX weisen Sie an einem zufälligen Wochentag ein 60-minütiges Wartungsfenster zu. Dieses 60-minütige Wartungsfenster wird nach dem Zufallsprinzip aus einem Zeitblock von jeweils 8 Stunden ausgewählt. AWS-Region Die folgende Tabelle listet die Blöcke für jede Region auf, von denen die Standard-Wartungsfenster zugewiesen werden.

Regionscode	Name der Region	Wartungsfenster
ap-northeast-1	Region Asien-Pazifik (Tokio)	13:00 — 21:00 UTC
ap-southeast-1	Region Asien-Pazifik (Singapur)	14:00 — 22:00 UTC
ap-southeast-2	Region Asien-Pazifik (Sydney)	12:00 — 20:00 UTC
ap-south-1	Region Asien-Pazifik (Mumbai)	17:30 — 1:30 UTC
cn-northwest-1	Region China (Ningxia)	23:00 — 07:00 UTC
cn-north-1	Region China (Peking)	14:00 — 22:00 UTC
eu-central-1	Region Europa (Frankfurt)	23:00 — 07:00 UTC
eu-north-1	Region Europa (Stockholm)	01:00 — 09:00 UTC
eu-south-2	Region Europa (Spanien)	21:00 — 05:00 UTC
eu-west-1	Region Europa (Irland)	22:00 — 06:00 UTC
eu-west-2	Region Europa (London)	23:00 — 07:00 UTC
eu-west-3	Region Europa (Paris)	23:00 — 07:00 UTC
sa-east-1	Region Südamerika (São Paulo)	01:00 — 09:00 UTC
us-east-1	Region USA Ost (Nord-Virginia)	03:00 — 11:00 UTC
us-east-2	Region USA Ost (Ohio)	23:00 — 07:00 UTC
us-west-1	Region USA West (Nordkalifornien)	06:00 — 14:00 UTC
us-west-2	Region USA West (Oregon)	06:00 — 14:00 UTC