Encriptação e De-Duplicação Em Ambientes Cloud. Inimigos Mortais? Parte 2 De 2

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
Será necessário aumentar o numero máximo de ficheiros a serem abertos concorrentemente:
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/
Adicionar o mountpoint ao fstab
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