Вопрос или проблема
В настоящее время мы проводим эксперименты с зеркалированием снимков CephFS, чтобы оценить, подходит ли это для создания пассивной резервной копии хранения на вторичном сайте. Мы настроили два кластера CEPH, используя версию CEPH Reef 18.2.2 с 3 узлами, каждый из которых имел загрузочный диск и дополнительный диск объемом 256 ГБ для OSD, в сумме 768 ГБ на кластер, затем мы создали пул Erasure Code для данных CephFS с k = 2 и m = 1, а также реплицируемый пул для метаданных. CephFS был создан на этих двух пулах, и на нем были включены снимки.
Следующим шагом было создание расписания снимков с его политикой хранения (которая составила 24 снимка с интервалом в 1 час), и все работало прекрасно после активации. Мы смонтировали CephFS на одном из наших серверов под определенной точкой монтирования/папкой и заполнили его файлами объемом 45 ГБ для нашего тестирования, затем мы подождали день, что подводит меня к моему вопросу.
Что я ожидал, так это что снимок должен иметь такой же размер, как текущая файловая система (45 ГБ), что действительно так после осмотра папки .snap под точкой монтирования. То, что я не смог понять, это то, что после 24 часов снимков у меня было данных объемом 1.1 ТБ в папке .snap, что не имело смысла, поскольку у нас всего 768 ГБ, и даже около двух третей из этого из-за профиля Erasure Code, хотя команда “ceph status” показывает всего 75 ГБ использования из 768 (что, похоже, не учитывает размеры снимков).
Как это возможно? Я что-то упускаю? Это случайность или CEPH перезаписывает существующие данные? Потому что, когда я проверил, оригинальные файлы были целыми и не поврежденными, а функция зеркалирования работала отлично, имея мои файлы скопированными на второй кластер. Разве не должно было расписание снимков остановиться, когда размер папки .snap превышает общий доступный дисковое пространство? Ваша информация и знания имеют решающее значение, так как документация не упоминает детали о том, как это на практике работает.
Я не знаю, как вы измерили размер папки .snap, но это не имеет смысла. Снимки не являются копиями.
Ответ или решение
Обзор: Использование контрольных точек в CephFS и размер папки .snap
Ваша ситуация с CephFS и его контрольными точками представляет интересный случай для анализа. Давайте глубже рассмотрим механизм работы контрольных точек в CephFS и причины такого поведения, которое вы наблюдаете в папке .snap.
Функции и механика контрольных точек в CephFS
Контрольные точки (snapshots) в CephFS представляют собой мощный инструмент для управления данными, позволяющий фиксировать состояние файловой системы в определенный момент времени. Ключевое здесь то, что контрольные точки не являются прямыми копиями данных. Вместо этого, при их создании CephFS использует механизмы, основанные на ссылочной подсчете (copy-on-write), что означает, что система сохраняет только изменения, которые произошли после создания контрольной точки.
Как работают контрольные точки в CephFS:
-
Сохранение изменений: Когда создается контрольная точка, CephFS не дублирует все данные на момент создания. Вместо этого он продолжает ссылаться на исходные блочные устройства (объекты), и только измененные данные записываются отдельно. Это значительно экономит место.
-
Управление метаданными: Контрольные точки также требуют управления метаданными, что может увеличивать объем используемого пространства. Каждая контрольная точка сохраняет данные о метаданных и о том, какие объекты были изменены.
-
Размер контрольных точек: Несмотря на то, что вы заполнили файловую систему на 45 ГБ, количество данных в
.snapможет быстро увеличиваться из-за частых изменений в файловой системе, создаваемых пользователями или системными процессами, а также копий метаданных для каждой контрольной точки.
Почему размер .snap превышает доступное пространство
Ваши наблюдения о том, что размер папки .snap превысил 1.1 ТБ, могут объясняться следующими факторами:
-
Копирование изменений: Если ваши файлы активно изменяются в течение 24 часов, система создаст множество изменений, записывая каждое из них в новые объекты.
-
Задержка сброса: Система может временно удерживать данные в метаданном пространстве, что также может влиять на отображаемый размер.
-
Отображение статистики: Команда
ceph statusпоказывает состояние кластера, включая использование пространства, однако это может не включать все данные из контрольных точек, особенно если они находятся в процессе обработки.
Ожидаемые ограничения и политика хранения
Важно помнить, что контрольные точки могут увеличивать использование пространства до тех пор, пока не будет достигнут максимум, определяемый политикой хранения. Если ваше значение достигнет предела, Ceph начнет удалять старые контрольные точки в соответствии с заданной политикой удержания, чтобы освободить место.
Если ваша политика хранения не обновляется, это может привести к некорректному отображению доступного пространства, поскольку система будет продолжать хранить старые данные, даже если они больше не используются.
Рекомендации
-
Мониторинг изменений: Проверьте, какие именно изменения происходят в файловой системе, чтобы установить причинно-следственную связь между активностью и увеличением размера папки
.snap. -
Настройка политики хранения: Убедитесь, что используется правильная политика хранения для ваших контрольных точек, чтобы предотвратить нежелательное переполнение и потери данных.
-
Оптимизация работы с данными: Рассмотрите возможность удаления или архивирования устаревших данных в целях экономии пространства и упрощения управления.
Заключение
Ваша текущая ситуация — это не баг, а результат специфики работы контрольных точек в CephFS и механизма копирования по запросу. С пониманием этих механизмов вы сможете более эффективно управлять вашими данными, используя возможности Ceph для резервного копирования и восстановления.