Cross Cluster Replication (CCR) in OpenSearch ermöglicht die automatische Synchronisation von Indizes zwischen verschiedenen Clustern. Stellen Sie sich das wie mehrere synchronisierte Kopien einer Bibliothek vor, bei der sich Änderungen an einem Standort automatisch in den anderen widerspiegeln. Diese Funktion ist entscheidend für Disaster Recovery, Datenverfügbarkeit in verschiedenen Regionen und das Erstellen von schreibgeschützten Kopien für Reporting oder Analysen.
Bevor wir in die Implementierung einsteigen, sollten wir verstehen, wie CCR unter der Haube funktioniert. Wenn Sie die Replikation einrichten, etabliert OpenSearch eine kontinuierliche Verbindung zwischen den Clustern, wobei ein Cluster als Leader (früher “Master” genannt) und andere als Follower agieren. Der Prozess ähnelt der Nachrichtenverbreitung: Der Hauptreporter (Leader) liefert Updates, und Korrespondenten (Follower) geben diese Informationen an ihr lokales Publikum weiter.
Der Replikationsprozess umfasst mehrere Schritte:
Sehen wir uns die praktische Implementierung an.
Zunächst müssen wir Vertrauen zwischen unseren Clustern aufbauen. Dies ist vergleichbar mit dem Aufbau sicherer diplomatischer Kanäle zwischen Ländern. Beginnen wir mit der Konfiguration der Cluster-Einstellungen:
PUT _cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"leader-cluster": {
"seeds": [
"leader-node-1:9300",
"leader-node-2:9300"
],
"transport.ping_schedule": "30s",
"connection_timeout": "30s"
}
}
}
}
}Diese Konfiguration etabliert eine sichere Verbindung zwischen den Clustern. Der ping_schedule stellt sicher, dass die Verbindung aktiv bleibt, ähnlich wie ein Herzschlag-Monitor.
Bevor die Replikation beginnen kann, müssen wir unseren Leader-Index vorbereiten. Dies beinhaltet die korrekte Konfiguration für die Replikation:
PUT /sales-data
{
"settings": {
"index": {
"number_of_shards": 5,
"number_of_replicas": 1,
"soft_deletes": {
"enabled": true,
"retention_lease.period": "12h"
}
}
},
"mappings": {
"properties": {
"sale_id": { "type": "keyword" },
"timestamp": { "type": "date" },
"amount": { "type": "double" },
"customer_id": { "type": "keyword" }
}
}
}Die soft_deletes-Einstellung ist besonders wichtig. Sie fungiert wie ein Änderungsprotokoll, das Followern hilft zu verstehen, welche Änderungen aufgetreten sind, selbst wenn Dokumente gelöscht wurden.
Jetzt können wir unseren Follower-Index einrichten. Dieser Prozess teilt dem Follower-Cluster mit, wie er Daten vom Leader replizieren soll:
PUT /sales-data-replica/_ccr/follow
{
"remote_cluster": "leader-cluster",
"leader_index": "sales-data",
"settings": {
"index.number_of_replicas": 2
},
"parameters": {
"max_read_request_operation_count": 5000,
"max_outstanding_read_requests": 12,
"max_read_request_size": "32mb",
"max_write_request_operation_count": 5000,
"max_write_request_size": "9mb",
"max_outstanding_write_requests": 9,
"max_write_buffer_count": 2147483647,
"max_write_buffer_size": "512mb",
"max_retry_delay": "500ms",
"read_poll_timeout": "1m"
}
}Diese Parameter optimieren den Replikationsprozess. Betrachten Sie sie als Regeln dafür, wie der Follower Updates vom Leader anfordern und verarbeiten soll.
Es ist wichtig, den Zustand Ihrer Replikation zu überwachen. Sie können den Status wie folgt prüfen:
GET /sales-data-replica/_ccr/statsDie Antwort liefert detaillierte Informationen über den Replikationsprozess:
{
"indices": [
{
"index": "sales-data-replica",
"leader_index": "sales-data",
"leader_global_checkpoint": 1000,
"follower_global_checkpoint": 999,
"last_requested_seq_no": 1000,
"outstanding_read_requests": 1,
"outstanding_write_requests": 0,
"write_buffer_operation_count": 0,
"follower_mapping_version": 1,
"total_read_time_millis": 100000,
"total_read_remote_exec_time_millis": 50000,
"successful_read_requests": 100,
"failed_read_requests": 0,
"operations_read": 1000,
"bytes_read": 1048576,
"total_write_time_millis": 100000,
"successful_write_requests": 100,
"failed_write_requests": 0,
"operations_written": 1000,
"read_exceptions": [],
"time_since_last_read_millis": 100
}
]
}Manchmal können Follower hinter dem Leader zurückfallen. Wir können diese Verzögerung überwachen und verwalten:
PUT /sales-data-replica/_ccr/pause
PUT /sales-data-replica/_ccr/resumeDiese Befehle ermöglichen es Ihnen, die Replikation bei Bedarf vorübergehend zu pausieren, etwa während einer Wartung oder bei der Fehlersuche.
Für globale Anwendungen möchten Sie möglicherweise Daten über mehrere Regionen hinweg replizieren. Hier ist ein Beispiel für eine Replikationskette:
# Region 1 (Leader)
PUT /sales-data
{
"settings": {
"index": {
"number_of_shards": 5,
"soft_deletes.enabled": true
}
}
}
# Region 2 (Follower und Leader)
PUT /sales-data-region2/_ccr/follow
{
"remote_cluster": "region1",
"leader_index": "sales-data",
"settings": {
"index": {
"number_of_replicas": 1,
"soft_deletes.enabled": true
}
}
}
# Region 3 (Follower)
PUT /sales-data-region3/_ccr/follow
{
"remote_cluster": "region2",
"leader_index": "sales-data-region2"
}Für Szenarien, in denen Sie neue Indizes, die bestimmten Mustern entsprechen, automatisch replizieren möchten:
PUT /_ccr/auto_follow/logs_pattern
{
"remote_cluster": "leader-cluster",
"leader_index_patterns": ["logs-*"],
"follow_index_pattern": "{{leader_index}}-replica",
"settings": {
"index.number_of_replicas": 1
},
"parameters": {
"max_read_request_operation_count": 5000,
"max_outstanding_read_requests": 12
}
}Diese Konfiguration erstellt automatisch Follower-Indizes für alle neuen Log-Indizes, die im Leader-Cluster erstellt werden.
Es ist wichtig, Ihre Disaster Recovery-Prozeduren regelmäßig zu testen. Hier ist ein Prozess für Failover-Tests:
# Schritt 1: Replikation pausieren
PUT /sales-data-replica/_ccr/pause
# Schritt 2: Alle Änderungen verifizieren
GET /sales-data-replica/_ccr/stats
# Schritt 3: Follower zum Leader befördern
POST /sales-data-replica/_ccr/unfollow
# Schritt 4: Schreibzugriff auf dem ehemaligen Follower aktivieren
PUT /sales-data-replica/_settings
{
"index.blocks.write": null
}Für automatisches Failover können Sie die Monitoring-Funktionen von OpenSearch zusammen mit benutzerdefinierten Skripten verwenden:
PUT _plugins/_alerting/monitors/replication_monitor
{
"type": "monitor",
"name": "CCR Health Monitor",
"enabled": true,
"schedule": {
"period": {
"interval": 1,
"unit": "MINUTES"
}
},
"inputs": [
{
"search": {
"indices": [".ccr-stats*"],
"query": {
"bool": {
"must": [
{
"range": {
"time_since_last_read_millis": {
"gte": 300000
}
}
}
]
}
}
}
}
],
"triggers": [
{
"name": "Replikationsverzögerung-Alert",
"severity": "High",
"condition": {
"script": {
"source": "ctx.results[0].hits.total.value > 0"
}
},
"actions": [
{
"name": "Operations-Team benachrichtigen",
"destination_id": "ops_webhook",
"message_template": {
"source": "Replikationsverzögerung erkannt. Initiiere Failover-Prozeduren."
}
}
]
}
]
}Bei der Implementierung von CCR sollten Sie diese wichtigen Praktiken beachten:
Index-Design: Stellen Sie sicher, dass Ihre Indizes für die Replikation ausgelegt sind. Dies umfasst geeignete Sharding-Strategien und Mapping-Konfigurationen, die clusterübergreifend gut funktionieren.
Netzwerk-Konfiguration: Achten Sie besonders auf die Netzwerkeinstellungen zwischen den Clustern. Konfigurieren Sie angemessene Timeouts und Retry-Einstellungen basierend auf Ihren Netzwerkeigenschaften.
Monitoring-Strategie: Implementieren Sie ein umfassendes Monitoring, das sowohl den Replikationsprozess selbst als auch die Auswirkungen auf Ihre Cluster abdeckt.
Ressourcenplanung: Berücksichtigen Sie die zusätzlichen Ressourcenanforderungen der Replikation, einschließlich Netzwerkbandbreite, Speicherplatz und Verarbeitungsleistung.