Решение для резервного копирования моментальных снимков GlusterFS

Мы ищем быстрый способ сделать снимки наших глянцевых кирпичей на определенный момент времени.

это не Важно то, что это идеальный моментальный снимок на определенный момент времени (т.е. если файлы меняются / добавляются / удаляются во время резервного копирования, это нормально для резервной копии иметь / не иметь этих изменений).
В идеале он мог бы работать как резервное копирование в реальном времени (без простоев), но мы можем иметь дело с удалением узла из кластера и добавлением его снова после этого, если нам нужно.
Резервные копии необходимо будет перенести в удаленное место, но это можно сделать после локального создания первоначальной резервной копии, если это необходимо.
У нас есть несколько кирпичей. Для всех потребуется резервное копирование, и это можно сделать по отдельности или все сразу.
В настоящее время мы работаем glusterfs 3.5.3 на момент написания, но имеют тенденцию обновляться при выпуске новых версий.

Мы рассмотрели возможность использования rsync (как и на обычном томе), но он действительно медленный по сравнению с gluster, поскольку у нас есть сотни тысяч довольно маленьких файлов (100–3 МБ), и я понимаю, что gluster общается со всеми узлами для каждого файл, чтобы убедиться, что он дает правильную версию. Можем ли мы выполнить rsync через расположение каталога данных на одном из узлов сервера (не через клиент glusterfs)? Будет ли это работать так, как ожидалось, и будет ли это быстрее, так как не нужно проверять данные со всеми узлами?

Снимок объема Gluster звучит как идеальное решение, но я не думаю, что оно еще выпущено.

Узлы хранения Gluster имеют LVM, но я не очень хорошо разбираюсь в его деталях. Может ли это быть решением?

Есть ли у кого-нибудь еще хорошее предложение, как справиться с этой ситуацией? Или реальный жизненный опыт? Спасибо.

Вам нужно поместить свои блестящие кирпичи в LVM-образы с тонкой подготовкой.

Создать тонкий пул LVM
Создание образа LVM для кирпича в thinpool
Создайте кирпич и настройте объем глянца и т. Д.

Насколько мне известно, самое простое решение:

sudo gluster snapshot create volume_name имя_снимка
размонтировать снимок из файловой системы
создать lz4 образ снимка с dd и lz4
смонтировать образ обратно

Полное резервное копирование образа с более чем 2M файлами и 18G занимает около 90 секунд на выделенном сервере.

Псевдокод:

# create snapshot
echo $(date)" Creating glusterfs snapshot" >> $LOG
gluster snapshot create $SNAP_NAME $GS_VOLUME no-timestamp 2>>$LOG
echo $(date)" [OK]" >> $LOG

# get snapshot volume name
SNAP_VOL_NAME=$(gluster snapshot info $SNAP_NAME | grep "Snap\ Volume\ Name" | sed -e 's/.*S.*:.//g') MOUNT_OBJECT="/dev/"$VG"/"$SNAP_VOL_NAME"_0" 
MOUNT_POINT="/run/gluster/snaps/$SNAP_VOL_NAME/"$BRICK BACKUP_FS=$DIR_BA"/"$SNAP_NAME".ddimg.lz4"

# umount the image
umount $MOUNT_POINT

# create backup
echo $(date)" Creating lz4 of LVM image" >> $LOG
sudo dd if=$MOUNT_OBJECT 2>>$LOG | lz4 > $BACKUP_FS 2>>$LOG
echo $(date)" [OK]" >> $LOG

# mount image back
#mount $MOUNT_OBJECT $MOUNT_POINT

# delete (all) snapshots and umount
yes | gluster snapshot delete volume $GS_VOLUME 2>> $LOG

Плохое решение imo.

GlusterNode1 ~ $ df -h | grep gluster

/ dev / mapper / vg_12564073a0545f72de3g7835e711459a-33eacc4c9c2c4e6fbec16cdb55dd8b37_0 2.0G 35M 2.0G 2% / run / gluster / snaps / 33000c4c9c2c4e6fbec16bdb55

снимок сделан с помощью lvm, а образ lv4 содержит только кирпичик этого узла.