Я создаю приложение, в котором у меня есть XX клиентов, которые могут работать на одном экземпляре. Приложение масштабируется за счет добавления дополнительных узлов (таким образом поддерживая на XX больше клиентов). Мне нужен способ использовать один IP-адрес, чтобы клиенты могли настроить CNAME для использования своих собственных URL-адресов.
Мне также нужна возможность переносить клиентов на разные узлы, что означает, что CNAME должен указывать на другой IP-адрес.
Я думал, что могу указать всем на один IP-адрес, а затем заставить это приложение направлять запросы клиентов на разные серверные узлы. Это похоже на то, что делал бы балансировщик нагрузки (из моих исследований), но для всего, что я хочу сделать, это кажется немного излишним.
Я бы предпочел сделать это в .NET, но я открыт для любой технологии для достижения цели.
Это похоже на работу для Ферма серверов IIS. Обратите внимание, что со стороны .NET вам нужно будет разработать приложение для правильной обработки состояния и других функций. У ваших клиентов будут странные проблемы, если / когда сработает балансировка нагрузки или отработка отказа.
Вы определенно хотите, чтобы Windows Server / IIS выполняла кластеризацию за вас, в основном потому, что Microsoft уже проделала большую работу по обеспечению работы кластеризации на уровне приложений.
Вы могли бы сделать это в .NET, но я думаю, что у вас все еще будет какая-то служба типа DNS.
Я предлагаю создать внутренний DNS, который разрешает IP-адреса ваших внутренних сельскохозяйственных машин.
Настройте свои привязки в IIS7, чтобы они отвечали на все URL-адреса, созданные клиентом, и создайте псевдоним общедоступного DNS-сервера для каждого отдельного IP-адреса в вашем интерфейсе.
Как только ваш интерфейсный сервер поражен, извлеките используемое имя хоста из переменных HTTP, а затем используйте свой внутренний DNS, чтобы найти, на каком IP-адресе работает фактическая служба.
Как только вы знаете IP, это просто случай перенаправления всех коммуникаций на этот IP.
Вы нигде не упомянули об использовании HTTP, но вы отметили вопросы как «веб-приложения» и «веб-ферма», поэтому я предполагаю, что это то, что использует ваше приложение; если это ваш случай, то это похоже на конкретный тип работы обратный прокси существует для.
Вы настраиваете N внутренних серверов, каждый из которых работает на своем собственном внутреннем IP-адресе, и настраиваете IIS (или любой другой веб-сервер, который вы используете) на каждом сервере для обработки имен веб-сайтов, на которые сервер будет отвечать.
Затем вы даете обратному прокси-серверу внутренний IP-адрес, который может взаимодействовать с внутренним сервером, и внешний общедоступный IP-адрес.
Затем вы заставляете все общедоступные DNS-имена указывать на внешний адрес обратного прокси-сервера.
Наконец, вы настраиваете обратный прокси-сервер таким образом, чтобы запросы для данного имени веб-сайта перенаправлялись на внутренний веб-сервер, на котором он фактически размещен.
И вуаля.
Я точно знаю, что и ISA Server 2006, и ForeFront TMG 2010 могут сделать это легко, но, конечно, вы можете использовать любое программное обеспечение обратного прокси, какое захотите.
Конечно, вы можете использовать массив обратных прокси-серверов с балансировкой нагрузки для обеспечения высокой доступности и балансировки нагрузки.
Я бы использовал HAProxy loadbalancer для выполнения этой задачи. Это решение для Linux, но оно может легко балансировать нагрузку HTTP- или TCP-запросов.