Systemdokumentation

Følgende beskriver en netværksudforskningsapplikation, der også fungerer som et datavarehus, og har en indbygget analyseplatform. Systemet indhenter selvstændigt status fra netværksswitche, opsamler informationer om deres geografiske placering og deres tilstand samt forbindelsernes status. Formålet med systemet er at give et omfattende overblik over netværksinfrastrukturen, muliggøre hurtig fejlidentifikation og tilbyde historiske dataanalyser.

Systemarkitektur

Netmap Systemet er opdelt i flere moduler, der hver især varetager specifikke opgaver.

  • Dataindsamling og -berigelse. Indhenter og transformerer realtidsdata fra switche. Der anvendes her Simple Network Management Protocol (SNMP) til at kommunikere med netværksswitche og hente statusdata. Der tilkobles her geografisk information baseret på IP-adresser, samt anden metadata.
  • Datavarehus. Data fra indsamlingen og behandlingen lagres her struktureret til analyse-og rapporteringsformål. Dette er en centraliseret PostgreSQL database, hvor alle data gemmes.
  • Netmap analytics. Denne omfatter geografiske kort, analyse dashboards og APIer til at udforske netværksdata.

Netmap platformen er derfor en dataindsamlings- og lagringsapplikation i samme grad som et netværksvisualiseringsværktøj. Applikationen er designet til at være letvægt, samt at kunne let integreres mod andre applikationer. Den fulde datarejse fra primærkilde til slutbruger ses nedenfor:

Dataflowet er designet til aldrig at gå opstrøm fra individuelle komponenter, og Netmap er derfor en ikke-invasiv applikation.

Dataindsamling

Dataindsamlingsprocessen starter med SNMP-agenten, der er ansvarlig for at kommunikere med netværksswitchene. Ved hjælp af Simple Network Management Protocol (SNMP) sender agenten periodiske forespørgsler (polling) til de konfigurerede switche. Formålet med disse forespørgsler er at hente detaljerede oplysninger om switchenes aktuelle status, herunder:

  • Switchens status: Information om, hvorvidt switchen er oppe eller nede.
  • Portstatus: Information om hver enkelt ports tilstand og aktivitetsniveau.
  • Tilsluttede enheder: Information om enheder, der er tilsluttet til switchens porte, herunder deres IP-adresser.

SNMP-agenten konfigureres med vigtige parametre som community strings, der sikrer autorisation af forespørgsler, og en liste over IP-adresser for de switche, der skal overvåges. Polling-intervallet bestemmes for at finde en balance mellem dataaktualitet og systembelastning, typisk med en frekvens på hvert 5. minut.

Udover SNMP-agenten anvender systemet en geolokationsservice til at indhente geografisk information baseret på switchenes IP-adresser. Denne service bruger eksterne geolokations-API'er eller interne databaser til at bestemme og tilføje geografisk placering til de indsamlede data.

Databehandling

Når data er indsamlet, overgår de til databehandlingsfasen, som består af flere trin. Det første trin i databehandlingen er parsering. Parseren fortolker de SNMP-responser, som SNMP-agenten har modtaget fra switchene. Under parseringen omdannes rådata til et struktureret format, der kan lagres i datavarehuset. Parseren er designet til at håndtere forskellige MIBs (Management Information Bases) for at udtrække relevante oplysninger såsom switchens status, portstatus og trafikdata.

Efter parsering gennemgår data en berigelsesproces, hvor yderligere information tilføjes. Berigelsen omfatter flere vigtige aspekter:

  • Geografisk placering: Dataen beriges med den geografiske information, som geolokationsservicen har leveret.
  • Tidsstempler: Hvert datasæt forsynes med tidsstempler, der angiver præcist, hvornår dataene blev indsamlet.
  • Netværksmetadata: Yderligere netværksrelaterede oplysninger tilføjes, såsom information om netværkstopologi og specifikke konfigurationer for de enkelte switche og forbindelser.

Den kombinerede dataindsamlings- og databehandlingsproces sikrer, at de rå data, der indhentes fra netværksswitchene, omdannes til rige og strukturerede datasæt. Disse datasæt er klar til at blive lagret i datavarehuset, hvor de kan anvendes til videre analyse, visualisering og rapportering. Resultatet er et omfattende, nær-realtidsbillede af netværksinfrastrukturen, der giver mulighed for dybdegående indsigt og effektiv netværksstyring.

Netmap Datavarehus

Datavarehuset anvender en MariaDB til at lagre oplysninger om netværket. Alle modifikationer i databasen foretages af poller-komponenten, og der findes derfor ikke noget forretningslogik i datavarehuset i sig selv.

Datavasehusets struktur tager afsæt i Microsofts' best practice anvendelse af meta-kolonner til at lagre data over tid (Se Sandbox eksempel her). Der er dog foretaget designvalg, der afviger fra Microsofts struktur. Der findes herved fire metadatakolonner:

  • Meta_ValidFrom: Starttidspunktet for hvornår et datapunkt er gældende. Den første observation for et datapunkt vil være d. 01/01/1970 kl. 00.00.000.
  • Meta_ValidTo: Sluttidspunktet for hvornår et datapunkt er gældende. Den sidste observation for et datapunkt vil være d. 31/12/9999 kl. 23.59.000.
  • Meta_LastChecked: Dette er tidspunktet for den sidste forsøgte opdatering af datapunktet. Hvis der ikke er sket nogen ændring, vil denne opdateres til datotidsstemplet for den forsøgte opdatering.
  • Meta_IsCurrent: Denne har en boolean-værdi, som er sand, hvis datapunktet er det nuværende. Alle gamle datapunkter vil have værdien falsk.

Herved kan nutidsrelevante data hentes fra datavarehuset ved at adspørge mod meta_is_current:

SELECT * FROM nodes WHERE meta_is_current = TRUE

Historisk data hentes fra datavarehuset ved at forsyne et datotidsstempel:

SET @point_in_time = NOW(); // Erstat med eget datotidsstempel
SELECT * FROM nodes
WHERE meta_valid_from > @point_in_time
AND meta_valid_to <= @point_in_time;

Netmap tilgår datavarehuset direkte gennem en SQL bruger. Det fulde databaseskema for datavarehuset ses nedenfor:

Gule kolonner viser meta-kolonnerne, der benyttes til at filtere data over tid.

Netmap analytics

Netmap Analytics er et webbaseret interface, der giver brugere realtidsadgang til netværksstatus og forretningsvendte analyser. Funktionaliteter inkluderer:

  • Geografisk kort: En geografisk visualisering af netværket.
  • Analyseplatform: Analysedashboards på netværks-, klynge- og nodeniveau.
  • APIer: APIer til udstilling af data omkring netværkskomposition, analyseresultater og konfigurationer af applikationen selv. Der findes tilhørende OpenAPI dokumentation (Se dokumentation her).
  • Konfigurationspanel: Et interface til konfiguration af branding af Netmap og visning af beskeder. Gå til konfigurationspanel.

Netmap analytics er designet til at integrere med datotids-kolonnerne fra datavarehuset, således at alle sider kan vises, som de fremstod på et tidligere tidspunkt. Der er derfor både mulighed at se et nu-og-her operationelt overblik over netværket, såvel som et tilbageblik på en given driftssituation.

Netværkstyper

Netværkstypen for en klynge defineres ud fra de forbindelser der eksisterer i netværksklyngen. Der findes fire typer af netværk, slange, cirkel, hub-and-spoke og mesh. Alle typer beskrives her sprogligt og matematisk. Der introduceres til dette formål følgende definitioner:


$n$: Dette repræsenterer antallet af noder i en netværksklynge.

$\sigma_i$: Dette repræsenterer antallet af forbindelser, som en node $i$ har. Da kun netværksenheder forbundet til klyngen inkluderes, vil denne aldrig være 0.

$ \vec {v [\sigma_i]} $: Dette repræsenterer en vektor, der indeholder antallet af forbindelser for hver node i klyngen.

Snake

En netværksklynge er en slange, hvis alle netværksenheder i klyngen har to forbindelser, med undtagelse af to. Disse to er enderne på slangen. En klynge defineres som en slange hvis nedenstående udtryk er sandt.

$$\frac{(\sum_{i=1}^n \sigma_i) + 2}{n} = 2$$

Circle

En netværksklynge er en cirkel, hvis alle netværksenheder i klyngen har to forbindelser. En klynge defineres som en cirkel hvis nedenstående udtryk er sandt.

$$ \max{( \vec {v [\sigma_i]} )} = \min{( \vec {v [\sigma_i]} )} = 2 $$

Hub-and-spoke

En netværksklynge er en hub-and-spoke, hvis en enkelt node har forbindelser til alle andre noder i klyngen. Bemærk at netværksklyngen kun defineres som en hub-and-spoke, hvis der kun er én enkelt node, der har forbindelser til alle andre noder. En klynge defineres som en hub-and-spoke hvis nedenstående udtryk er sandt.

$$ \text{count}(1, \frac{\vec {v [\sigma_i]}}{(n-1) \vec {1}_{v [\sigma_i]}}) = 1 $$

Mesh

Hvis ikke en af de tre ovenstående netværkstyper passer, vil netværket være et mesh-netværk.

Netværksrobusthed

Der udregnes i forbindelse med netværksrobustheden to udtryk. Netværkets samlede robusthed er derfor en funktion af de to variable. Denne beregning foretages som det eneste i Netmap Analytics kun én gang i døgnet, da den er beregnelsesmæssigt tung.


Redundans

Redundansen af en node defineres til at være antallet af enheder, noden er forbundet til. Der er derfor et udtryk for hvor mange indfaldsveje en given datapakke vil have til den givne node. Redundansscoren udtrykkes som et heltal der repræsenterer antallet af noder, der er forbundet med noden.


Vigtighed

Vigtigheden af en enkelt node udregnes ved at sammenholde distancen mellem alle noder i netværket iterativt. På baggrund af dette udregnes der en samlet gennemsnitlig rejsetid for en given datapakke et tilfældigt sted i netværket. Herefter fortages der en simulering af netværken uden en given node, og forskellen i de to værdier er det samlede effektivitetstab ved at fjerne den given node. Denne process gentages for samtlige noder i netværket.

Se matematisk redegørelse her.

Opsummering

Dette netværksovervågningssystem med datavarehus giver en omfattende løsning til at overvåge og analysere netværksinfrastruktur. Ved at kombinere realtidsdataindsamling, geografisk information og historisk analyse, tilbyder systemet en stærk platform for netværksadministration og beslutningstagning.