Следуйте приведенным ниже инструкциям, чтобы оценить размер резервной копии кластера для хранилища метрик и хранилища Elasticsearch. Общий размер резервной копии кластера можно приблизительно оценить как сумму ваших примерных размеров резервной копии для хранилища метрик и хранилища Elasticsearch.
Общая формула
Оцените размер резервной копии хранилища метрик.
Обычно это 20% от суммы хранилища метрик на всех узлах. Количество узлов не влияет на формулу.
Доступное место для хранения резервных копий
Текущая резервная копия хранилища метрик сохраняется до завершения следующего резервного копирования и создания новой резервной копии. Таким образом, до тех пор, пока не будет удалена первая резервная копия, объем дискового пространства, необходимый для резервной копии хранилища метрик, будет вдвое больше фактического размера вашей резервной копии. По этой причине мы рекомендуем удвоить предполагаемое пространство, необходимое для резервного копирования хранилища метрик.
1. Оцените размер резервной копии хранилища Elasticsearch.
Предполагаемый требуемый размер резервной копии для Elasticsearch основан на размере хранилища ElasticSearch. Обычно это меньше суммы хранилища ElasticSearch на всех узлах. Хотя резервная копия Elasticsearch не содержит реплик данных, из-за инкрементных снапшотов мы используем общий объем хранилища для оценки.
2. Оцените размер резервной копии кластера.
Основываясь на предыдущих оценках, рассчитайте предполагаемый размер резервной копии как 20% хранилища метрик + хранилище Elasticsearch.
Пример оценки
Например, предположим, что вы хотите оценить размер резервной копии для трехузлового кластера:
1. Рассчитайте хранилище метрик для всего кластера.
Проверьте размер хранилища метрик на диске на каждом узле. Размер должен незначительно отличаться между узлами.
du -sh /var/opt/<name>/cassandra/
885GB
В нашем примере кластер имеет три узла, и один узел имеет 885 ГБ хранилища метрик, поэтому мы можем оценить хранилище метрик как: 3 * 885 ГБ = 2,6 ТБ.
2. Рассчитайте хранилище Elasticsearch для всего кластера.
Проверьте размер хранилища Elasticsearch на диске на каждом узле. Размер должен незначительно отличаться между узлами.
du -sh /var/opt/<name>/elasticsearch/
1.5TB
В нашем примере кластер имеет три узла, и один узел имеет 1,5 ТБ хранилища Elasticsearch, поэтому мы можем оценить хранилище Elasticsearch как: 3 * 1,5 ТБ = 4,5 ТБ.
3. Теперь, когда у нас есть примерные значения для хранилища метрик и Elasticsearch, мы можем оценить размер резервной копии как 20% хранилища метрик + хранилище Elasticsearch: (2,6 ТБ * 0,2) + 4,5 ТБ = 5,02 ТБ.
Размер одной резервной копии оценивался в 5,02 ТБ. Чтобы оценить минимальный размер, который следует выделить для этой резервной копии, необходимо удвоить резервную копию хранилища метрик. Итого это 4,5 ТБ + ((2,6 ТБ * 0,2) * 2) = 5,54 ТБ.
Точность оценки
Эта оценка не будет точной, если она будет рассчитана на новом кластере, который только что начал хранить данные. По мере роста хранилища на диске будет увеличиваться и размер резервной копии.
Резервное копирование только конфигурации
Занимает до 10% хранилища метрик вместо 20% (это на 50% меньше хранилища метрик).
Исключение пользовательских сессий
В высокоинтенсивных средах RUM (50 тыс. пользовательских сеансов в минуту) пользовательские сеансы могут занимать до 99% всего хранилища Elasticsearch. Следовательно, их исключение может убрать оценку резервного копирования Elasticsearch из общей формулы. В других средах трудно оценить уменьшение размера резервной копии. Вы можете обратиться за помощью к специалисту по продукции Ключ-АСТРОМ ONE.