Eu espero que você possa ajudar. Desde já, obrigado.
Tenho um DNS privado do Azure no Azure conectado a 4 Vnet em 2 regiões. Eu li que posso colocar 2 IPs em um único registro A (Ex. A Record Name sql.midomain.local IP1 192.168.1.1/192.168.2.1).
Eu esperava que, se a VM IP1 fosse desligada, um cliente pudesse resolver para IP2, mas isso não aconteceu. Quando faço um ping para "sql.domain.local" ele sempre resolve para IP1, apesar de esta VM estar desligada.
Preciso disso porque preciso de mais resiliência se a instância SQL1 na região 1 estiver DESLIGADA, o cliente ainda se conectar à VM replicada na região 2. O balanceador de carga interno no Azure suporta isso, mas não quero colocar um IP público ativado meus SQLs para usar o balanceamento de carga externo.
Alguma idéia de como posso chegar a isso?
PD: É importante saber que todas as Vnets podem alcançar-se através do peering de vnet. Posso acessar qualquer VM em qualquer vnet.
Responder1
Eu li que posso colocar 2 IPs em um único registro A
Não, você pode criar vários registros A (ou CNAME, TXT, MX) com o mesmo nome e valores diferentes.
Eu esperava que, se a VM IP1 fosse desligada, um cliente pudesse resolver para IP2, mas isso não aconteceu. Quando faço um ping para "sql.domain.local" ele sempre resolve para IP1, apesar de esta VM estar desligada
Quando vários endereços são apresentados para um determinado nome, o clientedeveexperimente-os por sua vez. Isto é descrito emRFC 1794. Ping é uma ferramenta de diagnóstico de baixo nível; Eu precisaria fazer uma pesquisa significativa para determinar se o comportamento aqui é deliberado, anacrônico ou meramente defeituoso.
Os navegadores funcionam de maneira muito diferente - Round robin DNS (rrDNS) é uma ferramenta muito eficaz para suportar alta disponibilidade para serviços HTTP[s]. Mas isso é porque eles implementam a detecção de falhas commuitotempos limite mais curtos (<1 segundo) do que outros clientes TCP. As configurações TCP padrão na maioria dos sistemas operacionais têm um tempo limite de detecção de falhas de 5 minutos ou mais. Isso também pressupõe que o cliente TCP seja adequadamente compatível com RFC. Pela minha experiência, o Java (ou talvez o código do aplicativo em execução no Java) não lida com a resolução de DNS conforme o esperado.
Uma alternativa cara para fornecer acesso HA para clientes externos é via multicaminhos TCP. IME com 2 provedores diferentes, a detecção/comutação de failover demorava pelo menos 3 minutos e às vezes nem acontecia.
Embora seja uma ótima solução para fornecer alta disponibilidade a clientes externos, eu não usaria o rrDNS como meio de fornecer alta disponibilidade para conexões entre nós dentro de uma determinada infraestrutura.
mas não quero colocar um IP público nos meus SQLs para usar o Balanceamento de Carga Externo
Não expor seus servidores DBMS em um endereço público é sensato. Isso não significa que você não possa conectá-los por outros meios. Na verdade, se você tiver dados transacionais em seu SGBD, então você realmente,REALMENTEprecisa ser capaz de garantir a comunicação entre os nós do banco de dados. Se isso estiver disponível por meio de peering vnet e seu aplicativo não suportar um recurso de cliente HA initrínsico, consulte haproxy ou ProxySQL.
OTOH, você pode descobrir que seu aplicativo é um tanto sensível à latência entre o servidor de aplicativos e o DBMS (por exemplo, se estiver usando ORM trivial). Nesse caso, permitir que um servidor de aplicativos no local 'A' se conecte a um SGBD no local 'B' NÃO será desejável - aqui o rrDNS para pilhas isoladas pode resolver parcialmente o problema, mas você também precisa pensar no gerenciamento de sessões e na replicação de dados durante failover/failback.
Responder2
Quando faço um ping para "sql.domain.local" ele sempre resolve para IP1, apesar de esta VM estar desligada.
Isso é natural porque o sistema operacional armazenará em cache o endereço IP resolvido durante o tempo TTL especificado pelo servidor DNS.
O DNS tem um mecanismo round robin que alterna a resposta cada vez que um cliente pergunta diretamente desse servidor, mas não foi projetado para cenários de failover como o seu. não sei sobre o seu ambiente, mas em geral aconselho o uso de um proxy reverso.