iSCSI, программный, вопрос производительности

Поломалось, посыпалось, не работает...

Модераторы: Trinity admin`s, Free-lance moderator`s

dim-soft
Advanced member
Сообщения: 441
Зарегистрирован: 03 авг 2009, 21:25
Откуда: Perm

Re: iSCSI, программный, вопрос производительности

Сообщение dim-soft » 11 мар 2012, 08:24

KOOLER писал(а):Кстати, вы знаете, что у ESXi нет честного multipathinga?
* IOPS параметр с дефолтового 1000 на 1, 2 или 5 менять не пробовали? С 4.1 AFAIK
* Подразумевает переход на другой канал после достижения трешхолд. Если IOPS = 2, а каналов два (А) и (В), то
будет на 4 запросах 1А, 2А, 3В, 4В. Все каналы задействованы. В чем проблема-то?
а где в esxi 5.0 этот параметр настроить ?
сколько не пробовал, из 4 гигабитных каналов на СХД и 3 гигабитных на esxi больше 125 мегабайт выжать не могу, локально СХД 300-400 дает.

KOOLER
Advanced member
Сообщения: 54
Зарегистрирован: 12 ноя 2011, 15:18
Откуда: Киев

Re: iSCSI, программный, вопрос производительности

Сообщение KOOLER » 11 мар 2012, 18:06

Вот тут посмотрите:

http://henriwithani.wordpress.com/2012/ ... on-esxi-5/

Ну, это еще все как минимум от самой железки зависит. Половина EMC, к примеру, которые вроде как active-active, на самом деле ALUA:

http://www.boche.net/blog/index.php/201 ... c-storage/

Я бы начал со статистики по портам на самом свиче на выполнении какой-то долговременной операции.
dim-soft писал(а):
KOOLER писал(а):Кстати, вы знаете, что у ESXi нет честного multipathinga?
* IOPS параметр с дефолтового 1000 на 1, 2 или 5 менять не пробовали? С 4.1 AFAIK
* Подразумевает переход на другой канал после достижения трешхолд. Если IOPS = 2, а каналов два (А) и (В), то
будет на 4 запросах 1А, 2А, 3В, 4В. Все каналы задействованы. В чем проблема-то?
а где в esxi 5.0 этот параметр настроить ?
сколько не пробовал, из 4 гигабитных каналов на СХД и 3 гигабитных на esxi больше 125 мегабайт выжать не могу, локально СХД 300-400 дает.

KOOLER
Advanced member
Сообщения: 54
Зарегистрирован: 12 ноя 2011, 15:18
Откуда: Киев

Re: iSCSI, программный, вопрос производительности

Сообщение KOOLER » 11 мар 2012, 22:46

Вот еще одна ссылка, кой-чего с цифрами:

http://jpaul.me/?tag=vsphere-5

Хотя в зависимости от нагрузки имеет смысл ставить полиси переключения каналов не по IOPS, а по BYTES.
dim-soft писал(а):
KOOLER писал(а):Кстати, вы знаете, что у ESXi нет честного multipathinga?
* IOPS параметр с дефолтового 1000 на 1, 2 или 5 менять не пробовали? С 4.1 AFAIK
* Подразумевает переход на другой канал после достижения трешхолд. Если IOPS = 2, а каналов два (А) и (В), то
будет на 4 запросах 1А, 2А, 3В, 4В. Все каналы задействованы. В чем проблема-то?
а где в esxi 5.0 этот параметр настроить ?
сколько не пробовал, из 4 гигабитных каналов на СХД и 3 гигабитных на esxi больше 125 мегабайт выжать не могу, локально СХД 300-400 дает.

dreamond
Junior member
Сообщения: 3
Зарегистрирован: 05 мар 2012, 23:22
Откуда: Москва

Re: iSCSI, программный, вопрос производительности

Сообщение dreamond » 12 мар 2012, 01:27

KOOLER писал(а):Проблем вижу "с ходу" две:

1) не надо аггрегировать гигабиты по 4 штуки - попробуйте взять 10 гигабит. Как минимум пару для построения бэкбона на старвинде (для хартбита и резервного канала можно гигабит взять). Никакие транки на бэкбон ставить не надо, с 5.8 уже MPIO идет собственный (MS медленный). Народ вот радуется:

http://www.starwindsoftware.com/forums/ ... t2691.html
Кто бы сомневался что 10 гигабит лучше, однако тут же встает вопрос коммутатора- а коммутатор на 10 гигабит по цене ощутимо влияет на бюджет
KOOLER писал(а): 2) у вас явно не хватит IOPS при миграции physical -> virtual. SATA диски у нас 50 IOPS, RAID1 добавит на чтении 20-30%, правильный мультипас на две ноды почти удвоит все. Я вижу 120 IOPS, а реально 100. IMHO у вас все встанет раком. SAS нужен (( Вот тут:

http://blogs.hds.com/claus/2011/09/putt ... -view.html

не самая лучшая статья про расчет производительности систем, но математика объяснена верно.
Вот тут по всей видимости мне требуется уточнение- что вы имеете ввиду под
миграции physical -> virtual
имеется ввиду сама миграция на виртуализацию (использование VMconvertor) или то что в продакшене клином встанут сервера?

Если дело касается непосредственно самой миграции, то VMConvertor использовать я не собирался- все сервера (т.е их функции) поддерживают штатную репликацию и передачу ролей своими средствами. Да и везде рекомендуется не конвертировать БД (и в особенности AD )- поэтому я собирался поднимать реплики на виртуалках.

Что же касается IOps- то тестирование Iometer на уже имеющихся дисках SATA в raid 1 (и диски и контроллер пойдут в бой) показало следующие результаты

threads IOps Read IOps Write IOps
1 157,499006 105,589855 51,909151
2 246,175401 164,566779 81,608623
4 285,769147 191,329823 94,439325
8 323,969865 216,9734 106,996465
16 379,070145 253,081449 125,988697
32 398,909082 267,162794 131,746288
64 412,26142 276,464561 135,796858
128 426,899487 285,893799 141,005688
256 440,002028 294,594627 145,407402


Использовались сл. настройки
of Outstanding I/Os = 256
Block Size = 8K
Randomness = 100%
Read/write Ratio = 66% read (34% write)

Вроде бы все в порядке- или я чего то в упор не понимаю?

KOOLER писал(а): Вообще собирайте тестовый стенд и пробуйте (присейлз все равно бесплатный). Не понравится - разберете и поставите OpenIndiana + ZFS :))
Разумеется- жду когда придут сетевухи и коммутатор

PS с соляроподобными дистрибутивами в жизни дела не имел, вообще стоит на него внимание обратить?

KOOLER
Advanced member
Сообщения: 54
Зарегистрирован: 12 ноя 2011, 15:18
Откуда: Киев

Re: iSCSI, программный, вопрос производительности

Сообщение KOOLER » 12 мар 2012, 10:57

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

2) Я не имел в виду сложности перехода P2V, я про нагрузку говорил, которую ваши приложения на дисковую подсистему оказывают.

3) Вот вам этих 400 IOPS (возьмите 512 байт блоки, кстати) хватит на ваши все виртуальные машины? Сейчас посмотрите PerfMon на каждой физической машине - какая там нагрузка? Вот неплохая статья - как рассчитывать IOPS:

http://blog.synology.com/blog/?p=146

4) Да, почему нет? OpenIndiana + Napp-It дадут вам приблизительно все то же, только вы не деньгами платить будете, а своим временем ,)
dreamond писал(а):
KOOLER писал(а):Проблем вижу "с ходу" две:

1) не надо аггрегировать гигабиты по 4 штуки - попробуйте взять 10 гигабит. Как минимум пару для построения бэкбона на старвинде (для хартбита и резервного канала можно гигабит взять). Никакие транки на бэкбон ставить не надо, с 5.8 уже MPIO идет собственный (MS медленный). Народ вот радуется:

http://www.starwindsoftware.com/forums/ ... t2691.html
Кто бы сомневался что 10 гигабит лучше, однако тут же встает вопрос коммутатора- а коммутатор на 10 гигабит по цене ощутимо влияет на бюджет
KOOLER писал(а): 2) у вас явно не хватит IOPS при миграции physical -> virtual. SATA диски у нас 50 IOPS, RAID1 добавит на чтении 20-30%, правильный мультипас на две ноды почти удвоит все. Я вижу 120 IOPS, а реально 100. IMHO у вас все встанет раком. SAS нужен (( Вот тут:

http://blogs.hds.com/claus/2011/09/putt ... -view.html

не самая лучшая статья про расчет производительности систем, но математика объяснена верно.
Вот тут по всей видимости мне требуется уточнение- что вы имеете ввиду под
миграции physical -> virtual
имеется ввиду сама миграция на виртуализацию (использование VMconvertor) или то что в продакшене клином встанут сервера?

Если дело касается непосредственно самой миграции, то VMConvertor использовать я не собирался- все сервера (т.е их функции) поддерживают штатную репликацию и передачу ролей своими средствами. Да и везде рекомендуется не конвертировать БД (и в особенности AD )- поэтому я собирался поднимать реплики на виртуалках.

Что же касается IOps- то тестирование Iometer на уже имеющихся дисках SATA в raid 1 (и диски и контроллер пойдут в бой) показало следующие результаты

threads IOps Read IOps Write IOps
1 157,499006 105,589855 51,909151
2 246,175401 164,566779 81,608623
4 285,769147 191,329823 94,439325
8 323,969865 216,9734 106,996465
16 379,070145 253,081449 125,988697
32 398,909082 267,162794 131,746288
64 412,26142 276,464561 135,796858
128 426,899487 285,893799 141,005688
256 440,002028 294,594627 145,407402


Использовались сл. настройки
of Outstanding I/Os = 256
Block Size = 8K
Randomness = 100%
Read/write Ratio = 66% read (34% write)

Вроде бы все в порядке- или я чего то в упор не понимаю?

KOOLER писал(а): Вообще собирайте тестовый стенд и пробуйте (присейлз все равно бесплатный). Не понравится - разберете и поставите OpenIndiana + ZFS :))
Разумеется- жду когда придут сетевухи и коммутатор

PS с соляроподобными дистрибутивами в жизни дела не имел, вообще стоит на него внимание обратить?

ster
Junior member
Сообщения: 3
Зарегистрирован: 30 сен 2014, 10:44

Re: iSCSI, программный, вопрос производительности

Сообщение ster » 30 сен 2014, 10:53

Добрый день!
Есть вопрос по ISCSI.
т.к. вопрос больше не технический, а пользовательский решил не создавать новую тему.

Имеется NAS synology и имеется игровой компьютер. Соединены гигагибтным свитчом.
На компьютере стоит всего один SD диск на 128Гб, для операционной системы и офисных приложений.

Задумка была в том, чтобы хранить большие игрушки на NAS и загружать (стартовать) их через сеть.
Но, как всегда, не все так просто. При стандартном решении (подключение удаленных дисков):

1. Большая часть игрушек не запускается, причем иногда даже без выдачи каких-либо ошибок.
Скорее всего это связано с архитектурой игр.
2. Часть игрушек нельзя установить на удаленный диск. Либо зависает, либо вылетает.
3. Те игрушки, которые запускаются, грузятся по 2-3 мин. Учитывая гигагибтный свитч (~100 мб/сек), скорость загрузки по сети должна равняться скорости среднестатистического жесткого диска HHD. Хотя я могу ошибаться!

В итоге получается, что реализация моей задумки через подключение обычного удаленного диска не к чему хорошему не привела. sad.gif

В данный момент все диски NASа объедены в единый рейд и экспериментировать с ними честно говоря не сильно хочется.

Интересует вопрос как iSCSI LUN отражен на удаленной системе?
Каждый созданный блок (LUN) отражается как удаленный (сетевой) диск или же система, в частности windows, считает его собственным диском (как обычный диск "С")?

Если как свой, то скорее всего это снимет проблемы пунктов 1, 2, а возможно и 3.
С третьем как-то можно прожить, а вот первые два...

Заранее спасибо за ответ.

Ответить

Вернуться в «Массивы - Технические вопросы, решение проблем.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 18 гостей