Amazon OpenSearch Service erhält klonbasierte Upgrades: Prüfung nur von Leseanfragen auf einem geklonten Cluster, Abbruch vor der Umschaltung oder Zurückrollen innerhalb einer selbst gesetzten Aufbewahrungsfrist; beschränkt auf OpenSearch 1.1 oder neuer und Elasticsearch 7.10, fünf Upgrade-Pfade, und beide Cluster werden während der Prüfung berechnet

Am 10. November 2026 hat AWS klonbasierte Upgrades für Amazon OpenSearch Service angekündigt. Die Meldung sagt, man könne jetzt eine neue OpenSearch-Version neben der aktuellen prüfen und erst umschalten, wenn man zufrieden ist. Findet man ein Problem, kann man vor der Umschaltung abbrechen oder danach zurückrollen. Dieser Bericht stützt sich auf diese Meldung und auf die Seite zur Versionsmigration im OpenSearch-Service-Entwicklerhandbuch, die Schritte, Grenzen und Kosten beschreibt. Er sagt nichts dazu, wie schnell ein Klon aufgebaut wird, denn keine der beiden Seiten nennt Zeiten für klonbasierte Upgrades.

Die ältere Methode ist das Upgrade an Ort und Stelle (In-Place). Das Handbuch sagt, es aktualisiere den bestehenden Cluster der Domäne als Blue/Green-Bereitstellung, und man könne es weder pausieren noch abbrechen noch zurückrollen. Es ist ab OpenSearch 1.0 und Elasticsearch 5.1 verfügbar. Das Handbuch sagt, der aktualisierte Cluster übernehme, sobald das Upgrade abgeschlossen ist, auch wenn zuvor Prüfungen laufen, ein In-Place-Upgrade könne 15 Minuten bis mehrere Stunden dauern, und OpenSearch Dashboards könne währenddessen nicht verfügbar sein. Um nach einem In-Place-Upgrade zur früheren Version zurückzukehren, solle man einen Snapshot auf einer neuen Domäne wiederherstellen.

Ein klonbasiertes Upgrade funktioniert anders. OpenSearch Service erstellt einen zweiten Cluster, den geklonten Cluster, mit der Zielversion und kopiert Ihre Daten dorthin. Der Cluster, auf dem die Domäne bereits läuft, ist der primäre Cluster und bedient weiter den Datenverkehr. Das Handbuch nennt sechs Schritte. Zuerst laufen Vorabprüfungen, dieselben wie beim In-Place-Upgrade, und der Vorgang geht nicht weiter, wenn sie scheitern. Zweitens wird ein Snapshot erstellt, und auch hier geht nichts weiter, wenn er scheitert. Drittens wird der geklonte Cluster erstellt und die Daten werden kopiert; die Domäne bedient weiter Lese- und Schreibzugriffe vom primären Cluster, während der Klon synchron bleibt. Viertens wartet das Upgrade auf Ihre Prüfung des Klons. Die Meldung sagt, man könne dieselben Suchanfragen auf beiden Clustern ausführen und die Leistung mit Amazon-CloudWatch-Metriken vergleichen; das Handbuch ergänzt, man könne optional einen Teil des Lesedatenverkehrs an den Klon senden. Fünftens folgt die Umschaltung. Sechstens eine optionale Aufbewahrungsfrist.

Einige Bedingungen übersieht man leicht. Die Prüfung umfasst nur Lesezugriffe: Das Handbuch sagt, man könne den geklonten Cluster mit eigenen Leseanfragen prüfen, mehr nicht. Während der Umschaltung blockiert OpenSearch Service Schreibzugriffe, bis die Umschaltung abgeschlossen ist, während der Klon aufholt und der Datenverkehr dorthin verlagert wird. Laut Handbuch ändert sich der Domänenendpunkt nicht. Ein Zurückrollen ist nur nach der Umschaltung möglich und nur während der von Ihnen gesetzten Aufbewahrungsfrist. Diese Frist beginnt, wenn die Umschaltung abgeschlossen ist. Setzt man keine Frist, löscht OpenSearch Service laut Handbuch den primären Cluster unmittelbar nach der Umschaltung, sodass nichts zum Zurückkehren bleibt. Ein Abbruch vor der Umschaltung löscht den geklonten Cluster und lässt die Domäne, wie sie war.

Die Zulassungsregeln sind eng. Die Meldung sagt, klonbasierte Upgrades seien für Domänen mit OpenSearch 1.1 oder neuer oder Elasticsearch 7.10 verfügbar, in AWS-Commercial-Regionen, in denen der Dienst angeboten wird, außer Asien-Pazifik (Neuseeland), Asien-Pazifik (Taipeh), Asien-Pazifik (Thailand) und Mexiko (Zentral). Das Handbuch nennt fünf unterstützte Pfade: Elasticsearch 7.10 auf OpenSearch 1.3, OpenSearch 1.1 auf 1.3, OpenSearch 1.3 auf 2.19, OpenSearch 2.x auf 2.19 und OpenSearch 2.19 auf 3.x. Für andere Pfade solle man ein In-Place-Upgrade nutzen. Es nennt auch nicht unterstützte Domänen: solche mit OpenSearch-Optimized-Instanzen (OR1 oder OR2), UltraWarm-Instanzen oder Cross-Cluster-Replikation, solche mit zugeordneten benutzerdefinierten oder Drittanbieter-Plugin-Paketen und solche, die SAML- oder Amazon-Cognito-Authentifizierung für OpenSearch Dashboards verwenden. Außerdem kann man die Konfiguration der Domäne während des Upgrades nicht ändern.

Die Kostenregel ist klar benannt. Ein In-Place-Upgrade verursacht keine zusätzlichen Kosten. Bei einem klonbasierten Upgrade gelten für Instanzen und Speicher des Klons die üblichen Preise, wie für jeden anderen Knoten. Während der Prüfung zahlt man sowohl für den primären Cluster als auch für den Klon, und wer den primären Cluster für ein Zurückrollen behält, zahlt für beide, bis die Aufbewahrungsfrist endet. Meldung und Handbuch nennen keine Dollarbeträge. Eine längere Prüfung oder Aufbewahrungsfrist verlängert daher die Zeit, in der man für zwei Cluster zahlt; die Mehrkosten hängen von den eigenen Instanz- und Speicherentscheidungen und den Standardpreisen ab.

Vor jedem Upgrade verlangt das Handbuch drei Dinge: einen manuellen Snapshot erstellen, den man auf einer neuen Domäne wiederherstellen kann, wenn man die frühere Version zurückhaben will; die unterstützten Upgrade-Pfade prüfen; und die Vorabprüfung ausführen. Es warnt außerdem: Wer Daten mit Diensten wie Amazon Data Firehose oder Amazon CloudWatch Logs nach OpenSearch Service leitet, solle vor der Migration prüfen, ob diese Dienste die neuere Version unterstützen. Die Fehlerbehebungstabelle nennt Bedingungen, die ein Upgrade blockieren, etwa mehr als 1.000 Shards auf einem Knoten, Festplattenauslastung über 90 %, JVM-Speicherdruck über 75 % und ein roter Cluster-Status. Diese Prüfungen gelten für beide Upgrade-Arten.

Was auf diesen beiden Seiten nicht steht, zählt für die Planung. Sie nennen keine Messung, wie lange ein Klon zum Aufbau oder Aufholen braucht, keine Angabe, wie lange Schreibzugriffe bei der Umschaltung blockiert sind, und keinen Beleg dafür, wie gut die Klonleistung die Produktionsleistung vorhersagt. Das Handbuch sagt, die Prüfung umfasse nur Lesezugriffe; diese Prüfphase kann das Schreibverhalten also nicht direkt testen. Das Folgende ist unsere Einschätzung, keine Aussage von AWS. Ein Team mit schreibintensiver Last sollte eigene Schreibtests außerhalb der Produktion und eine Probe der Umschaltung einplanen. Jedes Team, das dieses Sicherheitsnetz will, sollte außerdem die Dauer der Umschaltung auf einer Nicht-Produktionsdomäne messen, vorab entscheiden, wie lange der primäre Cluster bleibt, und in dieser Zeit zwei Cluster einplanen.