Дедупликация с помощью VDO

    2019-01-06 21:48 | Автор: jekader | Filed under: Jekader

    Дедупликация - довольно интересная технология, использующаяся повсеместно в хранилищах данных для более эффективного использования дискового пространства. Несколько лет назад Red Hat приобрёл компанию Permabit, разработавшую решение для дедупликации блочных устройств в Linux под названием VDO. С тех пор, что называется "тихо и незаметно" эта технология стала доступна прямо в RHEL/CentOS и я хочу рассказать о её возможностях.

    Итак, для использования технологии нам достаточно RHEL/CentOS не старше версии 7.5 и отдельного диска, который собственно и будет базой для дедуплицируемого тома.

    Первым делом - установим необходимые пакеты:

    # yum install vdo kmod-kvdo

    Для VDO я подключил к системе второй диск /dev/sdb размером 20Гб. На нём я создам дедуплицированный том размером 100Гб, на котором и будем тестировать.

    # vdo create --name=vdo --device=/dev/sdb --vdoLogicalSize=100G 
    Creating VDO vdo
    Starting VDO vdo
    Starting compression on VDO vdo
    VDO instance 0 volume is ready at /dev/mapper/vdo

    Как видим, устройство создано и доступно по адресу /dev/mapper/vdo. Утилита vdostats показывает статистику томов:

    # vdostats --human-readable /dev/mapper/vdo 
    Device                    Size      Used Available Use% Space saving%
    /dev/mapper/vdo          20.0G      4.0G     16.0G  20%           N/A

    Необычно - уже "занято" 4 гигабайта. Разметим файловую систему и подмонтируем её:

    # mkfs.xfs /dev/mapper/vdo 
    meta-data=/dev/mapper/vdo        isize=512    agcount=4, agsize=6553600 blks
            =                       sectsz=4096  attr=2, projid32bit=1
            =                       crc=1        finobt=0, sparse=0
    data     =                       bsize=4096   blocks=26214400, imaxpct=25
            =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
    log      =internal log           bsize=4096   blocks=12800, version=2
            =                       sectsz=4096  sunit=1 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    # mkdir -p /mnt/vdo
    # mount /dev/mapper/vdo /mnt/vdo/
    # df -h /mnt/vdo/
    Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
    /dev/mapper/vdo    100G          33M  100G            1% /mnt/vdo

    Уличная магия! Файловая система на 100 гигабайт готова к использованию! Создадим на ней файл размером 1 гигабайт:

    # dd if=/dev/urandom of=/mnt/vdo/random1 bs=1M count=1024             
    1024+0 записей получено
    1024+0 записей отправлено
    скопировано 1073741824 байта (1,1 GB), 42,2853 c, 25,4 MB/c

    Теперь глянем статистику использования диска:

    # df -h /mnt/vdo 
    Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
    /dev/mapper/vdo    100G         1,1G   99G            2% /mnt/vdo
    # vdostats --human-readable /dev/mapper/vdo  
    Device                    Size      Used Available Use% Space saving%
    /dev/mapper/vdo          20.0G      5.0G     15.0G  25%            4%

    Интересные ифры. На файловой системе занят 1 гигабайт, на томе VDO уже 5 и при этом указана "экономия" в 4%! Но это лишь повод тестировать дальше. Файл, созданный из содержимого /dev/urandom - это эталон несжимаемой и недедуплицируемой информации. Теперь создадим несколько его копий на этой-же файловой системе и посмотрим, что будет:

    # for i in {2..22}; do cp random1 random$i; done             
    # df -h /mnt/vdo                              
    Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
    /dev/mapper/vdo    100G          23G   78G           23% /mnt/vdo
    [root@localhost vdo]# vdostats --human-readable /dev/mapper/vdo   
    Device                    Size      Used Available Use% Space saving%
    /dev/mapper/vdo          20.0G      5.0G     15.0G  25%           95%

    А вот теперь уже интереснее! Файловая система рапортует, что занято 23 гигабайта, что больше размеров нашего блочного устройства. При этом, на стороне VDO ничего не поменялось: все копии не занимают места. Продолжим эксперимент и удалим все файлы:

    # rm -f random* 
    # df -h /mnt/vdo                             
    Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
    /dev/mapper/vdo    100G          33M  100G            1% /mnt/vdo
    # vdostats --human-readable /dev/mapper/vdo  
    Device                    Size      Used Available Use% Space saving%
    /dev/mapper/vdo          20.0G      5.0G     15.0G  25%           95%

    Файловая система вернулась в исходное состояние, но VDO рапортует всё те-же данные. Это вызвано тем, что блочный уровень не в курсе удаления блоков. Чтобы сообщить об этом, нужно смонтировать файловую систему с опцией trim либо провести его вручную:

    # fstrim /mnt/vdo/    
    # vdostats --human-readable /dev/mapper/vdo  
    Device                    Size      Used Available Use% Space saving%
    /dev/mapper/vdo          20.0G      4.0G     16.0G  20%           99%

    Вернулись на исходную. Использование на стороне VDO упало, хотя счётчик "space saving" совсем сошёл с ума 🙂 Но главное, один гигабайт теперь вновь освободился.

    Вот и сказке конец! Как видно, чудес не бывает и дедупликация не всесильна. Эта технология позволяет экономить пространство, но неприменима для данных, таких как:

    • фото/видео в lossy форматах
    • зашифрованные файлы
    • сжатые файлы

    В случае хранения дисков виртуальных машин польза будет видна в основном при использовании RAW дисков и множества одинаковых виртуальных машин (в oVirt, например, применяются по умолчанию COW диски и пространство используется крайне эффективно).

    Ещё стоит отметить, что VDO не работает на основе колдовства, поэтому по сравнению с обычным файловым хранилищем увеличены требования к процессору и памяти. Конкретно - каждый том VDO требует порядка 600 мегабайт памяти под метаданные, плюс по 300 мегабайт на каждый терабайт физического блочного устройства.

    Подробную информацию по планированию и внедрению хранилищ на основе VDO можно почитать в документации к RHEL7, c которой полностью совместим CentOS 7

    1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5,00 out of 5)
    Loading...

    Метки: , ,

    Comments (1) »


    1 комментарий

    1. tolstushka:

      Впечатляет.
      Только команду mkfs.xfs стоит выполнять с опцией -К, а то при таких объёмах устройств (хоть и ненастоящих) она слишком долго будет выполняться.

    Leave a comment

    *