Data Domain Restorer e retenção de longo prazo para a nuvem: Perguntas frequentes

Este artigo aborda as perguntas mais frequentes sobre a configuração e o uso de Data Domain Restorers (DDRs) e do recurso de retenção em longo prazo (LTR) ou de nuvem.
 

O que é LTR?

• Um novo recurso chamado LTR foi introduzido a partir do Data Domain Operating System (DDOS) 6.0.
• A LTR permite que determinados modelos de DDRs migrem um subconjunto de arquivos ou dados para um armazenamento em objeto ou nuvem, conhecido como nível de nuvem, de diversos provedores compatíveis de serviços em nuvem pública ou privada.
• Para migrar arquivos ou dados fisicamente para o armazenamento em objeto, um processo de movimentação de dados é executado no DDR.
• Para liberar dados redundantes do nível de nuvem fisicamente, um processo de limpeza do nível de nuvem é executado no DDR.
• LTR é um recurso licenciado e requer uma CLOUDTIER_CAPACITY license.
• A LTR exige armazenamento local para metadados do nível de nuvem.

Para quais sistemas DDR a LTR está disponível?
Isso depende da versão do DDOS instalada junto com o tipo de modelo do sistema. A maioria dos modelos tem certos requisitos de hardware que devem ser atendidos com antecedência para a configuração da LTR. Para obter esses requisitos, consulte o guia de instalação de hardware dos modelos específicos, juntamente com o guia de administração do DDOS.

Qual licença é necessária para a LTR?

• Como o LTR é considerado um novo recurso do DDOS 6.x e versões posteriores, uma elicense é necessária. 
• O tipo de elicense necessário é chamado de CLOUDTIER_CAPACITY license. Veja um exemplo CLOUDTIER_CAPACITY license a seguir:

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Como funcionam os diferentes níveis?

• Os DDRs normais (sem uma licença de LTR) têm um só nível, conhecido como nível ativo.
• O nível ativo é o nível tradicional de armazenamento em todos os DDRs "padrão".
• Os sistemas de LTR têm um segundo nível de armazenamento conhecido como nível de nuvem.

O tamanho máximo de cada nível é determinado pelos limites compatíveis com a configuração de hardware e a versão do DDOS específica. Consulte o guia de hardware e o guia de administração do DDOS do modelo específico em questão.

Um exemplo de configuração de LTR de dois níveis, um ativo e um de nuvem, é exibido abaixo:   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

Como é a estrutura de um nível de nuvem?

• Um nível de nuvem consiste em:   
  • Metadados mantidos localmente, armazenados em um compartimento caso um DDR físico seja usado ou em um LUN ou um dispositivo caso um DDVE seja usado.
  • Provedores de armazenamento em objeto
• Ambos os itens acima são combinados em uma unidade de nuvem.
• Se várias unidades de nuvem estiverem configuradas, elas poderão compartilhar os metadados mantidos localmente.
• É possível configurar no máximo duas unidades de nuvem por sistema. Cada unidade de nuvem pode ser provisionada de um provedor de armazenamento em objeto diferente.
• O tamanho de cada unidade de nuvem pode igual ao tamanho máximo compatível do nível ativo para o modelo específico de DDR. Consulte o guia de administração do DDOS para obter mais informações.

O que acontece durante um ciclo de vida típico de backup quando a LTR é configurada?

• Inicialmente, todos os dados são gravados no nível ativo, onde começam a envelhecer.
• Os dados de curta duração que atingem o período de retenção expiram/são excluídos como em um DDR normal.
• No entanto, um subconjunto de dados que exige retenção de longo prazo migra para o nível de nuvem.
• O file system mantém um só namespace em todos os níveis; portanto, quando um arquivo migra para a nuvem, o namespace não muda e, assim, fica razoavelmente transparente para o usuário ou o aplicativo de backup.
• Quando um arquivo que já migrou para o nível de nuvem atinge o período de retenção, ele expira/é excluído como qualquer outro arquivo.
• O espaço que um arquivo estava usando no nível de nuvem não é recuperado imediatamente; em vez disso, é necessário executar a limpeza do nível de nuvem.

Como ocorre a desduplicação de dados entre níveis?

• Cada unidade de nuvem é um volume independente, o que significa que é uma unidade de desduplicação autossuficiente.
• Como resultado, somente é possível desduplicar os dados gravados em cada unidade de nuvem na mesma unidade de nuvem.

O que é hora de alocação (às vezes, chamada de ptime)?

• Os arquivos e diretórios têm vários registros de data e hora associados a eles.
• Por exemplo, um arquivo ou diretório tem uma hora de criação, hora do último acesso e hora de modificação.
• O DDOS aprimorou ainda mais esse processo para incluir também a hora de alocação. Ela é a data e a hora em que o arquivo migrou do nível ativo para o nível de nuvem.
• Dependendo da versão do DDOS, é possível ver a hora de alocação ao examinar em qual nível um arquivo reside. Se o arquivo migrou para o nível de nuvem, por exemplo, a hora de alocação será exibida da seguinte forma:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• ptime é o último campo do resultado acima, embora não exiba um cabeçalho de campo.

Como os dados se movem do nível ativo para o nível de nuvem?

• Um processo chamado de movimentação de dados é responsável por examinar os arquivos de uma MTree que residem no nível ativo.
• A movimentação de dados começa com a criação de um snapshot de todas as MTrees configuradas para movimentação de dados.
• Cada arquivo tem um horário de modificação que armazena a última vez em que um arquivo foi gravado.
• Se um arquivo migrou anteriormente para o nível de nuvem, haverá a definição de um campo adicional de horário chamado de hora de alocação. A hora de alocação armazena a data e a hora em que o arquivo migrou para o nível ativo. Se a hora de alocação estiver definida, ela será usada em vez da hora de modificação. Isso evita que um arquivo seja continuamente migrado de volta para o nível de nuvem em caso de recall de um arquivo (já que o recall de um arquivo não altera a hora de modificação).
• Os snapshots criados acima são examinados pela movimentação de dados.
• Se o arquivo que está sendo examinado tiver atingido um valor limite definido, conforme definido pela política de movimentação de dados para a MTree em questão, o arquivo será examinado para verificar quais dados mantidos nele devem migrar do nível ativo para o nível de nuvem. Há a definição de uma política de movimentação de dados por MTree.
• Os segmentos exclusivos do arquivo selecionado são gravados ou copiados no nível de nuvem. 
• Depois da cópia dos segmentos exclusivos, o arquivo será verificado lendo-os novamente para garantir que a migração foi bem-sucedida.
• Depois de verificar o arquivo, os metadados serão atualizados para refletir que o arquivo agora reside no nível de nuvem.
• É possível agendar o processo de movimentação de dados para execução em determinada frequência ou iniciá-lo manualmente.

Quando a movimentação de dados começa, quais são as fases existentes e quais ações cada fase realiza?

• Há três fases associadas à movimentação de dados: a fase de cópia, a fase de verificação e a fase de instalação.
• A fase de cópia é responsável por identificar os segmentos que devem ser copiados para a nuvem e, em seguida, migrar esses segmentos para a nuvem.
• Depois que a fase de cópia começa, o armazenamento em nuvem ou objeto é usado conforme a fase de cópia copia os segmentos identificados do nível ativo para o nível de nuvem.
• A fase de verificação é responsável por garantir que os segmentos de um arquivo foram migrados para a nuvem com sucesso.
• A fase de instalação é responsável por atualizar os metadados referentes ao arquivo que foi migrado para mostrar que ele agora reside no armazenamento em nuvem ou objeto.
• Cada arquivo precisa concluir todas as três fases para que a movimentação de dados seja considerada bem-sucedida para ele. Portanto, até a conclusão da fase de instalação de um arquivo, o arquivo permanecerá no nível ativo.

Quais são as políticas de movimentação de dados disponíveis?

• As políticas de movimentação de dados podem ser uma das seguintes:   
  • Limite de idade: Se a hora de modificação ou alocação de um arquivo for maior que o intervalo de idade definida, ele será selecionado para migração para o nível de nuvem.
  • Intervalo de idade: Se a hora de modificação ou alocação de um arquivo se enquadrar em determinado intervalo, ele será selecionado para migração para o nível de nuvem.
  • Aplicativo definido: O aplicativo de backup designa se um arquivo deve ser selecionado para migração para o nível de nuvem.
• As políticas são mutuamente exclusivas; ou seja, uma MTree só pode ter uma política definida por vez.

Como definir uma política de movimentação de dados em uma MTree?

• É possível usar o comando abaixo. Por exemplo:   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

Quais políticas de movimentação de dados já estão configuradas?

• O comando abaixo apresenta uma lista de quais MTrees têm políticas de movimentação de dados atribuídas a elas. Por exemplo:   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

Como funciona uma política de movimentação de dados gerenciada por aplicativo?

• A política de movimentação de dados da MTree em questão é definida como gerenciada por aplicativo. Isso é feito manualmente, ou o aplicativo de backup faz isso usando a interface API REST do Data Domain.
• O aplicativo de backup deve reconhecer LTR.
• O aplicativo de backup deve usar o DD Boost, e a versão do DD Boost deve ter reconhecimento de LTR e ser compatível.
• Usando a biblioteca/API do DD Boost, o aplicativo de backup definirá o tempo de posicionamento do arquivo que deve ser migrado para o nível da nuvem como um valor especial, indicando que, da próxima vez que a movimentação de dados for executada, o arquivo será migrado para a nuvem.
• Quando houver a movimentação de dados no sistema Data Domain, a hora de alocação será verificada e, se estiver definida como o valor especial mencionado acima, ele migrará o arquivo para a nuvem.

Como iniciar a movimentação de dados manualmente?

• É possível usar o comando abaixo, por exemplo:   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

Como monitorar a movimentação de dados?

• É possível usar o comando abaixo para verificar o status da movimentação de dados. Por exemplo:   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Se a movimentação de dados estiver em execução, será possível usar o comando abaixo, por exemplo:   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

Como interromper a movimentação de dados?

• É possível usar o comando abaixo. Por exemplo:   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

Se houver mais de uma unidade de nuvem, será possível executar a movimentação de dados paralelamente para as duas unidades de nuvem?

• Não. Basicamente, a movimentação de dados só pode migrar dados para uma unidade de nuvem por vez.

Como a LTR é configurada?

• Esta é uma visão geral de alto nível. Consulte o processo detalhado no guia de administração do DDOS.
• Adicione a CLOUDTIER_CAPACITY license.
• Defina a frase secreta do sistema, caso ainda não esteja definida.
• Ative o recurso de nuvem.
• Adicione o armazenamento de metadados do nível de nuvem.
• Configure um perfil de nuvem ou um perfil do armazenamento em nuvem ou objeto adequado.
• Adicione uma unidade de nuvem.
• Configure uma política de movimentação de dados da MTree ou das MTrees que exigem o armazenamento de dados na nuvem.
• Inicie a movimentação de dados manualmente ou aguarde até o início de uma movimentação de dados automática ou agendada.

É possível excluir uma unidade de nuvem? Em caso afirmativo, como?

• Aviso: Isso destruirá todos os dados mantidos na unidade de nuvem; portanto, os dados serão irrecuperáveis. Dessa forma, proceda com cuidado.
• Consulte a seção deste documento da base de conhecimento intitulada "Como um usuário determina em que nível um arquivo está localizado?" para entender quais arquivos residem na unidade de nuvem que será excluída.
• Se esses arquivos não serão mais necessários, deverão ser excluídos; se precisarão ser mantidos, faça recall deles para o nível ativo.
• Se for necessário manter os arquivos, certifique-se de fazer recall de todos eles antes de continuar.
• Não deve haver arquivos remanescentes na unidade de nuvem excluída.
• Redefina todas as políticas de movimentação de dados para a MTree ou as MTrees que usam essa unidade de nuvem.
• Desabilite o file system.
• Exclua a unidade de nuvem. Isso marcará a unidade de nuvem com o estado DELETE_PENDING, que é o comportamento esperado.
• Ative o file system.
• Depois do início do file system, ele começa a excluir de modo assíncrono todos os objetos do provedor de armazenamento em nuvem ou objeto que foram usados por essa unidade de nuvem. Depois da exclusão de todos os objetos, os buckets usados por essa unidade de nuvem também serão excluídos. Se houver muitos objetos, a unidade de nuvem poderá permanecer no estado DELETE_PENDING por um longo período.
• Depois de remover todos os objetos e buckets com sucesso, a unidade da nuvem desaparecerá da lista de unidades de nuvem.

O que acontecerá se uma unidade de nuvem não for excluída porque o armazenamento em objeto não está mais disponível ou há um problema de conectividade?

• Entre em contato com o Suporte Dell para obter mais assistência.

É possível configurar a LTR e o Extended Retention (ER) no mesmo sistema?

• Não. ER e LTR são recursos mutuamente exclusivos.

Como liberar ou limpar os dados do nível de nuvem?

• Isso funciona de maneira semelhante aos arquivos que residem no nível ativo
• Depois que um arquivo atinge o período de retenção, ele é excluído do namespace do file system.
• A execução da limpeza do nível de nuvem é agendada. Por padrão, a limpeza do nível de nuvem é executada após cada quatro sessões de limpeza do nível ativo.
• Para que a execução da limpeza do nível de nuvem comece, a unidade de nuvem que está sendo limpa deve ter pelo menos 1% de dados supérfluos ou passíveis de limpeza. Isso ocorre porque qualquer tráfego de rede em nuvem pode ser cobrado; portanto, o DDR tenta limitar o tráfego de rede sempre que possível.
• O nível de nuvem é executado com um padrão de controle de fluxo de limpeza de 50%.
• É possível alterar o agendamento e o controle de fluxo da limpeza do nível de nuvem.
• Não é possível executar a limpeza do nível ativo e do nível de nuvem paralelamente.
• Se a limpeza automática ou agendada do nível de nuvem estiver em execução, ela será sobreposta pela limpeza do nível ativo.
• Se uma limpeza manual do nível de nuvem for iniciada, a limpeza do nível ativo só poderá começar após a conclusão da limpeza do nível de nuvem.
• Se um nível de nuvem tiver duas unidades de nuvem, apenas uma delas passará pelo processo de limpeza agendada ou automática do nível de nuvem. De um ponto de vista de limpeza do nível de nuvem, as unidades de nuvem são operadas de acordo com um rodízio. Quando há duas unidades de nuvem, é um requisito especificar a unidade de nuvem que será limpa durante a execução na linha de comando (cloud clean start <unit-name>)
• Se uma limpeza do nível de nuvem não iniciar em uma unidade de nuvem, por exemplo, a unidade de nuvem atual não tem dados suficientes passíveis de limpeza para que o processo compense, o sistema tentará fazer a limpeza automaticamente a partir da próxima unidade de nuvem.
• Para obter mais informações sobre a limpeza do nível da nuvem, consulte o seguinte artigo Data Domain: Uma introdução à retenção em longo prazo/limpeza do nível da nuvem/coleta de lixo nos Data Domain Restorers (DDRs)

Como iniciar uma limpeza manual do nível de nuvem?

• É possível usar o comando abaixo. Por exemplo:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

Como monitorar uma limpeza do nível de nuvem?

• É possível usar o comando abaixo para verificar se a limpeza em nuvem está em execução. Por exemplo:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• Se a limpeza em nuvem estiver em execução, será possível monitorá-la usando o seguinte comando:

cloud clean watch

A limpeza do nível ativo pode ser executada simultaneamente com a limpeza do nível de nuvem?

• Não. Tanto a limpeza do nível ativo quanto a do nível de nuvem usam as mesmas estruturas de dados compartilhadas internas comuns, o que exige acesso exclusivo.

Como exibir ou alterar um agendamento de limpeza do nível de nuvem?

• É possível usar o comando abaixo para exibir o agendamento atual da limpeza em nuvem. Por exemplo:   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• O comando abaixo é usado para alterar um agendamento. Por exemplo:  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

Como alterar ou exibir o controle de fluxo da limpeza do nível de nuvem?

• Por padrão, o controle de fluxo da limpeza do nível de nuvem é definido como 50%. É possível usar o comando abaixo para redefini-lo à porcentagem padrão de controle de fluxo.

cloud clean throttle reset

• É possível usar o comando abaixo para exibir o controle de fluxo atual da limpeza em nuvem. Por exemplo:   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• É possível usar o comando abaixo para alterar o controle de fluxo da limpeza. Por exemplo:   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

O que o controle de fluxo da limpeza do nível de nuvem controla?

• O controle de fluxo da limpeza do nível de nuvem opera de maneira semelhante ao controle de fluxo da limpeza do nível ativo, na medida em que limita os recursos de E/S e da CPU que a limpeza do nível de nuvem pode usar.
• Ele não controla o fluxo da transferência de rede.

Por que a limpeza do nível de nuvem não libera/exclui o número esperado de objetos?

• A limpeza é sempre considerada uma estimativa. Consulte os seguintes artigos da KB, que descrevem aspectos relacionados a esse tópico e que se aplicam igualmente aos dados que residem no nível de nuvem:  

• Além disso, há mais detalhes específicos relacionados ao modo de implementação do nível de nuvem.
• Vários métodos foram implementados para limitar a quantidade de tráfego de rede para um provedor de armazenamento em nuvem ou objeto, pois isso pode trazer custos associados.
• Como mencionado anteriormente, é necessário ter, no mínimo, 1% de rotatividade de dados para que a limpeza seja executada.
• Ao examinar o file system para procurar arquivos que atendam à política de movimentação de dados, somente as cópias locais dos metadados são verificadas.
• Todos os segmentos mantidos no armazenamento em nuvem ou objeto que contenham apenas dados do usuário são marcados para exclusão assíncrona.
• Todos os segmentos que contêm pelo menos um segmento ativo são ignorados porque o DDOS não combina pequenas quantidades de dados em razão do tráfego de rede envolvido.

Como um usuário determina em que nível um arquivo está localizado?

• Use o seguinte comando para obter um exemplo do resultado gerado:  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

É possível ler ou acessar um arquivo diretamente depois de migrá-lo para o nível de nuvem?

• Isso depende da versão do DDOS em uso junto com o provedor de serviços em nuvem:   

• A restauração direta de arquivos é possível sem a necessidade de, primeiramente, fazer recall de um arquivo. Isso é conhecido como o recurso de "restauração direta" e está limitado ao ECS como o provedor de serviços em nuvem ou objeto.
• Para obter mais detalhes sobre a "restauração direta" do Avamar, consulte o white paper "Avamar Granular or File Level Restore from Data Domain Cloud Tier".
• O recurso Avamar GLR/FLR (Direct Restore) precisa de uma combinação mínima do Avamar 18.1 ou do DDOS 6.1 com o ECS como o provedor de serviços em nuvem. 

• Primeiramente, é necessário fazer recall de um arquivo. Ou seja, os dados são migrados de volta do nível de nuvem para o nível ativo.
• É necessário fazer recall do arquivo do nível de nuvem para o nível ativo usando o comando data-movement recall para permitir qualquer leitura de um arquivo ou modificação em um arquivo que reside no nível de nuvem.
• Caso não ocorra o recall do arquivo em primeiro lugar, qualquer tentativa de ler ou modificar um arquivo que reside no nível de nuvem resultará na exibição de um erro de E/S a quem tentar ler o arquivo que é o aplicativo de backup.
• Alguns aplicativos de backup com reconhecimento de nuvem podem iniciar recalls de arquivo; caso contrário, é necessário fazer recall dos arquivos manualmente.
• A partir do DDOS 7.7 ou versões posteriores:
  • A restauração direta permite que aplicativos não integrados leiam arquivos diretamente do nível de nuvem sem passar pelo nível ativo.
  • Estas são as principais considerações ao optar por usar a restauração direta:
  • A restauração direta não requer um aplicativo integrado e é transparente para aplicativos não integrados.
  • A leitura do nível de nuvem não exige, primeiramente, a cópia para o nível ativo.
  • Há histogramas e estatísticas disponíveis para rastrear leituras diretas do nível de nuvem.
  • A restauração direta é compatível apenas com provedores de serviços em nuvem AWS e ECS.
  • Os aplicativos apresentam latência do nível de nuvem.
  • A leitura direta do nível de nuvem não é otimizada para largura de banda.

De quantos arquivos é possível fazer recall paralelamente?

• O DDOS 6.0 oferece suporte ao enfileiramento e ao recall paralelos de quatro arquivos.
• O DDOS 6.1 oferece suporte ao enfileiramento de 1.000 arquivos e ao recall de 4 arquivos da fila de recall paralelamente.

De acordo com o Guia de administração do Data Domain 7.9:

• Sistemas com 256 GB de memória ou mais podem fazer recall de até 16 arquivos de uma só vez.
• Sistemas com menos de 256 GB de memória podem fazer recall de até oito arquivos de uma só vez.
• As instâncias do DDVE podem fazer recall de até quatro arquivos ao mesmo tempo.

Como fazer recall de um arquivo?

• É possível fazer recall de um arquivo usando o comando abaixo. Por exemplo:   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

Como fazer recall de todos os arquivos de uma MTree?

• Dependendo da versão do DDOS, é possível fazer recall de todos os arquivos da nuvem executando um só comando, como este:   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Consulte o "Guia de referência de comandos do Dell DDOS" da sua versão do DDOS para obter detalhes

Como monitorar uma operação de recall?

• É possível monitorar uma operação de recall usando o comando abaixo ou se um arquivo específico for necessário. Por exemplo:   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

A renomeação de um arquivo causa o recall dele do nível de nuvem para o nível ativo?

• Não. Se um arquivo for renomeado, ele permanecerá no nível atual.

Quais provedores de serviços em nuvem são compatíveis?

•  Dependendo da versão do DDOS em uso, o DDOS oferece suporte aos seguintes provedores de serviços em nuvem:   
• Amazon Web Services (AWS).
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Consulte o guia de administração do DDOS para obter mais informações.

A criptografia é compatível com o nível de nuvem? É necessário licenciá-la?

• Sim, a criptografia é compatível com o nível de nuvem. Ela não exige uma licença adicional, ao contrário da criptografia do nível ativo.
• Será possível configurar isso ao ativar ou modificar o recurso de nuvem posteriormente. 
• No momento da gravação, somente o gerenciador de chaves incorporado é compatível com a criptografia do nível de nuvem e somente é possível usar um algoritmo de criptografia para LTR em todo o sistema.

Quais buckets são criados no armazenamento em objeto dos provedores de serviços em nuvem?

• O DDOS cria três buckets
• Os buckets terminam com a cadeia de caracteres:

'-d0'

'-c0' 

'-m0'

• O bucket que termina com a cadeia de caracteres '-d0' é usado para segmentos de dados.
• O bucket que termina com a cadeia de caracteres '-c0' é usado para dados de configuração.
• O bucket que termina com a cadeia de caracteres '-m0' é usado para metadados.
• Antes do DDOS 6.1, embora três buckets sejam criados, apenas o bucket que termina com '-d0' é usado. No entanto, todos os três buckets são necessários. Portanto, não os remova.

É possível usar nomes de bucket existentes que foram criados anteriormente?

• Não, isso não é possível.

Além dos requisitos de hardware, há outros requisitos obrigatórios necessários antes de configurar a LTR?

• Sim
• Se o ECS for usado, um balanceador de carga será um requisito obrigatório. Sem um balanceador de carga, o Data Domain se comunica com o ECS em um só nó e se desconecta quando várias solicitações são feitas.
• Uma rede de 1 Gb entre o DDR e o provedor de serviços em nuvem

Os certificados são obrigatórios? Em caso afirmativo, quais certificados devem ser usados?

• Isso depende do provedor de serviços em nuvem ou objeto que está sendo usado e da configuração.
• AWS, Virtustream ou Azure exigem um certificado. Consulte o guia de administração do DDOS para obter mais informações.
• Se o ECS estiver configurado usando um endpoint http, um certificado não será necessário.
• Se o ECS estiver configurado usando um endpoint https, será necessário usar um certificado. Como um balanceador de carga é um requisito obrigatório, o certificado exigido é do sistema do balanceador de carga, e não do sistema ECS. Entre em contato com o provedor do balanceador de carga para obter mais detalhes.
• Ao importar o certificado, ele deve estar no formato PEM. Alguns provedores não oferecem o certificado no formato PEM; portanto, antes de importá-lo, é necessário convertê-lo.

Quais topologias de replicação são compatíveis?

• A replicação de conjuntos _não_ é compatível.
• A replicação de diretórios é compatível; no entanto, ela só pode ser usada pela MTree '/data/col1/backup', mas essa MTree não oferece suporte à movimentação de dados.
• A replicação de MTrees é totalmente compatível.
• A replicação de MFR ou VSR é totalmente compatível.

O que se deve considerar ao configurar/inicializar/reinicializar a replicação em um sistema que já tem a LTR configurada?

• O sistema de origem cria um snapshot da MTree (esse snapshot inclui detalhes dos arquivos nos níveis ativos e de nuvem).
• O sistema de origem replica o snapshot para o nível ativo do sistema de destino.
• O snapshot somente será exposto no sistema de destino depois de ser totalmente replicado (e, nesse momento, os arquivos ficam disponíveis no namespace do file system do sistema de destino).
• A execução da movimentação de dados no destino somente ocorre depois da exposição dos arquivos (supondo-se que ele esteja configurado para LTR).
• Como resultado, se o nível ativo do destino não for grande o suficiente para armazenar um snapshot completo da origem, o snapshot nunca será exposto e a replicação não poderá concluir a inicialização.

O que se deve considerar ao configurar a replicação MFR ou VSR em um sistema que já tem a LTR configurada?

• Se for necessário replicar os dados que já foram migrados para o nível de nuvem em um DDR de origem, antes de enviá-los pela rede, ocorrerá o recall automático deles do provedor de serviços em nuvem para o nível ativo.
• O recall de arquivos do nível de nuvem para o nível ativo pode incorrer em um custo ou causar atrasos.

Por que o resultado do comando "file system show space" do Data Domain não reflete o tamanho real do armazenamento em nuvem ou objeto?

• Devido à maneira inerente como o armazenamento em nuvem ou objeto funciona, um sistema Data Domain não tem como consultar o tamanho físico de um dispositivo em nuvem, pois ele pode ser visto como aparentemente infinito.
• No entanto, de um ponto de vista do DDOS, o DDOS precisava desenvolver uma maneira de exibir estatísticas atuais de uso/desduplicação.
• Portanto, usa-se uma de duas abordagens:

1. O tamanho do nível de nuvem é dimensionado pela CLOUDTIER_CAPACITY license
2. O tamanho do nível de nuvem é exibido como um múltiplo de tamanhos de unidade de nível ativo para esse tipo de modelo, dependendo de quantas unidades de nuvem estão configuradas. Consulte o guia de instalação de hardware do modelo em questão para obter mais informações sobre os tamanhos de nível ativo.

Como iniciar o file system se uma unidade de nuvem não estiver disponível?

• Certifique-se de que o file system esteja desativado.
• Desative a unidade de nuvem que não está disponível usando o seguinte comando:

cloud unit disable <cloud unit name>

• Ative o file system.

Se uma unidade de nuvem estiver desativada, como será possível ativá-la?

• Certifique-se de que o file system esteja desativado.
• Ative a unidade de nuvem usando o seguinte comando:

cloud unit enable <cloud unit name>

• Ative o file system.

Por que ainda existem arquivos no file system que residem em uma unidade de nuvem que foi excluída?

•  Se os arquivos não foram removidos de uma MTree antes da exclusão de uma unidade de nuvem, eles continuarão existindo no namespace do file system.
• Dessa forma, o relatório de localização do arquivo mostra que os arquivos fazem parte de uma unidade de nuvem excluída. Por exemplo:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• Ainda é possível ver os arquivos no namespace do file system acessando um compartilhamento CIFS/NFS dessa MTree.
• No entanto, não é possível ler os arquivos porque a unidade de nuvem onde estavam foi excluída.
• Portanto, a única opção é excluir esses arquivos, pois os dados a que faziam referência não existem mais.

É possível alterar o endpoint ou as portas do protocolo de um provedor de serviços em nuvem ECS ou S3 Flexible após a criação de uma unidade de nuvem?

• Isso pode ser necessário, por exemplo, ao mudar de http para https ou vice-versa, migrando para um novo balanceador de carga.
• No momento em que este artigo foi escrito, não há como um administrador do Data Domain realizar essa alteração. Essa funcionalidade está sendo considerada para uma versão futura do DDOS.
• No entanto, as equipes de suporte ou engenharia podem realizá-la.
• Para isso, é o file system precisa ser desativado.
• Se isso for necessário, todas as configurações fora do sistema Data Domain serão realizadas primeiramente porque, depois das alterações, quando o file system for ativado, ele esperará conseguir se comunicar usando o protocolo ou a porta atualizados e ler os buckets ou objetos como fazia anteriormente.