Ceph Object Gateway (radosgw): Object Lifecycle Management

Ceph Luminous очень богатый на фичи релиз и я планирую кратенько написать о всех наиболее интересных на мой взгляд новшествах по части RGW и S3 API работоспособность которых я проверил.

Object Lifecycle Management — это S3 API позволяющий задать политику:

— удаления объектов и/или их версий после заданной даты,
— удаления объектов и/или их версий после истечения указанного времени,
— перемещения объектов с одного класса хранения на другой.

В Ceph пока не реализованы разные классы хранения(storage classes) и перемещение соответственно тоже. Так же нельзя использовать тэги объектов в политиках. Но зато первые два пункта поддерживаются и это уже хорошо)

Пример правил

Удаление объектов после определенной даты

{
    "Rules": [
        {
            "Status": "Enabled",
            "Prefix": "pub/",
            "Expiration": {
                "Date": "2018-03-23T14:49:00Z"
            },
            "ID": "remove old objects"
        }
    ]
}

С этой политикий все объекты с префиксом pub/* будут удалены в указанное время. Удобно, если нужно удалить какие то публичные(или нет) данные и важно об этом не забыть. Время задается в UTC. После указанного времени, все загружаемые объекты с этим префиксом будут сразу удаляться, что бы это прекратить нужно удалить данную политику.

Удаление неактуальных(не latest) версий объектов

Версионирование объектов появилось довольно давно, еще в Hammer и само по себе это очень круто но для максимальной функциональности ему не хватало этого:

{
    "Rules": [
        {
            "Filter": {
                "Prefix": ""
            },
            "Status": "Enabled",
            "NoncurrentVersionExpiration": {
                "NoncurrentDays": 7
            },
            "Expiration": {
                "ExpiredObjectDeleteMarker": true
            },
            "ID": "Remove all NOT latest verions"
        }
    ]
}

Сейчас с помощью такой политики можно настроить автоматическое удаление старых версий объектов и 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