DNS failover
DNS
/ \
SiteA SiteB
A maioria dos TTLs de failover de DNS será definida para 30 segundos, permitindo uma interrupção máxima de 60 segundos para que um endereço IP de sites pare de ser anunciado aos clientes após o tempo necessário para a sua verificação de serviço ser "ruim". A maioria dos caches DNS obedecerá aos TTLs, outros não. Alguns clientes também podem armazenar em cache os IPs (java!).
Balanceador de carga
LB
/ \
SiteA SiteB
A opção "VIP" à qual você fez referência na postagem de um único balanceador de carga em nuvem (vip) permite que você falhe em sites com mais rapidez, pois você pode mover o tráfego de site para site assim que o serviço é marcado como ruim. Isso adiciona um único ponto de falha.
Balanceadores de carga + failover de DNS
DNS
/ \
LB LB
| \ / |
| X |
| / \ |
SiteA SiteB
Se você tiver dois balanceadores de carga baseados na nuvem (de preferência em sites diferentes ou provedores diferentes) e os enfrentar com o failover de DNS, poderá mover clientes do SiteX para o SiteN assim que uma falha for detectada e também protegida É possível que um balanceador de carga fique inativo, o que deve ser muito menos frequente do que um serviço de área de trabalho virtual hospedado nos links da rede do seu escritório.
Existem outras maneiras de obter o failover no nível da rede com o roteamento BGP e o BGP anycast, se você controlar seus próprios intervalos de IP e tiver roteadores BGP. Isso soa um pouco acima de onde você está mirando?
Para que qualquer failover funcione bem, você precisa de uma verificação completa do serviço de área de trabalho virtual para confirmar se um site está de fato funcionando. Não tenho certeza de até onde você pode verificar uma área de trabalho virtual além da autenticação, a menos que você escreva um cliente realmente bacana. Talvez você também possa fornecer métricas do sistema a partir de seus sites, o que pode ajudar a indicar que um site "passou mal". Estes provavelmente poderiam vir do agrupamento que você está fazendo dentro de um site, já que ele deve ter uma boa idéia sobre o status do serviço.
Além disso, com vários sites, é necessário levar em consideração onde os clientes acabam se conectando. Eles podem alternar sempre que quiserem? É melhor que eles permaneçam no mesmo caminho. É ativo / passivo um caminho melhor para ir? A localização geográfica é um fator importante? Tudo isso é muito específico para o que você está implementando. Sempre teste o que você acha melhor, e sempre teste cada cenário de falha que você possa imaginar.