Il servizio (prima chiamato RADOSGW) permette di implementare uno storage ad oggetti compatibile S3.

L'erogazione vera e propria avviene attraverso un pool accceduto da un gateway che ne consente l'accesso attraverso le API dedicate.

Assumendo di disporre di un cluster CEPH operativo, per il deploy dei realtivi daemon è possibile seguire i seguenti passi:

1. Applicare una label (di seguito verrà utilizzata una label rgw) a tutti gli host che dovranno ospitare i relativi daemon:

ceph orch host label add <host1> rgw
...
ceph orch host label add <hostn> rgw

2. Verificare la corretta associaziome deelle label con:

ceph orch host ls

3. Scatenare il deploy dei servizi utilizzando come regola di placemente l'assegnazione della label corrispondente:

ceph orch apply rgw rgw '--placement=label:rgw count-per-host:2' --port=8000    # utilizzare --dry-run per una prova di deploy

Il parametro count-per-host:2 indica il deploy di 2 servizi per ogni host, come suggerito da best practice. In questi caso, avendo specificato la porta d'ascolto (8000), quella assegnata al secondo servizio sarà la successiva (8001) nel nostro caso.

4. Verificare i servizi effettivamente avviati con:

ceph orch ls 

Per avere HA e distribuzione del carico su tutti i servizi attivi, è possibile utilizzare la definizione di un servizio ingress per ottenere un loadbalancer di livello applicazione avente come backend tutti i service RGW e la gestione in VRRP di un VIP associato al servizio S3 compatibile:

Per il deploy del servizio ingress procedere come segue:

1. Identificare dall'output dei comandi ceph orch ls e ceph orch ps:

• Identificativo del servizio RGW
• Host sui quali i servizi di LB e gestione VRRP andranno eseguiti

2. Definire poi indirizzo IP, porta e certificati per l'esposizione SSL/TLS del servizio, se necessario. Per utilizzare i bucket come sottodomini secondo la sintassi S3, generare gli opportuni certificati validi per la URL prescelta e wildcard dei sottodomini (che verranno poi ricondotti ai bucket)..

3. Definire un file (es. rgw_ingress.yaml) con il seguente contenuto:

service_type: ingress
service_id: <RGW_service_id>                
service_name: <ingress_desired_service_name>
placement:
  label: rgw
spec:
  backend_service: <RGW_service_id>
  frontend_port: <ingress_desired_listening_port>
  monitor_port: <ingress_desired_haproxy_monitoring_port>
  first_virtual_router_id: 40
  virtual_ips_list:
  - <VRRP_IP_1>
  - ...
  - <VRRP_IP_N>
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

4. Avviare il deploy del serviio ingress con:

ceph orch apply -i rgw_ingress.yaml

5. Verificare la presenza dei relativi servizi con ceph orch ls e ceph orch ps

6. Verificare con l'utilzzo di curl o wget la risposta ottenibile contattando IP e porta selezionate:

<?xml version="1.0" encoding="UTF-8"?>
<ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>anonymous</ID>
    <DisplayName></DisplayName>
  </Owner>
  <Buckets></Buckets>
</ListAllMyBucketsResult>

7. Definire un record wildcard nel DNS per ricondurre ogni risoluzione del sottodominio <nome_bucket>.<dominio_ingress>.

1. Ottenere le definizioni per il servizio ingress desiderato, ad es:

ceph orch ls ingress ingress.rgw.rgw --export > current_config.yaml

2. Modificare il file e poi aggiornare la configurazione con:

ceph orch apply -i current_config.yaml

3. Forzare il redeploy dei servizi HAproxy e Keepalived con le nuove configurazioni:

ceph orch redeploy ingress.rgw.rgw <ingress_desired_service_name>

Il servizio ingress viene avviato utilizando una configurazione per HAproxy che prevede un healthcheck verso i servizi rgw basato sul metodo HEAD:

option httpchk HEAD HTTP/1.0

Il corrispondente servizio rgw quindi rileva l'interruzione della connessione appena aperta e inserisce una riga di errore nei log:

client_io->complete_request() returned Connection reset by peer

Quindi è opportuno sostituire l'healthcheck utilizzando un path apposito (pre-esistente). Il file di template per la configurazione di HAproxy del servizio ingress deve essere perciò modificato:

1. Otteniamo la configurazione attuale con:

ceph config-key get mgr/cephadm/services/ingress/haproxy.cfg > haproxy.cfg.j2

2. Modifichiamo la riga sul file appena creato in:

option httpchk GET /swift/healthcheck HTTP/1.0     # invece di 'option httpchk HEAD HTTP/1.0'

3. Aggiornare la chiave di configurazione corrispondente con:

ceph config-key set mgr/cephadm/services/ingress/haproxy.cfg -i haproxy.cfg.j2

4. Riconfigurare il servizio ingress con:

ceph orch reconfig <service_name>

Per creare un utente, utilizzare la seguente sintassi:

radosgw-admin user create --uid=<user_id> --display-name="<Nome Cognome>"

Il comando restituisce un piccolo report che contiene tra l'altro secret_key e access_key (autogenerate perchè non inserite come parametro al lancio del comando) per l'accesso al cluster. Le stesse informazioni possono essere visualizzate in un secondo momento con:

radosgw-admin user info --uid=<user_id>

Per evitare l'utilizzo indiscriminato di risorse è possibile imporre delle quote:

• numero massimo di oggetti
• dimensioni massime occupate

Ogni tipo di quota viene applicato con un certo scope, quindi le restrizioni possono essere applicate a livello di:

• utente
• bucket
• bucket per i quali lo specifico utente è proprietario

radosgw-admin quota set --quota-scope=user --uid=<user_id> --max-objects=<object_num> --max-size=<size> 

radosgw-admin quota enable --quota-scope=user --uid=<user_id>

# radosgw-admin user info --uid=<user_id>
{
    "user_id": "<user_id>",
    
    ...
    
    "user_quota": {
        "enabled": false,
        "check_on_raw": false,
        "max_size": 2048,
        "max_size_kb": 2,
        "max_objects": 2048
    },
    
    ...
}

radosgw-admin quota set --quota-scope=bucket --bucket=<bucket_name> --max-objects=<object_num> --max-size=<size>

radosgw-admin quota enable --quota-scope=bucket --bucket=<bucket_name>

# radosgw-admin bucket stats --bucket=<bucket_name>
{
    "bucket": "<bucket_name>",
    
    ...
    
    "bucket_quota": {
        "enabled": false,
        "check_on_raw": false,
        "max_size": 1024,
        "max_size_kb": 1,
        "max_objects": 1024
    }
}

radosgw-admin quota set --quota-scope=bucket  --uid=<user_id> --max-objects=<object_num> --max-size=<size>

radosgw-admin quota enable --quota-scope=bucket --uid=<user_id>

# radosgw-admin user info --uid=<user_id>
{
    "user_id": "<user_id>",
    
    ...
    
    "bucket_quota": {
        "enabled": false,
        "check_on_raw": false,
        "max_size": 2048,
        "max_size_kb": 2,
        "max_objects": 2048
    },
    
    ...
}

radosgw-admin bucket rm --bucket=<bucket_name>

La verbosità del livello di log di default per il servizio è non trascurabile, vengono loggate anche le singole richieste. Per ridurre il livello:

ceph config set global debug_rgw 0/5