Este Guia rápido fornece as etapas necessárias para implementar a Dededuplicação Global e de Storage com o Bacula Enterprise.
As organizações de TI estão constantemente sendo desafiadas a fornecer soluções de alta qualidade com um custo total de propriedade reduzido. Um desses desafios é a quantidade crescente de dados para backup, juntamente com o tempo limitado para executar tarefas de backup (janela de backup). O Bacula Enterprise oferece várias maneiras de enfrentar esses desafios, sendo um deles a Desduplicação Global Endpoint, que minimiza a transferência de rede e o tamanho do volume Bacula usando tecnologia de desduplicação.
A desduplicação pode reduzir significativamente o espaço em disco necessário para armazenar seus dados. Nos melhores casos, dependendo da deduplicabilidade dos dados de backup, isso pode reduzir o espaço em disco necessário em 99%.
O Plugin Bacula já compacta os dados após a deduplicação, portanto, você deve evitar o backup de dados compactados, o que geralmente rende uma baixa taxa de deduplicação.
A deduplicação pode reduzir significativamente a largura de banda de rede necessária, porque ambas as extremidades podem trocar referências em vez dos dados reais em si. Funciona quando o destino já tem uma cópia dos blocos originais. A desduplicação funciona para backups, mas também ao fazer uma restauração.
Manipular referências em vez dos dados pode acelerar a maior parte do processamento dentro do Daemon de Armazenamento. Por exemplo, os recursos do Bacula como Cópia/Migração e o Virtual Full podem ser até 1.000 vezes mais rápidos.
Recomendações
Para realizar uma desduplicação eficiente e rápida, o Daemon de armazenamento precisará de energia adicional da CPU (para computar códigos hash e compactação), além de RAM adicional (para consultas rápidas de código de hash).
Para um desempenho eficaz, o índice de desduplicação deve ser armazenado em SSDs, pois o índice terá muitos acessos aleatórios e muitas atualizações. Normalmente, são necessários 10 GB de 1 TB de backups.
Para armazenamento com deduplicação, prefira sistemas de arquivos que verifiquem blocos, como ZFS e usando a tecnologia RAID de hardware. Se você não for capaz de usar o ZFS, recomendamos usar o XFS. A razão para isso é que, se o seu disco desenvolver um bloco defeituoso, em vez de danificar um arquivo (que pode ser armazenado várias vezes), ele poderá danificar todos os arquivos (dúzia e centenas) que contiverem o mesmo bloco de dados.
A desduplicação não é implementada para dispositivos de fita. Funciona apenas com backups baseados em disco.
A Desduplicação Global é realizada pelo software Bacula. Se você quiser usar a desduplicação fornecida pelo hardware ou pelo sistema de arquivos, consulte o white paper do produto do Driver de Volumes Alinhados do bacula.
Instalação
O pacote de instalação do Dedup Driver está disponível para RHEL, CentOS, Debian, Ubuntu, Suse e para a maioria das outras distribuições do Bacula Enterprise Linux suportadas. Ele deve ser instalado na mesma máquina Bacula Storage Daemon. Por exemplo.:
rpm -ivh bacula-enterprise-dedup-plugin-8.10.1-1.el7.x86_64.rpm
Reinicie o bacula-sd e verifique se o driver está carregado com um comando de armazenamento de status.
Storage Daemon Configuration (bacula-sd.conf)
Conforme a Figura 1, as diretivas Dedup Directory e Dedup Index Directory devem ser configuradas para uso do Dedup Global. Pelo bconsole, vá ao Módulo de Configuração, botão Storage Daemon (meio da tela) e edite o Recurso Storage Daemon:
Figura 1. Configuração do Recurso Storage Daemon do bacula-sd.conf pelo BWeb
Pelo texto, seu bacula-sd.conf deve ser editado para incluir as diretivas:
Storage {
Name = my-sd
Working Directory = /opt/bacula/working
Pid Directory = /opt/bacula/working
Subsys Directory = /opt/bacula/working
Plugin Directory = /opt/bacula/plugins
Dedup Directory = /mnt/bacula/dedup/containers
Dedup Index Directory = /mnt/SSD/dedup/index
}
Dedup Directory = <caminho do diretório>. Os dados de backup dos contêineres serão armazenados no diretório Dedup. Esse diretório é comum para todos os dispositivos Dedup configurados em um Daemon de armazenamento e deve ter uma grande quantidade de espaço livre para hospedar dados desduplicados de backups. Aconselhamos você a usar o LVM em sistemas Linux para garantir que você possa estender o espaço neste diretório. Se você alterar a diretiva do Dedup Directory, seus arquivos deverão ser movidos para o novo diretório.
Dedup Index Directory = <diretório-caminho>. Os índices serão armazenados no diretório do índice Dedup. Os índices terão muitos acessos aleatórios de atualização e se beneficiarão de unidades rápidas, como unidades SSD.
Por padrão, o Bacula Storage Daemon é executado com o usuário do sistema operacional bacula. Certifique-se de que tenha permissão ao montar esses diretórios ou se forem discos locais:
chown bacula /mnt/bacula/dedup/containers chown bacula /mnt/SSD/dedup/index
Ainda no bacula-sd.conf, também é necessário criar um novo Autochanger especial e Dispositivos que usarão o driver de deduplicação:
Autochanger {
Name = "Dedup"
ChangerCommand = "/dev/null"
ChangerDevice = "/dev/null"
Device = "DedupDisk1","DedupDisk2"
}
Device {
Name = "DedupDisk1"
Archive Device = /mnt/bacula/dedup/volumes
Media Type = DedupVolume1
Device Type = Dedup
LabelMedia = yes
Random Access = Yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Job = 5
}
Device {
Name = "DedupDisk2"
Archive Device = /mnt/bacula/dedup/volumes
Media Type = DedupVolume1
Device Type = Dedup
LabelMedia = yes
Random Access = Yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Job = 5
}
Um Autochanger e vários Dispositivos são sugeridos para evitar gargalos de tarefas de backup simultâneas e saturar a capacidade de gravação do Daemon de Armazenamento. Mais de 5 trabalhos simultâneos do Diretor irão para o próximo Dispositivo disponível (DedupDisk2).
O Archive Device contém a pasta no formato de volumes tradicionais do Bacula, por isso ainda é possível usar o bscan, o bextract e outras ferramentas de emergência do Bacula. Usando o Dedup, os volumes realmente não contêm os dados de backup, mas os contêineres escreveram no diretório Dedup.
O Midia Type deve ser um nome exclusivo para todos os Dispositivos e Daemons de Armazenamento anexados ao mesmo Diretor. Autochangers diferentes devem ter um Midia Types diferentes.
Reinicie o Storage Daemon para aplicar as alterações.
Configuração do Director (bacula-dir.conf)
Crie uma nova diretiva Autochanger para conectar o Bacula SD:
Storage {
Name = Dedup
Allow Compression = No
Address = 192.168.0.85
Password = xxx
Device = Dedup
Media Type = DedupVolume1
...
}
Permitir compactação deve ser não para desabilitar a compactação do software Bacula, pois o Mecanismo Global de Dedup já o executa após a desduplicação.
Os nomes de dispositivo e tipo de mídia devem corresponder aos definidos na configuração dos recursos Autochanger e Device do bacula-sd.conf.
Em cada um dos FileSets do Bacula, é possível decidir entre Global (cliente de backup) ou Deduplicação de armazenamento. A desduplicação global (ambos os lados) tem a vantagem de minimizar o tráfego da rede A opção de armazenamento só executa a deduplicação de dados na máquina do Daemon de Armazenamento.
Include {
Options {
Dedup = bothsides # or storage
}
File = /etc
}
Configuração Opcional de File Daemons (bacula-fd.conf)
Os Daemons do Arquivo Bacula podem ser configurados para manter algumas informações de deduplicação para acelerar as restaurações, especialmente usando larguras de banda menores. Isso pode ser ativado com a diretiva Enable Client Rehydration (padrão = não).
FileDaemon {
...
Enable Client Rehydration = yes
}
Novas Pools do Bacula Director
Depois que um novo Storage é anexado, é uma boa idéia criar novos Pools de backup associados, para não obter os Dedup Volumes misturados com outros. Por exemplo:
Pool {
Name = Daily-Dedup
Type = Backup
Storage = Dedup
...
}
Configuração do Job de backup
Não há configuração especial nos Jobs de backup que usam a deduplicação. Basta agendar tarefas de backup regulares para os pools de backup recém-criados, usando os FileSets com a deduplicação bothsides ou storage ativa.
Teste e Status de Deduplicação
Aqui está um exemplo de saída da saída do comando dedup usage:
* dedup storage=Dedup usage
Dedupengine status:
DDE: hash_count=1275 ref_count=1276 ref_size=78.09 MB
ref_ratio=1.00 size_ratio=1.13 dde_errors=0
Config: bnum=1179641 bmin=33554393 bmax=335544320 mlock_strategy=1
mlocked=9MB mlock_max=0MB
Containers: chunk_allocated=3469 chunk_used=1275
disk_space_allocated=101.2 MB disk_space_used=68.87 MB
containers_errors=0
Vacuum: last_run="06-Nov-14 13:28" duration=1s ref_count=1276
ref_size=78.09 MB vacuum_errors=0 orphan_addr=16
Stats: read_chunk=4285 query_hash=7591 new_hash=3469 calc_hash=3470
[1] filesize=40.88KB/499.6KB usage=36/484/524288 7% ***...............
[2] filesize=40.13KB/589.0KB usage=18/286/524288 6% **5...............
[3] filesize=25.47KB/655.2KB usage=7/212/524288 3% *4................
O size_ratio é o ganho geral de deduplicação para todos os trabalhos de backup. Quanto mais backups forem realizados e mantidos, essa proporção deverá melhorar.
O ref_size é o tamanho dos trabalhos de backup antes da deduplicação e o disk_space_used é o tamanho real dos contêineres de desduplicação.
É uma boa ideia habilitar a funcionalidade hole_punching, o que pode economizar mais espaço em disco a longo prazo, aproveitando os blocos de dados expirados no mecanismo de desduplicação. Por exemplo:
* dedup vacuum holepunching storage=<DeviceName>
Leia o white paper referenciado da Bacula Systems para obter mais informações sobre a saída do uso de dedup e para mais opções de comando, como o processo de vacuum e scrub (verificação) do engine de deduplicação.
Conforme mostrado na Figura 2, também é possível obter informações similares pelo Bweb, a exemplo do consumo dos dados de bakup deduplicado em disco (Actual Disk Space Used), e o tamanho caso esses dados não fossem reduzidos pelo Dedup (Equivalente Standard File or Tape Storage Space). Versão do Engine de Dedup, tamanho dos Holes e muitas outras informações. Os uso dos containers e disposição dos blocos ocupados são exibidos graficamente no widget mais abaixo nessa tela.
Figura 2. Menu Estatísticas, Uso Deduplicação Global EBacula pelo BWeb
Executando um Job de Backup
O log registro regular de Jobs do Bacula deve imprimir algumas informações sobre a deduplicação. Por exemplo:
... FD Bytes Written: 137,402,873,108 (137.4 GB) SD Bytes Written: 258,766,712 (258.7 MB) Rate: 28330.5 KB/s Software Compression: 99.8% 531.0:1 ...
FD Bytes Written são os dados de backup não deduplicados obtidos do Client.
O SD Bytes Written é a quantidade de dados duplicados gravados no Bacula Storage.
Se o formato de compactação FileSet estiver definido (por exemplo, LZO, mesmo que não seja usado por Bacula ao gravar no driver Dedup), o campo Software Compression deverá informar a taxa de desduplicação.
Referência
Global Endpoint Deduplication – Bacula Enterprise Edition. http://baculasystems.com
