article 6 novembre 2018

Storage NFS per applicazioni atlassian server

Le applicazioni Atlassian hanno la tendenza a farsi apprezzare dagli utenti e dalle organizzazioni che le adottano. Capita spesso che vengano inizialmente introdotte come strumento per un singolo team, ma in breve tempo acquisiranno slancio e si diffonderanno tra un numero crescente di team. Al punto che la direzione capirà che stanno diventando uno strumento importante all’interno dell’azienda. I dati archiviati nell’applicazione sono di importanza cruciale per le attività aziendali e devono essere salvaguardati. A questo scopo, il server che prima era ospitato sotto una scrivania verrà consegnato al reparto IT, e lì verrà adeguatamente accudito dallo staff informatico. Ma questo cosa significa? Ovviamente l’azienda può contare su un eccellente reparto IT che:

• aggiorna periodicamente le applicazioni a una versione stabile
• applica tempestivamente patch per le vulnerabilità di sicurezza, non appena Atlassian le rilascia
• aggiorna il sistema operativo quando necessario
• esegue il monitoraggio dei server
• crea i backup
• e così via

Quando sempre più utenti dell’organizzazione iniziano a utilizzare le applicazioni, i contenuti man mano aggiunti aumentano. Parliamo di documentazione, immagini, repository git, ecc. Col tempo, tutti questi bit e byte si sommano, e ci si ritrova ad ampliare la capacità di archiviazione locale fino al punto in cui ha senso ripensare le scelte fatte in passato. Si potrebbe anche prendere in considerazione l’idea di passare a una soluzione di alta disponibilità, ad esempio una soluzione Atlassian Data Center. Per prepararsi a questa transizione, si può cominciare a memorizzare i dati su un file server NFS.

QUINDI, CHE FARE?
Mentre si valuta il da farsi, probabilmente si vorrà spostare l’intera home directory della propria applicazione sul server NFS; perché no? Valutando l’ipotesi della configurazione data center di un’applicazione Atlassian, è facile decidere di spostare la home directory della propria applicazione server Atlassian su NFS.

Qui sono costretto a fermarvi! Le applicazioni non possono gestire una home directory localizzata su NFS. Le ragioni sono molteplici:

1. Jira ha la bisogno di indicizzare le issue (problemi), ma su NFS questo processo comporta una notevole perdita di tempo. La memorizzazione dell’indice su unità SSD locali riduce drasticamente il tempo dell’indicizzazione. Ad esempio: Una re-indicizzazione di un singolo progetto con 2.400 problemi e la cui home directory si trova su NFS impiega 3 ore e 14 minuti. Nelle stesse circostanze, con solo una parte della home directory su NFS, sono necessari 35 minuti per completare un re-indicizzazione del sistema (per un totale di oltre 250.000 problemi).
2. Lo stesso discorso vale per Confluence. Avere l’intera home directory su NFS comporta un’indicizzazione estremamente lenta delle pagine.
3. Per Bitbucket c’è un motivo ancora più convincente per trasferire solo una parte della home directory su NFS. La ragione primaria è la velocità delle operazioni git. Abbiamo notato che quando si esegue la clonazione di un repository, git inizia a creare un file git-pack sul server. Durante la creazione di questo file git-pack, la velocità del download risulta fino a 60 volte più lenta rispetto a quando la creazione del file git-pack è terminata. Questo comportamento si manifesta in particolare nella clonazione di archivi di grandi dimensioni (> 1 GB). Inoltre, abbiamo osservato che quando più persone avviano la stessa operazione di clonazione (stesso repository, stesso commit), tutte devono attendere il completamento della medesima creazione del file git-pack. Una volta terminata l’operazione, le velocità aumentano di nuovo per tutti i cloni. Da ultimo, abbiamo scoperto che se si decide di interrompere sul lato client una clonazione già avviata, l’operazione git-pack sul server continua l’elaborazione.

Quindi, è opportuno allocare sul server NFS solo determinate directory su cui archiviare i dati. Tutti gli altri dati nella home directory devono essere memorizzati su supporti locali al proprio server, preferibilmente su unità SSD.

SUDDIVIDI LA TUA HOME!

Ecco come fare. Prima di tutto “mai cambiare una gomma mentre si guida”: quindi, arrestare l’applicazione prima di iniziare la migrazione dei dati.

Per Jira è necessario copiare i dati correnti delle cartelle home “dati”, “plug-in”, “logos”, “import” ed “export” sul server NFS. Poi, esportare tali cartelle sul server NFS, creare le directory di mount nella home directory di Jira e montale: il gioco è fatto!

Per Confluence è possibile seguire lo stesso procedimento, ma questa volta con le cartelle “attachments”, “backups”, “export”, “recovery”, “restore”, “shared-home” e “thumbnails”. Si noti che alcune di queste directory potrebbero non essere presenti sul proprio server. Se non si utilizza una determinata funzionalità, come il ripristino di uno spazio, la directory non viene creata.

E infine, per Bitbucket è necessario spostare la cartella “shared” sul server NFS.

Dopo aver suddiviso in questo modo la propria home directory, si potrà continuare a utilizzare le applicazioni a velocità impressionante e con enormi pssibilità di crescita!