Warum ist meine Amazon-OpenSearch-Service-Domäne im Zustand „Verarbeitung“ hängen geblieben?

Letzte Aktualisierung: 5.8.2021

Mein Amazon OpenSearch Service (Nachfolger von Amazon Elasticsearch Service) ist im Status „Verarbeitung“ hängen geblieben. Warum passiert das und wie kann ich das verhindern?

Kurzbeschreibung

Ihr OpenSearch-Service-Cluster wechselt in den Status „Verarbeitung“, wenn er sich mitten in einer Konfigurationsänderung befindet. Der Cluster kann im Status „Verarbeitung“ hängen bleiben, wenn eine der beiden Situationen eintritt:

  • Ein neuer Satz von Datenknoten wird nicht gestartet.
  • Die Shard-Migration auf den neuen Satz von Datenknoten ist erfolglos.

Wenn Sie eine Konfigurationsänderung einleiten, ändert sich der Domänenstatus in „Verarbeitung“, während OpenSearch Service eine neue Umgebung erstellt. In der neuen Umgebung startet OpenSearch Service einen neuen Satz anwendbarer Knoten (wie Daten, Master oder UltraWarm). Nach Abschluss der Migration werden die älteren Knoten beendet.

Auflösung

Ein neuer Satz von Datenknoten konnte nicht gestartet werden

Wenn Sie vor Abschluss der ersten Änderung gleichzeitig Konfigurationsänderungen an Ihrem Cluster vornehmen, kann Ihr Cluster hängen bleiben. Stellen Sie sicher, dass Sie in Ihrem Cluster nach laufenden Blau/Grün-Bereitstellungen suchen. Um zu überprüfen, ob es laufende Blau/Grün-Bereitstellungen gibt, überprüfen Sie die Gesamtzahl der Knoten in Amazon CloudWatch. Wenn Sie eine höhere Anzahl von Knoten als erwartet beobachten, ist wahrscheinlich eine blau/grüne Bereitstellung im Gange.

Verwenden Sie den folgenden API-Aufruf, um weitere Informationen über zusätzliche Knoten und den Shard-Migrationsprozess abzurufen:

GET /_cluster/health?pretty and GET /_cat/recovery?pretty

Wenn Sie eine Amazon-Virtual-Private-Cloud (VPC)-Domäne verwenden, stellen Sie sicher, dass Sie über genügend freie IP-Adressen in Ihrem Subnetz verfügen. Wenn in Ihrem Subnetz nicht genügend IP-Adressen angegeben sind, schlägt der Start neuer Knoten fehl. Infolgedessen bleibt Ihr Cluster im Status „Verarbeitung“ hängen. Weitere Informationen finden Sie unter Reservieren von IP-Adressen in einem VPC-Subnetz.

Wenn Sie eine OpenSearch-Service-Domäne verschlüsselt haben, stellen Sie sicher, dass Ihr AWS-KMS-Schlüssel in Ihrem AWS-Konto vorhanden ist, bevor Sie eine Konfigurationsänderung vornehmen. Wenn Sie den AWS-KMS-Schlüssel versehentlich gelöscht haben, kann der Cluster im Status „Verarbeitung“ hängen bleiben.

Ihr Cluster kann auch aus folgenden Gründen hängen bleiben:

  • Ein überladener Masterknoten mit zu vielen ausstehenden Aufgaben oder hohem CPU- und JVM-Speicherdruck. Verwenden Sie die API für ausstehende Aufgaben von Cat, um nach ausstehenden Aufgaben zu suchen. Sie können auch die MasterCPUUtilization und MasterJVMMemoryPressure in Amazon CloudWatch überprüfen.
  • Die Authentifizierungsvoraussetzungen Amazon-Cognito-Authentifizierung für OpenSearch-Dashboards wurden nicht erfüllt. Wenn Sie Amazon Cognito für die OpenSearch-Dashboard-Authentifizierung konfiguriert haben, stellen Sie sicher, dass Sie die Authentifizierungsvoraussetzungen erfüllt haben. Zum Beispiel muss OpenSearch Service den Benutzerpool, den Amazon-Cognito-Identitätspool und die AWS-Identity-Access-Management (IAM)-Rolle mit den richtigen Berechtigungen festlegen. Der Standardname für diese Rolle lautet CognitoAccessForAmazonOpenSearch (mit der angehängten Richtlinie AmazonESCognitoAccess).
    Hinweis: Wenn Sie eine benutzerdefinierte IAM-Rolle erstellt haben, stellen Sie sicher, dass Ihre Rolle über dieselben Berechtigungen wie CognitoAccessForAmazonOpenSearch verfügt.

Die Shard-Migration auf den neuen Satz von Datenknoten ist erfolglos

Eine Shard-Migration (vom alten zum neuen Satz von Datenknoten) könnte aus folgenden Gründen erfolglos sein:

  • Ihr OpenSearch-Service-Cluster befindet sich derzeit im roten Zustand. Wenn sich Ihr Cluster im roten Zustand befindet, beheben Sie einen Fehler bei Ihrem roten Clusterstatus, damit sich Ihr Cluster in einem fehlerfreien Zustand befindet.
    Hinweis: Es empfiehlt sich, Ihren Cluster zu konfigurieren, wenn er sich in einem fehlerfreien Zustand befindet.
  • Knoten sind aufgrund einer hohen Verarbeitungslast, die durch hohen JVM-Speicherdruck und CPU-Auslastung verursacht wird, außer Betrieb. Um dieses Problem zu beheben, reduzieren Sie Ihren Netzwerkdatenverkehr zum Cluster oder stoppen Sie den Netzwerkdatenverkehr vollständig, um den Cluster wieder in einen fehlerfreien Zustand zu versetzen. Andernfalls könnte Ihr blau/grüner Bereitstellungsprozess auslaufen und manuelle Eingriffe erfordern.
  • Aufgrund interner Hardwarefehler können die Shards auf alten Datenknoten während einer Migration hängen bleiben. (Hinweis: Abhängig von Ihrem Hardwareproblem wird Ihr Cluster möglicherweise auch nicht automatisch wiederhergestellt.) Wenn sich Ihr Cluster nicht automatisch wiederherstellt, führt OpenSearch Service Selbstheilungsskripte aus, um die Knoten wieder in einen fehlerfreien Zustand zu versetzen. Der Verlust des Root-Volumes eines Knotens kann verhindern, dass OpenSearch Service reagiert, und eine Auto-Scaling-Gruppe ersetzt dann automatisch die fehlerhaften Knoten. Wenn das angeschlossene EBS-Volume für einen Knoten ausfällt, ist ein manueller Eingriff erforderlich, um das EBS-Volume zu ersetzen. Verwenden Sie die folgenden API-Befehle, um festzustellen, welche Shards noch von einem älteren Satz von Knoten aus arbeiten: Cat-Zuweisungs-API, Cat-Knoten-API oder Cat-Shards-API.
  • Eine hängen gebliebene Shard-Verlagerung, die durch unzureichenden freien Speicher im neuen Satz von Knoten verursacht wird. Dieses Problem tritt auf, wenn während eines blau/grünen Bereitstellungsprozesses neue Daten in den Cluster gelangen.
    Hinweis: Eine blau/grüne Bereitstellung wird nicht ausgelöst, wenn OpenSearch Service weniger Speicherplatz erkennt, als für eine erfolgreiche Datenmigration erforderlich ist.
  • Eine hängengebliebene Shard-Verlagerung, die durch Shards verursacht wird, die an einen älteren Satz von Knoten angeheftet sind. Um sicherzustellen, dass Shards nicht an Knoten angeheftet werden, bevor eine Konfigurationsänderung vorgenommen wird, überprüfen Sie die Indexeinstellung. Oder prüfen Sie, ob bei Ihrem Cluster eine Schreibblockade vorliegt, die durch hohen JVM-Speicherdruck oder geringen Festplattenspeicher verursacht wird.

Verwenden Sie die folgenden Befehle, um festzustellen, welche Index-Shards hängen bleiben und welche Indexeinstellungen verwendet werden:

curl -X GET "ENDPOINT/_cluster/allocation/explain?pretty"
curl -X GET "ENDPOINT/INDEX_NAME/_settings?pretty"

Prüfen Sie in Ihren Indexeinstellungen, ob eine dieser Einstellungen angezeigt wird:

{
    "index.routing.allocation.require._name": "NODE_NAME" (OR)
    "index.blocks.write": true
    }

Wenn Sie "index.routing.allocation.require._name": "NODE_NAME" in Ihren Indexeinstellungen sehen, entfernen Sie die Einstellung wie folgt:

curl -X PUT "ENDPOINT/INDEX_NAME/_settings?pretty" H 'Content-Type: application/json' -d '
{
"index.routing.allocation.require._name": null
}'

Weitere Informationen finden Sie unter Filtern der Shard-Zuweisung auf Indexebene auf der Elasticsearch-Website.

Wenn Sie "index.blocks.write": true in Ihren Indexeinstellungen sehen, liegt bei Ihrem Cluster eine Schreibblockade vor. Die Schreibblockade wird wahrscheinlich durch einen hohen JVM-Speicherdruck oder geringen Festplattenspeicher verursacht. Stellen Sie sicher, dass Sie diese Probleme beheben, bevor Sie weitere Tipps zur Fehlerbehebung implementieren. Weitere Hinweise zur Behebung dieser Ausnahme finden Sie unter ClusterBlockException.

Hinweis: Wenn sich Ihr Cluster länger als 24 Stunden im Status „Verarbeitung“ befindet, benötigt Ihr Cluster einen manuellen Eingriff. Wenn Sie keine Konfigurationsänderungen vorgenommen haben, die Anzahl der Knoten jedoch höher als erwartet ist, wird möglicherweise ein Software-Patch ausgeführt.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?