No post
anterior, citei os requisitos mínimos
de hardware e software para o servidor TSM. Falei também a respeito das
duas formas de dimensionamento de
espaço para acomodação do Banco de Dados – DB2 (pelo número máximo de arquivos armazenados no servidor ou pela
capacidade dos conjuntos de armazenamento).
Hoje,
abordarei o dimensionamento de espaço reservado para os Logs de recuperação.
No TSM, o termo log de
recuperação compreende:
- Active log (Log Ativo);
- Archive log;
- Active log mirror;
- Archive log failover archive.
A quantidade de espaço necessária para o log de recuperação
depende de diversos fatores, incluindo, por exemplo, a quantidade de atividade
dos clientes com o servidor.
Espaço de Log Ativo e Archive Log
No dimensionamento de espaço para logs ativos e archive logs,
sempre inclua algum espaço extra para contingências, tais como: cargas de
trabalho pesadas ocasionais e failovers.
A partir da V6.1, o log ativo pode ter um tamanho máximo de 128
GB.
O tamanho do log de archive é limitado ao tamanho do sistema de
arquivos no qual está instalado.
Utilize as seguintes boas
práticas ao estimar o tamanho do log ativo e archive log:
· O tamanho inicial sugerido para o log
ativo é de 16 GB.
· O log ativo deve ser grande o suficiente
para a quantidade de atividade simultânea que o servidor geralmente manipula.
Forneça espaço extra ao log ativo para que possa ser usado se necessário. Vinte
por cento é uma quantidade razoável de espaço extra a considerar.
· Monitore
o espaço de log usado e ativo disponível e ajuste se necessário.
· Considere que o diretório que armazena o
log ativo seja tão grande ou maior que o tamanho do log ativo. Um diretório
maior que o log ativo pode acomodar failovers, caso ocorram.
· Certifique-se de que o sistema de arquivos
que contém o diretório de log ativo possua pelo menos 8 GB de espaço livre para
os requisitos de movimento de log temporário.
· O tamanho inicial sugerido para o log de
archive é de 48 GB (3x Active Log).
O diretório de log de archive deve ser grande o suficiente para
conter os arquivos de log desde o backup completo anterior.
Por exemplo, se você executar um backup completo do banco de
dados todos os dias, o diretório de log do archive deverá ser grande o
suficiente para conter os arquivos de log para toda a atividade do cliente que
ocorrer durante 24 horas.
Para recuperar espaço, o servidor exclui arquivos de log de
archive obsoletos após um backup completo do banco de dados. Se o diretório de log de archive ficar cheio e um diretório
para logs de failover de archive não existir, os arquivos de log permanecerão
no diretório de log ativo. Essa condição pode fazer com que o diretório de log
ativo fique cheio e, consequentemente, pare o servidor.
- Monitore a utilização de archive log e o espaço no diretório e ajuste caso necessário.
Se o espaço no diretório de archive log ficar cheio, pode
acontecer o seguinte problema:
- O servidor pode não executar backups completos do banco de dados.
Verifique se outros aplicativos não estão gravando no diretório
de archive log, consumindo o espaço requerido. Nunca compartilhe o espaço do
archive log. Cada servidor ou instância
deverá ter seu local de armazenamento (archive log) separado.
Todas as estimativas que serão
demonstradas a seguir foram retiradas do IBM Tivoli Storage Manager para Linux: Guia de Instalação
1 - Estimando tamanhos de log ativos e de archive para operações
básicas de armazenamento de clientes (backup, archive e gerenciamento de
espaço).
O espaço de log deve ser suficiente para manipular todas as
transações de armazenamento que estiverem em andamento de uma só vez.
Para determinar os tamanhos dos logs ativos e de archive para
operações básicas de armazenamento de clientes, use o seguinte cálculo:
número de clientes
x
arquivos armazenados durante
cada transação
x
espaço de log necessário
para cada arquivo
Item
|
Valores de exemplo
|
Descrição
|
Número máximo de nós clientes que efetuam backup, archive ou
migração de arquivos simultaneamente a qualquer momento.
|
300
|
O número de nós clientes que fazem backup, archive ou migram
arquivos no mesmo período
|
Arquivos armazenados durante cada transação
|
4096
|
O valor padrão da opção do servidor TXNGROUPMAX é 4096.
|
O espaço de log requerido para cada arquivo
|
3053 bytes
|
O valor de 3053 bytes para cada arquivo em uma transação
representa os bytes do log necessários ao efetuar backup de arquivos de um
cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
|
Log ativo
|
19.5 GB
|
Use o cálculo a seguir para determinar o tamanho do log
ativo.
1 GB = 1.073.741.824 bytes.
(300 clientes x 4096 arquivos
armazenados durante cada transacao x 3053 bytes para cada arquivo) ÷
1.073.741.824 bytes = 3.5 GB + tamanho inicial sugerido de 16 GB: 3.5 + 16 = 19.5 GB
|
Archive log
|
58.5 GB
|
Devido ao requisito de poder armazenar logs de archive em
três ciclos de backup do banco de dados do servidor, multiplique a estimativa
para o log ativo por 3 para estimar o requisito de log de archive total.
3.5 x 3 = 10.5 GB
+
tamanho inicial sugerido de 48 GB:
10.5 + 48 = 58.5 GB
|
Sempre monitore seus logs e ajuste seu tamanho se necessário.
| ||
2 - Estimando tamanhos de log ativos e de archive para clientes
que usam diversas sessões
Se a opção do cliente RESOURCEUTILIZATION for configurada para um valor maior que o
padrão, a carga de trabalho simultânea para o servidor aumentará.
Para determinar os
tamanhos dos logs ativo e de archive quando os clientes usarem diversas sessões use o seguinte cálculo:
número de clientes
x
sessões para cada cliente
x
arquivos armazenados durante cada transação
x
espaço de log necessário para cada arquivo
Item
|
Valores de exemplo
|
Descrição
|
Número máximo de nós clientes que efetuam backup, archive ou
migração de arquivos simultaneamente a qualquer momento.
|
300
|
O número de nós clientes que fazem backup, archive ou migram
arquivos no mesmo período
|
Sessões possíveis para cada cliente
|
3
|
A configuração da opção do cliente RESOURCEUTILIZATION é maior que o padrão. Cada sessão do cliente executa um
máximo de três sessões em paralelo.
|
Arquivos armazenados durante cada
Transação
|
4096
|
O valor padrão da opção do servidor TXNGROUPMAX é 4096.
|
O espaço de log requerido para cada
Arquivo
|
3053 bytes
|
O valor de 3053 bytes para cada arquivo em uma transação
representa os bytes do log necessários ao efetuar backup de arquivos de um
cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
|
Log ativo
|
26.5 GB
|
Use o cálculo a seguir para determinar o tamanho do log
ativo.
1 GB = 1.073.741.824 bytes.
(300 clientes x 3 sessoes para
cada cliente x 4096 arquivos armazenados durante cada transacao x 3053 bytes
para cada arquivo) ÷ 1.073.741.824 = 10.5 GB
+
tamanho inicial sugerido de 16 GB:
10.5 + 16 = 26.5 GB
|
Archive log
|
79.5 GB
|
Devido ao requisito de poder armazenar logs de archive em
três ciclos de backup do banco de dados do servidor, multiplique a estimativa
para o log ativo por 3 para estimar o requisito de log de archive total.
10.5 x 3 = 31.5 GB
+
tamanho inicial sugerido de 48 GB:
31.5 + 48 = 79.5 GB
|
Sempre monitore seus logs e ajuste seu tamanho se necessário.
|
||
3 - Estimando tamanhos de log ativos e de archive para operações
simultâneas de gravação
Se as operações de backup do cliente usarem conjuntos de
armazenamentos configurados para gravação simultânea, a quantidade de espaço de
log requerida para cada arquivo aumenta.
O espaço de log requerido para cada arquivo aumenta
aproximadamente 200 bytes para cada conjunto de armazenamentos de cópias que é
usado para uma operação de gravação simultânea. No exemplo a seguir, os dados
são armazenados em dois conjuntos de armazenamentos de cópias, além de um
conjunto de armazenamentos primário. O tamanho do log estimado aumenta em 400
bytes para cada arquivo. Se você usar o valor sugerido de 3053 bytes de espaço
de log para cada arquivo, o número total de bytes requerido será de 3453.
Item
|
Valores de exemplo
|
Descrição
|
Número máximo de nós clientes que efetuam backup, archive ou
migração de arquivos simultaneamente a qualquer momento.
|
300
|
O número de nós clientes que fazem backup, archive ou migram
arquivos no mesmo período
|
Arquivos armazenados durante cada transação
|
4096
|
O valor padrão da opção do servidor TXNGROUPMAX é 4096.
|
O espaço de log requerido para cada arquivo
|
3453 bytes
|
3053 bytes mais 200 bytes para cada conjunto de
armazenamentos de cópias.
O valor de 3053 bytes para cada arquivo em uma transação
representa os bytes do log necessários ao efetuar backup de arquivos de um
cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
|
Log ativo
|
20 GB
|
Use o cálculo a seguir para determinar o tamanho do log
ativo.
1 GB = 1.073.741.824 bytes.
(300 clientes x 4096 arquivos
armazenados durante cada transacao x 3453 bytes para cada arquivo) ÷
1.073.741.824 bytes = 4 GB
+
tamanho inicial sugerido de 16 GB:
4 + 16 = 20 GB
|
Archive log
|
60 GB
|
Devido ao requisito de poder armazenar logs de archive em
três ciclos de backup do banco de dados do servidor, multiplique a estimativa
para o log ativo por 3 para estimar o requisito de log de archive total.
4 x 3 = 12 GB
+
tamanho inicial sugerido de 48 GB:
12 + 48 = 60 GB
|
Sempre monitore seus logs e ajuste seu tamanho se necessário.
|
||
4 - Estimando tamanhos de log ativos e de archive para operações
básicas de armazenamento de clientes e operações do servidor
Migração de dados no armazenamento do servidor, processos de
identificação para deduplicação de dados, reclamação e expiração podem ser
executados simultaneamente com operações de armazenamento de clientes.
Igualmente, tarefas administrativas como comandos administrativos ou
consultas SQL de clientes administrativos também podem ser executados
simultaneamente com operações de armazenamento de clientes.
Operações do servidor e tarefas administrativas que são
executadas simultaneamente podem aumentar o espaço de log ativo requerido.
Por exemplo, a
migração de arquivos do conjunto de armazenamentos de acesso aleatório (DISK)
para um conjunto de armazenamentos de disco de acesso sequencial (FILE) usa
aproximadamente 110 bytes de espaço de log para cada arquivo que é migrado. Suponha que você tenha 300 clientes de
backup-archive e cada um deles faça backup de 100.000 arquivos cada noite. Os
arquivos são inicialmente armazenados no DISK e, em seguida, migrados para um
conjunto de armazenamentos FILE. Para estimar a quantidade de espaço de log
ativo requerido para a migração de dados, use o seguinte cálculo: o número de clientes do
cálculo representa o número máximo de nós clientes que realiza backup, archive
ou migra arquivos simultaneamente a qualquer momento.
300 clientes x 100.000 arquivos
para cada cliente x 110 bytes = 3.1 GB
Por fim, inclua este valor na estimativa para o tamanho do log ativo
calculado para operações básicas de armazenamento de clientes.
5 - Estimando tamanhos de log do archive com backups completos
de banco de dados
O servidor Tivoli Storage Manager exclui arquivos
desnecessários do log de archive somente quando ocorre um backup completo do
banco de dados.
Consequentemente, quando você estima o espaço requerido para o
log de archive, você também deve considerar a frequência dos backups completos
do banco de dados.
Por exemplo, se
ocorrer um backup completo do banco de dados uma vez por semana, o espaço de
log do archive deverá conter as informações no log
de archive para uma semana inteira.
Item
|
Valores de exemplo
|
Descrição
|
Número máximo de nós clientes que efetuam backup, archive ou
migração de arquivos simultaneamente a qualquer momento.
|
300
|
O número de nós clientes que fazem backup, archive ou migram
arquivos no mesmo período
|
Arquivos armazenados durante cada transação
|
4096
|
O valor padrão da opção do servidor TXNGROUPMAX é 4096.
|
O espaço de log requerido para cada arquivo
|
3453 bytes
|
3053 bytes mais 200 bytes para cada conjunto de
armazenamentos de cópias.
O valor de 3053 bytes para cada arquivo em uma transação
representa os bytes do log necessários ao efetuar backup de arquivos de um
cliente do Windows em que os nomes do arquivo sejam de 12 - 120 bytes.
|
Log ativo
|
20 GB
|
Use o cálculo a seguir para determinar o tamanho do log
ativo.
1 GB = 1.073.741.824 bytes.
(300 clientes x 4096 arquivos
armazenados durante cada transacao x 3453 bytes para cada arquivo) ÷
1.073.741.824 bytes = 4 GB
+
tamanho inicial sugerido de 16 GB:
4 + 16 = 20 GB
|
Archive log
|
60 GB
|
Devido ao requisito de poder armazenar logs de archive em
três ciclos de backup do banco de dados do servidor, multiplique a estimativa
para o log ativo por 3 para estimar o requisito de log de archive total.
4 x 3 = 12 GB
+
tamanho inicial sugerido de 48 GB:
12 + 48 = 60 GB
|
Archive log: Com um banco de dados completo toda semana
|
132 GB
|
Multiplique o resultado pelo número de dias entre os backups
completos do banco de dados:
(4 GB x 3 ) x 7 = 84 GB
Aumente essa quantidade no tamanho inicial sugerido de 48 GB:
84 + 48 = 132 GB
|
Sempre monitore seus logs e ajuste seu tamanho se necessário.
|
||
6 - Estimando tamanhos de logs ativos e de archive para
operações de deduplicação de dados
Se você deduplicar dados, deverá considerar seus efeitos nos
requisitos de espaço para logs ativos e de archive.
Os fatores a seguir afetam requisitos para o espaço de logs
ativos e de archive:
A quantidade de dados deduplicados
Os efeitos da deduplicação de dados no log ativo e no espaço de
log do archive dependem da porcentagem de dados elegíveis para deduplicação.
Se a porcentagem de dados que pode ser deduplicada for
relativamente alta, mais espaço de log será requerido.
O tamanho e o número de extensões
Aproximadamente 1.500 bytes de espaço de log ativo são requeridos
para cada extensão identificada por um processo de identificação de
deduplicações.
Por exemplo, se 250.000 extensões forem identificadas por um
processo de identificação de deduplicações, o tamanho estimado do log ativo
será 358 MB:
250.000 extensões identificadas
durante cada processo x 1.500 bytes para cada extensão = 358 MB
Ex: 300 clientes de backup-archive fazem backup de 100.000
arquivos a cada noite. Essa atividade cria uma carga de trabalho de 30.000.000
de arquivos. O tamanho médio de extensões de cada arquivo é dois. Assim, o
número total de extensões é 60.000.000 e o requisito de espaço para o log de
archive é de 84 GB:
60.000.000 de extensões x 1.500
bytes para cada extensao = 84 GB
Um processo de identificação de duplicações opera em agregados
de arquivos. Um agregado consiste em arquivos que são armazenados em uma
determinada transação, conforme especificado pela opção do servidor TXNGROUPMAX. Suponha que a opção do servidor TXNGROUPMAX seja configurada para o padrão 4096. Se o número médio de
extensões para cada arquivo for dois, o número total de extensões em cada
agregado será 8192 e o espaço requerido para o log ativo será de 12 MB:
8192 extensões em cada agregado x
1500 bytes para cada extensão = 12 MB
Sincronização e número de processos de identificação de
deduplicações
A sincronização e o número de processos de identificação de
deduplicações também afetam o tamanho do log ativo. Usando o tamanho de log
ativo de 12 MB que foi calculado no exemplo anterior, o carregamento simultâneo
no log ativo será de 120 MB se 10 processos de identificação de deduplicações
estiverem em execução em paralelo:
12 MB para cada processo x 10
processos = 120 MB
Tamanho do arquivo
Arquivos grandes que são processados para identificação
duplicada também podem afetar o tamanho do log ativo. Por exemplo, suponha que
um cliente de backup-archive faça backup de uma imagem do sistema de arquivos
de 80 GB. Esse objeto pode ter um número elevado de extensões duplicadas se,
por exemplo, for feito backup, de forma incremental, dos arquivos incluídos na
imagem do sistema de arquivos. Por exemplo, suponha que uma imagem do sistema
de arquivos tenha 1,2 milhões de extensões duplicadas. Os 1,2 milhões de
extensões deste arquivo grande representam uma única transação para um processo
de identificação de deduplicações. Por conseguinte, o espaço total no log ativo
que é requerido para este único objeto é de 1.7 GB:
1.200.000 de extensões x 1.500
bytes para cada extensão = 1.7 GB
Se ocorrerem
outros processos menores de identificação de deduplicação ao mesmo tempo em que
o processo de identificação de deduplicação para um único objeto grande, o log
ativo talvez não tenha espaço suficiente. Por
exemplo, suponha que o conjunto de armazenamentos esteja ativado para deduplicação.
O conjunto de armazenamentos possui uma mistura de dados, incluindo muitos
arquivos relativamente pequenos que vão de 10 KB a várias centenas de KB. O
conjunto de armazenamentos também possui poucos objetos grandes que têm uma
alta porcentagem de extensões duplicadas.
Para levar em conta não apenas os requisitos de espaço, mas
também a sincronização e duração de transações simultâneas, aumente o tamanho
estimado do log ativo em um fator de dois. Por exemplo, suponha que seus
cálculos para os requisitos de espaço sejam de 25 GB (23.3 GB + 1.7 GB para
deduplicação de um objeto grande). Se os processos de deduplicação estiverem em
execução simultaneamente, o tamanho sugerido do log ativo será de 50 GB. O
tamanho sugerido do log de archive é de 150 GB.
Item
|
Valores de exemplo
|
Descrição
|
Tamanho do maior objeto único para deduplicação
|
800 GB
|
A granularidade de processamento para deduplicação está no
nível do arquivo. Assim, o maior arquivo único para deduplicação representa a
maior transação e um carregamento correspondentemente grande nos logs ativos
e de archive.
|
Tamanho médio das extensões
|
256 KB
|
Os algoritmos de deduplicação usam um método de bloqueio
variável. Nem todas as extensões deduplicadas para um determinado arquivo são
do mesmo tamanho, assim, esse cálculo presume um tamanho médio de extensão.
|
Extensões para um determinado arquivo
|
3.276.800 bits
|
Usando o tamanho médio de extensão, esses cálculos
representam o número total de extensões para um determinado objeto.
O cálculo a seguir foi usado para diversas transações e um
objeto de 800 GB:
(800 GB ÷ 256 KB) = 3.276.800
bits
|
Log ativo: Tamanho sugerido requerido para a deduplicação de
um único objeto grande durante um processo único de identificação de
deduplicação
|
4.5 GB
|
O tamanho estimado do espaço de log ativo que é requerido
para essa transação.
|
Log ativo: Tamanho total sugerido
|
71.6 GB
|
Após considerar outros aspectos da carga de trabalho no
servidor além da deduplicação, multiplique a estimativa existente por um
fator 2. Nesses exemplos, o espaço de log ativo requerido para deduplicar um
único objeto grande é considerado juntamente com estimativas anteriores para o tamanho de log ativo
requerido.
O cálculo a seguir foi usado para diversas transações e um
objeto de 800 GB:
(23.3 GB + 4.5 GB) x 2 = 55.6 GB
Aumente essa quantidade no tamanho inicial sugerido de 16 GB:
55.6 + 16 = 71.6 GB
|
Log de archive: Tamanho sugerido
|
214.8 GB
|
O tamanho estimado do log ativo multiplicado por um fator de
3.
O cálculo a seguir foi usado para um objeto de 800 GB:
55.6 GB x 3 = 166.8 GB
Aumente essa quantidade no tamanho inicial sugerido de 48 GB:
166.8 + 48 = 214.8 GB
|
Sempre monitore seus logs e ajuste seu tamanho se necessário.
|
||
Espaço do Espelho de Log Ativo
O log ativo pode ser espelhado para que a cópia espelhada seja
usada se os arquivos de log ativos não puderem ser lidos. Observa-se, porém,
que poderá haver somente um espelho de log ativo.
A criação de um espelho de log é uma opção sugerida. Se você
aumentar o tamanho do log ativo, o tamanho de espelho do log ativo será
aumentado automaticamente. O espelhamento de log pode
afetar o desempenho devido à atividade duplicada de I/O requerida para manter o
espelho.
O espaço adicional que o espelho de log requer é outro fator a
considerar ao decidir se um espelho de log deve ser criado.
Se o diretório de log do espelho ficar cheio, o servidor emitirá mensagens de erro para o log da atividade
e para o db2diag.log, mas isso não irá causar a parada do servidor.
Espaço de Failover Archive Log
O failover archive log é usado pelo servidor caso o
diretório do archive log fique sem espaço.
Especificar um diretório de log de archive de
failover pode evitar problemas que ocorrem se o log de archive ficar sem
espaço.
Se o archive log e o failover archive log ficarem cheios, os
dados permanecerão no diretório de log ativo. Essa condição pode fazer com que
o log ativo fique cheio, o que causa a parada do servidor.
Bom senhores (as), mais
um post enorme, eu sei, e peço desculpas por isso, mas como disse anteriormente
este é um assunto que não permite abreviações.
No nosso próximo
encontro estarei finalizando a etapa de Planejamento com os seguintes tópicos:
- Monitorando a utilização de
espaço para o banco de dados e os logs de recuperação;
- Boas Práticas de Nomenclatura do Servidor.
Até mais e um grande
abraço.
Nenhum comentário:
Postar um comentário