Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
Se aplica a SUSE Enterprise Storage 5

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

11.1 Restricciones y limitaciones de denominación de Object Gateway

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

11.1.1 Limitaciones del depósito

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

11.1.2 Limitaciones de 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.

11.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. En la opción por defecto, CivetWeb, se restringe el número de encabezados HTTP a 64 y el tamaño del encabezado HTTP a 16 kB.

11.2 Distribución de Object Gateway

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.

11.3 Funcionamiento del servicio de Object Gateway

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 el nombre de host del servidor cuya instancia de Object Gateway debe ejecutar es gateway_host.

Se admiten los siguientes subcomandos para el servicio de Object Gateway:

systemctl status ceph-radosgw@rgw.host_de_pasarela

Imprime la información de estado del servicio.

systemctl start ceph-radosgw@rgw.host_de_pasarela

Inicia el servicio en caso de que no se esté ejecutando.

systemctl restart ceph-radosgw@rgw.host_de_pasarela

Reinicia el servicio.

systemctl stop ceph-radosgw@rgw.host_de_pasarela

Detiene el servicio en ejecución.

systemctl enable ceph-radosgw@rgw.host_de_pasarela

Habilita el servicio para que se inicie automáticamente al mismo tiempo que el sistema.

systemctl disable ceph-radosgw@rgw.host_de_pasarela

Inhabilita el servicio para que no se inicie automáticamente al mismo tiempo que el sistema.

11.4 Parámetros de configuración

El comportamiento de Object Gateway puede verse afectado por un gran número de opciones del archivo ceph.conf. A continuación encontrará una lista de los más importantes. Para obtener una lista completa, consulte http://docs.ceph.com/docs/master/radosgw/config-ref/.

rgw_thread_pool_size

El número de hilos para el servidor de CivetWeb. Se incrementa a un valor superior si necesita atender más peticiones. Por defecto es 100 hilos.

rgw_num_rados_handles

El número de referencias de clúster de RADOS (consulte http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle) para Object Gateway. Disponer de un número de referencias de RADOS configurable aumenta de forma significativa el rendimiento de todos los tipos de cargas de trabajo. Cada hilo de trabajo de Object Gateway debería elegir ahora una referencia de RADOS para toda su vida útil. El valor por defecto es 1.

rgw_max_chunk_size

El tamaño máximo de una porción de datos que se leerá en una única operación. Si se aumenta el valor a 4 MB (4194304) se conseguirá un mejor rendimiento al procesar objetos grandes. El valor por defecto es 128 kB (131072).

11.4.1 Notas adicionales

rgw dns name

Si el parámetro rgw dns name se añade a ceph.conf, asegúrese de que el cliente de S3 está configurado para dirigir las peticiones al puesto final especificado por rgw dns name.

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

11.5.1 Acceso a Object Gateway

11.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 11.5.2.1, “Adición de usuarios de S3 y Swift”.

  1. Instale el paquete python-boto:

    sudo zypper in python-boto
  2. 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}\t{created}".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.

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

11.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 SP3. Antes de instalar el paquete, debe activar el módulo y actualizar el repositorio de software:

sudo SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper refresh

Para instalar el comando swift, ejecute lo siguiente:

sudo zypper in python-swiftclient

El acceso swift utiliza la sintaxis siguiente:

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 11.5.2.1, “Adición de usuarios de S3 y Swift”.

Por ejemplo:

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

El resultado es:

my-new-bucket

11.5.2 Gestión de cuentas de S3 y Swift

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

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 14.3.1, “Usuarios distintos de Object Gateway para NFS Ganesha”.

Para crear un usuario de Swift, siga estos pasos:

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

    sudo radosgw-admin user create --uid=username \
     --display-name="display-name" --email=email

    Por ejemplo:

    sudo radosgw-admin user create \
       --uid=example_user \
       --display-name="Example User" \
       --email=penguin@example.com
  2. Para crear un subusuario (interfaz de Swift) para el usuario, debe especificar el ID de usuario (--uid=nombre de usuario), el ID de subusuario y el nivel de acceso para el subusuario.

    sudo radosgw-admin subuser create --uid=uid \
     --subuser=uid \
     --access=[ read | write | readwrite | full ]

    Por ejemplo:

    sudo radosgw-admin subuser create --uid=example_user \
     --subuser=example_user:swift --access=full
  3. Genere una clave de secreto para el usuario.

    sudo radosgw-admin key create \
       --gen-secret \
       --subuser=example_user:swift \
       --key-type=swift
  4. 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:

sudo radosgw-admin user create --uid=username \
 --display-name="display-name" --email=email

Por ejemplo:

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

11.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:

sudo radosgw-admin user rm --uid=example_user

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

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

11.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:

sudo radosgw-admin key create --uid=example_user --key-type=s3 --gen-access-key --gen-secret

Para los usuarios de Swift, ejecute lo siguiente:

sudo radosgw-admin key create --subuser=example_user:swift --key-type=swift --gen-secret
--key-type=tipo

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=clave

Especifica una clave de secreto; por ejemplo, una generada manualmente.

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

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

sudo radosgw-admin quota enable --quota-scope=user --uid=example_user

Para inhabilitar una cuota:

sudo radosgw-admin quota disable --quota-scope=user --uid=example_user

Para mostrar la configuración de la cuota:

sudo radosgw-admin user info --uid=example_user

Para actualizar las estadísticas de la cuota:

sudo radosgw-admin user stats --uid=example_user --sync-stats

11.6 Habilitación de HTTPS/SSL para pasarelas Object Gateway

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.

11.6.1 Creación de un certificado autofirmado

Sugerencia
Sugerencia

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 nodo master de Salt.

  1. Añada la opción subjectAltName a la sección [v3_req] del archivo /etc/ssl/openssl.cnf para todos los nombres de host que desee que conozcan su pasarela Object Gateway:

    [...]
    [ v3_req ]
    subjectAltName = ${ENV::SAN}
    [...]
  2. Cree la clave y el certificado con openssl. Añada a openssl el prefijo env SAN=DNS:fqdn. 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 # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem

11.6.2 Configuración básica de HTTPS

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:

  1. Edite /srv/pillar/ceph/stack/global.yml y añada la línea siguiente:

    rgw_configurations: rgw-ssl
    rgw_init: default-ssl
  2. Ejecute las fases 2, 3 y 4 de DeepSea para aplicar los cambios:

    root@master # salt-run state.orch ceph.stage.2
    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

11.6.3 Configuración avanzada de HTTPS

Si necesita cambiar los valores por defecto de la configuración de SSL de Object Gateway, siga estos pasos:

  1. 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
  2. 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.

  3. Ejecute las fases 3 y 4 de DeepSea para aplicar los cambios:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4
Sugerencia
Sugerencia: vinculación con varios puertos

El servidor de CivetWeb 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. Al especificar los puertos, separe sus números de un signo más "+". A continuación se muestra un ejemplo de la línea de configuración de dos puertos:

[client.{{ client }}]
rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem

11.7 Módulos de sincronización

La funcionalidad de varios sitios de Object Gateway, introducida en la versión Jewel, 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 (los operadores de metadatos, como la creación de depósitos o usuarios también se consideran cambios de los datos). Como los cambios en varios sitios de rgw al final acaban siendo consistentes en los sitios remotos, estos cambios se propagan de forma asíncrona. Esto permite 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, etc.

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

11.7.1.1 Requisitos y supuestos

Supongamos que tenemos una configuración sencilla de varios sitios descrita en la Sección 11.11, “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.

11.7.1.2 Configuración de módulos de sincronización

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

    root # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
    --access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80
  2. Puede configurar un módulo de sincronización para esta zona mediante lo siguiente:

    root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \
    --tier-config={set of key=value pairs}
  3. Por ejemplo, en el módulo de sincronización elasticsearch:

    root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \
    --tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

    Para las distintas opciones de configuración de niveles admitidas, consulte la Sección 11.7.2, “Almacenamiento de metadatos en Elasticsearch”.

  4. Por último, actualice el período:

    root # radosgw-admin period update --commit
  5. Inicie ahora radosgw en la zona:

    root # systemctl start ceph-radosgw@rgw.`hostname -s`
    root # systemctl enable ceph-radosgw@rgw.`hostname -s`

11.7.2 Almacenamiento de metadatos en 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"
    }
  }
}

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

11.7.2.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 cadenas (opción por defecto), números enteros y fechas; es decir, si desea indexar el metadato de objeto personalizado x-amz-meta-year como número entero, x-amz-meta-date como fecha y x-amz-meta-title como cadena, debe 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

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

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

11.8.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
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
Sugerencia: comprobaciones de estado

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

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.

11.8.3 Configuración de Object Gateway para utilizar la autenticación LDAP

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://fqdn: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 11.8.4, “Uso de un filtro de búsqueda personalizado para limitar el acceso de usuario” para obtener más información.

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

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

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.

11.8.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
Nota: atributo memberOf

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

11.8.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 11.5.1, “Acceso a Object Gateway”) y especifique el testigo como clave de acceso y utilice una clave de secreto vacía.

root@minion > export RGW_ACCESS_KEY_ID="username"
root@minion > export RGW_SECRET_ACCESS_KEY="password"
root@minion > radosgw-token --encode --ttype=ldap
Importante
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
Nota: Active Directory

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

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

11.9.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 11.9.1.1, “Partición dinámica”, o partir el índice de depósito manualmente sin conexión (consulte la Sección 11.9.1.2, “Partición manual”).

11.9.1.1 Partición dinámica

Desde SUSE Enterprise Storage 5, se admite la partición de depósito en línea. 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.

Importante
Importante: configuraciones de varios sitios

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.

Comandos para administrar el proceso de partición
Añadir un depósito a la cola de partición:
root@minion > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Mostrar la cola de partición:
root@minion > radosgw-admin reshard list
Procesar o programar una partición de depósito:
root@minion > radosgw-admin reshard process
Mostrar el estado de partición del depósito:
root@minion > radosgw-admin reshard status --bucket BUCKET_NAME
Cancelar las particiones de depósito pendientes:
root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 Partición manual

La partición dinámica mencionada en la Sección 11.9.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:

root@minion > 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 objetos 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.

Procedimiento 11.1: Partición del repositorio de índice de depósito
  1. Asegúrese de que se han detenido todas las operaciones dirigidas al depósito.

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

    root@minion > radosgw-admin bi list \
     --bucket=BUCKET_NAME \
     > BUCKET_NAME.list.backup
  3. Vuelva a particionar el índice de depósito:

     root@minion > radosgw-admin reshard \
     --bucket=BUCKET_NAME \
     --num-shards=NEW_SHARDS_NUMBER
    Sugerencia
    Sugerencia: ID de depósito antiguo

    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.

  4. 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:

    root@minion > radosgw-admin bi purge
     --bucket=BUCKET_NAME
     --bucket-id=OLD_BUCKET_ID

11.9.2 Partición de índice de depósito para depósitos nuevo

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.

11.9.2.1 Configuraciones sencillas

  1. Abra el archivo de configuración de Ceph y añada o modifique la siguiente opción:

    rgw_override_bucket_index_max_shards = 12
    Sugerencia
    Sugerencia: todas las instancias de Object Gateway o solo una

    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.

  2. Reinicie Object Gateway. Consulte la Sección 11.3, “Funcionamiento del servicio de Object Gateway” para obtener más información.

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

  1. Exporte la configuración del grupo de zonas al archivo zonegroup.json:

    root@minion > radosgw-admin zonegroup get > zonegroup.json
  2. Edite el archivo zonegroup.json y defina la opción bucket_index_max_shards para cada zona con nombre.

  3. Restablezca el grupo de zonas:

    root@minion > radosgw-admin zonegroup set < zonegroup.json
  4. Actualice el período:

    root@minion > radosgw-admin period update --commit

11.10 Integración de 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.

11.10.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:

  1. Defina el servicio de Swift.Para utilizar OpenStack a fin de validar usuarios de Swift, cree primero el servicio de Swift:

    root # openstack service create \
     --name=swift \
     --description="Swift Service" \
     object-store
  2. 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.

    root # openstack endpoint create --region REGION_NAME \
     --publicurl   "http://radosgw.example.com:8080/swift/v1" \
     --adminurl    "http://radosgw.example.com:8080/swift/v1" \
     --internalurl "http://radosgw.example.com:8080/swift/v1" \
     swift
  3. 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.

    root # openstack endpoint show object-store

11.10.2 Configuración de Ceph Object Gateway

11.10.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"

OpenStack Keystone también se puede interrumpir con un certificado SSL autofirmado, a fin de que Ceph Object Gateway pueda interactuar con Keystone. 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.

11.10.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 del servicio deberían 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 único 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
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.

11.11 Pasarelas Object Gateway de varios sitios

Zona

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.

Grupo de zonas

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.

Mapa de grupo de zonas

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.

Dominio

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.

Período

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.

11.11.1 Terminología

A continuación se muestra una descripción de los términos específicos de una arquitectura federada:

11.11.2 Configuración de clúster de ejemplo

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.

11.11.3 Claves del sistema

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 11.5.2.1, “Adición de usuarios de S3 y Swift”.

Sugerencia
Sugerencia

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)

11.11.4 Convenciones de denominación

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

11.11.5 Repositorios por defecto

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.

11.11.6 Creación de un dominio

Configure un dominio denominado gold y conviértalo en el dominio por defecto:

cephadm > radosgw-admin realm create --rgw-realm=gold --default
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}

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.

11.11.7 Supresión del grupo de zonas por defecto

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 > radosgw-admin zonegroup delete --rgw-zonegroup=default

11.11.8 Creación de un grupo de zonas principal

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 > 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 > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.9 Creación de una zona principal

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 > 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 > radosgw-admin zone default --rgw-zone=us-east-1
cephadm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

11.11.9.1 Creación de usuarios del sistema

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 > radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \
--secret=$SYSTEM_SECRET_KEY --system

11.11.9.2 Actualización del período

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

11.11.9.3 Inicio de Object Gateway

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 11, Ceph Object Gateway. La sección de configuración de Object Gateway debe ser parecida a esto:

[client.rgw.us-east-1]
rgw_frontends="civetweb port=80"
rgw_zone=us-east-1

Inicie Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-east-1

11.11.10 Creación de una zona secundaria

En el mismo clúster, 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 > 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"
}

11.11.10.1 Actualización del período

Informe a todas las pasarelas del nuevo cambio del mapa del sistema realizando una actualización del período y confirmando los cambios:

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

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

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

11.11.10.2 Inicio de Object Gateway

Ajuste la configuración de Object Gateway para la zona secundaria e iníciela:

[client.rgw.us-east-2]
rgw_frontends="civetweb port=80"
rgw_zone=us-east-2
cephadm > sudo systemctl start ceph-radosgw@rgw.us-east-2

11.11.11 Adición de Object Gateway al segundo clúster

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.

11.11.11.1 Dominio y zona de grupos por defecto

Dado que ya ha creado el dominio para la primera pasarela, extraiga el dominio aquí y conviértalo en el dominio por defecto:

cephadm > radosgw-admin realm pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2
}
cephadm > radosgw-admin realm default --rgw-realm=gold

Obtenga la configuración de la zona principal extrayendo el período:

cephadm > 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 > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.11.2 Configuración de la zona secundaria

Cree una zona nueva denominada us-west con las mismas claves del sistema:

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \
--endpoints=http://rgw3:80 --default
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-west",
  "domain_root": "us-west.rgw.data.root",
  "control_pool": "us-west.rgw.control",
  "gc_pool": "us-west.rgw.gc",
  "log_pool": "us-west.rgw.log",
  "intent_log_pool": "us-west.rgw.intent-log",
  "usage_log_pool": "us-west.rgw.usage",
  "user_keys_pool": "us-west.rgw.users.keys",
  "user_email_pool": "us-west.rgw.users.email",
  "user_swift_pool": "us-west.rgw.users.swift",
  "user_uid_pool": "us-west.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-west.rgw.buckets.index",
              "data_pool": "us-west.rgw.buckets.data",
              "data_extra_pool": "us-west.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-west.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

11.11.11.3 Actualización del período

Para propagar los cambios del mapa de grupo de zonas, se actualiza y se confirma el período:

cephadm > radosgw-admin period update --commit --rgw-zone=us-west
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 3,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [
      "", # truncated
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                                  {
                      "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
                      "name": "us-east-2",
                      "endpoints": [
                          "http:\/\/rgw2:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                  {
                      "id": "d9522067-cb7b-4129-8751-591e45815b16",
                      "name": "us-west",
                      "endpoints": [
                          "http:\/\/rgw3:80"
                      ],
                      "log_meta": "false",
                      "log_data": "true",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }
              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          },
          {
              "key": "950c1a43-6836-41a2-a161-64777e07e8b8",
              "val": 4276257543
          },
          {
              "key": "d9522067-cb7b-4129-8751-591e45815b16",
              "val": 329470157
          }
      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

Tenga en cuenta que el número de época del período ha aumentado, lo que indica un cambio en la configuración.

11.11.11.4 Inicio de Object Gateway

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="civetweb port=80"
rgw_zone=us-west

Inicie la segunda pasarela Object Gateway:

sudo systemctl start ceph-radosgw@rgw.us-west

11.11.12 Failover y recuperación tras fallo

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

  1. Convierta la zona secundaria en la zona principal y por defecto. Por ejemplo:

    root # 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:

    root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \
    --read-only=False
  2. Actualice el período para que los cambios surtan efecto.

    root # radosgw-admin period update --commit
  3. 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.

  1. Desde la zona recuperada, extraiga el período de la zona principal actual.

    root # radosgw-admin period pull --url={url-to-master-zone-gateway} \
    --access-key={access-key} --secret={secret}
  2. Convierta la zona recuperada en la zona principal y por defecto.

    root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  3. Actualice el período para que los cambios surtan efecto.

    root # radosgw-admin period update --commit
  4. A continuación, reinicie Ceph Object Gateway en la zona recuperada.

    root # systemctl restart ceph-radosgw@rgw.`hostname -s`
  5. Si la zona secundaria debe tener una configuración de solo lectura, actualice la zona secundaria.

    root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
  6. Actualice el período para que los cambios surtan efecto.

    root # radosgw-admin period update --commit
  7. Por último, reinicie Ceph Object Gateway en la zona secundaria.

    root # systemctl restart ceph-radosgw@rgw.`hostname -s`

11.12 Equilibrio de carga de los servidores de Object Gateway con HAProxy

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-12/book_sleha/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:

root # cat /etc/haproxy/haproxy.cfg
[...]
frontend https_frontend
bind *:443 crt path-to-cert.pem [ciphers: ... ]
default_backend rgw

backend rgw
mode http
balance roundrobin
server rgw_server1 rgw-endpoint1 weight 1 maxconn 100 check
server rgw_server2 rgw-endpoint2 weight 1 maxconn 100 check
[...]
Imprimir esta página