- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
vedomir, для такой схемы нужны свои DNS, на каждом сервере. Каждый DNS не знает про другие и наивно сообщает что он и есть тот самый сервер, который нужен клиенту. Таким образом переключение клиента естественное и достаточно надежное. Проблема, как уже здесь упоминалось, в игноровании TTL некоторыми провайдерами.
vedomir, для такой схемы нужны свои DNS, на каждом сервере. Каждый DNS не знает про другие и наивно сообщает что он и есть тот самый сервер, который нужен клиенту. Таким образом переключение клиента естественное и достаточно надежное. Проблема, как уже здесь упоминалось, в игноровании TTL некоторыми провайдерами.
Что-то не понял, как это должно работать по вашей схеме.
В каждом dns указывается свой ip-адрес?
Если так, то:
1. Многие регистраторы не примут такие DNS.
2. Есть вероятность попадания на нерабочий DNS и тогда сайт вообще не загрузится.
TTL игнорируется, так что BGP - единственный выход.
Есть ещё один вариант. Для разных областей DNS должен выдавать разные ответы, чтобы трафик шёл только на локальные сервера. Технически это возможно. Останется только решить проблемы синхронизации серверов.
Сколько можно обсуждать одно и то же? Каждые полгода подопные темы появляются...
Все давно и прекрасно работет и с BGP, и с DNS.
Проблема в другом - спроса на геокластеры, да и на HA в целом, в РФ нет. Совсем нет. И не будет в ближайшее время.
Сколько можно обсуждать одно и то же? Каждые полгода подопные темы появляются...
Все давно и прекрасно работет и с BGP, и с DNS.
Проблема в другом - спроса на геокластеры, да и на HA в целом, в РФ нет. Совсем нет. И не будет в ближайшее время.
У Вас нет, а у меня в проекте записано "24 h per day 7 days per week with
better than 99.9% availability measured over a year and better than 95% availability in any one day" .
1. DNS (если ns-серверы доступны) меняется в течении TTL. Все, кто думает, что это не так - пусть идут куда-нибудь курить. Если какой-то пров кешит ДНС настолько, то это уже не наши проблемы.
2. Вопрос именно о бюджетном решении.
3. Andreyka, drbd как раз для синхронизациию
4. 4 NS как раз нужны для того, чтобы они были доступны. Один отвалится - второй ответит.
5. Простукивающий скрипт - пара строк на перле. По-моему, любой админ способен это сделать. Вопрос глупый изначально.
6. А если оба упадут? Так правильно, пропинговка яндекса и гугла, к примеру... А если все 10 упадут? Или мы чисто из-за софта резервируемся, а не по железу? О, блин... Ну вообще когда все настроено, то изменения все вносятся только после тестирования на отдельном сервере, а на рабочий проект только после ПОЛНОГО бекапа. ИМХО, другое не возможно.
7. Дешево и сердито. На канал надо только потратиться. Да, криво, но работает. Резервируется по железу и на случай если упадет. Чтобы понять, как это работает - NS2 и NS1 поднимаем на одной ВДС, NS3 и NS4 на второй - оно работает, так как когда падает одна ВДС, тогда на второй меняется зона и с нее начинает отдаваться сайт, пока не поднимется первая. Как-то так. Причем занимает это все как раз время TTL. А про не падучее железо это вы мне сказки рассказывайте... Новое железо, прошедшее все тесты может сдохнуть неожиданно (видел). Ну а по поводу софта - от ваших кривых рук никто не застрахует.
У Вас нет, а у меня в проекте записано "24 h per day 7 days per week with
better than 99.9% availability measured over a year and better than 95% availability in any one day" .
Так именно об этом и речь - пока под HA будут подразумевать "24 h per day 7 days per week with
better than 99.9% availability measured over a year and better than 95% availability in any one day" - никакие геокластеры никому нужны не будут.
7. Дешево и сердито. На канал надо только потратиться. Да, криво, но работает. Резервируется по железу и на случай если упадет. Чтобы понять, как это работает - NS2 и NS1 поднимаем на одной ВДС, NS3 и NS4 на второй - оно работает, так как когда падает одна ВДС, тогда на второй меняется зона и с нее начинает отдаваться сайт, пока не поднимется первая. Как-то так. Причем занимает это все как раз время TTL. А про не падучее железо это вы мне сказки рассказывайте... Новое железо, прошедшее все тесты может сдохнуть неожиданно (видел). Ну а по поводу софта - от ваших кривых рук никто не застрахует.
Конечно можно и так сделать, на VPS, но не солидно это, мягко говоря.
По нормальному, это делается на anycast сети DNS-серверов с серьезной системой мониторинга доступности сайтов, расположенных в 15 ДЦ по всему миру со 100% SLA и серьезными штрафами за простой. Кстати, стоит все это удовольствие совсем не дорого.
Да не так это будет. Если отвалится один, то часть клиентов будут получать ошибку резолвинга.
Не будет запрос к DNS идти сначала к одному, а если не доступен - к другому. Пойдёт к случайному и если он не доступен, то будет ошибка.
Поэтому нужно иметь стабильные DNS. К примеру, можно арендовать отдельно. Вот только мониторить сервера нужно и информацию в DNS менять.
Вот попробуйте так сделать сначала. Будет совершенно не ожиданный для вас результат. Клиентское ПО будет запрашивать данные со случайного dns и не факт, что он доступен в данный момент.
Да не так это будет. Если отвалится один, то часть клиентов будут получать ошибку резолвинга.
Не будет запрос к DNS идти сначала к одному, а если не доступен - к другому. Пойдёт к случайному и если он не доступен, то будет ошибка.
будет. вот в нашей деревне был случай : серьезная фирма неизвестно куда потеряла пароль от nic.ru и несколько лет один из ns-ов был неправильный - так никто ничего не заметил.
будет. вот в нашей деревне был случай : серьезная фирма неизвестно куда потеряла пароль от nic.ru и несколько лет один из ns-ов был неправильный - так никто ничего не заметил.
А я вот я знаю случаи, когда у сервера 4 dns и один из них не рабочий. И периодически "стегало", никто не мог понять почему. А причина была проста - на одном из dns глюки.
Единственное, что интернет-провайдеры могут кэшировать ответ рабочего dns и потом всё нормально будет работать. Но шанс "нарваться" на нерабочий есть.
P.S.: Я даже сейчас проверял. У меня 4 dns у домена, если остановить хоть один, начинаются переодически проблемы. Если запрос попадает к неработающему dns, то долго всё тормозит и в итоге не может определить ip. Хотя другие 3 в этот момент работают.