domingo, 22 de novembro de 2015

Failover de Servidores DHCP Redundantes no Linux

Olá Pessoal.

É muito comum a utilização de um servidor DHCP no ambiente da empresa para fins de configuração dinâmica dos endereços IP das estações da rede de maneira automática. Uma vez que a implementação de um servidor DHCP é uma tarefa relativamente simples, é comum que muitos administradores acabem por dar menor importância ao seu papel crucial em qualquer rede de médio ou grande porte. É fato que o serviço de configuração automática dos endereços é fundamental para a operação de uma rede, afinal sem endereço IP nenhum host sequer consegue ser membro efetivo da rede.

É por essa simplicidade de configuração que o serviço DHCP acaba recebendo menos atenção do administrador e muitas vezes, talvez na maioria, é implantado através de um único servidor. O problema dessa abordagem tradicional é que um único servidor DHCP acaba se tornando um potencial ponto de falha que pode trazer sérios prejuízos para qualquer rede. Caso o servidor venha a cair, as máquinas que já receberam suas configurações irão mantê-las somente até que o tempo limite de empréstimo seja atingido (lease), por isso muitos administradores contornam esse problema aumentando o tempo de empréstimo. Ocorre que essa estratégia não resolve o problema por completo, uma vez que  novas máquinas não conseguirão localizar um servidor DHCP na rede e, portanto, não serão capazes de configurar automaticamente seus endereços.

No contexto específico de ambientes que possuem servidores baseados no Linux Debian, o serviço ISC-DHCP oferece a capacidade de configuração do recurso de failover através da inserção de dois servidores DHCP redundantes. Para demonstrar o roteiro de instalação de ambos os servidores primário e secundário, tomaremos por base a topologia apresentada na figura abaixo.


1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server em ambos os servidores para que o Linux possa ser posteriormente configurado com o serviço DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em ambos os servidores em qual(is) interface(s) o serviço irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth0"

3. Configuração do Servidor DHCP Primário

Assim como a configuração tradicional de um servidor DHCP, a configuração do failover é relativamente simples. A principal diferença é que será adicionada uma nova declaração denominada "failover peer", onde definiremos a função do servidor (primário ou secundário) e as portas em que ambos os servidores parceiros irão conversar para sincronizar os empréstimos de endereços.

#--- em /etc/dhcp/dhcpd.conf
authoritative;
ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"
{
    primary;                     #define servidor como primário
    address 192.168.221.1;       #endereço do servidor local
    port 647;                    #porta do servidor local
    peer address 192.168.221.2;  #endereço do servidor parceiro
    peer port 647;               #porta do servidor parceiro
    max-response-delay 30;      
    max-unacked-updates 10;     
    load balance max seconds 3;
    mclt 1800;                  
    split 128;                  

subnet 192.168.221.0 netmask 255.255.255.0
{
    option routers 192.168.221.254;
    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";
    pool
    {
        failover peer "NOME";
        range 192.168.221.100 192.168.221.199;
    }
}

Os parâmetros mclt e split somente devem ser configurados no servidor primário. O parâmetro mclt (maximum client lead time) corresponde à extensão do tempo de lease concedido aos clientes no caso de falha do servidor responsável. O parâmetro split é uma métrica que define a proporção de balanceamento de carga entre os dois servidores, podendo variar de 0 (toda a carga no servidor secundário) até 255 (toda a carga no servidor primário), sendo que 128 equivale ao balanceamento simétrico (50/50).

4. Configuração do Servidor DHCP Secundário

A configuração do servidor secundário não é muito diferente da configuração anterior do servidor primário, exceto pelo fato de que informaremos o papel secundário e que algumas informações específicas previamente configuradas no servidor primário agora são omitidas.

#--- em /etc/dhcp/dhcpd.conf

authoritative;
ddns-update-style none;
default-lease-time 3600;
max-lease-time 3600;

failover peer "NOME"
{
    secondary;                   #define servidor como secundário
    address 192.168.221.2;       #endereço do servidor local
    port 647;                    #porta do servidor local
    peer address 192.168.221.1;  #endereço do servidor parceiro
    peer port 647;               #porta do servidor parceiro
    max-response-delay 30;
    max-unacked-updates 10;
    load balance max seconds 3;

subnet 192.168.221.0 netmask 255.255.255.0
{
    option routers 192.168.221.254;
    option domain-name-servers 192.168.221.201, 208.67.222.222;
    option domain-name "nome.com.br";
    pool
    {
        failover peer "NOME";
        range 192.168.221.100 192.168.221.199;
    }
}

Além dos servidores redundantes serem úteis para fins de disponibilidade ao eliminar o ponto único de falha na rede, outra vantagem é que eles fazem um trabalho cooperativo de balanceamento de carga na oferta dos leases para os clientes da rede, dividindo igualmente os empréstimos (se split = 128). Ambos os servidores irão armazenar o registro de todos os leases, além de logar o status dos servidores.

Obs.: É importante estar ciente de que antes da configuração dos servidores primário e secundário, espera-se que ambos estejam com os clocks devidamente sincronizados, uma vez que a referência de tempo é crucial para o serviço DHCP funcionar devidamente. Uma boa opção para manter os relógios dos servidores sincronizados é a implantação do serviço NTP na rede. O leitor encontra mais informações sobre esse assunto em outro artigo do blog, intitulado "A Hora Certa na Internet Brasileira".

Façam seus testes...

Samuel.

domingo, 8 de novembro de 2015

Nova Nomenclatura de Interfaces Previsíveis no Linux

Olá Pessoal

Recentemente, a partir da versão v197 do systemd/udev, o Linux passou a utilizar um novo mecanismo para nomenclatura das interfaces de redes, denominado Predictable Network Interface Names. O objetivo da nova nomenclatura foi solucionar problemas reais decorrentes da generalização dos nomes tradicionais que utilizavam o formato ethX (ethernet), wlanX (wireless), etc.

O problema da nomenclatura tradicional é que as interfaces de mesma natureza recebem seus nomes do kernel de maneira sequencial (no formato eth0, eth1, eth2, etc...) assim que elas são consultadas pelo driver. Ocorre que o mecanismo de comunicação entre o driver e a interface não é previsível, o que implica na possibilidade de alteração nos nomes das interfaces durante o processo de boot de máquinas que tenham múltiplas interfaces de rede em caso de atualização de hardware. Essa situação traz riscos de segurança em ambientes que tenham scripts de firewall que foram baseados nos nomes tradicionais.

Obs.: O leitor pode fazer um teste rápido para verificar essa situação usando um liveCD em máquina que tenha duas interfaces de rede. Repare que a indexação das interfaces ocorre de forma aleatória a cada boot. Em sistemas devidamente instalados os nomes permanecem persistentes depois de atribuídos pelo kernel até que haja alguma alteração de hardware que demande nova reindexação. 

O novo mecanismo de nomenclatura traz suporte nativo a diferentes políticas para nomeação das interfaces de rede, a destacar:

  1. Nomes Indexados via Firmware/BIOS On-Board
  2. Nomes Indexados via Firmware/BIOS PCI Express
  3. Nomes Indexados via Localização Física do Hardware
  4. Nomes Indexados via Endereço Físico (MAC)
  5. Nomes Clássicos Nativos do Kernel (Imprevisíveis)

Todas essas políticas são utilizadas em conjunto, de forma que a primeira política será adotada caso as informações do firmware on-board estejam disponíveis, seguida pela segunda política caso as informações do firmware PCI estejam disponíveis, seguida pela terceira política se disponível, seguida da quinta política caso contrário. A quarta política não é utilizada por padrão, a menos que seja explicitamente configurada pelo administrador. Por exemplo, possíveis nomes de interfaces baseados na primeira, segunda, terceira, quarta e quinta políticas, respectivamente, seriam: eno1, ens1, enp2s0, enx78e7d1ea46da e eth0


Apesar das políticas padrões, as configurações realizadas pelo administrador sempre têm precedência. Ou seja, se o administrador criar links para outras regras udev, por exemplo para utilizar seus próprios nomes personalizados ou mesmo os nomes tradicionais, o novo mecanismo de nomenclatura previsível não será adotado. A nova nomenclatura previsível pode ser desativada, fazendo com que o sistema volte a utilizar os nomes tradicionais, através da simples passagem de uma instrução ao kernel durante o processo de boot. Essa tarefa pode ser realizada adicionando a seguinte linha  no arquivo de configuração do GRUB que fica localizado em /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0

Obs.: Reparem que em distribuições desktop é provável que a opção "quiet splash" esteja presente para que o usuário, durante o processo de boot, não tenha contato direto com as várias informações de inicialização do sistema, sendo que, ao invés disso, o usuário visualiza na tela uma imagem de inicialização (splash). Se for esse o caso, basta adicionar o parâmetro net.ifnames na sequência, depois de um espaço e dentro das aspas.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0"

Para que as alterações no arquivo de configuração do GRUB tenham efeito a partir do próximo boot, é necessário digitar update-grub. Façam seus testes...