Грешновато проходить мимо такой увлекательной функциональности, поэтому сегодня мы посмотрим, как reflink может помочь всем ответственным за бекапы, и что на этой ниве нам может предложить Veeam Backup & Replication 10.
Если сильно не вдаваться в подробности, то reflink для XFS был представлен примерно три года назад. Ничего прорывного в этом событии не было, так как своя реализация у Microsoft была аж с 2012 года (под названием ReFS), а в том или ином виде reflink есть в BTRFS и OCFS2. Возможно, даже в большем количестве файловых систем тут прошу поправить читателей, если незаслуженно кого-то пропустил.
Итак, что же нам, бойцам фронта резервного копирования, с подобных технологий? Конечно же, самое главное это спасение драгоценного места в наших бекапных репозиториях за счёт встроенного в файловую систему механизма дедуплицирования. Это самый первый и очевидный плюс. Менее очевидный повышение быстродействия тяжёлых файловых операций. Если наше приложение умеет работать с reflink, то процедура копирования тяжёлого файла может свестись к обновлению метаданных, без необходимости реально перемещать блоки данных. Что, как вы догадываетесь, на порядки быстрее.
В контексте Veeam это позволило многократно (вы даже себе не представляете, насколько) ускорить такую операцию, как Synthetic Full. Создание синтетики это страшный сон вашего хранилища. Наверняка помните, как любят всякие техноблогеры взять и начать мучать условный винчестер тестом на чтение из произвольных мест, злобно потешаясь над упавшим в пол графиком производительности? А создание синтетического бекапа это не тест, а реальная задача, состоящая из постоянного потока операций чтения и записи из любого места на диске. Если у вас просто упадёт производительность накопителей, это ещё не плохо. Некоторые хранилища могут и просто зависнуть на полуслове.
Соответственно, если нам не надо метаться по всему диску в поисках нужных блоков и копировать их в новое место, а можно просто поправить таблицу метаданных, это даёт невероятный эффект. Поэтому нет ничего странного, что мы в Veeam давно рекомендуем использовать эту возможность, а саму функцию назвали Fast Clone. И, как было уже сказано, изначально Veeam получил поддержку майкрософтовского ReFs. У нас на форуме есть отзыв клиента, которому использование ReFS позволило уместить 99 терабайт реальных данных на 15 терабайт занятого места. И это без использования дорогих дедуплицирующих устройств.
И вот теперь настала пора и XFS получить свою толику славы.
Подготовка
Во-первых, reflink доступен в XFS только в относительно свежих релизах т.к. требует поддержки на уровне ядра. Ваша любимая Ubuntu 16.04 здесь не подойдёт, так что обновляйте до 18.04. Или лучше даже 20.04.
Что ещё? На системе обязательно должна быть включена проверка CRC и очень интересный момент: используемый размер блока данных должен быть в промежутке от 1 KiB до 4 KiB. Технически верхняя граница задаётся размером страниц в памяти (default), хотя можно и больше до 64KiB, но придётся пересобирать ядро. И многие репортят, что такой конфиг нестабилен. Как сказано в официальном мане XFS on Linux can only mount filesystems with pagesize or smaller blocks.
.
Предварительно проверяем, что у нас всё хорошо:
toor@ubuntuxfs:~$ sudo lshw -class disk -class storage -shortH/W path Device Class Description================================================/0/2 scsi0 storage/0/2/0.0.0 /dev/sda disk 5368MB Virtual Disk/0/2/0.0.2 /dev/sdb disk 21GB Virtual Disk
А потом создаём нужный раздел командой. Почему именно создаём? Да потому что нельзя включить флаг -reflink на уже созданной файловой системе. Такое вот ограничение от разработчиков.
toor@ubuntuxfs:~$ mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
И видим примерно такой вывод, где crc=1 и reflink=1, что нам и требуется. Честно говоря, crc=1 выставляется по дефолту, но у нас тут условия лабораторные, так что мы это сделали для наглядности.
meta-data=/dev/sdb isize=512 agcount=4, agsize=1310720 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1data = bsize=4096 blocks=5242880, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0, ftype=1log =internal log bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0
Делаем папку для бекапов и монтируем её
toor@ubuntuxfs: mkdir /backupsmount /dev/sdb /backups
А чтобы окончательно убедиться в том, что всё хорошо, смотрим:
toor@ubuntuxfs: df -hT .Filesystem Type Size Used Avail Use% Mounted on/dev/sdb xfs 20G 17M 20G 1% /backups
Испытания
Теперь давайте в лабораторных условиях проверим, как работает это хвалёный XFS и его reflink. Для это сгенерируем файл с рандомным содержимым с помощью всеми любимого метода перенаправления вывода из urandom
root@ubuntu: dd if=/dev/urandom of=test bs=1M count=1024010240+0 records in10240+0 records out10737418240 bytes (11 GB, 10 GiB) copied, 71.9184 s, 149 MB/s
Тут никакого дедуплицирования мы не увидим, так как reflink не используется системой по дефолту. Так что сколько места просили занять, столько и займётся. Что нас сейчас действительно интересует, так это сколько места заняли сами данные, а сколько ушло на метаданные. Проверяем.
root@ubuntu:/backups# df -hFilesystem Size Used Avail Use% Mounted on/dev/sdb 20G 11G 9.9G 51% /backups
Ага, на десять гигабайт данных у нас приходится около гигабайта метаданных.
Теперь попробуем скопировать этот файл с принудительным использованием reflink и посмотрим на результат.
root@ubuntu: cp -v --reflink=always test test-one'test' -> 'test-one
Проверяем
root@ubuntu:/backups# ls -hsltotal 20G10G -rw-r--r-- 1 root root 10G Jun 17 09:45 test10G -rw-r--r-- 1 root root 10G Jun 17 10:01 test-one
root@ubuntu:/backups# df -hFilesystem Size Used Avail Use% Mounted on/dev/sdb 20G 11G 9.9G 51% /backups
Отлично! У нас два файла по десять гигабайт, вместе занимающие одиннадцать. Слава технологиям! Но помним, что так же, как и в случае с ReFS, это всё не проходит даром и требует определённых издержек. В ReFS один блок можно переиспользовать всего 8175 раз. Также и в XFS. Количество зависит от того, сколько записей о клонах мы можем хранить это количество записей inodes. А это уже те самые метаданные. Но есть и хорошие новости: этот размер меняется динамически, и теоретический предел XFS гораздо больше, чем в ReFS.
Давайте ещё посмотрим, как данные расположены на диске
root@ubuntu:/backups# filefrag -v test test-oneFilesystem type is: 58465342File size of test is 10737418240 (2621440 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 1048559: 24.. 1048583: 1048560: shared 1: 1048560.. 2097135: 1310733.. 2359308: 1048576: 1048584: shared 2: 2097136.. 2621439: 2624013.. 3148316: 524304: 2359309: last,shared,eoftest: 3 extents foundFile size of test-one is 10737418240 (2621440 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 1048559: 24.. 1048583: 1048560: shared 1: 1048560.. 2097135: 1310733.. 2359308: 1048576: 1048584: shared 2: 2097136.. 2621439: 2624013.. 3148316: 524304: 2359309: last,shared,eoftest-one: 3 extents found
Как мы видим, оба файла занимают по три экстента, да ещё и расположены они одинаково с точностью до блока. Значит, reflink работает, как мы от него и ожидали.
Теперь переходим к практическим упражнениям с Veeam
Практика
Велосипед мы изобретать не будем, поэтому совершенно стандартным путём подключим нашу Linux машину в качестве репозитория.
И не забудем выбрать правильный диск
И главное, не забываем галочку Use Fast Cloning on XFS volumes. Иначе фокус не получится. И проверьте, что по кнопке Advanced все галочки сняты.
Когда мастер закончит свою работу, можно переходить к созданию бекапов. Как вы помните, в начале я говорил про использование заданий с созданием синтетических точек. Поэтому на шаге Storage не забываем выбрать нужный репозиторий, зайти на вкладку Advanced, выбрать Create Synthetic full backups periodically и выбрать, в какие дни они будут создаваться. Обычно мы всем советуем выбирать выходные, так как операции это сложные, и незачем на буднях лишний раз нагружать ваше хранилище.
Также не будет лишним на вкладке Maintenance включить периодический backup health check. Слишком много мы все слышали печальных историй о повреждении данных на системах вроде ReFS и XFS. Да, подобные механизмы уже встроены в саму файловую систему, но если бы они реально работали, мы бы не читали столько увлекательных рассказов про героическое спасение данных. Практика показала, что если у вас RAID с избыточностью, то вы можете спать более-менее спокойно. Если нет, то всё, на что способны эти системы самопроверки это сказать Ой, всё.
Все остальные пункты стандартные и особого внимания не заслуживают. Когда задание создано и успешно отработает, в день с запланированной синтетикой вы должны увидеть в логе вот такую строчку:
Приписка [fast clone] означает, что была создана не просто синтетическая точка, а именно с использованием Fast Clone [xfs reflink] для всего содержимого бекапа. Бывает ещё вариант [partial fast clone], когда создаётся смешанная цепочка. Да, мы умеем делать синтетику даже на не выравненных фс. Как и в ReFS, Veeam может клонировать блоки только по границам блоков файловой системы. Поэтому блоки данных бэкапных файлов создаются с выравниванием, равным block_size. Это делается автоматически при создании репозитория и для этого даже есть отдельная галочка в настройках репозитория.
Теперь давайте вернёмся на репозиторий и посмотрим файлы с бекапами. А именно, проверим, из чего состоит последний синтетический .vbk
Вывод реального файла может быть очень большим, поэтому я приведу лишь его начало и конец
root@ubuntu:/backups/Agent Linux/192.168.91.226# filefrag -v Agent\ Linux\ -\ 192.168.91.226D2020-06-18T062036_1F09.vbkFilesystem type is: 58465342File size of Agent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk is 2430484480 (593380 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 1777650.. 1777650: 1: 1: 1.. 4360: 2039034.. 2043393: 4360: 1777651: 2: 4361.. 5341: 1315106.. 1316086: 981: 2043394: shared 3: 5342.. 5345: 1986271.. 1986274: 4: 1316087: 4: 5346.. 5348: 1316091.. 1316093: 3: 1986275: shared 5: 5349.. 5570: 1986275.. 1986496: 222: 1316094: shared 6: 5571.. 5603: 1316319.. 1316351: 33: 1986497: shared 7: 5604.. 5781: 1986497.. 1986674: 178: 1316352: shared 8: 5782.. 5800: 1974097.. 1974115: 19: 1986675: shared 9: 5801.. 5872: 1316508.. 1316579: 72: 1974116: shared.... 925: 545910.. 546109: 2534022.. 2534221: 200: 1853810: shared 926: 546110.. 546299: 1776748.. 1776937: 190: 2534222: shared 927: 546300.. 546477: 2534222.. 2534399: 178: 1776938: shared 928: 546478.. 546623: 1854227.. 1854372: 146: 2534400: shared 929: 546624.. 547203: 2534400.. 2534979: 580: 1854373: shared 930: 547204.. 548096: 1855025.. 1855917: 893: 2534980: shared 931: 548097.. 549585: 2534980.. 2536468: 1489: 1855918: shared 932: 549586.. 551487: 1857319.. 1859220: 1902: 2536469: shared 933: 551488.. 551787: 2536469.. 2536768: 300: 1859221: shared 934: 551788.. 553011: 2037808.. 2039031: 1224: 2536769: 935: 553012.. 577866: 1929924.. 1954778: 24855: 2039032: shared 936: 577867.. 578291: 2536769.. 2537193: 425: 1954779: shared 937: 578292.. 592732: 1954913.. 1969353: 14441: 2537194: shared 938: 592733.. 593373: 2537194.. 2537834: 641: 1969354: shared 939: 593374.. 593375: 1777645.. 1777646: 2: 2537835: shared 940: 593376.. 593379: 1969356.. 1969359: 4: 1777647: last,eofAgent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk: 941 extents found
Как мы видим, он практически весь состоит из переиспользованных shared блоков. Никак не помеченные блоки относятся к последнему инкременту, который создаётся перед созданием фульника.
Но какой именно выигрыш дали нам эти шаред блоки? Смотрим:
root@ubuntu:/backups/Agent Linux/192.168.91.226# df -h .Filesystem Size Used Avail Use% Mounted on/dev/sdb 20G 3.8G 17G 19% /backups
Реально использовано 3,8 Гигабайта. А что же сами файлы?
root@ubuntu:/backups/Agent Linux/192.168.91.226# ls -hsltotal 7.2G 56K -rw-rw-rw- 1 root root 54K Jun 18 13:20 'Agent Linux - 192.168.91.226.vbm'1.8G -rw-r--r-- 1 root root 1.8G Jun 17 13:53 'Agent Linux - 192.168.91.226D2020-06-17T065146_8546.vbk' 63M -rw-r--r-- 1 root root 63M Jun 17 13:57 'Agent Linux - 192.168.91.226D2020-06-17T065727_0228.vib'317M -rw-r--r-- 1 root root 317M Jun 17 14:03 'Agent Linux - 192.168.91.226D2020-06-17T070240_FD8B.vib'383M -rw-r--r-- 1 root root 383M Jun 17 14:09 'Agent Linux - 192.168.91.226D2020-06-17T070826_5860.vib'2.4G -rw-r--r-- 1 root root 2.4G Jun 17 15:04 'Agent Linux - 192.168.91.226D2020-06-18T020624_DF44.vbk'2.3G -rw-r--r-- 1 root root 2.3G Jun 18 13:20 'Agent Linux - 192.168.91.226D2020-06-18T062036_1F09.vbk'
А сами файлы занимают 7,2 Гигабайта. Вот такой вот выигрыш.
На этом задачу показать пользу и выгоду от использования Fast Clone считаю выполненной. Как мы видим, это не только экономия места, хотя сейчас и считается, что проще купить новый сторадж и накидать в него дисков. Это ещё и экономия времени, чтобы попасть в необходимый backup window. Пока скорость обычной синтетики ограничена производительностью дисковой подсистемы, в случае ReFS/XFS это нагрузка больше вычислительная. А с доступностью CPU и RAM ресурсов дела обычно обстоят намного лучше.
И перед тем как распрощаться, позвольте оставить вам несколько полезных ссылок:
helpcenter.veeam.com/docs/backup/vsphere/backup_repository_block_cloning.html?ver=100 Про Fast Clone в документации
www.veeam.com/kb3150 Fast Clone и Nutanix Mine
blogs.oracle.com/linux/xfs-data-block-sharing-reflink Отличная статья про XFS и Reflink в блоге Oracle
