Ceph Luminous очень богатый на фичи релиз и я планирую кратенько написать о всех наиболее интересных на мой взгляд новшествах по части RGW и S3 API работоспособность которых я проверил.
Object Lifecycle Management — это S3 API позволяющий задать политику:
— удаления объектов и/или их версий после заданной даты,
— удаления объектов и/или их версий после истечения указанного времени,
— перемещения объектов с одного класса хранения на другой.
В Ceph пока не реализованы разные классы хранения(storage classes) и перемещение соответственно тоже. Так же нельзя использовать тэги объектов в политиках. Но зато первые два пункта поддерживаются и это уже хорошо)
Пример правил
Удаление объектов после определенной даты
{_x000D_ "Rules": [_x000D_ {_x000D_ "Status": "Enabled",_x000D_ "Prefix": "pub/",_x000D_ "Expiration": {_x000D_ "Date": "2018-03-23T14:49:00Z"_x000D_ },_x000D_ "ID": "remove old objects"_x000D_ }_x000D_ ]_x000D_ }
С этой политикий все объекты с префиксом pub/* будут удалены в указанное время. Удобно, если нужно удалить какие то публичные(или нет) данные и важно об этом не забыть. Время задается в UTC. После указанного времени, все загружаемые объекты с этим префиксом будут сразу удаляться, что бы это прекратить нужно удалить данную политику.
Удаление неактуальных(не latest) версий объектов
Версионирование объектов появилось довольно давно, еще в Hammer и само по себе это очень круто но для максимальной функциональности ему не хватало этого:
{_x000D_ "Rules": [_x000D_ {_x000D_ "Filter": {_x000D_ "Prefix": ""_x000D_ },_x000D_ "Status": "Enabled",_x000D_ "NoncurrentVersionExpiration": {_x000D_ "NoncurrentDays": 7_x000D_ },_x000D_ "Expiration": {_x000D_ "ExpiredObjectDeleteMarker": true_x000D_ },_x000D_ "ID": "Remove all NOT latest verions"_x000D_ }_x000D_ ]_x000D_ }
Сейчас с помощью такой политики можно настроить автоматическое удаление старых версий объектов и DeleteMarker’ы. Это позволяет держать несколько версий объектов и пользоваться прелестями версионирования но не думать об удалении старых версий что само по себе является довольно не простой задачей.
Работа с правилами на примере awscli
Правила устанавливаются для конкретного бакета:
aws s3api put-bucket-lifecycle-configuration --lifecycle-configuration file://lifecycle.json --bucket {bk} --endpoint-url=https://{your rgw endpoint}
lifecycle.json — файл со списком правил в описанном выше формате.
Посмотреть текущие политики:
aws s3api get-bucket-lifecycle-configuration --bucket {bk} --endpoint-url=https://{your rgw endpoint}
Удаление всех политик:
aws s3api delete-bucket-lifecycle-configuration --bucket {bk} --endpoint-url=https://{your rgw endpoint}
Параметры RGW
На тему lifecycle у RGW(у каждого экземпляра по отдельности) есть несколько важных параметров:
rgw_enable_lc_threads = true
должен ли конкретный экземпляр RGW выполнять LC операции над объектами. Например экземпляры работающие на относительно слабых серверах можно освободить от этой функции. Или же это можно отключить на экземплярах с ролью website.
rgw lc max objs = 32
тут как и в случае с gс, при большем числе объектов может потребоваться увеличить число объектов обрабатываемых за раз
rgw lifecycle work time = "00:00-06:00"
а это то почему вы можете посчитать, что LC не работает)
Ручное управление
прогресс по бакетам с настроенными политиками:
radosgw-admin lc list
ручной запуск итерации:
radosgw-admin lc process
Помогла ли вам статья?