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

Будет ли работать эта схема аварийного переключения?

У меня есть два реплицированных сервера LAMP, один как подчиненный, а другой как главный:

Master: Name = master.kimsufi.com - IP = 5.5.5.1
Slave:  Name = slave.kimsufi.com  - IP = 5.5.5.2

(как видите, оба зарегистрированы в кимсуфи)

С этими серверами и без дополнительного IP-адреса, моя цель - разместить www.domain.com с мастером, и в случае, если он не может передать управление ведомому (я знаю, что есть программное обеспечение, такое как Heartbeat, которое позволяет это, но ему нужен виртуальный IP-адрес, то есть дополнительный IP-адрес, а Кимсуфи не позволяет этого).

Я размышлял над этой проблемой и «нашел» возможное решение, которое, я уверен, неверно, потому что я нигде не нашел его опубликованным (а мои знания о сети низкие). Может быть, вы поможете мне разобраться в проблеме.

Идея состоит в том, чтобы добавить DNS-сервер на каждый сервер и настроить подчиненное устройство в качестве резервного сервера на случай, если Мастер не могу решить. Более-менее идея в том, чтобы настроить в реестре domain.com что-то вроде этого:

Primary DNS: Master (5.5.5.1)
Secondary DNS: Slave (5.5.5.2)

Затем Мастер сервер будет настроен как обычно, указав его bind9 служение Мастер сервер:

$TTL        86400
@       IN      SOA     master.kimsufi.com. user.gmail.com. (
                        2014011302       ; serial, todays date + todays serial #
                        28800              ; refresh, seconds
                        7200              ; retry, seconds
                        604800              ; expire, seconds
                        86400 )            ; minimum, seconds
;

domain.com.   86400 A        5.5.5.1
domain.com.      NS        master.kimsufi.com.
domain.com.      NS        slave.kimsufi.com.
www           86400 A        5.5.5.1

И раб:

$TTL        86400
@       IN      SOA     slave.kimsufi.com. user.gmail.com. (
                        2014011304       ; serial, todays date + todays serial #
                        28800              ; refresh, seconds
                        7200              ; retry, seconds
                        604800              ; expire, seconds
                        86400 )            ; minimum, seconds
;

domain.com.   86400 A        5.5.5.2
domain.com.      NS        master.kimsufi.com.
domain.com.      NS        slave.kimsufi.com.
www           86400 A        5.5.5.2

Итак, если вы попробуете копать с этим, вы получите что-то вроде:

ivan@local:~$ dig domain.com NS

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> domain.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33268
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;domain.com.            IN  NS

;; ANSWER SECTION:
domain.com.     86400   IN  NS  master.kimsufi.com.
domain.com.     86400   IN  NS  slave.kimsufi.com.

;; Query time: 87 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jan 14 15:30:11 2015
;; MSG SIZE  rcvd: 78

Идея в том, что как Мастер является основным сервером имен, он будет обрабатывать любой запрос для domain.com но если он не в сети, Раб сделать работу.

Я не тестировал, это просто идея (в настоящее время у меня есть только сервер в kimsufi). Является ли это возможным? Какие недостатки в этой схеме?

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

Прежде всего, вам необходимо правильно настроить DNS-серверы.

Ваша установка несколько необычна и, вероятно, не удастся выполнить стандартные проверки (например, ваша запись SOA должна быть одинаковой на всех серверах имен, обслуживающих зону)

Правильный способ настройки главного / подчиненного DNS-сервера заключается в том, что вы настраиваете свой главный и настраиваете подчиненное устройство для передачи AXFR зоны от главного.

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

В Интернете есть множество руководств о том, как настроить любой DNS-сервер с конфигурацией главный / подчиненный.

При стандартной конфигурации «главный / подчиненный» с передачей зон вам не нужно беспокоиться о переключениях на уровне DNS.
Они автоматически обрабатываются самим протоколом DNS.
Таким образом, если один сервер имен не работает, преобразователь DNS, запрашивающий ваш домен, автоматически перейдет к следующему доступному серверу имен (как определено в записях NS вашего файла зоны).

Теперь для обслуживания вашего HTTP-трафика вы просто добавляете 2 записи A, указывающие на IP-адреса двух серверов.

domain.com.   86400 A        5.5.5.1
domain.com.   86400 A        5.5.5.2
www           86400 A        5.5.5.1
www           86400 A        5.5.5.2

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

То же самое происходит, если IP работает, а затем внезапно перестает отвечать на запросы. Браузер автоматически переключится на следующий IP (конечно с некоторой задержкой в ​​первый раз)

По сути, имея 2 записи A, вы получаете высокую доступность / избыточность плюс балансировку нагрузки, поскольку DNS-серверы будут обслуживать IP-адреса в циклическом режиме для клиентов.

Однако имейте в виду, что описанная выше настройка требует, чтобы на обоих серверах было одинаковое содержимое для обслуживания.
Поэтому, если ваш веб-сайт является динамическим с серверной частью базы данных, вам, вероятно, придется настроить репликацию мастер-мастер базы данных, способ репликации сеансов (если это важно для веб-сайта), а также какой-то способ репликации файлов.

Опять же, это сильно зависит от вашего веб-сайта, поэтому универсального решения не существует.