Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7.1 / Guida all'amministrazione e alle operazioni / Accesso ai dati del cluster  / Ceph Object Gateway
Si applica a SUSE Enterprise Storage 7.1

21 Ceph Object Gateway

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.

21.1 Restrizioni e limitazioni di denominazione di Object Gateway

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

21.1.1 Limitazioni 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
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.

21.1.2 Limitazioni 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.

21.1.3 Limitazioni dell'intestazione HTTP

L'intestazione HTTP e il limite di richiesta dipendono dalla front-end Web utilizzata. L'oggetto beast di default limita le dimensioni dell'intestazione HTTP a 16 KB.

21.2 Distribuzione di Object Gateway

Analogamente agli altri servizi Ceph, Ceph Object Gateway viene distribuito tramite cephadm. Per ulteriori dettagli, fare riferimento a Sezione 8.2, «Specifica del servizio e del posizionamento», nello specifico a Sezione 8.3.4, «Distribuzione degli Object Gateway».

21.3 Attivazione del servizio Object Gateway

In modo analogo agli altri servizi Ceph, gli Object Gateway vengono attivati identificando innanzitutto il nome del servizio con il comando ceph orch ps ed eseguendo quindi il comando di attivazione seguente, ad esempio:

ceph orch daemon restart OGW_SERVICE_NAME

Fare riferimento al Capitolo 14, Funzionamento dei servizi Ceph per informazioni complete sull'attivazione dei servizi Ceph.

21.4 Opzioni di configurazione

Fare riferimento alla Sezione 28.5, «Ceph Object Gateway» per un elenco delle opzioni di configurazione di Object Gateway.

21.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.

21.5.1 Accesso a Object Gateway

21.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 21.5.2.1, «Aggiunta di utenti S3 e Swift».

  1. Installare il pacchetto python-boto:

    # zypper in python-boto
  2. 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\tCREATED".format(
      name = bucket.name,
      created = bucket.creation_date,
      )

    Sostituire HOSTNAME con il nome host dell'host in cui è stato configurato il servizio Object Gateway, ad esempio gateway_host.

  3. 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

21.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" di SUSE Linux Enterprise 12 a partire da SP3 e di SUSE Linux Enterprise 15. Prima di installare il pacchetto, è necessario attivare il modulo e aggiornare l'archivio software:

# SUSEConnect -p sle-module-public-cloud/12/SYSTEM-ARCH
sudo zypper refresh

Oppure

# SUSEConnect -p sle-module-public-cloud/15/SYSTEM-ARCH
# zypper refresh

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

# 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 valore corrispondente dell'output del comando radosgw-admin key create eseguito per l'utente swift nella Sezione 21.5.2.1, «Aggiunta di utenti S3 e Swift».

Esempio:

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

L'output è:

my-new-bucket

21.5.2 Gestione degli account S3 e Swift

21.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.

Per creare un utente Swift, seguire la procedura indicata:

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

    cephuser@adm > radosgw-admin user create --uid=USERNAME \
     --display-name="DISPLAY-NAME" --email=EMAIL

    Esempio:

    cephuser@adm > radosgw-admin user create \
       --uid=example_user \
       --display-name="Example User" \
       --email=penguin@example.com
  2. Per creare un sottoutente (interfaccia Swift) per l'utente, occorre specificare l'ID utente (--uid=USERNAME) nonché l'ID e il livello di accesso del sottoutente.

    cephuser@adm > radosgw-admin subuser create --uid=UID \
     --subuser=UID \
     --access=[ read | write | readwrite | full ]

    Esempio:

    cephuser@adm > radosgw-admin subuser create --uid=example_user \
     --subuser=example_user:swift --access=full
  3. Generare una chiave segreta per l'utente.

    cephuser@adm > radosgw-admin key create \
       --gen-secret \
       --subuser=example_user:swift \
       --key-type=swift
  4. 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"}],

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

cephuser@adm > radosgw-admin user create --uid=USERNAME \
 --display-name="DISPLAY-NAME" --email=EMAIL

Esempio:

cephuser@adm > 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"}],
 [...]

21.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:

cephuser@adm > radosgw-admin user rm --uid=example_user

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

cephuser@adm > 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
Suggerimento: rimozione di un sottoutente

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

21.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:

cephuser@adm > radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret

Per gli utenti Swift, eseguire quanto riportato di seguito:

cephuser@adm > 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.

21.5.2.4 Abilitazione della 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:

cephuser@adm > 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:

cephuser@adm > radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER

Per disabilitare una quota:

cephuser@adm > radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER

Per elencare le impostazioni della quota:

cephuser@adm > radosgw-admin user info --uid=EXAMPLE_USER

Per aggiornare le statistiche della quota:

cephuser@adm > radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats

21.6 Front-end HTTP

Ceph Object Gateway supporta due front-end HTTP integrati: oggetto beast e Civetweb.

Il front-end dell'oggetto beast utilizza la libreria Boost.Beast per l'analisi HTTP e la libreria Boost.Asio per l'I/O di rete asincrono.

Il front-end Civetweb utilizza la libreria HTTP Civetweb, che è un fork di Mongoose.

È possibile configurarli con l'opzione rgw_frontends. Fare riferimento alla Sezione 28.5, «Ceph Object Gateway» per un elenco delle opzioni di configurazione.

21.7 Abilitazione di HTTPS/SSL per gli Object Gateway

Per abilitare la comunicazione sicura di Object Gateway tramite SSL, occorre disporre di un certificato emesso da un'autorità di certificazione o crearne uno autofirmato.

21.7.1 Creazione di un certificato autofirmato

Suggerimento
Suggerimento

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

Nella procedura seguente è illustrato come generare un certificato SSL autofirmato sul Salt Master.

  1. Se è necessario che Object Gateway sia noto ad altre identità di oggetto, aggiungerle all'opzione subjectAltName nella sezione [v3_req] del file /etc/ssl/openssl.cnf:

    [...]
    [ v3_req ]
    subjectAltName = DNS:server1.example.com DNS:server2.example.com
    [...]
    Suggerimento
    Suggerimento: indirizzi IP in subjectAltName

    Per utilizzare gli indirizzi IP al posto dei nomi di dominio nell'opzione subjectAltName, sostituire la riga di esempio con quanto segue:

    subjectAltName = IP:10.0.0.10 IP:10.0.0.11
  2. Creare la chiave e il certificato utilizzando openssl. 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 # openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key
     -out rgw.pem
  3. Aggiungere la chiave al file di certificato:

    root@master # cat rgw.key >> rgw.pem

21.7.2 Configurazione di Object Gateway con SSL

Per configurare Object Gateway sull'uso dei certificati SSL, utilizzare l'opzione rgw_frontends. Esempio:

cephuser@adm > ceph config set WHO rgw_frontends \
 beast ssl_port=443 ssl_certificate=config://CERT ssl_key=config://KEY

Se le chiavi di configurazione CERT e KEY non vengono specificate, il servizio Object Gateway cercherà la chiave e il certificato SSL nelle chiavi di configurazione seguenti:

rgw/cert/RGW_REALM/RGW_ZONE.key
rgw/cert/RGW_REALM/RGW_ZONE.crt

Se si desidera sostituire l'ubicazione della chiave e del certificato SSL di default, importarli nel database di configurazione utilizzando il comando seguente:

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

Quindi, utilizzare le chiavi di configurazione personalizzate con la direttiva config://.

21.8 Moduli di sincronizzazione

Object Gateway viene distribuito come servizio multisito ed è possibile eseguire la copia speculare dei dati e dei metadati tra le zone. 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 (ad esempio, operazioni correlate ai metadati come la creazione di compartimenti o di utenti). Poiché le modifiche del multisito Object Gateway sono coerenti nei siti remoti, le modifiche vengono propagate in modo asincrono. Questo concetto comprende casi d'uso come il backup della memorizzazione di oggetti in un cluster cloud esterno, una soluzione di backup personalizzata in cui vengono utilizzate unità nastro o l'indicizzazione dei metadati in ElasticSearch.

21.8.1 Configurazione dei moduli di sincronizzazione

Tutti i moduli di sincronizzazione vengono configurati in modo simile. È necessario creare una nuova zona (fare riferimento alla Sezione 21.13, «Object Gateway multisito» per ulteriori dettagli) e impostare la relativa opzione --tier_type, ad esempio --tier-type=cloud, per il modulo di sincronizzazione cloud:

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --endpoints=http://endpoint1.example.com,http://endpoint2.example.com, [...] \
 --tier-type=cloud

È possibile configurare un livello specifico tramite il comando seguente:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=KEY1=VALUE1,KEY2=VALUE2

La variabile KEY della configurazione specifica la variabile di configurazione da aggiornare, mentre VALUE specifica il nuovo valore corrispondente. È possibile accedere ai valori nidificati utilizzando il punto. Esempio:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=connection.access_key=KEY,connection.secret=SECRET

È possibile accedere agli elementi della matrice aggiungendo delle parentesi quadre "[]" all'elemento a cui si fa riferimento. È possibile aggiungere un nuovo elemento della matrice utilizzando le parentesi quadre "[]". Il valore di indice -1 fa riferimento all'ultimo elemento della matrice. Non è possibile creare un nuovo elemento e farvi nuovamente riferimento nello stesso comando. Ad esempio, di seguito è riportato un comando per la creazione di un nuovo profilo per i compartimenti che iniziano con PREFIX:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID
Suggerimento
Suggerimento: aggiunta e rimozione delle voci di configurazione

Tramite il parametro --tier-config-add==VALUE, è possibile aggiungere una nuova voce di configurazione del livello.

Per rimuovere una voce esistente, utilizzare --tier-config-rm=KEY.

21.8.2 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
Nota: plug-in di sincronizzazione di default

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

21.8.2.1 Requisiti e presupposti

Si supponga una semplice configurazione multisito, come descritta nella Sezione 21.13, «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.

21.8.2.2 Configurazione delle zone

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

    cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
    --access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80
  2. È possibile configurare un modulo di sincronizzazione per questa zona nel modo seguente:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
    --tier-config={set of key=value pairs}
  3. Ad esempio, nel modulo di sincronizzazione ElasticSearch

    cephuser@adm > 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 21.8.3, «Modulo di sincronizzazione ElasticSearch».

  4. Infine, aggiornare il periodo

    cephuser@adm > radosgw-admin period update --commit
  5. Adesso, avviare Object Gateway nella zona

    cephuser@adm > ceph orch start rgw.REALM-NAME.ZONE-NAME

21.8.3 Modulo di sincronizzazione 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"
    }
  }
}

21.8.3.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.

nomeutente

Specifica un nome utente per ElasticSearch se occorre effettuare l'autenticazione.

password

Specifica una password per ElasticSearch se occorre effettuare l'autenticazione.

21.8.3.2 Interrogazioni dei metadati

Poiché adesso nel cluster ElasticSearch vengono memorizzati metadati di oggetti, è importante che l'endpoint di ElasticSearch non sia esposto al 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 l'utente dovrebbe interrogare 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, il che 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 di ElasticSearch non viene esposto al 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: <, <=, ==, >=, >

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 i metadati di oggetto personalizzati x-amz-meta-year come int, x-amz-meta-date come tipo di data e x-amz-meta-title come stringa, procedere come indicato di seguito

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

21.8.4 Modulo di sincronizzazione cloud

Questa sezione descrive un modulo che effettua la sincronizzazione dei dati della zona con un servizio cloud remoto. La sincronizzazione è esclusivamente unidirezionale (ovvero la data non viene risincronizzata dalla zona remota). L'obiettivo principale di questo modulo è quello di abilitare la sincronizzazione dei dati con più provider di servizi cloud. Al momento, questo modulo supporta i provider cloud compatibili con AWS (S3).

Per sincronizzare i dati con un servizio cloud remoto, occorre configurare le credenziali utente. Poiché molti servizi cloud introducono dei limiti sul numero di compartimenti che ciascun utente può creare, è possibile configurare la mappatura dei compartimenti e degli oggetti di origine, delle diverse destinazioni su compartimenti diversi e dei prefissi dei compartimenti. Tenere presente che gli elenchi di accesso all'origine (ACL) non verranno conservati. È possibile mappare le autorizzazioni degli utenti di origine specifici a determinati utenti di destinazione.

A causa delle limitazioni dell'API, non è possibile conservare l'ora di modifica dell'oggetto originale e il tag dell'entità HTTP (ETag). Il modulo di sincronizzazione cloud memorizza queste informazioni come attributi di metadati sugli oggetti di destinazione.

21.8.4.1 Configurazione del modulo di sincronizzazione cloud

Di seguito sono riportati degli esempi di configurazione semplice e complessa del modulo di sincronizzazione cloud. Tenere presente che la configurazione semplice può entrare in conflitto con quella complessa.

Esempio 21.1: Configurazione semplice
{
  "connection": {
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,
  },
  "acls": [ { "type": id | email | uri,
    "source_id": SOURCE_ID,
    "dest_id": DEST_ID } ... ],
  "target_path": TARGET_PATH,
}
Esempio 21.2: Configurazione complessa
{
  "default": {
    "connection": {
      "access_key": ACCESS,
      "secret": SECRET,
      "endpoint": ENDPOINT,
      "host_style" path | virtual,
    },
    "acls": [
    {
      "type": id | email | uri,   #  optional, default is id
      "source_id": ID,
      "dest_id": ID
    } ... ]
    "target_path": PATH # optional
  },
  "connections": [
  {
    "connection_id": ID,
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,  # optional
  } ... ],
  "acl_profiles": [
  {
    "acls_id": ID, # acl mappings
    "acls": [ {
      "type": id | email | uri,
      "source_id": ID,
      "dest_id": ID
    } ... ]
  }
  ],
  "profiles": [
  {
   "source_bucket": SOURCE,
   "connection_id": CONNECTION_ID,
   "acls_id": MAPPINGS_ID,
   "target_path": DEST,          # optional
  } ... ],
}

Di seguito è riportata la spiegazione dei termini di configurazione utilizzati:

connessione

Rappresenta la connessione al servizio cloud remoto. Contiene "connection_id", "access_key", "secret", "endpoint", e "host_style".

access_key

La chiave di accesso al cloud remoto che verrà utilizzata per la connessione specifica.

secret

La chiave segreta del servizio cloud remoto.

endpoint

URL dell'endpoint del servizio cloud remoto.

host_style

Tipo di stile host ("path" o "virtual") da utilizzare per l'accesso all'endpoint cloud remoto. L'impostazione di default è "path".

acls

Matrice delle mappature dell'elenco accessi.

acl_mapping

Ciascuna struttura "acl_mapping" contiene "type", "source_id" e "dest_id". Questi valori definiscono la mutazione dell'ACL di ciascun oggetto. Le mutazioni dell'ACL consentono di convertire l'ID utente di origine in un ID di destinazione.

tipo

Tipo di ACL: "id" definisce l'ID utente, "email" definisce l'utente tramite l'indirizzo e-mail e "uri" definisce l'utente in base all'uri (gruppo).

source_id

ID dell'utente nella zona di origine.

dest_id

ID dell'utente nella destinazione.

target_path

Una stringa che definisce la modalità di creazione del percorso di destinazione. Il percorso di destinazione specifica un prefisso al quale viene aggiunto il nome dell'oggetto di origine. Il percorso di destinazione configurabile può includere una delle seguenti variabili:

SID

Una stringa univoca che rappresenta l'ID dell'istanza di sincronizzazione.

ZONEGROUP

Nome del gruppo di zone.

ZONEGROUP_ID

ID del gruppo di zone.

ZONE

Nome della zona.

ZONE_ID

ID della zona.

BUCKET

Nome del compartimento di origine.

OWNER

ID del proprietario del compartimento di origine.

Ad esempio: target_path = rgwx-ZONE-SID/OWNER/BUCKET

acl_profiles

Una matrice dei profili dell'elenco accessi.

acl_profile

Ogni profilo contiene "acls_id", che rappresenta il profilo, e una matrice "acls" che contiene un elenco delle "acl_mappings".

profili

Un elenco dei profili. Ogni profilo contiene quanto segue:

source_bucket

Il nome o il prefisso di un compartimento (se termina con *) che definisce i compartimenti di origine per il profilo.

target_path

Vedere sopra per la spiegazione.

connection_id

ID della connessione che verrà utilizzato per questo profilo.

acls_id

ID del profilo dell'ACL che verrà utilizzato per questo profilo.

21.8.4.2 Elementi configurabili specifici di S3

Il modulo di sincronizzazione cloud funziona soltanto con i back-end compatibili con AWS S3. È possibile utilizzare alcuni elementi configurabili per ottimizzarne il comportamento durante l'accesso ai servizi cloud S3:

{
  "multipart_sync_threshold": OBJECT_SIZE,
  "multipart_min_part_size": PART_SIZE
}
multipart_sync_threshold

Gli oggetti di dimensioni uguali o superiori a questo valore verranno sincronizzati con il servizio cloud tramite l'upload multipart.

multipart_min_part_size

Dimensioni minime delle parti da utilizzare durante la sincronizzazione degli oggetti con l'upload multipart.

21.8.5 Modulo di sincronizzazione degli archivi

Il modulo di sincronizzazione degli archivi utilizza la funzione del controllo versioni degli oggetti S3 in Object Gateway. È possibile configurare una zona di archiviazione per acquisire le diverse versioni degli oggetti S3 che hanno luogo nel corso del tempo nelle altre zone. Tramite i gateway associati alla zona di archiviazione, è possibile eliminare la cronologia delle versioni conservata nella zona stessa.

Grazie a questa architettura, diverse zone senza versione possono eseguire la copia speculare dei relativi dati e metadati tramite i propri gateway di zona fornendo elevata disponibilità agli utenti finali, mentre la zona di archiviazione acquisisce tutti gli aggiornamenti dei dati per consolidarli come versioni degli oggetti S3.

Includendo la zona di archiviazione in una configurazione multizona, è possibile ottenere in una zona la flessibilità della cronologia degli oggetti S3 risparmiando al contempo spazio che verrà utilizzato nelle zone rimanenti dalle repliche degli oggetti S3 con versione.

21.8.5.1 Configurazione del modulo di sincronizzazione degli archivi

Suggerimento
Suggerimento: maggiori informazioni

Fare riferimento alla Sezione 21.13, «Object Gateway multisito» per i dettagli sulla configurazione dei gateway multisito.

Fare riferimento alla Sezione 21.8, «Moduli di sincronizzazione» per i dettagli sulla configurazione dei moduli di sincronizzazione.

Per utilizzare il modulo di sincronizzazione degli archivi, occorre creare una nuova zona con tipo di livello impostato su archive:

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \
 --rgw-zone=OGW_ZONE_NAME \
 --endpoints=http://OGW_ENDPOINT1_URL[,http://OGW_ENDPOINT2_URL,...]
 --tier-type=archive

21.9 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.

21.9.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.

21.9.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
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
Suggerimento: test di integrità

Utilizzare l'utility ldapsearch per verificare l'account di servizio o la connessione LDAP. 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.

21.9.3 Configurazione di Object Gateway per utilizzare l'autenticazione LDAP

I seguenti parametri sono correlati all'autenticazione LDAP:

rgw_s3_auth_use_ldap

Impostare questa opzione su true per abilitare l'autenticazione S3 con LDAP.

rgw_ldap_uri

Specifica il server LDAP da utilizzare. Assicurarsi di utilizzare il parametro ldaps://FQDN:PORT per evitare di trasmettere apertamente le 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 21.9.4, «Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti» per ulteriori informazioni.

21.9.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.

21.9.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.

21.9.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
Nota: attributo memberOf

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

21.9.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 21.5.1, «Accesso a Object Gateway»), specificare il token come chiave di accesso e utilizzare una chiave segreta vuota.

> export RGW_ACCESS_KEY_ID="USERNAME"
> export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap
Importante
Importante: credenziali non cifrate

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

Nota
Nota: Active Directory

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

21.10 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.

21.10.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 automatico dell'indice del compartimento online (fare riferimento alla Sezione 21.10.1.1, «Ripartizionamento dinamico») o eseguire manualmente il ripartizionamento dell'indice del compartimento offline (fare riferimento alla Sezione 21.10.1.2, «Ripartizionamento manuale»).

21.10.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.

Comandi per amministrare il processo di ripartizionamento
Aggiungere un compartimento alla coda di ripartizionamento:
cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Elencare la coda di ripartizionamento:
cephuser@adm > radosgw-admin reshard list
Elaborare/pianificare un ripartizionamento del compartimento:
cephuser@adm > radosgw-admin reshard process
Visualizzare lo stato di ripartizionamento del compartimento:
cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME
Annullare il ripartizionamento del compartimento in sospeso:
cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 Ripartizionamento manuale

Il ripartizionamento dinamico di cui alla Sezione 21.10.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:

cephuser@adm > 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 di questi oggetti di 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.

Suggerimento
Suggerimento

Quando si sceglie il numero di partizionamenti, non superare le 100.000 voci per partizionamento. I partizionamenti dell'indice del compartimento corrispondenti a numeri primi tendono a funzionare meglio in voci dell'indice del compartimento distribuite uniformemente nei partizionamenti. Ad esempio, invece di impostare 500 partizionamenti dell'indice del compartimento, è consigliabile impostarne 503, dal momento che questo è un numero primo.

Procedura 21.1: Ripartizionamento dell'indice del compartimento
  1. Assicurarsi che tutte le operazioni nel compartimento vengano interrotte

  2. Eseguire il backup dell'indice del compartimento originale:

    cephuser@adm > radosgw-admin bi list \
     --bucket=BUCKET_NAME \
     > BUCKET_NAME.list.backup
  3. Eseguire il ripartizionamento dell'indice del compartimento:

     cephuser@adm > radosgw-admin bucket reshard \
     --bucket=BUCKET_NAME \
     --num-shards=NEW_SHARDS_NUMBER
    Suggerimento
    Suggerimento: ID compartimento precedente

    Come parte del rispettivo output, questo comando consente inoltre di stampare l'ID compartimento nuovo e quello precedente.

21.10.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.

21.10.2.1 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:

  1. Esportare la configurazione del gruppo di zone nel file zonegroup.json:

    cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
  2. Modificare il file zonegroup.json e impostare l'opzione bucket_index_max_shards per ciascuna zona con nome.

  3. Reimpostare il gruppo di zone:

    cephuser@adm > radosgw-admin zonegroup set < zonegroup.json
  4. Aggiornare il periodo. Vedere Sezione 21.13.2.6, «Aggiornare il periodo».

21.11 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.

21.11.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:

  1. Impostare il servizio Swift. Prima di poter utilizzare OpenStack per la convalida degli utenti Swift, creare il servizio Swift:

    > openstack service create \
     --name=swift \
     --description="Swift Service" \
     object-store
  2. 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.

    > 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
  3. Verificare le impostazioni. Dopo aver creato il servizio Swift e impostati gli endpoint, visualizzare questi ultimi per verificare che tutte le impostazioni siano corrette.

    > openstack endpoint show object-store

21.11.2 Configurazione di Ceph Object Gateway

21.11.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:

# mkdir /var/ceph/nss
# 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"

Per consentire l'interazione tra Ceph Object Gateway e OpenStack Keystone, quest'ultimo può utilizzare un certificato SSL firmato da se stessi. 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.

21.11.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 2.0 di OpenStack Identity API) in modo simile a quanto avviene per la configurazione dei servizi OpenStack. In tal modo, è possibile 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 di 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 diversi ruoli, 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
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 a 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.

21.12 Posizionamento di pool e classi di storage

21.12.1 Visualizzazione delle destinazioni di posizionamento

Le destinazioni di posizionamento consentono di controllare quali pool sono associati a un determinato compartimento. La destinazione di posizionamento di un compartimento viene selezionata al momento della creazione e non può essere modificata. Per visualizzare la regola placement_rule corrispondente, utilizzare il comando seguente:

cephuser@adm > radosgw-admin bucket stats

La configurazione del gruppo di zone contiene un elenco di destinazioni di posizionamento con una destinazione iniziale denominata "default-placement". La configurazione della zona mappa quindi ogni nome della destinazione di posizionamento del gruppo di zone allo storage locale corrispondente. Queste informazioni sul posizionamento della zona includono il nome "index_pool" per l'indice del compartimento, il nome "data_extra_pool" per i metadati relativi agli upload multipart incompleti e il nome "data_pool" per ogni classe di storage.

21.12.2 Classi di storage

Le classi di storage agevolano la personalizzazione del posizionamento dei dati di oggetto. Le regole di S3 Bucket Lifecycle consentono di automatizzare la transizione degli oggetti tra le classi di storage.

Le classi di storage vengono definite in termini di destinazioni di posizionamento. Per ogni destinazione di posizionamento del gruppo di zone sono elencate le relative classi di storage disponibili con una classe iniziale denominata "STANDARD". La configurazione della zona specifica il nome di pool "data_pool" per ciascuna delle classi di storage del gruppo di zone.

21.12.3 Configurazione dei gruppi di zone e delle zone

Per configurare il posizionamento dei gruppi di zone e delle zone, utilizzare il comando radosgw-admin. È possibile interrogare la configurazione del posizionamento del gruppo di zone tramite il comando seguente:

cephuser@adm > radosgw-admin zonegroup get
{
    "id": "ab01123f-e0df-4f29-9d71-b44888d67cd5",
    "name": "default",
    "api_name": "default",
    ...
    "placement_targets": [
        {
            "name": "default-placement",
            "tags": [],
            "storage_classes": [
                "STANDARD"
            ]
        }
    ],
    "default_placement": "default-placement",
    ...
}

Per interrogare la configurazione del posizionamento della zona, eseguire:

cephuser@adm > radosgw-admin zone get
{
    "id": "557cdcee-3aae-4e9e-85c7-2f86f5eddb1f",
    "name": "default",
    "domain_root": "default.rgw.meta:root",
    ...
    "placement_pools": [
        {
            "key": "default-placement",
            "val": {
                "index_pool": "default.rgw.buckets.index",
                "storage_classes": {
                    "STANDARD": {
                        "data_pool": "default.rgw.buckets.data"
                    }
                },
                "data_extra_pool": "default.rgw.buckets.non-ec",
                "index_type": 0
            }
        }
    ],
    ...
}
Nota
Nota: nessuna configurazione multisito precedente

Se in precedenza non è stata effettuata nessuna configurazione multisito, vengono creati un gruppo di zone e una zona "default" per l'utente e le relative modifiche apportate non saranno effettive fino al riavvio di Ceph Object Gateway. Se è stato creato un dominio per la configurazione multisito, le modifiche alla zona/al gruppo di zone verranno applicate dopo averle confermate tramite il comando radosgw-admin period update --commit.

21.12.3.1 Aggiunta di una destinazione di posizionamento

Per creare una nuova destinazione di posizionamento denominata "temporary", iniziare aggiungendola al gruppo di zone:

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id temporary

Quindi, fornire le informazioni sul posizionamento della zona per la destinazione specificata:

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id temporary \
      --data-pool default.rgw.temporary.data \
      --index-pool default.rgw.temporary.index \
      --data-extra-pool default.rgw.temporary.non-ec

21.12.3.2 Aggiunta di una classe di storage

Per aggiungere una nuova classe di storage denominata "COLD" alla destinazione "default-placement", iniziare aggiungendola al gruppo di zone:

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id default-placement \
      --storage-class COLD

Quindi, fornire le informazioni sul posizionamento della zona per la classe di storage specificata:

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id default-placement \
      --storage-class COLD \
      --data-pool default.rgw.cold.data \
      --compression lz4

21.12.4 Personalizzazione del posizionamento

21.12.4.1 Modifica del posizionamento del gruppo di zone di default

Per default, i nuovi compartimenti utilizzeranno la destinazione default_placement del gruppo di zone. È possibile modificare questa impostazione del gruppo di zone con quanto segue:

cephuser@adm > radosgw-admin zonegroup placement default \
      --rgw-zonegroup default \
      --placement-id new-placement

21.12.4.2 Modifica del posizionamento dell'utente di default

Gli utenti di Ceph Object Gateway possono sostituire la destinazione di posizionamento di default del gruppo di zone impostando un campo default_placement non vuoto nella sezione delle informazioni utente. Analogamente, la classe default_storage_class può sostituire la classe di storage STANDARD applicata per default agli oggetti.

cephuser@adm > radosgw-admin user info --uid testid
{
    ...
    "default_placement": "",
    "default_storage_class": "",
    "placement_tags": [],
    ...
}

Se la destinazione di posizionamento di un gruppo di zone contiene tag, gli utenti non potranno creare compartimenti con questa destinazione, a meno che le relative informazioni non contengano almeno un tag corrispondente nel campo "placement_tags". Ciò può essere utile per limitare l'accesso a determinati tipi di storage.

Poiché il comando radosgw-admin non è in grado di modificare direttamente questi campi, è necessario modificare manualmente il formato JSON:

cephuser@adm > radosgw-admin metadata get user:USER-ID > user.json
> vi user.json     # edit the file as required
cephuser@adm > radosgw-admin metadata put user:USER-ID < user.json

21.12.4.3 Modifica del posizionamento del compartimento S3 di default

Durante la creazione di un compartimento con il protocollo S3, è possibile specificare una destinazione di posizionamento come parte del LocationConstraint al fine di sostituire le destinazioni di posizionamento di default per l'utente e il gruppo di zone.

In genere, il LocationConstraint deve corrispondere all'api_name del gruppo di zone:

<LocationConstraint>default</LocationConstraint>

È possibile aggiungere una destinazione di posizionamento personalizzata all'api_name dopo i due punti:

<LocationConstraint>default:new-placement</LocationConstraint>

21.12.4.4 Modifica del posizionamento del compartimento Swift

Durante la creazione di un compartimento con il protocollo Swift, è possibile specificare una destinazione di posizionamento nell'X-Storage-Policy dell'intestazione HTTP:

X-Storage-Policy: NEW-PLACEMENT

21.12.5 Utilizzo delle classi di storage

Tutte le destinazioni di posizionamento dispongono di una classe di storage STANDARD che viene applicata per default ai nuovi oggetti. È possibile sostituire questa classe di default con la relativa default_storage_class.

Per creare un oggetto in una classe di storage non di default, specificare il nome di tale classe in un'intestazione HTTP insieme alla richiesta. Il protocollo S3 utilizza l'intestazione X-Amz-Storage-Class, mentre il protocollo Swift utilizza l'intestazione X-Object-Storage-Class.

È possibile utilizzare S3 Object Lifecycle Management per spostare i dati degli oggetti tra le classi di storage con le azioni Transition.

21.13 Object Gateway multisito

Ceph supporta diverse opzioni di configurazione multisito per Ceph Object Gateway:

Multizona

Configurazione composta da un gruppo di zone e da più zone, ognuna delle quali con una o più istanze ceph-radosgw. Ogni zona è supportata dal relativo cluster di memorizzazione Ceph. Le zone multiple all'interno di un gruppo di zone forniscono funzionalità di disaster recovery a quest'ultimo, se dovesse verificarsi un grave errore in una delle zone. Ogni zona è attiva e può ricevere operazioni di scrittura. Oltre alle funzioni di disaster recovery, più zone attive possono fungere anche da base per le reti per la consegna di contenuto.

Gruppo multizona

Ceph Object Gateway supporta più gruppi di zone, ciascuno costituito da una o più zone. Gli oggetti memorizzati nelle zone di un gruppo di zone all'interno dello stesso dominio di un altro gruppo di zone condividono uno spazio dei nomi di oggetto globale, per fare in modo che gli ID oggetto delle zone e dei gruppi di zone siano univoci.

Nota
Nota

È importante tenere presente che i gruppi di zone sincronizzano i metadati soltanto tra di loro. I dati e i metadati vengono replicati tra le zone all'interno del gruppo di zone e non vengono condivisi nel dominio.

Domini multipli

Ceph Object Gateway supporta la nozione dei domini, ovvero uno spazio dei nomi univoco a livello globale. I domini multipli sono supportati e possono contenere uno o più gruppi di zone.

È possibile configurare ciascun Object Gateway per l'esecuzione in una configurazione della zona attiva-attiva, al fine di consentire le operazioni di scrittura nelle zone non master. La configurazione multisito è memorizzata all'interno di un container denominato dominio. Il dominio memorizza gruppi di zone, zone e un intervallo di tempo con più epoche per il monitoraggio delle modifiche apportate alla configurazione. I daemon rgw gestiscono la sincronizzazione eliminando la necessità di utilizzare un agente di sincronizzazione separato. Questo approccio alla sincronizzazione consente il funzionamento di Ceph Object Gateway con una configurazione attiva-attiva invece che attiva-passiva.

21.13.1 Requisiti e presupposti

Per una configurazione multisito sono necessari almeno due cluster di memorizzazione Ceph e almeno due istanze di Ceph Object Gateway, una per ogni cluster di memorizzazione Ceph. Nella configurazione riportata di seguito si presuppone la presenza di almeno due cluster di memorizzazione Ceph in ubicazioni geograficamente separate. Tuttavia, la configurazione può funzionare nello stesso sito. Ad esempio, le zone denominate rgw1 e rgw2.

Per la configurazione multisito sono necessari un gruppo di zone master e una zona master, che sarà l'origine di riferimento per quanto riguarda tutte le operazioni dei metadati in un cluster multisito. Inoltre, ogni gruppo di zone deve contenere una zona master. I gruppi di zone possono avere una o più zone non master o secondarie. Nella presente guida, l'host rgw1 funge da zona master del gruppo di zone master e l'host rgw2 funge da zona secondaria del gruppo di zone master.

21.13.2 Configurazione di una zona master

Tutti i gateway di una configurazione multisito recuperano la rispettiva configurazione da un daemon ceph-radosgw su un host all'interno del gruppo di zone master e della zona master. Per configurare i gateway in una configurazione multisito, selezionare un'istanza ceph-radosgw per configurare il gruppo di zone master e la zona master.

21.13.2.1 Creazione di un dominio

Un dominio rappresenta uno spazio dei nomi univoco a livello globale composto da uno o più gruppi di zone contenenti una o più zone. Le zone contengono i compartimenti, che a loro volta contengono gli oggetti. Tramite i domini, Ceph Object Gateway può supportare più spazi dei nomi e le relative configurazioni sullo stesso hardware. Un dominio contiene la nozione dei periodi. Ogni periodo rappresenta lo stato della configurazione del gruppo di zone e della zona nel tempo. Ogni volta che si apporta una modifica a un gruppo di zone o a una zona, aggiornare il periodo ed eseguirne il commit. Per default, Ceph Object Gateway non crea domini per la compatibilità con le versioni precedenti. Come best practice, si consiglia di creare i domini per i nuovi cluster.

Creare un nuovo dominio denominato gold per la configurazione multisito aprendo l'interfaccia della riga di comando su un host da utilizzare nel gruppo di zone e nella zona master. Quindi, eseguire quanto riportato di seguito:

cephuser@adm > radosgw-admin realm create --rgw-realm=gold --default

Se il cluster dispone di un dominio singolo, specificare il flag --default. Se il flag --default è specificato, radosgw-admin utilizza per default questo dominio. Se il flag --default non è specificato, per aggiungere gruppi di zone e zone occorre specificare i flag --rgw-realm o ‑‑realm-id per identificare il dominio durante l'aggiunta di gruppi di zone e zone.

In seguito alla creazione del dominio, radosgw-admin ne restituisce la configurazione:

{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}
Nota
Nota

Ceph genera un ID univoco per il dominio, che ne consente la ridenominazione in caso di necessità.

21.13.2.2 Creazione di un gruppo di zone master

All'interno di un dominio deve essere presente almeno un gruppo di zone che funge da gruppo di zone master del dominio stesso. Creare un nuovo gruppo di zone master per la configurazione multisito aprendo l'interfaccia della riga di comando su un host da utilizzare nel gruppo di zone e nella zona master. Creare un gruppo di zone master denominato us eseguendo quanto riportato di seguito:

cephuser@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default

Se il dominio dispone di un singolo gruppo di zone, specificare il flag --default. Se il flag --default è specificato, radosgw-admin utilizza per default questo gruppo di zone per l'aggiunta di nuove zone. Se il flag --default non è specificato, per aggiungere le zone occorre specificare i flag --rgw-zonegroup o --zonegroup-id per identificare il gruppo di zone durante l'aggiunta o la modifica delle zone.

In seguito alla creazione del gruppo di zone master, radosgw-admin ne restituisce la configurazione: Esempio:

{
 "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"
}

21.13.2.3 Creazione di una zona master

Importante
Importante

Le zone devono essere create su un nodo Ceph Object Gateway che si trova all'interno della zona.

Creare una nuova zona master per la configurazione multisito aprendo l'interfaccia della riga di comando su un host da utilizzare nel gruppo di zone e nella zona master. Eseguire le operazioni seguenti:

cephuser@adm > 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
Nota
Nota

Le opzioni --access-key e --secret non sono specificate nell'esempio precedente e vengono aggiunte alla zona al momento della creazione dell'utente nella sezione successiva.

In seguito alla creazione della zona master, radosgw-admin ne restituisce la configurazione. Esempio:

  {
      "id": "56dfabbb-2f4e-4223-925e-de3c72de3866",
      "name": "us-east-1",
      "domain_root": "us-east-1.rgw.meta:root",
      "control_pool": "us-east-1.rgw.control",
      "gc_pool": "us-east-1.rgw.log:gc",
      "lc_pool": "us-east-1.rgw.log:lc",
      "log_pool": "us-east-1.rgw.log",
      "intent_log_pool": "us-east-1.rgw.log:intent",
      "usage_log_pool": "us-east-1.rgw.log:usage",
      "reshard_pool": "us-east-1.rgw.log:reshard",
      "user_keys_pool": "us-east-1.rgw.meta:users.keys",
      "user_email_pool": "us-east-1.rgw.meta:users.email",
      "user_swift_pool": "us-east-1.rgw.meta:users.swift",
      "user_uid_pool": "us-east-1.rgw.meta:users.uid",
      "otp_pool": "us-east-1.rgw.otp",
      "system_key": {
          "access_key": "1555b35654ad1656d804",
          "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
      },
      "placement_pools": [
          {
              "key": "us-east-1-placement",
              "val": {
                  "index_pool": "us-east-1.rgw.buckets.index",
                  "storage_classes": {
                      "STANDARD": {
                          "data_pool": "us-east-1.rgw.buckets.data"
                      }
                  },
                  "data_extra_pool": "us-east-1.rgw.buckets.non-ec",
                  "index_type": 0
              }
          }
      ],
      "metadata_heap": "",
      "realm_id": ""
  }

21.13.2.4 Eliminazione del gruppo e della zona di default

Importante
Importante

Nella procedura seguente si presuppone che sia stata eseguita una configurazione multisito tramite i sistemi appena installati che non hanno ancora iniziato a memorizzare i dati. Non eliminare la zona di default e i relativi pool se la si utilizza già per memorizzare i dati, altrimenti questi verranno eliminati e non sarà più possibile recuperarli.

L'installazione di default di Object Gateway crea un gruppo di zone di default denominato default. Eliminare la zona di default se presente. Rimuoverla innanzitutto dal gruppo di zone di default.

cephuser@adm > radosgw-admin zonegroup delete --rgw-zonegroup=default

Eliminare i pool di default dal cluster di memorizzazione Ceph, se presenti:

Importante
Importante

Nel passaggio seguente si presuppone che sia stata eseguita una configurazione multisito tramite i sistemi appena installati che non hanno ancora iniziato a memorizzare i dati. Non eliminare il gruppo di zone di default se lo si utilizza già per memorizzare i dati.

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
Avvertimento
Avvertimento

Se il gruppo di zone di default viene eliminato, verrà eliminato anche l'utente del sistema. Se le chiavi dell'utente amministratore non vengono propagate, la funzionalità di gestione di Object Gateway del Ceph Dashboard restituirà un errore. Andare alla sezione successiva per ricreare l'utente di sistema se si procede con questo passaggio.

21.13.2.5 Creazione di utenti di sistema

I daemon ceph-radosgw devono eseguire l'autenticazione prima di eseguire il pull delle informazioni sul dominio e sul periodo. Nella zona master, creare un utente di sistema per semplificare l'autenticazione tra i daemon:

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

Annotare le variabili access_key e secret_key, poiché saranno necessarie per l'autenticazione delle zone secondarie nella zona master.

Aggiungere l'utente di sistema alla zona master:

cephuser@adm > radosgw-admin zone modify --rgw-zone=us-east-1 \
--access-key=ACCESS-KEY --secret=SECRET

Aggiornare il periodo per applicare le modifiche:

cephuser@adm > radosgw-admin period update --commit

21.13.2.6 Aggiornare il periodo

Dopo aver aggiornato la configurazione della zona master, aggiornare il periodo:

cephuser@adm > radosgw-admin period update --commit

In seguito all'aggiornamento del periodo, radosgw-admin ne restituisce la configurazione. Esempio:

{
  "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
}
Nota
Nota

Tramite l'aggiornamento del periodo viene modificata l'epoca e ci si assicura che le altre zone ricevano la configurazione aggiornata.

21.13.2.7 Avvio di Gateway

Sull'host di Object Gateway, avviare e abilitare il servizio Ceph Object Gateway. Per identificare l'FSID univoco del cluster, eseguire ceph fsid. Per identificare il nome del daemon di Object Gateway, eseguire ceph orch ps --hostname HOSTNAME.

cephuser@ogw > systemctl start ceph-FSID@DAEMON_NAME
cephuser@ogw > systemctl enable ceph-FSID@DAEMON_NAME

21.13.3 Configurazione delle zone secondarie

Le zone all'interno di un gruppo di zone replicano tutti i dati per fare in modo che in ogni zona siano presenti gli stessi dati. Durante la creazione di una zona secondaria, effettuare tutte le operazioni seguenti su un host identificato per servire tale zona.

Nota
Nota

Per aggiungere una terza zona, attenersi alle stesse procedure seguite per l'aggiunta della zona secondaria. Utilizzare un nome diverso per la zona.

Importante
Importante

Le operazioni dei metadati, come la creazione di un utente, devono essere eseguite su un host all'interno della zona master. La zona master e la zona secondaria possono ricevere le operazioni dei compartimenti, ma la zona secondaria reindirizza tali operazioni alla zona master. Se la zona master è inattiva, le operazioni dei compartimenti non andranno a buon fine.

21.13.3.1 Esecuzione del pull del dominio

Utilizzando il percorso URL, la chiave di accesso e il segreto della zona master nel gruppo di zone master, importare la configurazione del dominio nell'host. Per importare un dominio non di default, specificare il dominio tramite le opzioni di configurazione --rgw-realm o --realm-id.

cephuser@adm > radosgw-admin realm pull --url=url-to-master-zone-gateway --access-key=access-key --secret=secret
Nota
Nota

Tramite l'importazione del dominio viene recuperata anche la configurazione corrente del periodo, che viene contrassegnato come attuale anche sull'host remoto.

Se questo dominio è il dominio di default o l'unico dominio, contrassegnarlo come dominio di default.

cephuser@adm > radosgw-admin realm default --rgw-realm=REALM-NAME

21.13.3.2 Creazione di una zona secondaria

Creare una zona secondaria per la configurazione multisito aprendo l'interfaccia della riga di comando su un host da utilizzare nella zona secondaria. Specificare l'ID del gruppo di zone, il nome della nuova zona e l'endpoint corrispondente. Non utilizzare il flag --master. Per default, tutte le zone vengono eseguite in una configurazione attiva-attiva. Se la zona secondaria non deve accettare le operazioni di scrittura, specificare il flag --read-only per creare una configurazione attiva-passiva tra la zona master e la zona secondaria. Inoltre, specificare le variabili access_key e secret_key dell'utente di sistema generato memorizzate nella zona master del gruppo di zone master. Eseguire le operazioni seguenti:

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME\
 --rgw-zone=ZONE-NAME --endpoints=URL \
 --access-key=SYSTEM-KEY --secret=SECRET\
 --endpoints=http://FQDN:80 \
 [--read-only]

Esempio:

cephuser@adm > 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"
}
Importante
Importante

Nei passaggi seguenti si presuppone che sia stata eseguita una configurazione multisito tramite i sistemi appena installati che non hanno ancora iniziato a memorizzare i dati. Non eliminare la zona di default e i relativi pool se la si utilizza già per memorizzare i dati, altrimenti questi andranno persi e non sarà più possibile recuperarli.

Eliminare la zona di default se necessario:

cephuser@adm > radosgw-admin zone delete --rgw-zone=default

Eliminare i pool di default dal cluster di memorizzazione Ceph se necessario:

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

21.13.3.3 Aggiornamento del file di configurazione Ceph

Aggiornare il file di configurazione Ceph sugli host della zona secondaria aggiungendo l'opzione di configurazione rgw_zone e il nome della zona secondaria alla voce dell'istanza.

Per farlo, eseguire il comando seguente:

cephuser@adm > ceph config set SERVICE_NAME rgw_zone us-west

21.13.3.4 Aggiornamento del periodo

Dopo aver aggiornato la configurazione della zona master, aggiornare il periodo:

cephuser@adm > 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
}
Nota
Nota

Tramite l'aggiornamento del periodo viene modificata l'epoca e ci si assicura che le altre zone ricevano la configurazione aggiornata.

21.13.3.5 Avvio di Object Gateway

Sull'host di Object Gateway, avviare e abilitare il servizio Ceph Object Gateway:

cephuser@adm > ceph orch start rgw.us-east-2

21.13.3.6 Verifica dello stato di sincronizzazione

Una volta configurata la zona secondaria, verificare lo stato di sincronizzazione. La sincronizzazione copia nella zona secondaria gli utenti e i compartimenti creati nella zona master.

cephuser@adm > radosgw-admin sync status

L'output fornisce lo stato delle operazioni di sincronizzazione. Esempio:

realm f3239bc5-e1a8-4206-a81d-e1576480804d (gold)
    zonegroup c50dbb7e-d9ce-47cc-a8bb-97d9b399d388 (us)
         zone 4c453b70-4a16-4ce8-8185-1893b05d346e (us-west)
metadata sync syncing
              full sync: 0/64 shards
              metadata is caught up with master
              incremental sync: 64/64 shards
    data sync source: 1ee9da3e-114d-4ae3-a8a4-056e8a17f532 (us-east)
                      syncing
                      full sync: 0/128 shards
                      incremental sync: 128/128 shards
                      data is caught up with source
Nota
Nota

Le zone secondarie accettano le operazioni dei compartimenti; tuttavia, le reindirizzano alla zona master ed eseguono la sincronizzazione con quest'ultima per ricevere i risultati di tali operazioni. Se la zona master è inattiva, le operazioni dei compartimenti eseguite sulla zona secondaria non andranno a buon fine, ma le operazioni degli oggetti riusciranno correttamente.

21.13.3.7 Verifica di un oggetto

Per default, dopo che la sincronizzazione di un oggetto è riuscita non viene eseguita una nuova verifica degli oggetti. Per abilitare la verifica, impostare l'opzione rgw_sync_obj_etag_verify su true. Dopo l'abilitazione, gli oggetti facoltativi verranno sincronizzati. Un ulteriore checksum MD5 verificherà che il calcolo sia effettuato sull'origine e sulla destinazione. Questo consente di assicurare l'integrità degli oggetti recuperati da un server remoto su HTTP, inclusa la sincronizzazione multisito. L'opzione può ridurre le prestazioni degli RGW poiché è necessaria maggiore potenza di calcolo.

21.13.4 Manutenzione generale di Object Gateway

21.13.4.1 Verifica dello stato di sincronizzazione

È possibile interrogare le informazioni sullo stato della replica di una zona con:

cephuser@adm > radosgw-admin sync status
        realm b3bc1c37-9c44-4b89-a03b-04c269bea5da (gold)
    zonegroup f54f9b22-b4b6-4a0e-9211-fa6ac1693f49 (us)
         zone adce11c9-b8ed-4a90-8bc5-3fc029ff0816 (us-west)
        metadata sync syncing
              full sync: 0/64 shards
              incremental sync: 64/64 shards
              metadata is behind on 1 shards
              oldest incremental change not applied: 2017-03-22 10:20:00.0.881361s
data sync source: 341c2d81-4574-4d08-ab0f-5a2a7b168028 (us-east)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source
          source: 3b5d1a3f-3f27-4e4a-8f34-6072d4bb1275 (us-3)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source

L'output può variare a seconda dello stato di sincronizzazione. Durante la sincronizzazione, i partizionamenti sono descritti come di due tipi diversi:

Partizionamenti arretrati

I partizionamenti arretrati sono quelli che richiedono una sincronizzazione completa dei dati e quelli che richiedono una sincronizzazione dei dati incrementale perché non sono aggiornati.

Partizionamenti di ripristino

I partizionamenti di ripristino sono quelli contrassegnati per un nuovo tentativo, poiché presentano un errore durante la sincronizzazione. L'errore riguarda principalmente problemi minori, come l'acquisizione di un blocco su un compartimento, e in genere si risolve da sé.

21.13.4.2 Controllo dei log

Solo per la configurazione multisito, è possibile controllare il log dei metadati (mdlog), il log dell'indice del compartimento (bilog) e il log dei dati (datalog). È possibile elencarli e troncarli. Nella maggior parte dei casi, l'operazione non è necessaria poiché l'opzione rgw_sync_log_trim_interval è impostata per default a 20 minuti. Se l'opzione non è impostata manualmente su 0, non sarà mai necessario effettuare la troncatura, che può causare effetti collaterali.

21.13.4.3 Modifica della zona dei metadata master

Importante
Importante

Prestare la massima attenzione quando si modifica la zona dei metadata master. Se una zona non ha terminato la sincronizzazione dei metadati dalla zona master corrente, non sarà in grado di servire alcuna voce rimanente quando viene promossa al ruolo di master e queste modifiche andranno perse. Per questo motivo, prima di promuoverla come master, si consiglia di attendere che lo stato di sincronizzazione radosgw-admin della zona raggiunga lo stesso livello della sincronizzazione dei metadati. Analogamente, se le modifiche ai metadati sono in corso di elaborazione nella zona master corrente, mentre è in corso la promozione di un'altra zona al ruolo di master, è probabile che queste modifiche andranno perse. Per evitarlo, si consiglia di disattivare le istanze di Object Gateway sulla zona master precedente. In seguito alla promozione di un'altra zona, il rispettivo nuovo periodo può essere recuperato con il pull del periodo di radosgw-admin ed è possibile riavviare i gateway.

Per promuovere una zona (ad esempio, la zona us-west nel gruppo di zone us) a metadata master, eseguire i comandi seguenti su tale zona:

cephuser@ogw > radosgw-admin zone modify --rgw-zone=us-west --master
cephuser@ogw > radosgw-admin zonegroup modify --rgw-zonegroup=us --master
cephuser@ogw > radosgw-admin period update --commit

In questo modo viene generato un nuovo periodo che verrà inviato ad altre zone dalle istanze di Object Gateway nella zona us-west.

21.13.5 Esecuzione del failover e del disaster recovery

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

  1. Rendere la zona secondaria la zona master e di default. Esempio:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default

    Per default, Ceph Object Gateway viene 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-only per consentire alla zona di ricevere le operazioni di scrittura. Esempio:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                       --read-only=false
  2. Aggiornare il periodo per applicare le modifiche:

    cephuser@adm > radosgw-admin period update --commit
  3. Riavviare Ceph Object Gateway:

    cephuser@adm > ceph orch restart rgw

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

  1. Dalla zona recuperata, eseguire il pull della configurazione del dominio più recente dall'attuale zona master.

    cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                               --access-key=ACCESS-KEY --secret=SECRET
  2. Rendere la zona recuperata la zona master e di default:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
  3. Aggiornare il periodo per applicare le modifiche:

    cephuser@adm > radosgw-admin period update --commit
  4. Riavviare Ceph Object Gateway nella zona recuperata:

    cephuser@adm > ceph orch restart rgw@rgw
  5. Se la configurazione della zona secondaria deve essere in sola lettura, aggiornare la zona secondaria:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
  6. Aggiornare il periodo per applicare le modifiche:

    cephuser@adm > radosgw-admin period update --commit
  7. Riavviare Ceph Object Gateway nella zona secondaria:

    cephuser@adm > ceph orch restart@rgw