Om je netwerk goed te laten blijven werken, hebben we 10 gebieden uitgelicht waarin tweaken en wat investeren kan leiden tot significante prestatiewinst. Het is nu eenmaal zo dat meer en meer organisaties zaken doen met de snelheid van het licht. Daarom is het belangrijk om je netwerk te laten vliegen, zodat je bedrijf goed kan blijven concurreren.

Gooi je oude meuk uit het raam

Veel organisaties houden nog krampachtig vast aan bejaarde applicatie platformen, wat de IT opzadelt met de dure en inefficiënte taak om de oude platformen in nieuwe infrastructuur te proppen. En zo zit je met een gloednieuwe VMware vSphere architectuur waarop een handjevol NT4 OSsen draait.

Het weigeren om het verleden los te laten, resulteert vaak in hogere kosten, downtime en fragiliteit van core business-systemen. In plaats van het houden van tig vergaderingen over hoe je een 10 jaar oud software-pakket in een nieuwe infrastructuur gaat implementeren: schiet die oude meuk de ruimte in en migreer naar iets nieuws. De kosten zijn dan op de korte termijn wellicht hoger, maar die verbleken als je gaat kijken naar de kosten op langere termijn wanneer je die oude rommel in ere houdt.

Dit is zowel een zaak van het personeel als van de techniek. Er zijn altijd mensen die alles door de bril zien van hun eigen favoriete technologie, zonder rekening te houden met de feiten. Wat de boer niet kent, dat vreet hij niet. Het is niet altijd makkelijk om deze personen door de stormachtige en duistere vallei van nieuwe technologie te leiden. Maar onthoudt: het aanhouden van mensen die gefocussed zijn op één ding, kan net zo schadelijk zijn als het krampachtig vasthouden aan oude technologie.

Bouw een laboratorium

Er is geen excuus. Voor de prijs van één enkele server kun je een prachtig IT test ‘laboratorium’ maken. Een goedkoop servertje met een dual-CPU, 12-core AMD die in Istanbul staat kan tig virtuele machines draaien in een testopstelling voor ongeveer 1200 euro. Door VMware Server op Linux of VMware ESXi te gebruiken, kun je de licentiekosten schrappen, terwijl je een perfect platform hebt om van alles en nog wat te testen. Software upgrades, nieuwe OSsen en zelfs netwerk architecturen… het kan er allemaal mee.

Combineer een gevirtualiseerd server laboratorium met tools als GNS3 en je kunt elk netwerk en elke infrastructuur testen. Er bestaat simpelweg geen makkelijkere manier om erachter te komen waar de bottlenecks zitten dan het testen in zo’n eigen laboratorium. Daarnaast kun je met zo’n testomgeving vaak precies uitbalanceren hoeveel RAM en CPU je nodig zult hebben voor het echte werk. Daardoor ga je dus efficiënt om met je middelen.

Houd alles in de gaten

Het monitoren van je netwerken en systemen is de betovergrootvader van bottleneck diagnostiek. Wanneer gebruikers klagen dat het netwerk traag is, heeft het netwerk zelf er meestal niets mee te maken. Maar tenzij je de hulpmiddelen hebt die je precies laten zien waar het probleem ligt, zul je in het duister blijven tasten naar de oplossing.

Of je het nu op merkspulletjes hebt of dat je open source tools prefereert, er is een hele horde aan opties beschikbaar om alles te monitoren, van netwerk latency en throughput tot RAM- en CPU-gebruik, SAN-prestaties en de lengte van schijfqueues.

Als het bestaat, kun je het monitoren. Als het gemonitord kan worden, kan het in een grafiekje worden gezet. En als het in een grafiekje gezet kan worden is er een hele goede kans dat een simpele uitlezing van de resulterende grafiek je in de goede richting kan leiden, wat de probleemdetectie flink versnelt.

En wanneer je het netwerkmonitoren introduceert, wees dan volledig. Monitor het CPU-gebruik van je routers en switches, kijk naar de error rates op Ethernet interfaces, laat je switches en routers naar centrale systeemlog servers loggen en implementeer een manier om de logbestanden te analyseren, zodat je gewaarschuwd wordt als er IP-conflicten zijn, als delen van het netwerk down gaan en alles wat daartussenin zit. Voorzichtige en nauwgezette implementatie en het tweaken van je monitor-framework zal je enorme hoeveelheden tijd en energie schelen, zeker waar dat het meest nodig is.

Ken uw applicaties

Met het monitoren van je infrastructuurprestaties kun je een eind komen, maar er zijn beperkingen. Alle middelen die op je netwerk aangesloten zitten worden uiteindelijk geconsumeerd door je applicaties. Voor velen van ons vormen die applicaties tezamen een soort van zwart gat. We kunnen namelijk heel makkelijk het effect zien dat ze op onze infrastructuur hebben, maar het is vaak lastig om ze goed van binnen te bekijken om te weten te komen wat er precies aan de hand is.

Veel IT-afdelingen vinden het prima om softwareverkopers alle applicaties te laten installeren en implementeren op hun netwerken. Dat betekent namelijk minder werk. Maar wees voorzichtig, je bent later de sigaar als je netwerk vertraagt tot kruipmodus.

Steek wat tijd in het testen van je applicaties en houdt het scherp in de gaten zodat je de zwakke plekken eruit kunt pikken. Hoe dan ook, je moet de vertragingen in de prestaties lokaliseren.

Om dit te bereiken zul je moeten eisen dat je een applicatie mag testen voor hij wordt aangeschaft. Let goed op de hoeveelheid systeembronnen worden opgeslokt terwijl je het test en hoe het programma dus zal presteren met echt dataverkeer. Dit soort tests kunnen architectonische fouten blootleggen in de applicatie die het onbruikbaar maken voor jouw netwerkomgeving. Het is beter dat op voorhand te weten dan om te moeten vluchten voor gebruikers met hooivorken en fakkels.

Terabytes en spindles tellen

De afgelopen jaren hebben we een explosieve groei gezien in diskcapaciteit. Met de komst van de 2TB SATA disks, is het nu mogelijk om meer dan 10 TB in een enkel two-rack-unit server te duwen. En dat is fantastisch, want dan heb je minder disks nodig… toch? Niet zo snel, makker.

Het is van cruciaal belang om te begrijpen dat de SATA-disks van tegenwoordig een belangrijk kenmerk delen met hun kleinere voorgangers: hun snelheid. Het is misschien mogelijk om 2TB data op een enkele 7.200 RPM SATA-schijf te krijgen, maar je zit nog steeds vast aan een gemiddelde willekeurige transactie-throughput van misschien 80 I/O operaties per seconde (IOPS). Tenzij je data voor het grootste gedeelte statisch is, zul je erg ongelukkig worden van de prestaties die je krijgt uit die nieuwe disks, vergeleken met twee keer zoveel 1 TB schijven.

Als je applicaties veel willekeurig lezen en schrijven vereisen, zoals database en e-mail servers doen, zul je veel individuele disks nodig hebben om de noodzakelijke prestaties te halen. Hoewel grote schijven geweldig zijn om minder vaak gebruikte data op te slaan, moet je meest gebruikte data nog steeds op snellere en maar kleinere disks staan.

Vermijd bottlenecks in je hardwareconfiguratie

Virtualisatie is zo ongeveer het meest geweldige dat er kan gebeuren in een datacenter. Het biedt veel beheers-, management- en monitorvoordelen. Het schaalt geweldig, maakt disaster recovery makkelijker dan ooit en je hoeft minder servers te hebben staan die hitte spuwen.

Maar bij incorrect gebruik kan virtualisatietechnologie je stevig in de kont bijten. Het is helaas geen magie. Het kan CPU, geheugen en IOPS niet zomaar tevoorschijn toveren.

Terwijl je gevirtualiseerde omgeving groeit, kun je makkelijk je CPU- en geheugenprestaties bijhouden. Een beetje hypervisor zal je de maximale capaciteit van je systeem laten zien. De prestaties van je schijf zijn echter lastiger bij te houden en die zullen je in de problemen brengen als je de grenzen van virtualisatie gaat opzoeken.

Zeg dat je 100 fysieke servers hebt die je wilt virtualiseren. Ze draaien op drie jaar oude hardware en hebben 1 GHz aan CPU bandbreedte nodig, 1GB geheugen en een harde schijf die 250 IOPS kan verwerken.

Je zou misschien denken dat een six-core X5650 server met 8 sockets en 128 GB RAM hiervoor volstaat. Je hebt namelijk meer dan 20% CPU- en geheugencapaciteit over, toch? Natuurlijk, maar vergeet niet dat je het equivalent van 15.000 RPM Fibre Channel of SAS disks aan de server moet koppelen om in staat te zijn om het dataverkeer aan te kunnen dat je gaat krijgen. Het gaat niet alleen maar om verwerkingssnelheid.

Dedupen, of toch niet?

Omdat je data exponentieel groeit, is het logisch dat je naar manieren gaat zoeken die de dure opslagcapaciteit die je nodig hebt in te perken. Eén van de beste manieren om dat te doen is data-deduplicatie. Of je nu in je backup- en archief-tier dedupliceert of direct de primaire opslag aanpakt, het is een ontzettend grote winst wat betreft opslagcapaciteit als je alle dubbele data uit je opslag kunt halen en alleen opslaat wat uniek is.

Deduplicatie is inderdaad geweldig voor de backup-tier. Of je het nu implementeert in je backupsoftware of in een apparaat als een virtuele tape bibliotheek, je backups blijven altijd ongeveer even groot en je kunt ze in een oogwenk herstellen. Dat is altijd beter dan dat je elke keer dat een backup ouder is dan 2 dagen moet gaan graven naar het desbetreffende tapeje.

Maar zoals de meeste geweldige ideeën heeft ook deduplicatie een aantal nadelen. De grootste is dat het veel werk is. Het zal geen verrassing zijn dat NetApp, een van de weinige grote SAN-fabrikanten die deduplicatie op primaire opslag leveren, ook een van de weinige SAN-leveranciers is die controller hardware performance upgrades aanbieden via hun Performance Acceleration Modules. Het identificeren en consolideren van gededupliceerde data vergt een hoop controller resources. Met andere woorden, het bezuinigen op opslag kost performance.

Versnel je backups

Backups zijn bijna altijd trager dan je zou willen. En erachter komen waar het probleem op het gebied van prestaties precies resideert is meer kunst dan wetenschap. Maar er is één gemeenschappelijk probleem dat bijna elke backupadmin wel een keer tegenkomt.

Als je direct naar tape backupt, is het waarschijnlijk dat je je tapedrives ondervoedt. De huidige generatie van LTO4 tapedrives is theoretisch in staat om meer dan 120 MBps data schrijfsnelheid te halen. Helaas zie je dat in de praktijk haast nooit. Dat komt voor een groot deel doordat er heel weinig backupbronnen zijn die constante leessnelheden hebben die gelijk zijn aan de snelheid van de tapedrive.

Een backupbron die bestaat uit een paar SAS-schijven in een RAID1-reeks kan dan misschien wel 120 MBps aan in een testopstelling, maar voor standaard bestandsoverdracht in een Windows-omgeving via een netwerk, zul je zelden hogere snelheden zien dan 60 MBps. Omdat veel tapedrives aanzienlijk minder efficiënt worden wanneer de buffers leeg zijn, vormt dit de bron van veel prestatieproblemen met backups.

Met andere woorden, het probleem is niet de tapedrive, maar de opslag in de servers die je backupt. Hoewel je hier niet al te veel aan kunt doen zonder een vermogen te investeren in een grote high-performance disk-to-disk backup-oplossing, toch heb je meer opties wanneer je een SAN hebt draaien. Hoewel het voor een groot deel af zal hangen van wat voor SAN je hebt en welke backupsoftware je gebruikt, is het gebruiken van host backups (die direct van de SAN lezen in plaats van via het netwerk) een goede oplossing om dit lastige probleem het hoofd te bieden.

Bron: Techworld