The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"отказоустойчивость с помощью bind"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (DNS)
Изначальное сообщение [ Отслеживать ]

"отказоустойчивость с помощью bind"  +/
Сообщение от evi9 (ok) on 24-Авг-11, 12:51 
Есть домен domain.com с адрессом 1.1.1.1

Возможно ли настроить bind таким образом, что-бы при недоступности
первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
а по поднятию основного резолв возвращался на 1.1.1.1 ?

Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
какой на резервном? Что должно быть прописано у регистратора?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "отказоустойчивость с помощью bind"  +/
Сообщение от Pahanivo (ok) on 24-Авг-11, 12:59 
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?

проверям доступность сервера - если недоступен:
меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
при возобновлении аналогично, колько айпЫ наоборот
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,

ммм бинд не умеет проверять доступность http
> какой на резервном? Что должно быть прописано у регистратора?

тоже что и обычно

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "отказоустойчивость с помощью bind"  +/
Сообщение от evi9 (ok) on 24-Авг-11, 13:11 
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
> проверям доступность сервера - если недоступен:
>  меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
> при возобновлении аналогично, колько айпЫ наоборот

А как я заменю файл зоны, если сервер недоступен? Предпологается что
bind запущен на основном сервере.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "отказоустойчивость с помощью bind"  +/
Сообщение от омоним on 24-Авг-11, 13:45 
Напрашивается вывод что нужно ставить bind и на запасном сервере, и на нем производить вышеуказанные действия
отказоустойчивостью это можно назвать, разве что в пределах маленькой локальной сети ;)

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "отказоустойчивость с помощью bind"  +/
Сообщение от user (??) on 24-Авг-11, 17:12 
>>> Есть домен domain.com с адрессом 1.1.1.1
>>> Возможно ли настроить bind таким образом, что-бы при недоступности
>>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
>> проверям доступность сервера - если недоступен:
>>  меняем файл зоны 1.1.1.1->2.2.2.2, serial++, rndc reload domain.com
>> при возобновлении аналогично, колько айпЫ наоборот
> А как я заменю файл зоны, если сервер недоступен? Предпологается что
> bind запущен на основном сервере.

Смешно...

И так... есть домен domain.com с адрессом 1.1.1.1
Есть днс-сервер обслуживающий этот домен, причем он поднят на том же 1.1.1.1

Но уважаемый...:) ведь запись о том, что домен domain.com обслуживается ДНС-сервером с адресом 1.1.1.1 прописана не на вашем сервере, а у регистратора.
Вы можете, указать (обязаны указать при регистрации) что у вас есть секондари, который вы соответственно разместите на 2.2.2.2

Соответственно... если неработоспособность вашего сайта однозначно связывается с неработоспособностью ДНС-сервера НА ЭТОМ ЖЕ компьютере, то на секондари, для вашего домена можно просто указать адрес 2.2.2.2


Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "отказоустойчивость с помощью bind"  +/
Сообщение от YuryD (??) on 24-Авг-11, 15:46 
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?

В зоне прописываете 2 своих ns. На запасном втором после тестирования подменяете зону и блокируете ответы, на нем же проверяете доступность 1-го, и если он лег - разрешаете отвечать...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "отказоустойчивость с помощью bind"  +/
Сообщение от Pahanivo (ok) on 24-Авг-11, 16:25 
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
>  В зоне прописываете 2 своих ns. На запасном втором после тестирования
> подменяете зону и блокируете ответы, на нем же проверяете доступность 1-го,
> и если он лег - разрешаете отвечать...

и получаете большооооой таймаут при резовинге в половине случаев

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 24-Авг-11, 16:45 
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,

Знаю, что это не ответ на ваш вопрос, но будет порядком лучше использовать DNS-rr + (carp/vrrp), если это возможно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "отказоустойчивость с помощью bind"  +/
Сообщение от evi9 (ok) on 24-Авг-11, 18:11 
>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
> Знаю, что это не ответ на ваш вопрос, но будет порядком лучше  > использовать DNS-rr + (carp/vrrp), если это возможно.

а чем лучше? какие плюсы?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 24-Авг-11, 19:29 
>>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
>> Знаю, что это не ответ на ваш вопрос, но будет порядком лучше  > использовать DNS-rr + (carp/vrrp), если это возможно.
> а чем лучше? какие плюсы?

Ну, DNS-rr нужен лишь для распределения нагрузки, а carp/vrrp - для отказоустойчивости. carp/vrrp лучше тем, что работают мгновенно, и никакие кеш-ы на DNS-серверах или на стороне клиента не помешают failover-у. Более того, не надо изобретать велосипед, всё уже давно сделано, если идти таким путём ;)

Я даже конкретно могу сказать что использовать - carp или vrrp. Во FreeBSD лучше сделана реализация carp, а в linux лучше сделана реализация vrrp (на базе keepalived). Думаю, каждый кто пробывал ucarp, осознал какое это бажное убожество :)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "отказоустойчивость с помощью bind"  +/
Сообщение от ALex_hha (ok) on 25-Авг-11, 11:39 
А на ttl все забили что ли? :D
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 25-Авг-11, 13:21 
> А на ttl все забили что ли? :D

Не забивал, просто:
1.) Очень не рекомендую делать 1-секундный TTL.
2.) Зачем изобретать велосипед с какими-то левыми скриптами, если есть хорошие стандартны и их реализации для обеспечения failover-а?
3.) Даже 1-секундный TTL может не помочь в силу того, как, наверника, работают браузеры. Отресолвили один раз, и далее работают с IP-адресом не проверяя его актуальность.

И если уж на то пошло, то не рекомендую в таком случае использовать bind. Есть полно легковесных DNS-серверов с backend-ом в mysql. Всё таки работать с MySQL проще, чем с файлами в такой ситуации, например, серийник двигается вперёд автоматически ;). Меньше возможностей, чтобы накостылявить.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "отказоустойчивость с помощью bind"  +/
Сообщение от ALex_hha (ok) on 25-Авг-11, 16:49 
Я как раз и говорил, что существует понятие ttl и делать проверку доступности сервера и потом переключать что то не имеет смысла.

> И если уж на то пошло, то не рекомендую в таком случае использовать bind. Есть полно легковесных DNS-серверов с backend-ом в mysql. Всё таки работать с MySQL проще, чем с файлами в такой ситуации, например, серийник двигается вперёд автоматически ;). Меньше возможностей, чтобы накостылявить

не вижу никакой взаимосвязи! Т.е. по твоему хранение записей в MySQL эффективней, чем в текстовом файле?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 25-Авг-11, 17:18 
> Я как раз и говорил, что существует понятие ttl и делать проверку
> доступности сервера и потом переключать что то не имеет смысла.

То что существует понятие "TTL", лично я, как думаю и остальные, и сами знаем (и, я, надеюсь, вы сейчас про DNS TTL, а не про IP TTL, иначе вообще какой-то бред получается). Однако объясните, пожалуйста, какую схему предлагаете Вы. Вы предлагаете разместить по bind-у на обоих серверах, проделегировать зону на них и занизить TTL? Тут всё хорошо, кроме всяких браузеров (если это веб-сервер), которые предётся перезапускать, чтобы они заного отресолвили и начали работать с новым адресом.. ну и прочих подобных неприятностей. Да и не хорошо, когда на двух NS-ах одной зоны разная информация.

Тем более в данной ситуации никак нельзя отказаться от балансировки нагрузки, если не переключать зону. Если у автора не предпоалагается, что сервера могут работать параллельно, то это не подходит.

Ествественно, если не получится воспользоваться {vr,ca}rp, то такая схема подходит. Собственно, если бы автор сказал, что объединить {vr,ca}rp-ом не удастся, была бы предложена какая-нибудь похожая схема.

> не вижу никакой взаимосвязи! Т.е. по твоему хранение записей в MySQL эффективней,
> чем в текстовом файле?

Я написал "проще" и "меньше возможностей, чтобы на костылявить", но я не говорил "эффективнее". И поясню на всякий случай, что речь была про системы, где какие-то скрипты _автоматически_ правят зону по каким-то событиям. А почему проще? Например, когда изменяешь зону, нужно сдвигать серийник, а когда начинаешь делать подобные парсеры для файла - это серьёзный источник багов. Допустим, закончилось место на диске, тогда файл затрётся при первом же автоматическом передёргивании. Другими словами, нет, я не считаю, что это "эффективнее", я считаю, как я это изначально и написал, что это "проще".

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "отказоустойчивость с помощью bind"  +/
Сообщение от evi9 (ok) on 26-Авг-11, 12:23 
как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет расположен, где будут располагаться днс сервера?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 26-Авг-11, 12:35 
> как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет
> расположен, где будут располагаться днс сервера?

Вы расскажите для начала что имеется и что требуется. IP-адреса эти гуляют из одного vlan-е или как вообще это всё у вас устроено? И какому именно сервису вы хотите прикрутить failover?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "отказоустойчивость с помощью bind"  +/
Сообщение от evi9 (ok) on 27-Авг-11, 01:54 
>> как в схеме с отказоустойчивостью будет задействован "carp/vrrp" , где он будет
>> расположен, где будут располагаться днс сервера?
> Вы расскажите для начала что имеется и что требуется. IP-адреса эти гуляют
> из одного vlan-е или как вообще это всё у вас устроено?
> И какому именно сервису вы хотите прикрутить failover?

Имеется сервер, на нем 40 виртуальных доменов (apache virtual hosts).
Каждый из доменов прописан у своего регистратора, который ссылается на днс этого же сервера. На сервере стоит bind, обслуживает все домены. Есть второй сервер, он расположен в сети другого провайдера, на него с помощью rsync каждый час копируется все с первого. Трафиком он не нагружен, дежурит так сказать в stand-by режиме. Нужно чтобы при падении основного сервера (пропал канал к провайдеру, сгорело оборудование, упал апач и т.п.) весь трафик направлялся на резервный. Как только сервер оживает, весь траффик возвращался на него, а запасной переходил в режим ожидания.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 27-Авг-11, 16:10 
>[оверквотинг удален]
>> И какому именно сервису вы хотите прикрутить failover?
> Имеется сервер, на нем 40 виртуальных доменов (apache virtual hosts).
> Каждый из доменов прописан у своего регистратора, который ссылается на днс этого
> же сервера. На сервере стоит bind, обслуживает все домены. Есть второй
> сервер, он расположен в сети другого провайдера, на него с помощью
> rsync каждый час копируется все с первого. Трафиком он не нагружен,
> дежурит так сказать в stand-by режиме. Нужно чтобы при падении основного
> сервера (пропал канал к провайдеру, сгорело оборудование, упал апач и т.п.)
> весь трафик направлялся на резервный. Как только сервер оживает, весь траффик
> возвращался на него, а запасной переходил в режим ожидания.

Я, помнится, делал отказоустойчивый web-кластер с распределением нагрузки. Делалось это на связке DNS-rr+keepalived+drbd+ocfs2+rsync+mysql-replication+(php-sessions -> memcached+mysql). Вся связь между нодами осуществлялась по ipsec. Самым слабым местом был ocfs2, несколько тормозная FS. В остальном абсолютно рабочая схема.

Однако, если вы хотите делать по-вашему. Я так понял, эти сервера не имеют прямой связи друг с другом (в обход сети Интернет)? И что тоже важно, BGP, я так понимаю, тоже не доступен, так? Если "да и да", то, Вам, действительно стоит занизить TTL почти до нуля, проделегировать зону на оба сервера и выбрать один из _костыльных_ путей:
1.) Сделать скрипты, которые по событиям правят зону, переключая IP-адрес (самый терпимый, на мой взгляд, вариант). В этом случае вместо bind советую использовать какой-нибудь DNS с backend-ом в MySQL;
2.) Сделать на каждом из серверов так, чтобы bind указывал на себя, но тогда вы должны обеспечивать корректность работы "кластера" при параллельном использовании. К сожалению, эксперимент показывает, что клиенты опрашивают NS-сервера выбирая случайный, а не первый по их порядку;

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

17. "отказоустойчивость с помощью bind"  +/
Сообщение от boykov (ok) on 27-Авг-11, 13:13 
> Есть домен domain.com с адрессом 1.1.1.1
> Возможно ли настроить bind таким образом, что-бы при недоступности
> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
> а по поднятию основного резолв возвращался на 1.1.1.1 ?
> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
> какой на резервном? Что должно быть прописано у регистратора?

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "отказоустойчивость с помощью bind"  +/
Сообщение от Xaionaro (ok) on 27-Авг-11, 16:14 
>> Есть домен domain.com с адрессом 1.1.1.1
>> Возможно ли настроить bind таким образом, что-бы при недоступности
>> первого сервера, domain.com резолвился в 2.2.2.2 (запасной сервер),
>> а по поднятию основного резолв возвращался на 1.1.1.1 ?
>> Как организовать такую схему? Какой конфиг бинда должен быть на основном сервере,
>> какой на резервном? Что должно быть прописано у регистратора?
> не стоит делать обеспечение отказоустойчивости сервисов средствами, не предназначенными
> для этого.
> Выясните основные причины возможных отказов (каналы, железо, идиотизм персонала) и применяйте
> соответствующие методы (бгп, карп, кластеры, повышение квалификации)

Если я правильно понял ситуацию, то ни BGP, ни carp не доступен в данной ситуации. А повышать квалификацию своего ISP или электриков - очень проблематично :)

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру