Round robin как настроить
DNS сервер — это первый узел, который принимает запрос от посетителя и возвращает IP-адрес приложения. После этого браузер посетителя посылает HTTP запрос на сервер приложения и получает ответ. 
IP адрес указывается в A записи домена, например так:
Обычно указывается одна А запись, следовательно DNS всегда возвращает один и тот же IP адрес. Однако существует возможность изменять отдаваемый IP адрес. Это позволяет направлять разных посетителей на разные сервера с одного домена.
Round Robin
DNS позволяет указывать более одного IP адреса в А записях:
В этом случае, разные клиенты будут получать разные IP адреса при обращении к нашему домену. Это позволит распределить нагрузку между несколькими серверами, которые обслуживают приложение. Round Robin предполагает, что IP адреса будут выдаваться по очереди (сначала первый, потом — второй и т.п.). Однако, это нигде не стандартизировано, поэтому не стоит на это полагаться. 
IP адреса доменов кэшируются в локальных DNS’ах. При выходе из строя одного из серверов, будет длительная задержка перед тем, как обновятся все кэши. Поэтому схема Round Robin должна использоваться совместно с механизмами обеспечения отказоустойчивости.
Устанавливайте небольшой ttl для А записей, чтобы иметь возможность быстро их изменять. Оптимальные значения — несколько минут.
Geo DNS
DNS сервера также позволяют отдавать разные IP адреса для клиентов на основе их местоположения. Это очень полезно для сайтов с высоким разбросом географии посетителей.
Допустим у Вас есть существенное количество посетителей из США и Европы, а сервер приложения находится только в Европе. Тогда будет полезно сделать копию сервера в США. При обращении посетителей из США, отправлять их на сервер в США. Из Европы — на сервер в Европе. 
Эту возможность используют при построении CDN.
Bind GeoDNS
Для популярного сервера BIND существует GeoDNS Patch. Он позволяет указывать различные настройки для зон на основе геоданных. В качестве базы геоданных используется Max Mind:
Самое важное
Используйте DNS Round Robin для распределения нагрузки между несколькими серверами. Устанавливайте небольшой ttl, а также ознакомьтесь с балансировкой нагрузки на фронтенды.
В результате неравномерного распределения питания потребителей между трансформаторами подстанции неравномерно распределяется загрузка кабельных линий, питающих те или иные приемники электрической энергии. Из-за этого по ряду потребителей существует превышение норматива по потерям на 1 км кабельной линии. Данные потери считаются нерациональными, но их можно избежать – перераспределить нагрузку между вводами силовых пунктов. Данное распределение должно быть по возможности равномерным. В результате реализации данного мероприятия уменьшаются не только потери в кабельных линиях, питающих конкретный потребитель, но и потери электрической энергии, обусловленные несимметричной загрузкой фаз самой линии.
14. Релейная защита силовых трансформаторов
В релейной защите электроустановок защитные функции возложены на реле, которые служат для подачи импульса на автоматическое отключение элементов электроустановки или сигнала о нарушении нормального режима работы оборудования, участка электроустановки, линии и т. д.
Реле представляет собой аппарат, реагирующий на изменение какой-либо физической величины, например тока, напряжения, давления, температуры.
Планирование процессов
Когда отклонение этой величины оказывается выше допустимого, реле срабатывает и его контакты, замыкаясь или размыкаясь, производят необходимые переключения с помощью подали или отключения напряжения в цепях управления электроустановкой.
К релейной защите предъявляют следующие требования:
селективность (избирательность) — отключение только той минимальной части или элемента установки, которая вызвала нарушение режима;
чувствительность — быстрая реакция на определенные, заранее заданные отклонения от нормальных режимов, иногда самые незначительные;
надежность — безотказная работа в случае отклонения от нормального режима; надежность защиты обеспечивается как правильным выбором схемы и аппаратов, так и правильной эксплуатацией, предусматривающей периодические профилактические проверки и испытания.
Необходимая скорость срабатывания реле определяется проектом в зависимости от характера технологического процесса. Иногда для сведения до минимума ущерба от возникших повреждений релейная защита должна обеспечивать полное отключение в течение сотых долей секунды.
По своему назначению реле разделяют на реле управления и реле защиты.
Реле управления обычно включают непосредственно в электрические цепи и срабатывают они при отклонениях от технологического процесса или изменениях в работе механизмов. Реле защиты включают в электрические цепи через измерительные трансформаторы и только иногда непосредственно. Они срабатывают при неформальных или аварийных режимах работы установки. Реле характеризуется следующими показателями:
уставка — сила тока, напряжение или время, на которые отрегулировано данное реле для его срабатывания; напряжение (или ток) срабатывания — наименьшее или наибольшее значение, при котором реле полностью срабатывает; напряжение (или ток) отпускания — наибольшее значение, при котором реле отключается (возвращается в исходное положение); коэффициент возврата — отношение напряжения (или тока) отпускания к напряжению (или току) срабатывания. По времени срабатывания различают реле мгновенного действия и с выдержкой времени.
15. Режимы работы и регулирование мощности компенсирующих устройств
Задание питающей энергосистемой двух значений входной реактивной мощности, которые могут быть переданы предприятию в режимах наибольшей и наименьшей активных нагрузок системы, соответственно Qs1 и Оэ2 (причем Оэ2 = 0 практически во всех случаях), предопределяет необходимость регулирования потребления реактивной мощности предприятием в течение суток.
Для регулирования потребления реактивной мощности используется автоматическое регулирование возбуждения синхронных машин и регулирование батарей конденсаторов.
Регулирование конденсаторами реактивной мощности может вестись только ступенями путем деления батарей на части. Чем больше число таких ступеней, тем совершеннее регулирование, но тем больше затраты на установку переключателей и защитной аппаратуры. Обычно мощность батарей конденсаторов разделяется на две ступени:
1. базовую QK 6аз, равную реактивной нагрузке предприятия в часы минимума активных нагрузок энергосистемы, включенную постоянно;
2. регулируемую QK per = QKy — QK 6аз, включаемую в часы максимальных активных нагрузок энергосистемы.
Ступенчатое регулирование батарей конденсаторов может производиться как вручную, так и автоматически. Автоматическое регулирование конденсаторных батарей может производиться в функции:
2. тока нагрузки;
3. направления реактивной мощности относительно направления активной мощности;
4. по времени суток.
Рис. 5. Схема влияния установки компенсирующих устройств на параметры режимов электрической сети
Поэтому на напряжении до 1 кВ для коммутации БК обычно применяют контакторы, на напряжении выше 1 кВ — воздушные, элегазовые или вакуумные выключатели. Для устранения переходных процессов при коммутации БК вместо выключателей можно использовать тиристорные ключи, которые позволяют включать конденсаторы в тот момент, когда мгновенное напряжение на конденсаторах равно напряжению сети, и отключать их, когда мгновенное значение тока в конденсаторах равно нулю.
Балансировка сетевой нагрузки
Основная задача кластера балансировки сетевой нагрузки (Network Load Balancing Cluster, NLB) — обеспечение оптимальной загрузки серверов при минимально-необходимом времени отклика прикладных сервисов информационной системы во всех географических точках, где они должны быть доступны пользователям. Балансировка нагрузки достигается путем разгрузки запросов на несколько параллельно-установленных серверов. При этом технологии реализации балансировки могут быть различными.
К приложениям, требующим балансировки, как правило, относят наиболее типовые Web-серверы, серверы электронной почты и DNS-серверы, которые обслуживают сеть Интернет и корпоративные сети организаций. Помимо этого многие прикладные программы и инфраструктурные сервисы также могут поддерживать возможность балансировки, для чего они должны удовлетворять следующим требованиям:
- Согласованность данных на всех параллельно-доступных серверах.
- Целостность асинхронных и длительных по времени транзакций.
- Поддержка приложением системной инфраструктуры балансировки нагрузки.
Согласованность данных — основная проблема, так как все серверы должны выдавать одинаковые ответы пользователям на один и тот же запрос. При этом, если данные изменились на одном сервере, то они должны быть реплицированы на остальные сервера. А в зависимости от требований к времени обновления реплик на серверах технологии реализации согласования данных могут сильно отличаться: от переноса данных оператором системы на диске до организации масштабной системы онлайн-кластеризации и репликации данных (как в поисковых Web-площадках). Фактически, данную задачу должно решать прикладное программное обеспечение, но ни в коем случае не «железо» (зачастую при закупке оборудования предприятием допускается такая ошибка).
Целостность транзакций — одна из наиболее сложных проблем при организации NLB-кластера. В NLB-кластерах возможны ситуации, в которых приложение, начиная работу с одним сервером кластера, завершает её на другом сервере. Очевидно, что необходимо обеспечить целостность данных и корректность завершения транзакции.
Особое значение эта проблема имеет при организации сетей с балансировкой нагрузки и отказоустойчивостью маршрутизаторов и брандмауэров.
Инфраструктура балансировки сетевой нагрузки обеспечивает равномерное распределение заявок пользователей между серверами системы балансировки. Общая схема системы балансировки приведена на рисунке:
Рис.1. Типовая система балансировки сетевой нагрузки
Различают следующие уровни реализации NLB-системы:
- Сетевой уровень. Поддерживается на уровне операционной системы и реализован в Windows Server Network Load Balancing. Суть подхода заключается в логическом объединениии всех интерфейсов серверов под один IP-адрес в сети, при котором серверы договариваются между собой о порядке обслуживания запросов. Существует два способа реализации этого подхода:
- Unicast mode. В случае unicast mode на всех серверах NLB-кластера настраивается один виртуальный MAC-адрес, что позволяет организовать прием пакетов на все интерфейсы кластера. В этом случае узлы кластера не могут обмениваться информацией между собой с использованнием таких интерфейсов.
Round-robin scheduling
Для этого обычно организуется дополнительная административная сеть или сеть доступа к данным, в которую узлы подключаются дополнительными интерфейсами (см. рис.1.).
Планирование NLB-решения предполагает принятия решений по следующим вопросам:
- Количество пользователей и интенсивность запросов, которое влияет на загрузку серверов.
- Географическая распределенность.
- Объем данных.
- Подход к реализации балансировки нагрузки.
- Разработка технологии репликации данных на серверах.
- Требования к отказоустойчивости.
Инструменты для настройки производительности Web-сереров
Индустрия электронной коммерции продолжает развиваться, и сегодня все новые компании начинают общаться со своими клиентами с помощью Web. Высокопроизводительный сайт, способный предоставлять материалы быстро и без сбоев, не только помогает привлекать новых клиентов. Он становится важнейшей предпосылкой успешной деятельности предприятий электронной торговли и повышения их конкурентоспособности. Едва ли потенциальные клиенты когда-нибудь вернутся на раздражающе «тихоходный» узел, где посетитель подолгу ждет реакции на свой запрос, а то и вовсе остается без ответа. Вот почему при планировании инфраструктуры узла Web в любой организации мерам по повышению его производительности следует уделять особое внимание.
Существует несколько способов повышения быстродействия сайта: можно увеличить полосу пропускания, установить высокопроизводительное сетевое оборудование, разработать эффективные приложения для Web, оптимизировать и модернизировать программные и аппаратные компоненты Web-сервера, а также взять на вооружение технологию кэширования в среде Web.
Еще один способ повышения производительности узла Web состоит в том, чтобы увеличить количество Web-серверов и сайтов и размещать на них «зеркальные» копии материалов. Таким образом можно распределить общую нагрузку по всем компонентам системы и сократить время возврата информации при выполнении сервером внутренних процедур обработки клиентских запросов. При этом сохраняются и существующие серверы, поскольку выводить их из эксплуатации и заменять новыми не придется.
Распределение, или выравнивание нагрузок, приходящихся на несколько серверов, позволяет избежать такой ситуации, когда передаваемые по сети Web пакеты лавиной обрушиваются на один сервер, в то время как другие простаивают без дела. Для распределения нагрузки между Web-серверами обычно используется функция DNS, именуемая циклической выборкой (round-robin feature), которая предусматривает возможность круговой передачи IP-адреса любого Web-сервера, составляющего сайт, любому клиенту; в итоге все Web-серверы становятся в равной степени загружены трафиком. Однако этот механизм недостаточно эффективен в тех средах, где возможности аппаратных и программных компонентов отдельных Web-серверов неравнозначны. Понятно, что в среде с распределенной нагрузкой оснащенная двумя 450-мегагерцевыми процессорами Pentium III и памятью емкостью 1 Гбайт система под управлением Windows 2000 Server может взять на себя более тяжелую ношу, нежели система Windows NT Server с одним 300-мегагерцевым процессором Pentium II и 256 Мбайт памяти. Однако с точки зрения процедуры циклической выборки службы DNS между этими системами нет никакой разницы; более того, данная функция «не имеет представления» о доступности того или иного Web-сервера, поскольку не может определить, работоспособен компьютер или вышел из строя.
Не так давно поставщики наладили выпуск систем балансировки нагрузки — программных продуктов, которые выравнивают нагрузку, распределяя ее по нескольким серверам. Кроме того, они повышают отказоустойчивость Web-серверов: в случае отказа одной машины направляют пакеты данных на другой сервер или сайт. Таким образом, время ожидания сокращается, а число необработанных запросов сводится к минимуму. Системы балансировки нагрузки можно использовать как при наличии лишь одного Web-сайта, так и при работе с целым рядом узлов. Получив представление о том, что такое системы балансировки нагрузки и как они работают, можно определить наиболее важные их характеристики, которые следует учитывать при выборе средства выравнивания нагрузки.
Что такое система балансировки нагрузки
Рис.2 Система балансировки для одного сайта.
Система балансировки нагрузки Web-серверов — это инструментальное средство, предназначенное для переадресации клиентских запросов на наименее загруженный или наиболее подходящий Web-сервер из группы машин, на которых хранятся зеркальные копии информационного ресурса. Клиент не подозревает о том, что обращается к целой группе серверов: все они представляются ему в виде некоего единого виртуального сервера. Предположим для примера, что мы обслуживаем один Web-сайт и имеем при этом два Web-сервера: web1.acme.com с IP-адресом 193.168.36.1 и web2.acme.com с IP-адресом 193.168.36.2. Эту конфигурацию иллюстрирует Рисунок 2. Представляя наш сайт пользователям Internet, система балансировки нагрузки использует имя виртуального компьютера (пусть это будет имя www.acme.com), а также виртуальный IP-адрес (VIP-адрес — скажем, 193.168.35.10). Чтобы связать имя виртуальной системы и соответствующий VIP-адрес с двумя нашими Web-серверами, мы должны опубликовать имя системы и ее VIP-адрес на сервере DNS. Система балансировки нагрузок постоянно контролирует нагрузки и степень готовности каждого из Web-серверов. Когда на узел http://www.acme.com/ заглядывает посетитель, его запрос поступает не на один из Web-серверов, а в систему балансировки нагрузки. Эта система и принимает решение о том, на какой сервер направить запрос. При этом она руководствуется такими критериями, как загрузка каждого подопечного сервера, а также соблюдает условия и правила, сформулированные администратором. Затем система балансировки нагрузки направляет запрос клиента соответствующему серверу (как правило, она же направляет ответ сервера клиенту, но это зависит от конкретной реализации).
Системы распределения нагрузки могут к тому же обеспечивать выравнивание нагрузок нескольких Web-сайтов. Напомню читателям, что применение нескольких сайтов позволяет размещать серверы-«дублеры» (зеркальные Web-серверы) ближе к посетителям сайта и сокращать задержки при обмене информацией между сайтом и клиентами. Кроме того, при наличии нескольких Web-сайтов появляется возможность равномерно распределять нагрузку между ними, а также обеспечивать высокую степень их готовности и отказоустойчивость в случае нарушений в работе сайта (будь то по причине сбоев в системе энергоснабжения или из-за потери связи с Internet в вычислительном центре). При наличии нескольких сайтов, как показано на Рисунке 6, все системы балансировки нагрузок на всех сайтах имеют одно общее имя виртуальной системы, но разные VIP-адреса. Так, системе балансировки 1 на сайте 1 в Нью-Йорке присвоено имя виртуальной главной машины http://www.acme.com/ с VIP-адресом 193.168 .35.10. А балансировщик 2 на сайте 2 в Лос-Анджелесе, пользующийся тем же именем виртуальной главной машины, имеет уже другой VIP-адрес — 193.200.1.10. Связи всех систем балансировки с локальными Web-серверами устанавливаются так же, как и в случае с одним сайтом. Наряду с мониторингом нагрузок локальных серверов системы балансировки обмениваются со своими «коллегами» на других сайтах информацией о конфигурации и загрузке; при этом проверяется и степень готовности сайта. В итоге все системы балансировки имеют в своем распоряжении общую картину распределения нагрузок и готовности к работе различных узлов. При наличии нескольких сайтов системы балансировки нагрузок часто параллельно выполняют еще одну задачу: берут на себя роль серверов DNS, обслуживающих имя виртуальной системы. Получив через DNS сигнал от клиента, указавшего данное имя, система балансировки возвращает клиенту VIP-адрес сайта, наиболее подходящего с учетом текущего уровня нагрузки, степени удаленности от клиента и других параметров. Затем клиент автоматически получает доступ к этому узлу.
Рис.3 Система балансировки для нескольких сайтов.
Системы балансировки нагрузок делятся на три категории: аппаратные устройства (hardware appliances), сетевые коммутаторы и программные решения. Системы балансировки на базе аппаратного устройства можно рассматривать как «черный ящик»; обычно это функционирующая под управлением UNIX или фирменной ОС машина с процессором Intel, на которой установлена разработанная поставщиком система балансировки нагрузки. Такие системы соответствуют спецификации Plug and Play (PnP), что облегчает работу администраторов узлов Web. Для реализации систем балансировки на базе сетевых коммутаторов используются коммутаторы второго и третьего уровня. В отличие от аппаратных решений эти системы не предусматривают установки дополнительных устройств, через которые Web-серверы подключаются к коммутатору. Если при организации службы распределения нагрузки в пуле Web-серверов используются программные продукты, то можно обойтись без модификации имеющихся сетевых средств и оборудования.
Программные пакеты устанавливаются на существующих Web-серверах или на специальных серверах выравнивания нагрузки.
Вне зависимости от того, к какой категории относится та или иная система балансировки нагрузки, она выполняет следующие задачи: контроль за нагрузкой и состоянием серверов, правильный выбор сервера, который будет отвечать на запрос клиента, и управление трафиком между клиентом и сервером. Сейчас я подробнее расскажу о каждой из этих функций и о том, как их реализуют средства балансировки.
Мониторинг состояния серверов
Система балансировки нагрузки постоянно отслеживает уровень нагрузки и состояние вверенных ей Web-серверов с тем, чтобы на основании собранной информации в любой момент предоставить клиенту доступ к тому серверу, который сможет наилучшим образом ответить на его запрос. При этом используется два метода контроля: внешний мониторинг и внутренний мониторинг.
При проведении внешнего мониторинга система балансировки нагрузки рассчитывает время отклика сервера, для чего направляет на сервер запрос и замеряет время ответа.
Самая простая техника выполнения внешнего мониторинга сервера предполагает использование ping-тестов по протоколу управления сообщениями Internet Control Message Protocol (ICMP). Эти тесты позволяют системе убедиться в готовности сервера к работе и узнать, сколько времени необходимо для передачи информации с сервера на систему балансировки и обратно. Если система балансировки нагрузки не получает отклика от сервера после нескольких последовательных запросов, считается, что данный сервер недоступен. Как правило, администраторы подключают Web-серверы непосредственно к системе балансировки нагрузки, поэтому если время, затрачиваемое на передачу, слишком велико, система заключает, что сервер работает с большой нагрузкой.
Здесь, однако, надо отметить, что в ходе ping-тестов сервера по протоколу ICMP диагностируется только стек протоколов IP; описанный метод не дает представления о состоянии стека TCP, который используется протоколом передачи гипертекста HTTP. Чтобы убедиться в правильности функционирования стека TCP сервера, средство балансировки нагрузки предпринимает попытку установить соединение по протоколу TCP, для чего требуется осуществить состоящий из трех этапов обмен подтверждающими сообщениями. Делается это так. Сначала средство балансировки нагрузки направляет серверу TCP-пакет, в котором значение бита SYN установлено равным 1. Если после этого система балансировки получает от сервера TCP-пакет, в котором значение бита SYN равно 1, а значение бита ACK тоже установлено равным 1, она направляет серверу второй TCP-пакет со значением бита SYN равным 0 и значением бита ACK равным 1. Если обмен подтверждающими сообщениями завершился успешно, значит, TCP-стек сервера функционирует нормально. По завершении такого обмена средство балансировки нагрузки немедленно разрывает соединение с сервером, чтобы исключить непроизводительное использование его ресурсов. Качество TCP-соединения с сервером оценивается системой по такому показателю, как время, необходимое для выполнения всех трех этапов обмена подтверждающими сообщениями.
Наряду с тестированием стеков протоколов лучшие средства балансировки нагрузки могут обеспечивать мониторинг времени отклика и готовности как самого Web-сервера, так и установленных на нем приложений еще одним способом: на сервер направляется запрос по протоколу HTTP на получение информационных материалов или адреса URL. Пусть именем начальной страницы сервера web1.acme.com будет index.htm. Система балансировки нагрузки на Рисунке 2 может инициировать предусмотренную по протоколу HTTP команду Get, запрашивая тем самым у сервера web1.acme.com содержимое страницы index.htm. Если код возврата, направляемый системе Web-сервером, будет 200, значит, начальная страница на сервере web1.acme.com недоступна. Время отклика определяется системой балансировки нагрузки как время с момента отправки запроса на предоставление информации до момента получения кода возврата.
Однако при том, что внешний мониторинг дает возможность получить о сервере полезную информацию, как метод диагностики он имеет свои недостатки. О таких существенных характеристиках сервера, как состояние центрального процессора, памяти, системной шины, шины ввода/вывода, сетевой интерфейсной платы, а также о ряде важных ресурсов системы и прикладных программ администратор имеет лишь отрывочные сведения или вообще никаких. Подробную информацию о нагрузке сервера может предоставить только внутренний мониторинг. Для его выполнения в системе балансировки нагрузки предусмотрены специальные агенты внутреннего мониторинга, которые устанавливаются на каждом сервере. Агент постоянно контролирует состояние своей «среды обитания» и сообщает о нем средству балансировки. Многие поставщики предлагают инструментальные средства для работы со сценариями, которые позволяют администраторам создавать утилиты внутреннего мониторинга для Web-приложений. Внутренний мониторинг широко применяется в программных системах балансировки, но в аппаратных устройствах и в решениях на базе коммутаторов этот метод диагностики реализуется редко.
Выбор сервера
С учетом информации, полученной в ходе внешнего и внутреннего мониторинга серверов, система балансировки нагрузки может выделить сервер, который способен лучше других справиться с обработкой клиентского запроса. Если рабочие характеристики аппаратных и программных компонентов всех серверов пула равнозначны, можно настроить систему балансировки нагрузки так, чтобы она выделяла сервер для обработки очередного запроса по принципу кругового списка, учитывая при этом состояние сервера. Но если система балансировки управляет как сервером с процессором Pentium III, так и еще одной машиной, на которой установлен процессор Pentium Pro, существует возможность отрегулировать эту систему для работы в другом режиме: более мощному серверу будет доставаться большее число запросов. Иначе говоря, речь идет о том же принципе кругового списка, только с учетом весовых коэффициентов.
Современные системы балансировки нагрузки позволяют администратору определять правила выбора сервера по своему усмотрению. Можно, к примеру, включить в эти правила такие критерии, как коэффициент загрузки ЦП и памяти, число открытых соединений TCP и количество пакетов, поступающих на сетевую интерфейсную плату того или иного сервера.
Формула, по которой система балансировки определяет уровень загруженности серверов, может выглядеть примерно так: (10 * уровень использования ЦП) + (3 * уровень использования памяти) + (6 * число открытых TCP-соединений) + (3* число переданных пакетов) = загрузка сервера. При получении запроса от клиента система балансировки нагрузки рассчитывает по этой формуле нагрузку каждого сервера и направляет запрос серверу с наименьшей нагрузкой.
В некоторых случаях после того, как средство балансировки назначает сервер для выполнения запроса клиента и клиент устанавливает первоначальное соединение, для обеспечения выполнения прикладной программы необходимо, чтобы система балансировки постоянно поддерживала трафик между клиентом и сервером. Такое соединение называется постоянным. Предположим, посетитель электронного книжного магазина выбирает покупку и откладывает в виртуальную корзину три книги. Если сервер, обрабатывающий запрос клиента, кэширует информацию о содержимом корзины локально, система балансировки нагрузки уже не может выделить для последующих обменов с клиентом другой сервер, даже если того требует изменившееся соотношение нагрузок серверов узла. Ведь при такой переадресации данные о содержимом виртуальной корзины клиента будут потеряны, ибо новый сервер попросту не имеет этих сведений. Следовательно, система балансировки должна фиксировать информацию о том, с каким сервером связывается каждый клиент, и хранить ее в памяти в течение определенного времени (время хранения указывает администратор с учетом таких факторов, как обычное поведение клиентов и особенности прикладной программы). При активизации функции постоянных (устойчивых) соединений она будет все время отменять другие правила балансировки нагрузки.
При организации устойчивого соединения основная задача системы состоит в том, чтобы идентифицировать клиента и связать соответствующий идентификатор с сервером-получателем запроса. Как правило, системы балансировки нагрузки используют в качестве идентификатора клиента применяемый им IP-адрес отправителя. Но все дело в том, что адрес отправителя не обязательно совпадает с реальным IP-адресом клиента. Многие компании и провайдеры, стараясь удержать Web-трафик под контролем и скрыть от посторонних глаз IP-адреса своих пользователей, устанавливают серверы-посредники. И в случае, если на наш гипотетический узел Web поступят запросы от 500 клиентов службы America Online (AOL), а также от 10 клиентов, представляющих другую компанию, баланс нагрузок серверов будет нарушен. Система балансировки свяжет 500 клиентов из AOL, имеющих один и тот же адрес отправителя, с одним сервером, а 10 остальных клиентов — с другим.
Round Robin
К счастью, эту проблему можно решить, если воспользоваться системой балансировки нагрузки, оснащенной средствами идентификации IP-адресов отправителей и номеров портов TCP. Подобные системы способны опознавать клиентов даже в том случае, когда последние выходят в Internet через один и тот же proxy-сервер. Такая идентификация возможна потому, что каждое TCP-соединение имеет уникальный IP-адрес отправителя и номер порта TCP. Еще один способ идентификации клиента, проводящего защищенный сеанс связи по протоколу HTTP, состоит в том, чтобы зафиксировать идентификационный номер сеанса связи пользователя по протоколу Secure Sockets Layer (SSL). Протокол SSL назначает каждому установленному сеансу связи специальный идентификатор, а прикладные программы для виртуальных магазинов часто пользуются этим протоколом. Самое современное средство поддержания устойчивых соединений — это распространяемые по сети Web cookie-файлы. Напомню, что эти файлы содержат как сведения о клиенте, так и другие данные (например, о том, с каким сервером клиент связывался в последний раз). Анализ содержимого cookie-файлов помогает системе балансировки нагрузки идентифицировать клиентов и подбирать для них наиболее подходящий сервер. В число поставщиков систем балансировки нагрузки, оснащенных средствами работы с cookie-файлами, входят такие компании, как Alteon WebSystems, ArrowPoint Communications, F5 Networks и Resonate.
Наконец, существует еще один способ выбора сервера — так называемое непосредственное связывание (immediate binding). В соответствии с этим методом системы балансировки нагрузки подбирают сервер для клиента и направляют запрос на него в тот самый момент, когда система получает от клиента пакет TCP SYN. При этом система балансировки выбирает сервер, руководствуясь заданными правилами распределения нагрузки серверов, а также IP-адресом, содержащимся в полученном от клиента пакете TCP SYN. Этот метод обеспечивает высокое быстродействие, но надо сказать, что при его применении система балансировки просто не успевает проанализировать другую информацию: в частности, идентификатор сеанса связи по протоколу SSL, содержимое cookie-файла, адрес URL и данные прикладной программы.
Чтобы получить более подробные сведения о клиенте и, соответственно, точнее выбрать для него сервер, системе балансировки нагрузки требуется время для анализа информации уровня приложения. При выборе сервера по методу отложенного связывания система балансировки нагрузки принимает решение о назначении сервера лишь по завершении трехэтапного обмена подтверждающими сообщениями и после установки соединения между ней и клиентом. Система может учитывать содержимое публикуемых материалов, если исследует информацию уровня прикладной программы до выбора сервера для клиента.
Реклама: настройка переключателя diseqc switch 1.2 позиционера для спутниковых антенн
Источник
Round robin как настроить
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов на просторах рунета Pyatilistnik.org. Продолжаем с вами усовершенствовать свои навыки и знания в сфере системного администрирования. В предыдущей статье мы с вами разобрали основные понятия DNS сервера и его компонентов. Сегодня мы более подробно разберем, одну из его полезнейших вещей, которую очень часто используют, например на RDS фермах, или различных балансировщиках. Речь пойдет про функционал DNS Round Robin, рассмотрим его настройку и его применение.
Теория
Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS. Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).
В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.
Предположим, у меня есть несколько зеркальных веб-сайтов по имени www.gorbunov.pro, расположенных на разных площадках и имеющих IP адреса 20.0.0.1, 30.0.0.1 и 40.0.0.1.
В ответ на рекурсивный запрос клиента об имени www.gorbunov.pro сервер DNS вернет клиенту весь набор записей из зоны:
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока «жив» сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.
Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.
При включенной функции Round robin сервер DNS постоянно «перемешивает» ответы клиентам, поэтому на первый запрос клиента DNS об имени www.gorbunov.pro сервер DNS вернет ответ
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
На второй запрос от клиента или от другого сервера DNS будет возвращен ответ
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1
На третий запрос будет ответ
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
В результате мы получаем динамическую балансировку запросов клиентов между несколькими хостами.
Практика
____________________________________________________________________________________
Проверка работы DNS Round robin
В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.
Что такое DNS Round robin и как он работает-01
Для практической проверки функционала DNS Round robin создаем зону gorbunov.pro и добавляем в нее три записи для хоста www.
Что такое DNS Round robin и как он работает-02
Если вы попробуете теперь “попинговать” хост www.gorbunov.pro, то с удивлением обнаружите, что клиент все время отправляет пакеты на адрес 20.0.0.1 (выделено красным). Понятно, что ответа от хоста нет, но и DNS Round robin не работает!
Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro
Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
Анализ кэша DNS на стороне клиента дает следующий результат:
C:\>ipconfig /displaydns
Windows IP Configuration
www.gorbunov.pro
—————————————-
Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 20.0.0.1
Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 30.0.0.1
Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 40.0.0.1
C:\>
Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.
Сброс кэша командой ipconfig / flushdns и новая команда
ping www.gorbunov.pro приводят, наконец к желаемому результату.C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
C:\>ping www.gorbunov.pro –n 1
Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.
Теперь ясно, что для правильной работы DNS Round robin потребуется изменение параметров кэширования, чтобы клиенты постоянно получали обновленный список с “перемешанными” записями.
Настройка времени кэширования ответов DNS
Возможные варианты:
постоянный сброс кэша на стороне клиента (плохой вариант);
установка времени кэширования, равное нулю, в свойствах зоны (плохой вариант, поскольку влияет на всю зону);
установка индивидуального времени кэширования на отдельных записях (хороший вариант).
Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.
Что такое DNS Round robin и как он работает-03
Проверка работы дает в конце концов желаемый результат!
C:\>ping www.gorbunov.pro –n 1
Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro –n 1
Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.
Ping statistics for 30.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping www.gorbunov.pro –n 1
Pinging www.gorbunov.pro [40.0.0.1] with 32 bytes of data:
Request timed out.
Ping statistics for 40.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Файл зоны на сервере DNS при этом будет выглядеть так:
;
; Database file gorbunov.pro.dns for gorbunov.pro zone.
; Zone version: 7
;
@ IN SOA dc01.contoso.com. hostmaster.contoso.com. (
7 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL
www 0 A 20.0.0.1
0 A 30.0.0.1
0 A 40.0.0.1
Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.
В настройках сервера DNS по умолчанию включена и опция Enable netmask ordering. Смысл опции заключаются в том, что при наличии нескольких IP адресов для одного и того же имени хоста сервер DNS анализирует из какой сети пришел запрос от клиента. Если IP сеть клиента совпадает с номером сети одного из IP адресов хоста, то такой IP всегда возвращается первым. Проще говоря, если в нашем примере клиент с адресом 30.67.98.123 будет запрашивать имя www.gorbunov.pro, то ему всегда первым в списке будет возвращаться адрес 30.0.0.1. В серверах Windows опция Enable netmask ordering перебивает опцию Enable round robin. Т.е. клиентам DNS первым всегда возвращается адрес ближайшего хоста, даже несмотря на правильно настроенную функцию DNS Round robin.
Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.
Источник
Балансировка нагрузки с помощью round robin DNS
Управление ответами DNS (т. е. списком возвращенных IP-адресов) – хороший, хотя и очень противоречивый метод распространения приложения. Если вы хотите сократить расходы на оборудование и инфраструктуру, DNS может обеспечить высокую доступность.
Данное руководство поможет создать географически распределенное, высокодоступное приложение с минимальным простоем с помощью DNS.
Высокая доступность
Если от приложения зависит ваш бизнес, вы должны поддерживать его работу 24 часа в сутки 7 дней в неделю, без сбоев и простоя. К сожалению, горизонтальное масштабирование не всегда помогает избежать простоя (особенно если сбой произошел в центре обработки данных).
Разместив виртуальные серверы в разных центрах обработки в разных регионах, вы можете обеспечить более стабильную работу приложения.
Высокая доступность – это качество, присущее структурам, в которых нет единой точки отказа.
Примечание: Вы можете подключить плавающие IP-адреса. Плавающий IP-адрес – это общедоступный статический IP-адрес, который можно мгновенно присвоить другому серверу. Подробнее об этой функции читайте в статье Использование плавающих IP-адресов.
Структура развертывания высокодоступного приложения
Структура развертывания высокодоступного приложения зависит от обслуживания запросов из разных центров обработки данных.
Существует много способов реализации такой структуры, но проще всего, пожалуй, просто воспользоваться преимуществами DNS.
Базовая структура выглядит так:
________________
| |
| CLIENT |
| WEB BROWSER |
|________________|
||
||
_______\/_______
| |
| DNS SERVER |
|________________|
||
||
_______/ \_______
/ \
/ \
____________________ ____________________
| | | |
| SAN FRANCISCO | | SAN FRANCISCO |
|____________________| |____________________|
| ______________ | | ______________ |
| | | | | | | |
| | WEB SERVER | | | | WEB SERVER | |
| | LOAD BALANCE | | | | LOAD BALANCE | |
| | PROXY | | | | PROXY | |
| |_____ _____| | | |_____ _____| |
|________| |________| |________| |________|
|| __ __ ||
|| ||
\/ \/ \/ \/
____________________ ____________________
| | | |
| SAN FRANCISCO | | NEW YORK |
|____________________| |____________________|
| ______________ | | ______________ |
| | | | | | | |
| | APP SERVER | | | | APP SERVER | |
| |______ ______| | | |______ ______| |
| ______||______ | | ______||______ |
| | | | | | | |
| | DATABASE | | DATABASE | |
| |______________| | | |______________| |
|____________________| |____________________|
Высокая доступность с помощью DNS
Когда пользователь вводит доменное имя веб-сайта, с помощью набора определенных правил (то есть протокола), веб-браузер подключается к серверам имен и запрашивает адреса машин, на которых размещен указанный веб-сайт. Получив IP-адрес, он отправляет запрос с некоторыми дополнительными данными на этот компьютер и отображает ответ.
DNS позволяет поддерживать несколько записей (даже одного вида), благодаря чему становится возможным перечислить несколько хостов.
Представьте ситуацию (как показано на приведенной выше схеме): вы указываете IP-адрес двух балансировщиков нагрузки или обратных прокси-серверов, расположенных в двух разных ЦОД, каждый из которых настроен для балансировки нагрузки между серверами приложений, которые также расположены в разных местах. Если один из центров обработки данных становится недоступным, веб-браузер клиента попытается использовать следующие записи IP-адресов, возвращаемые DNS-сервером, и повторить процесс для получения доступа к сайту.
Такая технология балансировки нагрузки называется round robin DNS.
На первый взгляд такая технология может показаться сложной. Попробуем подвести итоги:
- DNS может содержать несколько записей для одного и того же домена.
- DNS может возвращать список IP-адресов для одного и того же домена.
- Когда веб-браузер запрашивает сайт, он будет пробовать эти IP-адреса один за другим, пока не получит ответ.
- Эти IP-адреса должны указывать на не серверы приложений, а на балансировщики нагрузки или обратные прокси-серверы.
- Обратные прокси должны распределять нагрузку между несколькими серверами в разных ЦОД.
- Если центр обработки данных не работает и веб-браузер не может получить ответ от IP-адреса (то есть от балансировщика нагрузки), он попытается подключиться к другому адресу.
- Скорее всего, второй балансировщик нагрузки вернет ответ на запрос клиента (вероятность того, что в разных ЦОД одновременно случится сбой, очень мала).
- Серверы баз данных должны поддерживать репликацию.
Развертывание высокодоступного приложения
Примечание: Описанная ниже процедура не зависит от языка программирования или типа веб-сервера. Следуя этим инструкциям, вы можете достичь высокой доступности вне зависимости от фреймворка, веб-сервера или HTTP-сервера.
Настройка балансировки нагрузки или обратного прокси-сервера
Сначала нужно обеспечить балансировку нагрузки. Для этого подготовьте два (или больше) балансировщика нагрузки, которые смогут взаимодействовать с серверами приложений.
Создайте два сервера в двух разных ЦОД.
Чтобы обеспечить распределение нагрузки, установите Nginx, Apache или HAProxy.
Читайте также:
Узнайте IP-адрес балансировщиков.
Настройте записи DNS.
Запись A преобразовывает домен (например www.example.com) в понятный машине IP-адрес.
Настроив два балансировщика, создайте две записи А.
Обычно это можно сделать с помощью панели управления во вкладке DNS.
После этого настройте серверы приложений. Вам понадобится два сервера в разных ЦОД.
Затем нужно настроить балансировщики нагрузки для распределения и проксирования запросов между серверами приложения. Это можно сделать с помощью этих руководств:
Затем нужно настроить базу данных.
В зависимости от выбранного вами сервера базы данных выполните одно из предложенных руководств на сервере БД и настройте репликацию.
Источник