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
Помогла ли вам статья?
