вобщем суть задачи :есть 20-30 серверов с установленым "софтом" сервера freebsd и linux разносортные , "софт" одинаковый и стоит везде "в 1 месте"
надо сделать синхронизацию данных на всех серверах. например каждые X минут т.е. чтоб на всех серверах поддерживалась актуальная копия данных , данные изменяются на всех серверах (по очереди)
небольшая потеря не страшна (1-X из сервров сдох) т.е. надо синхронизация по времени изменения - т.е. самое новое считать самым правильным.
важно отслеживать появление новых фалйлов , удаление удалённых
как такового "ведущего" сервера нет и по теории задумки не должно быть.кто что может подсказать по этому поводу ?
идеи с "главным сервером" не предалгать т.к. это недопустимо (падение главного сервера)
rsync запускать по очереди для синхронизации. по цепочке по кругу, постепенно новые файлы разнесутся на все сервера (либо не по цепочке - чтобы исключить падение n серверов) сначала по группам, потом в группах, потом заново :)
>как такового "ведущего" сервера нет и по теории задумки не должно быть.
Чуш какая-то...
Привет,rsync действителяно подойдет, быстрый и легкий, но... при X серверах вам надо будет построить full mesh между ними... т.е. каждый синхронизируется со всеми... и обязательно тогда запустите time server в сети.
WWell,
>Привет,
>
>rsync действителяно подойдет, быстрый и легкий, но... при X серверах вам надо
>будет построить full mesh между ними... т.е. каждый синхронизируется со всеми...
>и обязательно тогда запустите time server в сети.
>
>WWell,
rsync конечно то что нужно я считаю, но можно еще рассмотреть вариант с scp.
завести юзера с правами на этот 'soft', настроить ссш-аутентификацию по ключам и юзать scp.
а время изменения файлов можно тиким же образом по ссш (удаленное выполнение команд)получать и парсить стандартными утилитами.
Зачем велосипед изобретать? Есть красивые, функциональные слова по теме.
И, ИМХО, одно из таких: кластер.
>Зачем велосипед изобретать? Есть красивые, функциональные слова по теме.зависит от типа данныых.
по норvмальному делаем один-два мастер сервера , все остальные ослики с них вытягивают инфу по ftp|rsync|nfs - на выбор :)
nfs живей всех будет , хи-хи :)
>[оверквотинг удален]
>на всех серверах (по очереди)
>небольшая потеря не страшна (1-X из сервров сдох) т.е. надо синхронизация
>по времени изменения - т.е. самое новое считать самым правильным.
>важно отслеживать появление новых фалйлов , удаление удалённых
>как такового "ведущего" сервера нет и по теории задумки не должно быть.
>
>
>кто что может подсказать по этому поводу ?
>идеи с "главным сервером" не предалгать т.к. это недопустимо (падение главного сервера)
>как вариан решения проблемы предлагаю сделать с двома главными серверами(можно разширыть алгоритм, и сделать намного больше ведущих)
допустим есть есть сеть 22- компа делаем три сети(192.168.0.0-6 компов(диапазон 1-6) 192.168.1.0-9компов(1-9),192.168.2.0-9компов(1-9)),вообщем обновления должно проходить в 4 этапа
1-й:
сервер 0.3 запирает через rsync файлы с (0.1;0.2)
0.4(0.5;0.6)
1.7(1.1;1.2;1.3)
1.5(1.3;1.6;1.9)
2.7(2.1;2.2;2.3)
2.5(2.3;2.6;2.9)
2-ой этап:
0.4(0.3 если неудача 0.1;0.2 потом 0.4 || 0.5;0.6)
2.7(1.5 || 1.3;1.6;1.9 && 2.5 || 2.3;2.6;2.9
3-й этап:
0.4 (2.7 || (1.5 || 1.3;1.6;1.9 && 2.5 || 2.3;2.6;2.9))
2.7(0.4 || (0.3 || 0.1;0.2 && 0.4 || 0.5;0.6))
4-й этап синхронизируем клиенты с серверами
0.1(0.4 || 2.7)
0.2(0.4 || 2.7)
0.3(0.4 || 2.7)
...
1.1(0.4 || 2.7)
1.2(0.4 || 2.7)
1.3(0.4 || 2.7)
...
2.1(0.4 || 2.7)
2.2(0.4 || 2.7)
2.3(0.4 || 2.7)
...
и так далее и еще надо поставить ntp, ну надеюсь помог. удачи