Dependendo do seu raciocínio para esse tipo de configuração, as possíveis soluções podem mudar. Eu vejo dois motivos que podem estar em jogo aqui:
- Tentando obter alta disponibilidade enquanto prefere servidores de aplicativos, que proporcionam os melhores tempos de resposta (cenário 1)
- Apresentando conteúdo personalizado com base em qual site um usuário está localizado (cenário 2)
Cenário 1
Se você está tentando obter HA e obter os melhores tempos de resposta, você terá um problema devido a todas as solicitações que precisam passar pelo servidor ARR primeiro. Uma maneira de contornar isso seria ter uma ARR em cada site, usar o DNS para direcionar os usuários ao servidor ARR do site e, em seguida, usar o algoritmo de balanceamento de carga "Menor tempo de resposta". Isso teoricamente direcionará os usuários no site 1 para s1.mysite.com, ao mesmo tempo em que fornecerá failover para s2 e s3 se s1 falhar.
No entanto, se um problema de rede estiver causando a indisponibilidade de s1.mysite.com, isso também poderá fazer com que o servidor ARR no site 1 também não esteja disponível. No entanto, ele protegeria você das falhas de aplicativos em s1.mysite.com.
Cenário 2
Não parece estar disponível nada pronto para executar o tipo de roteamento que você deseja realizar. No entanto, existem APIs expostas para permitir que você crie um provedor de reconfiguração personalizada para a reconfiguração de URL. Informações sobre como fazer isso podem ser encontradas Aqui . Você pode usar informações de variáveis de servidor, cabeçalhos de solicitação ou até mesmo parâmetros de string de consulta em conjunto com um provedor de reconfiguração personalizado para executar o tipo de roteamento que deseja alcançar.