Olá a todos,
Chegou agora a altura de completar o post iniciado na semana passada sobre de-duplicação, encriptação e o ônus necessário em espaço ocupados para ambientes cloud.
No post original fizemos um teste usado um método de de-duplicação por ficheiro, com os resultados apresentados ficando muito aquém do desejado.
Hoje, o processo usado será diferente, usando para tal de-duplicação por bloco.
Este método é a norma, tanto em ambientes cloud como em ambientes locais, e existem muitas opções sobre qual o software a utilizar: SDFS, ZFS, etc
Para o nosso teste utilizamos SDFS pois é suportado nativamente por ambientes GlusterFS e está mais perto do nosso universo de Linux, embora o port que existe de ZFS onLinux seja excelente.
Aconselho vivamente a que vejam e experimentem com o produto opendedup. Está extremamente bem feito, e com integrações em ambientes de Cloud (por exemplo S3 ou AWS), ou para ambientes locais (usado como backends em Ceph e Gluster) está simplesmente perfeito.
Em relação ao teste em si:
O nosso laboratório tem a mesma constituição de hardware que o ultimo post, com a diferença que agora estamos a utilizar Centos 7, pois o método de instalação do produto em Centos é mais rápida e mais direta:
# wget http://opendedup.org/downloads/sdfs-latest.rpm # yum install jsvc libxml2 java-1.8.0-openjdk # rpm -iv --force sdfs-latest.rpm
echo "* hardnofile 65535" >> /etc/security/limits.conf echo "* soft nofile 65535" >> /etc/security/limits.conf exit
Caso o vosso ambiente permita em termos de segurança, desactivar a firewall local de sistema, ou em alternativa aplicar regras que se adequem as vossas portas:
# systemctl stop firewalld # systemctl disable firewalld
Finalmente fazer log-out e reboot.
Nota: Os dados referentes ao nosso filesystem são armazenados localmente no nosso sistema em “/opt/sdfs/volumes/<volume-name>/ddb/”
Chegou a altura de fazer o nosso SDFS filesystem:
# mkfs.sdfs --volume-name=pool0 --volume-capacity=30GB Attempting to create SDFS volume ... Volume [pool0] created with a capacity of [30GB] check [/etc/sdfs/pool0-volume-cfg.xml] for configuration details if you need to change anything
Temos agora um filesystem funcional pelo que falta apenas efetuar o mount e adicionar ele ao fstab:
mkdir /media/pool0 mount -t sdfs pool0 /media/pool0/
pool0 /media/pool0 sdfs defaults 0 0
Em seguida, chegamos novamente a altura de configurar o rclone. Todas as passwords foram geradas aleatoriamente na altura da configuração.
[DRIVE2] type = local nounc = true [DRIVE2CRYPT] type = crypt remote = DRIVE2:/mnt/test/2 filename_encryption = standard password = glJtiB9t64Qy33of8gxEnnxm8ze4z1-9FfuRwtduk2jKiJT_cj-8D-t1-tdyxfEtKJezF004NUVxW00OfbySZ5LpqEX3qcKxA2O0vd5umpwX1gQmSXHG_y0T44nEi15nLSxEWzqqm3KuHw37rWnererrciRFlPmVHprCj7ysnVpOGmJlXTOjFbvP3emgcWggZgimOicsPNouwveGitVNUYYfvB7VSJG3C4-iNe-1i_qnA6OF6twoQIZDVg password2 = WG8dUWeZhxFgrp2wBr93eYxZeHUmQ6j0eNwLIqqsBiNRy4S1YOe1RGhMImF1o8GTcGb6HYfjb5d26NxhmJF6Ebmo9Sc8Mqxge6nB3SGw0xNXWOOyG-Zjph2ZbMX63hv0PzyUV8fKR9aPb5R_1x7Dzm37B-eHqAy6qSE3YApDYRXJ99-yfDMzTyFMUnNYANMyuoWkpmS9ChbNWlZQ2XawaH_Wi1fV85SQmhss0G-9ZbbT8nq1zOtjk2uLQg
Com os fuse mountpoints já ativos utilizando o rclone e o seu baseline de SDFS:
sdfs:/etc/sdfs/pool0-volume-cfg.xml:6442 31521280 13789184 17732096 44% /media/pool0 DRIVE2CRYPT: 1099511627776 0 1099511627776 0% /mnt/arquivos
Foi iniciada em seguida a copia, dos mesmos 6 ficheiros do teste original e chegamos a
uma conclusão em linha com a anterior:
Com ficheiros encriptados via rclone e colocados dentro do SDFS com o Engine de de-duplicação activo:
sdfs:/etc/sdfs/pool0-volume-cfg.xml:6442 32G 27G 6.0G 84% /media/pool0
Temos uma poupança de 3GB em cada 30GB de dados ocupados, utilizando encriptação.
Caso não seja usada encriptação o resultado é diferente:
sdfs:/etc/sdfs/pool0-volume-cfg.xml:6442 32G 14G 17G 44% /media/pool0
Passamos de uma poupança de 14% no caso de dados encriptados, para uma poupança de 56% do espaço o que bastante significativo.
É muito importante lembrar que o universo de estudo tinha apenas 32GB de tamanho, e que eram apenas 6 ficheiros em estudo.
Caso o universo fosse substancialmente maior (> 1PB) a taxa de reaproveitamento provavelmente seria maior no caso dos ficheiros encriptados, embora o incontestável vencedor seria sempre o método onde os ficheiros não se encontram encriptados.
Conclui-se ainda que a de-duplicação por bloco, ao invés da deduplicação por ficheiros tem vantagens:
- O espaço reclamado é maior, mesmo em ambientes encriptados.
- Permite que todo o processo seja feito on-the-fly (por ficheiro é on-demand).
- Maior transparência para o utilizador final.
Caso tenham alguma duvida já sabem onde me encontrar.
Até ao próximo post!
Abraço,
Nuno