Как настроить DNS на отказоустойчивость?

Question

[Юрий Денисов]

Добрый день!

Хочется, чтобы сервер был максимально отказоустойчивым за вменяемые деньги.

Дано: 2 сервера в разных ДЦ с разными IP.

Хочу попробовать сделать так:

Прописать у регистратора ns сервера Яндекса + прописать ns сервера другого dns хостинга, например, cloudflare. Чтоб если отказал Яндекс, то запросы пошли через cloudflare. Продублирую записи на оба ДНС хостинга и впишу в A запись два ip адреса, для того, чтобы кидало с сервера на сервер.

Получается ns сервера у меня должны выглядеть как-то так?
1) dns1.yandex.net
2) dns2.yandex.net
3) ns1.cloudflare.com
4) ns2.cloudflare.com
И две A записи у каждого хостера? Проканает ли такая схема? И какие последствия негативные можно от неё ждать?
P.S. Репликация базы будет master - master. Плюс синхронизация файлов в двух ДЦ.

Answer 1

[portfelio]

По вашим вопросам

1) Вы можете прописать хоть 22 А-записи.
2) Проканает, если под этим вы подразумеваете, что клиент будет получать пул адресов
3) RR DNS далеко не самый лучший вариант распределения нагрузки. Правильнее было бы раскидывать клиентов через балансировщик. И не забывайте про сессии. Весьма неприятны ситуации, когда я залогинен на сервере в Токио, а при следующем запросе получаю адрес сервера в Торонто, который еще не успел получить мои сессионные данные.

Самое негативное последствие, помимо описанного выше, может быть в том, что у вас отвалится сервер приложений, а NS-сервера будут отдавать клиентам его адрес.

P.S. Если соберетесь таки делать "синхронизацию файлов" советую присмотреться к этой реализации DFS www.leofs.org

Comments

[Юрий Денисов]

@portfelio балансировщик это сервер ещё один правильно? а если накрывается сервер балансировщик? что происходит в этом случае? т.е. 4 сервера два яндекса два cloudflare можно прописывать и всё будет норм? а A запись делать на балансировщик? Сессию лучше обнулять или как с этим бороться?

[portfelio]

1) Да, баллансировщик это еще один сервер
2) Если накрывается баллансировщик, то накрывается всё. Альтернативой вы можете использовать ЕЩЕ один сервер для мониторинга баллансировщика и, в случае, если он накрылся, то делать соотв. изменения в записях на NS-серверах. То есть вначале у вас в NS прописывается адрес баллансировщика, в случае его аварии ваша схема должна УМЕТЬ АВТОМАТОМ менять NS-записи.
3) В случае с баллансировщиком А-запись нужно делать на него. Проверку работоспособности серверов приложений/бд будет делать баллансировщик.
4) Сессию лучше не обнулять ;) При обнулении у вас все посетители разбегутся с сайта нафиг. Бороться можно установкой распределенного (и/или реплицируемого) хранилища сессий. Например им может быть Redis.

Ну и если совсем придираться к схеме, то сервера в разных ДЦ разных поставщиков тоже не самая лучшая затея. Если есть возможность, то лучше брать сервера одного поставщика, так можно минимизировать накладные расходы по трафику.

[portfelio]

Впрочем, если у вас сайт исключительно информационный и не использует персонализацию, то и сессии вам вовсе не нужны, а значит и нет необходимости в их распределенном управлении.

[Юрий Денисов]

сессии нужны, есть авторизация пользователей с уровнями доступа. А вы используете балансировщик? Если не секрет у кого держите сервер? Трафика не так много на самом деле. Поэтому такой проблемы с разными ДЦ по идее возникнуть не должно, но за подсказку спасибо. Плюс нет доверия к одному поставщику) вдруг прикроет сервер и всё)

[portfelio]

В зависимости от требований заказчика, и в большинстве случаев да, используем HAProxy. Про сервера не секрет, но тут тоже зависит сильно от заказчика: Selectel, Amazon, Linode, Hetzner, Digitalocean.

[Юрий Денисов]

ясно. спасибо огромное за советы. натолкнули на много интересных вещей) теперь неделю разбираться буду что куда=)

Answer 2

[Пума Тайланд]

ваша основная проблема не в днс , а в репликации мастер мастер и синхронизации.

Comments

[Юрий Денисов]

@opium какую предложите репликацию если нужны идентичные данные в базе? с синхронизацией ещё пол беды. Её в принципе можно и не делать, там файлы будут обновляться редко, разве что пару папок с временными.

[Пума Тайланд]

просто днсы самое что не наесть простое что можно реализовать для отказоустойчивости, за 5 лет у меня всего один раз падали днсы того же годади, и 100 раз репликацию в mysql.

[Юрий Денисов]

@opium вы можете что-то предложить взамен репликации? если её не делать то будет две разные базы на разных серверах в случае падения.

[Пума Тайланд]

Я вам просто указал что днс это одно из самых надежных в отказоустойчивости. В том же mysql до сих пор нет вменяемой репликации мастер мастер. А альтернатив особо то и нет.

[Юрий Денисов]

@opium на нет и суда нет как говорится)) на днс после нескольких падений особо тоже не надеюсь просто, вот и возникают такие вопросы

[Пума Тайланд]

не используйте русские днсы

[Юрий Денисов]

@opium поэтому и хочу просто прописать дополнительно ещё cloudflare. У них ценник очень демократичный

[portfelio]

@denissov Раз уж вы так тяготеете к пачке НС-серверов, то лучше примари прописывать на Cloudflare, а секондари можете раскидать по русским компаниям.

[portfelio]

@denisov MySQL и репликация это еще несколько кг головной боли ;) Лучшим вариантом будет вынесение мастера на отдельный сервер, а слейвы сделать в тех ДЦ, где будут серера приложений. Но приложения должны использовать, конечно, мастер, и только в случае его аварии переключаться на свой слейв. И тут уже сетевые издержки весьма имеют значение!

[Юрий Денисов]

@portfelio а задержки не будет если примари поставить иностранный днс? а если просто два отдельных сервера под базу? мне хоть как делать два мастера, инфа должна дублироваться идентичная, при слейве на сколько я знаю может быть задержка, и не факт что пакет дошёл до слейва правильно я понимаю?

[Пума Тайланд]

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

[Пума Тайланд]

а что вам будет гаранти ровать что пакет дошел при мастер мастер репликации?

[portfelio]

@denissov Задержки будут всегда.

[Юрий Денисов]

получается насчёт задержек можно сильно не париться? тогда ок

[Юрий Денисов]

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

[Юрий Денисов]

а кстати если построить всё на основе reg.ru jelastic? там это всё я так понимаю проще и настроено

[Пума Тайланд]

Вы какие то чудеса рассказываете, а вот если связи между серверами нет то ответов клиенту тоже никогда не будет что ли? Мастер мастер это всего лишь две репликации мастер слейв настроенные в разные стороны. И работают они точно так же как и мастер слейв, так как они и есть мастер слейв, только их две и проблем тоже две.

[Пума Тайланд]

Наивно верить что кто то будет решать ваши проблемы за вас, проблема репликации не в настройке, проблемы в сценариях, что делать если что то не так. Вот сломается ваш джеластик, что вы будете делать?

[Юрий Денисов]

@opium как понял по статьям так и рассказываю=) вобщем решение принял, буду осуществлять) спасибо за ответы и подсказки