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

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, и, скорее всего, потребуется увеличить timeout, чтобы дать время для успешного завершения процесса. Вы должны запустить анализ на многоузловом кластере, аналогичном вашему производственному кластеру, чтобы выявить любые проблемы, возникающие только при одновременном доступе к репозиторию многих узлов.

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

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

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

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

Анализ включает в себя несколько задач на уровне блоков, как задано параметром blob_count. Задачи на уровне блоков распределяются по узлам данных и мастер-узлам кластера для выполнения.

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

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

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

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

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