page header photo

november 2015 Archieven

Waarom Configuratiebeheer


Geplaatst door tonk op 2015-11-24 12:40:13 | Permanente link | Categorie: Systeembeheer, Infrastructuur | Reacties: 0

Al jaren gonst in computerland de kreet Configuratie Beheer of, in goed "ICT-Jargon", Configuration Management. Maar, wat is nu configuration management en waarom zou je het moeten doen?

In de beginjaren van de computerwetenschappen waren er hordes hoogopgeleide beheerders nodig om een handjevol systemen te beheren. Met de hand. Naarmate de hardware goedkoper en beter beschikbaar werd, werd ook het vak van systeembeheerder anders. Steeds meer systemen werden door steeds minder mensen beheerd. Hierbij werd fanatiek gebruik gemaakt van scripts die op afstand op een systeem inloggen en die daar dan met veel hocus pocus de zaken regelden. Maar als het aantal systemen blijft groeien is dit op een gegeven moment geen werkbare situatie meer. Het is bijna niet te voorkomen dat het de systemen steeds verder uit elkaar drijven, configuration drift genoemd. Dit is een onwenselijke situatie die voor veel storingen en frustraties zorgt omdat de oplossing van een probleem op het ene systeem niet automatisch de oplossing is op het andere systeem. Er werd dan ook naarstig gezocht naar een manier om dit te voorkomen.

In 1993 bedacht Mark Burgess een oplossing voor dit probleem dat veel beheerders aangaat. Het idee van Burgess was eigenlijk kinderlijk eenvoudig: Het beschrijft wat de status van het systeem moet zijn, in tegenstelling tot het beschrijven van wat er gedaan moet worden. Dit is een omslag in denken die behoorlijk revolutionair is, zowel als concept als in zijn eenvoud. Doordat je namelijk beschrijft hoe het systeem er uit moet zien, kun je met de beschikbare tools ook afdwingen dat die status gehandhaafd wordt en blijft, waardoor de configuration drift tot een minimum beperkt wordt.

De tool die Mark Burgess hiervoor ontwikkelde is The Configuration Engine (CFEngine), de voorvader van alle configuration management tools.

Oké, het is revolutionair, maar waarom zou je het moeten gebruiken? Het antwoord is eigenlijk net zo eenvoudig als het idee van Burgess. Als je een handvol systemen hebt die allemaal identiek zijn, dan kun je dat met een kleine groep mensen nog wel beheren, maar als het aantal systemen explosief groeit naar duizenden dan is dat met ouderwets handwerk niet meer te doen. Configuratiebeheer is op zo'n moment essentieel om de systemen onder controle te krijgen en te houden.

In het begin van de jaren 2000 ging de beheerders-gemeenschap meer en meer aandacht besteden aan configuratiebeheer omdat er steeds meer gedistribueerde systemen kwamen die steeds complexer werden. Na een serie artikelen van LISA (Large Installation System Administration Conference) kwam er een ware explosie van open-source tools beschikbaar.

In de loop der tijd zijn er steeds meer tools ontwikkeld die zijn gebaseerd op de ideeën van Mark Burgess. In 2005 begon Luke Kanies uit ontevredenheid over CFEngine versie 2 met een eigen programma, genaamd Puppet. Momenteel is Puppet is één van de meest gebruikte configuratie beheer tools. Puppet heeft een eigen beschrijvende taal (Domain-specific language, DSL) waarin wordt beschreven wat de status van het systeem moet zijn. Later, in 2009, werd er een afsplitsing van Puppet gemaakt, door Adam Jacob, met de naam Chef. Chef richt zich vooral op Ruby specialisten, waarbij de beschrijvende configuratie taal ook volledig Ruby georiënteerd is. Naarmate de tijd vorderde zijn er meerdere systemen gekomen die allemaal hun specifieke voor- en nadelen hadden. Maar wat al deze systemen gemeen hebben is het concept van convergentie, het steeds dichter naderen van de gewenste situatie. Dit houdt in de praktijk vaak in dat er meerdere malen een run gedaan moet worden om het systeem in de juiste staat te krijgen. Dat dit een nadeel is mag duidelijk zijn, alhoewel het geen onoverkomelijk probleem is. Door de meeste beheerders wordt dit verschijnsel gewoon geaccepteerd.

In 2012 besloot een oud medewerker van RedHat en Puppet Labs, Michael DeHaan, dat dit beter kon en ontwikkelde zijn eigen programma genaamd Ansible. Een erg eenvoudig te gebruiken en te beheren configuratie beheer tool. De kracht van Ansible ligt vooral in het gemak waarmee het gebruikt kan worden en het ontbreken van convergentie. Een slag is voldoende om het systeem volledig te configureren. Hierdoor lijkt het weer op de eenvoud van de ouderwetse scripts maar wel met alle voordelen van configuratie beheer. Ook de taal (YAML) waarmee wordt beschreven in welke staat een systeem zich moet bevinden is erg eenvoudig en snel te leren.

Maar welk tool er door een beheerder gebruikt wordt, maakt in de praktijk vaak niet zoveel uit. Je kiest datgene wat het beste bij jezelf of je omgeving past en waar je je prettig bij voelt. Uiteindelijk is deze technologie ontwikkeld om de bedrijfs-doelen te halen, zoals in een korte tijd een systeem te herstellen of opnieuw op te bouwen, mogelijkheid om systeem-veranderingen te kunnen traceren (audits), een hoog aantal systemen per beheerder en nog vele meer.

In een wereld waarin de systemen voortdurend in beweging zijn, kun je je als beheerder waarschijnlijk wel vinden in de woorden van Tim Bell van CERN die stelt dat er bij het beheren van systemen steeds meer een verandering plaatsvindt van het hebben van huisdieren naar het hoedden van een kudde.

SNMP monitoring via Zabbix


Geplaatst door ivo op 2015-11-03 23:00:22 | Permanente link | Categorie: Systeembeheer, Infrastructuur, Open Source, Open Standaarden | Reacties: 0

Inleiding

In dit blog leg ik uit hoe je auto-discovery kunt gebruiken om meerdere Dell Equallogic systemen in een SAN Group in de gaten te houden. SNMP leest de status van de Equallogic uit. Auto-discovery is een methode die Zabbix biedt om automagisch checks aan te maken op bijvoorbeeld alle aanwezige disks en partities, alle poorten in een netwerk-switch of, zoals in dit verhaal, alle Equallogic systemen in 1 SAN group.

Om het verhaal niet te lang te maken, wordt het opgedeeld in 3 korte blogs.

Deel 1 is hier te vinden.

Deel 2: SNMP

SNMP (Simple Network Management Protocol) is een netwerkprotocol om apparatuur te beheren via het netwerk. SNMP kan worden gebruikt om informatie uit te lezen, maar ook om instellingen te wijzigen. Ook kan een machine zelf via SNMP meldingen versturen, wanneer problemen optreden (traps). SNMP toegang kan (slechts minimaal) worden beveiligd door een wachtwoord te gebruiken voor lees- of schrijftoegang. Dit wachtwoord wordt ook wel 'community' genoemd. Er is meestal een aparte community voor leesacties en voor schrijfacties naar een machine. De community voor alleen lezen is gewoonlijk 'public'.

Elk SNMP element krijgt een OID (Object Identifier) als naam. De OID's zijn ondergebracht in een hierarchische structuur. Elk element uit deze structuur bestaat uit een getal. Elementen worden gescheiden door punten. Veel OID's zijn al voorgedefinieerd, bijvoorbeeld: .1.3.6.1.2.1.1.5 (.iso.org.dod.internet.mgmt.mib-2.system.sysName) geeft de naam van het systeem terug. Een fabrikant kan zijn eigen OID aanvragen om daaronder informatie te kunnen leveren over zijn specifieke systemen.

Om niet te verdwalen in deze brei van nummers worden MIB (Management Information Base) bestanden gebruikt. Hierin staan definities van elk OID, waarbij bij elke OID een naam wordt vermeld, het datatype en de mogelijke waardes, samen met een korte beschrijving. MIB's voor Dell Equallogic systemen kunnen worden gedownload van de Equallogic support site, maar zijn ook te vinden op Internet, als je goed zoekt. Plaats extra MIB bestanden in de directory /usr/share/snmp/mibs.

Zelf gebruik ik mbrowse (zie http://sourceforge.net/projects/mbrowse/) om een apparaat uit te lezen. Mbrowse leest de aanwezige MIB bestanden en toont de namen bij OID's. Mbrowse leest bij het opstarten alle MIB's in de directory /usr/share/snmp/mibs (zoals ook vele andere SNMP utilities).

Een andere manier om informatie van een systeem of apparaat op te vragen via SNMP is via de commandline. Met name snmpwalk en snmpget (onderdeel van het pakket net-snmp-utils op mijn Fedora systeem) zijn handig. Deze programma's kunnen ook in scripts worden gebruikt. snmpwalk wordt gebruikt om vanaf een bepaald OID de hele boom daaronder op te vragen. Met snmpget kun je 1 enkele waarde opvragen. Dit gebruik je als je al precies weet welk OID je wilt bekijken.

Installeer het pakket net-snmp om een SNMP daemon op je PC te draaien. Zorg er voor dat alleen de volgende regels actief zijn in het configuratiebestand /etc/snmp/snmpd.conf:

com2sec notConfigUser   default         public
group   notConfigGroup  v1              notConfigUser
group   notConfigGroup  v2c             notConfigUser
view    roview          included        .1
access  notConfigGroup ""      any       noauth    exact  roview none none
syslocation AT Computing
syscontact Ivo <ivo@localhost>

In dit voorbeeld is een read-only community gemaakt 'public' die alle informatie over het systeem mag lezen. Start de snmp server door middel van: systemctl restart snmpd

Je kunt nu grafische tools, zoals mbrowse, of de command-line tools gebruiken om informatie over je Linux systeem op te vragen. Probeer eens de volgende commando's om te zien wat voor informatie je via SNMP op kunt halen:

  • snmpget -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.1.1.0
  • snmpget -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.1.3.0
  • snmpwalk -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.2.2.1.2

Er zijn veel andere apparaten die je ook via SNMP kunt benaderen, zoals printers, netwerkapparatuur, een UPS, etc. Cacti is een handig programma om statistieken van apparatuur over langere tijd te bewaren en te analyseren. Je kunt van een switch bijvoorbeeld heel eenvoudig de belasting van elke poort afzonderlijk opslaan en bekijken. Zie: www.cacti.net.

In deel 3 gebruiken we Zabbix om een Dell Equallogic systeem te monitoren. Hierbij kunnen bijvoorbeeld alle members van een SAN automatisch bepaald worden.

Zie voor meer informatie over SNMP: