Отказоустойчивость на базе DNS

    Внутри одно дата-центра организовать отказоустойчивость легко — есть масса инструментов и техник.
    А как быть если надо организовать отказоустойчивость на базе нескольких дата-центров?

    Ниже я приведу, на мой взгляд элегантное и очень дешевое решение, не лишенное конечно же недостатков.

    Смысл заключается в том чтоб в каждом дата-центре был свой NS сервер который отдает IP своего дата-центра.

    Теперь в картинках, imho так нагляднее и понятнее...

    И так, что происходит при попытке браузером открыть web страничку (упрощенный вариант):



    Если же DNS не отвечает, то dns клиент обращается к следующему ns серверу:



    Настройки зон для каждого дата-центра.



    Тут видно что в некоторых дата-центрах фронтов может быть больше чем 1.

    В общем я рассказал про идею. А из нее можно накрутить много чего интересного.

    Достоинства:
    • Если падает дата-центр в течении минуты все клиенты уйдут на работающие площадки.
    • Если надо провести профилактические работы — выключаем named, ждем минуту, можно работать.

    Недостатки:
    • Очень маленькая часть клиентов все равно будет ломиться в «выключенный» дата-центр.
    • Надо поддерживать отдельный файл зон для каждого дата-центра, но эта задача легко решается с помощью например puppet.
    • Не совсем равномерно распределяется нагрузка, но терпимо


    P.S. Обязательно в файле зон выставить:
    $TTL 60; 1 minutes
    Share post

    Similar posts

    Comments 77

      +1
      Это прекрасно. Вот только и данные в каждом дата-центре должны быть идентичны. А это не всегда возможно.
        0
        Как невозможно? :) очень даже возможно.
        Puppet_ом раскладываем файл зон.
        Есть раздел общий а есть раздел уникальный для каждого ДЦ.
          +3
          Насколько я понял al1k — речь идет о данных в контексте UGC, исходный код и БД.
            0
            Верно. В первую очередь имеются в виду базы данных. Тут будут сложности как с репликацией данных вообще, так и с объемом данных, который нужно передавать постоянно.
              +1
              репликация это вертикальное масштабирование. рано или поздно упремся. только горизонт. только споты. только хардкор.

              =)
        +1
        Чем лучше чем Round-robin DNS?
          +1
          тем, что не надо следить за тем жив ли ДЦ. все работает в автоматическом режиме с файлтаймом в 1 минуту. профилактику можно проводить на лету.
            0
            И все таки не понимаю, чем отличается от RR. Если ЦОД не доступен — бразуер пойдет на следующий в списке айпишник, и будет пользоваться им.
              +2
              нет не пойдет… или я чего то не понимаю…
              dns server вернет список IP.
              dns client обратится к первому и все.
                +1
                нет. не пойдет. в этом и фишка.
            0
            Согласен с al1k. В связи с этим и поднял тему в Q&A.
            А вообще — я в этом случае за DNS Round robin.
              +2
              причем тут данные и RR? это на столько разные вещи… тут же говорится о форонтах и отказоустойчивом автоматичсеком решении, что бы по ночам спать спокойно.
                +2
                Для того, чтобы подобный механизм реализовать и ночью мне спать спокойно — необходимо решить вопрос синхронизации данных между ДЦ.
                  0
                  ответил в Q&A
                    +1
                    я понимаю вашу задачу, но это абсолютно разные задачи.
                  +2
                  в RR NS будет отдавать IP «выключенного» сервера и клиенты не смогут приконектиться к серверу.

                  В моей схеме через минуту все уже «переедут» на рабочие сервера.
                  0
                  Что касается сессий: пользователь всегда попадает на один и тот же сервер?
                    0
                    Да с сессиями засада.
                    Чтоб пользователь попал всегда на один и тот же фронт (в рамках одной сесии) в html приходится прописывать URL к этому конкретному фронту.

                    +1
                    GSLB намного более гибкий.
                    В идеальном мире клиент не должен сам решать, куда идти.
                      +3
                      Не совсем уверен в: «Если падает дата-центр в течении минуты все клиенты уйдут на работающие площадки»
                      То что у DNS указан TTL 1min — провайдеры могут его игнорировать. Или я не прав?
                        0
                        не прав
                          0
                          Прав. Точнее DNS кэш сервер провайдера может «залипнуть», а то и вовсе быть настроен криворуким админом. Не сказал бы, что это очень частая ситуация, но имеет место быть с некоторой регулярностью.
                            0
                            Многие операторы к слову говоря занижают специально TTL если оно слишком большое. Этим точно балуется билай. Видимо чтобы избавить себя от лишьних звонков в тех поддержку.
                              0
                              Во всех случаях с которыми сталкивался я ситуация была как раз обратная. На стороне провайдера TTL домена не срабатывал и записи в кэше не обновлялись. Причем проблема выявляется только в одном случае — домен клиента переежает на сервер с другим IP. Если бы этого не было, ни кто бы и не узнал, что проблема вообще есть.

                              Так что уменьшенный TTL на стороне провайдера это в принципе даже хорошо.
                              0
                              Да некоторые кеширующие сервера игнорируют TTL, но их очень мало. может 1-2%

                            0
                            Мы используем немного другую схему, но, в целом, суть та же — TTL на записи 5 минут, в случае падения одного ДЦ запись меняется.
                            Через пять минут после переключения я на своем haproxy вижу 0, редко-редко когда появится 1-2.
                            Вывод: подавляющее большинство провайдеров TTL обрабатывают правильно.
                              0
                              «Через пять минут после переключения я на своем haproxy вижу 0, редко-редко когда появится 1-2.
                              Вывод: подавляющее большинство провайдеров TTL обрабатывают правильно.»

                              Вот это интересно.
                              А какова выборка в количественном выражении?
                              И по странам?
                            +1
                            чтото мне кажется что многие клиенты не воспринимают '$TTL 60; 1 minutes' как должное.
                              –1
                              это какие? примеры в студию.

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

                                Другое дело, когда сайт пытается открыть человек являющийся владельцем этого сайта. И вот тут да, он обязательно достучится до технической поддержки и целью выяснить, какого же хрена сайт не пашет. Могу это утверждать исходя из опыта работы у одного достаточно известного регистратора-хостера.
                                +1
                                ооооочень маленький процент… можно игнорировать.
                                0
                                А еще есть готовый вариант у Амазона. aws.amazon.com/route53/

                                Там правда немного другой способ, у них настраиваются http/tcp проверки на сервер.

                                Сразу оговорюсь, что работает не только для сервисов AWS.
                                  0
                                  Как раз смотрю в эту сторону — но интересно узнать о том, как механизм сессий при этом ведет себя. Будет ли один и тот же пользователь направляться на один и тот же сервер.
                                    +1
                                    Сомневаюсь, очень большая нагрузка помнить куда какого пользователя послали. IMHO.
                                      0
                                      Не будет. Каждый раз будет выдаваться любой из живых IP. Если рассматриваем схему Active-Active.
                                        0
                                        а если Actie-Passive?
                                          0
                                          Тогда всегда будет выдаваться только Active IP, в случае падения Active только Passive.
                                    0
                                    Так а что, не тормозит разве маленькое время устаревание загрузку страниц в браузере? Он же должен все время днс-резолвинг повторять.
                                      0
                                      Обычно это нивелируется DNS кэшем провайдера.
                                        0
                                        Да как же он нивелируется, если DNS-кэш провайдера сам раз в минуту будет на основной DNS-ходить. Не нивилируется. Но практика полуторагодичного использования, действительно, показала, что устаревание в 1 минуту практически не ощущается клиентами. Можно смело использовать.
                                      +1
                                      Есть конторы, считающие ttl ~ 60 секунд признаком fast flux'а, а его, в свою очередь, признаком ботнета. На этой почве можно попасть в неприятную ситуацию. Это первый минус.
                                      Второй — при желании запустить DNSSec, придется подписывать несколько зон.
                                        0
                                        > Есть конторы, считающие ttl

                                        какие? можно поточнее?
                                          0
                                          Если мне склероз не изменяет, то тот же спамхаус.
                                          Низкий TTL сам по себе конечно не означает fast flux, но является предметом для пристального внимания. Тот же ICANN советует минимальное значение — 30 минут.
                                            0
                                            Clarifications to the DNS Specification
                                            tools.ietf.org/html/rfc2181#page-10

                                            8. Time to Live (TTL)

                                            The definition of values appropriate to the TTL field in STD 13 is
                                            not as clear as it could be, with respect to how many significant
                                            bits exist, and whether the value is signed or unsigned. It is
                                            hereby specified that a TTL value is an unsigned number, with a
                                            minimum value of 0, and a maximum value of 2147483647. That is, a
                                            maximum of 2^31 — 1. When transmitted, this value shall be encoded
                                            in the less significant 31 bits of the 32 bit TTL field, with the
                                              0
                                              Техническая спецификация — это одно, административная рекомендация — другое, а спамо- и малвароборческие организации руководствуются вообще чем-то третьим.
                                                0
                                                В общем работает эта схема не на одном проекте. Все замечательно :)
                                        0
                                        вот момент выключения dns


                                          0
                                          Кстати, хочу заметить, что если глубина просмотра типичного пользователя — 1-2 страницы (бывают и такие сайты), то такой график может быть и при TTL=1day. Если же пользователь сидит на сайте, то современный браузер, насколько я понимаю, сам кэширует IP-адрес домена, причем плюет на настройки устаревания зоны (поправьте меня, если я ошибаюсь). По крайней мере, я помню, как приходилось несколько раз закрывать+открывать браузер даже после dns flush-а на локальной машине (даже Ctrl+F5 не помогало, только переоткрытие). Может быть, конечно, браузер умный и, видя, что IP-адрес перестал отвечать, быстренько сделает DNS-запрос за новым адресом, но что-то я в этом сомневаюсь (опять же — поправьте меня, если это не так).

                                          По сему — реквестую чистый эксперимент у тех, кто пользуется методом топика:
                                          1. Заходим на сайт.
                                          2. Переключаем DNS.
                                          3. Продолжаем ходить по сайту тем же браузером.
                                          4. Смотрим, через какое время «отпустит» (если вообще отпустит).
                                            +1
                                            делали следующее в разных броузерах. 2 сервера фронта на балансировке с ТТЛ 60. ходим по сайту. то.се. отключаем 1 сервер. максимум через минуту работа восстанавливается. тестили из локалки, и снаружи.

                                            потом делали под реальной нагрузкой. примерно 1к запросов в сек. просто отключали ДНС на одном фронте. 3 фронта под балансировкой. через минуту почти все юзеры перетекают на работающие сервера. остаются 1-2 запроса, но это для нас приемлимо.

                                            все, что нам надо это автоматическое переключение при отказе. нас это устраивает.

                                            если есть желание можно провести эксперимент. мощности есть. пишите в личку.
                                              0
                                              Ну как вам не стыдно, зачем же вот так сразу в личку. :)

                                              По делу: вот это уже пошла экспериментальная информация, это хорошо. Есть 2 мысли:
                                              1. Напишите здесь, пожалуйста, адрес сайта, на котором организована такая схема. Каждый сможет сам протестить, что к чему, даже без вашего участия — просто ра своем фаерволе перекроет тот или иной фронт+днс, и вам не придется ДЦ отключать.
                                              2. То, что браузеры переключаются — это ок. Хотелось бы еще второй момент выяснить — как часто они делают днс-запросы «ненужные», когда все работает штатно? А то на среднем сайте по исследованиям гугла — порядка 5 доменов задействовано, и если к каждому из них каждую минуту каждый пользователь будет за ip-адресом ломиться, работа сайта замедлится, лишний пинг добавится.
                                                0
                                                по 1 вопросу светить как то не хотелось…
                                                по второму: не броузер а dns client получив список ns от root-dns сервера дергает ваш. поел перогоже откза дергает другой, т.к. не получил никакой A записи.
                                                А вот когда получил держит ее в кеше TTL секунд :) и процесс повторяется.
                                                  0
                                                  > Напишите здесь, пожалуйста, адрес сайта, на котором организована такая схема.

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

                                                  ===

                                                  вот как выглядит нагрузка на одном боевом проекте. в среднем 300 rps. в пиках доходит до 1000 rps. собственно можно увидеть нагрузку фронтов и нагрузку DNS серверов на них. если хочется, я могу выключить один из серверов (погасить там DNS) на полчасика и мы увидим перетекание нагрузки. потом его включу и нагруз опять перераспределится.

                                                  Запросы на фронты



                                                  Траффик



                                                  BIND



                                                  NGINX на 1 фронте

                                                    0
                                                    Хабраэффекта не существует, тем более — в нишевом топике, тем более — по ссылке в коммента. :-)

                                                    Как я выше писал, график общей нагрузки может мало что показывать — важен опыт отдельного пользователя, который ходит по сайту в момент, когда один из ДЦ внезапно падает. А именно, 2 аспекта такого опыта:
                                                    1. Что происходит, когда отдельно взятый юзер ходит-ходит по сайту, а один ДЦ внезапно падает — через сколько времени юзер может продолжит хождение (выше вы писали, что проводили эксперимент, и в течение минуты он может продолжить ходить — с этим ОК, можно считать вопрос решенным).
                                                    2. Что происходит, когда отдельно взятый юзер ходит-ходит по сайту, а ДЦ никак не падает и не падает. Сколько DNS-запросов при этом генерирует юзер: если по одному на каждый домен в каждую минуту (в чем лично я сомневаюсь — см. выше мои наблюдение про сброс кэша локального резолвера, браузеры его не видят) — то это плохо (увеличивается пинг). Идеальная ситуация — браузер сам кэширует все у себя, не обращаясь к резолверу (возможно, он так и делает), и, получив однажды IP-адрес, не идет в DNS до тех пор, пока не обнаружил, что сайт вдруг перестал отвечать. Но я не знаю, далают ли так современные браузеры. Имея пример сайта, на котором реализована описанная в топике техника, это легко проверить без выключения серверов, достаточно на локальной машине перекрыть фаерволом один из ДЦ.

                                                    Таким образом, по п. 2 полной ясности пока так и нет.
                                                      0
                                                      > Таким образом, по п. 2 полной ясности пока так и нет.

                                                      готов проэксперементировать. скажите что и как сделать?
                                                        0
                                                        Ну я вроде бы писал, что сделать: дать ссылку на сайт, где реализуется описанная в посте схема. Больше ничего не требуется.
                                                          0
                                                            0
                                                            440hz напишите еще, пожалуйста: может быть, у вас был опыт в вопросе habrahabr.ru/post/177145/#comment_8222453? Я бы в личку написал, но, к сожалению, у вас в профиле конвертик не показывается… надеюсь, что упоминание 440hz сработает, и вам придет письмо-уведомление.
                                                            0
                                                            в приват отписал
                                                        0
                                                        в среднем 300 rps

                                                        Это динамика+статика? Чисто динамика?
                                                          0
                                                          А какая разница динамика или статика?
                                                            0
                                                            Динамика — показатель эффективности работы бэкэнда.
                                                            Статика — показатель эффективности работы nginx.

                                                            300 rps на чисто статических сайтах банальная себе такая величина, ибо да, nginx хорош. 300 rps динамики, да еще на развесистой бизнес логике, да еще с одного сервера, может быть очень хорошим показателем. Поэтому характер нагрузки имеет значение.
                                                              0
                                                              Как это связанно с работой dns? и скоростью переключения клиентво?
                                                                0
                                                                Это был вопрос к комментарию.
                                                        0
                                                        вот. отключение одного сервера.

                                                        видно, что на втором графике траф перераспределяется на другие сервера.

                                                  0
                                                  У нас состоялась небольшая переписка с rukhem в привате — выкладываю ее тут, она дает некоторую дополнительную информацию к топику. Может быть, конечно, это повтор, но вроде в чистом виде не обсуждалось пока.

                                                  Пусть у меня 2 ДЦ, соответственно, 2 NS-сервера: ns-04.example.com и ns-03.example.com, при этом ns-04 (и его ДЦ) — основной. По идее, надо тогда прописать в список NS-серверов для домена такой порядок:
                                                  ns-04.example.com
                                                  ns-03.example.com
                                                  чтобы клиенты брали первый NS-сервер в списке. Но на практике многие регистраторы сортируют NS-серверы по алфавиту (в моем случае это не подходит), так что данный порядок установить не получается:
                                                  — nic.ru для доменов в зоне COM точно так сортирует (для зоны ru — не сортирует)
                                                  — philsdomains — то же самое, в каком порядке ни задавай, все равно оказывается по алфавиту
                                                  — godaddy — пока еще точно не знаю, данные обновляются.
                                                  Вопрос — что делать в этом случае. Можно ли как-то на своей стороне задать этот порядок, чтобы не завязываться за особенности регистраторов?

                                                  Опрашивайте root сервер. он будет выдавать список ваших ns серверов round robbin.
                                                  так что заморачиваться на тему сортировки имхо не стоит.

                                                  Так-так… то есть, получается, схема, когда в 2 ДЦ стоят 2 NS-сервера, отдающие IP-адреса «своего» ДЦ, в «чистом виде» для организации fallback-ДЦ не работает? И запросы будут идти равномерно и в тот, и в другой ДЦ, а не только «в самый первый»? Тогда получается, что нужно строго следить за синхронностью данных (даже асинхронная репликация тут не подойдет, только синхронная), потому что один и тот же клиент может попадать то в один ДЦ, то в другой.

                                                  В этой связи техника, когда IP-адрес на NS-сервере «вручную» переключается при сбое одного из ДЦ, выглядит лучше. Т.е. оба NS-сервера выдают IP в одном и том же ДЦ, а когда он падает, админ бородой переключает IP-адрес, и NS-серверы начинают выдавать IP в другом ДЦ.
                                                    0
                                                    Вы сами поняли что написали?
                                                      +1
                                                      Странный вопрос. Собственно, есть 2 схемы организации «отказоустойчивости» с использованием DNS (в обоих случаях TTL=1min):

                                                      1. Когда есть 2 ДЦ, в каждом их них свой NS-сервер, выдающий IP в своем ДЦ — ровно то, что описано в топике. Минус этого способа — трафик идет в оба ДЦ, если оба работают, и нельзя сделать так, чтобы трафик шел только в один из ДЦ (основной), в то время как второй (резервный) простаивал бы и ждал, когда упадет первый. Это накладывает жесткие условия, например, на организацию репликации БД и вообще на синхронизацию данных, а то один и тот же клиент будет попадать то в первый ДЦ, то (через минуту) во второй, и начнет удивляться, чего это у него данные разные.

                                                      2. Когда есть 2 ДЦ, но на NS-серверах прописаны только IP первого из них (основного). Когда основной ДЦ падает, кто-то переключает IP-адрес на NS-серверах, и трафик начинает идти в резервный ДЦ. Минус тут — должен быть этот «кто-то». Правда, он и так должен в большинстве случаев быть (хотя бы чтобы назначить реплику новым мастером), но все равно, 2 операции хуже, чем одна.
                                                        0
                                                        Теперь понятно.

                                                        1, Вопрос с репликацией данных решаем.
                                                        В предложенной мной схеме данные во всех ДЦ должны быть одинаковы — это если хотите требование такое.

                                                        2. «кто-то» кто будет переключать что-то вручную ЗЛО, все должно работать автоматически.
                                                        А что когда кто-то переключит вручную в этот момент реплика догонится волшебным образом? :)
                                                          0
                                                          Конечно понимаю, что может не спортивно, но завязываем файловер на тот же Route53, делаем мастер-мастер и убираем «кого-то» из схемы.
                                                            0
                                                            Route53 failover (вместе с health-check'ами их же) — штука хорошая, да. А вот мастер-мастер с двумя датацентрами ИМХО на практике не работает, увы (разве что в вырожденных случаях, когда у нас очень-очень мало записи идет в БД).
                                                              0
                                                              Все зависит от условий, нагрузки, удаленности ДЦ и т.д. Часто банально делают реплику всех! баз вместо только критических для таких переключений. Я бы не сказал, что когда «очень-очень мало записи», а сказал бы, что это просто будет сложнее:)
                                                                0
                                                                А почему вы решили что мастер-мастер? Яж написал в каждом ДЦ зоны немного разные — ns сервер в каждом дц отдает IP только своего ДЦ.
                                                                А зоны разливаются через Puppet ;)
                                                                  0
                                                                  Я отвечал на комментарий про «делаем мастер-мастер и убираем «кого-то» из схемы» выше. И здесь под «мастер-реплика» имелся в виду мастер СУБД.
                                                          0
                                                          поставил TTL 1;
                                                          2 недели — полет нормальный.
                                                            0
                                                            Вопрос по статье. Предположим, у меня есть example.com с NS-записью, содержащей 2 DNS-сервера: ns1.example.com и ns2.example.com. Первый DNS-сервер находится в первом ДЦ и отдает IP-адрес для example.com из своего ДЦ, второй, соответственно, во втором (и отдает тоже IP-адрес из своего ДЦ). Время устаревания A-записи для example.com у ns1 и ns2 установлено равным 1 минуте. Все, как в статье.

                                                            Теперь предположим, что первый ДЦ ложится. Соответственно, клиентам при запросе example.com становится доступен только ns2, но не ns1.

                                                            Вопрос: а вызовет ли это задержку при разрешении DNS-имен у клиентов? Ведь ОС клиента может сунуться на ns1, оттаймаутиться на нем (например, тайм-аут 5 секунд) и уж только после этого пойдет на ns2. Т.е. будет задержка в 5 секунд раз в минуту (т.к. время устаревания записи равно 1 минуте). Такое ощущение, что эта задержка ЕСТЬ, хотя я не могу добиться точного воспроизведения. Как с ней быть?

                                                            (Выставить время устаревания зоны больше 1 минуты я не могу, потому что иначе старые клиенты, которые видели ДЦ1, не переключатся быстро на использование ДЦ2. Например, если я сделаю время устаревания 1 час, то после последовательности «1. клиент сделал запрос и попал в работающий ДЦ1; 2. ДЦ1 лег» клиент получит IP-адрес ДЦ2 только через час.)
                                                              0
                                                              >Время устаревания A-записи для example.com у ns1 и ns2 установлено равным 1 минуте.

                                                              1. поставьте TTL 1; для всей зоны
                                                              Это увеличит нагрузку на dns но сильно сократит время переключения на второй ДЦ в случае падения первого.

                                                              2. пусть dns первого ДЦ (ns1) отдает NS запись только своего ДЦ

                                                              $TTL 1
                                                              ;…
                                                              example.com. NS ns-dc1
                                                              ns-dc1 A ip_dc1
                                                              example.com. A ip_dc1

                                                              а dns второго dc отдает NS второго

                                                              $TTL 1
                                                              ;…
                                                              example.com. NS ns-dc2
                                                              ns-dc1 A {ip_dc2}
                                                              example.com. A {ip_dc2}

                                                              >оттаймаутиться на нем (например, тайм-аут 5 секунд)
                                                              Это зависит от dns клиента. но как показывает практика 95% клиентов переключаются моментально.

                                                              Как проверить:
                                                              Рисуете графики конектов к nginx для обоих ДЦ.
                                                              В одном выключаете dns, смотрите на графики конектов к nginx :)
                                                                0
                                                                Не, графиками nginx-а мой вопрос вряд ли проверить. Задержка-то на стороне клиента (причем небольшая, всего 5 секунд, но для восприятия скорости открытия сайта это может быть критичным). Хочется именно этой задержки по возможности избежать в случае, когда одна машина включена, а другая — выключена. На второй сервер все запросы при отключении первого в итоге приходят (т.е. клиенты реально переключаются в течение 1 минуты), это я проверил.

                                                            Only users with full accounts can post comments. Log in, please.