Насколько важен размер кэша в RAID 10?

Cast: true_admin , tazhate

Давно не смотрел аппаратный RAID'ы, но раньше далеко не всегда аппаратный RAID давал производительность одного диска, обычно ниже. Лучше сообщие модель, может кто что скажет конкретнее.

Как он может быть медленнее чем один диск, если там 0 raid есть из двух дисков? Контроллер SmartArray 5i.

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

ЗЫ: При прочих равных кэш диска почти никак не сказывается на производительности. На хай-энд SAS 15kRPM сигейта его вообще 16мб, хотя на многих сата - 64мб.

Как он может быть медленнее чем один диск, если там 0 raid есть из двух
дисков? Контроллер SmartArray 5i.

не скажу за SmartAarray, но очень часто аппаратные контроллеры отключают кеш у самого диска, и не всегда дают использовать собственный кеш контроллера (наличие батарейки и т.п.)

Особых проблем не будет, это точно. Всю жизнь на разнобойных винтах сидел :).

Размер кэша ни на что не влияет. Его может быть 16метров, может быть 32 метра, может быть 64, но разницы в тестах не почти не увидишь. Т.е. диск с «маленьким» кэшем легко может оказаться быстрее.

Я бы забил на проблемы. Тюнинг фс и рейда и настройки vfs, настройки БД и вебсервера влияют гораздо сильней.

Кэш дисков обычно рекомендуется вообще отключать т.к. он ничем не прикрыт

1) а разве он вообще отключается?

2) то что не прикрыт это не важно, главное чтобы веник рапортовал об окончании записи только когда данные попали на диск. Именно те данные что «в полёте» и прикрывает батарейка рейда. Ну и нужна надёжность - ставь упс.

очень часто аппаратные контроллеры отключают кеш у самого диска

можно пруфлинк?

а разве он вообще отключается?

Да, по крайней мере для записи.

Раз такая пьянка..

Вопрос: сравнима ли выделенная машина (простенькая мать с простеньким селероном, памяти гиг или два, mdadm), защищенная упсом, по надежности с аппаратным рейд-контроллером? Если нет, в чем разница?

Да, по крайней мере для записи.

пруфлинк пожалуйста

man hdparm

Ящитаю аппаратные рейды говном и всегда строю на софте (речь идёт о маленьких рейдах на 2-4 диска, на бОльших объёмах опыта мало). Даже отдельную машину не надо.

Надёжность софтварного рейда на стабильном ядре тоже считаю выше. Аргументы всё те же:

1) меньше железа

2) больше юзеров протестировали это, оно работает.

3) никаких проблем с дровами, не надо ничего перепрошивать.

4) сейчас можно поставить хоть 100 гиг памяти в одну машину, это не сравнится с кол-вом памяти в рейде

5) современные процы очень мощные и в них много ядер. Много ресурсов рейд не отожрёт

Сравнение скорости легко гуглится, найдёшь любые интересующие конфигурации и любые бенчмарки.

Для лютого перфоманса подтюнь sysctl vm.dirty_* и поставь UPS. Будет всё летать. Но железка должна быть протестирована, иначе при больших кэшах в случае зависона много незаписанных данных потеряешь. И бэкапы, бэкапы, бэкапы.

man hdparm

Открыл, там ни слова про отключение кэша. Но даже если есть, мне нужны спеки на какой-нить рейд где это сказано.

Пока мне кажется что ты путаешь с кэшем самого рейда где есть настройка write through, но это к дискам не имеет отношения.

Открыл, там ни слова про отключение кэша.

-W

рейда

Разве речь шла не о принципиальной возможности выключить кэш диска?

-W

Проглядел. Только я вот вообще не вижу чтобы кто-то это использовал. Даже бенчмарки не могу найти кроме общих слов «убило производительность в 10 раз». У меня сомнение что это юзабельно.

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

Можно чуть подробнее?

бекапы

Люто согласен

Ну здрасьте, кэш винтов может быть в режиме writeback (кэш записи) и write-through. В первом случае он рапортует о записи при попадании данных в кэш, во втором - на диск.

В LSI массив с откл. кэшем дисков выглядит так:

Virtual Drive: 4 (Target Id: 4)
Name                :VM_STORAGE1_1
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 2.723 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 2.723 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives per span:2
Span Depth          : 5
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
****Disk Cache Policy   : Disabled****
Encryption Type     : None
Is VD Cached: No

В общем согласен, дома юзаю, но на работе редко. Могу немного поспорить.

1) Встроенные контроллеры сата обычно менее надежны, и валидированность дисков непонятна. Заработает или нет - хз. Плюс, если нужен SAS, то надо брать HBA с его поддержкой.

4) В сервер с рейдом можно тоже поставить стопицот гиг памяти и это будет тот же кеш. Так что без разницы софт это рейд или хард

5) Если это сервер-хранилище, то да. Если же у это просто софтрейд на обычном сервере, то при полной нагрузке ядерные треды рейда (в случае с 5 и 6) грузят проц достаточно прилично, что может тормозить остальные приложения.

Кэш дисков обычно рекомендуется вообще отключать т.к. он ничем не прикрыт

2) то что не прикрыт это не важно, главное чтобы веник рапортовал об окончании записи только когда данные попали на диск.

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

кэш винтов может быть в режиме writeback (кэш записи) и write-through.

это кэш рейда

ага, только тогда это то же, что и с отключеным кэшем получается, не находишь?

нет, не то же. Есть два уровня кэширования (на самом деле, больше): на винтах и на рейде. Вот тут в этом треде все путаются с этим. Так вот, write back это когда рейд рапортует об успешной записи, а сам при этом потихоньку дописывает на винты.

и да, в схд кэши таки отключают.

пруфлинки?

Блин, вот странный ты. Ну подучи матчасть. Мы говорим про кеш *винтов*. Кеш рейда это отдельная тема, он вот:

Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00687518/c00687518.pdf

We advise against enabling disk drive write cache because a power failure could result in data loss.

Встроенные контроллеры сата обычно менее надежны

В каком смысле? У меня вообще они никогда не дохли. Бывали проблемы с отдельными портами и шлейфами... Ну так и с 3ware были непонятные глюки.

валидированность дисков непонятна. Заработает или нет - хз

Это как?

В сервер с рейдом можно тоже поставить стопицот гиг памяти и это будет тот же кеш. Так что без разницы софт это рейд или хард

а зачем платить больше?

Плюс, если нужен SAS,

Зачем он вообще нужен? Винты-то те же. Или речь про 10k/15k RPM винты? Я бы постарался вместо SAS воткнуть кэширующий SSD.

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

Пруфлинк? Я во вижу при загрузки системы в dmesg что даже одно ядро даёт бешенные скорости на XOR-операции (гигабайты в секунду). Ну и никто не использует эти уровни если нужна скорость (и надёжность :)). Я бы даже рекомендовал отказаться от этих уровней. Если речь идёт о большом кол-ве винтов то я сразу сказал что опыта у меня мало с такими системами.

Проглядел. Буду знать.

Можно чуть подробнее?

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

1. Порты это тоже часть контроллера, у меня на домашних системах (да и на рабочий пару раз) было прилично случаев UDMA CRC Error и подобных, когда замена шлейфов не помогала.

2. Валидированный винт - проверенный производителем. У всех вендоров рейд-контроллеров есть HCL с такими девайсами.

3. SAS выдает на том же железе в среднем в 1.5-2 раза больше IOPS, так что даже с SSD кешем, который нынче очень полезен, ни разу не помешает. Я на работу беру только SAS.

4. Про нагрузку проца померяю, например при проверке рейда треды жрут прилично, посмотрю седня.

можно пруфлинк?
пруфлинк пожалуйста
пруфлинки?
Пруфлинк?

То что ктото чего то не знает не наши проблемы... И с чего вдруг мы все должны вместо тебя, сейчас в пятницу в конец рабочего дня, кинуться в гугль искать ссылки?

И с чего вдруг мы все должны вместо тебя, сейчас в пятницу в конец рабочего дня, кинуться в гугль искать ссылки?

Есть мнение что многое из того что тут сказано является ничем не подтверждёнными домыслами. Я вот не испытываю проблем подкреплять свою точку зрения практикой и независимыми тестами.

Порты это тоже часть контроллера, у меня на домашних системах (да и на рабочий пару раз) было прилично случаев UDMA CRC Error и подобных, когда замена шлейфов не помогала.

Окей, с этим спорить не буду. Мой подход такой: никогда не полагаться на одну железку. Поэтому я принципиально беру дешёвое железо.

Валидированный винт - проверенный производителем

честно скажу, никогда не верил никаким сертификатам.

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

Ну, можно write-through поставить, если это все-таки не флешка, а парочка винтов.

Кстати, в случае софтового рейда у винтов надо кеши отключать?

1. Насчет дешевого железа тут уже как повезет. Те же Supermicro стоят, по серверным меркам, недорого, но при этом достаточно надежны и много где используются, у меня в том числе, наряду с брендами аля HP. А всякие Асусы и подобное (даже «серверное») я в принципе брать не буду т.к. мне же с ними потом и трахаться.

2. Это не сертификат, это просто список устройств (HDD/SSD SATA/SAS плюс еще корзины, материнки и т.п.), с указанием ревизий и прошивок, с которыми данный контроллер проверялся.

Вот, например: http://www.lsi.com/downloads/public/raid controllers/raid controllers common ...

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

В случае софтового рейда смысла особого нет т.к. в случае потери питания сервером рухнет всё: и кеш дисков и кеш ОСи.

Кстати, в случае софтового рейда у винтов надо кеши отключать?

Я думаю тут слово «надо» неприменимо. Есть настройки которые увеличивают надёжность и уменьшают скорость, есть наоборот. Всё зависит от задач. На экспериментальных и бэкапных тачках я всё выкручиваю по-максимому. На сервере в ДЦ я оставил как есть потому что доверия датацентру нет, данные важные, возиться с востановлением из бэкапов не охота и попробуй ещё пойми что могло повредиться при падении.

Но я раз в пол года произвожу востановление из бэкапа чтобы убедиться что оно работает.

Вот, например:

Круто, я думал там будет полтора устройства от самого вендора.

Есть два уровня кэширования (на самом деле, больше): на винтах и на рейде. Вот тут в этом треде все путаются с этим.

Я в курсе, кэп. И ничего не путаю, я говорил про кэш диска.
Ниже тебе уже blind_oracle привёл выдержку хп, лень от других искать, но поверь - там будет всё так же.

Так вот, write back это когда рейд рапортует об успешной записи, а сам при этом потихоньку дописывает на винты.

Ты думаешь дисковый кэш не так же работает? в случае потери питания, даже в схд с bbu, ничто не спасёт данные из кэша диска.

Ты думаешь дисковый кэш не так же работает?

Я думал что нет. Я думал он влияет на то сколько можно в него мгновенно запихнуть данных. А уведомление о записи придёт позже. Сейчас вот засомневался, хотя достаточно много читал на эту тему.

Спасибо всем.

В дисковом кеше всё так же, как в рейдовом и прочих. В режиме Write-Back ты потеряешь данные, которые винт рапортовал как успешно записаные.

ЗЫ: Сейчас запустил проверку своего домашнего RAID5, нагрузка получилась приличная:

md3_resync - 21%
md3_raid5 - 10%

т.е. только один рейд массив скушал 30%+ процессора. Проц - i5-3570T 2.3Ghz

Процессора или ядра процессора?

В дисковом кеше всё так же, как в рейдовом и прочих

Я готов с этим спорить. При выключении компа, как ОС знает что все данные уже записаны и можно выключаться? В районе года 2005-го даже тесты на эту тему проводились из-за проблем с этим. Вот кое-какая инфа на эту тему: http://support.microsoft.com/kb/153296

Я сколько не гуглил, везде спекуляции на тему «возможно оно работает именно так». Мне это не интересно, предполагать всё что угодно можно. Хочу видеть спеки. Вот что я вижу в сырцах ядра и hdparm: hdparm -F через ATA_OP_FLUSHCACHE (0xe7) сбрасывает эти буфера. Т.е. механизм для этого этого предусмотрен. И, судя по тому что никто больше не теряет данные при выключении компов, это работает.

Команда на сброс кешей на диск конечно есть, как и в SCSI при выключении в консоль валится «Synchronizing SCSI cache».

Непонятно - в чем вопрос то? Одно дело ты ему говоришь запиши мне кое-что кое-куда, он тебе рапортует - готово! Но данные еще не на диске, если кеш в режиме write-back. Если ты хочешь убедиться, что данные на диске - ты командуешь ему flush cache.

Это две совершенно разные операции, не следует их смешивать.

ЗЫ: По этой ссылке просто ОСи (NT4 & 3.51), которые не командовали винтам flush cache при выключении компьютера и данные терялись, что закономерно. Опять непонятно причем тут наши бараны :)

Ядра. Но, на мой взгляд, это нельзя назвать «незначительной» нагрузкой. Незначительная - до 10%. Это мое ИМХО :) Плюс там к этим md3_* тредам еще пачка kworker (штуки 3) вертится по 6%.

это нельзя назвать «незначительной» нагрузкой

5-7% от общей мощности проца который всё равно бОльшую часть времени простаивает.

Окей, тогда возьмём в рассмотрение ещё два параметра: нагрузку при использовании аппаратного рейда и стоимость аппаратного рейда. Ты думаешь аппаратный рейд в 10 раз меньше жрать будет? Как бы не так.

По мне так на сэкономленные деньги можно проц помощнее купить если жаба душит.

Ну а даже на средних серверах этих ядер от 12 штук и смысла экономить путь даже 50% одного ядра я не вижу. Это, скорее, психологическая проблема - «мой софтовый рейд сильно грузит тачку».

Непонятно - в чем вопрос то?

Ящитаю что кэш диска сбрасывается при коммите в журнал и при комманде sync. В отличие от рейда с батарейкой и режимом write-back. Вот линк с вменяемым обсуждением: http://monolight.cc/2011/06/barriers-caches-filesystems/ . Я знаю что там написано что «вендор может и игнорировать эту комманду». Но что-то мне подсказывает что раз при ребуты нет потери данных значит это таки работает. Наверно, можно найти винт который этого делать не будет. Ну так и глюков у аппаратных рейдов тоже хватает.

А ссылку на ресурс МС я дал неправильную.

1.

Что значит «аппаратный рейд жрать будет» я не понял, он «жрет» только прерывания для обработки I/O.

А стоимость его в рамках цены сервера ничтожная (LSI, которые я беру, стоят меньше 20т.р. обычно).

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

2.

Кэш диска сбрасывается тогда-то и тогда-то, да. Только если у тебя питание отвалится между этими знаменательными событиями, то данные потеряются.

Что значит «аппаратный рейд жрать будет» я не понял, он «жрет» только прерывания для обработки I/O.

а ты померяй. Запусти бенчмарк какой-нить и сравни.

А стоимость его в рамках цены сервера ничтожная (LSI, которые я беру, стоят меньше 20т.р. обычно).

фига се у вас там сервера раз 20тр это ничтожно мало. Значит там и процов столько что отдать ядро под рейд не жалко.

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

У нас это было реализовано на уровне приложения :P Причём, в кэш складывалось самые популярные файлы, а не просто least recently used. Аппаратные рейды такое умеют? А сколько при этом стоят? Ну и, если не ошибаюсь, какой-нить zfs давно умел кэшировать на отдельный сторадж.

Кэш диска сбрасывается тогда-то и тогда-то, да. Только если у тебя питание отвалится между этими знаменательными событиями, то данные потеряются.

за 20тр можно купить стоечный упс сразу на несколько серверов, если не ошибаюсь.

Что померять то? Нагрузку на процессор? Мерял, ее нет, кроме прерываний.

Ядро под рейд отдать то не жалко, если бы это имело явные преимущества перед железным рейдом.

У меня много серверов, которые работают как хранилища (FC, iSCSI), где кэшировать на уровне приложений нет смысла :) Там как раз LRU рулит с несколькими SSDшками.

Кстати, контроллеры кеширующие горячие данные есть, например: http://www.lsi.com/products/storagecomponents/Pages/SolidState.aspx

Стоят, конечно, как самолёт (150-200т.р), но в основном из-за SSD серверного класса.

За 20т.р. упс будет так себе, тот же 3U On-Line APC на 5КВА стоит около 90т.р.

Я не буду спорить на тему «как построить cdn», у меня нет такого опыта. Но я верю что подход гугла (накупим много дешёвого железа) доказал своё право на существование.

Что померять то? Нагрузку на процессор? Мерял, ее нет, кроме прерываний.

Запускаешь бенчмарк и смотришь сколько проца жрётся. Здаётся мне софтворный рейд это не самый жрущий элемент на сервере если это не файлопомойка. А если файлопомойка то проц ей не нужен (кроме ssl, конечно, не знаю какой трафик сейчас сервера на soft ssl держат).

За 20т.р. упс будет так себе

по каким параметрам? Я бы сказал, задача упса продержать ровно 5минут пока серваки останавливаются. И это в худшем случае если резервное питание в ДЦ тоже отказало.

Если строить ДЦ из тысячи серверов, то да, я бы тоже выбрал такой подход скорее всего. Но у меня стоек всего пять штук, так что я выбираю то, что будет проще мне, т.к. финансовая выгода на общем фоне невелика :) Я куплю контроллеров прозапас и доволен.

Насчет проца: у меня все сервера-хранилища шифрованы через dm-crypt, так что проц там один из самых нагруженных элементов, даже учитывая ускорение через AES-NI.

Для меня у упса основные параметры: 1. Выходное напряжение не зависящее от входного (его дает только On-Line UPS, а не линейно-интерактивные).

2. Нормальный выделенный мониторинг по SNMP встроенный.

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

«ДЦ» у меня свой, так что питание в нем ни разу не гарантированое.

За 20тр такой упс не купишь.