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.
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».
Installare il pacchetto
python-boto
:#
zypper in python-botoCreare 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 esempiogateway_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
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:
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=EMAILEsempio:
cephuser@adm >
radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ --email=penguin@example.comPer 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=fullGenerare una chiave segreta per l'utente.
cephuser@adm >
radosgw-admin key create \ --gen-secret \ --subuser=example_user:swift \ --key-type=swiftL'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.
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
os3
.--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
euser
. 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 #
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.
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: indirizzi IP insubjectAltName
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
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.pemAggiungere 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
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.
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 #
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È 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}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=1Per le varie opzioni tier-config supportate, fare riferimento a Sezione 21.8.3, «Modulo di sincronizzazione ElasticSearch».
Infine, aggiornare il periodo
cephuser@adm >
radosgw-admin
period update --commitAdesso, 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.
{ "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, }
{ "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 #
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.
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.
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
ocn
.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))"
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
Il token di accesso è una struttura JSON codificata base-64 e contiene le credenziali LDAP non cifrate.
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.
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.
- 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.
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.
Assicurarsi che tutte le operazioni nel compartimento vengano interrotte
Eseguire il backup dell'indice del compartimento originale:
cephuser@adm >
radosgw-admin bi list \ --bucket=BUCKET_NAME \ > BUCKET_NAME.list.backupEseguire il ripartizionamento dell'indice del compartimento:
cephuser@adm >
radosgw-admin bucket reshard \ --bucket=BUCKET_NAME \ --num-shards=NEW_SHARDS_NUMBERSuggerimento: ID compartimento precedenteCome 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:
Esportare la configurazione del gruppo di zone nel file
zonegroup.json
:cephuser@adm >
radosgw-admin zonegroup get > zonegroup.jsonModificare il file
zonegroup.json
e impostare l'opzionebucket_index_max_shards
per ciascuna zona con nome.Reimpostare il gruppo di zone:
cephuser@adm >
radosgw-admin zonegroup set < zonegroup.jsonAggiornare 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:
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-storeImpostare 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" \ swiftVerificare 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"root
openssl 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
.
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
}
}
],
...
}
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 requiredcephuser@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È 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 }
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 #
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
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 #
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:
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-itcephuser@adm >
ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-itcephuser@adm >
ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-itcephuser@adm >
ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-itcephuser@adm >
ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
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 }
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_NAMEcephuser@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.
Per aggiungere una terza zona, attenersi alle stesse procedure seguite per l'aggiunta della zona secondaria. Utilizzare un nome diverso per la zona.
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
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"
}
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-itcephuser@adm >
ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-itcephuser@adm >
ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-itcephuser@adm >
ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-itcephuser@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
}
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
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 #
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 --mastercephuser@ogw >
radosgw-admin zonegroup modify --rgw-zonegroup=us --mastercephuser@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.
Rendere la zona secondaria la zona master e di default. Esempio:
cephuser@adm >
radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --defaultPer 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=falseAggiornare il periodo per applicare le modifiche:
cephuser@adm >
radosgw-admin period update --commitRiavviare Ceph Object Gateway:
cephuser@adm >
ceph orch restart rgw
Se la zona master precedente viene recuperata, ripristinare l'operazione.
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=SECRETRendere la zona recuperata la zona master e di default:
cephuser@adm >
radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --defaultAggiornare il periodo per applicare le modifiche:
cephuser@adm >
radosgw-admin period update --commitRiavviare Ceph Object Gateway nella zona recuperata:
cephuser@adm >
ceph orch restart rgw@rgwSe 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-onlyAggiornare il periodo per applicare le modifiche:
cephuser@adm >
radosgw-admin period update --commitRiavviare Ceph Object Gateway nella zona secondaria:
cephuser@adm >
ceph orch restart@rgw