21 Gateway de Objetos do Ceph #

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

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

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

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

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:

Dica: Removendo um subusuário

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

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

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

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

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.

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.

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.

{
  "connection": {
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,
  },
  "acls": [ { "type": id | email | uri,
    "source_id": SOURCE_ID,
    "dest_id": DEST_ID } ... ],
  "target_path": TARGET_PATH,
}

{
  "default": {
    "connection": {
      "access_key": ACCESS,
      "secret": SECRET,
      "endpoint": ENDPOINT,
      "host_style" path | virtual,
    },
    "acls": [
    {
      "type": id | email | uri,   #  optional, default is id
      "source_id": ID,
      "dest_id": ID
    } ... ]
    "target_path": PATH # optional
  },
  "connections": [
  {
    "connection_id": ID,
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,  # optional
  } ... ],
  "acl_profiles": [
  {
    "acls_id": ID, # acl mappings
    "acls": [ {
      "type": id | email | uri,
      "source_id": ID,
      "dest_id": ID
    } ... ]
  }
  ],
  "profiles": [
  {
   "source_bucket": SOURCE,
   "connection_id": CONNECTION_ID,
   "acls_id": MAPPINGS_ID,
   "target_path": DEST,          # optional
  } ... ],
}

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

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
}

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

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.

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.

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:

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.

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:

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.

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:

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.

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

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:

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

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

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

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

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

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>

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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:

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.

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.