Un sistem bazat pe evenimente, protocoalele de management al rețelei funcționează foarte diferit de sistemele bazate pe interogări.
În orice caz, sistemul de management al rețelei ascultă pur și simplu eventualele anunțuri sau evenimente
care trebuie trimise prin cablu.
În mod obișnuit, protocoalele de gestionare a rețelei care folosesc aceste tipuri de evenimente sunt fie bazate pe log, fie
pe bază de baze de date.
Acum sunt controlabile în ceea ce privește cantitatea de detaliu pe care o primiți de la dispozitive din rețeaua dvs.
De exemplu, pe un Cisco Rodda ați putea permite depanarea care produce o cantitate foarte mare de date.
Există o mulțime de detaliu de nivel scăzut care este generat de depanare.
Este posibil să nu doriți în mod necesar acea cantitate de date împinse în sistemul de gestionare a rețelei.
Una dintre problemele de aici este dacă primiți o cantitate mare de date care va trece prin
datele pentru a lua decizii semnificative cu privire la datele primite.
Deci, nu doriți să activați o mulțime de informații bazate pe eveniment, aceleași care să vă ajute să
privească unul dintre avantajele sistemelor bazate pe evenimente, este că aceștia pot reacționa foarte repede.
Cu alte cuvinte, dacă un eveniment are loc în rețea, sistemul de gestionare a rețelei poate acționa
imediat asupra acelui eveniment în loc să aștepte expirarea unui interval de sondaj.
De exemplu, dacă interogați o interfață a router-ului pentru starea sa la fiecare cinci minute, atunci veți
ști că interfețele se fac ori de câte ori sondajul este efectuat sau interogarea se face într-un sistem bazat pe interogări.
Dar, dacă interfața coboară imediat după ce ați interogat, poate dura mai mult de cinci minute pentru
a vă da seama că interfața a scăzut atunci când sistemul dvs. de management al rețelei trage ruterul la fiecare
cinci minute.
Acesta va primi un răspuns pozitiv din partea Rodda, care confirmă faptul că interfața este sus ca un exemplu.
Asta se face de obicei folosind protocoalele de management al rețelei, cum ar fi Ace și MP.
Deci știți că interfața este operațională pentru că ați întrebat router-ul dacă nu primiți un răspuns de la router,
atunci știi că există o problemă.
Dar dezavantajul unui sistem bazat pe interogări este acela că îl chemați la fiecare cinci minute.
Dacă interfața a coborât imediat după ce ați tras ruterul, ar putea dura până la cinci minute
pentru a vă da seama că există o problemă la interfața acelui router în care, ca
în orice sistem bazat pe evenimente și este un mesaj de jurnalizare a capcanelor goale, interfața coboară.
Deci, în acest caz, router-ul informează sistemul de management al rețelei că există o problemă
mai degrabă decât ca sistemul de management al rețelei să aștepte un interval de cinci minute pentru a
interoga Rodda pentru starea unei interfețe.
Acum, există un dezavantaj pentru sistemele bazate pe evenimente, protocoalele de gestionare a rețelei nu sunt fiabile, deoarece sistemul
de management al rețelei este pur și simplu în așteptare pasivă și ascultare pentru evenimentele care urmează să fie trimise la ea.
Nu ar ști dacă există o problemă în rețea dacă evenimentul nu a ajuns la sistemul de
gestionare a rețelei.
Deci, dacă există o problemă de rețea sau o necesitate de a face față a scăzut care împiedică mesajul
de jurnal sau o capcană goală de la ajunge la sistemul de gestionare a rețelei sistemul de management de rețea nu
ar fi conștient de problemă, fără a polling în mod explicit dispozitivul de rețea.
Deci, care sunt cele mai bune practici ce ar trebui să faci într-un mediu live despre modul în care cele
mai bune practici precizează că ar trebui să folosiți ambele ar trebui să utilizați protocoale de gestionare bazate pe interogări sau interogări bazate
pe evenimente, ca parte a soluției de gestionare a rețelei.
Acum nu ajută doar să primească o cantitate mare de date.
Trebuie să luați decizii cu privire la aceste date.
De asemenea, doriți să introduceți semne de avertizare și rapoarte, astfel încât ambele să fie anunțate
atunci când apare o problemă dacă se bazează pe un mecanism de detectare bazat pe interogări sau pe o detectare bazată pe evenimente.
În plus, veți dori o anumită capacitate de raportare, care vă oferă detalii despre
performanță nu numai în timp real.
În acest moment, dar într-o perioadă de timp.
Deci, doriți date istorice disponibile, astfel încât să puteți lua decizii semnificative.
Ca exemplu, dacă o interfață pe o Rodda are o utilizare de 70% este atât de bună.
Ce e rău.
Este greu de știut dacă nu aveți date istorice care vă permit să construiți o linie de bază a
rețelei pe care rulează în mod obișnuit rețeaua dvs.
Dacă această interfață în ultimele trei luni a fost utilizată la o utilizare de 2% și
acum dintr-o dată se execută la o utilizare de 90%, veți ști că sa întâmplat ceva în
rețeaua dvs. care sa schimbat dramatic în utilizarea interfeței.
Deci, veți dori ca rapoartele să vă ofere detaliile de performanță în timp, precum și să vă anunțe
despre problemele și disponibilitatea dispozitivelor din rețeaua dvs.
Veți dori să vedeți dintr-o singură privire posibilitatea de a vedea dacă există o problemă cu un
dispozitiv de rețea, cum ar fi un router, sau dacă există o problemă cu o interfață individuală pe unul dintre rutere.
Nu uitați să setați frecvența de sondare și cât de granular sunt notificările despre eveniment.
Acest lucru va varia de la un mediu la altul și de multe ori depinde de tipul de tipologie
pe care o aveți la dispoziție și de resursele pe care trebuie să le detectați și apoi acționați asupra informațiilor pe care
le primiți.
În plus, este posibil să trebuiască să luați decizii cu privire la cât de repede trebuie să reacționați la
o problemă din rețeaua dvs., dacă se întâmplă ceva în rețeaua dvs. și efectuează o clădire întreagă pentru întreaga organizație pe care
veți dori să o acționați rapid.
Dar dacă se întâmplă ceva și afectează numai un singur dispozitiv care nu este important, probabil că
nu este la fel de important să te trezești la ora 3 dimineața pentru a-ți spune că portul de pe
comutator a coborât.