forum.lissyara.su

есть у меня такая задачка: нужно организовать отказоустойчивость стораджа для vmware esx, т.к. в текущей ситуации оно является узким местом, при его падении - падает вся виртуальная инфраструктура (порядка 20 серверов разной важности, для некоторых из них простои неприемлемы). в тоже самое время денег никто на это выделять не желает (недорогое железо правда закупят).
требуемый функционал:
надо esx серверам предоставить отказоустойчивый сторадж на основе iscsi (предпочтительно) либо nfs. падение одного из серверов кластера, должно произойти прозрачно для esx'ов (и vm'ок которые крутятся на них). они должны продолжить работу как ни в чем не бывало.
что пробовал:
а пробовал классический вариант - drbd + heartbeat + iscsi на ubuntu... конфигурация active/passive. отказоустойчивость, мягко говоря, хреновая получилась. при падении активного сервера iscsi отваливается на несколько минут от esx. соответственно vm'ки падают, что не есть гут.
вопрос:
какое может быть решение этой задачи? может стоит еще что-то попробовать? есть ли у кого опыт построения отказоустойчивых хранилищ?

drbd+hearbeat вроде, я слышал, нормально работают. Может поднастроить, таймаут у iscsi увеличить, например?

погуглил и нашел следующее: в конфигурации primary/secondary при падении основного сервера iscsi сессии теряются, соответственно на клиенте (esx) происходит переинициализация сессий, отсюда и выплывает проблема, о которой я писал в первом посте.

я с кластерами (кроме как на vmware) до этого не сталкивался, может ли мне кто-то ответить - поможет ли мне конфигурация drbd primary/primary (с использованием gfs2)?

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

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

а номер журнала не подскажешь?

нашел еще статью в архиве самага с конфигурацией, аналогичной моей:

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

кстати, у opensolaris есть проект Open HA Cluster, только вот нигде не найду толкового описания...

m0ps писал(а):нашел еще статью в архиве самага с конфигурацией, аналогичной моей:

Да, я не стал её тебе писать, т.к. там как раз такая же проблема
А на фре нет желания попробовать?

на фре нет желания попробовать?

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

Да, я не стал её тебе писать, т.к. там как раз такая же проблема

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

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

в общем раскурил... правда пока еще не на физических железка не проверял, но на vm'ках все отлично работает...
общий смысл состоит в том, чтоб использовать drbd в режиме primary/primary и кластерную fs (я использовал gfs2). на обоих серверах одновременно запущены iet, которые экспортируют файл (расположенный на gfs2 разделе) а не блочное устройство. heartbeat2 мониторит сервера, и переключает ip с одного физического сервера на другой в случае краха. hb_gui позволяет удобно настраивать heartbeat2 (не заморачиваясь с xml файликами), а также переключать ip с одного на другой сервер в ручном режиме (к примеру на время меинтанса)