Size: a a a

2020 December 09

AD

Alexander Dobrynin in VMware vSAN
Nikolay Kulikov
вы пока так и не показали, что у вас проблема в очередях, чтобы это утверждать. Я кучу раз видел и тестировал NVMe+SATA - ни разу не было там проблем с очередями
Я исключил такой сценарий на SAS / NVMe что и подтверждает скриншот от коллег - там на графиках ронвые 1-2 мс для чтения, прыжки только на запись
источник

AD

Alexander Dobrynin in VMware vSAN
Nikolay Kulikov
а почему не HBA330 купили?
Отдельно их сложновато заказать, а заказ был сформирован до нас увы, там были h730-ые
источник

N

Nikolay Kulikov in VMware vSAN
Alexander Dobrynin
Я исключил такой сценарий на SAS / NVMe что и подтверждает скриншот от коллег - там на графиках ронвые 1-2 мс для чтения, прыжки только на запись
хотите такие же графики с NVMe+SATA?
источник

AD

Alexander Dobrynin in VMware vSAN
Nikolay Kulikov
хотите такие же графики с NVMe+SATA?
Охотно верю что на больших кластерах где все равномерно раскинуто все будет хорошо, у нас проблема "плотной застройки" никуда не девается, кластер все же небольшой
источник

N

Nikolay Kulikov in VMware vSAN
Alexander Dobrynin
Отдельно их сложновато заказать, а заказ был сформирован до нас увы, там были h730-ые
источник

a

a in VMware vSAN
Alexander Dobrynin
Охотно верю что на больших кластерах где все равномерно раскинуто все будет хорошо, у нас проблема "плотной застройки" никуда не девается, кластер все же небольшой
Алгоритм один и тот же плейсинга чанков, на больших кластерах тоже большие перекосы
источник

N

Nikolay Kulikov in VMware vSAN
Alexander Dobrynin
Охотно верю что на больших кластерах где все равномерно раскинуто все будет хорошо, у нас проблема "плотной застройки" никуда не девается, кластер все же небольшой
4 узла - Optane + SATA SSD
источник

N

Nikolay Kulikov in VMware vSAN
Alexander Dobrynin
Охотно верю что на больших кластерах где все равномерно раскинуто все будет хорошо, у нас проблема "плотной застройки" никуда не девается, кластер все же небольшой
опять таки - абсолютно нигде не было видно у вас перегрузки дисков/дисковых групп
источник

KS

Konstantin Statsenko in VMware vSAN
еще вам информация к размышлению - в прошлом году перед вводом в эксплуатацию гоняли тесты и выяснили интересную вещь - при включенном дедупе/компресии на R1FTT1 и R1FTT2 запись большим блоком (64к и выше) невероятно просаживает производительность и латенси улетает по непонятным причинам. Поэтому если у вас преобладает запись и большой блок то посмотрите как работают ВМ именно с R1FTTx и попробуйте поменять на R5FTT1, например.
источник

KS

Konstantin Statsenko in VMware vSAN
источник

KS

Konstantin Statsenko in VMware vSAN
источник

AD

Alexander Dobrynin in VMware vSAN
На момент прихода из доступных вариантов быстрых были LSI родные, что в принципе ничему не противоречит, возможно стоит поменять на HBA330 для полного феншуя
источник

AD

Alexander Dobrynin in VMware vSAN
Nikolay Kulikov
опять таки - абсолютно нигде не было видно у вас перегрузки дисков/дисковых групп
Обещал скриншоты к следующему разу, пока ждем как всплывет
источник

AD

Alexander Dobrynin in VMware vSAN
Konstantin Statsenko
еще вам информация к размышлению - в прошлом году перед вводом в эксплуатацию гоняли тесты и выяснили интересную вещь - при включенном дедупе/компресии на R1FTT1 и R1FTT2 запись большим блоком (64к и выше) невероятно просаживает производительность и латенси улетает по непонятным причинам. Поэтому если у вас преобладает запись и большой блок то посмотрите как работают ВМ именно с R1FTTx и попробуйте поменять на R5FTT1, например.
Спасибо за информацию, проверим, пока из яркого увы на чистом чтении наблюдается
источник

N

Nikolay Kulikov in VMware vSAN
Konstantin Statsenko
еще вам информация к размышлению - в прошлом году перед вводом в эксплуатацию гоняли тесты и выяснили интересную вещь - при включенном дедупе/компресии на R1FTT1 и R1FTT2 запись большим блоком (64к и выше) невероятно просаживает производительность и латенси улетает по непонятным причинам. Поэтому если у вас преобладает запись и большой блок то посмотрите как работают ВМ именно с R1FTTx и попробуйте поменять на R5FTT1, например.
потому что в destage уперлись. на Mirror больше данных летит в буфер, активнее идет destage. в последних 6.7U3 и 7U1 скорость дестейджа заметно увеличили (хотя в нее все равно можно упереться на больших workload set). Это одна из причин появления Compression Only - там разницы нет практически
источник

N

Nikolay Kulikov in VMware vSAN
Имеено поэтому и говорю, что Erasure Coding часто бывает быстрее Mirror при включенном DD&С
источник

DG

Dmitry Gorokhov in VMware vSAN
V
А чем h730 не зашли? Они в списке совместимого железа до 7.01.
С глубиной очереди команд по сравнению с hba330 там грустно
источник

AD

Alexander Dobrynin in VMware vSAN
Nikolay Kulikov
вы пока так и не показали, что у вас проблема в очередях, чтобы это утверждать. Я кучу раз видел и тестировал NVMe+SATA - ни разу не было там проблем с очередями
Вот за ночь, словилась желтая зона по latency, OIO улетел ближе к 850
источник

AD

Alexander Dobrynin in VMware vSAN
Кто там такой говорливый уточняем
источник

N

Nikolay Kulikov in VMware vSAN
Alexander Dobrynin
Вот за ночь, словилась желтая зона по latency, OIO улетел ближе к 850
а какой там размер блока в этот момент - посчитайте плз. Видно 600MB/s, а сколько IOPS - не видно
источник