1

Comment un Flexclone Netapp permet-il de cloner d’une base de 5 To en 15 minutes ?

Posted on 25, octobre 2010 by Gregory Guillou in blog-arkzoyd avec 0 Commentaires

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

2

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 :

3

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

4

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ées 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 ?