cephx
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.
A continuación encontrará una lista de limitaciones importantes de Object Gateway.
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.
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.
No hay restricciones por defecto (limitado a ~2^63).
No hay restricciones por defecto (limitado a ~2^63).
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.
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.
La forma recomendada de distribuir Ceph Object Gateway es a través de la infraestructura DeepSea añadiendo las líneas role-rgw [...]
pertinentes en el archivo policy.cfg
del master de Salt y, después, ejecutando las fases necesarias de DeepSea.
Para incluir Object Gateway durante el proceso de distribución del clúster de Ceph, consulte Sección 5.3, “Distribución del clúster” y Sección 5.5.1, “El archivo policy.cfg
”.
Para añadir la función de Object Gateway a un clúster ya distribuido, consulte la Sección 2.2, “Adición de nuevas funciones a los nodos”.
El servicio de Object Gateway funciona con el comando systemctl
. Debe tener privilegios de usuario root
para poder ejecutar el servicio de Object Gateway. Tenga en cuenta que GATEWAY_HOST es el nombre de host del servidor cuya instancia de Object Gateway debe ejecutar.
Se admiten los siguientes subcomandos para el servicio de Object Gateway:
Imprime la información de estado del servicio.
Inicia el servicio en caso de que no se esté ejecutando.
Reinicia el servicio.
Detiene el servicio en ejecución.
Habilita el servicio para que se inicie automáticamente al mismo tiempo que el sistema.
Inhabilita el servicio para que no se inicie automáticamente al mismo tiempo que el sistema.
Consulte en la Sección 16.3, “Ceph Object Gateway” una lista de opciones de configuración de 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.
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 17.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
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/x86_64
sudo zypper refresh
O bien
root #
SUSEConnect -p sle-module-public-cloud/15/x86_64root #
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 17.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
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.
También se pueden añadir usuarios a través del archivo rgw.sls
de DeepSea. Si desea ver un ejemplo, consulte la Sección 21.3.1, “Usuarios distintos de Object Gateway para NFS Ganesha”.
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.
cephadm@adm >
radosgw-admin user create --uid=USERNAME \
--display-name="DISPLAY-NAME" --email=EMAIL
Por ejemplo:
cephadm@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.
cephadm@adm >
radosgw-admin subuser create --uid=UID \
--subuser=UID \
--access=[ read | write | readwrite | full ]
Por ejemplo:
cephadm@adm >
radosgw-admin subuser create --uid=example_user \
--subuser=example_user:swift --access=full
Genere una clave de secreto para el usuario.
cephadm@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:
cephadm@adm >
radosgw-admin user create --uid=USERNAME \
--display-name="DISPLAY-NAME" --email=EMAIL
Por ejemplo:
cephadm@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"}], [...]
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:
cephadm@adm >
radosgw-admin user rm --uid=example_user
Para eliminar un subusuario, especifique subuser rm
y el ID de subusuario.
cephadm@adm >
radosgw-admin subuser rm --uid=example_user:swift
Puede usar las siguientes opciones:
Limpia todos los datos asociados al ID de usuario.
Limpia todas las claves asociadas al ID de usuario.
Cuando se elimina un subusuario, se elimina el acceso a la interfaz de Swift. El usuario permanecerá en el sistema.
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:
cephadm@adm >
radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret
Para los usuarios de Swift, ejecute lo siguiente:
cephadm@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.
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:
cephadm@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:
cephadm@adm >
radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER
Para inhabilitar una cuota:
cephadm@adm >
radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER
Para mostrar la configuración de la cuota:
cephadm@adm >
radosgw-admin user info --uid=EXAMPLE_USER
Para actualizar las estadísticas de la cuota:
cephadm@adm >
radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats
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
en el archivo /etc/ceph/ceph.conf
. Consulte la Sección 16.3, “Ceph Object Gateway” para obtener una lista de las opciones de configuración.
Para habilitar la función de Object Gateway por defecto para comunicarse de forma segura mediante SSL, debe tener un certificado emitido por una CA o crear uno autofirmado. Existen dos formas de configurar Object Gateway con HTTPS habilitado: una forma sencilla donde se usan los ajustes por defecto y otra avanzada que permite configurar con más detalles los valores relacionados con HTTPS.
Omita esta sección si ya dispone de un certificado válido firmado por una CA.
Por defecto, DeepSea espera que el archivo de certificado esté en /srv/salt/ceph/rgw/cert/rgw.pem
en el master de Salt. A continuación, distribuirá el certificado a /etc/ceph/rgw.pem
en el minion de Salt con la función de Object Gateway, donde Ceph lo lee.
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 [...]
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 /srv/salt/ceph/rgw/cert/rgw.pem
Añada la clave al final del archivo de certificado:
root@master #
cat rgw.key >> /srv/salt/ceph/rgw/cert/rgw.pem
Por defecto, la instancia de Ceph del nodo de Object Gateway lee el certificado /etc/ceph/rgw.pem
y utiliza el puerto 443 para la comunicación SSL segura. Si no necesita cambiar estos valores, siga estos pasos:
Edite /srv/pillar/ceph/stack/global.yml
y añada la línea siguiente:
rgw_init: default-ssl
Copie la configuración por defecto de SSL de Object Gateway en el subdirectorio ceph.conf.d
:
root@master #
cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
/srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
Ejecute las fases 2, 3 y 4 de DeepSea para aplicar los cambios:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Si necesita cambiar los valores por defecto de la configuración de SSL de Object Gateway, siga estos pasos:
Edite /srv/pillar/ceph/stack/global.yml
y añada la línea siguiente:
rgw_init: default-ssl
Copie la configuración por defecto de SSL de Object Gateway en el subdirectorio ceph.conf.d
:
root@master #
cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
/srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
Edite /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf
y cambie las opciones por defecto, como el número de puerto o la vía al certificado SSL para reflejar su configuración.
Ejecute las fases 3 y 4 de DeepSea para aplicar los cambios:
root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
El servidor de Beast puede vincularse a varios puertos. Esto resulta útil si necesita acceder a una única instancia de Object Gateway mediante conexiones tanto SSL como no SSL. A continuación se muestra un ejemplo de una línea de configuración de dos puertos:
[client.{{ client }}] rgw_frontends = beast port=80 ssl_port=443 ssl_certificate=/etc/ceph/rgw.pem
La funcionalidad de varios sitios de Object Gateway permite crear varias zonas y duplicar datos y metadatos entre ellas. 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,
Todos los módulos de sincronización se configuran de forma similar. Debe crear una zona nueva (consulte la Sección 17.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:
cephadm@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:
cephadm@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:
cephadm@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:
cephadm@adm >
radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \ --rgw-zone=ZONE-NAME \ --tier-config=profiles[].source_bucket=PREFIX'*'cephadm@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
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
.
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.
El complemento de sincronización por defecto es rgw
y no es necesario configurarlo de forma explícita.
Supongamos que tenemos una configuración sencilla de varios sitios descrita en la Sección 17.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.
Cree una tercera zona similar a la que se describe en la Sección 17.13, “Pasarelas Object Gateway de varios sitios”, por ejemplo:
cephadm@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 mediante lo siguiente:
cephadm@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
:
cephadm@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 17.8.3, “Módulo de sincronización ElasticSearch”.
Por último, actualice el período:
cephadm@adm >
radosgw-admin
period update --commit
Inicie ahora radosgw en la zona:
root #
systemctl
start ceph-radosgw@rgw.`hostname -s`root #
systemctl
enable ceph-radosgw@rgw.`hostname -s`
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" } } }
Especifica el puesto final del servidor de ElasticSearch al que se accede.
(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.
(número entero) El número de réplicas con las que se configurará ElasticSearch al inicializar la sincronización de datos.
(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).
(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").
(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.
(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.
Indica un nombre de usuario para ElasticSearch si se requiere autenticación.
Indica una contraseña para ElasticSearch si se requiere autenticación.
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.
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.
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
Puede suprimir una configuración personalizada de metadatos.
DELETE /BUCKET?mdsearch
Puede recuperar una configuración personalizada de metadatos.
GET /BUCKET?mdsearch
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.
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.
{ "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 } ... ], }
A continuación se explican los términos de configuración utilizados:
Representa una conexión con el servicio remoto en la nube. Contiene "connection_id", "access_key", "secret", "endpoint" y "host_style".
La clave de acceso remoto a la nube que se usará para la conexión específica.
La clave secreta para el servicio remoto en la nube.
Dirección URL del puesto final del servicio remoto en la nube.
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".
La matriz de asignaciones de la lista de acceso.
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.
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).
El ID de usuario en la zona de origen.
El ID de usuario en el destino.
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:
Una cadena exclusiva que representa el ID de instancia de sincronización.
El nombre del grupo de zonas.
El ID de grupo de zonas.
Nombre de zona.
El ID de zona.
El nombre del depósito de origen.
El ID de propietario del depósito de origen.
Por ejemplo: target_path = rgwx-ZONA-SID/PROPIETARIO/DEPÓSITO
Una matriz de perfiles de lista de acceso.
Cada perfil contiene "acls_id", que representa el perfil y una matriz "acls" que contiene una lista "acl_mappings".
Una lista de perfiles. Cada perfil contiene lo siguiente:
Un nombre de depósito o un prefijo de depósito (si termina con *) que define los depósitos de origen para este perfil.
Consulte arriba la explicación.
El ID de la conexión que se utilizará para este perfil.
El ID del perfil de ACL que se utilizará para este perfil.
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 }
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.
El tamaño mínimo de las partes que se debe utilizar al sincronizar objetos mediante la carga de varias partes.
El módulo archive sync module utiliza 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 de varias zonas, 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.
Consulte la Sección 17.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 17.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 archivador, debe crear una zona nueva cuyo tipo de nivel esté definido como archive
:
cephadm@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
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.
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.
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.
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.
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.
Los siguientes parámetros del archivo de configuración /etc/ceph/ceph.conf
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.
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 17.9.4, “Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario” para obtener más información.
Existen dos formas de utilizar el parámetro rgw_search_filter
.
Un ejemplo de un filtro parcial:
"objectclass=inetorgperson"
Object Gateway generará el filtro de búsqueda de la forma habitual con el nombre de usuario tomado del testigo y el valor de rgw_ldap_dnattr
. El filtro construido se combina a continuación con el filtro parcial del atributo rgw_search_filter
. Según el nombre de usuario y la configuración, el filtro de búsqueda final puede ser:
"(&(uid=hari)(objectclass=inetorgperson))"
En este caso, solo se otorgará acceso al usuario "hari" si se encuentra en el directorio LDAP, tiene la clase de objeto "inetorgperson" y ha especificado una contraseña válida.
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))"
memberOf
Para poder usar el atributo memberOf
en las búsquedas LDAP se requiere compatibilidad en el servidor LDAP específico implementado.
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 17.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"cephadm@adm >
radosgw-token --encode --ttype=ldap
El testigo de acceso es una estructura JSON codificada en base 64 y contiene las credenciales LDAP en texto sin cifrar.
Para Active Directory, utilice el parámetro ‑‑type=ad
.
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.
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 17.10.1.1, “Partición dinámica”, o partir el índice de depósito manualmente sin conexión (consulte la Sección 17.10.1.2, “Partición manual”).
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.
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.
La partición dinámica no se admite en entornos de varios sitios. Está inhabilitada por defecto desde Ceph 12.2.2, pero se recomienda volver a comprobar el ajuste.
cephadm@adm >
radosgw-admin reshard add \
--bucket BUCKET_NAME \
--num-shards NEW_NUMBER_OF_SHARDS
cephadm@adm >
radosgw-admin reshard list
cephadm@adm >
radosgw-admin reshard process
cephadm@adm >
radosgw-admin reshard status --bucket BUCKET_NAME
cephadm@adm >
radosgw-admin reshard cancel --bucket BUCKET_NAME
La partición dinámica mencionada en la Sección 17.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:
cephadm@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.
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:
cephadm@adm >
radosgw-admin bi list \
--bucket=BUCKET_NAME \
> BUCKET_NAME.list.backup
Vuelva a particionar el índice de depósito:
cephadm@adm >
radosgw-admin reshard \
--bucket=BUCKET_NAME \
--num-shards=NEW_SHARDS_NUMBER
Como parte del resultado, este comando también imprime los ID nuevo y antiguo. Anote el ID de depósito antiguo: lo necesitará para limpiar los objetos de índice de depósito antiguos.
Verifique que los objetos se muestran correctamente comparando la lista del índice de depósito antiguo con la nueva. A continuación, limpie los objetos de índice de depósito antiguos:
cephadm@adm >
radosgw-admin bi purge
--bucket=BUCKET_NAME
--bucket-id=OLD_BUCKET_ID
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.
Abra el archivo de configuración de Ceph y añada o modifique la siguiente opción:
rgw_override_bucket_index_max_shards = 12
Para configurar la partición de índice de depósito para todas las instancias de Object Gateway, incluya rgw_override_bucket_index_max_shards
en la sección [global]
.
Para configurar la partición de índice de depósito solo para una instancia concreta de Object Gateway, incluya rgw_override_bucket_index_max_shards
en la sección oportuna de la instancia.
Reinicie Object Gateway. Consulte la Sección 17.3, “Funcionamiento del servicio de Object Gateway” para obtener más información.
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
:
cephadm@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:
cephadm@adm >
radosgw-admin zonegroup set < zonegroup.json
Actualice el período:
cephadm@adm >
radosgw-admin period update --commit
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.
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
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/nssroot #
openssl x509 -in /etc/keystone/ssl/certs/ca.pem \ -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"root
openssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \ -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"
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.
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
.
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.
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:
cephadm@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.
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.
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:
cephadm@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:
cephadm@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
}
}
],
...
}
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
.
Para crear un nuevo destino de colocación denominado "temporary", comience añadiéndolo al grupo de zonas:
cephadm@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:
cephadm@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
Para añadir una nueva clase de almacenamiento denominada "COLD" al destino "default-placement", empiece añadiéndola al grupo de zonas:
cephadm@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:
cephadm@adm >
radosgw-admin zone placement add \
--rgw-zone default \
--placement-id default-placement \
--storage-class COLD \
--data-pool default.rgw.cold.data \
--compression lz4
Por defecto, los nuevos depósitos utilizarán el destino "default_placement" del grupo de zonas. Puede cambiar este valor del grupo de zonas con:
cephadm@adm >
radosgw-admin zonegroup placement default \
--rgw-zonegroup default \
--placement-id new-placement
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.
cephadm@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:
cephadm@adm >
radosgw-admin metadata get user:USER-ID > user.jsontux >
vi user.json # edit the file as requiredcephadm@adm >
radosgw-admin metadata put user:USER-ID < user.json
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>
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
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".
Una agrupación lógica de una o varias instancias de Object Gateway. Debe haber una zona designada como zona principal en un grupo de zonas que gestionará toda la creación de depósitos y usuarios.
Un grupo de zonas es un conjunto de varias zonas. Debe haber un grupo de zonas principal que gestionará los cambios de la configuración del sistema.
Una estructura de configuración que contiene el mapa de todo el sistema; por ejemplo, qué grupo de zonas es el principal, las relaciones entre distintos grupos de zonas y ciertas opciones de configuración, como las directivas de almacenamiento.
Un contenedor para grupos de zonas. Esto permite la separación de grupos de zonas entre los clústeres. Es posible crear varios dominios para que sea más fácil ejecutar configuraciones completamente distintas en el mismo clúster.
Un período guarda la estructura de configuración para el estado actual del dominio. Cada período contiene un ID único y una época. Cada dominio tiene un período actual asociado, que contiene el estado actual de la configuración de los grupos de zonas y las directivas de almacenamiento. Cualquier cambio de configuración para una zona principal incrementará la época del período. Si se cambia la zona principal a una zona diferente, se activan los siguientes cambios:
Se genera un nuevo período con un nuevo ID de período y la época 1.
El período actual del dominio se actualiza para que señale al ID de período recién generado.
La época del dominio se incrementa.
Puede configurar cada Object Gateway para que participe en una arquitectura federada, en la que trabaja en una configuración de zona activa y permite la escritura en zonas no principales.
A continuación se muestra una descripción de los términos específicos de una arquitectura federada:
En este ejemplo nos centraremos en la creación de un único grupo de zonas con tres zonas independiente que sincronizan sus datos de forma activa. Dos zonas pertenecen al mismo clúster, mientras que la tercera pertenece a otro diferente. No hay ningún agente de sincronización implicado en la duplicación de los cambios de datos entre las pasarelas Object Gateway. Esto permite un esquema de configuración mucho más sencillo y configuraciones de tipo activa-activa. Tenga en cuenta que las operaciones de metadatos, como crear un usuario nuevo, aún deben realizarse a través de la zona principal. Sin embargo, las operaciones de datos, como la creación de depósitos y objetos, se pueden gestionar en cualquiera de las zonas.
Durante la configuración de las zonas, Object Gateway espera que se cree un usuario de sistema compatible con S3 junto con sus claves de acceso y de secreto. Esto permite a otra instancia de Object Gateway extraer la configuración de forma remota con las claves de acceso y de secreto. Para obtener más información sobre cómo crear usuarios de S3, consulte la Sección 17.5.2.1, “Adición de usuarios de S3 y Swift”.
Resulta útil para generar las claves de acceso y de secreto antes de crear la propia zona, ya que se facilita la creación de guiones y el uso de herramientas de gestión de configuraciones más adelante.
Para este ejemplo, supongamos que las claves de acceso y de secreto están definidas en las variables de entorno:
# SYSTEM_ACCESS_KEY=1555b35654ad1656d805 # SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==
Por lo general, las claves de acceso están formadas por 20 caracteres alfanuméricos, mientras que las claves de secreto constan de 40 caracteres alfanuméricos (pueden contener también los caracteres +/=). Estas claves se pueden generar en la línea de comandos:
# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) # SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)
Este ejemplo describe el proceso de configuración de una zona principal. Partiremos de un grupo de zonas denominado us
que abarca los Estados Unidos, que serán nuestro grupo de zonas principal. Contendrá dos zonas con el formato GRUPOZONAS-ZONA. Esto es simplemente una convención que se usa para este ejemplo, pero puede elegir el formato que prefiera. En resumen:
Grupo de zonas principal: Estados Unidos us
Zona principal: Estados Unidos, región Este 1: us-east-1
Zona secundaria: Estados Unidos, región Este 2: us-east-2
Zona secundaria: Estados Unidos, región Oeste: us-west
Todo esto formará parte de un dominio mayor denominado gold
. Las zonas us-east-1
y us-east-2
forman parte del mismo clúster de Ceph, us-east-1
es la principal. us-west
está en un clúster de Ceph diferente.
Si se ha configurado con los permisos apropiados, Object Gateway crea repositorios por defecto por sí misma. Los valores pg_num
y pgp_num
se toman del archivo de configuración ceph.conf
. Los repositorios relacionados con una zona, siguen por defecto la convención NOMBRE-ZONA.NOMBRE-REPOSITORIO. Por ejemplo, para la zona us-east-1
, serán los repositorios siguientes:
.rgw.root us-east-1.rgw.control us-east-1.rgw.data.root us-east-1.rgw.gc us-east-1.rgw.log us-east-1.rgw.intent-log us-east-1.rgw.usage us-east-1.rgw.users.keys us-east-1.rgw.users.email us-east-1.rgw.users.swift us-east-1.rgw.users.uid us-east-1.rgw.buckets.index us-east-1.rgw.buckets.data us-east-1.rgw.meta
Estos repositorios se pueden crear también en otras zonas; basta con sustituir us-east-1
por el nombre de zona correspondiente.
Configure un dominio denominado gold
y conviértalo en el dominio por defecto:
cephadm@adm >
radosgw-admin realm create --rgw-realm=gold --default
{
"id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"name": "gold",
"current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"epoch": 1
}
Tenga en cuenta que cada dominio tiene un ID, lo que aporta flexibilidad, por ejemplo si hay que cambiar el nombre del dominio más tarde. El valor de current_period
cambia cada vez que se modifica algo en la zona principal. El valor de epoch
aumenta cuando se produce un cambio en la configuración de la zona principal que provoque un cambio del periodo actual.
La instalación por defecto de Object Gateway crea el grupo de zonas por defecto denominado default
. Dado que ya no se necesita el grupo de zonas por defecto, elimínelo.
cephadm@adm >
radosgw-admin zonegroup delete --rgw-zonegroup=default
Cree un grupo de zonas principal denominado us
. Este grupo de zonas gestionará el mapa del grupo de zonas y propagará los cambios al resto del sistema. Si se marca el grupo de zonas como grupo por defecto, se permite explícitamente que se mencione el parámetro rgw-zonagroup en comandos posteriores.
cephadm@adm >
radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "",
"zones": [],
"placement_targets": [],
"default_placement": "",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
Si lo prefiere, puede marcar un grupo de zonas como grupo por defecto con el comando siguiente:
cephadm@adm >
radosgw-admin zonegroup default --rgw-zonegroup=us
Cree ahora una zona por defecto y añádala al grupo de zonas por defecto. Tenga en cuenta que utilizará esta zona para las operaciones de metadatos, como la creación de usuarios:
cephadm@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
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"domain_root": "us-east-1/gc.rgw.data.root",
"control_pool": "us-east-1/gc.rgw.control",
"gc_pool": "us-east-1/gc.rgw.gc",
"log_pool": "us-east-1/gc.rgw.log",
"intent_log_pool": "us-east-1/gc.rgw.intent-log",
"usage_log_pool": "us-east-1/gc.rgw.usage",
"user_keys_pool": "us-east-1/gc.rgw.users.keys",
"user_email_pool": "us-east-1/gc.rgw.users.email",
"user_swift_pool": "us-east-1/gc.rgw.users.swift",
"user_uid_pool": "us-east-1/gc.rgw.users.uid",
"system_key": {
"access_key": "1555b35654ad1656d804",
"secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
},
"placement_pools": [
{
"key": "default-placement",
"val": {
"index_pool": "us-east-1/gc.rgw.buckets.index",
"data_pool": "us-east-1/gc.rgw.buckets.data",
"data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec",
"index_type": 0
}
}
],
"metadata_heap": "us-east-1/gc.rgw.meta",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
Recuerde también que los parámetros ‑‑rgw-zonagroup
y ‑‑default
añaden la zona a un grupo de zonas y la convierten en la zona por defecto. Como alternativa, se puede hacer lo mismo con los comandos siguientes:
cephadm@adm >
radosgw-admin zone default --rgw-zone=us-east-1cephadm@adm >
radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1
Para acceder a los repositorios de zona, debe crear un usuario del sistema. Tenga en cuenta que también necesitará estas claves cuando configure las zonas secundarias.
cephadm@adm >
radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \
--secret=$SYSTEM_SECRET_KEY --system
Puesto que ha cambiado la configuración de la zona principal, debe confirmar los cambios para que surtan efecto en la estructura de configuración del dominio. Inicialmente, el período tiene este aspecto:
cephadm@adm >
radosgw-admin period get
{
"id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map":
{
"id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": []
}, "master_zonegroup": "", "master_zone": "", "period_config":
{
"bucket_quota": {
"enabled": false, "max_size_kb": -1, "max_objects": -1
}, "user_quota": {
"enabled": false, "max_size_kb": -1, "max_objects": -1
}
}, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1
}
Actualice el período y confirme los cambios:
cephadm@adm >
radosgw-admin period update --commit
{
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"epoch": 1,
"predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"sync_status": [ "[...]"
],
"period_map": {
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"zonegroups": [
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"zones": [
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"endpoints": [
"http:\/\/rgw1:80"
],
"log_meta": "true",
"log_data": "false",
"bucket_index_max_shards": 0,
"read_only": "false"
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
],
"short_zone_ids": [
{
"key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"val": 630926044
}
]
},
"master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"period_config": {
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
}
},
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"realm_name": "gold",
"realm_epoch": 2
}
Es necesario mencionar las opciones de zona y puerto de Object Gateway en el archivo de configuración antes de iniciar Object Gateway. Para obtener más información sobre Object Gateway y su configuración, consulte el Capítulo 17, Ceph Object Gateway. La sección de configuración de Object Gateway debe ser parecida a esto:
[client.rgw.us-east-1] rgw_frontends="beast port=80" rgw_zone=us-east-1
Inicie Object Gateway:
root #
systemctl start ceph-radosgw@rgw.us-east-1
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.
En el clúster secundario, cree y configure la zona secundaria denominada us-east-2
. Puede ejecutar los comandos siguientes en el nodo que aloja la zona principal.
Para crear la zona secundaria, utilice el mismo comando que usó al crear la zona principal, pero no incluya el parámetro master:
cephadm@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"
}
Informe a todas las pasarelas del nuevo cambio del mapa del sistema realizando una actualización del período y confirmando los cambios:
cephadm@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
}
Ajuste la configuración de Object Gateway para la zona secundaria e iníciela:
[client.rgw.us-east-2] rgw_frontends="beast port=80" rgw_zone=us-east-2
cephadm@adm >
sudo systemctl start ceph-radosgw@rgw.us-east-2
Defina lo siguiente para actualizar la configuración de la consola para varios sitios en función de las variables de secreto y de clave de acceso:
cephadm@adm >
ceph dashboard set-rgw-api-access-key ACCESS-KEYcephadm@adm >
ceph dashboard set-rgw-api-secret-key SECRET-KEY
Para la consola, use por defecto el valor admin
:
cephadm@adm >
ceph dashboard set-rgw-api-user-id admin
Inhabilite y vuelva a habilitar la consola para aplicar la configuración.
cephadm@adm >
ceph mgr module disable dashboardcephadm@adm >
ceph mgr module enable dashboard
Si el nodo de Object Gateway ha cambiado o se utiliza un equilibrador de carga en lugar de pasarelas de Object Gateway, actualice la consola:
cephadm@adm >
dashboard set-rgw-api-host HOSTcephadm@adm >
dashboard set-rgw-api-port PORT
El segundo clúster de Ceph pertenece al mismo grupo de zonas que el inicial, pero puede que esté ubicado en otro lugar geográfico.
Dado que ya ha creado el dominio para la primera pasarela, extraiga el dominio aquí y conviértalo en el dominio por defecto:
cephadm@adm >
radosgw-admin realm pull --url=http://rgw1:80 \ --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY { "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2 }cephadm@adm >
radosgw-admin realm default --rgw-realm=gold
Obtenga la configuración de la zona principal extrayendo el período:
cephadm@adm >
radosgw-admin period pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
Defina el grupo de zonas por defecto en el grupo de zonas us
existente:
cephadm@adm >
radosgw-admin zonegroup default --rgw-zonegroup=us
Cree una zona nueva denominada us-west
con las mismas claves del sistema:
cephadm@adm >
radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \
--endpoints=http://rgw3:80 --default
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-west",
"domain_root": "us-west.rgw.data.root",
"control_pool": "us-west.rgw.control",
"gc_pool": "us-west.rgw.gc",
"log_pool": "us-west.rgw.log",
"intent_log_pool": "us-west.rgw.intent-log",
"usage_log_pool": "us-west.rgw.usage",
"user_keys_pool": "us-west.rgw.users.keys",
"user_email_pool": "us-west.rgw.users.email",
"user_swift_pool": "us-west.rgw.users.swift",
"user_uid_pool": "us-west.rgw.users.uid",
"system_key": {
"access_key": "1555b35654ad1656d804",
"secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
},
"placement_pools": [
{
"key": "default-placement",
"val": {
"index_pool": "us-west.rgw.buckets.index",
"data_pool": "us-west.rgw.buckets.data",
"data_extra_pool": "us-west.rgw.buckets.non-ec",
"index_type": 0
}
}
],
"metadata_heap": "us-west.rgw.meta",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
Para propagar los cambios del mapa de grupo de zonas, se actualiza y se confirma el período:
cephadm@adm >
radosgw-admin period update --commit --rgw-zone=us-west
{
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"epoch": 3,
"predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
"sync_status": [
"", # truncated
],
"period_map": {
"id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
"zonegroups": [
{
"id": "d4018b8d-8c0d-4072-8919-608726fa369e",
"name": "us",
"api_name": "us",
"is_master": "true",
"endpoints": [
"http:\/\/rgw1:80"
],
"hostnames": [],
"hostnames_s3website": [],
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"zones": [
{
"id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"name": "us-east-1",
"endpoints": [
"http:\/\/rgw1:80"
],
"log_meta": "true",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
},
{
"id": "950c1a43-6836-41a2-a161-64777e07e8b8",
"name": "us-east-2",
"endpoints": [
"http:\/\/rgw2:80"
],
"log_meta": "false",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
},
{
"id": "d9522067-cb7b-4129-8751-591e45815b16",
"name": "us-west",
"endpoints": [
"http:\/\/rgw3:80"
],
"log_meta": "false",
"log_data": "true",
"bucket_index_max_shards": 0,
"read_only": "false"
}
],
"placement_targets": [
{
"name": "default-placement",
"tags": []
}
],
"default_placement": "default-placement",
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}
],
"short_zone_ids": [
{
"key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"val": 630926044
},
{
"key": "950c1a43-6836-41a2-a161-64777e07e8b8",
"val": 4276257543
},
{
"key": "d9522067-cb7b-4129-8751-591e45815b16",
"val": 329470157
}
]
},
"master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
"period_config": {
"bucket_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
},
"user_quota": {
"enabled": false,
"max_size_kb": -1,
"max_objects": -1
}
},
"realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
"realm_name": "gold",
"realm_epoch": 2
}
Tenga en cuenta que el número de época del período ha aumentado, lo que indica un cambio en la configuración.
Esto es similar a iniciar Object Gateway en la primera zona. La única diferencia es que la configuración de la zona de Object Gateway debe reflejar el nombre de zona us-west
:
[client.rgw.us-west] rgw_frontends="beast port=80" rgw_zone=us-west
Inicie la segunda pasarela Object Gateway:
root #
systemctl start ceph-radosgw@rgw.us-west
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:
cephadm@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:
cephadm@adm >
radosgw-admin
zone modify --rgw-zone=ZONE-NAME --master --default \ --read-only=False
Actualice el período para que los cambios surtan efecto.
cephadm@adm >
radosgw-admin
period update --commit
Por último, reinicie Ceph Object Gateway.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
Si la zona principal anterior se recupera, revierta la operación.
Desde la zona recuperada, extraiga el período de la zona principal actual.
cephadm@adm >
radosgw-admin
period pull --url=URL-TO-MASTER-ZONE-GATEWAY \ --access-key=ACCESS-KEY --secret=SECRET
Convierta la zona recuperada en la zona principal y por defecto.
cephadm@adm >
radosgw-admin
zone modify --rgw-zone=ZONE-NAME --master --default
Actualice el período para que los cambios surtan efecto.
cephadm@adm >
radosgw-admin
period update --commit
A continuación, reinicie Ceph Object Gateway en la zona recuperada.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
Si la zona secundaria debe tener una configuración de solo lectura, actualice la zona secundaria.
cephadm@adm >
radosgw-admin
zone modify --rgw-zone=ZONE-NAME --read-only
Actualice el período para que los cambios surtan efecto.
cephadm@adm >
radosgw-admin
period update --commit
Por último, reinicie Ceph Object Gateway en la zona secundaria.
root #
systemctl
restart ceph-radosgw@rgw.`hostname -s`
Puede utilizar el mecanismo de equilibrio de carga HAProxy para distribuir todas las peticiones entre varios servidores de procesador final de Object Gateway. Consulte https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/sec_ha_lb_haproxy.html para obtener más información sobre cómo configurar HAProxy.
A continuación se muestra una configuración sencilla de HAProxy para equilibrar nodos de Object Gateway mediante carga rotativa como algoritmo de equilibrio:
tux >
cat /etc/haproxy/haproxy.cfg
[...]
frontend HTTPS_FRONTEND
bind *:443 crt path-to-cert.pem [ciphers: ... ]
default_backend rgw
backend rgw
mode http
balance roundrobin
server rgw_server1 RGW-ENDPOINT1 weight 1 maxconn 100 check
server rgw_server2 RGW-ENDPOINT2 weight 1 maxconn 100 check
[...]