Guia para instalação do perfSONAR em modo de Archive Host, em servidores com Rocky Linux 9.5.
O perfSONAR (Performance Service-Oriented Network monitoring ARchitecture) é uma ferramenta de medição de desempenho de redes amplamente usada para monitorar e diagnosticar problemas em redes de longa distância. Ele permite realizar testes ativos, como latência e largura de banda, fornecendo uma visão detalhada do comportamento de redes complexas. Seu objetivo é oferecer uma infraestrutura colaborativa para medir e otimizar o desempenho de redes, ajudando equipes de engenharia a detectar e resolver problemas de forma mais eficaz.
Instalação do Archive
Ao contrário do testpoint em que tem disponível uma imagem de container no Docker Hub, não há uma imagem que contenham somente os pacotes necessários para o archiving. Dessa forma, a seguir está presente o guia de instalação feita baremetal (via RPM).
Atualizar o sistema operacional para a última versão disponível
É necessário atualizar o kernel do SO, aplicações e bibliotecas para a última versão disponível, por questões de segurança. Para isso, execute o seguinte comando:
Instalação dos pré requisitos para o Perfsonar
Instalando repositório epel-release
Para atender alguns requisitos de bibliotecas e pacotes do PerfSonar, é necessário instalar o repositório EPEL. Para isso, execute o seguinte comando:
Habilitando repositório CRB
Para ter acesso aos pacotes de desenvolvimento (pacotes devel), é necessário habilitar o repositório CRB.
Veja se tem atualizações do repositório
Instalação do pacote chkconfig para que seja possível habilitar corretamente a inicialização automática do grafana-server.
Para instalá-lo, execute:
Instalação do Perfsonar
Instalando o repositório do PerfSonar 5
Para ter acesso aos pacotes de instalação do PerfSonar, instale o repositório a seguir:
sudo dnf install -y http://software.internet2.edu/rpms/el9/x86_64/latest/packages/perfsonar-repo-0.11-1.noarch.rpm
Limpar cache DNF
Para forçar a atualização da lista e versões dos pacotes disponíveis, é necessário limpar a cache do YUM/DNF.
Instalando Pacotes Perfsonar de archiving:
Archive
Toolkit-security
Pacote necessário para configuração adequada do Firewall.
Configuração do Firewalld
Verificação das configurações
Saída esperada:
public (active)
target: default
icmp-block-inversion: no
interfaces: enX0
sources:
services: bwctl cockpit dhcpv6-client http https ntp owamp-control ssh traceroute twamp-control
ports: 5201/tcp 5201/udp 5001/tcp 5001/udp 5000/tcp 5101/tcp 5000/udp 5101/udp 5890-5900/tcp
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
pSCONFIG Publisher
Caso o Archive Host também seja usado para disponibilizar templates .jsons (arquivos que o psconfig-pscheduler-agent consulta) de forma centralizada de modo que os DTNs (focados somente na transferência) consultem as configurações de agendamentos, archive e etc de forma externa (Archive Host), pode ser instalado o pacote:
Aviso
Caso não seja usado para tal, então não há necessidade de instalá-lo.
Instalação dos Testpoints
Uma vez instalado o archiving de forma baremetal (via RPM) em um único host, o passo seguinte é a instalação dos pacotes os quais disponibilizam os serviços e ferramentas necessárias para os testes, sendo o principal serviço o pScheduler (responsável pelos agendamentos).
Para o testpoint há tanto a opção baremetal (via RPM) caso seja de interesse instalar em uma VM, por exemplo, assim como também a versão em imagem docker caso tenha necessidade de usar container. A seguir terão os passos referentes a essas duas opções:
- Container Docker
- Via RPM
Opção em Docker
Em versão para container foi feito um arquivo docker compose a fim de facilitar o processo de deploy dessa imagem:
services:
testpoint:
image: perfsonar/testpoint:v5.1.4-systemd
container_name: ps-testpoint
cgroup: host
environment:
- container=docker
- TZ=America/Sao_Paulo
network_mode: "host"
restart: unless-stopped
tmpfs:
- /run
- /run/lock
- /tmp
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:rw
- /etc/hosts:/etc/hosts:ro
- /opt/testbed_ps/share:/share
- db:/var/lib/pgsql
- log:/var/log
- psconfig:/etc/perfsonar/psconfig
- pscheduler:/etc/pscheduler
# Para o systemd utilizar o UTC correto:
- /etc/localtime:/etc/localtime:ro
tty: true
volumes:
db:
# Logs dos servicos
log:
# Configs do psconfig
psconfig:
# O pscheduler eh importante para persistir, principalmente, o limits.conf
pscheduler:
Opção em RPM
Os passos a seguir são muitos semelhantes aos mostrados a partir do capítulo "Instalação dos pré-requisitos" em torno da atualização do sistema operacional e do uso do repositório do perfsonar:
Pacote RPM Testpoint
Para ter acesso aos pacotes de instalação do PerfSonar, instale o repositório a seguir:
sudo dnf install -y http://software.internet2.edu/rpms/el9/x86_64/latest/packages/perfsonar-repo-0.11-1.noarch.rpm
Toolkit-security para os Testpoints
Pacote necessário para configuração adequada do Firewall.
Configuração do Firewalld
Verificação das configurações
Configurações e personalizações
Instalando e configurando o Grafana
O Grafana permite visualizar os resultados dos testes e métricas de consumo, através de dashboards. Será usado os pacotes do grafana disponibilizados no repositório do PerfSonar.
Antes disso, é importante que o pacote chkconfig, mencionado no início, esteja instalado.
Pacotes do Grafana:
É necessário iniciar o servidor do grafana manualmente. Para isso, execute:
Aviso
Foi encontrado um problema durante a instalação do chkconfig, que não permite configurar a inicialização automática do grafana.
Recomenda-se tentar instalar o chkconfig antes da instalação da suite do Perfsonar.
Para acessar o Grafana, no browser, aponte para o seguinte endereço:
http://[ip ou hostname do archiver]/grafana
O endereço também é acessível via HTTPS, porém o certificado é self-signed, gerando o aviso de segurança de certificado não reconhecido.
Executando testes unitários nos DTNs e enviando os resultados para o Archive Host.
Para executar os testes de desempenho unitários, através do pscheduler, e enviar os resultados para o servidor central de arquivamento, é necessário
indicar no teste, que será usado um archive externo. O pscheduler irá enviar uma cópia do resultado para o logstash do servidor de arquivamento selecionado.
Criando arquivo JSON, para indicar o servidor de arquivamento destino
Crie um arquivo na conta do usuário, com extensão json. O conteúdo do arquivo deverá ser parecido com o modelo abaixo, apontando para o respectivo servidor de arquivamento.
Exemplo:
/home/[usuario]/archive.json
Conteúdo:
{
"archiver": "http",
"data": {
"schema": 2,
"_url": "https://[hostname ou ip]/logstash",
"_headers": {
"Authorization": "[token de acesso]",
"Content-Type": "application/json"
}
}
}
Autenticação via Token ao Logstash do Archive Host
O token de acesso pode ser visualizado no arquivo presente no Archive Host:
/etc/perfsonar/logstash/proxy_auth.json.
Ele tem o seguinte formato: Basic [hash].
Exemplo:
Token do exemplo:
cGVyZnNvbmFyOlNBTm1DcnlWZHRKY1laRWVGc29r
Autenticação via usuário e senha
Também há a possibilidade de autenticação por login e senha. Neste caso, o arquivo json criado no DTN pode ser gerado através da execução do script abaixo no Archive Host:
{
"archiver": "http",
"data": {
"schema": 3,
"_url": "https://[hostname ou IP]/logstash",
"verify-ssl": false,
"op": "put",
"_headers": {
"x-ps-observer": "{% scheduled_by_address %}",
"content-type": "application/json",
"Authorization":"Basic cGVyZnNvbmFyOjNKQXZ3Q25iZjJmVm9CejlnUHlq"
}
},
"_meta": {
"esmond_url": "https://172.20.5.121/esmond/perfsonar/archive/"
}
}
Aviso
O token do Archive Host é inserido automaticamente na saída como no exemplo.
Uso da autenticação via comando
A partir da criação do arquive.json a partir da saída do script, é possível utilizá-lo diretamente em um comando Pscheduler a partir do parâmetro --archive @/caminho/do/diretorio/[arquivo].json
Uso automatizado com pSConfig
Se os DTNs focados somente na transferência de dados estiverem usando o psConfig, é possível colocar no diretório /etc/perfsonar/psconfig/archives.d/ o json da saída do script acima ou inseri-lo no json dos templates
Liberação de acesso para escrita no Logstash no servidor de arquivamento central
No servidor de arquivamento central, é necessário liberar, no Apache/HTTPD, o acesso ao Logstash para o servidor que irá enviar os resultados.
Para isso, edite o arquivo /etc/httpd/conf.d/apache-logstash.conf, descomentando as seguintes linhas e liberando o acesso pelo ip de origem, da seguinte forma:
<IfModule proxy_module>
...
<Location /logstash>
...
<RequireAny>
...
Require valid-user
...
Require ip [Host IP ou Network IP, do host origem, com Netmask]
</RequireAny>
</Location>
</IfModule>
Reinicie o servidor Apache/HTTPD e Logstash, executando os seguintes comandos:
Acesso ao Grafana
Para acesso ao grafana basta acessar:
https://[hostname ou IP]/grafana
Inicialmente o grafana vai exibir uma página que dá acesso aos dashboards sem a necessidade de realizar login. No entanto, para realizar alterações de configuração, um login de admin é gerado na instalação. Esse login pode ser consultado no diretório:
/etc/grafana/grafana.ini
Na seção security terá algo como:
Se a intenção é acessar o grafana somente a partir do Archive Host então essas configurações já são suficientes.
Abordagem de visualização descentralizada [via DTN]
No entanto, se a abordagem for visualizar os dashboards via DTNs, será necessário a mudança do hostname/IP no plugin OpenSearch do Grafana.
Por padrão a configuração do perfsonar-grafana vem da seguinte forma:
O default é o plugin OpenSearch consultar via localhost. Devido ao Archive Host estar centralizado em outro host, é necessário então a modificação do perfSONAR Local para consultar o hostname/IP correto.
Como o perfSONAR host metrics se trata de métricas locais do DTN, então o acesso deve permanecer como localhost.
Contudo, por padrão as alterações nos campos relacionados aos datasources são bloqueadas mesmo com permissões administrativas.
Desse forma, é necessário a alteração do arquivo datasource perfsonar-local.yml para liberar a edição e/ou para alterar o hostname/IP diretamente.
O diretório encontra-se em:
/usr/lib/perfsonar/grafana/provisioning/datasources/perfsonar-local.yaml
O arquivo terá algo como:
# Configuration file version
apiVersion: 1
# List of data sources to delete from the database.
deleteDatasources:
- name: perfSONAR Local
orgId: 1
# List of data sources to insert/update depending on what's
# available in the database.
datasources:
# <string, required> Sets the name you use to refer to
# the data source in panels and queries.
- name: perfSONAR Local
[....]
# <string> Sets the data source's URL, including the
# port.
url: https://localhost/opensearch
[....]
editable: false
Se quiser que seja editável na web coloque editable: true
e o url: https://[hostname ou IP]/opensearch para o correto.
Após as alterações reinicie o serviço:
Abordagem centralizada
Se a visualização for centralizada, isto é, acessando o grafana do próprio Archive Host, então não há necessidade de alteração, pois o localhost/opensearch irá atender.
Após as alterações acima, o Archive Host já deve estar funcionando.
Edição dos Dashboards
Por padrão, embora os dashboards sejam editáveis, as alterações não podem ser salvas via interface web do Grafana devido a uma restrição de um parâmetro.
Os dashboards são definidos por arquivos JSON. Os dashboards feitos pelo perfSOnar, em especial, estão presentes no diretório:
Por exemplo:
- 📄perfsonar-endpoint-pair-explorer.json
- 📄perfsonar-host-metrics.json
- 📄perfsonar-main.json
Uma das maneiras de editar os dashboards a fim de uma personalização pode ser feita editando via web, e a partir do momento em que é exibido o JSON resultante das alterações este pode ser copiado e colado manualmente no arquivo referente que esteja alterando.
A outra maneira é tirando a restrição a partir da edição do arquivo:
Parâmetro:
allowUiUpdates: true
O padrão é false, altere para true.
apiVersion: 1
providers:
- name: 'perfSONAR Toolkit'
orgId: 1
folder: 'perfSONAR'
folderUid: 'e65dd0fc-fd6d-45c2-a8bb-f6df1186cf66'
type: file
updateIntervalSeconds: 10
allowUiUpdates: true
options:
path: /usr/lib/perfsonar/grafana/dashboards/toolkit
- name: 'My perfSONAR Dashboards Empty Folder'
orgId: 1
folder: 'My perfSONAR Dashboards'
folderUid: 'd94dcbb1-4076-4c61-b947-3194b3881b65'
type: file
options:
path: /usr/lib/perfsonar/grafana/dashboards/empty
Reinicie o serviço para atualizar as alterações:
Host Metrics Centralizado
Caso seja de interesse também ter a visualização das informações dos recursos dos hosts envolvidos nos testes como CPU, memória, serviços online etc, então é necessário a adição do arquivo/URL remoto do pSConfig (cobaia_testes.json) ao agent do Host Metrics (psconfig-hostmetrics-agent)
Dashboard host metrics:
Diretório:
input {
http_poller {
schedule => {
every => "10s"
}
urls => {
"<IP-PSRJ>" => "https://<IP-PSRJ>/node_exporter/metrics"
"<IP-PSSC>" => "https://<IP-PSSC>/node_exporter/metrics"
}
codec => plain
ssl_verification_mode => "none"
request_timeout => 30
metadata_target => "[http_poller_metadata]"
add_field => {
"[type]" => "node"
}
}
http_poller {
schedule => {
every => "30s"
}
urls => {
"<IP-PSRJ>" => "https://<IP-PSRJ>/perfsonar_host_exporter"
"<IP-PSSC>" => "https://<IP-PSSC>/perfsonar_host_exporter"
}
(...)
Exemplo final
A seguir está presente um exemplo utilizando testes periódicos de throughput e latencia.
Configuração JSON pSConfig:
{
"addresses": {
"pssc": { "address": "<IP-PSSC>" },
"psrj": { "address": "<IP-PSRJ>" }
},
"groups": {
"dtn_groups": {
"type": "mesh",
"addresses": [{ "name": "pssc" }, { "name": "psrj" }]
}
},
"archives": {
"ps-archiver": {
"archiver": "http",
"data": {
"schema": 2,
"_url": "https://ps-archiver/logstash",
"_headers": {
"content-type": "application/json",
"Authorization": "cGVyZnNvbmFyOmxqNGJQcGw3OFBtVEZ5aG1tNkpr"
}
}
}
},
"schedules": {
"every_1_hour": {
"repeat": "PT1H",
"slip": "PT15M",
"sliprand": true
},
"every_30_min": {
"repeat": "PT30M",
"slip": "PT10M",
"sliprand": true
},
"every_4_hours": {
"repeat": "PT4H",
"slip": "PT15M",
"sliprand": true
}
},
"tests": {
"throughput_test": {
"spec": {
"source": "{% address[0] %}",
"dest": "{% address[1] %}",
"duration": "PT60S",
"parallel": 8,
"schema": 1
},
"type": "throughput"
},
"owping_test": {
"spec": {
"source": "{% address[0] %}",
"dest": "{% address[1] %}",
"schema": 1
},
"type": "latency"
},
"rtt_test": {
"spec": {
"source": "{% address[0] %}",
"dest": "{% address[1] %}",
"schema": 1
},
"type": "rtt"
},
"latencybg_test": {
"type": "latencybg",
"spec": {
"source": "{% address[0] %}",
"dest": "{% address[1] %}",
"packet-count": 100,
"packet-interval": 0.5,
"schema": 1
}
},
"traceroute_test": {
"type": "trace",
"spec": {
"source": "{% address[0] %}",
"dest": "{% address[1] %}",
"fragment": true,
"schema": 1
}
}
},
"tasks": {
"throughput_task": {
"group": "dtn_groups",
"schedule": "every_4_hours",
"archives": ["ps-archiver"],
"test": "throughput_test"
},
"latencybg_task": {
"group": "dtn_groups",
"archives": ["ps-archiver"],
"test": "latencybg_test"
}
}
}
Gráficos de resultados: