[Ilya Evseev]

Кстати, миграция на КВМ - у кого получилось?

У меня. Главный нюанс - образы дисков.

Для нормальной скорости и гибкости надо заводить для них LVM.

Детали можете почитать в http://www.opennet.ru/openforum/vsluhforumID1/91666.html

[d1m0n]

Подниму старую тему. Хочется больше мнений и критики. Итак, есть тазик с биллингом, на нем софтрейд, MySQL, Radius, DHCP, сервер статистики, есть тазик с сервисами типа DNS и лёгким роутингом для нужд компании, есть тазик для тестов... В общем думаю перенести всё это на VMware, ибо уже есть некоторый опыт - остальные сервисы (второй DNS, почта, хостинг и т.д.) крутятся в виртуалках. Т.е. получится примерно так (№ контейнера - задача): 1 - Radius, 2 - DHCP, 3 - DNS и т.д. Внешнего хранилища не будет - денег не хватит. Так вот главный вопрос: стоит ли БД биллинга переносить в виртуальную машину?

[^rage^]

Можно поспорить. Мне известен случай, когда делали решение на vspere исключительно из-за прозрачной(по отношению к ОС и приложениям) кластеризации, т.к. иногда затраты на имплементацию программной кластеризации слишком велики, проще сделать vmware FT

 

FT накладывает неслабые ограничения: только 1 vCPU и максимум 4Gb RAM для гостя. Оно того стоит? Это не считая 10GE линков между нодами.

 

На OpenVZ такое руками (с использованием dump/restore встроенных) реализовывал - можно, но грабельно, в Virtuozzo вроде из коробки, но в данном случае коммерческого решения не пробовал, увы. На KVM лучше даже не пробовать (хотя... может что-то уже изменилось, давно не трогал) :)

vzmigrate же.

[NiTr0]

Так вот главный вопрос: стоит ли БД биллинга переносить в виртуальную машину?

Ну если вам не жалко бешеного оверхида на дисковые i/o - можете переносить. На деле же в виртуалку стоит совать только то, что а) требует изоляции б) допускает несколько минут на подъем в) не имеет активного ввода-вывода, как дискового так и сетевого. Все остальное - должно крутиться на реальном железе. К слову, на котором вполне могут уживаться и виртуальные машины. Можете прогнать тесты - результат на виртуалке будет печален.

[^rage^]

Ну если вам не жалко бешеного оверхида на дисковые i/o - можете переносить.

 

откуда там бешеный оверхед? )) паравиртуальные драйвера не просаживают производительность.

[Aliech]

Ну если вам не жалко бешеного оверхида на дисковые i/o - можете переносить.

 

откуда там бешеный оверхед? )) паравиртуальные драйвера не просаживают производительность.

Просаживают, любые просаживают. В той или иной степени. Вопрос в задачах. А вот насчёт бешеного оверхида - тож не согласен.

[s.lobanov]

^rage^

люди старой закалки, они такие, консервативные, от "новых технологий" стараются спрятаться.

[NiTr0]

откуда там бешеный оверхед? )) паравиртуальные драйвера не просаживают производительность.

Имел опыт с паравиртуальным сторэджем в kvm. Впечатления - далеко не позитивные. Какие-то 600 источников данных в кактусе вызывали скукоживание виртуальной машины в непрерывное ожидание окончания i/o...

Оверхид по любому будет. Переключение контекста, с сохранением всех регистров - далеко не мгновенное, а при интенсивном вводе-выводе - оно случается весьма часто.

[martin74]

на виртуалках вмвари крутится у меня почти все. И что то я там скукоживания не замечаю...

[NiTr0]

Сравните производительность/нагрузку на проц из-под виртуальной машины и при разворачивании поверх реального железа. Думаю, разница в разы будет...

[martin74]

сравнивал. И не раз. На vmware не недисковых задачах (виртуализировать высоконагруженный фтп сервер не будем) разница в производительности - единицы процентов...

[NiTr0]

На vmware не недисковых задачах...

А с чего начинался спор:

Ну если вам не жалко бешеного оверхида на дисковые i/o - можете переносить.

 

Оверхид на любой ввод-вывод данных в/из виртуалки есть. И солидный. Будь то сеть или дисковая подсистема. И игнорировать его не стоит. Хотя в случае сети VT-d несколько должно спасти, да и оверхид на дисковые операции таким образом скорее всего удастся снизить (iscsi через сеть, проброшенную через VT-d в гостевую систему) - но это пока гипотеза, не подтвержденная практикой.

А вот тупо вычислительные задачи, с минимальным i/o (пример: веб-сервер) - да, виртуализируются на ура :)

[SergeiK]

На vmware не недисковых задачах...

А с чего начинался спор:

Ну если вам не жалко бешеного оверхида на дисковые i/o - можете переносить.

 

Оверхид на любой ввод-вывод данных в/из виртуалки есть. И солидный. Будь то сеть или дисковая подсистема. И игнорировать его не стоит. Хотя в случае сети VT-d несколько должно спасти, да и оверхид на дисковые операции таким образом скорее всего удастся снизить (iscsi через сеть, проброшенную через VT-d в гостевую систему) - но это пока гипотеза, не подтвержденная практикой.

А вот тупо вычислительные задачи, с минимальным i/o (пример: веб-сервер) - да, виртуализируются на ура :)

 

Да какой он солидный-то?

Если у вас дисковая система на Sata-ых дисках, так любая, нагруженная разнородными задачами, система умрет.

А если у вас система хранения - то оверхэд минимальный.

По сетевой части - та же петрушка. Вот под VMware Cisco Nexus 1000-v встает, при незначительном эффекте на производительность нормальной системы.

 

Главное в виртуализации - чтоб памяти на все хватало и с запасом. В остальном - значительных проблем не замечалось.

[NiTr0]

Да какой он солидный-то?

А такой. Дисковый запрос в виртуалке -> переключение контекста в хост-систему -> чтение хост-системой с винта -> передача в буфер гостевой системы -> переключение контекста в гостевую систему. Аналогично и сетевая подсистема. Это для паравиртуализированных дров; для эмуляции девайсов все намного печальнее.

 

Если у вас дисковая система на Sata-ых дисках, так любая, нагруженная разнородными задачами, система умрет.

Даже если на SSD - это не помешает системе скукожиться из-за частого переключения контекста.

 

А если у вас система хранения - то оверхэд минимальный.

Дык нет же у вопрошающего системы хранения. Да и сомневаюсь, что она станет волшебной пилюлей...

 

Главное в виртуализации - чтоб памяти на все хватало и с запасом.

Не только. Еще очень важно, чтобы голов процессора хватало для переваривания всех виртуалок. Ибо когда 2 виртуалки начинают биться за ресурсы проца, и каждая стремится откусить побольше - результатом может оказаться внезапное падение производительности в разы. Благодаря затратам на переключение контекста и вымыванию кеша...

[SergeiK]

Да какой он солидный-то?

А такой. Дисковый запрос в виртуалке -> переключение контекста в хост-систему -> чтение хост-системой с винта -> передача в буфер гостевой системы -> переключение контекста в гостевую систему. Аналогично и сетевая подсистема. Это для паравиртуализированных дров; для эмуляции девайсов все намного печальнее.

Я не являюсь гуру в современном железе, тем более, на самом низком уровне.

Но думается мне, все заметно сложнее нынче.

Уже давно процессоры поддерживают аппаратную виртуализацию, и, я полагаю, много подобных проблем там решили.

Понятно, что будет оверхед, но он копеечный, если сравнивать стоимость дополнительного процессора со стоимостью отдельного железа под отдельную систему.

А если вешать на один целерон 10 нагруженных виртуалок - так необходимость пользоваться головой виртуализация не отменяет. Как и большинство других технологий.

[Aliech]

Сравните производительность/нагрузку на проц из-под виртуальной машины и при разворачивании поверх реального железа. Думаю, разница в разы будет...

Вы предлагаете сравнивать загрузку проца одним приложением и целой ВМ?)

 

В общем-то говоря, аппаратная виртуализация нас всех давным-давно спасла, да. То, что вы писали про оверхид на I/O - почти что правда, за исключением того, что эпитет "бешеный" выдаёт, скорее всего, отсутствие шагов по оптимизации и тюнингу хост-машины, а так же гостей с вашей стороны. Сие не понятно мне, так как роутеры вы пилить не гнушаетесь, а ноды виртуализации, оказывается, не заслуживают такого внимания. Хотя тоже, надо отметить, крайне важная в продакшне вещь. Ответственный участок, так сказать.

 

Возможно вам проще иметь много железа на резерве, или вы не против вляпываться в "виртуальные контейнеры" а-ля OpenVZ, но лично я не стану ставить для DNS-сервера отедльную железку, когда есть кластер ВМ с резервированием. Тем более не буду полагаться на хитрый винигред из внутриядерных разграничений ресурсов, т.е. на VZ.

 

С другой стороны, огромные файло-помойки на ВМ тоже ставить глупо)

[Aliech]

Уже давно процессоры поддерживают аппаратную виртуализацию, и, я полагаю, много подобных проблем там решили.

Понятно, что будет оверхед, но он копеечный, если сравнивать стоимость дополнительного процессора со стоимостью отдельного железа под отдельную систему.

 

I/O - забота ОС, правильно всё товарищ написал. Другой вопрос в том, надо ещё потратить время на готовку, и всё будет не совсем печально, как минимум. А аппаратная виртуализация заботится только о CPU, да о памяти. Есть ещё блекджек ввиде DMA и проброса таблиц ACPI в VM (IOMMU / Vt-d), но это, зачастую, нужно тем, кто роутеры в VM собирает. Я лично против таких извращений. (Иногда, правда, бывает полезно. Я так USB-хосты прокидываю с шины PCI, когда какой-нибудь телефон надо прошить. Но это не о продакшне).

[^rage^]

Сравните производительность/нагрузку на проц из-под виртуальной машины и при разворачивании поверх реального железа. Думаю, разница в разы будет...

нет там этих "в разы". более того, циферки виртуалки могут быть даже больше, чем реальной железки(засчёт кеширования на хост ОС).

[^rage^]

Да какой он солидный-то?

А такой. Дисковый запрос в виртуалке -> переключение контекста в хост-систему -> чтение хост-системой с винта -> передача в буфер гостевой системы -> переключение контекста в гостевую систему. Аналогично и сетевая подсистема. Это для паравиртуализированных дров; для эмуляции девайсов все намного печальнее.

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

посмотри на то, как устроены virtio. там кольцевой буфер. гость запихивает в него как можно больше запросов, потом делает kick.

как пример ещё посмотри на NAPI и его работу с pci-карточками. если бы на каждый пакет вызывалось прерывание, любой более-менее приличный пакетрейт приводил к печальным последствиям.

 

Не только. Еще очень важно, чтобы голов процессора хватало для переваривания всех виртуалок. Ибо когда 2 виртуалки начинают биться за ресурсы проца, и каждая стремится откусить побольше - результатом может оказаться внезапное падение производительности в разы. Благодаря затратам на переключение контекста и вымыванию кеша...

с чего ли им биться? это не ситуация, когда 2 программы бьются за общий ресурс, т.к. тут есть арбитр в виде гипервизора. откуда такие выводы не имея данных с какой частотой гостям выделяются кванты времени?

[NiTr0]

Но думается мне, все заметно сложнее нынче.

Уже давно процессоры поддерживают аппаратную виртуализацию, и, я полагаю, много подобных проблем там решили.

Не в тему. Аппаратная виртуализация никоим образом не поможет виртуалке увидеть раздел поверх DRBD как блочное устройство...

 

Понятно, что будет оверхед, но он копеечный, если сравнивать стоимость дополнительного процессора со стоимостью отдельного железа под отдельную систему.

Падение производительности в 2-3 раза и полный затык при активном дисковом i/o.

 

Вы предлагаете сравнивать загрузку проца одним приложением и целой ВМ?)

А что еще оверхидом зовется? Или как его сравнить иначе? :)

 

В общем-то говоря, аппаратная виртуализация нас всех давным-давно спасла, да. То, что вы писали про оверхид на I/O - почти что правда, за исключением того, что эпитет "бешеный" выдаёт, скорее всего, отсутствие шагов по оптимизации и тюнингу хост-машины, а так же гостей с вашей стороны.

Аппаратная виртуализация к виртуализации ввода-вывода в общем-то никакого отношения не имеет...

По части тюнинга - как-то проще ресурсоемкие по части ввода-вывода сервисы вынести подальше из виртуалок, оставив там вычислительные изолированные песочницы - в которых крутятся сервисы, не шибко активно общающиеся по сети и с диском.

 

Возможно вам проще иметь много железа на резерве, или вы не против вляпываться в "виртуальные контейнеры" а-ля OpenVZ, но лично я не стану ставить для DNS-сервера отедльную железку, когда есть кластер ВМ с резервированием. Тем более не буду полагаться на хитрый винигред из внутриядерных разграничений ресурсов, т.е. на VZ.

Мне проще изолировать только те сервисы, которые нуждаются в изолировании. Веб - да, экспериментальные площадки - да, но БД - увольте. Когда реальная железка, крутящая БД, начинает скукоживаться - становится как-то боязно подумать, что будет с виртуалкой.

 

С другой стороны, огромные файло-помойки на ВМ тоже ставить глупо)

Почему, если оверхид, по-вашему, незаметный? :)

 

нет там этих "в разы". более того, циферки виртуалки могут быть даже больше, чем реальной железки(засчёт кеширования на хост ОС).

Поставьте фтп, налейте туда гигов 40 мелких файлов, сделайте рандомное чтение в виртуалке потоков в 20, и на реальной машине.

Поставьте PPPoE сервер, прогоните iperf в виртуалке и на реальной машине, мелкими пакетами.

Думаю, разница наглядно покажет "разы"...

[Aliech]

А что еще оверхидом зовется? Или как его сравнить иначе? :)

Ммм... В виртуальной машине (не VZ контейнере) куча ещё сервисов крутится. Это - накладные расходы с которыми ты согласен изначально. И ни сколько не свидетельствует о недостатке технологи.

 

Аппаратная виртуализация к виртуализации ввода-вывода в общем-то никакого отношения не имеет...

А я сие и не отрицал. Более того:

I/O - забота ОС, правильно всё товарищ написал.

 

Мне проще изолировать только те сервисы, которые нуждаются в изолировании. Веб - да, экспериментальные площадки - да, но БД - увольте. Когда реальная железка, крутящая БД, начинает скукоживаться - становится как-то боязно подумать, что будет с виртуалкой.

БД бывают разные) Я и не предлагал втыкать виртуализацию везде. Мой пример был - DNS сервер. Там не ахти какая нагрузка в сторону диска. А с сетью траблов я не замечал совсем. Памяти по-больше и всё в ажуре.

И, кстати, для жирных БД, когда тот же PostgreSQL требует отдельные дисковые устройства для файлов журнала, о плюсах виртуализации можно забыть. Это правильно отмечено.

 

Почему, если оверхид, по-вашему, незаметный? :)

Выше ^rage^ отлично описал паравиртуализацию ввода-вывода. Накладные расходы не большие. А вот в отзывчивости можно потерять. Для web-сервера Василия Пупкина сие не страшно, а вот нагруженному серверу CRM может повредить. Но, внезапно, может оказаться, что проще иметь 4 виртуальных машины с кластером этого CRM, чем один такой сервер...

 

Так что это всё - инструмент, который выбирается под задачу.

[NiTr0]

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

посмотри на то, как устроены virtio. там кольцевой буфер. гость запихивает в него как можно больше запросов, потом делает kick.

как пример ещё посмотри на NAPI и его работу с pci-карточками. если бы на каждый пакет вызывалось прерывание, любой более-менее приличный пакетрейт приводил к печальным последствиям.

Ставил кактус на виртуалку. Захлебывался. Поставил на реальную машину, более слабую. Тащит в 2 раза больше хостов и не жужжит.

А NAPI начинает работать только тогда, когда процессор не успевает обрабатывать все прерывания :) Со всеми вытекающими - на юзерленд тогда времени не остается совсем. Не даром в свое время патчили e100, дабы выгребать данные не мгновенно, а по таймеру на следующий джиффи...

Interrupt moderation - из другой оперы будет.

 

с чего ли им биться? это не ситуация, когда 2 программы бьются за общий ресурс, т.к. тут есть арбитр в виде гипервизора. откуда такие выводы не имея данных с какой частотой гостям выделяются кванты времени?

Банальное наблюдение за реальной ситуацией. Есть 2 виртуальные машины, KVM. По 2 головы. Есть 2-головый проц. Запускаю компиляцию на одной из них. Все работает прекрасно, веб (в одной из виртуалок) отзывчивый, не тормозит. Запускаю компиляцию во второй ВМ. Скорость компиляции на глаз падает в несколько раз, веб начинает тормозить.

Выводы?

 

Ммм... В виртуальной машине (не VZ контейнере) куча ещё сервисов крутится. Это - накладные расходы с которыми ты согласен изначально. И ни сколько не свидетельствует о недостатке технологи.

Сервисы-то кушают 0.01% ресурсов в общем-то. Если брать свежеразвернутую виртуалку, а не помойку с вебом/почтой/прочим, что там крутится.

 

 

Мой пример был - DNS сервер. Там не ахти какая нагрузка в сторону диска.

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

У себя я предпочитаю ДНС держать на реальной машине. Сейчас готовим кластер, и днс как сервис имеет преимущество в виде быстрого старта.

 

А с сетью траблов я не замечал совсем. Памяти по-больше и всё в ажуре.

А вы внимательнее посмотрите, сколько кппс без VT-d пророутит какой-то роутер в виртуалке, и сколько на том же железе без VM...

[SergeiK]

Банальное наблюдение за реальной ситуацией. Есть 2 виртуальные машины, KVM. По 2 головы. Есть 2-головый проц. Запускаю компиляцию на одной из них. Все работает прекрасно, веб (в одной из виртуалок) отзывчивый, не тормозит. Запускаю компиляцию во второй ВМ. Скорость компиляции на глаз падает в несколько раз, веб начинает тормозить.

Выводы?

Может дело не в бобине?

 

На 8 ядрах, sas дисках в зеркале и 4-х 1G интерфейсах под ESXi бегали:

zabbix, и бд к нему, 500 хвостов, не помню сколько, но тысячи параметров.

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

бд mysql, к нагиосу и всяких других целей.

cisco prime LMS на 200 свитчей, но не в полной моще, в тестовой стадии осталось.

proxy, небольшой, мегабит 10 всего, в среднем.

по мелочи, DNS, AAA, syslog + splunk, rancid, tftp, web-морды разные, тестовые системы. Всего до 16 виртуальных машин.

 

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

Все в 2U (+2, так две железки, основная и резервная, которая отдыхала).

Ко всем системам удаленная консоль, при необходимости, с авторизацией.

Если очень нужна производительность - думаю можно отдать диск напрямую в гостевую систему, через pass through (с диском так не делали, на самом деле, с картой сетевой делали, работало).

 

В нынешних условиях лично я не вижу потребности ставить выделенные сервера, разве что кроме террабайтных БД или 10G софтовых firewall-ов/роутеров.

Ибо цена юнита, электричества+охлаждения, обслуживания и прочее дороже гигагерца и гигабайта.

[^rage^]

Поставьте фтп, налейте туда гигов 40 мелких файлов, сделайте рандомное чтение в виртуалке потоков в 20, и на реальной машине.

Поставьте PPPoE сервер, прогоните iperf в виртуалке и на реальной машине, мелкими пакетами.

Думаю, разница наглядно покажет "разы"...

ну что ж ты так официально :)))

 

вот смотри: у меня в десктопе 32Гб памяти и i7-3770. можно потестить, но смысла не вижу. 40 гигов либо большей частью осядут в кеше VFS(и тогда мы упрёмся в имеющийся у меня 1-2гигабита), либо(если не осядут), то IOPS'ы винта(т.е. нам всё-таки нужен raid10 с большим числом дисков). на серверном железе соотношение более-менее сохраняется: ты раньше упираешься в диски(чтобы это как-то преодолеть ставят ssd для flashcache/bcache/arc).

кроме того, есть всякие разные штуки типа SR-IOV, если речь про сетку.

 

А NAPI начинает работать только тогда, когда процессор не успевает обрабатывать все прерывания :)

Linux kernel uses the interrupt-driven mode by default and only switches to polling mode when the flow of incoming packets exceeds a certain threshold, known as the "weight" of the network interface.

 

The final step is to tell the networking subsystem about your poll() method. This, of course, is done in your initialization code when all the other struct net_device fields are set:

  dev->poll = my_poll;
  dev->weight = 16;
The weight field is a measure of the importance of this interface; the number stored here will turn out to be the same number your driver finds in the quota field when poll() is called. If you forget to initialize weight and leave it at zero, poll() will never be called (voice of experience here). Gigabit adaptor drivers tend to set weight to 64; smaller values can be used for slower media.

 

root@wks0:~# sysctl -a | grep wei
net.core.dev_weight = 64

Изменено 19 марта, 2013 пользователем ^rage^

[taf_321]

Сравните производительность/нагрузку на проц из-под виртуальной машины и при разворачивании поверх реального железа. Думаю, разница в разы будет...

 

Ээээ... Снимитесь с ручника. Еще два года назад для KVM разница между виртуальной и голой машиной была не более 15%. Какие тут разы?

 

Нет, ну если задать в виртуалке сетевую карту ne2k и диск IDE, то тогда да, будет даже не в разы, а на порядок.