Blonko!

Sinds twee weken kunnen we Stad Sint-Niklaas tot onze klantenkring rekenen. De hoofdsite en enkele subsites van de stadsdiensten staan sinds kort dus op een server bij ons, en alles wordt door ons onderhouden. De gevraagde service was een managed dedicated server en bijkomende dienstverlening, en een strenge SLA.

Vandaag kregen we ook de officiële bestelbon van Stad Sint-Niklaas, met de nodige stempels en handtekeningen. Hierbij zat een overzicht van de toewijzingscriteria, met een soort puntentelling en enkele gegevens van de andere partijen die ook een offerte hadden ingediend. Zo werden punten toegekend naar kostprijs, inhoud van de SLA, extra diensten, etc… het geeft meteen een beeld waarom er gekozen is voor onze oplossing. Het is natuurlijk ook ideaal om te zien wat anderen in de sector aanbieden voor een bepaalde prijs, en dus zo onze eigen prijszetting te be-oordelen.

Wij moesten helpen met de migratie en de overgang van de oude server naar de server bij ons. We kozen in overleg voor een eenvoudige overgang: gewoon beide systemen online zetten, het nieuwe systeem testen via een testadres, en dan de nameserver records wijzigen.

Er wordt veelvuldig gebruik gemaakt van Xoops, een PHP/MySQL gebasseerd CMS systeem, dat via modules uitbreidbaar is. De overzetting hiervan was quasi kinderspel, er diende één bestandje aangepast te worden, en alles bleef werken. De nieuwere versie van PHP zorgde voor enkele kleine zaken, maar niets wat niet binnen de minuut gevonden en opgelost was.

Wanneer het verkeer op de oude server sterk verminderd, zal ik daar misschien nog een rinetd plaatsen om de resteren mensen door te verwijzen tot wanneer iedereen het nieuwe IP gebruikt. Dat is een beetje afhankelijk van het resterende verkeer. Afhankelijk van het aantal bezoeken na enkele dagen wordt er misschien nog een pagina geplaatst op de oude server, die de mensen op de hoogte brengt van hun trage dns-servers .

Steeds meer heb ik een andere manier van werken als het op programmatie voor eigen gebruik aankomt. Elke paar dagen voeg ik een beetje code toe, en kleine functionaliteit, maar met in het achterhoofd altijd wat er nog allemaal moet komen, in plaats van ineens de wereld te willen veranderen, alles weg te gooien, de helft opnieuw op te bouwen, en uiteindelijk met een nieuw systeem te zitten dat 20% meer kan dan het oude, en uiteindelijk nooit afraakt.

Zo ben ik reeds enkele weken bezig met onze domein-interface aan het uitbreiden met nieuwe (*kuch*, nog ontbrekende) functionaliteit. Gestaag komt er functionaliteit bij, en na elke kleine aanpassing wordt mijn verstand en visie eens ge-cross-checked met Frank zijn idee erover, en indien nodig bijgestuurd. Hetzelfde heb ik enkele weken gedaan voor de facturatie-interface (al moet ik toegeven dat er daar ook nog een ellenlange todo-lijst aan vasthangt).

Ik weet het niet goed, maar het lijkt erop dat ik meer gedaan krijg op deze manier.

Al geruime tijd verrichten we wat denkwerk rond “high availability”. Wanneer we kijken op applicatieniveau -denk “het terugsturen van een webpagina wanneer erom gevraagd wordt”- is dit allemaal niet extreem moeilijk. Er bestaan zelfs verschillende kant en klare oplossingen, en meestal bestaat meer dan één techniek om alles te balancen, clusteren of failover-en. Per applicatie zijn verschillende mogelijkheden, de één al mooier dan de andere, maar uiteindelijk kan je altijd wel iets maken dat redundant is en werkt.

Je blijft echter altijd met één groot probleem zitten: redundante opslag. Ik maak deze denkoefening nu al minstens 9 maand, en tot op heden ben ik er nog niet uitgeraakt wat het best is. Ofwel ga je op block-niveau gaan werken, en moet je kijken naar oplossingen als DRBD of iets dergelijks. Het enige wat hier mogelijk is, is failover (dus, omschakelen als de “hoofdserver” doodgevallen is), en wanneer je replicatie uitvalt, zit je met een block-device met daarop een mogelijks inconsistent filesysteem. Deze blockdevices kunnen geëxporteerd worden via verschillende technologieën, maar als het als block geëxporteerd is, moet een umount/detecteer ander device/chkfs/re-mount gebeuren. Hier heb ik reeds verschillende zaken getest (bvb iSCSI exports, via drbd gesynced, met HA, en dan portal failover of iets dergelijks voor het omschakelen). Heel het iSCSI gebeuren onder Linux kan nog wat stabiliteit en zo gebruiken, maar het is werkbaar als je er genoeg tijd in steekt om alles uit te vissen. LVM eronder, en je hebt een mooie schaalbare oplossing.

Wanneer je een filesysteem exporteert (smb/cifs, nfs…) kan je hier wat omheen werken, maar dan moet je je filesysteem syncroon houden, en dat is dan weer iets anders. GFS is blijkbaar één oplossing, maar daar heb ik al veel threads gezien met als onderwerp “horrible data corruption” of “where did my data go today?”. Ik heb het nog niet getest, maar het lijkt me dus onstabiel. Als mijn testmachines terug onder de levenden zijn, gooien we dat op de testbank. Verder zijn er ook zaken die met daemons werken, en files heen en terug syncroniseren (met rsync als onderliggende technologie). Dat heb ik dan wel al getest, en binnen de 5 minuten kreeg ik het stuk. Afgevoerd.

De enige oplossing die altijd terugkomt is NFS op een drbd gesyncd device. NFS heeft zijn nadelen, maar blijkbaar is het wel iets wat werkt. Je blijft echter zitten met het feit dat je FS corrupt kan zijn, als de replicatie op een slecht moment wegvalt. Je kan ook maar 2 storage devices gebruiken, en bvb geen 3 met load balancing, of “preferred device” wanneer je bvb je materiaal verdeelt over meerdere locaties en een applicatie bij voorkeur het “dichtste” device moet gebruiken.

Toevallig heb ik deze week heb ik wat zitten zoeken naar kant-en-klare NAS-distributies voor een klant, en vond ik OpenFiler en FreeNAS (naast een hoop andere rommel), en OpenFiler beweert een failover oplossing te hebben. Aangezien het een CentOS gebasseerde oplossing is, vermoed ik dat het terug GFS zal zijn. We gaan dat eens installeren en onderzoeken hoe ze het doen, en daar onze conclusies uit trekken.

Alweer iets over WHT, mijn dagelijkse bron van verwondering. Vandaag nemen we een blik in de forumsectie “brol te koop”, waar allerlei apperatuur – van een kabeltje tot 30 servers en meer – te koop wordt aangeboden. Kijk even mee naar de thread van deze verkoper.

Niets bijzonders? Gewoon 2 servers te koop. Kijken we even naar server 1, dan zien we iets verder dat er enkele fotos beschikbaar zijn (let op, vrij groot). Kijk even mee op de eerste foto.

Levensles voor een goede 1U server: luchtstroom gaat van voorkant naar achterkant, en blaast dus normaal over de disks en over/door het koelblok van de processor en de mogelijke koelblokken op north/southbridge, en op bvb een mogelijke raidcontroller. We zien duidelijk enkele fans (ventilators voor de server-leken) op het middenste stuk ijzer zitten (minstens 2, misschien 4 aan de schroefjes te zien). Jammer genoeg zien we enkele hindernissen. We zien dat bvb het geheugen haaks op de airflow staat. Een geheugenlatje is 3 cm hoog. Een kast is 1.75 inch hoog, ofwel 4,4 cm ongeveer. Je moet weten dat het moederbord ietwat boven de onderkant van de kast zweeft, en dat het geheugen ook in een socket zit. Er blijft dus niet veel meer over. Jammer. Achteraan de kast zien we ook niet echt veel perforatie voor de afvoer van de warme lucht.

Nog opmerkelijker is bvb de plaatsing van de koelvin op de chipset (de zilverkleurige). De vinnen staan haaks op de (toch al niet mogelijke) luchtstroom. De processorkoeling werd ook met de vinnen haaks op de luchtstroom gezet. Deze heeft echter een eigen koelingsfan.

Achteraan de kast zien we NA de voeding nog een koeler (zo een type dat boven/onderaan lucht zuigt, en dat door de “slurf” wegblaast). De fan die in de voeding ingebouwd zit blaast los op de zijkant van deze koeler.

Hoe komt dit nu? Het moederbord is een Asrock bordje, gegeerd door low-budget, el-cheapo hostingbedrijfjes die net beginnen. Dit bordje is niet ontworpen om in een 1U kast ingebouwd te worden. Verder is het design van de kast ietwat raar (onder andere die koeler achter de voeding deed me rillen), en niet echt optimaal te noemen.

Er is reeds 320 EUR geboden op deze server. Beschamend. Hij is geen 5 EUR waard in mijn ogen. Wanneer ik een moment tijd heb, neem ik eens enkele foto’s van de machines die hier klaar liggen om naar het datacentrum te vertrekken. We weten wel waarom we iets meer betalen voor een server.

Een blik achter de schermen, of liever, onder de schermen.

Wat je ziet is een beeld van onder de verhoogde vloer in een van de datacentra waar we met materiaal zitten. De dikke zwarte kabel naast het doosje is een stroomkabel, die één van onze racks van 16A stroom voorziet (er zijn twee dergelijke kabels per rack, die door een STS in 1 redundante omgezet wordt).

Ik moet zeggen dat ik het doosje toch ietwat dichter naar de kabel heb geschoven, voor de slechtziende of slechtruikende knaagdieren nog wat meer te overtuigen van het eten van het lokaas ipv hun tanden in de kabel te zetten.

Als DC uitbater moet je dus aan alles denken, ook aan kleine knaagdieren. Ik vermoed dat het een ramp is om tussen de honderden kilometer kabel die er ligt, die ene kabel te beginnen vervangen die doorgeknaagd is (al denk ik dat vervangen niet gebeurt, maar gewoon een nieuwe leggen).

Hier en hier nog twee sfeerbeelden onder de verhoogde vloer.