[Nlnog] SNMP en performance impact

[Funs Kessen]

Hi Robert,

On Fri, Jan 14, 2005 at 03:00:03PM +0100, Robert van der Meulen wrote:
> M'n vraag is eenvoudig:
> Ik wil enkele honderden DSLAM's, een paar MGXen, 6400's en 10K's bijna
> volledig leegtrekken via SNMP, op regelmatige basis. Heeft iemand hier
> ervaring met 't leegzuigen van grotere netwerkconfiguraties over SNMP,
> en dan met name impact op performance/load, en/of handige tips om bulk
> SNMP retrievals te doen op 'n zo vriendelijk mogelijke manier?
>
Bij mijn vorige werkgever heb ik voor een SLA project cricket gebruikt
met wat modificasties hier en daar. Ik zou echter niet meer een RRD based
systeem gebruiken, omdat je in de knoop komt zodra je op je rollover point
van je datasources komt. Destijds heb ik ook getest met een SQL backend en
dan transaction based insertion, wat een stuk sneller was. Het enige
probleem was dat de data hoeveelheid nogal groot werd, je zult dan dus
data weg moeten snijden, en dat is een keuze. Wat ook erg belangrijk is
voor je cycle is de hoeveelheid datasources die je wil pollen, hoe meer
data sources hoe langer je cycle.
Wat ook belangrijk is bij de aparatuur die jij wil pollen is dat je
dynamisch een "klant" moet kunnen opzoeken, iig eerder was het zo dat
een klant een moving target was zodra er een kaartje getrokken werd,
op een en hetzelfde device al, Je zult dus klanten moeten "mappen".
Je wil namelijk ook niet dat als een engineer iets modificeert je weer
opnieuw die klant moet gaan configureren op de een of andere manier
in je systeem, dat wordt namelijk veel werk, en vaak gewoon niet gedaan.
Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds
niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn.
Later ben ik ook nog bezig geweest met een threaded engine in combinatie
met een SQL backend, maar de aandacht verslapte nogal snel :)

Mijn vraag hiernaast is dan ook nog wat regelmatige basis is ?, elke vijf
minuten, elke tien minuten, elke minuut ? En wat voor data wil je specifiek
pollen ?

Load wise hoeft het niet veel te zijn, SNMP is heel licht, dus dat is geen
issue, het is vaak de onderliggende crap en slechte implementatie die ervoor
zorgt dat er problemen zijn met SNMP. Veel devices supporten niet echt netjes
bulk retrieval en bouwen voor elke OID die gevraagd wordt de hele table
opnieuw (net-snmp/snmpx/enz). Daar komt het verhaal ook vandaan dat snmp
"zwaar" zou zijn voor sommige devices, de brakke implementatie in de
software van deze devices zorgde er in het verleden nog weleens voor dat
dingen op hun gezicht gingen. De aparatuur die jij boven noemt heeft er
relatief weinig last van, er zijn mensen die zeggen van wel, maar het spelen
met de devices leert mij dat de retrieval van SNMP data niet voor problemen
zorgt.

Grtz,

Funs

-- 
Funs Kessen
funsk at nl.demon.net