Projectplanning in de praktijk: het uitbreiden van de backup-retentie!

Zoals je wellicht weet, hebben we onze Antagonist Backups onlangs flink uitgebreid. Erg gaaf, want je kunt door de hogere backup-retentie data van tot véél verder terug op je pakket herstellen. Het uitbreiden van een backup-platfom gaat uiteraard niet vanzelf. Graag geven we je daarom met dit artikel inzicht in hoe dit, dankzij de inspanningen van The A-Team, werkelijkheid is geworden!

Projectplanning in de praktijk: het uitbreiden van de Antagonist Backups!

Graag vertel ik je stapsgewijs hoe onze backups de sprong van drie dagen naar vier weken maakten. De vaste lezer zal hierin ons vaste projectplanningsproces herkennen:

  1. Pitch
  2. Specificatie
  3. Akkoord
  4. Uitvoering
  5. Testen
  6. Release team
  7. Lancering & evaluatie

Pitch

Voor de start van het project merkte één van onze Antagonist-veteranen op dat sinds hij hier werkt al de wens heeft om backups met hoge ‘retentie’ aan te bieden. Wat is retentie exact? Simpel gezegd: hoe hoger de retentie, hoe langer data kan worden bewaard.

Dat het lang bewaren van backups een voordeel is, dat is duidelijk. Hoe hoog de retentie precies moet zijn, is echter lastiger om te bepalen. We hebben geprobeerd een inschatting te maken hoe vaak klanten backups met een bepaalde ‘leeftijd’ nodig hebben en dit afgewogen tegen de kosten.

Bij de lancering van de Antagonist Backups werden de voor de klanten te herstellen backups nog op de hostingservers zelf opgeslagen. Hier gebruiken we zeer snelle opslag voor. Echter, naast dat deze erg snel is, is het ook erg duur. Daarnaast profiteren backups amper van de lage wachttijd van deze snelle opslagruimte. Het was dus al snel duidelijk dat de huidige oplossing uitbreiden met veel meer opslag geen optie was.

Uiteraard slaan we de backups niet alleen op de hostingservers zelf op. Stel dat er iets grondig misgaat met die server, dan ben je alles kwijt zonder mogelijkheid tot herstel. Aangezien zoiets onacceptabel voor ons is, hebben we aanvullend dus ook speciale backup-servers. Naast dat deze servers in een ander datacentrum hangen, bieden ze per definitie al een hogere retentie.

Het plan was dus simpel: de huidige retentie nog hoger maken op de bestaande backup-servers en de hostingservers in staat stellen om deze backups op te kunnen halen. In de volgende stap, de specificatie, hebben we dit plan verder uitgewerkt.

Specificatie

De retentie verhogen, betekende kort gezegd dat er meer opslag in de servers moest komen. Om precies te bepalen hoeveel opslag dit moest zijn, is er ‘tooling’ geschreven. Hiermee kon een inschatting gemaakt worden, wat de kosten zouden zijn voor verschillende periodes. Na een kosten-batenanalyse is de periode vastgesteld op vier weken. Nu we dit wisten, konden we over op het bestellen van de schijven.

Antagonist Backups: schijven in doos

Het tweede deel is een stukje complexer te omschrijven. Daarom stellen we ons voor dat we een gebruiker zijn en kijken we per stap wat nodig is.

Als eerste zien we een overzicht van alle beschikbare backups. Dat overzicht bestaat deels uit lokale backups, zoals het huidige systeem werkt, en deels uit ‘remote backups’, backups die op een externe locatie worden opgeslagen. We noemen dit een ‘medium’ en geven prioriteit aan het lokale medium in verband met snelheid. Verder bouwen we een ‘index’ op van beschikbare backups. Iedere hostingserver mag daarbij alleen de backups ophalen die op die hostingserver zijn gemaakt.

Het start met het kiezen van een backup die we willen herstellen. Hoewel we onderliggend nu NFS gebruiken om de backups van de backup-servers op te halen, kunnen we ze nog steeds in hetzelfde formaat uitlezen. Vrijwel alle herstellogica kan dus hergebruikt worden. Het enige verschil is het vasthouden. Wat we willen voorkomen, is dat een gebruiker de oudste backup kiest, deze terugzet en halverwege besluit het systeem dat deze ‘weggeroteerd’ moet worden. Om dit probleem op te lossen, hebben we een ‘lock daemon’ bedacht die de backups voor ons vasthoudt, terwijl ze hersteld worden.

Uiteraard heb ik hier de eindconclusie beschreven en heb ik de tussenstappen voor het gemak weggelaten. Uiteindelijk, nadat iedereen akkoord was, kon de implementatie beginnen.

Uitvoering

De uitvoering is gedeeltelijk parallel gelopen. De exacte retentie maakt niet uit voor het bouwen, dus development kon aan de slag terwijl de opslag werd uitgebreid. Als developer zal ik vooral mijn perspectief belichten.

Het hele systeem heeft een behoorlijk modulaire opzet. We hebben een ‘client-server-architectuur’ die beiden op de hostingserver draaien. Dit biedt ons een authenticatie-laag die ervoor zorgt dat iedere gebruiker alleen de voor hem of haar bedoelde backups kan zien.

Binnen de server hebben we ‘inspectors’ en ‘restorers’ die op die backups werken. Ze kunnen kijken wat in een bepaalde backup zit en die gedeeltelijk of geheel terugzetten. De werkelijke operaties op het medium, toen nog het lokale bestandssysteem, leefden in een andere module. Om het medium configureerbaar te maken, hebben we een abstractielaag (engine) geïntroduceerd die ook de prioriteit kon bepalen. Ook kunnen we op runtime de verschillende media in- en uitschakelen.

Het uitbreiden van de backup-retentie: release early, release often

Hoewel de engine geen verschil in functionaliteit had, hadden we dit al vrij snel uitgerold volgens het ‘Release Early, Release Often’-principe. Door kleinere stappen te zetten, kun je het probleem opdelen, beter testen en heb je meer controle. Ook weet je eerder dat je code werkt, wat erg fijn is. Des te eerder je bugs vindt, des te gemakkelijker ze op te lossen zijn.

Tegelijkertijd had systeembeheer ervoor gezorgd dat de ‘NFS-mounts’ werkten. Dankzij handige tools als ‘Puppet’ en ‘Foreman’ was ook dat eenvoudig uitgerold op het hele platform.

Het nieuwe medium is betrekkelijk eenvoudig, omdat het grote overeenkomsten heeft met de oude. Je werkt nog steeds op bestanden en de backups hebben dezelfde structuur. Alleen de overzichten en het ‘locken’ zijn anders.

Testen

Met alle puzzelstukjes op hun plek konden we het geheel gaan testen. Helaas ontdekten we dat in sommige situaties een bug konden ‘triggeren’. Dit bleek een combinatie van het lokale bestandssysteem en NFS te zijn. Na kort overleg is besloten om NFS door SMB te vervangen en dat werkte wel betrouwbaar. Dat was vooraf niet te voorzien, maar de impact was beperkt doordat we er snel achter kwamen.

Daarnaast zaten er nog fouten in onze ‘lock daemon’. De oorzaak was een verschil tussen de ontwikkelomgeving en productieomgeving. Een leerpunt voor de toekomst om deze zo gelijk mogelijk te houden.

Deze fouten waren echter snel opgelost en daarmee is het gefaseerd uitgerold naar productie. Initieel met het nieuwe medium uitgeschakeld, maar vrij snel hebben we alles ingeschakeld. Daarmee kon de afdeling Support direct gebruikmaken van de reeds opgebouwde retentie. Dat er door supporters al voor de release een tiental backups hersteld zijn, toonde al aan dat het een erg nuttige feature is!

Release Team

Met alles technisch opgeleverd, kon het Release Team naar een lancering toewerken. Hierbij werd gekeken naar de retentie: klopten onze berekeningen en kunnen we werkelijk de gewenste retentie bieden? Werkt alles snel genoeg en ziet het er goed uit?

Het uitbreiden van de backup-retentie: release team

Ook werd bepaald hoe de communicatie naar buiten toe ging. Wat komt er op het blog, in de mailing en in de informatieblokken van Mijn Antagonist en DirectAdmin te staan? Je wilt daarin graag zoveel mogelijk klanten bereiken. Een feature is immers pas nuttig als gebruikers het weten te vinden!

Lancering & evaluatie

Op het moment van schrijven is er nog geen evaluatie, omdat de tijd tussen dit blog en de lancering nog te kort is. Echter, een kleine ‘sneak peak’ is er natuurlijk wel.

Er bleek in de specificatie nog wat onduidelijkheid te zitten. De bug met NFS is echter een voorbeeld van goede samenwerking. Development merkt het op en dankzij snel schakelen met systeembeheer kon snel een alternatief gevonden worden. Daarnaast is de beoogde deadline gehaald en daarmee kunnen we toch stellen dat het een succesvol project is met leerpunten voor volgende projecten.

Dit was een klein kijkje in de backup-keuken. Mogelijk denk je nu: ‘gaaf, aan zoiets zou ik ook wel willen werken!’ Goed nieuws in dat geval, we zijn namelijk op zoek naar talentvolle en gedreven ‘chef-koks’ voor in onze ‘ontwikkel-keuken’. Geïnteresseerd? kom dan solliciteren als developer of system engineer!

Bekijk de vacatures →

P.S. Wil je op de hoogte blijven van alle artikelen, updates, tips en trucs die verschijnen op ons blog? Dat kan! Rechts bovenin via RSS, e-mail, het liken op Facebook, het +1’en op Google+ of het volgen op Twitter.

Deel Deel Deel Deel

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *