Мы начинаем миграцию на кластер IIS для балансировки нагрузки, поддержки аварийного переключения, а также обновлений с нулевым временем простоя.
В настоящее время мы тестируем эту конфигурацию с парой виртуальных машин Windows 2008 R2. В нашем текущем подходе обе виртуальные машины настроены с одним и тем же IP-адресом и привязками в IIS. Другими словами, 192.168.100.88 привязан к обеим виртуальным машинам, и обе виртуальные машины показывают этот адрес в своей IP-конфигурации.
У каждого сервера также есть IP-адрес, не связанный с балансировщиком нагрузки.
Итак, мой вопрос: как проверить узел, прежде чем вывести его в сеть? Например, мы отключаем один узел, чтобы выполнить обновление. Мы хотим протестировать его, прежде чем он вернет контент сервера клиенту. Раньше, когда мы вручную переключались между разными хостами через конфигурацию брандмауэра / сети, у каждого сервера IIS был свой набор IP-адресов, и мы просто меняли файл хостов и очищали кеш DNS. Протестируйте автономный режим. Затем выведите его в онлайн.
Однако ... с конфигурацией балансировки нагрузки оба сервера технически привязаны к одному и тому же IP-адресу (который я понятия не имею, как который работает). Итак, как мне указать в моем браузере именно тот узел, который не включен в балансировщике?
Единственная мысль, которая приходит в голову, - это иметь второй набор IP-адресов для каждого веб-сайта и связывать их (в дополнение к IP-адресу с балансировкой нагрузки) в IIS. Внутреннее тестирование будет использовать второй набор IP-адресов, поскольку они не открываются через брандмауэр для внешних клиентов.
Единственная проблема с этим (кроме дополнительных накладных расходов на дополнительные IP-адреса) заключается в том, что некоторые веб-сайты используют https. И IIS7 может привязать сертификат SSL только к одному IP-адресу.
Итак, как вы тестируете узлы, которые в настоящее время не подключены к кластеру (отключены с помощью диспетчера балансировки сетевой нагрузки)
NLB использует правила порта для определения маршрутов к узлам. Мы настроили наш кластер NLB для маршрутизации нестандартных портов в дополнение к стандартным портам для веб-служб (http / s) и настроили NLB, чтобы всегда маршрутизировать один нестандартный порт на один узел, а затем другой нестандартный порт на другой узел. .
В IIS для каждого узла мы добавили запись файла заголовка хоста для нестандартного порта этого узла. Результат позволяет перейти по конкретному URL-адресу (http://mysite.com:81), а обозначение порта гарантирует, что трафик будет поступать на узел, который вы хотите проверить, на основе правил порта NLB.
Если вас беспокоит безопасность, не открывайте эти нестандартные порты в правилах брандмауэра / NAT, и тогда вы сможете тестировать узлы только из своей внутренней сети.
Результат позволяет вам использовать тот же IP-адрес для тестирования, что и для производства, но зависит от ПОРТА, чтобы указать, на каком узле вы хотите просматривать веб-сайт. Это сохраняет IP-адреса и позволяет обойти требование сертификата SSL о привязке сайта к одному IP-адресу.
Что касается отключения узлов, вместо отключения всего узла отключите только те порты, которые вы используете для производства (80, 443). Балансировщик нагрузки по-прежнему будет маршрутизировать трафик, который поступает на нестандартные порты, позволяя вам протестировать этот узел, в то же время гарантируя, что ваш производственный трафик безопасно перенаправляется на другой узел. Просто снова включите производственные порты, когда убедитесь, что узел активен и работает правильно.
Пример правил порта в NLB:
80 - разделение 50/50 на оба узла (http) 443 - разделение 50/50 на оба узла (https)
81 - всегда идет на узел 1 (http) 451 - всегда идет на узел 1 (https)
82 - всегда идет на узел 2 (http) 452 - всегда идет на узел 2 (https)
Пример URL-адреса для доступа к узлам:
http://mysite.com:81 - Узел 1 http http://mysite.com:82 - Узел 2 http https://mysite.com:451 - Узел 1 https https://mysite.com:452 - Узел 2 https