Il faut bien reconnaître que les technologies Netapp n’ont pas d’équivalent quand il s’agit d’offrir des multitudes de points de reprise ou de cloner des bases de données Oracle, y compris en cluster RAC. Il suffit de regarder l’engouement actuel autour de Btrfs et de ZFS, qui développent des principes similaires, si vous n’êtes pas convaincu.

Cet article présente, de 10000 mètres, le principe de fonctionnement des snapshots et flexclone Netapp. Il s’agit de comprendre pourquoi :

1. Contrairement aux technologies Copy-On-Write, les snapshots Netapp n’ont aucun impact sur les performances du système de stockage
2. Le coût des « copies » en lecture et écritures des volumes (les flexclones) est si faible en termes de temps, d’espace et de performances

Les raisons sont liées à l’architecture logicielle du produit, d’où l’intérêt de cette explication.

Evidemment, bien des critères entre en ligne de compte quand il s’agit de choisir et mettre en oeuvre un sous-système de stockage. NetApp est bien plus riche que ces 2 pages d’explications et, chaque système à ses avantages… Si un jour vous travaillez avec des bases Oracle et des serveurs NetApp, notamment en NFS, vous apprécierez sans doute le confort et la simplicité d’utilisation, y compris avec des bases de données de plusieurs tera-octets, avec ou sans clusters ;-).

Copy-on-Write

Avant de parler de NetApp, parlons des « autres ». La plupart des snapshots, y compris ceux mis en oeuvre dans ACFS, utilise des technologies dites de Copy-On-Write (CoW) présentées dans le schéma ci-dessous :

Le principe du Copy-on-Write consiste, comme son nom de suggère, à copier (Copy) l’ancienne version d’un bloc de données dans un espace souvent dédié au moment où ce bloc est modifié par une écriture (Write) d’un des systèmes amonts. Pour se faire, on utilise une structure qui permet de virtualiser l’espace de stockage. Le snapshot présente donc toujours l’ancienne version des données malgré le changement effectué sur la LUN ou le système de fichiers original.

Ce qui apparait de manière assez évidente sur le schéma est que, si vous avez plusieurs snapshots en lignes, chaque I/O du système original met à jour la « table de correspondance » entre les blocs présentés et les anciens blocs de potentiellement tous les snapshots. Le résultat est que les technologies CoW permettent généralement de conserver un nombre relativement faible de snapshots en ligne.

BlockMap

Cet article ne s’intéresse pas précisemment à l’architecture technique des controllers, de Data Ontap, ni des différentes couches de RAID, Aggregates, Volumes, LUN ou Qtree. Ce qui nous intéresse, c’est que, si la correspondance entre les fichiers ou LUN et leur implémentation sur disque dans la plupart des solutions de stockage reste simple, celle des baies Netapp est largement plus évoluée. Cette structure s’appuie en fait sur une structure appelée BlockMap. Le schéma ci-dessous présente le fonctionnement de cette structure lorsque des données sont écrites sur disques :

Contrairement à la plupart des solutions qui reportent directement les changements dans le stockage, Netapp écrit chaque modification à un nouvel endroit et modifie la structure de BlockMap pour que le contenu du volume représente toujours les fichiers ou LUN tels que mis à jour par les systèmes amonts. Cette approche peut sembler un peu paradoxale à priori mais ce qui est important pour vous est que :

• Elle est effectuée avec une très grande efficacité ce qui permet à Netapp d’avoir des performances comparables aux baies de stockage concurrentes
• Elle offre de nombreux avantages quand il s’agit de certains mécanismes et notamment (1) le type de RAID et (2) la prise de centaines de snapshots sans aucun impact sur les performances du système.

Snapshots Netapp

La prise d’un snapshot consiste donc à copier la structure de BlockMap qui est généralement très petite (e.g. 1/20000e) si on la compare à la taille du volume. Une fois la table de BlockMap copiée, lorsque les données sont mises à jour sur le système original, parce que que le bloc correspondant est copié à une nouvelle place dans le stockage, il n’est pas nécessaire de modifier les données dans le snapshots pour le maintenir :

L’intérêt est donc assez évident : même si vous avez 100 snapshots sur votre volume, contrairement aux approches de Copy-on-Write, il n’y a pas d’impact sur les performances de votre LUN ou système de fichiers. Bien sur si vous accédez au données depuis les snapshots, c’est une autre histoire mais les snapshots servent en général d’assurance…

FlexClone et Lun Clone

Flexclone et Lun Clone fonctionnent de manière similaire au LUN ou système de fichier originaux. Le principe consiste à ce que le snapshot soit accessible en mode lecture/écriture comme sur le schéma ci-dessous :

Comme vous pouvez l’observer, le fait que les blocs ne soient pas modifiés en place fait que seul le BlockMap du clone est modifiée lors d’une écriture sur le clone. On peut donc dire que l’impact est limité. Bien sur les blocs sont écrit dans le même volume et, si les besoins de performance sont extrêmement importants sur la base de données originale on préfèrera faire le clone sur une copie de la base de données, c’est à dire :

• Soit une standby maintenue par Oracle Data Guard
• Soit une copie de la base de données maintenue par des Snapmirror ou des SnapVault

SnapManager for Oracle (SMO) et Protection Manager

Parce que (1) la prise de snapshots avec une base de données Oracle nécessite de la passer en mode de sauvegarde à chaud (Begin/End Backup), (2) l’ouverture d’une base nécessite un recover des archivelogs en cours, (3) vous voudrez intégrer les snapshots aux catalogues RMAN, (4) vous utiliserez les snapshots pour déclencher des SnapMirrors ou SnapVault et conserverez des sauvegardes sur un site distant ou (5) vous voudrez constituer des clones sur les sites distants ou décrocher les clones des snapshots d’origine sur le site primaire pour générer des copies sans aucun impact sur les performances de la production, Netapp a développé les solutions SnapManager for Oracle (Snapshots, Clones et RMAN) qu’il a intégré à Protection Manager (Snapmirror et SnapVault).

Si vous passez par la tour Ariane ou si vous avez l’occasion de mettre en oeuvre les technologies Netapp avec Oracle dans votre organisation, vous découvrirez bientôt que vous pouvez constituer des clones de vos bases de donnée
s pour quasiment 0 espace de stockage, en quelques minutes quelque soit la taille de votre base de données (y compris multi-teraoctets) ET avec 0 impact sur votre base de données de production pour un peu que vous utilisiez SnapMirror ou Data Guard. Alors, pourquoi ne pas y réfléchir ?

Notes :

• Pour ceux qui sont prêt également à remettre à plat ses idées à propos de NFS vs FCP, lisez le Technical Report intitulé « AIX Protocol Performance Comparison with Oracle Database 11g Release 2 ». Et pensez que dNFS n’implémente pas encore pNFS (disponible avec NFS 4.1), alors ?
• Il est possible de séparer les clones de leur snapshot avec les commandes lun clone split et vol clone split. La version 3.1 de SnapManager for Oracle intégre désormais le split de FlexClone pour provisioner de nouvelles bases de données sans impacter les bases originales.