Здравствуйте
проблекма, думаю распространённая, но нигде ни словаСуть в том что есть сервер на нём сайты при всяких чп, типа с сервером перемудрили или дата центр накосячил сайты конечно отрубаются, последствия как минимум ужасные, хочется поставить ещё 1 сервер, и сделать так чтобы при отрубания основного включался резервный (или он должен постоянно работать, или сами включать), но смысл такой.
У кого какие мысли, можно ли такое сделать, и главное как?
>У кого какие мысли, можно ли такое сделать, и главное как?Да можно. Вариантов "как" очень много, причем большинство из них расписаны по многу раз в инете. Так что качайте скилл поиска и умение правильно задавать вопросы. На общие вопросы можно дать только общие ответы.
спасибо, уже этим сильно помогли, просто я уже отчаялся что это невозможно, был бы очень рад если дали бы ссылку на какой нибудь пример, инет я облазил, ничего не мог найти, поэтому начал писать в форумах.
Сейчас тоже над этим работаю. Планирую реализовать такую схему:Есть серверы А - основной и B - резервный. Оба сервера соединены патч-кордом через интерфейсы eth1., на eth0 у обоих Интернет.
Оба находятся в одной подсети и могут присваивать IP адреса друг-друга (здесь пришлось договориться с дата-центром).
На сервере В работает скрипт по крону, который проверяет доступность сервера А.
В случае недоступности последнего, он присваивает себе его IP адрес и выставляет признак "основной сервер недоступен". В результате, сайт открывается с сервера В. При следующем запуске скрипт проверяет признак доступности основного сервера. Если выставлен признак "недоступен", он проверяет его доступность и если A доступен, удаляет из своих алиасов адрес сервера А.Все это не очень красиво, но пока лучшей схемы не придумал.
Вижу проблема распространённая, уже радует, но вот первый вариант связанный с дата центром конечно не радует, всётаки дата центр бывает то элекричество отрубит, то какието работы у них там, то у ихнего провайдера инет пропал на канале, вообщем суть в изоляции от дата центра (большой опыт в этом, независимость должна быть от дата центра в любом случае), и страховку от собственных кривых рук если что то напортачил чтобы сайты не отрубались.
Вот уже чуть яснее стало чего вы хотите. Тут мы натыкаемся на очень серьезную проблему. Датацентрам просто необходимо доверять, разумных альтернатив этому нет. Да, можно играться с dns и получить типа балансировку по разным DC, но практической применимости в этом немного. Если вы не можете доверять конкретному DC, то просто смените его, по крайней мере для точки входа. Сбой того же hurricane electric приведет к падению значительной части серверов в штатах, на моей памяти такого еще не случалось, так почему бы не взять его или аналоги и спать спокойно?
Другое дело зашита от собственных шаловливых рук или выхода из строя железа. Для первого ставим систему бэкапов/снапшотов и виртуализацию системного уровня. Для второго RAID(в 90% случаев умирает именно винт) и дополнительные сервера + балансировщик в качестве точки входа. Балансировкой может заниматься как своя так и провайдерская железка.Вообще чем больше серверов, тем дешевле обеспечивать отказоустойчивость.
Это верно... у самого перед НГ сервак сгорел в ДЦ из-за кривых рук инженеров-электриков.А вот как по другому быстро переключить домен на другой сервак без подмены IP - даже не знаю. DNS переключать не вариант - слишком долго может расходиться зона по миру.
Самое интересное что всё так и работало, был резервный и тд, но на фирме перестройка, админы сменились, сервер остался 1 (теперь приходится брать второй) и как это всё работало хрен знает, единственное помню что когда основной отрубался, звонили и включали резервный=)
а если добавить ещё 1 днс (третий) на другом сервере можно что нибудь сделать?
Не знаю даже, чем это поможет... DNS'ы опрашиваются, вроде как, рэндомно. Да и запросы кэшируются на других DNS-серверах.
У меня появилась вот такая идея:Делегировать домен сайта DNS'ам сервиса dyndns.org.
У них есть такая услуга: Premium DNS hosting. Она позволяет динамически менять IP-адреса для днс-записей при помощи стандартных клиентов (вроде есть под все ОС).Нужно узнать есть ли возможность запускать клиент не демоном, а единожды. Если есть, то дальше все просто: на резервный сервер вешаем скрипт, проверяющий доступность основного сервера; если сервер недоступен - меняем запись в ДНС при помощи клиента DynDNS и т.д.
Сразу возникает вопрос "а как же кэш провайдерских и прочих серверов имен?". Могу только сказать, что сам пользуюсь бесплатными услугами DynDNS для доступа к моей домашней машине с динамическим IP (домен my-name.dyndns.org). Изменения IP-адреса происходят почему-то моментально - новый IP видно сразу же, если заходить с разных провайдеров Москвы. Такое чувство, что все, что делегировано для DynDNS, ни где не кэшируется (возможно, я чего-то не понимаю и здесь имеет значение, например TTL).
В общем, буду копать в этом направлении.
Чувствую есть люди которые в этом хорошо шарят, но почему то молчат, вообщем интересный вариант у Nas_tradamus, хотелось бы ещё послушать варианты, где все гуру программисты?=)
Вы что только что из офиса, где любой человек связанный с компами это "программист"? Какое отношение к проблеме имеет программирование?
)))) забавно сказано, прям как моя бабушка))), вообщем тогда просто "прошаренные в этой теме люди".
В общем, буду реализовывать идею с DynDNS - все реально:
Их NS'ы позволяют выставлять маленький TTL (20 секунд!), что не даст кэшировать домен у провайдерских и прочих NS-серверов. Мало того, можно менять A-записи при помощи клиента под Unix в разовом порядке (не запускать утилиту как демон). Стоит удовольствие 30 долларов в месяц.
> Стоит удовольствие 30 долларов в месяц.Поправка: 30 долларов в год.
ок, вы ещё с кем нибудь консультировались?
звучит немного рискованно, машинка рабочая, хотелось бы узнать ещё мнения.
>ок, вы ещё с кем нибудь консультировались?
>звучит немного рискованно, машинка рабочая, хотелось бы узнать ещё мнения.Надо написать алгоритм на листочке и тестить скрипты не на основном, а тестовом домене и сайте.
Когда закончу, может быть даже статью напишу :).Сразу скажу, что на втором резервном сервере файлы с первого сервера дублируются раз в сутки, а для копирования базы используются репликации MASTER -> SLAVE.
Для возврата системы в исходное состояние скрипт писать не буду. Но алгоритм возврата будет таков: восстанавливаем основной сервер, блокируем (LOCK TABLES) БД резервного сервера, делаем дамп базы, заливаем его на основной, меняем A-запись в NS обратно.upd. Кстати, можно зарегать бесплатный домен третьего уровня в dyndns.org и тестить на нем. Если понравится - то уже покупать аккаунт с возможностью делегирования своего домена под их NS'ы.
немного потороплюсь, где статью читать? чтобы не потерялись
>немного потороплюсь, где статью читать? чтобы не потерялисьЯ отпишусь здесь. Статью если и напишу, то для опеннета.
на самом деле я не понимаю почему так мало комментариев, это ведь распространённая проблема.
>на самом деле я не понимаю почему так мало комментариев, это ведь
>распространённая проблема.несколько ip для одной A записи уже пробовали? чем не подошло? коментов мало потому-что раз 100 обсуждалось и прямо и криво и вверх-тормашками.
google же робит!
>>на самом деле я не понимаю почему так мало комментариев, это ведь
>>распространённая проблема.
>
>несколько ip для одной A записи уже пробовали? чем не подошло? коментов
>мало потому-что раз 100 обсуждалось и прямо и криво и вверх-тормашками.
>
>
>google же робит!А как это работает? Не опрашиваются ли эти IP рэндомно каждый раз при обращении?
> А как это работает? Не опрашиваются ли эти IP рэндомно каждый
>раз при обращении?Не рендомно, а по очереди, называется roundrobin. С горем пополам годится для балансировки, но не для поставленной задачи.
Ответов мало потому, что сама идея отказоустойчивости на основе смены DNS записей хреновая и редко используемая на практике.
>> А как это работает? Не опрашиваются ли эти IP рэндомно каждый
>>раз при обращении?
>
>Не рендомно, а по очереди, называется roundrobin. С горем пополам годится для
>балансировки, но не для поставленной задачи.
>
>Ответов мало потому, что сама идея отказоустойчивости на основе смены DNS записей
>хреновая и редко используемая на практике.Идея использовать балансировщик мне тоже не понравилась - слишком большая ответственность ложится на одну железку. При выходе ее из строя, ляжет вся система и поднять все в рабочее состояние быстро не получится.