Назад | Перейти на главную страницу

Перенаправление HTTP-запроса с прямым возвратом сервера

У меня есть серверы, расположенные в нескольких центрах обработки данных, каждый из которых хранит разные файлы. Я хочу, чтобы пользователи могли получать доступ к файлам на всех серверах через один домен и чтобы отдельные серверы возвращали файлы непосредственно пользователям.

Ниже показан простой пример: 1) Браузер пользователя запрашивает http://www.example.com/files/file1.zip 2) Запрос поступает на сервер A на основе записи A DNS для example.com. 3) Сервер A анализирует запрос и выясняет, что /files/file1.zip хранится на сервере B. 4) Сервер A перенаправляет запрос на сервер B. 5) Сервер B возвращает file1.zip непосредственно пользователю, не проходя через сервер. А.

Примечание: шаги 4 и 5 должны быть прозрачными для пользователя и не могут включать отправку перенаправления пользователю, поскольку это нарушит требования одного домена.

Согласно моему исследованию, то, что я хочу достичь, называется «Прямой возврат сервера», и это обычная установка для балансировки нагрузки. Его также иногда называют полуобратным прокси.

Для шага 4 мне нужно выполнить трансляцию MAC-адресов, а затем передать запрос обратно в сеть, а для серверов за пределами сети сервера потребуется туннелирование.

Для шага 5 мне просто нужно настроить сервер B в соответствии с реальными серверами в настройке балансировки нагрузки. А именно, сервер B должен иметь IP-адрес сервера A на интерфейсе обратной связи, и он не должен отвечать ни на какие запросы ARP для этого IP-адреса.

Моя проблема в том, как на самом деле достичь шага 4?

Я нашел множество оборудования и программного обеспечения, которое может сделать это для простой балансировки нагрузки на уровне 4, но эти решения не справляются и не могут справиться с необходимой мне настраиваемой маршрутизацией. Похоже, мне нужно будет накатить собственное решение.

В идеале я хотел бы выполнять маршрутизацию / пересылку на уровне веб-сервера, то есть на PHP или C # / ASP.net. Однако я готов сделать это на более низком уровне, таком как Apache или IIS, или даже на более низком уровне, то есть настраиваемой прокси-службе перед всем.

Спасибо.

Даниэль, вы, вероятно, могли бы сделать это с помощью LVS и кластерной файловой системы относительно легко. Ваши балансировщики нагрузки LVS будут получать HTTP-запросы и перенаправлять запросы на веб-узел, который может ответить на запрос. Ответ будет исходить непосредственно от веб-узла, и балансировщик нагрузки вообще не будет участвовать в ответе.

Я собрал руководство для этого (в Fedora), который хорошо работает на виртуализированных экземплярах Xen.

Дэниел, ты действительно сделал домашнее задание. Может быть, есть Гуру, чтобы доказать, что я ошибаюсь, но мой первоначальный ответ - «не делай этого». Я знаю, что это своего рода отказ, но без каких-либо рассуждений относительно Зачем тебе это действительно нужно, это лучший ответ, который у меня есть. Хотя я думаю, что предложенное решение может сработать, требуется много настроек и настроек, которые нужно обрабатывать только для того, чтобы скрыть домен - мне оно кажется слишком хрупким и сложным.

Я бы предложил либо:

  • Поиграйте в жесткие переговоры и откажитесь от требования единого домена. Действительно объясните, насколько это увеличивает сложность и стоимость. Затем используйте простые HTTP-перенаправления на каждый сервер / сайт.
  • ИЛИ
  • Реплицируйте все данные во все центры обработки данных (DC) для обеспечения избыточности. Использовать Anycast чтобы сделать один домен доступным на нескольких контроллерах домена. Используйте обычный балансировщик нагрузки по вашему выбору на каждом DC.

HTH

Я думаю, для достижения своей цели вам следует использовать либо кеширующий прокси-сервер, либо перенаправления HTTP.

Например, с nginx вы можете использовать бэкэнд (скрипт PHP или какой-либо сервер, размещенный на FastCGI), чтобы определить, в какой «центр обработки данных» вам следует перейти, вернуть X-Accel-Redirect в новое место с proxy_pass в этот центр обработки данных. После этого nginx должен кэшировать / сохранять ваш результат.

Таким образом, ваша конфигурация в каждом центре обработки данных будет отличаться только для файлов, которые на 100% являются локальными.

Второй случай - бэкэнд возвращает код ошибки 301 с необходимой прямой ссылкой.

Любой коммерческий балансировщик нагрузки можно настроить для прямого возврата с сервера. (F5 BIG-IP может это сделать; в их терминологии это называется «маршрутизация nPath».) Недорогое решение - Linux Virtual Server. Задокументирована настройка Direct Routing. Вот.

Однако загвоздка в том, что для прозрачности балансировки нагрузки для уровня 3 пересылка должна выполняться на уровне 2. Это означает, что балансировщик нагрузки и серверы содержимого должны находиться в одном физическом сегменте. Я не уверен, как бы вы это сделали в нескольких центрах обработки данных.

В качестве альтернативы вы можете выполнить HTTP-перенаправление страницы, содержащей приложение Flash. Тогда у вас будут независимые сайты, каждый из которых удовлетворяет принципу одинакового происхождения.

Комбинация Linux Virtual Server и keepalived и, возможно, некоторая искусная магия должна достичь того, что вы ищете. Я широко использовал этот метод в прошлом, и он оказался очень масштабируемым. Тот факт, что реальные серверы разговаривают с клиентом после получения соединений, делает балансировщик нагрузки (LVS + Keepalived) очень масштабируемым.

Уловка состоит в том, чтобы получить правильные аргументы. В Red Hat / CentOS пакет называется arptables_jf. Вот несколько примеров правил, которые можно разместить на сервере B из вашего примера, предполагая, что 10.10.0.1 - это ваш VIP, а 10.10.0.10 - IP-адрес сервера B:

arptables -A IN -d 10.10.0.1 -j DROP 
arptables -A OUT -s 10.10.0.1 -j mangle --mangle-ip-s 10.10.0.10

Обратите внимание, что ваш балансировщик нагрузки (Сервер A) и реальный сервер (ы) (Сервер B +) должны находиться в одной сети.

Вам также необходимо настроить каждый реальный сервер с «фиктивным» интерфейсом с IP-адресом VIP. Опять же, в Red Hat / CentOS:

# cat /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
BOOTPROTO=static
IPADDR=10.10.0.1
NETMASK=255.255.255.255
ONBOOT=yes
TYPE=Ethernet

Правила arptable будут обрабатывать отключение запросов ARP для этого IP (без arptables все реальные серверы и балансировщик нагрузки ответят на вопрос: у кого 10.10.0.1).

Надеюсь, это поможет!

Выполнение DSR через arp mangling и некоторые другие уловки работают на локальном уровне - если вы хотите расширить это до нескольких, назовем их «подчиненными» центрами обработки данных - вам нужно будет инкапсулировать пакеты и отправить их в другой ящик по адресу удаленный контроллер домена для удаления инкапсуляции - это могут быть ваши узлы по отдельности или это может быть другой экземпляр балансировщика нагрузки, выполняющий обычный DSR на основе arp.

Если вы делаете это на нескольких контроллерах домена, вам также необходимо убедиться, что их фильтрация разрешает исходящий трафик с IP-адресов, которыми они не управляют, и что любые устройства брандмауэра, которые могут быть основаны на потоке, не будут вмешиваться - поскольку они будут видеть только одну сторону разговора (другая сторона входит в капсулу)

Просто дополнение - не могли бы вы рассказать, зачем вам нужна именно эта установка? Чего именно вы пытаетесь достичь, используя перенаправления или несколько доменных имен? Если несколько доменных имен подходят для фактических файлов ресурсов - решение CDN или Anycast было бы гораздо более экономичным и надежным решением - позвольте логике вашего приложения определять, на какой ресурс перенаправлять пользователей.

То, что вы предлагаете, технически интересно, но это также создает единую точку отказа - если вам трудно понять это на локальном уровне 2-го уровня с помощью спуфинга arp, то обработка этого на глобальном уровне будет только более сложный .... CDN - это наверное что вам нужно.

Тем не менее - с чисто сетевой точки зрения это действительно интересно - если вы можете предоставить более подробную информацию, я, вероятно, смогу разработать конкретное решение с использованием инструментов Linux, которые будут делать то, что вы просите, - звучит весело.

Я не могу отказаться от требования «один и тот же домен» и не хотите переходить на расширенный сетевой маршрут, может быть, вы можете отказаться от требования «хранить разные файлы в разных местах»?

Если вы можете заставить все серверы (местоположения) хранить все файлы, вы можете иметь идентично настроенные стеки за циклическим IP за одним доменом. Каждое местоположение будет полностью доступным и доступным за одним доменом. Разумеется, любое действие с базой данных по-прежнему требует репликации или удаленного подключения.

Я делаю различие между серверами и местоположениями, потому что обратное проксирование по высокоскоростной локальной сети с низкой задержкой не так уж и плохо (см. Ответ Йорика).

Как насчет маршрутизации запросов приложений?

http://www.iis.net/download/ApplicationRequestRouting

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

Даниэль,

Обходной путь для этого должен быть на уровне приложения. Если вы сделаете это на нижних уровнях, правила станут применимы ко всему трафику, а здесь это приложение к конкретному приложению.

Я бы посоветовал вам создать поддомены и указать IP-адреса разных серверов в качестве записи A на поддоменах. Поэтому, поскольку он находится в том же домене, о сделке третьей стороны позаботятся. Затем используйте базу данных на центральном сервере и сделайте запросы CURL к определенным серверам. Таким образом, ваш домен также будет скрыт, пока ваше приложение работает. Однако единственная проблема здесь в том, что база данных всегда должна быть без пятен. В противном случае ваше приложение провалится с треском.

Следите за тем, чтобы база данных работала постоянно и эффективно. Вам, вероятно, следует подумать о создании резервного банка данных, чтобы вам не пришлось сталкиваться с проблемами простоя сервера.

С уважением
Бинаек Саркар
Фонд