Mar 17 14:35:24 altora1 httpd: httpd startup succeeded

...

heartbeat: [2185]: info: local HA resource acquisition completed (standby).

heartbeat: [1631]: info: Standby resource acquisition done [foreign].

heartbeat: [1631]: info: Initial resource acquisition complete (auto_failback)

heartbeat: [1631]: info: remote resource transition completed.

Поздравляю, ваш кластер работает!

Эксплуатация

Порядок включения узлов не имеет значения, т.к. узел, запустившийся первым, будет ждать запуска другого узла (в файле /etc/drbd.conf параметр wfc-timeout). Что делать, если один из узлов не стартует, мы обсудим ниже.

Порядок выключения узлов кластера зависит от приложений, запущенных на этом кластере. Для нашего случая мы должны добиться, чтобы информация, хранящаяся в базе Oracle, по завершении работы кластера была в идентичном состоянии на обоих узлах и была «цельной» (consistent). Мне представляется, что единственный способ этого добиться – выключать главный узел первым, тогда Oracle успешно завершит работу, и даже если Heartbeat на резервном узле успеет запустить Oracle, то это уже не должно повлечь за собой какое-либо изменение данных в базе, т.к. резервный узел также будет завершать свою работу.

Так что же делать, если один из узлов не запускается? Перезагружаем рабочий узел и загружаем систему в однопользовательском режиме. В этом режиме ни DRBD, ни Heartbeat не запускаются. Редактируем конфигурационный файл /etc/drbd.conf и устанавливаем параметр wfc-timeout в значение, отличное от 0, например, 1 (равно 1 секунде). Снова перезагружаем узел уже в обычном режиме.

Как повлияет синхронизация данных по сети на скорость работы с Oracle и как значительно может уменьшиться производительность по сравнению с одиночным сервером? Здесь многое зависит как от скорости используемого сетевого соединения, так и от режима работы Oracle. Значительное падение цен сделало доступным гигабитные решения для бюджетного сектора. Учитывая, что DRBD буферизирует данные и то, что скорость работы современных жестких дисков в реальных условиях пока еще значительно меньше, чем пропускная способность гигабитной сети, то в данном случае узким местом скорее станет скорость работы с дисками. В любом случае вы не должны заметить сколько-нибудь значительного проигрыша. Если вы используете сеть 100 Mbit, то здесь тоже не все безнадежно. Если большая часть запросов к базе (как правило) составляет запросы на выборку, то работа в основном будет идти с диском на главном узле, и здесь скорость соединения в 100 Mbit практически никак не скажется на производительности кластера. Если же основная работа с Oracle состоит в добавлении новых записей, то все зависит от объема новых данных, поступающих на запись. На основе своего опыта могу сказать, что Oracle на удаление и потом вставку 20000 записей тратил около 15 секунды на одиночном сервере. В объемах это где-то 5-10 Мб, учитывая индексы и служебную информацию. То есть у нас остается даже запас. Такова специфика работы сервера баз данных, хотя если бы мы с вами организовывали файл-сервер, то наверняка заметили бы падение производительности.

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