Olá a todos,
Num dos nossos posts anteriores, falei da minha migração de bacula para bareos.
Uma das razões que referi na altura, foi o formato mais aberto a comunidade do bareos versus a postura mais empresarial da empresa que produz o bacula.
Não me interpretem mal, todos necessitamos de comer, mas a postura pró-empresarial na forma que o bacula começou a ser gerido, em formato pay-for-goodies incomodou-me a um nível pessoal.
Uma outra razão, que deriva diretamente da abertura do bareos, foi a existência de plugins que podem ser utilizados para integrações extremamente interessantes.
Esta capacidade, e em particular o plugin de integração com clusters CEPH/Gluster, deixara-me de olhos em bico.
A ideia é simples: Ao invés de se fazer o típico backup para tape / virtual tape file, o backup é feito por objetos para dentro de um cluster de storage que suporte armazenamento por objetos.
A vantagem disto, é termos replicação em near-real-time de ficheiros, após os backups, por exemplo para uma localização segura, através de um mecanismo de replicação em geo-cluster:
Para os mais curiosos, sim, o processo de geo-replicação é suportado pela Red Hat em ambientes certificados para o efeito, já desde o Red Hat Storage 2.0.
Isto leva a necessidade por detrás do projeto: Foi me pedido um mecanismo de replica, o mais perto de tempo real, de virtual tapes usadas num backup, para um site remoto seguro.
Aguardar pelo fim do backup, para em seguida se efetuar um sync não seria aceitável.
A melhor forma de resolver o problema foi com o bareos+gfsapi, fazendo o backup para um gluster storage server local, deixando o gluster em si, fazer a replica.
O gluster geo-replicado já existia, pelo que a configuração adicional foi relativamente simples:
Nota: para referencia, o nosso volume de gluster que irá receber os backups chama-se geobackup.
No ficheiro /etc/glusterfs/glusterd.vol foi adicionada a opção rpc-auth-allow-insecure a todos os membros do cluster (locais e remoto). Em seguida efetuar um restart a instância de gluster.
Em seguida, nos membros do gluster efetuar o comando gluster volume set geobackups server.allow-insecure.
Existem versões de gluster que podem vos obrigar a parar e a arrancar o volume envolvido através do comando gluster volume stop geobackups e gluster volume start geobackups.
Nota: Tenham atenção se no vosso caso o volume de gluster for partilhado com aplicações ou containers, o restart e o stop/start irá levar a falha do volume e ao que estiver lá em funcionamento.
Em primeiro lugar vamos carregar as bibliotecas necessárias para a manipulação de objetos via gluster:
yum -y install bareos-storage-glusterfs
Em seguida, é altura de criar a diretoria-objecto onde o SD irá escrever as tapes referentes a este objecto:
mount -t glusterfs gluster.empresa.pt:geobackups /mnt mkdir /mnt/bareos chown bareos:bareos /mnt/bareos chmod ug=rwx /mnt/bareos umount /mnt
Substituir o FQDN gluster.empresa.pt pela vossa realidade / ip do vosso servidor de gluster.
Em seguida, será necessária a configuração do daemon do SD em si, para escrever na objecto-dir dentro do nosso gluster cluster.
# cat /etc/bareos/bareos-sd.d/device/GlusterStorage.conf
Device {
Name = GlusterStorage
Description = "Storage device using a Gluster backend."
Archive Device = "Gluster Device"
Device Options = "uri=gluster://gluster.empresa.pt/geobackups/bareos"
Device Type = gfapi
Media Type = GlusterFile
Label Media = yes
Random Access = yes
Automatic Mount = yes
Removable Media = no
Always Open = no
}
Após esta configuração será necessário adicionar a indicação do novo storage de SD disponível, ao Bareos Director:
cat /etc/bareos/bareos-dir.d/storage/Gluster.conf
Storage {
Name = Gluster
Address = IP_DO_VOSSO_SD_TIPICAMENTE_E_O_SERVIDOR_DE_BAREOS
Password = 5KNLs9MYkFWwbC46jqtU32jWEpmkHEGg
Device = GlusterStorage
Media Type = GlusterFile
}
Notem que o Device refere-se ao gerado no passo anterior, e que o MediaType é GlusterFile.
Finalmente, vamos configurar as definições de jobs, filesets no próprio director:
Job {
Name = customer_fileserver_Gluster
fileset = customer_fileserver_Gluster
Type = Backup
Level = Incremental
Client = servidorvps999-fd
Schedule = ClienteVPS999
Storage = Gluster
Pool = customer_fileserver
Messages = Standard
Reschedule on Error = yes
Reschedule Interval = 1 hours
Reschedule Times = 3
}
Pool {
Name = customer_fileserver
Pool Type = Backup
Volume Retention = 60 days
Recycle = yes
AutoPrune = yes
Label Format = customer_fileserver-
Maximum Volumes = 2000
Maximum Volume Bytes = 500M
}
FileSet {
Name = customer_fileserver
Include {
File = /var/www
File = /home
File = /var/pgsql-exports/
Options {
signature = MD5
compression = GZIP9
wild = "*.jpg"
wild = "*.gz"
wild = "*.gif"
wild = "*.zip"
wild = "*.mp3"
noatime=yes
}
}
}
Options {
signature = MD5
compression = GZIP9
aclsupport = yes
signature = MD5
xattrsupport = yes
}
}
}
Finalmente efetuamos um reload ao bareos-sd e ao bareos-dir e tudo deverá funcionar perfeitamente e a primeira :).
Nota: Foram detetados alguns casos onde o bareos-sd tem de correr como root sob pena de aparecerem erros de permissões a escrever os ficheiros de vtapes dentro da pool de storage gluster.
O processo para mim foi baseado em trial-and-error, pois a documentação não estava muito explicita na minha optica, e sobretudo porque a arquitetura deste Cliente é particularmente complexa envolvendo redes de frontend e redes de backup dedicadas para alguns sistemas.
Um dos pontos que tropecei foi nas permissões do object-dir dentro do gluster:
Todas as virtual tapes vão ser criadas com os UIDs/GIDs do Bareos-SD original.
Se não foram dadas permissões adequadas, os vossos ficheiros vão ficar na root do vosso gluster storage volume, ao invés da diretoria de armazenamento esperada.
Outro ponto importante a reter, é a necessidade de garantir conectividade entre a VPS do vosso cliente, e o vosso servidor de SD na porta do processo bareos-sd.
Claro que se tiverem duvidas já sabem onde me encontrar, ou em alternativa, pf enviem-me um email para nuno(at)nuneshiggs.com
Abraço!
Nuno