Ceph Object Gateway | Guia de Administração

documentation.suse.com › Documentação do SUSE Enterprise Storage 5 › Guia de Administração › Acessando os dados do cluster › Ceph Object Gateway

ConteúdoConteúdo

Guia de Administração

Navegação←→

Aplica-se a SUSE Enterprise Storage 5

11 Ceph Object Gateway #

11.1 Restrições e limitações de nomeação do Object Gateway
11.2 Implantando o Object Gateway
11.3 Operando o serviço Object Gateway
11.4 Parâmetros de configuração
11.5 Gerenciando o acesso ao Object Gateway
11.6 Habilitando HTTPS/SSL para Object Gateways
11.7 Módulos de sincronização
11.8 Autenticação LDAP
11.9 Fragmentação de índice do compartimento de memória
11.10 Integrando o OpenStack Keystone
11.11 Object Gateways multissite
11.12 Equilibrando a carga dos servidores Object Gateway com HAProxy

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

11.1 Restrições e limitações de nomeação do Object Gateway #

Veja a seguir uma lista dos limites importantes do Object Gateway:

11.1.1 Limitações de compartimento de memória #

Ao usar o Object Gateway 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 Object Gateway 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: 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.

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

11.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 CivetWeb padrão restringe o número de cabeçalhos HTTP a 64 e o tamanho a 16 KB cada.

11.2 Implantando o Object Gateway #

O método recomendado de implantar o Ceph Object Gateway é pela infraestrutura do DeepSea, adicionando a(s) linha(s) role-rgw [...] relevante(s) ao arquivo policy.cfg no master Salt e executando as fases necessárias do DeepSea.

Para incluir o Object Gateway durante o processo de implantação do cluster do Ceph, consulte o Seção 4.3, “Implantação do cluster” e o Seção 4.5.1, “Arquivo policy.cfg”.
Para adicionar a função Object Gateway a um cluster já implantado, consulte a Seção 1.2, “Adicionando novas funções aos nós”.

11.3 Operando o serviço Object Gateway #

O serviço Object Gateway é operado pelo comando systemctl. Você precisa ter privilégios de root para operar o serviço Object Gateway. Observe que gateway_host é o nome de host do servidor cuja instância do Object Gateway você precisa operar.

Os subcomandos a seguir são suportados para o serviço Object Gateway:

systemctl status ceph-radosgw@rgw.gateway_host: Imprime as informações de status do serviço
systemctl start ceph-radosgw@rgw.gateway_host: Inicia o serviço caso ainda não esteja em execução.
systemctl restart ceph-radosgw@rgw.gateway_host: Reinicia o serviço.
systemctl stop ceph-radosgw@rgw.gateway_host: Para o serviço em execução.
systemctl enable ceph-radosgw@rgw.gateway_host: Habilita o serviço para que ele seja iniciado automaticamente na inicialização do sistema.
systemctl disable ceph-radosgw@rgw.gateway_host: Desabilita o serviço para que ele não seja iniciado automaticamente na inicialização do sistema.

11.4 Parâmetros de configuração #

O comportamento do Object Gateway pode ser afetado por inúmeras opções no arquivo ceph.conf. Veja a seguir uma lista das mais importantes. Para ver a lista completa, consulte http://docs.ceph.com/docs/master/radosgw/config-ref/.

rgw_thread_pool_size: Número de threads para o servidor CivetWeb. Aumente para um valor mais alto se você precisa atender a mais solicitações. O padrão é 100 threads.
rgw_num_rados_handles: O número de manipuladores de cluster RADOS (consulte http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle) para o Object Gateway. Disponibilizar um número configurável de manipuladores RADOS tem resultado em um aumento significativo no desempenho para todos os tipos de cargas de trabalho. Agora, cada thread do worker do Object Gateway precisa selecionar um manipulador RADOS para sua vida útil. O padrão é 1.
rgw_max_chunk_size: Tamanho máximo de um pacote de dados que será lido em uma única operação. Aumentar o valor para 4 MB (4194304) proporcionará um melhor desempenho ao processar objetos grandes. O padrão é 128 KB (131072).

11.4.1 Notas adicionais #

rgw dns name: Se o parâmetro rgw dns name for adicionado a ceph.conf, verifique se o cliente S3 foi configurado para direcionar as solicitações no endpoint especificado por rgw dns name.

11.5 Gerenciando o acesso ao Object Gateway #

Você pode se comunicar com o Object Gateway 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.

11.5.1 Acessando o Object Gateway #

11.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 Object Gateway, 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 11.5.2.1, “Adicionando usuários do S3 e do Swift”.

Instale o pacote python-boto:
```
sudo zypper in python-boto
```

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}\t{created}".format(
  name = bucket.name,
  created = bucket.creation_date,
  )

Substitua {hostname} pelo nome de host no qual você configurou o serviço Object Gateway. Por exemplo, gateway_host.

Execute o script:
```
python s3test.py
```
A saída do script é parecida com o seguinte:
```
my-new-bucket 2015-07-22T15:37:42.000Z
```

11.5.1.2 Acesso à interface do Swift #

Para acessar o Object Gateway 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” (Nuvem Pública) do SUSE Linux Enterprise 12 SP3. Antes de instalar o pacote, você precisa ativar o módulo e atualizar o repositório de software:

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

Para instalar o comando swift, execute o seguinte:

sudo 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 swift_secret_key pelo respectivo valor da saída do comando radosgw-admin key create executado para o usuário swift na Seção 11.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

11.5.2 Gerenciando contas do S3 e do Swift #

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

Os usuários também podem ser adicionados por meio do arquivo rgw.sls do DeepSea. Para obter um exemplo, consulte a Seção 14.3.1, “Usuários diferentes do Object Gateway para NFS Ganesha”.

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

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

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

Por exemplo:

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

Para criar um subusuário (interface do Swift) para o usuário, você deve especificar o ID de usuário (--uid=nomedeusuário), um ID de subusuário e o nível de acesso para o subusuário.

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

Por exemplo:

sudo radosgw-admin subuser create --uid=example_user \
 --subuser=example_user:swift --access=full

Gere uma chave secreta para o usuário.

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

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 Object Gateway por meio da interface do S3, você precisa criar um usuário do S3 executando:

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

Por exemplo:

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

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

sudo radosgw-admin user rm --uid=example_user

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

sudo 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: Removendo um subusuário

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

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

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

Para usuários do Swift, execute o seguinte:

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

11.5.2.4 Gerenciamento de cotas de usuário #

O Ceph Object Gateway 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:

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

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

Para desabilitar uma cota:

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

Para listar as configurações de cota:

sudo radosgw-admin user info --uid=example_user

Para atualizar as estatísticas de cota:

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

11.6 Habilitando HTTPS/SSL para Object Gateways #

Para habilitar a função Object Gateway padrão para comunicação segura por meio de SSL, você precisa ter um certificado emitido por uma CA ou criar um autoassinado. Há duas maneiras de configurar o Object Gateway com HTTPS habilitado: uma maneira simples que usa as configurações padrão e uma maneira avançada que permite ajustar as configurações relacionadas a HTTPS.

11.6.1 Criar um certificado autoassinado #

Dica

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

Por padrão, o DeepSea espera o arquivo de certificado em /srv/salt/ceph/rgw/cert/rgw.pem no master Salt. Em seguida, ele distribuirá o certificado para /etc/ceph/rgw.pem no minion Salt com a função Object Gateway, onde o Ceph faz a leitura.

O procedimento a seguir descreve como gerar um certificado SSL autoassinado no nó master Salt.

Adicione a opção subjectAltName à seção [v3_req] do arquivo /etc/ssl/openssl.cnf para todos os nomes de host desejados para o seu Object Gateway:
```
[...]
[ v3_req ]
subjectAltName = ${ENV::SAN}
[...]
```
Crie a chave e o certificado usando openssl. Adicione o prefixo env SAN=DNS:fqdn ao 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 # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \
 -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem
```

11.6.2 Configuração de HTTPS simples #

Por padrão, o Ceph no nó do Object Gateway lê o cerificado /etc/ceph/rgw.pem e usa a porta 443 para comunicação SSL segura. Se você não precisa mudar esses valores, siga estas etapas:

Edite /srv/pillar/ceph/stack/global.yml e adicione a seguinte linha:
```
rgw_configurations: rgw-ssl
rgw_init: default-ssl
```

Execute as Fases 2, 3 e 4 do DeepSea para aplicar as mudanças:

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

11.6.3 Configuração de HTTPS avançada #

Se você precisar mudar os valores padrão para as configurações de SSL do Object Gateway, siga estas etapas:

Copie a configuração de SSL do Object Gateway padrão para o subdiretório ceph.conf.d:

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \
 /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

Edite /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf e mude as opções padrão, como número da porte ou caminho para o certificado SSL, para refletir sua configuração.

Execute as Fases 3 e 4 do DeepSea para aplicar as mudanças:

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

Dica: Vinculando a várias portas

O servidor CivetWeb pode ser vinculado a várias portas. Isso será útil se você precisar acessar uma única instância do Object Gateway com ambas as conexões SSL e não SSL. Ao especificar as portas, separe os números usando um sinal de adição “+”. Veja a seguir um exemplo de linha de configuração de duas portas:

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

11.7 Módulos de sincronização #

A funcionalidade multissite do Object Gateway incluída no Jewel permite criar várias zonas e espelhar os dados e metadados entre elas. 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 (operações de metadados, como criação de compartimento de memória ou usuário, etc., também são consideradas mudanças nos dados). Como as mudanças multissite do rgw acabam sendo consistentes em sites remotos, elas são propagadas de forma assíncrona. Desse modo, é possível desbloquear casos de uso, como backup de armazenamento de objetos em um cluster de nuvem externo ou em uma solução de backup personalizada que usa unidades de fita, indexação de metadados no Elasticsearch, etc.

11.7.1 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 padrão para sincronizar dados entre zonas, e log, que é o comum para registrar a operação de metadados que ocorre 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: 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.

11.7.1.1 Requisitos e considerações #

Vamos considerar uma configuração multissite simples, conforme descrito na Seção 11.11, “Object Gateways 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 Object Gateways nela não atenderão diretamente nenhuma solicitação de usuário final.

11.7.1.2 Configurando módulos de sincronização #

Crie a terceira zona semelhante àquelas descritas na Seção 11.11, “Object Gateways multissite”. Por exemplo,

root # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
--access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80

É possível configurar um módulo de sincronização para essa zona por meio do seguinte procedimento

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \
--tier-config={set of key=value pairs}

Por exemplo, no módulo de sincronização elasticsearch
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \
--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
```
Para as várias opções de configuração de camada suportadas, consulte a Seção 11.7.2, “Armazenando metadados no Elasticsearch”.

Por fim, atualize o período

root # radosgw-admin period update --commit

Agora, inicie o radosgw na zona

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

11.7.2 Armazenando metadados no Elasticsearch #

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

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

11.7.2.1 Parâmetros de 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 que será configurado no Elasticsearch 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 que será configurado no Elasticsearch 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á usado como caminho do índice do elasticsearch. Do contrário, o caminho do índice será determinado e gerado na inicialização da sincronização.

11.7.2.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 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 “;”. Atualmente, os tipos permitidos são string (padrão), número inteiro e data. Por exemplo, para indexar os metadados de objetos personalizados x-amz-meta-year como número inteiro, x-amz-meta-date como tipo de data e x-amz-meta-title como string, você executa 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

11.8 Autenticação LDAP #

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

11.8.1 Mecanismo de autenticação #

O Object Gateway 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 Object Gateway usa a conta de serviço configurada para pesquisar uma entrada correspondente no diretório. Se uma entrada for encontrada, o Object Gateway 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 Object Gateway 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.

11.8.2 Requisitos #

LDAP ou Active Directory: Uma instância LDAP em execução acessível pelo Object Gateway.
Conta de serviço: Credenciais LDAP para uso do Object Gateway com permissões de pesquisa.
Conta de usuário: Pelo menos, uma conta do usuário no diretório LDAP.

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 Object Gateway não pode diferenciá-los e os trata como se fossem os mesmos usuários.

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.

11.8.3 Configurar o Object Gateway para usar a autenticação LDAP #

Os seguintes parâmetros no arquivo de configuração /etc/ceph/ceph.conf estão relacionados à autenticação LDAP:

rgw_ldap_uri: Especifica o servidor LDAP a ser usado. Use o parâmetro ldaps://fqdn:porta 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 Object Gateway.
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 Object Gateway 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 11.8.4, “Usando um filtro de pesquisa personalizado para limitar o acesso do usuário” para obter detalhes.

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

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

11.8.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: Atributo `memberOf`

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

11.8.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 11.5.1, “Acessando o Object Gateway”), especifique o token como a chave de acesso e use uma chave secreta vazia.

root@minion > export RGW_ACCESS_KEY_ID="username"
root@minion > export RGW_SECRET_ACCESS_KEY="password"
root@minion > radosgw-token --encode --ttype=ldap

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: Active Directory

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

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

O Object Gateway 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.

11.9.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 11.9.1.1, “Refragmentação dinâmica”) ou refragmentar o índice do compartimento de memória offline manualmente (consulte a Seção 11.9.1.2, “Refragmentação manual”).

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

Importante: Configurações multissite

A refragmentação dinâmica não é suportada em ambiente multissite. Por padrão, ela está desabilitada desde o Ceph 12.2.2, mas recomendamos conferir essa configuração.

Comandos para administrar o processo de refragmentação #

Adicionar um compartimento de memória à fila de refragmentação:

root@minion > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS

Listar a fila de refragmentação:

root@minion > radosgw-admin reshard list

Processar/Programar a refragmentação de um compartimento de memória:

root@minion > radosgw-admin reshard process

Exibir o status da refragmentação do compartimento de memória:

root@minion > radosgw-admin reshard status --bucket BUCKET_NAME

Cancelar uma refragmentação pendente do compartimento de memória:

root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 Refragmentação manual #

A refragmentação dinâmica mencionada na Seção 11.9.1.1, “Refragmentação dinâmica” é suportada apenas nas configurações simples do Object Gateway. 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:

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

Procedimento 11.1: Refragmentando o pool de índice do compartimento de memória #

Verifique se todas as operações no compartimento de memória foram interrompidas.

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

root@minion > radosgw-admin bi list \
 --bucket=BUCKET_NAME \
 > BUCKET_NAME.list.backup

Refragmente o índice do compartimento de memória:
```
 root@minion > radosgw-admin reshard \
 --bucket=BUCKET_NAME \
 --num-shards=NEW_SHARDS_NUMBER
```
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. Anote o ID do compartimento de memória antigo. Ele será necessário para purgar os objetos de índice do compartimento de memória antigo.
Verifique se os objetos estão listados corretamente comparando a listagem de índice do compartimento de memória antigo com o novo. Em seguida, purgue os objetos de índice do compartimento de memória antigo:
```
root@minion > radosgw-admin bi purge
 --bucket=BUCKET_NAME
 --bucket-id=OLD_BUCKET_ID
```

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

11.9.2.1 Configurações simples #

Abra o arquivo de configuração do Ceph e adicione ou modifique a seguinte opção:
```
rgw_override_bucket_index_max_shards = 12
```
Dica: Uma ou todas as instâncias do Object Gateway
Para configurar a fragmentação de índice do compartimento de memória para todas as instâncias do Object Gateway, inclua rgw_override_bucket_index_max_shards na seção [global].
Para configurar a fragmentação de índice do compartimento de memória apenas para uma instância específica do Object Gateway, inclua rgw_override_bucket_index_max_shards na seção relacionada da instância.
Reinicie o Object Gateway. Consulte a Seção 11.3, “Operando o serviço Object Gateway” para obter mais detalhes.

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

Exporte a configuração do grupo de zonas para o arquivo zonegroup.json:
```
root@minion > radosgw-admin zonegroup get > zonegroup.json
```
Edite o arquivo zonegroup.json e defina a opção bucket_index_max_shards para cada zona nomeada.

Redefina o grupo de zonas:

root@minion > radosgw-admin zonegroup set < zonegroup.json

Atualize o período:

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

11.10 Integrando o OpenStack Keystone #

O OpenStack Keystone é um serviço de identidade que faz parte do produto OpenStack. Você pode integrar o Object Gateway 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 Ceph Object Gateway e criado automaticamente, se necessário. O Object Gateway consulta o Keystone periodicamente para obter uma lista de tokens revogados.

11.10.1 Configurando o OpenStack #

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

Defina o serviço Swift. Para usar o OpenStack para validar usuários do Swift, crie primeiro o serviço Swift:
```
root # openstack service create \
 --name=swift \
 --description="Swift Service" \
 object-store
```

Defina os endpoints. Após criar o serviço Swift, aponte para o Ceph Object Gateway. Substitua REGION_NAME pelo nome do grupo de zonas ou da região do gateway.

root # openstack endpoint create --region REGION_NAME \
 --publicurl   "http://radosgw.example.com:8080/swift/v1" \
 --adminurl    "http://radosgw.example.com:8080/swift/v1" \
 --internalurl "http://radosgw.example.com:8080/swift/v1" \
 swift

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.
```
root # openstack endpoint show object-store
```

11.10.2 Configurando o Ceph Object Gateway #

11.10.2.1 Configurar certificados SSL #

O Ceph Object Gateway 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”:

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

É possível também terminar o OpenStack Keystone com um certificado SSL autoassinado para o Ceph Object Gateway interagir com o Keystone. Instale o certificado SSL do Keystone no nó que executa o Ceph Object Gateway 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.

11.10.2.2 Configurar as opções do Object Gateway #

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 Ceph Object Gateway 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 do Keystone, usuário e senha do Keystone (para a versão 2.0 da API do OpenStack Identity), similar ao modo como 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 Ceph Object Gateway é mapeado para um locatário do Keystone. Um usuário do Keystone tem funções diferentes atribuídas, possivelmente em mais do que um único locatário. Quando o Ceph Object Gateway 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: Mapeando locatários do OpenStack

Embora os locatários do Swift sejam mapeados para o usuário do Object Gateway 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 Object Gateway usa como padrão. É recomendável decidir sobre o método de mapeamento na fase de planejamento para evitar confusão. O motivo é 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.

11.11 Object Gateways multissite #

Zona

Um agrupamento lógico de uma ou mais instâncias do Object Gateway. Deve haver uma zona designada como master em um grupo de zonas, que processa toda a criação de compartimento de memória e usuário.

Grupo de zonas

Um grupo de zonas consiste em várias zonas. Deve haver um grupo de zonas master que processará as mudanças na configuração do sistema.

Mapa de grupo de zonas

Uma estrutura de configuração que contém o mapa de todo o sistema. Por exemplo, que grupo de zonas é master, os relacionamentos entre diferentes grupos de zonas e determinadas opções de configuração, como políticas de armazenamento.

Domínio

Um container para grupos de zonas. Ele permite a separação de grupos de zonas entre clusters. É possível criar vários domínios, facilitando a execução de configurações completamente diferentes no mesmo cluster.

Período

Um período contém a estrutura de configuração para o estado atual do domínio. Cada período contém um ID e uma época exclusivos. Cada domínio tem um período atual associado, que contém o estado atual da configuração dos grupos de zonas e das políticas de armazenamento. Qualquer mudança na configuração para uma zona não master incrementará a época do período. Modificar a zona master para uma zona diferente acionará as seguintes mudanças:

Um novo período será gerado com um novo ID e época do período de 1.
O período atual do domínio será atualizado para apontar para o ID do período recém-gerado.
A época do domínio será incrementada.

Você pode configurar cada Object Gateway para participar de uma arquitetura unificada, trabalhando em uma configuração de zona ativa e permitindo gravações em zonas não master.

11.11.1 Terminologia #

Veja a seguir uma descrição dos termos específicos de uma arquitetura unificada:

11.11.2 Configuração de cluster de exemplo #

Neste exemplo, o foco será na criação de um único grupo de zonas com três zonas separadas, que sincronizam seus dados ativamente. Duas zonas pertencem ao mesmo cluster, enquanto a terceira pertence a outro. Não há um agente de sincronização envolvido no espelhamento das mudanças de dados entre os Object Gateways. Isso possibilita um esquema de configuração muito mais simples e configurações ativas-ativas. Observe que as operações de metadados, como a criação de um novo usuário, ainda precisam passar pela zona master. No entanto, as operações de dados, como criação de objetos e compartimentos de memória, podem ser gerenciadas por qualquer uma das zonas.

11.11.3 Chaves do sistema #

Ao configurar as zonas, o Object Gateway espera a criação de um usuário do sistema compatível com S3 juntamente com as chaves secretas e de acesso. Isso permite que outra instância do Object Gateway extraia a configuração remotamente com as chaves secretas e de acesso. Para obter mais informações sobre como criar usuários do S3, consulte a Seção 11.5.2.1, “Adicionando usuários do S3 e do Swift”.

Dica

Isso é útil para gerar as chaves secretas e de acesso antes da criação da própria zona, pois facilita a criação de scripts e o uso das ferramentas de gerenciamento de configuração no futuro.

Para efeitos deste exemplo, vamos supor que as chaves secretas e de acesso foram definidas nas variáveis de ambiente:

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805
# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

Normalmente, as chaves de acesso são compostas por 20 caracteres alfanuméricos, enquanto as chaves secretas são constituídas de 40 caracteres alfanuméricos (também podem conter os caracteres +/=). É possível gerar essas chaves na linha de comando:

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)
# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

11.11.4 Convenções de nomeação #

Este exemplo descreve o processo de configuração de uma zona master. Vamos considerar um grupo de zonas denominado us abrangendo os Estados Unidos, que será nosso grupo de zonas master. Ele incluirá duas zonas gravadas no formato grupodezonas-zona. Trata-se apenas da nossa convenção, e você pode escolher o formato de sua preferência. Em resumo:

Grupo de zonas master: Estados Unidos us
Zona master: Estados Unidos, Região Leste 1: us-east-1
Zona secundária: Estados Unidos, Região Leste 2: us-east-2
Zona secundária: Estados Unidos, Região Oeste: us-west

Isso fará parte de um domínio maior denominado gold. As zonas us-east-1 e us-east-2 fazem parte do mesmo cluster do Ceph, sendo us-east-1 a primária. us-west está em um cluster diferente do Ceph.

11.11.5 Pools padrão #

Quando configurado com as permissões apropriadas, o próprio Object Gateway cria pools padrão. Os valores pg_num e pgp_num são obtidos do arquivo de configuração ceph.conf. Por padrão, os pools relacionados a uma zona seguem a convenção nome-zona.nome-pool. Por exemplo, para a zona us-east-1, serão os seguintes pools:

.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

Esses pools também podem ser criados em outras zonas substituindo us-east-1 pelo nome da zona apropriado.

11.11.6 Criando um domínio #

Configure um domínio chamado gold e torne-o o domínio padrão:

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

Observe que cada domínio tem um ID, que permite flexibilidade, como renomear um domínio no futuro, se necessário. current_period muda sempre que alguma coisa é modificada na zona master. epoch é incrementado quando há alguma mudança na configuração da zona master que resulta na mudança do período atual.

11.11.7 Apagando o grupo de zonas padrão #

A instalação padrão do Object Gateway cria o grupo de zonas padrão chamado default. Como não precisamos mais do grupo de zonas padrão, remova-o.

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

11.11.8 Criando um grupo de zonas master #

Crie um grupo de zonas master chamado us. O grupo de zonas gerenciará o mapa de grupo de zonas e propagará as mudanças para o restante do sistema. Ao marcar o grupo de zonas como padrão, você permite mencionar explicitamente o switch rgw-zonegroup para comandos futuros.

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

Se preferir, você poderá marcar um grupo de zonas como padrão com o seguinte comando:

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

11.11.9 Criando uma zona master #

Agora, crie uma zona padrão e adicione-a ao grupo de zonas padrão. Observe que você usará essa zona para operações de metadados, como criação de usuário:

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

Observe que os switches --rgw-zonegroup e --default adicionam a zona a um grupo de zonas e a tornam padrão. Se preferir, o mesmo também pode ser feito com os seguintes comandos:

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

11.11.9.1 Criando usuários do sistema #

Para acessar os pools da zona, você precisa criar um usuário do sistema. Observe que você também precisará dessas chaves durante a configuração da zona secundária.

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

11.11.9.2 Atualizar o período #

Como você mudou a configuração da zona master, precisa confirmar as modificações para que elas entrem em vigor na estrutura de configuração do domínio. Inicialmente, o período tem esta aparência:

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

Atualize o período e confirme as mudanças:

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

11.11.9.3 Iniciar o Object Gateway #

É necessário mencionar as opções de zona e porta do Object Gateway no arquivo de configuração antes de iniciá-lo. Para obter mais informações sobre o Object Gateway e sua configuração, consulte o Capítulo 11, Ceph Object Gateway. A seção de configuração do Object Gateway deve ser semelhante a esta:

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

Inicie o Object Gateway:

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

11.11.10 Criando uma zona secundária #

No mesmo cluster, crie e configure a zona secundária chamada us-east-2. Você pode executar todos os comandos a seguir no nó que hospeda a própria zona master.

Para criar a zona secundária, execute o mesmo comando de quando você criou a zona primária, mas descartando o flag de master:

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

11.11.10.1 Atualizar o período #

Informe todos os gateways sobre a nova mudança no mapa do sistema fazendo uma atualização do período e confirmando as modificações:

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

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

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

11.11.10.2 Iniciar o Object Gateway #

Ajuste a configuração do Object Gateway para a zona secundária e inicie-o:

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

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

11.11.11 Adicionando o Object Gateway ao segundo cluster #

O segundo cluster do Ceph pertence ao mesmo grupo de zonas que o inicial, mas pode estar geograficamente em qualquer outro lugar.

11.11.11.1 Domínio padrão e grupo de zonas #

Como você já criou o domínio para o primeiro gateway, insira-o aqui e torne-o padrão:

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

Obtenha a configuração da zona master extraindo o período:

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

Defina o grupo de zonas padrão como o grupo us já criado:

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

11.11.11.2 Configuração da zona secundária #

Crie uma nova zona chamada us-west com as mesmas chaves do sistema:

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

11.11.11.3 Atualizar o período #

Para propagar as mudanças do mapa de grupo de zonas, atualizamos e confirmamos o período:

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

Observe que o número da época do período foi incrementado, o que indica uma mudança na configuração.

11.11.11.4 Iniciar o Object Gateway #

O procedimento é quase igual a iniciar o Object Gateway na primeira zona. A única diferença é que a configuração da zona do Object Gateway deve refletir o nome da zona us-west:

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

Inicie o segundo Object Gateway:

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

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

Converta a zona secundária na zona master e padrão. Por exemplo:
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
```
Por padrão, o Ceph Object Gateway será 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:
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \
--read-only=False
```
Atualize o período para que as mudanças entrem em vigor.
```
root # radosgw-admin period update --commit
```

Por fim, reinicie o Ceph Object Gateway.

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

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

Da zona recuperada, extraia o período da zona master atual.

root # radosgw-admin period pull --url={url-to-master-zone-gateway} \
--access-key={access-key} --secret={secret}

Converta a zona recuperada na zona master e padrão.

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

Atualize o período para que as mudanças entrem em vigor.
```
root # radosgw-admin period update --commit
```
Em seguida, reinicie o Ceph Object Gateway na zona recuperada.
```
root # systemctl restart ceph-radosgw@rgw.`hostname -s`
```
Se a zona secundária precisar de uma configuração apenas leitura, atualize-a.
```
root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
```
Atualize o período para que as mudanças entrem em vigor.
```
root # radosgw-admin period update --commit
```
Por fim, reinicie o Ceph Object Gateway na zona secundária.
```
root # systemctl restart ceph-radosgw@rgw.`hostname -s`
```

11.12 Equilibrando a carga dos servidores Object Gateway com HAProxy #

Você pode usar o balanceador de carga HAProxy para distribuir todas as solicitações entre os vários servidores Object Gateway de back end. Consulte https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html para obter mais detalhes sobre como configurar o HAProxy.

Veja a seguir uma configuração simples do HAProxy para equilibrar os nós do Object Gateway usando o rodízio como algoritmo de equilíbrio:

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

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

Imprimir esta página

Guia de Administração

11 Ceph Object Gateway #

11.1 Restrições e limitações de nomeação do Object Gateway #

11.1.1 Limitações de compartimento de memória #

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

11.1.2 Limitações de objetos armazenados #

11.1.3 Limitações de cabeçalho HTTP #

11.2 Implantando o Object Gateway #

11.3 Operando o serviço Object Gateway #

11.4 Parâmetros de configuração #

11.4.1 Notas adicionais #

11.5 Gerenciando o acesso ao Object Gateway #

11.5.1 Acessando o Object Gateway #

11.5.1.1 Acesso à interface do S3 #

11.5.1.2 Acesso à interface do Swift #

11.5.2 Gerenciando contas do S3 e do Swift #

11.5.2.1 Adicionando usuários do S3 e do Swift #

11.5.2.2 Removendo usuários do S3 e do Swift #

Dica: Removendo um subusuário

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

11.5.2.4 Gerenciamento de cotas de usuário #

11.6 Habilitando HTTPS/SSL para Object Gateways #

11.6.1 Criar um certificado autoassinado #

Dica

11.6.2 Configuração de HTTPS simples #

11.6.3 Configuração de HTTPS avançada #

Dica: Vinculando a várias portas

11.7 Módulos de sincronização #

11.7.1 Sincronizando zonas #

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

11.7.1.1 Requisitos e considerações #

11.7.1.2 Configurando módulos de sincronização #

11.7.2 Armazenando metadados no Elasticsearch #

11.7.2.1 Parâmetros de configuração de tipo de camada do Elasticsearch #

11.7.2.2 Consultas de metadados #

11.8 Autenticação LDAP #

11.8.1 Mecanismo de autenticação #

11.8.2 Requisitos #

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

Dica: Verificações de integridade

11.8.3 Configurar o Object Gateway para usar a autenticação LDAP #

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

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

11.8.4.2 Filtro completo #

Nota: Atributo memberOf

11.8.5 Gerando um token de acesso para autenticação LDAP #

Importante: Credenciais de texto sem criptografia

Nota: Active Directory

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

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

11.9.1.1 Refragmentação dinâmica #

Configurando a refragmentação dinâmica #

Importante: Configurações multissite

Comandos para administrar o processo de refragmentação #

11.9.1.2 Refragmentação manual #

Procedimento 11.1: Refragmentando o pool de índice do compartimento de memória #

Dica: ID do compartimento de memória antigo

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

11.9.2.1 Configurações simples #

Dica: Uma ou todas as instâncias do Object Gateway

11.9.2.2 Configurações multissite #

11.10 Integrando o OpenStack Keystone #

11.10.1 Configurando o OpenStack #

11.10.2 Configurando o Ceph Object Gateway #

11.10.2.1 Configurar certificados SSL #

11.10.2.2 Configurar as opções do Object Gateway #

Dica: Mapeando locatários do OpenStack

11.11 Object Gateways multissite #

11.11.1 Terminologia #

11.11.2 Configuração de cluster de exemplo #

11.11.3 Chaves do sistema #

Dica

11.11.4 Convenções de nomeação #

11.11.5 Pools padrão #

11.11.6 Criando um domínio #

11.11.7 Apagando o grupo de zonas padrão #

11.11.8 Criando um grupo de zonas master #

11.11.9 Criando uma zona master #

11.11.9.1 Criando usuários do sistema #

11.11.9.2 Atualizar o período #

Nota: Atributo `memberOf`