vendredi mai 09, 2014

Deploy and operate your Business Applications quickly and securely

Last week, we announced the upcoming release of Solaris 11.2. Even if this is a minor release, it contains major features that enable strong benefits for IT operations toward Business requirements that I am hearing everyday: "time-to-market", pay for what you use, security, simplified operations. Yes, OS are not a commodity and are a corner piece bringing either a lot's of value or a lot's of pain (depending on which one you rely on). At Oracle we are putting a large part of our R&D effort to hide the complexity and bring strong value through Solaris toward your infrastructure and applications management: Solaris acting as the glue between your hardware execution layer and your applications. 

Time-to-market: Centralized Cloud Management, Fast and Agile Application Provisioning

Cloud brings a lot's of promise and as such all Businesses are strongly looking at Clouds optimization, targeting "Time-to-market" (agility) and pay for what you use.

Source: TwinStrata

On the other side, either for the Cloud Service Providers or your internal IT operations, there is a lot's of work to do to make it happen in a standard, repeatable, secured and scalable model. To achieve this, one emerging standard embrace by the major IT players, including Oracle, is OpenStack. Still, discussing with many System Integrators who are starting to leverage it, OpenStack requires a lot's of work to make it right and maintain it, as it is in an constant evolution path. What we did in Solaris 11.2, was to benefit from strong proven features already in place, to build the foundation of the OpenStack framework, and get it ready and engineered to be delivered quickly and reliably.

This is a key milestone to provide Cloud Service Providers and internal IT the foundation layer required to achieve the expected "Time-to-Market" of your Cloud infrastructure. The nice thing about it, is that it is not only the management point of your Solaris environments, but of all your OpenStack compliant systems.

Pay for what you use: Independent and Isolated Environments... compliant with licensing boundaries

The next step once the service is deployed is to provide the required boundaries to "pay for what you use", not only from a pure hardware perspective, but also from a software licensing model. We already benefit from this capability, since Solaris 10, with the Solaris Zones virtualization technology. In Solaris 11.2, this has been enhanced to simplify the allocation of  resources at cpus, cores and sockets level, matching your software licenses requirements.

Security: Reduce Risk with Comprehensive Compliance Checking and Reporting

In a Cloud environment, where resources are shared, you need to insure very strong security mechanism between tenants. Thanks to built-in security, inside Solaris, we were already able to provide those mechanisms. In Solaris 11.2, we bring it  a step further, being able to provide compliance checking and reporting of the configuration, like PCI/DSS required in Card Banking industry.

This provide to Cloud Providers and Cloud Consumers a reliable, secured platform to build upon, simplifying complex configurations and associated audits processes.

Simplified operation: Enhancing OpenStack with Live Reconfiguration

Once you get your application on time, paying for what you use in a secured environment, you may think you are done. Are you ? Of course not ! What about application upgrade, platform patching, all the life cycle management of both your application and the Cloud platform you are relying on ? This is a well known challenge of consolidation projects, where the more tenants you put on a platform, the more complex is it to find a proper maintenance windows.

At the Solaris 11.2 platform level, you can now :

  1. dynamically reconfigure Oracle Solaris Zones without requiring a reboot, helping to eliminate system downtime,
  2. manage Solaris Zones patching independently, helping you apply your system and/or applications patches at your own pace

To go further in understanding the multiple values Solaris 11.2 platform can bring to your Business, I invite you to join us in Paris, on May 22nd, for a Solaris Tech Day. You will have the opportunity to exchange with Chris Arms, VP of Engineering, ISVs and customers using it today.

Associated Resources:

jeudi juin 13, 2013

3 minutes video of last Month Oracle Solaris Users Group event

A quick report of last month Oracle Solaris Users Group event in Paris... in french...

vendredi mai 17, 2013

Why OS matters: Solaris Users Group testimony

Wednesday evening, a month after the new SPARC servers T5 & M5 launch in Paris, the french Solaris users group, get together to get the latest from Oracle experts on SPARC T5 & M5, Oracle Virtual Network, as well as the new enhancements inside Solaris 11.1 for Oracle Database. They also came to share their projects experiences and lessons learn, leveraging Solaris features : René Garcia Vallina from PSA, did a deep dive on ZFS internal and best practices around SAP deployment and Bruno Philippe explained how he managed to consolidate 100 Solaris servers into 6 thanks to Solaris 11 specific features.

It was very interesting to see all the value that an operating system like Solaris can bring. As of today, operating systems are often deeply hidden in the bottom layers of the IT stack, and we tend to forget that this is a key layer to leverage all the hardware innovations (being new CPUs cores, SSD storage, large memory subsystems,....) and expose them to the applications layers (being Databases, Java application servers,...). Solaris is going even further than most operating systems, around performances (will get back to that point), observability (with DTrace), reliability (predictive self healing,...), and virtualization (Solaris ZFS, Solaris Zones & Solaris Network Virtualization, also known as project "crossbow").

All of those unique features are bringing even more values and benefits for IT management and operations in a time of cost optimization and efficiency. And during this event, this was something that we could get from all the presentations and exchanges.

Solaris and SPARC T5 & M5

As Eric Duminy explained in the introduction of his session on the new SPARC T5 & M5, we are looking into new paradigm of CPU design and associated systems. Following Moor's law, we are using transistors in completely new ways. This is no more a run for frequency, if you want to achieve performance gain, you need more. You need to bring application features directly at CPU and Operating System level. Looking at SPARC T5, we are talking about a 16 cores, 8 threads/core processor, with up to 8x sockets, 4 TB RAM, SPARC T5-8 server in only 8 rack units ! This mean also, 128 cores and 1024 threads, and even more for the M5-32, with up to 192 cores, 1536 threads, 32 TB RAM  ! That's why the operating system is a key piece that needs to be able to handle such systems efficiently : ability to scale to that level, ability to place the process threads and associated memory on the right cores to avoid context switch, ability to manage the memory to feed the cores at the right pace.... This is all what we have done inside Solaris, and even more with Solaris 11.1 to leverage all this new SPARC T5 & M5 servers, and get the results that we announced a month ago at the launch.

 Of course we don't stop there. To get the best out of the infrastructure, we are designing at CPU, system and Solaris level to optimize for the application, starting at the database level.This is what Karim Berrah covered in his session.

Solaris 11.1 unique optimizations for Oracle Database

Karim's explained first the reasoning behind the complete new virtual memory management of Solaris 11.1, something that benefits directly to Oracle Database for the PGA and SGA allocation. You will experience it directly at database startup (twice faster !). The new virtual memory system will also benefit to ALL your applications, just looking for example at the mmap() function which is now x45 faster (this is what is used for all the shared libraries). Beyond performances, optimizations have been made on security, audit, and management. For example, with the up coming new release of Oracle Database, you will be able to dynamically resize your SGA and also get greater visibility for the DBA in datapath performances thanks to a new DTrace table directly available inside the database: a tight integration between Oracle DB and Solaris unique features.

Alain Chereau one of our performance guru from EMEA Oracle Solution Center provided his foresight and expertise. He especially reminded that the performance is achieve when ALL the layers work well together, and that "your OS choice has an impact on the DB and reverse. Something to remember for your critical applications." Alain closed the session with a final advice on best use of SSD for Oracle DB and Solaris ZFS. In short, SSD are align on 4k block. For Oracle DB, starting with, redolog can write in 4k block. This needs to be specify at redolog creation on the record size setting. For Solaris, ZFS knows about SSD and directly adapt. That's the reason why putting ZFS secondary cache on SSD (readzilla) is a very good idea, and a way to avoid bad behavior introduced by new "blind" storage tiering when combined with ZFS. Just put SSD drives for ZFS secondary cache directly inside your T5 or M5 servers and you are done. This is an important topic, as even if a majority of customers are running Oracle Database on ASM on production to get the benefit of grid and Oracle RAC security and scalability, that maybe different for development environments. As a matter of fact, for development systems most customers are leveraging Solaris ZFS and its compression and infinite clone and snapshot functions.

This brings me to René's session on SAP on ZFS...

Lessons learn from deploying SAP on ZFS

Clearly one of the most technical session of this event. Congratulation to René for a very clear explanation on ZFS allocation mechanisms and algorithm policies. I will start by René's conclusion : "Don't follow your ISV (SAP in this case) recommendations blindly". In fact, PSA was experiencing performances degradation and constant I/O activity even with very few transactions on application side. This was due to the fact that SAP recommends to use the SAP Data filesystem at more than 90% ! A very bad idea when you put your data on a Copy-on-Write (COW) filesystem like ZFS... Where I always recommend to keep around 20% of free space to allow for the COW operations to take place ! That's of course the new rule for SAP deployment at PSA.

So if you already have ZFS deployed with this rule in place, you don't have to read further, just keep doing it and move directly to the next topic... otherwise you maybe facing currently some performance problems as well.  To identify which of your ZFS pools are facing this situation, René provided a nice dtrace command that will tell you :

# dtrace -qn 'fbt::zio_gang_tree_issue:entry { @[pid]=count();  }' -c 'sleep 60'

Then to solve the problem, you understand that you need to add free space to enable the COW operation (in one shot). The best way would be to add a vdev (for more details: Oracle Solaris ZFS: A Closer Look at Vdevs and Performance). You could also use a zfs replace with a bigger vdev, but that's not the best option in the long run. If you go through a whole modification cycle of the content of the pool, your zpool will "defragement" by itself. If you want to "defragment" the zfs pool immediatly, if you have a Database, you can do it through "alter table move" operations (special thank to Alain Chereau for the tip). For standard files, you need to copy them and rename them back, or best, do a zfs send | zfs receive to another free zpool and you are done.

From 100 Servers to 6 thanks to Solaris 11

Last but not least, we also had another deep dive session during this event, with live demo ! Thanks to Bruno Philippe, President of the French Solaris Users Group, who shared with us his project of consolidating 100 servers, going from Solaris 8 to Solaris 10 into 6 servers with minimal to no business impact allow ! Bruno achieved his project thanks to Solaris 11 unique new feature : Solaris network virtualization, combine with Solaris Zones P2V and V2V, and SPARC Hardware hypervisor (Oracle VM for SPARC, known also as "LDOM", or Logical Domain).

I invite you to visit Bruno's blog for more details : Link Aggregations and VLAN Configurations for your consolidation (Solaris 11 and Solaris Zone)

Awaiting his next entry explaining the detail of the V2V and P2V operations that he demonstrated to us live on his laptop through a Solaris 11 x86 VBOX image.

I hope to see you on the up coming Solaris and SPARC event to share your feedback and experience with us.

The up coming Paris events will take place on June 4th, for  Datacenter Virtualization, focus on storage and network, and July 4th for a special session on new SPARC servers and their business impact.

mercredi avr. 10, 2013

IT Modernization: SPARC Servers Engineering Vice President in Paris

Avec le renouvèlement complet des serveurs SPARC annoncé il y a 2 semaines, Masood Heydari, vice-président de l'ingénierie SPARC sera à Paris le 18 Avril, afin de partager avec vous, les apports de ces nouveaux serveurs T5 et M5 sur le marché. Après l'intervention de Masood, Didier Vionnet, ACCOR vice-président du back-office, Bruno Philippe, président du groupe français des utilisateurs de Solaris, Renato Vista, CTO CAP Gemini Infrastructure Services, Harry Zarrouk, Directeur des Systèmes d'Oracle pour la France et moi-même, participeront à une table ronde sur les apports de ces innovations pour la modernisation des systèmes d'informations et les nouveaux besoins métiers des entreprises. Je vous invite à vous inscrire à cet évènement afin de venir échanger avec l'ensemble des intervenants.

With the complet renewal of SPARC Servers announced 2 weeks ago, Masood HEYDARI, Senior Vice President of SPARC Servers Engineering will be in Paris on April 18th, to share what the new SPARC Servers T5 and M5 bring on the market. Following Masood key notes, Didier Vionnet, ACCOR Vice-President of Back-office, Bruno Philippe, President of French Solaris Users Group, Renato Vista, CTO CAP Gemini Infrastructure Services, Harry Zarrouk, Director of Oracle Systems for France and myself, will exchange on the benefits those innovations bring to IT Modernization and Business needs.

lundi nov. 21, 2011

Solaris 11 : les nouveautés vues par les équipes de développement

Translate in English 

Pour ceux qui ne sont pas dans la liste de distribution de la communauté des utilisateurs Solaris francophones, voici une petite compilation de liens sur les blogs des développeurs de Solaris 11 et qui couvre en détails les nouveautés dans de multiples domaines.

 Les nouveautés côté Desktop

Les outils de développements

Le nouveau système de packaging : Image Packaging System (IPS)

[Read More]

lundi oct. 10, 2011

Oracle Open World 2011 : Very Big (again) !

Translate in English 

Oracle Open World continue a battre des records aussi bien en terme d'audience avec plus de 45000 personnes que de contenus, avec plus de 2000 sessions, sans parler des annonces majeures qui ont eu lieu cette année et sur lesquelles je vais revenir dans ce poste, jour par jour.

Premier jour : Engineered Systems

L'évènement a été lancé avec une "key notes" 100% matériel, autour des Engineered Systems, avec un rappel du succès d'Exadata et d'Exalogic, et du pourquoi : massivement parallèle à tous les niveaux, avec en plus la compression des données pour pouvoir bouger beaucoup de données, beaucoup plus vite qu'une architecture traditionnelle, le tout basé sur un coeur infiniband... Conception poussée jusqu'au processeur avec le T4 et Solaris côté système d'exploitation, qui aboutissent a un nouvel "Engineered Systems", le Supercluster, pour proposer la solution la plus adaptée (intégrée) sur le terrain des applications utiles à l'Entreprise (Java/Database). Pour le partie calcul géométrique, ce sera la prochaine étape...

""Cette première "key notes" s'est conclue toujours sur du "Hardware and Software Engineered to work together", pour délivrer des résultats "plus vite que la pensée" avec l'Exalytics, qui s'interface de préférence avec un Exadata, mais pas seulement... pourquoi pas votre SAP, pour en tirer des analyses très rapide sur une volumétrie de données importante, que l'on arrive à faire tenir dans 1 TB de RAM, grâce à des technologies de... [Read more][Read More]

dimanche oct. 02, 2011

Oracle Open World - Hands-on Lab : Configuring ASM and ACFS on Solaris - Part 2

Oracle Open World - Hands-on Lab - Participant Guide

Content and Goal

"Oracle Automatic Storage Management gives database administrators a storage management interface that is consistent across all server and storage platforms and is purpose-built for Oracle Database.

Oracle Automatic Storage Management Cluster File System is a general-purpose file system for single-node and cluster configurations. It supports advanced data services such as tagging and encryption.

This hands-on lab shows how to configure Oracle Automatic Storage Management and Oracle Automatic Storage Management Cluster File System for installation of an Oracle Database instance on Oracle Solaris 10 8/11.

You'll learn how to install the software, build Oracle Automatic Storage Management volumes, and configure and mount Oracle Automatic Storage Management Cluster File System file systems."


This tutorial covers the installation of Oracle Grid Infrastructure for a standalone server. In the Oracle 11g Release 2, the Grid Infrastructure contains, amongst other software:

  • Automatic Storage Managment (ASM)

  • ASM Dynamic Volume Manager (ADVM)

  • ASM Cluster File System (ACFS)

This lab is divided into 4 exercises.

Exercise 1: We install the ASM binaries and grid infrastructure. As part of the install we create a diskgroup of three disks called DATA. DATA will later be used to store the database data files.

Exercise 2: We use ASM Configuration Assistant (ASMCA) to create a second diskgroup called MYDG. From MYDG we create a ADVM volume called MYVOL and from that we create a ACFS file system called u02.

Exercise 3: We use the installer to install the Oracle database binaries into our new ACFS filesystem (u02).

Exercise 4: We then use the database configuration assistant to create a database with the tablespaces populating the DATA ASM diskgroup.

In our setup we use "External" redundancy for our disks. This implies ... Read more...[Read More]

vendredi sept. 30, 2011

Oracle Open World - Hands-on Lab : Configuring ASM and ACFS on Solaris - Part 1

A quick introduction

I have been invited by Dominic Kay, Product Manager for Solaris Storage sub-systems, for an hands-on lab at OOW. For those of you who will assist at this session, next Monday, at 11:00am, in Marriott Marquis - Salon 5/6, here are the gory details to get you through this lab. For the others that won't have the opportunity to be there, we hope it will be usefull for you to set it up on your own environment. 

The reasoning behind this lab

I already posted on this blog many times, about ZFS, and all its benefits, including the deployment of Oracle Database. And Dominic found very valuable to develop the knowledge of ASM (and ACFS) deployment on Solaris, as you can look at ASM in a way, as the "ZFS" from a DBA perspective, with another interesting benefit : the ability to deploy an Oracle Database in a shared multi-nodes environment with Oracle RAC, which is what's is running on Solaris on Exadata and on this week's new Engineered System announced, SPARC Supercluster... Read more...

[Read More]

vendredi juin 10, 2011

Stratégie Solaris : venez rencontrer et partager avec les responsables de l'offre Solaris

Le 20 juin à Paris, Lynn Rohrer (Director of Solaris Product Management) et Joost Pronk (Principal Product Director) rencontrerons les utilisateurs de Solaris lors d'un évènement, co-organisé avec le GUSES. Ils seront parmi nous pour expliquer en quoi l'engagement d'Oracle vis-à-vis de Solaris est fort aussi bien sur plates-formes SPARC et x86. L'évènement débutera par une présentation, suivie d'un échange avec les intervenants. Il se déroulera à partir de 18h30, au 115 rue Saint-Lazare 75008 Paris. Inscription obligatoire ici.

lundi mars 14, 2011

Les détails qui fond la différence : l'importance d'une bonne gestion de la mémoire

Translate in English

La semaine dernière, William Roche a clôturé son intervention sur la gestion de la mémoire, dans le cadre du Groupe des Utilisateurs Solaris. Le sujet était tellement riche, qu'il a fallu 2 sessions à William pour expliciter les avancées apportées au niveau de Solaris pour exploiter au mieux la mémoire.

Tout utilisateur manipulant de gros volumes de données, ou cherchant à consolider ses applications ou des machines virtuelles, connait l'importance de la mémoire. En effet, face à l'évolution des processeurs vers les multi-coeurs avec en plus plusieurs unités d'exécution par coeur, la mémoire prend une place prépondérante pour pouvoir les alimenter comme il se doit. Pour que cela soit efficace, il faut à la fois concevoir des serveurs sans goulot d'étranglement matériel avec une architecture homogène permettant de mettre en oeuvre suffisamment de mémoire en face des processeurs. Mais aussi disposer d'un système d'exploitation capable de tirer partie de l'infrastructure à disposition et d'en rendre la pleine puissance aux applications.

La mémoire se cache partout, pas uniquement la RAM, mais aussi dans les disques (SWAP, SSD), et pour Solaris c'est beaucoup beaucoup plus que cela : y compris les registres et le cache du CPU (le plus rapide, mais le plus cher).

Quelques chiffres de temps d'accès

  • Registres CPUS : < 1 ns d'accès.
  • Les caches L1, L2 : 1 à 20 ns
  • La RAM : 80ns à 500ns
  • SSD : 25 us à 250 us
  • Disques : 5ms - 20ms
  • DVD : 100ms

...mis en perspective

 Type de Cache
 Taille  Temps d'accès
 Registes CPU
 1 Koctets
 1 cycle
 1 seconde
 100 Ko
 2 cycles
 2 secondes
 8-16 Mo
 19 cycles
 10 secondes
 mémoire principale
 128 Mo à 512 Go (et plus)
 50 - 300 cycles
 50 secondes à 5 minutes
 Disques  40 Go à plusieurs To
 11 M cycles
 4.24 mois !
 Réseau  Pas de limite
 80 M cycles
 2.57 années !!

Garder les données actives proches du processeur est critique !

Et c'est là où, la conception des serveurs et Solaris rentrent en action.

Lors du démarrage, Solaris prend connaissance du système sous-jacent : processeurs, bancs mémoires, temps d'accès entre chacun des processeurs avec les différents bancs mémoires, etc... Cela lui sert non seulement dans l'optimisation de l'allocation des processus vis à vis de l'accès à la mémoire, mais aussi pour sécuriser le système, en pouvant par exemple "black lister" des coeurs ou des bancs mémoires défaillant sans impacter les applications.

En outre, grâce aux fonctions de "Large Page Support", Solaris adapte dynamiquement  la taille des pages mémoires en fonction du comportement de l'application pour éviter des cycles d'accès inutiles, qui comme illustré dans le tableau précédent coûtent cher !

Ces points ne représentent que quelques unes des nombreuses optimisations nous permettant de tirer parti des évolutions technologiques, et de répondre à l'évolution des besoins des applications, sans que vous, utilisateur, n'ayez à y penser. Si vous souhaitez approfondir le sujet, je vous renvoie à l'excellente présentation de William, ainsi qu'à l'article suivant : "Understanding Memory Allocation and File System Caching in OpenSolaris"

Vous pourrez même échanger directement avec William, ainsi que plusieurs experts Oracle Solaris, comme Clive King, Thierry Manfé ou Claude Teissedre,  lors du Solaris Tech Day, qui se tiendra le 5 avril prochain.

Translate in English

samedi sept. 25, 2010

Oracle OpenWorld : BIG !

Translate in English

Gigantesque est bien le mot. Je suis dans l'avion qui me ramène d'oracle openworld avec Christophe Talvard et nous voulions vous livrer quelques impressions "à chaud" et un chiffre : 41000 personnes ! Evidemment vous n'avez sûrement pas manqué les nombreux articles sur le sujet, avec bien entendu l'annonce majeure sur la solution Exalogic Elastic Cloud, qui vient s'adosser à l'offre Exadata pour couvrir le tier applicatif de façon très efficace : 12 fois plus performante qu'une architecture traditionnelle en grille de serveurs d'application. Un niveau de performance permettant de supporter la charge du trafic mondial de Facebook sur seulement deux configurations! Ce qui démontre en soi la stratégie d'Oracle : "Hardware and Software engineered to work together". Une stratégie qui va bien au delà de l'extraordinaire gain en performance et qui s'attache également à faciliter la gestion de l'ensemble des composants logiciels et matériels de l'Exalogic avec la possibilité de les mettre à jour avec un unique fichier, pré-testé et validé par Oracle.

Avec Exalogic et Exadata, tous les éléments sont présents pour déployer un Cloud public ou privé : les performances, l'intégration des logiciels et des matériels mais également la tolérance aux pannes, la flexibilité et l'évolutivité.

Mais ce n'est pas tout, SPARC et Solaris disposaient également d'une place de choix avec la présentation de la roadmap à 5 ans et l'annonce du processeur T3, ses 16 cœurs et quelques records du monde à la clé, ainsi que l'arrivée prochaine de Solaris 11, non seulement de façon générale mais aussi en option au sein d'Exalogic et de la nouvelle version d'Exadata. A ce titre de nombreuses sessions d'échanges sur des retours d'expérience de mises en œuvre d'Exadata ont fait salles combles, notamment celles de Jim Duffy et Christien Bilien sur la solution déployée chez BNP Paribas (voir précédent poste). A noter également plusieurs témoignages sur l'utilisation d'Exadata en consolidation de bases de données. Un modèle qui devrait s'accélérer avec la nouvelle machine x2-8, ses nœuds très capacitifs de 64 cores et 2 To de RAM et ses unités de stockage Exadata Storage server ultra performantes et optimisées pour vos données structurées. Sans oublier l'annonce de la nouvelle gamme ZFS Storage Appliances pour l'ensemble de vos données non structurées et le stockage de vos environnements virtualisés au meilleur coût et avec une sécurité maximum (triple parité).

Toutes ces infrastructures matérielles et logiciels conçues pour travailler ensemble, sont les fondations des applications supportant les métiers de votre entreprise. Et dans ce domaine, l'annonce de l'arrivée de Fusion Applications, l'un des plus gros projet de développement de l'histoire d'Oracle, est majeure. En effet, Fusion Application apporte à vos applications métiers (CRM, ERP, RH,...) un socle standard et non plus un moteur propriétaire comme c'était le cas jusqu'ici. Or, nous le savons tous, ces moteurs propriétaires liés aux développements spécifiques sont les causes de la complexité des systèmes d'informations actuellement en place et de leur non agilité à répondre aux changements des métiers toujours plus rapide. Fusion Application change radicalement les perspectives, car non seulement il fournit une souche standard mais il a été également conçu pour découpler les besoins spécifiques du socle et donc pour ne pas freiner les évolutions et l'agilité de l'entreprise.

En bref, nous disposons de solutions technologiques ouvertes, qui, tout en s'intégrant de manière évolutive dans votre système d'information vont en révolutionner les opérations avec un alignement sur les besoins métiers et une agilité incomparable. Et nous sommes tous prêts à travailler à vos côtés pour les mettre en application dès aujourd'hui.

Translate in English

mercredi juin 16, 2010

Gagnez en observabilité et en rapidité d'analyse avec DTrace

Translate in English

Faisant suite à la présentation de William Roche sur DTrace, le groupe d'utilisateurs Solaris se réunit pour une mise en pratique ce soir à Supinfo. Afin de comprendre les atouts de cette technologie, j'ai repris dans ce poste, les principaux points exposés par William lors de son intervention. Avec ces éléments, vous serez capable de :

  1. vous lancer dans DTrace
  2. briller dans l'analyse et la résolution de vos problèmes de production !
  3. nous rejoindre ce soir pour débuter l'expérience
Un peu d'historique

Dtrace existe depuis l'origine de Solaris 10. Il permet d'observer dynamiquement non seulement Solaris mais également les applications, incluant Java, python, php, MySQL,... et bien d'autres. DTrace s'accompagne d'un langage (D) qui permet d'écrire des programmes servant à collecter des informations, voir même à agir sur le système.

DTrace a été conçu pour être utilisé en production

Par exemple, DTrace est conçu pour ne pas causer de Panic, de crash, de corruption de données, ou de dégradation de performance...

Comment ?
En le concevant sur la même idée que Java : un script DTrace va être exécuté en étant interprété dans le noyau, et en passant des filtres d'exécutions et des filtres de données au plus prêt possible où elles sont générées. Ce qui aboutit notamment à une réduction au maximum du temps de capture, de sélection et de traitement des données : limitant d'autant l'impact d'une telle analyse sur un système en production.

DTrace révolutionne la méthode d'analyse

Avant, (1) vous partiez d'une hypothèse, (2) vous instrumentiez le binaire (il vous fallait les sources, pour y ajouter votre instrumentation :  printf("coucou\\n"); ce qui n'était pas toujours simple, puis recompiler, et enfin exécuter), (3) vous collectiez vos données, (4) vous les analysiez, (5) vous revoyez vos hypothèses... et vous relanciez la boucle d'analyse.

Avec DTrace, la partie instrumentation est très fortement réduite :

  • pas besoin de recompiler un programme,
  • capaciter de s'attacher à un programme qui est déjà en cours d'exécution,
  • capaciter de mettre des points d'observations,....
tous cela au plus proche de là où sont générées les données !

Le programme qui passe dans l'endroit que l'on souhaite surveiller génére un évènement, et DTrace capture l'information à la source. La boucle d'analyse est réduite et on peut se concentrer sur le problème à résoudre et non sur l'instrumentation proprement dite.

Pourquoi Dynamic ?

Il y a énormément de mécanismes qui permettent d'analyser des erreurs sur un programme, comme par exemple, un core applicatif, ou un crash dump système, avec les outils d'analyse postmortem comme mdb ou dbx.

Par contre pour analyser des problèmes transient, il existe également truss voir mdb... Mais avec des limitations, comme par exemple l'impossibilité de couvrir les appels systèmes.

Pouvoir comprendre sur un système, pourquoi il y a énormément de threads, qui les réveille, qui les mets en sommeille, c'est à ce type d'information et bien d'autre que Dtrace nous donne en temps réel : des éléments d'analyse précieux.

Dtrace est un framework accessible à travers l'interface DTrace (7D). Pour parler à la partir noyau, nous disposons de la librairie libDTrace (3LIB). dtrace (1M) , lockstat (1M), plockstat (1M) utilisent cette librairie pour collecter des données.

En dessous du framework, il y a le coeur du système : les providers, permettant de collecter les données, de mettre les points d'observations : sdt (stat du système), sysinfo (mpstat), vminfo(vmstat), fasttrap (memory trap, etc...), lockstat (lock système), sched (info sur le scheduling : qui se réveille, qui s'endort, ...), proc (instrumentation d'un processus user land) , syscall (appels système), mib (mib II), io , nfsv4, ip, fbt (les fonctions du noyaux : tous les points d'entrées et de départs de presque toutes les fonctions du noyaux)... pour n'en siter que quelques uns ! Les providers activés vont instrumenter le code et l'exécution du code dans le noyau va faire un petit bond dans le provider pour collecter les informations.

MySQL, Java, php, quand ils se lancent viennent s'authentifier au niveau du framework DTrace et enregistrer leurs providers. Par défaut, ils ne sont pas actifs. Si par contre vous avez besoin d'une information précise, il suffit d'activer le probe voulu.

La richesse de notre implémentation DTrace vient des providers !

Un éditeur de logiciel peut mettre ses points d'observation dans son logiciel : USDT (User-Level Statically Defined Tracing) et fournir ainsi son provider.

On peut avoir plusieurs observateurs en parallèle qui regardent le même "probe". Quand un utilisateur arrête un programme DTrace, tous les probes qu'il utilisaient sont dés référencés de 1, jusqu'à potentiellement la désactivation du probe.

La syntaxe d'un probe

Probe : <provider>: <module>:<fonction>: <name>
Le DTrace framework s'executant dans le Kernel,  il n'y a pas de context switch lors de la rencontre d'une trace.
Nous pouvons avoir des buffers mémoires DTrace par CPU (meilleur gestion des performances), et nous capturons exactement l'information consolidée : par exemple le nombre de fois que l'on rentre dans une fonction... Une grosse différente avec la méthode printf("coucou\\n");.

Pour obtenir la liste de tous les providers (enregistrés à l'instant t) : # dtrace -l

Puis pour avoir des informations plus ciblées :
# dtrace -P <provider>
# dtrace -m <module>
# dtrace -f <function>
# dtrace -n <name>

Au passage, il est important de noter les droits d'utilisation de dtrace, généralement réservés à root. Vous pouvez déléguer tout ou parti de ces droits, en utilisant les niveaux suivants dans /etc/user_attr : dtrace_user, dtrace_proc, dtrace_kernel

Le language D

Le language D a presque la syntaxe du C avec la manière d'écrire un programme awk(1M).  C'est un script qui définit un certain nombre de prédicats et qui a chaque fois que ce prédicat est rencontré, génère une action. Dans l'action on peut positionner des variables pouvant elles-mêmes faire l'objet de conditions.

DTrace c'est un programme construit de cette manière qui dispose de variables globales, locales au thread d'exécutions, locales au provider, avec des variables intégrées comme execname et timestamp.
On définit ensuite l'action, par exemple : tracer la données, enregistrer une trace de la stack, enregistrer la donnée.

Quand un évènement est déclanché et que le prédicat est vrai, l'action est exécutée.

Example : "Print all the system calls executed by bash"
#!/usr/sbin/dtrace -s
syscall:::entry   => probe description
/execname=="bash"/ => /predicat/
printf("%s called\\n", probefunc); => action statements

Nous venons d'écrire une commande truss capable de tracer TOUS les "bash" du système.

Execute l'action seulement si la condition du predicat est vrai.
La condition est une expression en language D.

Certaines actions peuvent changer l'état du système de manière bien définie (-w).

Exemple d'actions pour enregistrer les données :

  • trace()
  • printf() : la vérification de la cohérence sur le nombre et sur le type des paramètres est faite à la compilation du script : mieux qu'en C !
  • stack() enregistre la stack kernel
  • ustack() enregistre la stack userland du thread dont la stack est exécutée
  • printa() qui permet d'afficher une aggrégation
  • exit() pour sortir

Actions "destructive" : "-w"

  • stop() un process
  • raise() envoi un signal à un process
  • breakpoint() le kernel
  • panic() le système
  • chill() introduit une latence

Parfois ce n'est pas l'évènement mais la tendance qui nous intéresse : "combien de fois appelle-t-on cette fonction avec un argument entre 4k et 8k ?"
Ce type d'information va nous être fourni au travers des fonctions suivantes : sum(),count(), min(), max(), avg(), quantize() en puissance de 2 (exponentiel), lquantize() en mode linéaire

L'aggrégation peut être collecté dans un tableau de taille indéterminé.
L'aggrégation peut porter un nom : @name[keys] = aggfunc(args);

Par exemple, si vous souhaitez regarder la répartion des tailles de malloc() dans le process que l'on suit :

Script dtrace : aggr2.d
#!/usr/sbin/dtrace -s
  @["Malloc Distribution"]=quantize(arg0);

$ aggr2.d -c who (le pid du process "who" qui va être lancé à ce moment là va remplacer pid$target dans le script dtrace aggr2.d)

trace: script './aggr2.d' matched 1 probe
dtrace: pid 6906 has exited
Malloc Distribution
        value ------------- Distribution ------------- -----------------count
           1  |                                                         0
           2  |@@@@@@@@@@@@@@@@@                                        3
           4  |                                                         0
           8  |@@@@@@                                                   1
           16 |@@@@@@                                                   1
           32 |                                `                        0
           64 |                                                         0
          128 |                                                         0
          256 |                                                         0
          512 |                                                         0
         1024 |                                                         0
         2048 |                                                         0
         4096 |                                                         0
         8192 |@@@@@@@@@@@                                              2
        16384 |                                                         0

Calculer le temps passé dans une fonction
Là, nous avons besoin de variables spécifiques au thread d'exécution : variables pré-fixées par "self->" qui éliminent les cas de "race condition" sur une même variable. Quand vous remettez à zéro la variable, dtrace la dés-alloue (c'est son "garbage collector").

#!/usr/sbin/dtrace -s
     printf("ThreadID %d spent %d nsecs in %s", tid, timestamp - self->ts, probefunc);
self->ts=0; /\*allow DTrace to reclaim the storage \*/

DTrace fournit également l'accès aux variables kernel et externes.
Pour accèder aux variables externes, il suffit de les préfixer par ` (anti-quote)

#!/usr/sbin/dtrace -qs
printf("physmem is %d\\n", `physmem);
printf("maxusers is %d\\n", `maxusers);
printf("ufs:freebehind is %d\\n", ufs`freebehind);

Speculative tracing
Il est important de trier les informations collectées car les buffers en mémoire de Dtrace sont limités (pour de bonnes raisons : impact des performances, utilisable en production...).
On crée dans ce cas "une spéculation". Vous allez allouer un buffer mémoire qui collecte vos traces, et si le thread sort en erreur, nous gardons l'information (pour analyse), sinon nous libérons le contenu du buffer.

C'est très intéressant dans le cas où vous recherchez un problème aléatoire qui sort de temps en temps en erreur.

self->spec = speculation () : mise en place d'un buffer speculatif par thread

Un exemple : si l'on recherche les cas de mount() qui sortent en erreur.

   self->spec = speculation();
   printf(“returning %d\\n”, arg1);
/self->spec && errno != 0/
/self->spec && errno == 0/
{ self->spec = 0; }

copyin & copyinstr

Ce sont des fonctions qui servent à récupérer des informations de processus userland, pour voir ces informations dans le noyau, car DTrace tourne dans le kernel :

  • copyin(addr,len)
  • copinstr(addr) - chaîne de caractère

Anonymous tracing
Imaginons que le système crash de temps en temps au boot, ou en panic.
Mais pour étudier cela avec un script, quand il y a un crash, le système disparait.
Pour y répondre, dtrace dispose d'une solution non rattachée à un consommateur donné et qui doit être enregistré dans le noyau. Le script dtrace est dans ce cas mis dans un fichier de configuration qui sera démarré au boot. Les buffers de trace associés à ce script sont dans le kernel et donc récupérables et analysables sur crash.

Pour créer ce script : # dtrace -A
Pour collecter les informations : # dtrace -a

Dtrace : une technologie à la porté des développeurs 

Au delà de la disponibilité de dtrace sur un système en production, vous pouvez également en bénéficier dès les phases de développement !

D-Light plugin dans SunStudio 12.1
Dans Sun Studio, au travers de D-Light, vous disposez de tout un ensemble de scripts dtrace qui permettent de récupérer des informations en temps réel sur le process que l'on exécute au sein de SunStudio. Cette collecte se fait de façon graphique avec une capacité de "drill-down" fine. Vous pouvez suivre un processus conçu dans l'IDE, mais également un processus s'exécutant sur un système.

Le point crucial : la documentation !

Vous disposez d'un grand nombre d'informations (liste des providers, etc...) indispensables à l'analyse sur le site wiki de DTrace :

Il existe également un kit avec un ensemble de scripts déjà prêts : le Dtrace Toolkit.
C'est un ensemble de scripts qui mélangent du Dtrace et du perl (pour la présentation) qui permettent de répondre à un grand nombre de questions sur les différents paramètres d'utilisation de vos applications et du système :

Vous pouvez même utiliser DTrace à l'intérieur d'Oracle Solaris Studio (ex- Sun Studio Tools) - voir plus haut.

Et en standard sur toutes vos machines Solaris : /usr/demo/dtrace

"let's do it" !

Pour aller plus loin :

  1. DTrace party ce soir à Supinfo !
  2. La formation :
    • EXL-2210 Developing and Optimizing Applications with Dtrace
        > 4 days - Experienced Java and C/C++ Developers
    • EXL-2211 Optimizing Solaris Administration with Dtrace
        > 4 days - Experienced System Administrators
  3. Bryan Cantrill en live :
Translate in English

mardi avr. 13, 2010

ZFS pour base de données Oracle : Best Practices

Translate in English

Le mois dernier, Alain Chéreau, expert Solaris et Oracle du Sun Solution Center, a partagé son retour d'expérience sur l'optimisation des bases Oracle sur ZFS. C'est donc avec un peu de retard, à la veille de la prochaine conférence du GUSES sur DTrace, que je vous livre les points clés de son intervention.

Les quelques bases de tuning de ZFS restent bien entendu d'actualité :

  • taille de la mémoire utilisé par ZFS

  • dévalidation du mécanisme de flush des caches disques sur baie de disques sécurisés

  • taille du record size, de grande importance dans un contexte Oracle, pour éviter de lire plus de données que nécessaire (du fait du mécanisme de Copy on Write), car les performances d'Oracle sont surtout sensibles aux temps de réponse des écritures et aux débits de lecture

    • Ajuster le recordsize= db_block_size = 8k pour index et tables (très important car supprime énormément de lecture)

    • Garder 128k (défaut) pour redo, undo, temporaire et archivelog

    • Ajuster le recordsize des filesystems des bases DW ayant plus des contraintes de lectures que de batch de mise à jour : recordsize = db_block_size = 16k ou 32k

  • une attention sur le prefetch (en fonction du type de charge).

    A cela Alain a ajouté un certain nombre d'éléments d'optimisation très pertinents.

Gestion des écritures synchrones

Oracle ouvre tout ses fichiers en O_DSYNC et demande de ce fait à ZFS d'écrire en mode synchrone. ZFS va donc écrire dans son ZIL (ZFS Intent Log), qui n'est utilisé que pour des écritures de type synchrone. Une fois l'écriture dans le ZIL effectuée, la transaction peut être acquitté côté Oracle. Il est donc important d'aller vite (privilégier la latence). Si on dispose d'une baie disque externe, on mettra le ZIL dans la baie de stockage (ou, sinon sur SSD). 15 secondes de flux d'écriture suffisent comme volume pour le log device de ZFS (ZIL). En outre, si la baie voit que l'on réécrit toujours les mêmes blocks, elle ne va pas l'écrire sur disque et elle va le garder en cache. Un petit ZIL sera donc à préférer à un gros (utilisation d'une slice (64Mo) dans un LUN si les LUN des baies sont trop gros)

Cache Disques, cache ZFS et cache Oracle
Caches à tous les niveaux : c'est la règle générale en transactionnel ! Une fois que le cache hit ratio Oracle est bon, il n'y a plus besoin d'agrandir le cache Oracle et il faut mieux laisser la mémoire restante au cache ZFS car les politiques de cache sont différentes et se complètent.

Ecritures et lectures séquentielles

ZFS écrit en séquentiel (en Copy on Write) : toutes les écritures logiquement aléatoires deviennent séquentielles. Il a donc un comportement optimisé pour des baies de disques (et pas uniquement des disques locaux), et aussi pour les indexes (indexes que l'on va également mettre en générale sur SSD). Par contre, il faut faire attention au comportement de tout ce qui est full scan/range scan (lecture séquentielle) qui du fait du Copy On Write (COW) de ZFS auront été éparpillées. ZFS va quand même regrouper au mieux ses I/Os sur ce type de lecture. Cela aura également un impact sur le comportement des sauvegardes. C'est pourquoi l'utilisation de snapshots peut-être intéressant à ce niveau, ainsi que les fonctions zfs send/receive.

Throughput vs. latency
Il peut être utile lors de grosses écritures séquentielles d'éviter une double écriture (ZIL, puis disques), pour cela il est possible d'indiquer à ZFS en mode « throughput » (mais attention, ensuite il s'applique à toute la machine). Ainsi, si on positionne dans /etc/system zfs_immediate_write_sz à 8000 sur Sparc (sur intel il faut mettre en dessous de 4096 (taille de pagesize et de db_block_size)), toutes les écritures dépassant les 8000 octets seront écrites directement sur le disque (utile pour les processus db writers)

Sur les redolog, la base Oracle aime bien que l'on écrive très vite, il faut donc privilégier le mode latence. Pour cela il faut déclarer un log device (ZIL) séparé sur un ZPOOL des redologs pour ignorer le paramètre « throughput » et garder une bonne latence sur les redologs (vitesse des commits)

Cache ZFS « SSD aware » : adapté pour beaucoup de lectures aléatoires (SGA trop petite, cache primaire (RAM) ZFS trop petit, et beaucoup de lecture aléatoire sur disques). Base avec 'sequential read' très important (>  40%) dans le top 5 des événements Oracle (Statpack ou Awr). Faites attention au warm up du cache secondaire sur SSD... Et c'est bien entendu sans intérêt pour les redologs (écritures).

Mettre les index sur SSD permet également de gagner en bande passante sur les I/O baies qui deviennent dédiées au flux des données.

Optimisation en fonction des profiles de bases
1. Base avec un flux de modification important
utiliser un zpool séparé pour les redologs avec log device séparé (même sur la même LUN en utilisant des slices)

  • une slice pour le ZIL
  • une slice pour le redolog
  • une slice pour les Données (tous les datafiles)
  • Archivelog : n'importe quel disque, même interne

2. Base très active et très importante (volume et activité de l'application)
La séparation des IO sur des disques physiques différents est toujours une optimisation valide : définir des structures disques (zpool/ZFS filesystems) pour séparer redo, tables, index, undo, temp.
Plus le comportement est de type transactionnel (OLTP) plus ce découpage est efficace.
Si le profile est plutôt décisonnel, vous pouvez choisir une approche de type « stripe everything »

Bien entendu, tout cela doit être mis en perspective en fonction de la vie de la baie et est lié à la problématique de mutualisation de bases sur une baie consolidée et des politiques d'évolutions associées.

3. Serveur multi-bases (consolidation)
Utilisez un zpool par usage (redo, datafiles,...) puis ensuite, créez des systèmes de fichiers ZFS par base dans les zpools correspondants.

Gestion des ZPOOL
Garder 20% de place libre dans chaque zpools avec écritures et utilisez l'autoextend des datafiles car la pré-allocation en général utile sur UFS pour jouer sur l'aspect contiguë des données n'a pas d'intérêt avec ZFS (du fait du COW).

ZFS Compression
Sur les Archivelog : allez y !
Sur les datafiles : cela semble une bonne idée... Il faut prévoir 10% à 15% de CPU, mais le gain de place est important. Si vous hésitez à le passer directement sur la production, allez y par contre dans vos environnements de développement et intégration. Et aussi, bénéficiez des capacités de gestion de compression dynamique de ZFS. En effet, à la création de la base, mettez par défaut la compression à « on » : vous allez gagner en place et en temps de création (compression du vide). Ensuite vous pouvez remettre la compression à « off » : ainsi les blocs de données réelles ne seront pas compressés (du fait du mécanisme de COW).

ZFS Clones
Bénéficier du mécanisme de Copy on Write, pour récupérer instantanément un ou des clone(s) de vos bases de données : un moyen simple de fournir de multiple copies modifiables sur même jeu de disques pour développement, recette, intégration...

Checksum Oracle + ZFS : gardez tout ! Plus de sécurité pour un coût CPU faible.

Oracle RAC et ZFS : ils sont incompatibles, car ZFS gère ses méta-data localement.

Les autres points à prendre en compte sur l'optimisation des performances Oracle

  • Mauvais SQL, Contention applicatives
  • Manque de puissance CPU
  • Configuration mémoire (SGA, caches)
  • Contention réseau
  • Débit et capacité en nombre d'IO des disques

Comme le précisait Alain en conclusion de cette session d'optimisation des bases Oracle sur ZFS, « pour aller plus loin, à l'ère des processeurs multi-cores, multi-thread, pensez au parallèlisme !!! » : les statistiques, les sauvegardes, la construction d'index en parallèle sont déjà des bonnes choses en standard à mettre en oeuvre.

J'espère que ces notes vous seront utiles dans la mise en oeuvre de vos bases Oracle sur ZFS.

Merci encore à Alain Chéreau pour son retour d'expérience fouillé sur le sujet. Et n'oubliez pas, demain à Supinfo, la conférence du groupe des utilisateurs Solaris autour de Dtrace, pour vous permettre d'appréhender au mieux son usage et gagner en efficacité sur l'identification et la correction de vos incidents de production.

Translate in English

mardi mars 02, 2010

A vos agendas : les conférences du Groupe des Utilisateurs Solaris deviennent mensuelles

Translate in English

La prochaine conférence du groupe des utilisateurs Solaris aura lieu le 17 mars, à partir de 18h30 à SUPINFO. Alain Chereau, expert Solaris et Oracle du centre de benchmark, partagera son retour d'expérience sur l'optimisation des bases Oracle sur ZFS : performances et tuning.

Pour les détails de l'agenda, je vous invite à consulter directement le site du GUSES, et à vous enregistrez dès maintenant.

Vous pouvez également dès à présent réserver les dates suivantes, pour les prochaines conférences du GUSES :

  • 14 avril : 18h30 - 21h - DTrace Tutorial, par William Roche - Expert Solaris
  • 19 mai : 18h30 - 21h - Sujet en cours de définition
  • 16 juin : 18h30 - 21h - Sujet en cours de définition

En effet, les conférences du GUSES deviennent mensuelles, et SUPINFO a offert de les héberger. Je vous invite donc à rejoindre les membres du GUSES pour ces échanges, à SUPINFO, 52 rue Bassano, 75008 Paris, aux dates indiquées.

Translate in English

vendredi févr. 19, 2010

Oracle Extreme Performance Data Warehousing

Translate in English

Mardi dernier a eu lieu un évènement portant sur la probématique de performance des environnements Data Warehouse et organisé par Oracle. A cette occasion, Sun a été invité à présenter les infrastructures et solutions adressant les exigences toujours plus fortes dans ce domaine. Et BNP Paribas CIB, en la personne de Jim Duffy, Head of Electronic Market DW, a apporté un témoignage très intéressant sur les phases d'évolution de leur Data Warehouse de gestion des flux financiers sur lequel je vais revenir également dans ce post, en vous parlant infrastructure évidement, socle majeur pour atteindre l'"Extreme Performance".

Explosion des données numériques = fort impact sur les infrastructures

Les chiffres parlent d'eux même. Nous assistons à l'explosion des données numériques. De 2006 à 2009, les données numériques ont pratiquement quintuplé pour atteindre pratiquement 500 Exabytes, et IDC prédit la même croissance d'ici 2012, soit 2500 Exabytes de données numériques dans le monde (source: IDC, Digital Universe 2007 et 2009).

En tant que fournisseur de stockage et numéro #1 de la protection de la données, nous le vivons tous les jours à vos côtés. Cette tendance à des impacts à plusieurs niveaux :

  • Sur la capacité à stocker et sauvegarder les données

  • Sur la capacité de traiter les informations pertinentes parmi une masse de données toujours plus conséquente

  • Sur la capacité de gérer l'évolution des unités de calculs et de stockage nécessaires tout en restant “vert”, c'est à dire en maîtrisant également l'impact sur l'énergie, les capacités de refroidissement, et l'encombrement dans vos Datacenter

Les besoins sur les infrastructures des Data Warehouse

Tout cela induit de nombreux enjeux techniques à couvrir pour les entrepôts de données. D'autant plus que cette fonction est devenue une fonction capitale et critique pour le pilotage de l'entreprise.

Le premier enjeu est la capacité de faire croitre l'ensemble de l'infrastructure pour faire face à la croissance des données et des utilisateurs. Ce que Jim Duffy a illustré clairement dans la présentation des phases d'évolutions du projet d'analyse des flux financiers chez BNP. Après un démarrage avec quelques dizaines de Giga Octets en alimentation par jour, ils ont vu la tendance évoluer fortement pour atteindre pratiquement 500 Giga Octects sur 2010. Grâce aux différentes options de la base de données Oracle (partitionnements, compressions) explicitées d'ailleurs lors de ce séminaire par Bruno Bottereau, avant-ventes technologies Oracle, la BNP a pu contrôler l'explosion des données au sein de son Data Warehouse. En outre, compte-tenu de la tendance d'une augmentation importante des données à traiter, les fonctions avancées disponibles dans la solution Sun Oracle Database Machine (Exadata) comme l'Hybride Columnar Compression s'avéraient indispensables à évaluer pour contrôler au mieux cette croissance. Comme l'expliquait Jim Duffy, l'évolution paraissait naturelle et simplifiée, car restant sur des technologies Oracle, ils ont validé en réel lors d'un Proof of Concept la simplicité de passage de la solution actuelle sur Oracle RAC 10g vers la solution Exadata en Oracle RAC 11gR2 en un temps record, avec un gain de performance important.

L'enjeu suivant est la performance avec la nécessité de prendre des décisions intelligentes souvent dans des temps de plus en plus courts et sur une masse de données plus importante. Ce qui impacte à la fois les unités de traitement et la bande passante pour traiter les données. Ce point a été clairement illustré par Jim dans son intervention, où il cherche a effectuer des analyses "quasi" en temps réel (minutes, voir secondes !) sur la masse de données collectée.

Avec une économie mondialisée, et un besoin de réajuster la stratégie presque en temps réel, les entrepôts de données ont vu leur besoin en disponibilité s'accroitre de façon très importante. C'est d'ailleurs ce qui a poussé la BNP à l'origine du projet à déployer un cluster Oracle RAC sur Solaris x86 pour supporter leur entrepôt de données.

Les entrepôts de données conservant les informations de l'entreprise, la sécurité est un élément incontournable dans le traitement de l'information qui y est stockée : qui à le droit d'accéder à quoi ? Quel niveau de protection est en place (cryptographie,...) ? Fonctions évidement couvertes par la base Oracle, mais également dans l'ADN du système d'exploitation Solaris : un double avantage.

Les solutions doivent évidement être rapide à mettre en place, pour ne pas être obsolètes une fois le projet d'entrepôt de données réalisé. Et évidemment, elles doivent répondre à une problématique de coût d'infrastructure optimisé aussi bien en terme de puissance de traitement, de capacité de stockage et de consommation énergétique associée. Tout en couvrant l'ensemble des critères évoqués jusqu'ici : scalabilité, performance, disponibilité, sécurité... Finalement, en s'appuyant sur des standards ouverts, à tous les niveaux, elles doivent permettent d'intégrer les nouvelles évolutions technologiques sans tout remettre en cause. En bref : être flexible.

L'approche des Systèmes Oracle Sun

Pour répondre à tous ces besoins, l'approche de Sun a toujours été de maîtriser l'ensemble des développements des composants de l'infrastructure, ainsi que leur intégration. Afin de concevoir des systèmes homogènes et évolutifs du serveur au stockage en incluant le système d'exploitation... et même jusqu'à l'application... au travers d'architectures de références testées et validées avec les éditeurs, dont Oracle ! En clair, fournir un système complet, homogène et pas uniquement un composant.

La solution Sun Oracle Database Machine (Exadata) en est une bonne illustration, en solution "prêt à porter". Cette philosophie s'applique à l'ensemble de la gamme des systèmes, tout en permettant de couvrir également des besoins "sur mesure", comme par exemple la sauvegarde.

A titre d'exemple de solution "sur mesure", voici une illustration d'un entrepôt de données, réalisé pour un de nos clients, avec des contraintes très fortes de volumétrie  à traiter et de disponibilité. Plus de 300 To de volumétrie pour le Data Warehouse et les Data Marts.

Cette implémentation s'appuie sur 3x serveurs Sun M9000, pouvant contenir chacun jusqu'à 64 processeurs quadri-coeurs, soit 256 coeurs, jusqu'à 4 To de mémoire et 244 Go/s de bande passante E/S: de la capacité pour évoluer en toute sérénité. Le coeur de l'entrepôt tourne sur 1x M9000, les DataMarts étant répartis sur 2 autres M9000. La disponibilité est assurée par le serveur M9000 en lui-même et sa redondance totale sans aucun point de rupture unique.

Le passage sur la nouvelle architecture a permis d'améliorer par 2 le temps de réponse de la plupart des requêtes, sur des données toujours croissantes. Cette infrastructure supporte plus de 1000 utilisateurs DW concurrents et la disponibilité a été améliorée de part la redondance interne des serveurs M9000 et des capacités d'intervention à chaud sur les composants.

En outre, en entrée et milieu de gamme, la gamme Oracle Sun T-Series, bien que limitée à 4 processeurs maximum offre une capacité de traitement parallèle unique  de part son processeur 8 coeurs/8 threads, couplé à des unités d'E/S et de cryptographie intégrées au processeur, et détient le record du nombre d'utilisateurs concurrents Oracle BI EE sur un serveur.

Quelle solution choisir : du "sur mesure" au "prêt à porter" ?

4 critères majeurs vous aideront à sélectionner le serveur répondant le mieux à vos besoins :

  1. le volume de données à traiter,
  2. le type de requêtes,
  3. le niveau de service attendu,
  4. le temps de mise en oeuvre

N'hésitez pas à nous contacter pour que nous vous guidions vers la solution la plus adaptée à vos besoins.

Translate in English


Eric Bezille


« mars 2015