Балансировщик нагрузки Cisco (ACE 4710) может сделать перенаправление в другой домен?

Наши пользователи в настоящее время получают доступ к нашему внутреннему веб-сайту, набрав "наш веб-сайт". Существует запись DNS, которая сопоставляет наш веб-сайт с IP-адресом Cisco ACE 4700. DNS-имя ourwebsite.ourcompany.org также сопоставляется с IP-адресом Cisco ACE 4700.

Мы хотим, чтобы наши пользователи начали использовать ourwebsite.ourcompany.org и отказались от возможности использовать наш веб-сайт. В течение некоторого времени мы хотим, чтобы "наш сайт" продолжал размещать их на нашем сайте.

Мы хотели бы знать, можно ли настроить Cisco ACE 4700 таким образом, чтобы, если пользователь вводит по http://ourwebsite/, он немедленно выполняет перенаправление на http://ourwebsite.ourcompany.org/.

Это возможно? например, через правило перезаписи URL?

Источник

1 ответ

Я знаю, что это старый вопрос (связанный с тем, когда я отвечаю), но я могу сказать, что это то, что Cisco ACE может сделать, используя несколько простых директив конфигурации.

Предположим, ваш сайт настроен с использованием простой конфигурации, подобной этой:

rserver host HOST1
 ip address 1.2.3.4
 inservice
rserver host HOST2
 ip address 5.6.7.8
 inservice

serverfarm host OURWEBSITE
 probe <your-probe>
 rserver HOST1 80
  inservice
 rserver HOST2 80
  inservice

class-map match-all VIP-OURWEBSITE
 match virtual-address 1.1.1.1 tcp eq www

policy-map type loadbalance first-match LB-OURWEBSITE
 class class-default
  serverfarm OURWEBSITE

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  loadbalance vip inservice
  loadbalance policy LB-OURWEBSITE
  loadbalance vip icmp-reply active

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

То, что вы хотите сделать, это сопоставить заголовок хоста, который приходит от клиента - если это "наш веб-сайт", то запрос должен быть отправлен на сервер перенаправления, который принудительно перенаправляет HTTP 30x "ourwebsite.ourcompany.org" на клиент.

rserver redirect REDIRECT-OURWEBSITE
 webhost-redirection http://ourwebsite.ourcompany.org%p 301
 inservice

serverfarm redirect REDIRECT-OURWEBSITE
 rserver REDIRECT-OURWEBSITE
 inservice

Выше настраивает объект перенаправления. В директиве "webhost-redirection" вы заметите%p и 301.%p - это переменная, которая берет путь из запроса клиента и добавляет его в перенаправление - таким образом, если кто-то имеет, скажем, http://ourwebsite/somepage.html закладки, редирект автоматически отправит их на http://ourwebsite.ourcompany.org/somepage.html а не отправит их на страницу со статической настройкой. Это чисто опционально, поэтому, если вы предпочитаете, чтобы они отправлялись на настроенную страницу, а не перенаправлялись автоматически, просто оставьте эту переменную%p и замените ее URL-адресом, на который вы хотите перенаправиться. 301 заставляет перенаправить отправлять HTTP-код 301 - который сообщает запрашивающему клиенту, что страница "навсегда" переместилась на этот новый адрес.

Теперь перейдем к настройке объекта, который соответствует запросам заголовка узла для http://ourwebsite/.

class-map match-all MATCH-OURWEBSITE
 match http header Host header-value "ourwebsite"

policy-map type loadbalance first-match LB-OURWEBSITE
 class MATCH-OURWEBSITE
  serverfarm REDIRECT-OURWEBSITE

Новая карта классов настроит соответствующий класс, который ищет "наш веб-сайт" в заголовке HTTP-хоста. В правилах сопоставления используются простые регулярные выражения, поэтому приведенное выше не будет совпадать с нашим веб-сайтом.ourcompany.org.

Вторая директива выше, из ранее определенной карты политик LB-OURWEBSITE, вставляет новый соответствующий класс в политику балансировки нагрузки. Если единственный класс, который у вас есть в карте политик, это class-default, этот новый класс будет вставлен над ним. Если у вас уже есть один или несколько классов выше class-default, вы можете вставить это правило над любым из них, используя класс MATCH-OURWEBSITE insert-before, и он вставит его выше указанного вами класса.

После того, как все это завершено, обычно рекомендуется циклически выполнять VIP, выполняя vip-вставку без нагрузки, а затем vip-вставку нагрузки в политике обслуживания:

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  no loadbalance vip inservice
  loadbalance vip inservice

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

Полная конфигурация после настройки всего этого будет выглядеть так:

rserver host HOST1
 ip address 1.2.3.4
 inservice
rserver host HOST2
 ip address 5.6.7.8
 inservice
rserver redirect REDIRECT-OURWEBSITE
 webhost-redirection http://ourwebsite.ourcompany.org%p 301
 inservice

serverfarm host OURWEBSITE
 probe <your-probe>
 rserver HOST1 80
  inservice
 rserver HOST2 80
  inservice
serverfarm redirect REDIRECT-OURWEBSITE
 rserver REDIRECT-OURWEBSITE
 inservice

class-map match-all MATCH-OURWEBSITE
 match http header Host header-value "ourwebsite"
class-map match-all VIP-OURWEBSITE
 match virtual-address 1.1.1.1 tcp eq www

policy-map type loadbalance first-match LB-OURWEBSITE
 class MATCH-OURWEBSITE
  serverfarm REDIRECT-OURWEBSITE
 class class-default
  serverfarm OURWEBSITE

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  loadbalance vip inservice
  loadbalance policy LB-OURWEBSITE
  loadbalance vip icmp-reply active

Оттуда, в зависимости от процесса вывода из эксплуатации, вы можете либо через некоторое время отключить запись DNS, либо даже изменить директиву webhost-redirection, чтобы она указывала на страницу, указывающую пользователям прекратить использовать имя хоста для подключения к веб-сайту. Все зависит от вашей политики вывода из эксплуатации.

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

Источник
Другие вопросы по тегам