У нас есть набор общего статического контента, который мы обслуживаем между нашими веб-сайтами по адресу http://sstatic.net. К сожалению, этот контент в настоящее время вообще не имеет балансировки нагрузки - он обслуживается с одного сервера. Если у этого сервера есть проблемы, все сайты, которые на него полагаются, фактически не работают, потому что общие ресурсы являются важными общими библиотеками javascript и изображениями.
Мы ищем способы сбалансировать нагрузку статического контента на этом сервере, чтобы избежать зависимости от одного сервера.
Я понимаю, что циклический DNS - это, в лучшем случае, нижний предел (некоторые даже могут сказать гетто) решение, но я не могу не задаться вопросом - Является ли циклический DNS "достаточно хорошим" решением для базовой балансировки нагрузки статического контента?
Это обсуждается в [DNS] [балансировка нагрузки] теги, и я прочитал несколько замечательных сообщений по этой теме.
Мне известны общие недостатки балансировки нагрузки DNS с помощью нескольких циклических записей A:
Но является ли циклический DNS достаточно хорошим стартером, лучше, чем ничего, «пока мы исследуем и реализуем лучшие альтернативы» - это форма балансировки нагрузки для нашего статического контента? Или циклический перебор DNS в значительной степени бесполезен любой обстоятельства?
Джефф, я не согласен, балансировка нагрузки не подразумевает избыточности, это как раз наоборот. Чем больше у вас серверов, тем больше вероятность отказа в данный момент. Вот почему резервирование является обязательным при балансировке нагрузки, но, к сожалению, существует множество решений, которые обеспечивают только балансировку нагрузки без выполнения какой-либо проверки работоспособности, что приводит к менее надежному обслуживанию.
Раундробин DNS отлично подходит для увеличения пропускной способности за счет распределения нагрузки между несколькими точками (потенциально географически распределенными). Но это не обеспечивает переключения при отказе. Сначала вы должны описать, какой тип отказа вы пытаетесь устранить. Сбой сервера должен быть покрыт локально с помощью стандартного механизма подмены IP-адреса (VRRP, CARP, ...). Отказ коммутатора покрывается устойчивыми связями на сервере с двумя коммутаторами. Отказ канала WAN может быть покрыт настройкой нескольких каналов между вами и вашим провайдером с использованием протокола маршрутизации или решения уровня 2 (например, многосвязного PPP). Сбой сайта должен быть покрыт BGP: ваши IP-адреса реплицируются на нескольких сайтах, и вы объявляете их в сети только там, где они доступны.
Из вашего вопроса кажется, что вам нужно только предоставить решение для переключения сервера при отказе, что является самым простым решением, поскольку оно не требует какого-либо оборудования или контракта с каким-либо провайдером. Для этого вам просто нужно установить соответствующее программное обеспечение на своем сервере, и это, безусловно, самое дешевое и надежное решение.
Вы спросили: «Что делать, если машина haproxy откажет?». Это то же самое. Все люди, которых я знаю, которые используют haproxy для балансировки нагрузки и высокой доступности, имеют две машины и запускают на них либо ucarp, либо keepalived, либо heartbeat, чтобы гарантировать, что одна из них всегда доступна.
Надеюсь, это поможет!
Что касается балансировки нагрузки, это гетто, но более или менее эффективно. Если у вас был один сервер, который падал из-за нагрузки, и вы хотели распределить его по нескольким серверам, это может быть хорошей причиной для этого, по крайней мере, временно.
Существует ряд обоснованных критических замечаний по поводу циклического перебора DNS как «балансировки» нагрузки, и я бы не рекомендовал делать это для этого, кроме как в качестве краткосрочного бандажа.
Но вы говорите, что ваша основная мотивация - избежать зависимости от одного сервера. Без какого-либо автоматизированного способа вывода мертвых серверов из ротации это не очень ценно как способ предотвращения простоев. (Благодаря автоматизированному способу вывода серверов из ротации и короткому TTL это превращается в отработку отказа в гетто. Вручную даже не это.)
Если один из ваших двух серверов с циклическим перебором выйдет из строя, то 50% ваших клиентов выйдут из строя. Это лучше, чем 100% сбой только с одним сервером, но почти любое другое решение, обеспечивающее реальное аварийное переключение, было бы лучше этого.
Если вероятность отказа одного сервера равна N, то для двух серверов ваша вероятность равна 2N. Без автоматизированного, быстро отказоустойчивость, эта схема увеличивается вероятность того, что некоторые из ваших пользователей столкнутся с ошибкой.
Если вы планируете вручную выводить мертвый сервер из режима ротации, вы ограничены скоростью, с которой вы можете это сделать. и TTL DNS. Что делать, если сервер умрет в 4 утра? Лучшая часть настоящего аварийного переключения - это спать всю ночь. Вы уже используете HAProxy, так что вы должны быть с ним знакомы. Я настоятельно рекомендую использовать его, поскольку HAProxy разработан именно для этой ситуации.
Круговой DNS - это не то, что люди думают. Как автор программного обеспечения DNS-сервера (а именно, BIND) мы получаем пользователей, которые задаются вопросом, почему их циклический алгоритм перестает работать, как планировалось. Они не понимают, что даже при TTL, равном 0 секунд, будет некоторое количество кеширования, поскольку некоторые кеши устанавливают минимальное время (часто 30-300 секунд), несмотря ни на что.
Кроме того, хотя ваши серверы AUTH могут выполнять циклический перебор, нет гарантии, что те, которые вам небезразличны - кеши, с которыми общаются ваши пользователи - будут. Короче говоря, циклический перебор не гарантирует никакого упорядочивания с точки зрения клиента, только то, что ваши серверы аутентификации предоставляют кешу.
Если вам нужна настоящая отработка отказа, DNS - это всего лишь один шаг. Неплохая идея указать более одного IP-адреса для двух разных кластеров, но я бы использовал там другую технологию (например, простую рассылку) для фактической балансировки нагрузки. Я лично презираю оборудование для балансировки нагрузки, которое сбивается с DNS, поскольку оно обычно ошибается. И не забывайте, что приближается DNSSEC, поэтому, если вы все же выберете что-то в этой области, спросите своего поставщика, что происходит, когда вы подписываете свою зону.
Я уже говорил это несколько раз раньше и скажу еще раз - если проблема в отказоустойчивости, то трюки с DNS не ответ.
Лучшие системы высокой доступности позволят вашим клиентам использовать один и тот же IP-адрес для каждого запроса. Это только способ гарантировать, что клиенты даже не заметят сбоя.
Итак, фундаментальное правило состоит в том, что для истинной устойчивости требуется IP. маршрутизация уровень хитрости. Используйте устройство балансировки нагрузки или OSPF «равная стоимость с несколькими путями» или даже VRRP.
DNS с другой стороны обращаясь технология. Он существует исключительно для отображения одного пространства имен в другое. Он не был предназначен для очень краткосрочного динамичный изменения в этом отображении, и, следовательно, когда вы попытаетесь внести такие изменения, многие клиенты либо не заметят их, либо, в лучшем случае, заметят их очень долго.
Я бы также сказал, что поскольку грузить для вас не проблема, вы можете иметь другой сервер, готовый к работе в качестве горячего резерва. Если вы используете тупой циклический перебор, вам необходимо заранее изменить свои записи DNS, когда что-то ломается, поэтому вы можете также заранее активировать сервер горячего резервирования и не смени свой DNS.
Я прочитал все ответы, и одной вещи, которую я не заметил, является то, что большинство современных веб-браузеров попробуют один из альтернативных IP-адресов, если сервер не отвечает. Если я правильно помню, Chrome даже попробует несколько IP-адресов и продолжит работу с сервером, который отвечает первым. Так что, на мой взгляд, балансировка нагрузки DNS Round Robin всегда лучше, чем ничего.
Кстати: я больше рассматриваю DNS Round Robin как простое решение для распределения нагрузки.
Примечательно, сколько участников помогают распространять дезинформацию о DNS Round Robin как механизме распределения нагрузки и обеспечения устойчивости. Обычно это работает, но вам нужно понимать, как это работает, и избегать ошибок, вызванных всей этой дезинформацией.
1) TTL для записей DNS, используемых для циклического перебора, должен быть коротким, но НЕ НУЛЕВЫМ. Нулевое значение TTL нарушает основной способ обеспечения устойчивости.
2) DNS RR распространяется, но не балансирует нагрузку, она распределяет ее, потому что в большой клиентской базе они, как правило, запрашивают DNS-сервер независимо, и поэтому в конечном итоге получают разные записи DNS первого выбора. Эти разные варианты первого выбора означают, что клиенты обслуживаются разными серверами, а нагрузка распределяется. Но все зависит от того, какое устройство выполняет DNS-запрос и как долго оно сохраняет результат. Типичным примером является то, что все клиенты за корпоративным прокси-сервером (который выполняет для них DNS-запрос) все в конечном итоге нацелены на один сервер. Нагрузка распределена, но не сбалансирована равномерно.
3) DNS RR обеспечивает отказоустойчивость, если клиентское программное обеспечение реализует ее должным образом (и время жизни, а также время действия внимания пользователей не слишком короткое). Это связано с тем, что циклический перебор DNS предоставляет упорядоченный список IP-адресов серверов, и клиентское программное обеспечение должно пытаться связаться с каждым из них по очереди, пока не найдет сервер, который принимает соединение.
Таким образом, если первый выбранный сервер не работает, тогда время ожидания клиентского TCP / IP-соединения истекает и при условии, что ни TTL, ни интервал внимания не истек, тогда клиентское программное обеспечение делает еще одну попытку подключения ко второй записи в списке - и так до тех пор, пока Срок действия TTL истекает, или он доходит до конца списка (или пользователь с отвращением сдается).
Длинный список неработающих серверов (ваша ошибка) и большие лимиты повторных попыток подключения TCP / IP (неправильная конфигурация клиента) могут длиться долгое время, прежде чем Клиент действительно найдет рабочий сервер. Слишком короткий TTL означает, что он никогда не дойдет до конца списка, а вместо этого выдает новый DNS-запрос и получает новый список (надеюсь, в другом порядке).
Иногда Клиенту не везет, и новый список все равно начинается с неработающих серверов. Чтобы дать системе наилучшие шансы обеспечить устойчивость клиента, вы должны убедиться, что TTL больше, чем типичный интервал внимания, и чтобы клиент добрался до конца списка.
Как только клиент нашел рабочий сервер, он должен его запомнить, а когда ему нужно будет установить следующее соединение, он не должен повторять поиск (если не истек TTL). Более длительный TTL снижает частоту, с которой пользователи испытывают задержку, пока клиент ищет рабочий сервер, что улучшает работу.
4) DNS TTL вступает в свои права, когда вы хотите вручную изменить записи DNS (например, чтобы удалить долгосрочно сломанный сервер), тогда короткий TTL позволяет этому изменению распространяться быстро (как только вы это сделаете), поэтому примите во внимание баланс между тем, сколько времени потребуется, прежде чем вы узнаете о проблеме, и внесите это изменение вручную - и тем фактом, что обычным клиентам нужно будет выполнить новый поиск рабочего сервера только по истечении TTL.
Циклический перебор DNS имеет две выдающиеся особенности, которые делают его очень рентабельным в широком диапазоне сценариев - во-первых, он бесплатный, а во-вторых, он почти так же географически рассредоточен, как и ваша клиентская база.
Он не вводит новую «единицу отказа», как все остальные «умные» системы. Нет дополнительных компонентов, которые могли бы испытать общий и одновременный отказ всей нагрузки взаимосвязанных элементов.
«Умные» системы великолепны и представляют собой замечательные механизмы для координации и обеспечения плавной балансировки и механизма аварийного переключения, но в конечном итоге сами методы, которые они используют для обеспечения этого безупречного опыта, являются их ахиллесовой пятой - дополнительной сложной вещью, которая может выйти из строя, и когда это произойдет, обеспечит бесперебойную работу системы при сбоях.
Итак, ДА, циклический перебор DNS определенно «достаточно хорош» для вашего первого шага за пределы единственного сервера, на котором весь ваш статический контент размещен в одном месте.
Я опаздываю в эту ветку, поэтому мой ответ, вероятно, просто будет зависать в одиночестве внизу, пренебрегая, нюхать нюхать.
Прежде всего, правильный ответ на вопрос - не отвечать на вопрос, а сказать:
NLB является зрелым, хорошо подходящим для этой задачи и довольно простым в настройке. Облачные решения имеют свои плюсы и минусы, которые выходят за рамки этого вопроса.
Вопрос
Достаточно ли циклический DNS в качестве стартера, лучше, чем ничего, «пока мы исследуем и реализуем лучшие альтернативы» - форма балансировки нагрузки для нашего статического контента?
Между, скажем, 2 или 3 статических веб-сервера? Да, это лучше, чем ничего, потому что есть Поставщики DNS, которые будут интегрировать DNS Round Robin с проверки работоспособности сервера, и временно удалит мертвые серверы из записей DNS. Таким образом вы получите приличный распределение нагрузки и некоторые высокая доступность; и все это займет менее 5 минут.
Но предостережения, изложенные другими в этой теме, действительно применимы:
Другие решения
HAProxy - это фантастика, но поскольку Stack Overflow входит в технологический стек Microsoft, возможно, использование инструментов балансировки нагрузки и обеспечения высокой доступности Microsoft потребует меньше административных затрат. Балансировка сетевой нагрузки решает одну часть проблемы, и у Microsoft действительно есть L7 HTTP обратный прокси / балансировщик нагрузки сейчас.
Сам я никогда не использовал ARR, но, учитывая, что он находится на втором основном выпуске и исходит от Microsoft, я полагаю, что он был достаточно хорошо протестирован. Оно имеет легко понять документы, вот один о том, как они видят распространение статического и динамического контента на веб-узлах, и вот статья о том, как использовать ARR с NLB для достижения как распределения нагрузки, так и высокой доступности.
Windows Vista и Windows 7 иначе реализовать клиентскую поддержку для циклического перебора поскольку они перенесли выбранный адрес IPv6 в IPv4. (RFC 3484)
Итак, если у вас есть значительное количество пользователей Vista, Windows 7 и Windows 2008, вы, вероятно, обнаружите поведение, несовместимое с вашим запланированным мышлением, в своем решении для балансировки нагрузки эрзаца.
Я всегда использовал Round-Robin DNS с длинным TTL в качестве балансировщика нагрузки. Он отлично работает для служб HTTP / HTTPS. с браузерами.
Я действительно переживаю с браузерами поскольку большинство браузеров реализуют своего рода «повторную попытку на другом IP», но я не знаю, как другие библиотеки или программное обеспечение будут обрабатывать решение с несколькими IP.
Когда браузер не получает ответа от одного сервера, он автоматически вызывает следующий IP-адрес, а затем придерживается его (пока он не выйдет из строя ... а затем попробует другой).
Еще в 2007 году я провел следующий тест:
http://roundrobin.test:10080/ping.phpЯ дал ему поработать один час, у меня было много данных. Результаты показали, что для 99,5% попаданий в сокет А, У меня был удар по любому сокету B или C (Конечно, я не отключал их сразу). Браузеры были: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Так что даже несовместимые браузеры справлялись с этим правильно!
По сей день я никогда не тестировал его снова, но, возможно, однажды я настрою новый тест или опубликую код на github, чтобы другие могли его протестировать.
Важная заметка: даже если он работает большую часть времени, он не устраняет того факта, что некоторые запросы воля потерпеть поражение. Я также использую его для запросов POST, так как мое приложение вернет сообщение об ошибке, если оно не работает, чтобы пользователь мог снова отправить данные, и, скорее всего, в этом случае браузер будет использовать другой IP-адрес, и сохранение будет работать . А для статического контента он отлично работает.
Поэтому, если вы работаете с браузерами, используйте Round-Robin DNS для статического или динамического контента, в большинстве случаев все будет в порядке. Серверы также могут отключаться в середине транзакции, и даже с лучшим балансировщиком нагрузки вы не сможете справиться с таким случаем. Для динамического контента вы должны синхронизировать свои сеансы / базу данных / файлы, иначе вы не сможете справиться с этим (но это также верно и для настоящего балансировщика нагрузки).
Дополнительное примечание: вы можете протестировать поведение на своем собственном IP, используя iptables. Например, перед правилом брандмауэра для HTTP-трафика добавьте:
iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT
(где 12.34.56.78 очевидно, ваш IP)
Не использовать DROP, когда он покидает порт фильтрованный, и ваш браузер дождется тайм-аута. Итак, теперь вы можете включить или отключить тот или иной сервер. Самый очевидный тест - отключить сервер A, загрузить страницу, затем включить сервер A и отключить сервер B. Когда вы снова загрузите страницу, вы увидите небольшое ожидание от браузера, затем оно загрузится с сервера. Снова А. В Chrome вы можете подтвердить IP-адрес сервера, посмотрев запрос в сетевой панели. в General вкладка Headers, вы увидите поддельный заголовок с именем Remote Address:. Это IP-адрес, с которого вы получили ответ.
Итак, если вам нужно перейти в режим обслуживания на одном сервере, просто отключите трафик HTTP / HTTPS одним iptables REJECT правило, все запросы будут идти на другие серверы (с одним небольшим ожиданием, почти незаметным для пользователей).
Чтобы кратко ответить на вопрос (достаточно ли циклический DNS для начала, лучше, чем ничего, «пока мы изучаем и внедряем лучшие альтернативы», форма балансировки нагрузки для нашего статического контента?), Я бы сказал, что это является лучше, чем ничего, но вам обязательно стоит продолжить изучение других форм балансировки нагрузки.
Вероятно, это сработает, особенно если у вас может быть несколько IP-адресов на ваших статических ящиках. иметь один IP-адрес для обслуживания статического контента и один IP-адрес для управления машиной. Если после этого коробка выходит из строя, вы можете использовать существующее решение высокой доступности или ручное вмешательство, чтобы перенести IP-адрес отказавшей машины на один из других «членов кластера» или на совершенно новую машину (в зависимости от того, насколько быстро это будет чтобы запустить его).
Однако у такого решения будут небольшие проблемы. Балансировка нагрузки далеко не идеальна, и если вы полагаетесь на ручное вмешательство, у некоторых посетителей могут быть перебои в работе.
Аппаратный балансировщик нагрузки, вероятно, лучше справляется как с распределением нагрузки, так и с обеспечением «времени безотказной работы кластера», чем циклический перебор DNS. С другой стороны, это один (или два, поскольку в идеале у вас есть LB в кластере высокой доступности) аппаратных средств, которые потребуют покупки, питания и охлаждения и (возможно) некоторого времени для ознакомления (если вы еще этого не сделали). есть специальные балансировщики нагрузки).
Я предлагаю вам назначить дополнительный IP-адрес каждому из ваших серверов (в дополнение к статическому IP-адресу, который вы используете, например, для ssh), и перенести его в пул DNS. А затем вы используете какое-то программное обеспечение для переключения этих IP-адресов в случае отказа сервера. Например, Heartbeat или CARP могут это сделать, но есть и другие решения.
Это имеет то преимущество, что для клиентов вашей службы ничего не нужно менять в настройке, и вам не нужно беспокоиться о кешировании DNS или TTL, но вы все равно можете воспользоваться циклической «балансировкой нагрузки» DNS. .
Если бы вы использовали RR DNS для балансировки нагрузки, это было бы хорошо, но это не так. Вы используете его для включения резервного сервера, и в этом случае это не нормально.
Как говорилось в предыдущем посте, вам нужно что-то, чтобы определять сердцебиение и прекращать его, пока оно не вернется.
Хорошая новость заключается в том, что сердцебиение доступно очень дешево, как в коммутаторах, так и в Windows.
Не знаю о других ОС, но я предполагаю, что это тоже есть.
Это действительно зависит от того, о чем вы говорите и сколько серверов вы используете. Когда-то у меня был сайт, который работал на нескольких серверах, и я использовал для этого циклический перебор DNS, в основном из-за моего новичка в то время, и это действительно не было большой проблемой. Это не было большой проблемой, потому что он не разбился. Это была действительно глупая несложная система, поэтому она выдерживала и имела довольно постоянный уровень посещаемости. Если он и разбился из-за пробок, то это было днем, и я легко мог бы это исправить. Я бы сказал, что ваш статический контент достаточно простой, чтобы сам по себе не вызывать сбоев.
Насколько стабильным был ваш сервер, не считая аппаратного сбоя и т. Д.? Насколько "пиковый" у вас трафик этого контента? Если предположить, что Apache или что-то в этом роде, и относительно ровный трафик, он не будет сильно вылетать, и я бы сказал, что циклический перебор «достаточно хорош».
Я уверен, что я проиграю, потому что я не проповедую решение 100% высокой доступности, но это не то, о чем вы просили. Все сводится к тому, что вы готовы принять как решение, а не затраченным усилиям.
Балансировка нагрузки с циклическим перебором работает только тогда, когда вы также контролируете зону DNS, чтобы вы могли изменить список серверов и своевременно передать его мастерам зоны.
Как упоминалось в одном из других ответов, скрытым злом циклического перебора является кеширование DNS, которое может происходить где угодно между вашими серверами и клиентом, что полностью сводит на нет небольшое преимущество этого решения. Даже если для DNS TTL установлено очень низкое значение, у вас мало контроля над тем, как долго кеш DNS-провайдера или даже клиента будет поддерживать активным теперь мертвый IP-адрес.
Это определенно улучшение по сравнению с SPOF, но лишь незначительное. Я бы посмотрел, кто когда-либо размещал ваш сервер, и посмотрел, что они могут предложить, у многих есть какая-то базовая служба балансировки нагрузки, которую они могут предоставить.
Вы также можете иметь один сервер со статическим содержимым, дублированным в S3, и переключаться на S3 CNAME, когда ваш основной выходит из строя. У вас будет такая же задержка, но без дополнительных затрат на сервер.
Я не думаю, что это достаточно хорошее решение, потому что предположим, что у вас сейчас два сервера и вы используете циклический перебор с использованием DNS для каждого IP-адреса сервера. Когда один сервер выходит из строя, DNS-серверы не знают, что он вышел из строя, и будут продолжать обслуживать этот IP-адрес в рамках процесса RR. Тогда 50% вашей аудитории увидят неработающий сайт без javascript или изображений.
Возможно, проще указать общий IP-адрес, который обрабатывается Windows NLB, представляющий два сервера позади. Если вы не используете Linux-сервер для своего статического контента, если я где-то это читал?
При исследовании балансировки нагрузки Windows несколько лет назад я увидел документ, в котором говорилось, что веб-ферма Microsoft была настроена как несколько групп балансировки нагрузки с циклическим перебором DNS между ними. Поскольку в каждом пространстве имен может отвечать несколько DNS-серверов и поскольку балансировка нагрузки Microsoft является самовосстанавливающейся, это обеспечивает как избыточность, так и балансировку нагрузки.
Оборотная сторона: вам нужно как минимум 4 сервера (2 сервера x 2 группы).
Отвечая на комментарий Джеффа к ответу Шофа, есть ли способ циклического перебора DNS между серверами HAProxy?
Он имеет очень незначительное применение, достаточное, чтобы помочь вам, пока вы создадите реальное решение. Как вы и сказали, TTL должно быть достаточно низким. Тем не менее, у этого есть побочное преимущество: вытаскивание проблемного компьютера из DNS, когда на нем есть проблемы. Допустим, у вас есть SvrA, SvrB и SvrC, раздающие ваш контент, и SvrA падает. Вы извлекаете его из DNS, и по прошествии короткого периода времени, определенного вашим низким TTL, резолверы определят другой сервер (SvrB или SvrC), который работает. Вы снова подключаете SvrA к сети и снова помещаете ее в DNS. У одних короткий простой, у других - нет. Не здорово, но работоспособно. Чем больше статических серверов вы добавите в микс, тем меньше вероятность того, что у вас будет отключено большинство групп пользователей.
Вы определенно не получите истинно сбалансированного распределения, которое может обеспечить реальное решение для балансировки нагрузки, из-за топологии Интернета. Я бы по-прежнему смотрел загрузку на всех задействованных серверах.