Кластер с распределением нагрузки

Хм. Вроде в DragonFly BSD уже что-то реализовано. Надо бы посмотреть, не интересовался как-то...

HA-кластер виртуалок без балансировки нагрузки на базе десктопных железок непринужденно рисуется за один-два вечера и четыре-пять литров кофе.

Излагаю общую идею. Делается два субкластера: кластер хранения (DRBD + heartbeat + iSCSI tgtd) и кластер исполнения (Xen/KVM + heartbeat + iSCSI initiator + опционально libvirt). Если либвирт использовать, то все значительно упрощается (там встроенная поддержка инициатора). Из недефолтного — только heartbeat-скрипт управления виртуалками.
Можно еще до кучи puppet прикрутить, чтобы рулить конфигами централизованно.

Используя редхатовкий кластерный арсенал (CLVM, GFS и проч.), возможности кластера хранения можно существенно расширить (ввести больше нод, обеспечить доступ master-master и проч.), но это будет стоить порядочной потери производительности (из-за введения дополнительных прослоек и ФС).

А вот чтобы прикрутить балансировку, уже придется попрыгать. Из личного опыта: крупные конторы, занимающиеся кластерами, обычно самостоятельно пишут софт для управления и контроля под свои нужды.

это все лирика. «кластеры» - они разные бывают. скажи, какие задачи будет решать кластер (ты собрался виртуалки гонять, а что тогда будет в виртуалках делаться?) - и мы тебе скажем, какие технологии тебе лучше всего подходят. то, что предложил nnz, это что-то типа универсального варианта, но он может быть сильно неоптимальным для тебя. по твоему сообщению выходит, что тебе нужна и высокая производительность (HPC кластер), и отказоустойчивость (HA кластер). если же тебе нужно просто виртуалки, каждая из которых делает что-то свое и никак не связана с другими, то достаточно вмвари с нфс'ом (самое простое в реализации для новичка, нфс по желанию и возможности заменить на искайзи для производительности). вмварь конечно можно заменить на квм/ксен с либвиртом, но это решение сложнее в настройке.

спс, почитаю

сижу, смотрю... много думаю )) с чего бы начать ))

спасибо за ответ

'для новичка' это в точку. Ты предложил собрать nfs и там положить виртуалки, виртуалки крутить на вмваре, как я понял.. а вмварь крутить на чем? Есть куча трухли начала 2000х годов (рабочие станции), кластер скорее нужен, чтобы выжил вмварь с виртуалками

P.S. Мне HA не очень нужен. Если есть распределение нагрузки, то он уже на полпути HA (то что потеряется при рестарте виртуалки не в счет). На виртуалках - хрюша (WinXP).

Исх. Стоит 20 (напр) старых компов (железо все разное): на одних косынку раскладывают, на других - «считают» много (туча легких и тяжелых виндовых прог). Денег нет (платное ПО не вариант).

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

ясно.

а вмварь крутить на чем?

на железе или на линуксе: vmware esxi или vmware server, оба продукта бесплатны.

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

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

совершенно не понял этой фразы:

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

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

аааа. так эти компьютеры используются в работе юзерами (они «сидят» за ними)? там линукс или винда? в любом случае, можно при запуске виртуалку уводить в форграунд, юзер и знать не будет, что он в виртуалке работает. но я тогда все меньше понимаю цель этой эпопеи, разве что от нефиг делать.

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

Почти все ноды действительно пользовательские машины.

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

Ноды двух типов (по железу): барахло (старые рабочие станции) и старые сервера (типа 2х ядерных Core2Duo по 1,6ГГц).

Нода 1го типа (20 штук из барахла): 1. Стоит Linux (заточенный под исп-ие в кластере) 2. При загрузке а) подрубается к кластеру б) запускает «свою» виртуалку (каждому пользователю по виртуалке с виндой) в) подрубается по RDP к своей виртуалке * пользователь после загрузки видит свою винду

Нода 2го типа (около 5ти штук - старые сервера): 1. Стоит Linux (заточенный под исп-ие в кластере) 2. Ночует (постоянно включен) 3. При старте выполняет скрипт поднятия служебных виртуалок

Итак, I. Пока пользователь в отпуске или на обеде, его виртуалка погашена, но машина работает на благо кластера. Цель: свободные машины не простаивают, а трудятся для всех

II. Если нужно ввести новое железо, то достаточно накатить заготовленный Linux и машина станет частью кластера, будет возможно тут же работать с имеющимися виртуалками. Цель: свободная горизонтальная масштабируемость

III. Если одна из нод упала, то кластер это заметит и перезапустит процессы, которые потерялись. Будут потери, но пока считаю их незначимыми. Цель: при сбое происходит восстановление

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

V. Ночью все пользовательские виртуалки вырубятся и кластер будет достаточно сильным. Цель: иметь возможность проводить какие-либо вычисления (такие возникают) или общие задачи по архивации, индексированию и т.п.

** Запуск виртуалок, их выключение, а также обеспечение надежного сетевого хранилища это другие задачи - их можно не рассматривать

см. выше

Хочется избежать Master-Slave. не использовать централизированный сервер для управления кластером, поэтому набрел на MOSIX (только логика замечательная, а виртуалки не получилось поставить.. скорее всего нельзя). Если есть идеи, то рад буду услышать любые предложения (включая Master-Salve реализацию) и адрес, куда пиво отправить

Кстати, посмотри oVirt, возможно, пригодится.

Почитал, но требуется поддержка аппаратной виртуализации.. только некоторые Intel'ы и некоторые AMD'шки, а у меня развал совсем с железом

Нда, без аппаратной виртуализации все очень плохо.
Потому что тогда для виртуализации винды придется использовать динамическую трансляцию (напр, QEMU без KVM), а это очень сильные потери производительности. Да и с миграцией проблемы (навскидку не припоминаю опенсорсных решений на базе динтры, умеющих миграцию).