Как использовать DRBD для репликации всей системы

Я установил и настроил DRBD на моих серверах Ubuntu 9.10, следуя ссылкам ниже.

ссылка text1 и ссылка text2

Я планирую настроить серверы Ubuntu для высокой доступности, поэтому я протестировал работу DRBD, и все в порядке, как по ссылкам, на которые я ссылался. Но мое главное требование - я мог бы запустить другой сервер в работу, если основной сервер вышел из строя / поврежден. Можно ли настроить DRBD таким образом, чтобы любые изменения, внесенные на первичном сервере в '/', реплицировались на вторичный сервер?

.

РЕДАКТИРОВАТЬ:

Уважаемые эксперты!

У меня есть сервер Ubuntu, на котором размещены apache , tomcat , [ 1115] mysql , ldap и так далее. Я не знаю, как сказать ... например, если этот сервер поврежден или работает со сбоями, я должен немедленно запустить другую систему с такими же приложениями, службами, файлами и каталогами баз данных (как клон). Мне интересно, есть ли что-то вроде первичного и вторичного, которые реплицируют (всю систему) друг друга, и если в случае сбоя первичного сервера, я могу немедленно найти вторичный.

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

Спасибо!

1
задан 9 March 2012 в 20:23

2 ответа

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

Например, вы можете создать виртуальную машину xen, которая использует диск с резервной копией drbd.

0
ответ дан 9 March 2012 в 20:23

Тиражирование всей системы в высоконадежном сценарии является, вероятно, не хорошей идеей по двум причинам:

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

  2. Одним из преимуществ, которые Высоконадежные установки дают Вам, является способность сделать обновления системы без сервисного времени простоя: Вы обновляете "резервную" систему, тест, что это работает, обменивается "основными" и "резервными" ролями, обновляет бывшую основную систему. Если что-то разлагается, у Вас все еще есть по крайней мере одна система и выполнение. Установка автоматизированной всей системной репликации освобождает эту процедуру: если Вы обновляете одну систему, другой обновлен также: Вы, вероятно, не можете сделать этого, в то время как услуга работает, и Вы освобождаете функцию "аварийного восстановления".

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

Точные детали того, как Вы делаете это, зависят от сервиса, который Вы хотите выполнить (www? mysql? nfs?), но общее представление: копируйте конфигурацию и изменяемые данные. Например, принятие Вас хочет иметь высоконадежный сервер NFS, можно продолжить двигаться как следующее (на обоих серверах):

  1. Настройте дублируемый диск DRBD и смонтируйте его на /nfs на обоих серверах (основной и резервный).

  2. Создайте каталоги /nfs/etc и /nfs/data

  3. Символьная ссылка /etc/export кому: /nfs/etc/export и заставьте его экспортировать /nfs/data файловая система клиентам.

  4. Справься с сервисом NFS heartbeat, вместо системой init/upstart демон, так, чтобы это пошло вверх и вниз согласно роли сервера (основной или резервный) и доступность диска DRBD.

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

3
ответ дан 9 March 2012 в 20:23

Другие вопросы по тегам:

Похожие вопросы: