Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7.1 / Guia de Administração e Operações / Acessando os dados do cluster / Gateway de Objetos do Ceph
Aplica-se a SUSE Enterprise Storage 7.1

21 Gateway de Objetos do Ceph

Este capítulo apresenta detalhes sobre as tarefas de administração relacionadas ao Gateway de Objetos, como verificação de status do serviço, gerenciamento de contas, gateways multissite ou autenticação LDAP.

21.1 Restrições e limitações de nomeação do Gateway de Objetos

Veja a seguir uma lista dos limites importantes do Gateway de Objetos:

21.1.1 Limitações de compartimento de memória

Ao usar o Gateway de Objetos por meio da API do S3, há um limite para os nomes de compartimento de memória que devem ser compatíveis com DNS e podem ter um traço “-”. Ao usar o Gateway de Objetos por meio da API do Swift, você pode aplicar qualquer combinação de caracteres UTF-8 permitidos, exceto a barra “/”. O tamanho máximo do nome de um compartimento de memória é de 255 caracteres. Os nomes de compartimento de memória devem ser exclusivos.

Dica
Dica: Usar nomes de compartimento de memória compatíveis com DNS

Embora seja possível usar qualquer nome de compartimento de memória baseado em UTF-8 por meio da API do Swift, é recomendável nomear os compartimentos de memória de acordo com as limitações de nomeação do S3 para evitar problemas ao acessar o mesmo compartimento de memória pela API do S3.

21.1.2 Limitações de objetos armazenados

Número máximo de objetos por usuário

Por padrão, nenhuma restrição (limitado por ~ 2^63).

Número máximo de objetos por compartimento de memória

Por padrão, nenhuma restrição (limitado por ~ 2^63).

Tamanho máximo de um objeto para upload/armazenamento

Cada upload está restrito a 5 GB. Use várias partes para tamanhos de objetos maiores. O número máximo de pacotes de várias partes é 10.000.

21.1.3 Limitações de cabeçalho HTTP

A limitação de cabeçalho HTTP e de solicitação depende do front end da Web usado. O Beast padrão restringe o tamanho do cabeçalho HTTP a 16 kB.

21.2 Implantando o Gateway de Objetos

A implantação do Gateway de Objetos do Ceph segue o mesmo procedimento da implantação de outros serviços do Ceph: por meio do cephadm. Para obter mais detalhes, consulte o Seção 8.2, “Especificação de serviço e posicionamento”, especificamente o Seção 8.3.4, “Implantando Gateways de Objetos”.

21.3 Operando o serviço Gateway de Objetos

Você pode operar os Gateways de Objetos da mesma forma que os outros serviços do Ceph, identificando primeiro o nome do serviço com o comando ceph orch ps e executando o seguinte comando para os serviços operacionais, por exemplo:

ceph orch daemon restart OGW_SERVICE_NAME

Consulte o Capítulo 14, Operação de serviços do Ceph para obter informações completas sobre como operar os serviços do Ceph.

21.4 Opções de configuração

Consulte a Seção 28.5, “Gateway de Objetos do Ceph” para ver uma lista de opções de configuração do Gateway de Objetos.

21.5 Gerenciando o acesso ao Gateway de Objetos

Você pode se comunicar com o Gateway de Objetos usando qualquer interface compatível com S3 ou Swift. A interface do S3 é compatível com um grande subconjunto da API RESTful do Amazon S3. A interface do Swift é compatível com um grande subconjunto da API do OpenStack Swift.

As duas interfaces exigem que você crie um usuário específico e instale o software cliente relevante para comunicação com o gateway usando a chave secreta do usuário.

21.5.1 Acessando o Gateway de Objetos

21.5.1.1 Acesso à interface do S3

Para acessar a interface do S3, você precisa de um cliente REST. S3cmd é um cliente S3 de linha de comando. Você pode encontrá-lo em OpenSUSE Build Service. O repositório contém as versões para ambas as distribuições baseadas no SUSE Linux Enterprise e no openSUSE.

Para testar o acesso à interface do S3, você também pode gravar um pequeno script do Python. O script se conectará ao Gateway de Objetos, criará um novo compartimento de memória e listará todos os compartimentos de memória. Os valores para aws_access_key_id e aws_secret_access_key são extraídos dos valores de access_key e secret_key retornados pelo comando radosgw_admin da Seção 21.5.2.1, “Adicionando usuários do S3 e do Swift”.

  1. Instale o pacote python-boto:

    # zypper in python-boto
  2. Crie um novo script do Python denominado s3test.py com o seguinte conteúdo:

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

    Substitua HOSTNAME pelo nome de host no qual você configurou o serviço do Gateway de Objetos. Por exemplo, gateway_host.

  3. Execute o script:

    python s3test.py

    A saída do script é parecida com o seguinte:

    my-new-bucket 2015-07-22T15:37:42.000Z

21.5.1.2 Acesso à interface do Swift

Para acessar o Gateway de Objetos pela interface do Swift, você precisa do cliente de linha de comando swift. A página de manual dele man 1 swift apresenta mais detalhes sobre as opções de linha de comando.

O pacote está incluído no módulo “Public Cloud” para o SUSE Linux Enterprise 12 a partir do SP3 e o SUSE Linux Enterprise 15. Antes de instalar o pacote, você precisa ativar o módulo e atualizar o repositório de software:

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

Ou

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

Para instalar o comando swift, execute o seguinte:

# zypper in python-swiftclient

O acesso ao swift usa a seguinte sintaxe:

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

Substitua IP_ADDRESS pelo endereço IP do servidor gateway, e _SECRET_KEY pelo respectivo valor da saída do comando radosgw-admin key create executado para o usuário swiftswift na Seção 21.5.2.1, “Adicionando usuários do S3 e do Swift”.

Por exemplo:

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

A saída é:

my-new-bucket

21.5.2 Gerenciar contas do S3 e do Swift

21.5.2.1 Adicionando usuários do S3 e do Swift

É necessário criar um usuário, uma chave de acesso e um segredo para permitir que os usuários finais interajam com o gateway. Há dois tipos de usuário: usuário e subusuário. Os usuários são usados para interagir com a interface do S3, os subusuários são usuáros da interface do Swift. Cada subusuário está associado a um usuário.

Para criar um usuário do Swift, siga as etapas:

  1. Para criar um usuário do Swift, que é um subusuário em nossa terminologia, você precisa criar primeiro o usuário associado.

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

    Por exemplo:

    cephuser@adm > radosgw-admin user create \
       --uid=example_user \
       --display-name="Example User" \
       --email=penguin@example.com
  2. Para criar um subusuário (interface do Swift) para o usuário, você deve especificar o ID de usuário (--uid=USERNAME), um ID de subusuário e o nível de acesso para o subusuário.

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

    Por exemplo:

    cephuser@adm > radosgw-admin subuser create --uid=example_user \
     --subuser=example_user:swift --access=full
  3. Gere uma chave secreta para o usuário.

    cephuser@adm > radosgw-admin key create \
       --gen-secret \
       --subuser=example_user:swift \
       --key-type=swift
  4. Os dois comandos resultarão em dados formatados em JSON que mostram o estado do usuário. Observe as linhas a seguir e lembre-se do valor secret_key:

    "swift_keys": [
       { "user": "example_user:swift",
         "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],

Ao acessar o Gateway de Objetos por meio da interface do S3, você precisa criar um usuário do S3 executando:

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

Por exemplo:

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

O comando também cria o acesso do usuário e a chave secreta. Verifique a saída para as palavras-chave access_key e secret_key e seus valores:

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

21.5.2.2 Removendo usuários do S3 e do Swift

O procedimento para apagar usuários é semelhante para os usuários do S3 e do Swift. No caso dos usuários do Swift, porém, você pode precisar apagar o usuário com os subusuários incluídos.

Para remover um usuário do S3 ou do Swift (incluindo todos os subusuários), especifique user rm e o ID de usuário no seguinte comando:

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

Para remover um subusuário, especifique subuser rm e o ID de subusuário.

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

Você pode usar as seguintes opções:

--purge-data

Purga todos os dados associados ao ID de usuário.

--purge-keys

Purga todas as chaves associadas ao ID de usuário.

Dica
Dica: Removendo um subusuário

Ao remover um subusuário, você remove o acesso à interface do Swift. O usuário permanecerá no sistema.

21.5.2.3 Mudando o acesso e as chaves secretas do usuário do S3 e do Swift

Os parâmetros access_key e secret_key identificam o usuário do Gateway de Objetos ao acessar o gateway. A mudança das chaves existentes de usuário é o mesmo que criar novas chaves, pois as chaves antigas são sobregravadas.

Para usuários do S3, execute o seguinte:

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

Para usuários do Swift, execute o seguinte:

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

Especifica o tipo de chave. Pode ser swift ou s3.

--gen-access-key

Gera uma chave de acesso aleatória (por padrão, para o usuário do S3).

--gen-secret

Gera uma chave secreta aleatória.

--secret=KEY

Especifica uma chave secreta. Por exemplo, gerada manualmente.

21.5.2.4 Habilitando o gerenciamento de cotas de usuários

O Gateway de Objetos do Ceph permite definir cotas para usuários e compartimentos de memória pertencentes aos usuários. As cotas incluem o número máximo de objetos em um compartimento de memória e o tamanho máximo de armazenamento em megabytes.

Antes de habilitar uma cota de usuário, você precisa definir os respectivos parâmetros:

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

Especifica o número máximo de objetos. Um valor negativo desabilita a verificação.

--max-size

Especifica o número máximo de bytes. Um valor negativo desabilita a verificação.

--quota-scope

Define o escopo para a cota. As opções são bucket e user. As cotas de compartimento de memória aplicam-se aos compartimentos de memória que um usuário possui. As cotas de usuário aplicam-se a um usuário.

Após definir uma cota de usuário, você poderá habilitá-la:

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

Para desabilitar uma cota:

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

Para listar as configurações de cota:

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

Para atualizar as estatísticas de cota:

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

21.6 Front ends HTTP

O Gateway de Objetos do Ceph suporta dois front ends HTTP incorporados: Beast e Civetweb.

O front end Beast usa a biblioteca Boost.Beast para análise de HTTP e a biblioteca Boost.Asio para E/S de rede assíncrona.

O front end Civetweb usa a biblioteca HTTP Civetweb, que é uma bifurcação do Mongoose.

Você pode configurá-la com a opção rgw_frontends. Consulte a Seção 28.5, “Gateway de Objetos do Ceph” para ver uma lista de opções de configuração.

21.7 Habilitar HTTPS/SSL para Gateways de Objetos

Para habilitar a comunicação segura do Gateway de Objetos por meio de SSL, você precisa ter um certificado emitido por uma CA ou criar um autoassinado.

21.7.1 Criando um certificado autoassinado

Dica
Dica

Ignore esta seção se você já tem um certificado válido assinado por uma CA.

O procedimento a seguir descreve como gerar um certificado SSL autoassinado no Master Salt.

  1. Se você precisar que o Gateway de Objetos seja reconhecido por outras identidades de assunto, adicione-as à opção subjectAltName na seção [v3_req] do arquivo /etc/ssl/openssl.cnf:

    [...]
    [ v3_req ]
    subjectAltName = DNS:server1.example.com DNS:server2.example.com
    [...]
    Dica
    Dica: Endereços IP em subjectAltName

    Para usar endereços IP no lugar de nomes de domínio na opção subjectAltName, substitua a linha de exemplo pelo seguinte:

    subjectAltName = IP:10.0.0.10 IP:10.0.0.11
  2. Crie a chave e o certificado usando openssl. Insira todos os dados que você precisa incluir em seu certificado. É recomendável inserir o FQDN como nome comum. Antes de assinar o certificado, verifique se “X509v3 Subject Alternative Name:” está incluído nas extensões solicitadas e se o certificado resultante tem "X509v3 Subject Alternative Name:" definido.

    root@master # openssl req -x509 -nodes -days 1095 \
     -newkey rsa:4096 -keyout rgw.key
     -out rgw.pem
  3. Anexe a chave ao arquivo de certificado:

    root@master # cat rgw.key >> rgw.pem

21.7.2 Configurando o Gateway de Objetos com SSL

Para configurar o Gateway de Objetos para usar certificados SSL, use a opção rgw_frontends. Por exemplo:

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

Se você não especificar as chaves de configuração CERT e KEY, o serviço Gateway de Objetos procurará o certificado SSL e a chave nas seguintes chaves de configuração:

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

Para anular a chave SSL padrão e o local do certificado, importe-os para o banco de dados de configuração usando o seguinte comando:

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

Em seguida, use as chaves de configuração personalizadas com a diretiva config://.

21.8 Módulos de sincronização

O Gateway de Objetos é implantado como um serviço multissite, enquanto você pode espelhar dados e metadados entre as zonas. Os módulos de sincronização foram desenvolvidos com base na estrutura multissite, que permite encaminhar dados e metadados para uma camada externa diferente. Um módulo de sincronização permite a execução de um conjunto de ações sempre que há uma mudança nos dados (por exemplo, operações de metadados como criação de compartimento de memória ou de usuário). Como as mudanças de multissite do Gateway de Objetos acabam sendo consistentes em sites remotos, elas são propagadas de forma assíncrona. Isso abrange casos de uso como backup de armazenamento de objetos em um cluster de nuvem externo, solução de backup personalizada que usa unidades de fita ou indexação de metadados no ElasticSearch.

21.8.1 Configurando módulos de sincronização

Todos os módulos de sincronização são configurados de forma semelhante. Você precisa criar uma nova zona (consulte a Seção 21.13, “Gateways de Objetos multissite” para obter mais detalhes) e definir a opção --tier_type dela, por exemplo, --tier-type=cloud para o módulo de sincronização de nuvem:

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

Você pode configurar a camada específica usando o seguinte comando:

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

A KEY (CHAVE) na configuração especifica a variável de configuração que você deseja atualizar, e o VALUE (VALOR) especifica o novo valor dela. É possível usar um ponto para acessar os valores aninhados. Por exemplo:

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

Você pode acessar entradas de matriz anexando colchetes “[]” com a entrada referenciada. Você pode adicionar uma nova entrada de matriz usando colchetes “[]”. O valor do índice de -1 faz referência à última entrada na matriz. Não é possível criar uma nova entrada e fazer referência a ela novamente no mesmo comando. Por exemplo, veja a seguir um comando para criar um novo perfil para compartimentos de memória que começam com PREFIX:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID
Dica
Dica: Adicionando e removendo entradas de configuração

Você pode adicionar uma nova entrada de configuração de camada usando o parâmetro --tier-config-add=KEY=VALUE.

Você pode remover uma entrada existente usando --tier-config-rm=KEY.

21.8.2 Sincronizando zonas

A configuração de um módulo de sincronização é local para uma zona. O módulo de sincronização determina se a zona exporta os dados ou apenas pode consumir os dados que foram modificados em outra zona. A partir do Luminous, os plug-ins de sincronização suportados são ElasticSearch, rgw, que é o plug-in padrão que sincroniza dados entre zonas, e log, que é o plug-in comum que registra a operação de metadados executada nas zonas remotas. As seções a seguir foram elaboradas com o exemplo de uma zona que usa o módulo de sincronização ElasticSearch. O mesmo processo pode ser aplicado para configurar qualquer outro plug-in de sincronização.

Nota
Nota: Plug-in de sincronização padrão

rgw é o plug-in de sincronização padrão, e não há necessidade de configurá-lo explicitamente.

21.8.2.1 Requisitos e considerações

Vamos considerar uma configuração multissite simples, conforme descrito na Seção 21.13, “Gateways de Objetos multissite”, com 2 zonas: us-east e us-west. Agora, adicionamos uma terceira zona us-east-es, que processará apenas os metadados de outros sites. Essa zona pode estar no mesmo ou em um cluster do Ceph diferente do us-east. Essa zona consumirá apenas os metadados de outras zonas, e os Gateways de Objetos nela não atenderão diretamente nenhuma solicitação de usuário final.

21.8.2.2 Configurando zonas

  1. Crie a terceira zona semelhante àquelas descritas na Seção 21.13, “Gateways de Objetos multissite”. Por exemplo,

    cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
    --access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80
  2. É possível configurar um módulo de sincronização para essa zona por meio do seguinte comando:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
    --tier-config={set of key=value pairs}
  3. Por exemplo, no módulo de sincronização ElasticSearch

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \
    --tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

    Para as várias opções de configuração de camada suportadas, consulte a Seção 21.8.3, “Módulo de sincronização ElasticSearch”.

  4. Por fim, atualize o período

    cephuser@adm > radosgw-admin period update --commit
  5. Agora, inicie o Gateway de Objetos na zona

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

21.8.3 Módulo de sincronização ElasticSearch

Esse módulo de sincronização grava os metadados de outras zonas no ElasticSearch. A partir do Luminous, é o JSON dos campos de dados que armazenamos no ElasticSearch atualmente.

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

21.8.3.1 Parâmetros de configuração de tipo de camada do ElasticSearch

endpoint

Especifica o endpoint do servidor ElasticSearch a ser acessado.

num_shards

(número inteiro) O número de fragmentos com os quais o ElasticSearch será configurado na inicialização da sincronização de dados. Observe que ele não pode ser mudado após a inicialização. Qualquer mudança aqui requer a reconstrução do índice do ElasticSearch e a reinicialização do processo de sincronização de dados.

num_replicas

(número inteiro) O número de réplicas com as quais o ElasticSearch será configurado na inicialização da sincronização de dados.

explicit_custom_meta

(true | false) Especifica se todos os metadados personalizados do usuário serão indexados ou se o usuário precisará configurar (no nível do compartimento de memória) quais entradas de metadados do cliente devem ser indexadas. Por padrão, isso é “false”

index_buckets_list

(lista de strings separadas por vírgulas) Se vazia, todos os compartimentos de memória serão indexados. Do contrário, apenas os compartimentos de memória especificados nela serão indexados. É possível inserir prefixos (por exemplo, “foo*”) ou sufixos (por exemplo, “*bar”) de compartimento de memória.

approved_owners_list

(lista de strings separadas por vírgulas) Se vazia, os compartimentos de memória de todos os proprietários serão indexados (sujeito a outras restrições); do contrário, apenas os compartimentos de memória pertencentes a determinados proprietários serão indexados. É possível também inserir prefixos e sufixos.

override_index_path

(string) Se não estiver vazia, essa string será usada como o caminho do índice do ElasticSearch. Do contrário, o caminho do índice será determinado e gerado na inicialização da sincronização.

username

Especifica um nome de usuário para o ElasticSearch se a autenticação for necessária.

password

Especifica uma senha para o ElasticSearch se a autenticação for necessária.

21.8.3.2 Consultas de metadados

Como o cluster do ElasticSearch agora armazena metadados de objetos, é importante não expor o endpoint do ElasticSearch ao público e mantê-lo acessível apenas aos administradores de cluster. A própria exposição das consultas de metadados ao usuário final representa um problema, já que desejamos que o usuário consulte apenas os metadados dele, e não de quaisquer outros usuários. Para isso, o cluster do ElasticSearch deve autenticar os usuários de modo similar ao RGW, o que representa um problema.

A partir do Luminous, o RGW na zona master de metadados agora pode atender às solicitações de usuários finais. Isso evita a exposição do endpoint do ElasticSearch ao público e resolve também o problema de autenticação e autorização, pois o próprio RGW pode autenticar as solicitações de usuário final. Para essa finalidade, o RGW inclui uma nova consulta nas APIs de compartimento de memória que pode atender às solicitações de serviço do ElasticSearch. Todas essas solicitações devem ser enviadas para a zona master de metadados.

Obter uma consulta do ElasticSearch
GET /BUCKET?query=QUERY-EXPR

parâmetros de solicitação:

  • max-keys: número máx. de entradas a retornar

  • marker: marcador de paginação

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

op é um dos seguintes: <, <=, ==, >=, >

Por exemplo:

GET /?query=name==foo

Retornará todas as chaves indexadas para as quais o usuário tem permissão de leitura e que são denominadas “foo”. A saída será uma lista de chaves em XML, que é semelhante à resposta de compartimentos de memória da lista do S3.

Configurar campos personalizados de metadados

Defina quais entradas de metadados personalizados devem ser indexadas (no compartimento de memória especificado) e quais são os tipos das chaves. Se for configurada a indexação explícita de metadados personalizados, esse procedimento será necessário para o rgw indexar os valores de metadados personalizados especificados. Do contrário, ele será necessário nos casos em que as chaves dos metadados indexados são de um tipo diferente de string.

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

Vários campos de metadados devem ser separados por vírgula. É possível forçar um tipo para um campo com “;”. Os tipos permitidos atualmente são string (padrão), número inteiro e data. Por exemplo, para indexar metadados de um objeto personalizado x-amz-meta-year como número inteiro, x-amz-meta-date como o tipo data e x-amz-meta-title como string, faça o seguinte

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string
Apague a configuração de metadados personalizados

Apague a configuração de compartimento de memória dos metadados personalizados.

DELETE /BUCKET?mdsearch
Obter a configuração dos metadados personalizados

Recupere a configuração de compartimento de memória dos metadados personalizados.

GET /BUCKET?mdsearch

21.8.4 Módulo de sincronização de nuvem

Esta seção apresenta um módulo que sincroniza os dados da zona com um serviço de nuvem remoto. A sincronização é apenas unidirecional, os dados não são sincronizados de volta da zona remota. O principal objetivo deste módulo é habilitar a sincronização de dados com vários provedores de serviços de nuvem. Atualmente, ele suporta provedores de nuvem compatíveis com a AWS (S3).

Para sincronizar os dados com um serviço de nuvem remoto, você precisa configurar as credenciais do usuário. Como muitos serviços de nuvem apresentam limites quanto ao número de compartimentos de memória que cada usuário pode criar, é possível configurar o mapeamento de objetos e compartimentos de memória de origem, destinos diferentes para compartimentos de memória distintos e prefixos de compartimento de memória. Observe que as listas de acesso de origem (ACLs) não serão preservadas. É possível mapear permissões de usuários de origem específicos para usuários de destino específicos.

Devido às limitações da API, não existe um modo de preservar o horário de modificação do objeto original e a tag da entidade HTTP (ETag). O módulo de sincronização de nuvem armazena essas informações como atributos de metadados nos objetos de destino.

21.8.4.1 Configurando o módulo de sincronização de nuvem

Veja a seguir exemplos de uma configuração comum e não comum para o módulo de sincronização de nuvem. Observe que a configuração comum pode ser diferente da não comum.

Exemplo 21.1: Configuração comum
{
  "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,
}
Exemplo 21.2: Configuração não comum
{
  "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
  } ... ],
}

Veja a seguir a explicação dos termos de configuração usados:

connection

Representa uma conexão com o serviço de nuvem remota. Contém "connection_id", "access_key", "secret", "endpoint" e "host_style".

access_key

A chave de acesso à nuvem remota que será usada para a conexão específica.

secret

A chave secreta para o serviço de nuvem remota.

endpoint

URL do endpoint do serviço de nuvem remota.

host_style

Tipo de estilo do host ("path" ou "virtual") a ser usado quando acessar o endpoint da nuvem remota. O padrão é “path” (caminho).

acls

Matriz de mapeamentos da lista de acesso.

acl_mapping

Cada estrutura "acl_mapping" contém "type", "source_id" e "dest_id". Eles definirão a mutação da ACL para cada objeto. Uma mutação da ACL permite converter o ID de usuário de origem em um ID de destino.

type

Tipo de ACL: "id" define o ID de usuário, "email" define o usuário por e-mail e "uri" define o usuário por URI (grupo).

source_id

ID do usuário na zona de origem.

dest_id

ID do usuário no destino.

target_path

Uma string que define como o caminho de destino é criado. O caminho de destino especifica um prefixo ao qual o nome do objeto de origem é anexado. O caminho de destino configurável pode incluir qualquer uma das seguintes variáveis:

SID

Uma string exclusiva que representa o ID da instância de sincronização.

ZONEGROUP

Nome do grupo de zonas.

ZONEGROUP_ID

ID do grupo de zonas.

ZONE

Nome da zona.

ZONE_ID

ID da zona.

BUCKET

Nome do compartimento de memória de origem.

OWNER

ID do proprietário do compartimento de memória de origem.

Por exemplo: target_path = rgwx-ZONE-SID/OWNER/BUCKET

acl_profiles

Uma matriz de perfis da lista de acesso.

acl_profile

Cada perfil contém: “acls_id”, que representa o perfil, e uma matriz de “acls”, que armazena uma lista de “acl_mappings”.

profiles

Uma lista de perfis. Cada perfil contém o seguinte:

source_bucket

Nome ou prefixo do compartimento de memória (se terminar com *), que define o(s) compartimento(s) de memória de origem para este perfil.

target_path

Veja a explicação acima.

connection_id

ID da conexão que será usada para este perfil.

acls_id

ID do perfil da ACL que será usado para este perfil.

21.8.4.2 Elementos de configuração específicos do S3

O módulo de sincronização de nuvem apenas funcionará com back ends compatíveis com o AWS S3. Há alguns elementos de configuração que podem ser usados para ajustar o comportamento ao acessar serviços de nuvem do S3:

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

Os objetos cujo tamanho é igual ou maior do que esse valor serão sincronizados com o serviço de nuvem por meio do upload de várias partes.

multipart_min_part_size

Tamanho mínimo das partes para usar na sincronização de objetos por meio do upload de várias partes.

21.8.5 Módulo de sincronização de arquivo

O módulo de sincronização de arquivo usa o recurso de controle de versão dos objetos do S3 no Gateway de Objetos. Você pode configurar uma zona de arquivo, que captura as diferentes versões dos objetos do S3 à medida que surgem nas outras zonas ao longo do tempo. O histórico de versões que a zona de arquivo mantém apenas pode ser eliminado pelos gateways associados à zona de arquivo.

Com essa arquitetura, várias zonas sem controle versão podem espelhar seus dados e metadados por meio de seus gateways de zona, oferecendo alta disponibilidade aos usuários finais, enquanto a zona de arquivo captura todas as atualizações de dados para consolidá-los como versões dos objetos do S3.

Ao incluir a zona de arquivo em uma configuração de várias zonas, você ganha a flexibilidade de um histórico de objetos do S3 em uma zona, além de economizar o espaço que as réplicas dos objetos do S3 com controle de versão consomem nas zonas restantes.

21.8.5.1 Configurando o módulo de sincronização de arquivo

Dica
Dica: Mais informações

Consulte a Seção 21.13, “Gateways de Objetos multissite” para obter detalhes sobre a configuração de gateways multissite.

Consulte a Seção 21.8, “Módulos de sincronização” para obter detalhes sobre a configuração de módulos de sincronização.

Para usar o módulo de sincronização de arquivo, você precisa criar uma nova zona com o tipo de camada definido como arquivo:

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

21.9 Autenticação LDAP

Além da autenticação de usuário local padrão, o Gateway de Objetos pode usar os serviços do servidor LDAP para autenticar também os usuários.

21.9.1 Mecanismo de autenticação

O Gateway de Objetos extrai as credenciais de LDAP do usuário de um token. Um filtro de pesquisa é construído com base no nome de usuário. O Gateway de Objetos usa a conta de serviço configurada para pesquisar uma entrada correspondente no diretório. Se uma entrada for encontrada, o Gateway de Objetos tentará se vincular ao nome exclusivo encontrado com a senha do token. Se as credenciais forem válidas, o vínculo será bem-sucedido, e o Gateway de Objetos concederá o acesso.

Você pode limitar os usuários permitidos definindo a base para a pesquisa como uma unidade organizacional específica ou especificando um filtro de pesquisa personalizado. Por exemplo, exigir a participação em um grupo específico, classes de objetos ou atributos personalizados.

21.9.2 Requisitos

  • LDAP ou Active Directory: Uma instância LDAP em execução acessível pelo Gateway de Objetos.

  • Conta de serviço: Credenciais LDAP para uso do Gateway de Objetos com permissões de pesquisa.

  • Conta de usuário: Pelo menos, uma conta do usuário no diretório LDAP.

Importante
Importante: Não sobreponha usuários LDAP e locais

Você não deve usar os mesmos nomes para usuários locais e usuários autenticados por LDAP. O Gateway de Objetos não pode diferenciá-los e os trata como se fossem os mesmos usuários.

Dica
Dica: Verificações de integridade

Use o utilitário ldapsearch para verificar a conta de serviço ou a conexão LDAP. Por exemplo:

> 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

Use os mesmos parâmetros LDAP que o arquivo de configuração do Ceph para evitar possíveis problemas.

21.9.3 Configurando o Gateway de Objetos para usar a autenticação LDAP

Os parâmetros a seguir estão relacionados à autenticação LDAP:

rgw_s3_auth_use_ldap

Defina essa opção como true para habilitar a autenticação S3 com LDAP.

rgw_ldap_uri

Especifica o servidor LDAP a ser usado. Use o parâmetro ldaps://FQDN:PORT para evitar a transmissão aberta de credenciais de texto simples.

rgw_ldap_binddn

O DN (Distinguished Name – Nome Exclusivo) da conta de serviço usada pelo Gateway de Objetos.

rgw_ldap_secret

A senha para a conta de serviço.

rgw_ldap_searchdn

Especifica a base na árvore de informações do diretório para pesquisar usuários. Ela pode ser a unidade organizacional de usuários ou alguma OU (Organizational Unit – Unidade Organizacional) mais específica.

rgw_ldap_dnattr

O atributo que está sendo usado no filtro de pesquisa construído para corresponder um nome de usuário. Dependendo da DIT (Directory Information Tree – Árvore de Informações do Diretório), ele provavelmente será uid ou cn.

rgw_search_filter

Se não for especificado, o Gateway de Objetos construirá automaticamente o filtro de pesquisa com a configuração rgw_ldap_dnattr. Use esse parâmetro para restringir a lista de usuários permitidos com muita flexibilidade. Consulte a Seção 21.9.4, “Usando um filtro de pesquisa personalizado para limitar o acesso do usuário” para obter detalhes.

21.9.4 Usando um filtro de pesquisa personalizado para limitar o acesso do usuário

Você pode usar o parâmetro rgw_search_filter de duas maneiras.

21.9.4.1 Filtro parcial para limitar ainda mais o filtro de pesquisa construído

Veja a seguir um exemplo de filtro parcial:

"objectclass=inetorgperson"

O Gateway de Objetos gerará o filtro de pesquisa como de costume com o nome de usuário extraído do token e o valor de rgw_ldap_dnattr. Em seguida, o filtro construído será combinado ao filtro parcial com base no atributo rgw_search_filter. Dependendo do nome de usuário e das configurações, o filtro de pesquisa final poderá ser:

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

Nesse caso, o usuário “hari” apenas receberá acesso se for encontrado no diretório LDAP, se tiver uma classe de objeto “inetorgperson” e se especificar uma senha válida.

21.9.4.2 Filtro completo

Um filtro completo deve conter um token USERNAME que será substituído pelo nome de usuário durante a tentativa de autenticação. O parâmetro rgw_ldap_dnattr não é mais usado neste caso. Por exemplo, para limitar os usuários válidos a um grupo específico, use o filtro a seguir:

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

O uso do atributo memberOf nas pesquisas LDAP requer suporte da sua implementação de servidor LDAP específica.

21.9.5 Gerando um token de acesso para autenticação LDAP

O utilitário radosgw-token gera o token de acesso com base no nome de usuário e na senha LDAP. Ele emite uma string codificada com base64, que é o token de acesso real. Use seu cliente S3 favorito (consulte a Seção 21.5.1, “Acessando o Gateway de Objetos”), especifique o token como a chave de acesso e use uma chave secreta vazia.

> export RGW_ACCESS_KEY_ID="USERNAME"
> export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap
Importante
Importante: Credenciais de texto sem criptografia

O token de acesso é uma estrutura JSON codificada com base64 que contém as credenciais LDAP como texto sem criptografia.

Nota
Nota: Active Directory

Para o Active Directory, use o parâmetro --ttype=ad.

21.10 Fragmentação de índice do compartimento de memória

O Gateway de Objetos armazena os dados de índice do compartimento de memória em um pool de índice, que assume .rgw.buckets.index como padrão. Se você colocar um número excessivo (centenas de milhares) de objetos em um único compartimento de memória, e a cota para o número máximo de objetos por compartimento de memória (rgw bucket default quota max objects) não for definida, o desempenho do pool de índice poderá ser prejudicado. A fragmentação de índice do compartimento de memória impede essa redução no desempenho e permite um alto número de objetos por compartimento de memória.

21.10.1 Refragmentação de índice do compartimento de memória

Se um compartimento de memória ficar muito grande e sua configuração inicial não for mais suficiente, será necessário refragmentar o pool de índice dele. Você pode usar a refragmentação de índice do compartimento de memória automática online (consulte a Seção 21.10.1.1, “Refragmentação dinâmica”) ou refragmentar o índice do compartimento de memória offline manualmente (consulte a Seção 21.10.1.2, “Refragmentação manual”).

21.10.1.1 Refragmentação dinâmica

A partir do SUSE Enterprise Storage 5, oferecemos suporte à refragmentação do compartimento de memória online. Ela detecta se o número de objetos por compartimento de memória atinge determinado limite e aumenta automaticamente o número de fragmentos usados pelo índice do compartimento de memória. Esse processo reduz o número de entradas em cada fragmento de índice do compartimento de memória.

O processo de detecção é executado:

  • Quando novos objetos são adicionados ao compartimento de memória.

  • Em um processo em segundo plano que explora periodicamente todos os compartimentos de memória. Isso é necessário para resolver a questão de compartimentos de memória existentes que não são atualizados.

Um compartimento de memória que requer refragmentação é adicionado à fila reshard_log e será programado para ser refragmentado posteriormente. Os threads de refragmentação são executados em segundo plano e executam a refragmentação programada, uma de cada vez.

Configurando a refragmentação dinâmica
rgw_dynamic_resharding

Habilita ou desabilita a refragmentação dinâmica de índice do compartimento de memória. Os valores possíveis são “true” (verdadeiro) ou “false” (falso). O padrão é “true”.

rgw_reshard_num_logs

Número de fragmentos para o registro da refragmentação. O padrão é 16.

rgw_reshard_bucket_lock_duration

Duração do bloqueio do objeto do compartimento de memória durante a refragmentação. O padrão é 120 segundos.

rgw_max_objs_per_shard

Número máximo de objetos por fragmento de índice do compartimento de memória. O padrão é 100.000 objetos.

rgw_reshard_thread_interval

Tempo máxithread de refragmentaçãomo entre os ciclos de processamento do . O padrão é 600 segundos.

Comandos para administrar o processo de refragmentação
Adicionar um compartimento de memória à fila de refragmentação:
cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS
Listar a fila de refragmentação:
cephuser@adm > radosgw-admin reshard list
Processar/Programar a refragmentação de um compartimento de memória:
cephuser@adm > radosgw-admin reshard process
Exibir o status da refragmentação do compartimento de memória:
cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME
Cancelar uma refragmentação pendente do compartimento de memória:
cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 Refragmentação manual

A refragmentação dinâmica mencionada na Seção 21.10.1.1, “Refragmentação dinâmica” é suportada apenas nas configurações simples do Gateway de Objetos. Para configurações multissite, use a refragmentação manual descrita nesta seção.

Para refragmentar o índice do compartimento de memória manualmente offline, use o seguinte comando:

cephuser@adm > radosgw-admin bucket reshard

O comando bucket reshard executa o seguinte:

  • Cria um novo conjunto de objetos de índice do compartimento de memória para o objeto especificado.

  • Distribui todas as entradas desses objetos de índice.

  • Cria uma nova instância do compartimento de memória.

  • Vincula a nova instância do compartimento de memória ao compartimento de memória para que todas as novas operações de índice passem pelos novos índices do compartimento de memória.

  • Imprime o ID do compartimento de memória antigo e novo para a saída padrão.

Dica
Dica

Ao escolher um número de fragmentos, observe o seguinte: especifique no máximo 100.000 entradas por fragmento. Os fragmentos de índice do compartimento de memória que são números primos costumam funcionar melhor na distribuição uniforme das entradas de índice do compartimento de memória entre os fragmentos. Por exemplo, 503 fragmentos de índice do compartimento de memória são melhores do que 500, pois o primeiro é número primo.

Procedimento 21.1: Refragmentando o índice do compartimento de memória
  1. Verifique se todas as operações no compartimento de memória foram interrompidas.

  2. Faça backup do índice original do compartimento de memória:

    cephuser@adm > radosgw-admin bi list \
     --bucket=BUCKET_NAME \
     > BUCKET_NAME.list.backup
  3. Refragmente o índice do compartimento de memória:

     cephuser@adm > radosgw-admin bucket reshard \
     --bucket=BUCKET_NAME \
     --num-shards=NEW_SHARDS_NUMBER
    Dica
    Dica: ID do compartimento de memória antigo

    Como parte da saída, esse comando também imprime o ID do compartimento de memória novo e antigo.

21.10.2 Fragmentação de índice para novos compartimentos de memória

Há duas opções que afetam a fragmentação de índice do compartimento de memória:

  • Use a opção rgw_override_bucket_index_max_shards para configurações simples.

  • Use a opção bucket_index_max_shards para configurações multissite.

A definição das opções como 0 desabilita a fragmentação de índice do compartimento de memória. Um valor maior do que 0 habilita a fragmentação de índice do compartimento de memória e define o número máximo de fragmentos.

A fórmula a seguir ajuda você a calcular o número recomendado de fragmentos:

number_of_objects_expected_in_a_bucket / 100000

Esteja ciente de que o número máximo de fragmentos é 7877.

21.10.2.1 Configurações multissite

As configurações multissite podem ter um pool de índice diferente para gerenciar o failover. Para configurar um número consistente de fragmentos para as zonas em um grupo de zonas, defina a opção bucket_index_max_shards na configuração do grupo de zonas:

  1. Exporte a configuração do grupo de zonas para o arquivo zonegroup.json:

    cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
  2. Edite o arquivo zonegroup.json e defina a opção bucket_index_max_shards para cada zona nomeada.

  3. Redefina o grupo de zonas:

    cephuser@adm > radosgw-admin zonegroup set < zonegroup.json
  4. Atualize o período. Consulte a Seção 21.13.2.6, “Atualize o período”.

21.11 Integração do OpenStack Keystone

O OpenStack Keystone é um serviço de identidade que faz parte do produto OpenStack. Você pode integrar o Gateway de Objetos ao Keystone para configurar um gateway que aceita o token de autenticação do Keystone. Um usuário autorizado pelo Keystone a acessar o gateway será verificado no Gateway de Objetos do Ceph e criado automaticamente, se necessário. O Gateway de Objetos consulta o Keystone periodicamente para obter uma lista de tokens revogados.

21.11.1 Configurando o OpenStack

Antes de configurar o Gateway de Objetos do Ceph, você precisa configurar o OpenStack Keystone para habilitar o serviço Swift e apontá-lo para o Gateway de Objetos do Ceph:

  1. Defina o serviço Swift. Para usar o OpenStack para validar usuários do Swift, crie primeiro o serviço Swift:

    > openstack service create \
     --name=swift \
     --description="Swift Service" \
     object-store
  2. Defina os endpoints. Após criar o serviço Swift, aponte para o Gateway de Objetos do Ceph. Substitua REGION_NAME pelo nome do grupo de zonas ou da região do gateway.

    > 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 as configurações. Após criar o serviço Swift e definir os endpoints, mostre os endpoints para verificar se todas as configurações estão corretas.

    > openstack endpoint show object-store

21.11.2 Configurando o Gateway de Objetos do Ceph

21.11.2.1 Configurar certificados SSL

O Gateway de Objetos do Ceph consulta o Keystone periodicamente para obter uma lista de tokens revogados. Essas solicitações são codificadas e assinadas. É possível também configurar o Keystone para fornecer tokens autoassinados, que também são codificados e assinados. Você precisa configurar o gateway para que possa decodificar e verificar essas mensagens assinadas. Portanto, os certificados OpenSSL que o Keystone usa para criar as solicitações precisam ser convertidos no 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 o Gateway de Objetos do Ceph interaja com o OpenStack Keystone, o OpenStack Keystone pode usar um certificado SSL autoassinado. Instale o certificado SSL do Keystone no nó que executa o Gateway de Objetos do Ceph ou, se preferir, defina o valor da opção rgw keystone verify ssl como “false”. A definição de rgw keystone verify ssl como “false” indica que o gateway não tentará verificar o certificado.

21.11.2.2 Configurar as opções do Gateway de Objetos

Você pode configurar a integração com o Keystone usando as seguintes opções:

rgw keystone api version

Versão da API do Keystone. As opções válidas são 2 ou 3. O padrão é 2.

rgw keystone url

O URL e o número da porta da API RESTful administrativa no servidor Keystone. Segue o padrão URL_SERVIDOR:NÚMERO_DA_PORTA.

rgw keystone admin token

O token ou segredo compartilhado configurado internamente no Keystone para solicitações administrativas.

rgw keystone accepted roles

As funções necessárias para atender às solicitações. O padrão é “Member, admin”.

rgw keystone accepted admin roles

A lista de funções que permite a um usuário obter privilégios administrativos.

rgw keystone token cache size

O número máximo de entradas no cache de token do Keystone.

rgw keystone revocation interval

O número de segundos antes de verificar se há tokens revogados. O padrão é 15 * 60.

rgw keystone implicit tenants

Criar novos usuários em seus próprios locatários de mesmo nome. O padrão é “false”.

rgw s3 auth use keystone

Se definido como “true”, o Gateway de Objetos do Ceph autenticará os usuários com o Keystone. O padrão é “false”.

nss db path

O caminho para o banco de dados NSS.

Também é possível configurar o locatário de serviço, o usuário e a senha do Keystone (para a versão 2.0 da API do OpenStack Identity), do mesmo modo que os serviços do OpenStack costumam ser configurados. Dessa forma, você pode evitar a definição do segredo compartilhado rgw keystone admin token no arquivo de configuração, que deve ser desabilitado em ambientes de produção. As credenciais do locatário de serviço devem ter privilégios de admin. Para obter mais detalhes, consulte a documentação oficial do OpenStack Keystone. Veja a seguir as opções de configuração relacionadas:

rgw keystone admin user

Nome do usuário administrador do Keystone.

rgw keystone admin password

Senha do usuário administrador do Keystone.

rgw keystone admin tenant

Locatário do usuário administrador do Keystone versão 2.0.

Um usuário do Gateway de Objetos do Ceph é mapeado para um locatário do Keystone. Um usuário do Keystone tem funções diferentes atribuídas, possivelmente em mais do que um locatário. Quando o Gateway de Objetos do Ceph recebe o ticket, ele examina o locatário e as funções do usuário atribuídas a esse ticket e aceita ou rejeita a solicitação de acordo com a configuração da opção rgw keystone accepted roles.

Dica
Dica: Mapeando para locatários do OpenStack

Embora os locatários do Swift sejam mapeados para o usuário do Gateway de Objetos por padrão, eles também podem ser mapeados para os locatários do OpenStack por meio da opção rgw keystone implicit tenants. Isso fará com que os containers usem o namespace do locatário em vez do namespace global do tipo do S3 que o Gateway de Objetos usa como padrão. É recomendável decidir sobre o método de mapeamento na fase de planejamento para evitar confusão. O motivo dessa recomendação é que alternar a opção posteriormente afeta apenas as solicitações mais recentes que são mapeadas em um locatário, enquanto os compartimentos de memória mais antigos criados antes ainda continuam em um namespace global.

Para obter a versão 3 da API do OpenStack Identity, você deve substituir a opção rgw keystone admin tenant por:

rgw keystone admin domain

Domínio do usuário administrador do Keystone.

rgw keystone admin project

Projeto do usuário administrador do Keystone.

21.12 Posicionamento do pool e classes de armazenamento

21.12.1 Exibindo destinos de posicionamento

Os destinos de posicionamento controlam os pools que serão associados a um determinado compartimento de memória. O destino de posicionamento de um compartimento de memória é selecionado na criação e não pode ser modificado. Você pode executar o comando a seguir para exibir a respectiva regra placement_rule:

cephuser@adm > radosgw-admin bucket stats

A configuração do grupo de zonas contém uma lista de destinos de posicionamento com um destino inicial chamado "default-placement". A configuração da zona mapeia cada nome de destino de posicionamento do grupo de zonas para o respectivo armazenamento local. Essas informações de posicionamento de zona incluem o nome "index_pool" para o índice de compartimento de memória, o nome "data_extra_pool" para os metadados sobre uploads de várias partes incompletos e um nome "data_pool" para cada classe de armazenamento.

21.12.2 Classes de armazenamento

As classes de armazenamento ajudam a personalizar o posicionamento dos dados de objetos. As regras de Ciclo de Vida de Compartimento de Memória do S3 podem automatizar a transição dos objetos entre as classes de armazenamento.

As classes de armazenamento são definidas em termos de destinos de posicionamento. Cada destino de posicionamento do grupo de zonas lista suas classes de armazenamento disponíveis com uma classe inicial chamada “STANDARD”. A configuração da zona é responsável por conceder um nome de pool "data_pool" a cada uma das classes de armazenamento do grupo de zonas.

21.12.3 Configurando grupos de zonas e zonas

Use o comando radosgw-admin nos grupos de zonas e nas zonas para configurar o respectivo posicionamento. Você pode consultar a configuração de posicionamento do grupo de zonas usando o seguinte comando:

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

Para consultar a configuração de posicionamento da zona, execute:

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

Se você não fez nenhuma configuração de multissite anterior, uma zona e um grupo de zonas “padrão” são criados para você, e as mudanças feitas neles não entrarão em vigor até você reiniciar os Gateways de Objetos do Ceph. Se você criou um domínio Kerberos para multissite, as mudanças feitas na zona/grupo de zonas entrarão em vigor depois que você confirmá-las com o comando radosgw-admin period update --commit.

21.12.3.1 Adicionando um destino de posicionamento

Para criar um novo destino de posicionamento chamado "temporary", comece adicionando-o ao grupo de zonas:

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

Em seguida, insira as informações de posicionamento da zona para esse destino:

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

21.12.3.2 Adicionando uma classe de armazenamento

Para adicionar uma nova classe de armazenamento chamada “COLD” ao destino de posicionamento padrão, comece adicionando-a ao grupo de zonas:

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

Em seguida, insira as informações de posicionamento da zona para essa classe de armazenamento:

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

21.12.4 Personalização de posicionamento

21.12.4.1 Editando o posicionamento do grupo de zonas padrão

Por padrão, os novos compartimentos de memória usarão o destino default_placement do grupo de zonas. Você pode mudar essa configuração do grupo de zonas com:

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

21.12.4.2 Editando o posicionamento do usuário padrão

Um usuário do Gateway de Objetos do Ceph pode anular o destino de posicionamento padrão do grupo de zonas definindo um campo default_placement não vazio nas informações do usuário. Da mesma forma, a default_storage_class pode anular a classe de armazenamento STANDARD aplicada aos objetos por padrão.

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

Se o destino de posicionamento do grupo de zonas incluir tags, os usuários não poderão criar compartimentos de memória com esse destino de posicionamento, a menos que as informações de usuário deles contenham pelo menos uma tag correspondente no respectivo campo "placement_tags". Isso pode ser útil para restringir o acesso a determinados tipos de armazenamento.

O comando radosgw-admin não pode modificar esses campos diretamente, portanto, você precisa editar o 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

21.12.4.3 Editando o posicionamento do compartimento de memória padrão do S3

Ao criar um compartimento de memória com o protocolo S3, é possível inserir um destino de posicionamento como parte de LocationConstraint para anular os destinos de posicionamento padrão do usuário e do grupo de zonas.

Normalmente, o LocationConstraint precisa corresponder ao api_name do grupo de zonas:

<LocationConstraint>default</LocationConstraint>

É possível adicionar um destino de posicionamento personalizado ao api_name após dois-pontos:

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

21.12.4.4 Editando o posicionamento do compartimento de memória do Swift

Ao criar um compartimento de memória com o protocolo Swift, você pode fornecer um destino de posicionamento em X-Storage-Policy do cabeçalho HTTP:

X-Storage-Policy: NEW-PLACEMENT

21.12.5 Usando classes de armazenamento

Todos os destinos de posicionamento têm uma classe de armazenamento STANDARD, que é aplicada a novos objetos por padrão. Você pode anular esse padrão com default_storage_class.

Para criar um objeto em uma classe de armazenamento não padrão, insira o nome dessa classe de armazenamento em um cabeçalho HTTP com a solicitação. O protocolo S3 usa o cabeçalho X-Amz-Storage-Class, enquanto o protocolo Swift usa o cabeçalho X-Object-Storage-Class.

É possível usar o Gerenciamento do Ciclo de Vida de Objeto do S3 para mover dados de objetos entre classes de armazenamento por meio das ações de Transição.

21.13 Gateways de Objetos multissite

O Ceph suporta várias opções de configuração multissite para o Gateway de Objetos do Ceph:

Várias zonas

Uma configuração que consiste em um grupo de zonas e várias zonas, cada uma com uma ou mais instâncias de ceph-radosgw. Cada zona é acompanhada de seu próprio Cluster de Armazenamento do Ceph. Várias zonas em um grupo de zonas fornecem recuperação de desastre para o grupo de zonas, caso uma das zonas apresente uma falha significativa. Cada zona é ativa e pode receber operações de gravação. Além da recuperação de desastre, várias zonas ativas também podem servir como base para redes de distribuição de conteúdo.

Vários grupos de zonas

O Gateway de Objetos do Ceph suporta vários grupos de zonas, cada um com uma ou mais zonas. Os objetos armazenados em zonas de um grupo de zonas no mesmo domínio que outro grupo de zonas compartilham um namespace de objeto global, garantindo IDs de objeto exclusivos em todos os grupos de zonas e as zonas.

Nota
Nota

É importante observar que os grupos de zonas sincronizam apenas metadados entre eles. Os dados e os metadados são replicados entre as zonas do grupo de zonas. Não são compartilhados dados ou metadados em um domínio.

Vários domínios

O Gateway de Objetos do Ceph suporta a noção de domínios: um namespace globalmente exclusivo. Vários domínios são suportados, o que pode abranger um ou diversos grupos de zonas.

Você pode configurar cada Gateway de Objetos para operar em uma configuração de zona ativa-ativa, permitindo gravações em zonas não master. A configuração multissite é armazenada em um container chamado domínio. O domínio armazena grupos de zonas, zonas e um período com várias épocas para monitorar as mudanças na configuração. Os daemons rgw processam a sincronização, eliminando a necessidade de um agente de sincronização separado. Essa abordagem de sincronização permite que o Gateway de Objetos do Ceph opere com uma configuração ativa-ativa, e não ativa-passiva.

21.13.1 Requisitos e considerações

Uma configuração multissite requer pelo menos dois clusters de armazenamento do Ceph e, no mínimo, duas instâncias do Gateway de Objetos do Ceph, uma para cada cluster de armazenamento do Ceph. A configuração a seguir considera que pelo menos dois clusters de armazenamento do Ceph estão em locais geograficamente separados. No entanto, a configuração pode funcionar no mesmo site. Por exemplo, rgw1 e rgw2 nomeados.

Uma configuração multissite requer um grupo de zonas master e uma zona master. Uma zona master é a fonte da verdade em relação a todas as operações de metadados em um cluster multissite. Além disso, cada grupo de zonas requer uma zona master. Os grupos de zonas podem ter uma ou mais zonas secundárias ou não master. Neste guia, o host rgw1 atua como a zona master do grupo de zonas master, e o host rgw2 atua como a zona secundária do grupo de zonas master.

21.13.2 Configurando uma zona master

Todos os gateways em uma configuração multissite recuperam sua configuração de um daemon ceph-radosgw em um host no grupo de zonas master e na zona master. Para configurar seus gateways em uma configuração multissite, selecione uma instância de ceph-radosgw para configurar o grupo de zonas master e a zona master.

21.13.2.1 Criando um domínio

Um domínio representa um namespace globalmente exclusivo que consiste em um ou mais grupos de zonas com uma ou mais zonas. As zonas contêm compartimentos de memória que, por sua vez, contêm objetos. Um domínio permite que o Gateway de Objetos do Ceph suporte vários namespaces e a respectiva configuração no mesmo hardware. Um domínio engloba a noção de períodos. Cada período representa o estado da configuração do grupo de zonas e da zona no tempo. Sempre que você modificar um grupo de zonas ou uma zona, atualize e confirme o período. Por padrão, o Gateway de Objetos do Ceph não cria um domínio para compatibilidade retroativa. Como melhor prática, recomendamos criar domínios para os novos clusters.

Crie um novo domínio chamado gold para a configuração multissite abrindo uma interface de linha de comando em um host identificado para atuar no grupo de zonas master e na zona. Em seguida, execute o seguinte:

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

Se o cluster tiver um único domínio, especifique o flag --default. Se --default for especificado, radosgw-admin usará esse domínio por padrão. Se --default não for especificado, a adição de grupos de zonas e zonas exigirá que o flag --rgw-realm ou --realm-id seja especificado para identificar o domínio ao adicionar grupos de zonas e zonas.

Após criar o domínio, radosgw-admin retornará a configuração do domínio:

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

O Ceph gera um ID exclusivo para o domínio, o que permite renomear um domínio se houver necessidade.

21.13.2.2 Criando um grupo de zonas master

Um domínio deve ter pelo menos um grupo de zonas para atuar como o grupo de zonas master do domínio. Crie um novo grupo de zonas master para a configuração multissite abrindo uma interface de linha de comando em um host identificado para atuar no grupo de zonas master e na zona. Execute o seguinte comando para criar um grupo de zonas master chamado us:

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

Se o domínio tiver apenas um grupo de zonas, especifique o flag --default. Se --default for especificado, radosgw-admin usará esse grupo de zonas por padrão ao adicionar novas zonas. Se --default não for especificado, a adição de zonas exigirá o flag --rgw-zonegroup ou ‑‑zonegroup-id para identificar o grupo de zonas ao adicionar ou modificar zonas.

Após criar o grupo de zonas master, radosgw-admin retornará a configuração do grupo de zonas. Por exemplo:

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

21.13.2.3 Criando uma zona master

Importante
Importante

As zonas precisam ser criadas em um nó do Gateway de Objetos do Ceph que estará na zona.

Crie uma nova zona master para a configuração multissite abrindo uma interface de linha de comando em um host identificado para atuar no grupo de zonas master e na zona. Execute o seguinte:

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
Nota

As opções --access-key e --secret não estão especificadas no exemplo acima. Essas configurações são adicionadas à zona quando o usuário é criado na próxima seção.

Após criar a zona master, radosgw-admin retornará a configuração da zona. Por exemplo:

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

21.13.2.4 Apagando a zona e o grupo padrão

Importante
Importante

As etapas a seguir consideram uma configuração multissite que usa sistemas recém-instalados que ainda não estão armazenando dados. Não apague a zona padrão e seus pools se você já a estiver usando para armazenar dados; do contrário, os dados serão apagados de modo irrecuperável.

A instalação padrão do Gateway de Objetos cria o grupo de zonas padrão chamado default. Apague a zona padrão, se ela existir. Remova-a primeiro do grupo de zonas padrão.

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

Apague os pools padrão do cluster de armazenamento do Ceph, se existirem:

Importante
Importante

A etapa a seguir considera uma configuração multissite que usa sistemas recém-instalados que não estão armazenando dados no momento. Não apague o grupo de zonas padrão se você já o estiver usando para armazenar dados.

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
Atenção
Atenção

Se você apagar o grupo de zonas padrão, também apagará o usuário do sistema. Se as chaves de usuário admin não forem propagadas, haverá falha na funcionalidade de gerenciamento do Gateway de Objetos do Ceph Dashboard. Avance para a próxima seção para recriar o usuário do sistema, se você prosseguir com esta etapa.

21.13.2.5 Criando usuários do sistema

Os daemons ceph-radosgw devem ser autenticados antes de extrair informações de domínio e período. Na zona master, crie um usuário do sistema para simplificar a autenticação entre 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 a access_key e a secret_key, pois as zonas secundárias precisam delas para autenticação na zona master.

Adicione o usuário do sistema à zona master:

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

Atualize o período para que as mudanças entrem em vigor:

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

21.13.2.6 Atualize o período

Após atualizar a configuração da zona master, atualize o período:

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

Após atualizar o período, radosgw-admin retornará a configuração do período. Por exemplo:

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

A atualização do período muda a época e garante que as outras zonas recebam a configuração atualizada.

21.13.2.7 Iniciar o gateway

No host do Gateway de Objetos, inicie e habilite o serviço Gateway de Objetos do Ceph. Para identificar o FSID exclusivo do cluster, execute ceph fsid. Para identificar o nome do daemon do Gateway de Objetos, execute ceph orch ps --hostname HOSTNAME.

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

21.13.3 Configurar zonas secundárias

As zonas dentro de um grupo de zonas replicam todos os dados para garantir que cada zona tenha os mesmos dados. Ao criar a zona secundária, execute todas as operações a seguir em um host identificado para processar a zona secundária.

Nota
Nota

Para adicionar uma terceira zona, siga os mesmos procedimentos da adição da zona secundária. Use um nome de zona diferente.

Importante
Importante

Você deve executar operações de metadados, como criação de usuário, em um host na zona master. A zona master e a zona secundária podem receber operações de compartimento de memória, mas a zona secundária redireciona essas operações para a zona master. Se a zona master estiver inativa, haverá falha nas operações de compartimento de memória.

21.13.3.1 Extraindo do domínio

Usando o caminho de URL, a chave de acesso e o segredo da zona master no grupo de zonas master, extraia a configuração do domínio para o host. Para extrair de um domínio não padrão, especifique o domínio usando as opções de configuração --rgw-realm ou --realm-id.

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

A extração do domínio também recupera a configuração do período atual remoto e também o torna o período atual neste host.

Se esse for o único domínio ou o padrão, defina o domínio como padrão.

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

21.13.3.2 Criando uma zona secundária

Crie uma zona secundária para a configuração multissite abrindo uma interface de linha de comando em um host identificado para atender à zona secundária. Especifique o ID do grupo de zonas, o novo nome da zona e um endpoint para a zona. Não use o flag --master. Por padrão, todas as zonas são executadas em uma configuração ativa-ativa. Se a zona secundária não aceitar operações de gravação, especifique o flag --read-only para criar uma configuração ativa-passiva entre a zona master e a zona secundária. Além disso, insira a access_key e a secret_key do usuário do sistema gerado armazenado na zona master do grupo de zonas master. Execute o seguinte:

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

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
Importante

As etapas a seguir consideram uma configuração multissite que usa sistemas recém-instalados que ainda não estão armazenando dados. Não apague a zona padrão e seus pools se você já a estiver usando para armazenar dados; do contrário, os dados serão perdidos de modo irrecuperável.

Apague a zona padrão, se necessário:

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

Apague os pools padrão do cluster de armazenamento do Ceph, se necessário:

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

21.13.3.3 Atualizando o arquivo de configuração do Ceph

Atualize o arquivo de configuração do Ceph nos hosts da zona secundária adicionando a opção de configuração rgw_zone e o nome da zona secundária à entrada da instância.

Para isso, execute o seguinte comando:

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

21.13.3.4 Atualizando o período

Após atualizar a configuração da zona master, atualize o 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
Nota

A atualização do período muda a época e garante que as outras zonas recebam a configuração atualizada.

21.13.3.5 Iniciando o Gateway de Objetos

No host do Gateway de Objetos, inicie e habilite o serviço Gateway de Objetos do Ceph:

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

21.13.3.6 Verificando o status da sincronização

Quando a zona secundária estiver ativa e em execução, verifique o status da sincronização. A sincronização copia os usuários e compartimentos de memória criados na zona master para a zona secundária.

cephuser@adm > radosgw-admin sync status

A saída mostra o status das operações de sincronização. Por exemplo:

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
Nota

As zonas secundárias aceitam operações de compartimento de memória, mas elas redirecionam essas operações para a zona master e, em seguida, são sincronizadas com a zona master para receber o resultado das operações. Se a zona master estiver inativa, haverá falha nas operações de compartimento de memória executadas na zona secundária, mas as operações de objeto deverão ser bem-sucedidas.

21.13.3.7 Verificação de um objeto

Por padrão, os objetos não são verificados novamente depois que a sincronização de um objeto é bem-sucedida. Para habilitar a verificação, defina a opção rgw_sync_obj_etag_verify como true. Após a habilitação, os objetos opcionais serão sincronizados. Um checksum MD5 adicional verificará se eles foram calculados na origem e no destino. Isso é feito para garantir a integridade dos objetos buscados de um servidor remoto por HTTP, incluindo a sincronização multissite. Essa opção pode diminuir o desempenho dos RGWs, já que mais computação é necessária.

21.13.4 Manutenção geral do Gateway de Objetos

21.13.4.1 Verificando o status da sincronização

As informações sobre o status da replicação de uma zona podem ser consultadas com:

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

A saída pode ser diferente dependendo do status da sincronização. Os fragmentos são descritos como dois tipos diferentes durante a sincronização:

Fragmentos esquecidos

Trata-se de fragmentos que precisam de uma sincronização completa de dados e de fragmentos que precisam de uma sincronização incremental de dados porque não estão atualizados.

Fragmentos de recuperação

Trata-se de fragmentos que encontraram um erro durante a sincronização e foram marcados para nova tentativa. Na maioria das vezes, o erro ocorre em caso de problemas secundários, como aquisição de um bloqueio em um compartimento de memória. Normalmente, esse erro se resolve sozinho.

21.13.4.2 Verificar os registros

Apenas para multissite, você pode verificar o registro de metadados (mdlog), o registro de índice do compartimento de memória (bilog) e o registro de dados (datalog). Você pode listá-los e também cortá-los. Na maioria dos casos, isso não é necessário porque a opção rgw_sync_log_trim_interval está definida como 20 minutos por padrão. Se isso não for definido manualmente como 0, você não precisará cortar a qualquer momento, pois poderá causar efeitos colaterais.

21.13.4.3 Mudando a zona master de metadados

Importante
Importante

Tenha cuidado ao mudar a zona que é master de metadados. Se uma zona não concluiu a sincronização de metadados da zona master atual, ela não pode processar as entradas restantes ao ser promovida a master, e essas mudanças são perdidas. Por esse motivo, recomendamos aguardar até o status da sincronização de radosgw-admin de uma zona concluir a sincronização de metadados antes de promovê-la a master. Da mesma forma, se as mudanças nos metadados estiverem sendo processadas pela zona master atual enquanto outra zona for promovida a master, essas mudanças provavelmente serão perdidas. Para evitar isso, recomendamos encerrar quaisquer instâncias do Gateway de Objetos na zona master anterior. Após promover outra zona, será possível buscar seu novo período com a extração de período de radosgw-admin e reiniciar o(s) gateway(s).

Para promover uma zona (por exemplo, a zona us-west no grupo de zonas us) a master de metadados, execute os seguintes comandos nessa 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

Isso gera um novo período, e a(s) instância(s) do Gateway de Objetos na zona us-west envia(m) esse período para as outras zonas.

21.13.5 Executando failover e recuperação de desastre

Se a zona master falhar, faça o failover para a zona secundária para recuperação de desastre.

  1. Converta a zona secundária na zona master e padrão. Por exemplo:

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

    Por padrão, o Gateway de Objetos do Ceph é executado em uma configuração ativa-ativa. Se o cluster foi configurado para ser executado em uma configuração ativa-passiva, a zona secundária é uma zona apenas leitura. Remova o status --read-only para permitir que a zona receba as operações de gravação. Por exemplo:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                       --read-only=false
  2. Atualize o período para que as mudanças entrem em vigor:

    cephuser@adm > radosgw-admin period update --commit
  3. Reinicie o Gateway de Objetos do Ceph:

    cephuser@adm > ceph orch restart rgw

Se a zona master anterior for recuperada, reverta a operação.

  1. Da zona recuperada, extraia a configuração mais recente do domínio da zona master atual.

    cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                               --access-key=ACCESS-KEY --secret=SECRET
  2. Converta a zona recuperada na zona master e padrão:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
  3. Atualize o período para que as mudanças entrem em vigor:

    cephuser@adm > radosgw-admin period update --commit
  4. Reinicie o Gateway de Objetos do Ceph na zona recuperada:

    cephuser@adm > ceph orch restart rgw@rgw
  5. Se a zona secundária precisar de uma configuração apenas leitura, atualize-a:

    cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
  6. Atualize o período para que as mudanças entrem em vigor:

    cephuser@adm > radosgw-admin period update --commit
  7. Reinicie o Gateway de Objetos do Ceph na zona secundária:

    cephuser@adm > ceph orch restart@rgw