Кеш для виртуализации

Если используется zfs, то, очевидно, нужно использовать l2arc.

та вот перед выбором стою mdadm + lvm или zfs
мне просто интересует как кеш с блочными устройствами для виртуализации работает. Сейчас крутятся все виртуалки на ssd но хочется купить 4 винта по 2 тб. собрать 10 рейдом и добавить кеш в виде SSD гигов так на 512, вот и хочу узнать есть ли в этом смысл, так как до этого с вопросом кеша никогда не заморачивался

та вот перед выбором стою mdadm + lvm или zfs

Мой выбор - zfs. Сколько памяти на сервере?

собрать 10 рейдом и добавить кеш в виде SSD гигов так на 512, вот и хочу узнать есть ли в этом смысл

Касательно zfs, l2arc очень эффективно кэширует запросы на чтение, чтобы ускорит запись нужно выносить ZIL на отдельный диск.

памяти 32 гб. У меня был случай что при использовании zfs забивалась вся память и при выключении виртуалок не освобождалась, я так понимаю это из за того что автоматом включен ARC, его же можно отключить ?
Вы предлагаете zil еще на 1 SSD вынести ? Впринципе это возможно, а как с выключением питание и тд у него ?
P.S: кстати, есть ли смысл использовать дедупликацию при использовании виртуализации на блочных устройствах и как она ведет при потери питания ?

У меня был случай что при использовании zfs забивалась вся память

Ну так ограничить же можно через zfs_arc_max.

В ZoL 0.6.5.3 просадка чтения досадная, https://github.com/zfsonlinux/zfs/issues/3950

а как с выключением питание и тд у него ?

С выключением питания у него UPS, который всегда должен быть.

кстати, есть ли смысл использовать дедупликацию при использовании виртуализации на блочных устройствах

Лучше не надо, если точно не знаешь, что делаешь.

памяти 32 гб.

Для zfs более чем достаточно.

У меня был случай что при использовании zfs забивалась вся память и при выключении виртуалок не освобождалась

Она автоматом освободится при необходимости, но можно ограничить arc через параметр zfs_arc_max.

так понимаю это из за того что автоматом включен ARC, его же можно отключить

Отключить его можно, но не нужно, так как никакого другого кэша у zfs нет.

Вы предлагаете zil еще на 1 SSD вынести ?

Только в том случае, если именно запись является узким местом, в общем зависит от конкретной ситуации, чаще всего вынос ZIL не даёт эффекта.

есть ли смысл использовать дедупликацию

Моё мнение - нет.

ну вот такая штука была, я выключил все виртуалки и вот http://i.imgur.com/IR6RJBW.png

«Отключить его можно, но не нужно, так как никакого другого кэша у zfs нет.» я имел ввиду не l2arc, а arc(ОЗУ кеш) или одно без другого не работает ?

P.S: спасибо за консультацию

ну а если БП накрылся, только ежедневный бекап спасет ?

ну вот такая штука была, я выключил все виртуалки и вот

Если каким то процессам понадобится эта память arc её отдаст.

я имел ввиду не l2arc, а arc(ОЗУ кеш) или одно без другого не работает ?

zfs без arc встанет колом, нельзя его отключать, даже l2arc не поможет, они должны работать вместе.

ну а если БП накрылся, только ежедневный бекап спасет ?

Во-первых, между предложением и знаком вопроса пробел не ставится.

Во-вторых, всегда старайтесь покупать сервера с двумя БП. Тем более для сервера виртуализации. Это дороже совсем ненамного, но зато очень выручает при проблемах с питанием или с одним из БП.

Она автоматом освободится при необходимости, но можно ограничить arc через параметр zfs_arc_max.

Вот тут, не согласен. Категорически. Оно себя очень чудным образом ведёт в виртуализованных окружениях. Получается вплоть до тройного кеширования. Кеш уровня ядра linux, кеш ARC, кеш виртуализованной ОС. В общем, первые два, я на фиг убрал. В противном случае, у меня приключалось по 10-20 гигабайт swap...

Оно себя очень чудным образом ведёт в виртуализованных окружениях.

Отлично себя ведёт в виртуализированных окружениях. Стоят несколько серверов по всему миру, несколько в DC, везде zfs/kvm под ubuntu/centos - всё отлично. Гости - в основном линукс и чуть-чуть винды. Везде кэш ограничен через zfs_arc_max.

Оно себя очень чудным образом ведёт в виртуализованных окружениях.

Согласен с Dimez, никаких чудес не наблюдаю, ограничиваю кэш через zfs_arc_max. Но был сервер, где zfs_arc_max забыли, тоже долго работало без глюков и свапов.

Не, не, друзья, если ограничить через: zfs_arc_max - всё ок! Я имею ввиду, что начинает всё свапиться, если всё оставить по дефолту, и скажем, с виртуалки 50 гиг слить данных.

У меня в целом, всё ок, до тех пор, пока я не начинаю делать backup машинок. Вот тут начинается попа, я снутри машинок, иногда по 10-50 гб. сливаю, и начинается swap

Во-вторых, всегда старайтесь покупать сервера с двумя БП. Тем более для сервера виртуализации. Это дороже совсем ненамного, но зато очень выручает при проблемах с питанием или с одним из БП.

год назад у гугла сгорело все питание в датацентре,спас только бекап,через сутки ковыряния дисков(и простоя) накатили недельный бекап

...каждый год пара хостингов рипаются по питюанию,и спасает только бекап

и да,тсу на вопрос про «как с потерей питания»-также как и в любой «большой системе»-раз в 100000000000 быстрее накатить бекап чем «ковырять» битые диски и пытаться то поднять часами а то и сутками(да я не юзаю сей софт,и не делаю виртуалок,я разрабатываю обычные серверные приложения для работы с бд,и по своему опыту-только бекап,пусть даже недельный-в тыщу раз лучше простоя)

Не, ну можно ещё в ногу себе пострелять из ружжа охотницкого, а потом жаловаться :-)

Я что-то разве говорил против бэкапов? Два БП - это своего рода RAID. А RAID != backup и никогда им не был.

Эм... Ну так, я про то, что кеш ARC, в линукс, довольно агрессивный! И просто так, не отдаст память. Это весьма, весьма важный момент.

Ну конечно же! И именно поэтому, если на сервере выполняются ещё и другие задачи кроме стораджа, его надо ограничить, а не отключить, это ж логично по-моему?

Это весьма важный момент, а не то, что он агрессивный :)

Это логично для ZoL. К примеру, там где zfs, исполняется в нативном виде, ARC = файловый кеш ОС.

Надо покрутить, кстати, солярку с нативным zfs. Спасибо, что напомнил.

так и есть, снова на новом серваке забыл ограничить, и все сожрало за неделю, как только ограничил до 512 мбайт, все стало хорошо

памяти 32 гб

это почти «ниочем»

железки дестопные

понятно. Впрочем, у меня у самого дома на выделенной машине с виртуализацией вообще всего 16 гиг. У себя там я выключил своп. Потому что линупс пытался закешировать данные виртуальной венды с торрентом внутри. Это был мрак и ужос. :MLOL:

День добрый, так вот хотел поинтересоваться
у вас как, zfs выдает блочное устройство под виртуалку и кеш при этом работает ?

Вот я например хочу сделать хранилище наа 4 тбайта из wdblack и добавить ему кешом 1 тб ssd, будет ли такое работать или чего то упустил ? (и под zil тоже надо 1тб выделить ?)

у вас как, zfs выдает блочное устройство под виртуалку

Нет, лежат qcow2-файлы на zfs.

Вот я например хочу сделать хранилище наа 4 тбайта из wdblack и добавить ему кешом 1 тб ssd, будет ли такое работать или чего то упустил ?

Конечно будет.

и под zil тоже надо 1тб выделить ?

Под ARC, видимо? ARC - оперативка, L2ARC - SSD. Очень грубо без дедупликации 1Tb дисков == 1Gb ARC.

виртуальной венды с торрентом внутри

Извращенец. Есть же православный transmission, накой костыли с вендой плодить?

мне так удобнее :P

ну вот человек написал
«Касательно zfs, l2arc очень эффективно кэширует запросы на чтение, чтобы ускорит запись нужно выносить ZIL на отдельный диск.»
я этот zil и имел ввиду

А, ну да. Я немного плаваю в формулировках у ZFS ;)

Не знаю, насколько оправданна будет zfs на одном диске + ssd в качестве кэша.

Хех, https://pve.proxmox.com/wiki/Storage:_ZFS утверждает, что ZIL и L2ARC можно на одном SSD помещать.

Ок. Спасибо за советы. И такой вопрос есть, будет ли кеш работать если хранилище будет отдельнфм и блочные устройства по iscsi будут выдаваться ?

Не знаю, по-идее, без разницы.

Хехе, у меня щас такой же выбор, решил снова zfs попробовать.

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

Уважаемые знатоки, помогите пожалуйста
King_Carlo
EvgGad_303

Смотря для чего тебе этот кэш, если только под виртуалки, то возможно будет лучше воткнуть локально в сервер.

а если все таки l2arc на хранилище будет и vol будет по iscsi предоставляться серверу, то кеш будет в таком случае работать ?

А чего ему не работать?

та вот жду винты, буду проверять. Кстати не подскажете как правильно протестировать что бы понять что кеш работает, а то все таки переживаю, одно дело создать vol и на той же машине виртуалку запустить, а другое дело этот vol по iscsi отдать другой машине ?
P.S: пожалуйста ответьте если не сложно
1. есть ли в ZOL команда которая показывает заполненость кеша l2arc ? 2. если я еще добавлю ZIL то тоже через iscsi все будет работать ?
3. Как вообще посчитать сколько надо кеша l2arc и zil для моих винтов(будет raid10 по 1тб = 2тб массив), чем больше тем лучше, все съест ?
4. Может zfs не лучшее решение для такой задачи и есть более лучшие варианты, вот присматриваюсь к quadstor например, можете дать совет ?

1. в zol фиг знает, DALDON вроде постил какой-то скрипт, но может то был arcstat.py из состава zol, но никто не мешает допилить.
2. по iscsi zil лучше локально имхо
3. надо смотреть статистику.
4. zol сам по себе не лучшее решение, на вкус и цвет

Большое спасибо за помощь

1.Никаких чудес, я постил arcstat.py. И просил показать результаты с серверов - в общем, у товарища, там 18% попадания в l2arc.

В общем случае, я не стал бы ждать (да и по своим результатам вижу), прироста производительности от l2arc.

2. Другое дело zil - да, штука очень годная. Но опять-же имеет смысл только на direct_sync операциях.

3. зависит от размера блока zvol. Сильно зависит. Чем больше размер, тем меньше надо ОЗУ для zfs будут другие возможности l2arc.

4. пришёл к выводу, что zol - всё ещё не очень стабилен на linux. Особенно в zvol варианте.

P.S. сейчас буду разворачиваться на lvmcache. Тоже решение местами так себе. Но... Пока стабильно, адекватно себя показывает.

так ты же без iscsi будешь делать без отдельного стораджа ?

так ты же без iscsi будешь делать без отдельного стораджа ?

Лично я - да. Я уже можно сказать сделал. Надо только машинки перетащить.

Делать связку zol+iscsi - ещё более рисковая идея, чем просто zol (ИМХО).

Если iscsi - то тогда, вполне возможно рассмотреть zfs, на opensolaris или freebsd. Только, и zil и l2arc - на стороне nix.

вот к этой идеи тоже подошел, дело в том что я все это на infiniband собираюсь делать, а в фре с этим туго. Жаль что под линукс так тяжко с zfs

зато на солярисе с этим отлично. серьезно, если есть деньги на IB, возьми нормальную соляру с родным zfs.

взять «нормальную соляру» это в смысле купить ?

дело в том что я все это на infiniband собираюсь делать, а в фре с этим туго

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

Nexenta Community Edition This is a free community version of a commercial storage product. This might be for you if Solaris is your thing.

Good * ZFS support * based on Open Solaris (now called Illumos). * free version limitations are quite generous (e.g. 18TB of storage) for home use * based on a commercial product, which can be a good thing for stability and support

Bad * Community edition is feature-limited and not for commercial installations. * Web GUI is convoluted and unattractive. * obnoxious initial configuration wizard * Unfamiliar (to some like me) underlying OS could make it hard to self-troubleshoot and support.