Управление распределенными серверами

Содержание материала

Звезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активна
 

В крупной сети существует достаточно много серверов. Как говорилось выше, серверы часто распределены по сети - и в каждой подсети существует сервер. Такая архитектура повышает эффективность работы сети, но противоречит общей цели централизации управления настройкой.

Чем больше в сети серверов, тем более рассредоточено управление и тем более вероятно возникновение ошибок в настройках. Работа с распределенными серверами требует механизма централизованного управления и распространения информации среди серверов. В TCP/IP таких механизмов существует несколько.

Для переноса настроек с центральной системы на группу распределенных систем может использоваться любой протокол передачи файлов. Подойдет FTP или TFTP, однако подобное использование протоколов связано с некоторыми сложностями. FTP и TFTP - протоколы диалоговые, они требуют выполнения многих команд для получения файла, что затрудняет написание соответствующих сценариев. Кроме того, FTP требует парольной идентификации для получения доступа к файлам, а большинство специалистов но безопасности реагируют на хранение паролей в сценариях недовольными гримасами. По этим причинам мы не будем рассматривать эти протоколы в качестве средства распространения файлов настройки. Кроме того, если вы знакомы с FTP (а вы должны быть знакомы с этим протоколом!), то знаете, как использовать его для передачи файла настройки.

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


Организация доступа к единственной копии файла настройки противоречит усилиям, направленным на распределение служб загрузки, поскольку возникает слишком большая зависимость от центрального сервера.

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

r-команды Unix rep и relist реализуют наиболее популярные методы распространения файлов настройки.

rep - Программа удаленного копирования (remote сору, гер) - это обычный протокол передачи файлов. Применительно к поставленной задаче она имеет два преимущества перед FTP: легко позволяет автоматизировать процессы и не требует использования паролей. Автоматизация с гер проста потому, что для передачи файла требуется одна-единственная строка. В следующем примере выполняется передача файла dhcpd.conf с головного сервера на удаленный сервер arthropod.wrotethebook.com:

# rep /etc/dhcpd.conf arthropod.wrotethebook.com:/etc/dhcpd.conf

Для каждого удаленного сервера, которому необходимо передать файл, добавьте подобную строку в процедуру обновления основной копии файла настройки.

гср - лишь один из вариантов решения задачи о распространении основной копии файла настройки. Программа relist, будучи не столь простой в приме- нении, часто оказывается более предпочтительным выбором, поскольку имеет ряд возможностей, делающих ее особенно подходящей для решения подобных задач.


Обмениваться, хранить, передавать Ваши файлы стало просто как никогда.
yandex-disk
Читать подробнее: для чего Yandex-Диск проекту Mini-Server. Практика установки, настройки и использования сетевого хранилища на Ubuntu server LTS 12.04 в статье Резервное копирование сервера Ubuntu на Яндекс Диск.

>> Ubuntu 12.04 + Nginx Скачать сервер
>> Fedora 15 Скачать сервер
>> Простой Debian 6.0.6 Скачать сервер
>> CentOS 6.0 и
+ (5.6) другой
Скачать сервер
>> OpenSUSE 11.4
MAX
Скачать сервер

Вход на сайт

ВНИМАНИЕ!

Регистрация на сайте только по согласованию с администратором ресурса. Обращаться через форму обратной связи.