Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Como StorageGRID API REST S3 equilibra disponibilidade e consistência

PDFs

A consistência proporciona um equilíbrio entre a disponibilidade dos objetos e a consistência desses objetos em diferentes Storage Nodes e sites. Você pode alterar a consistência conforme necessário para sua aplicação.

Por padrão, StorageGRID garante a consistência de leitura após gravação para objetos recém-criados. Qualquer GET subsequente a um PUT concluído com sucesso poderá ler os dados recém-gravados. Sobrescritas de objetos existentes, atualizações de metadados e exclusões são eventualmente consistentes.

Se você deseja executar operações de objetos com um nível de consistência diferente, você pode:

  • Especifique uma consistência para cada bucket.

  • Especifique uma consistência para cada operação de API.

  • Altere a consistência padrão de toda a grade executando uma das seguintes tarefas:

    • No Grid Manager, acesse Configuração > Sistema > Configurações de armazenamento > Consistência padrão do bucket.

    • .

      Observação Uma alteração na consistência de toda a grade aplica-se apenas aos buckets criados após a alteração da configuração. Para determinar os detalhes de uma alteração, consulte o log de auditoria localizado em /var/local/log (pesquise por consistencyLevel).

Valores de consistência

A consistência afeta a forma como os metadados que StorageGRID usa para rastrear objetos são distribuídos entre os nós. A consistência afeta a disponibilidade de objetos para solicitações de clientes.

Você pode definir a consistência de um bucket ou de uma operação de API para um dos seguintes valores:

  • Todos: Todos os nós recebem metadados de objeto imediatamente ou a solicitação falhará.

  • Strong-global: Garante a consistência de leitura após gravação para todas as solicitações do cliente em todos os sites. Quando a semântica de Quorum está configurada, os seguintes comportamentos se aplicam:

    • Permite tolerância a falha do local para solicitações de clientes quando as grades têm três ou mais sites. Grades com dois sites não terão tolerância a falha do local.

    • As seguintes operações do S3 não serão bem-sucedidas com um site inativo:

      • DeleteBucketEncryption

      • PutBucketBranch

      • PutBucketEncryption

      • PutBucketVersioning

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

    Se necessário, você pode "configurar a semântica de quorum do StorageGRID para consistência global forte".

  • Strong-site: os metadados do objeto são distribuídos imediatamente para outros nós no site. Garante a consistência de leitura após gravação para todas as solicitações do cliente dentro de um site.

  • Leitura após nova gravação: Oferece consistência de leitura após gravação para novos objetos e consistência eventual para atualizações de objetos. Oferece alta disponibilidade e garantias de proteção de dados. Recomendado para a maioria dos casos.

  • Disponível: Oferece consistência eventual tanto para novos objetos quanto para atualizações de objetos. Para buckets do S3, use somente quando necessário (por exemplo, para um bucket que contém valores de log que são lidos raramente ou para operações HEAD ou GET em chaves que não existem). Não é compatível com buckets do S3 FabricPool.

Use as consistências "Read-after-new-write" e "Available"

Quando uma operação HEAD ou GET utiliza a consistência "Leitura após nova gravação", StorageGRID realiza a pesquisa em várias etapas, da seguinte forma:

  • Primeiro, ele busca o objeto usando uma consistência baixa.

  • Caso essa busca falhe, ela se repete no próximo valor de consistência até atingir uma consistência equivalente ao comportamento de strong-global.

Se uma operação HEAD ou GET usar a consistência "Read-after-new-write", mas o objeto não existir, a busca pelo objeto sempre atingirá uma consistência equivalente ao comportamento para strong-global. Como essa consistência exige que várias cópias dos metadados do objeto estejam disponíveis em cada site, você pode receber um grande número de erros 500 Internal Server se dois ou mais Storage Nodes no mesmo site estiverem indisponíveis.

A menos que você precise de garantias de consistência semelhantes às da Amazon S3, você pode evitar esses erros para operações HEAD e GET definindo a consistência como "Disponível". Quando uma operação HEAD ou GET usa a consistência "Disponível", StorageGRID fornece apenas consistência eventual. Não tenta novamente uma operação com falha em níveis de consistência crescentes, portanto, não exige que várias cópias dos metadados do objeto estejam disponíveis.

Especifique a consistência para a operação da API

Para definir a consistência de uma operação de API específica, os valores de consistência devem ser suportados pela operação e você deve especificar a consistência no cabeçalho da solicitação. Este exemplo define a consistência como "Strong-site" para uma operação GetObject.

GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
Observação Você deve usar a mesma consistência para as operações PutObject e GetObject.

Especifique a consistência para o bucket

Para definir a consistência do bucket, você pode usar a solicitação "Consistência de PUT Bucket" do StorageGRID. Ou você pode "alterar a consistência de um bucket" a partir do Tenant Manager.

Ao definir a consistência de um bucket, esteja ciente do seguinte:

  • A configuração de consistência para um bucket determina qual consistência é usada para as operações S3 realizadas nos objetos no bucket ou na configuração do bucket. Ela não afeta as operações no próprio bucket.

  • A consistência de uma operação individual da API tem precedência sobre a consistência do bucket.

  • Em geral, os buckets devem usar a consistência padrão, "Leitura após nova gravação". Se as solicitações não estiverem funcionando corretamente, altere o comportamento do cliente do aplicativo, se possível. Ou configure o cliente para especificar a consistência para cada solicitação de API. Defina a consistência no nível do bucket somente como último recurso.

Como as regras de consistência e ILM interagem para afetar a proteção de dados

Tanto a sua escolha de consistência quanto a sua regra ILM afetam a forma como os objetos são protegidos. Essas configurações podem interagir.

Por exemplo, a consistência usada quando um objeto é armazenado afeta o posicionamento inicial dos metadados do objeto, enquanto o comportamento de ingestão selecionado para a regra de gerenciamento de ciclo de vida (ILM) afeta o posicionamento inicial das cópias do objeto. Como StorageGRID requer acesso tanto aos metadados quanto aos dados de um objeto para atender às solicitações do cliente, selecionar níveis de proteção correspondentes para a consistência e o comportamento de ingestão pode proporcionar melhor proteção inicial dos dados e respostas mais previsíveis do sistema.

As seguintes "opções de ingestão" estão disponíveis para as regras do ILM:

Commit duplo

StorageGRID cria imediatamente cópias provisórias do objeto e retorna sucesso ao cliente. Cópias especificadas na regra ILM são feitas quando possível.

Estrito

Todas as cópias especificadas na regra ILM devem ser feitas antes que a mensagem de sucesso seja retornada ao cliente.

Equilibrado

StorageGRID tenta criar todas as cópias especificadas na regra ILM durante a ingestão; se isso não for possível, cópias provisórias são criadas e uma mensagem de sucesso é retornada ao cliente. As cópias especificadas na regra ILM são criadas sempre que possível.

Exemplo de como a consistência e a regra de ILM podem interagir

Suponha que você tenha uma grade de três sites com a seguinte regra ILM e a seguinte consistência:

  • Regra ILM: Crie três cópias do objeto, uma no local e uma em cada local remoto. Use o comportamento de ingestão estrito.

  • Consistência: Global forte (os metadados do objeto são distribuídos imediatamente para vários sites).

Quando um cliente armazena um objeto na grid, StorageGRID cria as três cópias do objeto e distribui os metadados para vários sites antes de retornar sucesso ao cliente.

O objeto fica totalmente protegido contra perda no momento em que a mensagem de ingestão bem-sucedida é recebida. Por exemplo, se o local remoto for perdido logo após a ingestão, cópias dos dados do objeto e dos metadados do objeto ainda existirão nos locais remotos. O objeto poderá ser recuperado integralmente dos outros locais.

Se, em vez disso, você usasse a mesma regra ILM e a consistência forte do site, o cliente poderia receber uma mensagem de sucesso após os dados do objeto serem replicados para os locais remotos, mas antes que os metadados do objeto fossem distribuídos lá. Nesse caso, o nível de proteção dos metadados do objeto não corresponde ao nível de proteção dos dados do objeto. Se o local remoto for perdido logo após a ingestão, os metadados do objeto serão perdidos. O objeto não pode ser recuperado.

A inter-relação entre as regras de consistência e as regras de ILM pode ser complexa. Entre em contato com a NetApp se você precisar de assistência.