Oracle Exadata Exascale : grande architecture pour petites charges de travail

Oracle adapte ASM au mode multitenant

Cette logique a été adaptée à une architecture mutualisée, en modifiant principalement la gestion logicielle des bases de données.

« Avant cette annonce, chaque tenant disposait de serveurs de calcul et de stockage exadata dédiés. Et nous avions un logiciel appelé Automatic Storage Management (ASM) qui était utilisé pour distribuer le stockage entre les bases de données », déclare Kodi Umamageswaran, Senior Vice President, Exadata and Scale-Out Technologies chez Oracle. « Désormais, un pool commun de calcul et de stockage exascale prend en charge des milliers de tenants et des millions de bases de données ».

« Désormais, un pool commun de calcul et de stockage exascale prend en charge des milliers de tenants et des millions de bases de données ».

En résumé, un control plane spécifique à Exascale est utilisé pour gérer les VM et les espaces de stockage.

Traditionnellement, Oracle représente logiquement chaque disque dur dans le système d’exploitation du serveur sous la forme d’un LUN (Logical Unit Number).

De plus, il gère l’ensemble des actifs logiques sous forme de fichiers : données dans une base, snapshots, logs « redos », clones, blocs de stockage, etc.

Or, avec Oracle ASM, chaque type de fichiers est réparti par groupe de disques associé aux données de la base, aux fichiers de récupération, aux snapshots et aux configurations de stockage étendu. Ici, il s’agissait d’assurer la redondance de ces informations et leur séparation sur des volumes de stockage distincts.

Avec Exascale, désormais, c’est le type de fichiers qui détermine la redondance. Des templates permettent de configurer le niveau de redondance et le control plane s’assure qu’ils ne sont pas stockés sur les mêmes disques.

De plus, ces fichiers sont divisés sous forme « d’extents » de 8 Mo chacun. Ce choix s’explique pour des raisons de performances et de compatibilité effective avec l’architecture multitenant.

« Ces fragments de 8 Mo sont suffisamment grands pour obtenir de bonnes performances séquentielles quand nous scannons des données contiguës. Huit Mo c’est également suffisamment petit pour distribuer une base de données à travers le stockage cloud, afin de répartir la charge I/O », explique Kodi Umamageswaran.

Ces fragments sont alloués à des buckets de stockage en utilisant une fonction de Hash. Une table de mapping indique les disques sur lesquels chaque bucket est stocké.

« Tous les extents qui résident dans un bucket sont stockés de manière redondante sur trois disques situés sur trois serveurs de stockage distincts, afin de se prémunir contre les pannes de stockage et les interruptions de service », poursuit le vice-président sénior.

Le nombre de bucket est fixe. « Un nombre de 100 000 buckets est suffisant pour répartir les données sur des milliers de serveurs de stockage, et assez petit pour que la table de correspondance soit mise en cache dans la mémoire du serveur de bases de données du client », illustre-t-il.

Des performances équivalentes aux infrastructures dédiées

Ce mécanisme, associé au réseau RoCE et au protocole RDMA, permettrait d’obtenir des niveaux de performance similaires des services Exadata dédiés, à savoir un débit I/O de 2 880 Go/s lors de benchmarks analytiques génériques et une latence I/O de l’ordre de 17 microsecondes, quand les serveurs sous-jacents sont des X10M.

Ces performances seraient également dues à la gestion à la volée du tiering de données et à la parallélisation automatique des traitements SQL, entre autres.

Les développeurs, eux, peuvent profiter d’Exascale pour créer des clones de base de données, soit comme une copie entière ou des clones « thin », depuis une base de données de production ou un snapshot. La technologie « redirect on write » permettrait de « réduire drastiquement les capacités de stockage requises pour le clonage », puisque ces clones peuvent partager des blocs avec la base de données d’origine tant que celle-ci n’a pas enregistré de nouvelles données. Des fonctionnalités qui, pour la plupart, existaient déjà.

En lieu et place des groupes de disques, les administrateurs voient des vaults rattachés aux clusters de VM. Ces vaults sont des conteneurs de stockage logique tirant les ressources des pools de serveurs physiques, attachés aux clusters de VM. « Les Vaults représentent le nouveau concept le plus visible [par les administrateurs], car ils sont utilisés directement par la base de données Oracle à la place des groupes de disques ASM ». Les vaults accueillent indifféremment les fichiers de données et de récupération. « Le type de contenu est associé au fichier lui-même dans Exascale, de sorte que les administrateurs n’ont pas besoin de séparer ces fichiers dans différents vaults, puisque le stockage sous-jacent est partagé par tous les vaults », précise Oracle.

En ce qui concerne le déploiement, une page permet de configurer les VM, les vaults attachés, de provisionner l’image de conteneur de la base de données ainsi que le VCN et ses deux sous réseaux (client, backup).

ExaDB-XS n’est compatible qu’avec Oracle Database 23ai, entrée en disponibilité générale en mai. Le service peut inclure la licence pour la 23ai ou les clients peuvent charger une image BYOL.

Les administrateurs peuvent déployer entre 2 et 10 VM, chacune dotée de 8 à 200 ECPU (« l’ECPU est basé sur le nombre de cœurs par heure alloués de manière élastique à partir d’un pool de serveurs de calcul et de stockage »). Chaque VM nécessite au minimum 22 Go de RAM (2,75 Go par ECPU). Il faut par ailleurs allouer un espace de stockage de fichiers par VM compris entre 280 et 1 100 Go.

Un Vault comprend entre 300 Go et 100 To d’espace de stockage.

Moins cher… à petite échelle

Mais du fait de l’architecture multitenant, ExaDB-XS serait 95 % moins cher qu’Exadata Cloud Infrastructure X9M Dedicated.

Pour une configuration de base (licence incluse) reposant sur un quart de baie X9M (deux serveurs de bases de données pour trois serveurs de stockage), Exadata Cloud Infrastructure dédié coûte 10 044,05 euros par mois (744 heures), contre 331,15 euros par mois avec l’infrastructure Exadata Exascale.

Mais il faut ajouter l’exécution des services Exadata Database, et Oracle facture l’exécution des traitements via RDMA. Une instance de base ExaDB-XS coûte plutôt 4 050,92 euros par mois pour une configuration de base, contre 13 764,09 euros par mois pour l’instance dédiée dans le cloud X9M avec 4 OCPU (8vCPU) associé à Exadata Database Service. Soit une économie d’environ 70 % si l’on reprend le schéma du fournisseur.

Si le quart de baie X9M est plus capacitaire en stockage (190 To disponibles), 4 OCPU ne sont pas suffisants pour traiter une telle quantité de données. Oracle semble finalement comparer des choux et des carottes et Exadata Exascale n’apparaît pas forcément moins cher pour des capacités de stockage équivalentes.

Pour autant, ce modèle au cluster doublé d’un paiement à l’usage, qui « ne requiert pas d’acheter le cadre », était réclamé par des petits clients et des plus grands, afin d’exploiter les capacités d’Oracle Database.

« Le faible coût d’Exascale permet aux entreprises de type Fortune Global 2000, aux ETI et aux PME de l’utiliser pour de plus petites charges de travail », assure Kodi Umamageswaran.

Les analystes IT s’entendent sur le fait qu’Oracle continue d’innover face à des compétiteurs historiques relayés aux seconds rangs. Les ennemis pour la firme de Larry Ellison, c’est PostgreSQL et ses variantes, qui ont suscité beaucoup de travaux de la part des géants du cloud, et MongoDB. Pour autant, Oracle était à la traîne sur l’aspect « à l’usage » de son offre. Il compte bien rattraper son retard.

À l’avenir, Exadata Exascale sera l’architecture sous-jacente pour tous les services Oracle Database dans OCI, selon Kodi Umamageswaran.