Se aplica a SUSE Enterprise Storage 7

21 Ceph Object Gateway #

En este capítulo se presentan las tareas de administración relacionadas con Object Gateway, como la comprobación del estado del servicio, la gestión de cuentas, las pasarelas de varios sitios o la autenticación LDAP.

21.1 Restricciones y limitaciones de denominación de Object Gateway #

A continuación encontrará una lista de limitaciones importantes de Object Gateway.

21.1.1 Limitaciones de los depósitos #

Cuando se accede a Object Gateway a través de la API de S3, los nombres de depósito deben ser nombres compatibles con DNS y solo se permite el carácter de guión "-". Cuando se accede a Object Gateway a través de la API de Swift, puede utilizar cualquier combinación de caracteres UTF-8 compatibles, excepto el carácter de barra "/". La longitud máxima de los nombres de depósito es de 255 caracteres. Los nombres de depósitos deben ser exclusivos.

Sugerencia: uso de nombres de depósitos compatibles con DNS

Aunque puede utilizar cualquier nombre de depósito basado en UTF-8 en la API de Swift, se recomienda respetar la limitación existente para los nombre en S3, a fin de evitar problemas al acceder al mismo depósito a través de la API de S3.

21.1.2 Limitaciones de los objetos almacenados #

Número máximo de objetos por usuario: No hay restricciones por defecto (limitado a ~2^63).
Número máximo de objetos por depósito: No hay restricciones por defecto (limitado a ~2^63).
Tamaño máximo de un objeto para cargar o almacenar: Las cargas sencillas están restringidas a 5 GB. Divida varias partes para objetos más grandes. El número máximo de porciones de varias partes es 10 000.

21.1.3 Limitaciones de los encabezados HTTP #

El encabezado HTTP y la limitación de la petición dependen de la interfaz Web que se utilice. La instancia por defecto de Beast restringe el tamaño del encabezado HTTP a 16 kB.

21.2 Distribución de Object Gateway #

La distribución de Ceph Object Gateway sigue el mismo procedimiento que la distribución de otros servicios de Ceph, mediante cephadm. Para obtener más información, consulte el Sección 5.4.2, “Especificación del servicio y la colocación”, específicamente el Sección 5.4.3.4, “Distribución de pasarelas Object Gateways”.

21.3 Funcionamiento del servicio de Object Gateway #

Puede utilizar las pasarelas Object Gateway de la misma forma que otros servicios de Ceph: identificando primero el nombre del servicio con el comando ceph orch ps y ejecutando el comando siguiente para los servicios operativos, por ejemplo:

ceph orch daemon restart OGW_SERVICE_NAME

Consulte el Capítulo 14, Funcionamiento de los servicios de Ceph para obtener información completa sobre el funcionamiento de los servicios de Ceph.

21.4 Opciones de configuración #

Consulte en la Sección 28.5, “Ceph Object Gateway” una lista de opciones de configuración de Object Gateway.

21.5 Gestión del acceso a Object Gateway #

Es posible comunicarse con Object Gateway mediante una interfaz compatible con S3 o con Swift. La interfaz de S3 es compatible con un gran subconjunto de la API RESTful de Amazon S3. La interfaz de Swift es compatible con un gran subconjunto de la API de OpenStack Swift.

Ambas interfaces requieren que cree un usuario específico y que instale el software cliente relevante para comunicarse con la pasarela mediante la clave de secreto del usuario.

21.5.1 Acceso a Object Gateway #

21.5.1.1 Acceso a la interfaz de S3 #

Para acceder a la interfaz de S3, necesita un cliente de REST. S3cmd es un cliente de S3 de línea de comandos. Lo encontrará en OpenSUSE Build Service. El repositorio contiene versiones tanto para SUSE Linux Enterprise como para distribuciones basadas en openSUSE.

Si desea probar el acceso a la interfaz de S3, también puede escribir un pequeño guion de Python. El guion se conectará con Object Gateway, creará un depósito nuevo y mostrará todos los depósitos. Los valores de aws_access_key_id y aws_secret_access_key se toman de los valores de access_key y secret_key devueltos por el comando radosgw_admin de la Sección 21.5.2.1, “Adición de usuarios de S3 y Swift”.

Instale el paquete python-boto:
```
root # zypper in python-boto
```

Cree un nuevo guion de Python denominado s3test.py con el siguiente contenido:

import boto
import boto.s3.connection
access_key = '11BS02LGFB6AL6H1ADMW'
secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'HOSTNAME',
is_secure=False,
calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
bucket = conn.create_bucket('my-new-bucket')
for bucket in conn.get_all_buckets():
  print "NAME\tCREATED".format(
  name = bucket.name,
  created = bucket.creation_date,
  )

Sustituya HOSTNAME por el nombre del host donde haya configurado el servicio de Object Gateway; por ejemplo gateway_host.

Ejecute el guion:
```
python s3test.py
```
El guion da como resultado algo parecido a lo siguiente:
```
my-new-bucket 2015-07-22T15:37:42.000Z
```

21.5.1.2 Acceso a la interfaz de Swift #

Para acceder a Object Gateway a través de una interfaz de Swift, necesita el cliente de línea de comandos swift. La página man 1 swift incluye más información sobre las opciones de la línea de comandos.

El paquete se incluye en el módulo "Nube pública" de SUSE Linux Enterprise 12 de la versión SP3 y en SUSE Linux Enterprise 15. Antes de instalar el paquete, debe activar el módulo y actualizar el repositorio de software:

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

O bien

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

Para instalar el comando swift, ejecute lo siguiente:

root # zypper in python-swiftclient

El acceso swift utiliza la sintaxis siguiente:

tux > swift -A http://IP_ADDRESS/auth/1.0 \
-U example_user:swift -K 'SWIFT_SECRET_KEY' list

Sustituya IP_ADDRESS por la dirección IP del servidor de pasarela, y SWIFT_SECRET_KEY por el valor de la clave de secreto de Swift que se obtiene al ejecutar el comando radosgw-admin key create para el usuario de swift en la Sección 21.5.2.1, “Adición de usuarios de S3 y Swift”.

Por ejemplo:

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

El resultado es:

my-new-bucket

21.5.2 Gestión de cuentas de S3 y Swift #

21.5.2.1 Adición de usuarios de S3 y Swift #

Debe crear un usuario, una clave de acceso y un secreto para permitir que los usuarios finales puedan interactuar con la pasarela. Existen dos tipos de usuarios: usuario y subusuario. Los usuarios se utilizan cuando se interactúa con la interfaz de S3, mientras que los subusuarios son usuarios de la interfaz de Swift. Cada subusuario está asociado a un usuario.

Para crear un usuario de Swift, siga estos pasos:

Para crear un usuario de Swift, que es un subusuario en nuestra terminología, debe crear primero el usuario asociado.

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

Por ejemplo:

cephuser@adm > radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

Para crear un subusuario (interfaz de Swift) para el usuario, debe especificar el ID de usuario (‑‑uid=USERNAME), el ID de subusuario y el nivel de acceso para el subusuario.

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

Por ejemplo:

cephuser@adm > radosgw-admin subuser create --uid=example_user \
 --subuser=example_user:swift --access=full

Genere una clave de secreto para el usuario.

cephuser@adm > radosgw-admin key create \
   --gen-secret \
   --subuser=example_user:swift \
   --key-type=swift

Ambos comandos darán como resultado datos con formato JSON que muestran el estado del usuario. Fíjese en las siguientes líneas y recuerde el valor de secret_key:
```
"swift_keys": [
   { "user": "example_user:swift",
     "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],
```

Cuando acceda a Object Gateway a través de la interfaz de S3, deberá crear un usuario de S3 ejecutando:

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

Por ejemplo:

cephuser@adm > radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

El comando también crea la clave de acceso y la clave de secreto del usuario. Compruebe el resultado de las palabras clave access_key y secret_key y sus valores correspondientes:

[...]
 "keys": [
       { "user": "example_user",
         "access_key": "11BS02LGFB6AL6H1ADMW",
         "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
 [...]

21.5.2.2 Eliminación de usuarios de S3 y Swift #

El procedimiento para suprimir usuarios es similar para los usuarios de S3 y de Swift. Pero en el caso de los usuarios de Swift, puede ser necesario suprimir el usuario incluyendo sus subusuarios.

Para eliminar un usuario de S3 o Swift (incluidos todos sus subusuarios), especifique user rm y el ID de usuario en el siguiente comando:

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

Para eliminar un subusuario, especifique subuser rm y el ID de subusuario.

cephuser@adm > radosgw-admin subuser rm --uid=example_user:swift

Puede usar las siguientes opciones:

--purge-data: Limpia todos los datos asociados al ID de usuario.
--purge-keys: Limpia todas las claves asociadas al ID de usuario.

Sugerencia: eliminación de un subusuario

Cuando se elimina un subusuario, se elimina el acceso a la interfaz de Swift. El usuario permanecerá en el sistema.

21.5.2.3 Cambio del acceso de usuario y las claves de secreto de S3 y Swift #

Los parámetros access_key y secret_key identifican al usuario de Object Gateway cuando se accede a la pasarela. Cambiar las claves de usuario existentes es igual a crear otras nuevas, ya que las claves antiguas se sobrescriben.

Para los usuarios de S3, ejecute lo siguiente:

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

Para los usuarios de Swift, ejecute lo siguiente:

cephuser@adm > radosgw-admin key create --subuser=EXAMPLE_USER:swift --key-type=swift --gen-secret

‑‑key-type=TYPE: Especifica el tipo de clave. Puede ser swift o s3.
--gen-access-key: Genera una clave de acceso aleatoria (por defecto, para el usuario de S3).
--gen-secret: Genera una clave de secreto aleatoria.
‑‑secret=KEY: Especifica una clave de secreto; por ejemplo, una generada manualmente.

21.5.2.4 Habilitación de la gestión de cuotas de usuario #

Ceph Object Gateway permite definir cuotas en usuarios y depósitos que pertenezcan a los usuarios. Las cuotas incluyen el número máximo de objetos de un depósito y el tamaño de almacenamiento máximo en megabytes.

Antes de habilitar una cuota de usuario, debe definir los parámetros correspondientes:

cephuser@adm > radosgw-admin quota set --quota-scope=user --uid=EXAMPLE_USER \
 --max-objects=1024 --max-size=1024

--max-objects: Especifica el número máximo de objetos. Un valor negativo inhabilita la comprobación.
--max-size: Especifica el número máximo de bytes. Un valor negativo inhabilita la comprobación.
--quota-scope: Define el ámbito para la cuota. Las opciones son depósito y usuario. Las cuotas de depósito se aplican a los depósitos que posee un usuario. Las cuotas de usuario se aplican a un usuario.

Una vez definida una cuota de usuario, se puede habilitar:

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

Para inhabilitar una cuota:

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

Para mostrar la configuración de la cuota:

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

Para actualizar las estadísticas de la cuota:

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

21.6 Procesadores frontales HTTP #

Ceph Object Gateway admite dos front-ends HTTP incrustados: Beast y Civetweb.

El front-end Beast utiliza la biblioteca Boost.Beast para el análisis HTTP y la biblioteca Boost.Asio para la E/S de red asincrónica.

El front-end Civetweb utiliza la biblioteca HTTP Civetweb, que es una derivación de Mongoose.

Puede configurarlos con la opción rgw_frontends. Consulte la Sección 28.5, “Ceph Object Gateway” para obtener una lista de las opciones de configuración.

21.7 Habilitación de HTTPS/SSL para pasarelas Object Gateway #

Para permitir que Object Gateway se pueda comunicar de forma segura mediante SSL, debe tener un certificado emitido por una CA o crear uno autofirmado.

21.7.1 Creación de certificados autofirmados #

Sugerencia

Omita esta sección si ya dispone de un certificado válido firmado por una CA.

El siguiente procedimiento describe cómo generar un certificado SSL autofirmado en el master de Salt.

Si necesita que identidades de sujeto adicionales conozcan Object Gateway, añádalas a la opción subjectAltName en la sección [v3_req] del archivo /etc/ssl/openssl.cnf:
```
[...]
[ v3_req ]
subjectAltName = DNS:server1.example.com DNS:server2.example.com
[...]
```
Sugerencia: direcciones IP en subjectAltName
Para utilizar direcciones IP en lugar de nombres de dominio en la opción subjectAltName, sustituya la línea de ejemplo por lo siguiente:
```
subjectAltName = IP:10.0.0.10 IP:10.0.0.11
```
Cree la clave y el certificado con openssl. Introduzca todos los datos que necesite incluir en el certificado. Es recomendable introducir el nombre completo como nombre común. Antes de firmar el certificado, verifique que en las extensiones pedidas se incluye "X509v3 Subject Alternative Name:" y que el certificado resultante tiene definido "X509v3 Subject Alternative Name:".
```
root@master # openssl req -x509 -nodes -days 1095 \
 -newkey rsa:4096 -keyout rgw.key
 -out rgw.pem
```
Añada la clave al final del archivo de certificado:
```
root@master # cat rgw.key >> rgw.pem
```

21.7.2 Configuración de Object Gateway con SSL #

Para configurar Object Gateway para que utilice certificados SSL, utilice la opción rgw_frontends. Por ejemplo:

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

Si no especifica las claves de configuración CERT y KEY, el servicio de Object Gateway buscará el certificado SSL y la clave en las siguientes claves de configuración:

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

Si desea anular la clave SSL por defecto y la ubicación del certificado, impórtelos a la base de datos de configuración mediante el comando siguiente:

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

A continuación, utilice las claves de configuración personalizadas mediante la directiva config://.

21.8 Módulos de sincronización #

Object Gateway se distribuye como un servicio multisitio y puede duplicar datos y metadatos entre las zonas. Los módulos de sincronización se crean sobre la infraestructura de varios sitios y permiten el envío de datos y metadatos a un nivel externo diferente. Con un módulo de sincronización es posible realizar un conjunto de acciones siempre que se produzca un cambio en los datos (por ejemplo, las operaciones de metadatos como la creación de depósitos o usuarios). Como los cambios en varios sitios de Object Gateway al final acaban siendo consistentes en los sitios remotos, estos cambios se propagan de forma asíncrona. Esto cubre situaciones de uso como realizar una copia de seguridad del almacenamiento de objetos en un clúster de nube externa o una solución de copia de seguridad personalizada mediante unidades de cinta; o también indexar metadatos en ElasticSearch,

21.8.1 Configuración de módulos de sincronización #

Todos los módulos de sincronización se configuran de forma similar. Debe crear una zona nueva (consulte la Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener más detalles) y defina su opción ‑‑tier_type, por ejemplo ‑‑tier-type-cloud para el módulo de sincronización en la nube:

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

Puede configurar el nivel específico mediante el siguiente comando:

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

El elemento KEY de la configuración especifica la variable de configuración que desea actualizar y VALUE especifica su nuevo valor. Es posible acceder a los valores anidados usando un punto. Por ejemplo:

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

Puede acceder a las entradas de matriz añadiendo corchetes "[]" detrás de la entrada a la que se hace referencia. Es posible añadir una entrada de matriz nueva utilizando corchetes "[]". El valor de índice de -1 hace referencia a la última entrada de la matriz. No es posible crear una entrada nueva y volver a hacer referencia a ella en el mismo comando. Por ejemplo, se muestra un comando para crear un perfil nuevo para depósitos que empiecen con PREFIX:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID

Sugerencia: adición y eliminación de entradas de configuración

Puede añadir una nueva entrada de configuración de nivel con el parámetro ‑‑tier-config-add=KEY=VALUE.

Para quitar una entrada existente, use ‑‑tier-config-rm=KEY.

21.8.2 Sincronización de zonas #

La configuración del módulo de sincronización es local en una zona. El módulo de sincronización determina si la zona exporta los datos o si solo puede utilizar los datos que se ha modificado en otra zona. A partir de la versión Luminous, los complementos de sincronización compatibles son ElasticSearch, rgw (el complemento por defecto que sincroniza los datos entre las zonas) y log, un complemento de sincronización trivial que registra la operación de metadatos que se produce en las zonas remotas. Las secciones siguientes muestran como ejemplo una zona con el módulo de sincronización ElasticSearch. El proceso será similar para configurar cualquier otro complemento de sincronización.

Nota: complemento de sincronización por defecto

El complemento de sincronización por defecto es rgw y no es necesario configurarlo de forma explícita.

21.8.2.1 Requisitos y supuestos #

Supongamos que tenemos una configuración sencilla de varios sitios, descrita en la Sección 21.13, “Pasarelas Object Gateway de varios sitios”, formada por 2 zonas: us-east y us-west. Se añade una tercera zona us-east-es, que es una zona que solo procesa metadatos de los otros sitios. Esta zona puede estar en el mismo clúster de Ceph o en uno distinto a us-east. Esta zona solo consumirá metadatos de otras zonas y la pasarela Object Gateway de esta zona no atenderá directamente a ninguna petición del usuario final.

21.8.2.2 Configuración de zonas #

Cree una tercera zona similar a la que se describe en la Sección 21.13, “Pasarelas Object Gateway de varios sitios”, por ejemplo:

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
--access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80

Puede configurar un módulo de sincronización para esta zona así:

cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
--tier-config={set of key=value pairs}

Por ejemplo, en el módulo de sincronización ElasticSearch:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \
--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
```
Para las distintas opciones de configuración de niveles admitidas, consulte la Sección 21.8.3, “Módulo de sincronización ElasticSearch”.

Por último, actualice el período:

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

Inicie ahora Object Gateway en la zona:

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

21.8.3 Módulo de sincronización ElasticSearch #

Este módulo de sincronización escribe los metadatos de otras zonas en ElasticSearch. A partir de la versión Luminous, este es el código JSON de campos de datos que se almacenan en ElasticSearch.

{
  "_index" : "rgw-gold-ee5863d6",
  "_type" : "object",
  "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null",
  "_score" : 1.0,
  "_source" : {
    "bucket" : "testbucket123",
    "name" : "object1",
    "instance" : "null",
    "versioned_epoch" : 0,
    "owner" : {
      "id" : "user1",
      "display_name" : "user1"
    },
    "permissions" : [
      "user1"
    ],
    "meta" : {
      "size" : 712354,
      "mtime" : "2017-05-04T12:54:16.462Z",
      "etag" : "7ac66c0f148de9519b8bd264312c4d64"
    }
  }
}

21.8.3.1 Parámetros de configuración de tipo de nivel de ElasticSearch #

endpoint: Especifica el puesto final del servidor de ElasticSearch al que se accede.
num_shards: (número entero) El número de particiones con las que se configurará ElasticSearch al inicializar la sincronización de datos. Tenga en cuenta que este valor no se puede cambiar después de la inicialización. Cualquier cambio que se haga aquí requiere que se vuelva a crear el índice de ElasticSearch y se reinicialice el proceso de sincronización de datos.
num_replicas: (número entero) El número de réplicas con las que se configurará ElasticSearch al inicializar la sincronización de datos.
explicit_custom_meta: (true | false) Especifica si se indexarán todos los metadatos personalizados del usuario, o si el usuario deberá configurar (en el nivel de depósitos) las entradas de metadatos del cliente que se deben indexar. La opción por defecto es "false" (falso).
index_buckets_list: (lista de cadenas separadas por comas) Si está vacío, todos los depósitos se indexarán. De lo contrario, solo se indexarán los depósitos que se especifiquen aquí. Es posible proporcionar prefijos de depósito (por ejemplo, "foo*") o sufijos de depósito (por ejemplo, "*bar").
approved_owners_list: (lista de cadenas separadas por comas) Si está vacío, se indexarán los depósitos de todos los propietarios (esto está sujeto a otras restricciones). En caso contrario, se indexarán solo los depósitos de los propietarios especificados. También es posible proporcionar prefijos y sufijos.
override_index_path: (cadena) Si no está vacío, esta cadena se utilizará como la vía de índice de ElasticSearch. De lo contrario, la vía de índice se determinará y se generará durante la inicialización de la sincronización.
username: Indica un nombre de usuario para ElasticSearch si se requiere autenticación.
password: Indica una contraseña para ElasticSearch si se requiere autenticación.

21.8.3.2 Consultas de metadatos #

Dado que el clúster de ElasticSearch almacena ahora metadatos de objeto, es importante que el puesto final de ElasticSearch no esté expuesto al público y solo puedan acceder los administradores de clúster. Exponer las consultas de metadatos a los usuarios finales plantea un problema, ya que queremos que los usuarios solo puedan consultar sus propios metadatos y no los de otros usuarios. Esto último requeriría que el clúster de ElasticSearch autenticara a los usuarios de forma similar a como lo hace RGW, lo que supone un problema.

A partir de la versión Luminous, la instancia de RGW de la zona principal de metadatos puede atender a las peticiones del usuario final. De este modo, no se expone el puesto final de ElasticSearch al público y también se resuelve el problema de la autenticación y la autorización, ya que RGW realiza estas labores para las peticiones del usuario final. Por este motivo, RGW presenta una nueva consulta en las API de depósito que pueden atender las peticiones de ElasticSearch. Todas estas peticiones deben enviarse a la zona principal de metadatos.

Cómo obtener una consulta de ElasticSearch

GET /BUCKET?query=QUERY-EXPR

Parámetros de la petición:

max-keys: el número máximo de entradas que se deben devolver.
marker: el marcador de paginación.

expression := [(]<arg> <op> <value> [)][<and|or> ...]

El operador "op" es uno de los siguientes: <, <=, ==, >=, >

Por ejemplo:

GET /?query=name==foo

devolverá todas las claves indexadas para las que el usuario tiene permiso de lectura y que tienen como nombre "foo". El resultado será una lista de claves en formato XML similar a la respuesta de lista de depósitos de S3.

Cómo configurar campos de metadatos personalizados

Defina las entradas de metadatos personalizados que se deben indexar (en el depósito especificado) y cuáles son los tipos de estas claves. Si se ha configurado el indexado explícito de metadatos personalizados, esto es obligatorio para que rgw indexe los valores de los metadatos personalizados especificados. También es necesario en casos en los que las claves de metadatos indexadas sean de un tipo distinto a cadena.

POST /BUCKET?mdsearch
x-amz-meta-search: <key [; type]> [, ...]

Si hay varios campos de metadatos, deben separarse con comas. Es posible aplicar un tipo para un campo con punto y coma ";". Los tipos permitidos actualmente son string (valor por defecto), integer y date. Por ejemplo, si desea indexar un metadato de objeto personalizado x-amz-meta-year como int, x-amz-meta-date como fecha de tipo y x-amz-meta-title como cadena, debería hacer lo siguiente:

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

Cómo suprimir una configuración personalizada de metadatos

Puede suprimir una configuración personalizada de metadatos.

DELETE /BUCKET?mdsearch

Cómo obtener una configuración personalizada de metadatos

Puede recuperar una configuración personalizada de metadatos.

GET /BUCKET?mdsearch

21.8.4 Módulo de sincronización en la nube #

En esta sección se presenta un módulo que sincroniza los datos de zona con un servicio remoto en la nube. La sincronización es unidireccional: la fecha no se sincroniza de nuevo desde la zona remota. El objetivo principal de este módulo es habilitar la sincronización de datos con varios proveedores de servicios en la nube. Actualmente es compatible con proveedores de nube compatibles con AWS (S3).

Para sincronizar los datos con un servicio remoto en la nube, debe configurar las credenciales de usuario. Dado que muchos servicios en la nube incluyen límites en el número de depósitos que puede crear cada usuario, es posible configurar la asignación de objetos y depósitos de origen, diferentes destinos para a distintos depósitos y prefijos de depósito. Tenga en cuenta que las listas de acceso de origen (ACL) no se conservarán. Es posible asignar permisos de usuarios de origen específicos a usuarios de destino concretos.

Debido a las limitaciones de la API, no hay manera de conservar la hora de modificación del objeto original ni la etiqueta de entidad HTTP (ETag). El módulo de sincronización en la nube los almacena como atributos de metadatos en los objetos de destino.

21.8.4.1 Configuración del módulo de sincronización en la nube #

A continuación se muestran ejemplos de una configuración trivial y no trivial para el módulo de sincronización en la nube. Tenga en cuenta que la configuración trivial puede presentar conflictos con la no trivial.

Ejemplo 21.1: Configuración trivial #

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

Ejemplo 21.2: Configuración no trivial #

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

A continuación se explican los términos de configuración utilizados:

connection

Representa una conexión con el servicio remoto en la nube. Contiene "connection_id", "access_key", "secret", "endpoint" y "host_style".

access_key

La clave de acceso remoto a la nube que se usará para la conexión específica.

secret

La clave secreta para el servicio remoto en la nube.

endpoint

Dirección URL del puesto final del servicio remoto en la nube.

host_style

El tipo de estilo del host ("path" o "virtual") que se usará al acceder de forma remota al puesto final en la nube. El valor por defecto es "path".

acls

La matriz de asignaciones de la lista de acceso.

acl_mapping

Cada estructura "acl_mapping" contiene "type", "source_id" y "dest_id". Estos elementos definen la mutación de la ACL para cada objeto. Una mutación de la ACL permite convertir el ID de usuario de origen en un ID de destino.

type

El tipo de ACL: "id" define el ID de usuario, "email" define al usuario por correo electrónico y "uri" define al usuario por uri (grupo).

source_id

El ID de usuario en la zona de origen.

dest_id

El ID de usuario en el destino.

target_path

Cadena que define cómo se crea la vía de destino. La vía de destino especifica un prefijo al que se anexa el nombre del objeto de origen. La vía de destino configurable puede incluir cualquiera de las variables siguientes:

SID: Una cadena exclusiva que representa el ID de instancia de sincronización.
ZONEGROUP: El nombre del grupo de zonas.
ZONEGROUP_ID: El ID de grupo de zonas.
ZONE: Nombre de zona.
ZONE_ID: El ID de zona.
BUCKET: El nombre del depósito de origen.
OWNER: El ID de propietario del depósito de origen.

Por ejemplo: target_path = rgwx-ZONA-SID/PROPIETARIO/DEPÓSITO

acl_profiles

Una matriz de perfiles de lista de acceso.

acl_profile

Cada perfil contiene "acls_id", que representa el perfil y una matriz "acls" que contiene una lista "acl_mappings".

profiles

Una lista de perfiles. Cada perfil contiene lo siguiente:

source_bucket: Un nombre de depósito o un prefijo de depósito (si termina con *) que define los depósitos de origen para este perfil.
target_path: Consulte arriba la explicación.
connection_id: El ID de la conexión que se utilizará para este perfil.
acls_id: El ID del perfil de ACL que se utilizará para este perfil.

21.8.4.2 Elementos configurables específicos de S3 #

El módulo de sincronización en la nube solo funciona con back-ends compatibles con AWS S3. Hay algunos elementos configurables que se pueden utilizar para ajustar su comportamiento al acceder a los servicios en la nube de S3:

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

multipart_sync_threshold: Los objetos cuyo tamaño sea igual o mayor que este valor se sincronizarán con el servicio en la nube mediante la carga de varias partes.
multipart_min_part_size: El tamaño mínimo de las partes que se debe utilizar al sincronizar objetos mediante la carga de varias partes.

21.8.5 Módulo de sincronización de archivador #

El módulo archive sync module usa la característica de control de versiones de objetos S3 en Object Gateway. Puede configurar una zona de archivador que capture las diferentes versiones de los objetos S3 a medida que se producen en otras zonas. El historial de versiones que conserva la zona de archivador solo se puede eliminar a través de pasarelas asociadas con la zona de archivador.

Con esta arquitectura, es posible que varias zonas sin versiones pueden duplicar sus datos y metadatos a través de sus pasarelas de zona, lo que proporciona alta disponibilidad a los usuarios finales, mientras que la zona de archivador captura todas las actualizaciones de datos para consolidarlos como versiones de objetos S3.

Al incluir la zona de archivador en una configuración multizona, se consigue la flexibilidad de un historial de objetos dS3 en una zona, al tiempo que se ahorra el espacio que las réplicas de los objetos S3 versionados consumirían en las zonas restantes.

21.8.5.1 Configuración del módulo de sincronización de archivador #

Sugerencia: más información

Consulte la Sección 21.13, “Pasarelas Object Gateway de varios sitios” para obtener más información sobre la configuración de pasarelas de varios sitios.

Consulte la Sección 21.8, “Módulos de sincronización” para obtener información detallada sobre cómo configurar los módulos de sincronización.

Para utilizar el módulo de sincronización de archivador, debe crear una zona nueva cuyo tipo de nivel esté definido como archive:

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

21.9 Autenticación LDAP #

Aparte de la autenticación de usuario local por defecto, Object Gateway también puede utilizar servicios del servidor LDAP para autenticar a los usuarios.

21.9.1 Mecanismo de autenticación #

Object Gateway extrae las credenciales LDAP del usuario de un testigo. Se construye un filtro de búsqueda a partir del nombre de usuario. Object Gateway utiliza la cuenta del servicio configurado para buscar una entrada que coincida en el directorio. Si se encuentra una entrada, Object Gateway intenta vincularse al nombre completo encontrado con la contraseña del testigo. Si las credenciales son válidas, la vinculación se realizará correctamente y Object Gateway otorgará acceso.

Puede limitar los usuarios permitidos estableciendo como base para la búsqueda una unidad organizativa específica o especificando un filtro de búsqueda personalizado; por ejemplo, un filtro que requiera la pertenencia a un grupo específico, clases de objetos personalizados o atributos.

21.9.2 Requisitos #

LDAP o Active Directory: una instancia de LDAP en ejecución a la que Object Gateway pueda acceder.
Cuenta de servicio: credenciales LDAP que utilizará Object Gateway con los permisos de búsqueda.
Cuenta de usuario: al menos una cuenta de usuario en el directorio LDAP.

Importante: LDAP y los usuarios locales no se deben solapar

No debe utilizar los mismos nombres de usuario para los usuarios locales y los usuarios que se van a autenticar mediante LDAP. Object Gateway no puede distinguirlos y los trata como el mismo usuario.

Sugerencia: comprobaciones de estado

Emplee la utilidad ldapsearch para verificar la cuenta de servicio o la conexión LDAP. Por ejemplo:

tux > 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

Asegúrese de utilizar los mismos parámetros LDAP del archivo de configuración de Ceph para eliminar posibles problemas.

21.9.3 Configuración de Object Gateway para utilizar la autenticación LDAP #

Los siguientes parámetros están relacionados con la autenticación LDAP:

rgw_ldap_uri: Especifica el servidor LDAP que se debe usar. Asegúrese de usar el parámetro ldaps://nombre_completo:puerto para evitar la transmisión de credenciales de forma abierta en formato de texto sin cifrar.
rgw_ldap_binddn: El nombre completo (DN) de la cuenta de servicio que utiliza Object Gateway.
rgw_ldap_secret: La contraseña de la cuenta de servicio.
rgw_ldap_searchdn: Especifica la base en el árbol de información del directorio para buscar usuarios. Puede tratarse de la unidad organizativa de los usuarios o alguna unidad organizativa (OU) más específica.
rgw_ldap_dnattr: El atributo que se utiliza en el filtro de búsqueda construido para que coincida con un nombre de usuario. Dependiendo de su árbol de información de directorio (DIT), probablemente será uid o cn.
rgw_search_filter: Si no se especifica, Object Gateway crea automáticamente el filtro de búsqueda con el valor rgw_ldap_dnattr. Este parámetro se puede usar para restringir la lista de usuarios permitidos de formas muy flexibles. Consulte la Sección 21.9.4, “Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario” para obtener más información.

21.9.4 Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario #

Existen dos formas de utilizar el parámetro rgw_search_filter.

21.9.4.2 Filtro completo #

Un filtro completo debe contener un testigo USERNAME que se sustituirá por el nombre de usuario durante el intento de autenticación. El parámetro rgw_ldap_dnattr ya no se usa en este caso. Por ejemplo, para limitar los usuarios válidos a un grupo específico, utilice el filtro siguiente:

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

Nota: atributo memberOf

Para poder usar el atributo memberOf en las búsquedas LDAP se requiere compatibilidad en el servidor LDAP específico implementado.

21.9.5 Generación de un testigo de acceso para la autenticación LDAP #

La utilidad radosgw-token genera el testigo de acceso en función del nombre de usuario y la contraseña LDAP. Cree una cadena codificada en base 64 que es el testigo de acceso real. Utilice su cliente de S3 favorito (consulte la Sección 21.5.1, “Acceso a Object Gateway”) y especifique el testigo como clave de acceso y utilice una clave de secreto vacía.

tux > export RGW_ACCESS_KEY_ID="USERNAME"
tux > export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap

Importante: credenciales en texto no cifrado

El testigo de acceso es una estructura JSON codificada en base 64 y contiene las credenciales LDAP en texto sin cifrar.

Nota: Active Directory

Para Active Directory, utilice el parámetro ‑‑type=ad.

21.10 Partición del índice de depósito #

Object Gateway almacena los datos del índice de depósito en un repositorio de índice, que usa por defecto .rgw.buckets.index. Si coloca demasiados objetos (cientos de miles) en un único depósito y no se define la cuota del número máximo de objetos por depósito (rgw bucket default quota max objects), el rendimiento del repositorio de índice se puede degradar. La partición del índice de depósito evita esa disminución del rendimiento y permite un número elevado de objetos por depósito.

21.10.1 Nueva partición del índice de depósito #

Si un depósito ha crecido mucho y su configuración inicial ya no es suficiente, es preciso volver a partir el repositorio de índice del depósito. Se puede usar la partición de índice de depósito en línea automática (consulte la Sección 21.10.1.1, “Partición dinámica”, o partir el índice de depósito manualmente sin conexión (consulte la Sección 21.10.1.2, “Partición manual”).

21.10.1.1 Partición dinámica #

Desde SUSE Enterprise Storage 5, se admite la partición de depósito en línea. Esto detecta si el número de objetos por depósito alcanza un umbral determinado y aumenta automáticamente el número de particiones utilizado por el índice de depósito. Este proceso reduce el número de entradas de cada partición de índice de depósito.

El proceso de detección se ejecuta en estos casos:

Cuando se añaden nuevos objetos al depósito.
En un proceso en segundo plano que explora periódicamente todos los depósitos. Esto es necesario para tratar con los depósitos existentes que no se van a actualizar.

Si un depósito requiere partición, se añade a la cola reshard_log y se programa para su partición más tarde. Los hilos de partición se ejecutan en segundo plano y ejecutan la partición programada de una en una.

Configuración de la partición dinámica #

rgw_dynamic_resharding: Habilita o inhabilita la partición del índice de depósito dinámica. Los valores válidos son "true" (verdadero) o "false" (falso). Por defecto es "true" (verdadero).
rgw_reshard_num_logs: El número de particiones para el registro. Se usa el valor por defecto de 16.
rgw_reshard_bucket_lock_duration: Duración del bloqueo en el objeto de depósito durante la partición. Se usa el valor por defecto de 120 segundos.
rgw_max_objs_per_shard: El número máximo de objetos por partición de índice de depósito. Por defecto es 100 000 objetos.
rgw_reshard_thread_interval: El tiempo máximo entre las rondas de procesamiento de hilos de partición. Se usa el valor por defecto de 600 segundos.

Comandos para administrar el proceso de partición #

Añadir un depósito a la cola de partición:

cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS

Mostrar la cola de partición:

cephuser@adm > radosgw-admin reshard list

Procesar o programar una partición de depósito:

cephuser@adm > radosgw-admin reshard process

Mostrar el estado de partición del depósito:

cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME

Cancelar las particiones de depósito pendientes:

cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 Partición manual #

La partición dinámica mencionada en la Sección 21.10.1.1, “Partición dinámica” solo se admite en configuraciones sencilla de Object Gateway. Para las configuraciones de varios sitios, utilice la partición manual que se describe en esta sección.

Para particionar manualmente el índice de depósito sin conexión, utilice el comando siguiente:

cephuser@adm > radosgw-admin bucket reshard

El comando bucket reshard realiza las acciones siguientes:

Crea un nuevo conjunto de objetos de índice de depósito para el objeto especificado.
Distribuye todas las entradas de estos objetos de índice.
Crea una nueva instancia del depósito.
Enlaza la nueva instancia del depósito con el depósito para que todas las operaciones de índice nuevas pasen por los nuevos índices de depósito.
Imprime el ID de depósito antiguo y el nuevo en una salida estándar.

Sugerencia

Cuando elija un número de particiones, tenga en cuenta lo siguiente: no debe haber más de 100.000 entradas por partición. Las particiones del índice de depósito que son números primos tienden a funcionar mejor para distribuir uniformemente las entradas de índice de depósito entre las particiones. Por ejemplo, tener 503 particiones de índice de depósito es mejor que tener 500, ya que 503 es un número primo.

Procedimiento 21.1: partición del índice de depósito #

Asegúrese de que se han detenido todas las operaciones dirigidas al depósito.

Realice una copia de seguridad del índice de depósito original:

cephuser@adm > radosgw-admin bi list \
 --bucket=BUCKET_NAME \
 > BUCKET_NAME.list.backup

Vuelva a particionar el índice de depósito:
```
 cephuser@adm > radosgw-admin bucket reshard \
 --bucket=BUCKET_NAME \
 --num-shards=NEW_SHARDS_NUMBER
```
Sugerencia: ID de depósito antiguo
Como parte del resultado, este comando también imprime los ID nuevo y antiguo.

21.10.2 Partición de índice de depósito para depósitos nuevos #

Existen dos opciones que afectan a la partición de índice de depósito:

Utilice la opción rgw_override_bucket_index_max_shards para las configuraciones sencillas.
Utilice la opción bucket_index_max_shards para las configuraciones de varios sitios.

Si se define el valor 0 en las opciones, se inhabilita la partición de índice de depósito. Un valor mayor que 0 permite la partición de índice de depósito y establece el número máximo de particiones.

La fórmula siguiente le permitirá calcular el número recomendado de particiones:

number_of_objects_expected_in_a_bucket / 100000

Tenga en cuenta que el número máximo de particiones es de 7877.

21.10.2.1 Configuraciones de varios sitios #

Las configuraciones de varios sitios pueden tener un repositorio de índice diferente para gestionar el failover. Para configurar un número de particiones coherente para las zonas de un grupo de zonas, defina la opción bucket_index_max_shards en la configuración del grupo de zonas:

Exporte la configuración del grupo de zonas al archivo zonegroup.json:
```
cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
```
Edite el archivo zonegroup.json y defina la opción bucket_index_max_shards para cada zona con nombre.

Restablezca el grupo de zonas:

cephuser@adm > radosgw-admin zonegroup set < zonegroup.json

Actualice el período. Consulte la Sección 21.13.2.6, “Actualice el período”.

21.11 Integración con OpenStack Keystone #

OpenStack Keystone es un servicio de identidad para el producto OpenStack. Puede integrar Object Gateway con Keystone a fin de configurar una pasarela que acepte un testigo de autenticación de Keystone. Un usuario autorizado por Keystone para acceder a la pasarela se verificará en Ceph Object Gateway y, si fuera necesario, se creará automáticamente. Object Gateway pide periódicamente a Keystone una lista de los testigos revocados.

21.11.1 Configuración de OpenStack #

Antes de configurar Ceph Object Gateway, debe configurar OpenStack Keystone para habilitar el servicio de Swift y dirigirlo a Ceph Object Gateway:

Defina el servicio de Swift.Para utilizar OpenStack a fin de validar usuarios de Swift, cree primero el servicio de Swift:
```
tux > openstack service create \
 --name=swift \
 --description="Swift Service" \
 object-store
```

Defina los puestos finales.Después de crear el servicio de Swift, diríjalo a Ceph Object Gateway. Sustituya REGION_NAME por el nombre del grupo de zonas o el nombre de la región de la pasarela.

tux > 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

Verifique los ajustes.Después de crear el servicio de Swift y definir los puestos finales, muestre los puestos finales para verificar que todos los valores son correctos.
```
tux > openstack endpoint show object-store
```

21.11.2 Configuración de Ceph Object Gateway #

21.11.2.1 Configuración de certificados SSL #

Ceph Object Gateway pide periódicamente a Keystone una lista de los testigos revocados. Estas peticiones están codificadas y firmadas. Keystone también puede configurarse para que proporcione testigos autofirmados, que también están codificados y firmados. Debe configurar la pasarela para que pueda descodificar y verificar estos mensajes firmados. Por lo tanto, los certificados OpenSSL que Keystone utiliza para crear las peticiones deben convertirse al formato "nss db":

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

Para permitir que Ceph Object Gateway interactúe con OpenStack Keystone, OpenStack Keystone puede utilizar un certificado SSL autofirmado. Instale el certificado SSL de Keystone en el nodo donde se ejecuta Ceph Object Gateway o, de forma alternativa, defina el valor de la opción rgw keystone verify ssl como "false" (falso). Si define rgw keystone verify ssl como "false", la pasarela no intentará verificar el certificado.

21.11.2.2 Configuración de las opciones de Object Gateway #

Puede configurar la integración de Keystone utilizando las siguientes opciones:

rgw keystone api version: Versión de la API de Keystone. Las opciones válidas son 2 o 3. Se usa el valor por defecto de 2.
rgw keystone url: La URL y el número de puerto de la API RESTful administrativa en el servidor de Keystone. Sigue el patrón URL_SERVIDOR:NÚMERO_PUERTO.
rgw keystone admin token: El testigo o secreto compartido que se configura internamente en Keystone para las peticiones administrativas.
rgw keystone accepted roles: Las funciones necesarias para atender las peticiones. Por defecto es "Member, admin".
rgw keystone accepted admin roles: La lista de funciones que permiten a un usuario obtener privilegios administrativos.
rgw keystone token cache size: El número máximo de entradas en el caché de testigo de Keystone.
rgw keystone revocation interval: El número de segundos antes de comprobar los testigos revocados. Por defecto es 15 * 60.
rgw keystone implicit tenants: Crea nuevos usuarios en sus propios inquilinos del mismo nombre. Se usa el valor por defecto, "false" (falso).
rgw s3 auth use keystone: Si se establece como "true" (verdadero), Ceph Object Gateway autenticará a los usuarios mediante Keystone. Se usa el valor por defecto, "false" (falso).
nss db path: La vía a la base de datos NSS.

También es posible configurar el inquilino del servicio de Keystone, el usuario y la contraseña para Keystone (para la versión 2.0 de la API de identidades de OpenStack), de modo similar a cómo se suelen configurar los servicios de OpenStack. De este modo, puede evitar establecer el secreto compartido rgw keystone admin token en el archivo de configuración, que se debe inhabilitar en entornos de producción. Las credenciales del inquilino de servicio deben tener privilegios de administrador. Para obtener más información, consulte la documentación oficial de OpenStack Keystone. A continuación se muestran las opciones de configuración relacionadas:

rgw keystone admin user: El nombre de usuario del administrador de Keystone.
rgw keystone admin password: La contraseña del usuario administrador de Keystone.
rgw keystone admin tenant: El inquilino del usuario administrador de Keystone versión 2.0.

Se asigna un usuario de Ceph Object Gateway a un inquilino de Keystone. Un usuario de Keystone tiene diferentes funciones asignadas, posiblemente en más de un inquilino. Cuando Ceph Object Gateway obtiene el ticket, busca en las funciones de inquilino y usuario que se han asignado a dicho ticket y acepta o rechaza la petición de acuerdo con el valor de la opción rgw keystone accepted roles.

Sugerencia: asignación a inquilinos de OpenStack

Aunque los inquilinos de Swift se asignan por defecto al usuario de Object Gateway, también pueden asignarse a inquilinos de OpenStack mediante la opción rgw keystone implicit tenants. Esto hará que los contenedores usen el espacio de nombres del inquilino en lugar del espacio de nombres global de S3, que es la opción por defecto de Object Gateway. Se recomienda decidir de antemano el método de asignación en la fase de planificación para evitar confusiones. La razón es que si se cambia la opción más tarde, solo se verán afectadas las peticiones nuevas que se asignen bajo un inquilino, mientras que los depósitos antiguos creados anteriormente seguirán en el espacio de nombres global.

En la versión 3 de la API de identidades de OpenStack, deber sustituir la opción rgw keystone admin tenant por:

rgw keystone admin domain: El dominio de usuario administrador de Keystone.
rgw keystone admin project: El proyecto de usuario administrador de Keystone.

21.12 Colocación de repositorios y clases de almacenamiento #

21.12.1 Visualización de destinos de colocación #

Los destinos de colocación controlan qué repositorios están asociados con un depósito determinado. El destino de colocación de un depósito se selecciona durante la creación y no se puede modificar. Es posible mostrar su valor de placement_rule ejecutando el siguiente comando:

cephuser@adm > radosgw-admin bucket stats

La configuración del grupo de zonas contiene una lista de destinos de colocación con un destino inicial denominado "default-placement". A continuación, la configuración de zona asigna cada nombre de destino de la colocación del grupo de zona a su almacenamiento local. Esta información de colocación de zona incluye el nombre "index_pool" para el índice del depósito, el nombre "data_extra_pool" para los metadatos sobre cargas de varias incompletas y un nombre de "data_pool" para cada clase de almacenamiento.

21.12.2 Clases de almacenamiento #

Las clases de almacenamiento ayudan a personalizar la colocación de los datos de objeto. Las reglas del ciclo de vida del depósito S3 pueden automatizar la transición de objetos entre clases de almacenamiento.

Las clases de almacenamiento se definen en términos de destinos de colocación. Cada destino de colocación de grupo de zonas muestra sus clases de almacenamiento disponibles con una clase inicial denominada "STANDARD". La configuración de zona es responsable de proporcionar un nombre de repositorio "data_pool" para cada una de las clases de almacenamiento del grupo de zonas.

21.12.3 Configuración de grupos de zonas y zonas #

Utilice el comando radosgw-admin en los grupos de zona y las zonas para configurar su colocación. Puede consultar la configuración de la colocación del grupo de zonas con el comando siguiente:

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

Para consultar la configuración de colocación de la zona, ejecute:

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

Nota: sin configuración de varios sitios anterior

Si no ha realizado ninguna configuración de varios sitios anterior, se crean automáticamente una zona por defecto ("default") y un grupo de zonas. Los cambios en el grupo de zonas o las zonas no tendrán efecto hasta que reinicie Ceph Object Gateway. Si ha creado un reino para varios sitios, los cambios de la zona o el grupo de zonas surtirán efecto después de confirmar los cambios con el comando radosgw-admin period update ‑‑commit.

21.12.3.1 Adición de un destino de colocación #

Para crear un nuevo destino de colocación denominado "temporary", comience añadiéndolo al grupo de zonas:

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

A continuación, proporcione la información de colocación de zona para ese destino:

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

21.12.3.2 Adición de una clase de almacenamiento #

Para añadir una nueva clase de almacenamiento denominada "COLD" al destino "default-placement", empiece añadiéndola al grupo de zonas:

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

A continuación, proporcione la información de colocación de zona para esa clase de almacenamiento:

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

21.12.4 Personalización de colocación #

21.12.4.1 Edición de la colocación del grupo de zonas por defecto #

Por defecto, los nuevos depósitos utilizan el destino default_placement del grupo de zonas. Puede cambiar este valor del grupo de zonas con:

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

21.12.4.2 Edición de la colocación del usuario por defecto #

Un usuario de Ceph Object Gateway puede sustituir el destino de la colocación por defecto del grupo de zonas definiendo un campo default_placement no vacío en la información del usuario. De forma similar, el valor de default_storage_class puede sustituir la clase de almacenamiento STANDARD aplicada a los objetos por defecto.

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

Si el destino de colocación de un grupo de zonas contiene etiquetas, los usuarios no podrán crear depósitos con ese destino de colocación a menos que su información de usuario contenga al menos una etiqueta que coincida en su campo "placement_tags". Esto puede ser útil para restringir el acceso a ciertos tipos de almacenamiento.

El comando radosgw-admin no puede modificar estos campos directamente; por lo tanto, debe editar el formato JSON manualmente:

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

21.12.4.3 Edición de la colocación del depósito por S3 por defecto #

Al crear un depósito con el protocolo S3, es posible proporcionar un destino de colocación como parte de LocationConstraint para sustituir los destinos de colocación por defecto del usuario y del grupo de zonas.

Normalmente, LocationConstraint debe coincidir con el valor de api_name del grupo de zonas:

<LocationConstraint>default</LocationConstraint>

Puede añadir un destino de colocación personalizado a api_name detrás de un signo de dos puntos:

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

21.12.4.4 Edición de la colocación del depósito por Swift #

Cuando se crea un depósito con el protocolo Swift, es posible proporcionar un destino de colocación en el parámetro X-Storage-Policy del encabezado HTTP:

X-Storage-Policy: NEW-PLACEMENT

21.12.5 Uso de clases de almacenamiento #

Todos los destinos de colocación tienen una clase de almacenamiento STANDARD que se aplica por defecto a los nuevos objetos. Puede sustituir este valor por defecto con su valor de default_storage_class.

Para crear un objeto en una clase de almacenamiento que no sea la clase por defecto, proporcione ese nombre de clase de almacenamiento en un encabezado HTTP con la petición. El protocolo S3 utiliza el encabezado X-Amz-Storage-Class, mientras que el protocolo Swift utiliza el encabezado X-Object-Storage-Class.

Puede utilizar la gestión del ciclo de vida del objeto S3 para mover datos de objetos entre clases de almacenamiento mediante acciones de transición.

21.13 Pasarelas Object Gateway de varios sitios #

Ceph admite varias opciones de configuración de varios sitios para Ceph Object Gateway:

Multizona: Una configuración que consta de un grupo de zonas y varias zonas, y cada zona tiene una o más instancias de ceph-radosgw. Cada zona tiene el respaldo de su propio clúster de almacenamiento de Ceph. Varias zonas de un grupo de zonas proporcionan recuperación tras fallos para el grupo de zonas en caso de que una de las zonas experimente un fallo importante. Todas las zonas están activas y pueden recibir operaciones de escritura. Además de la recuperación tras fallos, varias zonas activas también pueden servir como base para las redes de distribución de contenido.
Grupo multizona: Ceph Object Gateway admite varios grupos de zonas, cada grupo de zonas con una o más zonas. Los objetos almacenados en zonas de un grupo de zonas dentro del mismo dominio que otro grupo de zonas comparten un espacio de nombres de objeto global, lo que garantiza que haya ID de objeto exclusivos en los grupos de zonas y las zonas.
Nota
Es importante tener en cuenta que los grupos de zonas solo sincronizan metadatos entre sí. Los datos y los metadatos se replican entre las zonas del grupo de zonas. No se comparten datos ni metadatos en un dominio.
Varios dominios: Ceph Object Gateway admite la noción de dominios; un espacio de nombres exclusivo global. Se admiten varios dominios que pueden abarcar uno o varios grupos de zonas.

Puede configurar cada instancia de Object Gateway para que funcione con una configuración de zona activa-activa, lo que permite la escritura en zonas no principales. La configuración de varios sitios se almacena en un contenedor denominado "dominio". El dominio almacena grupos de zonas, zonas y un período de tiempo con varias épocas para realizar un seguimiento de los cambios en la configuración. Los daemons rgw gestionan la sincronización, eliminando la necesidad de un agente de sincronización independiente. Este enfoque de la sincronización permite que Ceph Object Gateway funcione con una configuración activa-activa, en lugar de con una activa-pasiva.

21.13.1 Requisitos y supuestos #

Una configuración de varios sitios requiere al menos dos clústeres de almacenamiento de Ceph y al menos dos instancias de Ceph Object Gateway, una para cada clúster de almacenamiento de Ceph. En la siguiente configuración se presupone que hay al menos dos clústeres de almacenamiento de Ceph en ubicaciones separadas geográficamente. Sin embargo, la configuración puede funcionar en el mismo sitio. Por ejemplo, se pueden llamar rgw1 y rgw2.

Una configuración de varios sitios requiere un grupo de zonas principal y una zona principal. Una zona principal es la fuente de información con respecto a todas las operaciones de metadatos de un clúster de varios sitios. Además, cada grupo de zonas requiere una zona principal. Los grupos de zonas pueden tener una o más zonas secundarias o no principales. En esta guía, el host rgw1 actúa como zona principal del grupo de zonas principal y el host rgw2 actúa como zona secundaria del grupo de zonas principal.

21.13.2 Configuración de una zona principal #

Todas las pasarelas de una configuración de varios sitios recuperan su configuración de un daemon ceph-radosgw situado en un host dentro del grupo de zonas principal y la zona principal. Para configurar las pasarelas en una configuración de varios sitios, seleccione una instancia de ceph-radosgw para configurar el grupo de zonas principal y la zona principal.

21.13.2.1 Creación de un dominio #

Un dominio representa un espacio de nombres único global que consta de uno o más grupos de zonas, que a su vez contienen una o más zonas. Las zonas contienen depósitos, que a su vez contienen objetos. Un dominio permite que Ceph Object Gateway admita varios espacios de nombres y su configuración en el mismo hardware. Un dominio contiene la noción de períodos. Cada período representa el estado del grupo de zonas y la configuración de la zona en el tiempo. Cada vez que realice un cambio en un grupo de zonas o en una zona, debe actualizar el período y asignarlo. Por defecto, Ceph Object Gateway no crea un dominio para la compatibilidad con versiones anteriores. Como práctica recomendada, se recomienda crear dominios para los clústeres nuevos.

Cree un nuevo dominio denominado gold para la configuración de varios sitios abriendo una interfaz de línea de comandos en un host identificado para servir en el grupo de zonas principal y la zona. A continuación, ejecute lo siguiente:

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

Si el clúster tiene un solo dominio, especifique el indicador --default. Si se especifica ‑‑default, radosgw-admin utiliza este dominio por defecto. Si no se especifica --default, para añadir grupos de zonas y zonas es necesario especificar el indicador --rgw-realm o el indicador --realm-id para identificar el dominio al añadir grupos de zonas y zonas.

Después de crear el dominio, radosgw-admin devuelve la configuración del dominio:

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

Nota

Ceph genera un ID exclusivo para el dominio, que permite renombrar el dominio si es necesario.

21.13.2.2 Creación de un grupo de zonas principal #

Un dominio debe tener al menos un grupo de zonas para servir como grupo de zonas principal para el dominio. Cree un nuevo grupo de zonas principal para la configuración de varios sitios abriendo una interfaz de línea de comandos en un host identificado para servir en el grupo de zonas principal y la zona. Cree un grupo de zonas principal llamado us ejecutando lo siguiente:

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

Si el dominio solo tiene un grupo de zonas, especifique el indicador --default. Si se especifica --default, radosgw-admin utiliza este grupo de zonas por defecto al añadir nuevas zonas. Si no se especifica --default, para añadir zonas se necesitará el indicador --rgw-zonegroup o el indicador --zonegroup-id para identificar el grupo de zonas al añadir o modificar zonas.

Después de crear el grupo de zonas principal, radosgw-admin devuelve la configuración del grupo de zonas. Por ejemplo:

{
 "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
 "name": "us",
 "api_name": "us",
 "is_master": "true",
 "endpoints": [
     "http:\/\/rgw1:80"
 ],
 "hostnames": [],
 "hostnames_s3website": [],
 "master_zone": "",
 "zones": [],
 "placement_targets": [],
 "default_placement": "",
 "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

21.13.2.3 Creación de una zona principal #

Importante

Las zonas deben crearse en un nodo de Ceph Object Gateway que se encuentre dentro de la zona.

Cree una nueva zona principal para la configuración de varios sitios abriendo una interfaz de línea de comandos en un host identificado para servir en el grupo de zonas principal y la zona. Realice lo siguiente:

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

Las opciones --access-key y --secret no se especifican en el ejemplo anterior. Estos ajustes se añaden a la zona cuando se crea el usuario en la siguiente sección.

Después de crear la zona principal, radosgw-admin devuelve la configuración de la zona. Por ejemplo:

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

21.13.2.4 Supresión de la zona y el grupo de zonas por defecto #

Importante

En los siguientes pasos se presupone que hay una configuración de varios sitios que utiliza sistemas recién instalados en los que aún no se almacenan datos. No suprima la zona por defecto ni sus repositorios si ya la está utilizando para almacenar datos, o los datos se suprimirán y no se podrán recuperar.

La instalación por defecto de Object Gateway crea el grupo de zonas por defecto denominado default. Suprima la zona por defecto si existe. Asegúrese de eliminarla primero del grupo de zonas por defecto.

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

Suprima los repositorios por defecto del clúster de almacenamiento de Ceph, si existen:

Importante

En el siguiente paso se presupone que hay una configuración de varios sitios que utiliza sistemas recién instalados en los que no se almacenan datos. No suprima el grupo de zonas por defecto si ya lo está utilizando para almacenar datos.

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

Aviso

Si suprime el grupo de zonas por defecto, también está suprimiendo el usuario del sistema. Si las claves del usuario administrador no se propagan, la funcionalidad de gestión de Object Gateway de Ceph Dashboard fallará. Continúe en la siguiente sección para volver a crear el usuario del sistema si continúa con este paso.

21.13.2.5 Creación de usuarios del sistema #

Los daemons ceph-radosgw deben autenticarse antes de extraer información del dominio y el período. En la zona principal, cree un usuario del sistema para simplificar la autenticación entre los daemons:

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

Anote la clave de acceso y la clave secreta, ya que las zonas secundarias deben autenticarse con la zona principal.

Añada el usuario del sistema a la zona principal:

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

Actualice el período para que los cambios surtan efecto:

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

21.13.2.6 Actualice el período #

Después de actualizar la configuración de la zona principal, actualice el período:

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

Después de actualizar el período, radosgw-admin devuelve la configuración del período. Por ejemplo:

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

La actualización del período cambia la época y garantiza que otras zonas reciban la configuración actualizada.

21.13.2.7 Inicio de Gateway #

En el host de Object Gateway, inicie y habilite el servicio Ceph Object Gateway. Para identificar el FSID exclusivo del clúster, ejecute ceph fsid. Para identificar el nombre del daemon de Object Gateway, ejecute ceph orch ps --hostname NOMBREHOST.

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

21.13.3 Configuración de zonas secundarias #

Las zonas de un grupo de zonas replican todos los datos para asegurarse de que cada zona tiene los mismos datos. Cuando cree la zona secundaria, ejecute todas las operaciones siguientes en un host identificado para servir a la zona secundaria.

Nota

Para añadir una tercera zona, siga los mismos procedimientos que para añadir la zona secundaria. Utilice un nombre de zona diferente.

Importante

Debe realizar las operaciones de metadatos, como crear usuarios, en un host de la zona principal. La zona principal y la zona secundaria pueden recibir operaciones de depósito, pero la zona secundaria redirige las operaciones de depósito a la zona principal. Si la zona principal está inactiva, las operaciones de depósito fallarán.

21.13.3.1 Extracción del dominio #

Mediante la vía URL, la clave de acceso y el secreto de la zona principal del grupo de zonas principal, extraiga la configuración del dominio en el host. Para extraer un dominio que no sea el dominio por defecto, especifique el dominio mediante las opciones de configuración --rgw-realm o --realm-id.

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

Nota

Al importar el dominio, también se recupera la configuración del período actual del host remoto, que se convierte también en el período actual en este host.

Si este dominio es el dominio por defecto, o el único dominio, conviértalo en el dominio por defecto.

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

21.13.3.2 Creación de una zona secundaria #

Cree una zona secundaria para la configuración de varios sitios abriendo una interfaz de línea de comandos en un host identificado para servir a la zona secundaria. Especifique el ID del grupo de zonas, el nombre de la nueva zona y un puesto final para la zona. No utilice el indicador ‑‑master. Todas las zonas se ejecutan con una configuración activa-activa por defecto. Si la zona secundaria no debe aceptar operaciones de escritura, especifique el indicador --read-only para crear una configuración activa-pasiva entre la zona principal y la zona secundaria. Además, proporcione la clave de acceso y la clave secreta del usuario del sistema generado almacenado en la zona principal del grupo de zonas principal. Realice lo siguiente:

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]

Por ejemplo:

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

En los pasos siguientes se presupone que hay una configuración de varios sitios en la que se usan sistemas recién instalados en los que aún no se almacenan datos. No suprima la zona por defecto ni sus repositorios si ya la está utilizando para almacenar datos, o los datos se perderán y no se podrán recuperar.

Suprima la zona por defecto si es necesario:

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

Suprima los repositorios por defecto del clúster de almacenamiento de Ceph si es necesario:

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

21.13.3.3 Actualización del archivo de configuración de Ceph #

Actualice el archivo de configuración de Ceph en los hosts de la zona secundaria añadiendo la opción de configuración rgw_zone y el nombre de la zona secundaria a la entrada de la instancia.

Para ello, ejecute el comando siguiente:

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

21.13.3.4 Actualización del período #

Después de actualizar la configuración de la zona principal, actualice el período:

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

La actualización del período cambia la época y garantiza que otras zonas reciban la configuración actualizada.

21.13.3.5 Inicio de Object Gateway #

En el host de Object Gateway, inicie y habilite el servicio Ceph Object Gateway:

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

21.13.3.6 Comprobación del estado de sincronización #

Cuando la zona secundaria esté activa y en ejecución, compruebe el estado de sincronización. La sincronización copia los usuarios y depósitos creados en la zona principal en la zona secundaria.

cephuser@adm > radosgw-admin sync status

La salida proporciona el estado de las operaciones de sincronización. Por ejemplo:

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

Las zonas secundarias aceptan operaciones de depósito; sin embargo, las zonas secundarias redirigen las operaciones de depósito a la zona principal y, a continuación, se sincronizan con la zona principal para recibir el resultado de las operaciones de depósito. Si la zona principal está inactiva, las operaciones de depósito que se ejecuten en la zona secundaria fallarán, pero las operaciones de objeto deberían realizarse correctamente.

21.13.4 Mantenimiento general de Object Gateway #

21.13.4.1 Comprobación del estado de sincronización #

La información sobre el estado de réplica de una zona se puede consultar 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

21.13.4.2 Cambio de la zona principal de metadatos #

Importante

Tenga cuidado cuando cambie qué zona es la principal para los metadatos. Si una zona no ha terminado de sincronizar los metadatos de la zona principal actual, no puede servir las entradas restantes cuando se asciende a principal, y esos cambios se pierden. Por este motivo, se recomienda esperar a que el estado de sincronización radosgw-admin de una zona se ponga al día con la sincronización de los metadatos antes de subirla a zona principal. Del mismo modo, si la zona principal actual está procesando cambios en los metadatos mientras otra zona se está subiendo a principal, es probable que se pierdan dichos cambios. Para evitarlo, se recomienda cerrar todas las instancias de Object en la zona principal anterior. Después de subir de nivel otra zona, su nuevo período se puede recuperar con la el comando de extracción de período radosgw-admin y se las pasarelas se pueden reiniciar.

Para subir de nivel una zona (por ejemplo, la zona us-west del grupo de zonas us) a zona principal de metadatos, ejecute los comandos siguientes en esa 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

Esto genera un nuevo período y las instancias de Object Gateway de la zona us-west envían este período a otras zonas.

21.13.5 Realización de failover y recuperación tras fallos #

Si la zona principal fallara, realice un failover a la zona secundaria para recuperarse tras los fallos.

Convierta la zona secundaria en la zona principal y por defecto. Por ejemplo:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
```
Por defecto, Ceph Object Gateway ejecuta una configuración activa-activa. Si el clúster se ha configurado para ejecutarse en una configuración activa-pasiva, la zona secundaria será una zona de solo lectura. Elimine el estado --read-only para permitir que la zona reciba operaciones de escritura. Por ejemplo:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                   --read-only=false
```
Actualice el período para que los cambios surtan efecto:
```
cephuser@adm > radosgw-admin period update --commit
```
Reinicie Ceph Object Gateway:
```
cephuser@adm > ceph orch restart rgw
```

Si la zona principal anterior se recupera, revierta la operación.

Desde la zona recuperada, extraiga la última configuración de dominio de la zona principal actual.

cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                           --access-key=ACCESS-KEY --secret=SECRET

Convierta la zona recuperada en la zona principal y por defecto:

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

Actualice el período para que los cambios surtan efecto:
```
cephuser@adm > radosgw-admin period update --commit
```
Reinicie Ceph Object Gateway en la zona recuperada:
```
cephuser@adm > ceph orch restart rgw@rgw
```
Si la zona secundaria debe tener una configuración de solo lectura, actualice la zona secundaria:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
```
Actualice el período para que los cambios surtan efecto:
```
cephuser@adm > radosgw-admin period update --commit
```
Reinicie Ceph Object Gateway en la zona secundaria:
```
cephuser@adm > ceph orch restart@rgw
```

21 Ceph Object Gateway #

21.1 Restricciones y limitaciones de denominación de Object Gateway #

21.1.1 Limitaciones de los depósitos #

21.1.2 Limitaciones de los objetos almacenados #

21.1.3 Limitaciones de los encabezados HTTP #

21.2 Distribución de Object Gateway #

21.3 Funcionamiento del servicio de Object Gateway #

21.4 Opciones de configuración #

21.5 Gestión del acceso a Object Gateway #

21.5.1 Acceso a Object Gateway #

21.5.1.1 Acceso a la interfaz de S3 #

21.5.1.2 Acceso a la interfaz de Swift #

21.5.2 Gestión de cuentas de S3 y Swift #

21.5.2.1 Adición de usuarios de S3 y Swift #

21.5.2.2 Eliminación de usuarios de S3 y Swift #

21.5.2.3 Cambio del acceso de usuario y las claves de secreto de S3 y Swift #

21.5.2.4 Habilitación de la gestión de cuotas de usuario #

21.6 Procesadores frontales HTTP #

21.7 Habilitación de HTTPS/SSL para pasarelas Object Gateway #

21.7.1 Creación de certificados autofirmados #

21.7.2 Configuración de Object Gateway con SSL #

21.8 Módulos de sincronización #

21.8.1 Configuración de módulos de sincronización #

21.8.2 Sincronización de zonas #

21.8.2.1 Requisitos y supuestos #

21.8.2.2 Configuración de zonas #

21.8.3 Módulo de sincronización ElasticSearch #

21.8.3.1 Parámetros de configuración de tipo de nivel de ElasticSearch #

21.8.3.2 Consultas de metadatos #

21.8.4 Módulo de sincronización en la nube #

21.8.4.1 Configuración del módulo de sincronización en la nube #

21.8.4.2 Elementos configurables específicos de S3 #

21.8.5 Módulo de sincronización de archivador #

21.8.5.1 Configuración del módulo de sincronización de archivador #

21.9 Autenticación LDAP #

21.9.1 Mecanismo de autenticación #

21.9.2 Requisitos #

21.9.3 Configuración de Object Gateway para utilizar la autenticación LDAP #

21.9.4 Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario #

21.9.4.1 Filtro parcial para restringir aún más el filtro de búsqueda construido #

21.9.4.2 Filtro completo #

21.9.5 Generación de un testigo de acceso para la autenticación LDAP #

21.10 Partición del índice de depósito #

21.10.1 Nueva partición del índice de depósito #

21.10.1.1 Partición dinámica #

21.10.1.2 Partición manual #

21.10.2 Partición de índice de depósito para depósitos nuevos #

21.10.2.1 Configuraciones de varios sitios #

21.11 Integración con OpenStack Keystone #

21.11.1 Configuración de OpenStack #

21.11.2 Configuración de Ceph Object Gateway #

21.11.2.1 Configuración de certificados SSL #

21.11.2.2 Configuración de las opciones de Object Gateway #

21.12 Colocación de repositorios y clases de almacenamiento #

21.12.1 Visualización de destinos de colocación #

21.12.2 Clases de almacenamiento #

21.12.3 Configuración de grupos de zonas y zonas #

21.12.3.1 Adición de un destino de colocación #

21.12.3.2 Adición de una clase de almacenamiento #

21.12.4 Personalización de colocación #

21.12.4.1 Edición de la colocación del grupo de zonas por defecto #

21.12.4.2 Edición de la colocación del usuario por defecto #

21.12.4.3 Edición de la colocación del depósito por S3 por defecto #

21.12.4.4 Edición de la colocación del depósito por Swift #

21.12.5 Uso de clases de almacenamiento #

21.13 Pasarelas Object Gateway de varios sitios #

21.13.1 Requisitos y supuestos #

21.13.2 Configuración de una zona principal #

21.13.2.1 Creación de un dominio #

21.13.2.2 Creación de un grupo de zonas principal #

21.13.2.3 Creación de una zona principal #

21.13.2.4 Supresión de la zona y el grupo de zonas por defecto #

21.13.2.5 Creación de usuarios del sistema #

21.13.2.6 Actualice el período #

21.13.2.7 Inicio de Gateway #

21.13.3 Configuración de zonas secundarias #

21.13.3.1 Extracción del dominio #

21.13.3.2 Creación de una zona secundaria #

21.13.3.3 Actualización del archivo de configuración de Ceph #

21.13.3.4 Actualización del período #