Как прописать днсы?

Тема в разделе "Домены", создана пользователем dizpers, 13 дек 2010.

Статус темы:
Закрыта.
Модераторы: Aste
  1. dizpers

    dizpers Создатель

    Регистр.:
    8 июл 2008
    Сообщения:
    43
    Симпатии:
    3
    Может я ошибся разделом... но суть вопроса такова. Есть домен, скажем site.ru... есть первый, основной сервер сайта в панели управления доменом сейчас прописаны днсы именно этого первого сервака... в связи с некоторыми проблемами на первом серваке был взят второй - как бы запасной - как организовать такую штуку, что если основной первый сервер вдруг лежит, то при обращении к домену site.ru я попадал на второй сервак?
     
  2. ask0n

    ask0n

    Регистр.:
    9 июн 2009
    Сообщения:
    227
    Симпатии:
    63
    Лежание основного вэб сервера и ДНС сервера для домена не взаимосвязаны.
    Можно использовать failover настройки для вэбсерверов.
     
  3. dizpers

    dizpers Создатель

    Регистр.:
    8 июл 2008
    Сообщения:
    43
    Симпатии:
    3
    Расскажи плиз подробней про такие настройки.

    PS
    Слышал также про некий heartbeat для решения подобного рода задач...
     
  4. ask0n

    ask0n

    Регистр.:
    9 июн 2009
    Сообщения:
    227
    Симпатии:
    63
    Есть два варианта реализации:
    1. Клиент хочет попасть на site.ru, после DNS запроса получает ответ относительно IP адреса site.ru. Если в DNS сделать несколько одинаковых записей ссылающихся например на www сабдомен для site.ru, каждый запрос к DNS будет по кругу возвращать один из адресов.
    Если клиент получил IP адрес сервера который в настоящий момент лежит, его браузер ругнется по таймауту, он обновляет страницу и с вероятностью 50% для двух серверов попадает на работающий сервер.
    Это называется round-robin DNS.

    2. На сервере, на который ведут DNS записи ставим проксирующий сервер, например nginx, у которого прописываем несколько backend серверов, на которые будут перенаправляться запросы.
    Nginx сам будет перебирать backend'ы, если один из них недоступен. Для клиента прозрачно все происходит через вэбсервер с nginx.
    Но, если ляжет сам сервер с nginx пользователь ничего не получит, поэтому можно микшировать эти варианты.

    Если уж совсем извратится можно прикрутить геотаргетинг к DNS и отдавать адреса серверов в зависимости от географического положения того, кто делает запрос, тогда упавшие сервера сделают недоступным сайт из какой либо локации, а не для всего мира.
     
    latteo нравится это.
  5. baddan

    baddan

    Регистр.:
    14 мар 2008
    Сообщения:
    354
    Симпатии:
    42
    говря DNS наверное имел ввиду NS, предположем

    site.ru лег. если лег сайт именно а не домен, по топучается смысла нет с зеркал сайта на томже IP. тоесть небудет смысла и с nginx.

    если предположим отвязались по какойто причине NS что само по себе из области фантастики. то от куда узнают про зеркала?

    возникают проблемы
    1. синхронизация ресурсов.
    2. для поисковиков редирект пусть даже 301 не есть очень хорошо. лучше пусть полежит пару часиков на ПС это не повлияет.
    бредово немного написал, вобщем мне кажется решения однозначного нет на уровне NS.
     
  6. dizpers

    dizpers Создатель

    Регистр.:
    8 июл 2008
    Сообщения:
    43
    Симпатии:
    3
    Попутно еще такой вопрос - как можно синхронизировать данные на двух серверах? С файлами еще более менее понятно - а с бд? Можно руками конечно sh скриптик написать, который будет делать дамп, и на примнимающем сервере скрипт, который скажем в 00-00 мск выкачивал бы дами и импортировал его... А есть ли готовые решения?

    ask0n
    А эффективно будет микшировать так сказать эти два метода?
     
  7. ask0n

    ask0n

    Регистр.:
    9 июн 2009
    Сообщения:
    227
    Симпатии:
    63
    Что имел ввиду, про то и писал...
    Вот простейший пример делаем несколько раз подрят команду host google.com:

    Код:
    # host google.com
    google.com has address 74.125.77.104
    google.com has address 74.125.77.147
    google.com has address 74.125.77.99
    google.com has IPv6 address 2a00:1450:8001::93
    google.com mail is handled by 400 google.com.s9b2.psmtp.com.
    google.com mail is handled by 100 google.com.s9a1.psmtp.com.
    google.com mail is handled by 200 google.com.s9a2.psmtp.com.
    google.com mail is handled by 300 google.com.s9b1.psmtp.com.
    # host google.com
    google.com has address 74.125.77.99
    google.com has address 74.125.77.104
    google.com has address 74.125.77.147
    google.com has IPv6 address 2a00:1450:8001::93
    google.com mail is handled by 300 google.com.s9b1.psmtp.com.
    google.com mail is handled by 400 google.com.s9b2.psmtp.com.
    google.com mail is handled by 100 google.com.s9a1.psmtp.com.
    google.com mail is handled by 200 google.com.s9a2.psmtp.com.
    # host google.com
    google.com has address 74.125.77.147
    google.com has address 74.125.77.99
    google.com has address 74.125.77.104
    google.com has IPv6 address 2a00:1450:8001::93
    google.com mail is handled by 200 google.com.s9a2.psmtp.com.
    google.com mail is handled by 300 google.com.s9b1.psmtp.com.
    google.com mail is handled by 400 google.com.s9b2.psmtp.com.
    google.com mail is handled by 100 google.com.s9a1.psmtp.com.
    Смотрим какой А адрес идет первый при каждом запросе. На первый адрес полетит запрос из браузера, если google.com не отвечает с 74.125.77.104, при следующем обновлении страницы запрос полетит уже на 74.125.77.99 который его и обработает.

    В п.1 нигде про "тот же IP" ничего не писалось, там та же A запись, но IP все разные. В п.2 писалось про "тот же IP" но с оговорками и описанием чем это чревато, обычно п.2 и п.1 микшируют.

    Насчет 301го редиректа вообще интересно откуда взялось? Какой редирект? Сервера отдают один и тот же контент самое примитивное - настроенный правильно rsync.

    А еще есть такая вещь как CARP там может быть один IP но совершенно разные сервера.

    Для БД готовые решения - репликация.
     
    latteo, dizpers и baddan нравится это.
  8. baddan

    baddan

    Регистр.:
    14 мар 2008
    Сообщения:
    354
    Симпатии:
    42
    мои познания к сожалению не дотягивают до ваших, буду больше курить маны на досуге. Я думал о программном решении данного вопроса.

    Если сервер который определяет загруженность ресурса тотже гугл и который постоянно возращяет при запросе необходимый IP на котором на данный момент наименьшая загрузка. Как это делается я чесно скажу не знаю, но если сервер который за это отвечает накроется сломается все, это я и имел в виду.
     
  9. ask0n

    ask0n

    Регистр.:
    9 июн 2009
    Сообщения:
    227
    Симпатии:
    63
    IP как раз вращает не google, это описанный в п.1 round-robin DNS. Тут нет определения загруженности, тут просто перебор по кругу (round) IP адресов для домена, для определения загруженности нужен прокси сервер промежуточный, который будет перенаправлять на менее нагруженные бэкенды - это и будет микшированием 1го и 2го вариантов реализации.
    Любой может сделать себе такое, не только google :)
    Предположим у меня два разных сервера, у разных хостеров:
    1й - IP 10.10.10.10
    2й - IP 20.20.20.20

    Настраиваем ДНС запись для домена www.example.com выглядеть она у нас будет так:
    www IN A 10.10.10.10
    www IN A 20.20.20.20

    Т.е. один и тот же сабдомен имеет как бы несколько адресов.
    На 1м и 2м сервере прописываем Servername www.example.com
    Ну и собственно получаем эффект чередования IP адресов, при запросе www.example.com как у google.com :)
    За это как раз и отвечает NS сервер который обслуживает домен example.com, но от его накрытия ничего не произойдет т.к. по всем правилам NSов должно быть минимум два и в случае накрытия запросы о домене www.example.com будет обслуживать резервный NS.
    Ну а дальше уже синхронизируем как-то между ними docroot, чтоб отдаваемый контент был одинаковым.
     
    dizpers нравится это.
  10. dizpers

    dizpers Создатель

    Регистр.:
    8 июл 2008
    Сообщения:
    43
    Симпатии:
    3
    Ок, то есть если у меня будет стоять отдельный сервер с nginx, в конфигах которого прописано

    upstream cool_backend{
    server 1.2.3.4;
    server 5.6.7.8;
    }

    где 1.2.3.4 - ip адрес основного зеркала, а 5.6.7.8 - адрес зеркала, то при обращении пользователя к nginx и при доступности 1.2.3.4 - он будет всегда попадать ТОЛЬКО на 1.2.3.4 если вдруг по каким-либо причинам 1.2.3.4 лег, а 5.6.7.8 - доступен, то пользователь сразу же попадет на 5.6.7.8? расскажите плиз механизм работы nginx в случае нескольких бекендов
     
Статус темы:
Закрыта.