Я установил и настроил DRBD на моих серверах Ubuntu 9.10, следуя ссылкам ниже.
Я планирую настроить серверы Ubuntu для высокой доступности, поэтому я протестировал работу DRBD, и все в порядке, как по ссылкам, на которые я ссылался. Но мое главное требование - я мог бы запустить другой сервер в работу, если основной сервер вышел из строя / поврежден. Можно ли настроить DRBD таким образом, чтобы любые изменения, внесенные на первичном сервере в '/'
, реплицировались на вторичный сервер?
РЕДАКТИРОВАТЬ:
Уважаемые эксперты!
У меня есть сервер Ubuntu, на котором размещены apache , tomcat , [ 1115] mysql , ldap и так далее. Я не знаю, как сказать ... например, если этот сервер поврежден или работает со сбоями, я должен немедленно запустить другую систему с такими же приложениями, службами, файлами и каталогами баз данных (как клон). Мне интересно, есть ли что-то вроде первичного и вторичного, которые реплицируют (всю систему) друг друга, и если в случае сбоя первичного сервера, я могу немедленно найти вторичный.
Я говорю не только о DRBD, это может быть любой сторонний инструмент, который отвечает всем моим требованиям. Я должен сделать это к назначенному мне времени. Каким-то образом вы пытаетесь понять, в чем я нуждаюсь, и положить этому конец
Спасибо!
Вы можете рассмотреть возможность объединения drdb с виртуализацией. Более подробную информацию можно найти здесь здесь .
Например, вы можете создать виртуальную машину xen, которая использует диск с резервной копией drbd.
Тиражирование всей системы в высоконадежном сценарии является, вероятно, не хорошей идеей по двум причинам:
Существует несколько параметров конфигурации, которые уникальны для каждого сервера: например, имя хоста и IP-адрес, возможно отображение устройств DRBD к дискам. Установка системы так, чтобы это могло выбрать корректную конфигурацию на основе некоторого "экологического" параметра (например, порядковый номер ЦП) является определенно большей проблемой, чем это стоит.
Одним из преимуществ, которые Высоконадежные установки дают Вам, является способность сделать обновления системы без сервисного времени простоя: Вы обновляете "резервную" систему, тест, что это работает, обменивается "основными" и "резервными" ролями, обновляет бывшую основную систему. Если что-то разлагается, у Вас все еще есть по крайней мере одна система и выполнение. Установка автоматизированной всей системной репликации освобождает эту процедуру: если Вы обновляете одну систему, другой обновлен также: Вы, вероятно, не можете сделать этого, в то время как услуга работает, и Вы освобождаете функцию "аварийного восстановления".
Тем не менее возможно копировать точно части системы, которую у Вас должно быть "горячее резервирование" для производственных систем, готовых вталкивать в случае, если основной сервер понижается.
Точные детали того, как Вы делаете это, зависят от сервиса, который Вы хотите выполнить (www? mysql? nfs?), но общее представление: копируйте конфигурацию и изменяемые данные. Например, принятие Вас хочет иметь высоконадежный сервер NFS, можно продолжить двигаться как следующее (на обоих серверах):
Настройте дублируемый диск DRBD и смонтируйте его на /nfs
на обоих серверах (основной и резервный).
Создайте каталоги /nfs/etc
и /nfs/data
Символьная ссылка /etc/export
кому: /nfs/etc/export
и заставьте его экспортировать /nfs/data
файловая система клиентам.
Справься с сервисом NFS heartbeat, вместо системой init/upstart демон, так, чтобы это пошло вверх и вниз согласно роли сервера (основной или резервный) и доступность диска DRBD.
Это является довольно поверхностным, но должно быть достаточно для запущения Вас.