Sol в 18:04, 20 апреля 2015

2015-04-20T18:04:39Z

Sol: Новая страница: «Master & Slave, с автоматической репликацией данных между серверами В этот раз, я вам расскажу…»

2015-04-20T18:04:17Z

Новая страница: «Master & Slave, с автоматической репликацией данных между серверами В этот раз, я вам расскажу…»

Новая страница

Master & Slave, с автоматической репликацией данных между серверами

В этот раз, я вам расскажу как настроить собственные DNS сервера, с автоматическим переносом зон на подчиненные сервера.
Идея следующая, т.к. для полноценной работы доменного имени требуется как минимум 2 DNS сервера, то один сервер у нас получается главным (Master), а второй, подчиненным (Slave), то принцип работы будет следующий, изменения внесенные на Master сервере, будут автоматический перенесены на Slave сервера.
Для чего это может понадобиться-например для поддержки работы своего доменного имени, или целой кучи сайтов. В принципе, держать, ради одного домена, собственную инфраструктуру NS серверов, наверное не стоит, но если у вас пара десятков сайтов, то повозиться имеет смысл…
Ну а чтобы не создавать «тепличных условий», мы настроим сразу 3 сервера 1-Master и 2 -Salave, как указанно на схеме ниже.
[[Файл:421822.png]]

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

== Настраиваем Master сервер ==

Для начала сделаем основные настройки сервера:
Поднимаем права до root
sudo su

Установим Bind:
aptitude install bind9

редактируем параметры options:
nano /etc/bind/named.conf.options

Сразу под строкой directory "/var/cache/bind"; добавляем

allow-query { any; };
version "Super DNS server";
allow-recursion { none; };

Находим и закомменитуем строку
dnssec-validation auto;

Рассмотрим подробнее, то что мы написали:
'''allow-query { any; };''' -параметр отвечающий за то- от кого принимать запросы, мы их принимаем от всех.
'''version «Super DNS server»;''' -Уровень болтливости сервера, вместо названия сервера выдаст Super DNS server (можно написать что-то свое).
'''allow-recursion { none; };''' — Отключаем использование рекурсивных запросов т.к. это сильно снижает скорость работы, да и нее имеет смысла опрашивать вышестоящие DNS сервера по поводу
зоны которую сами же и обслуживаем. Можете ради эксперимента закомментировать эту функцию, и выполнить запрос, разрешение имени идет почти 4 сек, что не позволительно много…

Создадим нашу первую доменную зону.
Открываем файл
nano /etc/bind/named.conf.local

И добавляем туда:
zone "example.org" IN {
type master;
file "/var/lib/bind/example.org.db";
allow-transfer {192.168.10.60; 192.168.10.70;};
allow-update {192.168.10.60; 192.168.10.70;};
notify yes;
};

Сохраняем изменения и выходим.
Давайте разберемся, что мы туда добавили:
'''zone «example.org» IN''' — собственно, название DNS зоны, которую мы будем обслуживать, тут вы указываете название своего домена (который нужно купить заранее!!!)
'''type master;''' — Тип данного сервера, не буду играть в К.О. это мастер сервер.
'''file "/var/lib/bind/example.org.db";''' -путь к файлу с настройками данной зоны
'''allow-transfer {192.168.10.60; 192.168.10.70;};''' -разрешаем передачу данной зоны на остальные наши DNS сервера.
'''allow-update {192.168.10.60; 192.168.10.70;};''' — разрешаем обновление.
'''notify yes;''' -включаем автоматическое уведомление подчиненных серверов об обновлении файла настроек DNS зоны.

Создаем файл с настройками для созданной нами DNS зоны.
как мы определились ранее, файл с настройкам будет у нас находиться в /var/lib/bind/example.org.db вот его мы и создадим:
nano /var/lib/bind/example.org.db

Со следующим содержимым:

$TTL 3600 ;
example.org. IN SOA ns01.example.org. root.example.org. (
1 ; Serial
600 ; Refresh
3600 ; Retry
1w ; Expire
300 ; Minimum TTL
)
IN NS ns01.example.org.
IN NS ns02.example.org.
IN NS ns03.example.org.
IN A 192.168.10.20
ns01 IN A 192.168.10.50
ns02 IN A 192.168.10.60
ns03 IN A 192.168.10.70
www IN A 192.168.10.20
test IN A 192.168.10.12

Рассмотрим подробнее написанное:

'''$TTL 3600''' — Time to live время жизни, по умолчанию ставим 1 час

'''example.org IN SOA ns01.example.org. root.example.org.''' сама зона, которая обслуживается данным сервером.

'''1; Serial''' -ее серийный номер DNS записи.

'''600; Refresh'''-указывает подчиненным DNS серверам как часто им обращаться, для поиска изменений к master серверу.

'''3600; Retry''' — говорит о том, сколько Slave сервер должен подождать, прежде чем повторить попытку.

'''1w; Expire''' — Максимальный срок жизни записей, после которой они потеряют актуальность (1 неделя)

'''300; Minimum TTL''' -минимальный срок жизни записи 5 мин.

'''NS ns01.example.org.'''-NS сервер который обслуживает эту зону

'''NS ns02.example.org.'''-NS сервер который обслуживает эту зону

'''NS ns03.example.org.'''-NS сервер который обслуживает эту зону

'''A 192.168.10.20''' -если требуется попасть по адресу example.org, то клиенту будет выдан этот IP

'''ns01 A 192.168.10.50''' — Записи для поиска наших NS серверов

'''ns02 A 192.168.10.60'''

'''ns03 A 192.168.10.70'''

'''www A 192.168.10.20''' -Если клиент запросит адрес www.example.org, то ему будет выдан IP 192.168.10.20

'''test A 192.168.10.12''' -Если клиент запрашивает адрес test.example.org, какой будет выдан ему IP?

Перезапускаем Bind:
/etc/init.d/bind9 restart

Если все поднялось нормально, то переходим к настройке Slave сервера, если по каким-то причинам «не взлетело» идем смотреть логи, которые находятся /var/log/syslog и устраняем указанные в них ошибки.

== Настраиваем Slave сервер ==

Я расскажу как настроить 1 подчиненный сервер, второй настраивается аналогично.
Редактируем options
nano /etc/bind/named.conf.options

Добавим в него, тоже что и к первому серверу

allow-query { any; };
version "Super DNS server";
allow-recursion { none; };

Находим и закомменитуем строку
dnssec-validation auto;

Думаю что останавливаться на этом, во второй раз, не имеет смысла, ну а если память «девичья» возвращающемся в начало, повторение оно мать, сами знаете чего…

Создадим доменную зону.
Открываем файл

nano /etc/bind/named.conf.local

И добавляем туда запись, только на этот раз она будет немного отличаться:

zone "example.org" IN {
type slave;
file "/var/lib/bind/slave.example.org.db";
masters { 192.168.10.50; };
};

Рассмотрим подробнее изменения:

type slave;-тип зоны подчиненная

file "/var/lib/bind/slave.example.org.db"; -путь к файлу с настройками, в этот раз в имени файла указано slave.example.org.db чтобы было понятно на каком сервере вы находитесь.

masters { 192.168.10.50; }; — IP адрес Мастер сервера, откуда будет производиться запрос файлов с настройками DNS зон.

Сохраняем изменения и перезапускаем Bind:
/etc/init.d/bind9 restart

Больше ничего создавать не нужно!
теперь открываем файл с настройками DNS зоны и обнаруживаем что в нем появилось содержимое
nano /var/lib/bind/slave.example.org.db

== Проверяем ==

Bind кое что туда добавил сам(Смотрим скриншот):

[[Файл:E419af.png]]

А именно-расставил комментарии о сроках жизни различных параметров.
Третий сервер настраивается аналогично этому, все 1 в 1…
На подчиненных серверах все файлы создаются автоматически

Тестируем работу автоматического обновления DNS записей.
Для лучшего понимания происходящего в системе, очень удобно просматривать логи с отображением изменений в реальном времени, на любом подчиненном сервере открываем syslog т.к. все записи о событиях Bind пишутся в него (правильнее конечно завести отдельный лог для Bind), но это уже сами…
tail -f /var/log/syslog

Теперь возвращающемся к нашему мастер серверу, в файле /var/lib/bind/example.org.db добавляем запись вида
test123 IN A 192.168.10.14

и увеличиваем серийный номер DNS зоны на единицу
После этого на мастер сервере перезапускаем Bind
/etc/init.d/bind9 restart

Возвращаемся к нашему подчиненному серверу, на котором мы открыли просмотр отображения изменений в syslog и замечаем что там появились новые записи вида:
Jul 15 16:32:50 ns03 named[1346]: client 192.168.10.50#22434: received notify for zone 'example.org'
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: Transfer started.
Jul 15 16:32:50 ns03 named[1346]: transfer of 'example.org/IN' from 192.168.10.50#53: connected using 192.168.10.60#56299
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: transferred serial 2
Jul 15 16:32:50 ns03 named[1346]: transfer of 'example.org/IN' from 192.168.10.50#53: Transfer completed: 1 messages, 11 records, 271 bytes, 0.001 secs (271000 bytes/sec)
Jul 15 16:32:50 ns03 named[1346]: zone example.org/IN: sending notifies (serial 2)
Это говорит о том что Master сервер уведомил Slave сервера об изменениях, а Salve сервер их принял и примерил.

Теперь нам нужно уточнить что DNS записи пока НЕ идентичны на всех серверах, т.к. изменения могут еще «не доехать» до подчиненных серверов.

Чтобы в этом убедиться давайте сначала опросим Master сервер, чтобы послать ему запрос, в Windows это делается из командной строки, почти всем, знакомой командой nslookup, нас интересует новая запись

test123.example.org

nslookup test123.example.org 192.168.10.50

Где:
Nslookup-думаю что все знают что это за команда…
test123.example.org -запрос записи
192.168.10.50 -IP адрес DNS сервера от которого мы хотим получить ответ
В ответ нам выдаст, то что изображено на скриншоте

[[Файл:2204f6.png]]

Таким же способом мы опросим Slave сервер
nslookup test123.example.org 192.168.10.60

В ответ мы получим:

[[Файл:853e89.png]]

Это произошло по тому что изменения до него еще «не доехали» с мастера, таке иногда бывает, нужно просто немного подождать, пока в логах не появляться запись вида
ns02 named[1346]: transfer of 'example.org/IN' from 192.168.10.50#53: Transfer completed: 1 messages, 11 records, 271 bytes, 0.001 secs (271000 bytes/sec)

Это говорит о том что данные приехали нормально.
Отлично данные реплицируются, на подчиненные сервера.

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

$TTL 3600 ;
example.org. IN SOA ns01.example.org. root.example.org. (
1 ; Serial
600 ; Refresh
3600 ; Retry
1w ; Expire
300 ; Minimum TTL
)
IN NS ns01.example.org.
IN NS ns02.example.org.
IN NS ns03.example.org.
IN A 192.168.10.20
ns01 IN A 192.168.10.50
ns02 IN A 192.168.10.60
ns03 IN A 192.168.10.70
www IN A 192.168.10.20
test IN A 192.168.10.12

У нас есть такой параметр как серийный номер зоны, который в данный момент равен единице,
'''ВНИМАНИЕ!!!'''
Каждый раз, когда в настройки вносятся изменения, к серийному номеру прибавляется единица, это делается для того чтобы подчиненные сервера увидели изменения в записях и приняли обновленный файл зоны, если после внесения изменений в файл, серийный номер остался прежним или уменьшился, то подчиненные DNS сервера НЕ станут подтягивать обновления считая что на мастер сервере изменений небыло!
За более подробной информацие обратитесь к RFC1982
Это важный и тонкий момент, внесли изменения +1 к серийному номеру!!!

Теперь, чтобы делегировать доменное имя в настройках домена вам нужно указать:
ns01.example.org
ns02.example.org
ns03.example.org
После завершения тестирования, домен будет делегирован, с указанным вами списком NS серверов.
И все будет работать как часы.

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

[[Категория:BIND]

@@ Строка 5: / Строка 5: @@
 Для чего это может понадобиться-например для поддержки работы своего доменного имени, или целой кучи сайтов. В принципе, держать, ради одного домена, собственную инфраструктуру NS серверов, наверное не стоит, но если у вас пара десятков сайтов, то повозиться имеет смысл…
 Ну а чтобы не создавать «тепличных условий», мы настроим сразу 3 сервера 1-Master и 2 -Salave, как указанно на схеме ниже.
 [[Файл:421822.png]]

Настройка BIND - История изменений

Sol в 18:04, 20 апреля 2015

Sol: Новая страница: «Master & Slave, с автоматической репликацией данных между серверами В этот раз, я вам расскажу…»