Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # UltraWarm Speicher für Amazon OpenSearch Service UltraWarm bietet eine kostengünstige Möglichkeit, große Mengen schreibgeschützter Daten auf Amazon OpenSearch Service zu speichern. Standarddatenknoten verwenden „Hot“-Speicher, der in Form von Instance-Speichern oder Amazon EBS-Volumes an jeden Knoten angefügt ist. Hot Storage bietet die schnellstmögliche Leistung für die Indizierung und die Suche nach neuen Daten. Anstatt angehängten Speicher verwenden UltraWarm Knoten Amazon S3 und eine ausgeklügelte Caching-Lösung, um die Leistung zu verbessern. Bei Indizes, in die Sie nicht aktiv schreiben, seltener Abfragen durchführen und für die Sie nicht dieselbe Leistung benötigen, UltraWarm sind die Kosten pro GiB an Daten erheblich niedriger. Da warme Indizes schreibgeschützt sind, sofern Sie sie nicht in den Hot-Storage zurückschicken, UltraWarm eignet sie sich am besten für unveränderliche Daten wie Protokolle. In verhalten OpenSearch sich warme Indizes genauso wie jeder andere Index. Sie können sie auf dieselbe Weise abfragen APIs oder sie verwenden, um Visualisierungen in Dashboards zu erstellen. OpenSearch **Topics** + [Voraussetzungen](#ultrawarm-pp) + [UltraWarm Speicheranforderungen und Leistungsaspekte](#ultrawarm-calc) + [UltraWarm Preisgestaltung](#ultrawarm-pricing) + [Aktiviert UltraWarm](#ultrawarm-enable) + [Indizes in den Speicher migrieren UltraWarm](#ultrawarm-migrating) + [Automatisieren von Migrationen](#ultrawarm-ism) + [Migrationsoptimierung](#ultrawarm-settings) + [Abbrechen von Migrationen](#ultrawarm-cancel) + [Auflisten von Hot- und Warm-Indizes](#ultrawarm-api) + [Warm-Indizes in den Hot Storage zurückbringen](#ultrawarm-migrating-back) + [Warme Indizes aus Snapshots wiederherstellen](#ultrawarm-snapshot) + [Manuelle Snapshots von Warm-Indizes](#ultrawarm-manual-snapshot) + [Migration Warm-Indizes in Cold Storage](#ultrawarm-cold) + [Bewährte Methoden für KNN-Indizes](#ultrawarm-recommendations) + [Deaktivierung UltraWarm](#ultrawarm-disable) ## Voraussetzungen UltraWarm hat ein paar wichtige Voraussetzungen: + UltraWarm benötigt OpenSearch Elasticsearch 6.8 oder höher. + Um einen Warm-Speicher verwenden zu können, müssen Domains über [dedizierte Hauptknoten](managedomains-dedicatedmasternodes.md) verfügen. + Bei Verwendung einer [Multi-AZ mit Standby-Domain](managedomains-multiaz.md#managedomains-za-standby) muss die Anzahl der warmen Knoten ein Vielfaches der Anzahl der verwendeten Availability Zones sein. + Wenn Ihre Domäne einen T2- oder T3-Instance-Typ für Ihre Datenknoten verwendet, können Sie keinen Warm-Speicher verwenden. + Wenn Ihr Index ungefähr k-NN (`"index.knn":true`) verwendet, können Sie ihn ab Version 2.17 und höher in den Warmspeicher verschieben. Domains mit Versionen vor 2.17 können auf 2.17 aktualisiert werden, um diese Funktionalität zu nutzen, aber KNN-Indizes, die auf Versionen vor 2.x erstellt wurden, können nicht auf Version 2.x migriert werden. UltraWarm + Wenn die Domain eine [differenzierte Zugriffskontrolle](fgac.md) verwendet, müssen Benutzer der `ultrawarm_manager` Rolle in Dashboards zugeordnet werden, um API-Aufrufe tätigen zu können. OpenSearch UltraWarm **Anmerkung** Die `ultrawarm_manager` Rolle ist für einige bereits bestehende Service-Domänen möglicherweise nicht definiert. OpenSearch Wenn die Rolle in Dashboards nicht angezeigt wird, müssen Sie sie [manuell erstellen](#ultrawarm-create-role). ### So konfigurieren Sie Berechtigungen Wenn Sie die Funktion in einer bereits vorhandenen OpenSearch Dienstdomäne aktivieren UltraWarm , ist die `ultrawarm_manager` Rolle möglicherweise nicht in der Domäne definiert. Benutzer ohne Administratorrechte müssen dieser Rolle zugeordnet werden, um Warm-Indizes in Domains mithilfe einer fein abgestuften Zugriffskontrolle zu verwalten. Führen Sie die folgenden Schritte aus, um die `ultrawarm_manager`-Rolle manuell zu erstellen: 1. **Gehen Sie in OpenSearch Dashboards zu **Sicherheit** und wählen Sie Berechtigungen aus.** 1. Wählen Sie **Aktionsgruppe erstellen** und konfigurieren Sie die folgenden Gruppen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/ultrawarm.html) 1. Wählen Sie **Rollen** und **Rolle erstellen**. 1. Benennen Sie die Rolle **ultrawarm\$1manager**. 1. Wählen Sie für **Clusterberechtigungen** `ultrawarm_cluster` und `cluster_monitor` aus. 1. Geben Sie für **Index** `*` ein. 1. Wählen Sie für **Indexberechtigungen** `ultrawarm_index_read`, `ultrawarm_index_write` und `indices_monitor` aus. 1. Wählen Sie **Erstellen** aus. 1. Nachdem Sie die Rolle erstellt haben, [ordnen Sie sie](fgac.md#fgac-mapping) einer beliebigen Benutzer- oder Backend-Rolle zu, die Indizes verwaltet UltraWarm . ## UltraWarm Speicheranforderungen und Leistungsaspekte Wie unter beschrieben[Berechnung der Speicheranforderungen](bp-storage.md), entsteht für Daten im Hot-Storage ein erheblicher Mehraufwand: Replikate, reservierter Linux-Speicherplatz und vom OpenSearch Service reservierter Speicherplatz. Zum Beispiel benötigt ein primärer 20 GiB-Shard mit einem Replica-Shard etwa 58 GiB Hot Storage. Da Amazon S3 verwendet wird, UltraWarm fällt dieser Overhead nicht an. Bei der Berechnung der UltraWarm Speicheranforderungen berücksichtigen Sie nur die Größe der primären Shards. Durch die Dauerhaftigkeit der Daten in S3 entfällt die Notwendigkeit für Replicas und S3 macht alle Betriebssystem- oder Dienstüberlegungen überflüssig. Derselbe 20 GiB-Shard erfordert 20 GiB Warm-Speicher. Wenn Sie eine `ultrawarm1.large.search`-Instance bereitstellen, können Sie alle 20 TiB des maximalen Speichers für primäre Shards verwenden. Eine Zusammenfassung der Instance-Typen und Informationen zur maximalen Speicherkapazität, die jeder adressieren kann, finden Sie unter [UltraWarm Speicherkontingente](limits.md#limits-ultrawarm). Wir empfehlen weiterhin eine maximale Shard-Größe von 50 GiB. UltraWarm Die [Anzahl der CPU-Kerne und die Menge an RAM, die jedem UltraWarm Instance-Typ zugewiesen sind, geben](#ultrawarm-pricing) Ihnen eine Vorstellung davon, wie viele Shards sie gleichzeitig durchsuchen können. Beachten Sie, dass zwar nur primäre Shards für den UltraWarm Speicherplatz in S3 angerechnet werden, OpenSearch Dashboards und Dashboards `_cat/indices` dennoch die UltraWarm Indexgröße als *Summe* aller Primär- und Replikat-Shards angeben. Jede `ultrawarm1.medium.search`-Instance hat beispielsweise zwei CPU-Kerne und kann bis zu 1,5 TiB Speicher auf S3 adressieren. Zwei dieser Instances haben zusammen 3 TiB Speicher, was ungefähr 62 Shards ergibt, wenn jeder Shard 50 GiB groß ist. Wenn eine Anfrage an den Cluster nur vier dieser Shards durchsucht, kann die Leistung hervorragend sein. Wenn die Anfrage breit gefächert ist und alle 62 durchsucht, können die vier CPU-Kerne Schwierigkeiten haben, den Vorgang auszuführen. Überwachen Sie die `WarmCPUUtilization` und `WarmJVMMemoryPressure` [UltraWarm -Metriken](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw), um zu verstehen, wie die Instances mit Ihren Workloads umgehen. Wenn Sie viel oder häufig suchen, sollten Sie die Indizes im Hot Storage belassen. Wie bei jedem anderen OpenSearch Workload ist der wichtigste Schritt, um festzustellen, ob UltraWarm er Ihren Anforderungen entspricht, die Durchführung repräsentativer Client-Tests anhand eines realistischen Datensatzes. ## UltraWarm Preisgestaltung Bei Hot Storage zahlen Sie für das, was Sie bereitstellen. Einige Instances benötigen ein angefügtes Amazon-EBS-Volume, während andere einen Instance-Speicher enthalten. Unabhängig davon, ob dieser Speicher leer oder voll ist, zahlen Sie den gleichen Preis. Bei UltraWarm Speicherplatz zahlen Sie für das, was Sie nutzen. Eine `ultrawarm1.large.search`-Instance kann bis zu 20 TiB Speicher auf S3 adressieren, aber wenn Sie nur 1 TiB Daten speichern, werden Ihnen nur 1 TiB Daten in Rechnung gestellt. Wie bei allen anderen Knotentypen zahlen Sie auch für jeden UltraWarm Knoten einen Stundensatz. Weitere Informationen finden Sie unter [Preise für Amazon OpenSearch Service](what-is.md#pricing). ## Aktiviert UltraWarm Die Konsole ist die einfachste Möglichkeit, eine Domain zu erstellen, die Warm-Speicher verwendet. Wählen Sie beim Erstellen der Domäne die Option **Warm Data Nodes aktivieren** und geben Sie die Anzahl der gewünschten Warm-Nodes an. Derselbe grundlegende Prozess funktioniert auf vorhandenen Domains, sofern sie die [Voraussetzungen](#ultrawarm-pp)erfüllen. Auch wenn der Domänenstatus von „In **Bearbeitung**“ in „**Aktiv**“ geändert wurde, UltraWarm kann es sein, dass er mehrere Stunden lang nicht verwendet werden kann. Bei Verwendung einer Multi-AZ mit Standby-Domain muss die Anzahl der warmen Knoten ein Vielfaches der Anzahl der Availability Zones sein. Weitere Informationen finden Sie unter [Multi-AZ mit Standby](managedomains-multiaz.md#managedomains-za-standby). Sie können auch die [Konfigurations-API [AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html)](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html)oder verwenden UltraWarm, um insbesondere die `WarmType` Optionen `WarmEnabled``WarmCount`, und in `ClusterConfig` zu aktivieren. **Anmerkung** Die Domains unterstützen eine maximale Anzahl von Warm-Knoten. Details hierzu finden Sie unter [Amazon OpenSearch Service-Kontingente](limits.md). ### Beispiel für einen CLI-Befehl Der folgende AWS CLI Befehl erstellt eine Domäne mit drei Datenknoten, drei dedizierten Master-Knoten, sechs warmen Knoten und aktivierter detaillierter Zugriffskontrolle: ``` aws opensearch create-domain \ --domain-name my-domain \ --engine-version Opensearch_1.0 \ --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.search \ --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \ --node-to-node-encryption-options Enabled=true \ --encryption-at-rest-options Enabled=true \ --domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \ --advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName=master-user,MasterUserPassword=master-password}' \ --access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-west-1:123456789012:domain/my-domain/*"}]}' \ --region us-east-1 ``` Weitere Informationen finden Sie in der [AWS CLI -Befehlsreferenz](https://docs.aws.amazon.com/cli/latest/reference/). ### Beispiel für eine Konfigurations-API-Anforderung Die folgende Anforderung an die Konfigurations-API erstellt eine Domain mit drei Datenknoten, drei dedizierten Hauptknoten und sechs Warm-Knoten mit differenzierter Zugriffskontrolle und einer restriktiven Zugriffsrichtlinie: ``` POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain { "ClusterConfig": { "InstanceCount": 3, "InstanceType": "r6g.large.search", "DedicatedMasterEnabled": true, "DedicatedMasterType": "r6g.large.search", "DedicatedMasterCount": 3, "ZoneAwarenessEnabled": true, "ZoneAwarenessConfig": { "AvailabilityZoneCount": 3 }, "WarmEnabled": true, "WarmCount": 6, "WarmType": "ultrawarm1.medium.search" }, "EBSOptions": { "EBSEnabled": true, "VolumeType": "gp2", "VolumeSize": 11 }, "EncryptionAtRestOptions": { "Enabled": true }, "NodeToNodeEncryptionOptions": { "Enabled": true }, "DomainEndpointOptions": { "EnforceHTTPS": true, "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07" }, "AdvancedSecurityOptions": { "Enabled": true, "InternalUserDatabaseEnabled": true, "MasterUserOptions": { "MasterUserName": "master-user", "MasterUserPassword": "master-password" } }, "EngineVersion": "Opensearch_1.0", "DomainName": "my-domain", "AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"123456789012\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:us-east-1:123456789012:domain/my-domain/*\"}]}" } ``` Ausführliche Informationen finden Sie in der [Amazon OpenSearch Service API-Referenz](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html). ## Indizes in den Speicher migrieren UltraWarm Wenn Sie mit dem Schreiben in einen Index fertig sind und nicht mehr die schnellstmögliche Suchleistung benötigen, migrieren Sie ihn von Hot-Modus zu: UltraWarm ``` POST _ultrawarm/migration/my-index/_warm ``` Überprüfen Sie dann den Status der Migration: ``` GET _ultrawarm/migration/my-index/_status { "migration_status": { "index": "my-index", "state": "RUNNING_SHARD_RELOCATION", "migration_type": "HOT_TO_WARM", "shard_level_status": { "running": 0, "total": 5, "pending": 3, "failed": 0, "succeeded": 2 } } } ``` Die Indexintegrität muss grün sein, um eine Migration durchzuführen. Wenn Sie mehrere Indizes schnell hintereinander migrieren, erhalten Sie eine Zusammenfassung aller Migrationen im Klartext, ähnlich der `_cat`-API: ``` GET _ultrawarm/migration/_status?v index migration_type state my-index HOT_TO_WARM RUNNING_SHARD_RELOCATION ``` OpenSearch Der Service migriert jeweils einen Index nach dem anderen zu UltraWarm. Sie können bis zu 200 Migrationen in der Warteschlange haben. Jede Anfrage, die das Limit überschreitet, wird abgelehnt. Um die aktuelle Anzahl von Migrationen in der Warteschlange zu überprüfen, überwachen Sie die `HotToWarmMigrationQueueSize`-[Metrik](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw). Indizes bleiben während des gesamten Migrationsprozesses verfügbar – keine Ausfallzeiten. Der Migrationsprozess weist die folgenden Zustände auf: ``` PENDING_INCREMENTAL_SNAPSHOT RUNNING_INCREMENTAL_SNAPSHOT FAILED_INCREMENTAL_SNAPSHOT PENDING_FORCE_MERGE RUNNING_FORCE_MERGE FAILED_FORCE_MERGE PENDING_FULL_SNAPSHOT RUNNING_FULL_SNAPSHOT FAILED_FULL_SNAPSHOT PENDING_SHARD_RELOCATION RUNNING_SHARD_RELOCATION FINISHED_SHARD_RELOCATION ``` Wie diese Zustände zeigen, können Migrationen während Snapshots, Shard-Verlagerungen oder erzwungenen Zusammenführungen fehlschlagen. Fehler bei Snapshots oder Shard-Verlagerungen sind in der Regel auf Knotenfehler oder S3-Konnektivitätsprobleme zurückzuführen. Ein Mangel an Speicherplatz ist in der Regel die zugrunde liegende Ursache für Fehler bei erzwungenen Zusammenführungen. Nach Abschluss der Migration gibt dieselbe `_status`-Anforderung einen Fehler zurück. Wenn Sie den Index zu diesem Zeitpunkt überprüfen, können Sie einige Einstellungen sehen, die für Warm-Indizes eindeutig sind: ``` GET my-index/_settings { "my-index": { "settings": { "index": { "refresh_interval": "-1", "auto_expand_replicas": "false", "provided_name": "my-index", "creation_date": "1599241458998", "unassigned": { "node_left": { "delayed_timeout": "5m" } }, "number_of_replicas": "1", "uuid": "GswyCdR0RSq0SJYmzsIpiw", "version": { "created": "7070099" }, "routing": { "allocation": { "require": { "box_type": "warm" } } }, "number_of_shards": "5", "merge": { "policy": { "max_merge_at_once_explicit": "50" } } } } } } ``` + `number_of_replicas` ist in diesem Fall die Anzahl der passiven Replicas, die keinen Speicherplatz verbrauchen. + `routing.allocation.require.box_type` gibt an, dass der Index Warm-Knoten anstelle von Standarddatenknoten verwenden soll. + `merge.policy.max_merge_at_once_explicit` gibt die Anzahl der Segmente an, die während der Migration gleichzeitig zusammengeführt werden sollen. Indizes im Warmspeicher sind schreibgeschützt, es sei denn, Sie [geben sie in den Hotspeicher zurück](#ultrawarm-migrating-back). Dies ist UltraWarm am besten für unveränderliche Daten wie Protokolle geeignet. Sie können die Indizes abfragen und löschen, aber Sie können keine einzelnen Dokumente hinzufügen, aktualisieren oder löschen. Wenn Sie es versuchen, wird möglicherweise der folgende Fehler angezeigt: ``` { "error" : { "root_cause" : [ { "type" : "cluster_block_exception", "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];" } ], "type" : "cluster_block_exception", "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];" }, "status" : 429 } ``` ## Automatisieren von Migrationen Wir empfehlen die Verwendung von [Verwaltung des Indexstatus in Amazon OpenSearch Service](ism.md) zur Automatisierung des Migrationsprozesses, nachdem ein Index ein bestimmtes Alter erreicht hat oder andere Bedingungen erfüllt. Sehen Sie sich die [Beispielrichtlinie](ism.md#ism-example-cold) an, die diesen Workflow veranschaulicht. ## Migrationsoptimierung Für Indexmigrationen in den Speicher ist eine erzwungene Zusammenführung erforderlich. UltraWarm Jeder OpenSearch Index besteht aus einer bestimmten Anzahl von Shards, und jeder Shard besteht aus einer bestimmten Anzahl von Lucene-Segmenten. Der Vorgang der erzwungenen Zusammenführung löscht Dokumente, die zum Löschen markiert wurden, und spart Speicherplatz. Führt Indizes standardmäßig zu einem Segment zusammen, mit Ausnahme von kNN-Indizes, bei denen der Standardwert 20 verwendet wird. UltraWarm Sie können diesen Wert mit der `index.ultrawarm.migration.force_merge.max_num_segments`-Einstellung auf bis zu 1.000 Segmente ändern. Höhere Werte beschleunigen den Migrationsprozess, erhöhen jedoch die Abfragelatenz für den warmen Index nach Abschluss der Migration. Um die Einstellung zu ändern, stellen Sie die folgende Anfrage: ``` PUT my-index/_settings { "index": { "ultrawarm": { "migration": { "force_merge": { "max_num_segments": 1 } } } } } ``` Um zu überprüfen, wie lange diese Phase des Migrationsprozesses dauert, überwachen Sie die `HotToWarmMigrationForceMergeLatency`-[Metrik](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw). ## Abbrechen von Migrationen UltraWarm verarbeitet Migrationen sequentiell in einer Warteschlange. Wenn sich eine Migration in der Warteschlange befindet, aber noch nicht gestartet wurde, können Sie sie mit der folgenden Anforderung aus der Warteschlange entfernen: ``` POST _ultrawarm/migration/_cancel/my-index ``` Wenn Ihre Domain eine differenzierte Zugriffskontrolle verwendet, müssen Sie die `indices:admin/ultrawarm/migration/cancel`-Berechtigung haben, um diese Anfrage zu stellen. ## Auflisten von Hot- und Warm-Indizes UltraWarm fügt zwei zusätzliche Optionen hinzu, ähnlich wie`_all`, um die Verwaltung von Hot- und Warm-Indizes zu erleichtern. Für eine Auflistung aller Warm- oder Hot-Indizes, tätigen Sie folgende Anforderungen: ``` GET _warm GET _hot ``` Sie können diese Optionen in anderen Anforderungen verwenden, die Indizes angeben, zum Beispiel: ``` _cat/indices/_warm _cluster/state/_all/_hot ``` ## Warm-Indizes in den Hot Storage zurückbringen Wenn Sie noch einmal in einen Index schreiben müssen, migrieren Sie ihn zurück in den Hot Storage: ``` POST _ultrawarm/migration/my-index/_hot ``` Sie können bis zu 10 Migrationen von warmem zu heißem Speicher gleichzeitig in Warteschlangen durchführen. OpenSearch Der Service verarbeitet Migrationsanfragen nacheinander in der Reihenfolge, in der sie sich in der Warteschlange befanden. Überwachen Sie die `WarmToHotMigrationQueueSize`-[Metrik](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw), um die aktuelle Anzahl zu überprüfen. Überprüfen Sie nach Abschluss der Migration die Indexeinstellungen, um sicherzustellen, dass sie Ihren Anforderungen entsprechen. Indizes werden mit einem Replikat im Hot Storage wiederhergestellt. ## Warme Indizes aus Snapshots wiederherstellen Fügt zusätzlich zum Standard-Repository für automatisierte Snapshots ein zweites Repository für warme Indizes UltraWarm hinzu. `cs-ultrawarm` Jeder Snapshot in diesem Repository enthält nur einen Index. Wenn Sie einen warmen Index löschen, bleibt sein Snapshot wie jeder andere automatisierte Snapshot 14 Tage lang im `cs-ultrawarm`-Repository. Wenn Sie einen Snapshot aus `cs-ultrawarm` wiederherstellen, wird er im Warm Storage und nicht im Hot Storage wiederhergestellt. Snapshots in den Repositorys `cs-automated` und `cs-automated-enc` werden im Hot Storage wiederhergestellt. **Um einen UltraWarm Snapshot im Warmspeicher wiederherzustellen** 1. Identifizieren Sie den neuesten Snapshot, der den Index enthält, den Sie wiederherstellen möchten: ``` GET _snapshot/cs-ultrawarm/_all?verbose=false { "snapshots": [{ "snapshot": "snapshot-name", "version": "1.0", "indices": [ "my-index" ] }] } ``` **Anmerkung** Standardmäßig zeigt der `GET _snapshot/` Vorgang ausführliche Dateninformationen wie Startzeit, Endzeit und Dauer für jeden Snapshot innerhalb eines Repositorys an. Der `GET _snapshot/` Vorgang ruft Informationen aus den Dateien der einzelnen Snapshots ab, die in einem Repository enthalten sind. Wenn Sie die Startzeit, Endzeit und Dauer nicht benötigen und nur den Namen und die Indexinformationen eines Snapshots benötigen, empfehlen wir, den `verbose=false` Parameter beim Auflisten von Snapshots zu verwenden, um die Verarbeitungszeit zu minimieren und Zeitüberschreitungen zu vermeiden. 1. Wenn der Index bereits vorhanden ist, löschen Sie ihn: ``` DELETE my-index ``` Wenn Sie den Index nicht löschen möchten, [legen Sie ihn in den Hot Storage](#ultrawarm-migrating-back) zurück und [indizieren Sie ihn neu](https://docs.opensearch.org/latest/opensearch/reindex-data/). 1. Stellen Sie den Snapshot wieder her: ``` POST _snapshot/cs-ultrawarm/snapshot-name/_restore ``` UltraWarm ignoriert alle Indexeinstellungen, die Sie in dieser Wiederherstellungsanforderung angeben, aber Sie können Optionen wie `rename_pattern` und angeben. `rename_replacement` Eine Zusammenfassung der Optionen zur Wiederherstellung von OpenSearch Snapshots finden Sie in der [OpenSearch Dokumentation](https://docs.opensearch.org/latest/opensearch/snapshot-restore/#restore-snapshots). ## Manuelle Snapshots von Warm-Indizes Sie *können* manuelle Snapshots von Warm-Indizes erstellen, dies wird jedoch nicht empfohlen. Das automatisierte `cs-ultrawarm`-Repository enthält bereits ohne Aufpreis einen Snapshot für jeden warmen Index, der während der Migration erstellt wurde. Standardmäßig schließt OpenSearch Service keine warmen Indizes in manuelle Snapshots ein. Der folgende Aufruf enthält beispielsweise nur Hot-Indizes: ``` PUT _snapshot/my-repository/my-snapshot ``` Wenn Sie manuelle Snapshots von Warm-Indizes erstellen möchten, müssen mehrere wichtige Überlegungen angestellt werden. + Sie können Hot- und Warm-Indizes nicht mischen. Die folgende Anfrage schlägt beispielsweise fehl: ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,hot-index-1", "include_global_state": false } ``` Wenn sie eine Mischung aus Hot- und Warm-Indizes enthalten, schlagen auch Platzhalter (`*`)-Anweisungen fehl. + Sie können nur einen warmen Index pro Snapshot einschließen. Die folgende Anfrage schlägt beispielsweise fehl: ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,warm-index-2,other-warm-indices-*", "include_global_state": false } ``` Diese Anfrage ist erfolgreich: ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1", "include_global_state": false } ``` + Manuelle Snapshots werden immer im Hot Storage wiederhergestellt, auch wenn sie ursprünglich einen warmen Index enthielten. ## Migration Warm-Indizes in Cold Storage Wenn Sie Daten haben, die Sie selten abfragen UltraWarm , sollten Sie erwägen, sie in einen Cold Storage zu migrieren. Cold Storage ist für Daten gedacht, auf die Sie nur gelegentlich zugreifen oder die nicht mehr aktiv genutzt werden. Sie können Cold-Indizes weder lesen noch in sie schreiben, aber Sie können sie kostenlos zurück in den Warm-Speicher migrieren, wann immer Sie sie abfragen müssen. Anweisungen finden Sie unter [Migrieren von Indizes](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html#coldstorage-migrating) in Cold Storage. ## Bewährte Methoden für KNN-Indizes + Die Stufe Ultrawarm/Cold ist für alle KNN-Index-Motortypen verfügbar. Wir empfehlen es für KNN-Indizes, die die Lucene-Engine und die festplattenoptimierte Vektorsuche verwenden, bei der die Grafikdaten nicht vollständig in den Off-Heap-Speicher geladen werden müssen. Bei der Verwendung mit systemeigenen In-Memory-Engines wie FAISS und NMSLIB müssen Sie die Größe des Shard-Diagramms berücksichtigen, nach dem aktiv gesucht wird, und die Instances, vorzugsweise des Instance-Typs, entsprechend bereitstellen. UltraWarm `uw.large` Wenn Kunden beispielsweise 2 `uw.large` Instances konfiguriert haben, verfügen sie jeweils über ungefähr `knn.memory.circuit_breaker.limit * 61` GiB verfügbaren Off-Heap-Speicher. Sie erzielen eine optimale Leistung, wenn all Ihre Warm-Abfragen auf Shards abzielen, deren kumulative Grafikgröße den verfügbaren Off-Heap-Speicher nicht überschreitet. Die Latenz wird beeinträchtigt, wenn der verfügbare Speicher aufgrund von Räumungen geringer ist als zum Laden des Diagramms erforderlich ist und darauf gewartet wird, dass Off-Heap-Speicher verfügbar wird. Aus diesem Grund empfehlen wir nicht, `uw.medium` Instances für Anwendungsfälle zu verwenden, in denen In-Memory-Engines verwendet werden, oder für Fälle mit höherem Suchdurchsatz, unabhängig von den Engines. + KNN-Indizes, zu denen migriert UltraWarm wird, werden nicht zwangsweise zu einem einzigen Segment zusammengeführt. Dadurch werden Auswirkungen auf die heißen und warmen Knoten vermieden, bei denen OOM-Probleme auftreten, weil die Grafikgröße für In-Memory-Engines zu groß wird. Aufgrund der zunehmenden Anzahl von Segmenten pro Shard kann dies dazu führen, dass mehr lokaler Cache-Speicherplatz beansprucht wird und weniger Indizes auf die warme Ebene migriert werden können. Sie können festlegen, dass die Zusammenführung von Indizes zu einem einzelnen Segment erzwungen wird, indem Sie die vorhandene Einstellung verwenden und diese überschreiben, bevor Sie Indizes in die Warm-Tier migrieren. Weitere Informationen finden Sie unter [Migrationsoptimierung](#ultrawarm-settings). + Wenn Sie einen Anwendungsfall haben, in dem Indizes nur selten durchsucht werden und keine latenzempfindliche Arbeitslast abdecken, können Sie diese Indizes auf die Ebene migrieren. UltraWarm Auf diese Weise können Sie die Hot-Tier-Compute-Instances herunterskalieren und den UltraWarm Tier-Computing-Instanzen die Abfrage für Indizes mit niedriger Priorität überlassen. Dies kann auch dazu beitragen, die Ressourcen zu isolieren, die zwischen den Abfragen von Indizes mit niedriger und hoher Priorität verbraucht werden, sodass sie sich nicht gegenseitig beeinflussen. ## Deaktivierung UltraWarm Die Konsole ist die einfachste Methode zum Deaktivieren UltraWarm. Klicken Sie auf die Domain, wählen Sie **Aktionen** und **Clusterkonfiguration bearbeiten**. Deaktivieren Sie „**Warm Data Nodes aktivieren**“ und wählen Sie „**Änderungen speichern**“. Sie können die `WarmEnabled`-Option auch in der AWS CLI und der Konfigurations-API verwenden. Vor der Deaktivierung UltraWarm müssen Sie entweder alle warmen Indizes [löschen](https://opensearch.org/docs/latest/opensearch/rest-api/index-apis/delete-index/) oder [sie zurück in den Hot-Storage migrieren](#ultrawarm-migrating-back). Wenn der Warmspeicher leer ist, warten Sie fünf Minuten, bevor Sie versuchen, ihn zu deaktivieren UltraWarm.