Na de geluiden in Heerenveen en Amsterdam over het op een lager pitje zetten van een Linux/OpenOffice-migratie (in München gaat ondertussen zo'n migratie wel goed), nu een verhaal over een migratie naar Open Source die wel gelukt is. Toegegeven dit is geen desktopmigratie maar eentje van een proprietary storage-oplossing naar een open source-variant.
Een klant heeft een storage-oplossing in gebruik, die de afgelopen jaren goed gewerkt heeft, maar waarvan binnenkort de licentie verlengd dient te worden. Die verlening en de daarbij behorende upgrade zou in de tonnen gaan lopen qua kosten. De vraag was wat open source hierin zou kunnen betekenen. Linux heeft in deze situatie zich al vaak genoeg bewezen.
De nieuwe storagemachine, filer genaamd, bestaat uit 'gewone' Dell-hardware met 36 GB aan geheugen. Op dit systeem is Novel SuSE Linux Enterprise Server (SLES) geïnstalleerd. Waarom SLES? SuSE was al in gebruik binnen deze organisatie en beviel goed. Na de installatie zijn de hardeschijven aan elkaar gekoppeld in één logisch volume (met LVM [Linux Logical Volume Manager]) om een ruimte van ongeveer 2 TB te creëren. Deze setup, met deze hardware, levert zonder additionele optimalisaties een schrijfperformance op van zo rond de 700 MB/s. Niet slecht.
De oude filers hebben een heel mooi snapshotting-mechanisme. Daarmee wordt om de zoveel tijd de hele set bestanden apart gezet. Dit mechanisme werkt erg goed en geeft gebruikers de mogelijkheid om snel een oudere versie van een bestand terug te halen. Natuurlijk moet de nieuwe filer dat ook ondersteunen.
Deze functionaliteit moest gedupliceerd worden met LVM, waar ook een snapshot-mechanisme in zit. Helaas blijkt dat dit mechanisme een zeer serieuze performance-impact heeft. Eén enkele snapshot zorgt ervoor dat de schrijf- en leessnelheid met 30 procent afnam. Elk extra snapshot zorgde voor een extra performance drop van 10 procent. Dit is natuurlijk niet acceptabel.
Uiteindelijk is er voor gekozen om gebruik te maken van rsync. Op de productie filer draait elke twee uur een rsync-job die de set van bestanden, via het netwerk, (efficiënt) kopieert naar een back-up filer. Op deze back-up filer draait elke vier uur een rsync die een snapshot-mechanisme emuleert en de bestanden kopieert en veilig stelt. Hiermee is dus met een standaard open source-tool het snapshotting-mechanisme gerealiseerd. Technisch gezien is dat wat kort door de bocht, maar voor de eindgebruikers is er vrijwel niks veranderd.
De filer moet Linux- en Windows-clients bedienen. Dit is opgelost door de filer NFS en Samba te laten spreken. Voor het gebruikersbeheer is het zo gemaakt dat de NFS-kant (Linux) in een LDAP-server kijkt en Samba (Windows) aan de Active Directory is gekoppeld. De gebruikersinformatie binnen LDAP en de AD wordt door een synchronisatiescript gelijk gehouden.
Er staan nu vier van zulke filers die alle vier een goede performance leveren. De uiteindelijke kosten zijn met 60.000 euro, voor de vier filers gezamenlijk, ruim lager. Ook zijn ze een stuk sneller dan de oude oplossing.
Waarom lukt met met OpenOffice dan zoveel moeilijker, waar het hier wel lukt? Het op te lossen probleem is een stuk kleiner en afgebakend. En misschien nog wel belangrijker: er zijn geen eindgebruikers die je moet overtuigen, want die zien alleen maar een snellere, werkende netwerkschijf (als alles goed gaat).
Los van dat er best grotere migraties op de desktop gelukt zijn (bel Novell eens voor hun cases met SLED), merk je vaak dat het allemaal inderdaad een politiek verhaal is. Niet of iets beter is, wel of het pruduct a) of juist b) is.
ALs je practisch gezien ‘gewoon’ de boel verbouwt/veradert, dan blijkt vaak achteraf dat de verbeteringen zichtbaar zijn. En dat stukje succes kun je op geen enkele manier van te voren uitleggen aan de decision taker…