Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Visão geral do cluster do chassi

Um cluster de chassi oferece alta disponibilidade em firewalls da Série SRX, onde dois dispositivos operam como um único dispositivo. O cluster do chassi inclui a sincronização de arquivos de configuração e os estados dinâmicos de sessão de tempo de execução entre os firewalls da Série SRX, que fazem parte da configuração do cluster do chassi.

Visão geral do cluster do chassi

O Junos OS oferece alta disponibilidade no firewall da Série SRX usando clusters de chassi. Os firewalls da Série SRX podem ser configurados para operar no modo cluster, onde um par de dispositivos pode ser conectado em conjunto e configurado para operar como um único nó, fornecendo redundância de dispositivo, interface e nível de serviço.

Para os firewalls da Série SRX, que atuam como firewalls stateful, é importante preservar o estado do tráfego entre dois dispositivos. Em uma configuração de cluster de chassi, em caso de falha, a persistência da sessão é necessária para que as sessões estabelecidas não sejam descartadas mesmo que o dispositivo com falha esteja encaminhando tráfego.

Quando configurados como um cluster de chassi, os dois nós recuam entre si, com um nó atuando como o dispositivo principal e o outro como dispositivo secundário, garantindo falhas stateful de processos e serviços em caso de falha no sistema ou hardware. Se o dispositivo primário falhar, o dispositivo secundário assume o processamento do tráfego. Os nós de cluster são conectados em conjunto com dois links chamados link de controle e enlace de malha e dispositivos em um cluster de chassi sincronizam os estados de configuração, kernel e sessão de PFE em todo o cluster para facilitar a alta disponibilidade, failover de serviços stateful e balanceamento de carga.

Não é necessária uma licença separada para habilitar o cluster do chassi. No entanto, alguns recursos de software do Junos OS exigem uma licença para ativar o recurso. Para obter mais informações, veja Entendendo os requisitos de licenciamento de cluster do chassi, instalando licenças nos dispositivos da Série SRX em um cluster de chassi e verificando licenças em um dispositivo da Série SRX em um cluster de chassi. Consulte o Guia de licenciamento da Juniper para obter informações gerais sobre o gerenciamento de licenças. Consulte a folha de dados do produto nos gateways de serviços da Série SRX para obter detalhes ou entrar em contato com sua equipe de conta da Juniper ou com o parceiro Juniper.

Benefícios do cluster de chassi

  • Evita uma falha em um único dispositivo que resulta em uma perda de conectividade.

  • Oferece alta disponibilidade entre dispositivos ao conectar links de filiais e locais remotos a escritórios corporativos maiores. Aproveitando o recurso de cluster do chassi, as empresas podem garantir a conectividade em caso de falha no dispositivo ou no link.

Funcionalidade de cluster de chassi

A funcionalidade de cluster do chassi inclui:

  • Arquitetura de sistema resiliente, com um único plano de controle ativo para todo o cluster e vários mecanismos de encaminhamento de pacotes. Essa arquitetura apresenta uma visão única do dispositivo do cluster.

  • Sincronização de configuração e estados de tempo de execução dinâmicos entre nós dentro de um cluster.

  • Monitoramento de interfaces físicas e failover se os parâmetros de falha cruzarem um limiar configurado.

Modos de cluster de chassi

Um cluster de chassi pode ser configurado em um modo ativo/ativo ou ativo/passivo.

  • Active/passive mode: No modo ativo/passivo, o tráfego de trânsito passa pelo nó principal enquanto o nó de backup é usado apenas em caso de falha. Quando ocorre uma falha, o dispositivo de backup se torna primário e assume todas as tarefas de encaminhamento.

  • Active/active mode: No modo ativo/ativo, o tráfego de trânsito passa por ambos os nós do cluster o tempo todo.

Como funciona o clustering de chassis?

As portas de controle nos respectivos nós estão conectadas para formar um plano de controle que sincroniza a configuração e o estado do kernel para facilitar a alta disponibilidade de interfaces e serviços.

O plano de dados nos respectivos nós está conectado sobre as portas da malha para formar um plano de dados unificado.

Ao criar um cluster de chassi, as portas de controle nos respectivos nós são conectadas para formar um plano de controle que sincroniza a configuração e o estado do kernel para facilitar a alta disponibilidade de interfaces e serviços.

Da mesma forma, o plano de dados nos respectivos nós está conectado nas portas da malha para formar um plano de dados unificado.

O link de malha permite o gerenciamento do processamento de fluxo de nós cruzados e para o gerenciamento da redundância de sessão.

O software de plano de controle opera no modo ativo ou de backup. Quando configurados como um cluster de chassi, os dois nós recuam entre si, com um nó atuando como o dispositivo principal e o outro como dispositivo secundário, garantindo falhas stateful de processos e serviços em caso de falha no sistema ou hardware. Se o dispositivo primário falhar, o dispositivo secundário assume o processamento do tráfego.

O software de plano de dados opera no modo ativo/ativo. Em um cluster de chassi, as informações de sessão são atualizadas à medida que o tráfego atravessa ambos os dispositivos, e essas informações são transmitidas entre os nós sobre o link da malha para garantir que as sessões estabelecidas não sejam descartadas quando ocorre um failover. No modo ativo/ativo, é possível que o tráfego ingresse o cluster em um nó e saída do outro nó. Quando um dispositivo se junta a um cluster, ele se torna um nó desse cluster. Com exceção de configurações de nó exclusivas e endereços IP de gerenciamento, nós em um cluster compartilham a mesma configuração.

Em um determinado momento, um cluster pode estar em um dos seguintes estados: hold, primário, secundário, inelegibilidade e desativado. Uma transição de estado pode ser desencadeada por qualquer evento, como monitoramento de interfaces, monitoramento de SPU, falhas e failovers manuais.

Suporte para clusters IPv6

Os firewalls da Série SRX que executam a versão IP 6 (IPv6) podem ser implantados em configurações de cluster de chassi ativo/ativo (failover), além do suporte existente de configurações de cluster de chassi ativo/passivo (failover). Uma interface pode ser configurada com um endereço IPv4, endereço IPv6 ou ambos. As entradas da lista de endereços podem incluir qualquer combinação de endereços IPv4, endereços IPv6 e nomes de sistema de nomes de domínio (DNS).

O cluster do chassi oferece suporte a túneis de encapsulamento de roteamento genérico (GRE) usados para rotear tráfego IPv4/IPv6 encapsulado por meio de uma interface interna, gr-0/0/0. Esta interface é criada pelo Junos OS no inicialização do sistema e é usada apenas para processamento de túneis GRE. Consulte o guia de usuário de interfaces para dispositivos de segurança.

Caso de uso para clusters de chassi SRX

As redes empresariais e de provedores de serviços utilizam vários métodos de redundância e resiliência no nível de rede de borda do cliente. Como esse nível representa o ponto de entrada ou peering para a Internet, sua estabilidade e tempo de atividade são de grande importância. Informações transacionais do cliente, e-mail, Voz sobre IP (VoIP) e tráfego de site para site podem utilizar este único ponto de entrada para a rede pública. Em ambientes onde uma VPN local a site é a única interconexão entre sites de clientes e o site da sede, esse link se torna ainda mais vital.

Tradicionalmente, vários dispositivos com configurações discretas têm sido usados para fornecer redundância nesta camada de rede com resultados mistos. Nessas configurações, a empresa conta com protocolos de roteamento e redundância para habilitar uma borda de cliente altamente disponível e redundante. Esses protocolos costumam demorar para reconhecer falhas e normalmente não permitem a sincronização necessária para lidar adequadamente com o tráfego stateful. Dado que uma quantidade justa de tráfego empresarial que passa pela borda (para/a partir da Internet ou entre sites de clientes) é stateful, um desafio consistente na configuração deste nível de rede tem sido garantir que o estado da sessão não seja perdido quando o failover ou a reversão ocorrem.

Outro desafio na configuração de dispositivos redundantes é a necessidade de configurar, gerenciar e manter dispositivos físicos separados com diferentes configurações. Sincronizar essas configurações também pode ser um desafio porque, à medida que a necessidade e a complexidade das medidas de segurança aumentam, também aumenta a probabilidade de que as configurações sejam incompatíveis. Em um ambiente seguro, uma configuração inigualável pode causar algo tão simples quanto uma perda de conectividade ou tão complexo e caro quanto uma falha total de segurança. Qualquer evento anômalo na borda do cliente pode afetar o tempo de atividade, o que consequentemente afeta a capacidade de atender aos clientes ou possivelmente a capacidade de manter os dados dos clientes seguros.

Uma resposta para o problema da configuração redundante da borda do cliente é introduzir uma arquitetura de clustering consciente do estado que permite que dois ou mais dispositivos operem como um único dispositivo. Dispositivos nesse tipo de arquitetura são capazes de compartilhar informações de sessão entre todos os dispositivos para permitir failover quase instantâneo e reversão do tráfego stateful. Uma medida fundamental de sucesso neste espaço é a capacidade do cluster de falhar e reverter o tráfego, mantendo o estado das sessões ativas.

Usando a configuração de cluster do chassi SRX descrita no exemplo: a configuração de um gateway de serviços da Série SRX como um cluster de chassi de malha completa reduzirá o tempo de inatividade do sistema.

Dispositivos em uma arquitetura de clustering eficaz também podem ser gerenciados como um único dispositivo; compartilhando um único plano de controle. Essa função é vital, pois reduz a OpEx associada ao gerenciamento de vários dispositivos. Em vez de gerenciar e operar dispositivos separados com diferentes configurações e portais de gerenciamento, você pode gerenciar vários dispositivos que atendem a mesma função por meio de um único ponto de gerenciamento.

Por fim, em uma configuração de cluster, os dispositivos têm a capacidade de monitorar interfaces ativas para determinar seu estado de serviço. Um cluster eficaz monitora proativamente todas as interfaces de receita e deve falhar em interfaces de backup se uma falha for detectada. Isso deve ser feito em intervalos quase instantâneos para minimizar o impacto de uma falha no serviço (chamadas de clientes perdidas etc.).

Limitações do cluster do chassi

Os firewalls da Série SRX têm as seguintes limitações de cluster de chassi:

Chassis Cluster

  • A VPN do grupo não é suportada.

  • Em todos os firewalls da Série SRX em um cluster de chassi, o monitoramento de fluxo para a versão 5 e a versão 8 é suportado. No entanto, o monitoramento de fluxo para a versão 9 não é suportado.

  • Quando um firewall da Série SRX está operando no modo cluster do chassi e encontra qualquer problema de acesso de chip de IA em um SPC ou uma placa de E/S (IOC), um alarme FPC menor é ativado para acionar o failover do grupo de redundância.

  • Em dispositivos de SRX5400, SRX5600 e SRX5800, os dados das estatísticas de tela podem ser coletados apenas no dispositivo principal.

  • Em dispositivos de SRX4600, SRX5400, SRX5600 e SRX5800, em configurações de cluster de grande porte, se mais de 1000 interfaces lógicas forem usadas, recomenda-se que os temporizadores de cluster sejam aumentados do tempo de espera padrão antes de acionar o failover. Em uma implementação de capacidade total, recomendamos aumentar a espera para 8 segundos modificando heartbeat-threshold e heartbeat-interval valores na [edit chassis cluster] hierarquia.

    O produto e heartbeat-interval os heartbeat-threshold valores definem o tempo antes do failover. Os valores padrão (heartbeat-threshold de 3 batidas e heartbeat-interval de 1000 milissegundos) produzem um tempo de espera de 3 segundos.

    Para alterar o tempo de espera, modifique os valores de opção para que o produto seja igual à configuração desejada. Por exemplo, definir o heartbeat-threshold 8 e manter o valor padrão para os heartbeat-interval (1000 milissegundos) gera um tempo de espera de 8 segundos. Da mesma forma, definir os heartbeat-threshold 4 e os heartbeat-interval milissegundos de 2000 também gera um tempo de espera de 8 segundos.

  • Em dispositivos de SRX5400, SRX5600 e SRX5800, as configurações de oito filas não se refletem na interface de cluster do chassi.

Flow and Processing

  • Se você usar a captura de pacotes em interfaces de reth, dois arquivos serão criados, um para pacotes de entrada e outro para pacotes de saída com base no nome da interface de reth. Esses arquivos podem ser mesclados fora do dispositivo usando ferramentas como Wireshark ou Mergecap.

  • Se você usar o espelhamento de porta em interfaces de reth, a interface de reth não pode ser configurada como a interface de saída. Você deve usar uma interface física como interface de saída. Se você configurar a interface de reth como uma interface de saída usando o set forwarding-options port-mirroring family inet output comando, a mensagem de erro a seguir será exibida.

    Port-mirroring configuration error. . Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

  • Quando um firewall da Série SRX está operando no modo cluster de chassi e encontra qualquer ia-chip (IA-chip faz parte do SPC1 e IOC1 da Juniper. Ele tem impacto direto no problema de acesso do plano de controle SPC1/IOC1 em um SPC ou placa de E/S (IOC), um alarme FPC menor é ativado para desencadear failover de grupo de redundância.

  • Em firewalls da Série SRX em um cluster de chassi, quando dois sistemas lógicos são configurados, o limite de escala ultrapassa 13.000, que é muito próximo do limite de escala padrão de 15.000, e um tempo de convergência de 5 minutos resulta. Esse problema ocorre porque o aprendizado de rotas multicast leva mais tempo quando o número de rotas é aumentado.

  • Em SRX4600, SRX5400, SRX5600 e dispositivos SRX5800 em um cluster de chassi, se o nó primário que executa o processo LACP (lacpd) passar por uma reinicialização graciosa ou sem graça, o lacpd no novo nó primário pode levar alguns segundos para iniciar ou redefinir interfaces e máquinas de estado para recuperar resultados síncronos inesperados. Além disso, durante o failover, quando o sistema está processando pacotes de tráfego ou pacotes internos de alta prioridade (excluindo sessões ou restabelecendo tarefas), os pacotes LACP de prioridade média do peer (switch) são empurrados para fora nas filas de espera, causando mais atrasos.

O monitoramento fluído é suportado nos dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600, SRX2300 e SRX4300.

Installation and Upgrade

  • Para dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380, o reboot parâmetro não está disponível, pois os dispositivos em um cluster são reiniciados automaticamente após uma atualização de cluster na banda (UTI).

Interfaces

  • Na interface lsq-0/0/0, os serviços de link MLPPP, MLFR e CRTP não são suportados.

  • Na interface lt-0/0/0, o CoS para RPM não é compatível.

  • A interface do dialer 3G não é suportada.

  • A fila na interface ae não é suportada.

Layer 2 Switching

  • No failover do firewall da Série SRX, os pontos de acesso na reinicialização do switch de Camada 2 e todos os clientes sem fio perdem a conectividade por 4 a 6 minutos.

MIBs

  • O MIB de cluster de chassi não é suportado.

Monitoring

  • O número máximo de IPs de monitoramento que podem ser configurados por cluster é de 64 para dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600, SRX2300 e SRX4300.

  • Nos dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500,SRX1600, SRX2300 e SRX4300, os logs não podem ser enviados ao NSM quando o registro é configurado no modo de fluxo. Os logs não podem ser enviados porque o log de segurança não oferece suporte à configuração do endereço IP de origem para a interface do switch e o destino de log de segurança no modo stream não pode ser roteado pela interface do switch. Isso implica que você não pode configurar o servidor de log de segurança na mesma sub-rede que a interface do fxp0 e rotear o servidor de log pela interface do switch0.

IPv6

  • O monitoramento de endereços IP do grupo de redundância não é suportado para destinos IPv6.

GPRS

  • Em dispositivos de SRX5400, SRX5600 e SRX5800, uma APN ou um filtro IMSI devem ser limitados a 600 para cada perfil GTP. O número de filtros é diretamente proporcional ao número de entradas de prefixo IMSI. Por exemplo, se um APN estiver configurado com duas entradas de prefixo IMSI, o número de filtros será de dois.

MIBs

  • O MIB de cluster de chassi não é suportado.

Nonstop Active Routing (NSR)

  • O NSR pode preservar as informações de interface e kernel e economiza informações de protocolo de roteamento executando o processo de protocolo de roteamento (RPD) no mecanismo de roteamento de backup. No entanto, a maioria das plataformas SRX ainda não oferece suporte ao NSR. Então, no nó secundário, não há daemon RPD existente. Após o failover do RG0, o novo mestre do RG0 terá um novo RPD e precisará negociar novamente com o dispositivo peer. Apenas plataformas SRX5000 com versão 17.4R2 ou superior podem oferecer suporte ao NSR.

A partir do Junos OS Release 12.1X45-D10 e posteriores, recursos de amostragem, como monitoramento de fluxo, captura de pacotes e espelhamento de portas, são suportados em interfaces de reth.

Veja também

Documentação relacionada

Tabela de histórico de mudanças

O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.

Soltar
Descrição
12.1X45
A partir do Junos OS Release 12.1X45-D10 e posteriores, recursos de amostragem, como monitoramento de fluxo, captura de pacotes e espelhamento de portas, são suportados em interfaces de reth.