Антон, позвольте с вами частично не согласиться. Я конечно понимаю, что вы большой специалист из EMC, но у меня на руках за последние месяцы тонны тестовых материалов, так что...
1. Теория IOPS - это хорошо, но на практике не всё так гладко. Начнем с того, что у SAS в 3 раза меньше задержки (примерно 3 против 9). Потом, у SATA длина очереди 32 против 256 у SAS. Уж не знаю как там с теорией, но на практике RAID5 SAS 10к и RAID10 SATA 7.2к из примерно одинакового количества дисков работают ну с очень разной скоростью. И по пропускной способности и и особенно по латентности. Естественно, ВМ на этих датасторах ведут себя совершенно по разному.
При работе в 1 поток с дисковой подсистемой (думаю, процент таких приложений устрашает) всё упирается в её латентность. Пример: у нас гипотетическая хранилка на SATA, выдающая 5 миллионов IOPS (пусть такм миллион дисков будет), противопоставляем ей хранилку на SAS, которая выдаёт 1000 тех же самых IOPS. И вот у нас приложение пытается в 1 поток писать (или читать) с такой хранилки SATA. Задержка пусть будет 9ms. 1000/9=111 IOPS. Это тот максимум, который получит приложение. Что же у нас с SAS? При задержке в 3ms приложение получит уже 333 IOPS. И больше, и более отзывчиво. Так что не все йопсы одинаково полезны, как говорится. Их еще и реально получить как-то надо, а вот с этим возникают проблемы.
Ну, и открою всем очевидную тайну (вроде она на поверхности, но озвучивается редко). Все уровни RAID на чтение имеют практически идентичные IOPS. А вот запись сильно отличается. В принципе, Антон уже коснулся этого тезиса чуть выше.
2. Про дровишки. Уж вам ли не знать принцип работы гипервизора ESXi? ВМ работает с тем типом контроллера, который установлен для неё в виртуальном железе. И прослоек с различными виртуализациями систем хранения там как минимум 4 штуки, а может быть и более. Последними слоями занимается RAID контроллер и мозги самих дисков, а вот первые разгребает госевая ОС и гипервизор. ОС работет с диском, подозревая что это некий скази и шлёт ему соответствующие команды. В этом момент гипервизор снимает машину с физических ядер и отправляет в очередь WAIT, подделывая при этом запросы ВМ в необходимый гипервизору вид для общения с системой хранения (это может быть что угодно, iSCSI, FC, SAS, SATA и т.д.) Так что команды внутри ОС гостя и команды общения гипервизора с системой хранения - это действительно 3 большие разницы.
Кстати, раз уж тема зашла про IOPS, давайте я всем мозг взорву. На IOPS ВМ влияет не только тип и производительность системы хранения, но и процессы, происходящие внутри ВМ. А точнее параллельные обращения ВМ к вводу-выводу, а так же текущая нагрузка на процессоры хоста. Всё сказанное достоверно на 100% для iSCSI, но по видимому и для FC тоже актуально (надо проверять).
Итак, тестовый стенд:
2хXeon E5 2690
394 GB RAM
2x10 Gbit LAN Intel X540 T2
Хранилка 2xXeon 2609 + 192 GB RAM + Starwind 6 + Ramdrive 100GB + iSCSI 10 Gbit
Свитч Dell 8024 10 Gbit
Измеряем IOPS при помощи IOMETER, 100% случайное чтение в 1 поток блоками по 4к
Итак, физическая машина, будучи подключенной к этой системе хранения снимает 90к+ IOPS в один поток.
Измеряем из ВМ, (2 vCPU), получаем 4000 IOPS в 1 поток (в 256 потоков 90к IOPS тоже снимаются)
При этом нагрузка на процессоры хоста практически 0
По показателмя esxtop GAVG=DAVG= 0.22ms
Теперь нагружаем другими ВМ процессоры хоста до 80%.
Измеряем из ВМ, получаем 1900 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.4ms (как так? у нас система хранения виновата? Да ну?)
Убираем нагрузку с процов хоста, тестовая ВМ опять одна.
Но пробуем работать с сетью (у хоста 2 сетевых адаптера, один выделен под iSCSI, воторой под работу с сетью)
Копируем из сети большой файл и кладём его на диск ВМ (другой диск, не тот, который меряется на IOPS, он физически лежит на другой системе хранения)
Измеряем из ВМ, получаем 2000 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.32ms (опять?)
Ну и для верности
Пробуем работать с чистой сетью
Копируем из сети большой файл и кладём его обратно на сеть, то есть дисковая подсистема вообще никак не нагружается дополнительно.
Измеряем из ВМ, получаем 3000 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.31ms (и снова?)
Вот такие вот интересные показатели. Так что теория IOPS у систем хранения и практика VMWare не совсем равны. Продолжаю наблюдения...
P.S. ИМХО, во всём виноваты постановки ВМ в очередь WAIT при работе с вводом-выводом. Больше ничем не могу объяснить такую картину. Ответ ищу уже давно, но все молчат, в том числе гугл и специалисты VMWare. Может вы чего подскажете?
Ну, и просил коллег на других системах померить максимальные IOPS в 1 поток. Тоже упёрлись в 4000. Магическое число... И на Hyper-V тоже в 4000 упёрлись. Хранилки использовались правильные 2-головые, тоже на iSCSI 10 Gbit. Диски SSD.
Кстати, смотрел документацию на свитч Dell, который использовался в тесте. Так вот, он по идее даёт задержки в районе 3-4 микросекунд (0.003-0.004ms). Вероятно, оно тоже виновато.
P.P.S. К чему я это всё? А к тому, что если у вас машина интенсивно работает с вводом-выводом, и не дай Бог еще и параллельно с диском и сетью - то тормозить она будет качественно Image may be NSFW.
Clik here to view.
Как вариант, сервер баз данных Image may be NSFW.
Clik here to view.Но надо признать, что VMWare прямо не рекомендует виртуализовывать сервисы, имеющие гиперактивный ввод-вывод.