Les dernières version d’Oracle (12.2 et supérieures) apportent une nouveauté subtile coté ASM pour la redondance des groupes des disques.
Elle est décrite sur le blog Oracle dans un article du « Product Manager » Jim Williams : ici
Je souhaiterais revenir dessus pour en souligner l’importance et l’intérêt, et en profiter pour remettre quelques principes de base de la fonctionnalité.
Les préconisations fortes de l’éditeur quand on utilise ASM et ses groupes de disques sont d’utiliser :
- un nombre restreint de groupes de disques, chaque groupe de disques étant composé du plus grand nombre de disques possible (36 grid disques quand on travaille sur un appliance Exadata)
- un disque groupe pour les fichiers de données de toutes les bases (en général DATA)
- et un disque groupe pour accueillir les zones de récupérations rapides (FRA) de toutes les bases.
C’est bien, mais si, en plus, on applique la protection (le mirroring) en s’appuyant sur les recommandations SAME (Stripe And Mirror Everything), c’est très gourmand en espace disque, particulièrement avec l’utilisation d’une redondance haute.
Pour comprendre cela, plusieurs points sont à prendre en compte.
Les groupes d’échec :
- La redondance est mise en œuvre par le mécanisme de groupes d’échec (Failure Group)
- Par défaut, à la création du groupe de disque, si l’information « failure group » n’est pas présente, il y a association d’un groupe d’échec par disque composant le groupe.
Les niveaux de redondance possible :
- Redondance normale (Normal redondancy) : chaque extent possède une copie, deux groupes d’échec (Failure Group) sont requis à minima, trois sont recommandés. L’espace utilisable est divisé par deux par rapport à l’espace total dans le groupe de disques.
- Redondance haute (High Redondancy) : chaque extent est écrit en trois exemplaires, trois groupes d’échec sont requis, quatre sont recommandés. L’espace utilisable est divisé par trois par rapport à l’espace total dans le groupe de disques.
- Redondance externe : Pas de protection par ASM, on assume que la sécurité des données est assurée par le matériel sous-jaçant (baie SAN, pool de disques gérés en RAIDn). On dispose de la volumétrie du LUN présenté par la baie de stockage.
Exemple de la protection apportée par la redondance normale, représentation de 3 extents sur 3 disques, un groupe d’échec par disque :
En cas de perte d’un disque (donc d’un groupe d’échec), les données des extents restent accessibles au travers de leur copie :
Rappel de la règle de l’espace utilisable :
Avec la redondance gérée par ASM, il doit toujours rester dans le groupe de disques suffisamment d’espace disponible pour s’assurer qu’en cas de perte d’un groupe d’échec (voire de deux pour la triple redondance), les données restantes puissent être toute de nouveau protégées avec le niveau de redondance défini.
Ainsi, sur la perte d’un ou plusieurs disques, la remise en place de la redondance pour les données restantes nécessite d’avoir suffisamment d’espace disponible. Si ce n’est pas la cas, certains fichiers ne seront pas protégés, amenant une redondance réduite (reduced redundancy).
Une redondance réduite signifie qu’un ou plusieurs extents d’un fichier ne sont pas mis en miroir avec le bon niveau de protection. Par exemple, dans un disque groupe défini avec une redondance haute, un fichier en redondance réduite possède au moins un extent avec seulement un miroir, voire aucun. Pour les fichiers définis sans protection (sans redondance), il peut manquer des extents complets.
Il faut donc suivre les préconisations d’Oracle pour s’assurer d’avoir toujours l’espace nécessaire dans vos groupe de disques :
- Groupe de disques avec redondance normale : Il faut avoir assez d’espace disque pour accepter la perte de tous les disques d’un groupe d’échec. L’espace libre disponible doit correspondre à la taille du groupe d’échec le plus volumineux.
- Groupe de disque avec redondance haute : Il faut avoir assez d’espace disque pour accepter la perte de tous les disques de deux groupes d’échec. L’espace libre disponible doit correspondre à la somme de la taille des deux groupes d’échec les plus volumineux.
Les informations fournies par l’instance ASM, au travers de la vue V$ASM_DISKGROUP, ou avec l’utilitaire « asmcmd » et la commande lsdg montrent les colonnes suivantes :
- REQUIRED_MIRROR_FREE_MB : Espace nécessaire dans le groupe de disques pour remettre la redondance sur les données restantes après la panne la plus importante qui peut être acceptée (voir la règle ci dessus).
- USABLE_FILE_MB : Espace utilisable pour de nouveaux fichiers dans le groupe de disque. L’espace prend en compte le mirroring. La formule de calcul est : USABLE_FILE_MB=(FREE_MB – REQUIRED_MIRROR_FREE_MB) / redondance.
- TOTAL_MB : Capacité totale du groupe de disques. La valeur tient compte de l’espace occupé par les entêtes des disques (environ 1%, mais est dépendant du nombre de disques et de fichiers).
- FREE_MB : Espace libre total dans le groupe de disques sans tenir compte d’un potentiel déséquilibrage.
Dans les faits, si nous regardons ces informations pour un groupe de disques en redondance normale, composé de 6 disques de 1Go et d’un groupe d’échec par disque, nous pouvons avoir : 1372 Mo utilisable, alors qu’il y a 3768 Mo d’espace libre. Le calcul étant : (3768 – 1024) / 2 = 2744 / 2 = 1372.
SQL>SELECT name, type, total_mb, free_mb, required_mirror_free_mb, usable_file_mb FROM V$ASM_DISKGROUP; NAME TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB --------------------------------------------------------------------- DATA NORMAL 6144 3768 1024 1372
La granularité de la redondance :
La redondance définie au niveau du groupe de disques est celle qui est utilisée par défaut. Cependant, dans le cas d’une redondance normale (et seulement dans ce cas), on peut définir une redondance spécifique par fichier. C’est ce que fait d’ailleurs Oracle au travers de son modèle par défaut (template) qui fixe une redondance triple pour les fichiers de contrôles, même si la redondance du groupe de disques est de type NORMAL.
La consolidation des bases sur un seul serveur pose un problème : On va trouver, dans le disque groupe DATA, des fichiers de données pour les bases de production et pour les bases de test ou de développement; si on laisse la même redondance partout, on perd de l’espace, car certains fichiers de certaines bases n’ont pas besoin du même niveau de protection (les bases de test par exemple).
Une solution avant la version 12.2 est d’utiliser les modèles « template » que l’on va associer au groupe de disques pour gérer cela :
Création de deux modèles
Un modèle de type « données sécurisées » :
SQL>ALTER DISKGROUP data ADD TEMPLATE reliable ATTRIBUTES (HIGH);
Un modèle de type « données non sécurisées » :
SQL>ALTER DISKGROUP data ADD TEMPLATE unreliable ATTRIBUTES (UNPROTECTED);
Il faut ensuite utiliser OMF pour le nommage des fichiers de données (pas de clause de nommage dans la commande), exemple :
SQL>CREATE TABLESPACE APPLI DATAFILE SIZE 600M ;
Pour les bases de production, création des tablespaces, avec, au préalable, le paramétrage suivant :
SQL>ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+data(reliable)';
Pour les bases de test ou de développement, on utilisera le paramétrage précisant l’autre modèle :
SQL>ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+data(unreliable)';
Si on obtient bien le résultat voulu, on le constate vite à l’usage, c’est complexe à utiliser et à maintenir.
La réponse d’Oracle pour tirer pleinement profit de la granularité au niveau fichier est d’introduire deux nouveaux concepts :
- le type de redondance « FLEX redondancy »
- et la notion de « Groupes de fichiers ».
Le principe est simple, chaque base de données que l’on va créer va être associée à un groupe de fichiers (par défaut du nom de la base de données), chaque groupe de fichiers ayant sa propre redondance et d’autres attributs propres comme un quota associé.
La première étape est de créer un groupe de disques, avec une redondance de type FLEX pour cela.
En prérequis :
- paramètres « compatible.asm »
- et « compatible.rdbms » supérieur ou égal à 12.2
Création d’un groupe de disques avec une commande de type :
SQL>CREATE DISKGROUP DG_FLEX_DATA FLEX REDUNDANCY DISK 'AFD:DISK1','AFD:DISK2','AFD:DISK3';
Ou transformation de la redondance de votre groupe de disques de NORMAL ou HIGH en FLEX avec la série de commandes :
SQL>alter diskgroup DG_NORMAL dismount; SQL>alter diskgroup DG_NORMAL mount restricted; SQL>ALTER DISKGROUP DG_NORMAL CONVERT REDUNDANCY TO FLEX; SQL>alter diskgroup DG_NORMAL dismount; SQL>alter diskgroup DG_NORMAL mount;
Ensuite, il faut créer les groupes pour les fichiers et les associer à une base de données avec l’attribut de leur redondance. Ainsi, pour le modèle multitenant, voici la répartition pour le tenant de production PDB1 et le tenant de test PDB2 :
SQL>ALTER DISKGROUP DATA_FLEX_1 ADD FILEGROUP FileGroup_PDB1 DATABASE PDB1 SET 'datafile.redundancy'='HIGH' ; SQL>ALTER DISKGROUP DATA_FLEX2 ADD FILEGROUP FileGroup_PDB2 DATABASE PDB2 SET 'datafile.redundancy'='UNPROTECTED' ;
Est aussi introduite une notion de groupe de quota, qui pourra limiter la consommation d’espace par environnement.
Ce qui peut donner le type de répartition suivante :
Prenons un cas pratique simple :
- un disque groupe DATAEX composé de 3 disques de 40 Go en redondance triple soit 120 Go au total.
- J’ai dessus une base de production de 10 Go soit une empreinte de 30 Go sur le groupe de disques.
- Une base de qualification, copie de la base de production, de 10 Go avec empreinte de 30 Go.
- Une base de développement, autre copie de la base de production, avec elle aussi une empreinte de 30 Go.
J’ai donc 90 Go occupés sur 120 Go, je suis proche de ma limite pour respecter REQUIRED_MIRROR_FREE_MB.
Si je convertis mon groupe de disques DATAEX en redondance global FLEX, que j’associe les fichiers de ma base de PROD avec un groupe de fichiers de redondance ‘HIGH’, pas de changement, l’empreinte est toujours de 30 Go.
J’associe les fichiers de ma base de QUALIF à un groupe de fichiers sans redondance (datafile.redundancy =’EXTERNAL’), l’empreinte passe à 10 Go.
J’associe les fichiers de ma base de DEV à un groupe de fichiers sans redondance (datafile.redundancy =’EXTERNAL’), l’empreinte passe elle aussi à 10 Go.
Je n’ai donc plus que 50 Go occupés sur 120 Go, soit 40 Go d’espace économisé !
Plus vous avez d’environnements non critiques dupliqués, plus vous gagnerez d’espace et économiserez peut-être l’achat de nouvelles cellules de stockage.
On l’a vu, cette discrète nouvelle fonctionnalité peut avoir un impact important sur le budget de votre service.
Pensez-y au moment de vous poser la question « Est-ce que je mets à jour mon système en version 12.2 (ou supérieure) ? »
Référence : Documentation Oracle
