Pull to refresh
Veeam Software
Продукты для резервного копирования информации

XFS, Reflink и Fast Clone. Созданы друг для друга

Reading time 9 min
Views 8.9K
Как все мы знаем, XFS — это высокопроизводительная журналируемая файловая система, созданная в недрах Silicon Graphics. А высокопроизводительная она потому, что способна справляться с множеством параллельных потоков ввода-вывода. Так что если вам интересна файловая система с легко масштабируемой пропускной способностью и не деградирующая от работы с несколькими устройствами одновременно, то вам, однозначно, сюда. Но сегодня мы будем нахваливать не весь XFS, а один конкретный его флаг — reflink. Он включает возможность переиспользовать одинаковые блоки данных между файлами, обеспечивая дедупликацию и возможность делать быстрые copy-on-write снапшоты.

Грешновато проходить мимо такой увлекательной функциональности, поэтому сегодня мы посмотрим, как 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 -short

H/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=1
data     =                       bsize=4096   blocks=5242880, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Делаем папку для бекапов и монтируем её

toor@ubuntuxfs: mkdir /backups
mount /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=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 71.9184 s, 149 MB/s

Тут никакого дедуплицирования мы не увидим, так как reflink не используется системой по дефолту. Так что сколько места просили занять, столько и займётся. Что нас сейчас действительно интересует, так это сколько места заняли сами данные, а сколько ушло на метаданные. Проверяем.

root@ubuntu:/backups# df -h
Filesystem      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 -hsl
total 20G
10G -rw-r--r-- 1 root root 10G Jun 17 09:45 test
10G -rw-r--r-- 1 root root 10G Jun 17 10:01 test-one

root@ubuntu:/backups# df -h
Filesystem      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-one
Filesystem type is: 58465342
File 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,eof
test: 3 extents found
File 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,eof
test-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.vbk
Filesystem type is: 58465342
File 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,eof
Agent 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 -hsl
total 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
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+9
Comments 4
Comments Comments 4

Articles

Information

Website
veeam.com
Registered
Founded
Employees
1,001–5,000 employees
Location
Швейцария