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.
Mehrstufiger Speicher für Amazon Service OpenSearch
Multi-Tier-Speicher für Amazon OpenSearch Service ist eine intelligente Datenverwaltungslösung, die sowohl die Leistung als auch die Kosten optimiert, indem Daten auf verschiedenen Speicherebenen verwaltet werden. Diese Architektur ermöglicht es Unternehmen, den Kompromiss zwischen Leistung und Kosten effizient auszubalancieren, indem häufig aufgerufene Daten in Hochleistungsspeichern gespeichert werden, während Daten, auf die seltener zugegriffen wird, in kostengünstigere Warmspeicher verschoben werden.
Amazon OpenSearch Service bietet zwei Architekturoptionen für die hot/warm Speicherstufe:
-
OpenSearch Mehrstufige Speicherarchitektur
Kombiniert Amazon S3 mit lokalem Instance-Speicher
Unterstützt von OpenSearch optimierten Instances
Unterstützt Schreibvorgänge in der warmen Stufe
Unterstützt die nahtlose Datenmigration zwischen der heißen und der warmen Ebene
Verfügbar auf OpenSearch 3.3 und höher
Unterstützt Cold Tier nicht
-
UltraWarmbasierte Architektur
Kombiniert Amazon S3 mit lokalem Instance-Speicher
Angetrieben von UltraWarm Instances
Optimiert für Workloads der Warm-Tier-Stufe mit Schreibzugriff
Verfügbar in Elasticsearch Version 6.8 und höher sowie in allen Versionen OpenSearch
Unterstützt Cold Tier
Anmerkung
Diese Dokumentation konzentriert sich nur auf die mehrstufige Architektur. Informationen zur Ultrawarm-Speicherarchitektur finden Sie unter Ultrawarm und Cold Storage
Mehrstufige Speicherarchitektur
Themen
Wichtigste Vorteile
Writable Warm: Unterstützt Schreiboperationen für warme Indizes
Reibungslose Migration: Reibungslose Übertragung von Daten zwischen Speicherebenen
Kostenoptimierung: Senken Sie die Speicherkosten, indem Sie weniger aktive Daten in kostengünstigen Warmspeicher verschieben
Leistungssteigerung: Sorgen Sie für eine hohe Leistung bei häufig abgerufenen Daten im Hot-Tier
Flexibles Datenmanagement: Wählen Sie die Architektur, die Ihren Workload-Anforderungen am besten entspricht
Automatisiertes Management: Vereinfachtes Datenlebenszyklusmanagement auf allen Speicherebenen
Voraussetzungen
Engine-Version: OpenSearch 3.3 oder höher
-
Instanzfamilien:
Heiße Knoten: OR1 OR2, OM2, oder OI2
Warme Knoten: OI2
Sicherheit: Node-to-node Verschlüsselung, Verschlüsselung im Ruhezustand, HTTPS erzwungen
Einschränkungen
Funktioniert auf allen Domains mit OpenSearch optimierten Instanzen, für die Ultrawarm noch nicht aktiviert ist
Keine Unterstützung für Cold Tier
Wissenswertes
Bei einer mehrstufigen Architektur kommt es bei Migrationen von heiß zu warm nicht zu einer erzwungenen Zusammenführung. Bei Bedarf kann der Benutzer dennoch erzwungene Zusammenführungen mithilfe der Indexverwaltungsrichtlinie orchestrieren.
Neben der Indizierung führen warme Knoten jetzt auch Zusammenführungsoperationen im Hintergrund durch (ähnlich wie bei heißen Knoten).
Alle Suchanfragen für warme Indizes werden an den primären Shard weitergeleitet, und Replica verarbeitet Lesevorgänge nur, wenn der primäre Shard ausgefallen ist.
Automatisierte Snapshots für warme Indizes werden mit dieser Architektur ebenfalls unterstützt
Clusterübergreifende Replikation wird nur für Hot-Indizes unterstützt
Indizes APIs wie Shrink, Split and Clone funktionieren nicht mit warmen Indizes.
Eine mehrstufige Domain erstellen
Schritt 1: Erstellen Sie die Domain
aws opensearch create-domain \ --domain-name my-domain \ --engine-version OpenSearch_3.3 \ --cluster-config InstanceCount=3,InstanceType=or2.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3,WarmEnabled=true,WarmCount=3,WarmType=oi2.2xlarge.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":"user_name","MasterUserPassword":"your_pass"}}' \ --access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":"*","Action":"es:*","Resource":"*"}]}' \ --region us-east-1
Schritt 2: Überprüfen Sie warme Knoten
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
Beispielantwort (Auszug):
{ "NodeType": "Warm", "InstanceType": "oi2.large.search", "NodeStatus": "Active" }
Verwaltung von Tier-Migrationen
Unterstützung für mehrstufige Domains:
Neues Tiering APIs für ein vereinfachtes Erlebnis
Legacy aus UltraWarm APIs Kompatibilitätsgründen
Neues Tiering APIs
Migrieren Sie einen Index nach Warm:
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
Antwort:
{"acknowledged": true}
Migrieren Sie einen Index zu Hot:
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
Antwort:
{"acknowledged": true}
Überprüfen Sie den Tiering-Status:
curl -XGET 'https://localhost:9200/index-name/_tier'
Beispielantwort:
{ "tiering_status": { "index": "index-name", "state": "RUNNING_SHARD_RELOCATION", "source": "HOT", "target": "WARM", "start_time": 1745836500563, "shard_level_status": { "running": 0, "total": 100, "pending": 100, "succeeded": 0 } } }
Detaillierte Shard-Ansicht:
curl 'https://localhost:9200/index1/_tier?detailed=true'
Alle laufenden Migrationen auflisten (Text):
curl 'https://localhost:9200/_tier/all'
Alle laufenden Migrationen auflisten (JSON):
curl 'https://localhost:9200/_tier/all?format=json'
Nach Zielstufe filtern:
curl 'https://localhost:9200/_tier/all?target=_warm'
Legacy aus UltraWarm APIs Kompatibilitätsgründen
Zu Warm migrieren:
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
Zu heiß migrieren:
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
Status überprüfen:
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
Security configuration (Sicherheitskonfiguration)
Wenn Sie Multi-Tier-Speicher auf einer bereits vorhandenen Amazon OpenSearch Service-Domain aktivieren, ist die storage_tiering_manager Rolle möglicherweise nicht für die Domain 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 storage_tiering_manager-Rolle manuell zu erstellen:
-
Gehen Sie in den OpenSearch Dashboards zu Sicherheit und wählen Sie Berechtigungen aus.
-
Wählen Sie Aktionsgruppe erstellen und konfigurieren Sie die folgenden Gruppen:
Gruppenname Berechtigungen storage_tiering_cluster Indices: admin/_tier/all storage_tiering_index_read Indices: admin/_ tier/get, indices:admin/get storage_tiering_index_write Indices: admin/_ _to_hot tier/hot_to_warm, indices:admin/_tier/warm -
Wählen Sie Rollen und Rolle erstellen.
-
Benennen Sie die Rolle
storage_tiering_manager. -
Wählen Sie für Clusterberechtigungen
storage_tiering_clusterundcluster_monitoraus. -
Geben Sie für Index
*ein. -
Wählen Sie für Indexberechtigungen die Optionen und aus.
storage_tiering_index_readstorage_tiering_index_writeindices_monitor -
Wählen Sie Erstellen aus.
-
Nachdem Sie die Rolle erstellt haben, ordnen Sie sie einer beliebigen Benutzer- oder Backend-Rolle zu, die mehrstufige Indizes verwaltet.
Best Practices
Beachten Sie bei der Implementierung von mehrstufigem Speicher in Ihren Amazon OpenSearch Service-Domains die folgenden bewährten Methoden:
Überprüfen Sie regelmäßig Ihre Datenzugriffsmuster, um die Tierzuweisung zu optimieren
Überwachen Sie Leistungskennzahlen, um eine effiziente Ressourcennutzung sicherzustellen
Nutzen Sie das neue Tiering APIs für eine detaillierte Kontrolle der Datenmigration
Metriken überwachen
Mehrstufige Speicherdomänen bieten zusätzliche Messwerte für die Überwachung der Warm-Tier-Leistung. Diese Metriken umfassen sowohl bestehende UltraWarm Metriken als auch neue Metriken, die speziell für die OpenSearch Optimized Instance-Architektur spezifisch sind:
Neue Metriken
| Metrikname | Statistiken auf Knotenebene | Statistiken auf Clusterebene | Granularity |
|---|---|---|---|
| WarmIndexingLatency | Durchschnitt | Durchschnitt | 1 Minute |
| WarmIndexingRate | Durchschnitt | Durchschnitt, Maximum, Summe | 1 Minute |
| WarmThreadpoolIndexingQueue | Maximum | Summe, Maximum, Durchschnitt | 1 Minute |
| WarmThreadpoolIndexingRejected | Maximum | Summe | 1 Minute |
| WarmThreadpoolIndexingThreads | Maximum | Summe, Durchschnitt | 1 Minute |