The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Использование FlashCache для кэширо..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Использование FlashCache для кэширо..."  +/
Сообщение от auto_tips (ok) on 26-Сен-11, 14:26 
Весной 2010 года компания Facebook [[http://www.opennet.dev/opennews/art.shtml?num=26440 открыла]] код проекта [[https://github.com/facebook/flashcache/ 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 подключаем репозитории [[http://fedoraproject.org/wiki/EPEL EPEL]] и репозиторий [[http://mirror.centos.org/centos/$releasever/updates/SRPMS/ 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-вызовов, описание которых можно найти в [[https://github.com/facebook/flashcache/blob/master/doc/flash... документации]].

URL: https://github.com/facebook/flashcache/blob/master/doc/flash... https://github.com/facebook/flashcache/blob/master/README-DKMS
Обсуждается: http://www.opennet.dev/tips/info/2629.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Ян Злобин email(ok) on 26-Сен-11, 14:26 
Бедняги.  Сколько ж костылей они придумали, чтобы MySQL мог работать в их масштабах.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Аноним (??) on 26-Сен-11, 17:48 
> Бедняги.  Сколько ж костылей они придумали, чтобы MySQL мог работать в
> их масштабах.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от KO on 26-Сен-11, 17:49 
В их масштабах все может работать только с костылями.

ВАШ КО

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от iZEN (ok) on 26-Сен-11, 22:44 
ZFS + кэширующие MLC SSD в L2ARC использовать не судьба?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Использование FlashCache для кэширования обращений к диску н..."  +1 +/
Сообщение от Crazy Alex (??) on 26-Сен-11, 23:40 
Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС, на которую портирована довольно-таки монструозная ФС из другой экзотической ОС. Монструозность и экзотичность почти автоматом означают большое количество ошибок. Солярис в плане надёжности (используется довольно слабо, но есть возможность получить качественную поддержку), но вариант на линуксе явно дешевле.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от iZEN (ok) on 27-Сен-11, 00:07 
> Если имеете в виду FreeBSD - то конторе размеров фейсбука наваять свой (довольно небольшой) велосипед к хорошо поддерживаемой и распространённой системе гораздо логичнее, чем возиться с довольно экзотической ОС

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

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

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

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

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

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

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Crazy Alex (ok) on 27-Сен-11, 15:08 
У фри распространённость несколько не та, что у соляриса или чпукса - по ним есть серьёзные курсы, сертификация и т.п. И для них доступна поддержка от производителя - не знаю, как оракловская, о о сановской я плохого не слышал. У линукса кое-что из поддержки тоже есть, плюс в силу распространённости гораздо меньше шанс нарваться на экзотические грабли, которых никто не знает.

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

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от iZEN (ok) on 27-Сен-11, 15:48 
> Что до объёма кода - сходу данных не нашел, а самому считать неохота.

Тут посчитали: http://www.linux.org.ru/jump-message.jsp?msgid=4936858&cid=4...
ZFS — 102033 строк;
Btrfs — 54758 строк;
LVM2 — 45633 строк;
Ext3 — 23567 строк;
Ext4 — 41348 строк;
XFS — 75621 строк.

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

LVM2 + XFS на 20% больше по объёму кода, чем "интегрированная" и более функциональная ZFS.

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

Как долго в продакшене LVM2 с Ext4?
21 октября 2008 Ext4 объявили стабильной (честно сказать, после этого ещё словили много глюков) — итого, всего три года использования, к-хм, в продакшене.
ZFS была представлена в OpenSolaris в ноябре 2005г., а в Solaris используется в продакшене с июня 2006 года — больше 5 лет практического использования.
У какой из технологий хранения данных больше срок практической эксплуатации?

> Не экспериментировать же фейсбуку на продакшне.

Чего "экспериментировать"? L2ARC работает на опережающее чтение часто используемых данных, а не на запись.

> ну и по поводу "сквозной целостности" туда же
> - критерий теории - практика. Пройдёт ещё года три, опробуют ZFS
> хорошенько разные энтузиасты, выявятся слабые места и баги - тогда и
> в серьёзные проекты можно. Как с XFS той же было.

Туда же — Цукерберг просто не видит в Linux тех технологий ускорения отдачи контента, которые уже есть в других операционных системах "из коробки". Цена портирования полновесной реализации ZFS в Linux слишком высока, и здесь, в первую очередь, встают не технические проблемы, а организационные: вряд ли Oracle позволит использовать ZFS в ядре "не его" дистрибутива Linux вследствие того, что это подорвёт продажи решений на основе Solaris. У поставщиков программно-аппаратных комплексов и комплектов решений, как у нормальных продавцов, рынок дистрибуции Linux искусственно сегментирован для увеличения объёмов продаж именно тех решений, которые востребованы покупателями. Как во всякой "правильной" продуктовой линейке, продавцы не делают единственный продукт со всеми интегрированными фичами, а разделяют его на отдельные (нишевые) решения, которые ни в коем случае не должны перетягивать клиентов друг у друга (не допускать конкуренции решений внутри продуктовой линейки). Этим обеспечивается большая прибыль и гибкость управления продажами/сопровождением.

Экстенсивный путь развития вырождается в "копроэкономику", когда продукты превращаются в однодневок, одноразового использования для быстрого решения какой-то задачи. Одновременно с этим ухудшается качество всей продуктовой линейки (зачем отлаживать код, если он больше нигде не используется, кроме как для решения определённой задачи?). Недостаток универсализма заставляет потребителей искать дополнительные "костыльные" решения, совмещать их с существующим продуктом.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Michael Shigorin email(ok) on 28-Сен-11, 10:46 
> Как долго в продакшене LVM2 с Ext4?

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

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

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Crazy Alex (??) on 28-Сен-11, 17:55 
20% разницы кода по сравнению с десятком, если не больше, лет вылизывания XFS на куче машин - копейки. LVM вообще только совсем уж ленивый не использует, по нему опыта тоже валом.

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

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

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от mnu (??) on 27-Сен-11, 18:53 
а в Dragonfly это искаропки...
Уже с год как? Или два?...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от superuser on 28-Сен-11, 00:38 
почти по теме, кто-нибудь заморачивался на тему raid1 with ramdisk? те объединяем в софтварный рэйд сверхбыстрый на чтение диск в ОЗУ и обычный накопитель для хранения данных. Например, такое нужно для некоторых файловых баз, размер которых не превышает 4гб.
немного погуглил, но никакой конкретики, везде предлагают купить SSD и не городить костыли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от me (??) on 28-Сен-11, 19:12 
запись в r1 считается завершенной после коммита на все устройства r1, на чтенние это чудо будет быстрым, но pagecahe все равно быстрее (и вам кстати придется писать/читать его O_DIRECT, иначе будет вам двойной оверхед памяти, хотя че там... "память нынче дешевая")
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от name (??) on 28-Сен-11, 19:23 
Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.
также понятно, что запись будет с обычной скоростью, но скорость чтения должна вырасти раз в 100.
>"память нынче дешевая"

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от me (??) on 28-Сен-11, 19:44 
> Понятно, что pagecahe будет быстрее, но только он не работает с древними базами в виде туевой хучи DBF-файлов.

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от XoRe (ok) on 29-Сен-11, 01:16 
> Понятно, что pagecahe будет быстрее, но только он не работает с древними
> базами в виде туевой хучи DBF-файлов.
> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
> вырасти раз в 100.

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Аноним (??) on 06-Окт-11, 21:48 
>> Понятно, что pagecahe будет быстрее, но только он не работает с древними
>> базами в виде туевой хучи DBF-файлов.
>> также понятно, что запись будет с обычной скоростью, но скорость чтения должна
>> вырасти раз в 100.
> Если вы используете современную БД, то, будучи правильно настроенно, она и так
> держит нужные данные в оперативке.
> А если у вас БД, которая работает только на файлах, можно вообще
> иметь диск только в оперативке.
> С rsync раз в минуту на жесткий диск.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

26. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Kapanir email(??) on 16-Окт-11, 16:00 
Посмотрите в сторону Gigabyte i-RAM
или
http://www.acard.com.tw/english/fb01-product.jsp?idno_no=382...
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

19. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от 1 (??) on 29-Сен-11, 16:57 
поставь много памяти и прочитай эти базы разок они будут в кеше системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее и никаких рейдов :)
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от Аноним (??) on 06-Окт-11, 21:49 
> поставь много памяти и прочитай эти базы разок они будут в кеше
> системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
> и никаких рейдов :)

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

24. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от XoRe (ok) on 08-Окт-11, 16:31 
>> поставь много памяти и прочитай эти базы разок они будут в кеше
>> системы + можно поискать настройки подшаманить чтоб файловый кэш был поболее
>> и никаких рейдов :)
> И посмотри на скорость базы в пару терабайт целиком в памяти.

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Использование FlashCache для кэширования обращений к диску н..."  +/
Сообщение от ирпоитимиа on 11-Окт-11, 07:33 
Неужели нельзя обойтись ОЗУ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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