@bogidaich

Какую скорость записи можно выжать из бюджетной СХД?

Доброго дня
Дано
Intel R1304BTLSFANR
Intel Pentium G2020
32Gb RAM ECC
4 x 2Tb WD Red
1 SSD Intel DC S3500 Series SSDSC2BB120G401
Intel X520-DA2
Требуется СХД с NFS шарой которая смогла бы записывать и считывать со скоростью более 2-3Гбит\содним потоком по сети 10Гбит - естественно хочется все бесплатно (т.е. даром).
Пока видится ZFS Raid10 + Zil на SSD
Вопросы:
1. Есть ли другие варианты ? Какие?
2. На чем лучше строить предложенную схему? Большие будут потери при использовании Дебиана? FreeNAS?
3. Какая теоретически возможная скорость на предложенном решении с учетом данного железа?
4. Поможет ли добавление второго SSD или замена процессора увеличить скорость?
Спасибо..
  • Вопрос задан
  • 1065 просмотров
Пригласить эксперта
Ответы на вопрос 3
Jump
@Jump Куратор тега Твердотельные накопители
Системный администратор со стажем.
которая смогла бы записывать и считывать со скоростью более 2-3Гбит\содним потоком
если речь именно про один поток - 0 или 10 рэйд, даже в софт реализации обеспечит близкую к указанной скорость на большинстве современных sata дисках
Если конечно фрагментации сильной не будет.

SSD на 120 GB тут явно лишний элемент, который не нужен вообще, и не только не даст преимуществ, а еще и серьезно ухудшит характеристики. Поэтому лучше исключить его из конфигурации.
SSD хорош для случайного чтения, но никак не для потока.

На чем лучше строить предложенную схему? Большие будут потери при использовании Дебиана? FreeNAS?
Зависит от протокола по которому будет работать СХД.

Какая теоретически возможная скорость на предложенном решении с учетом данного железа?
200-400Мб/с

Поможет ли добавление второго SSD или замена процессора увеличить скорость?
Нет.
Лучше добавить HDD в 10 чтобы страйпа больше было, или сделать 0.

Все сказанное - для ситуации когда чтение/запись идут одним потоком.
Т.е один процесс непрерывно читает последовательные данные, или пишет поток данных.
Если одновременных процессов чтения будет более одного, либо работа будет не потоком, а со случайными выборками данных - все будет наоборот.
Ответ написан
athacker
@athacker
Тут надо чётко понимать несколько вещей.

1) Физику не обманешь. Какие бы ни были ухищрения, при реально высокой интенсивности записи они мало чем помогают. Реально немножко помочь может кэширование записи и то, что называется coalescing -- т. е. система группирует блоки перед записью таким образом, чтобы можно было (ну, если совсем на пальцах) записать их в один пролёт головки над поверхностью. Основная же нагрузка всё равно придётся на диски, и тут вариант ускорения записи ровно один -- это как можно больше шпинделей, как можно более оборотистые диски (15k RPM вместо 7200 RPM), либо вообще переход на SSD/NVMe. Так что лучше взять пачку дисков мЕньшего объёма, но в бОльшем количестве, и скорость записи будет выше.

2) ZIL -- это не кэш записи. Это всего лишь журнал, который обеспечивает синхронную запись и позволяет сохранить ФС в консистентном состоянии даже при сбоях. В ZFS при синхронной записи по факту запись ведётся дважды -- сначала данные идут в ZIL, а потом уже переписываются на основной диск. Если под ZIL не выделялось отдельного устройства, ZIL размещается на основном диске. Разумеется, размещение ZIL на SSD операцию записи ускоряет. Но один тонкий момент -- ускоряет он не в абсолютных значениях, а относительно того случая, когда ZIL размещён на основных (HDD) дисках.

Учитывая, что вам требуется NFS, который использует только синхронную запись, то у вас вариантов два -- размещать ZIL на SSD, либо в свойства ZFS-датасета, который будет презентоваться по NFS, принудительно включить асинхронную запись. Выбор решения зависит от того, что конкретно вы хотите получить. Если вам важна консистентность данных -- лучше оставить sync и разместить ZIL на SSD. Но надо понимать, что async запись будет в любом случае несколько быстрее, так как запись в ZIL -- это всё равно задержка и дополнительный оверхед. Так как даже если ZIL размещён на SSD -- время доступа к нему и запись данных не нулевая.

3) Кэш в оперативке реально помогает (ARC). Учитывая, что у вас также будет параллельно идти и чтение, то увеличение оперативы имеет смысл, так как тот факт, что некоторые блоки были прочитаны из ARC означают, что эти блоки не были прочитаны с дисков, т. е. дискам не пришлось делать дополнительные телодвижения для поиска и чтения с блинов этих блоков. А значит, диски могут больше времени уделить записи. Что касается стоит ли добавлять L2ARC -- это вопрос философский, и сильно зависит от нагрузки. По моим наблюдениям в сценарии размещения на ZFS виртуалок и набортном объёме RAM в 128 Гб, до L2ARC уже ничего не долетало. Сравнительные цифры -- ARC hits/misses составляло в среднем примерно 80k/15k в минуту, а в L2ARC цифры были в районе 15/800. Т.е. 15 попаданий на 800 запросов к L2ARC. В итоге мы решили даже не тратить SSD на L2ARC.

Ещё один момент -- если у вас не предполагается последовательного чтения, а будет чистый рандом (например, при размещении виртуалок это именно так), то следует отключить ZFS prefetch. Его отключение на синтетических тестах показало рост IOPS примерно на 15-20%, при read/write 20%/80% и полном рандоме обращений.

А вообще, нужно развернуть систему, поставить её на мониторинг, и понаблюдать, что и как происходит. Фря выдаёт достаточно информации, чтобы делать выводы -- нужен ли префетч, работает ли L2ARC, насколько эффективен ARC и т. п. Если будет необходимость -- обращайтесь в личку, скину шаблоны и конфиги для заббикс под мониторинг хранилки на базе FreeBSD + ZFS. В планах статью нарисовать по этому поводу, но это пока руки дойдут... :-)
Ответ написан
@bogidaich Автор вопроса
ЗФС это просто пример. Может ЛВМ будет быстрее?
Может у кого-нибудь есть другие варианты для данного железа которые дадут больше скорость?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы