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

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

ссылка текст1 и ссылка текст2

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

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

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

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

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

Спасибо!

Источник

2 ответа

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

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

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

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

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

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

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

  3. Symlink /etc/export в /nfs/etc/export и сделать это экспортировать /nfs/data файловая система для клиентов.

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

Это довольно схематично, но должно быть достаточно, чтобы вы начали.

Источник

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

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

Источник
Другие вопросы по тегам