Requisitos e limites do Cloud Storage Pool no StorageGRID
Sugerir alterações
PDFs
Se você planeja usar um Cloud Storage Pool para mover objetos para fora do sistema StorageGRID, deve revisar as considerações para configurar e usar Cloud Storage Pools.
Considerações gerais
-
Em geral, o armazenamento em nuvem para arquivamento, como Amazon S3 Glacier ou Azure Blob storage, é uma opção econômica para armazenar dados de objetos. No entanto, os custos para recuperar dados do armazenamento em nuvem para arquivamento são relativamente altos. Para obter o menor custo total, você deve considerar quando e com que frequência acessará os objetos no Cloud Storage Pool. O uso de um Cloud Storage Pool é recomendado apenas para conteúdo que você espera acessar com pouca frequência.
-
O uso de Cloud Storage Pools com FabricPool não é compatível devido à latência adicional para recuperar um objeto do destino do Cloud Storage Pool.
-
Objetos com o S3 Object Lock ativado não podem ser colocados em Cloud Storage Pools.
-
As seguintes combinações de plataforma, autenticação e protocolo com o S3 Object lock não são compatíveis com Cloud Storage Pools:
-
Plataformas: Google Cloud Platform e Azure
-
Tipos de autenticação: acesso anônimo
-
Protocolo: HTTP
-
Considerações sobre as portas utilizadas para os Cloud Storage Pools
Para garantir que as regras do ILM possam mover objetos de e para o Cloud Storage Pool especificado, você deve configurar a(s) rede(s) que contém(êm) os Storage Nodes do seu sistema. Você deve garantir que as seguintes portas possam se comunicar com o Cloud Storage Pool.
Por padrão, os Cloud Storage Pools usam as seguintes portas:
-
80: Para URIs de endpoint que começam com http
-
443: Para URIs de endpoint que começam com https
Você pode especificar uma porta diferente ao criar ou editar um Cloud Storage Pool.
Se você utiliza um servidor proxy não transparente, também precisa "configurar um servidor proxy de storage" permitir que mensagens sejam enviadas para endpoints externos, como um endpoint na internet.
Considerações sobre custos
O acesso ao storage na nuvem usando um Cloud Storage Pool requer conectividade de rede com a nuvem. Você deve considerar o custo da infraestrutura de rede que usará para acessar a nuvem e provisioná-la adequadamente, com base na quantidade de dados que espera mover entre StorageGRID e a nuvem usando o Cloud Storage Pool.
Quando StorageGRID se conecta ao endpoint externo do Cloud Storage Pool, ele emite várias solicitações para monitorar a conectividade e garantir que pode executar as operações necessárias. Embora alguns custos adicionais estejam associados a essas solicitações, o custo de monitorar um Cloud Storage Pool deve representar apenas uma pequena fração do custo total de armazenar objetos no S3 ou no Azure.
Custos mais significativos podem ser incorridos se você precisar mover objetos de um endpoint externo do Cloud Storage Pool de volta para StorageGRID. Objetos podem ser movidos de volta para StorageGRID em qualquer um destes casos:
-
A única cópia do objeto está em um Cloud Storage Pool e você decide armazenar o objeto no StorageGRID em vez disso. Nesse caso, você reconfigura suas regras e políticas do ILM. Quando a avaliação do ILM ocorre, o StorageGRID faz várias solicitações para recuperar o objeto do Cloud Storage Pool. O StorageGRID então cria localmente o número especificado de cópias replicadas ou com código de eliminação. Depois que o objeto é movido de volta para o StorageGRID, a cópia no Cloud Storage Pool é excluída.
-
Os objetos são perdidos devido a falha no Storage Node. Se a única cópia restante de um objeto estiver em um Cloud Storage Pool, o StorageGRID restaura temporariamente o objeto e cria uma nova cópia no Storage Node recuperado.
|
Quando objetos são movidos de volta para StorageGRID a partir de um Cloud Storage Pool, StorageGRID envia várias solicitações ao endpoint do Cloud Storage Pool para cada objeto. Antes de mover grandes quantidades de objetos, entre em contato com o suporte técnico para obter ajuda na estimativa do tempo necessário e dos custos associados. |
S3: permissões necessárias para o bucket do Cloud Storage Pool
As políticas do bucket S3 externo usado para um Cloud Storage Pool devem conceder ao StorageGRID permissão para mover um objeto para o bucket, obter o status de um objeto, restaurar um objeto do armazenamento Glacier quando necessário e mais. Idealmente, o StorageGRID deve ter acesso de controle total ao bucket (s3:*; no entanto, se isso não for possível, a política do bucket deve conceder as seguintes permissões S3 ao StorageGRID:
-
s3:AbortMultipartUpload -
s3:DeleteObject -
s3:GetObject -
s3:ListBucket -
s3:ListBucketMultipartUploads -
s3:ListMultipartUploadParts -
s3:PutObject -
s3:RestoreObject
S3: Considerações sobre o ciclo de vida do bucket externo
A movimentação de objetos entre StorageGRID e o bucket S3 externo especificado no Cloud Storage Pool é controlada pelas regras de ILM e pelas políticas de ILM ativas no StorageGRID. Em contraste, a transição de objetos do bucket S3 externo especificado no Cloud Storage Pool para Amazon S3 Glacier ou S3 Glacier Deep Archive (ou para uma solução de storage que implemente a classe de armazenamento Glacier) é controlada pela configuração de ciclo de vida desse bucket.
Se você deseja migrar objetos do Cloud Storage Pool, é necessário criar a configuração de ciclo de vida apropriada no bucket S3 externo e usar uma solução de storage que implemente a classe de armazenamento Glacier e seja compatível com a API RestoreObject do S3.
Por exemplo, suponha que você queira que todos os objetos movidos do StorageGRID para o Cloud Storage Pool sejam transferidos imediatamente para o armazenamento Amazon S3 Glacier. Você criaria uma configuração de ciclo de vida no bucket S3 externo que especifica uma única ação (Transição) da seguinte forma:
<LifecycleConfiguration>
<Rule>
<ID>Transition Rule</ID>
<Filter>
<Prefix></Prefix>
</Filter>
<Status>Enabled</Status>
<Transition>
<Days>0</Days>
<StorageClass>GLACIER</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>
Essa regra faria a transição de todos os objetos do bucket para o Amazon S3 Glacier no dia em que foram criados (ou seja, no dia em que foram movidos do StorageGRID para o Cloud Storage Pool).
|
Ao configurar o ciclo de vida do bucket externo, nunca use ações de Expiração para definir quando os objetos expiram. As ações de Expiração fazem com que o sistema de storage externo exclua os objetos expirados. Se você tentar acessar um objeto expirado posteriormente no StorageGRID, o objeto excluído não será encontrado. |
Se você deseja migrar objetos no Cloud Storage Pool para o S3 Glacier Deep Archive (em vez do Amazon S3 Glacier), especifique `<StorageClass>DEEP_ARCHIVE</StorageClass>`no ciclo de vida do bucket. No entanto, esteja ciente de que você não pode usar o nível `Expedited`para restaurar objetos do S3 Glacier Deep Archive.
Azure: considerações sobre a camada de acesso
Ao configurar uma conta de armazenamento do Azure, você pode definir o nível de acesso padrão como Hot ou Cool. Ao criar uma conta de armazenamento para uso com um Cloud Storage Pool, você deve usar o nível Hot como padrão. Embora o StorageGRID defina imediatamente o nível como Archive ao mover objetos para o Cloud Storage Pool, usar a configuração padrão Hot garante que você não será cobrado por exclusão antecipada de objetos removidos do nível Cool antes do período mínimo de 30 dias.
Azure: gerenciamento de ciclo de vida não suportado
Não utilize o gerenciamento de ciclo de vida do Azure Blob storage para o contêiner usado com um Cloud Storage Pool. As operações de ciclo de vida podem interferir nas operações do Cloud Storage Pool.