dimanche 7 août 2011

Choix du type de file system sur linux: au cas où vous auriez des doutes...

Bonjour à tous,

c'est sous ce ciel menaçant que je prends ma plume pour me lancer dans un test que je voulais refaire depuis déjà quelque temps: l'incidence du choix de type de file system pour implémenter nos chunks Informix Dynamic Server, dans notre cas sur Linux.

Comme vous le savez sans doute, le raw device est depuis quelque temps une technologie obsolète sur la plupart des distributions Linux. Fait typique du conflit d'intérêts entre les éditeurs de base de données qui préconisent son utilisation,et les éditeurs d'OS et fabricants de hardware qui vont dans le sens contraire.

La manière d'implémenter des chunks sous IDS n'est pas sans effet, dans la mesure où elle impacte directement la performance d'entrées-sorties, donc la performance globale. Pour rappel, il est toujours bon de répartir au maximum les données sur le plus grand nombre possible de disque, et d'en maîtriser la disposition physique.
C'est pour celà qu'il est préférable d'éviter de créer les chunks sur des disque gérés de façon sans doute sécurisée ( RAID 0/1, RAID 5, file system journalisé etc..), mais qui vont coûter cher en termes de performance.

A priori, il est déjà inutile de sécuriser les dbspaces de données, sauf si vos bases de données ne sont pas journalisées ou si vous ne sauvegardez pas vos logical logs. Dans ces deux cas, il est probablement urgent de réviser votre stratégie sauf si la perte d'une journée de travail ou plus ne cause pas de problème.

Question sécurité de vos données, IDS est très bien fait. En "backupant" les logical logs en continu sur un device externe, et bien sur en faisant régulièrement vos sauvegardes avec ontape ou onbar, vous pouvez affronter un crash total avec un indice de confiance élevé quant à la pérennité de votre emploi.

Le gros intérêt de ce système est que IDS garantit la cohérence des données ( par le biais des transactions), et que la phase de restauration d'une instance se base sur ces mêmes transactions pour restaurer les données. L'intervalle effectif entre chaque backup de logical log sur une device externe est donc important, puisqu'il déterminera combien de temps de travail pour pouvez perdre en cas de crash de tous les disques de l'instance.

Bref, il est inutile de sécuriser vos file system hôtes de vos données, cela ne sert pas à grand chose, sauf éventuellement pour le rootdbs et/ou le dbspace contenant physical et logical logs pour garantir la disponibilité ( RAID 0/1 par exemple ).

Pour les dbspaces de données, je me suis donc livré à un exercice comparatif, qui a consisté à effectuer le dbimport d'une base de données de taille réduite ( 1.7 Gb), mais à indexation très complexe.

Le plan de test était le suivant:
1) création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
2)création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée
3)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
4)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée.

Je vois pointer la question: "qu'est-ce que DIRECT_IO ". C'est un paramètre onconfig qui permet de passer outre la couche de gestion des file systems, de telle sorte qu'IDS  écrit et lit en utilisant le Kernel IO, offrant donc pratiquement les mêmes avantages que si l'on utilisait des raw devices, à savoir sécurité d'écriture ( c'est IDS qui écrit dans le cooked file, pas le file system ), et un gain de performance variable en IO. Ce paramètre est disponible à partir de la Growth Edition,et malheureusement pas sur Innovator-C Edition :-(

faisons court:
test 1: durée du traitement =   91m41s
test 2: durée du traitement = 195m57s

test 3: durée du traitement =   54m49s
test 4: durée du traitement =   49m54s

Le vainqueur est donc sans appel le file system en ext2, avec direct_io activé.
La surprise a été le test en ext4 avec direct_io activé: combinaison à éviter absolument.

A noter que chaque test a été répété 2 fois, en prenant soin de redémarrer l'instance entretemps. Les temps obtenus pour chaque test ont été à chaque fois  très cohérents.

Vous avez donc maintenant des éléments de décision pour vos prochaines implémentations.



A bientôt sur notre station pour de nouveaux défis.