Регистрация хранилища моментальных снимков

Это руководство показывает, как зарегистрировать хранилище снимков. Хранилище снимков — это место хранения вне кластера для ваших снимков. Вы должны зарегистрировать хранилище, прежде чем сможете создавать или восстанавливать снимки.

В этом руководстве вы узнаете, как:

При регистрации хранилища снимков имейте в виду следующее:

Вы можете регистрировать и управлять хранилищами снимков двумя способами:

Чтобы управлять хранилищами в Kibana, перейдите в главное меню и щелкните Управление стеком > Снимок и Восстановление > Хранилища. Чтобы зарегистрировать хранилище снимков, щелкните Зарегистрировать хранилище.

Вы также можете зарегистрировать хранилище с помощью API создания хранилища снимков.

Поддерживаемые типы хранилищ снимков зависят от типа вашей среды:

Развертывания Elasticsearch Service автоматически регистрируют хранилище found-snapshots. Elasticsearch Service использует это хранилище и cloud-snapshot-policy для периодического создания снимков вашего кластера. Вы также можете использовать хранилище found-snapshots для собственных политик found-snapshots или для хранения поисковых снимков.

Хранилище found-snapshots специфично для каждого развертывания. Однако вы можете восстановить снимки из хранилища found-snapshots другого развертывания, если развертывания находятся в рамках одной учётной записи и одной области. Подробнее см. документацию Cloud Снимок и восстановление.

Развертывания Elasticsearch Service также поддерживают следующие типы хранилищ:

Если вы управляете собственным кластером Elasticsearch, вы можете использовать следующие встроенные типы хранилищ снимков:

Другие типы хранилищ доступны через официальные плагины:

Вы также можете использовать альтернативные реализации хранилища с этими типами хранилищ, если альтернативная реализация полностью совместима. Например, MinIO предоставляет альтернативную реализацию API AWS S3, и вы можете использовать MinIO с типом хранилища s3.

Обратите внимание, что некоторые системы хранения заявляют о совместимости с этими типами хранилищ, не полностью эмулируя их поведение. Elasticsearch требует полной совместимости. В частности, альтернативная реализация должна поддерживать тот же набор API-точек входа, возвращать те же ошибки в случае сбоев и обеспечивать эквивалентные гарантии согласованности и производительности даже при одновременном доступе нескольких узлов. Несовместимые коды ошибок, согласованность или производительность могут быть особенно трудно отслеживаемы, так как ошибки, сбои согласованности и проблемы с производительностью обычно редки и трудно воспроизводимы.

Вы можете выполнить некоторые базовые проверки пригодности вашей системы хранения с помощью API анализа хранилища. Если этот API не завершится успешно или укажет на низкую производительность, то ваша система хранения не полностью совместима и поэтому непригодна для использования в качестве хранилища снимков. Вам необходимо будет обратиться к поставщику вашей системы хранения для устранения любых возникших несовместимостей.

При регистрации хранилища снимков Elasticsearch автоматически проверяет доступность и работоспособность хранилища на всех узлах мастера и данных.

Чтобы отключить эту проверку, установите параметр запроса API создания хранилища снимков verify в значение false. Отключить проверку хранилища в Kibana нельзя.

resp = client.snapshot.create_repository(
    name="my_unverified_backup",
    verify=False,
    repository={
        "type": "fs",
        "settings": {
            "location": "my_unverified_backup_location"
        }
    },
)
print(resp)

response = client.snapshot.create_repository(
  repository: 'my_unverified_backup',
  verify: false,
  body: {
    type: 'fs',
    settings: {
      location: 'my_unverified_backup_location'
    }
  }
)
puts response

const response = await client.snapshot.createRepository({
  name: "my_unverified_backup",
  verify: "false",
  repository: {
    type: "fs",
    settings: {
      location: "my_unverified_backup_location",
    },
  },
});
console.log(response);

PUT _snapshot/my_unverified_backup?verify=false
{
  "type": "fs",
  "settings": {
    "location": "my_unverified_backup_location"
  }
}

При необходимости вы можете вручную выполнить проверку работоспособности хранилища. Чтобы проверить хранилище в Kibana, перейдите на страницу списка хранилищ и щелкните имя хранилища. Затем щелкните Проверить хранилище. Вы также можете использовать API проверки хранилища снимков.

resp = client.snapshot.verify_repository(
    name="my_unverified_backup",
)
print(resp)

response = client.snapshot.verify_repository(
  repository: 'my_unverified_backup'
)
puts response

const response = await client.snapshot.verifyRepository({
  name: "my_unverified_backup",
});
console.log(response);

POST _snapshot/my_unverified_backup/_verify

При успешном выполнении запрос возвращает список узлов, используемых для проверки хранилища. В случае неудачи запрос возвращает ошибку.

Вы можете более тщательно проверить хранилище с помощью API анализа хранилища.

Репозитории со временем могут накапливать данные, на которые не ссылается ни один существующий снимок. Это результат гарантий сохранности данных, которые предоставляет функциональность снимков в сценариях сбоев во время создания снимков, и децентрализованной природы процесса создания снимков. Эти неиспользуемые данные никак не влияют на производительность или безопасность репозитория снимков, но приводят к более высокому, чем необходимо, использованию хранилища. Чтобы удалить эти неиспользуемые данные, вы можете запустить операцию очистки репозитория. Это запустит полное учёт содержимого репозитория и удалит все неиспользуемые данные.

Чтобы запустить операцию очистки репозитория в Kibana, перейдите на страницу списка Репозиториев и щелкните имя репозитория. Затем нажмите Очистить репозиторий.

Вы также можете использовать API очистки репозитория снимков.

resp = client.snapshot.cleanup_repository(
    name="my_repository",
)
print(resp)

response = client.snapshot.cleanup_repository(
  repository: 'my_repository'
)
puts response

const response = await client.snapshot.cleanupRepository({
  name: "my_repository",
});
console.log(response);

POST _snapshot/my_repository/_cleanup

API возвращает:

{
  "results": {
    "deleted_bytes": 20,
    "deleted_blobs": 5
  }
}

В зависимости от конкретной реализации репозитория, показанные значения свободных байтов, а также количество удалённых блоков, могут быть приблизительными или точными. Любое ненулевое значение количества удалённых блоков подразумевает, что были найдены и удалены неиспользуемые блоки.

Обратите внимание, что большинство операций очистки, выполняемых этим конечным пунктом, автоматически выполняются при удалении любого снимка из репозитория. Если вы регулярно удаляете снимки, в большинстве случаев вы не получите каких-либо или получите лишь незначительные экономии места, используя эту функциональность, и соответственно должны снизить частоту её вызова.

Вам может потребоваться создать независимую резервную копию вашего репозитория, например, чтобы получить архивную копию его содержимого, которую можно использовать для восстановления репозитория в его текущем состоянии в будущем.

Вы должны убедиться, что Elasticsearch не записывает в репозиторий, пока вы выполняете резервное копирование его содержимого. Если Elasticsearch запишет любые данные в репозиторий во время резервного копирования, содержимое резервной копии может быть несогласованным, и в будущем может быть невозможно восстановить любые данные из неё. Предотвратите запись в репозиторий, деактивировав репозиторий в кластере, который имеет к нему доступ для записи.

В качестве альтернативы, если ваш репозиторий его поддерживает, вы можете выполнить атомарный снимок базовой файловой системы, а затем создать резервную копию этого снимка файловой системы. Очень важно, чтобы снимок файловой системы был выполнен атомарно.

При восстановлении репозитория из резервной копии вы не должны регистрировать репозиторий в Elasticsearch до тех пор, пока содержимое репозитория не будет полностью восстановлено. Если вы измените содержимое репозитория, когда он зарегистрирован в Elasticsearch, репозиторий может стать нечитаемым или незаметно потеряет часть своего содержимого. После восстановления репозитория из резервной копии используйте API проверки целостности репозитория, чтобы проверить его целостность, прежде чем начать использовать репозиторий.