Назад | Перейти на главную страницу

Простая настройка избыточности с использованием двух серверов в двух разных центрах обработки данных?

Объем вопроса

Этот вопрос касается исключительно того, чтобы клиент запрашивал домен: example.com на один из двух доступных серверов. Как с этим работать дальше - это еще одна проблема, которую необходимо решить, и поэтому не быть упомянутым в ответе.

Доступные инструменты

Мои доступные инструменты - два выделенных сервера (server A и server B) распределены в двух разных дата-центрах (data center A и data center B) расположен в другом физическом месте. В чисто вымышленный IP-адрес server A представлен как a.a.a.a и IP-адрес server B представлен как b.b.b.b. Оба сервера поставляются с дистрибутивом Linux, что не имеет особого значения.

Поскольку я хочу взять все под свой контроль, я не хочу использовать какие-либо сторонние службы (управляемый DNS, CDN и т. Д.). Таким образом, это мои единственные инструменты.

Цель

Катастрофа, на которую я рассчитываю, - это водородная бомба, уничтожающая один из двух центров обработки данных, используемых через неделю после того, как я правильно настроил все на обоих серверах. Я хочу свой домен example.com быть доступным в любое время, хотя я бы не стал беспокоиться о простое на несколько секунд или, возможно, даже на несколько минут, поскольку серверы настолько надежны, что они могут даже не выходить из строя чаще, чем раз в год. Также простая страница с сообщением «мы заняты решением проблемы» может увеличить это приемлемое время простоя до часа или около того.

Мое фиксированное решение

Прошло некоторое время с тех пор, как я задал этот вопрос, и теперь у меня есть разумная избыточная установка. Поскольку он закрыт, я не могу опубликовать это как ответ :(

Оба сервера имеют одинаковые DNS-записи для example.com домен:

# DNS records for both server A and server B
example.com. NS ns1a.example.com.
example.com. NS ns1b.example.com.
example.com. NS ns2a.example.com.
example.com. NS ns2b.example.com.
ns1a.example.com. A a.a.a.a
ns2a.example.com. A a.a.a.a
ns1b.example.com. A b.b.b.b
ns2b.example.com. A b.b.b.b
www.example.com. CNAME example.com.
example.com. A a.a.a.a
example.com. A b.b.b.b

На обоих серверах выполнялись скрипты, которые каждую минуту проверяли доступность друг друга. Оба сервера являются серверами имен домена example.com, поэтому оба могут изменять записи DNS. В случае проблемы сервер, который все еще находится в сети, обнаружит это и удалит другой сервер из записей DNS. Рядом с этим, в то время как другой сервер все еще находится в записях DNS, браузеры автоматически откатятся к другому серверу в течение 2 секунд (проверено с Mozilla Firefox)! Это действительно полезная функция.

Так как server A имел "власть" над example.com Я не знала как добавить server B как возможность контролировать DNS. Оказывается, вы можете просто добавить записи для любого домена, но они будут соблюдаться только в том случае, если тот, кто первым зарегистрировал домен с записями DNS, добавляет этот сервер в качестве сервера имен с 'NS' в записях DNS.

Я надеюсь, что это будет полезно для кого-нибудь с подобной проблемой.

Невозможно. Просто так. DNS не предназначен для этого.

Подделать можно, если:

  • Вы сохраняете свой DNS TTL на смехотворно низком уровне, в основном аннулируя все кеширование согласно RFC - не «законно» для большинства доменов, которые «требуют» минимального TTL.
  • Используйте сценарий на резервном сервере, чтобы проверить, выключен ли основной (ping dies и т. Д.), А затем автоматически изменить записи DNS в домене.

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

HA обрабатывается с помощью ОБОИХ серверов, использующих ОДИН IP - для чего вам требуется НАМНОГО более одного IP-адреса (есть технические ограничения), а затем с помощью протоколов маршрутизации, чтобы этот IP-адрес перешел в другой центр обработки данных.

1: Нет

2: Вы мне скажите. Логически пространство IP-адресов из центра обработки данных B становится недоступным. Вот и все - с DNS больше ничего не происходит, люди все равно заходят туда для подключения к серверу.

3: Ты мне скажи. Логически пространство IP-адресов из центра обработки данных A становится недоступным. Вот и все - с DNS больше ничего не происходит, люди все равно заходят туда для подключения к серверу.

4: Как? Посылая половину людей к А и половину людей к Б - НЕЗАВИСИМО (!), Находятся ли А и Б в сети? DNS не имеет положений НУЛЯ для обеспечения высокой доступности.

5: Нет, ваш регистратор ничего не делает. ВЫ идете к своему регистратору и указываете имя на IP-адрес. Кто-то «знает», что это правильная запись, если вы проверяете, были ли вы достаточно умны, чтобы правильно внести запись в базу данных. Вашему регистратору, вероятно, все равно. Теперь СОБСТВЕННОСТЬ - это юридический вопрос. Ваш регистратор продал вам домен, сообщил об этом корневому реестру домена. Они дают вам имя пользователя и пароль. Кому «принадлежит» ваш пароль к этому сайту?

Предлагаю вам прочитать книгу о том, как работает DNS. И не забудьте решить проблемы доступности с помощью DNS - DNS не предназначен для обеспечения высокой доступности. О, голосование за закрытие - вопросы новичков здесь не приветствуются в соответствии с FAQ. Не лучшее решение в данном случае, но правила остаются в силе.