IBM Tivoli Storage Manager – Entendendo o processo de ‘deduplication’ no TSM 6.X
Como entender o processo de ‘dedup’ do TSM e usá-lo corretamente.
A tecnologia de ‘deduplication’ permite uma economia no espaço de armazenamento nas operações de backup. Ao contrário das técnicas tradicionais de compressão de dados, nas quais são aplicados algoritmos capazes de, num escopo limitado, identificar cadeias de dados repetidos, o processo de deduplicação consegue identificar extensamente padrões binários já armazenados em grandes cadeias de dados, eliminando assim a redundância presente entre objetos e arquivos de um ou mais sistemas e atingindo taxas de economia muito maiores. Aqui descrevemos como é implementado o algoritmo de ‘deduplication’ no TSM, quais são as melhores práticas e cuidados que devem ser tomados e os resultados esperados.
Descrição
Antes de detalhar o processo de ‘deduplicação’ adotado no Tivoli Storage Manager 6.X, é importante entender como são classificados as principais tecnologias de ‘deduplicacão’ existentes no mercado e quais são suas caraterísticas que as diferenciam.
Quanto ao local onde é iniciado o processo de ‘deduplicação’:
- Origem (Source): o processo de identificação e eliminação das redundâncias de blocos repetidos é feito na máquina cliente onde estão armazenados os dados primários. Nesse caso há economia no uso de recursos da rede porque os dados já trafegam ‘deduplicados’ até o servidor de backup, em contrapartida esse processo consome tempo de CPU na máquina cliente e pode afetar o desempenho de sistemas de produção.
- Destino (Destination): o processo de identificação e eliminação é feito num servidor ou ‘appliance’ especializado. Nesse caso, os dados trafegam integralmente pela rede; o processo de identificação e eliminação é feito no destino, onde os dados serão armazenados.
Quando será executado o processo de ‘deduplicação’:
- Post-processing ou out-of- band: O processo de identificação e eliminação de redundâncias é feito a posteriori, ou seja, é feito por outro processo que não participa da operação de backup. Nesse caso essa operação é feita logo após as escritas de um operação de backup ou pode ser agendada para períodos de inatividade para que não impacte significativamente o sistema de backup, contudo a operação de backup exigirá um espaço maior, ainda que temporário, para armazenar os dados enquanto não for realizado o processo de deduplicação.
- Real Time ou in-band: O processo de indentificação e eliminação de redundâncias é iniciado e executado no momento que ocorre a operação de backup. Nesse caso os dados são ‘deduplicados’ à medida que processo de backup está ocorrendo, o que pode tornar o processo de backup mais lento devido ao processamento adicional exigido pela ‘deduplicação’, porém com a vantagem de exigir menos espaço para armazenar os dados, já que estes serão armazenados já no estado ‘deduplicado’.
Além das classificações acima, existem vários tipos de implementações de algoritmos de ‘deduplicação’. A maioria dos algoritmos está baseado no cálculo de ‘hashes’, funções matemáticas que produzem um identificador dos dados de forma que eles sejam representados unicamente. Idealmente, a probabilidade de repetição de ‘hash’ para dados diferentes deve ser desprezível mesmo para um conjunto de dados grande. O Tivoli Storage Manager utiliza essa técnica quando é utilizado ‘deduplicação’ em um storage pool configurado com essa função no TSM server. A operação pode ser agendada para que o
processo seja feito em lote durante períodos de inatividade. Em resumo, pode-se dizer que o processo de deduplicação do Tivoli Storage Manager 6.X pode ser classificado como um processo feito no destino, em modo ‘out-of-band’ e baseado em ‘hash’. Versões futuras do Tivoli Storage Manager poderão adicionar outros métodos como, por exemplo, iniciar o processo de identificação de redundâncias na origem. O TSM usa, em cada bloco de tamanho variável, denominado ‘chunk’, o algoritmo SHA-1 (de 160 bits) para calcular o ‘hash’ que o identifica unicamente. Considerando uma distribuição uniforme do conteúdo dos blocos, existe uma chance de 50% de ter um bloco diferentes com o mesmo ‘hash’ quando o número total de blocos armazenados é de 2^80. Como o TSM está limitado a armazenar 2^64 blocos na versão atual, as chances de uma instalação ter um problema com blocos diferentes com o mesmo ‘hash’ (geralmente chamada de ‘colisão’) será menor . Além disso, como os blocos são de tamanhos variáveis, essa probabilidade deve ser levada em conta para cada tamanho de bloco (no TSM, de 2 KiB a 4 MiB), portanto a probabibilidade de uma colisão se torna ainda menor. Apenas para fins de comparação, a probabilidade da ocorrência de erro de leitura irrecuperável causado pela falha em algoritmo de ECC de um
disco rígido Fibre Channel é de aproximadamente 1 setor a cada 2^53 (http://www.seagate.com/docs/pdf/datasheet/disc/ds_cheetah_15k_6.pdf (este link reside fora de ibm.com)). Além disso, há um proteção adicional para detecção de colisões no objeto, já que um segundo ‘hash’ MD5 é calculado em relação a todo o objeto armazenado
Planejando ativar ‘dedup’ no Tivoli Storage Manager
Algumas considerações devem ser feitas antes de ativar esse recurso no TSM:
- Considere ativar ‘deduplicação’ se:
- Os dados serão armazenados em disco por longos períodos de tempo sem que haja migração para fita;
- Dados com alta taxa de redundância estão sendo protegidos como, por exemplo, arquivos de sistemas operacionais ou servidores de arquivos;
- Recursos de CPU e I/O estão disponíveis no TSM Server para absorver o aumento de processamento durante o processo de identificação de redundâncias no storage pool que tem ‘deduplicação’ ativada. Tipicamente, o número de processos de ‘deduplicação’ que podem ser executados simultaneamente deve ser igual ao número de processadores ou núcleos disponíveis no TSM Server. Além disso, o uso de discos lentos pode afetar o tempo de recuperação, portanto recomenda-se que sejam usados subsistemas de disco capazes de distribuir a carga em diversos discos físicos para aumentar a vazão total no subsistema de discos.
- Evite ativar ‘deduplicação’ se:
- Os dados são de missão crítica, ou seja, dados cujo tempo de recuperação não pode ser afetado por blocos não-contíguos quando se usa o ‘dedup’;
- Não houve um dimensionamento correto do TSM Server para suportar a carga adicional do processamento relacionado ao processo de ‘dedup’
- Dados criptografados ou que não possuem redundância entre si.
- Arquivos menores que 2 KiB não são elegíveis para deduplicação. Além disso, arquivos menores que 100KiB geralmente apresentam uma demora maior durante um ‘restore’ quando deduplicadas, portanto cuidado deve ser tomado quando estas são enviadas para um storage pool com ‘deduplicação’ ativado.
Como estimar o espaço necessário para armazenar os dados ‘deduplicados’:
* A maneira mais indicada é testar a massa de dados num sistema de testes e depois desativá-lo após determinar quais serão os requerimentos de espaço.
* Uma maneira alternativa ao descrito acima é fazer um backup do seu ‘storage pool’ para um ‘copy storage pool’ que tem ativado o data deduplication para estimar a economia de espaço. Note que essa técnica pode aumentar o tamanho do DB do TSM.
Os passos são os seguintes:
- Crie um ‘copy storage pool’ usando um devclass do tipo FILE.
- Faça um backup do ‘storage pool’ para o ‘copy storage
- Execute o IDENTIFY DUPLICATES nos volumes do copy storagepool.
- Quando o processo IDENTIFY DUPLICATES atingir o estado ‘idle’, ajuste o ‘reclamation threshold’para 1%.
- Depois do término do ‘reclamation’, use o commando ‘q stgpool’ para o ‘copy stgpool’ para checar o tamanho do copy stgpool e veja quanto foi o ganho de espaço sobre o outro stgpool.
- Se os resultados foram satisfatórios, atualize o storage pool primário (se este for do tipo FILE) ou mova os dados para um novo stgpool se ele for do tipo (DISK).
Como estimar o espaço necessário em logs de transação do TSM:
* Durante o processo ‘IDENTIFY DUPLICATES’, monitore o número de logs arquivados para determinar os requerimentos sobre o tamanho dos logs.
Como fazer o dimensionamento do DB do TSM para ‘deduplicação’:
* Para cada ‘chunk’ ou bloco de dados do TSM são adicionados 500 bytes de overhead para armazenar metadados sobre a deduplicação. Como o tamanho médio de um chunk é de 256 KiB, pode-se dividir o tamanho de um stgpool e calcular o quanto de espaço adicional será necessário no DB do TSM facilmente.
Exemplo:
1. Tamanho do storage pool = 1 TiB
2. Tamanho médio do chunk = 256 KiB
3. Ovehead de metadados no DB = (1000000000/256)*500 = 20 GiB
Ativando ‘dedup’ no Tivoli Storage Manager 6.X
A ativação dessa característica pode ser feita apenas em storage pools do tipo ‘FILE’. Pode-se criar um storage pool sem que essa característica esteja ativada e depois ativá-la com o comando ‘UPDATE STGPOOL’.
Abaixo estão os passos recomendados para controlar essa operação no TSM:
- Para criar/atualizar um stgpool ‘FILE’ com essa característica, as seguintes opções foram adicionadas nos comandos
‘DEFINE/UPDATE STGPOOL’:
DEDUPlicate = [ Yes | No ]
Habilita o ‘dedup’, o default é ‘No’
&
IDENTIFYPRocess = nn
Número total de processos que serão usados para identificar as redundâncias nesse storage pool, o valor default é ‘1’
Caso o IDENTIFYProcess for maior que zero, o processo de identificação será executado continuamente até que o processo seja cancelado com o comando ‘CANCEL’. Também é possível alterar novamente o parâmetro para zero ou executar comando ‘IDENTIFY DUPLICATES’ ajustando os processos para zero para parar a execução após o término das operações correntes. É recomendado executar esse processo manualmente para que seja feito apenas em períodos de inatividade, portante ajuste esse parâmetro como ‘0’ e use o comando ‘IDENTIFY DUPLICATES’ descrito abaixo em um schedule administrativo do TSM.
Exemplo:
UPDATE STGPOOL FILE DEDUP=YES IDENTIFY=0 RECLAIM=6
2. Execute uma vez por dia o processo de identificação de redundâncias em períodos de baixa atividade do servidor. Note que esse processo não irá liberar o espaço nos volumes até que você execute a operação de ‘RECLAIM’.
Exemplo:
IDENTIFY DUPLICATES FILEPOOL NUMPR=2
Para verificar o progresso pode-se usar o comando ‘Q PROC’
Exemplo:
-------- -------------------- -------------------------------------------------
283 Identify Duplicates Storage Pool FILEPOOL, Volume /tsmpool2/00006664.
BFS, Files Processed: 2000, Duplicate
Extents Found: 344, Duplicate Bytes Found:
3,238,123 Current Physical File (bytes):
2,626,676,296.
Status: Processing
284 Identify Duplicates Storage Pool FILEPOOL, Volume None, Files
Processed: 4543, Duplicate Extents Found: 364,
Duplicate Bytes Found: 7,238,123,
Current Physical File (bytes): None.
Status: Idle
ATENÇÃO: O processo de ‘RECLAIM’ só poderá ser executado após um operação de backup do storage pool (‘BACKUP STGPOOL’ para um outro stgpool que não esteja com o parâmetro ‘dedup’ = yes. Essa é uma boa prática que visa evitar perda de dados em casos onde hajam ‘falsos positivos’ durante o processo de indentificação de redundâncias. Se você quiser desabilitar esse comportamento para que o ‘RECLAIM’ aconteça mesmo sem o backup do storagepool é possível utilizar-se da opção ‘SETOPT DEDUPREQUIRESBACKUP NO’
3. Após a janela estipulada para o processamento de identificação de redundâncias terminar, ajuste o parâmetro de processos do comando IDENTIFY DUPLICATES para zero.
Exemplo:
IDENTIFY DUPLICATES FILEPOOL NUMPR=0
4. Uma vez idenficadas as redundâncias, execute um operação de ‘RECLAIM’ no storage pool para que seja feita a consolidação do espaço liberado no passo anterior, com isso os volumes vazios serão liberados para a reutilização. O comando ‘RECLAIM STGPOOL’.
Exemplo:
RECLAIM STGPOOL DDPOOL
Verificando os ganhos com ‘dedup’ no Tivoli Storage Manager 6.X
Para verificar os ganhos obtidos, use o comando query stgpool antes e depois do processo de ‘reclaim’ (passo 4 da seçãoanterior)
Antes:
TSM> Q STGPOOL
Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
FILEPOOL DISK- 143 G 100
Depois:
TSM> Q STGPOOL
Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
FILEPOOL DISK- 143 G 35
Nenhum comentário:
Postar um comentário