Entendendo interfaces agregadas de multisserviços para serviços de próxima geração
Este tópico fornece uma visão geral do uso do recurso De interfaces agregadas de multisserviços com a placa de serviços MX-SPC3 para serviços de próxima geração. Ela contém as seguintes seções:
Interface agregada de multisserviços
No Junos OS, você pode combinar várias interfaces de serviços para criar um pacote de interfaces de serviços que podem funcionar como uma única interface. Esse pacote de interfaces é conhecido como AMS aggregated multiservices interface e é denotado como amsN na configuração, onde N há um número único que identifica uma interface AMS (por exemplo, ams0). A partir do Junos OS Release 19.3R2, as interfaces AMS são suportadas na placa de serviços MX-SPC3 dos serviços de próxima geração.
A configuração da AMS oferece maior escalabilidade, melhor desempenho e melhores opções de failover e balanceamento de carga.
Uma configuração ams permite que conjuntos de serviços ofereçam suporte a vários PICs de serviços associando um pacote AMS a um conjunto de serviços. Para serviços de próxima geração, a placa de serviços MX-SPC3 oferece suporte a até dois PICs e você pode ter no máximo oito placas de serviçoS MX-SPC3 em seu chassi. Isso permite que um pacote AMS de serviços de próxima geração tenha até 16 PICs de serviços como interfaces de membro e você pode distribuir serviços entre as interfaces dos membros.
As interfaces dos membros são identificadas como mams na configuração. O processo de chassi em roteadores que oferecem suporte à configuração ams cria uma entrada mams para cada interface multisserviços no roteador.
Quando você configura opções de serviços no nível da interface ams, as opções se aplicam a todas as interfaces de membro (mams) para a interface ams.
As opções também se aplicam aos conjuntos de serviços configurados em interfaces de serviços correspondentes às interfaces de membro da interface ams. Todas as configurações são por PIC. Por exemplo, o limite de sessão se aplica por membro e não em um nível agregado.
Você não pode configurar opções de serviços no nível ams (agregado) e interface de membro. Se as opções de serviços estiverem configuradasvms-x/y/z, elas também se aplicam a conjuntos de serviços.mams-x/y/z
Quando você deseja que as configurações de opções de serviços se apliquem uniformemente a todos os membros, configure opções de serviços no nível da interface ams. Se você precisar de configurações diferentes para membros individuais, configure opções de serviços no nível da interface do membro.
A queda de tráfego por membro e a configuração de próximo salto por membro são necessárias para o NAT64. Para o NAPT44, essa especificação por membro permite chaves de hash arbitrárias, oferecendo melhores opções de balanceamento de carga para permitir que as operações de NAT dinâmicas sejam realizadas. Para NAT64, NAPT44 e NAT44 dinâmico, não é possível determinar qual membro aloca o endereço NAT dinâmico. Para garantir que os pacotes de fluxo reverso cheguem ao mesmo membro que os pacotes de fluxo de encaminhamento, as rotas baseadas em endereços de pool são usadas para direcionar pacotes de fluxo reverso.
Se você modificar um pool de NAT que está sendo usado por um conjunto de serviços atribuído a uma interface AMS, você deve desativar e ativar o conjunto de serviços antes que as mudanças no pool de NAT entrem em vigor.
A distribuição de tráfego nas interfaces de membro de uma interface AMS pode ocorrer de forma redonda ou baseada em hash. Você pode configurar os seguintes valores chave de hash para regular a distribuição de tráfego: source-ip, destination-ip e protocol. Para serviços que exigem simetria de tráfego, você deve configurar o hashing simétrico. A configuração de hash simétrica garante que o tráfego avançado e reverso seja roteado pela mesma interface de membro.
Se o conjunto de serviços for aplicado na ethernet Gigabit ou na interface Ethernet de 10 Gigabits (conjunto de serviços no estilo de interface) que funciona como a interface interna do NAT, então as chaves de hash usadas para balanceamento de carga podem ser configuradas de tal forma que a chave de entrada seja definida como endereço IP de destino e a chave de saída é definida como endereço IP de origem. Como o endereço IP de origem passa pelo processamento de NAT, ele não está disponível para a hashing do tráfego na direção inversa. Portanto, o balanceamento de carga não acontece no mesmo endereço IP e o tráfego avançado e reverso não mapeia para o mesmo PIC. Com as teclas de hash invertidas, o balanceamento de carga ocorre corretamente.
Com serviços de próximo salto, para tráfego avançado, a chave de entrada na interface interna equilibra o tráfego e, para tráfego reverso, a chave de entrada na interface externa equilibra o tráfego ou o tráfego reverso do próximo salto por membro. Com serviços no estilo de interface, a chave de entrada equilibra o tráfego para a frente e a saída principais equilíbrios de carga encaminham tráfego ou próximo saltos por membro direcionam o tráfego reverso. O tráfego avançado é o tráfego entrando pelo lado interno de um conjunto de serviços e o tráfego reverso é o tráfego entrando do lado externo de um conjunto de serviços. A chave de encaminhamento é a chave de hash usada para a direção de encaminhamento do tráfego e a chave inversa é a chave de hash usada para a direção inversa do tráfego (depende se está relacionada com serviços de interface ou estilo de serviços de próximo salto).)
Com firewalls stateful, você pode configurar as seguintes combinações de chaves para frente e reversa para balanceamento de carga. Nas combinações a seguir apresentadas para chaves de hash, FOR-KEY refere-se à chave de encaminhamento, o REV-KEY denota a chave inversa, o SIP significa endereço IP de origem, o DIP significa endereço IP de destino e o PROTO refere-se a protocolos como IP.
FOR-KEY: SIP, REV-KEY: DIP
FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO
FOR-KEY: DIP, REV-KEY: SIP
FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO
POR CHAVE: SIP,DIP REV-KEY: SIP, DIP
POR CHAVE: SIP,DIP,PROTO REV-KEY: SIP, DIP,PROTO
Com NAT estático configurado como NAT44 básico ou NAT44 de destino, e com firewall stateful configurado ou não, se a direção de encaminhamento do tráfego deve passar pelo processamento de NAT, configure as chaves de hash da seguinte forma:
FOR-KEY: DIP, REV-KEY: SIP
FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO
Se a direção inversa do tráfego deve passar pelo processamento de NAT, configure as chaves de hash da seguinte forma:
FOR-KEY: SIP, REV-KEY: DIP
FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO
Com NAT dinâmico configurado e com firewall stateful configurado ou não, apenas o tráfego de direção futura pode passar por NAT. A chave de hash para frente pode ser qualquer combinação de SIP, DIP e protocolo, e a chave de hash reversa é ignorada.
A configuração do Junos OS AMS oferece suporte ao tráfego IPv4 e IPv6.
Visão geral do tráfego IPv6 nas interfaces AMS
Você pode usar interfaces AMS para tráfego IPv6. Para configurar o suporte IPv6 para uma interface AMS, inclua a family inet6 declaração no nível de [edit interfaces ams-interface-name unit 1] hierarquia. Quando family inet e family inet6 definidos para uma subunit de interface AMS, ele hash-keys está configurado no nível de conjunto de serviços para estilo de interface e no nível IFL para estilo next-hop.
Quando uma interface de membro de um pacote AMS falha, o tráfego destinado ao membro com falha é redistribuído entre os membros ativos restantes. O tráfego (fluxos ou sessões) que atravessa os membros ativos existentes não é afetado. Se os membros M estiverem ativos no momento, o resultado esperado é que apenas cerca de 1/M de fração do tráfego (fluxos/sessões) é afetado porque essa quantidade de tráfego é transferida do membro reprovado para permanecer membros ativos. Quando a interface de membro falha volta on-line, apenas uma fração do tráfego é redistribuída para o novo membro. Se os membros N estiverem ativos no momento, o resultado esperado é que apenas cerca de 1/(N+1) fração do tráfego (fluxos/sessões) é afetada porque essa quantidade de tráfego se move para o novo membro recuperado. Os valores de 1/M e 1/(N+1) assumem que os fluxos são distribuídos uniformemente entre os membros, porque um hash de pacote é usado para o equilíbrio de carga e porque o tráfego geralmente contém uma combinação aleatória típica de endereços IP (ou quaisquer outros campos que sejam usados como chaves de balanceamento de carga).
Semelhante ao tráfego IPv4, para pacotes IPv6, um pacote AMS deve conter membros de apenas um tipo PIC de serviços.
O número de fluxos distribuídos, em um ambiente ideal, pode ser de 1/N no melhor cenário quando o membro Nth sobe ou desce. No entanto, essa suposição considera que as teclas de hash equilibram o tráfego real ou dinâmico. Por exemplo, considere uma implantação do mundo real onde o membro A está servindo apenas um fluxo, enquanto o membro B está servindo 10 fluxos. Se o membro B cair, o número de fluxos interrompidos será de 10/11. O comportamento de divisão de pool de NAT foi projetado para utilizar os benefícios do recurso de minimização de repetição. A divisão de um pool de NAT é realizada para cenários nat dinâmicos (NAT dinâmico, NAT64 e NAPT44).
Se os fluxos originais e redistribuídos forem definidos da seguinte forma:
Fluxos originais dos membros — o tráfego mapeado para um membro quando todos os membros estão funcionando.
Fluxos redistribuídos por membros — o tráfego adicional mapeado para um membro quando algum outro membro falha. Esses fluxos de tráfego podem precisar ser reequilibrados quando as interfaces de membros surgem e descem.
Com as definições anteriores dos fluxos originais e redistribuídos para interfaces de membros, as seguintes observações se aplicam:
Os fluxos originais de um membro permanecem intactos enquanto esse membro estiver funcionando. Tais fluxos não são afetados quando outros membros se movem entre os estados para cima e para baixo.
Os fluxos redistribuídos por membros de um membro podem mudar quando outros membros sobem ou descem. Essa mudança de fluxos ocorre porque esses fluxos adicionais precisam ser reequilibrados entre todos os membros ativos. Portanto, o fluxo redistribuído por membros pode variar muito com base em outros membros indo para baixo ou para cima. Embora possa parecer que quando um membro cai, os fluxos em membros ativos são preservados, e que quando um membro sobe, os fluxos sobre membros ativos não são preservados de forma eficaz, esse comportamento é apenas devido ao reequilíbrio estático ou baseado em hash do tráfego entre membros ativos.
O recurso de minimização de repetição lida com as mudanças operacionais apenas no status da interface de membro (como o membro offline ou o junos os reset). Ele não lida com mudanças na configuração. Por exemplo, a adição ou exclusão, ou ativação e desativação de interfaces de membros no nível hierárquico [edit interfaces amsN load-balancing-options member-interface mams-a/b/0] exige que os PICs membros sejam saltados. Duas vezes o NAT ou o cabeamento de cabelo não são suportados, semelhante ao suporte IPv4 para interfaces AMS.
Opções de falha de membros e configurações de alta disponibilidade
Como várias interfaces de serviço estão configuradas como parte de um pacote AMS, a configuração da AMS também oferece failover e suporte de alta disponibilidade. Você pode configurar uma das interfaces de membro como uma interface de backup que se torna ativa quando qualquer uma das outras interfaces de membro cai, ou configurar a AMS de tal forma que, quando uma das interfaces de membro cai, o tráfego atribuído a essa interface é compartilhado nas interfaces ativas.
A member-failure-options declaração de configuração permite configurar como lidar com o tráfego quando uma interface de membro falha. Uma opção é redistribuir o tráfego imediatamente entre as outras interfaces de membros. No entanto, a redistribuição do tráfego envolve recalcular as tags de hash e pode causar alguma interrupção no tráfego em todas as interfaces dos membros.
A outra opção é configurar a AMS para soltar todo o tráfego atribuído à interface de membro com falha. Com isso, você pode configurar opcionalmente um intervalo, rejoin-timeoutpara que a AMS aguarde a falha da interface voltar a funcionar após a qual a AMS pode redistribuir o tráfego entre outras interfaces de membros. Se a interface de membro falha voltar a funcionar antes do tempo de espera configurado, o tráfego continua não afetado em todas as interfaces de membros, incluindo a interface que voltou on-line e retomou as operações.
Você também pode controlar a voltada interface com falha quando ela voltar a funcionar. Se você não incluir a enable-rejoin declaração na member-failure-options configuração, a interface com falha não poderá voltar à AMS quando ela voltar a funcionar. Nesses casos, você pode juntar isso manualmente à AMS executando o comando do request interfaces revert interface-name modo operacional.
As rejoin-timeout declarações e enable-rejoin as declarações permitem que você minimize as interrupções de tráfego quando as interfaces dos membros batem palmas.
Quando member-failure-options não estiver configurado, o comportamento padrão é abandonar o tráfego de membros com um tempo limite de retorno de 120 segundos.
A high-availability-options configuração permite que você designe uma das interfaces de membro como uma interface de backup. A interface de backup não participa de operações de roteamento enquanto permanecer uma interface de backup. Quando uma interface de membro falha, a interface de backup lida com o tráfego atribuído à interface com falha. Quando a interface com falha volta on-line, ela se torna a nova interface de backup.
Em uma configuração de muitos para um (N:1), uma única interface de backup oferece suporte a todas as outras interfaces de membros do grupo. Se alguma das interfaces de membro falhar, a interface de backup assume o controle. Nesta configuração sem estado, os dados não são sincronizados entre a interface de backup e as outras interfaces de membro.
Quando ambos member-failure-options e high-availability-options estão configurados para uma AMS, a high-availability-options configuração tem precedência sobre a member-failure-options configuração. Se uma segunda falha ocorrer antes que a interface com falha volte a funcionar para ser o novo backup, a member-failure-options configuração entra em vigor.
Redundância de espera quente
A partir do Junos OS Release 19.3R2, a opção de espera quente N:1 é suportada no MX-SPC3 se você estiver executando serviços de próxima geração. Cada interface AMS de standby quente contém dois membros; um membro é a interface de serviço que você deseja proteger, chamada de interface primária, e um membro é a interface secundária (backup). A interface principal é a interface ativa e a interface de backup não lida com nenhum tráfego a menos que a interface primária falhe.
Para configurar o standby quente em uma interface AMS, você usa a redundancy-options declaração. Você não pode usar a load-balancing-options declaração em uma interface AMS de standby quente.
Para mudar da interface primária para a interface secundária, emita o request interface switchover amsN comando.
Para reverter para a interface primária a partir da interface secundária, emita o request interface revert amsN comando.
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.