Controles de consistência
Sugerir alterações
PDFs
Os controles de consistência fornecem uma troca entre a disponibilidade dos objetos e a consistência desses objetos em diferentes nós e sites de storage, conforme exigido pelo 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 um nível de consistência diferente, você pode especificar um controle de consistência para cada bucket ou para cada operação de API.
Controles de consistência
O controle de 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 o controle de consistência para um bucket ou uma operação de API para um dos seguintes valores:
| Controle de consistência | Descrição |
|---|---|
tudo |
Todos os nós recebem os dados imediatamente, ou a solicitação falhará. |
forte-global |
Garante consistência de leitura após gravação para todas as solicitações de clientes em todos os sites. |
forte local |
Garante consistência de leitura após gravação para todas as solicitações de clientes dentro de um site. |
leitura-após-nova-gravação |
(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. Corresponde às garantias de consistência do Amazon S3. Observação: se o aplicativo usar SOLICITAÇÕES HEAD em objetos que não existem, você pode receber um número alto de erros de servidor interno 500 se um ou mais nós de armazenamento não estiverem disponíveis. Para evitar esses erros, defina o controle de consistência como "disponível", a menos que você exija garantias de consistência semelhantes ao Amazon S3. |
Disponível (eventual consistência para OPERAÇÕES DE CABEÇA) |
Comporta-se da mesma forma que o nível de consistência "read-after-novo-write", mas apenas fornece consistência eventual para operações HEAD. Oferece maior disponibilidade para OPERAÇÕES HEAD do que "read-after-novo-write" se os nós de storage não estiverem disponíveis. Difere das garantias de consistência do Amazon S3 apenas para operações PRINCIPAIS. |
Usando os controles de consistência "read-after-new-write" e "available"
Quando uma operação HEAD ou GET usa o controle de consistência "read-after-novo-write" ou uma operação GET usa o controle de consistência "'disponível'", 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 nível de consistência até atingir o mais alto nível de consistência, "All", o que requer que todas as cópias dos metadados do objeto estejam disponíveis.
Se uma operação HEAD ou GET usar o controle de consistência "read-after-novo-write", mas o objeto não existir, a pesquisa de objetos sempre alcançará o nível de consistência "'all'". Como esse nível de consistência exige que todas as cópias dos metadados do objeto estejam disponíveis, você pode receber um número alto de 500 erros de servidor interno se um ou mais nós de storage não estiverem disponíveis.
A menos que você precise de garantias de consistência semelhantes ao Amazon S3, você pode evitar esses erros para operações HEAD definindo o controle de consistência como "disponível". Quando uma operação HEAD usa o controle de consistência "disponível", o StorageGRID fornece consistência eventual apenas. Ele não tenta novamente uma operação com falha até atingir o nível de consistência "'tudo'", portanto, não requer que todas as cópias dos metadados do objeto estejam disponíveis.
Especificando o controle de consistência para uma operação de API
Para definir o controle de consistência para uma operação de API individual, os controles de consistência devem ser suportados para a operação e você deve especificar o controle de consistência no cabeçalho da solicitação. Este exemplo define o controle de consistência como "local-trong" para uma operação GET Object.
GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
|
Você deve usar o mesmo controle de consistência para as operações COLOCAR Objeto e OBTER Objeto. |
Especificando o controle de consistência para um bucket
Para definir o controle de consistência para o bucket, você pode usar a solicitação de consistência do bucket do StorageGRID PUT e a solicitação DE consistência do bucket do GET. Ou você pode usar o Gerenciador do Locatário ou a API de Gerenciamento do Locatário.
Ao definir os controlos de consistência para um balde, tenha em atenção o seguinte:
-
Definir o controle de consistência para um balde determina qual controle de consistência é usado para operações S3D realizadas nos objetos no balde ou na configuração do balde. Não afeta as operações no próprio balde.
-
O controle de consistência para uma operação de API individual substitui o controle de consistência para o bucket.
-
Em geral, os buckets devem usar o controle de 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 o controle de consistência para cada solicitação de API. Defina o controle de consistência no nível do balde apenas como último recurso.
Como os controles de consistência e as regras de ILM interagem para afetar a proteção de dados
Tanto a sua escolha de controle de consistência quanto a sua regra ILM afetam a forma como os objetos são protegidos. Essas configurações podem interagir.
Por exemplo, o controle de consistência usado 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 nível de consistência e comportamento de ingestão pode fornecer melhor proteção inicial de dados e respostas do sistema mais previsíveis.
Os seguintes comportamentos de ingestão estão disponíveis para regras ILM:
-
Strict: Todas as cópias especificadas na regra ILM devem ser feitas antes que o sucesso seja devolvido ao cliente.
-
Balanced: O StorageGRID tenta fazer todas as cópias especificadas na regra ILM no ingest; 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.
-
* 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.
|
|
Antes de selecionar o comportamento de ingestão para uma regra ILM, leia a descrição completa dessas configurações nas instruções para gerenciar objetos com gerenciamento do ciclo de vida das informações. |
Exemplo de como o controle de 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 configuração de nível de consistência:
-
Regra ILM: Crie duas cópias de objeto, uma no local e outra em um local remoto. O comportamento de ingestão estrita é selecionado.
-
Nível de consistência: "Trong-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 o nível de consistência "site-trong", o cliente poderá receber uma mensagem de sucesso depois que os dados do objeto forem replicados para o sitqe 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 níveis de consistência e regras de ILM pode ser complexa. Contacte a NetApp se necessitar de assistência.