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

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

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

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 :

18h30
Accueil
19h00

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

19h10
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

20h20

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

21h00

Networking

 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

mardi févr. 17, 2009

OpenSolaris et Intel Xeon Processor Nehalem

Translate in English

Lorsque nous mettons en place un partenariat, comme dans le cas d'Intel, ce n'est pas pour être un simple revendeur, mais bien pour innover ensemble, et apporter le meilleur des 2 sociétés à  nos clients.
A ce titre, je vous ai déjà parlé de l'ingénierie optimisée de nos systèmes x86/x64, mais notre collaboration va bien au-delà... Solaris (et OpenSolaris) est une des raisons majeures de l'accord de partenariat qui nous lie avec Intel. De part sa stabilité et sa capacité à exploiter des systèmes multiprocesseurs et multi-coeurs, Solaris dispose de fonctions avancées... Fonctions qu'Intel intègre à sa nouvelle architecture multi-coeur, Nehalem  pour :


  • exploiter un grand nombre de Threads, grâce au "Dispatcher" optimisé de Solaris
  • tirer partie des architectures NUMA, avec la fonction "Memory Placement Optimization" (MPO)
  • gérer la consommation d'énergie, au travers du projet TESLA
  • optimiser les performances des machines virtuelles en collaborant dans le projet de Virtualization xVM Server
  • intégrer les nouveaux jeux d'instructions dans les outils Solaris (Studio, ...) pour tirer partie des nouvelles fonctions matérielles du processeur (XML instruction, loop CPC, counters...)

(note: ce n'est pas moi sur la vidéo, mais David Stewart, Software Engineering Manager d'Intel) 

Toutes ces intégrations sont disponibles dans les distributions OpenSolaris2008.11 et  Solaris 10 Update 6.

A cela s'ajoute également l'optimisation des couches logicielles pour les architectures mutli-coeurs.
Sun fournit des logiciels opensource recompilés pour ces architectures, au travers des distributions CoolStack.
Ces logiciels sont disponibles sur architectures x86/x64, mais également SPARC. Car il ne faut pas l'oublier, Sun a toujours une avance importante sur les technologies mutli-coeurs. Nous avons lancé dès 2005 un processeur SPARC CMT (CMT pour Chip Multi-Threading) 8 coeurs, avec 4 threads par coeur, soit 32 threads matériels d'exécution. Ceci a posé un certain nombre d'enjeux au niveau du système d'exploitation. Enjeux qui permettent aujourd'hui à Solaris d'exceller sur ce type d'architectures. Nous sommes aujourd'hui à la 3ième génération de ce processeur (eh oui, une par an, pas mal pour le monde des processeurs), qui supporte 8 coeurs, 8 threads par coeur et des systèmes jusqu'à 4 processeurs (256 threads d'exécutions matériels !).

Maintenant, la question que nous avons souvent : quand utiliser x86/x64 et quand utiliser le processeur SPARC CMT massivement multi-coeurs/multi-threads ?

De façon synthétique, l'architecture x86/x64 est aujourd'hui plus généraliste, et est à privilégier dans les cas où l'application n'est pas mullti-thread, et où la performance d'un thread ainsi que le temps de réponse associé est le facteur important, en bref, clé pour le HPC.

A contrario, le SPARC CMT est vraiment spécialisé pour :

  • les applications fortement multi-threads (Java en fait partie bien sûr, ce qui rend éligible un nombre important d'applications)
  • la prédictibilité du comportement (même sur très fortes charges transactionnelles) : pas de surprise !
  • la consommation électrique optimisée (fréquence moins élevée = moins de dissipation calorifique)
  • le MTBF élevé, de part une intégration importante de fonctions au niveau du processeur (gestionnaire mémoire, I/O, réseau et de cryptographie !)
Un point à ne pas négliger non plus : la configuration et le paramétrage des logiciels dans un environnement multi-coeur change !
Il faut penser différemment et parfois même revoir son paramétrage applicatif à l'inverse des habitudes. Tuning JVM pour mutli-cores : GC ! , pool thread java...!

Donc si vous souhaitez tirer partie au mieux des nouvelles architectures multi-coeurs :
  1. sélectionnez le matériel par rapport à vos besoins : x86/x64 ou SPARC CMT
  2. utilisez le bon OS : Solaris ou OpenSolaris
  3. utilisez la bonne stack logiciel
  4. utilisez les bons paramètres
  5. et obtenez le meilleur meilleur ratio prix/performance/watt/m²

Note : je n'ai pas évoqué ici les systèmes "high-end", SPARC64, car dans une autre classe de serveurs que ceux de type x86/x64 et SPARC CMT. Toutefois, ces systèmes ont un rôle à jouer dans des environnements nécessitant des besoins de croissance applicative verticale (SMP, pour Symetric Multi-Processing), beaucoup d'entrées/sorties et avec un niveau de criticité élevé (car ils disposent notamment de fonctions d'intervention à chaud).

Translate in English

About

Eric Bezille

Search

Archives
« septembre 2015
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