Рекомендации по балансировке нагрузки для постоянства

Мы запускаем веб-приложение, обслуживающее веб-API для растущего числа клиентов. Для начала клиенты обычно были домашними, офисными или другими беспроводными сетями, отправляющими фрагментированные http-загрузки в наш API. Теперь мы разобрались с большим количеством мобильных клиентов. Файлы размером от нескольких тысяч до нескольких гигабайт разбиты на более мелкие куски и собраны в нашем API.

Наша текущая балансировка нагрузки выполняется на двух уровнях, сначала мы используем циклический DNS для рекламы нескольких записей A для нашего адреса api.company.com. На каждом IP- адресе мы размещаем Linux LVS: http://www.linuxvirtualserver.org/ , балансировщик нагрузки, который просматривает исходный IP-адрес запроса, чтобы определить, к какому API-серверу передать соединение. Эти блоки LVS настроены с heartbeatd для передачи внешних VIP и IP-адресов внутренних шлюзов друг от друга.

В последнее время мы увидели два новых условия ошибки.

Первая ошибка - это когда клиенты колеблются или переходят с одного LVS на другой, в середине загрузки. Это, в свою очередь, приводит к тому, что наши балансировщики нагрузки теряют постоянное соединение и отправляют трафик на новый сервер API, тем самым разбивая загрузку по частям на два или более серверов. Мы стремились к тому, чтобы значение DNS TTL Round Robin для нашего api.company.com (которое мы установили равным 1 часу) учитывалось нижестоящими серверами имен кэширования, уровнями кэширования ОС и уровнями клиентских приложений. Эта ошибка возникает примерно для 15% наших загрузок.

Вторая ошибка мы видели гораздо реже. Клиент инициирует трафик к блоку LVS и направляется на реальный сервер A за ним. После этого клиент войдет через новый IP-адрес источника, который блок LVS не распознает, тем самым перенаправляя текущий трафик на реальный сервер B также за этим LVS.

Учитывая нашу архитектуру, как описано выше, я хотел бы знать, что люди воспринимают с лучшим подходом, который позволит нам более изящно обрабатывать каждый из описанных выше случаев ошибок?

Изменить 3/5/2010:

Это похоже на то, что нам нужно. Взвешенное хэширование GSLB на IP-адресе источника.

http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674

Каноническое решение этой проблемы - не полагаться на IP-адрес конечного пользователя, а вместо этого использовать балансировщик нагрузки уровня 7 (HTTP / HTTPS) с помощью «Sticky Sessions» через cookie.

Липкие сеансы означают, что балансировщик нагрузки будет всегда направлять данного клиента на один и тот же внутренний сервер. Через cookie означает, что балансировщик нагрузки (который сам по себе является полностью работоспособным устройством HTTP) вставляет cookie (который балансировщик нагрузки создает и управляет автоматически), чтобы запомнить, какой внутренний сервер должен использовать данное HTTP-соединение.

Основным недостатком липких сеансов является то, что нагрузка на сервер beckend может стать несколько неравномерной. Балансировщик нагрузки может справедливо распределять нагрузку только при создании новых подключений, но, учитывая, что существующие подключения могут быть долгоживущими в вашем сценарии, тогда в некоторые периоды времени нагрузка не будет распределяться полностью справедливо.

Практически каждый балансировщик нагрузки уровня 7 должен это делать. В Unix / Linux распространенными примерами являются nginx, HAProxy, Apsis Pound, Apache 2.2 с mod_proxy и многие другие. В Windows 2008+ есть маршрутизация запросов приложений Microsoft. Как приборы, Coyote Point, loadbalancer.org, Kemp и Barracuda распространены в низком пространстве; и F5, Citrix NetScaler и другие в high-end.

У Вилли Тарро, автора HAProxy, есть хороший обзор методов балансировки нагрузки .

О DNS Round Robin:

Мы стремились, чтобы значение TTL Round Robin DNS для нашего api.company.com (которое мы установили равным 1 часу) было выполнено нижестоящими серверами имен кэширования, уровнями кэширования ОС и уровнями клиентских приложений.

Не будет . А DNS Round Robin не очень подходит для балансировки нагрузки . И если ничто иное не убеждает вас, имейте в виду, что современные клиенты могут предпочесть один хост всем остальным из-за совпадения самого длинного префикса. закрепления , поэтому, если мобильный клиент меняет IP-адрес, он может выбрать другой хост RR.

По сути, можно использовать циклический перебор DNS в качестве грубого распределения нагрузки, указав 2 или более записей RR на высокодоступных IP-адресах, которые обрабатываются реальными балансировщиками нагрузки в активной / пассивной или активной / активной HA. И если это то, что вы делаете, то вы могли бы также обслуживать эти записи DNS RR с длинными значениями времени жизни, поскольку соответствующие IP-адреса уже доступны.

Чтобы ответить на ваш вопрос об альтернативах: Вы можете получить сплошную балансировку нагрузки на уровне 7 через HAProxy .

Что касается решения проблем схожести с LVS, я немного не уверен в твердых идеях. Это может быть так просто, как тайм-аут или переполнение. Некоторые мобильные клиенты будут переключать IP-адреса, когда они подключены к сети; возможно это может быть источником твоих бед? Я бы предложил, по крайней мере, распространить гранулярность сродства хотя бы на класс C.