21 Ceph Object Gateway #

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

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

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:

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

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:

Suggerimento: rimozione di un sottoutente

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:

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

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

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

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.

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.

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:

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
}

Suggerimento: maggiori informazioni

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

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

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

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

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))"

Nota: attributo memberOf

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

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:

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.

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:

Suggerimento

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

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:

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

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

Per consentire l'interazione tra Ceph Object Gateway e OpenStack Keystone, quest'ultimo può utilizzare un certificato SSL firmato da se stessi. Installare il certificato SSL di Keystone sul nodo sul quale è in esecuzione Ceph Object Gateway o in alternativa impostare il valore dell'opzione rgw keystone verify ssl su "false". L'impostazione di rgw keystone verify ssl su "false" significa che non verrà effettuato alcun tentativo di verifica del certificato da parte del gateway.

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

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

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

Suggerimento: mappatura ai tenant OpenStack

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

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

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

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

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

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

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

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

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

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

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>

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

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

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

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

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

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

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

Nota

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

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

Importante

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

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

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY

Nota

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

Importante

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

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

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

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

Importante

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

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

Avvertimento

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.

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

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

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

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

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

Nota

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

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

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

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

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

Nota

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

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

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

Esempio:

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

Importante

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

Eliminare la zona di default se necessario:

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

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

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

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

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

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

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

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

Nota

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

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

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

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

cephuser@adm > radosgw-admin sync status

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

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

Nota

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.

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.

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

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.

Importante

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

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

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

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