Requisitos do sistema de controlador NorthStar

Espaço adicional em disco para a JTI Analytics em elasticSearch

É necessário um espaço de armazenamento considerável para oferecer suporte às análises de JTI no ElasticSearch. Cada evento de registro JTI requer aproximadamente 330 bytes de espaço em disco. Uma estimativa razoável do número de eventos gerados é (<números de interfaces> + <números de LSPs>) ÷ relatórios de intervalo em segundos = eventos por segundo.

Assim, para uma rede com 500 roteadores, interfaces de 50K e LSPs de 60K, com um intervalo configurado de relatórios de cinco minutos (300 segundos), você pode esperar que algo no bairro de 366 eventos por segundo seja gerado. A 330 bytes por evento, ele sai para 366 eventos x 330 bytes x 86.400 segundos em um dia = mais de 10G de espaço em disco por dia ou 3,65T por ano. Para uma rede de mesmo tamanho, mas com um intervalo de relatórios de um minuto (60 segundos), você teria um requisito muito maior de espaço em disco — mais de 50G por dia ou 18T por ano.

Há um evento de roll-up adicional criado por hora por elemento para agregação de dados. Em uma rede com interfaces de 50K e LSPs de 60K (total de elementos de 110K), você teria eventos de roll-up de 110K por hora. Em termos de espaço em disco, seriam eventos de 110K por hora x 330 bytes por evento x 24 horas por dia = quase 1G de espaço em disco necessário por dia.

Para uma rede típica de cerca de 100K elementos (interfaces + LSPs), recomendamos que você permita um adicional de 11G de espaço de disco por dia se tiver um intervalo de relatórios de cinco minutos, ou 51G por dia se tiver um intervalo de relatórios de um minuto.

Veja a retenção de dados bruta e agregada do NorthStar Analytics no Guia do usuário do controlador NorthStar para obter informações sobre a personalização de parâmetros de agregação e retenção de dados para reduzir a quantidade de espaço em disco exigido pela ElasticSearch.

Espaço adicional em disco para eventos de rede em Cassandra

O banco de dados de Cassandra é outro componente que requer espaço adicional em disco para armazenamento de eventos de rede.

Usando esse mesmo exemplo de interfaces 50K e LSPs de 60K (110 elementos) e estimando um evento a cada 15 minutos (900 segundos) por elemento, haveria 122 eventos por segundo. O armazenamento necessário seria então de 122 eventos por segundo x 300 bytes por evento x 86.400 segundos por dia = cerca de 3,2 G por dia, ou 1,2T por ano.

Usando um evento a cada 5 minutos por elemento como estimativa em vez de cada 15 minutos, o requisito adicional de armazenamento é mais como 9,6G por dia ou 3,6T por ano.

Para uma rede típica de cerca de 100K elementos (interfaces + LSPs), recomendamos que você permita um adicional de 3-10G de espaço de disco por dia, dependendo da taxa de geração de eventos em sua rede.

Por padrão, o NorthStar mantém o histórico de eventos por 35 dias. Para personalizar o número de dias em que os dados do evento são retidos:

1. Modifique o parâmetro de dbCapacity em /opt/northstar/data/web_config.json

2. Reinicie o processo pruneDB usando o supervisorctl restart infra:prunedb comando.

Requisitos de memória de coletor (Aipo)

Quando você usa o script collector.sh para instalar coletores secundários em um servidor separado do aplicativo NorthStar (para coleta distribuída), o script instala o número padrão de trabalhadores coletores descrito na Tabela 4. O número de processos de aipo iniciados por cada trabalhador é o número de núcleos na CPU mais um. Assim, em um servidor de 32 núcleos (por exemplo), o único trabalhador padrão instalado iniciaria 33 processos de aipo. Cada processo de aipo usa cerca de 50M de RAM.

Consulte a instalação de coletores secundários para coleta distribuída de dados para obter mais informações sobre a coleta distribuída de dados e trabalhadores secundários.

O número padrão de trabalhadores instalados visa otimizar os recursos do servidor, mas você pode alterar o número usando o script config_celery_workers.sh fornecido. Consulte a personalização da instalação do Collector Worker para obter mais informações. Você pode usar esse script para equilibrar o número de trabalhadores instalados com a quantidade de memória disponível no servidor.

Requisitos de imagem de VM

• O aplicativo NorthStar Controller VM está instalado em cima de uma VM Linux, de modo que o VM linux é necessário. Você pode obter uma imagem de VM do Linux de qualquer uma das seguintes maneiras:

  • Use a versão genérica fornecida pela maioria dos distribuidores Linux. Normalmente, essas são imagens baseadas em nuvem para uso em um ambiente habilitado para a nuvem e não exigem uma senha. Essas imagens são totalmente compatíveis com o OpenStack.

  • Crie sua própria imagem de VM. Alguns hipervisores, como DVM genérico, permitem que você crie sua própria imagem de VM. Recomendamos essa abordagem se você não estiver usando o OpenStack e seu hipervisor não oferecer suporte nativo à init na nuvem.

• O JunosVM é fornecido no formato Qcow2 quando está dentro do pacote NorthStar Controller. Se você baixar o JunosVM separadamente (não empacotado com o NorthStar) no site de download northstar, ele será fornecido no formato VMDK.

• A imagem do JunosVM só é compatível com controladores de disco IDE. Você deve configurar o hipervisor para usar o IDE em vez do tipo de controlador SATA para a imagem do disco JunosVM.

Requisitos de versão do JunosVM

Se você tiver e quiser continuar usando uma versão do JunosVM com mais de 17,2R1 de versão, você pode mudar a configuração northstar para dar suporte a ele, mas o suporte de roteamento por segmentos não estaria disponível. Veja a instalação do controlador NorthStar para as etapas de configuração.

Requisitos de redes VM

Os seguintes requisitos de rede devem ser atendidos para que a abordagem de instalação de duas VM seja bem sucedida:

• Cada VM requer os seguintes NICs virtuais:

  • Um conectado à rede externa

  • Uma para a conexão interna entre o aplicativo NorthStar e o JunosVM

  • Um conectado à rede de gerenciamento se uma interface diferente for necessária entre as interfaces voltadas para o roteador e o cliente

• Recomendamos uma rede plana ou roteada sem nenhum NAT para compatibilidade total.

• Uma rede virtual com NAT de um para um (geralmente referenciado como um IP flutuante) pode ser usada enquanto o BGP-LS for usado como mecanismo de aquisição de topologia. Se a adjacência IS-IS ou OSPF for necessária, ela deve ser estabelecida em um túnel GRE.

  Nota:

  Uma rede virtual com NAT n-to-one não é suportada.