ToFoIn v 1. Reserva de gateways e alternância entre canais externos no FreeBSD

Anotação

Em um artigo anterior, a organização da redundância para gateways da LAN foi considerada. Como solução, foi proposto um script que naquele momento solucionava o problema, mas apresentava várias desvantagens. Depois de algum tempo, acabou eliminando essas deficiências, reescrevendo parcialmente o código e obtendo algo aceitável na saída. Agora podemos dizer que os scripts foram testados o suficiente para serem chamados de estáveis. Para simplificar o entendimento de todo o sistema, os principais pontos para a configuração de serviços secundários (em termos do tópico do artigo) serão parcialmente duplicados abaixo. O motivo é simples - durante esse período, as regras do ipfw também foram reformuladas, o dns passou a viver no AD no Samba4 com um frontend de ligação e registros atualizados com segurança do isc-dhcpd usando kerberos, bem como servidores DNS secundários, como o bind nos gateways, CARP configurado ... Em geral, tornou-se muito mais interessante, mas mais sobre o que e como ele funciona está abaixo. Tudo o que pode ser dado com referências à fonte será projetado de maneira a não produzir essência. O que foi retirado de outros lugares, mas que não está mais disponível, será fornecido aqui com comentários relevantes.

1. Introdução

Portanto, existem duas maneiras de aumentar a imunidade a ruídos do canal de comunicação com o mundo externo por parte do consumidor: backup do gateway e reserva do ponto de conexão. Em outras palavras, no primeiro caso, é configurado um segundo gateway, que será ativado se o primeiro falhar; no segundo caso, um canal de Internet de backup será organizado em caso de problemas com o principal, e quanto mais eles cruzarem, melhor, obviamente. Se o CARP resolver a primeira tarefa do FreeBSD, a segunda, depois de organizar o segundo canal externo, poderá, novamente, ser resolvida de várias maneiras. No mínimo, você pode organizar o balanceamento de tráfego ou alternar entre canais. Devido à grande diferença na largura de banda dos canais externos, a primeira opção não me agradou ; portanto, o principal culpado da publicação foi escrito: ToFoIn - um conjunto de scripts bash que visa solucionar problemas de diagnóstico e mudar para um canal externo em funcionamento. Após o refinamento, pode ser aplicado a n gateways e m canais. A situação é fraca, onde n e m são maiores que 2, mas os scripts abaixo devem trabalhar com grandes valores de n e m, porque Logicamente, o limite não está definido. Em geral, suspeito que, usando esses scripts, é possível resolver uma ampla gama de tarefas, dependendo do status da conexão, limitada, talvez apenas pela imaginação.


Aproximadamente, essa topologia de rede assume da forma mais simples o uso de um conjunto de scripts ToFoIn. Obviamente, os scripts devem funcionar no caso de um único roteador, mas nesse caso, você precisará alterar fortemente o módulo Daemon para remover a dependência da sequência de ações no estado CARP, que simplesmente estará ausente no sistema. A reserva adicional desses e de outros nós depende apenas do grau de importância dos serviços correspondentes.

Metas e objetivos

O objetivo do projeto, como antes, é criar um pacote de software universal e facilmente escalável, focado na identificação de problemas em conexões externas e internas e na mudança automática para conexões viáveis. Em termos gerais, a lógica é a seguinte:

• Existem n "roteadores" com m canais externos em cada um. Além disso, todos os n "roteadores" estão em uma hierarquia estrita e são conectados entre si usando o CARP em todas as interfaces necessárias.
• Um agente trabalha independentemente em cada máquina, cuja tarefa é baseada no status atual do CARP de sua máquina:
  
  • Se fizer backup - detecte e configure a máquina em um roteador que atualmente é o mestre;
  • Se mestre - verifique o status das conexões no momento atual e, se necessário, alterne entre canais externos.

Solução

A rede interna possui o CARP, que fornece gateways de backup e permite que você não altere as configurações de outros dispositivos de rede na rede interna ao trocar de canal.

O dhcpd opera no modo primário - secundário e, em geral, não importa quais outros papéis sua máquina desempenha - a conexão entre o dhcpd ocorre na rede interna, para a qual os roteadores sempre olham.

A ligação mestre é removida no AD, que está oculto na rede local, enquanto os servidores de ligação secundária estão trabalhando nos roteadores de gateway em pé de igualdade.

As regras do ipfw diferem dependendo de qual canal é considerado o canal principal em um determinado momento e são reiniciadas pelo módulo Daemon ao alterar as funções.

Finalmente, sobre os próprios scripts. Agora, os arquivos estão localizados nos diretórios apropriados, funcionam com o usuário e têm um script de início no rc.d. Tarefas que requerem acesso root são resolvidas pelo sudo. Há um script de instalação que leva em consideração a possível presença de uma versão instalada, bem como um arquivo de configurações bastante detalhado. Os módulos são os mesmos com pequenas alterações, algumas quase não mudaram na funcionalidade:

Daemon - como o nome indica - é o processo principal que executa os módulos de teste e comutação em um timer e também monitora o CARP.
Testador - ainda testa comunicações externas usando o comando ping. (se estiver em execução, considera que a máquina possui CARP no estado mestre)
Juiz - com base nos resultados do teste, determina qual canal externo funciona e se a comutação é necessária, realiza a comutação (se estiver em execução, considera que a máquina possui CARP no estado Mestre).
Scout é um novo módulo. Inicia quando o CARP está no estado Backup. É necessário determinar qual dos roteadores restantes é atualmente o principal.
Logger - responsável pelo log de eventos. É necessário que as informações sobre os eventos não sejam duplicadas e a revista seja mais fácil de ler.
Watchdog - é executado dentro do cronograma do crontab. Ele determina os "congelamentos" de todos os módulos e (sempre que possível) tenta resolver os problemas que surgiram. I.e. pregue todo mundo, basta colocar.

Além dos próprios scripts, vale a pena considerar alguns arquivos mais importantes:

Tofoin.conf - um único arquivo de configurações.
Tofoin.log - um único arquivo de log de eventos.
Resultado_ <número interno do canal> é o arquivo de trabalho, os resultados do teste são adicionados aqui, criados em / tmp ao lado de .pid e outros arquivos de trabalho.

Posso responder com prazer as perguntas sobre o funcionamento dos módulos, explicando as soluções nos comentários.

Parte técnica

Equipamento

Comparado com o tempo anterior, os gateways passaram para o P4, receberam 1536 Mb de RAM e três HDs de 40 Gb (espelho + sobressalente). As placas de rede ainda são PCI, as PSUs são normais, naturalmente na presença de um no-break.
O aumento da capacidade está associado ao ferro liberado e a atualizações excessivamente entediantes da fonte, mas principalmente o primeiro. OS FreeBSD 11.1, FS zfs.

Configurações dos componentes do sistema

Software de terceiros

Um pouco sobre ToFoIn

Todo o texto do projeto, juntamente com o script de instalação, está disponível no gitlab .

Sumário

Acabou sendo um conjunto de scripts totalmente funcional e confiável que lida bem com a tarefa de mudar para o canal de trabalho no caso de 2 roteadores com 2 canais de comunicação externos.

Planos

Meus planos para este projeto dizem respeito, talvez, à reescrita do bash para o sh puro, para livrar-se de software desnecessário no servidor. Por outro lado, agora tudo funciona de maneira incrível e eu realmente não estou com vontade de interferir nesse processo. Além disso, mudar para sh é repleto de construções de linguagem mais terríveis necessárias para obter o mesmo resultado.
Quanto ao resto, provavelmente, valeria a pena considerar a melhor implementação dos módulos de teste.

Referências:

← Artigo anterior
→ Página do projeto ToFoIn no gitlab