UltraWarm 아마존 OpenSearch 서비스용 스토리지 - 아마존 OpenSearch 서비스
사전 조건 UltraWarm 스토리지 요구 사항 및 성능 고려 사항UltraWarm 가격 책정활성화 UltraWarm인덱스를 스토리지로 마이그레이션 UltraWarm 마이그레이션 자동화마이그레이션 조정마이그레이션 취소핫 인덱스 및 웜 인덱스 나열핫 스토리지로 웜 인덱스 되돌리기스냅샷에서 웜 인덱스 복원웜 인덱스의 수동 스냅샷콜드 스토리지로 웜 인덱스 마이그레이션비활성화 UltraWarm

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

UltraWarm 아마존 OpenSearch 서비스용 스토리지

UltraWarm Amazon OpenSearch Service에 대량의 읽기 전용 데이터를 저장하는 비용 효율적인 방법을 제공합니다. 표준 데이터 노드는 각 노드에 연결된 Amazon EBS 볼륨 또는 인스턴스 스토어의 형태를 취하는 “핫” 스토리지를 사용합니다. 핫 스토리지의 새로운 데이터 인덱싱 및 검색 성능이 가장 빠릅니다.

UltraWarm 노드는 연결된 스토리지 대신 Amazon S3와 정교한 캐싱 솔루션을 사용하여 성능을 개선합니다. 쓰기 작업이 활발하지 않고 쿼리 빈도가 낮고 동일한 성능이 필요하지 않은 인덱스의 경우 데이터 GiB당 비용을 크게 낮출 수 있습니다. UltraWarm 웜 인덱스는 핫 스토리지로 반환하지 않는 한 읽기 전용이므로 로그와 같은 UltraWarm 변경할 수 없는 데이터에 가장 적합합니다.

에서 OpenSearch 웜 인덱스는 다른 인덱스와 동일하게 동작합니다. 동일한 API를 사용하여 쿼리하거나 대시보드에서 시각화를 생성하는 데 사용할 수 있습니다. OpenSearch

사전 조건 

UltraWarm 다음과 같은 몇 가지 중요한 사전 요구 사항이 있습니다.

  • UltraWarm OpenSearch 또는 엘라스틱서치 6.8 이상이 필요합니다.

  • 웜 스토리지를 사용하려면 도메인에 전용 프라이머리 노드가 있어야 합니다.

  • 대기 도메인과 함께 다중 AZ를 사용하는 경우 웜 노드 수는 사용 중인 가용 영역 수의 배수여야 합니다.

  • 도메인이 데이터 노드에 T2 또는 T3 인스턴스 유형을 사용하는 경우, 웜 스토리지를 사용할 수 없습니다.

  • 색인이 근사치 k-NN("index.knn": true)을 사용하는 경우 웜 스토리지로 이동할 수 없습니다.

  • 도메인에서 세분화된 액세스 제어를 사용하는 경우 API를 호출하려면 사용자를 OpenSearch 대시보드의 ultrawarm_manager 역할에 매핑해야 합니다. UltraWarm

참고

일부 기존 ultrawarm_manager 서비스 도메인에서는 역할이 정의되지 않을 수 있습니다. OpenSearch Dashboards에 역할이 보이지 않으면 수동으로 생성해야 합니다.

권한 구성

기존 OpenSearch 서비스 UltraWarm 도메인에서 활성화하면 도메인에서 ultrawarm_manager 역할이 정의되지 않을 수 있습니다. 관리자가 아닌 사용자는 이 역할에 매핑되어 세분화된 액세스 제어를 사용하는 도메인의 웜 인덱스를 관리해야 합니다. 수동으로 ultrawarm_manager 역할을 생성하려면 다음 단계를 수행합니다.

  1. OpenSearch 대시보드에서 보안으로 이동하고 권한을 선택합니다.

  2. 작업 그룹 생성(Create action group)을 선택하고 다음 그룹을 구성합니다.

    그룹 이름 권한
    ultrawarm_cluster

    • cluster:admin/ultrawarm/migration/list

    • cluster:monitor/nodes/stats
    ultrawarm_index_read

    • indices:admin/ultrawarm/migration/get

    • indices:admin/get
    ultrawarm_index_write

    • indices:admin/ultrawarm/migration/warm

    • indices:admin/ultrawarm/migration/hot

    • indices:monitor/stats

    • indices:admin/ultrawarm/migration/cancel

  3. 역할(Roles)과 역할 생성(Create role)을 차례로 선택합니다.

  4. 역할 이름을 ultrawarm_manager로 지정합니다.

  5. 클러스터 권한(Cluster permissions)에서 ultrawarm_cluster 및 cluster_monitor를 선택합니다.

  6. 인덱스(Index)에 *를 입력합니다.

  7. 인덱스 권한(Index permissions)에서 ultrawarm_index_read, ultrawarm_index_write, indices_monitor를 선택합니다.

  8. 생성(Create)을 선택합니다.

  9. 역할을 만든 후에는 인덱스를 관리할 UltraWarm 사용자 또는 백엔드 역할에 역할을 매핑하세요.

UltraWarm 스토리지 요구 사항 및 성능 고려 사항

에서 설명한 것처럼 핫 스토리지의 데이터에는 복제본스토리지 요구 사항 계산, Linux 예약 공간, 서비스 예약 공간 등 상당한 오버헤드가 발생합니다. OpenSearch 예를 들어, 복제본 샤드가 1개인 20GiB 기본 샤드에는 약 58GiB의 핫 스토리지가 필요합니다.

Amazon S3를 사용하기 때문에 이 UltraWarm 오버헤드가 전혀 발생하지 않습니다. UltraWarm 스토리지 요구 사항을 계산할 때는 기본 샤드의 크기만 고려합니다. S3의 데이터 내구성 덕분에 복제본이 필요하지 않으며, S3는 운영 체제 또는 서비스 고려 사항을 추상화합니다. 동일한 20GiB 샤드에는 20GiB의 웜 스토리지가 필요합니다. ultrawarm1.large.search 인스턴스를 프로비저닝하는 경우, 기본 샤드에 최대 스토리지 20TiB를 모두 사용할 수 있습니다. 인스턴스 유형 요약과 각 인스턴스 유형이 사용할 수 있는 최대 스토리지 용량은 UltraWarm 스토리지 할당량 섹션을 참조하세요.

UltraWarm에서는 여전히 최대 샤드 크기를 50GiB로 설정하는 것이 좋습니다. 각 UltraWarm 인스턴스 유형에 할당된 CPU 코어 수와 RAM 용량을 통해 동시에 검색할 수 있는 샤드 수를 파악할 수 있습니다. 참고로 S3에는 기본 샤드만 UltraWarm 스토리지에 포함되지만 OpenSearch 대시보드는 _cat/indices 여전히 UltraWarm 인덱스 크기를 모든 기본 및 복제 샤드의 합계로 보고합니다.

예를 들어, 각 ultrawarm1.medium.search 인스턴스에는 2개의 CPU 코어가 있으며 S3에서 최대 1.5TiB 스토리지를 처리할 수 있습니다. 이러한 인스턴스 중 두 개에는 결합된 3TiB 스토리지가 있으며, 각 샤드가 50GiB인 경우 약 62개의 샤드로 작동합니다. 클러스터에 대한 요청이 이러한 샤드 중 네 개만 검색하는 경우 성능이 우수할 수 있습니다. 요청이 광범위하고 62개를 모두 검색하면 4개의 CPU 코어가 작업을 수행하는 데 어려움을 겪을 수 있습니다. WarmCPUUtilization및 WarmJVMMemoryPressure UltraWarm 지표를 모니터링하여 인스턴스가 워크로드를 처리하는 방식을 이해하십시오.

검색 범위가 넓거나 빈번한 경우 인덱스를 핫 스토리지에 남겨 두는 것이 좋습니다. 다른 OpenSearch 워크로드와 마찬가지로 요구 UltraWarm 사항을 충족하는지 확인하는 가장 중요한 단계는 실제 데이터 세트를 사용하여 대표적인 클라이언트 테스트를 수행하는 것입니다.

UltraWarm 가격 책정

핫 스토리지를 사용하면 프로비저닝하는 만큼 비용을 지불합니다. 연결된 Amazon EBS 볼륨이 필요한 인스턴스가 있는가 하면, 인스턴스 스토어가 포함되어 있는 인스턴스도 있습니다. 스토리지가 비어 있든 가득 차 있든, 동일한 가격을 지불합니다.

UltraWarm 스토리지를 사용하면 사용한 만큼만 비용을 지불하면 됩니다. ultrawarm1.large.search 인스턴스는 S3에서 최대 20TiB의 스토리지를 처리할 수 있지만, 1TiB의 데이터만 저장하는 경우 1TiB의 데이터에 해당하는 비용만 청구됩니다. 다른 모든 노드 유형과 마찬가지로 각 UltraWarm 노드에 대해서도 시간당 요금을 지불합니다. 자세한 정보는 아마존 OpenSearch 서비스 요금을 참조하세요.

활성화 UltraWarm

콘솔은 웜 스토리지를 사용하는 도메인을 생성하는 가장 간단한 방법입니다. 도메인을 생성할 때 UltraWarm 데이터 노드 활성화 및 원하는 웜 노드 수를 선택합니다. 사전 조건을 충족하는 경우 기존 도메인에서도 동일한 기본 프로세스가 적용됩니다. 도메인 상태가 Processing 상태에서 Active로 변경된 후에도 몇 시간 동안 사용하지 UltraWarm 못할 수 있습니다.

대기 도메인과 함께 다중 AZ를 사용하는 경우 웜 노드 수는 사용 중인 가용 영역 수의 배수여야 합니다. 자세한 정보는 Multi-AZ with Standby을 참조하세요.

AWS CLI또는 구성 API를 사용하여 특히 UltraWarm WarmEnabledWarmCount, 및 WarmType 옵션을 활성화할 수도 있습니다. ClusterConfig

참고

도메인은 최대 수의 웜 노드를 지원합니다. 자세한 내용은 아마존 OpenSearch 서비스 할당량 섹션을 참조하세요.

CLI 명령 예

다음 AWS CLI 명령을 실행하면 데이터 노드 3개, 전용 마스터 노드 3개, 웜 노드 6개, 세분화된 액세스 제어가 활성화된 도메인이 생성됩니다.

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

자세한 내용은 AWS CLI 명령 참조를 참조하세요.

샘플 구성 API 요청

구성 API에 대한 다음 요청은 3개의 데이터 노드, 3개의 전용 프라이머리 노드, 세분화된 액세스 제어가 활성화되어 있고 제한적인 액세스 정책이 있는 6개의 웜 노드로 도메인을 생성합니다.

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/*\"}]}"
}

자세한 내용은 Amazon OpenSearch 서비스 API 참조를 참조하십시오.

인덱스를 스토리지로 마이그레이션 UltraWarm

인덱스 쓰기를 완료하여 가능한 가장 빠른 검색 성능이 더 이상 필요하지 않은 경우 핫 인덱스에서 다음으로 마이그레이션하십시오. UltraWarm 

POST _ultrawarm/migration/my-index/_warm

그런 다음 마이그레이션 상태를 확인합니다.

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

마이그레이션을 수행하려면 인덱스 상태가 녹색이어야 합니다. 여러 인덱스를 빠르게 연속해서 마이그레이션하는 경우 _cat API와 비슷한 일반 텍스트로 모든 마이그레이션에 대한 요약을 얻을 수 있습니다.

GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch 서비스는 한 번에 하나의 인덱스로 마이그레이션합니다. UltraWarm 대기열에 최대 200번의 마이그레이션이 있을 수 있습니다. 한도를 초과하는 요청은 거부됩니다. 현재 대기열의 마이그레이션 번호를 확인하려면 HotToWarmMigrationQueueSize 지표를 모니터링합니다. 인덱스는 마이그레이션 프로세스 전반에 걸쳐 계속 사용할 수 있으며 가동 중지 없이 사용할 수 있습니다.

마이그레이션 프로세스의 상태는 다음과 같습니다.

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

이러한 상태가 나타내듯이 스냅샷, 샤드 재배치 또는 강제 병합 중에 마이그레이션이 실패할 수 있습니다. 스냅샷 또는 샤드 재배치 중 실패는 일반적으로 노드 오류 또는 S3 연결 문제로 인해 발생합니다. 일반적으로 디스크 공간 부족이 강제 병합 실패의 근본 원인입니다.

마이그레이션이 완료되면 동일한 _status 요청이 오류를 반환합니다. 이때 인덱스를 확인하면 웜 인덱스만의 고유한 몇 가지 설정을 볼 수 있습니다.

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는 디스크 공간을 소비하지 않는 수동 복제본의 수입니다.

  • routing.allocation.require.box_type은 인덱스가 표준 데이터 노드가 아닌 웜 노드를 사용하도록 지정합니다.

  • merge.policy.max_merge_at_once_explicit는 마이그레이션 중에 동시에 병합할 세그먼트 수를 지정합니다.

웜 스토리지의 인덱스는 핫 스토리지로 반환하지 않는 한 읽기 전용이므로 로그와 같은 변경할 수 없는 데이터에 UltraWarm 가장 적합합니다. 인덱스를 쿼리하여 삭제할 수 있지만 개별 문서를 추가, 업데이트 또는 삭제할 수 없습니다. 시도하는 경우 오류가 발생할 수 있습니다.

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

마이그레이션 자동화

인덱스가 특정 기간에 도달하거나 다른 조건을 충족한 후에는 Amazon OpenSearch 서비스의 인덱스 상태 관리을 사용하여 마이그레이션 프로세스를 자동화하는 것이 좋습니다. 이 워크플로를 보여주는 샘플 정책을 참조하세요.

마이그레이션 조정

인덱스를 스토리지로 마이그레이션하려면 강제 병합이 필요합니다 UltraWarm . 각 OpenSearch 인덱스는 몇 개의 샤드로 구성되고 각 샤드는 몇 개의 Lucene 세그먼트로 구성됩니다. 강제 병합 작업은 삭제하도록 표시된 문서를 소거하고 디스크 공간을 절약합니다. 기본적으로 인덱스를 하나의 세그먼트로 UltraWarm 병합합니다.

index.ultrawarm.migration.force_merge.max_num_segments 설정을 사용하여 이 값을 최대 1,000개의 세그먼트까지 변경할 수 있습니다. 값이 높을수록 마이그레이션 프로세스 속도가 빨라지지만 마이그레이션이 완료된 후 웜 인덱스에 대한 쿼리 대기 시간이 늘어납니다. 설정을 변경하려면 다음과 같이 요청합니다.

PUT my-index/_settings
{
  "index": {
    "ultrawarm": {
      "migration": {
        "force_merge": {
          "max_num_segments": 1
        }
      }
    }
  }
}

마이그레이션 프로세스의 이 단계에 걸리는 시간을 확인하려면HotToWarmMigrationForceMergeLatency 지표를 모니터링합니다.

마이그레이션 취소

UltraWarm 큐에서 순차적으로 마이그레이션을 처리합니다. 마이그레이션이 대기열에 있지만 아직 시작되지 않은 경우 다음 요청을 사용하여 대기열에서 제거할 수 있습니다.

POST _ultrawarm/migration/_cancel/my-index

도메인에서 세분화된 액세스 제어를 사용하는 경우 이 요청을 하기 위해 indices:admin/ultrawarm/migration/cancel 권한이 필요합니다.

핫 인덱스 및 웜 인덱스 나열

UltraWarm 와 유사한 두 가지 추가 옵션을 추가하여 핫 _all 인덱스와 웜 인덱스를 관리하는 데 도움이 됩니다. 모든 웜 또는 핫 인덱스 목록을 보려면 다음과 같이 요청합니다.

GET _warm
GET _hot

인덱스를 지정하는 다른 요청에서 이러한 옵션을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

_cat/indices/_warm
_cluster/state/_all/_hot

핫 스토리지로 웜 인덱스 되돌리기

인덱스에 다시 기록해야 하는 경우 핫 스토리지로 다시 마이그레이션합니다.

POST _ultrawarm/migration/my-index/_hot

웜 스토리지에서 핫 스토리지로 한 번에 최대 10개의 대기 중인 마이그레이션을 수행할 수 있습니다. OpenSearch 서비스는 마이그레이션 요청을 대기열에 있는 순서대로 한 번에 하나씩 처리합니다. 현재 번호를 확인하려면 WarmToHotMigrationQueueSize 지표를 모니터링합니다.

마이그레이션을 완료한 후 인덱스 설정을 검토하여 요구 사항을 충족하는지 확인합니다. 인덱스가 하나의 복제본이 있는 핫 스토리지로 돌아갑니다.

스냅샷에서 웜 인덱스 복원

자동 스냅샷을 위한 표준 리포지토리 외에도 웜 인덱스를 위한 두 번째 리포지토리를 UltraWarm 추가합니다. cs-ultrawarm 이 리포지토리의 각 스냅샷에는 하나의 인덱스만 포함됩니다. 웜 인덱스를 삭제하면 해당 스냅샷은 다른 자동 스냅샷과 마찬가지로 14일 동안 cs-ultrawarm 리포지토리에 남아 있습니다.

cs-ultrawarm에서 스냅샷을 복원하면 핫 스토리지가 아닌 웜 스토리지로 복원됩니다. cs-automated 및 cs-automated-enc 리포지토리의 스냅샷은 핫 스토리지로 복원됩니다.

UltraWarm 스냅샷을 웜 스토리지에 복원하려면

  1. 복원할 인덱스가 포함된 최신 스냅샷을 식별합니다.

    GET _snapshot/cs-ultrawarm/_all?verbose=false

{
  "snapshots": [{
    "snapshot": "snapshot-name",
    "version": "1.0",
    "indices": [
      "my-index"
    ]
  }]
}
    참고

    기본적으로 GET _snapshot/<repo> 작업에는 리포지토리 내 각 스냅샷의 시작 시간, 종료 시간, 기간과 같은 자세한 데이터 정보가 표시됩니다. 이 GET _snapshot/<repo> 작업은 리포지토리에 포함된 각 스냅샷의 파일에서 정보를 검색합니다. 시작 시간, 종료 시간 및 기간이 필요하지 않고 스냅샷의 이름 및 인덱스 정보만 필요한 경우 스냅샷을 나열할 때 verbose=false 파라미터를 사용하여 처리 시간을 최소화하고 시간 초과를 방지하는 것이 좋습니다.

  2. 인덱스가 이미 있는 경우 삭제합니다.

    DELETE my-index

    인덱스를 삭제하지 않으려면 핫 스토리지로 돌아가 재인덱스합니다.

  3. 스냅샷을 복원합니다.

    POST _snapshot/cs-ultrawarm/snapshot-name/_restore

    UltraWarm 이 복원 요청에서 지정하는 모든 인덱스 설정을 무시하지만, rename_pattern 및 와 rename_replacement 같은 옵션을 지정할 수 있습니다. OpenSearch 스냅샷 복원 옵션에 대한 요약은 OpenSearch 설명서를 참조하십시오.

웜 인덱스의 수동 스냅샷

웜 인덱스의 수동 스냅 샷을 생성할 수 있지만 권장하지 않습니다. 마이그레이션 중에 생성한 각 웜 인덱스에 대한 스냅샷이 추가 비용 없이 자동 cs-ultrawarm 리포지토리에 이미 포함되어 있습니다.

기본적으로 OpenSearch 서비스는 수동 스냅샷에 웜 인덱스를 포함하지 않습니다. 예를 들어, 다음 호출에는 핫 인덱스만 포함됩니다.

PUT _snapshot/my-repository/my-snapshot

웜 인덱스의 수동 스냅샷을 생성하도록 선택하면 몇 가지 중요한 고려 사항이 적용됩니다.

  • 핫 인덱스와 웜 인덱스를 혼합할 수 없습니다. 예를 들어 다음 요청은 실패합니다.

    PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1,hot-index-1",
  "include_global_state": false
}

    핫 인덱스와 웜 인덱스의 혼합을 포함하는 경우, 와일드카드(*) 문도 실패합니다.

  • 스냅샷당 하나의 웜 인덱스만 포함할 수 있습니다. 예를 들어 다음 요청은 실패합니다.

    PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1,warm-index-2,other-warm-indices-*",
  "include_global_state": false
}

    이 요청이 성공한 경우:

    PUT _snapshot/my-repository/my-snapshot
{
  "indices": "warm-index-1",
  "include_global_state": false
}

  • 수동 스냅샷은 원래 웜 인덱스가 포함된 경우에도 항상 핫 스토리지로 복원합니다.

콜드 스토리지로 웜 인덱스 마이그레이션

자주 쿼리하지 않는 데이터가 있는 경우 UltraWarm 해당 데이터를 콜드 스토리지로 마이그레이션하는 것을 고려해 보세요. 콜드 스토리지는 가끔 액세스하거나 더 이상 사용하지 않는 데이터를 위한 것입니다. 콜드 인덱스에서 읽거나 쓸 수는 없지만 쿼리해야 할 때마다 무료로 웜 스토리지로 다시 마이그레이션 할 수 있습니다. 지침은 콜드 스토리지로 인덱스 마이그레이션 섹션을 참조하세요.

비활성화 UltraWarm

콘솔은 UltraWarm 비활성화하는 가장 간단한 방법입니다. 도메인을 선택하고 [작업(Actions)], [클러스터 구성 편집(Edit cluster configuration)]을 선택합니다. UltraWarm 데이터 노드 활성화를 선택 취소하고 변경 내용 저장을 선택합니다. AWS CLI 및 구성 API에서 WarmEnabled 옵션을 사용할 수도 있습니다.

UltraWarm비활성화하기 전에 웜 인덱스를 모두 삭제하거나 핫 스토리지로 다시 마이그레이션해야 합니다. 웜 스토리지가 비워지면 5분 정도 기다린 후 비활성화해 보십시오. UltraWarm