The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Резервирование вторым сервером"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы WEB технологии (Public)
Изначальное сообщение [ Отслеживать ]

"Резервирование вторым сервером"  +/
Сообщение от VArtem (ok) on 18-Окт-09, 22:45 
Здравствуйте, уважаемые.

Стал подобный вопрос. Есть хост-сервер, на котором крутится Apache+PHP+mysql, bind, proftpd, Exim. С течением времени к-во сайтов крутящихся на нем возрасло и начала требоваться большая стабильность.  Дали задание настроить второй сервер (находится в другом месте, подключен через другого прова, имеет др. ip-шку), таким образом, что бы при отключении первого - он мог свободно взять на себя его функции, и пользователи, которые обращаются к сайтам - не чувствовали перебоя.

Сразу пришла на ум идея - в днс-ах на одно имя завязать два ip. Написать скрипт, который с первого сервера примерно раз в час перекачивал измененные файлы на второй серв.

НО!!!  Теперь представим, если первый сервер отключился и работает второй серв. Он обладает всей инфой, что была на первом, но пользователи в это время изменяют какую-то инфу (загружают новые файлы, добавляют/изменяют записи в БД). Когда включится в работу первый, то второй серв по привычке обновит данные с первого и изменения пользователей просто потеряются.

Как быть? Может есть стандартные средства и методы решения подобных задач?

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Резервирование вторым сервером"  +/
Сообщение от sHaggY_caT (ok) on 19-Окт-09, 00:53 

>Сразу пришла на ум идея - в днс-ах на одно имя завязать
>два ip. Написать скрипт, который с первого сервера примерно раз в
>час перекачивал измененные файлы на второй серв.

Две A DNS записи приведут к тому, что в 50% случаях будет возвращаться IP одной машины, в 50% другой, без какой-либо проверки, отвечает ли разрешаемый IP-адрес.
Есть сервисы dns-файловер, никогда не использовала, поэтому рассказывать не буду (может быть, кто-нибудь другой прокомментирует), но точно так, как Вы хотите, работать схема будет только со своей AS и провайдер-индепендет адресами.

>НО!!!  Теперь представим, если первый сервер отключился и работает второй серв.
>Он обладает всей инфой, что была на первом, но пользователи в
>это время изменяют какую-то инфу (загружают новые файлы, добавляют/изменяют записи в
>БД). Когда включится в работу первый, то второй серв по привычке
>обновит данные с первого и изменения пользователей просто потеряются.
>
>Как быть? Может есть стандартные средства и методы решения подобных задач?

Можно использовать связку drbd + headbeart, но он тормозит и при локальных гигабитных линках, можно использовать дорогие СХД с промышленной синхронизацией lun'ов, в Вашем случае, вероятно, реальной будет только репликация данных на уровне БД (того же постгресса), но оно тормозить, вероятно(я никогда не реализовывала такую схему, только собиралась попробовать) будет почти так же, как drbd

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Резервирование вторым сервером"  +/
Сообщение от shadow_alone (ok) on 19-Окт-09, 02:10 
Всё одно, тормоза будут невменяемые, тем более если тачка ДАЛЕКО.

Поставить рядом, сделать кластер.

если рядом невозможно, раскидайте хосты, т. е. перенесите некоторые хосты с первой на вторую.

а лучше, все-таки кластер, поднять виртуалки, поставить HA, DB по nfs замаунтить, или drdb.

А с DNS тож можно, сделать view отдельные для кого-то и всех остальных, например, для страны и прочих, удобно если есть bgp с view на страну.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Резервирование вторым сервером"  +/
Сообщение от angra (ok) on 20-Окт-09, 12:34 
Для БД есть репликация типа master-master, для файлов есть правильные опции у rsync.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Резервирование вторым сервером"  +/
Сообщение от VArtem (ok) on 20-Окт-09, 13:32 
>Для БД есть репликация типа master-master, для файлов есть правильные опции у
>rsync.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Резервирование вторым сервером"  +/
Сообщение от ЮрЫк on 20-Окт-09, 22:22 

>Вопрос в том, что во время
>офф-лайн сервера1 будет осуществляться работа с сервером2. Все данные что пользователь
>изменил в БД и те фалйы, которые он залил на сервер2
>пропадут, т.к. в обратную сторону репликация не действует

Организовать двусторонюю репликацию...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Резервирование вторым сервером"  +/
Сообщение от Slavaz (ok) on 23-Окт-09, 16:48 
>[оверквотинг удален]
>два ip. Написать скрипт, который с первого сервера примерно раз в
>час перекачивал измененные файлы на второй серв.
>
>НО!!!  Теперь представим, если первый сервер отключился и работает второй серв.
>Он обладает всей инфой, что была на первом, но пользователи в
>это время изменяют какую-то инфу (загружают новые файлы, добавляют/изменяют записи в
>БД). Когда включится в работу первый, то второй серв по привычке
>обновит данные с первого и изменения пользователей просто потеряются.
>
>Как быть? Может есть стандартные средства и методы решения подобных задач?

нужны три железки: 2 сервера (с аппаратной виртуализацией) и одна железка как хранилище данных.

На двух серваках поднимаете kvm, в них запускаете гостевую ось. Настраиваете миграцию. Всё. Миграция будет происходить в онлайне и абсолютно незаметно для пользователей.

Общее хранилище данных может быть ещё одним сервером или аппаратным решением. Я бы предпочтение отдал аппаратному решению... впрочем, и самодельное имеет право на жизнь :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Резервирование вторым сервером"  +/
Сообщение от sHaggY_caT (ok) on 25-Окт-09, 19:10 
>[оверквотинг удален]
>нужны три железки: 2 сервера (с аппаратной виртуализацией) и одна железка как
>хранилище данных.
>
>На двух серваках поднимаете kvm, в них запускаете гостевую ось. Настраиваете миграцию.
>Всё. Миграция будет происходить в онлайне и абсолютно незаметно для пользователей.
>
>
>Общее хранилище данных может быть ещё одним сервером или аппаратным решением. Я
>бы предпочтение отдал аппаратному решению... впрочем, и самодельное имеет право на
>жизнь :)

Имхо, избыточно. Хотя я сама предпочитаю, как платформу, RHEL, зачем :

>на двух серваках поднимаете kvm
>Общее хранилище данных может быть ещё одним сервером или аппаратным решением.

Судя по общему настрою топикстартера, у него нет денег на нормальную СХД, и этот "еще один сервер" будет единой точкой отказа.

Уж лучше два drbd-based блочных девайса, и два сервера, соединенные парочкой гигабатных кроссов, а так же SAS диски вместо процессоров с аппаратной виртуализацией, можно это все поднять на Xen, или вообще без виртуализации, это будет работать, но топикстартер, судя по всему, хочет географически разнести машины

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Резервирование вторым сервером"  +/
Сообщение от Slavaz (ok) on 27-Окт-09, 02:52 
>Судя по общему настрою топикстартера, у него нет денег на нормальную СХД,
>и этот "еще один сервер" будет единой точкой отказа.
>Уж лучше два drbd-based блочных девайса, и два сервера, соединенные парочкой гигабатных
>кроссов, а так же SAS диски вместо процессоров с аппаратной виртуализацией,
>можно это все поднять на Xen, или вообще без виртуализации, это
>будет работать, но топикстартер, судя по всему, хочет географически разнести машины

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру