Содержание статьи
Дисковая подсистема всегда была узким местом ПК. Проблема особенно обострилась с ростом вычислительной мощности, когда производительность харда фактически сводила на нет огромные возможности CPU. SSD, не имеющие движущихся частей, обеспечивали неплохую производительность в операциях чтения, однако они относительно дороги и имеют меньший ресурс. Неплохим решением стало использование тандема SSD + HDD, но это потребовало специального софта.
Что имеем?
Традиционные технологии — использование кеша в ОЗУ и RAID 0, позволяющие наращивать скорость операций ввода-вывода, — уже не устраивают из-за слишком большого объема обрабатываемых данных и повышенного требования к надежности. Возможность вынести журнал на внешний SSD-диск, например в ext4, помогает увеличить производительность ФС, но глобально это не настолько влияет на ситуацию. И хотя все они по-прежнему распространены, технология совместного использования SSD + HDD оказалась наиболее интересной, так как позволяла нарастить производительность при относительно низкой цене.
Идея в общем проста: SSD-накопители выступают в качестве кеширующего устройства к одному или нескольким медленным жестким дискам. При запросе данные сперва проверяются на наличие в кеше и, если они там есть, отдаются оттуда. Кеширование реализовано на уровне блочного устройства, что позволяет реализовать такую схему независимо от файловых систем и использовать везде, где есть необходимость в быстрых I/O-операциях: на рабочих станциях, серверах, в массивах хранения данных. Появились гибридные приводы, которые изначально сочетают обе технологии. Такие приводы поддерживаются Win 8.1 и выше, для Linux 3.19+ или с использованием патча.
Интерес был очень высок, и в результате практически одновременно стартовали четыре проекта, имевшие сходные идеи.
Dm-cache — решение, основанное на блочном устройстве device mapper и реализованное в виде модуля ядра. Зависит от модуля dm_mod.ko, появившегося в относительно новых ядрах (для старых есть патч). Может быть прозрачно подключено к любому устройству хранения, в том числе и к сетям SAN, iSCSI и AoE. Поддерживает LVM. С версии 3.9 добавлен в ядро, в дистрибутивах часто собран в виде модуля, поэтому ставится просто.
Dm-cache заботится о долговечности SSD, для этого часто меняющиеся данные не записываются в кеш. В настоящее время поддерживается три политики кеширования: multiqueue, stochastic multiqueue (фактически улучшенная multiqueue, по умолчанию) и очистка. Основная проблема работы с dm-cache — это сложность настройки, ведь требуется три диска: с данными, для кеша и для метаданных кеша. Размер метаданных нужно правильно подсчитать. Поэтому его и не очень любят. Но в случае, когда запись изменений в кеше откладывается (write-back), dm-cache показывает неплохой результат.
Flashcache создан в Facebook для решения проблем с масштабированием производительности InnoDB/MySQL, выпущен под лицензией GNU GPL. Реализован в виде модуля для ядра Linux (потребуется его сборка), работающего в стеке device mapper. Судя по активности на GitHub, основной код давно не обновлялся, хотя есть фиксы, устраняющие проблемы сборки с новыми ядрами третьей ветки. Не собирается в 32-битных Linux. Для использования на корневой файловой системе или LVM PV необходим модуль Dracut.
Flashcache может работать с двумя SSD, собранными как RAID 0 или RAID 1. Поддерживаются четыре политики кеширования: write-back (отложенная запись, данные пишутся на SSD, затем на медленный диск через время, определенное политиками), write-through (сквозная запись, данные пишутся на HDD, а затем в кеш), write-around (данные кешируются на SSD и сразу записываются на диск) и WriteOnly (вариант write-back, при котором кешируются только входящие данные). Настройке поддаются все параметры: размер блока, объем кеш-памяти, алгоритмы вытеснения FIFO или LRU (менее используемые блоки) и многое другое. Данные можно помечать как некешируемые.
EnhanceIO — форк flashcache, разрабатываемый в корпорации STEC и курируемый Дарриком Вонгом (Darrick Wong) из Oracle. Некоторые компоненты и алгоритмы полностью изменены, в результате он потребляет меньше ресурсов и в режиме параллельной записи (write-through) работает быстрее. Здесь не используется device mapper, поэтому появляется возможность подключать и отключать кеширование без остановки системы на лету.
Может работать с любым устройством: диском, разделом, software RAID, RAID DAS, SAN. Реализовано три режима: read-only, write-through и write-back — и три политики замещения: random (фактически round-robin), FIFO и LRU. Планировалось включение в ядро 3.10, но пока придется собирать все самостоятельно.
Все эти проекты нельзя назвать заброшенными, но и активно они не развиваются. Для flashcache и EnhanceIO потребуется пересборка ядра, а dm-cache хотя и предлагается некоторыми хостерами, но все-таки сложен. Наиболее интересен Bcache и новое решение на его основе Bcachefs.
Проект Bcachefs
Вначале был Bcache (block cache) — проект, запущенный в 2010 году как личный проект Кента Оверстрита (Kent Overstreet). Позже он заинтересовал Google, и некоторое время Кент продолжал развитие Bcache, работая в этой корпорации. К 2012 году Bcache уже представлял собой вполне стабильный релиз, а с версии Linux ядра 3.10 (2013 год) входит в состав ядра. Реализован, как и прочие подобные решения, в виде блочного устройства.
Доступны две основные политики кеширования: write-back и write-through (по умолчанию). При write-through операция записи считается завершенной после сохранения данных на обоих дисках. Это гарантирует целостность, но снижает скорость. Дополнительно реализован так называемый readahead, когда кеш наполняется не только при записи, но и при операциях чтения.
Чтобы повысить эффективность, последовательные обращения к большому объему данных не кешируются, в кеш попадают только операции случайного чтения и записи. Учитывая ограниченный ресурс, случайные операции записи преобразуются с использованием btree в последовательное заполнение накопителя. При сбросе данных на диск данные группируются с учетом минимизации перемещения головок диска. Один SSD может кешировать несколько HDD, их количество при необходимости можно менять и устанавливать гарантируемый порог I/O, чтобы избежать перегрузки SSD.
Один важный момент. Чтобы нельзя было получить доступ к этим разделам и нарушить кеш, Bcache требует явного переформатирования разделов, поэтому его удобно разворачивать на чистую систему или данные предварительно необходимо заархивировать.
Постепенно развивая проект, разработчики пришли к выводу, что блочное устройство содержит компоненты файловой системы, поэтому, пересмотрев подход, можно убрать один уровень и обеспечить более простое использование и управление. Так и появился Bcache File System — Bcachefs. Цель проекта — создать файловую систему, соответствующую ext4 и XFS по производительности и надежности с некоторыми особенностями Btrfs и ZFS. Пока проект официально находится в альфа-стадии, но считается достаточно стабильным.
В настоящее время разработчики реализовали большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL. Плюс возможность включения в раздел нескольких устройств (пока только два), репликацию (RAID), кеширование, прозрачное сжатие данных (пока только gzip) и верификацию целостности по контрольным суммам. Файловая система основана на использовании механизма copy-on-write (COW), при котором один файл могут получить несколько устройств, а изменения не приводят к перезаписи данных: новое состояние записывается в новое место, после чего меняется указатель актуального состояния.
Несколько устройств могут подключаться слоями, когда более быстрый накопитель используется для кеширования данных медленного диска с нижнего слоя. Необходима оптимизация — в тестах Bcachefs уже заметно обгоняет Btrfs, но пока отстает от ext4. В будущем планируется добавить и другие атрибуты современной ФС: предварительное резервирование места (fallocate), квоты, снапшоты, SMR (Shingled Magnetic Recording) и RAW режим доступа к flash и другие.
Пробуем
Для тестирования Bcachefs достаточно собрать ядро (на момент написания 4.1.0) и утилиту администрирования. Проект не предоставляет архив, поэтому все необходимое (приблизительно 700 Мбайт) качаем из Git.
$ sudo apt-get install kernel-package fakeroot build-essential ncurses-dev bcСам Bcachefs находится в ветке bcache-dev, утилиты — в dev (в Ubuntu ppa:g2p/storage не подходит).
$ git clone -b bcache-dev http://evilpiepirate.org/git/linux-bcache.gitСобираем ядро, здесь в общем все стандартно. За основу конфигурации ядра с Bcachefs используем настройки текущего:
$ cd linux-bcache
$ cat /boot/config-`uname -r`>.config
$ make oldconfig
$ make-kpkg clean
$ make-kpkg -j5 --initrd kernel_image kernel_headersСтавим получившиеся deb-пакеты:
$ sudo dpkg -i linux-headers-4.1.0-bcache-10.00.Custom_amd64.deb
$ sudo dpkg -i linux-image-4.1.0-bcache-10.00.Custom_amd64.debМожем перезагружаться с новым ядром. Для настроек Bcachefs используется bcacheadm (в Bcache — make-bcache). Ставим пакеты, необходимые для сборки:
$ sudo apt-get install libnih-dev libblkid-devИ собираем:
$ git clone -b dev http://evilpiepirate.org/git/bcache-tools.git
$ cd bcache-tools
$ make
$ sudo make install
Теперь можем отформатировать раздел:
$ sudo bcacheadm format -C /dev/sdb1
И примонтировать раздел, не забыв указать тип файловой системы:
$ sudo mount -t bcache /dev/sdb1 /mntДля включения контрольных сумм и сжатия при монтировании можно дополнительно задать -o data_checksum=crc32c,compression=gzip. Если диска два, их можно положить слоями с автоматическим кешированием между уровнями:
$ sudo bcacheadm format -C /dev/sdb1 --tier 1 -C /dev/sdc1При этом слой с большей цифрой предназначен для медленных устройств. Все параметры форматирования можно узнать, введя
$ bcacheadm format --helpНапример, возможно указать и бэкенд-устройство при помощи параметра -B:
$ bcacheadm format -C /dev/sdb1 -B /dev/sdc1Правда, такая схема пока не совсем работает. Параметр --cache-mode позволяет задать режим кеширования при форматировании. При необходимости его можно затем изменить, обратившись к /sys/fs/bcache.
Утилита bcacheadm имеет тринадцать основных параметров, но пока работают не все. Например, список устройств выдаст bcacheadm list.
Вывод
Даже простые тесты показывают, что использование связки SSD + HDD дает существенный прирост производительности. В разных ситуациях различные решения приносят свой результат, поэтому следует ориентироваться на конкретную нагрузку и возможность простого развертывания. Bcachefs, вероятно, пока рано рекомендовать для продакшна. Но начинание весьма интересно, и главное, что, в отличие от конкурентов, проект активно развивается.
