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

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

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

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

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

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:

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

Sugerencia: vinculación con varios puertos

El servidor de Beast puede vincularse a varios puertos. Esto resulta útil si necesita acceder a una única instancia de Object Gateway mediante conexiones tanto SSL como no SSL. A continuación se muestra un ejemplo de una línea de configuración de dos puertos:

[client.{{ client }}]
rgw_frontends = beast port=80 ssl_port=443 ssl_certificate=/etc/ceph/rgw.pem

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

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

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

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

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

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

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

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

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

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

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

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

Nota: Complemento de sincronización por defecto

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

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

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

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

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

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

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

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

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

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

17.8.5.1 Configuración #

Sugerencia: más información

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

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

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

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

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.

Los siguientes parámetros del archivo de configuración /etc/ceph/ceph.conf están relacionados con la autenticación LDAP:

Existen dos formas de utilizar el parámetro rgw_search_filter.

"objectclass=inetorgperson"

"(&(uid=hari)(objectclass=inetorgperson))"

17.9.4.2 Filtro completo #

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

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

Nota: atributo memberOf

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

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

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

Importante: credenciales en texto no cifrado

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

Nota: Active Directory

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

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

17.10.1.1 Partición dinámica #

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

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

• Cuando se añaden nuevos objetos al depósito.

• En un proceso en segundo plano que explora periódicamente todos los depósitos. Esto es necesario para tratar con los depósitos existentes que no se van a actualizar.

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

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

rgw_dynamic_resharding

Habilita o inhabilita la partición del índice de depósito dinámica. Los valores válidos son "true" (verdadero) o "false" (falso). Por defecto es "true" (verdadero).

rgw_reshard_num_logs

El número de particiones para el registro. Se usa el valor por defecto de 16.

rgw_reshard_bucket_lock_duration

Duración del bloqueo en el objeto de depósito durante la partición. Se usa el valor por defecto de 120 segundos.

rgw_max_objs_per_shard

El número máximo de objetos por partición de índice de depósito. Por defecto es 100 000 objetos.

rgw_reshard_thread_interval

El tiempo máximo entre las rondas de procesamiento de hilos de partición. Se usa el valor por defecto de 600 segundos.

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:

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

Mostrar la cola de partición:

cephadm@adm > radosgw-admin reshard list

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

cephadm@adm > radosgw-admin reshard process

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

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

Cancelar las particiones de depósito pendientes:

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

cephadm@adm > radosgw-admin bucket reshard

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

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.

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

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

cephadm@adm > radosgw-admin bucket stats

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

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

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

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

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

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

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

Nota: sin configuración de varios sitios anterior

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

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

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

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

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

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

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

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

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

En este ejemplo nos centraremos en la creación de un único grupo de zonas con tres zonas independiente que sincronizan sus datos de forma activa. Dos zonas pertenecen al mismo clúster, mientras que la tercera pertenece a otro diferente. No hay ningún agente de sincronización implicado en la duplicación de los cambios de datos entre las pasarelas Object Gateway. Esto permite un esquema de configuración mucho más sencillo y configuraciones de tipo activa-activa. Tenga en cuenta que las operaciones de metadatos, como crear un usuario nuevo, aún deben realizarse a través de la zona principal. Sin embargo, las operaciones de datos, como la creación de depósitos y objetos, se pueden gestionar en cualquiera de las zonas.

Durante la configuración de las zonas, Object Gateway espera que se cree un usuario de sistema compatible con S3 junto con sus claves de acceso y de secreto. Esto permite a otra instancia de Object Gateway extraer la configuración de forma remota con las claves de acceso y de secreto. Para obtener más información sobre cómo crear usuarios de S3, consulte la Sección 17.5.2.1, “Adición de usuarios de S3 y Swift”.

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)

Este ejemplo describe el proceso de configuración de una zona principal. Partiremos de un grupo de zonas denominado us que abarca los Estados Unidos, que serán nuestro grupo de zonas principal. Contendrá dos zonas con el formato GRUPOZONAS-ZONA. Esto es simplemente una convención que se usa para este ejemplo, pero puede elegir el formato que prefiera. En resumen:

Todo esto formará parte de un dominio mayor denominado gold. Las zonas us-east-1 y us-east-2 forman parte del mismo clúster de Ceph, us-east-1 es la principal. us-west está en un clúster de Ceph diferente.

Si se ha configurado con los permisos apropiados, Object Gateway crea repositorios por defecto por sí misma. Los valores pg_num y pgp_num se toman del archivo de configuración ceph.conf. Los repositorios relacionados con una zona, siguen por defecto la convención NOMBRE-ZONA.NOMBRE-REPOSITORIO. Por ejemplo, para la zona us-east-1, serán los repositorios siguientes:

.rgw.root
us-east-1.rgw.control
us-east-1.rgw.data.root
us-east-1.rgw.gc
us-east-1.rgw.log
us-east-1.rgw.intent-log
us-east-1.rgw.usage
us-east-1.rgw.users.keys
us-east-1.rgw.users.email
us-east-1.rgw.users.swift
us-east-1.rgw.users.uid
us-east-1.rgw.buckets.index
us-east-1.rgw.buckets.data
us-east-1.rgw.meta

Estos repositorios se pueden crear también en otras zonas; basta con sustituir us-east-1 por el nombre de zona correspondiente.

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

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

Tenga en cuenta que cada dominio tiene un ID, lo que aporta flexibilidad, por ejemplo si hay que cambiar el nombre del dominio más tarde. El valor de current_period cambia cada vez que se modifica algo en la zona principal. El valor de epoch aumenta cuando se produce un cambio en la configuración de la zona principal que provoque un cambio del periodo actual.

La instalación por defecto de Object Gateway crea el grupo de zonas por defecto denominado default. Dado que ya no se necesita el grupo de zonas por defecto, elimínelo.

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

Cree un grupo de zonas principal denominado us. Este grupo de zonas gestionará el mapa del grupo de zonas y propagará los cambios al resto del sistema. Si se marca el grupo de zonas como grupo por defecto, se permite explícitamente que se mencione el parámetro rgw-zonagroup en comandos posteriores.

cephadm@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default
{
  "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "name": "us",
  "api_name": "us",
  "is_master": "true",
  "endpoints": [
      "http:\/\/rgw1:80"
  ],
  "hostnames": [],
  "hostnames_s3website": [],
  "master_zone": "",
  "zones": [],
  "placement_targets": [],
  "default_placement": "",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

Si lo prefiere, puede marcar un grupo de zonas como grupo por defecto con el comando siguiente:

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

Cree ahora una zona por defecto y añádala al grupo de zonas por defecto. Tenga en cuenta que utilizará esta zona para las operaciones de metadatos, como la creación de usuarios:

cephadm@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
{
  "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "name": "us-east-1",
  "domain_root": "us-east-1/gc.rgw.data.root",
  "control_pool": "us-east-1/gc.rgw.control",
  "gc_pool": "us-east-1/gc.rgw.gc",
  "log_pool": "us-east-1/gc.rgw.log",
  "intent_log_pool": "us-east-1/gc.rgw.intent-log",
  "usage_log_pool": "us-east-1/gc.rgw.usage",
  "user_keys_pool": "us-east-1/gc.rgw.users.keys",
  "user_email_pool": "us-east-1/gc.rgw.users.email",
  "user_swift_pool": "us-east-1/gc.rgw.users.swift",
  "user_uid_pool": "us-east-1/gc.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-1/gc.rgw.buckets.index",
              "data_pool": "us-east-1/gc.rgw.buckets.data",
              "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-1/gc.rgw.meta",
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

Recuerde también que los parámetros ‑‑rgw-zonagroup y ‑‑default añaden la zona a un grupo de zonas y la convierten en la zona por defecto. Como alternativa, se puede hacer lo mismo con los comandos siguientes:

cephadm@adm > radosgw-admin zone default --rgw-zone=us-east-1
cephadm@adm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

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

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

cephadm@adm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 1,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [ "[...]"
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  }
              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          }
      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

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

root # systemctl start ceph-radosgw@rgw.us-east-1

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

En el clúster secundario, cree y configure la zona secundaria denominada us-east-2. Puede ejecutar los comandos siguientes en el nodo que aloja la zona principal.

Para crear la zona secundaria, utilice el mismo comando que usó al crear la zona principal, pero no incluya el parámetro master:

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

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

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

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

[client.rgw.us-east-2]
rgw_frontends="beast port=80"
rgw_zone=us-east-2

cephadm@adm > sudo systemctl start ceph-radosgw@rgw.us-east-2

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.

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

cephadm@adm > radosgw-admin period pull --url=http://rgw1:80 \
--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

cephadm@adm > radosgw-admin zonegroup default --rgw-zonegroup=us

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

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

[client.rgw.us-west]
rgw_frontends="beast port=80"
rgw_zone=us-west

root # systemctl start ceph-radosgw@rgw.us-west

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

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