Cenário:
Estou implementando failover para um nó de rede, então minha ideia é fazer com que o nó mestre receba escuta em um endereço IP e porta broadcast . Se o nó mestre falhar, outro nó de failover começará a escutar neste endereço de broadcast (e porta) e assumir o controle.
Pergunta:
Minha preocupação é que usarei um endereço IP de broadcast apenas para um único nó: o mestre. O nó de failover só liga se o mestre falhar, em outras palavras, quase nunca.
Em termos de sobrecarga de rede / tráfego, é ruim conversar com um nó único através de um endereço de broadcast ou a rede é inteligente o suficiente para saber que mais ninguém está ouvindo esse endereço de broadcast e tipo de tratá-lo como um unicast em termos de sobrecarga?
Minha preocupação é que eu esteja inundando minha rede com pacotes deste endereço de broadcast, mesmo achando que estou realmente falando com um único nó (o mestre). Mas não posso usar o unicast porque o nó de failover precisa ser capaz de captar o fluxo mestre de maneira rápida e transparente no caso de falha.
Parece que você está tentando reinventar o agrupamento / agrupamento de NICs em seu próprio caminho. A maioria dos clusters ativos / passivos compartilha um endereço IP e MAC virtual e, quando uma unidade falha, o secundário assume o endereço MAC compartilhado. Usar um IP de difusão para se comunicar com um cluster não é ortodoxo e quase certamente criará tráfego desnecessário em toda a LAN.
Em geral, é impossível para a rede prever antecipadamente ou estar ciente instantaneamente da falha de um nó.
Portanto, você deve:
Mensagens confiáveis no nível da rede são difíceis e caras de implementar. É por isso que usamos redes mudas de comutação de pacotes e implementamos confiabilidade no nível de transporte. Este é o cenário em que você usa um endereço IP flutuante (e possivelmente MAC) e espera que as tabelas de encaminhamento de cache ARP / gateway do gateway sejam atualizadas.
Mas se é tão importante que você nunca perca um único pacote, você terá que pagar um pouco de eficiência. Se você usa endereços multicast (não broadcast), e seus caminhos redundantes passam por switches que são capazes de snooping IGMP , eles devem ser inteligentes o suficiente para pelo menos não inundar seu LAN inteira. Você ainda precisa de uma maneira de seu nó de backup detectar com segurança uma falha do mestre.
Se você usa streams, em vez de usar seu próprio protocolo confiável ad-hoc em cima do udp multicast, é recomendável consultar SCTP , pois trata de multihoming e pode, com vantagem, substituir o udp ou o tcp.
Sim, a transmissão tem sobrecarga. Quanto mais nós você conectar ao seu switch, mais sobrecarga você terá. Portanto, você só deve enviar broadcast quando realmente quiser alcançar todos os nós e / ou quando estiver tentando descobrir um nó que tenha sido movido para outro local. Transmita uma vez, espere por uma resposta do nó de onde quer que seja, descubra seu novo endereço e, a partir de agora, unicast. Linda, não é? :)
Se você está inundando sua rede depende inteiramente da freqüência e tamanho das transmissões, do tamanho da sub-rede para a qual você está transmitindo, da topologia de sua rede e das capacidades do seu equipamento.
Sem saber que ninguém pode responder à sua pergunta com certeza.
No entanto, o DHCP é um tráfego de difusão e, em uma rede grande, pode ser bastante tagarela. Muitas redes não realizam nenhuma ação especial para gerenciar esse tráfego DHCP - o impacto não é uma preocupação. Estime se a sua transmissão será significativamente maior do que o tráfego de transmissão DHCP existente em sua rede - nesse caso, talvez você precise se preocupar e implementar uma solução diferente para qualquer problema que esteja tendo. Se não, então provavelmente você pode passar para o próximo desafio.
Estou intrigado sobre o que especificamente você está tentando configurar o failover para. Como outros entrevistados sugeriram, há várias opções disponíveis para redundância que você pode usar onde não precisa se preocupar com isso e pode aproveitar a experiência de outras pessoas.
Tags networking failover udp tcpip