rgw è il plug-in di sincronizzazione di default e non è necessario configurarlo esplicita-mente.
11.7.1.1 Requisiti e presupposti
Si supponga una semplice configurazione multisito, come descritta nella Sezione 11.11, «Object Gateway multisito», costituita da 2 zone: us-east e us-west. Adesso si aggiunge una terza zona us-east-es nella quale vengono elaborati solo i metadati provenienti da altri siti. Questa zona può essere nello stesso cluster Ceph di us-east o in uno diverso. In questa zona vengono utilizzati solo i metadati provenienti da altre zone e gli Object Gateway in essa contenuti non serviranno direttamente alcuna richiesta dell'utente finale.
11.7.1.2 Configurazione dei moduli di sincronizzazione
1. 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
2. È 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}
3. 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».
146 Sincronizzazione delle zone SES 5
4. Infine, aggiornare il periodo
root # radosgw-admin period update --commit
5. Adesso avviare radosgw nella zona
root # systemctl start ceph-radosgw@rgw.`hostname -s`
root # systemctl enable ceph-radosgw@rgw.`hostname -s`
11.7.2 Memorizzazione dei metadati in Elasticsearch
Questo modulo di sincronizzazione consente di scrivere in Elasticsearch i metadati provenienti da altre zone. A partire da Luminous, è il formato JSON dei campi dei dati che attualmente vengono memorizzati in Elasticsearch.
{
"_index" : "rgw-gold-ee5863d6", "_type" : "object",
"_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null", "_score" : 1.0,
"_source" : {
"bucket" : "testbucket123", "name" : "object1",
"mtime" : "2017-05-04T12:54:16.462Z", "etag" : "7ac66c0f148de9519b8bd264312c4d64"
} } }
147 Memorizzazione dei metadati in Elasticsearch SES 5
11.7.2.1 Parametri di configurazione di tipi di livelli Elasticsearch
endpoint
Specifica l'endpoint del server Elasticsearch cui accedere.
num_shards
(numero intero) Numero di partizioni che verranno configurate da Elasticsearch con l'ini-zializzazione della sincronizzazione sui dati. Dopo l'inil'ini-zializzazione non è possibile modi-ficare 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'inizia-lizzazione 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 ver-ranno indicizzati (operazione soggetta ad altre restrizioni), altrimenti verver-ranno 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'inizializza-zione della sincronizzadell'inizializza-zione.
148 Memorizzazione dei metadati in Elasticsearch SES 5
11.7.2.2 Interrogazioni dei metadati
Poiché adesso nel cluster Elasticsearch vengono memorizzati metadati di oggetti, è importante che l'endpoint di Elasticsearch non sia esposto in pubblico e che sia accessibile solo dagli ammi-nistratori del cluster. Ciò rappresenta un problema per l'esposizione delle interrogazioni dei me-tadati all'utente finale dato che è necessario che l'utente interroghi solo i propri meme-tadati 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 provve-dere 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 Ela-sticsearch. Tutte queste richieste devono essere inviate alla zona master dei metadati.
Ottenimento di un'interrogazione Elasticsearch
GET /BUCKET?query={query-expr}
parametri di richiesta:
max-keys: numero massimo di voci da restituire marker: marker di impaginazione
expression := [(]<arg> <op> <value> [)][<and|or> ...]
op è uno dei seguenti: <, <=, ==, >=, >
Ad esempio:
GET /?query=name==foo
Verranno restituite tutte le chiavi indicizzate per le quali l'utente dispone l'autorizzazione in lettura e vengono denominate "foo". L'output sarà un elenco di chiavi in XML simile alla risposta dei compartimenti dell'elenco S3.
Configurazione dei campi dei metadati personalizzati
Definire quali voci dei metadati personalizzati devono essere indicizzate (nel comparti-mento specificato) e quali sono i tipi di queste chiavi. Se si configura l'indicizzazione espli-cita 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.
149 Memorizzazione dei metadati in Elasticsearch SES 5
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 persona-lizzati 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
search: year;int, release-date;date, x-amz-meta-title;string
Eliminazione della configurazione dei metadati personalizzati
Eliminare la configurazione del compartimento dei metadati personalizzati.
DELETE /BUCKET?mdsearch
Ottenimento della configurazione dei metadati personalizzati
Recuperare la configurazione del compartimento dei metadati personalizzati.
GET /BUCKET?mdsearch
11.8 Autenticazione LDAP
Oltre all'autenticazione utente locale di default, con Object Gateway si possono utilizzare i ser-vizi del server LDAP per autenticare anche gli utenti.
11.8.1 Meccanismo di autenticazione
Object Gateway estrae le credenziali LDAP dell'utente da un token. Dal nome utente viene co-struito 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.
150 Autenticazione LDAP SES 5
11.8.2 Requisiti
LDAP o Active Directory: un'istanza LDAP in esecuzione accessibile da Object Gateway.
Account di servizio: credenziali LDAP che devono essere utilizzate da Object Gateway con autorizzazioni di ricerca.
Account utente: almeno un account utente nella directory LDAP.