кеш zfs на SSD

Sergey Anohin написал(а) к All в Apr 17 12:09:37 по местному времени:

Нello All
Есть ли смысл в сабже? На сколько пpоизводительность будет выше?

Bye, , 13 апpеля 17
--- FIPS/IP <build 01.14>

Nikolay Linkevich написал(а) к Sergey Anohin в Apr 17 19:35:39 по местному времени:

Нello, Sergey!

SA> Есть ли смысл в сабже? На сколько пpоизводительность будет выше?

Есть смысл. Как минимум, часто используемые данные в большем количестве будут доступны на высокой скорости.
К тому же можно будет снизить нагрузку на RAM. У меня сейчас RAID10 на ZFS с SSD под кеш и логи.
Прирост ощутимый. К тому же машина исполняет роль гипервизора и память нужна не только ZFS.

С наилучшими пожеланиями, Nikolay Linkevich.

--- wfido

Sergey Anohin написал(а) к Nikolay Linkevich в Apr 17 20:11:42 по местному времени:

Нello Nikolay* *Linkevich
SA>> Есть ли смысл в сабже? На сколько пpоизводительность будет выше?
NL> Есть смысл. Как минимум, часто используемые данные в большем количестве
NL> будут доступны на высокой скоpости.
NL> К тому же можно будет снизить нагpузку на RAM. У меня сейчас RAID10 на
NL> ZFS с SSD под кеш и логи.
NL> Пpиpост ощутимый. К тому же машина исполняет pоль гипеpвизоpа и память
NL> нужна не только ZFS.

Как-то можно измеpить пpоизводительность кеша или чисто на глаз?

Bye, Nikolay Linkevich, 18 апpеля 17
--- FIPS/IP <build 01.14>

Nikolay Linkevich написал(а) к Sergey Anohin в Apr 17 09:45:23 по местному времени:

Нello, Sergey!
SA> Как-то можно измеpить пpоизводительность кеша или чисто на глаз?

Я тестировал сначала без SSD, затем с ним. По скорости ощущается,
плюс gstat на операциях чтения показывает обращение к SSD диску

С наилучшими пожеланиями, Nikolay Linkevich.

--- wfido

Sergey Anohin написал(а) к Nikolay Linkevich в Apr 17 21:09:14 по местному времени:

Нello Nikolay* *Linkevich
SA>> Как-то можно измеpить пpоизводительность кеша или чисто на глаз?
NL> Я тестиpовал сначала без SSD, затем с ним. По скоpости ощущается,
NL> плюс gstat на опеpациях чтения показывает обpащение к SSD диску

Нажо копить на ссд

Bye, Nikolay Linkevich, 19 апpеля 17
--- FIPS/IP <build 01.14>

Alex Korchmar написал(а) к Sergey Anohin в Apr 17 09:23:34 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Sergey Anohin <Sergey.Anohin@p1.f10.n5034.z2.fidonet.org> wrote:

SA>>> Как-то можно измеpить пpоизводительность кеша или чисто на глаз?
NL>> Я тестиpовал сначала без SSD, затем с ним. По скоpости ощущается,
NL>> плюс gstat на опеpациях чтения показывает обpащение к SSD диску
SA> Нажо копить на ссд
не надо (ну, в смысле надо, но не для read cache).
Надо меньше верить неаргуменитрованной фидо-бредятине и больше
читать документацию.
(разумеется, у него будут обращения к ssd диску, отмеченному как кэш -
совершенно_лишние. В большинстве нормальных случаев.)
Копи на лишние планки оперативы - причем с ECC. И отдельно избегай freebsd11,
где все что можно поломано (по некоторым сведениям - ARC2 в том числе).

В очередной раз настоятельно рекомендую нубам читать очень внимательно
юзерскую_документацию к freenas. Там очень детально расписано, какие вещи
в zfs работают совсем не так, как вы думаете (если есть, чем), какие
практики полезны, а каких лучше избегать вовсе. Те кто это писали
- понимали что они делают и почему оно - так. Про ssd там тоже было.

> Alex

--- ifmail v.2.15dev5.4

Nikolay Linkevich написал(а) к Alex Korchmar в Apr 17 12:28:14 по местному времени:

Нello, Alex!

AK> From: Alex Korchmar <noreply@linux.e-moe.ru>

AK> Sergey Anohin <Sergey.Anohin@p1.f10.n5034.z2.fidonet.org> wrote:

AK> Надо меньше верить неаргуменитрованной фидо-бредятине и больше
AK> читать документацию.

:offtop on
Советую не бросаться громогласными заявлениями, т.к. ты не знаешь, кто я,
а выводы делаешь.
:offtop off

Так вот, я знаю как работает SSD с ZFS, а freenas, которая
отнюдь не чистая фряха (GENERIC), априори может(!) иметь определенные
модификации, начиная с sysctl и заканчивая опциями ядра.
В официальной(!) документации сказано, что если нет данных в ARC,
то ZFS ищет их в L2ARC и только потом на диске.

P.S. По своему опыту работы с СХД я советую юзать SSD под кеш.
К тому же мой случай с ZFS это бюджетная СХД для резервного ДЦ, где
распологается одна из нод ESXi кластера и куда реплицируется часть
однотипных виртуалокс(vReplication). До кучи там же будет стоять вторая
такая же для второго хранилища бекапов, чтобы в случае сбоя или достать
бекапы или запустить Instant VM Recovery. Прогретый кеш там
будет ой как нужен, ибо для критического сегмента КД у нас 0,98

С наилучшими пожеланиями, Nikolay Linkevich.

--- wfido

Alex Korchmar написал(а) к Nikolay Linkevich в Apr 17 14:52:42 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Nikolay Linkevich <Nikolay.Linkevich@p3193.f24.n5023.z2.fidonet.org> wrote:

NL> :offtop on
NL> Советую не бросаться громогласными заявлениями, т.к. ты не знаешь, кто я,
мне феерически начхать на то, кто ты.

NL> а выводы делаешь.
по твоей писанине.

NL> Так вот, я знаю как работает SSD с ZFS, а freenas, которая
я пока не вижу демонстрации этих знаний.

NL> отнюдь не чистая фряха (GENERIC), априори может(!) иметь определенные
то есть почитать - конечно же, нет - сразу рассказывать сказки.
(к тому же, конечно же, его писали рептилоиды, и специально сделали так,
чтобы как именно NAS он работал как можно хуже)
Так вот, специально для тебя: там (в том что надо читать, разумеется)
нет никаких специальных особенностей фринаса (если бы были, их стоило бы,
вообще-то, копировать) - просто объясняются ключевые
для понимания как все это работает вещи, мягко говоря, неочевидные
(иногда вообще контринтуитивные), поскольку они и их пользователи уже
наступили на все возможные и большинство невероятных грабель в этой
области.

NL> В официальной(!) документации сказано, что если нет данных в ARC,
NL> то ZFS ищет их в L2ARC и только потом на диске.
да, было бы странно их там не искать, и что с того?

NL> P.S. По своему опыту работы с СХД я советую юзать SSD под кеш.
опыт без знаний и умения поставить чистый эксперимент - увы, ничто.
(равно как - основанные на узкоспециальном опыте широковещательные
заявления без указания этой специфики)

NL> К тому же мой случай с ZFS это бюджетная СХД для резервного ДЦ, где
NL> распологается одна из нод ESXi кластера и куда реплицируется часть
NL> однотипных виртуалокс(vReplication). До кучи там же будет стоять вторая
NL> такая же для второго хранилища бекапов, чтобы в случае сбоя или достать
NL> бекапы или запустить Instant VM Recovery. Прогретый кеш там
NL> будет ой как нужен, ибо для критического сегмента КД у нас 0,98
то есть на самом деле ты мог бы выбросить эту хранилку целиком, и
обойтись просто одним ssd-диском (пусть зарезервированным, неважно).
Оставшиеся 2% пожав или переложив на отдельный медленный сторадж,
как и все остальное.
Да, в этом случае, безусловно, кэш работает, более того, он,
действительно, именно для такой ситуации предназначен.

К сожалению, большинство из нас используют хранилки несколько иначе -
и никакой пользы от него не получит, получит сплошные потери, поскольку
сперва мы будем читать вращающиеся диски, медленно и печально, потом -
"быстро", но совершенно ненужно для пользователя - записывать прочитанное
в кэш.
Потом, теоретически, мы могли бы прочитать это еще раз из кэша, но
практически - вряд ли это write-only хранилка, и вряд ли размер кэша
равен размеру хранилки - поэтому мы просто будем читать что-то другое,
вымывая предыдущее - опять с потерями производительности на ненужную
перезапись.
(надеюсь, не надо объяснять, почему для L1 такой проблемы нет, и
его наращивание всегда улучшает ситуацию, кроме совсем клинического
случая linear read чего-то всегда большего чем кэш ? ;-)

Почему в твоем случае это тоже неудачное решение - тоже надо разжевать?
Ок: поскольку кэш вряд ли равен размеру хранилки, любое обращение к
чему-то за пределами твоих 98% - портит производительность системы в разы,
и совершенно непредсказуемым образом. Очевидно, что если скорость чтения
твоих виртуалок для тебя важна - гораздо эффективнее держать их на ssd,
а бэкапам позволить дрыгать дисками столько, сколько им понадобится.
При это гораздо легче уследить за ситуацией, когда этот ssd кончится,
чем за ситуацией, когда из-за разрастания виртуалок кончится красивый
результат попадания в кэш, потому что это может стать заметно далеко
не сразу.


> Alex

--- ifmail v.2.15dev5.4

Nikolay Linkevich написал(а) к Alex Korchmar в Apr 17 21:08:18 по местному времени:

Нello, Alex!

AK> мне феерически начхать на то, кто ты.

Видали мы "чихающих" ;-) Потом бегали с вопросами, а-ля кто потер снепшоты
и смигрировал виртуалки на другой сторадж

AK> я пока не вижу демонстрации этих знаний.
А зачем мне распинаться? Надо будет - спросят (как создатель темы).

AK> наступили на все возможные и большинство невероятных грабель в этой
AK> области.
В области НA? Или в области хранения. Явного учточнения не вижу

AK> да, было бы странно их там не искать, и что с того?
AK>>В очередной раз настоятельно рекомендую нубам читать очень внимательно
AKY>>юзерскую_документацию к freenas.
Заметь, не я отправил читать документацию к freenas, а не официальную по ZFS

AK> то есть на самом деле ты мог бы выбросить эту хранилку целиком, и
AK> обойтись просто одним ssd-диском (пусть зарезервированным, неважно).
AK> Оставшиеся 2% пожав или переложив на отдельный медленный сторадж,
AK> как и все остальное.
Денег не выделяют на нормальную СХД, а бекапов там за 10TB перевалило.
Если бы закупили нечто вроде EMC VNX, даже бы не заморачивался с кешем,
настроив автотиринг

AK> (надеюсь, не надо объяснять, почему для L1 такой проблемы нет, и
AK> его наращивание всегда улучшает ситуацию, кроме совсем клинического
AK> случая linear read чего-то всегда большего чем кэш ? ;-)
С L1 другая проблема - вечно не хватает ;-)

AK> Почему в твоем случае это тоже неудачное решение - тоже надо разжевать?
AK> Ок: поскольку кэш вряд ли равен размеру хранилки, любое обращение к
AK> чему-то за пределами твоих 98% - портит производительность системы в разы,
AK> и совершенно непредсказуемым образом. Очевидно, что если скорость чтения
AK> твоих виртуалок для тебя важна - гораздо эффективнее держать их на ssd,
AK> а бэкапам позволить дрыгать дисками столько, сколько им понадобится.
AK> При это гораздо легче уследить за ситуацией, когда этот ssd кончится,
AK> чем за ситуацией, когда из-за разрастания виртуалок кончится красивый
AK> результат попадания в кэш, потому что это может стать заметно далеко
AK> не сразу.
К сожалению, опять таки денег не выделяют толком. Приходится делать спецификацию
на 150 тысяч рублей для дооснащения текущих ProLiant типа G5/G6 заместо ~4 миллионов
на новую СХД.
Поэтому пока так: виртуалки критичного уровня реплицируются на резервный сторадж,
бекапы держатся в "полупрогретом" состоянии, чтобы в случае чего запуститься под
Veeam Instant VM Recovery, а после появления основного стораджа среплицироваться
на него и загаситься на резервной СХД.
SSD тут нужен - к бабке не ходи.

С наилучшими пожеланиями, Nikolay Linkevich.

--- wfido

Alex Korchmar написал(а) к Nikolay Linkevich в Apr 17 22:37:53 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Nikolay Linkevich <Nikolay.Linkevich@p3193.f24.n5023.z2.fidonet.org> wrote:

AK>> я пока не вижу демонстрации этих знаний.
NL> А зачем мне распинаться? Надо будет - спросят (как создатель темы).
затем, что выступая со странными декларациями, неплохо бы их подтверждать
наличием опыта. Релевантного, а не "умею настраивать репликацию виртуалок".

AK>> наступили на все возможные и большинство невероятных грабель в этой
AK>> области.
NL> В области НA? Или в области хранения. Явного учточнения не вижу
Топикстартеру никакое НA даром не сдалось, фринасу тем более, откуда в
твоей голове вообще возник этот бредовый фортель?
В области практического применения zfs в миллионе разных сетапов.

NL> Заметь, не я отправил читать документацию к freenas, а не официальную
NL> по ZFS
официальная документация по zfs - эклектичное сборище мусора, наполовину
устаревшего, ее читать вообще незачем (за пределами манов, если вообще
синтаксис забыл). Читать надо книжки, и вот фринасовская (ну и еще некоторые
уже, увы, совсем устаревшие статьи сановских идеологов) - лучшее, что мне
попадалось на эту тему. Ссылок не дам, поскольку это достаточно один раз
прочесть, сохранять их мне было незачем.

NL> Денег не выделяют на нормальную СХД, а бекапов там за 10TB перевалило.
NL> Если бы закупили нечто вроде EMC VNX, даже бы не заморачивался с кешем,
NL> настроив автотиринг
ну а неавто - никак? Зачем вообще бэкапаться на тот же сторадж, что и
live migration? При таком размере оно тебе весь кэш и испохабит.
Я бы (раз оно у тебя заведомо влезло) тупо подставил под этот лайв ssdшную
спарку, с рассчетом, что когда оно (неминуемо) отвалится на ходу - этот самый
мигрейшн тебя и спасет, виртуалки уйдут на другую ноду, а ты пойдешь нажимать
этой ресет уже неспеша. А бэкапы могут до посинения писаться в сторонке на
вертящиеся диски, один хрен это write-only действо (хотя если единичный бэкап
влазит, тут уже можно задуматься про zil... подумать-подумать, и ну его
нафиг ;-)
Причем ради экономии денег ничто не мешает все совместить в одном ящике,
хрен с ним, с вымывом L1.

NL> С L1 другая проблема - вечно не хватает ;-)
ну так опять же, топикстартеру ни на что не хватает, он копить собирался - а
копить лучше всяко на l1 - во-первых, можно добавлять мелкими кусочками,
во-вторых, это беспроигрышное вложение.

NL> Поэтому пока так: виртуалки критичного уровня реплицируются на резервный
NL> сторадж, бекапы держатся в "полупрогретом" состоянии,
ну то есть совсем ручное управление кэшом, вместо разового разброса
разных задач по разным стораджам? Ну очень странный use case.
Понятно, что ради "денег никому не платить" можно и не так извернуться,
но опять же - вряд ли стоит на этом основании всем советовать бежать за
ssd - большинству обычных пользователей компьютера для работы/интернетов
никогда не удастся увидеть от него выигрыша (если только все их данные
вообще не влезают туда - но тогда мы снова вернемся к идее что куда проще
вручную раскидать их по разным дискам)

> Alex

--- ifmail v.2.15dev5.4