Сегодня не удержался и потестил скорость между VM-ками на одном хосте и между VM-ками на двух разных хостах. Оба хоста HP Blade сервера соединенные по 10Гбит к внутренней фабрике Virtual Connect.
между двумя хостами
между двумя хостами с TCP Windows 256K
Между двумя хостами с TCP Window 256K и JF 4K (увы, физическое ограничение встроенной сетевой карты в HP BL460c )
Между двумя хостами с TCP Window 256K и JF 4Kб, 8 сессий
Тут мы уже в физику уперлись.
На одном хосте, TCP Window 16K
На одном хосте, TCP Window 256K
Странно, тут почему то производительность оказалась ниже — может я в чем то ошибся.
На одном хосте, TCP Window 256K, JF 9K
На одном хосте, TCP Window 256K, JF 9K, 8 сессий
В принципе почти везде производительность упиралась в ограничения ОС и ее сетевого стека.
Меня заверяли, что разница в производительности наблюдалась между ram диском на физической машине и виртуальной, поэтому гипервизор тоже играет свою роль.
Сложно ответить не имея подробных данных. Я, кстати, уже второй раз слышу про низкие результаты скорости ram дисков в виртуальных машинах.
Какой процессор в вашем хосте? Какая именно ОС? Как называется аналог tmpfs для Windows? сколько выделили RAM диску? Чем замеряли скорость?
Я попробую сделать замер с условиями близкими к вашим и сравним. А потом уже попробуем сделать выводы.
Конечно, всерьез прям сейчас переход на новый продукт мало кто собирался делать, но для VMware риском является уже то, что клиенты начали прикидывать переход в долгосрочной перспективе.
Слухи, кстати, уже почти официальные. :)
amarao, я пока еще «ненастоящий сварщик», который vSphere впервые увидел 8 месяцев назад, а первый XenServer поставил дома на лабе только позавчера, поэтому подобное сравнение я сейчас не смогу провести. Вот вы бы сами взялись бы за это дело :)
почему пиар? по моему это все таки ударило по компании — за эти две недели достаточно много компаний начало прикидывать и оценивать конкурентные продукты от MS и Citrix.
Анекдот не знаю, но все это выглядит как обычный факап, который в принципе случается у всех — главное то, как быстро были меры: проведены опросы, проанализирована полученная информация и принято решение. Видимо в самой VMware было очень жарко эти дни.
Ну я стараюсь использовать active и standby аплинки.
Например, у меня три port group: первая для management vmknic, вторая для ВМ и траться для vmotion. При этом у меня всего 2 10 Гб интерфейса.
Для первых двух Port group активным является первый аплинк, а второй в режиме standby, и для vmotion у нас второй аплинк активный, а первый в резерве. трафик любого упавшего интерфейса или физического коммутатора прозрачно перекинется на уцелевший аплинк.
Это очень упрощенный пример и в реальной жизни все куда сложней, и уверен, что мой пример не всегда целесообразен, но идею мою он объясняет и экономит как минимум пару аплинков и портов.
А не сильно режут глаз аббревиатуры на английском? может стоит чаще использовать аналог на русском языке? честно говоря, это для меня самая сложная часть написания, потому что на русском я почти не читал техническую литературу, над банальным shared memory я долго ломал голову.
Коллеги, я очень хочу, чтобы мои опусы становились с каждым разом все лучше и лучше и поэтому был бы очень благодарен, если бы вы аргументировали свои минусы.
Я к тому, что когда у вас случится проблема на vSphere в поддержке вам может быть отказано. я вот так же поднимал у себя MS failover cluster на виртуальных машинах, а когда наткнулся на проблему, мне в службе поддержке VMware сказали — MS Cluster на EVA 6400 не поддерживается.
Ну и по стандартам компании у нас разве что тестовые лабы работают на железе без поддержки — все остальное обязательно должно иметь support contract.
ну iSCSI в принципе тоже не сложен в настройке. Высокая пропускная способность тоже есть.
Последние тесты производительности FCP/FCoe/iSCSI тоже не показывают существенной разницы. В принципе весь трафик, как сетевой, так и iSCSI можно пустить через производительные свитчи. С какими нить HP VC FlexFabric и G7 серверами мне кажется iSCSI вообще идеальным вариант.
Ага, я уже у них там все перечитал. Netapp тоже один из альтернативных вариантов, как более удачный продукт для виртуализации, но у нас традиционно HP EVA везде.
между двумя хостами
между двумя хостами с TCP Windows 256K
Между двумя хостами с TCP Window 256K и JF 4K (увы, физическое ограничение встроенной сетевой карты в HP BL460c )
Между двумя хостами с TCP Window 256K и JF 4Kб, 8 сессий
Тут мы уже в физику уперлись.
На одном хосте, TCP Window 16K
На одном хосте, TCP Window 256K
Странно, тут почему то производительность оказалась ниже — может я в чем то ошибся.
На одном хосте, TCP Window 256K, JF 9K
На одном хосте, TCP Window 256K, JF 9K, 8 сессий
В принципе почти везде производительность упиралась в ограничения ОС и ее сетевого стека.
Какой процессор в вашем хосте? Какая именно ОС? Как называется аналог tmpfs для Windows? сколько выделили RAM диску? Чем замеряли скорость?
Я попробую сделать замер с условиями близкими к вашим и сравним. А потом уже попробуем сделать выводы.
Слухи, кстати, уже почти официальные. :)
Например, у меня три port group: первая для management vmknic, вторая для ВМ и траться для vmotion. При этом у меня всего 2 10 Гб интерфейса.
Для первых двух Port group активным является первый аплинк, а второй в режиме standby, и для vmotion у нас второй аплинк активный, а первый в резерве. трафик любого упавшего интерфейса или физического коммутатора прозрачно перекинется на уцелевший аплинк.
Это очень упрощенный пример и в реальной жизни все куда сложней, и уверен, что мой пример не всегда целесообразен, но идею мою он объясняет и экономит как минимум пару аплинков и портов.
Жаль, что никто так и не поделился конкретными цифрами.
Ну и по стандартам компании у нас разве что тестовые лабы работают на железе без поддержки — все остальное обязательно должно иметь support contract.
Последние тесты производительности FCP/FCoe/iSCSI тоже не показывают существенной разницы. В принципе весь трафик, как сетевой, так и iSCSI можно пустить через производительные свитчи. С какими нить HP VC FlexFabric и G7 серверами мне кажется iSCSI вообще идеальным вариант.