Ausfallsicherheit für Elasticsearch: Replica + Snapshot + CCR

Symptom

Ziel: Ausfallsicherheit für Elasticsearch mit Replica Shards, dedizierten Master-/Data-Knoten, Snapshot-Backups (SLM) und Cross-Cluster Replication (CCR) aufbauen.

1. Rollen trennen: dedizierte Master- und Data-Knoten

Für die Stabilität des Clusters werden die stimmberechtigten Master-eligible-Knoten (vorzugsweise 3, eine ungerade Mehrheit) von der Datenlast getrennt. Weise die Rollen mit node.roles in elasticsearch.yml zu und definiere Seed Hosts für die Discovery. 3 Master verhindern Split-Brain.

Elasticsearch

# elasticsearch.yml on master nodes:
# node.roles: [ master ]
# on data nodes:
# node.roles: [ data, ingest ]
# discovery.seed_hosts: [ m1, m2, m3 ]
# cluster.initial_master_nodes: [ m1, m2, m3 ]

2. Replica-Anzahl des Index festlegen

number_of_replicas ist die Anzahl der Kopien, die für jeden Primary Shard gehalten werden; sie sollte mindestens 1 sein, damit die Daten beim Verlust eines Data-Knotens verfügbar bleiben. Sie lässt sich auf einem laufenden Index dynamisch ändern; die Replica-Anzahl muss kleiner als die Anzahl der Data-Knoten sein.

Elasticsearch

PUT /orders/_settings
{
  "index": { "number_of_replicas": 1 }
}
# default via template (composable template; the old _template API is legacy):
# PUT _index_template/order-tpl { "index_patterns": ["order*"], "template": { "settings": { "number_of_replicas": 1 } } }

3. Snapshot-Repository definieren

Backups werden in ein Repository geschrieben: ein gemeinsames Dateisystem (fs) oder die Plugins für S3/GCS/Azure. Damit sich die Daten auch nach dem Löschen des Clusters wiederherstellen lassen, muss das Repository auf dauerhaftem Speicher außerhalb des Clusters liegen.

Elasticsearch

PUT /_snapshot/backup_repo
{
  "type": "fs",
  "settings": { "location": "/mnt/es_backups", "compress": true }
}

4. Automatische Snapshots mit SLM planen

Snapshot Lifecycle Management (SLM) erstellt regelmäßig Snapshots und wendet eine Aufbewahrungsrichtlinie an. Ein Cron-Ausdruck legt die Häufigkeit fest, außerdem, welche Indizes einbezogen und wie viele Snapshots aufbewahrt werden.

Elasticsearch

PUT /_slm/policy/daily_backup
{
  "schedule": "0 30 1 * * ?",
  "name": "<daily-{now/d}>",
  "repository": "backup_repo",
  "config": { "indices": ["*"] },
  "retention": { "expire_after": "30d", "min_count": 5, "max_count": 50 }
}

5. Snapshot und Wiederherstellung prüfen

Löse die SLM-Policy manuell aus, um zu prüfen, ob sie funktioniert; der Snapshot-Status sollte SUCCESS sein. Führe regelmäßig Wiederherstellungstests durch, denn ein ungetestetes Backup ist kein Backup.

Elasticsearch

POST /_slm/policy/daily_backup/_execute
GET /_snapshot/backup_repo/_all
# restore:
POST /_snapshot/backup_repo/<snapshot_name>/_restore

6. Entferntes DR mit Cross-Cluster Replication (CCR) einrichten

Für regionsübergreifendes Disaster Recovery folgt ein zweiter Cluster (Follower) den Indizes im entfernten Primary-Cluster (Leader). Definiere zuerst den Remote-Cluster und verbinde dann den Follower-Index mit dem Leader; Änderungen auf dem Leader fließen automatisch nach. CCR ist ein Platinum-Feature (kommerziell).

Elasticsearch

# define the remote cluster on the follower cluster:
PUT /_cluster/settings
{ "persistent": { "cluster": { "remote": { "primary": { "seeds": ["leader1:9300"] } } } } }
# create the follower index:
PUT /orders-follower/_ccr/follow
{ "remote_cluster": "primary", "leader_index": "orders" }