Visão geral da arquitetura de software de alta disponibilidade Junos Space
A plataforma Junos Space foi projetada para garantir a disponibilidade de cinco noves com uma arquitetura distribuída em clusters, de várias camadas, compreendendo os seguintes recursos:
Clientes de GUI da Web 2.0 baseados em navegador padrão e clientes NBI baseados em REST/HTTPS
Apache Load Balancer como um balanceador de carga de alto nível
JBoss Application Server baseado na tecnologia J2EE para fornecer estrutura de aplicativos
Banco de dados MySQL para gerenciar dados persistentes
O sistema de arquivos distribuídos por Cassandra para armazenar arquivos e arquivos de imagens de dispositivos dos aplicativos Junos Space
As seções a seguir descrevem a arquitetura Junos Space e identificam os requisitos básicos de comunicação entre nós em um cluster Junos Space:
Arquitetura de software Junos Space
A Figura 1 oferece uma visão de alto nível da arquitetura de software Junos Space. Os serviços Junos Space são acessíveis aos clientes GUI e NBI por meio de um único endereço IP virtual para o cluster.

As solicitações dos clientes são balanceadas entre vários nós no cluster por meio do Apache HTTP Load Balancer, que é implantado em uma configuração de standby ativa em dois nós no cluster. O balanceador de carga no nó que possui o endereço IP virtual (VIP) funciona como a instância ativa. Se o nó que atualmente possui o endereço VIP for desativado, o outro nó no cluster Linux Virtual Server (LVS) detectará essa falha e assumirá automaticamente o endereço VIP. As solicitações de HTTP são balanceadas com carga em todos os servidores JBoss ativos no cluster usando um algoritmo round-robin.
Os servidores JBoss ativos dentro do cluster fornecem a estrutura do aplicativo para aplicativos Junos Space, incluindo os seguintes serviços:
Hospedagem dos aplicativos e lógica de negócios associada
Balanceamento de carga no nível de aplicativo dentro do cluster
Monitoramento de aplicativos e recuperação automática
Monitoramento de nós de cluster e recuperação automática
Serviços de banco de dados com acesso direto ao MySQL DB por meio do JDBC
Lógica de mediação de dispositivos de hospedagem
Arquitetura de balanceamento de carga
Um cluster Junos Space é apresentado com dois tipos de cargas:
Solicitações recebidas de clientes GUI e NBI
Comunicação com dispositivos gerenciados
O Junos Space foi projetado para equilibrar as solicitações recebidas em todos os nós ativos do cluster. As solicitações dos clientes gui e NBI chegam como solicitações de HTTP fornecidas pela instância ativa do balanceador de carga Apache HTTP. O balanceador de carga distribui as solicitações a todos os servidores JBoss ativos no cluster usando um algoritmo round-robin. As sessões pegajosas são utilizadas para garantir que todas as solicitações de HTTP associadas a uma sessão de GUI específica sejam atendidas pelo mesmo servidor JBoss durante a vida útil dessa sessão. Para fins de balanceamento de carga no nível de aplicativo, a lógica de negócios da JBoss processa solicitações complexas como um conjunto de subtrabalhamentos, que são distribuídos em vários nós no cluster. Por exemplo, uma única solicitação a um cluster Space de quatro nós para ressincronizar 100 dispositivos é dividida em quatro subtraídas que são executadas em quatro nós diferentes, com cada nó ressincronizando 25 dispositivos. Para obter uma visão geral detalhada do balanceamento de carga, veja o tópico Entendendo os clusters lógicos dentro de um cluster espacial Junos.
Para realizar o balanceamento de carga no nível do dispositivo, o Junos Space emprega lógica na Camada de Mediação de Dispositivos (DML) para que as conexões de dispositivo sejam igualmente distribuídas em todos os nós ativos do cluster. O balanceamento de carga no nível do dispositivo é realizado durante a descoberta do dispositivo comparando o número de conexões de dispositivos atendidas por nós individuais e selecionando o nó menos carregado. Se algum nó cair, todas as conexões de dispositivo associadas serão distribuídas aos nós ativos restantes no cluster, evitando assim que uma interrupção de nó afete a conectividade do dispositivo. Para obter uma visão geral detalhada do gerenciamento de conectividade de dispositivos, veja o tópico Entendendo o gerenciamento de alta disponibilidade das conexões de DMI.
Arquitetura de banco de dados
O MySQL Enterprise Edition é usado para fornecer serviços de banco de dados para o gerenciamento de dados persistentes para plataforma e aplicativos. Os servidores MySQL DB estão sendo executados em dois nós no cluster na configuração de standby ativo. As transações de banco de dados são replicadas entre os dois servidores MySQL em tempo quase real.! Para obter informações sobre o cluster MySQL formado em cada cluster Junos Space, veja Entendendo os clusters lógicos dentro de um cluster espacial Junos.
A plataforma Junos Space também incorpora monitoramento de rede para gerenciamento de falhas e desempenho, que usa o serviço de banco de dados relacional PostgreSQL para armazenar dados relacionados a falhas e desempenho. O servidor PostgreSQL é executado em dois nós no cluster Space na configuração ativa com replicação em tempo real para garantir que os dados de falha e desempenho continuem disponíveis mesmo se um desses nós falhar. Para obter mais informações, veja Alta disponibilidade para monitoramento de rede.
Comunicação entre nós entre nós em um Junos Space Cluster
Para facilitar a comunicação perfeita entre os nós em um cluster Space e alcançar o melhor desempenho do cluster, você precisa garantir o seguinte:
Todos os nós em um cluster Junos Space são configurados com endereços IP dentro da mesma sub-rede. Isso é importante para que o mecanismo de switchover VIP funcione corretamente.
Todos os nós em um cluster Space são conectados por meio de uma rede local de 1 Gbps ou 100 Mbps com latência insignificante.
Os servidores JBoss dentro de um cluster Junos Space comunicam-se por meio de um UDP multicast para formar clusters lógicos.
Nota:O tráfego multicast UDP deve ser permitido dentro dos nós do cluster, o que também significa que você deve desabilitar o IGMP bisbilhotando os switches que interconectam o cluster ou os configuram explicitamente para permitir que o UDP multicast entre os nós.