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, ergeben sich deutlich UltraWarm niedrigere Kosten pro GiB an Daten. 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 mit denselben APIs abfragen oder sie verwenden, um Visualisierungen in Dashboards zu erstellen. OpenSearch

Voraussetzungen

UltraWarm hat ein paar wichtige Voraussetzungen:

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:

UltraWarm Speicheranforderungen und Leistungsaspekte

Wie unter beschriebenBerechnung der Speicheranforderungen, 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.

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 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, 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.

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 UltraWarm Datenknoten aktivieren und geben Sie die gewünschte Anzahl an warmen Knoten an. Derselbe grundlegende Prozess funktioniert auf vorhandenen Domains, sofern sie die Voraussetzungenerfüllen. Auch wenn der Domänenstatus von „In Bearbeitung“ auf „Aktiv“ geändert wurde, kann er UltraWarm möglicherweise mehrere Stunden lang nicht verwendet werden.

Bei Verwendung einer Multi-AZ mit Standby-Domain muss die Anzahl der warmen Knoten ein Vielfaches der Anzahl der verwendeten Availability Zones sein. Weitere Informationen finden Sie unter Multi-AZ mit Standby.

Sie können auch die Konfigurations-API AWS CLIoder verwenden UltraWarm, um insbesondere die WarmType Optionen WarmEnabledWarmCount, und in ClusterConfig zu aktivieren.

Beispiel für einen CLI-Befehl

Mit dem folgenden AWS CLI Befehl wird eine Domäne mit drei Datenknoten, drei dedizierten Master-Knoten, sechs warmen Knoten und aktivierter detaillierter Zugriffskontrolle erstellt:

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.

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.

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. 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"
          }
        }
      }
    }
  }
}

Indizes im Warmspeicher sind schreibgeschützt, es sei denn, Sie geben sie in den Hotspeicher zurück. 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 zur Automatisierung des Migrationsprozesses, nachdem ein Index ein bestimmtes Alter erreicht hat oder andere Bedingungen erfüllt. Sehen Sie sich die Beispielrichtlinie 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 UltraWarm einem Segment zusammen.

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.

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 vom Warm- zum Hot-Speicher gleichzeitig in der Warteschlange durchführen. OpenSearch Der Service verarbeitet Migrationsanfragen nacheinander in der Reihenfolge, in der sie sich in der Warteschlange befanden. Überwachen Sie die WarmToHotMigrationQueueSize-Metrik, 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.

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.

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 Migration von Indizes auf Cold-Speicher.

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 die Option UltraWarm Datenknoten 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 oder sie zurück in den Hot-Storage migrieren. Wenn der Warmspeicher leer ist, warten Sie fünf Minuten, bevor Sie versuchen, ihn zu deaktivieren UltraWarm.