UltraWarm armazenamento para Amazon OpenSearch Service

UltraWarm fornece uma maneira econômica de armazenar grandes quantidades de dados somente para leitura no Amazon Service. OpenSearch Os nós de dados padrão usam armazenamento “dinâmico”, que assume a forma de armazenamentos de instâncias ou EBS volumes da Amazon anexados a cada nó. O armazenamento de atividade muito alta fornece a performance mais rápida possível para indexar e pesquisar novos dados.

Em vez de armazenamento conectado, UltraWarm os nós usam o Amazon S3 e uma solução sofisticada de armazenamento em cache para melhorar o desempenho. Para índices nos quais você não está gravando ativamente, consultar com menos frequência e dos quais não precisa do mesmo desempenho UltraWarm oferece custos significativamente mais baixos por GiB de dados. Como os índices quentes são somente para leitura, a menos que você os devolva ao armazenamento ativo, UltraWarm é mais adequado para dados imutáveis, como registros.

Em OpenSearch, os índices quentes se comportam como qualquer outro índice. Você pode consultá-los usando o mesmo APIs ou usá-los para criar visualizações em OpenSearch painéis.

Pré-requisitos

UltraWarm tem alguns pré-requisitos importantes:

• UltraWarm requer o Elasticsearch 6.8 OpenSearch ou superior.

• Para usar o armazenamento de alta atividade (warm), os domínios devem ter nós principais dedicados.

• Ao usar um Multi-AZ com domínio em espera, o número de nós quentes deve ser um múltiplo do número de zonas de disponibilidade que estão sendo usadas.

• Se o domínio usar um tipo de instância T2 ou T3 para os nós de dados, não será possível usar o armazenamento de alta atividade.

• Se seu índice usa k-NN ("index.knn":true) aproximado, você pode movê-lo para um armazenamento aquecido a partir da versão 2.17 e posterior. Domínios em versões anteriores à 2.17 podem ser atualizados para a 2.17 para usar essa funcionalidade, mas KNN os índices criados em versões anteriores à 2.x não podem migrar para o. UltraWarm

• Se o domínio usa controle de acesso refinado, os usuários devem ser mapeados para a ultrawarm_manager função nos OpenSearch painéis para fazer chamadas. UltraWarm API

nota

A ultrawarm_manager função pode não estar definida em alguns domínios de OpenSearch serviço preexistentes. Se você não vir a função no Dashboards, será necessário criá-la manualmente.

Configurar permissões

Se você habilitar UltraWarm em um domínio OpenSearch de serviço preexistente, a ultrawarm_manager função pode não estar definida no domínio. Os usuários não administradores deverão ser mapeados nessa função para poderem gerenciar índices warm usando o controle de aceso detalhado. Para criar manualmente a função ultrawarm_manager, faça o seguinte:

1. Em OpenSearch Painéis, acesse Segurança e escolha Permissões.

2. Escolha Criar grupo de ações e configure os seguintes grupos:

   Group name	Permissões
   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. Escolha Funções e, em seguida, Criar função.

4. Nomeie a função como ultrawarm_manager.

5. Para Permissões de cluster, selecione ultrawarm_cluster e cluster_monitor.

6. Para Índice, digite *.

7. Para Permissões de índice, selecione ultrawarm_index_read, ultrawarm_index_write, e indices_monitor.

8. Escolha Criar.

9. Depois de criar a função, mapeie-a para qualquer função de usuário ou back-end que gerenciará UltraWarm índices.

UltraWarm requisitos de armazenamento e considerações de desempenho

Conforme abordado emCálculo de requisitos de armazenamento, os dados no armazenamento dinâmico geram uma sobrecarga significativa: réplicas, espaço reservado do Linux e espaço reservado do OpenSearch serviço. Por exemplo, um fragmento primário de 20 GiB com um fragmento de réplica requer aproximadamente 58 GiB de armazenamento de atividade muito alta.

Como ele usa o Amazon S3, não UltraWarm incorre em nenhuma dessas despesas gerais. Ao calcular os requisitos UltraWarm de armazenamento, você considera somente o tamanho dos fragmentos primários. A durabilidade dos dados no S3 elimina a necessidade de réplicas e o S3 abstrai qualquer consideração de sistema operacional ou de serviço. Esse mesmo fragmento de 20 GiB exige 20 GiB de armazenamento de alta atividade. Se você provisionar uma instância ultrawarm1.large.search, poderá usar todos os 20 TiB de seu armazenamento máximo para fragmentos primários. Consulte UltraWarm cotas de armazenamento para obter um resumo dos tipos de instância e a quantidade máxima de armazenamento que cada um pode atender.

Com UltraWarm, ainda recomendamos um tamanho máximo de fragmento de 50 GiB. O número de CPU núcleos e a quantidade RAM alocada para cada tipo de UltraWarm instância dão uma ideia do número de fragmentos que eles podem pesquisar simultaneamente. Observe que, embora apenas os fragmentos primários contem para o UltraWarm armazenamento no S3, os OpenSearch painéis _cat/indices ainda relatam o tamanho do UltraWarm índice como o total de todos os fragmentos primários e de réplica.

Por exemplo, cada ultrawarm1.medium.search instância tem dois CPU núcleos e pode endereçar até 1,5 TiB de armazenamento no S3. Duas dessas instâncias têm uma combinação de 3 TiB de armazenamento, o que funcionará para aproximadamente 62 fragmentos se o tamanho de cada fragmento for 50 GiB. Se uma solicitação para o cluster pesquisar apenas quatro desses fragmentos, a performance poderá ser excelente. Se a solicitação for ampla e pesquisar todas as 62, os quatro CPU núcleos poderão ter dificuldades para realizar a operação. Monitore as WarmJVMMemoryPressure UltraWarm métricas WarmCPUUtilization e para entender como as instâncias lidam com suas cargas de trabalho.

Se as suas pesquisas forem amplas ou frequentes, considere deixar os índices no armazenamento quente. Assim como qualquer outra OpenSearch carga de trabalho, a etapa mais importante para determinar se UltraWarm atende às suas necessidades é realizar testes representativos do cliente usando um conjunto de dados realista.

UltraWarm preços

Com o armazenamento de alta atividade, você paga pelo que provisiona. Algumas instâncias exigem um EBS volume Amazon anexado, enquanto outras incluem um armazenamento de instâncias. Se esse armazenamento estiver vazio ou cheio, você pagará o mesmo preço.

Com o UltraWarm armazenamento, você paga pelo que usa. Uma instância ultrawarm1.large.search pode processar até 20 TiB de armazenamento no S3, mas se você armazenar apenas 1 TiB de dados, será cobrado somente por 1 TiB de dados. Como todos os outros tipos de nós, você também paga uma taxa horária por cada UltraWarm nó. Para obter mais informações, consulte Preços do Amazon OpenSearch Service.

Habilitando UltraWarm

O console é a maneira mais simples de criar um domínio que usa o armazenamento de alta atividade. Ao criar o domínio, escolha Habilitar nós de UltraWarm dados e o número de nós quentes que você deseja. O mesmo processo básico funciona em domínios existentes, desde que eles atendam aos pré-requisitos. Mesmo depois que o estado do domínio mudar de Processamento para Ativo, UltraWarm pode não estar disponível para uso por várias horas.

Ao usar um domínio Multi-AZ com modo de espera, o número de nós quentes deve ser um múltiplo do número de zonas de disponibilidade que estão sendo usadas. Para obter mais informações, consulte Multi-AZ com modo de espera.

Você também pode usar a configuração AWS CLIou API para habilitar UltraWarm, especificamenteWarmEnabled, as WarmType opçõesWarmCount, e emClusterConfig.

nota

Os domínios oferecem suporte a um número máximo de nós de alta atividade. Para obter detalhes, consulte Cotas OpenSearch do Amazon Service.

Exemplo de CLI comando

O AWS CLI comando a seguir cria um domínio com três nós de dados, três nós principais dedicados, seis nós quentes e um controle de acesso refinado ativado:

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

Para obter mais informações, consulte a Referência de comandos da AWS CLI.

Exemplo de API solicitação de configuração

A solicitação de configuração a seguir API cria um domínio com três nós de dados, três nós principais dedicados e seis nós quentes com controle de acesso refinado ativado e uma política de acesso restritiva:

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

Para obter informações detalhadas, consulte a APIReferência OpenSearch de Serviços da Amazon.

Migração de índices para armazenamento UltraWarm

Se você terminou de escrever em um índice e não precisa mais do desempenho de pesquisa mais rápido possível, migre-o de hot para UltraWarm:

POST _ultrawarm/migration/my-index/_warm

Depois, verifique o status da migração:

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

A integridade do índice deve ser verde para que seja possível executar uma migração. Se você migrar vários índices em rápida sucessão, poderá obter um resumo de todas as migrações em texto simples, semelhante ao: _cat API

GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch O serviço migra um índice por vez para o. UltraWarm É possível ter até 200 migrações na fila. Qualquer solicitação que exceda o limite será rejeitada. Para verificar o número de migrações atual, monitore a métrica HotToWarmMigrationQueueSize. Os índices permanecem disponíveis durante todo o processo de migração, sem tempo de inatividade.

O processo de migração tem os seguintes estados:

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

Como esses estados indicam, as migrações podem falhar durante os snapshots, as realocações de fragmentos ou as uniões de força. As falhas durante os snapshots ou as realocações de fragmentos geralmente ocorrem devido a falhas de nós ou a problemas de conectividade do S3. A falta de espaço em disco geralmente é a causa subjacente das falhas de união de força.

Após o término da migração, a mesma solicitação _status retornará um erro. Se você verificar o índice nesse momento, verá algumas configurações exclusivas dos índices mornos:

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, nesse caso, é o número de réplicas passivas, que não consomem espaço em disco.

• routing.allocation.require.box_type especifica que o índice deve usar nós de alta atividade em vez de nós de dados padrão.

• merge.policy.max_merge_at_once_explicit especifica o número de segmentos a serem mesclados simultaneamente durante a migração.

Os índices no armazenamento quente são somente para leitura, a menos que você os retorne ao armazenamento ativo, o que os torna UltraWarm mais adequados para dados imutáveis, como registros. Você pode consultar os índices e excluí-los, mas não pode adicionar, atualizar ou excluir documentos individuais. Se tentar, você poderá encontrar a seguinte mensagem de erro:

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

Automatização de migrações

Recomendamos usar Gerenciamento de estados de índices no Amazon OpenSearch Service para automatizar o processo de migração depois que um índice atinge uma determinada idade ou atende a outras condições. Consulte a política de exemplo que demonstra este fluxo de trabalho.

Ajuste de migrações

As migrações de índice para o UltraWarm armazenamento exigem uma mesclagem forçada. Cada OpenSearch índice é composto por um certo número de fragmentos, e cada fragmento é composto por algum número de segmentos do Lucene. A operação de forças mesclagem expurga documentos que foram marcados para exclusão e conserva espaço em disco. Por padrão, UltraWarm mescla índices em um segmento, exceto os índices kNN, nos quais um valor padrão de 20 é usado.

Você pode alterar esse valor para até 1.000 segmentos usando a configuração index.ultrawarm.migration.force_merge.max_num_segments. Valores mais altos aceleram o processo de migração, mas aumentam a latência de consulta para o índice de alta atividade após a conclusão da migração. Para alterar a configuração, faça a seguinte solicitação:

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

Para verificar a duração desse estágio do processo de migração, monitore a métrica HotToWarmMigrationForceMergeLatency.

Cancelamento de migrações

UltraWarm lida com migrações sequencialmente, em uma fila. Se uma migração estiver na fila, mas ainda não tiver sido iniciada, você poderá removê-la da fila usando a seguinte solicitação:

POST _ultrawarm/migration/_cancel/my-index

Se o domínio usa controle de acesso refinado, você precisará da permissão indices:admin/ultrawarm/migration/cancel para fazer essa solicitação.

Listagem de índices quentes e mornos

UltraWarm adiciona duas opções adicionais, semelhantes a_all, para ajudar a gerenciar índices quentes e quentes. Para obter uma lista de todos os índices mornos ou quentes, faça as seguintes solicitações:

GET _warm
GET _hot

Você pode usar essas opções em outras solicitações que especificam índices, como:

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

Retorno de índices warm para o armazenamento quente

Se você precisar gravar em um índice novamente, migre-o de volta para o armazenamento de atividade muito alta:

POST _ultrawarm/migration/my-index/_hot

Você pode ter até 10 migrações em fila do armazenamento quente para o armazenamento quente por vez. OpenSearch O serviço processa as solicitações de migração uma de cada vez, na ordem em que foram colocadas na fila. Para verificar o número atual, monitore a WarmToHotMigrationQueueSize métrica.

Após a conclusão da migração, verifique as configurações de índice para garantir que atendam às suas necessidades. Os índices retornam ao armazenamento quente com uma réplica.

Restauração de índices quentes de snapshots

Além do repositório padrão para instantâneos automatizados, UltraWarm adiciona um segundo repositório para índices quentes,. cs-ultrawarm Cada snapshot neste repositório contém apenas um índice. Se você excluir um índice de alta atividade, seu instantâneo permanecerá no repositório cs-ultrawarm por 14 dias, assim como qualquer outro snapshot automatizado.

Quando você restaura um snapshot de cs-ultrawarm, ele é restaurado no armazenamento de alta atividade (warm), não no armazenamento de atividade muito alta (hot). Os snapshots nos repositórios cs-automated e cs-automated-enc são restaurados no armazenamento de atividade muito alta.

Para restaurar um UltraWarm instantâneo para um armazenamento aquecido

1. Identifique o snapshot mais recente que contém o índice que você deseja restaurar:

   GET _snapshot/cs-ultrawarm/_all?verbose=false
   
   {
     "snapshots": [{
       "snapshot": "snapshot-name",
       "version": "1.0",
       "indices": [
         "my-index"
       ]
     }]
   }

   nota

   Por padrão, a operação GET _snapshot/<repo> exibe informações detalhadas de dados, como hora de início, hora de término e duração de cada instantâneo em um repositório. A operação GET _snapshot/<repo> recupera informações dos arquivos de cada instantâneo contido em um repositório. Se você não precisar do horário de início, horário de término e duração e precisar apenas do nome e das informações de índice de um snapshot, recomendamos usar o parâmetro verbose=false ao listar snapshots para minimizar o tempo de processamento e evitar o tempo limite.

2. Se o índice já existir, exclua-o:

   DELETE my-index

   Se não quiser excluir o índice, devolva-o ao armazenamento de atividade muito alta e reindexe-o.

3. Restaure o snapshot:

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

   UltraWarm ignora todas as configurações de índice que você especificar nessa solicitação de restauração, mas você pode especificar opções como rename_pattern e. rename_replacement Para obter um resumo das opções de restauração de OpenSearch instantâneos, consulte a OpenSearch documentação.

Snapshots manuais de índices mornos

Você pode obter snapshots manuais de índices mornos, mas não recomendamos fazer isso. O repositório cs-ultrawarm automatizado já contém um snapshot para cada índice de alta atividade, obtido durante a migração, sem custo adicional.

Por padrão, o OpenSearch Serviço não inclui índices quentes em instantâneos manuais. Por exemplo, a chamada a seguir inclui apenas índices quentes:

PUT _snapshot/my-repository/my-snapshot

Se você optar por obter snapshots manuais de índices mornos, diversas considerações importantes serão aplicáveis.

• Você não pode misturar índices quentes e mornos. Por exemplo, a solicitação a seguir falha:

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

  Se eles incluírem uma mistura de índices quentes e mornos, as instruções universais (*) também falharão.

• Você só pode incluir um índice de alta atividade por snapshot. Por exemplo, a solicitação a seguir falha:

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

  Esta solicitação é bem-sucedida:

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

• Os snapshots manuais são sempre restaurados para o armazenamento de atividade muito alta, mesmo que tenham originalmente incluído um índice de alta atividade.

Migração de índices mornos para o armazenamento frio

Se você tiver dados UltraWarm que não consulta com frequência, considere migrá-los para o armazenamento a frio. O armazenamento de baixa atividade é destinado a dados que você acessa apenas ocasionalmente ou que não estão mais em uso ativo. Você não pode ler nem gravar em índices frios, mas pode migrá-los de volta para o armazenamento morno sem nenhum custo sempre que precisar consultá-los. Para obter instruções, consulte Migração de índices para armazenamento refrigerado.

Práticas recomendadas para KNN índices

• O nível Ultrawarm/Cold está disponível para todos os tipos de motores de KNN índice. Nós o recomendamos para KNN índices que usam o mecanismo Lucene e a pesquisa vetorial otimizada para disco, que não exige carregar totalmente os dados do gráfico na memória off-heap. Ao usá-lo com mecanismos nativos de memória, como FAISS eNMSLIB, você deve considerar o tamanho do gráfico de fragmentos que serão pesquisados ativamente e provisionar as UltraWarm instâncias, preferencialmente do tipo de uw.large instância, adequadamente. Por exemplo, se os clientes tiverem duas uw.large instâncias configuradas, cada uma terá aproximadamente knn.memory.circuit_breaker.limit * 61 GiB de memória off-heap disponível. Você obtém um desempenho ideal se todas as suas consultas quentes tiverem como alvo fragmentos cujo tamanho cumulativo do gráfico não exceda a memória off-heap disponível. A latência é afetada se a memória disponível for menor do que a necessária para carregar o gráfico devido aos despejos e à espera que a memória fora da pilha fique disponível. É por isso que não recomendamos o uso de uw.medium instâncias para casos de uso em que mecanismos na memória estão sendo usados ou para casos de maior produtividade de pesquisa, independentemente dos mecanismos.

• KNNos índices migrados para não UltraWarm serão mesclados à força em um único segmento. Isso evita qualquer impacto nos nós quentes e quentes que tenham OOM problemas devido ao tamanho do gráfico se tornar muito grande para os mecanismos na memória. Devido ao aumento no número de segmentos por fragmento, isso pode resultar no consumo de mais espaço de cache local e na possibilidade de menos índices migrarem para o nível quente. Você pode optar por forçar a mesclagem de índices em um único segmento usando a configuração existente e substituindo-a antes de migrar os índices para a camada quente. Para obter mais informações, consulte Ajuste de migrações.

• Se você tiver um caso de uso em que os índices são pesquisados com pouca frequência e não atendem a uma carga de trabalho sensível à latência, você pode optar por migrar esses índices para o nível. UltraWarm Isso ajudará você a reduzir as instâncias de computação de nível ativo e permitir que a computação de UltraWarm nível gerencie a consulta nesses índices de baixa prioridade. Isso também pode ajudar a isolar os recursos consumidos entre as consultas de índices de baixa e alta prioridade, para que eles não afetem um ao outro.

Desativando UltraWarm

O console é a maneira mais simples de desativar UltraWarm. Escolha o domínio, Ações, e Editar configuração do cluster. Desmarque a opção Ativar nós de UltraWarm dados e escolha Salvar alterações. Você também pode usar a WarmEnabled opção na configuração AWS CLI API e.

Antes de desativar UltraWarm, você deve excluir todos os índices quentes ou migrá-los de volta para o armazenamento ativo. Depois que o armazenamento quente estiver vazio, aguarde cinco minutos antes de tentar UltraWarm desativá-lo.