Archi exadata

Fiche express
Type	Appliance de base de données (matériel + logiciel)
Éditeur	Oracle (V1 : HP+Oracle ; V2 et suivantes : Sun+Oracle)
Composants	Compute nodes (serveurs de base de données) + cellules de stockage + réseau InfiniBand
Voir aussi	Cellcli · Dcli · CELL Create hdd fileformat · Virtu cell · Virtu DB noeud · Virtu patch

Exadata est une appliance de base de données Oracle qui associe des serveurs de calcul (compute nodes, qui hébergent l'instance RDBMS et ASM) à des cellules de stockage dédiées (storage cells) reliées par un réseau InfiniBand haut débit. Le logiciel des cellules déporte une partie du traitement SQL au plus près du disque (Smart Scan), ce qui réduit fortement le volume de données remonté vers les serveurs de base de données.

Matériel

Générations successives (constructeur du châssis + partenariat Oracle) :

V1 = HP + Oracle
V2 = Sun + Oracle
X2 = Sun + Oracle
X3 = Sun + Oracle
X4 = Sun + Oracle

Configurations disponibles (nombre de serveurs de base de données / cellules de stockage / disques) :

Full    = 8 serveurs DB + 14 cellules + 168 disques
Half    = 4 serveurs DB + 7 cellules + 84 disques
Quarter = 2 serveurs DB + 3 cellules + 36 disques
Eighth  = 2 serveurs DB + 3 cellules + 36 disques (CPU divisée par 2, 18 disques actifs)

12 disques par tiroir (shelf). Les configurations diffèrent aussi par le nombre de processeurs des serveurs de base de données (bi-processeur sur X3-2, octo-processeur sur X3-8 Full). Le réseau interne (InfiniBand) fonctionne à 40 Gb/s.

Smart Flash Cache

Chaque cellule de stockage embarque un cache SSD (Smart Flash Cache) qui accélère les lectures aléatoires fréquentes, en complément du Storage Index :

X3-2 : 1,6 To de cache flash par cellule
X4   : 3,2 To de cache flash par cellule

Le flash est réparti sur 4 cartes PCI contenant chacune 4 modules (24 Go par module en X2/F20, 100 Go en X3/F40, 200 Go en X4/F80). Une zone de chaque module est réservée au Flash Log (journalisation des redo logs en cache, pour absorber les pics d'écriture).

Contenu typiquement mis en cache :

• Données et blocs d'index fréquemment accédés
• Lectures/écritures des fichiers de contrôle
• Lectures/écritures des en-têtes de fichiers

Contenu volontairement exclu du cache (l'administrateur peut influencer les priorités via le paramètre de stockage CELL_FLASH_CACHE : DEFAULT, KEEP, NONE) :

• Miroirs I/O de sauvegarde
• Flux RMAN
• Formatage de fichiers de données
• Full table scans (qui ne doivent pas monopoliser le cache)

Par défaut, Exadata écrit en write-through (écriture simultanée cache + disque, accusé de réception après écriture disque). Le mode write-back (accusé de réception dès l'écriture en cache) n'est pas activé par défaut et nécessite de vider le cache avant de basculer.

Storage Index

Le Storage Index réduit le nombre d'I/O disque en mémorisant, par zone de 1 Mo, les valeurs min/max des colonnes les plus sollicitées (jusqu'à 8 colonnes par zone) :

• Construction et maintenance automatiques et transparentes, entièrement en mémoire sur la

 cellule (pas de structure persistée sur disque)

• Permet un filtrage transparent des zones sans donnée pertinente (false negative

 impossible : une zone n'est jamais éliminée à tort)

• La commande calibrate de cellcli est à relancer périodiquement pour valider les

 performances I/O des disques de la cellule

Smart Scan et protocole iDB

Le Smart Scan déporte une partie du traitement SQL vers les cellules de stockage via le protocole iDB (Intelligent Database), qui s'appuie sur RDS (Reliable Datagram Sockets) au-dessus d'InfiniBand :

• Seules les colonnes et lignes utiles à la requête sont renvoyées au serveur de base de

 données, ce qui réduit fortement le trafic réseau

• Un filtrage par filtre de Bloom (approximation probabiliste d'appartenance à un ensemble)

 est appliqué côté cellule pour les jointures, avant renvoi des données

• Les cellules savent scanner des données chiffrées et compressées (HCC) directement, ainsi

 que participer au data mining, au formatage de cellule et à la restauration RMAN

Le Smart Scan ne fonctionne qu'en accès direct (PGA, mémoire privée à la session) : c'est dans cette zone que les allocations dédiées à la taille de l'objet scanné sont possibles. La SGA (mémoire partagée) reçoit les petites tables et gère uniquement des buffers classiques (attentes et verrous), contrairement à la PGA qui est en accès direct. Le comportement dépend de la version : les seuils SGA/PGA ne sont plus fixes depuis 11g, la lecture parallèle en SGA est possible.

Le Smart Scan ne s'applique qu'aux scans complets de table (full table scan) ou d'index (full index scan), pas aux accès par plage (range scan) ni aux accès unitaires (unique scan).

Hybrid Columnar Compression (HCC / EHCC)

La compression colonne par colonne (chaque colonne pouvant utiliser un algorithme différent) s'applique à la volée et est optimisée pour la volumétrie de type datawarehouse — la ligne compressée ne doit plus être modifiée ensuite, sous peine de très mauvaises performances (les mises à jour fragmentent le format columnar).

Niveaux de compression, du moins au plus agressif :

• Query low : algorithme LZO — mode requête, impact minimal sur les performances
• Query high : compression plus poussée (niveau ~6), toujours orienté requête
• Archive low : orienté archivage (niveau ~7)
• Archive high : algorithme bzip2 — taux de compression maximal, pour données froides

À distinguer de l'Advanced Compression Option (ACO) classique, qui compresse bloc par bloc au fur et à mesure du remplissage (indépendant du HCC et disponible hors Exadata).

IORM et DBRM (I/O Resource Manager)

L'IORM (côté cellule) et le DBRM (Database Resource Manager, côté base) permettent de prioriser les I/O sur un stockage partagé entre plusieurs bases et plusieurs charges de travail (par exemple, éviter qu'une grosse requête analytique ne pénalise l'OLTP) :

• Priorisation possible par groupe de ressources, par base de données ou par

 table/périmètre applicatif

• Échelle de granularité : catégories → interdatabase → intradatabase → consumer group
• Un plan IORM est déclaré sur la cellule pour arbitrer entre bases (interdatabase plan)
• Il est recommandé de désactiver les caches d'écriture disque classiques (IORM prend le relais)

ASM et redondance

La hiérarchie de stockage sur une cellule Exadata suit ce chemin :

Disque physique → LUN → Cell Disk → Grid Disk

Sur les deux premiers LUN de chaque cellule, une zone System Area est réservée pour héberger l'OS Linux de la cellule. Par défaut, un partitionnement sépare les régions « chaudes » et « froides » des disques (Cell Disk sur la zone rapide, Grid Disk sur le reste).

Chaque groupe de disques ASM (diskgroup) doit déclarer des failure groups — sur Exadata, un failure group correspond en général à une cellule complète :

• Redondance normale : minimum 2 failure groups (3 si le diskgroup contient l'OCR/voting disk)
• Redondance élevée : minimum 3 failure groups (5 si le diskgroup contient l'OCR/voting disk)

L'espace équivalent à la System Area sur les autres disques sert à héberger le voting disk et l'OCR, dans un diskgroup dédié nommé DBFS-DG (environ 60 Go sur une config Eighth).

Vue utile pour le suivi de l'espace réellement disponible :

v$ASM_DISKGROUP : USABLE_MB = FREE_MB - REQUIRED_MIRROR_FREE_MB

REQUIRED_MIRROR_FREE_MB réserve l'espace nécessaire pour qu'ASM puisse reconstruire la redondance après la perte d'un disque (2/3 de l'espace du disque perdu selon la redondance choisie) — l'espace réellement libre pour de nouvelles données est donc inférieur au free brut. Le mécanisme de checkpoint distribué RAC porte le nom de cache fusion.

En cas de perte de disque, ASM attend la durée définie par l'attribut disk_repair_time (3,6 heures par défaut) avant de lancer le rééquilibrage complet, pour laisser le temps de remplacer le disque à chaud sans déclencher un rebalance inutile. Diagnostic et remplacement d'un disque en panne :

CellCLI> list alerthistory where alertmessage like 'logical drive lost.*' detail
CellCLI> alter physicaldisk 20:5 serviceled on
CellCLI> list physicaldisk
SQL> select * from gv$asm_operation;

Remplacement à froid d'une carte flash PCI : arrêt du serveur, remplacement physique de la carte, redémarrage.

Sécurité

Deux modes de restriction d'accès aux Grid Disks depuis les bases :

• ASM-scoped security : une clé est générée et distribuée par cellule pour restreindre

 l'accès aux disques ASM ; configuration dans /etc/oracle/cell/network-config

• Database-scoped security : restriction au niveau base de données, via un fichier

 cellkey.ora placé dans $ORACLE_HOME/admin/<nom_unique_admin>/pfile

Sauvegarde

Le mécanisme de sauvegarde incrémentale RMAN s'appuie sur un suivi des blocs modifiés (Changed Block Tracking, CBT) : après un niveau 0 (image complète), chaque incrément de niveau 1 ne transfère que les blocs modifiés depuis la dernière sauvegarde. Sur Exadata, RMAN transmet aux cellules la carte des blocs modifiés (fichier CBT) afin que seules les données à sauvegarder transitent sur l'InfiniBand — le filtrage se fait donc côté cellule plutôt que côté serveur de base de données.

Administration

Deux outils en ligne de commande pilotent les cellules :

• Cellcli : administration d'une cellule locale (disques, cache flash, alertes, BMC…)
• Dcli : exécution distribuée d'une commande (cellcli ou shell) sur l'ensemble des cellules

 d'un cluster en une seule invocation

Chaque cellule fait tourner trois services : cellsrv (moteur de service I/O, cœur du Smart Scan et de l'IORM), MS (Management Server, supervision/administration) et RS (Restart Server, qui relance les autres services si besoin).

La bibliothèque cliente $ORACLE_HOME/lib/libcell11.so (celllib) est ce qui permet côté base de données de dialoguer avec l'intelligence embarquée des cellules (Smart Scan, offload).

Réseau : InfiniBand et protocole RDS

Les nœuds RAC et les cellules communiquent sur le réseau InfiniBand via ZDP (Zero-loss Zero- copy Datagram Protocol), une implémentation de RDS (Reliable Datagram Sockets, protocole en mode datagramme construit au-dessus d'UDP) qui réduit fortement l'overhead réseau par rapport à TCP/IP classique.

Montée de version et patch

Le patching d'une appliance Exadata couvre trois couches distinctes qu'il faut traiter dans l'ordre : réseau InfiniBand (firmware des switchs), cellules de stockage, puis serveurs de base de données. Avant toute campagne de patch, vérifier la corrélation entre la version de la base et celle du cell software dans la note MOS 888828.1 (Exadata Database Machine and Exadata Storage Server Supported Versions) — (à vérifier, référence non revalidée lors de cette migration). Voir Virtu patch pour le déroulé pratique de l'application d'un Bundle Patch.

Voir aussi

• Cellcli — commandes d'administration d'une cellule de stockage
• Dcli — exécution distribuée de commandes sur toutes les cellules
• CELL Create hdd fileformat — création pas à pas des disques d'une cellule (celldisk, griddisk, flash)
• Virtu cell — construction d'une cellule de stockage en environnement de simulation
• Virtu DB noeud — construction d'un nœud de calcul en environnement de simulation
• Virtu patch — application d'un Bundle Patch Exadata en approche out-of-place