forum.opennet.ru - "отказоустойчивость с помощью bind" (19)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"отказоустойчивость с помощью 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ообщить модератору

Оглавление

отказоустойчивость с помощью bind, Pahanivo, 12:59 , 24-Авг-11, (1)

отказоустойчивость с помощью bind, evi9, 13:11 , 24-Авг-11, (2)

отказоустойчивость с помощью bind, омоним, 13:45 , 24-Авг-11, (3)
отказоустойчивость с помощью bind, user, 17:12 , 24-Авг-11, (7)

отказоустойчивость с помощью bind, YuryD, 15:46 , 24-Авг-11, (4)

отказоустойчивость с помощью bind, Pahanivo, 16:25 , 24-Авг-11, (5)

отказоустойчивость с помощью bind, Xaionaro, 16:45 , 24-Авг-11, (6)

отказоустойчивость с помощью bind, evi9, 18:11 , 24-Авг-11, (8)

отказоустойчивость с помощью bind, Xaionaro, 19:29 , 24-Авг-11, (9)

отказоустойчивость с помощью bind, ALex_hha, 11:39 , 25-Авг-11, (10)

отказоустойчивость с помощью bind, Xaionaro, 13:21 , 25-Авг-11, (11)

отказоустойчивость с помощью bind, ALex_hha, 16:49 , 25-Авг-11, (12)

отказоустойчивость с помощью bind, Xaionaro, 17:18 , 25-Авг-11, (13)

отказоустойчивость с помощью bind, evi9, 12:23 , 26-Авг-11, (14)

отказоустойчивость с помощью bind, Xaionaro, 12:35 , 26-Авг-11, (15)

отказоустойчивость с помощью bind, evi9, 01:54 , 27-Авг-11, (16)

отказоустойчивость с помощью bind, Xaionaro, 16:10 , 27-Авг-11, (18)

отказоустойчивость с помощью bind, boykov, 13:13 , 27-Авг-11, (17)

отказоустойчивость с помощью bind, Xaionaro, 16:14 , 27-Авг-11, (19)

Сообщения по теме [Сортировка по времени | 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору