API анализа репозиториев

resp = client.perform_request(
    "POST",
    "/_snapshot/my_repository/_analyze",
    params={
        "blob_count": "10",
        "max_blob_size": "1mb",
        "timeout": "120s"
    },
)
print(resp)

response = client.snapshot.repository_analyze(
  repository: 'my_repository',
  blob_count: 10,
  max_blob_size: '1mb',
  timeout: '120s'
)
puts response

const response = await client.transport.request({
  method: "POST",
  path: "/_snapshot/my_repository/_analyze",
  querystring: {
    blob_count: "10",
    max_blob_size: "1mb",
    timeout: "120s",
  },
});
console.log(response);

POST /_snapshot/my_repository/_analyze?blob_count=10&max_blob_size=1mb&timeout=120s

POST /_snapshot/<repository>/_analyze

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

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

Значения параметров по умолчанию для этого API специально низкие, чтобы уменьшить влияние случайного запуска анализа и предоставить разумную отправную точку для ваших исследований. Запустите свой первый анализ со значениями параметров по умолчанию, чтобы проверить наличие простых проблем. При успешном выполнении запустите последовательность анализов с возрастающими размерами, пока не столкнётесь с ошибкой или не достигнете blob_count по крайней мере 2000, max_blob_size по крайней мере 2gb, max_total_data_size по крайней мере 1tb и register_operation_count по крайней мере 100. Всегда указывайте достаточно большой таймаут, возможно, 1h или больше, чтобы дать время каждому анализу завершиться. Выполняйте анализы с использованием многоузлового кластера, аналогичного по размеру вашему производственному кластеру, чтобы обнаружить любые проблемы, возникающие только при доступе к репозиторию сразу многими узлами.

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

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

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

Если анализ завершится успешно, это означает, что он не обнаружил неправильного поведения, но это не гарантирует правильное поведение. Анализ пытается обнаружить распространённые ошибки, но он, безусловно, не обеспечивает 100% охвата. Кроме того, он не тестирует следующее:

Анализ состоит из ряда задач на уровне фрагментов, как задано параметром blob_count, и ряда операций сравнения и обмена в линейно упорядоченных регистрах, как задано параметром register_operation_count. Эти задачи распределяются по узлам данных и узлам-мастерам кластера для выполнения.

Для большинства задач на уровне фрагментов исполняющий узел сначала записывает фрагмент в репозиторий, а затем инструктирует некоторые другие узлы в кластере попробовать прочитать только что записанные данные. Размер фрагмента выбирается случайным образом в соответствии с параметрами max_blob_size и max_total_data_size. Если какое-либо из этих чтений завершится неудачей, репозиторий не реализует необходимые семантику чтения после записи, которые требуются Elasticsearch.

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

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

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

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

Линейно упорядоченные регистры — это специальные фрагменты, которые Elasticsearch обрабатывает с помощью атомарной операции сравнения и обмена. Эта операция гарантирует правильное и строго согласованное поведение, даже когда к фрагменту обращаются несколько узлов одновременно. Подробная реализация операции сравнения и обмена в линейно упорядоченных регистрах различается в зависимости от типа репозитория. Анализ репозитория проверяет, что неконкурентные операции сравнения и обмена в линейно упорядоченном фрагменте регистра всегда завершаются успешно. Анализ репозитория также проверяет, что конкурентные операции либо завершаются успешно, либо сообщают о конфликте, но не возвращают неверные результаты. Если операция завершается неудачей из-за конфликта, Elasticsearch повторяет операцию до тех пор, пока она не завершится успешно. Большинство операций сравнения и обмена, выполняемых анализом репозитория, атомарно увеличивают счётчик, который представлен фрагментом размером 8 байт. Некоторые операции также проверяют поведение на небольших фрагментах с размерами, отличными от 8 байт.