forståelse af netværksstyringsprotokoller

Netværksstyringsprotokoller: en Guide til forståelse af dem

forståelse af netværksstyringsprotokoller kan være en vanskelig opgave.

det er let at gå glip af det tekniske udtryk, de forskellige procedurer, de forskellige måder at formatere dataene på, de flere muligheder osv.

for at lette denne opgave foreslår vi, at du følger denne enkle vejledning.

netværksstyringsprotokoller er netværksprotokoller

netværksadministrationsprotokollerne arbejder inden for netværk og er derfor netværksprotokoller.

nu er det vigtigt at skelne dem fra de netværksprotokoller, der tillader overførsel af data mellem to enheder, såsom TCP, UDP, SMTP, CSMA / CD osv.

i et netværk vil både dataoverførselsprotokoller og administrationsprotokoller eksistere sammen og dele ressourcer som CPU og linkbåndbredde.

det er derfor interessant at huske på, at netværksstyringsprotokoller også påvirker platformens samlede ydeevne.

vær klar over protokollens tilgang

det er let at forstå, at jo mere kompleks og heterogen platformen er, desto større vanskeligheder finder vi i administrationen.

netværksadministration har stået over for denne kompleksitet fra tre vinkler:

• fejl: på dette område er ideen at have procedurer til at opdage fejl og en ordning til at rapportere dem.
• præstation: her er ideen at få data om platformens opførsel, der giver os mulighed for at drage konklusioner om udførelsen af den.
• handlinger: mange administrationsprotokoller omfatter evnen til at udføre handlinger på administrerede elementer.
  når vi prøver at forstå en protokol, er det vigtigt at stoppe et øjeblik og tænke over, hvilken vinkel protokollen foreslår, eller med hvilken vinkel vi vil bruge den.

netværksstyringsprotokoller og deres arkitektur

alle administrationsprotokoller foreslår en arkitektur og procedurer til at udtrække, indsamle, overføre, gemme og rapportere ledelsesoplysninger fra de administrerede elementer.

det er vigtigt at forstå arkitekturen og procedurerne, når det kommer til at forstå en ledelsesprotokol, og uundværlig, når man implementerer en løsning baseret på denne protokol.

netværksstyringsprotokoller og organisering af data

et andet grundlæggende punkt er den måde, hvorpå netværksadministrationsprotokollerne formaterer og administrerer styringsdataene.

grundlaget er, hvordan de definerer og identificerer de elementer, der skal administreres. Det er altid interessant at nævne: hvilket element kan jeg administrere med denne protokol? Kun udstyr eller dækker det også applikationer?

så handler det om at definere, hvilke oplysninger jeg kan udtrække fra de administrerede elementer, og hvilke handlinger jeg kan udføre, hvis jeg kan udføre nogen.

hvilket format bruges til at håndtere dataene? Og hvordan det opbevares, hvis det opbevares.

endelig, Hvad er de muligheder, jeg har for at få adgang til disse oplysninger?

nu vil vi i resten af denne artikel gennemgå tre af de mest populære administrationsprotokoller og forsøge at koncentrere os om de ovennævnte punkter: fokus, arkitektur og dataorganisation.

til denne gennemgang vil vi tage følgende diagram som vejledning:

Diagram: administration af netværk og deres protokoller.

ICMP

ICMP (Internet Control Message Protocol) er en netværkslagsprotokol, der er en del af gruppen af underprotokoller, der er knyttet til IP-protokollen.

ICMP arbejder inden for fejlvalidering og tillader også beregning af visse præstationsmålinger.

læseren kan læse om de detaljerede specifikationer for protokollen i RFC792.

proceduren foreslået af ICMP er baseret på påvisning af en fejltilstand og afsendelse af en meddelelse, der rapporterer tilstanden.

nøgleelementet er således de meddelelser, der overvejes af ICMP, som normalt klassificeres i to kategorier:

• fejlmeddelelser: bruges til at rapportere en fejl i pakketransmissionen.
• kontrolmeddelelser: bruges til at rapportere om status for enheder.

arkitekturen, som ICMP arbejder med, er meget fleksibel, da enhver enhed i netværket kan sende, modtage eller behandle ICMP-meddelelser.

i praksis bruges den til routere og skifter til at rapportere til værten, der stammer fra en pakke, at pakken ikke kan leveres på grund af en netværksfejl.

derudover bruges ICMP også til at udføre beregninger af målinger på ydeevne, såsom niveauer af latenstid, responstid eller pakketab, blandt andre.

SNMP

SNMP (Simple Netværksstyringsprotokol) er en applikationslagsprotokol, der dækker områderne fejl, ydeevne og handlinger.

SNMP tilbyder en ordning til at indsamle, organisere og kommunikere ledelsesinformation mellem de enheder, der udgør et netværk.

denne ordning formår at være fælles for et stort antal udstyrskomponenter, der understøtter:

• mangfoldighed af enheder: fra netværksenheder såsom routere, afbrydere, brandvægge eller adgangspunkter til slutbrugerenheder såsom printere, scannere, stationer eller servere.
• mangfoldighed af mærker: de fleste mærker, når de præsenterer et produkt, skal du sørge for, at dette produkt har support til SNMP inkluderet.

læseren, der er interesseret i at læse de formelle SNMP-SPECIFIKATIONER, skal gennemgå flere RFC-dokumenter, men vi anbefaler, at du starter med RFC 1157.

arkitektur SNMP

SNMP-arkitekturen er baseret på to grundlæggende komponenter: SNMP-agenter og SNMP-administratorer. I det følgende diagram præsenterer vi en grundlæggende oversigt over denne SNMP-arkitektur:

beskrivelse: SNMP Basic Architecture

SNMP-agenter er stykker af programmer, der kører på de elementer, der skal styres. De er ansvarlige for at indsamle data på enheden. Når SNMP-administratorer derefter anmoder om sådanne data gennem forespørgsler, sender agenten det tilsvarende.

SNMP-agenterne kan også sende SNMP Manager-oplysninger, der ikke svarer til en forespørgsel, men den del af en begivenhed, der opstår i enheden, og som skal meddeles. Derefter siges det, at SNMP-agenten proaktivt sender en meddelelsesfælde.

SNMP-administratorerne findes som en del af et styrings-eller overvågningsværktøj og er designet til at fungere som konsoller, hvor alle de data, der er fanget og sendt af SNMP-agenterne, er centraliseret.

organisering af dataene i SNMP

i SNMP kaldes de elementer, der skal styres, objekter.

OID ‘ erne (Object Identifier) er de elementer, vi bruger til entydigt at identificere objekter. Du vil helt sikkert have set OID ‘ er i et talformat som:

faktisk udvindes disse tal fra et system med hierarkisk organisation, der starter med at identificere producenten af enheden, for derefter at identificere enheden og til sidst objektet. I det følgende billede ser vi et eksempel på ordningen:

beskrivelse: netstrøm arkitektur
taget fra: https://www.networkmanagementsoftware.com/snmp-tutorial-part-2-rounding-out-the-basics/

MIBs (Management Information Base) er de formater, som de data, der sendes fra SNMP-agenterne til SNMP-lederne, vil overholde.

i praksis har vi en generel skabelon med det, vi har brug for til at styre enhver enhed og derefter have individualiserede MIB ‘ er for hver enhed med deres særlige parametre og de værdier, som disse parametre kan nå.

hvis du har brug for at lære mere om SNMP og overvågning baseret på denne protokol, inviterer vi dig til at gennemgå i denne blog artiklen skrevet af Carla Andr Kruss om emnet.

HMI

med HMI vil vi bevæge os i universet sammensat af enheder, der kører nogle HMS-operativsystemer, og af de applikationer, der afhænger af dette operativsystem.

faktisk foreslår vi en model, så vi kan repræsentere, indhente, gemme og dele ledelsesinformation om Vinduer-baseret udstyr og programmel, både lokalt og eksternt.

på den anden side tillader VMI ud over hvad der er forbundet med ledelsesinformation også udførelse af visse handlinger.

MMI-arkitektur

MMI-arkitekturen består af tre grundlæggende enheder. Lad os se på følgende diagram:

beskrivelse: grundlæggende arkitektur MMI

MMI-udbydere: en leverandør er et stykke, der har ansvaret for at indhente ledelsesinformation fra et eller flere objekter.

vi fungerer som mellemled mellem leverandører og styringsværktøjer. Hans ansvar omfatter følgende:

• at indhente de data, der genereres af leverandører på en planlagt måde.
• for at opretholde et lager med alle de data, der er opnået på en planlagt måde.
• for dynamisk at finde de data, der anmodes om af administrationsværktøjerne, for hvilke der først foretages en søgning i depotet, og hvis de ønskede data ikke findes, foretages en søgning blandt de relevante udbydere.

administrationsapplikationerne svarer til de applikationer, tjenester eller scripts, der bruger og behandler oplysningerne om de administrerede objekter.

vi formår at tilbyde en ensartet grænseflade, hvorigennem applikationer, tjenester og scripts kan fås, der anmoder om data og udfører de handlinger, der er foreslået af vores udbydere på de objekter, der skal administreres.

organisering af data i arbejdsprogram

arbejdsprogram er baseret på CIM (Common Information Model), som er en model, der bruger objektbaserede teknikker til at beskrive forskellige dele af en virksomhed.

dette er en meget brugt model i Microsoft-produkter; faktisk installeres udvidelsen af den model, der svarer til produktet, automatisk, når Microsoft Office eller en Udvekslingsserver er installeret.

bare den udvidelse, der følger med hvert produkt, er det, der kaldes MMI-klasse. En klasse beskriver det objekt, der skal styres, og alt hvad der kan gøres med det.

denne beskrivelse starter fra de attributter, som klassen håndterer, såsom:

• egenskaber, der henviser til objekternes egne egenskaber, f.eks.
• metoder, der henviser til de handlinger, der kan udføres på objektet, såsom at holde i tilfælde af et objekt, der er en tjeneste.
• foreninger, der henviser til mulige foreninger mellem objekter.

nu, når vi bruger objektklasser til at indsamle ledelsesoplysninger, og disse oplysninger overføres til vores infrastruktur, er det nødvendigt at organisere det på en eller anden måde.

denne organisation opnås gennem logiske containere kaldet navneområder, som er defineret af administrationsområde og indeholder de data, der kommer fra de relaterede objekter.

navnerum defineres under et hierarkisk skema, der minder om skemaet efterfulgt af mapper på en disk. Så navneområdet rod er toppen af denne hierarkiske ordning, og root/CIMv2 er standard navneområdet.

en analogi, som mange forfattere bruger til at forklare organisationen af data i arbejdslivet, er at sammenligne arbejdslivet med databaser.

så vi ved, at klasserne svarer til tabellerne, navneområderne til databaserne og infrastrukturen til databasehandleren.

så dette er gennemgangen af netværksadministrationsprotokoller. For at afslutte skal vi angive, at alle overvågningsværktøjer bruger mindst en netværksadministrationsprotokol for at nå deres mål.

Pandora FMS arbejder med disse tre protokoller for at tilbyde et bredt og fleksibelt overvågningsværktøj til generelle formål.

hvis du stadig ikke kender de mange fordele, som Pandora FMS kan tilbyde din organisation, og den har mere end 100 enheder at overvåge, skal du tale med salgsteamet hos Pandora FMS for at få en gratis prøveversion af det mest fleksible overvågningsprogram på markedet: https://pandorafms.com/free-demo/

husk også, at hvis dine overvågningsbehov er mere begrænsede, har du OpenSource-versionen af Pandora FMS til rådighed. Find mere information her: https://pandorafms.org/

tøv ikke med at sende dine spørgsmål. Vores Pandora FMS team vil være glade for at hjælpe dig!