Valores de consistência
Sugerir alterações
PDFs
A consistência fornece um equilíbrio entre a disponibilidade dos objetos e a consistência desses objetos em diferentes nós de storage e locais. Você pode alterar a consistência conforme exigido pelo seu aplicativo.
Por padrão, o StorageGRID garante consistência de leitura após gravação para objetos recém-criados. Qualquer GET seguindo um PUT concluído com sucesso será capaz de ler os dados recém-escritos. As substituições de objetos existentes, atualizações de metadados e exclusões são, eventualmente, consistentes. As substituições geralmente levam segundos ou minutos para se propagar, mas podem levar até 15 dias.
Se você quiser executar operações de objeto em uma consistência diferente, você pode:
-
Especifique uma consistência para cada baldeo .
-
Especifique uma consistência para Cada operação da APIo .
-
Altere a consistência padrão em toda a grade executando uma das seguintes tarefas:
-
No Gerenciador de Grade, vá para CONFIGURATION > System > Storage settings > Default consistency.
-
.
Uma alteração na consistência em toda a grade se aplica somente 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(procure consistencyLevel).
-
Valores de consistência
A consistência afeta como os metadados que o StorageGRID usa para rastrear objetos são distribuídos entre nós e, portanto, a disponibilidade de objetos para solicitações de clientes.
Você pode definir a consistência de um bucket ou uma operação de API para um dos seguintes valores:
-
Todos: Todos os nós recebem os dados imediatamente, ou a solicitação falhará.
-
Strong-global: Garante consistência de leitura após gravação para todas as solicitações de clientes em todos os sites.
-
* Strong-site*: Garante consistência de leitura-após-gravação para todas as solicitações de clientes dentro de um site.
-
Read-after-novo-write: (Padrão) fornece consistência de leitura-após-gravação para novos objetos e eventual consistência para atualizações de objetos. Oferece alta disponibilidade e garantias de proteção de dados. Recomendado para a maioria dos casos.
-
Disponível: Fornece consistência eventual para novos objetos e atualizações de objetos. Para buckets do S3, use somente conforme necessário (por exemplo, para um bucket que contém valores de log raramente lidos, ou para operações HEAD ou GET em chaves que não existem). Não compatível com buckets do FabricPool S3.
Use a consistência "Read-after-new-write" e "Available"
Quando uma operação HEAD ou GET usa a consistência "Read-after-new-write", o StorageGRID realiza a pesquisa em várias etapas, como segue:
-
Ele primeiro procura o objeto usando uma baixa consistência.
-
Se essa pesquisa falhar, ela repete a pesquisa no próximo valor de consistência até atingir uma consistência equivalente ao comportamento para strong-global.
Se uma operação HEAD ou GET usa a consistência "Read-after-new-write", mas o objeto não existe, a pesquisa de objeto sempre alcançará uma consistência equivalente ao comportamento para strong-global. Como essa consistência exige que várias cópias dos metadados de objetos estejam disponíveis em cada local, você pode receber um número alto de erros de servidor interno do 500 se dois ou mais nós de storage no mesmo local não estiverem disponíveis.
A menos que você exija garantias de consistência semelhantes ao Amazon S3, você pode evitar esses erros para operações HEAD and GET definindo a consistência como "disponível". Quando uma operação HEAD ou GET usa a consistência "disponível", o StorageGRID fornece consistência eventual apenas. Ele não tenta novamente uma operação com falha em aumentar a consistência, portanto, não requer 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 para uma operação de API individual, os valores de consistência devem ser suportados para a 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
|
|
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 StorageGRID"COLOQUE a consistência do balde". Ou você pode "altere a consistência de um balde" do Gerente do Locatário.
Ao definir a consistência de um balde, tenha em atenção o seguinte:
-
Definir a consistência de um bucket determina qual consistência é usada para operações S3D executadas nos objetos no bucket ou na configuração do bucket. Não afeta as operações no próprio balde.
-
A consistência de uma operação de API individual substitui a consistência do bucket.
-
Em geral, os intervalos devem usar a consistência padrão, "Read-after-new-write". 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 balde apenas como último recurso.
como a consistência e as regras 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 ILM afeta o posicionamento inicial das cópias do objeto. Como o StorageGRID exige acesso aos metadados de um objeto e aos dados para atender às solicitações do cliente, selecionar níveis de proteção correspondentes para o comportamento de consistência e ingestão pode fornecer melhor proteção de dados iniciais e respostas do sistema mais previsíveis.
Estão disponíveis as seguintes "opções de ingestão"regras para ILM:
- Commit duplo
-
O StorageGRID faz imediatamente cópias provisórias do objeto e retorna sucesso ao cliente. Cópias especificadas na regra ILM são feitas quando possível.
- Rigoroso
-
Todas as cópias especificadas na regra ILM devem ser feitas antes que o sucesso seja devolvido ao cliente.
- Equilibrado
-
O StorageGRID tenta fazer todas as cópias especificadas na regra ILM na ingestão; se isso não for possível, cópias provisórias são feitas e o sucesso é retornado ao cliente. As cópias especificadas na regra ILM são feitas quando possível.
Exemplo de como a consistência e a regra ILM podem interagir
Suponha que você tenha uma grade de dois locais com a seguinte regra ILM e a seguinte consistência:
-
Regra ILM: Crie duas cópias de objeto, uma no local e outra em um local remoto. Use um comportamento rigoroso de ingestão.
-
Consistência: Strong-global (metadados de objetos são imediatamente distribuídos para todos os sites).
Quando um cliente armazena um objeto na grade, o StorageGRID faz cópias de objeto e distribui metadados para ambos os sites antes de retornar sucesso ao cliente.
O objeto é totalmente protegido contra perda no momento da mensagem de ingestão bem-sucedida. Por exemplo, se o local for perdido logo após a ingestão, cópias dos dados do objeto e dos metadados do objeto ainda existem no local remoto. O objeto é totalmente recuperável.
Se, em vez disso, você usou a mesma regra ILM e a consistência do site forte, o cliente pode receber uma mensagem de sucesso depois que os dados do objeto são replicados para o site remoto, mas antes que os metadados do objeto sejam distribuídos lá. Nesse caso, o nível de proteção dos metadados de objetos não corresponde ao nível de proteção dos dados de objeto. Se o site local 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 consistência e regras de ILM pode ser complexa. Contacte a NetApp se necessitar de assistência.