Введение #
Среди четырех типов трансляции сетевых адресов (NAT), поддерживаемых в RELIANOID АЦП, у нас есть Источник NAT (NAT), Динамический NAT (ДНАТ), Прямой возврат сервера (DSR) и DNAT без гражданства. В этой статье мы углубимся в тонкости Direct Server Return (DSR), изучим его архитектуру, преимущества и потенциальные препятствия. Мы также настроим DSR в Relianoid ADC.
DSR — это когда внутренние серверы приложений отвечают непосредственно на запросы клиента после получения и обработки запроса. Но как это работает? Вот как проходит связь между серверами и веб-клиентами.
Коммуникационный поток DSR #
Запрос клиента: Клиент инициирует запрос, например, на доступ к потоковым медиафайлам или отправку данных на серверы приложений через Relianoid ADC.
Взаимодействие с балансировщиком нагрузки: После получения запроса Relianoid не изменяет содержимое запроса, за исключением MAC-адрес назначения. MAC-адрес изменен на адрес внутреннего сервера для обработки запроса. Затем балансировщик нагрузки перенаправляет запрос на соответствующий внутренний сервер на основе установленного алгоритма балансировки нагрузки.
Бэкенд-сервер приложений: После получения запроса внутренний сервер обрабатывает запрос и формирует ответ.
Прямой ответ: Затем внутренний сервер отправляет ответ непосредственно на клиентское устройство, завершая цикл связи.
Важная заметка
- Relianoid обычно отвечает на запросы ARP от имени внутренних серверов, чтобы сохранить исходную связь клиент-сервер. Следовательно, правильная конфигурация ARP имеет решающее значение для обеспечения правильной маршрутизации пакетов.
- Необходимо тщательно спланировать схему IP-адресации, чтобы избежать конфликтов и обеспечить правильную связь между клиентами и внутренними серверами. Обычно мы настраиваем внутренние серверы так, чтобы они имели IP-адреса, аналогичные виртуальному IP-адресу (VIP), используемому фермой L4xNAT, но внутренние серверы могут не объявлять об этом в вызовах ARP, чтобы избежать конфликтов.
Зачем использовать DSR для вашей сетевой инфраструктуры #
DSR стал чрезвычайно важным в современной сетевой инфраструктуре из-за его способности обрабатывать огромные объемы данных, не создавая серьезных узких мест. Вот это большое дело. Помимо масштабируемости, универсальности, высокой доступности и отказоустойчивости, основными причинами, по которым DSR выделяется, являются:
Производительность с турбонаддувом: Устраняя дополнительные переходы, возникающие при использовании традиционных методов маршрутизации, DSR значительно снижает задержку и потерю пакетов. Мы могли бы использовать эту настройку в играх и потоковом видео, где решающее значение имеет эффективная доставка значительных фрагментов данных.
Например, в многопользовательских играх DSR обеспечивает прямую связь между игровыми клиентами и игровыми серверами без балансировщика нагрузки, передающего каждый пакет данных. Эта прямая связь позволяет быстрее и эффективнее передавать данные, связанные с игрой, такие как движения игроков, действия и обновления. В результате DSR уменьшает задержку, улучшает игровой процесс и способствует более плавному игровому процессу.
Точно так же в потоковом видео, когда клиент запрашивает видеопоток, внутренние серверы могут напрямую передавать видеоданные клиенту, не направляя их через балансировщик нагрузки. Удалив балансировщик нагрузки на пути передачи данных, мы минимизируем потенциальные узкие места, обеспечивая бесперебойную работу потоковой передачи для зрителей. Это особенно полезно для видеоконтента высокого качества или высокого разрешения, где эффективная обработка больших фрагментов данных необходима для бесперебойного воспроизведения.
Снижена нагрузка на балансировщик нагрузки: С помощью DSR мы разгружаем балансировщик нагрузки, обрабатывающий обратный трафик с внутреннего сервера. Эта разгрузка значительно снижает нагрузку на балансировщик нагрузки, позволяя ему сосредоточиться на эффективном распределении входящих запросов. В результате балансировщик нагрузки будет обрабатывать больший объем трафика и добиться лучшей общей масштабируемости.
Нет необходимости поддерживать таблицу маршрутизации: Маршрутизация может быть сложной, особенно в крупномасштабных сетях с несколькими подсетями и сложными политиками маршрутизации. Не поддерживая таблицу маршрутизации для обратного трафика, балансировщик нагрузки избавляет от необходимости обрабатывать и управлять сложными конфигурациями маршрутизации, уменьшая вероятность неправильных конфигураций или проблем, связанных с маршрутизацией.
Конфигурации Relianoid для внутренних серверов Linux и Windows #
Чтобы включить DSR, сначала необходимо настроить виртуальный сервер уровня 4 или ферму L4xNAT. Читать этой статья для его создания.
Требования к DSR: #
- виртуальный IP и серверные части должны быть в одной сети.
- Виртуальный порт и внутренние порты должны быть одинаковыми.
- Необходимо настроить бэкэнды петлевой интерфейсы с тем же IP-адресом, что и VIP, настроенный в балансировщике нагрузки, и отключите ARP в этом интерфейсе.
Бэкэнд-серверы Linux #
# ifconfig lo:0 192.168.0.99 маска сети 255.255.255.255 -arp up
Этой командой мы создаем виртуальный сетевой интерфейс вот:0 с IP-адресом 192.168.0.99 и маска подсети 255.255.255.255.
-арп флаг отключает протокол разрешения адресов (ARP) на этом интерфейсе.
Отключение недопустимых ответов ARP в бэкэнде. #
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
Эта команда устанавливает значение arp_ignore равным 1 в /proc/sys/net/ipv4/conf/все файл. Этот параметр определяет, как ядро отвечает на запросы ARP. Установка его в 1 означает, что система должна игнорировать запросы ARP для IP-адресов, не настроенных на сетевом интерфейсе.
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
Эта команда изменяет параметр arp_announce на внутренних серверах. В конфигурациях DSR установка arp_announce на 2 гарантирует, что когда внутренние серверы отвечают на запросы ARP, они используют IP-адрес назначения запроса в качестве исходного IP-адреса в ответе ARP. Это поддерживает надлежащую связь между внутренними серверами и клиентом, поскольку клиент ожидает получить ответ от IP-адреса, на который он отправил запрос.
Бэкэнд-серверы Windows #
- Начать->Настройки->Панель управления->Сеть и коммутируемое соединение.
- Щелкните правой кнопкой мыши сетевой адаптер и выберите Основные свойства.
- Только приблизительно Межсетевой протокол должен быть выбран (отмените выбор «Клиент для сетей MS» и «Общий доступ к файлам и принтерам»)
- Свойства TCP/IP-> Введите IP-адрес VIP в ферме Relianoid ADC. Шлюз по умолчанию не является обязательным. Введите маску 255.255.255.255
- Установите метрику интерфейса на 254. Эта конфигурация необходима, чтобы перестать отвечать на любой ответ ARP на VIP.
- Press OK и сохраните изменения.
После этого настройте модель безопасности хоста для приема трафика от Relianoid ADC на интерфейсе сетевого адаптера. Кроме того, разрешите Relianoid ADC отправлять и получать трафик через интерфейс NIC по умолчанию. Откройте CMD от имени администратора и выполните три предоставленные команды.
netsh интерфейс ipv4 установить интерфейс NIC слабыйhostreceive=включено netsh интерфейс ipv4 установить петлю интерфейса слабыйhostreceive=включено netsh интерфейс ipv4 установить петлю интерфейса слабыйhostsend=включено
Важная заметка
Измените сетевой адаптер и вернитесь к именам интерфейсов по умолчанию вашего компьютера с Windows.
Проблемы использования DSR #
Хотя Direct Server Return (DSR) предлагает множество преимуществ, иногда он может создавать потенциальные проблемы, которые организациям необходимо учитывать и решать. Понимание этих проблем поможет эффективно планировать и внедрять DSR. Вот некоторые распространенные проблемы, связанные с DSR:
Асимметричная маршрутизация: Это означает, что прямой и обратный пути идут по разным маршрутам. Хотя это может иметь свои преимущества, асимметричная маршрутизация может усложнить устранение неполадок и мониторинг сети, поскольку поток трафика несимметричен.
Совместимость с сервером: Не все серверы поддерживают DSR со всеми типами приложений. Например, мы можем выполнять DSR только с серверами Linux или Windows при использовании Relianoid.
Операции с состоянием: Для операций с отслеживанием состояния, которые полагаются на сохранение информации о сеансе, DSR может создавать проблемы. При использовании других типов NAT балансировщики нагрузки обрабатывают все формы сохранения сеанса, но с DSR прямая маршрутизация обходит этих посредников. Один из способов обойти это — использовать исходный IP-адрес на уровне 4 и вставку файлов cookie на уровне 7 для сохранения сеанса.
Видимость и мониторинг сети: DSR может повлиять на видимость и мониторинг сети, поскольку трафик обходит балансировщики нагрузки или обратные прокси-серверы. Инструменты и системы мониторинга, основанные на проверке или перехвате трафика на этих посредниках, могут не отражать полную картину сетевого трафика. Организации могут внедрять альтернативные решения для мониторинга, чтобы обеспечить видимость трафика, проходящего по путям DSR.
Сложность развертывания: Внедрение DSR может привести к дополнительным сложностям во время развертывания и настройки. Надлежащее планирование, проектирование и тестирование имеют решающее значение для обеспечения бесперебойной реализации. Например, может потребоваться настроить каждый внутренний сервер для выполнения разгрузки SSL и ведения журнала.
Соображения безопасности: DSR может вызвать проблемы с безопасностью, особенно когда трафик напрямую обходит меры безопасности, реализованные в балансировщиках нагрузки. Иногда вам может потребоваться изменить детали заголовков ответа, что невозможно при настройках DSR.
Заблаговременно решая эти проблемы, организации могут успешно внедрить DSR и использовать его преимущества, сводя к минимуму потенциальные недостатки.
Заключение #
Direct Server Return (DSR) представляет собой увлекательный подход к балансировке нагрузки, который может обогатить вашу инфраструктуру значительными преимуществами. Разгружая обратный трафик с внутренних серверов и позволяя им отправлять ответы напрямую клиентам, DSR снижает нагрузку на балансировщик нагрузки и улучшает общую масштабируемость системы.
Еще одним преимуществом может быть меньшая задержка в сети, поскольку ответы проходят более прямой путь к клиентам, минуя балансировщик нагрузки. Это может быть особенно выгодно для чувствительных к задержкам приложений, обеспечивая более быструю доставку контента и улучшение взаимодействия с пользователем.
Однако перед внедрением DSR тщательно оцените конкретные требования вашей сетевой архитектуры и потребности приложений. Учитывайте такие факторы, как топология сети, протоколы маршрутизации, необходимость сохранения сеанса и возможные связанные с этим проблемы.
Используя преимущества DSR, вы можете оптимизировать свою инфраструктуру, чтобы справляться с растущими нагрузками трафика и обеспечивать бесперебойную работу пользователей.
