А на двух следовой 24 плашки ))

Не на всех, но да

#вопрос Можно совет? Есть 2 ноды прокса и трунас. Трунас шарит по zfs over iscsi пулы для проксов. Но из-за того что диски разные приходится резать много пулов и получается всё это как-то не слишком удобно. Понял что можно сделать пул из разных vdev. Таки будет ли правильно собрать 8х500hdd + 4х1000hdd к ним закинуть например ssd 2x128 как ZIL и 1 или 2 ssd 512gb как L2ARC? И тогда всё будет типа быстро же? Можно даже под зил выделить 2х512ssd и из третьего 512 сделать l2arc. а 2х128 ещё под что-то применить. P.S. это типа хоумлаба-тестлаба которая держит видеонаблюдение и мини шару для офиса своего

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

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

Ну т е intel 6338 (64 threads 2 ghz ) должен идеально подойти ?

Ну т е intel 6338 (64 threads 2 ghz ) должен идеально подойти ?

Если итоговая конфигурация (без дисков) стоит меньше чем 80к, то да, частота немного низковата впрочем

мне стало интересно посмотреть цену этого интела, и глянуть что у амд за такую есть, наткнулся на https://www.xcom-shop.ru/amd_epyc_7713_873254.html такое. это вообще законно, 64 ядра за 215к рублей?

мне стало интересно посмотреть цену этого интела, и глянуть что у амд за такую есть, наткнулся на https://www.xcom-shop.ru/amd_epyc_7713_873254.html такое. это вообще законно, 64 ядра за 215к рублей?

Дороговато да, но видимо слишком новые

Дороговато да, но видимо слишком новые

я просто помню что мы пару лет назад закупали второе поколение эпиков, и там было 400к за процессор

я просто помню что мы пару лет назад закупали второе поколение эпиков, и там было 400к за процессор

Ну так тогда это были официальные поставки

(и то мы брали 7702p, который только односокетный. двухсокетный было 600к)

Ну так тогда это были официальные поставки

по моим представлениям неофициальные поставки только повышают цену :)

Нет

Неофициальные поставки чаще всего либо БУ под видом новых, либо не имеют гарантии

И это делает от ценник -40-60%, иногда 80%, к примеру, 7302 (16 ядер, 3ггц) стоит 14к сейчас

это где так?

мне 50 рисуют

Это секретные места~ Сам я за 25к их продаю :)

7282 - 24 7551 - 14 7601 - 33 где это 7302 за 14?

7282 - 24 7551 - 14 7601 - 33 где это 7302 за 14?

Секрет фирмы

хаха

причём даже бу

Это секретные места~ Сам я за 25к их продаю :)

А Xeon w 3265m есть ? )))

Intel не знаю

#вопрос Можно совет? Есть 2 ноды прокса и трунас. Трунас шарит по zfs over iscsi пулы для проксов. Но из-за того что диски разные приходится резать много пулов и получается всё это как-то не слишком удобно. Понял что можно сделать пул из разных vdev. Таки будет ли правильно собрать 8х500hdd + 4х1000hdd к ним закинуть например ssd 2x128 как ZIL и 1 или 2 ssd 512gb как L2ARC? И тогда всё будет типа быстро же? Можно даже под зил выделить 2х512ssd и из третьего 512 сделать l2arc. а 2х128 ещё под что-то применить. P.S. это типа хоумлаба-тестлаба которая держит видеонаблюдение и мини шару для офиса своего

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

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

А есть смысл slog использовать? И l2arc на ссд?

А есть смысл slog использовать? И l2arc на ссд?

конечно есть. только для SLOG достаточно 2x128, там много места не требуется

конечно есть. только для SLOG достаточно 2x128, там много места не требуется

А они подключены сейчас и при копировании данных на пул особо они там ничего не делают... А под л2арк как лучше? один 512 ссд выдать ?

А они подключены сейчас и при копировании данных на пул особо они там ничего не делают... А под л2арк как лучше? один 512 ссд выдать ?

они важны(нужны) для операций fsync. при тупом копировании этого не будет заметно

А они подключены сейчас и при копировании данных на пул особо они там ничего не делают... А под л2арк как лучше? один 512 ссд выдать ?

под l2arc вроде какой-то % от емкости пула можно взять. Возможно лучше мету вынести на отдельные быстрые диски чем l2arc городить (хотя l2arc для медленных hdd тоже полезен будет для случайного доступа если он у вас присутствует)

под l2arc вроде какой-то % от емкости пула можно взять. Возможно лучше мету вынести на отдельные быстрые диски чем l2arc городить (хотя l2arc для медленных hdd тоже полезен будет для случайного доступа если он у вас присутствует)

ну да получается остается 3х512 ссд и 2х128 и я сижу голову ломаю какие ларки слоги из них собрать в пул

Собрал все диски в один пул и получил супер медленный пул на 2к иопсов.... Правильно говорили что рейдом 0 можно ухудшить... Как бы ещё понять какие диски с тормозами

Собрал все диски в один пул и получил супер медленный пул на 2к иопсов.... Правильно говорили что рейдом 0 можно ухудшить... Как бы ещё понять какие диски с тормозами

zpool iostat -yv 1 5 Но тут есть более шаристые ребята, вроде бы видел лучше способы

ну да получается остается 3х512 ссд и 2х128 и я сижу голову ломаю какие ларки слоги из них собрать в пул

Слог не может быть больше арка, который по дефолту не может быть больше половины оперативы - это учти)

Собрал все диски в один пул и получил супер медленный пул на 2к иопсов.... Правильно говорили что рейдом 0 можно ухудшить... Как бы ещё понять какие диски с тормозами

А как тестировал? Раз под реальную нагрузку мы подбираем рекордсайз, то и под тесты тоже надо, я так вижу

Собрал все диски в один пул и получил супер медленный пул на 2к иопсов.... Правильно говорили что рейдом 0 можно ухудшить... Как бы ещё понять какие диски с тормозами

Тормозной диск? Хм, ну я бы: - чекнул смарты всех дисков - разобрал пул, и накидал скрипт, запускающий тест с фио на каждый диск по отдельности. По результатам найдёшь тормоза. Главное написать регулярку так, чтобы скрипт не затронул другие диски, убив фс на них) - проверил, что у них всех одинаковый размер сектора. Если там мешанина моделей, то мог затесаться экземпляр с 512n сектором. И для такого ашифт=12 дал бы некое пенальти... Хотя вряд ли это может быть значимым фактором на самом деле

Просто наполнял пул дисками ВМ. и смотрел как работают вм и какая скорость дисков у них. fio ещё запустил на ноде прокса которая на этом пуле имеет диск iscsi. Да сетка ещё тоже тут будет накладывать своё, но я сравнивал было/стало

Тормозной диск? Хм, ну я бы: - чекнул смарты всех дисков - разобрал пул, и накидал скрипт, запускающий тест с фио на каждый диск по отдельности. По результатам найдёшь тормоза. Главное написать регулярку так, чтобы скрипт не затронул другие диски, убив фс на них) - проверил, что у них всех одинаковый размер сектора. Если там мешанина моделей, то мог затесаться экземпляр с 512n сектором. И для такого ашифт=12 дал бы некое пенальти... Хотя вряд ли это может быть значимым фактором на самом деле

Эт кстати мысль. Только скрипт я не осилю. Но из миррора по одному диски вытащить и прогнать можно попробовать)

ну или можно фио погонять из под трунаса на самом пуле. Есть у кого под рукой фио который зфс хорошо гоняет?

Эт кстати мысль. Только скрипт я не осилю. Но из миррора по одному диски вытащить и прогнать можно попробовать)

Да, фио прекрасно тестит и блочные девайсы напрямую Только да, я и имел в виду напрямую на хранилке диски так тестировать) То есть все /dev/sd* из пула И осторожно☝️ Нельзя ошибиться диском, фс убивается от такого теста

ну или можно фио погонять из под трунаса на самом пуле. Есть у кого под рукой фио который зфс хорошо гоняет?

А что, есть которые плохо это делают?)

А что, есть которые плохо это делают?)

Да я с ними уже напутался в гугле там libao не либао всякие разные там надо сидеть разбираться что и зачем они делают) сижу обычно только размер блока правлю и randread/randwrite

fio --name=random --rw=randwrite --direct=1 --ioengine=libaio --bs=4k --numjobs=1 --size=16G так нормально?

fio --name=random --rw=randwrite --direct=1 --ioengine=libaio --bs=4k --numjobs=1 --size=16G так нормально?

Нее, тут маловато флагов, я чуть позже посмотрю что у там у меня в блокноте, и скину

fio --name=random --rw=randwrite --direct=1 --ioengine=libaio --bs=4k --numjobs=1 --size=16G так нормально?

bs=4k - это печально. На виртуалках ext4?

bs=4k - это печально. На виртуалках ext4?

Это на проксе ext4 на iscsi диске на 10гб сетке с трунаса так

Потому, порядок действий такой: 1) Создаём zvol с нужным volblocksize 2) Создаём ФС, для многих из них есть параметры для тюнинга под размер блока данных, чтобы ФС их складировала не разрозненно. Например, в ext4 stride указывает, сколько кластеров должны формировать блок данных. Так как этот тюнинг рассчитан был на корректное размещение данных для raid в stripe, то, желательно, указать stripe-width. В случае с ZFS, он всегда равен stride. 3) Я отключал журналирование данных в ext4, так как у нас эту функцию выполняет zfs. Оставлял только метаданные. 4) Монтирование в виртуальной машине. К сожалению, не записал нигде. Насколько помню: data=ordered,noatime,nobarrier

@Grafeen вот писал небольшую инструкцию, как в ZFS поставить блок больше и чтобы ext4 не разбрасывал в разные блоки свои данные по 4к

fio --name=random --rw=randwrite --direct=1 --ioengine=libaio --bs=4k --numjobs=1 --size=16G так нормально?

fio \ --name RWRITE \ --rw=randwrite \ --filename=/dev/sd* \ --size=1g \ --blocksize=4k \ --iodepth=1 \ --numjobs=1 \ --direct=1 \ --randrepeat=0 \ --ioengine=libaio \ --group_reporting / Вот так можно блочный девайс затестить на случайную запись, например. Просто меняй букву в имени девайса, но только не попутай❗️ с другими дисками) В плане самого тестирования надо регулировать size, blocksize, iodepth и numjobs - к примеру я когда тестирую SSD-диски, то для начала обычно ставлю 1g, 4к, 32 и 16 соответственно - потому что так КристалДискМарк по умолчанию тестит и можно сравнивать свои результаты с обзорами в инете)

fio \ --name RWRITE \ --rw=randwrite \ --filename=/dev/sd* \ --size=1g \ --blocksize=4k \ --iodepth=1 \ --numjobs=1 \ --direct=1 \ --randrepeat=0 \ --ioengine=libaio \ --group_reporting / Вот так можно блочный девайс затестить на случайную запись, например. Просто меняй букву в имени девайса, но только не попутай❗️ с другими дисками) В плане самого тестирования надо регулировать size, blocksize, iodepth и numjobs - к примеру я когда тестирую SSD-диски, то для начала обычно ставлю 1g, 4к, 32 и 16 соответственно - потому что так КристалДискМарк по умолчанию тестит и можно сравнивать свои результаты с обзорами в инете)

root@pve-1:~# fio --name RWRITE --rw=randwrite --filename=/dev/sdc1 --size=1g --blocksize=4k --iodepth=1 --numjobs=1 --direct=1 --randrepeat=0 --ioengine=libaio --group_reporting RWRITE: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1 fio-3.25 Starting 1 process Jobs: 1 (f=1): [w(1)][100.0%][w=20.8MiB/s][w=5330 IOPS][eta 00m:00s] RWRITE: (groupid=0, jobs=1): err= 0: pid=3029691: Sun Apr 16 12:17:59 2023 write: IOPS=4880, BW=19.1MiB/s (19.0MB/s)(1024MiB/53713msec); 0 zone resets slat (usec): min=7, max=402, avg=14.22, stdev= 4.38 clat (usec): min=2, max=1569, avg=187.25, stdev=52.45 lat (usec): min=91, max=1583, avg=201.81, stdev=54.13 clat percentiles (usec): | 1.00th=[ 117], 5.00th=[ 126], 10.00th=[ 130], 20.00th=[ 137], | 30.00th=[ 147], 40.00th=[ 165], 50.00th=[ 182], 60.00th=[ 196], | 70.00th=[ 212], 80.00th=[ 231], 90.00th=[ 258], 95.00th=[ 281], | 99.00th=[ 330], 99.50th=[ 355], 99.90th=[ 420], 99.95th=[ 461], | 99.99th=[ 750] bw ( KiB/s): min=16408, max=23232, per=100.00%, avg=19547.21, stdev=1419.31, samples=107 iops : min= 4102, max= 5808, avg=4886.80, stdev=354.83, samples=107 lat (usec) : 4=0.01%, 50=0.01%, 100=0.08%, 250=87.75%, 500=12.13% lat (usec) : 750=0.03%, 1000=0.01% lat (msec) : 2=0.01% cpu : usr=3.66%, sys=8.96%, ctx=262218, majf=0, minf=12 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=19.1MiB/s (19.0MB/s), 19.1MiB/s-19.1MiB/s (19.0MB/s-19.0MB/s), io=1024MiB (1074MB), run=53713-53713msec Disk stats (read/write): sdc: ios=6/261823, merge=0/0, ticks=3/46886, in_queue=46889, util=99.91%

Пул постоял 2 дня) Выстоялся видать. Сегодня выдаёт на 4к хотябы 5к иопсов что вполне вменяемо для хдд спека.

Пул постоял 2 дня) Выстоялся видать. Сегодня выдаёт на 4к хотябы 5к иопсов что вполне вменяемо для хдд спека.

Погодь), ты ведь сейчас протестил только диск sdc, а не пул

Погодь), ты ведь сейчас протестил только диск sdc, а не пул

Это тесты iscsi диска со стороны прокса) так что это да не пула. А это уже конечная получается. То что я хочу иметь в итоге) А как на пуле потестить со стороны трунаса ?

Это тесты iscsi диска со стороны прокса) так что это да не пула. А это уже конечная получается. То что я хочу иметь в итоге) А как на пуле потестить со стороны трунаса ?

Аа, понял🤓 Ты на стороне Прокса тестируешь Я думал идея в том, чтобы разобрать пул, и тестить его физические диски по отдельности, то есть как раз на стороне трунаса - выявляя таким образом какие из них проблемные тормоза Сам тест на стороне трунаса выполняется точно так же, только движок libaio надо полагаю заменить на posixaio, если у тебя фрибсдшный Трунас Кор Плюс помимо теста физических дисков и теста пула целиком ещё в принципе можно тестить и zvol-ы напрямую, путь кажется /dev/zvol/zvol*

Это тесты iscsi диска со стороны прокса) так что это да не пула. А это уже конечная получается. То что я хочу иметь в итоге) А как на пуле потестить со стороны трунаса ?

У меня есть подозрение, что на стороне трунаса ты пока вообще ничего тестил, и твоё изначальное сообщение про супер медленный пул подразумевало, что это айскази диск в Проксе даёт мало айопсов. Всё так?)

У меня есть подозрение, что на стороне трунаса ты пока вообще ничего тестил, и твоё изначальное сообщение про супер медленный пул подразумевало, что это айскази диск в Проксе даёт мало айопсов. Всё так?)

Всё так. Сегодня пасха, это хоумлаба, и советов дали уже на неделю дел вперёд) но через скази сегодня пул реально ожил и вместо 100 выдал 5к иопс

Аа, понял🤓 Ты на стороне Прокса тестируешь Я думал идея в том, чтобы разобрать пул, и тестить его физические диски по отдельности, то есть как раз на стороне трунаса - выявляя таким образом какие из них проблемные тормоза Сам тест на стороне трунаса выполняется точно так же, только движок libaio надо полагаю заменить на posixaio, если у тебя фрибсдшный Трунас Кор Плюс помимо теста физических дисков и теста пула целиком ещё в принципе можно тестить и zvol-ы напрямую, путь кажется /dev/zvol/zvol*

У меня почему то трунас говорит что он не знает кто такой libaio. И просит выбрать другой вариант. Ну я ссд из кэшей вывел чтобы сесть тестировать их и глянуть что они выдадут

У меня почему то трунас говорит что он не знает кто такой libaio. И просит выбрать другой вариант. Ну я ссд из кэшей вывел чтобы сесть тестировать их и глянуть что они выдадут

Ну поставь либу раз хочется проге

Ну поставь либу раз хочется проге

Ну вот не разбирался как и что сделать надо. Сначала подумал что фряха вообще может не поддерживать либаио

Всё так. Сегодня пасха, это хоумлаба, и советов дали уже на неделю дел вперёд) но через скази сегодня пул реально ожил и вместо 100 выдал 5к иопс

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

У меня почему то трунас говорит что он не знает кто такой libaio. И просит выбрать другой вариант. Ну я ссд из кэшей вывел чтобы сесть тестировать их и глянуть что они выдадут

Так я и пишу, что движок posixaio ннннада - если Трунас у тебя версии Core, то есть фряшный

Да посути я был неправ. Но про посихаио я не знал) так что впереди тесты всех дисков и ссд на трунасе. И самого пула через zvol.

Да посути я был неправ. Но про посихаио я не знал) так что впереди тесты всех дисков и ссд на трунасе. И самого пула через zvol.

Чуток ещё подушню) Мы можем тестить: 1) Физические диски - до сборки из них пула. В фио в этом случае filename=/dev/sd* 2) Сам пул - тут имеются в виду тесты на файловом уровне. В датасетах. То есть допустим корневой датасет пула zpool у нас примонтирован как /zpool, тогда в фио у нас будет filename=/zpool/testfile скажем 3) Ну и zvol-ы, здесь filename=/dev/zvol/zvol* (вроде такой путь). Правда я сам так не тестил) Всегда тесты запускал внутри виртуалок, которым звол отдал.

Чуток ещё подушню) Мы можем тестить: 1) Физические диски - до сборки из них пула. В фио в этом случае filename=/dev/sd* 2) Сам пул - тут имеются в виду тесты на файловом уровне. В датасетах. То есть допустим корневой датасет пула zpool у нас примонтирован как /zpool, тогда в фио у нас будет filename=/zpool/testfile скажем 3) Ну и zvol-ы, здесь filename=/dev/zvol/zvol* (вроде такой путь). Правда я сам так не тестил) Всегда тесты запускал внутри виртуалок, которым звол отдал.

А вот вм у меня вообще например кристалдиском выдают ровно 3к иопс, 12мбит на 4к. И 500мбит на последовательной записи-чтении. Сделал по рекомендациям диски virtio iscsi и без кэшей. Тоже не разбирался ещё почему больше не давит. Хотя сам прокс в скази давит больше

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

очевидно скорость сильно упадёт

очевидно скорость сильно упадёт

А вот наверное почему первые секунды записи шли на 100 иопс. А потом пошла жара в кэшах

А вот наверное почему первые секунды записи шли на 100 иопс. А потом пошла жара в кэшах

не, я о том что зфс рандомную запись превращает в линейную, потому особо смысла тестить такое нет imho

не, я о том что зфс рандомную запись превращает в линейную, потому особо смысла тестить такое нет imho

А CoW эту линейную в случайную потом не превращает?

А CoW эту линейную в случайную потом не превращает?

Так диски в raw же. При zfs over iscsi вообще получается идеально. Zvol напрямую к вм цепляется

А CoW эту линейную в случайную потом не превращает?

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

А CoW эту линейную в случайную потом не превращает?

1. при записи в лог (если виртуалка или тест требует синхронные записи) идут линейные 2. далее аллоцируется место на диске и все что надо записать пишется. тут я конечно не уверен но точно близко к линейной идут записи

#вопрос Можно совет? Есть 2 ноды прокса и трунас. Трунас шарит по zfs over iscsi пулы для проксов. Но из-за того что диски разные приходится резать много пулов и получается всё это как-то не слишком удобно. Понял что можно сделать пул из разных vdev. Таки будет ли правильно собрать 8х500hdd + 4х1000hdd к ним закинуть например ssd 2x128 как ZIL и 1 или 2 ssd 512gb как L2ARC? И тогда всё будет типа быстро же? Можно даже под зил выделить 2х512ssd и из третьего 512 сделать l2arc. а 2х128 ещё под что-то применить. P.S. это типа хоумлаба-тестлаба которая держит видеонаблюдение и мини шару для офиса своего

имхо, конечно - LOG скидывается (по умолчанию) каждые 5 секунд, по сетке 10 гигабит это не больше 5 гигабайт - ваш ЛОГ на 128 гиговых дисках будет всегда пустой на мой взгляд по ЛОГ идеально подойдуд ОПТАНы по 16 гига - они стоят пять копеек пучек но если некуда воткнуть - то можно с десяток гига откусить от диска/ов на котором лежит l2arc

зы. оптыны, даже через переходник PCI-E x1 > m.2 очень хороши на мелких блоках

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

Ничто никогда в zfs не записывается на место того же старого блока. Ибо copy on write (а по научному - redirect on write). Исключение - uberblocks, и то они тоже не на место того же блока, а в кольце по очереди.

Так что да, линейная запись рандома == рандомное чтение линейной записи (в худшем случае), если она билась на разные txg и уехала в разные metaslabs

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

Ничто никогда в zfs не записывается на место того же старого блока. Ибо copy on write (а по научному - redirect on write). Исключение - uberblocks, и то они тоже не на место того же блока, а в кольце по очереди.

По этой причине zvols стоит тестить после 100% заполнения, если хочется получить худший случай

Ничто никогда в zfs не записывается на место того же старого блока. Ибо copy on write (а по научному - redirect on write). Исключение - uberblocks, и то они тоже не на место того же блока, а в кольце по очереди.

А разве смысл RoW не в том, чтобы обеспечить консистентность данных на время записи на случай пропажи питания? И я тогда не совсем понимаю когда именно старый блок помечается как free

А разве смысл RoW не в том, чтобы обеспечить консистентность данных на время записи на случай пропажи питания? И я тогда не совсем понимаю когда именно старый блок помечается как free

В той же txg, либо она на 100% успешно записалась, либо нет. Синхронная запись отдельно трекается журналом zil

А разве смысл RoW не в том, чтобы обеспечить консистентность данных на время записи на случай пропажи питания? И я тогда не совсем понимаю когда именно старый блок помечается как free

Т.е. Запись txg атомарна, её номер в uberblock новом и будет записан емнип атомарно

Т.е. Запись txg атомарна, её номер в uberblock новом и будет записан емнип атомарно

Точнее не запись txg целиком, а факт 100% записи её атомарен