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

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

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