Сегодня тестовый день SSD Cache (bcache)

Интересная технология. Попробую.

В ближайшем будующем

упс. очепятка. пофиксил. спасибо.

Поздно. У меня нет ни одного компьютера, где использовались бы как жесткие диски, так и SSD.

а что тогда используется?

я думаю, что SSD ;)

Бездисковые станции? Ну, на сервере-то всё равно жёсткие диски есть.

Очевидно же, кэшируй медленные SSD более быстрыми.

Я один упустил, или в тексте новости НЕ написано, ЧТО это вообще ТАКОЕ?.. И для чего нужно? Или для чего не нужно?..

да. как-то не подумал перевести.

Bcache is a Linux kernel block layer cache. It allows one or more fast disk drives such as flash-based solid state drives (SSDs) to act as a cache for one or more slower hard disk drives.

Hard drives are cheap and big, SSDs are fast but small and expensive. Wouldn't it be nice if you could transparently get the advantages of both? With Bcache, you can have your cake and eat it too.

Bcache patches for the Linux kernel allow one to use SSDs to cache other block devices. It's analogous to L2Arc for ZFS, but Bcache also does writeback caching (besides just write through caching), and it's filesystem agnostic. It's designed to be switched on with a minimum of effort, and to work well without configuration on any setup. By default it won't cache sequential IO, just the random reads and writes that SSDs excel at. It's meant to be suitable for desktops, servers, high end storage arrays, and perhaps even embedded.

The design goal is to be just as fast as the SSD and cached device (depending on cache hit vs. miss, and writethrough vs. writeback writes) to within the margin of error. It's not quite there yet, mostly for sequential reads. But testing has shown that it is emphatically possible, and even in some cases to do better - primarily random writes.

It's also designed to be safe. Reliability is critical for anything that does writeback caching; if it breaks, you will lose data. Bcache is meant to be a superior alternative to battery backed up raid controllers, thus it must be reliable even if the power cord is yanked out. It won't return a write as completed until everything necessary to locate it is on stable storage, nor will writes ever be seen as partially completed (or worse, missing) in the event of power failure. A large amount of work has gone into making this work efficiently.

Bcache is designed around the performance characteristics of SSDs. It's designed to minimize write inflation to the greatest extent possible, and never itself does random writes. It turns random writes into sequential writes - first when it writes them to the SSD, and then with writeback caching it can use your SSD to buffer gigabytes of writes and write them all out in order to your hard drive or raid array. If you've got a RAID6, you're probably aware of the painful random write penalty, and the expensive controllers with battery backup people buy to mitigate them. Now, you can use Linux's excellent software RAID and still get fast random writes, even on cheap hardware.

Ну не обязательно всё, можно было один абзац в конце выделить... и объяснить парой предложений.

Судя по тому, что на официальном сайте, не уверен, что есть смысл... можно же просто заменить все HDD на SSD. А где нельзя (в силу громадных объёмов данных), SSD тут особо и не поможет, тут надо побольше оперативки под кэш диска, да и всё... Быстрее оперативки SSD ведь не будет?

вот на русском: http://www.opennet.ru/opennews/art.shtml?num=35849

можно же просто заменить все HDD на SSD

для десктопа не особо актуально, где есть игрульки (например) да и для high-load серверов тоже не очень.

тут надо побольше оперативки под кэш диска, да и всё

сравни сколько стоит SSD на 256 GiB и RAM на 256 GiB + ещё сколько-то нужно для самого сервера.

Быстрее оперативки SSD ведь не будет?

это не особо актуально ИМХО в данных юзкейсах

тут из зала кричат, что можно сделать кэш двух уровней: HDD=> L2-SSD, L1-RAM

а третий уровень отберём у процессора :D

вот ещё история успеха с bcache с хабра: http://habrahabr.ru/post/182372/

+ если хочешь уточнить какие-то низкоуровневые моменты - ткни сегодня у нас главного разработчика bcache ;)

До какого числа результаты принимаются? Я завтра/послезавтра на нескольких машинках потестю

не эффективно ли с точки зрения живости SSD пенести write-only-данные (типа логов) и своп на механический диск?

результаты принимаются всегда, но главный разработчик bcache на нашем канале в irc будет только сегодня.. + на вопросы не в тестовый день я или Rolf можем отвечать с задержкой

не эффективно ли с точки зрения живости SSD перенести write-only-данные (типа логов) и своп на механический диск?

Ну чего вы сразу строите предположения о том, что у меня? :)

Старый домашний компьютер (в старой квартире): да, там жесткий диск, один, на 250 GB. Но этому компьютеру уже 6 лет, обновлять - так целиком.

Рабочий компьютер (Asrock): раньше там был жесткий диск. Он примерно полгода назад посыпался, а директор «развел» меня на SSD. Так что там сейчас SSD на 512 GB, и пока все влезает. Из-за форм-фактора корпуса поставить второй диск не получится.

Ноутбук (Sony): «из коробки» RAID0 из двух SSD по 256 GB. Доустановка вообще чего бы то ни было не предусмотрена.

Новый домашний компьютер (в новой квартире): SSD на 512 GB. Поставлен по принципиальным соображениям - домашний компьютер должен быть абсолютно бесшумным, поэтому никаких жестких дисков там не будет.

NAS: к маршрутизатору ASUS RT-N66U подключен по USB жесткий диск на 3 TB. SSD тут вообще не нужен, т.к. производительность упирается в SAMBA-сервер или в USB. Ну и сборки fedora для этого маршрутизатора нет :)

Как раз для игрулек вполне себе актуально, а вот для high-load наверное нет.

Если уж так, то тогда первые три кэша - в процессоре, четвёртый - оперативки, и уже пятый SSD, шестой HDD. :) А седьмой - сетевые каталоги NFS/Samba. (то есть седьмой не кэш и уже вовсе).

Сегодня тестовый день SSD Cache (bcache)

Это такой способ оттянуть внимание от новенького flashcache 3.0 с кучей киллер-фич?

Там есть защита от грохинга системы?

на самом деле flashcache фигня:

• его нет в upstream kernel
• работает он криво

смотря что ты хочешь. когда у тебя теряется то, на что кешировать - данные не пропадают и всё работает

Точнне, ещё точнне!

Мне нужно что-то типо центра стабилизирования, там есть такое?

фигня:
его нет в upstream kernel

Пока нет.

работает он криво

Т.е. Facebook делает упор в своём хайлоуде на кривой модуль кеширования, да?

http://www.opennet.ru/opennews/art.shtml?num=38133

Пока нет.

вот как будет (если будет), тогда и поговорим.

Т.е. Facebook делает упор в своём хайлоуде на кривой модуль кеширования, да?

а ubuntu делает упор на кривой mir, да ?

надеюсь ты понял к чему я.. опять же учти, что я все пишу свои сообщение исходя из своего личного мнения.

хм. что это ? дай линк почитать.

а ubuntu делает упор на кривой mir, да ?

Да это пример из другой степи. Нельзя сравнивать xсервер с модулем кеширования который крутится 24/7 на продакшн 100500 серверах.

Упадёт mir на каком-нибудь очередном ноуте любопытного тестера - напишут багрепорт, ему ответят A team of highly trained monkeys has been dispatched to deal with this situation., он ребутнёт и продолжит работать.

опять же учти, что я все пишу свои сообщение исходя из своего личного мнения.

Мнения или _опыта_ относительно кривости flashcache?

я намедни потыкал этот flashcache. у меня пару раз были глюки с ним (например нерабочий гибернейт), но багрепорты я слать не собираюсь из-за того, что нет их в апстримном ядре

http://meetbot.fedoraproject.org/fedora-test-day/2013-10-13/fedora-test-day.2...

http://meetbot.fedoraproject.org/fedora-test-day/2013-10-13/fedora-test-day.2...

почитай вкратце.

там 100%й баг есть. чтобы проверить именно работу bcache - нужно поставить ядро 3.12. в логах ссылки на билдсервер и на багзиллу прилагаются.

Что за дешёвые понты?

И там даже баг с тримом журнала пофиксили?

кто все эти люди ?

Нельзя сравнивать xсервер с модулем кеширования который крутится 24/7 на продакшн 100500 серверах.

можно, этот фейсбуковый «продакшн» ничем не отличается от ноута очередного васи пупкина с mir на борту - точно так же всё падает и пропадают каменты/посты, и в фидер выползают посты месячной давности.

В ноутах много где есть. 4гига на ssd и террабайт на диске.

В ноутах много где есть. 4гига на ssd и террабайт на диске.

Вот у кого такой ноут, тот пусть и тестирует.

у нас появилось гламурное веб приложение для отправки результатов ))

http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=8

оно будет работать в течение недели

на самом деле всё можно тестить и на хдд и на флешке и в виртуалке и всё это можно друг с другом мешать. софту пофиг ссд у тебя или нет

Отлично!

Вечером затестю на 4-х сервачках :)

Судя по тому, что на официальном сайте, не уверен, что есть смысл...

Зависит от характера нагрузки. Особенно эфективно это будет работать при следующих условиях:

- суммарный объем данных большой, а объём активно используемых данных не очень большой (относительно суммарного объёма).

- преобладающий характер нагрузки - random read.

Под такой профиль нагрузки как правило попадают все биллинговые системы, образы виртуалок (например для VDI) и ещё много чего по мелочи.

можно же просто заменить все HDD на SSD. А где нельзя (в силу громадных объёмов данных), SSD тут особо и не поможет

Поможет.

Хардкорный Ынтерпрайз это давно просёк и выпустил софт, который называется EMC XtremSW (пруф: http://russia.emc.com/storage/xtrem/xtremsw-cache.htm).

Как вариант этого решения есть FAST Cache - та же самая идея реализованая на уровне массива (пруф: http://russia.emc.com/corporate/glossary/fast-cache.htm). Аналоги FAST Caсhe есть у IBM и NetApp, про аналоги XtremSW не знаю.

Кстати на массивах (у разных вендоров) реализована ещё одна интересная фича: FAST VP (пруф: http://russia.emc.com/storage/symmetrix-vmax/fast.htm). Если коротко, то на массиве создаётмя трёхуровневый пул дисков (три типа дисков SSD, SAS, SATA) и наиболее активные данние автоматически перемещаются на более быстрые диски. Подробности расписаны здесь: http://russia.emc.com/collateral/software/white-papers/h8058-fast-vp-unified-...

тут надо побольше оперативки под кэш диска, да и всё... Быстрее оперативки SSD ведь не будет?

Разоришся на памяти для больших баз. К тому же начиная с некоторого объёма очень часто вступают в силу граничения заложенные в софте.

PS0: в качестве примеров везде привёл железо и софт от EMC т.к. с ним более часто сталкиваюсь по работе. Остальных вендоров знаю много хуже. Не сочтите за рекламу.

PS1: Как и у всего Ынтерпрайза цены там прямо скажем не маленькие. Поэтому не удивлён, что нашлись люди, которые сделали OpenSource реализацию полезной фичи. Успехов им.

Понятно, раз в суровом Ынтерпрайзе это уже есть и работает эффективно, то был не прав. =) Будет интересно увидеть тоже самое в опенсурсе.

для десктопа не особо актуально, где есть игрульки (например) да и для high-load серверов тоже не очень.

Я не знаю чты ви есть понимайт под хай лоад конкретно, но для хостов с KVM очень в кассу было бы. Кэширование ввода-вывода посредством локальных SSD, плюс SSD флеш-пул диски как еще один кэш СХД, наимоднеший тренд. Один из юз кейз, уменьшение импакта бутшторма VDI. Второй, хосты с высоким мемори оверкоммитмент, когда балунинг вытесняет весь локальный кэш из памяти гостевых систем. Да и просто еще один кэш ввод вывод оживляет довольно весомо. Вообще, я б реквестировал в тренд dyasny, на тему живет ли это с RHEV, а если не живет, то планируеццо ли. А то я в кухне Шляпы не очень ориентируюсь.

на самом деле RedHat не очень то хотел в lvm2 принимать поддержку bcache ибо они за dm-cache, но увы. пришлось, т.к. fesco приняли bcache как self-contained фичу. так что думаю в rhev 8 оно будет поддерживаться, но больший приоритет всё равно будет уделяться dm-cache

на массиве создаётмя трёхуровневый пул дисков

Аутотиринг на уровне стораджа вещь очень в себе на самом то деле и для быстро изменяющихся данных может не подойти вовсе. Межделмашевский изи тиер, к примеру, реаллокейтит горячую дату на SSD раз в сутки итд, итп. .

Но это сторадж, в сабже же речь идет, как я понял о локальном кэше на стороне хоста. Я из аналогичных, навскидку могу назвать только несколько реализации для VMWare, и вендор-лок реализации типа НетАпповского Flash Accel, FlashSoft и IBM FCSA

но больший приоритет всё равно будет уделяться dm-cache

Архитектурно это более верный путь. bcache выглядит, как заплатка на скорую руку.

не эффективно ли с точки зрения живости SSD

С живостью у ссд давно все ок. К тому же, bcache в первую очередь для хранилок сделан, а как правило купить новую ссд для хранилки, где их и так уже от 10 до 80 - не такая уж и большая трата. Так что два раза пофигу на время жизни.

да и для high-load серверов тоже не очень.

Как раз таки очень. Гибридные хранилки давно уже есть. Более того, zfs так это вапще тыщу лет умеет, а мы все заплатки в линуксах клеем.