21 Ceph Object Gateway #

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

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

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:

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

O bien

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

Para instalar el comando swift, ejecute lo siguiente:

# 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 _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 swiftswift en la Sección 21.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

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

Para crear un usuario de Swift, siga estos pasos:

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

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

Por ejemplo:

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

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

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

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

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

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

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

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

Puede usar las siguientes opciones:

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.

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

Para los usuarios de S3, ejecute lo siguiente:

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

Para los usuarios de Swift, ejecute lo siguiente:

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

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

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

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

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

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

Para inhabilitar una cuota:

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

Para mostrar la configuración de la cuota:

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

Para actualizar las estadísticas de la cuota:

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

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

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.

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:

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
}

Sugerencia: más información

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

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

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

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

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

Nota: atributo memberOf

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

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:

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.

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

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

cephuser@adm > radosgw-admin bucket reshard

El comando bucket reshard realiza las acciones siguientes:

Sugerencia

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

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:

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

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

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:

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:

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

Sugerencia: asignación a inquilinos de OpenStack

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cephuser@adm > radosgw-admin metadata get user:USER-ID > user.json
> vi user.json     # edit the file as required
cephuser@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

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

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

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

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

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

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

Nota

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

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

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

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

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

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

Importante

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

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

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

Nota

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

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

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

Importante

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

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

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

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

Importante

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

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

Aviso

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

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

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

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

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

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

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

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

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

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

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

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

Nota

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

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

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

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

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

Nota

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

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

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

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

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

Por ejemplo:

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

Importante

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

Suprima la zona por defecto si es necesario:

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

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

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

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

Para ello, ejecute el comando siguiente:

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

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

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

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

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

Nota

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

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

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

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

cephuser@adm > radosgw-admin sync status

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

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

Nota

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

Por defecto, los objetos no se vuelven a verificar después de que la sincronización de un objeto se haya realizado correctamente. Para habilitar la verificación, defina la opción rgw_sync_obj_etag_verify en true. Cuando estén habilitados, los objetos opcionales se sincronizarán. Una suma de comprobación MD5 adicional verificará que se calcula en el origen y en el destino. Esto garantiza la integridad de los objetos obtenidos de un servidor remoto a través de HTTP, incluida la sincronización de varios sitios. Esta opción puede reducir el rendimiento de los RGW, ya que se necesita más capacidad de cálculo.

La información sobre el estado de réplica de una zona se puede consultar con:

cephuser@adm > radosgw-admin sync status
        realm b3bc1c37-9c44-4b89-a03b-04c269bea5da (gold)
    zonegroup f54f9b22-b4b6-4a0e-9211-fa6ac1693f49 (us)
         zone adce11c9-b8ed-4a90-8bc5-3fc029ff0816 (us-west)
        metadata sync syncing
              full sync: 0/64 shards
              incremental sync: 64/64 shards
              metadata is behind on 1 shards
              oldest incremental change not applied: 2017-03-22 10:20:00.0.881361s
data sync source: 341c2d81-4574-4d08-ab0f-5a2a7b168028 (us-east)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source
          source: 3b5d1a3f-3f27-4e4a-8f34-6072d4bb1275 (us-3)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source

El resultado puede variar según el estado de sincronización. Durante la sincronización, se describen dos tipos distintos de fragmentos:

Solo en la funcionalidad de varios sitios, puede consultar el registro de metadatos (mdlog), el registro de índice de papelera (bilog) y el registro de datos (datalog). Es posible mostrarlos y recortarlos. No es necesario hacerlo en la mayoría de los casos, ya que la opción rgw_sync_log_trim_interval está definida en 20 minutos por defecto. Si no se establece manualmente en 0, no será necesario recortarlos en ningún momento, ya que de lo contrario podría provocar efectos secundarios.

Importante

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

Para subir de nivel una zona (por ejemplo, la zona us-west del grupo de zonas us) a zona principal de metadatos, ejecute los comandos siguientes en esa zona:

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

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