Storage Area Network's (SAN's)

Een SAN bestaat uit een (groot) aantal disken in een zogenaamd storage array. Bij een groot aantal kunt u denken aan 10 tot enkele honderden schijven. Met de huidige opslagruimte per disk kan een SAN al snel in de vele terabytes gaan lopen (1 terabyte = 1024 gigabyte).

Deze disken zijn verbonden aan één of meerdere diskcontrollers. Dit kan op basis van SCSI, iSCSI, Fibre channel, SATA of een andere technologie. De controllers zijn op hun beurt via Fibre channel verbonden aan één of meerdere SAN switches. Hierop zijn ook de servers aangesloten, via zogenaamde HBA's (Host Bus Adapters).

Backup

Aan een SAN zitten ook vaak tapelibraries gekoppeld voor backup doeleinden. Zo'n backup kan dan gebeuren door het SAN zelf. De data wordt door het SAN verplaatst van de disken naar de tape, zonder tussenkomst van een server. Op die manier hebben de server en het LAN geen last van de load die een backup meestal met zich meebrengt.

Een SAN zorgt er dus voor dat disken en tapedrives die normaal in elke server zijn geïnstalleerd, worden gebundeld in 1 pool van disken en tapedrives.

Virtuele disken

Het SAN zorgt voor het aanbieden van disken aan het operating system op de servers. Dit gebeurt meestal niet 1 op 1. Op de disk controller van het SAN worden meestal virtuele disken gemaakt op basis van RAID technologie.

Zo kunnen bijvoorbeeld 8 disken van 72GB in een RAID5 configuratie worden aangeboden als 1 virtuele disk van 500GB. Het operating system ziet dan 1 disk en weet niet dat de disk eigenlijk uit meerdere fysieke disken bestaat.

Cloning en snapshotting

Typische SAN functionaliteit is cloning en snapshotting. Hiermee is het mogelijk om data te "bevriezen". De data wordt dan gedurende een bepaalde tijd niet gewijzigd, zodat er bijvoorbeeld een backup kan worden gemaakt.

Bij cloning wordt het SAN de opdracht gegeven een exacte kopie te maken van een (virtuele) disk. Dit lijkt op het maken van en RAID1 mirror disk. Deze clone kan dan van het SAN worden afgesplitst, zodat er een backup van kan worden gemaakt. Ook kan op deze manier bijvoorbeeld een kopie van data van een productieomgeving worden gemaakt voor testdoeleinden.

Snapshotting lijkt op cloning, alleen is snapshotting wat intelligenter. Bij een snapshot wordt door het SAN een punt in de tijd genomen waarop er geen schrijfacties meer naar een disk worden gedaan. In plaats daarvan wordt de weg te schrijven data naar een ander stukje disk geschreven. Als een gebruiker dan een stukje data leest, dat vlak daarvoor is weggeschreven naar de tijdelijke plek, zal het SAN het aanbieden uit de tijdelijke plek.

Omdat gedurende de snaphot tijd niet wordt geschreven naar de originele data, is er tijd om een backup te maken. Zodra het snapshot wordt opgeheven, wordt alle data weer naar de originele plaats geschreven en wordt de tijdelijke plek weer vrijgegeven.

Het grote voordeel van snapshots ten opzichte van clones is dat het maken van een clone relatief veel tijd en ruimte kost (alle data moet worden gekopieerd). Een snapshot is beschikbaar op het moment dat het wordt aangevraagd, en als het snapshot niet al te lang in stand hoeft te blijven, kost het ook weinig diskruimte.

Software

Al bovenstaande zaken worden geregeld met speciale SAN management software. Dit is het gebied waarop de SAN aanbieders zich onderscheiden. Het gemak waarmee taken op het SAN kunnen worden uitgevoerd is sterk afhankelijk van de mogelijkheden van de software.

Vendors

Grote SAN aanbieders zijn HP (EVA serie), EMC, IBM en Hitachi.

Systeembeheer documentatie

Als beheerders ergens een broertje aan dood hebben, is het wel aan het schrijven en bijhouden van documentatie. De ervaring leert dat documentatie na de (verplichte) oplevering zelden wordt bijgehouden.

Dit komt meestal door twee redenen:

• De beheerders zien het nut van de documentatie niet in, want ze hebben er weinig profijt van;
• De documentatie is lastig aan te passen en het is ondankbaar werk.

Het is daarom zaak aan beide aspecten aandacht te besteden. Documentatie is voor beheerders handig als ze snel de informatie kunnen vinden die ze zoeken.

Zoeken

Een mooi voorbeeld is Google. In Google kun je een antwoord op een technische vraag meestal binnen 30 seconden vinden, door het ingeven van goede steekwoorden. Het opzoeken van informatie in documentatie op een netwerkschijf, met een meestal moeilijk te doorgronden directory tree, duurt veel langer. Dit frustreert gebruikers, zodat men het wiel liever opnieuw uitvindt dan dat men de documentatie raadpleegt.

Het aanpassen van documentatie begint ook met het zoeken naar de documentatie. Zoals hierboven beschreven, is dit de eerste hinderpaal. Bovendien is na het aanpassen van documentatie niet duidelijk wat er nu precies is veranderd en wie dat heeft gedaan. Om deze redenen wordt documentatie meestal helemaal niet bijgewerkt.

Wiki's

Moderne technieken kunnen deze problemen voor een groot deel oplossen. Het gebruik van Wiki’s met een zoekfunctie bijvoorbeeld, lost bovenstaande problemen op. Het succes van wiki’s is het best af te lezen aan de vrije tijd die vele mensen steken aan het vrijwillig documenteren op http://www.wikipedia.org

Murdoc

Ook mijn open source project Murdoc is een handig systeem om documentatie bereikbaar te maken. Het is zelfs mogelijk om systemen zichzelf automatisch dagelijks te laten documenteren.

Murdoc bevat ook een standaard directory indeling waarmee systeembeheer documenten kunnen worden gerangschikt.

Naamgeving IT architecten

IT architect is een relatief nieuw beroep. En omdat het zo nieuw is, is er weinig consensus over een aantal basis zaken. Een van die zaken is de naamgeving van de IT architect.

Namen die op het internet aan IT architecten worden gegeven zijn bijvoorbeeld:

• Enterprise architect
• Informatie architect
• Software architect
• Infrastructuur architect
• Security architect
• Project architect
• Systems architect
• Application architect

Uiteraard is het voor niemand echt duidelijk wat deze mensen precies doen en waar hun expertise precies ligt. Ik houd me zelf graag aan de volgende rolverdeling, zoals die is voorgesteld door het GIA, het Genootschap voor Informatie Architecten en het SCIA, Society for the Certification of Information Architects:

• Informatie architect -- Bij deze architect staat informatie als productiefactor cq. bedrijfsmiddel centraal. Dit zijn de mensen die weten wat informatie in een organisatie is en hoe een organisatie passende oplossingen kan vinden voor problemen in hun behoefte aan informatie.
• IT-Business architect -- Deze mensen houden zich bezig met de manier waarop een met IT ingerichte informatievoorziening past bij een organisatie (alignment, het IT-landschap).
• IT architect -- Deze mensen zijn gespecialiseerd in het inrichten van IT infrastructuren.

IT architecten hebben dan hun eigen expertise terreinen. Zo zijn er IT architecten die zijn gespecialiseerd in software ontwikkeling, in security, of in infrastructuur.

De GIA en de SCIA zijn bezig een zogenaamde BOK, een Body Of Knowledge op te stellen, waarin staat wat dergelijke architecten moeten weten en kunnen. Bovendien zijn veel instanties bezig met het opzetten van certificeringen op dit gebied, zodat het voor iedereen duidelijk wordt wat men van een architect kan verwachten.

Wat zijn Rootkits

Rootkits vallen onder de zogenaamde "malicious software", net als virussen en wormen. Het specifieke aan rootkits is dat ze bijna niet te detecteren zijn.

De naam Rootkit is afkomstig van de naam van de super user in UNIX (de zogenaamde root user). Deze root user heeft alle rechten op een systeem, net als de "administrator" in Windows. Overigens zijn rootkits een probleem van alle besturingssystemen, inclusief Windows.

Rootkits en andere malicious software kunnen een achterdeur in een systeem maken. Hiermee kan een hacker op afstand toegang krijgen een systeem om het over te nemen, het te beschadigen (het wissen van gegevens), om er aanvallen op andere machines mee uit te voeren, of om andere ellende te veroorzaken.

Rootkits zijn bijna niet te detecteren omdat ze behalve de malicious software, ook software installeren die commando's van het operating system vervangen. Een voorbeeld is het UNIX/Linux commando 'ls -l'. Hiermee kan een lijst van files worden opgevraagd:

$ ls -l

total 72

drwxr-xr-x 3 slaan slaan 4096 2006-09-14 11:02 BACKUP

drwxr-xr-x 9 slaan slaan 4096 2006-09-16 13:52 google-earth

-rwxrwxrwx 1 slaan slaan 150 2006-10-02 19:50 maliciouscode.exe

drwxr-xr-x 8 slaan slaan 4096 2006-05-05 09:44 Murdoc_development

drwxrwxrwt 7 slaan slaan 4096 2006-09-10 13:54 My Virtual Machines

drwxr-xr-x 2 slaan slaan 4096 2006-09-15 08:45 scripts

drwxr-xr-x 11 slaan slaan 4096 2006-09-25 15:35 uapplications

drwxr-xr-x 2 slaan slaan 4096 2006-09-12 21:42 vmware

Een rootkit installeert een andere versie van het commando 'ls'. Hiermee wordt de malicious code onzichtbaar:

$ ls -l

total 72

drwxr-xr-x 3 slaan slaan 4096 2006-09-14 11:02 BACKUP

drwxr-xr-x 9 slaan slaan 4096 2006-09-16 13:52 google-earth

drwxr-xr-x 8 slaan slaan 4096 2006-05-05 09:44 Murdoc_development

drwxrwxrwt 7 slaan slaan 4096 2006-09-10 13:54 My Virtual Machines

drwxr-xr-x 2 slaan slaan 4096 2006-09-15 08:45 scripts

drwxr-xr-x 11 slaan slaan 4096 2006-09-25 15:35 uapplications

drwxr-xr-x 2 slaan slaan 4096 2006-09-12 21:42 vmware

Om te voorkomen dat opgemerkt wordt dat het 'ls' commando is vervangen, wordt onjuist informatie over zichzelf getoond door het gepatchte 'ls' commando. Op deze manier worden ook files die een afwijkende grootte hebben gemaskeerd. Eventueel wordt zelfs de kernel gepatched om onjuiste informatie te tonen!

Er zijn twee manieren om rootkits te voorkomen:

1. Door middel van virusdetectie moet voorkomen worden dat rootkits überhaupt worden geïnstalleerd;

2. Door middel van Host-IDS (Intruder Detection Systems) technologie kan worden ontdekt dat bepaalde zaken aan het systeem worden veranderd door een rootkit.

Beide mogelijkheden zijn echter flinterdun: Een virusscanner omzeilen is iets dat nu ook al regelmatig voorkomt en een IDS kan door de rootkit ook worden misleid, net zoals hij de andere tools misleid.

Rootkits kwamen in 2005 in het nieuws, toen ontdekt werd dat platenmaatschappij Sony/BMG rootkits installeerde via hun muziek cd's, om zo een kopieerbeveiliging te installeren. Dit kostte Sony uiteindelijk veel meer dan het opleverde, men heeft veel moeite moeten doen en kosten moeten maken om de goede naam weer te zuiveren.