The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Использование FlashCache для кэширования обращений к диску на высокоскоростном SSD-накопителе
Весной 2010 года компания Facebook открыла код проекта FlashCache,
представляющего собой модуль для ядра Linux, позволяющий заметно ускорить
работу MySQL и других интенсивно работающих с диском приложений. Увеличение
производительности достигается за счет организации процесса прозрачного
кэширования наиболее активно используемых данных на быстрых SSD-накопителях.

С точки зрения организации работы ничего не меняется, добавляется новое блочное
устройство, которое при чтении выдает данные из быстрого кэша, а при записи
дублирует их в кэше и на диске, обеспечивая прежний уровень надежности.
Поддерживается также менее надежный режим увеличения скорости записи, при
котором сначала осуществляется запись на хранилище SSD, а затем в фоне
производится  синхронизация данных на обычное хранилище. Поддерживаются функции
зеркалирования кэша на несколько SSD-накопителей и  задействование команды ATA
TRIM для более оптимального распределения данных по SSD.


Установка.

Устанавливаем сопутствующие пакеты для Debian/Ubuntu:

   $ apt-get install git-core dkms build-essential linux-headers-`uname -r`


Для CentOS/RHEL подключаем репозитории EPEL и репозиторий SRPMS.
Устанавливаем необходимые пакеты:

   $ yum install dkms gcc make yum-utils kernel-devel

Так как для сборки FlashCache требуются некоторые внутренние заголовочные
файлы, которые не входят в состав пакета kernel-headers/devel требуется
загрузить и установить полный код ядра:

   $ yumdownloader --source kernel-`uname -r`
   $ sudo rpm -ivh kernel-`uname -r`.src.rpm

Загружаем исходные тексты FlashCache:

   $ git clone https://github.com/facebook/flashcache.git

Работа FlashCache протестирована с ядрами Linux с 2.6.18 по 2.6.38, для более
новых ядер могут наблюдаться проблемы.

Собираем модуль с использованием DKMS (Dynamic Kernel Module Support):

   $ cd flashcache
   $ sudo make -f Makefile.dkms

   install -o root -g root -m 0755 -d /var/lib/dkms/flashcache/1.0-101-g4bceda86d13d/source
   rsync -r src/ /var/lib/dkms/flashcache/1.0-101-g4bceda86d13d/source/
   sed "s/PACKAGE_VERSION=/PACKAGE_VERSION=1.0-101-g4bceda86d13d/" src/dkms.conf > "/var/lib/dkms/flashcache/1.0-101-g4bceda86d13d/source/dkms.conf"
   dkms build -m flashcache -v 1.0-101-g4bceda86d13d

   Kernel preparation unnecessary for this kernel.  Skipping...

   Building module:
   cleaning build area....
   KERNEL_TREE=/lib/modules/2.6.32-33-generic/build make modules.......
   cleaning build area....

   DKMS: build Completed.
   make -C src/utils install
   ...
   install -d -m 755 /sbin/
   install -m 755 flashcache_create flashcache_destroy  flashcache_load /sbin/
   make[1]: Выход из каталога `/home2/home/mc/soft/flashcache/flashcache/src/utils'
   dkms install -m flashcache -v 1.0-101-g4bceda86d13d

   flashcache.ko:
   Running module version sanity check.
    - Original module
      - No original module exists within this kernel
    - Installation
      - Installing to /lib/modules/2.6.32-33-generic/updates/dkms/

   depmod.........

   Updating initrd
   Making new initrd as /boot/initrd.img-2.6.32-33-generic
   (If next boot fails, revert to the .bak initrd image)
   update-initramfs....

все, теперь модуль flashcache.ko установлен и готов к использованию.


Режимы кэширования

Поддерживается три режима кэширования:

Writethrough - самый надежный режим, при котором все операции записи сразу
переносятся на диск и сохраняются на SSD. Кэшируются только операции записи.
При перезагрузке или при отключении накопителя содержимое кэша не теряется и
может быть использовано сразу, без траты дополнительного времени на его заполнение.

Writearound - надежный режим, при котором данные при выполнении операции записи
сохраняются только на диск и не отражаются на SSD. Кэш на SSD-накопителе
обновляется только на основании выполнения операций чтения с диска (кэшируются
только операции чтения). Режим подходит в ситуации, когда запись на диск
производится быстрее, чем на SSD. После перезагрузки или отключения накопителя
кэш начинает заполняться с нуля.

Writeback - наиболее быстрый, но менее надежный режим. Данные вначале
записываются на SSD, а потом в фоне перекидываются на диск. Кэшируются как
операции записи, так и чтения. При экстренном отключении питания не исключено
пропадание не синхронизированных на диск данных.



Использование

Для управления FlashCache подготовлены три утилиты:

flashcache_create - создание нового дискового раздела с кэшированием;

flashcache_load - подключение ранее созданного раздела с кэшем в режиме  writeback;

flashcache_destroy - очистка содержимого кэша, созданного в режиме  writeback.

Для режимов writethrough и writebehind утилиты flashcache_load и
flashcache_destroy не требуются, так как кэш очищается при переподключении раздела.


Предположим, что в системе имеется жесткий диск /dev/sdb и быстрый
SSD-накопитель /dev/sdc. Для организации кэширования в режиме writeback, с
размером блока 4 Кб и общим размером кэша 1 Гб следует выполнить:

   flashcache_create -p writeback -s 1g -b 4k cachedev /dev/sdc /dev/sdb

После выполнения этой команды будет создано виртуальное блочное устройство с
именем "cachedev", при монтировании раздела через которое будет автоматически
использовано кэширование.

Для загрузки прошлого содержимого кэши или очистки кэша в режиме writeback можно выполнить команды:

   flashcache_load /dev/sdc
   flashcache_destroy /dev/sdc

Для удаления и просмотра статистики для уже созданных виртуальных блочных
устройств следует использовать утилиту dmsetup.

Удаляем устройство cachedev:

   dmsetup remove cachedev

Смотрим статистику:

   dmsetup status cachedev
   dmsetup table cachedev

или 

   cat /proc/flashcache/cachedev/flashcache_errors
   cat /proc/flashcache/cachedev/flashcache_stats

Для тонкого управления режимами кэширования поддерживается большое число
специальных sysctl-вызовов, описание которых можно найти в документации.
 
Ключи: flashcache, cache, disk, ssd, block, speed, optimization / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Диски и файлы / Файловые системы

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Ян Злобин (ok), 14:26, 26/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Бедняги.  Сколько ж костылей они придумали, чтобы MySQL мог работать в их масштабах.
     
     
  • 2.2, Аноним (-), 17:48, 26/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Бедняги.  Сколько ж костылей они придумали, чтобы MySQL мог работать в
    > их масштабах.

    Этот костыль никак не привязанк к мускулу. Вообще.

     
  • 2.3, KO (?), 17:49, 26/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В их масштабах все может работать только с костылями.

    ВАШ КО

     

  • 1.4, iZEN (ok), 22:44, 26/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ZFS + кэширующие MLC SSD в L2ARC использовать не судьба?
     
     
  • 2.5, Crazy Alex (??), 23:40, 26/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС, на которую портирована довольно-таки монструозная ФС из другой экзотической ОС. Монструозность и экзотичность почти автоматом означают большое количество ошибок. Солярис в плане надёжности (используется довольно слабо, но есть возможность получить качественную поддержку), но вариант на линуксе явно дешевле.
     
     
  • 3.6, iZEN (ok), 00:07, 27/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС

    FreeBSD довольно распространённая ОС из всех Unix-подобных. Так что поддержка и сопровождение не составят огромного труда по сравнению, скажем, с теми же AIX, HP-UX или Solaris.

    >, на которую портирована довольно-таки монструозная ФС из другой экзотической ОС.

    ZFS не монструознее XFS (по объёму кода), отлажена и документирована весьма качественно.

    > Монструозность и экзотичность почти автоматом означают большое количество ошибок.

    Если система не писалась с расчётом на обеспечение отказоустойчивости и живучести, то даже критические ошибки в ней — обычное дело. Во главу угла при разработке ZFS ставилась надёжность и непротиворечивость.

    > Солярис в плане надёжности (используется довольно слабо, но есть возможность получить качественную поддержку), но вариант на линуксе явно дешевле.

    Вариант на традиционных ФС линукса не обеспечивает той надёжности и живучести, что обеспечивается в ZFS изначально. Нету в линуксе сквозной целостности данных, как ни прикручивай костыли.

     
     
  • 4.9, Crazy Alex (ok), 15:08, 27/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У фри распространённость несколько не та, что у соляриса или чпукса - по ним есть серьёзные курсы, сертификация и т.п. И для них доступна поддержка от производителя - не знаю, как оракловская, о о сановской я плохого не слышал. У линукса кое-что из поддержки тоже есть, плюс в силу распространённости гораздо меньше шанс нарваться на экзотические грабли, которых никто не знает.

    Что до объёма кода - сходу данных не нашел, а самому считать неохота. Но из общих соображений - сомнительно, учитывая, что zfs включает в себя кучу функционала, которого в XFS той же нет.

    А критерий "обеспечения отказоустойчивости и живучести" - практика и только практика. И практики использования у более традиционных XFS, Ext3 (да, пожалуй, уже и Ext4) и нижележащих LVM и raid много больше. Не экспериментировать же фейсбуку на продакшне. ну и по поводу "сквозной целостности" туда же - критерий теории - практика. Пройдёт ещё года три, опробуют ZFS хорошенько разные энтузиасты, выявятся слабые места и баги - тогда и в серьёзные проекты можно. Как с XFS той же было.

     
     
  • 5.10, iZEN (ok), 15:48, 27/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тут посчитали http www linux org ru jump-message jsp msgid 4936858 cid 494444... большой текст свёрнут, показать
     
     
  • 6.13, Michael Shigorin (ok), 10:46, 28/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Как долго в продакшене LVM2 с Ext4?

    LVM много для чего избыточен.

    > ZFS была представлена в OpenSolaris в ноябре 2005г., а в Solaris используется
    > в продакшене с июня 2006 года — больше 5 лет практического использования.
    > У какой из технологий хранения данных больше срок практической эксплуатации?

    Вам опять напомнить про приплыв того же joyent (на солярке, а не левой с точки зрения разработчика операционке)?  Постеснялись бы хоть.

     
  • 6.14, Crazy Alex (??), 17:55, 28/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    20% разницы кода по сравнению с десятком, если не больше, лет вылизывания XFS на куче машин - копейки. LVM вообще только совсем уж ленивый не использует, по нему опыта тоже валом.

    Кроме "как долго" есть ещё понятие "у скольких людей". Суммарная доля установок bsd и соляриса во сколько раз меньше линукса? В сто? В тысячу? Поэтому хотя ext4 и свежее, она УЖЕ оттестирована лучше. И дальше разница будет только нарастать.

    ZFS для линукс есть, как все прекрасно знают. Но пока оно дойдёт до примемлемого уровня надёжности опять-таки пара лет пройдёт.

    А "копроэкономика" - это полагаться на систему, которую поддерживает десять человек и полторы фирмы вместо альтернативы, которую клепает весь мир. Тогда на выходе только "копро" и будет.

     

  • 1.11, mnu (??), 18:53, 27/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а в Dragonfly это искаропки...
    Уже с год как? Или два?...
     
  • 1.12, superuser (?), 00:38, 28/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    почти по теме, кто-нибудь заморачивался на тему raid1 with ramdisk? те объединяем в софтварный рэйд сверхбыстрый на чтение диск в ОЗУ и обычный накопитель для хранения данных. Например, такое нужно для некоторых файловых баз, размер которых не превышает 4гб.
    немного погуглил, но никакой конкретики, везде предлагают купить SSD и не городить костыли.
     
     
  • 2.15, me (??), 19:12, 28/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    запись в r1 считается завершенной после коммита на все устройства r1, на чтенние это чудо будет быстрым, но pagecahe все равно быстрее (и вам кстати придется писать/читать его O_DIRECT, иначе будет вам двойной оверхед памяти, хотя че там... "память нынче дешевая")
     
     
  • 3.16, name (??), 19:23, 28/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.
    также понятно, что запись будет с обычной скоростью, но скорость чтения должна вырасти раз в 100.
    >"память нынче дешевая"

    именно, 4 гига оперативы нынче это уже немного устаревший сервер, а сама файловая база занимает не более этого объема, прирост производительности должен же быть.

     
     
  • 4.17, me (??), 19:44, 28/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.

    серьезно? хмм... а я-то думал, ему пофиг какие блоки кэшировать... хоть дидями читай.

     
  • 4.18, XoRe (ok), 01:16, 29/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Понятно, что pagecahe будет быстрее, но только он не работает с древними
    > базами в виде туевой хучи DBF-файлов.
    > также понятно, что запись будет с обычной скоростью, но скорость чтения должна
    > вырасти раз в 100.

    Если вы используете современную БД, то, будучи правильно настроенно, она и так держит нужные данные в оперативке.
    А если у вас БД, которая работает только на файлах, можно вообще иметь диск только в оперативке.
    С rsync раз в минуту на жесткий диск.

     
     
  • 5.21, Аноним (-), 21:48, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Понятно, что pagecahe будет быстрее, но только он не работает с древними
    >> базами в виде туевой хучи DBF-файлов.
    >> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
    >> вырасти раз в 100.
    > Если вы используете современную БД, то, будучи правильно настроенно, она и так
    > держит нужные данные в оперативке.
    > А если у вас БД, которая работает только на файлах, можно вообще
    > иметь диск только в оперативке.
    > С rsync раз в минуту на жесткий диск.

    Попробуй 1 Тб базу целиком в оперативку засунуть? И - когда сможешь - расскажи о производительности, ага?

     
     
  • 6.23, XoRe (ok), 16:29, 08/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>> базами в виде туевой хучи DBF-файлов.
    >>> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
    >>> вырасти раз в 100.
    >> Если вы используете современную БД, то, будучи правильно настроенно, она и так
    >> держит нужные данные в оперативке.
    >> А если у вас БД, которая работает только на файлах, можно вообще
    >> иметь диск только в оперативке.
    >> С rsync раз в минуту на жесткий диск.
    > Попробуй 1 Тб базу целиком в оперативку засунуть? И - когда сможешь
    > - расскажи о производительности, ага?

    Человек написал:
    > Например, такое нужно для некоторых файловых баз, размер которых не превышает 4гб.

    Мой совет был только ему.
    Чукча не читатель, чукча писатель, да?)

     
  • 4.26, Kapanir (??), 16:00, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите в сторону Gigabyte i-RAM
    или
    http://www.acard.com.tw/english/fb01-product.jsp?idno_no=382&prod_no=ANS-9010
     
  • 2.19, 1 (??), 16:57, 29/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    поставь много памяти и прочитай эти базы разок они будут в кеше системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее и никаких рейдов :)
     
     
  • 3.22, Аноним (-), 21:49, 06/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > поставь много памяти и прочитай эти базы разок они будут в кеше
    > системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
    > и никаких рейдов :)

    И посмотри на скорость базы в пару терабайт целиком в памяти.

     
     
  • 4.24, XoRe (ok), 16:31, 08/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> поставь много памяти и прочитай эти базы разок они будут в кеше
    >> системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
    >> и никаких рейдов :)
    > И посмотри на скорость базы в пару терабайт целиком в памяти.

    Имеете базу в 1 Тб и пытаетесь применять советы для базы в 4 Гб?
    Экий вы злобный буратино)

     

  • 1.25, ирпоитимиа (?), 07:33, 11/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неужели нельзя обойтись ОЗУ
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру