[Ivan_83]

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

С фрями/линухами таких проблем нет: воткнул в новое железо, немного настроек поменять и снова работает.

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

[NiTr0]

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

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

 

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

Попробуйте, проверьте различие в скорости/нагрузке...

 

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

Не осядут. По причине рандомного обращения. Да и в IOPS не упрется думается...

 

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

Да кто ж спорит - VT-d/SR-IOV может и поможет, но только для тех девайсов/платформ которыми оно подерживается.

 

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

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

Проверил сейчас (хост - центос 5.х, давненько не обновлявшийся, гость - виртуалка с 2.6.30 ядром), гость:

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 75.5126 s, 14.2 MB/s

 

хост:

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 18.6749 seconds, 57.5 MB/s

Думаю, в комментариях не нуждается...

 

Да, проц - 4-головый феном 920-й, загружен менее чем на 20%.

[martin74]

[root@stat conf.d]# cd
[root@stat ~]# dd if=/dev/zero of=test bs=1048576 count=1024
1024+0 ������� �������
1024+0 ������� ��������
1073741824 bytes (1,1 GB) copied, 16,8357 ������, 63,8 MB/s

 

Не нуждается в комментариях. Первая попавшаяся виртуалка, прошу прощения за кодировку...

[NiTr0]

Загрузка проца хост-машины при этом какая? :) До копирования и во время оного?

[martin74]

Это ESXi. Кроме этой машины там еще с десяток крутится.

 

Загрузка процессора не прыгала в это время.

 

Вот с хранилища dd

[root@cc-storage0-0 data]# dd if=/dev/zero of=test bs=1048576 count=1024
1024+0 записей считано
1024+0 записей написано
1073741824 bytes (1,1 GB) copied, 0,530498 секунд, 2,0 GB/s

 

Я согласен, разница есть. Но для работы - не существенная ;)

Виртуализировать сервер хранения я точно не буду.

[sirmax]

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

LXC для этого не плох по-моему.

[Aliech]

Мысли в слух: а ведь виртуализированный стораж - вполне себе маржинальная услуга. Не только позволяет продать полоски не распределённой памяти на нодах и тоны гигов с современных хардов, но ещё и профит в карман несёт.

[SergeiK]

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

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

Дык, использование головы обязательно :).

Если вы на 8 ядра вешаете 25 и все 25 нагружаете как следует, не следует удивлятся, что они тормозят. И тормоза будут нелинейными, безусловно.

 

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

Я говорю, что сейчас лучше собрать несколько серверов со многимим ядрами, памятью в десятки Гиг, быстрой сетью и с хорошими дисками, или системой хранения (от масштаба задач), чем ставить десятки отдельных машин. Даже, если десятки машин получатся дешевле, в обслуживании будет дороже. Так же это лучше, чем громоздить множество задач на одной системе, если вы конечно, не единственный админ всего-всего (если вас двое - тоже сойдет).

 

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

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

Попробуйте, проверьте различие в скорости/нагрузке...

Уже не могу, увы.

[^rage^]

Проверил сейчас (хост - центос 5.х, давненько не обновлявшийся, гость - виртуалка с 2.6.30 ядром), гость:

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 75.5126 s, 14.2 MB/s

хост:

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 18.6749 seconds, 57.5 MB/s

Думаю, в комментариях не нуждается...

 

Да, проц - 4-головый феном 920-й, загружен менее чем на 20%.

 

ну во-первых, где oflag=direct? во-вторых:

 

# for i in `seq 0 10`; do rm -f test ; sync ; dd if=/dev/zero of=test oflag=direct bs=1048576 count=512 ; done
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,82251 s, 111 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,89869 s, 110 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,84561 s, 111 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,98329 s, 108 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,86603 s, 110 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,92228 s, 109 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,84882 s, 111 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,84865 s, 111 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 5,0015 s, 107 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 4,78169 s, 112 MB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 5,22856 s, 103 MB/s

 

# for i in `seq 0 10`; do rm -f test ; sync ; dd if=/dev/zero of=test oflag=direct bs=1048576 count=512 ; done
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.354577 s, 1.5 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.192784 s, 2.8 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.264711 s, 2.0 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.179757 s, 3.0 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.374873 s, 1.4 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.22254 s, 2.4 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.224258 s, 2.4 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.209489 s, 2.6 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.17539 s, 3.1 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.341155 s, 1.6 GB/s
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.168589 s, 3.2 GB/s

 

пояснять? ;)

[d1m0n]

вот мои результаты одной из виртуальных машин (Gentoo, веб-сервер):

server user # dd if=/dev/zero of=test bs=1048576 count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 9,83477 s, 109 MB/s

При этом в вмваре крутится 8 серверов (3 веб-сервера, небольшая файлопомойка с бэкапами, DNS, почта, мониторинг и тестовый сервачок), железо простенькое: 4 ядра по 2,13 ГГц, 8 Гб памяти и RAID-1 для виртуалок + RAID-0 для данных, которые не жалко. Нагрузка примерно 50%, видимо поэтому такие результаты.

 

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

 

PS: Virtualization-for-MySQL-on-VMware

[taf_321]

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

Проверил сейчас (хост - центос 5.х, давненько не обновлявшийся, гость - виртуалка с 2.6.30 ядром), гость:

 

Цитата

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 75.5126 s, 14.2 MB/s

 

 

хост:

 

Цитата

# dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 records in

1024+0 records out

1073741824 bytes (1.1 GB) copied, 18.6749 seconds, 57.5 MB/s

 

Думаю, в комментариях не нуждается...

 

Да, проц - 4-головый феном 920-й, загружен менее чем на 20%.

 

dd if=/dev/zero of=test bs=1048576 count=1024

1024+0 записей считано

1024+0 записей написано

скопировано 1073741824 байта (1,1 GB), 10,5076 c, 102 MB/c

 

 

ЧЯДНТ? Виртуалка - сервер с Zimbra. Хост - аппаратная нода с еще 4 виртуалками от ДНС сервера до сервера Chat Comfort с перманентным онлайном в 2к рыл (соотвественно по сетевому вводу-выводу простоями и не пахнет)

[Ivan_83]

LXC для этого не плох по-моему.

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

[sirmax]

LXC для этого не плох по-моему.

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

ну это вроде jail в BSD (FreeBSD занаю плохо), чуть проще что ли для администрирования. Мне, вобщем, нравится.

[NiTr0]

Дык, использование головы обязательно :).

Если вы на 8 ядра вешаете 25 и все 25 нагружаете как следует, не следует удивлятся, что они тормозят. И тормоза будут нелинейными, безусловно.

О чем я и говорил:

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

 

ЧЯДНТ?

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

 

Хост - аппаратная нода с еще 4 виртуалками от ДНС сервера до сервера Chat Comfort с перманентным онлайном в 2к рыл (соотвественно по сетевому вводу-выводу простоями и не пахнет)

5-10 мбит (максимум) сетевой вывод - не так и много... Не гигабиты.

[s.lobanov]

5-10 мбит (максимум) сетевой вывод - не так и много... Не гигабиты.

 

Есть виртуалка под iperf. 1G выдаёт без проблем, ради прикола пробовал 2G(балансировка через ospf equal cost), тоже всё ок. хост-железо хорошее, vmware esxi

[^rage^]

(балансировка через ospf equal cost)

 

так делать не надо. ECMP не работает в linux =( точнее, работает очень своеобразно.

[agr]

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

 

Я провел эксперимент на linux'овом серваке с небольшой фоновой нагрузкой. iozone запускался на хост машине, двух контейнерах openvz и двух виртуалках xen (дисковый драйвер xvd, сиречь обычный файл в хост системе).

Результаты получились противоречивые, но хост система оказалась далеко не чемпионах.

iozone.tar.gz

[NiTr0]

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

Кеш в памяти оно конечно хорошо, позволяет получить прирост за счет игнорирования flush/direct io (на виртуалке-то flush отработал, на реальной машине - данные все еще в кеше файла образа, который и не подозревает о flush в вртуалке). Это все прекрасно ровно до тех пор, пока не идет речь о сохранности данных - "посеянные" при внезапном ребуте пару гигов данных чреваты однако :)

[agr]

Для чистоты эксперимента надо было еще испытать xen не с xdv, а с логическим разделом диска прокинутым в виртуалку. Как будет время заморочусь.

 

А вообще, как уже писали, виртуалки они не для производительности, а для гибкости, удобства и более полного задействования аппаратных ресурсов. По виртуалке под каждую задачу(сервис) - это только с первого взгляда страшно. Уровень абстракции, который предоставляет виртуализация, дает просто великие возможности для администрирования: нужно перенести сервис на другой сервер - дело пары минут; нужно провести апгрейд софта без перерыва связи - делается клонирование, апгрейд, синхронизация данных и переключение на другую виртуалку; сервис стал не нужен - просто дропается виртуалка без необходимости вычищения оставшихся ненужных конфигов и софта. Все эти задачи на реальных ОС займут гораздо больше времени и усилий.

[NiTr0]

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

И со второго, и с третьего.

512М-гиг памяти под каждую виртуалку вместо 30-100 МБ под сервис - это более полное задействование ресурсов, или их разбазаривание?

 

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

Да в общем-то это и отдельных ресурсов касается. Перенос конфигов рсинком - дело пары минут, апгрейд софта - аналогично, перенос за пару минут, апгрейд... Хотя для критичных сервисов - кластеризация на реальном железе только. Ибо иначе падение одной из железок = повторному старту виртуалок на второй ноде, т.е. простой в пару минут. В то время как старт сервиса и поднятие ИП занимают секунды.

 

Все эти задачи на реальных ОС займут гораздо больше времени и усилий.

Скажите, сколько на идентичных ОС занимает перенос одного сервиса? Т.е. за сколько времени rsync стянет данные? :)

 

Виртуалки хороши там, где действительно требуется изоляция софта. Т.е. веб, куда предоставляется доступ сторонним людям (хостинг/сайты энтузиастов/что там еще), песочницы и т.п. Везде их лепить - я лично смысла не вижу. Хотя если сильно много вычислительных ресурсов и нечем их занять - да, можно виртуалками забить, пускай крутятся :)

[SergeiK]

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

И со второго, и с третьего.

512М-гиг памяти под каждую виртуалку вместо 30-100 МБ под сервис - это более полное задействование ресурсов, или их разбазаривание?

Это единственная проблема?

http://price.ru/search/pc-components/ram/dimm/offers/?query=ddr3+8G&auto=1

 

Ресурсы - я уже писал, это место, электропитание, провода лишние, люди, которые обслуживают железо.

У вас больше 10-и серверов? Снимаете статистику с них? Сложите все процессорное время, которое потребляется, и поделите на суммарную мощь. Если у вас получится большо 10% - это будет очень много, вы очень эффективно используете свои сервера.

 

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

Да в общем-то это и отдельных ресурсов касается. Перенос конфигов рсинком - дело пары минут, апгрейд софта - аналогично, перенос за пару минут, апгрейд... Хотя для критичных сервисов - кластеризация на реальном железе только. Ибо иначе падение одной из железок = повторному старту виртуалок на второй ноде, т.е. простой в пару минут. В то время как старт сервиса и поднятие ИП занимают секунды.

Все эти задачи на реальных ОС займут гораздо больше времени и усилий.

Скажите, сколько на идентичных ОС занимает перенос одного сервиса? Т.е. за сколько времени rsync стянет данные? :)

 

Виртуалки хороши там, где действительно требуется изоляция софта. Т.е. веб, куда предоставляется доступ сторонним людям (хостинг/сайты энтузиастов/что там еще), песочницы и т.п. Везде их лепить - я лично смысла не вижу. Хотя если сильно много вычислительных ресурсов и нечем их занять - да, можно виртуалками забить, пускай крутятся :)

Вы просто не пробовали это по настоящему. Возможности современных систем виртуализации очень большие.

Даже бесплатный ESXi (остальные не пробовал) дает приличные возможности. Коммерческие системы для большего количества серверов с системами хранения дают уже очень много.

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

 

Но сильно уговаривать вас не буду. Можете считать мегабайты ОЗУ, и вытягивать из 486 DX4 его максимальные возможности, имеете право.

[NiTr0]

Это единственная проблема?

http://price.ru/sear...=ddr3+8G&auto=1

 

Ресурсы - я уже писал, это место, электропитание, провода лишние, люди, которые обслуживают железо.

У вас больше 10-и серверов? Снимаете статистику с них? Сложите все процессорное время, которое потребляется, и поделите на суммарную мощь. Если у вас получится большо 10% - это будет очень много, вы очень эффективно используете свои сервера.

Кто говорит о том, что на каждый сервис должен крутиться на отдельной машине? :)

И да, сейчас на боевых серверах обработки данных (брасы/роутеры не трогаем) нагрузка в ЧНН в среднем порядка 10-20%.

 

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

Я где-то говорил что исключает? Я говорил, что сервис, требующий минимального времени простоя, в виртуалку запихивать не стоит. Ибо старт виртуалки при краше одной ноды на другой - процесс длительный. Особенно если ФС повреждена.

[s.lobanov]

Я где-то говорил что исключает? Я говорил, что сервис, требующий минимального времени простоя, в виртуалку запихивать не стоит. Ибо старт виртуалки при краше одной ноды на другой - процесс длительный. Особенно если ФС повреждена.

 

А кто запрещает делать такой же софтовый кластер из двух виртуалок на разных хост-машинах? (если FT не устраивает)

[NiTr0]

А кто запрещает делать такой же софтовый кластер из двух виртуалок на разных хост-машинах? (если FT не устраивает)

И разруливать каждый split-brain руками? Или тащить отдельный интерфейс в виртуалки для обеспечения надежного линка между нодами кластера в виртуалках?

И какой в итоге профит будет из этого нагромождения излишних сущностей? :)

[SergeiK]

А кто запрещает делать такой же софтовый кластер из двух виртуалок на разных хост-машинах? (если FT не устраивает)

И разруливать каждый split-brain руками? Или тащить отдельный интерфейс в виртуалки для обеспечения надежного линка между нодами кластера в виртуалках?

У виртуалки изначалально много интерфейсов, причем резервированных.

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

И какой в итоге профит будет из этого нагромождения излишних сущностей? :)

Профит в том, что у вас вместо 20-и железяк - две, которые можно поставить с двумя БП и УПС-ами, и все вместе места будет занимать четверть стойки.

И вместо вязанки проводов - десяток, с учетом всех резервирований, которые никогда не перекоммутируются.

 

Если у вас 10-20% утилизации в ЧНН на боевых серверах, плюс тестовые и небоевые, то как раз 10 к одному и получиться.

И не важно, сервис на сервер, или по 3 сервиса на сервер.

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

 

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

Это базовые возможности. Дальше в виртуализации уже навороченно очень много. Но это потом, когда распробовали.