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>
Exemple : FBT:XXX:FFF:ENTRY
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.

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

Action
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

Aggregation
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
pid$target:libc:malloc:entry
{
  @["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
syscall::open\*:entry,
syscall::close\*:entry
{
self->ts=timestamp;
}
syscall::open\*:return,
syscall::close\*:return
{
     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
dtrace:::BEGIN
{
printf("physmem is %d\\n", `physmem);
printf("maxusers is %d\\n", `maxusers);
printf("ufs:freebehind is %d\\n", ufs`freebehind);
exit(0);
}


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.

#!/usr/sbin/dtrace
syscall::mount:entry
{
   self->spec = speculation();
}
fbt:::return
/self->spec/
{
   speculate(self->spec);
   printf(“returning %d\\n”, arg1);
}
syscall::mount:return
/self->spec && errno != 0/
{
   commit(self->spec);
}
syscall::mount:return
/self->spec && errno == 0/
{
   discard(self->spec);
}
syscall::mount:return
/self->spec/
{ 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 : http://wikis.sun.com/display/DTrace/Documentation

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 :

    http://www.youtube.com/watch?v=6chLw2aodYQ
Translate in English

vendredi mai 21, 2010

Virtualisation : restitution du groupe de travail du CRIP

Translate in English

Avant-hier ce tenait le retour du groupe de travail du CRIP sur la virtualisation. PSA, Orange, Generali et Casino ont témoigné de leurs retours d'expériences et des orientations qu'ils étaient en train de prendre sur leurs futures évolutions. Le focus était sur la mise en oeuvre des technologies d'hyperviseurs et des différents choix possible d'implémentations : mono ou multi-hyperviseurs, avec chacun ses avantages et inconvénients.

Entre une approche unifiée, comme Orange, avec une équipe dédiée sur un hyperviseur pour supporter des environnements hétérogènes.

Et une approche comme celle de PSA, intégrée par environnement, sans équipe dédiée, et où l'expertise est liée à l'équipe système (Solaris, Linux, Windows) et associée à l'offre du fournisseur correspondante pour assurer le support de bout en bout.

Des gains évidents qui poussent vers une virtualisation globale

Dans tous les cas, tout le monde s'accorde sur les avantages recherchés par la mise en oeuvre de la virtualisation des serveurs (voir également un précédent billet sur le sujet) :

  • consolidation des serveurs avec le corollaire sur les économies énergétiques,
  • gestion de l'obsolescence des serveurs et des applications comme par exemple, chez Sun, avec le support des Containers Solaris 8 et Solaris 9 sur des serveurs récents en Solaris 10,
  • plus d'agilité et de réactivité de part la fourniture et le déplacement des environnements virtuels de façon beaucoup plus aisé que des serveurs physiques

Toutefois, la majorité des entreprises semblent être à un taux de virtualisation de 25%, là où la technologie disponible aujourd'hui devrait les amener vers un taux plus proche de 70%. Ceci est due à une phase d'adoption et à l'évolution de maturité des hyperviseurs où tout n'était pas forcément éligible lors du démarrage des premiers projets de virtualisation. 

Aujourd'hui, tout est virtualisable et virtualisé, avec plus ou moins de précaution en fonction de l'environnement. Ainsi, pour Solaris, comme certains des témoignages le précisaient, c'est la virtualisation "les yeux fermés". En effet, le modèle des Containers Solaris, s'affranchit de la couche d'hyperviseur et offre une capacité (pratiquement) sans limite de l'utilisation des ressources de la machine (pas de limite en nombre de CPU, taille mémoire et I/O) et multi-plate-formes (SPARC et x64). Par contre, impossible d'y faire tourner un OS windows ou Linux (sauf exception). C'est pourquoi, c'est une stratégie qui est complémentaire à un modèle d'hyperviseurs, et que nous appliquons en pratique chez nos clients, aussi bien sur architecture SPARC (en complément des domaines physiques et d'Oracle VM pour SPARC, hyperviseur matériel) qu' x86/x64, avec notamment l'arrivée du support de Solaris comme Guest dans Oracle VM pour x86, hyperviseur basé sur la souche opensource Xen, et supportant déjà les Guest Linux et Windows (1).

Une communication avec un modèle économique : un facteur clés de succès

Il est clair, qu'une communication importante est nécessaire pour déployer un projet de virtualisation dans l'entreprise et qu'un modèle économique attrayant pour les métiers est indispensable.

Bien prendre en compte l'ensemble des coûts et garder la maîtrise

Il faut également prendre en compte l'ensemble des coûts opérationnels. En effet, l'introduction de la couche de virtualisation nécessite d'être prise en charge. Et il ne faut pas oublier que si les gains sont réels, la maîtrise de la prolifération des environnements virtuels doit être contrôlée pour ne pas avoir un effet négatif sur le ROI (et les SLA). Car ces derniers restent à administrer (patches, mise à jours,...). C'est d'ailleurs pourquoi, des entreprises comme Casino valorisent également une approche de virtualisation de plus haut niveau, comme par exemple la consolidation de plusieurs bases de données ou serveurs d'applications sur une même instance d'OS. Stratégie parfaitement compatible avec le cloisonnement offert par les Containers de Solaris reposant sur une même souche OS.

(1) Note : Sachez également que le support de Solaris, OpenSolaris, Oracle Enterprise Linux et Oracle VM est inclus dans le coût du support matériel des serveurs Sun.

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

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 spec.org 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 : http://guses.org/home/divers/inscription.

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

Translate in English

mercredi déc. 09, 2009

Etat des lieux du Cloud en France

Translate in English

Mardi dernier a eu lieu à Paris la 3ième édition du CloudStorm (après Bruxelles et Londres). Evénement destiné à présenter les solutions existantes aujourd'hui dans le Cloud Computing. Une occasion à ne pas manquer pour faire un état des lieux, 6 mois après le Cloud Camp de Paris.

Dans ce mouvement de remise en cause des modèles informatiques, il est clair que les solutions SaaS sont  maintenant bien présentes et matures, notamment pour ce qui est des offres d'outils de collaboration en ligne.

La problématique d'intégration reste toutefois une question fondamentale entre les applications SaaS (Software as a Service) et les applications internes de l'Entreprise, et a fortiori sur l'infrastructure supportant les services SaaS. Les critères de scalabilité qui s'appliquent aux SaaS, doivent s'appliquer à l'infrastructure qui les supporte.

De fait, des offres d'IaaS (Infrastructure as a Service) arrivent sur le marché. Elles permettent de résoudre entre autres la problématique d'intégration évoquée précédemment, en fournissant de blocs de construction incluant serveurs, stockages et réseaux, et l'outillage de management du Cloud. Une solution intégrée et intégrable dans un Datacenter existant.
C'est ce qu'a exposé la société Cloudsphere, en présentant la refonte de leur business de hosting vers une infrastructure hybride co-localisée.

Clouds public, privés, globaux, locaux ?

Même si les acteurs du Cloud Computing tels que Amazon et Google présentent un service globalisé, nous voyons également chez Sun une tendance vers une localisation des Clouds publics et privés. Et cela pour des raisons très pragmatiques et même légales.

Comme l'évoquait Patrick Crasson, Strategic Business Developer pour Sun et Business Angel, lors de son intervention: bien que "dans les nuages", les données sont malgré tout localisées dans un pays qui a sa législation propre et pas toujours en adéquation avec la vôtre. Cela peut vite devenir contraignant, voire rédhibitoire si vous êtes une administration et que le service soit destiné à stocker des données des citoyens.
C'est pour les mêmes raisons que les institutions financières étudient la faisabilité de mise en oeuvre de clouds privés, afin de garder un contrôle total sur leurs données.

La proposition de Cloudsphere permet à la fois de bénéficier des intérêts du Cloud Computing, en valorisant une architecture partagée pour soutenir des pics de charge,  tout en permettant de garder une connexion vers un système privé, dédié et co-localisé (un modèle hybride co-localisé). C'est une réponse intéressante face aux problèmes de sécurité, hébergement des données, bande passante et points d'accès réseau.
Le modèle hybride co-localisé répond donc aux 2 champs de contraintes évoqués:

  1. simplifier l'intégration,
  2. permettre aux entreprises de bénéficier des avantages du Cloud Computing sans avoir à subir ses inconvénients.

Et vous vous en doutez surement, tout cela étant basé sur de la technologie Sun, de l'infrastructure jusqu'à la brique de virtualization: VirtualBox.

Ce modèle est évidement applicable directement au sein de votre entreprise pour créer un Cloud Privé d'Infrastructure as a Service fournissant une solution "élastique" et permettant à l'informatique d'offrir de la flexibilité et de la réactivité accrue, en complément de votre existant.

Par ailleurs, il ne faut pas penser qu'ajouter une couche de virtualisation à votre infrastructure suffira à la transformer en Cloud
et la rendre "élastique". Il suffit pour cela de regarder les grands acteurs du Cloud comme Google, et vous constaterez que tout a été conçu de bout en bout en mode intégré et spécifique (voir GoogleFS, jusqu'à l'optimisation des couches d'inter-connexion réseaux [3.2 Data Flow]).

L'apport de Sun provient à la fois des technologies et de l'expérience acquises dans la fourniture de puissance informatique à la demande. Nous en sommes à la 5ième génération des blocs d'infrastructures extensibles ou "POD" (Point of Delivery). Et nous avons donc appris à les optimiser dans un modèle industriel, répétable et intégré (y compris avec les solutions logicielles, comme VirtualBox, OpenStorage ou VDI).

Si je peux me permettre une analogie, le POD est au Cloud ce qu'Exadata est à la base de données.

C'est pourquoi de grands acteurs comme AT&T nous ont fait confiance pour construire leur propre service de Cloud Public ou pour mettre en place des solutions de Desktop as a Service.

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

jeudi déc. 03, 2009

Run Best on Sun

Translate in English

Voici en quelques mots la synthèse des annonces faites pendant l'Oracle Open World qui s'est déroulé au mois d'octobre à San Fransisco.

Le lancement début septembre de la solution Sun/Oracle, Exadata V2, n'était qu'un avant-goût des premiers résultats d'une collaboration renforcée entre Sun et Oracle, nos équipes ayant en effet travaillé en  partenariat pour tirer le meilleur des produits Oracle sur plate-formes Sun. Il suffit pour cela de se référer à quelques benchmarks de référence, couvrant du transactionnel à la paie, en passant par l'ERP avec SAP (sur base Oracle). Je vous laisse consulter les résultats détaillés dans les pointeurs ci-joints, surtout si vous avez déjà une de ces applications déployées chez vous ou si vous l'envisagez :

J'ai attendu un peu avant de publier ce billet, car un bon nombre de ces benchmarks reposent sur la version Oracle 11gR2... Et cette version est disponible sur Solaris depuis la semaine dernière, vous pouvez d'ailleurs la télécharger ici. Ceci est vrai pour l'ensemble des plate-formes Solaris : SPARC et x86/x64 !

Au delà de ces benchmarks, l'intérêt est de voir ce qui peut être directement applicable pour vous. Au travers notamment des technologies matérielles et logicielles employées et intégrées pour mieux tirer partie de l'ensemble. J'attire particulièrement votre attention sur une nouvelle option d'Oracle 11gR2 qui permet d'utiliser les disques SSD "à la" mode ZFS : DB Flash Cache, et d'obtenir des gains de performances déjà démontrés jusqu'à x4.

Vous pouvez dès à présent en bénéficier, grâce aux différentes technologies Flash que nous offrons, dont le Sun Storage F5100 qui fournit 1,9To sur 1U, consomme 300 watts et délivre plus de 1 Millions d'IOPS. Essayez d'y mettre vos indexes de bases de données et tenez moi au courant...

Vous pouvez également intégrer des disques SSD dans nos serveurs et du cache Flash sur le bus PCIe avec la carte F20 (qui équipe les éléments de stockage de la solution Exadata v2).

Translate in English

mardi déc. 01, 2009

Un centre de calcul plus "vert" : Green Grid HPC

Translate in English

A une semaine  de la conférence sur le climat de Copenhague, voici une petite note sur l'impacte de l'informatique, et quelques éléments sur ce que nous faisons pour contrôler la consommation d'énergie dans ce secteur.

L'informatique et la consommation d'énergie

Comme vous le savez surement déjà, l'informatique est un consommateur important d'énergie, au même niveau que l'industrie aéronautique. Sun s'est engagé depuis de nombreuses années déjà vers une informatique plus verte, que nous déclinons dans nos technologies (processeurs CMT, disques Flash,...) et notre savoir faire (Sun Modular Datacenter 20, par exemple). Et que nous appliquons à nous même : nous avons atteint cette année l'objectif de réduction de plus de 20% de gaz carbonique de nos propres centres informatique, objectif que nous nous étions fixé pour 2012 ! Bien entendu, nous avons relevé la barre avec une nouvelle cible de réduction de 20% à 2015 par rapport à notre taux d'émission de 2007.

L'enjeu des grilles de calcul Sun HPC Constellation system

Or, dans l'informatique, il y a un secteur qui consomme généralement plus que les autres : le calcul intensif ou scientifique. Même si c'est souvent pour le bien de la planète (calcul du climat, simulation numérique en lieu et place de tests grandeurs réels -encore plus consommateurs en énergie-), il est critique de pouvoir rendre ces centres de calculs plus économes, également pour des raisons très pragmatiques concernant les installations à mettre en oeuvre face aux besoins.

Les innovations de Sun pour y répondre 

Chez Sun nous avons non seulement optimisé la mise en oeuvre de grilles de calcul par un design intégré et innovant. Ce savoir faire technologique permet notamment de minimiser le besoin en équipements et câblage réseau d'un facteur 6 à 300 !, grâce à notre technologie infiniband couplée à nos serveurs (intégrée également dans l'offre annoncée récemment Sun Oracle Database Machine v2). Mais aussi sur le design du Datacenter proprement dit, comme le "Free Cooling"...

La preuve par l'exemple

La combinaison de ces innovations vient d'intégrer le Top 10 des centres de calcul mondiaux chez CLUMEQ, au Canada. Je vous laisse en découvrir les détails dans cette petite vidéo. Et si vous vous posez des questions sur la possibilité d'implémenter cette solution, le consortium Green Grid fournit une carte des possibilités de mise en oeuvre du "Free Cooling" en Europe. Nous pouvons vous accompagner comme nous l'avons fait pour le projet européen Juelich supercomputing center.

Translate in English

mercredi oct. 21, 2009

7ième Conférence ITSMF : passez à l'offensive !

Translate in English

J'ai pu assister hier à la conférence ITSMF annuelle. Grand rendez-vous des DSI et responsables de production de France, maintenant qu'ITIL est vraiment la référence en production et un standard au travers de l'ISO 20000-1.

La crise était très présente, toutefois, Jean-Pierre Corniou\* invite les DSI à passer à l'offensive en s'appuyant sur des messages forts que nous connaissons bien chez Sun depuis des années : le monde devient connecté, "anywhere, anytime, any device". Nous passons d'un modèle utilisateur/machine à un modèle machine2machine, temps réel et mobile. Illustré déjà par 4,6 Milliards d'abonnés mobiles et plus de 1,7 Milliards (26% population monde) connectés à internet . Or l'IT devient de plus en plus prépondérante pour pouvoir gérer un monde dominé par l'information et où notre capacité à  l'exploiter et l'analyser devient critique pour rester compétitif. C'est pourquoi, Jean-Pierre conclut sur l'importance pour les dirigeants d'investir dans "La continuité numérique de l'éco-mobilité"\*. En sachant lier la stratégie de l'entreprise avec les apports business de l'IT par la maîtrise qu'elle peut apporter de l'information "temps réel".

Ensuite, Jean-Paul Amoros - Vice-président du CRIP nous a présenté le succès de l'alignement de l'IT avec la stratégie de l'entreprise, par son retour d'expérience de 3 ans chez Générali. Et comment, le développement d'une intimité avec les métiers et la mise en place d'indicateurs représentatifs pour eux, le différencie en temps que production interne d'un "simple" out-sourcer gérant des SLA (IT).

Pour conclure les sessions plénières, Pierre Thory nous a présenté un état des lieux de la norme ISO 20000-1 (tirée d'ITILv2) et des travaux internationaux associés. Où il faut notamment rester vigilant sur l'implication d'autres pays poussant leurs propres standard autour des SOA et bientôt du Cloud Computing.

Côté témoignages utilisateurs, Ludovic Lacote, responsable de la production d'ACCOR, a présenté comment ils avaient mis en oeuvre un système de gestion financière des services IT, permettant

  1. de stopper la rumeur "l'informatique coûte cher",
  2. de valoriser les besoins et l'apport de l'informatique aux métiers !

Si ce processus ITIL est vu comme optionnel, il est clairement obligatoire chez ACCOR.

La Gendarmerie Nationale, avec Régis Martin et Philippe Bouchet, a présenté comment ils avaient industrialisé leur production en passant à ITIL et cela de façon rapide avec l'aide de Sun et de Cap. Une autre expérience intéressante de l'adoption d'ITIL par les collaborateurs a été développée par Robert Demory, de La Poste Courrier, avec une démarche centrée sur l'appropriation et la réalisation en interne.

Pour finir, j'ai également assisté à la présentation de Xavier Rambaud, DSI de Rhodia, qui a mis en oeuvre une solution permettant de remonter des indicateurs de qualité de service vue de l'utilisateur final. Très intéressant pour dialoguer avec les utilisateurs à partir d'éléments factuels mais aussi pour valider ce qui marche, les tendances et les impacts sur un changement.

En tout cas, comme vous pouvez le voir une journée très enrichissante, chargée de messages et de savoirs faire dans l'ADN de Sun !

\*"la continuité numérique de l'éco-mobilité": Jean-Pierre Corniou, Président de l'Instance de coordination du programme TIC PME 2010, à voulue illustrer ainsi la convergence entre la révolution numérique en y associant la mobilité non seulement de l'information, mais également des objets et des personnes et l'éco-responsabilité, enjeu majeur pour l'avenir de tous.

Translate in English

mercredi sept. 30, 2009

Sun @Oracle Open World

Translate in English

Je pense que ce n'est pas une surprise pour vous si Sun est massivement présent à Oracle Open World qui va se dérouler du 11 au 15 octobre à San Fransisco. Pour ceux qui auront l'opportunité d'y aller, ne manquez pas les sessions que nous présenterons et dont vous trouverez le tableau de synthèse ici.

Pour plus de détails sur les sessions autour de Solaris notamment, je vous invite à consulter la page suivante : http://www.sun.com/software/solaris/oow/ qui contient un aperçu des sessions et des démonstrations disponibles.

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 : http://milek.blogspot.com/2008/02/2530-array-and-zfs.html
    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
    http://blogs.sun.com/roch/entry/tuning_zfs_recordsize

  • 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

samedi juil. 11, 2009

Table ronde à l'ITIForum : retour sur disques SSD et stockage x86

Translate in English

C'est avec un petit décalage de 15 jours que je reviens sur la table ronde disques SSD et stockage x86, organisée par Jean-Pierre Dumoulin, lors du dernier ITIForum du CRIP. Je reprends également ce billet en français, ce qui est préférable, à la vue du résultat de la dernière traduction électronique de l'anglais vers le français ! Je vous en laisse juge en cliquant ici.

Lors de cette table ronde, les membres du CRIP, nous avaient posé 2 questions, à mes confrères fournisseurs de stockage, ainsi qu'à quelques utilisateurs : François Dessables de PSA, Christian Jaubert de Bouygues Télécom et Jacques-Alain Barret de Manpower.
2 questions sur lesquelles je vais tenter de vous faire un bref résumé.

1) Utilisation des disques SSD ( Flash ) , quels enjeux pour l'industrie, pourquoi l'adoption est-elle plus lente en France ?

Globalement un consensus s'est dégagé sur cette question. Les SSD sont une tendance de fond qui se retrouve petit à petit dans l'ensemble des offres. Sachant qu'il faut bien distinguer les disques SSD d'entreprise de ceux utilisés pour le grand public.

Toutefois, 2 stratégies de mises en oeuvre apparaissent. Une stratégie classique, qui consiste à intégrer les disques SSD au sein des baies existantes, l'autre, celle de Sun notamment, qui s'appuie sur les disques SSD pour accélérer les I/O de manière transparentes aux applications et aux administrateurs.

Dans le cas des disques SSD au sein des baies de stockages, il est nécessaire de définir quelles seront les données qui en bénéficieront, tout un travail en perspective. Car vous n'allez pas remplir une baie avec un ensemble complet de disques SSD (pour ne pas avoir à vous poser cette question) pour 2 raisons : le coût, la capacité des contrôleurs des baies actuelles, qui de toute façon ne pourraient pas tenir les IOPS potentielles. Naturellement, Sun disposant de baies de stockage de ce type, nous sommes capable de répondre à ce besoin pour certains cas d'usages adaptés. Ce besoin de réfléchir au placement des données et à sa pertinence, c'est peut-être une des raisons qui explique l'adoption lente en France -outre le fait que tous les acteurs du stockage n'en disposent pas...

L'autre axe de développement sur lequel Sun investit et délivre des solutions déjà disponibles aujourd'hui, c'est l'OpenStorage, commercialement connus sous les gammes x45xx et 7000. J'ai déjà produit un billet sur cette « révolution ». En 2 mots, nous rapprochons les disques SSD au plus prêt des processeurs, au sein des serveurs, et nous nous en servons également comme (très très gros) cache secondaire dans nos « baies » OpenStorage. Ainsi, toutes les applications en bénéficient de facto. Je vous invite à consulter ce blog pour quelques chiffres de performance en stockage de type NAS.

Maintenant, pour en faciliter l'adoption, l'enjeux pour les industriels, dans les 2 stratégies, est de fournir les guides de mises en oeuvre en fonction des usages. Ce que nous faisons bien évidement... Si vous souhaiter déployer, par exemple, vos bases Oracle sur Sun Storage 7000, je vous engage notamment à lire ce Blueprint. Et si vous avez un doute, n'hésitez pas à nous consulter, nous pourrons vous guider !

Pour plus d'information sur les disques SSD (technologies) et la démarche d'intégration, je vous renvoie à cet article d'Adam Leventhal : "Can flash memory become the foundation for a new tier in the storage hierarchy?", ainsi qu'à son blog.

Maintenant passons à la deuxième question de cette table ronde...

2) L'émergence des offres de stockage sur base X86 ( à l'image de ce qu'utilisent les grands acteurs du web, Google, Amazon, ... ) , quelle utilisation pour l'industrie, est-ce une opportunité de réduire les coûts dans le contexte de crise actuel ?

Pour répondre à cette dernière, je vais être beaucoup plus synthétique en vous invitant à (re)lire : "Openstorage: La révolution dans la gestion des données", déjà cité précédemment.

Je compléterais juste par le fait qu'au-delà du HPC (voir: Solving the HPC I/O bottleneck - Sun Lustre Storage System) et des stockages en grilles, les utilisations pour l'industrie que je vois dès aujourd'hui sur certains projets auxquels je participe se situent principalement dans le stockage d'environnement virtualisés type VMWare ainsi que les environnements de bases de données en développement et intégration. En effet, les solutions de stockage x86 offrent une réelle opportunité de réduire les coûts. D'autres cas d'usages existent et quelques uns sont résumés dans l'image ci-contre.clic to enlarge

Comme pour les disques SSD, le stockage x86 est une tendance de fond (voir: Data Trends... Driving Storage (radical) Evolution), avec la performance des processeurs actuels et les solutions logiciels complètes disponibles comme la stack OpenStorage d'OpenSolaris. Nous sommes au début de la standardisation de l'offre de stockage avec :

  • abandon des solutions propriétaires,
  • adoption de solution standards à base de x86 et des logiciels open source associés,
  • s'appuyant sur des technologies innovantes (SSD, ZFS,...)

Donc, fort potentiel de gain en performances et en coûts. C'est sur ce constat qu'il y a bientôt un an, Sun a fédéré ses ingénieries serveurs et stockages. Nos serveurs x86 (incluant les disques SSD) devenant le composant de base pour construire nos solutions de stockage x45xx et Sun Storage 7000, en y ajoutant l'intelligence avec OpenSolaris et toutes ses fonctions OpenStorage (snapshot, réplications, « de-duplication » à la mode ZFS...).

Translate in English

About

Eric Bezille

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today