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 oct. 17, 2012

Understanding what's happening to your VMWare's VM I/O in real-time

Back in California to work for a week with our development teams, I met Art Licht, who pointed me to a very cool 7 minutes video showing how you see and analyze what's going on for each one of your VMWare's VM seating on your ZFS Storage Appliance. I invite you to see the real value this can bring to you and any Infrastructure Cloud Builder or Operator in this short video :

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]

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

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

mercredi déc. 16, 2009

La virtualisation Solaris pour quels gains ?

Translate in English

Hier soir, nous nous sommes retrouvés avec une vingtaine d'utilisateurs Solaris pour la soirée du GUSES dont je vous avais parlé la semaine dernière. Bruno Philippe, expert Solaris d'une grande banque française, nous a brillamment exposé son retour d'expérience sur l'adoption de la technologie de virtualisation incluse dans Solaris, et les bénéfices associés. Des bénéfices qui font que le projet a largement débordé du cadre initial de rafraichissement d'un parc vieillissant et s'applique maintenant aux nouveaux projets, non seulement SPARC, mais également x64. La méthode une fois mise en oeuvre étant applicable dans les 2 environnements, car Solaris est le seul UNIX d'entreprise multi plate-formes.

La maturité !

Comme Bruno le rappelait en introduction, la virtualisation incluse dans Solaris (à coût 0€) est très mature car présente dès l'origine de Solaris 10 (janvier 2005) et déployée dans des environnements très variés comme  oracle, sybase, sap, avec les outils d'administration associés : $u, cft, mqm, netbackup.... pour n'en citer que quelques uns. En outre, c'est une solution qui s'enrichit tous les jours pour pouvoir offrir une virtualisation sans limites (ou presque) et des gains substantiels !

La virtualisation Solaris pour quels gains ?

Avec une économie de plus de 100K€/an, l'intérêt du projet était évident (!) pour cette grande institution financière et ne s'arrête pas là ! A cela s'ajoute une optimisation des opérations avec un ratio de 30j/h vs. 125 h/j précédemment, ainsi qu'un niveau de service amélioré : pas au niveau d'un cluster, mais très correcte du fait de l'architecture permettant de déplacer les containers Solaris très rapidement d'un serveur à un autre. D'ailleurs, pour les environnements plus exigeants, cette grande banque a déployé 2x Solaris Cluster 3.2 gérant la bascule automatique des containers Solaris en cas d'incident : l'un en SPARC et l'autre en x86/x64.

Les détails du projet

Pour ceux qui souhaitent se lancer dans l'aventure, voici les détails du projet tels que je les ai retenu hier. Je compte sur Bruno pour apporter les corrections nécessaires le cas échéant.

Les objectifs recherchés étaient les suivants :

  1. Réduction des coûts.
    Plus il y a de machines, plus il y a de jours/hommes d'administration : patches, etc...
  2. Flexibilité.
    Cibler des serveurs plus capacitifs (notamment en mémoire) et partager les ressources de façon plus efficace au travers de la virtualisation
  3. Optimisation des coûts opérationnels de déploiement et mise à jour.
    Installation d'une seule version qui est déployée ensuite dans plusieurs containers, donc une seule mise à jour pour les DBA.
D'autres besoins importants des administrateurs UNIX et des DBA ont également été adressés au travers de ce projet. J'en ai retenu 2 principaux : la reprise d'activité simplifiée dans le cadre d'un DRP et la capacité de rafraîchir les données facilement (envisagé via snapshot/clone ZFS).

Un vrai ROI

Une étude préalable a été menée afin de définir la bonne architecture cible et d'obtenir le ROI du projet, démontrant sa viabilité.

Le périmètre de l'étude portait sur 30 serveurs physiques (SPARC), 70 instances Oracle, 30 instances Sybase. Elle passait par un monitoring du parc existant pour calibrer les serveurs, définir le type de serveur cible pour la consolidation, et valoriser le ROI pour les achats.

Les valeurs prises en compte pour le ROI ont été les suivantes :
  • la consommation éléctrique (théorique)
  • le nombre total de racks utilisés (surface)
  • le nombre de connexions SAN et réseau (une connexion coûte 1k€/an - selon une étude constructeur)
  • le coût en h/j pour différentes opérations système uniquement... avec 1 h/j système correspondant à environ 500€ (pour une entreprise, charges comprises)

Sur la base de ces mesures, le ROI a été démontré en 2 ans (y compris la mise en oeuvre). Or, les DBA se sont aperçus après coup des gains et économies supplémentaires apportés, soit au final un ROI encore plus rapide.

En complément de ces valeurs, la partie gain en maintenance a été également prise en compte (ancien vs. nouveau) directement au niveau des achats.

L'architecture cible du refresh technologique

Suite au calibrage des serveurs existants (sur une base avec requêtes OLTP type Oracle), la cible de la consolidation a été orientée sur des serveurs Sun M5000, 8 processeurs, 4 coeurs chacun, 2 threads par coeur, soit 64 threads d'exécution physique (ou processeurs virtuels vues de l'instance Solaris) avec 128 Go de RAM (pour commencer) et le doublement de l'ensemble des interfaces réseaux (IPMP) et SAN (MPXIO) offrant ainsi la capacité et la sécurité.

Une bonne base de travail en terme de ressources pour virtualiser, sachant que la technique de virtualisation Solaris ne nécessite l'administration que d'une seule instance d'OS, quelque soit le nombre de machines virtuelles (containers) créées à partir de celle-ci. En outre, contrairement à d'autres solutions de virtualisation, la taille des containers n'est pas limitée et peut prendre toute la machine (dans ce cas, 64 CPUs virtuelles) si besoin. Pour plus d'information sur la technologie proprement dite, je vous engage à consulter ce petit guide : "How to Consolidate Servers and Applications using Solaris Containers".

2x M5000 ainsi configurés servent de socle pour la consolidation des bases Oracle.
Pour la partie Sybase, qui nécessite moins de puissance unitaire en processeur, mais par contre beaucoup de mémoire (notamment pour monter le tempdb sous tmpfs), 2x serveurs T5240 avec 256 Go de RAM ont été acquis.

Au final, comme les containers peuvent indifféremment être démarrés ou déplacés sur une machine M5000 ou T5240, la répartition est gérée de façon transparente en fonction des besoins réellement constatés. Le périmètre initial de refresh du parc de développement et pré-production a conduit à la mise en oeuvre de 90 containers regroupant 110 bases Oracle et environ 30 bases Sybase.
En outre, du fait du succès de l'opération, le parc de serveurs virtualisés de cette façon s'est étendu, et un socle sur architecture x86/x64 constitué de plusieurs serveurs Sun X4600 (8 processeurs de 6 coeurs chacun, soit 48 coeurs au total par serveur) est en cours de déploiement.

Pour un projet initié en mars 2009, plus de 250 containers sont déployés à ce jour sur une quinzaine de M5000. Avec en moyenne 20 containers par instance Solaris sur le développement et la pré-production et 10 containers sur la production (car le besoin mémoire est le facteur limitant du nombre de containers possible, bien avant le besoin en processeurs).

Je ne rentrerai pas plus loin dans les détails d'implémentations technique tels que :

  • le choix de normalisation du nommage des zones globales, des containers, des pool ZFS
  • le choix d'un container de type sparse (vs. full) avec le zonepath sur le SAN (non monté à partir de la racine, mais d'un sous répertoire pour que le Liveupgrade fonctionne)
  • le choix d'un pool ZFS par containers
  • les options de mise en oeuvre de ZFS (vous pouvez déjà avoir une petite idée ici)
  • le choix d'un pool et d'un seul système de fichier ZFS par instance de base de données
  • le choix d'un seul VDEV par pool (la sécurité étant assurée par la baie disque).
    Des combinaisons qui ont surement eu un impact sur les performances des zfs send | zfs receive via le réseau... D'où le passage par RMAN pour certains besoins de refresh des données (oops, je rentre dans le détail là, on dirait...)

En tout cas (au moins pour les membres du GUSES) la présentation de Bruno devrait être en ligne prochainement et couvre l'ensemble des choix d'implémentation ainsi que les diverses options, y compris pour Oracle et Sybase, qui ont été développées en détail pendant cette soirée. Je vous invite donc à ne pas manquer les prochaines soirées GUSES pour bénéficier en direct de ces échanges.

Une petite note en guise de conclusion. Comme nous l'avons vu au travers du témoignage très riche de Bruno, si la virtualisation apporte de nombreux gains, la séparation entre le physique et le virtuel complexifie d'autant en revanche les problématiques de localisation. C'est pourquoi, à la suite de ce projet, cet établissement financier est en train de regarder de très très près la dernière version de notre outil de management : Ops Center 2.5. Et il ne sont pas les seuls à la vue du succès du dernier évènement organisé sur ce thème dans notre centre de Paris, et pour lequel une session de rattrapage est planifiée le 7 janvier 2010. N'hésitez pas à vous y inscrire !

Comme j'espère vous l'avoir retransmis par ce billet, pour les personnes qui n'ont pas pu assister à cette soirée, un témoignage passionnant qui a donné lieu à un échange très riche et qui a joué les prolongations avec les participants... A ce titre, suite à de nombreuses demandes, voici le lien pour vous inscrire au GUSES :

Encore merci à Bruno Philippe, au GUSES et bien sûr à SUPINFO qui nous a accueilli pour cette soirée.

Translate in English

mardi déc. 08, 2009

Témoignage utilisateur : Virtualisation Solaris en environnement Oracle et Sybase

Translate in English

Nous en avions parlé à la rentrée, et comme promis, je vous tiens informé de la prochaine Soirée du Groupe des Utilisateurs Solaris (GUSES) sur le retour d'expérience de la virtualisation chez une Grande Banque Française.

Date de l'événement : 15 décembre 2009
Lieu : SUPINFO, 52 rue de Bassano, 75008 Paris

La virtualisation est un axe majeur d'optimisation des ressources, et une possibilité fournit en standard dans Solaris. Dans le cadre des soirées d'échanges du GUSES, nous vous proposons de venir assister au retour d'expérience sur ce sujet, présenté par Bruno Philippe - Expert Solaris, dans un contexte Oracle et Sybase (avec ZFS), chez une Grande Banque Française. Si vous vous posez encore des questions sur comment le mettre en oeuvre, quels sont les bénéfices et pièges à éviter, n'hésitez à venir prendre l'information à la source.

Merci encore à Supinfo qui accueille le GUSES pour cet évènement.

Agenda :
Accueil à partir de 18h30
Conférence et échange de 19h00 à 20h30

Inscrivez-vous dès maintenant

Translate in English

mardi sept. 15, 2009

Soirée GUSES - Groupe des Utilisateurs Solaris (et OpenSolaris)

Translate in English

Hier soir c'était la rentrée pour le GUSES, l'occasion de parler Solaris et OpenSolaris avec des cas d'usages métiers très concrets...
Une soirée où nos amis banquiers étaient assez bien représentés et nous ont fait part de quelques retour d'expériences intéressantes.

1) ZFS et performances

ZFS est très prisé pour sa simplicité et l'ensemble des fonctionnalités qu'il apporte : snapshot, checksum, ....
Reste le point important des performances. A ce titre, je tiens à rappeler l'existence du site ZFS Evil Tuning Guide et notamment quelques paramètres important à positionner :
  • Encadrer l'utilisation de la mémoire système entre ZFS et vos applications (comme iozone, pour les personnes cherchant à effectuer des comparaisons, par example). Dans le cas d'une évaluation récente face à Ext3, sur un système avec 16Go de RAM, le bon paramètrage a été un positionnement du ARC limité à 10 Go (laissant 6 Go pour l'application -IOzone- ).
    Pour limiter le taille mémoire utilisée par ZFS, positionner dans /etc/system : set zfs:zfs_arc_max = 0x280000000 (pour limiter à 10Go)
    En outre, il faut dimensionner la swap de façon adéquate également pour que la réclamation de pages mémoires entre ZFS et les applications se face de façon optimum.

  • Dévalider le flush des caches des disques dans le cas où le système de fichier ZFS se trouve sur une baie de disque avec un cache RAM sécurisé. Si ce paramètre n'est pas positionné, toutes les 5 secondes environs ZFS va forcer la baie à flusher l'ensemble de son cache sur les disques !! Pour plus d'explication et quelques résultats :
    Pour dévalider le flush de façon permanente, ajouter dans /etc/system : set zfs:zfs_nocacheflush = 1

  • Utiliser le bon record size au niveau de chacun des systèmes de fichier ZFS
    # zfs set recordsize=8k mypool/myDatafs;zfs set recordsize=128k mypool/myRedologfs

  • Attention au prefetch de ZFS qui peut avoir un effet de bord additionnel avec le prefetch des baies disques, et conduire à la "pollution" du cache (de la baie). Donc si les I/O ne sont pas séquentielles, il peut être pertinent de dévalider le prefetch de ZFS.
    Pour dévalider le prefetch de ZFS, ajouter dans /etc/system : set zfs:zfs_prefetch_disable = 1

    2) Solaris Temps réel vs. Linux Temps réel
    Un point important recherché avec un système temps réel est son aspect déterministe. C'est ce qu'ont pu observer des utilisateurs de Solaris face à Linux (avec un noyau temps réel) dans ce contexte. Linux a faible charge ayant un traitement plus rapide des requêtes que Solaris, mais étant fortement instable à forte charge (traitement plus long des requêtes que Solaris). Là où Solaris gardait un comportement constant, et donc déterministe...  Pour cela, l'utilisation des techniques de processeurs set (psrset(1M)) et de binding des interrupts (psrset(1M) options -f et -n)  sont des éléments de Solaris intéressant à utiliser.

    3) Les optimisations de Solaris avec Intel Nehalem (Xeon 5500 Series)
    J'ai déjà écrit sur ce sujet, mais depuis, un document assez fouillé sur ces optimisations est disponible à l'adresse suivante :The Solaris Operating System---Optimized for the Intel Xeon Processor 5500 Series

    Il comprend notamment un chapitre pour les développeurs autour des outils d'optimisation et des options de compilation permettant de tirer parti des avancées offertes par le Xeon 5500.

    4) Les fonctions avancées d'OpenSolaris et Solaris pour construire des architectures Cloud
    Mikael Lofstrand, Sun Chief Technologist-Networking vient de publier un document décrivant les architectures associées, étayé au travers de la mise en oeuvre d'une plate-forme Cloud s'appuyant sur ces principes, dont notamment la couche de virtualisation réseau Crossbow et les containers Solaris : The VeriScale Architecture: Towards a Scalable and Elastic Datacenter

    Pour conclure, sachez que les membres du GUSES nous préparent une conférence pour fin octobre, début novembre sur un retour d'expérience client avec la consolidation Solaris sur environnement Oracle utilisant les containers et ZFS.

    Translate in English

lundi févr. 23, 2009

Soirée performances et "best practices" ZFS/OpenStorage

Translate in English

Comme promis, suite à la venue sur Paris de Roch Bourbonnais, Senior Performance Analyst, voici le détail de la soirée organisée avec les membres des communautés OpenSolaris (GUSES) et MySQL (LeMUG). Roch traitera des meilleures pratiques d'optimisation dans différents contextes : systèmes de fichiers, SGBD, et MySQL. Nous aurons également le plaisir d'accueillir Frédéric Vannière, Directeur Technique de Planet-work qui lancera la table ronde de questions/réponses en nous faisant bénéficier de son retour d'expérience sur le sujet.

Date : Mercredi 18 Mars

Lieu : SUPINFO, 52 rue de Bassano, 75008 Paris

Inscription : formulaire en ligne

Agenda :


Introduction - Dernières tendances du stockage (by myself)

Gestion des performances et cas d'usages : les meilleures pratiques avec ZFS et Open Storage autours des systèmes de fichiers, des bases de données et de MySQL en particulier
Roch Bourbonnais, Senior Performance Analyst, Sun Microsystems


Frédéric Vannière, Directeur Technique de Planet-Work, ZFS et OpenStorage - retour d'expérience -  Q&A 



 Je tiens à remercier Supinfo qui nous prête ces locaux à cette occasion, mais aussi l'Ecole Polytechnique qui s'était aussi proposée pour nous accueillir.

Translate in English

vendredi févr. 06, 2009

OpenStorage : la révolution dans la gestion des données

Avant de plonger dans la naissance de la révolution OpenStorage, j'aimerais commencer par souligner 2 éléments importants de la gestion des données aujourd'hui :
  • l'explosion des données à gérer, stocker, analyser. Nous en sommes déjà aux PB dans les entreprises (j'ai personnellement 2TB sur mon bureau...)... bientôt les Exabytes...
  • un marché propriétaire et captif pour les stocker. Si je me permets une analogie, un marché qui ressemble fortement au marché des imprimantes : grosse compétition sur le stockage au prix au giga (l'imprimante au moins cher) et ensuite, un prix très élevé sur les fonctions propriétaires additionnelles indispensables pour gérer de telles volumétries -logiciels de réplications, de snapshots, de compression... - (cartouches propriétaires et non standard pour les imprimantes)
Et Sun dans tout ça ? Nous sommes effectivement très présents sur le marché du stockage, et comme nous aimons beaucoup l'innovation, nous avons pris un virage radical dans l'économie du stockage et de la gestion des données : l'Open Storage. La première solution qui nous a servi de validation du concept s'appelle le X4500 : un serveur hybride, moitié stockage, moitié serveur, permettant de stocker 48TB dans 4U, mais surtout une solution performante, ouverte et intégrée, qui représente déjà 11PB chez un de nos clients français dans le monde de la recherche. Une solution qui fournit toutes les fonctions nécessaires dès le départ : le prix au giga incluant la réplication, le snapshot, la compression... et plus besoin de fsck() car le système de fichier (ZFS) garantit l'intégrité : une des raisons majeures pour laquelle notre client avec 11PB a retenu cette solution (imaginez que vous soyez obligé de vérifier l'intégrité d'un système de fichier de 48TB : ça prend du temps !).

Comme cette solution est basée à 100% sur nos technologies matérielles et logicielles, cela nous permet d'avoir une approche au meilleur coût, surtout que nous valorisons l'open source pour l'enrichir. Voilà pour le deuxième point évoqué plus haut : fini le marché propriétaire et captif, vive l'Open Storage !

Maintenant, il est également important de répondre au premier point : l'explosion des données à traiter. Ce point est critique et suppose une toute nouvelle approche par rapport aux systèmes de stockages classiques SAN ou NAS actuels. En effet, comment traiter toujours plus de données ? Un premier élément de réponse nous est donné par Google, qui, ne trouvant pas de solution sur le marché pour classer toutes les données d'internet a développé sa propre solution. Le principe est simple : comme il est impossible de ramener des PB, voir Exabytes de données vers des serveurs de traitements, ils ont intégré l'application au plus près des données, données qui sont réparties sur les briques à la fois serveur et stockage : le GoogleFS et l'algorithme Map/Reduce... qui sont maintenant disponibles en open source, au travers des projets hadoop (Map/Reduce) et HDFS (GoogleFS)... Je viens d'ailleurs de récupérer l'image ISO OpenSolaris (livehadoop) incluant l'ensemble pour jouer un peu avec (grâce à VirtualBox). Evidement, la brique Sun X4540 (extension du X4500) correspond parfaitement à ce type de déploiement. C'est d'ailleurs ce qu'a fait Greenplum pour sa solution de Business Intelligence.

Bien entendu, tout le monde n'a pas encore Hadoop chez soi, quoi que, les personnes cherchant à faire de l'analyse sur des données non structurées (donc massives) regardent cela de très près. Par contre, tout le monde possède des serveurs de fichiers, qui, eux aussi voient leur besoin en stockage croitre de façon dramatique... C'est là que nous avons décidé d'agir avec les dernières solutions Open Storage (S7110, S7210 et S7410) avec, en prime, des fonctions d'analyses  du stockage (adaptables à vos besoins) et des performances uniques à ce jour, y compris pour stocker les données du "Cloud" avec MySQL.

Notre capacité à combiner les innovations matérielles ET le logiciel au sein des systèmes Open Storage nous permet d'obtenir des performances extrèmes, de part la combinaison des disques SSD et du système de fichier ZFS capable de l'exploiter (avoir des disques SSD est une condition nécessaire mais pas suffisante - pour ceux qui n'auraient que cela à leur catalogue- il faut également un système de fichier "SSD aware" - merci ZFS). Jusqu'à :

  • 5x et 40x !!! sur les IOPS
  • avec un temps de réponse autour de 1ms ! (une fois le cache SSD "chaud" - ce qui peut prendre un peu de temps)
... mais quand même, pour les suspicieux, les résultats sont là avec en plus pas mal de règles de mise en oeuvre en fonction des types de profils d'I/O qui sont donnés par Brendan Gregg.

Comme je le disais récemment, l'avantage de la démarche d'adoption des technologies ouvertes de Sun, c'est que non seulement vous pouvez télécharger le logiciel mais aussi le matériel ! pour l'essayer chez vous gratuitement ! Et en plus très simple à installer, à en croire ceux qui l'ont déjà testé :

Si vous voulez en savoir plus, l'un des développeurs de cette technologie, expert en performance, sera à Paris le 18 Mars, Roch Bourbonnais. Je vous tiendrai informé prochainement de la logistique pour ceux que cela intéresse. Mais vous pouvez dès maintenant réserver votre soirée...

Translate in English


Eric Bezille


« avril 2014