forum.lissyara.su

Постепенно перетаскиваю весь хлам на виртуалки на машине, которая в перспективе разрастется в кластер; при этом заметил, что в некоторых задачах накладные расходы на "хз что" становятся явно неадекватными... К примеру, одна из таких задач - cacti, а вернее, его поллер spine, который форкает туеву хучу процессов, в итоге - работает раз в 5 медленнее, чем на полноценной машине. По части архивации и прочего - существенных проблем с производительностью замечено не было. При большой нагрузке на обеих виртуалках - начинаются проблемы с сетью (задержки пинга, вплоть до отваливания сети).
Диски эмулятся через virtio, сеть - через e1000 (virtio - периодически отваливается, пакеты бродить перестают). Ядро на хосте - 2.6.18-164.10.1.el5, на гостевых ОС - 2.6.30.9. На хосте стоит 2-головый камень (K8, с раздельным л2 кешем), в виртуалках - тоже указано 2 цпу.
Собссно вопрос - кто-то с таким сталкивался? В чем причины и как (если вообще возможно) с этим бороться?
Единственное объяснение данного феномена - кривое распределение реальных ресурсов, из-за чего виртуальные машины начинают скакать по разным ядрам, вызывая многочисленные cache miss - со всеми вытекающими... Но надеюсь, что я ошибаюсь.

почему бы контейнеры для виртуализации linux не использовать?

OpenVZ? Проблема в том, что у нас не всегда будет только линукс; + в качестве системы управления "типа кластером" взят ganeti, который OpenVZ не умеет (pacemaker - не осилил ), и который, не смотря на всю свою примитивность, с главной задачей - управлением несколькими нодами - таки справляется, а что ganeti не осилит (к примеру, HA-фичи) - можно будет реализовать скриптами к heartbeat (типа как здесь - только с той разницей, что нужно будет не xen/kvm дергать, а всего лишь пошевелить ganeti)...

А что за сетевуха на хосте стоит?

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

Может стоит попробывать Xen на NetBSD с ним точно проблем будет меньше?

NiTr0 писал(а):OpenVZ? Проблема в том, что у нас не всегда будет только линукс; + в качестве системы управления "типа кластером" взят ganeti, который OpenVZ не умеет (pacemaker - не осилил ), и который, не смотря на всю свою примитивность, с главной задачей - управлением несколькими нодами - таки справляется, а что ganeti не осилит (к примеру, HA-фичи) - можно будет реализовать скриптами к heartbeat (типа как здесь - только с той разницей, что нужно будет не xen/kvm дергать, а всего лишь пошевелить ganeti)...

если "типа кластер", то можно proxmox попробовать

Xen - возможно, в весьма близкой перспективе и мигрирую на него, тем более проблем много не составит (разве что ядра гостей пересобрать). Да и не обязательно для него юзать NetBSD - собссно, самому Xen-у не шибко важно, что в dom0 крутится, т.к. dom0 уже виртуализируется, и служит только для управления гипервизором.
proxmox - почитал о нем, единственное его преимущество - веб-гуй с интегрированным VNC клиентом... Ну и более быстрое развертывание. Т.к. мне от этих преимуществ ни холодно, ни жарко - смысла на него переходить не вижу.

P.S. Заметил, что сразу после старта виртуалок все шевелится шустренько, а вот чуть позже - одна из них начинает подтормаживать, причем - ощутимо. При том, что средняя загрузка проца на хосте - 40-60%. Пытался обновиться на последнюю версию kvm-83-105.el5_4.28.x86_64 - получил краш гостевых систем при буте, на предпоследней (27й) - аналогично; в дебиановских багрепортах нашел подобные ситуации (ядра 2.6.30+ гостей крашатся на свежих KVM, с ядрами на хосте 2.6.32 ветки), и даже патч для их решения, у рэдхета/центоси - молчок... Такое ощущение, что никто не пускал гостей со свежими ядрами на рэдхетовскких осях

С какими свежими ядрами на центоси? На штатных ядрах все работает нормально

На хосте - ядро 2.6.18.хххх (какое там последнее в репозиториях было - лень смотреть). Свежие ядра на гостевых ОС.
А вот рэдхет походже сделал бэкпорт глюков kmod-kvm из 2.6.32 ведра

у тебя нода в оверкомите. Выдели на каждую из виртуалок по одному процессору и посмотри как будут работать.

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

Конечно, оверхеад по памяти на виртуалках ощутимый, но куда деваться Windows сервер вполне себя прилично чувствует.
Если же моногемное линуховое окружение - то определенно брать OpenVZ, на одном сервере десятки виртуалок можно запустить. Хотя сравнивать его с KVM\XEN не корректно.

Я бы даже весьма задумался, об создании миксовой технологии виртуализации. Т.е. один кластер на OpenVZ, второй на KVM. Да и может быть не обязательно кластер, хотя бы чтобы резервная машина стояла под боком - в случае надобности на нее мигрировать контейнер или развернуть из бекапов. Ну или вообще контейнеры на NAS\SAN сторадже держать.

OpenVZ надо будет поковырять, жаль ganeti его не поддерживает - но я пока ведь не жестко к нему привязан

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

Кстати, в качестве NAS можно пользовать сами ноды, подняв на паре из них DRBD, и реализовав HA-NFS

openvz по части низкого оверхеада рвет в хлам все остальное.
Я его использую в основном для консолидации и логического разделения ресурсов (соотвественно простота поддержки и безопасность). Очень неплохая штука. Миграция контейнеров происходит элементарно.

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

рекомендую
http://download.openvz.org/doc/openvz-intro.pdf

paix писал(а):openvz по части низкого оверхеада рвет в хлам все остальное.
Я его использую в основном для консолидации и логического разделения ресурсов (соотвественно простота поддержки и безопасность). Очень неплохая штука. Миграция контейнеров происходит элементарно.

Не спорю

paix писал(а):DRBD не панацея. Высокодоступность и виртуализация несколько различные понятия.
Там где действительно нужна высокодоступность, я бы не стал использовать виртуализацию.

Однако для поднятия бюджетного отказоустойчивого хранилища без отдельных SAN/NAS, DRBD master-slave ИМХО самое то.