article 6 novembre 2018

Stockage NFS pour les applications serveur d’atlassian

Les applications Atlassian tendent à développer votre organisation et vous-même. Ce qui démarre normalement comme un outil pour une seule équipe va bientôt prendre de l’ampleur et de plus en plus d’équipes suivront. À tel point que la direction réalisera qu'il devient un outil important au sein de l'entreprise. Les données stockées dans l'application sont sensibles et doivent être sauvegardées. Pour cela, le serveur nommé under-the-desk sera transmis au service informatique, où il sera correctement géré par le personnel informatique. Mais qu'est-ce que cela veut dire ? Naturellement, vous disposez d’un excellent service informatique opérationnel qui :

• actualise les applications vers une version stable à intervalles réguliers
• corrige rapidement les failles de sécurité que Atlassian pourrait présenter
• corrige le système d’exploitation en cas de besoin
• surveille les serveurs
• crée des sauvegardes
• etc.

Lorsque de plus en plus d'utilisateurs de votre organisation utilisent les applications, ils y ajoutent également du contenu. Les contenus peuvent être des documents ou des images, en passant par des référentiels de données git etc. Au fil du temps, tous ces bits et octets s’additionneront et vous vous retrouverez à étendre les disques durs locaux de votre serveur jusqu’à ce que vous vous rendiez compte qu’il faut revoir les choix que vous avez faits dans le passé. Vous pourriez même envisager de passer à une solution de haute disponibilité comme celle du centre de données Atlassian. Pour préparer cette transition, vous pouvez commencer à stocker les données sur un serveur de fichiers NFS.

DONC QUE POUVEZ-VOUS FAIRE ?

Pendant que vous y êtes, vous voudrez probablement déplacer le répertoire personnel complet de votre application sur le serveur NFS. Oui, pourquoi pas ? En regardant la configuration du centre de données d'une application Atlassian, vous pouvez simplement décider de déplacer tout le répertoire personnel de votre application serveur Atlassian vers NFS.

Eh bien c'est là que je dois vous arrêter ! Les applications ne peuvent pas gérer un répertoire personnel situé dans NFS. Et cela pour plusieurs raisons :

1. Jira doit répertorier les problèmes. Sous NFS, cela prendra beaucoup de temps. Le stockage de l’index sur votre disque SSD local améliorera considérablement les temps d’indexation. Par exemple : la ré-indexation d'un projet unique comportant 2 400 problèmes avec un répertoire personnel sur NFS a pris 3 heures et 14 minutes. Pour le même cas, avec seulement une partie du répertoire personnel sur NFS, il a fallu 35 minutes pour effectuer une ré-indexation du système (avec un total de plus de 250 000 problèmes).
2. C’est la même chose pour Confluence. Mettre tout le répertoire personnel sur NFS entraînera une très lente indexation des pages.
3. Pour Bitbucket, il existe une raison encore plus convaincante de ne stocker qu'une partie du répertoire personnel sur NFS. La raison principale est la rapidité des opérations git. Ce que nous avons observé, c’est que lorsque vous créez un clone pour un référentiel, git commence à créer un fichier pack sur le serveur. Lors de la création de ce fichier pack git, la vitesse de téléchargement est jusqu'à 60 fois plus lente que lorsque la création du fichier pack est terminée. Ce comportement est particulièrement visible lorsque vous clonez des référentiels très volumineux (> 1 GB). La deuxième observation est que lorsque plusieurs personnes démarrent la même opération de clonage (même référentiel, même commit), elles doivent toutes attendre sur la même opération de fichier pack git. Une fois terminé, la vitesse augmente de nouveau pour tous les clones. Enfin, nous avons constaté qu’une fois que vous avez démarré une opération de clonage, mais que vous avez décidé de l’interrompre sur le site du client, l’opération git-pack continue sur le serveur.

Il ne reste donc qu'à allouer certains répertoires au NFS pour y stocker des données. Toutes les autres données du répertoire personnel doivent être stockées dans une mémoire locale du serveur, de préférence un lecteur SSD.

PARTAGEZ VOTRE RÉPERTOIRE PERSONNEL !

Et voici comment le faire. Tout d’abord, ne faites pas deux choses en même temps et arrêtez votre application avant de commencer la migration des données.

Pour Jira, vous devez copier les données actuelles des dossiers locaux « data », « plugins », « logos », « import » et « export » sur le serveur NFS. Puis exportez-les sur le serveur NFS, créez des répertoires mount-over dans le répertoire personnel Jira, montez-les et le tour est joué !

Pour Confluence, vous devez faire la même chose, mais cette fois avec les dossiers « attachments », « backups », « export », « recovery », « restore », « shared-home » et « thumbnails ». Veuillez remarquer que sur votre serveur, certains de ces répertoires peuvent ne pas exister. Si vous n’avez pas utilisé certaines fonctionnalités, telles que la restauration d’un espace, le répertoire n’est pas créé.

Enfin, pour Bitbucket, vous devez déplacer le « dossier partagé » vers le serveur NFS.

Après avoir partagé le répertoire personnel de cette façon, vous pourrez poursuivre votre activité avec une vitesse fulgurante et une énorme possibilité d’expansion !