La gestion du cycle de vie de la donnée ou ILM en anglais, pour Information Lifecycle Management, vise une meilleure adéquation entre le coût du stockage et l’obsolescence de la donnée.
Comment EXADATA peut-il nous aider ?
Règles de base de l’ILM
On part du constat suivant, nouvel avatar de la fameuse règle des 80/20 :
- On accède fréquemment aux données récentes alors que celles-ci ne représentent qu’une faible partie de la volumétrie globale ;
- Les données anciennes sont peu utilisées mais, stockées sur les mêmes supports que les données récentes, pèsent lourdement sur les coûts de stockage.
Il faut donc adapter la technologie et les coûts de stockage à l’obsolescence de la donnée :
- Le vieillissement de la donnée entraînera son déplacement vers des solutions de stockage plus capacitives mais moins onéreuses.
La majorité des solutions proposées sur le marché s’appuient sur des critères simples :
- Vieillissement de la donnée, où par donnée il faut entendre l’ensemble des données contenues dans un fichier ou un volume disque ;
- Taux d’accès aux données, où par données il faut entendre l’ensemble des données contenues dans un fichier ou un volume disque voire un bloc[1].
Toutes ces solutions reposent sur le principe d’une hiérarchisation des infrastructures de stockage, tiered storage en anglais.
Il importe donc d’éviter une complexité inutile de la politique d’ILM. Selon David Merrill, Hitachi[2], la hiérarchisation des infrastructures de stockage permet, sur une période de 3 ans, une réduction de 15 à 30% du coût de possession à condition, toutefois, de limiter le nombre de niveaux hiérarchiques.
EXADATA
EXADATA, le bébé de Larry, est une solution intégrée comprenant matériel et logiciel :
- Serveurs, stockage et réseau INFINIBAND pour le matériel ;
- Système d’exploitation Oracle Enterprise Linux et moteur de base de données 11gR2 en cluster RAC pour le logiciel.
En fait EXADATA est un terme impropre ; il faudrait parler d’Exadata Database Machine et non d’ EXADATA tout court, qui ne désigne que la partie stockage. Mais, par suite d’un glissement sémantique, même chez Oracle, la partie en est venue à désigner le tout.
Exadata X2-2 se décline en comme suit :
Les cellules de stockage contiennent chacune 12 disques SAS ou SATA et toutes les cellules d’un même cabinet doivent être équipées de la même technologie disque.
EXADATA nouvelle mouture ou Exadata X2-8[3] contient seulement 2 serveurs de traitements et 14 cellules de stockage. Chaque serveur de traitement se compose de :
- 8 processeurs intel Xeon octocores ;
- 1 To de RAM
- 8 ports infiniband QDR et 8 ports 10 Gb
- 8 disques internes SAS 300 G
Dans le présent article nous nous intéresserons aux configurations ne comportant qu’un seul cabinet et aux architectures dédiées aux applications décisionnelles.
Nous nous focaliserons sur les données et considérerons qu’il n’y a aucun index. La gestion des index dans le cadre de l’ILM fera l’objet d’un article complémentaire.
Les technologies Oracle pour l’ILM
Sur une infrastructure traditionnelle, Serveur(s) de base de données connecté(s) à une infrastructure SAN, la gestion du cycle de vie des données stockées dans une base Oracle nécessite la mise en œuvre de l’option Oracle Partitioning.
Sans cette option, il est quasiment impossible de tirer parti d’une infrastructure de stockage hiérarchisée.
Les données sont partitionnées selon l’axe temporel ; depuis la version 11g, on aura intérêt à utiliser le partitionnement par intervalles. Rappelez-vous : Les coûts d’acquisition ne représentent que 20 à 25% des coûts de stockage ; l’administration du stockage représente quant à elle 75 à 80% des coûts. Il convient de simplifier le plus possible les tâches d’administration ; évitons donc d’avoir à gérer le futur, concentrons nous sur la gestion du passé.
Les nouvelles partitions, créées automatiquement par la base de données, sont affectées à un TABLESPACE courant qui sera, bien évidemment stocké sur des disques rapides sécurisés soit via du RAID hardware soit via la redondance offerte par Oracle Automatic Storage Management ou ASM. Le choix de l’intervalle –jour, mois, trimestre…– dépendra de l’application de même que les règles de gestion de l’obsolescence.
Supposons, pour les besoins de la démonstration, que l’intervalle retenu est le mois. La politique de gestion du cycle de vie de nos données pourrait être la suivante :
- 3 niveaux de stockag, par exemple :
- Niveau 1, en RAID-10 ou redondance ASM sur des disques rapides ;
- Niveau 2, en RAID-5 sur des disques rapides ;
- Niveau 3, en RAID-5 sur des disques capacitifs et moins rapides.
- Politique d’allocation des niveaux de stockage :
- Niveau 1 pour les données courantes et les données de moins de 6 mois ;
- Niveau 2 pour les données de plus de 6 mois et moins de 2 ans ;
- Niveau 3 pour les données de plus de 2 ans.
- Politique de partitionnement Oracle:
- Partitionnement par intervalle au mois dans le TABLESPACE courant ;
- En fin de mois, déplacement de la partition mensuelle dans un TABLESPACE mensuel ;
- Au bout de 6 mois, déplacement du TABLESPACE mensuel du niveau 1 vers le niveau 2 et passage du TABLESPACE en lecture seule (READ ONLY) car ces données ne sont plus sujettes à modification ;
- Au bout de 2 ans, déplacement du TABLESPACE du niveau 2 vers le niveau 3
Mais alors, me direz-vous, comment mettre en œuvre une hiérarchisation du stockage quand nous disposons d’une et une seule technologie de disque ?
Les technologies EXADATA pour l’ILM
Avec EXADATA on dispose de plusieurs techniques de compression :
- Compression standard intégrée à Oracle Enterprise Edition depuis la version 9i ;
- L’option Oracle Advanced Compression introduite avec la version 11g ;
- Oracle Hybrid Columnar Compression ou HCC disponible uniquement sur EXADATA, depuis la version 2 d’EXADATA.
L’option Oracle Advanced Compression, payante comme toutes les options, est surtout intéressante pour les applications transactionnelles.
Pour les environnements décisionnels son intérêt est des plus limité. Si l’intégration des nouvelles données se fait en mode chargement de masse cette option n’a aucune utilité.
En revanche, pour un chargement au fil de l’eau, il faudra se livrer à une étude économique mettant en balance les coûts de licence et les bénéfices qu’apporterait l’utilisation de ce type de compression. Dans la suite de cet article nous exclurons donc cette option.
Les techniques restant à notre disposition sont donc la compression standard et les différents modes de compression HCC[4] :
- Warehouse Compression (QUERY) avec, selon Oracle, un taux de compression de 10 :1 (x10) ;
- Archive Compression (ARCHIVE) avec, toujours selon Oracle, un taux de compression de 15 :1 (x15).
Les taux de compression obtenus sont très dépendants de la nature et de la distribution des données. Nous prendrons donc des valeurs moyennes:
- Compression standard, X2 ;
- Compression Datawarehouse, X6 ;
- Compression Archive, X10.
Ces valeurs sont très conservatrices car nous avons pu constater, sur des données client, les taux suivants :
- Compression standard [1.7, 3] ;
- Compression Datawarehouse [9,10] ;
- Compression Archive X13.
Politiques d’ILM sur EXADATA
Nous pouvons désormais répondre à la question posée préalablement, que nous transformerons comme suit :
- Comment mettre en œuvre une politique d’ILM sur EXADATA quand nous disposons d’une et une seule technologie de disque ?
En lieu et place d’une hiérarchie de stockage basée sur différentes technologies de disques, nous mettrons en place une hiérarchie basée sur le type de compression utilisable :
- Aucune compression ;
- Compression standard ;
- Compression HCC en mode Datawarehouse ;
- Compression HCC en mode Archive.
La mise en œuvre de ces différentes techniques va à l’encontre de simplicité ; il nous faudra donc faire des choix :
- Nombre de niveaux à utiliser ;
- Type de compression pour chaque niveau.
- Passage du TABLESPACE en lecture/écriture (READ WRITE) ;
- Pour chaque table, EXCHANGE PARTITION afin de compresser la partition, dans un TABLESPACE de manœuvre, puis la réintégrer dans la table et le TABLESPACE d’origine ;
- Sauvegarde du TABLESPACE contenant les partitions nouvellement compressées.
Politique d’ILM en mode chargement de masse
- Politique avec compression standard puis compression HCC en mode Datawarehouse ;
- Politique en mode non compressé puis compression HCC en mode Datawarehouse.
Dans les deux cas, il faudra se livrer à des tests pour choisir le mode le mieux adapté, à savoir QUERY LOW ou QUERY HIGH, et prendre en compte les paramètres suivants :
- Taux de compression obtenu avec chacun des modes ;
- Temps de compression pour chacun des modes ;
- Impact du mode de compression (QUERY LOW et QUERY HIGH) sur le temps de réponse des requêtes les plus fréquentes.
- Impact de la compression sur le temps de chargement des nouvelles données ;
- Taux de compression obtenu en mode compression standard ;
- Impact de la compression standard sur le temps de réponse des requêtes les plus fréquentes.
Au final, notre politique d’ILM se présentera comme suit :
- Définition des modes de compression
- Compression standard ou aucune compression pour les données courantes et les données de moins de 6 mois ;
- Compression HCC QUERY HIGH (ou LOW) pour les données de plus de 6 mois
- Politique de partitionnement Oracle
- Partitionnement par intervalle au mois dans le TABLESPACE courant ;
- En fin de mois, déplacement de la partition mensuelle dans un TABLESPACE mensuel ;
- Au bout de 6 mois, EXCHANGE PARTITION pour compression dans le mode HCC QUERY (HIGH ou LOW) retenu ;
- Passage du TABLESPACE en READ ONLY.
Politique d’ILM en mode chargement au fil de l’eau
On supposera que, dans ce mode, les données sont chargées au moyen de transactions courtes pouvant insérer de nouvelles données ou modifier des données récemment insérées.
Ce type de chargement est peu compatible avec la compression standard car les données en entrée ne sont pas triées et peuvent être modifiées après insertion. Il faudrait utiliser la compression en mode Advanced Compression qui est une option payante.
Nous recommandons donc de n’utiliser cette option que si les gains obtenus compensent le coût de l’option (acquisition et support) :
- Taux de compression obtenu ;
- Impact de la compression sur le temps de réponse des requêtes les plus fréquentes ;
- Absence de pénalisation sur les temps de chargement.
Il faudra se livrer, comme dans le cas précédent, à des tests pour choisir le mode le mieux adapté, à savoir QUERY LOW ou QUERY HIGH.
- Définition des modes de compression
- Aucune compression pour les données courantes et les données de moins de 6 mois, sauf justification économique en faveur de l’utilisation de l’option Advanced Compression ;
- Compression HCC QUERY HIGH (ou LOW) pour les données de plus de 6 mois
- Politique de partitionnement Oracle
- Partitionnement par intervalle au mois dans le TABLESPACE courant ;
- En fin de mois, déplacement de la partition mensuelle dans un TABLESPACE mensuel ;
- Au bout de 6 mois, EXCHANGE PARTITION pour compression dans le mode HCC QUERY (HIGH ou LOW) retenu ;
- Passage du TABLESPACE en READ ONLY.
SYNTHÈSE
Les modes de compression propres à EXADATA permettent de mettre en œuvre une politique d’ILM sur des configuration ne comportant qu’une technologie de disques, SAS ou SATA.
La simplicité milite en faveur de politique d’ILM à 2 niveaux hiérarchiques :
- Aucune compression ou Compression standard ;
- Compression EXADATA en mode Datawarehouse (HCC QUERY HIGH ou HCC QUERY LOW).
L’utilisation d’un troisième niveau utilisant le mode ARCHIVE doit faire l’objet d’une étude économique si et seulement si le taux de compression obtenu dans ce mode (ARCHIVE HIGH ou ARCHIVE LOW) est très supérieur au taux retenu pour le mode Datawarehouse :
Selon nous, le gain obtenu devrait permettre de réduire la volumétrie des données soumises à compression d’au moins 40% pour justifier une étude économique.
En effet, l’ajout d’un troisième niveau utilisant le mode de compression ARCHIVE entraîne un surcroît de complexité en terme de procédures d’exploitation.
[1] Data Progression de Compellent, par exemple, gère la donnée au niveau bloc
2 réflexions sur “EXADATA et la gestion du cycle de vie de la donnée”
Ping : HCC disponible pour les baies Pillar et ZFS ! « EASYTEAM LE BLOG
Excellent article !
Les commentaires sont fermés.