Linux in een datacentrum

De installatie van een server in een datacentrum is anders als de inrichting van een stand-alone server dat op een zolder kamer web services aanbiedt. Zo moet een server in een data centrum vaak gekoppeld worden aan een SAN en heb je te maken met management van de server. In dit artikel lees j over een aantal zaken waar je rekening mee moet houden voordat je een Linux server in een datacentrum in gebruik neemt.

Bij het werken met Linux in een datacentrum is er een aantal uitdagingen. Om te beginnen is het vaak niet mogelijk of erg lastig fysiek toegang te krijgen tot de server omdat het data centrum overal op de wereld kan zijn. Een andere uitdaging is de koppeling van de server aan storage en tot slot heb je te maken met beheer van de server. We bespreken hoe je deze specifieke taken tot een geslaagd eind kunt brengen zodat je Linux server goed in het datacentrum geïntegreerd wordt.

Remote toegang

Waarschijnlijk lees je hier niets nieuws als we zeggen dat je voor beheer op afstand een oplossing als SSH nodig hebt. De kans is groot dat je SSH al veelvuldig gebruikt om toegang te krijgen tot servers. Bij gebruik van SSH in een datacentrum is het echter van belang extra aandacht te besteden aan de beveiliging van de server.

Als je Linux server een standaard SSH proces aanbiedt dat op poort 22 staat te luisteren voor binnenkomende verbindingen, duurt het niet lang voordat je de eerste hacker op bezoek hebt. Er zijn op internet talloze scripts die continue scannen op open SSH poorten om daar vervolgens een dictionary attack tegenaan te gooien. Je zult dus iets moeten doen om dit tegen te gaan.

Een eenvoudige maar efficiënte manier om jezelf te beschermen tegen dictionary attacks, is door je SSH daemon op een andere dan de standaard poort te laten draaien. Biedt je server geen HTTPS aan? Dan is poort 443 een prima keuze. In feite is alles goed, zolang het maar geen poort 22 is, want daar scannen de scripts op.

Als tweede minimale beveiliging van SSH moet je er voor zorgen dat root login niet is toegestaan. Als root wel aan mag melden, weet de intruder immers al de helft van wat nodig is om binnen te maken op je server. Dus zet AllowRootLogin op no en herstart je ssh proces.

Naast SSH is er nog een belangrijk toegangsmechanisme als je Linux in een datacentrum in wilt zetten. Vaak is het lastig servers fysiek te bezoeken, maar ook in een datacentrum is het soms nodig een server te herstarten. Stel nu dat er tijdens dat herstarten iets verkeerd gaat, dan moet je wel een mogelijkheid hebben nog bij de server te komen. Hiervoor is het zaak de server uit te voeren met een remote toegangsmogelijkheid. Veel servers gebruiken daarvoor een managementkaart zoals HP ILO of Dell Drac. Door te verbinden met het specifieke IP adres op deze managementkaart kun je inloggen op een console sessie op afstand en dat is wel heel handig als je server tijdens een herstart blijkt te hangen op een fout in bijvoorbeeld /etc/fstab en vraagt het root wachtwoord in te voeren voor maintenance. Als na een tijdje blijkt dat je server nergens op reageert, hoef je namelijk alleen maar in te loggen op de management kaart om vervolgens het probleem op te lossen.

Koppelen aan opslag

Een uitdaging van heel andere orde is de koppeling van Linux aan opslag. Opslag is in een datacentrum vaak extern en wordt verzorgd door een SAN. Als beheerder moet je er voor zorgen dat een Linux server op correcte wijze aan het SAN gekoppeld wordt.

Grofweg bestaan er twee manieren om Linux aan SAN storage te verbinden: Fibre Channel en iSCSI. In Fibre Channel SAN omgevingen is het vrij eenvoudig, je installeert een speciale Fibre Channel kaart in de server en de SAN storage wordt zonder veel moeite als externe disk herkend. Fibre Channel is als standaard ook dusdanig algemeen dat je vrijwel nooit problemen zult hebben met de herkenning van de Fibre Channel interface kaart, eenmaal goed aangekoppeld zal de SAN storage als normale SCSI schijf zichtbaar worden.

Bij het werken met iSCSI is het een iets ander geval. iSCSI is een daemon die gestart moet worden om contact te maken met het iSCSI SAN. Deze verbinding wordt gelegd over een dedicated netwerk verbinding, of eventueel over het normale netwerk waarover ook het gebruikersverkeer gaat. Dat laatste is echter bepaald niet aan te raden vanwege het te verwachten volume bij gebruik van iSCSI.

Om een iSCSI verbinding te maken, moet je eerst het iSCSI SAN “ontdekken”. Dit doe je met behulp van het commando iscsiadm waarbij je het IP adres van het SAN gebruikt om te ontdekken wat er allemaal aangeboden wordt. Gebruik hiervoor de onderstaande opdracht:

iscsiadm –mode discoverydb –type sendtargets –portal 192.168.1.10 –discover

In reactie op deze opdracht zal het SAN een iSCSI naam teruggeven, de zogenaamde iqn. Deze bestaat uit als eerste een identificatie van het SAN met daarachter een identificatie van de specifieke iSCSI target, zoals in iqn.2012-09.com.example:linux. Deze IQN heb je vervolgens nodig om in te loggen op het SAN, wat je wederom met het iscsiadm commando doet, bijvoorbeeld:

Iscsiadm –mode node –targetname iqn.2012-09.com.example:linux –portal 192.168.1.10 –login

Onder normale omstandigheden wordt de SAN connectie onthouden, dat betekent dat je bij een eventuele herstart de procedure niet hoeft te herhalen, maar deze automatisch uitgevoerd wordt op het moment dat de iscsid service gestart wordt.

Multipath

Verbindingen naar het SAN worden normaal dubbel uitgevoerd. In het SAN zitten twee controllers die via twee verschillende switches aangesloten worden aan 2 SAN interface kaarten per server. Dat is handig, want als er dan eens een pad naar de storage uitvalt, kan altijd nog het andere pad gebruikt worden. Op zich is dat handig, maar er is een praktisch issue waarmee rekening gehouden moet worden: de SAN devices worden namelijk ook twee keer gepresenteerd. Dat betekent dat als er op het SAN één LUN (gedeelde disk) is aangemaakt die via twee paden wordt aangeboden, dat je hem twee keer te zien krijgt. Niet alleen als /dev/sdb, maar ook als /dev/sdc dus. Gelukkig is er een oplossing.

Door de multipath driver te laden, wordt herkent dat de twee SAN devices in feite twee keer hetzelfde device zijn. Elke disk heeft namelijk zijn eigen unieke ID en op basis van die ID kan bepaald worden dat het om twee keer hetzelfde device gaat. De multipath driver zal ervoor zorgen dat een apart multipath device aangeboden wordt met een unieke naam. Door er nu voor te zorgen dat je met dit aparte device verbindt in plaats van de afzonderlijke disk devices gaat alles automatisch goed als er eens een keer een pad naar de storage uitvalt. De multipath devices worden normaal gepresenteerd als /dev/mapper/mpath0, maar je kunt er voor zorgen dat andere namen gebruikt worden. Als dit wenselijk is, dien je hiervoor te zorgen door een bestand met de naam multipath.conf aan te maken dat alle te gebruiken parameters bevat.

Beheer

Als je een enkele server in een datacentrum plaatst, zal beheer niet echt een issue zijn. Als je echter tientallen of honderden servers onder je verantwoordelijkheid hebt wordt dat een heel ander geval. Stel je maar eens voor dat je even een bestand aan moet passen op honderd verschillende servers! Om het beheer van Linux eenvoudiger te maken, kan je eigenlijk niet zonder beheersoplossing. Er zijn verschillende oplossingen die hiervoor ingezet kunnen worden.

Waarschijnlijk de meest bekende en populaire oplossing om configuraties te beheren, is Puppet. Puppet is ontworpen om de infrastructuur gedurende de hele levenscyclus te beheren, en daarbij gaat het met name om het distribueren van veranderingen naar meerdere servers.

Puppet maakt het mogelijk eerst de gewenste staat van de servers te definiëren. Vervolgens kan gesimuleerd worden wat er gebeurt bij het uitrollen van alle veranderingen in de configuratie. Als deze simulatie op de juiste wijze plaatsgevonden heeft, kan de gewenste staat van de servers vervolgens toegepast worden. Het geheel wordt vervolgens afgesloten met een rapportage, zodat je eenvoudig ziet dat het ook allemaal goed gegaan is.

Wat bijdraagt aan de populariteit van Puppet is dat het modulair is. Dat betekent dat er verschillende configuratiemodules beschikbaar zijn waarmee eenvoudig taken geautomatiseerd kunnen worden. Daarbij komt dat Puppet een eigen programmeertaal heeft zodat je eenvoudig nieuwe modules kunt ontwikkelen als dat nodig is.

Ondanks de populariteit van Puppet, is het niet de enige oplossing om Linux servers te beheren. Een andere bekende oplossing is Spacewalk, een open source project dat gesponsord wordt door Fedora dat als doel heeft om patches en updates te distribueren naar verschillende servers. Binnen een groot datacentrum wil je namelijk niet alle servers apart updaten, maar een mechanisme gebruiken dat het mogelijk maakt patches eerst te testen en vervolgens uit te rollen naar alle servers die de patches nodig hebben. Spacewalk is voor dit doel ontwikkeld.

Op basis van Spacewalk hebben zowel Red Hat als SUSE ook hun eigen management oplossing gemaakt, met als specialiteit de integratie met de (betaalde) on-line repositories die door deze distributies aangeboden worden. De Red Hat oplossing heet Satellite, en SUSE gebruikt SUSE Manager, beiden worden ingezet voor zowel de grootschalige distributie van patches als het gecentraliseerd beheren van configuratiebestanden.

Samenvatting

Je kunt natuurlijk een Linux server in een datacentrum zetten en deze beheren zoals je dat gewend bent voor een Linux server op je zolderkamer. Als je het datacentrum echter beschouwt als een bedrijfsmatige omgeving waar grote aantallen Linux servers staan die allemaal beheerd moeten worden, komt daar een aantal zaken bij kijken. In dit artikel heb je kennis gemaakt met een paar van de bijzondere beheersaspecten van Linux in een data centrum. Op basis van je kennis hiervan ben je beter in staat Linux bedrijfsmatig en efficiënt in te zetten.