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.
Di seguito è riportato un elenco di importanti limiti Object Gateway:
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.
Per default, nessuna restrizione (limite definito da ~ 2^63).
Per default, nessuna restrizione (limite definito da ~ 2^63).
Gli upload singoli sono limitati a 5 GB. Utilizzare multipart per dimensioni grandi degli oggetti. Il numero massimo di porzioni multipart è 10000.
L'intestazione HTTP e il limite di richiesta dipendono dalla front-end Web utilizzata. CivetWeb di default limita il numero di intestazioni HTTP a 64 e le dimensioni dell'intestazione HTTP a 16 kB.
Il metodo di distribuzione consigliato per Ceph Object Gateway è tramite l'infrastruttura DeepSea aggiungendo le righe role-rgw [...]
pertinenti nel file policy.cfg
sul Salt master ed eseguendo le fasi DeepSea richieste.
Per includere Object Gateway durante il processo di distribuzione del cluster Ceph, fare riferimento a Sezione 4.3, «Distribuzione del cluster» e Sezione 4.5.1, «Il file policy.cfg
».
Per aggiungere il ruolo Object Gateway a un cluster già distribuito, fare riferimento a Sezione 1.2, «Aggiunta di nuovi ruoli ai nodi».
Il servizio Object Gateway viene attivato con il comando systemctl
. Per attivare il servizio Object Gateway è necessario disporre dei diritti root
. gateway_host è il nome host del server di cui è necessario attivare l'istanza Object Gateway.
Per il servizio Object Gateway sono supportati i seguenti comandi:
Stampa le informazioni sullo stato del servizio.
Avvia il servizio nel caso non sia già in esecuzione.
Riavvia il servizio.
Interrompe il servizio in esecuzione.
Abilita il servizio in modo che venga avviato automaticamente all'avvio del sistema.
Disabilita il servizio in modo che non venga avviato automaticamente all'avvio del sistema.
Il comportamento di Object Gateway può essere influenzato da numerose opzioni contenute nel file ceph.conf
. Di seguito è rimportato un elenco delle più importanti. Per l'elenco completo, vedere http://docs.ceph.com/docs/master/radosgw/config-ref/ (in lingua inglese).
Numero di thread per il server CivetWeb. Aumentare il valore se è necessario provvedere a più richieste. Il valore di default è 100 thread.
Numero di handle del cluster RADOS (fare riferimento a http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle) per Object Gateway. La possibilità di disporre un numero configurabile di handle RADOS comporta un miglioramento significativo delle prestazioni per tutti i tipi di workload. Adesso per ciascun thread di lavoro Object Gateway verrebbe selezionato un handle RADOS permanente. Il valore di default è 1.
Dimensioni massime di una porzione di dati che verrà letta in una singola operazione. Se si aumenta il valore a 4 MB (4194304) si otterranno prestazioni migliori durante l'elaborazione di oggetti di grandi dimensioni. Il valore di default è 128 kB (131072).
Se si aggiunge il parametro rgw dns name
a ceph.conf
, assicurarsi che il client S3 sia configurato per indirizzare le richieste all'endpoint specificato da rgw dns name
.
È 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.
Per accedere all'interfaccia S3, è necessario un client REST. S3cmd
è un client S3 della riga di comando. È possibile trovarlo in openSUSE Build Service (OBS) (in lingua inglese). L'archivio contiene versioni di entrambe le distribuzioni basate su SUSE Linux Enterprise e openSUSE.
Se si desidera testare l'accesso all'interfaccia S3, è anche possibile scrivere un piccolo script Python, che consentirà di eseguire la connessione a Object Gateway, creare un nuovo compartimento ed elencare tutti i compartimenti. I valori per aws_access_key_id
e aws_secret_access_key
sono ricavati dai valori di access_key
e secret_key
restituiti dal comando radosgw_admin
di cui alla Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».
Installare il pacchetto python-boto
:
sudo zypper in python-boto
Creare un nuovo script Python denominato s3test.py
con il seguente contenuto:
import boto import boto.s3.connection access_key = '11BS02LGFB6AL6H1ADMW' secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY' conn = boto.connect_s3( aws_access_key_id = access_key, aws_secret_access_key = secret_key, host = '{hostname}', is_secure=False, calling_format = boto.s3.connection.OrdinaryCallingFormat(), ) bucket = conn.create_bucket('my-new-bucket') for bucket in conn.get_all_buckets(): print "{name}\t{created}".format( name = bucket.name, created = bucket.creation_date, )
Sostituire {hostname}
con il nome host dell'host in cui si è configurato il servizio Object Gateway, ad esempio gateway_host
.
Eseguire lo script:
python s3test.py
L'output dello script è simile a quanto riportato di seguito:
my-new-bucket 2015-07-22T15:37:42.000Z
Per accedere a Object Gateway tramite l'interfaccia Swift, è necessario il client della riga di comando swift
. Nella relativa documentazione man 1 swift
sono fornite ulteriori informazioni sulle rispettive opzioni della riga di comando.
Il pacchetto è incluso nel modulo "Public Cloud" per SUSE Linux Enterprise 12 SP3. Prima di installare il pacchetto, è necessario attivare il modulo e aggiornare l'archivio software:
sudo SUSEConnect -p sle-module-public-cloud/12/x86_64 sudo zypper refresh
Per installare il comando swift
, eseguire quanto riportato di seguito:
sudo zypper in python-swiftclient
Per l'accesso swift si utilizza la seguente sintassi:
swift -A http://IP_ADDRESS/auth/1.0 \ -U example_user:swift -K 'swift_secret_key' list
Sostituire IP_ADDRESS con l'indirizzo IP del server gateway e swift_secret_key con il rispettivo valore risultante dal comando radosgw-admin key create
eseguito per l'utente swift
in Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».
Ad esempio:
swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \ -K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list
L'output è:
my-new-bucket
Per abilitare gli utenti finali all'iterazione con il gateway, è necessario creare un utente, una chiave di accesso e un segreto. Esistono due tipi di utenti: un utente e un sottoutente. Mentre gli utenti vengono utilizzati per l'iterazione con l'interfaccia S3, i sottoutenti sono gli utenti dell'interfaccia Swift. Ciascun sottoutente è associato a un utente.
È anche possibile aggiungere gli utenti tramite il file DeepSea rgw.sls
. Per un esempio, vedere Sezione 14.3.1, «Utenti Object Gateway diversi per NFS Ganesha».
Per creare un utente Swift, seguire la procedura indicata:
Per creare un utente Swift, che nella nostra terminologia è denominato sottoutente, prima è necessario creare l'utente associato.
sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email
Ad esempio:
sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ --email=penguin@example.com
Per creare un sottoutente (interfaccia Swift) per l'utente, è necessario specificare l'ID utente (--uid=username), un ID sottoutente e il livello di accesso per il sottoutente.
sudo radosgw-admin subuser create --uid=uid \ --subuser=uid \ --access=[ read | write | readwrite | full ]
Ad esempio:
sudo radosgw-admin subuser create --uid=example_user \ --subuser=example_user:swift --access=full
Generare una chiave segreta per l'utente.
sudo radosgw-admin key create \ --gen-secret \ --subuser=example_user:swift \ --key-type=swift
L'output di entrambi i comandi saranno i dati formattati per JSON in cui è visualizzato lo stato dell'utente. Osservare le righe seguenti e ricordare il valore di secret_key
:
"swift_keys": [ { "user": "example_user:swift", "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],
Quando si accede a Object Gateway tramite l'interfaccia S3, è necessario creare un utente S3 eseguendo:
sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email
Ad esempio:
sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ --email=penguin@example.com
Con questo comando si creano anche la chiave di accesso e la chiave segreta dell'utente. Verificare l'output per le parole chiave access_key
e secret_key
e i rispettivi valori:
[...] "keys": [ { "user": "example_user", "access_key": "11BS02LGFB6AL6H1ADMW", "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}], [...]
La procedura di eliminazione degli utenti S3 e Swift è simile. Nel caso degli utenti Swift però potrebbe essere necessario eliminare l'utente e i rispettivi sottoutenti.
Per rimuovere un utente S3 o Swift (inclusi tutti i rispettivi sottoutenti), specificare user rm
e l'ID utente nel seguente comando:
sudo radosgw-admin user rm --uid=example_user
Per rimuovere un sottoutente, specificare subuser rm
e l'ID sottoutente.
sudo radosgw-admin subuser rm --uid=example_user:swift
È possibile utilizzare una delle seguenti opzioni:
Elimina definitivamente tutti i dati associato all'ID utente.
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.
I parametri di access_key
e secret_key
identificano l'utente Object Gateway nel momento in cui accede al gateway. Modificare chiavi utente esistenti è come crearne di nuove, in quanto le chiavi precedenti vengono sovrascritte.
Per gli utenti S3, eseguire quanto riportato di seguito:
sudo radosgw-admin key create --uid=example_user --key-type=s3 --gen-access-key --gen-secret
Per gli utenti Swift, eseguire quanto riportato di seguito:
sudo radosgw-admin key create --subuser=example_user:swift --key-type=swift --gen-secret
--key-type=type
Specifica il tipo di chiave. swift
o s3
.
--gen-access-key
Genera una chiave di accesso casuale (di default per l'utente S3).
--gen-secret
Genera una chiave segreta casuale.
--secret=key
Specifica una chiave segreta, ad esempio una chiave generata manualmente.
Ceph Object Gateway consente di impostare le quote su utenti e compartimenti di proprietà degli utenti. Le quote includono il numero massimo di oggetti in un compartimento e le dimensioni massime di memorizzazione espresse in megabyte.
Prima di abilitare una quota utente, è necessario impostarne i parametri:
sudo radosgw-admin quota set --quota-scope=user --uid=example_user \ --max-objects=1024 --max-size=1024
--max-objects
Specifica il numero massimo di oggetti. Con un numero negativo la verifica viene disabilitata.
--max-size
Specifica il numero massimo di byte. Con un numero negativo la verifica viene disabilitata.
--quota-scope
Specifica l'ambito della quota. Le opzioni sono bucket
e user
. Le quote dei compartimenti si riferiscono ai compartimenti di proprietà di un utente. Le quote utente si riferiscono a un utente.
Una volta impostata una quota utente, è possibile abilitarla:
sudo radosgw-admin quota enable --quota-scope=user --uid=example_user
Per disabilitare una quota:
sudo radosgw-admin quota disable --quota-scope=user --uid=example_user
Per elencare le impostazioni della quota:
sudo radosgw-admin user info --uid=example_user
Per aggiornare le statistiche della quota:
sudo radosgw-admin user stats --uid=example_user --sync-stats
Per abilitare il ruolo Object Gateway di default in modo che comunichi in modo sicuro tramite SSL, è necessario disporre di un certificato emesso dalla CA o crearne uno firmato da se stessi. È possibile configurare Object Gateway con HTTPS in due modi diversi: uno semplice in cui vengono utilizzate le impostazioni di default e un modo avanzato che consente di ottimizzare le impostazioni correlate ad HTTPS.
Ignorare questa sezione se si dispone già di un certificato valido firmato dalla CA.
Per default, DeepSea si aspetta che il file certificato sia in /srv/salt/ceph/rgw/cert/rgw.pem
nel Salt master. Il certificato verrà quindi distribuito a /etc/ceph/rgw.pem
nel Salt minion con il ruolo Object Gateway, dove viene letto da Ceph.
Nella procedura seguente è illustrato come generare un certificato SSL firmato da se stessi sul nodo Salt master.
Aggiungere l'opzione subjectAltName
alla sezione [v3_req]
del file /etc/ssl/openssl.cnf
per tutti i nomi host cui si desidera rendere noto Object Gateway mediante:
[...] [ v3_req ] subjectAltName = ${ENV::SAN} [...]
Creare la chiave e il certificato utilizzando openssl
. Aggiungere a openssl
il prefisso env SAN=DNS:fqdn
. Immettere tutti i dati che è necessario includere nel certificato. Si consiglia di immettere FQDN come nome comune. Prima di firmare il certificato, verificare che "X509v3 Subject Alternative Name:" sia incluso nelle estensioni richieste e che sia impostato nel certificato che viene generato.
root@master #
env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \
-newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem
Per default, Ceph sul nodo Object Gateway legge il certificato /etc/ceph/rgw.pem
e utilizza la porta 443 per la comunicazione SSL sicura. Se non è necessario modificare questi valori, seguire la procedura indicata di seguito:
Modificare /srv/pillar/ceph/stack/global.yml
e aggiungere la riga seguente:
rgw_configurations: rgw-ssl rgw_init: default-ssl
Eseguire le fasi 2, 3 e 4 di DeepSea per applicare le modifiche:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Se è necessario modificare i valori di default per le impostazioni SSL di Object Gateway, seguire la procedura indicata di seguito:
Copiare la configurazione SSL di Object Gateway di default nella sottodirectory ceph.conf.d
:
root@master #
cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
/srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
Modificare /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
e le opzioni di default, come il numero porta o il percorso del certificato SSL in modo che riflettano la configurazione impostata.
Eseguire le fasi 3 e 4 di DeepSea per applicare le modifiche:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Nel server CivetWeb è possibile associare più porte. Tale funzione è utile se è necessario accedere a un'istanza singola di Object Gateway con entrambe le connessioni SSL e non SSL. Quando si specificano le porte, separare i relativi numeri con un simbolo più "+". Di seguito è riportato un esempio di riga di configurazione con due porte:
[client.{{ client }}] rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem
La funzionalità multisite di Object Gateway introdotta in Jewel consente di creare più zone e di eseguire la copia speculare dei dati e dei metadati tra loro. I moduli di sincronizzazione sono costruiti in cima al framework multisito che consente l'inoltro di dati e metadati a un livello esterno diverso. Un modulo di sincronizzazione consente di eseguire un set di azioni ogni volta che ha luogo una modifica dei dati (con modifiche dei dati si intendono anche operazioni correlate ai metadati, come la creazione di compartimenti o utenti e così via). Poiché le modifiche del multisito rgw alla fine sono coerenti nei siti remoti, le modifiche vengono propagate in modo asincrono. Ciò consente di sbloccare casi di utilizzo come il backup della memorizzazione di oggetti in un cluster cloud esterno o una soluzione di backup personalizzata in cui vengono utilizzate unità nastro o l'indicizzazione dei metadati in Elasticsearch e così via.
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.
Si supponga una semplice configurazione multisito, come descritta nella Sezione 11.11, «Object Gateway multisito», costituita da 2 zone: us-east
e us-west
. Adesso si aggiunge una terza zona us-east-es
nella quale vengono elaborati solo i metadati provenienti da altri siti. Questa zona può essere nello stesso cluster Ceph di us-east
o in uno diverso. In questa zona vengono utilizzati solo i metadati provenienti da altre zone e gli Object Gateway in essa contenuti non serviranno direttamente alcuna richiesta dell'utente finale.
Creare una terza zona simile a quelle descritte nella Sezione 11.11, «Object Gateway multisito», ad esempio
root #
radosgw-admin
zone create --rgw-zonegroup=us --rgw-zone=us-east-es \ --access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80
È possibile configurare un modulo di sincronizzazione per questa zona nel modo seguente
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --tier-type={tier-type} \ --tier-config={set of key=value pairs}
Ad esempio, nel modulo di sincronizzazione elasticsearch
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \ --tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
Per le varie opzioni tier-config supportate, fare riferimento a Sezione 11.7.2, «Memorizzazione dei metadati in Elasticsearch».
Infine, aggiornare il periodo
root #
radosgw-admin
period update --commit
Adesso avviare radosgw nella zona
root #
systemctl
start ceph-radosgw@rgw.`hostname -s`root #
systemctl
enable ceph-radosgw@rgw.`hostname -s`
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" } } }
Specifica l'endpoint del server Elasticsearch cui accedere.
(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.
(numero intero) Numero di repliche che verranno configurate da Elasticsearch con l'inizializzazione della sincronizzazione sui dati.
(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.
(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").
(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.
(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.
Poiché adesso nel cluster Elasticsearch vengono memorizzati metadati di oggetti, è importante che l'endpoint di Elasticsearch non sia esposto in pubblico e che sia accessibile solo dagli amministratori del cluster. Ciò rappresenta un problema per l'esposizione delle interrogazioni dei metadati all'utente finale dato che è necessario che l'utente interroghi solo i propri metadati e non quelli di altri utenti. Pertanto sarebbe opportuno che l'autenticazione degli utenti da parte del cluster Elasticsearch venga eseguita in modo simile a RGW che di fatto rappresenta un problema.
A partire da Luminous RGW, adesso nella zona master dei metadata master è possibile provvedere alle richieste degli utenti finali. In tal modo l'endpoint Elasticsearch non viene esposto in pubblico e si risolve anche il problema di autenticazione e autorizzazione in quanto RGW stesso è in grado di autenticare le richieste degli utenti finali. A tal fine, RGW introduce una nuova interrogazione nelle API del compartimento che sono in grado di provvedere alle richieste Elasticsearch. Tutte queste richieste devono essere inviate alla zona master dei metadati.
GET /BUCKET?query={query-expr}
parametri di richiesta:
max-keys: numero massimo di voci da restituire
marker: marker di impaginazione
expression := [(]<arg> <op> <value> [)][<and|or> ...]
op è uno dei seguenti: <, <=, ==, >=, >
Ad esempio:
GET /?query=name==foo
Verranno restituite tutte le chiavi indicizzate per le quali l'utente dispone l'autorizzazione in lettura e vengono denominate "foo". L'output sarà un elenco di chiavi in XML simile alla risposta dei compartimenti dell'elenco S3.
Definire quali voci dei metadati personalizzati devono essere indicizzate (nel compartimento specificato) e quali sono i tipi di queste chiavi. Se si configura l'indicizzazione esplicita dei metadati personalizzati, tale operazione è necessaria affinché rgw indicizzi i valori dei metadati personalizzati specificati. Altrimenti è necessaria nei casi in cui le chiavi dei metadati indicizzati siano di tipo diverso dalla stringa.
POST /BUCKET?mdsearch x-amz-meta-search: <key [; type]> [, ...]
I campi di metadati multipli devono essere separati da virgole, è possibile forzare un tipo per un campo con un punto e virgola ";". I tipi attualmente consentiti sono stringa (default), numero intero e data, ad esempio se si desidera indicizzare metadati di oggetti personalizzati si possono utilizzare x-amz-meta-year come numero intero, x-amz-meta-date come tipo di data e x-amz-meta-title come stringa
POST /mybooks?mdsearch x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string
Eliminare la configurazione del compartimento dei metadati personalizzati.
DELETE /BUCKET?mdsearch
Recuperare la configurazione del compartimento dei metadati personalizzati.
GET /BUCKET?mdsearch
Oltre all'autenticazione utente locale di default, con Object Gateway si possono utilizzare i servizi del server LDAP per autenticare anche gli utenti.
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.
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. Ad esempio:
ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \ -H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn
Assicurarsi di utilizzare gli stessi parametri LDAP del file di configurazione Ceph per eliminare eventuali problemi.
I seguenti parametri nel file di configurazione /etc/ceph/ceph.conf
sono correlati all'autenticazione LDAP:
rgw_ldap_uri
Specifica il server LDAP da utilizzare. Assicurarsi di utilizzare il parametro ldaps://fqdn:port
per evitare di trasmettere apertamente credenziali come testo normale.
rgw_ldap_binddn
Nome distinto (DN) dell'account di servizio utilizzato da Object Gateway.
rgw_ldap_secret
Password per l'account di servizio.
Specifica la base DIT (Directory Information Tree) per la ricerca degli utenti. Questa può essere l'unità organizzativa degli utenti o una più specifica.
rgw_ldap_dnattr
Attributo che viene utilizzato nel filtro di ricerca costruito per la corrispondenza con un nome utente. A seconda del DIT, è probabile che tale attributo sia uid
o cn
.
rgw_search_filter
Se non è specificato, in Object Gateway il filtro di ricerca viene costruito automaticamente con l'impostazione rgw_ldap_dnattr
. Utilizzare questo parametro per restringere l'elenco degli utenti consentiti con la massima flessibilità. Consultare Sezione 11.8.4, «Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti» per ulteriori informazioni.
È possibile utilizzare il parametro rgw_search_filter
in due modi diversi.
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.
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.
Il token di accesso viene generato dall'utility radosgw-token
in base al nome utente e alla password LDAP. L'output è una stringa codificata base-64 che corrisponde al token di accesso effettivo. Utilizzare il client S3 preferito (fare riferimento a Sezione 11.5.1, «Accesso a Object Gateway»), specificare il token come chiave di accesso e utilizzare una chiave segreta vuota.
root@minion >
export RGW_ACCESS_KEY_ID="username"root@minion >
export RGW_SECRET_ACCESS_KEY="password"root@minion >
radosgw-token --encode --ttype=ldap
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
.
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.
Se un compartimento è diventato più grande e la rispettiva configurazione iniziale non è più sufficiente, è necessario ripartizionare il pool di indice del compartimento. È possibile utilizzare il ripartizionamento dell'indice del compartimento online (fare riferimento a Sezione 11.9.1.1, «Ripartizionamento dinamico») o eseguire manualmente il ripartizionamento dell'indice del compartimento offline (fare riferimento a Sezione 11.9.1.2, «Ripartizionamento manuale»).
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.
Il ripartizionamento dinamico non è supportato in ambienti multisito. A partire da Ceph 12.2.2 è disabilitato per default, ma si consiglia di verificare ulteriormente l'impostazione.
root@minion >
radosgw-admin reshard add \
--bucket BUCKET_NAME \
--num-shards NEW_NUMBER_OF_SHARDS
root@minion >
radosgw-admin reshard list
root@minion >
radosgw-admin reshard process
root@minion >
radosgw-admin reshard status --bucket BUCKET_NAME
root@minion >
radosgw-admin reshard cancel --bucket BUCKET_NAME
Il ripartizionamento dinamico di cui alla Sezione 11.9.1.1, «Ripartizionamento dinamico» è supportato solo per le configurazioni Object Gateway semplici. Per le configurazioni multisito, utilizzare il ripartizionamento manuale descritto nella presente sezione.
Per eseguire il ripartizionamento manuale dell'indice del compartimento offline, utilizzare il comando seguente:
root@minion >
radosgw-admin bucket reshard
Il comando bucket reshard
consente di effettuare le seguenti operazioni:
Creare un nuovo set di oggetti Indice compartimento per l'oggetto specificato.
Distribuire tutte le voci degli oggetti Indice.
Creare una nuova istanza del compartimento.
Collegare la nuova istanza del compartimento al compartimento in modo che tutte le nuove operazioni di indice passino attraverso i nuovi indici del compartimento.
Stampare il vecchio e il nuovo ID compartimento nell'output standard.
Assicurarsi che tutte le operazioni nel compartimento vengano interrotte
Eseguire il backup dell'indice del compartimento originale:
root@minion >
radosgw-admin bi list \
--bucket=BUCKET_NAME \
> BUCKET_NAME.list.backup
Eseguire il ripartizionamento dell'indice del compartimento:
root@minion >
radosgw-admin reshard \
--bucket=BUCKET_NAME \
--num-shards=NEW_SHARDS_NUMBER
Come parte del rispettivo output, questo comando consente inoltre di stampare l'ID compartimento nuovo e quello precedente. So noti l'ID compartimento precedente visualizzato sotto; questo sarà necessario per eliminare definitivamente gli oggetti Indice del compartimento precedenti.
Verificare che tali oggetti siano elencati correttamente confrontando l'elenco degli indici del compartimento precedenti con quello nuovo. Quindi, eliminare definitivamente gli oggetti Indice compartimento precedenti:
root@minion >
radosgw-admin bi purge
--bucket=BUCKET_NAME
--bucket-id=OLD_BUCKET_ID
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.
Aprire il file di configurazione di Ceph e aggiungere o modificare l'opzione seguente:
rgw_override_bucket_index_max_shards = 12
Per configurare il partizionamento dell'indice del compartimento per tutte le istanze di Object Gateway, includere rgw_override_bucket_index_max_shards
nella sezione [global]
.
Per configurare il partizionamento dell'indice del compartimento solo per una determinata istanza di Object Gateway, includere rgw_override_bucket_index_max_shards
nella relativa sezione dell'istanza.
Riavviare Object Gateway. Per ulteriori dettagli, vedere Sezione 11.3, «Funzionamento del servizio Object Gateway».
Le configurazioni multisito possono avere un pool di indice diverso per la gestione dei failover. Per configurare un numero di partizioni coerente per le zone in un gruppo di zone, impostare l'opzione bucket_index_max_shards
nella configurazione del gruppo di zone:
Esportare la configurazione del gruppo di zone nel file zonegroup.json
:
root@minion >
radosgw-admin zonegroup get > zonegroup.json
Modificare il file zonegroup.json
e impostare l'opzione bucket_index_max_shards
per ciascuna zona con nome.
Reimpostare il gruppo di zone:
root@minion >
radosgw-admin zonegroup set < zonegroup.json
Aggiornare il periodo:
root@minion >
radosgw-admin period update --commit
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.
Prima di configurare Ceph Object Gateway, è necessario configurare OpenStack Keystone all'abilitazione del servizio Swift e fare in modo questo che punti a Ceph Object Gateway:
Impostare il servizio Swift. Prima di poter utilizzare OpenStack per la convalida degli utenti Swift, creare il servizio Swift:
root #
openstack service create \
--name=swift \
--description="Swift Service" \
object-store
Impostare gli endpoint. Dopo aver creato il servizio Swift, fare in modo che punti a Ceph Object Gateway. Sostituire REGION_NAME con il nome del gruppo di zone o il nome dell'area del gateway.
root #
openstack endpoint create --region REGION_NAME \
--publicurl "http://radosgw.example.com:8080/swift/v1" \
--adminurl "http://radosgw.example.com:8080/swift/v1" \
--internalurl "http://radosgw.example.com:8080/swift/v1" \
swift
Verificare le impostazioni. Dopo aver creato il servizio Swift e impostati gli endpoint, visualizzare questi ultimi per verificare che tutte le impostazioni siano corrette.
root #
openstack endpoint show object-store
Ceph Object Gateway interroga Keystone periodicamente per un elenco di token revocati. Tali richieste sono codificate e firmate. È inoltre possibile configurare Keystone in modo che vengano forniti token firmati da se stessi, a loro volta codificati e firmati. È necessario configurare il gateway in modo che possa decodificare e verificare tali messaggi firmati. Pertanto, è necessario convertire in formato "nss db" i certificati OpenSSL utilizzati da Keystone per creare le richieste:
root #
mkdir /var/ceph/nssroot #
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"
È inoltre possibile terminare OpenStack Keystone con un certificato SSL firmato da se stessi ai fini dell'iterazione di Ceph Object Gateway con Keystone. Installare il certificato SSL di Keystone sul nodo sul quale è in esecuzione Ceph Object Gateway o in alternativa impostare il valore dell'opzione rgw keystone verify ssl
su "false". L'impostazione di rgw keystone verify ssl
su "false" significa che non verrà effettuato alcun tentativo di verifica del certificato da parte del gateway.
È possibile configurare l'integrazione di Keystone utilizzando le opzioni seguenti:
rgw keystone api version
Versione dell'API Keystone. Le opzioni valide sono 2 o 3. Il valore di default è 2.
rgw keystone url
URL e numero di porta dell'API amministrativa RESTful sul server Keystone. Segue il modello SERVER_URL:PORT_NUMBER.
rgw keystone admin token
Token o segreto condiviso configurato all'interno di Keystone per le richieste amministrative.
rgw keystone accepted roles
Ruoli richiesti per provvedere alle richieste. L'impostazione di default è "Member, admin".
rgw keystone accepted admin roles
Elenco dei ruoli che consentono a un utente di ottenere privilegi amministrativi.
rgw keystone token cache size
Numero massimo di voci nella cache dei token Keystone.
rgw keystone revocation interval
Numero di secondi prima della verifica dei token revocati. Il valore di default è 15 * 60.
rgw keystone implicit tenants
Crea nuovi utenti nei rispettivi tenant con lo stesso nome. L'impostazione di default è "false".
rgw s3 auth use keystone
Se impostata su "'true", Ceph Object Gateway eseguirà l'autenticazione degli utenti tramite Keystone. L'impostazione di default è "false".
nss db path
Percorso del database NSS.
È inoltre possibile configurare il tenant del servizio Keystone, l'utente e la password per Keystone (per la versione v2.0 di OpenStack Identity API), in modo simile a quanto avviene per la configurazione dei servizi OpenStack. In tal modo si può evitare di impostare il segreto condiviso rgw keystone admin token
nel file di configurazione, che deve essere disabilitato negli ambienti di produzione. Le credenziali del tenant del servizio devono disporre dei privilegi amministrativi. Per ulteriori dettagli, fare riferimento alla documentazione ufficiale di OpenStack Keystone (in lingua inglese). Di seguito sono riportate le opzioni di configurazione correlate:
rgw keystone admin user
Nome utente amministratore Keystone.
rgw keystone admin password
Password utente amministratore Keystone.
rgw keystone admin tenant
Tenant utente amministratore Keystone versione 2.0.
Un utente Ceph Object Gateway viene mappato a un tenant Keystone. A un utente Keystone vengono assegnati ruoli diversi, possibilmente su più tenant. Quando Ceph Object Gateway ottiene il ticket, fa riferimento ai ruoli del tenant e dell'utente assegnati a tale ticket, quindi accetta o rifiuta la richiesta in base all'impostazione definita per l'opzione rgw keystone accepted roles
.
Sebbene i tenant Swift vengano mappati per default all'utente Object Gateway, è possibile mapparli anche ai tenant OpenStack tramite l'opzione rgw keystone implicit tenants
. In tal modo i container utilizzeranno lo spazio dei nomi dei tenant anziché quello globale uguale a S3 che è l'impostazione di default di Object Gateway. Per evitare di fare confusione, si consiglia di decidere il metodo di mappatura in fase di pianificazione. L'attivazione/disattivazione dell'opzione in un momento successivo influisce solo sulle richieste più recenti che vengono mappate in un tenant, mentre i compartimenti creati precedentemente continuano a risiedere in uno spazio dei nomi globale.
Per la versione 3 di OpenStack Identity API, si deve sostituire l'opzione rgw keystone admin tenant
con:
rgw keystone admin domain
Domino utente amministratore Keystone.
rgw keystone admin project
Progetto utente amministratore Keystone.
Raggruppamento logico di una o più istanze Object Gateway. È necessario designare una zona come master in un gruppo di zone, dalla quale gestire la creazione di tutti i compartimenti e di tutti gli utenti.
Un gruppo di zone è costituito da più zone. Le modifiche alla configurazione del sistema dovranno essere gestite da un gruppo di zone master.
Struttura di configurazione che contiene la mappa dell'intero sistema, ad esempio indica il gruppo di zone master, le relazioni tra gruppi di zone diversi e alcune opzioni di configurazione come le policy di memorizzazione.
Container per i gruppi di zone. Consente la separazione dei gruppi di zone tra i cluster. È possibile creare più domini in modo da semplificare l'esecuzione di configurazioni completamente diverse nello stesso cluster.
Un periodo contiene la struttura di configurazione per lo stato attuale del dominio. Ciascun periodo contiene un ID univoco e un'epoca. A ogni dominio è associato un periodo attuale, con lo stato attuale della configurazione dei gruppi di zone e le policy di memorizzazione. Qualsiasi modifica alla configurazione per una zona non master aumenterà l'epoca del periodo. Se si modifica la zona master in una zona diversa, verranno attivate le seguenti modifiche:
Viene generato un nuovo periodo con un ID periodo nuovo e un'epoca pari a 1.
Il periodo attuale del dominio viene aggiornato in modo che punti all'ID periodo appena generato.
L'epoca del dominio aumenta di valore.
È possibile configurare ciascun Object Gateway in modo che faccia parte di un'architettura federata, operando in una configurazione di zona attiva e consentendo al contempo le scritture in zone non master.
Di seguito è riportata una descrizione dei termini specifici di un'architettura federata:
Questo esempio è incentrato sulla creazione di un singolo gruppo di zone con tre zone distinte, in cui vengono sincronizzati attivamente i rispettivi dati. Due zone appartengono allo stesso cluster, mentre la terza appartiene a un cluster diverso. Non è presente alcun agente di sincronizzazione coinvolto nel processo di copia speculare delle modifiche dei dati tra gli Object Gateway. In tal modo si ottengono uno schema di configurazione e configurazioni attive-attive più semplici. Le operazioni dei metadati, come la creazione di un nuovo utente, devono continuare a passare dalla zona master. Le operazioni dei dati, tuttavia, come la creazione di compartimenti e oggetti, possono essere gestite da qualsiasi zona.
Durante la configurazione delle zone, Object Gateway si aspetta la creazione di un utente del sistema compatibile con S3 e delle rispettive chiavi di accesso e segreta. Ciò consente a un'altra istanza di Object Gateway di recuperare la configurazione in remoto tramite le chiavi di accesso e segreta. Per ulteriori informazioni sulla creazione di utenti S3, vedere Sezione 11.5.2.1, «Aggiunta di utenti S3 e Swift».
È utile generare la chiave di accesso e la chiave segreta prima della creazione della zona stessa perché così facendo, successivamente la creazione di script e l'uso degli strumenti di gestione della configurazione risulteranno più semplici.
Ai fini del presente esempio, presupporre che la chiave di accesso e la chiave segreta siano impostate nelle variabili ambiente:
# SYSTEM_ACCESS_KEY=1555b35654ad1656d805 # SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==
Di norma, le chiavi di accesso sono costituite da 20 caratteri alfanumerici, mentre le chiavi segrete da 40 caratteri alfanumerici (possono contenere anche i caratteri +/=). È possibile generare tali chiavi nella riga di comando:
# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) # SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)
In questo esempio è illustrato il processo di configurazione di una zona master. Si prenda come riferimento un gruppo di zone denominato us
esteso agli Stati Uniti che sarà il gruppo di zone master . Tale gruppo di zone conterrà due zone scritte nel formato zonegroup-zone. Il formato dell'esempio è quello convenzionale, ma è possibile scegliere il formato che si preferisce. Nel riepilogo:
Gruppo di zone master: Stati Uniti us
Zona master: Stati Uniti, Area Est 1: us-east-1
Zona secondaria: Stati Uniti, Area Est 2: us-east-2
Zona secondaria: Stati Uniti, Area Ovest: us-west
Questa farà parte di un dominio più grande denominato gold
. Le zone us-east-1
e us-east-2
fanno parte dello stesso cluster Ceph, us-east-1
che è quello primario. us-west
rientra in un cluster Ceph diverso.
Quando è configurato con le autorizzazioni appropriate, Object Gateway crea pool di default propri. I valori pg_num
e pgp_num
sono ricavati dal file di configurazione ceph.conf
. I pool correlati a una zona per default seguono la convezione zone-name.pool-name. Ad esempio, per la zona us-east-1
verranno creati i seguenti pool:
.rgw.root us-east-1.rgw.control us-east-1.rgw.data.root us-east-1.rgw.gc us-east-1.rgw.log us-east-1.rgw.intent-log us-east-1.rgw.usage us-east-1.rgw.users.keys us-east-1.rgw.users.email us-east-1.rgw.users.swift us-east-1.rgw.users.uid us-east-1.rgw.buckets.index us-east-1.rgw.buckets.data us-east-1.rgw.meta
È possibile creare tali pool anche in altre zone sostituendo us-east-1
con il nome zona appropriato.
Configurare un dominio denominato gold
e renderlo il dominio di default:
cephadm >
radosgw-admin realm create --rgw-realm=gold --default
{
"id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"name": "gold",
"current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"epoch": 1
}
Si noti che ciascun dominio dispone di un ID ai fini della flessibilità, ad esempio consente di rinominarlo in un momento successivo in caso di necessità. Il current_period
cambia ogni volta che si modifica la zona master. Il valore di epoch
aumenta quando una modifica nella configurazione della zona master risulta in una modifica del periodo attuale.
L'installazione di default di Object Gateway crea un gruppo di zone di default denominato default
. Poiché il gruppo di zone di default non è più necessario, rimuoverlo.
cephadm >
radosgw-admin zonegroup delete --rgw-zonegroup=default
Creare un gruppo di zone master denominato us
. Il gruppo di zone gestirà la mappa del gruppo di zone e propagherà le modifiche al resto del sistema. Contrassegnando il gruppo di zone come default, si consentirà la menzione esplicita dello switch rgw-zonegroup per i comandi successivi.
cephadm >
radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "",
"zones": [],
"placement_targets": [],
"default_placement": "",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
In alternativa, è possibile contrassegnare un gruppo di zone come default con il comando seguente:
cephadm >
radosgw-admin zonegroup default --rgw-zonegroup=us
Adesso creare una zona di default e aggiungerla al gruppo di zone di default. Questa zona verrà utilizzata per le operazioni dei metadati, come la creazione di un utente:
cephadm >
radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"domain_root": "us-east-1/gc.rgw.data.root",
"control_pool": "us-east-1/gc.rgw.control",
"gc_pool": "us-east-1/gc.rgw.gc",
"log_pool": "us-east-1/gc.rgw.log",
"intent_log_pool": "us-east-1/gc.rgw.intent-log",
"usage_log_pool": "us-east-1/gc.rgw.usage",
"user_keys_pool": "us-east-1/gc.rgw.users.keys",
"user_email_pool": "us-east-1/gc.rgw.users.email",
"user_swift_pool": "us-east-1/gc.rgw.users.swift",
"user_uid_pool": "us-east-1/gc.rgw.users.uid",
"system_key": {
"access_key": "1555b35654ad1656d804",
"secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
},
"placement_pools": [
{
"key": "default-placement",
"val": {
"index_pool": "us-east-1/gc.rgw.buckets.index",
"data_pool": "us-east-1/gc.rgw.buckets.data",
"data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec",
"index_type": 0
}
}
],
"metadata_heap": "us-east-1/gc.rgw.meta",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
Gli switch --rgw-zonegroup
e --default
consentono di aggiungere la zona a un gruppo di zone e la rendono la zona di default. In alternativa, è possibile effettuare la stessa operazione con i comandi seguenti:
cephadm >
radosgw-admin zone default --rgw-zone=us-east-1cephadm >
radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1
Per accedere ai pool di zone, è necessario creare un utente di sistema. Queste chiavi saranno necessarie anche quando si configura la zona secondaria.
cephadm >
radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \
--secret=$SYSTEM_SECRET_KEY --system
Poiché si è modificata la configurazione della zona master, è necessario confermare le modifiche per poterle applicare alla struttura di configurazione del dominio. Inizialmente il dominio ha il seguente aspetto:
cephadm >
radosgw-admin period get
{
"id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map":
{
"id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": []
}, "master_zonegroup": "", "master_zone": "", "period_config":
{
"bucket_quota": {
"enabled": false, "max_size_kb": -1, "max_objects": -1
}, "user_quota": {
"enabled": false, "max_size_kb": -1, "max_objects": -1
}
}, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1
}
Aggiornare il periodo e confermare le modifiche:
cephadm >
radosgw-admin period update --commit
{
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"epoch": 1,
"predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"sync_status": [ "[...]"
],
"period_map": {
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"zonegroups": [
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"zones": [
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"endpoints": [
"http:\/\/rgw1:80"
],
"log_meta": "true",
"log_data": "false",
"bucket_index_max_shards": 0,
"read_only": "false"
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
],
"short_zone_ids": [
{
"key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"val": 630926044
}
]
},
"master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"period_config": {
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
}
},
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"realm_name": "gold",
"realm_epoch": 2
}
Prima di avviare Object Gateway, è necessario menzionare nel file di configurazione le opzioni relative alla zona e alla porta Object Gateway. Per ulteriori informazioni su Object Gateway e la relativa configurazione, vedere Capitolo 11, Ceph Object Gateway. La sezione di configurazione di Object Gateway deve avere un aspetto simile a quanto riportato di seguito:
[client.rgw.us-east-1] rgw_frontends="civetweb port=80" rgw_zone=us-east-1
Avviare Object Gateway:
sudo systemctl start ceph-radosgw@rgw.us-east-1
Nello stesso cluster, creare e configurare la zona secondaria denominata us-east-2
. È possibile eseguire tutti i comandi seguenti nel nodo che ospita la zona master stessa.
Per creare una zona secondaria, utilizzare lo stesso comando impiegato per la creazione della zona primaria, ad eccezione del rilascio del flag master:
cephadm >
radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \
--rgw-zone=us-east-2 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-east-2",
"domain_root": "us-east-2.rgw.data.root",
"control_pool": "us-east-2.rgw.control",
"gc_pool": "us-east-2.rgw.gc",
"log_pool": "us-east-2.rgw.log",
"intent_log_pool": "us-east-2.rgw.intent-log",
"usage_log_pool": "us-east-2.rgw.usage",
"user_keys_pool": "us-east-2.rgw.users.keys",
"user_email_pool": "us-east-2.rgw.users.email",
"user_swift_pool": "us-east-2.rgw.users.swift",
"user_uid_pool": "us-east-2.rgw.users.uid",
"system_key": {
"access_key": "1555b35654ad1656d804",
"secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
},
"placement_pools": [
{
"key": "default-placement",
"val": {
"index_pool": "us-east-2.rgw.buckets.index",
"data_pool": "us-east-2.rgw.buckets.data",
"data_extra_pool": "us-east-2.rgw.buckets.non-ec",
"index_type": 0
}
}
],
"metadata_heap": "us-east-2.rgw.meta",
"realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"
}
Informare tutti i gateway in merito alla nuova modifica della mappa di sistema eseguendo un aggiornamento del periodo e confermando le modifiche:
cephadm >
radosgw-admin period update --commit
{
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"epoch": 2,
"predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"sync_status": [ "[...]"
],
"period_map": {
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"zonegroups": [
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"zones": [
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"endpoints": [
"http:\/\/rgw1:80"
],
"log_meta": "true",
"log_data": "false",
"bucket_index_max_shards": 0,
"read_only": "false"
},
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-east-2",
"endpoints": [
"http:\/\/rgw2:80"
],
"log_meta": "false",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
],
"short_zone_ids": [
{
"key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"val": 630926044
},
{
"key": "950c1a43-6836-41a2-a161-64777e07e8b8",
"val": 4276257543
}
]
},
"master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"period_config": {
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
}
},
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"realm_name": "gold",
"realm_epoch": 2
}
Regolare la configurazione di Object Gateway per una zona secondaria e avviarlo:
[client.rgw.us-east-2] rgw_frontends="civetweb port=80" rgw_zone=us-east-2
cephadm >
sudo systemctl start ceph-radosgw@rgw.us-east-2
Il secondo cluster Ceph appartiene allo stesso gruppo di zone di quello iniziale, ma è geograficamente ubicato altrove.
Poiché si è già creato il dominio per il primo gruppo di zone, recuperare qui il dominio e renderlo quello di default:
cephadm >
radosgw-admin realm pull --url=http://rgw1:80 \ --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY { "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2 }cephadm >
radosgw-admin realm default --rgw-realm=gold
Ottenere la configurazione dalla zona master recuperando il periodo:
cephadm >
radosgw-admin period pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
Impostare il gruppo di zone di default a quello us
che è già stato creato:
cephadm >
radosgw-admin zonegroup default --rgw-zonegroup=us
Creare una nuova zona denominata us-west
con le stesse chiavi di sistema:
cephadm >
radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \
--endpoints=http://rgw3:80 --default
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-west",
"domain_root": "us-west.rgw.data.root",
"control_pool": "us-west.rgw.control",
"gc_pool": "us-west.rgw.gc",
"log_pool": "us-west.rgw.log",
"intent_log_pool": "us-west.rgw.intent-log",
"usage_log_pool": "us-west.rgw.usage",
"user_keys_pool": "us-west.rgw.users.keys",
"user_email_pool": "us-west.rgw.users.email",
"user_swift_pool": "us-west.rgw.users.swift",
"user_uid_pool": "us-west.rgw.users.uid",
"system_key": {
"access_key": "1555b35654ad1656d804",
"secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
},
"placement_pools": [
{
"key": "default-placement",
"val": {
"index_pool": "us-west.rgw.buckets.index",
"data_pool": "us-west.rgw.buckets.data",
"data_extra_pool": "us-west.rgw.buckets.non-ec",
"index_type": 0
}
}
],
"metadata_heap": "us-west.rgw.meta",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
Per propagare le modifiche del gruppo di zone, si aggiorna e si conferma il periodo:
cephadm >
radosgw-admin period update --commit --rgw-zone=us-west
{
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"epoch": 3,
"predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"sync_status": [
"", # truncated
],
"period_map": {
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"zonegroups": [
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"zones": [
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"endpoints": [
"http:\/\/rgw1:80"
],
"log_meta": "true",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
},
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-east-2",
"endpoints": [
"http:\/\/rgw2:80"
],
"log_meta": "false",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
},
{
"id": "d9522067-cb7b-4129-8751-591e45815b16",
"name": "us-west",
"endpoints": [
"http:\/\/rgw3:80"
],
"log_meta": "false",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
],
"short_zone_ids": [
{
"key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"val": 630926044
},
{
"key": "950c1a43-6836-41a2-a161-64777e07e8b8",
"val": 4276257543
},
{
"key": "d9522067-cb7b-4129-8751-591e45815b16",
"val": 329470157
}
]
},
"master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"period_config": {
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
}
},
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"realm_name": "gold",
"realm_epoch": 2
}
Il numero di epoca del periodo aumenta a indicare una modifica nella configurazione.
Questa operazione è simile all'avvio di Object Gateway nella prima zona, con l'unica differenza che la configurazione di zona di Object Gateway deve riflettere il nome zona us-west
:
[client.rgw.us-west] rgw_frontends="civetweb port=80" rgw_zone=us-west
Avviare il secondo Object Gateway:
sudo systemctl start ceph-radosgw@rgw.us-west
Qualora la zona master dovesse venire meno, eseguire il failover nella zona secondaria per il disaster recovery.
Rendere la zona secondaria la zona master e di default. Ad esempio:
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --master --default
Per default, Ceph Object Gateway verrà eseguito in una configurazione attiva-attiva. Se si è configurato il cluster per l'esecuzione in una configurazione attiva-passiva, la zona secondaria è di sola lettura. Rimuovere lo stato --read-per consentire alla zona di ricevere operazioni di scrittura. Ad esempio:
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --master --default \ --read-only=False
Aggiornare il periodo per applicare le modifiche.
root #
radosgw-admin
period update --commit
Infine, riavviare Ceph Object Gateway.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
Se la zona master precedente viene recuperata, ripristinare l'operazione.
Dalla zona recuperata, recuperare il periodo dall'attuale zona master.
root #
radosgw-admin
period pull --url={url-to-master-zone-gateway} \ --access-key={access-key} --secret={secret}
Rendere la zona recuperata la zona master e di default.
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --master --default
Aggiornare il periodo per applicare le modifiche.
root #
radosgw-admin
period update --commit
Quindi, riavviare Ceph Object Gateway nella zona recuperata.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
Se la configurazione della zona secondaria deve essere in sola lettura, aggiornare la zona secondaria.
root #
radosgw-admin
zone modify --rgw-zone={zone-name} --read-only
Aggiornare il periodo per applicare le modifiche.
root #
radosgw-admin
period update --commit
Infine, riavviare Ceph Object Gateway nella zona secondaria.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
È possibile utilizzare il bilanciamento del carico HAProxy per distribuire tutte le richieste in più server back-end Object Gateway. Per ulteriori dettagli sulla configurazione di HAProxy, fare riferimento a https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html (in lingua inglese).
Di seguito è riportata una configurazione semplice di HAProxy per il bilanciamento dei nodi Object Gateway mediante l'uso di Round Robin come algoritmo di bilanciamento:
root #
cat /etc/haproxy/haproxy.cfg
[...]
frontend https_frontend
bind *:443 crt path-to-cert.pem [ciphers: ... ]
default_backend rgw
backend rgw
mode http
balance roundrobin
server rgw_server1 rgw-endpoint1 weight 1 maxconn 100 check
server rgw_server2 rgw-endpoint2 weight 1 maxconn 100 check
[...]