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

Comments:

Très bonne présentation, forte interessante ! Merci

Posted by Sylvain on décembre 16, 2009 at 02:09 PM CET #

Bonsoir Eric,

Une précision sur les motivations du projet:

L'un des moteurs principaux, et même le moteur principal de cette mise en œuvre partait des deux constats suivants :
- La concentration de nombreuses bases de test/uat/développement mutualisées sur des serveurs vieillissants combinée aux tailles importantes de certaines de ces bases rendait impossible le dimensionnement rationnel des ressources. Certaines bases habituellement peu utilisées pouvaient servir à des tests de charge, puis ne plus être utilisées pendant un laps de temps de plusieurs semaines. L'adaptation à ce type de contrainte nécessite une organisation contraignante, une planification créant des dépendances entre les projets et une administration manuelle importante des systèmes et bases de données
- Certains serveurs étaient trop peu puissants et surtout trop différents de la production pour représenter une infrastructure de tests représentative.

Ce type de situation est un cas d'école pour le concept même de virtualisation "share/pool". L'idée était principalement de pouvoir allouer/désallouer dynamiquement des ressources CPU/mémoire à partir d'une ferme de serveurs.

Sans sous estimer les gains de productivité des équipes d'infrastructures, le bénéfice de la virtualisation était surtout attendu sur les possibilités :
- de pouvoir accélérer les mises à disposition ou même tout simplement de répondre aux besoins des projets et des métiers. Les délais de mise à disposition de copies de base de production de plusieurs To sur un serveur donné peuvent être incompatible avec les exigences des projets, par exemple dans le cas de tests de non régression consécutifs à un bug critique de l’application
- de limiter les upgrades à une partie du pool tout en continuant à utiliser les anciens serveurs au lieu d'upgrader un parc entier

Last but not least, la ferme est "scalable" contrairement à des serveurs isolés. Bien qu'elle soit l'un des critères de base du design des infrastructures de production, la notion même de "scalabilité" n'avait jusqu'à la mise en œuvre du projet de virtualisation pas été appliquée aux environnements de tests et d'UAT.

En résumé, les composantes indirectes et non-monétarisées du "ROI" étaient très importantes.

Christian

Posted by Christian Bilien on décembre 16, 2009 at 02:27 PM CET #

Très bon article !
Une suggestion de complément, suite à des discussions sur le potentiel de virtualisation chez Alcatel-Lucent :
- Facilité de mettre en place une configuration : Très utile en phase de test (toutes les configurations possibles)
- Facilité de figer (snapshot) un environnement et de le rétablir à volonté. Très utile en phase de support (se mettre rapidement dans la config du client, ne pas perdre des jours en travail de configuration mais se concentrer rapidement sur le problème). Tests de non-régression aussi bien sûr.

Tout ceci pour dire que la virtualisation ouvre l'horizon à des actions qui sinon seraient en pratique impossibles (cf ci-dessus). Donc mettre en avant les aspects opérationnels (ce que l'on peut faire, facilement et industriellement) et pas uniquement un ROI en Euros (sous-estimé, car basé uniquement sur des économies).

Posted by Hervé Bitteur on décembre 17, 2009 at 12:12 AM CET #

Soirée extremement intéressante (j'y étais).

Ce n'est pas précisé au début, mais vous l'aurez compris, Bruno Philippe travaille pour la "grande banque" et non pas pour Sun. Son témoignage n'en est donc que plus réaliste.
Cette présentation, puis le repas qui a suivi (jusqu'a minuit pour les plus courageux !), ont été l'occasion de multiples échanges et retours d'expérience sur ce sujet de la virtualisation, mais également sur bien d'autres.

A refaire donc !

Posted by Christophe Pauliat on décembre 17, 2009 at 02:11 AM CET #

@Christian (et @Hervé)

Merci pour ces précisions, qui répondent également au commentaire d'Hervé par la même occasion. Ce sont effectivement des points qui ont été abordés lors des échanges. Il est intéressant de voir qu'ils ont été pris en compte dès le départ avec un poids important dans la démarche d'investissement, et qu'ils ont même constitué le facteur de déclencheur du projet au-delà du pure ROI financier, souvent partiel car ayant des difficultés à intégrer l'ensemble des paramètres.

Posted by Eric Bezille on décembre 17, 2009 at 02:52 AM CET #

@Christophe

Bonne remarque. Mise à jour effectuée.

Posted by Eric Bezille on décembre 17, 2009 at 02:58 AM CET #

Eric, merci pour cette excellent article.

Juste pour vous signaler que ce retour d'expérience a été présenté lors de l'annuel ITIForums le 18 juin dernier. Vous trouverez la présentation sur mon blog (Solaris mon amour).

Merci à Eric (et Oracle) pour le sponsoring.

Posted by Bruno PHILIPPE on juillet 01, 2010 at 06:13 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
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