Este tutorial mostra como implementar um cluster de base de dados vetorial do Elasticsearch no Google Kubernetes Engine (GKE).
As bases de dados vetoriais são armazenamentos de dados especificamente concebidos para gerir e pesquisar grandes coleções de vetores de alta dimensão. Estes vetores representam dados como texto, imagens, áudio, vídeo ou quaisquer dados que possam ser codificados numericamente. Ao contrário das bases de dados relacionais que se baseiam em correspondências exatas, as bases de dados vetoriais especializam-se em encontrar itens semelhantes ou identificar padrões em conjuntos de dados massivos.
O Elasticsearch é uma base de dados vetorial que combina funcionalidades de pesquisa e análise. Inclui uma API REST aberta para gerir o seu cluster e suporta consultas estruturadas, consultas de texto completo e consultas complexas. O Elasticsearch permite-lhe fazer pesquisas de expressões, de semelhanças e de prefixos, com sugestões de preenchimento automático.
Este tutorial destina-se a administradores e arquitetos da plataforma na nuvem, engenheiros de ML e profissionais de MLOps (DevOps) interessados na implementação de clusters de bases de dados do Elasticsearch no GKE.
Vantagens
O Elasticsearch oferece as seguintes vantagens:
- Vasta gama de bibliotecas para várias linguagens de programação e API aberta para integração com outros serviços.
- Escalabilidade horizontal e suporte para divisão e replicação que simplificam a escalabilidade e a alta disponibilidade.
- Equilíbrio de clusters com vários nós para uma utilização ideal dos recursos.
- Suporte de contentores e Kubernetes para uma integração perfeita em ambientes nativos da nuvem modernos.
Objetivos
Neste tutorial, vai aprender a:
- Planeie e implemente a infraestrutura do GKE para o Elasticsearch.
- Implemente e configure o Elasticsearch num cluster do GKE.
- Implemente o operador StatefulHA para garantir a elevada disponibilidade do Elasticsearch.
- Execute um notebook para gerar e armazenar exemplos de incorporações de vetores na sua base de dados e execute consultas de pesquisa baseadas em vetores.
- Recolha e visualize métricas num painel de controlo.
Arquitetura de implementação
Neste tutorial, implementa um cluster do GKE regional de alta disponibilidade para o Elasticsearch, com vários nós do Kubernetes distribuídos por várias zonas de disponibilidade. Esta configuração ajuda a garantir a tolerância a falhas, a escalabilidade e a redundância geográfica. Permite atualizações contínuas e manutenção, ao mesmo tempo que oferece SLAs para tempo de atividade e disponibilidade. Para mais informações, consulte o artigo Clusters regionais.
Quando um nó fica inacessível, um pod nesse nó não é reagendado imediatamente. Com os pods a usar um StatefulSet, pode demorar mais de oito minutos para que os pods da aplicação sejam eliminados e reagendados para novos nós.
Para resolver este problema, o operador StatefulHA faz o seguinte:
- Resolve o atraso no reagendamento, processa as definições de comutação por falha e reduz o tempo de recuperação através das definições de
.forceDeleteStrategy
:AfterNodeUnreachable
. - Garante que a aplicação StatefulSet está a usar o RePD.
- Expande o GKE com um recurso HighAvailabilityApplication personalizado que é implementado no mesmo espaço de nomes que o Elasticsearch. Isto permite que o operador StatefulHA monitorize e responda a eventos de comutação por falha.
O diagrama seguinte mostra um cluster do Elasticsearch em execução em vários nós e zonas num cluster do GKE:
Configure o seu ambiente
Para configurar o seu ambiente com o Cloud Shell, siga estes passos:
Defina variáveis de ambiente para o seu projeto, região e um prefixo de recurso de cluster do Kubernetes:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=elasticsearch export REGION=us-central1
- Substitua
PROJECT_ID
pelo seu Google Cloud ID do projeto.
Este tutorial usa a região
us-central1
para criar os recursos de implementação.- Substitua
Verifique a versão do Helm:
helm version
Atualize a versão se for anterior à 3.13:
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
Clone o repositório de código de exemplo do GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Navegue para o
elasticsearch
diretório para começar a criar recursos de implementação:cd kubernetes-engine-samples/databases/elasticsearch
Crie a infraestrutura do cluster
Nesta secção, executa um script do Terraform para criar um cluster do GKE regional privado e de elevada disponibilidade para implementar a sua base de dados do Elasticsearch.
Pode optar por implementar o Elasticsearch através de um cluster padrão ou do Autopilot. Cada um tem as suas próprias vantagens e modelos de preços diferentes.
Piloto automático
O diagrama seguinte mostra um cluster do GKE Autopilot implementado no projeto.
Para implementar a infraestrutura do cluster, execute os seguintes comandos no Cloud Shell:
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
O GKE substitui as seguintes variáveis no tempo de execução:
GOOGLE_OAUTH_ACCESS_TOKEN
usa o comandogcloud auth print-access-token
para obter um token de acesso que autentica as interações com várias APIs Google CloudPROJECT_ID
,REGION
eKUBERNETES_CLUSTER_PREFIX
são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster do Autopilot que está a criar.
Quando lhe for pedido, escreva yes
.
O resultado é semelhante ao seguinte:
...
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials elasticsearch-cluster --region us-central1"
O Terraform cria os seguintes recursos:
- Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
- Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
- Um cluster do GKE privado na região
us-central1
. - Um
ServiceAccount
com autorizações de registo e monitorização para o cluster. - Configuração do serviço gerido Google Cloud para o Prometheus para monitorização e alertas de clusters.
Standard
O diagrama seguinte mostra um cluster GKE regional privado padrão implementado em três zonas diferentes.
Para implementar a infraestrutura do cluster, execute os seguintes comandos no Cloud Shell:
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
O GKE substitui as seguintes variáveis no tempo de execução:
GOOGLE_OAUTH_ACCESS_TOKEN
usa o comandogcloud auth print-access-token
para obter um token de acesso que autentica as interações com várias APIs Google Cloud.PROJECT_ID
,REGION
eKUBERNETES_CLUSTER_PREFIX
são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster padrão que está a criar.
Quando lhe for pedido, escreva yes
. Estes comandos podem demorar vários minutos a serem concluídos e o cluster pode demorar a apresentar o estado pronto.
O resultado é semelhante ao seguinte:
...
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.
Outputs:
kubectl_connection_command = "gcloud container clusters get-credentials elasticsearch-cluster --region us-central1"
O Terraform cria os seguintes recursos:
- Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
- Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
- Um cluster do GKE privado na região
us-central1
com a escala automática ativada (um a dois nós por zona). - Um
ServiceAccount
com autorizações de registo e monitorização para o cluster. - Configuração do Google Cloud Managed Service for Prometheus para monitorização e alertas de clusters.
Estabeleça ligação ao cluster
Configure o kubectl
para obter credenciais e comunicar com o seu novo cluster do GKE:
gcloud container clusters get-credentials \
${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}
Implemente a base de dados Elasticsearch e o operador StatefulHA
Nesta secção, implementa a base de dados Elasticsearch (no modo de cluster) e o operador StatefulHA no cluster do GKE através do gráfico Helm do operador ECK.
A implementação cria um cluster do GKE com a seguinte configuração:
- Três réplicas dos nós do Elasticsearch.
- DaemonSet para alterar as definições de memória virtual, para um desempenho ideal do Elasticsearch. Um DaemonSet é um controlador do Kubernetes que garante que uma cópia de um Pod é executada em cada nó num cluster.
- Configuração de NodeAffinity e PodAntiAffinity para garantir a distribuição adequada em nós do Kubernetes, otimizando a utilização de node pools e maximizando a disponibilidade em diferentes zonas.
- Um operador de HA com estado que gere processos de comutação por falha e garanta a alta disponibilidade. Um StatefulSet é um controlador do Kubernetes que mantém uma identidade única persistente para cada um dos respetivos pods.
- Para a autenticação, a base de dados cria Secrets do Kubernetes com credenciais de autenticação, palavras-passe e certificados.
Para usar o gráfico Helm para implementar a base de dados Elasticsearch, siga estes passos:
Ative o suplemento StatefulHA:
Piloto automático
O GKE ativa automaticamente o suplemento
StatefulHA
aquando da criação do cluster.Standard
Execute o seguinte comando:
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \ --project=${PROJECT_ID} \ --location=${REGION} \ --update-addons=StatefulHA=ENABLED
Este comando pode demorar 15 minutos a ser concluído e o cluster pode demorar 15 minutos a apresentar o estado pronto.
Crie uma definição de recurso personalizado (CRD) do Elastic Cloud on Kubernetes (ECK):
kubectl apply -f https://download.elastic.co/downloads/eck/2.11.1/crds.yaml
Implemente o operador ECK:
kubectl apply -f https://download.elastic.co/downloads/eck/2.11.1/operator.yaml
Crie o espaço de nomes
elastic
para a base de dados:kubectl create ns elastic
Instale o recurso
HighAvailabilityApplication
(HAA), que define regras de comutação por falha para o Elasticsearch.kubectl apply -n elastic -f manifests/01-regional-pd/ha-app.yaml
O manifesto
ha-app.yaml
descreve o recursoHighAvailabilityApplication
:Aplique o manifesto para criar um disco SSD persistente regional
StorageClass
:kubectl apply -n elastic -f manifests/01-regional-pd/regional-pd.yaml
O manifesto
regional-pd.yaml
descreve o disco SSD persistenteStorageClass
:Implemente o recurso DaemonSet para definir a memória virtual em cada nó:
kubectl apply -n elastic -f manifests/02-elasticsearch/mmap-count.yaml
O manifesto
mmap-count.yaml
descreve oDaemonSet
:Aplique o manifesto para implementar o cluster do Elasticsearch:
kubectl apply -n elastic -f manifests/02-elasticsearch/elasticsearch.yaml
O manifesto
elasticsearch.yaml
descreve a implementação:Aguarde alguns minutos até que o cluster do Elasticsearch seja iniciado totalmente.
Verifique o estado da implementação:
kubectl get elasticsearch -n elastic --watch
O resultado é semelhante ao seguinte, se a base de dados
elasticsearch
for implementada com êxito:NAME HEALTH NODES VERSION PHASE AGE elasticsearch-ha green 3 8.11.4 Ready 2m30s
Aguarde até que
HEALTH
seja apresentado comogreen
. Prima Ctrl+C para sair do comando, se necessário.Implemente um equilibrador de carga interno para aceder à sua base de dados do Elasticsearch que está a ser executada na mesma VPC que o seu cluster do GKE:
kubectl apply -n elastic -f manifests/02-elasticsearch/ilb.yaml
O manifesto
ilb.yaml
descreve o serviçoLoadBalancer
:Para verificar se as regras de comutação por falha são aplicadas, descreva o recurso e confirme
Status: Message: Application is protected
.kubectl describe highavailabilityapplication elasticsearch-ha-es-main -n elastic
O resultado é semelhante ao seguinte
Status: Conditions: Last Transition Time: 2024-02-01T13:27:50Z Message: Application is protected Observed Generation: 1 Reason: ApplicationProtected Status: True Type: Protected Events: <none>
Assim que o GKE iniciar as cargas de trabalho, verifique se o GKE criou as cargas de trabalho do Elasticsearch:
kubectl get pod,svc,statefulset,pdb,secret,daemonset -n elastic
O resultado é semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE pod/elasticsearch-ha-es-main-0 2/2 Running 0 7m16s pod/elasticsearch-ha-es-main-1 2/2 Running 0 7m16s pod/elasticsearch-ha-es-main-2 2/2 Running 0 7m16s pod/max-map-count-setter-28wt9 1/1 Running 0 7m27s pod/max-map-count-setter-cflsw 1/1 Running 0 7m27s pod/max-map-count-setter-gzq9k 1/1 Running 0 7m27s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/elasticsearch-ha-es-http ClusterIP 10.52.8.28 <none> 9200/TCP 7m18s service/elasticsearch-ha-es-internal-http ClusterIP 10.52.3.48 <none> 9200/TCP 7m18s service/elasticsearch-ha-es-main ClusterIP None <none> 9200/TCP 7m16s service/elasticsearch-ha-es-transport ClusterIP None <none> 9300/TCP 7m18s NAME READY AGE statefulset.apps/elasticsearch-ha-es-main 3/3 7m16s NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE poddisruptionbudget.policy/elasticsearch-ha-es-default 2 N/A 1 7m16s NAME TYPE DATA AGE secret/elasticsearch-ha-es-elastic-user Opaque 1 7m18s secret/elasticsearch-ha-es-file-settings Opaque 1 7m16s secret/elasticsearch-ha-es-http-ca-internal Opaque 2 7m17s secret/elasticsearch-ha-es-http-certs-internal Opaque 3 7m17s secret/elasticsearch-ha-es-http-certs-public Opaque 2 7m17s secret/elasticsearch-ha-es-internal-users Opaque 4 7m18s secret/elasticsearch-ha-es-main-es-config Opaque 1 7m16s secret/elasticsearch-ha-es-main-es-transport-certs Opaque 7 7m16s secret/elasticsearch-ha-es-remote-ca Opaque 1 7m16s secret/elasticsearch-ha-es-transport-ca-internal Opaque 2 7m16s secret/elasticsearch-ha-es-transport-certs-public Opaque 1 7m16s secret/elasticsearch-ha-es-xpack-file-realm Opaque 4 7m18s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/max-map-count-setter 6 6 6 6 6 <none> 13m
Os seguintes recursos do GKE são criados para o cluster do Elasticsearch:
- O Elasticsearch
StatefulSet
que controla três réplicas de pods. - Um DaemonSet para configurar as definições de memória virtual.
- Serviços para estabelecer ligação ao Elasticsearch.
- Informações secretas com credenciais de superutilizador e certificados relacionados com o serviço.
- Pod do operador de HA com estado e recurso
HighlyAvailableApplication
, a monitorizar ativamente a aplicação Elasticsearch.
Execute consultas com o bloco de notas do Vertex AI Colab Enterprise
Esta secção explica como gerar incorporações em documentos do Elasticsearch e executar consultas de pesquisa semântica usando o cliente Python oficial do Elasticsearch no bloco de notas do Colab Enterprise. Um documento no Elasticsearch é composto por vários campos, cada um associado ao respetivo valor.
Para mais informações sobre o Vertex AI Colab Enterprise, consulte a documentação do Colab Enterprise.
Para usar o Elasticsearch de forma eficaz, recomendamos que estruture os seus dados nestes documentos, que são depois indexados para fins de pesquisa.
Neste exemplo, usa um conjunto de dados de um ficheiro CSV que contém uma lista de livros de diferentes géneros. O Elasticsearch funciona como um motor de pesquisa e o pod que cria funciona como um cliente que consulta a base de dados do Elasticsearch.
Pode usar um modelo de tempo de execução dedicado para implementar na elasticsearch-vpc
VPC (nuvem privada virtual), para que o bloco de notas possa comunicar com os recursos no seu cluster do GKE.
Crie um modelo de tempo de execução
Para criar um modelo de tempo de execução do Colab Enterprise:
Na Google Cloud consola, aceda à página Modelos de tempo de execução do Colab Enterprise e certifique-se de que o seu projeto está selecionado:
Clique em add_box Novo modelo. É apresentada a página Criar novo modelo de tempo de execução.
Na secção Noções básicas do ambiente de execução:
- No campo Nome a apresentar, introduza
elastic-connect
. - Na lista pendente Região, selecione
us-central1
. É a mesma região que o seu cluster do GKE.
- No campo Nome a apresentar, introduza
Na secção Configurar computação:
- Na lista pendente Tipo de máquina, selecione
e2-standard-2
. - No campo Tamanho do disco, introduza
30
.
- Na lista pendente Tipo de máquina, selecione
Na secção Redes e segurança:
- Na lista pendente Rede, selecione a rede onde o seu cluster do GKE reside.
- Na lista pendente Sub-rede, selecione uma sub-rede correspondente.
- Desmarque a caixa de verificação Ativar acesso público à Internet.
Para concluir a criação do modelo de tempo de execução, clique em Criar. O modelo de tempo de execução aparece na lista no separador Modelos de tempo de execução.
Crie um tempo de execução
Para criar um tempo de execução do Colab Enterprise:
Na lista de modelos de tempo de execução do modelo que acabou de criar, na coluna Ações, clique em more_vert e, de seguida, clique em Criar tempo de execução. É apresentado o painel Criar tempo de execução do Vertex AI.
Para criar um tempo de execução com base no seu modelo, clique em Criar.
No separador Tempos de execução que é aberto, aguarde até que o estado passe a Em bom estado.
Importe o bloco de notas
Para importar o bloco de notas no Colab Enterprise:
Aceda ao separador Os meus blocos de notas e clique em Importar. É apresentado o painel Importar blocos de notas.
Em Origem da importação, selecione URL.
Em URLs do bloco de notas, introduza o seguinte link:
https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/main/databases/elasticsearch/manifests/03-notebook/vector-database.ipynb
Clique em Importar.
Ligue-se ao tempo de execução e execute consultas
Para associar ao tempo de execução e executar consultas:
No bloco de notas, junto ao botão Associar, clique em arrow_drop_down Opções de associação adicionais. É apresentado o painel Ligar ao tempo de execução do Vertex AI.
Selecione Ligar a um tempo de execução e, de seguida, selecione Ligar a um tempo de execução existente.
Selecione o tempo de execução que iniciou e clique em Associar.
Para executar as células do bloco de notas, clique no botão
Executar célula junto a cada célula de código.
O bloco de notas contém células de código e texto que descrevem cada bloqueio de código. A execução de uma célula de código executa os respetivos comandos e apresenta um resultado. Pode executar as células por ordem ou executar células individuais conforme necessário.
Veja as métricas do Prometheus para o seu cluster
O cluster do GKE está configurado com o Google Cloud Managed Service for Prometheus, que permite a recolha de métricas no formato Prometheus. Este serviço oferece uma solução totalmente gerida para monitorização e alertas, permitindo a recolha, o armazenamento e a análise de métricas do cluster e das respetivas aplicações.
O diagrama seguinte mostra como o Prometheus recolhe métricas para o seu cluster:
O cluster privado do GKE no diagrama contém os seguintes componentes:
- Pods do Elasticsearch que expõem métricas no caminho
/
e na porta9114
. Estas métricas são fornecidas pelo contentor sidecar denominadometrics
que contém o elasticsearch_exporter. - Coletores baseados no Prometheus que processam as métricas do pod do Elasticsearch.
- Um recurso PodMonitoring que envia as métricas para o Cloud Monitoring.
A configuração do cluster define um contentor sidecar com o exportador de métricas no formato Prometheus:
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elasticsearch-ha
spec:
...
nodeSets:
- name: main
...
podTemplate:
spec:
containers:
...
- name: metrics
image: quay.io/prometheuscommunity/elasticsearch-exporter:v1.7.0
command:
- /bin/elasticsearch_exporter
- --es.ssl-skip-verify
- --es.uri=https://$(ES_USER):$(ES_PASSWORD)@localhost:9200
...
env:
- name: ES_USER
value: "elastic"
- name: ES_PASSWORD
valueFrom:
secretKeyRef:
name: elasticsearch-ha-es-elastic-user
key: elastic
Para exportar e ver as métricas, siga estes passos:
Crie o recurso
PodMonitoring
para extrair métricas porlabelSelector
:kubectl apply -n elastic -f manifests/04-prometheus-metrics/pod-monitoring.yaml
O manifesto
pod-monitoring.yaml
descreve o recursoPodMonitoring
:Após alguns minutos, é apresentado o painel de controlo incorporado "Elasticsearch Prometheus Overview" (Vista geral do Elasticsearch Prometheus).
Para ver mais gráficos relacionados com dados, importe um painel de controlo do Cloud Monitoring personalizado com as configurações definidas em
dashboard.json
:gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
Depois de o comando ser executado com êxito, aceda a Cloud Monitoring Painéis de controlo:
Na lista de painéis de controlo, abra o painel de controlo
ElasticSearch Overview
. Pode demorar 1 a 2 minutos a recolher e apresentar métricas.O painel de controlo mostra uma contagem das principais métricas:
- Índices
- Documentos e fragmentos
- Operações pendentes
- Executar nós com os respetivos estados de saúde
Faça uma cópia de segurança da configuração do cluster
A funcionalidade Cópia de segurança do GKE permite-lhe agendar cópias de segurança regulares da configuração completa do cluster do GKE, incluindo as cargas de trabalho implementadas e os respetivos dados.
Neste tutorial, vai configurar um plano de cópia de segurança para o seu cluster do GKE para fazer cópias de segurança de todas as cargas de trabalho, incluindo segredos e volumes, todos os dias às 03:00. Para garantir uma gestão de armazenamento eficiente, as cópias de segurança com mais de três dias são eliminadas automaticamente.
Ative a funcionalidade Cópia de segurança do GKE para o seu cluster:
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \ --project=${PROJECT_ID} \ --location=${REGION} \ --update-addons=BackupRestore=ENABLED
Crie um plano de cópia de segurança com uma programação diária para todos os espaços de nomes no cluster:
gcloud beta container backup-restore backup-plans create ${KUBERNETES_CLUSTER_PREFIX}-cluster-backup \ --project=${PROJECT_ID} \ --location=${REGION} \ --cluster="projects/${PROJECT_ID}/locations/${REGION}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster" \ --all-namespaces \ --include-secrets \ --include-volume-data \ --cron-schedule="0 3 * * *" \ --backup-retain-days=3
O comando usa as variáveis de ambiente relevantes no tempo de execução.
O formato do nome do cluster é relativo ao seu projeto e região, da seguinte forma:
projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME
Quando lhe for pedido, escreva
y.
O resultado é semelhante ao seguinte:Create request issued for: [elasticsearch-cluster-backup] Waiting for operation [projects/PROJECT_ID/locations/us-central1/operations/operation-1706528750815-610142ffdc9ac-71be4a05-f61c99fc] to complete...⠹
Esta operação pode demorar alguns minutos a ser concluída com êxito. Após a conclusão da execução, o resultado é semelhante ao seguinte:
Created backup plan [elasticsearch-cluster-backup].
Pode ver o plano de cópia de segurança recém-criado
elasticsearch-cluster-backup
listado na consola de cópia de segurança do GKE.
Se quiser restaurar as configurações de cópia de segurança guardadas, consulte o artigo Restaure uma cópia de segurança.