article 6 november 2018

NFS-lagring för atlassians serverprogram

Atlassian-program har en tendens att få dig och din verksamhet att tycka om dem mer och mer med tiden. Vad som ofta börjar som ett verktyg för ett enda team hämtar snart fart och team efter team tar till sig det. Det blir så populärt att ledningen till slut inser att det har blivit ett viktigt verktyg inom verksamheten. Data som lagras i programmet är affärskritiskt och måste skyddas. För att förverkliga detta kommer så kallade ”under-skrivbordet-servrar” att överlämnas till IT-avdelningen, där de vårdas ordentligt av IT-personalen. Men vad innebär det ens? Självklart har du en utmärkt driven IT-avdelning som

• regelbundet kommer att uppgradera program till en stabil version
• snabbt fixar säkerhetssårbarheter, så fort Atlassian släpper en patch
• vid behov kommer att fixa operativsystemet med patcher
• övervakar servrarna
• skapar säkerhetskopior
• osv.

När fler och fler användare inom din organisation använder programmen kommer de också att tillföra mer innehåll till dem. Innehållet kan vara allt från kontorsdokument till bilder och git-lagringsplatser osv. Med tiden kommer alla dessa bitar och bytes att staplas på hög och du hamnar i en situation där du expanderar din servers lokala diskar till den punkt att det är logiskt att tänka om kring de val du har gjort. Du kanske till och med överväger att gå över till en högtillgänglighetslösning i form av en datacenterlösning från Atlassian. För att förbereda dig för övergången kan du börja lagra data på en NFS-filserver.

SÅ VAD SKA DU GÖRA?

När du ändå håller på vill du antagligen flytta hela ditt programs hemkatalog till NFS-servern, för det är väl lika bra? Genom att titta på datacenterlayouten hos ett Atlassian-program kan du enkelt ta beslutet att flytta hemkatalogen för ditt Atlassian-serverprogram till NFS.

Men här måste jag stoppa dig! Programmen kan inte hantera en hemkatalog som sitter på NFS. Det finns flera skäl till detta:

1. Jira måste skapa ett index över problemen och över NFS kommer det att vara mycket tidskrävande. Att lagra indexet på din lokala SSD kommer att förbättra indextiden avsevärt. Ett exempel: Att skapa ett nytt index för ett enda projekt med 2 400 problem där arbetsmappen är placerad på NFS tog 3 timmar och 14 minuter. För samma exempel, med bara en del av hemkatalogen på NFS, tog det 35 minuter att färdigställa ett nytt index över systemet (totalt över 250 000 problem).
2. En liknande historia finns för Confluence. Att ha hela hemkatalogen på NFS kommer att resultera i en väldigt långsam indexering av sidorna.
3. För Bitbucket finns det ett ännu mer övertygande skäl att lagra bara en del av hemkatalogen på NFS. Detta beror främst på hastigheten för git-processer. Det vi har observerat är att när du börjar skapa en klon för en lagringsplats kommer git att börja skapa en git-pack-fil på servern. Under skapandet av denna git-pack-fil är hämtningshastigheten upp till 60 gånger långsammare än när skapandet av git-pack-filen är klar. Detta beteende gäller särskilt när du klonar mycket stora lagringsplatser (> 1 GB). En andra observation var att när flera personer startar samma klonprocess (samma lagringsplats, samma commit) måste de alla vänta på samma git-pack-filprocess. När det var klart ökade hastigheten igen för alla kloner. Till sist såg vi att när du startade en klonprocess men bestämde dig för att avbryta den på klientsidan fortsatte git-pack-processen på servern.

Så vad som behöver göras är att endast allokera vissa kataloger på NFS-servern för datalagring. Alla övriga data i hemkatalogen bör lagras lokalt någonstans på din server, helst på en SSD-hårddisk.

DELA DITT HEM!

Och så här gör du det. För det första bör man inte ändra på hjulen medan man kör, så stäng ner ditt program innan du påbörjar datamigrationen.

För Jira behöver du kopiera alla aktuella data i hemmamapparna ”data”, ”plugin-program”, ”import” och ”export” till NFS-servern. Exportera sedan dessa på NFS-servern, skapa monteringskataloger i Jira-hemkatalogen, montera dem och sen är allt klappat och klart!

För Confluence gör du samma sak, men nu med mapparna ”bifogat”, ”säkerhetskopieringar”, ”exporterat”, ”återskapat”, ”återställt”, ”delade hem” och ”miniatyrbilder”. Observera att några av dessa kataloger kanske inte finns på din server. Om du inte har använt en viss funktion, såsom att återställa ett utrymme, har katalogen inte skapats.

Och slutligen behöver du flytta ”delat” till NFS-servern för Bitbucket.

När du har delat upp hemkatalogen på det här sättet kommer du att fortsätta din resa med blixtsnabb hastighet och enorm tillväxtmöjlighet!