Ceph Object Gateway | Guida all'amministrazione

documentation.suse.com › Documentazione di SUSE Enterprise Storage 5 › Guida all'amministrazione › Accesso ai dati del cluster › Ceph Object Gateway

ContenutoContenuto

Guida all'amministrazione

Navigazione←→

Si applica a SUSE Enterprise Storage 5

11 Ceph Object Gateway #

11.1 Restrizioni e limiti di denominazione di Object Gateway
11.2 Distribuzione di Object Gateway
11.3 Funzionamento del servizio Object Gateway
11.4 Parametri di configurazione
11.5 Gestione dell'accesso a Object Gateway
11.6 Abilitazione di HTTPS/SSL per gli Object Gateway
11.7 Moduli di sincronizzazione
11.8 Autenticazione LDAP
11.9 Partizionamento dell'indice del compartimento
11.10 Integrazione di OpenStack Keystone
11.11 Object Gateway multisito
11.12 Bilanciamento del carico dei server Object Gateway con HAProxy

In questo capitolo vengono fornite ulteriori informazioni sui task amministrativi correlati a Object Gateway, come la verifica dello stato del servizio, la gestione degli account, i gateway multisito o l'autenticazione LDAP.

11.1 Restrizioni e limiti di denominazione di Object Gateway #

Di seguito è riportato un elenco di importanti limiti Object Gateway:

11.1.1 Limiti dei compartimenti #

Quando si inizia a utilizzare Object Gateway tramite l'API S3, i nomi dei compartimenti sono limitati ai nomi conformi a DNS in cui è consentito un trattino "". Quando si inizia a utilizzare Object Gateway tramite l'API Swift, è possibile utilizzare una combinazione qualsiasi di caratteri UTF-8 supportati, tranne la barra "/". La lunghezza massima di un nome di compartimento è di 255 caratteri. I nomi dei compartimenti devono essere univoci.

Suggerimento: utilizzo di nomi di compartimenti conformi a DNS

Sebbene sia possibile utilizzare qualsiasi nome di compartimento basato su UTF-8 tramite l'API Swift, si consiglia di denominare i compartimenti tenendo in considerazione i limiti di denominazione S3 in modo da evitare problemi di accesso allo stesso compartimento tramite l'API S3.

11.1.2 Limiti degli oggetti memorizzati #

Numero massimo di oggetti per utente: Per default, nessuna restrizione (limite definito da ~ 2^63).
Numero massimo di oggetti per compartimento: Per default, nessuna restrizione (limite definito da ~ 2^63).
Dimensioni massime di un oggetto di cui effettuare l'upload/da memorizzare: Gli upload singoli sono limitati a 5 GB. Utilizzare multipart per dimensioni grandi degli oggetti. Il numero massimo di porzioni multipart è 10000.

11.1.3 Limiti dell'intestazione HTTP #

L'intestazione HTTP e il limite di richiesta dipendono dalla front-end Web utilizzata. CivetWeb di default limita il numero di intestazioni HTTP a 64 e le dimensioni dell'intestazione HTTP a 16 kB.

11.2 Distribuzione di Object Gateway #

Il metodo di distribuzione consigliato per Ceph Object Gateway è tramite l'infrastruttura DeepSea aggiungendo le righe role-rgw [...] pertinenti nel file policy.cfg sul Salt master ed eseguendo le fasi DeepSea richieste.

Per includere Object Gateway durante il processo di distribuzione del cluster Ceph, fare riferimento a Sezione 4.3, «Distribuzione del cluster» e Sezione 4.5.1, «Il file policy.cfg».
Per aggiungere il ruolo Object Gateway a un cluster già distribuito, fare riferimento a Sezione 1.2, «Aggiunta di nuovi ruoli ai nodi».

11.3 Funzionamento del servizio Object Gateway #

Il servizio Object Gateway viene attivato con il comando systemctl. Per attivare il servizio Object Gateway è necessario disporre dei diritti root. gateway_host è il nome host del server di cui è necessario attivare l'istanza Object Gateway.

Per il servizio Object Gateway sono supportati i seguenti comandi:

systemctl status ceph-radosgw@rgw.gateway_host: Stampa le informazioni sullo stato del servizio.
systemctl start ceph-radosgw@rgw.gateway_host: Avvia il servizio nel caso non sia già in esecuzione.
systemctl restart ceph-radosgw@rgw.gateway_host: Riavvia il servizio.
systemctl stop ceph-radosgw@rgw.gateway_host: Interrompe il servizio in esecuzione.
systemctl enable ceph-radosgw@rgw.gateway_host: Abilita il servizio in modo che venga avviato automaticamente all'avvio del sistema.
systemctl disable ceph-radosgw@rgw.gateway_host: Disabilita il servizio in modo che non venga avviato automaticamente all'avvio del sistema.

11.4 Parametri di configurazione #

Il comportamento di Object Gateway può essere influenzato da numerose opzioni contenute nel file ceph.conf. Di seguito è rimportato un elenco delle più importanti. Per l'elenco completo, vedere http://docs.ceph.com/docs/master/radosgw/config-ref/ (in lingua inglese).

rgw_thread_pool_size: Numero di thread per il server CivetWeb. Aumentare il valore se è necessario provvedere a più richieste. Il valore di default è 100 thread.
rgw_num_rados_handles: Numero di handle del cluster RADOS (fare riferimento a http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle) per Object Gateway. La possibilità di disporre un numero configurabile di handle RADOS comporta un miglioramento significativo delle prestazioni per tutti i tipi di workload. Adesso per ciascun thread di lavoro Object Gateway verrebbe selezionato un handle RADOS permanente. Il valore di default è 1.
rgw_max_chunk_size: Dimensioni massime di una porzione di dati che verrà letta in una singola operazione. Se si aumenta il valore a 4 MB (4194304) si otterranno prestazioni migliori durante l'elaborazione di oggetti di grandi dimensioni. Il valore di default è 128 kB (131072).

11.4.1 Note aggiuntive #

rgw dns name: Se si aggiunge il parametro rgw dns name a ceph.conf, assicurarsi che il client S3 sia configurato per indirizzare le richieste all'endpoint specificato da rgw dns name.

11.5 Gestione dell'accesso a Object Gateway #

È possibile comunicare con Object Gateway mediante l'interfaccia compatibile con S3 o Swift. L'interfaccia S3 è compatibile con un grande sottoinsieme dell'API Amazon S3 RESTful. L'interfaccia Swift è compatibile con un grande sottoinsieme dell'API OpenStack Swift.

Per entrambe le interfacce è richiesto di creare un utente specifico e installare il software client pertinente per comunicare con il gateway che utilizza la chiave segreta dell'utente.

11.5.1 Accesso a Object Gateway #

11.5.1.1 Accesso all'interfaccia S3 #

Per accedere all'interfaccia S3, è necessario un client REST. S3cmd è un client S3 della riga di comando. È possibile trovarlo in openSUSE Build Service (OBS) (in lingua inglese). L'archivio contiene versioni di entrambe le distribuzioni basate su SUSE Linux Enterprise e openSUSE.

Se si desidera testare l'accesso all'interfaccia S3, è anche possibile scrivere un piccolo script Python, che consentirà di eseguire la connessione a Object Gateway, creare un nuovo compartimento ed elencare tutti i compartimenti. I valori per aws_access_key_id e aws_secret_access_key sono ricavati dai valori di access_key e secret_key restituiti dal comando radosgw_admin di cui alla Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».

Installare il pacchetto python-boto:
```
sudo zypper in python-boto
```

Creare un nuovo script Python denominato s3test.py con il seguente contenuto:

import boto
import boto.s3.connection
access_key = '11BS02LGFB6AL6H1ADMW'
secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = '{hostname}',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
bucket = conn.create_bucket('my-new-bucket')
for bucket in conn.get_all_buckets():
  print "{name}\t{created}".format(
  name = bucket.name,
  created = bucket.creation_date,
  )

Sostituire {hostname} con il nome host dell'host in cui si è configurato il servizio Object Gateway, ad esempio gateway_host.

Eseguire lo script:
```
python s3test.py
```
L'output dello script è simile a quanto riportato di seguito:
```
my-new-bucket 2015-07-22T15:37:42.000Z
```

11.5.1.2 Accesso all'interfaccia Swift #

Per accedere a Object Gateway tramite l'interfaccia Swift, è necessario il client della riga di comando swift. Nella relativa documentazione man 1 swift sono fornite ulteriori informazioni sulle rispettive opzioni della riga di comando.

Il pacchetto è incluso nel modulo "Public Cloud" per SUSE Linux Enterprise 12 SP3. Prima di installare il pacchetto, è necessario attivare il modulo e aggiornare l'archivio software:

sudo SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper refresh

Per installare il comando swift, eseguire quanto riportato di seguito:

sudo zypper in python-swiftclient

Per l'accesso swift si utilizza la seguente sintassi:

swift -A http://IP_ADDRESS/auth/1.0 \
-U example_user:swift -K 'swift_secret_key' list

Sostituire IP_ADDRESS con l'indirizzo IP del server gateway e swift_secret_key con il rispettivo valore risultante dal comando radosgw-admin key create eseguito per l'utente swift in Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».

Ad esempio:

swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \
-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

L'output è:

my-new-bucket

11.5.2 Gestione degli account S3 e Swift #

11.5.2.1 Aggiunta di utenti S3 e Swift #

Per abilitare gli utenti finali all'iterazione con il gateway, è necessario creare un utente, una chiave di accesso e un segreto. Esistono due tipi di utenti: un utente e un sottoutente. Mentre gli utenti vengono utilizzati per l'iterazione con l'interfaccia S3, i sottoutenti sono gli utenti dell'interfaccia Swift. Ciascun sottoutente è associato a un utente.

È anche possibile aggiungere gli utenti tramite il file DeepSea rgw.sls. Per un esempio, vedere Sezione 14.3.1, «Utenti Object Gateway diversi per NFS Ganesha».

Per creare un utente Swift, seguire la procedura indicata:

Per creare un utente Swift, che nella nostra terminologia è denominato sottoutente, prima è necessario creare l'utente associato.

sudo radosgw-admin user create --uid=username \
 --display-name="display-name" --email=email

Ad esempio:

sudo radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

Per creare un sottoutente (interfaccia Swift) per l'utente, è necessario specificare l'ID utente (--uid=username), un ID sottoutente e il livello di accesso per il sottoutente.

sudo radosgw-admin subuser create --uid=uid \
 --subuser=uid \
 --access=[ read | write | readwrite | full ]

Ad esempio:

sudo radosgw-admin subuser create --uid=example_user \
 --subuser=example_user:swift --access=full

Generare una chiave segreta per l'utente.

sudo radosgw-admin key create \
   --gen-secret \
   --subuser=example_user:swift \
   --key-type=swift

L'output di entrambi i comandi saranno i dati formattati per JSON in cui è visualizzato lo stato dell'utente. Osservare le righe seguenti e ricordare il valore di secret_key:
```
"swift_keys": [
   { "user": "example_user:swift",
     "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],
```

Quando si accede a Object Gateway tramite l'interfaccia S3, è necessario creare un utente S3 eseguendo:

sudo radosgw-admin user create --uid=username \
 --display-name="display-name" --email=email

Ad esempio:

sudo radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

Con questo comando si creano anche la chiave di accesso e la chiave segreta dell'utente. Verificare l'output per le parole chiave access_key e secret_key e i rispettivi valori:

[...]
 "keys": [
       { "user": "example_user",
         "access_key": "11BS02LGFB6AL6H1ADMW",
         "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
 [...]

11.5.2.2 Rimozione di utenti S3 e Swift #

La procedura di eliminazione degli utenti S3 e Swift è simile. Nel caso degli utenti Swift però potrebbe essere necessario eliminare l'utente e i rispettivi sottoutenti.

Per rimuovere un utente S3 o Swift (inclusi tutti i rispettivi sottoutenti), specificare user rm e l'ID utente nel seguente comando:

sudo radosgw-admin user rm --uid=example_user

Per rimuovere un sottoutente, specificare subuser rm e l'ID sottoutente.

sudo radosgw-admin subuser rm --uid=example_user:swift

È possibile utilizzare una delle seguenti opzioni:

--purge-data: Elimina definitivamente tutti i dati associato all'ID utente.
--purge-keys: Elimina definitivamente tutte le chiavi associate all'ID utente.

Suggerimento: rimozione di un sottoutente

Quando si rimuove un sottoutente, si rimuove l'accesso all'interfaccia Swift. L'utente rimarrà nel sistema.

11.5.2.3 Modifica delle chiavi di accesso e segrete degli utenti S3 e Swift #

I parametri di access_key e secret_key identificano l'utente Object Gateway nel momento in cui accede al gateway. Modificare chiavi utente esistenti è come crearne di nuove, in quanto le chiavi precedenti vengono sovrascritte.

Per gli utenti S3, eseguire quanto riportato di seguito:

sudo radosgw-admin key create --uid=example_user --key-type=s3 --gen-access-key --gen-secret

Per gli utenti Swift, eseguire quanto riportato di seguito:

sudo radosgw-admin key create --subuser=example_user:swift --key-type=swift --gen-secret

--key-type=type: Specifica il tipo di chiave. swift o s3.
--gen-access-key: Genera una chiave di accesso casuale (di default per l'utente S3).
--gen-secret: Genera una chiave segreta casuale.
--secret=key: Specifica una chiave segreta, ad esempio una chiave generata manualmente.

11.5.2.4 Gestione delle quote utente #

Ceph Object Gateway consente di impostare le quote su utenti e compartimenti di proprietà degli utenti. Le quote includono il numero massimo di oggetti in un compartimento e le dimensioni massime di memorizzazione espresse in megabyte.

Prima di abilitare una quota utente, è necessario impostarne i parametri:

sudo radosgw-admin quota set --quota-scope=user --uid=example_user \
 --max-objects=1024 --max-size=1024

--max-objects: Specifica il numero massimo di oggetti. Con un numero negativo la verifica viene disabilitata.
--max-size: Specifica il numero massimo di byte. Con un numero negativo la verifica viene disabilitata.
--quota-scope: Specifica l'ambito della quota. Le opzioni sono bucket e user. Le quote dei compartimenti si riferiscono ai compartimenti di proprietà di un utente. Le quote utente si riferiscono a un utente.

Una volta impostata una quota utente, è possibile abilitarla:

sudo radosgw-admin quota enable --quota-scope=user --uid=example_user

Per disabilitare una quota:

sudo radosgw-admin quota disable --quota-scope=user --uid=example_user

Per elencare le impostazioni della quota:

sudo radosgw-admin user info --uid=example_user

Per aggiornare le statistiche della quota:

sudo radosgw-admin user stats --uid=example_user --sync-stats

11.6 Abilitazione di HTTPS/SSL per gli Object Gateway #

Per abilitare il ruolo Object Gateway di default in modo che comunichi in modo sicuro tramite SSL, è necessario disporre di un certificato emesso dalla CA o crearne uno firmato da se stessi. È possibile configurare Object Gateway con HTTPS in due modi diversi: uno semplice in cui vengono utilizzate le impostazioni di default e un modo avanzato che consente di ottimizzare le impostazioni correlate ad HTTPS.

11.6.1 Creazione di un certificato firmato da se stessi #

Suggerimento

Ignorare questa sezione se si dispone già di un certificato valido firmato dalla CA.

Per default, DeepSea si aspetta che il file certificato sia in /srv/salt/ceph/rgw/cert/rgw.pem nel Salt master. Il certificato verrà quindi distribuito a /etc/ceph/rgw.pem nel Salt minion con il ruolo Object Gateway, dove viene letto da Ceph.

Nella procedura seguente è illustrato come generare un certificato SSL firmato da se stessi sul nodo Salt master.

Aggiungere l'opzione subjectAltName alla sezione [v3_req] del file /etc/ssl/openssl.cnf per tutti i nomi host cui si desidera rendere noto Object Gateway mediante:
```
[...]
[ v3_req ]
subjectAltName = ${ENV::SAN}
[...]
```
Creare la chiave e il certificato utilizzando openssl. Aggiungere a openssl il prefisso env SAN=DNS:fqdn. Immettere tutti i dati che è necessario includere nel certificato. Si consiglia di immettere FQDN come nome comune. Prima di firmare il certificato, verificare che "X509v3 Subject Alternative Name:" sia incluso nelle estensioni richieste e che sia impostato nel certificato che viene generato.
```
root@master # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \
 -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem
```

11.6.2 Configurazione HTTPS semplice #

Per default, Ceph sul nodo Object Gateway legge il certificato /etc/ceph/rgw.pem e utilizza la porta 443 per la comunicazione SSL sicura. Se non è necessario modificare questi valori, seguire la procedura indicata di seguito:

Modificare /srv/pillar/ceph/stack/global.yml e aggiungere la riga seguente:
```
rgw_configurations: rgw-ssl
rgw_init: default-ssl
```

Eseguire le fasi 2, 3 e 4 di DeepSea per applicare le modifiche:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4

11.6.3 Configurazione HTTPS avanzata #

Se è necessario modificare i valori di default per le impostazioni SSL di Object Gateway, seguire la procedura indicata di seguito:

Copiare la configurazione SSL di Object Gateway di default nella sottodirectory ceph.conf.d:

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
 /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

Modificare /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf e le opzioni di default, come il numero porta o il percorso del certificato SSL in modo che riflettano la configurazione impostata.

Eseguire le fasi 3 e 4 di DeepSea per applicare le modifiche:

root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4

Suggerimento: associazione di più porte

Nel server CivetWeb è possibile associare più porte. Tale funzione è utile se è necessario accedere a un'istanza singola di Object Gateway con entrambe le connessioni SSL e non SSL. Quando si specificano le porte, separare i relativi numeri con un simbolo più "+". Di seguito è riportato un esempio di riga di configurazione con due porte:

[client.{{ client }}]
rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem

11.7 Moduli di sincronizzazione #

La funzionalità multisite di Object Gateway introdotta in Jewel consente di creare più zone e di eseguire la copia speculare dei dati e dei metadati tra loro. I moduli di sincronizzazione sono costruiti in cima al framework multisito che consente l'inoltro di dati e metadati a un livello esterno diverso. Un modulo di sincronizzazione consente di eseguire un set di azioni ogni volta che ha luogo una modifica dei dati (con modifiche dei dati si intendono anche operazioni correlate ai metadati, come la creazione di compartimenti o utenti e così via). Poiché le modifiche del multisito rgw alla fine sono coerenti nei siti remoti, le modifiche vengono propagate in modo asincrono. Ciò consente di sbloccare casi di utilizzo come il backup della memorizzazione di oggetti in un cluster cloud esterno o una soluzione di backup personalizzata in cui vengono utilizzate unità nastro o l'indicizzazione dei metadati in Elasticsearch e così via.

11.7.1 Sincronizzazione delle zone #

La configurazione di un modulo di sincronizzazione viene eseguita a livello locale in una zona. Il modulo di sincronizzazione determina se i dati vengono esportati dalla zona o se questa utilizza solo dati modificati in un'altra zona. A partire da Luminous, i plug-in di sincronizzazione supportati sono elasticsearch, rgw, il plug-in di sincronizzazione di default mediante il quale vengono sincronizzati i dati tra le zone, e log, un plug-in di sincronizzazione semplice che registra le operazioni dei metadati che hanno luogo nelle zone remote. Nelle sezioni seguenti è riportato l'esempio di una zona in cui viene utilizzato il modulo di sincronizzazione elasticsearch. Il processo è simile a quello utilizzato per la configurazione di qualsiasi altro plug-in di sincronizzazione.

Nota: plug-in di sincronizzazione di default

rgw è il plug-in di sincronizzazione di default e non è necessario configurarlo esplicitamente.

11.7.1.1 Requisiti e presupposti #

Si supponga una semplice configurazione multisito, come descritta nella Sezione 11.11, «Object Gateway multisito», costituita da 2 zone: us-east e us-west. Adesso si aggiunge una terza zona us-east-es nella quale vengono elaborati solo i metadati provenienti da altri siti. Questa zona può essere nello stesso cluster Ceph di us-east o in uno diverso. In questa zona vengono utilizzati solo i metadati provenienti da altre zone e gli Object Gateway in essa contenuti non serviranno direttamente alcuna richiesta dell'utente finale.

11.7.1.2 Configurazione dei moduli di sincronizzazione #

Creare una terza zona simile a quelle descritte nella Sezione 11.11, «Object Gateway multisito», ad esempio

root # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
--access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80

È possibile configurare un modulo di sincronizzazione per questa zona nel modo seguente

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \
--tier-config={set of key=value pairs}

Ad esempio, nel modulo di sincronizzazione elasticsearch
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \
--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
```
Per le varie opzioni tier-config supportate, fare riferimento a Sezione 11.7.2, «Memorizzazione dei metadati in Elasticsearch».

Infine, aggiornare il periodo

root # radosgw-admin period update --commit

Adesso avviare radosgw nella zona

root # systemctl start ceph-radosgw@rgw.`hostname -s`
root # systemctl enable ceph-radosgw@rgw.`hostname -s`

11.7.2 Memorizzazione dei metadati in Elasticsearch #

Questo modulo di sincronizzazione consente di scrivere in Elasticsearch i metadati provenienti da altre zone. A partire da Luminous, è il formato JSON dei campi dei dati che attualmente vengono memorizzati in Elasticsearch.

{
  "_index" : "rgw-gold-ee5863d6",
  "_type" : "object",
  "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null",
  "_score" : 1.0,
  "_source" : {
    "bucket" : "testbucket123",
    "name" : "object1",
    "instance" : "null",
    "versioned_epoch" : 0,
    "owner" : {
      "id" : "user1",
      "display_name" : "user1"
    },
    "permissions" : [
      "user1"
    ],
    "meta" : {
      "size" : 712354,
      "mtime" : "2017-05-04T12:54:16.462Z",
      "etag" : "7ac66c0f148de9519b8bd264312c4d64"
    }
  }
}

11.7.2.1 Parametri di configurazione di tipi di livelli Elasticsearch #

endpoint: Specifica l'endpoint del server Elasticsearch cui accedere.
num_shards: (numero intero) Numero di partizioni che verranno configurate da Elasticsearch con l'inizializzazione della sincronizzazione sui dati. Dopo l'inizializzazione non è possibile modificare tale numero. Per qualsiasi modifica sono richieste la ricompilazione dell'indice di Elasticsearch e la reinizializzazione del processo di sincronizzazione dei dati.
num_replicas: (numero intero) Numero di repliche che verranno configurate da Elasticsearch con l'inizializzazione della sincronizzazione sui dati.
explicit_custom_meta: (true | false) Specifica se tutti i metadati personalizzati dell'utente verranno indicizzati o se l'utente dovrà configurare (a livello di compartimento) quali voci dei metadati del cliente devono essere indicizzate. Per default, questa opzione è impostata su false.
index_buckets_list: (elenco di stringhe separate da virgole) Se vuoti, tutti i compartimenti verranno indicizzati. Altrimenti, verranno indicizzati solo i compartimenti specificati qui. È possibile specificare i prefissi dei compartimenti (ad esempio "foo*") o i suffissi (ad esempio "*bar").
approved_owners_list: (elenco di stringhe separate da virgole) Se vuoti, i compartimenti di tutti i proprietari verranno indicizzati (operazione soggetta ad altre restrizioni), altrimenti verranno indicizzati solo i compartimenti appartenenti ai proprietari specificati. È possibile specificare anche i suffissi e i prefissi.
override_index_path: (stringa) Se non è vuota, la stringa verrà utilizzata come percorso di indice di elasticsearch. Altrimenti il percorso di indice verrà determinato e generato al momento dell'inizializzazione della sincronizzazione.

11.7.2.2 Interrogazioni dei metadati #

Poiché adesso nel cluster Elasticsearch vengono memorizzati metadati di oggetti, è importante che l'endpoint di Elasticsearch non sia esposto in pubblico e che sia accessibile solo dagli amministratori del cluster. Ciò rappresenta un problema per l'esposizione delle interrogazioni dei metadati all'utente finale dato che è necessario che l'utente interroghi solo i propri metadati e non quelli di altri utenti. Pertanto sarebbe opportuno che l'autenticazione degli utenti da parte del cluster Elasticsearch venga eseguita in modo simile a RGW che di fatto rappresenta un problema.

A partire da Luminous RGW, adesso nella zona master dei metadata master è possibile provvedere alle richieste degli utenti finali. In tal modo l'endpoint Elasticsearch non viene esposto in pubblico e si risolve anche il problema di autenticazione e autorizzazione in quanto RGW stesso è in grado di autenticare le richieste degli utenti finali. A tal fine, RGW introduce una nuova interrogazione nelle API del compartimento che sono in grado di provvedere alle richieste Elasticsearch. Tutte queste richieste devono essere inviate alla zona master dei metadati.

Ottenimento di un'interrogazione Elasticsearch

GET /BUCKET?query={query-expr}

parametri di richiesta:

max-keys: numero massimo di voci da restituire
marker: marker di impaginazione

expression := [(]<arg> <op> <value> [)][<and|or> ...]

op è uno dei seguenti: <, <=, ==, >=, >

Ad esempio:

GET /?query=name==foo

Verranno restituite tutte le chiavi indicizzate per le quali l'utente dispone l'autorizzazione in lettura e vengono denominate "foo". L'output sarà un elenco di chiavi in XML simile alla risposta dei compartimenti dell'elenco S3.

Configurazione dei campi dei metadati personalizzati

Definire quali voci dei metadati personalizzati devono essere indicizzate (nel compartimento specificato) e quali sono i tipi di queste chiavi. Se si configura l'indicizzazione esplicita dei metadati personalizzati, tale operazione è necessaria affinché rgw indicizzi i valori dei metadati personalizzati specificati. Altrimenti è necessaria nei casi in cui le chiavi dei metadati indicizzati siano di tipo diverso dalla stringa.

POST /BUCKET?mdsearch
x-amz-meta-search: <key [; type]> [, ...]

I campi di metadati multipli devono essere separati da virgole, è possibile forzare un tipo per un campo con un punto e virgola ";". I tipi attualmente consentiti sono stringa (default), numero intero e data, ad esempio se si desidera indicizzare metadati di oggetti personalizzati si possono utilizzare x-amz-meta-year come numero intero, x-amz-meta-date come tipo di data e x-amz-meta-title come stringa

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

Eliminazione della configurazione dei metadati personalizzati

Eliminare la configurazione del compartimento dei metadati personalizzati.

DELETE /BUCKET?mdsearch

Ottenimento della configurazione dei metadati personalizzati

Recuperare la configurazione del compartimento dei metadati personalizzati.

GET /BUCKET?mdsearch

11.8 Autenticazione LDAP #

Oltre all'autenticazione utente locale di default, con Object Gateway si possono utilizzare i servizi del server LDAP per autenticare anche gli utenti.

11.8.1 Meccanismo di autenticazione #

Object Gateway estrae le credenziali LDAP dell'utente da un token. Dal nome utente viene costruito un filtro di ricerca. In Object Gateway si utilizza il servizio configurato per ricercare la directory di una voce corrispondente. Se si trova la voce, Object Gateway tenta di associare il nome distinto con la password ottenuta dal token. Se le credenziali sono valide, l'associazione avrà esito positivo e verrà concesso l'accesso a Object Gateway.

È possibile limitare gli utenti consentiti impostando la base per la ricerca a un'unità organizzativa specifica o definendo un filtro di ricerca personalizzato, ad esempio richiedendo l'appartenenza di un gruppo specifico, classi di oggetti personalizzati o attributi.

11.8.2 Requisiti #

LDAP o Active Directory: un'istanza LDAP in esecuzione accessibile da Object Gateway.
Account di servizio: credenziali LDAP che devono essere utilizzate da Object Gateway con autorizzazioni di ricerca.
Account utente: almeno un account utente nella directory LDAP.

Importante: non sovrapporre utenti LDAP e utenti locali

Non utilizzare gli stessi nomi utente per gli utenti locali e per gli utenti che vengono autenticati mediante l'uso di LDAP. Object Gateway non è in grado di distinguerli e li considera come lo stesso utente.

Suggerimento: test di integrità

Utilizzare l'utility ldapsearch per verificare l'account di servizio o la connessione LDAP. Ad esempio:

ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \
-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

Assicurarsi di utilizzare gli stessi parametri LDAP del file di configurazione Ceph per eliminare eventuali problemi.

11.8.3 Configurazione di Object Gateway per utilizzare l'autenticazione LDAP #

I seguenti parametri nel file di configurazione /etc/ceph/ceph.conf sono correlati all'autenticazione LDAP:

rgw_ldap_uri: Specifica il server LDAP da utilizzare. Assicurarsi di utilizzare il parametro ldaps://fqdn:port per evitare di trasmettere apertamente credenziali come testo normale.
rgw_ldap_binddn: Nome distinto (DN) dell'account di servizio utilizzato da Object Gateway.
rgw_ldap_secret: Password per l'account di servizio.
rgw_ldap_searchdn: Specifica la base DIT (Directory Information Tree) per la ricerca degli utenti. Questa può essere l'unità organizzativa degli utenti o una più specifica.
rgw_ldap_dnattr: Attributo che viene utilizzato nel filtro di ricerca costruito per la corrispondenza con un nome utente. A seconda del DIT, è probabile che tale attributo sia uid o cn.
rgw_search_filter: Se non è specificato, in Object Gateway il filtro di ricerca viene costruito automaticamente con l'impostazione rgw_ldap_dnattr. Utilizzare questo parametro per restringere l'elenco degli utenti consentiti con la massima flessibilità. Consultare Sezione 11.8.4, «Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti» per ulteriori informazioni.

11.8.4 Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti #

È possibile utilizzare il parametro rgw_search_filter in due modi diversi.

11.8.4.1 Filtro parziale per limitare ulteriormente il filtro di ricerca costruito #

Di seguito è riportato un esempio di filtro parziale:

"objectclass=inetorgperson"

In Object Gateway il filtro di ricerca verrà generato come di consueto, con il nome dell'utente ottenuto dal token del valore di rgw_ldap_dnattr. Il filtro costruito viene quindi combinato con il filtro parziale dell'attributo rgw_search_filter. A seconda del nome utente e delle impostazioni, il filtro di ricerca finale può diventare:

"(&(uid=hari)(objectclass=inetorgperson))"

In tal caso, all'utente 'hari' verrà concesso l'accesso solo se è presente nella directory LDAP, dispone di una classe oggetto 'inetorgperson' e ha specificato una password valida.

11.8.4.2 Filtro completo #

Un filtro completo deve contenere un token USERNAME che verrà sostituito con il nome dell'utente durante il tentativo di autenticazione. In tal caso, il parametro rgw_ldap_dnattr non viene più utilizzato. Ad esempio, per limitare gli utenti validi a un gruppo specifico, utilizzare il filtro seguente:

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

Nota: attributo `memberOf`

Per utilizzare l'attributo memberOf nelle richieste LDAP è richiesto il supporto lato server dall'implementazione del server LDAP specificata.

11.8.5 Generazione di un token di accesso per l'autenticazione LDAP #

Il token di accesso viene generato dall'utility radosgw-token in base al nome utente e alla password LDAP. L'output è una stringa codificata base-64 che corrisponde al token di accesso effettivo. Utilizzare il client S3 preferito (fare riferimento a Sezione 11.5.1, «Accesso a Object Gateway»), specificare il token come chiave di accesso e utilizzare una chiave segreta vuota.

root@minion > export RGW_ACCESS_KEY_ID="username"
root@minion > export RGW_SECRET_ACCESS_KEY="password"
root@minion > radosgw-token --encode --ttype=ldap

Importante: credenziali non cifrate

Il token di accesso è una struttura JSON codificata base-64 e contiene le credenziali LDAP non cifrate.

Nota: Active Directory

Per Active Directory, utilizzare il parametro --ttype=ad.

11.9 Partizionamento dell'indice del compartimento #

In Object Gateway i dati di indice del compartimento vengono memorizzati in un pool di indice, che per default è impostato su .rgw.buckets.index. Se si inseriscono troppi (centinaia di migliaia) oggetti in un singolo compartimento e la quota massima per il numero di oggetti per compartimento (rgw bucket default quota max objects) non è impostata, le prestazioni del pool di indice potrebbero essere compromesse. Il partizionamento dell'indice del compartimento impedisce tali riduzioni delle prestazioni e consente un numero maggiore di oggetti per compartimento.

11.9.1 Ripartizionamento dell'indice del compartimento #

Se un compartimento è diventato più grande e la rispettiva configurazione iniziale non è più sufficiente, è necessario ripartizionare il pool di indice del compartimento. È possibile utilizzare il ripartizionamento dell'indice del compartimento online (fare riferimento a Sezione 11.9.1.1, «Ripartizionamento dinamico») o eseguire manualmente il ripartizionamento dell'indice del compartimento offline (fare riferimento a Sezione 11.9.1.2, «Ripartizionamento manuale»).

11.9.1.1 Ripartizionamento dinamico #

A partire da SUSE Enterprise Storage 5, è supportato il ripartizionamento del compartimento online. Viene rilevato se il numero di oggetti per compartimento raggiunge una determinata soglia e viene aumentato automaticamente il numero di partizioni utilizzate dall'indice del compartimento. Questo processo consente di ridurre il numero di voci in ciascuna partizione dell'indice del compartimento.

Il processo di rilevamento viene eseguito:

Quando vengono aggiunti nuovi oggetti al compartimento.
In un processo in background che esegue periodicamente la scansione di tutti i compartimenti. Questo è necessario per gestire i compartimenti esistenti che non vengono aggiornati.

Un compartimento per il quale è richiesto il ripartizionamento viene aggiunto alla coda reshard_log e verrà pianificato per un ripartizionamento successivo. I thread della ripartizione vengono eseguiti in background ed eseguono un ripartizionamento pianificato alla volta.

Configurazione del ripartizionamento dinamico #

rgw_dynamic_resharding: Abilita o disabilita il ripartizionamento dinamico dell'indice del compartimento. I valori possibili sono "true" o "false". Il valore di default è "true".
rgw_reshard_num_logs: Numero di partizioni per il log di ripartizionamento. Il valore di default è 16.
rgw_reshard_bucket_lock_duration: Durata del bloccaggio nell'oggetto Compartimento durante il ripartizionamento. Il valore di default è 120 secondi.
rgw_max_objs_per_shard: Numero massimo di oggetti per partizione dell'indice del compartimento. Il valore di default è 10.0000 oggetti.
rgw_reshard_thread_interval: Durata massima tra i cicli di elaborazione dei thread delle ripartizioni. Il valore di default è 600 secondi.

Importante: configurazioni multisito

Il ripartizionamento dinamico non è supportato in ambienti multisito. A partire da Ceph 12.2.2 è disabilitato per default, ma si consiglia di verificare ulteriormente l'impostazione.

Comandi per amministrare il processo di ripartizionamento #

Aggiungere un compartimento alla coda di ripartizionamento:

root@minion > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS

Elencare la coda di ripartizionamento:

root@minion > radosgw-admin reshard list

Elaborare/pianificare un ripartizionamento del compartimento:

root@minion > radosgw-admin reshard process

Visualizzare lo stato di ripartizionamento del compartimento:

root@minion > radosgw-admin reshard status --bucket BUCKET_NAME

Annullare il ripartizionamento del compartimento in sospeso:

root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 Ripartizionamento manuale #

Il ripartizionamento dinamico di cui alla Sezione 11.9.1.1, «Ripartizionamento dinamico» è supportato solo per le configurazioni Object Gateway semplici. Per le configurazioni multisito, utilizzare il ripartizionamento manuale descritto nella presente sezione.

Per eseguire il ripartizionamento manuale dell'indice del compartimento offline, utilizzare il comando seguente:

root@minion > radosgw-admin bucket reshard

Il comando bucket reshard consente di effettuare le seguenti operazioni:

Creare un nuovo set di oggetti Indice compartimento per l'oggetto specificato.
Distribuire tutte le voci degli oggetti Indice.
Creare una nuova istanza del compartimento.
Collegare la nuova istanza del compartimento al compartimento in modo che tutte le nuove operazioni di indice passino attraverso i nuovi indici del compartimento.
Stampare il vecchio e il nuovo ID compartimento nell'output standard.

Procedura 11.1: Ripartizionamento del pool di indice del compartimento #

Assicurarsi che tutte le operazioni nel compartimento vengano interrotte

Eseguire il backup dell'indice del compartimento originale:

root@minion > radosgw-admin bi list \
 --bucket=BUCKET_NAME \
 > BUCKET_NAME.list.backup

Eseguire il ripartizionamento dell'indice del compartimento:
```
 root@minion > radosgw-admin reshard \
 --bucket=BUCKET_NAME \
 --num-shards=NEW_SHARDS_NUMBER
```
Suggerimento: ID compartimento precedente
Come parte del rispettivo output, questo comando consente inoltre di stampare l'ID compartimento nuovo e quello precedente. So noti l'ID compartimento precedente visualizzato sotto; questo sarà necessario per eliminare definitivamente gli oggetti Indice del compartimento precedenti.
Verificare che tali oggetti siano elencati correttamente confrontando l'elenco degli indici del compartimento precedenti con quello nuovo. Quindi, eliminare definitivamente gli oggetti Indice compartimento precedenti:
```
root@minion > radosgw-admin bi purge
 --bucket=BUCKET_NAME
 --bucket-id=OLD_BUCKET_ID
```

11.9.2 Partizionamento dell'indice del compartimento per nuovi compartimenti #

Sono disponibili due opzioni che influenzano il partizionamento dell'indice del compartimento:

Utilizzare l'opzione rgw_override_bucket_index_max_shards per le configurazioni semplici.
Utilizzare l'opzione bucket_index_max_shards per le configurazioni multisito.

Con l'impostazione delle opzioni su 0 si disabilita il partizionamento dell'indice del compartimento. Con un valore maggiore di 0 si abilita il partizionamento dell'indice del compartimento e si imposta il numero massimo di partizioni.

La formula seguente consente di calcolare il numero di partizioni consigliato:

number_of_objects_expected_in_a_bucket / 100000

Si tenga presente che il numero massimo di partizioni è 7877.

11.9.2.1 Configurazioni semplici #

Aprire il file di configurazione di Ceph e aggiungere o modificare l'opzione seguente:
```
rgw_override_bucket_index_max_shards = 12
```
Suggerimento: tutte o un'istanza di Object Gateway
Per configurare il partizionamento dell'indice del compartimento per tutte le istanze di Object Gateway, includere rgw_override_bucket_index_max_shards nella sezione [global].
Per configurare il partizionamento dell'indice del compartimento solo per una determinata istanza di Object Gateway, includere rgw_override_bucket_index_max_shards nella relativa sezione dell'istanza.
Riavviare Object Gateway. Per ulteriori dettagli, vedere Sezione 11.3, «Funzionamento del servizio Object Gateway».

11.9.2.2 Configurazioni multisito #

Le configurazioni multisito possono avere un pool di indice diverso per la gestione dei failover. Per configurare un numero di partizioni coerente per le zone in un gruppo di zone, impostare l'opzione bucket_index_max_shards nella configurazione del gruppo di zone:

Esportare la configurazione del gruppo di zone nel file zonegroup.json:
```
root@minion > radosgw-admin zonegroup get > zonegroup.json
```
Modificare il file zonegroup.json e impostare l'opzione bucket_index_max_shards per ciascuna zona con nome.

Reimpostare il gruppo di zone:

root@minion > radosgw-admin zonegroup set < zonegroup.json

Aggiornare il periodo:

root@minion > radosgw-admin period update --commit

11.10 Integrazione di OpenStack Keystone #

OpenStack Keystone è un servizio di gestione delle identità per il prodotto OpenStack. È possibile integrare Object Gateway con Keystone per configurare un gateway che accetti un token di autenticazione Keystone. Un utente autorizzato da Keystone ad accedere al gateway verrà verificato sul lato Ceph Object Gateway e verrà creato automaticamente se necessario. Object Gateway interroga Keystone periodicamente per un elenco di token revocati.

11.10.1 Configurazione di OpenStack #

Prima di configurare Ceph Object Gateway, è necessario configurare OpenStack Keystone all'abilitazione del servizio Swift e fare in modo questo che punti a Ceph Object Gateway:

Impostare il servizio Swift. Prima di poter utilizzare OpenStack per la convalida degli utenti Swift, creare il servizio Swift:
```
root # openstack service create \
 --name=swift \
 --description="Swift Service" \
 object-store
```

Impostare gli endpoint. Dopo aver creato il servizio Swift, fare in modo che punti a Ceph Object Gateway. Sostituire REGION_NAME con il nome del gruppo di zone o il nome dell'area del gateway.

root # openstack endpoint create --region REGION_NAME \
 --publicurl   "http://radosgw.example.com:8080/swift/v1" \
 --adminurl    "http://radosgw.example.com:8080/swift/v1" \
 --internalurl "http://radosgw.example.com:8080/swift/v1" \
 swift

Verificare le impostazioni. Dopo aver creato il servizio Swift e impostati gli endpoint, visualizzare questi ultimi per verificare che tutte le impostazioni siano corrette.
```
root # openstack endpoint show object-store
```

11.10.2 Configurazione di Ceph Object Gateway #

11.10.2.1 Configurazione dei certificati SSL #

Ceph Object Gateway interroga Keystone periodicamente per un elenco di token revocati. Tali richieste sono codificate e firmate. È inoltre possibile configurare Keystone in modo che vengano forniti token firmati da se stessi, a loro volta codificati e firmati. È necessario configurare il gateway in modo che possa decodificare e verificare tali messaggi firmati. Pertanto, è necessario convertire in formato "nss db" i certificati OpenSSL utilizzati da Keystone per creare le richieste:

root # mkdir /var/ceph/nss
root # openssl x509 -in /etc/keystone/ssl/certs/ca.pem \
 -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \
 -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

È inoltre possibile terminare OpenStack Keystone con un certificato SSL firmato da se stessi ai fini dell'iterazione di Ceph Object Gateway con Keystone. Installare il certificato SSL di Keystone sul nodo sul quale è in esecuzione Ceph Object Gateway o in alternativa impostare il valore dell'opzione rgw keystone verify ssl su "false". L'impostazione di rgw keystone verify ssl su "false" significa che non verrà effettuato alcun tentativo di verifica del certificato da parte del gateway.

11.10.2.2 Configurazione delle opzioni di Object Gateway #

È possibile configurare l'integrazione di Keystone utilizzando le opzioni seguenti:

rgw keystone api version: Versione dell'API Keystone. Le opzioni valide sono 2 o 3. Il valore di default è 2.
rgw keystone url: URL e numero di porta dell'API amministrativa RESTful sul server Keystone. Segue il modello SERVER_URL:PORT_NUMBER.
rgw keystone admin token: Token o segreto condiviso configurato all'interno di Keystone per le richieste amministrative.
rgw keystone accepted roles: Ruoli richiesti per provvedere alle richieste. L'impostazione di default è "Member, admin".
rgw keystone accepted admin roles: Elenco dei ruoli che consentono a un utente di ottenere privilegi amministrativi.
rgw keystone token cache size: Numero massimo di voci nella cache dei token Keystone.
rgw keystone revocation interval: Numero di secondi prima della verifica dei token revocati. Il valore di default è 15 * 60.
rgw keystone implicit tenants: Crea nuovi utenti nei rispettivi tenant con lo stesso nome. L'impostazione di default è "false".
rgw s3 auth use keystone: Se impostata su "'true", Ceph Object Gateway eseguirà l'autenticazione degli utenti tramite Keystone. L'impostazione di default è "false".
nss db path: Percorso del database NSS.

È inoltre possibile configurare il tenant del servizio Keystone, l'utente e la password per Keystone (per la versione v2.0 di OpenStack Identity API), in modo simile a quanto avviene per la configurazione dei servizi OpenStack. In tal modo si può evitare di impostare il segreto condiviso rgw keystone admin token nel file di configurazione, che deve essere disabilitato negli ambienti di produzione. Le credenziali del tenant del servizio devono disporre dei privilegi amministrativi. Per ulteriori dettagli, fare riferimento alla documentazione ufficiale di OpenStack Keystone (in lingua inglese). Di seguito sono riportate le opzioni di configurazione correlate:

rgw keystone admin user: Nome utente amministratore Keystone.
rgw keystone admin password: Password utente amministratore Keystone.
rgw keystone admin tenant: Tenant utente amministratore Keystone versione 2.0.

Un utente Ceph Object Gateway viene mappato a un tenant Keystone. A un utente Keystone vengono assegnati ruoli diversi, possibilmente su più tenant. Quando Ceph Object Gateway ottiene il ticket, fa riferimento ai ruoli del tenant e dell'utente assegnati a tale ticket, quindi accetta o rifiuta la richiesta in base all'impostazione definita per l'opzione rgw keystone accepted roles.

Suggerimento: mappatura ai tenant OpenStack

Sebbene i tenant Swift vengano mappati per default all'utente Object Gateway, è possibile mapparli anche ai tenant OpenStack tramite l'opzione rgw keystone implicit tenants. In tal modo i container utilizzeranno lo spazio dei nomi dei tenant anziché quello globale uguale a S3 che è l'impostazione di default di Object Gateway. Per evitare di fare confusione, si consiglia di decidere il metodo di mappatura in fase di pianificazione. L'attivazione/disattivazione dell'opzione in un momento successivo influisce solo sulle richieste più recenti che vengono mappate in un tenant, mentre i compartimenti creati precedentemente continuano a risiedere in uno spazio dei nomi globale.

Per la versione 3 di OpenStack Identity API, si deve sostituire l'opzione rgw keystone admin tenant con:

rgw keystone admin domain: Domino utente amministratore Keystone.
rgw keystone admin project: Progetto utente amministratore Keystone.

11.11 Object Gateway multisito #

Zona

Raggruppamento logico di una o più istanze Object Gateway. È necessario designare una zona come master in un gruppo di zone, dalla quale gestire la creazione di tutti i compartimenti e di tutti gli utenti.

Gruppo di zone

Un gruppo di zone è costituito da più zone. Le modifiche alla configurazione del sistema dovranno essere gestite da un gruppo di zone master.

Mappa del gruppo di zone

Struttura di configurazione che contiene la mappa dell'intero sistema, ad esempio indica il gruppo di zone master, le relazioni tra gruppi di zone diversi e alcune opzioni di configurazione come le policy di memorizzazione.

Dominio

Container per i gruppi di zone. Consente la separazione dei gruppi di zone tra i cluster. È possibile creare più domini in modo da semplificare l'esecuzione di configurazioni completamente diverse nello stesso cluster.

Periodo

Un periodo contiene la struttura di configurazione per lo stato attuale del dominio. Ciascun periodo contiene un ID univoco e un'epoca. A ogni dominio è associato un periodo attuale, con lo stato attuale della configurazione dei gruppi di zone e le policy di memorizzazione. Qualsiasi modifica alla configurazione per una zona non master aumenterà l'epoca del periodo. Se si modifica la zona master in una zona diversa, verranno attivate le seguenti modifiche:

Viene generato un nuovo periodo con un ID periodo nuovo e un'epoca pari a 1.
Il periodo attuale del dominio viene aggiornato in modo che punti all'ID periodo appena generato.
L'epoca del dominio aumenta di valore.

È possibile configurare ciascun Object Gateway in modo che faccia parte di un'architettura federata, operando in una configurazione di zona attiva e consentendo al contempo le scritture in zone non master.

11.11.1 Terminologia #

Di seguito è riportata una descrizione dei termini specifici di un'architettura federata:

11.11.2 Esempio di configurazione cluster #

Questo esempio è incentrato sulla creazione di un singolo gruppo di zone con tre zone distinte, in cui vengono sincronizzati attivamente i rispettivi dati. Due zone appartengono allo stesso cluster, mentre la terza appartiene a un cluster diverso. Non è presente alcun agente di sincronizzazione coinvolto nel processo di copia speculare delle modifiche dei dati tra gli Object Gateway. In tal modo si ottengono uno schema di configurazione e configurazioni attive-attive più semplici. Le operazioni dei metadati, come la creazione di un nuovo utente, devono continuare a passare dalla zona master. Le operazioni dei dati, tuttavia, come la creazione di compartimenti e oggetti, possono essere gestite da qualsiasi zona.

11.11.3 Chiavi di sistema #

Durante la configurazione delle zone, Object Gateway si aspetta la creazione di un utente del sistema compatibile con S3 e delle rispettive chiavi di accesso e segreta. Ciò consente a un'altra istanza di Object Gateway di recuperare la configurazione in remoto tramite le chiavi di accesso e segreta. Per ulteriori informazioni sulla creazione di utenti S3, vedere Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».

Suggerimento

È utile generare la chiave di accesso e la chiave segreta prima della creazione della zona stessa perché così facendo, successivamente la creazione di script e l'uso degli strumenti di gestione della configurazione risulteranno più semplici.

Ai fini del presente esempio, presupporre che la chiave di accesso e la chiave segreta siano impostate nelle variabili ambiente:

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805
# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

Di norma, le chiavi di accesso sono costituite da 20 caratteri alfanumerici, mentre le chiavi segrete da 40 caratteri alfanumerici (possono contenere anche i caratteri +/=). È possibile generare tali chiavi nella riga di comando:

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)
# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

11.11.4 Convenzioni di denominazione #

In questo esempio è illustrato il processo di configurazione di una zona master. Si prenda come riferimento un gruppo di zone denominato us esteso agli Stati Uniti che sarà il gruppo di zone master . Tale gruppo di zone conterrà due zone scritte nel formato zonegroup-zone. Il formato dell'esempio è quello convenzionale, ma è possibile scegliere il formato che si preferisce. Nel riepilogo:

Gruppo di zone master: Stati Uniti us
Zona master: Stati Uniti, Area Est 1: us-east-1
Zona secondaria: Stati Uniti, Area Est 2: us-east-2
Zona secondaria: Stati Uniti, Area Ovest: us-west

Questa farà parte di un dominio più grande denominato gold. Le zone us-east-1 e us-east-2 fanno parte dello stesso cluster Ceph, us-east-1che è quello primario. us-west rientra in un cluster Ceph diverso.

11.11.5 Pool di default #

Quando è configurato con le autorizzazioni appropriate, Object Gateway crea pool di default propri. I valori pg_num e pgp_num sono ricavati dal file di configurazione ceph.conf. I pool correlati a una zona per default seguono la convezione zone-name.pool-name. Ad esempio, per la zona us-east-1 verranno creati i seguenti pool:

.rgw.root
us-east-1.rgw.control
us-east-1.rgw.data.root
us-east-1.rgw.gc
us-east-1.rgw.log
us-east-1.rgw.intent-log
us-east-1.rgw.usage
us-east-1.rgw.users.keys
us-east-1.rgw.users.email
us-east-1.rgw.users.swift
us-east-1.rgw.users.uid
us-east-1.rgw.buckets.index
us-east-1.rgw.buckets.data
us-east-1.rgw.meta

È possibile creare tali pool anche in altre zone sostituendo us-east-1 con il nome zona appropriato.

11.11.6 Creazione di un dominio #

Configurare un dominio denominato gold e renderlo il dominio di default:

cephadm > radosgw-admin realm create --rgw-realm=gold --default
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}

Si noti che ciascun dominio dispone di un ID ai fini della flessibilità, ad esempio consente di rinominarlo in un momento successivo in caso di necessità. Il current_period cambia ogni volta che si modifica la zona master. Il valore di epoch aumenta quando una modifica nella configurazione della zona master risulta in una modifica del periodo attuale.

11.11.7 Eliminazione del gruppo di zone di default #

L'installazione di default di Object Gateway crea un gruppo di zone di default denominato default. Poiché il gruppo di zone di default non è più necessario, rimuoverlo.

cephadm > radosgw-admin zonegroup delete --rgw-zonegroup=default

11.11.8 Creazione di un gruppo di zone master #

Creare un gruppo di zone master denominato us. Il gruppo di zone gestirà la mappa del gruppo di zone e propagherà le modifiche al resto del sistema. Contrassegnando il gruppo di zone come default, si consentirà la menzione esplicita dello switch rgw-zonegroup per i comandi successivi.

cephadm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default
{
  "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "name": "us",
  "api_name": "us",
  "is_master": "true",
  "endpoints": [
      "http:\/\/rgw1:80"
  ],
  "hostnames": [],
  "hostnames_s3website": [],
  "master_zone": "",
  "zones": [],
  "placement_targets": [],
  "default_placement": "",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

In alternativa, è possibile contrassegnare un gruppo di zone come default con il comando seguente:

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.9 Creazione di una zona master #

Adesso creare una zona di default e aggiungerla al gruppo di zone di default. Questa zona verrà utilizzata per le operazioni dei metadati, come la creazione di un utente:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "name": "us-east-1",
  "domain_root": "us-east-1/gc.rgw.data.root",
  "control_pool": "us-east-1/gc.rgw.control",
  "gc_pool": "us-east-1/gc.rgw.gc",
  "log_pool": "us-east-1/gc.rgw.log",
  "intent_log_pool": "us-east-1/gc.rgw.intent-log",
  "usage_log_pool": "us-east-1/gc.rgw.usage",
  "user_keys_pool": "us-east-1/gc.rgw.users.keys",
  "user_email_pool": "us-east-1/gc.rgw.users.email",
  "user_swift_pool": "us-east-1/gc.rgw.users.swift",
  "user_uid_pool": "us-east-1/gc.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-1/gc.rgw.buckets.index",
              "data_pool": "us-east-1/gc.rgw.buckets.data",
              "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-1/gc.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

Gli switch --rgw-zonegroup e --default consentono di aggiungere la zona a un gruppo di zone e la rendono la zona di default. In alternativa, è possibile effettuare la stessa operazione con i comandi seguenti:

cephadm > radosgw-admin zone default --rgw-zone=us-east-1
cephadm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

11.11.9.1 Creazione di utenti di sistema #

Per accedere ai pool di zone, è necessario creare un utente di sistema. Queste chiavi saranno necessarie anche quando si configura la zona secondaria.

cephadm > radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \
--secret=$SYSTEM_SECRET_KEY --system

11.11.9.2 Aggiornamento del periodo #

Poiché si è modificata la configurazione della zona master, è necessario confermare le modifiche per poterle applicare alla struttura di configurazione del dominio. Inizialmente il dominio ha il seguente aspetto:

cephadm > radosgw-admin period get
{
  "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map":
  {
    "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": []
  }, "master_zonegroup": "", "master_zone": "", "period_config":
  {
     "bucket_quota": {
     "enabled": false, "max_size_kb": -1, "max_objects": -1
     }, "user_quota": {
       "enabled": false, "max_size_kb": -1, "max_objects": -1
     }
  }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1
}

Aggiornare il periodo e confermare le modifiche:

cephadm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 1,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [ "[...]"
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }
              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          }
      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

11.11.9.3 Avvio di Object Gateway #

Prima di avviare Object Gateway, è necessario menzionare nel file di configurazione le opzioni relative alla zona e alla porta Object Gateway. Per ulteriori informazioni su Object Gateway e la relativa configurazione, vedere Capitolo 11, Ceph Object Gateway. La sezione di configurazione di Object Gateway deve avere un aspetto simile a quanto riportato di seguito:

[client.rgw.us-east-1]
rgw_frontends="civetweb port=80"
rgw_zone=us-east-1

Avviare Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-east-1

11.11.10 Creazione di una zona secondaria #

Nello stesso cluster, creare e configurare la zona secondaria denominata us-east-2. È possibile eseguire tutti i comandi seguenti nel nodo che ospita la zona master stessa.

Per creare una zona secondaria, utilizzare lo stesso comando impiegato per la creazione della zona primaria, ad eccezione del rilascio del flag master:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \
--rgw-zone=us-east-2 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-east-2",
  "domain_root": "us-east-2.rgw.data.root",
  "control_pool": "us-east-2.rgw.control",
  "gc_pool": "us-east-2.rgw.gc",
  "log_pool": "us-east-2.rgw.log",
  "intent_log_pool": "us-east-2.rgw.intent-log",
  "usage_log_pool": "us-east-2.rgw.usage",
  "user_keys_pool": "us-east-2.rgw.users.keys",
  "user_email_pool": "us-east-2.rgw.users.email",
  "user_swift_pool": "us-east-2.rgw.users.swift",
  "user_uid_pool": "us-east-2.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-2.rgw.buckets.index",
              "data_pool": "us-east-2.rgw.buckets.data",
              "data_extra_pool": "us-east-2.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-2.rgw.meta",
  "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"
}

11.11.10.1 Aggiornamento del periodo #

Informare tutti i gateway in merito alla nuova modifica della mappa di sistema eseguendo un aggiornamento del periodo e confermando le modifiche:

cephadm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [ "[...]"
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                  {
                      "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
                      "name": "us-east-2",
                      "endpoints": [
                          "http:\/\/rgw2:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }

              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          },
          {
              "key": "950c1a43-6836-41a2-a161-64777e07e8b8",
              "val": 4276257543
          }

      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

11.11.10.2 Avvio di Object Gateway #

Regolare la configurazione di Object Gateway per una zona secondaria e avviarlo:

[client.rgw.us-east-2]
rgw_frontends="civetweb port=80"
rgw_zone=us-east-2

cephadm > sudo systemctl start ceph-radosgw@rgw.us-east-2

11.11.11 Aggiunta di Object Gateway al secondo cluster #

Il secondo cluster Ceph appartiene allo stesso gruppo di zone di quello iniziale, ma è geograficamente ubicato altrove.

11.11.11.1 Dominio e gruppo di zone di default #

Poiché si è già creato il dominio per il primo gruppo di zone, recuperare qui il dominio e renderlo quello di default:

cephadm > radosgw-admin realm pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2
}
cephadm > radosgw-admin realm default --rgw-realm=gold

Ottenere la configurazione dalla zona master recuperando il periodo:

cephadm > radosgw-admin period pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

Impostare il gruppo di zone di default a quello us che è già stato creato:

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.11.2 Configurazione della zona secondaria #

Creare una nuova zona denominata us-west con le stesse chiavi di sistema:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \
--endpoints=http://rgw3:80 --default
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-west",
  "domain_root": "us-west.rgw.data.root",
  "control_pool": "us-west.rgw.control",
  "gc_pool": "us-west.rgw.gc",
  "log_pool": "us-west.rgw.log",
  "intent_log_pool": "us-west.rgw.intent-log",
  "usage_log_pool": "us-west.rgw.usage",
  "user_keys_pool": "us-west.rgw.users.keys",
  "user_email_pool": "us-west.rgw.users.email",
  "user_swift_pool": "us-west.rgw.users.swift",
  "user_uid_pool": "us-west.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-west.rgw.buckets.index",
              "data_pool": "us-west.rgw.buckets.data",
              "data_extra_pool": "us-west.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-west.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

11.11.11.3 Aggiornamento del periodo #

Per propagare le modifiche del gruppo di zone, si aggiorna e si conferma il periodo:

cephadm > radosgw-admin period update --commit --rgw-zone=us-west
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 3,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [
      "", # truncated
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                                  {
                      "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
                      "name": "us-east-2",
                      "endpoints": [
                          "http:\/\/rgw2:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                  {
                      "id": "d9522067-cb7b-4129-8751-591e45815b16",
                      "name": "us-west",
                      "endpoints": [
                          "http:\/\/rgw3:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }
              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          },
          {
              "key": "950c1a43-6836-41a2-a161-64777e07e8b8",
              "val": 4276257543
          },
          {
              "key": "d9522067-cb7b-4129-8751-591e45815b16",
              "val": 329470157
          }
      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

Il numero di epoca del periodo aumenta a indicare una modifica nella configurazione.

11.11.11.4 Avvio di Object Gateway #

Questa operazione è simile all'avvio di Object Gateway nella prima zona, con l'unica differenza che la configurazione di zona di Object Gateway deve riflettere il nome zona us-west:

[client.rgw.us-west]
rgw_frontends="civetweb port=80"
rgw_zone=us-west

Avviare il secondo Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-west

11.11.12 Failover e disaster recovery #

Qualora la zona master dovesse venire meno, eseguire il failover nella zona secondaria per il disaster recovery.

Rendere la zona secondaria la zona master e di default. Ad esempio:
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
```
Per default, Ceph Object Gateway verrà eseguito in una configurazione attiva-attiva. Se si è configurato il cluster per l'esecuzione in una configurazione attiva-passiva, la zona secondaria è di sola lettura. Rimuovere lo stato --read-per consentire alla zona di ricevere operazioni di scrittura. Ad esempio:
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \
--read-only=False
```
Aggiornare il periodo per applicare le modifiche.
```
root # radosgw-admin period update --commit
```

Infine, riavviare Ceph Object Gateway.

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

Se la zona master precedente viene recuperata, ripristinare l'operazione.

Dalla zona recuperata, recuperare il periodo dall'attuale zona master.

root # radosgw-admin period pull --url={url-to-master-zone-gateway} \
--access-key={access-key} --secret={secret}

Rendere la zona recuperata la zona master e di default.

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

Aggiornare il periodo per applicare le modifiche.
```
root # radosgw-admin period update --commit
```
Quindi, riavviare Ceph Object Gateway nella zona recuperata.
```
root # systemctl restart ceph-radosgw@rgw.`hostname -s`
```
Se la configurazione della zona secondaria deve essere in sola lettura, aggiornare la zona secondaria.
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
```
Aggiornare il periodo per applicare le modifiche.
```
root # radosgw-admin period update --commit
```
Infine, riavviare Ceph Object Gateway nella zona secondaria.
```
root # systemctl restart ceph-radosgw@rgw.`hostname -s`
```

11.12 Bilanciamento del carico dei server Object Gateway con HAProxy #

È possibile utilizzare il bilanciamento del carico HAProxy per distribuire tutte le richieste in più server back-end Object Gateway. Per ulteriori dettagli sulla configurazione di HAProxy, fare riferimento a https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html (in lingua inglese).

Di seguito è riportata una configurazione semplice di HAProxy per il bilanciamento dei nodi Object Gateway mediante l'uso di Round Robin come algoritmo di bilanciamento:

root # cat /etc/haproxy/haproxy.cfg
[...]
frontend https_frontend
bind *:443 crt path-to-cert.pem [ciphers: ... ]
default_backend rgw

backend rgw
mode http
balance roundrobin
server rgw_server1 rgw-endpoint1 weight 1 maxconn 100 check
server rgw_server2 rgw-endpoint2 weight 1 maxconn 100 check
[...]

Stampa pagina

Guida all'amministrazione

11 Ceph Object Gateway #

11.1 Restrizioni e limiti di denominazione di Object Gateway #

11.1.1 Limiti dei compartimenti #

Suggerimento: utilizzo di nomi di compartimenti conformi a DNS

11.1.2 Limiti degli oggetti memorizzati #

11.1.3 Limiti dell'intestazione HTTP #

11.2 Distribuzione di Object Gateway #

11.3 Funzionamento del servizio Object Gateway #

11.4 Parametri di configurazione #

11.4.1 Note aggiuntive #

11.5 Gestione dell'accesso a Object Gateway #

11.5.1 Accesso a Object Gateway #

11.5.1.1 Accesso all'interfaccia S3 #

11.5.1.2 Accesso all'interfaccia Swift #

11.5.2 Gestione degli account S3 e Swift #

11.5.2.1 Aggiunta di utenti S3 e Swift #

11.5.2.2 Rimozione di utenti S3 e Swift #

Suggerimento: rimozione di un sottoutente

11.5.2.3 Modifica delle chiavi di accesso e segrete degli utenti S3 e Swift #

11.5.2.4 Gestione delle quote utente #

11.6 Abilitazione di HTTPS/SSL per gli Object Gateway #

11.6.1 Creazione di un certificato firmato da se stessi #

Suggerimento

11.6.2 Configurazione HTTPS semplice #

11.6.3 Configurazione HTTPS avanzata #

Suggerimento: associazione di più porte

11.7 Moduli di sincronizzazione #

11.7.1 Sincronizzazione delle zone #

Nota: plug-in di sincronizzazione di default

11.7.1.1 Requisiti e presupposti #

11.7.1.2 Configurazione dei moduli di sincronizzazione #

11.7.2 Memorizzazione dei metadati in Elasticsearch #

11.7.2.1 Parametri di configurazione di tipi di livelli Elasticsearch #

11.7.2.2 Interrogazioni dei metadati #

11.8 Autenticazione LDAP #

11.8.1 Meccanismo di autenticazione #

11.8.2 Requisiti #

Importante: non sovrapporre utenti LDAP e utenti locali

Suggerimento: test di integrità

11.8.3 Configurazione di Object Gateway per utilizzare l'autenticazione LDAP #

11.8.4 Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti #

11.8.4.1 Filtro parziale per limitare ulteriormente il filtro di ricerca costruito #

11.8.4.2 Filtro completo #

Nota: attributo memberOf

11.8.5 Generazione di un token di accesso per l'autenticazione LDAP #

Importante: credenziali non cifrate

Nota: Active Directory

11.9 Partizionamento dell'indice del compartimento #

11.9.1 Ripartizionamento dell'indice del compartimento #

11.9.1.1 Ripartizionamento dinamico #

Configurazione del ripartizionamento dinamico #

Importante: configurazioni multisito

Comandi per amministrare il processo di ripartizionamento #

11.9.1.2 Ripartizionamento manuale #

Procedura 11.1: Ripartizionamento del pool di indice del compartimento #

Suggerimento: ID compartimento precedente

11.9.2 Partizionamento dell'indice del compartimento per nuovi compartimenti #

11.9.2.1 Configurazioni semplici #

Suggerimento: tutte o un'istanza di Object Gateway

11.9.2.2 Configurazioni multisito #

11.10 Integrazione di OpenStack Keystone #

11.10.1 Configurazione di OpenStack #

11.10.2 Configurazione di Ceph Object Gateway #

11.10.2.1 Configurazione dei certificati SSL #

11.10.2.2 Configurazione delle opzioni di Object Gateway #

Suggerimento: mappatura ai tenant OpenStack

11.11 Object Gateway multisito #

11.11.1 Terminologia #

11.11.2 Esempio di configurazione cluster #

11.11.3 Chiavi di sistema #

Suggerimento

11.11.4 Convenzioni di denominazione #

11.11.5 Pool di default #

11.11.6 Creazione di un dominio #

11.11.7 Eliminazione del gruppo di zone di default #

11.11.8 Creazione di un gruppo di zone master #

11.11.9 Creazione di una zona master #

11.11.9.1 Creazione di utenti di sistema #

11.11.9.2 Aggiornamento del periodo #

Nota: attributo `memberOf`