V12N
    avec Xen et IBM BladeCenter

●   Cas d'étude :
    Plateforme d'hébergement Plone/Zope

●   Pourquoi Xen ?

●   P...
Contexte

●   10 à 100 serveurs physiques

● Configurations matérielles disparates
● Configurations logicielles disparates...
Xen – aspects techniques

●   Hyperviseur en version 3.2
    (packaging Debian/Ubuntu)

●   Noyaux :
     ● dom0 – léger l...
Pourquoi Xen ?
            Raisons objectives
●   Besoin de performances
      Exclut les solutions full HVM
      (qemu, ...
Pourquoi Xen ?
           Raisons subjectives

●   Forte culture Debian GNU/Linux

●   Utilisation d'outils standard
     ...
Pourquoi Xen ?
       Raisons économiques

Open Source réel :
   La version libre est fonctionnelle
   Nombreux contribute...
Le futur de Xen

●   Hyperviseur 3.3 déjà disponible
    (améliorations sur le HVM, la migration ...)

●   Xen 4/3.4 : min...
IBM BladeCenter :
            aspects techniques
●   Châssis 7U / 14 lames

●   Double connectivité gigabit par lame

●   ...
IBM BladeCenter :
               mise en œuvre

podp : Power-On-Demand Platform

●   Démarrage avec 2 lames

●   Ajout de ...
IBM BladeCenter :
                avantages

●   Intégration des éléments vitaux :
     ● console déportée,

     ● switch...
IBM BladeCenter :
         intégration et évolution

●   Un chassis BladeCenter
    = une machine (presque) comme les autr...
Résultats
●   Infrastructure matérielle plus saine
     ● Virtualisation des machines obsolètes

     ● Réutilisation des ...
Conclusions

●   Xen : une brique logicielle de virtualisation,
    riche en fonctionalités, puissante, ...
    Et toutefo...
Prochain SlideShare
Chargement dans…5
×

V12N avec Xen et IBM BladeCenter

1 191 vues

Publié le

Présentation de Pilot Systems lors de la réunion du Guide Share du 1 octobre 2008

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 191
Sur SlideShare
0
Issues des intégrations
0
Intégrations
96
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

V12N avec Xen et IBM BladeCenter

  1. 1. V12N avec Xen et IBM BladeCenter ● Cas d'étude : Plateforme d'hébergement Plone/Zope ● Pourquoi Xen ? ● Pourquoi BladeCenter ? ● Conclusions
  2. 2. Contexte ● 10 à 100 serveurs physiques ● Configurations matérielles disparates ● Configurations logicielles disparates ● Besoin de performances ... mais bottleneck non identifié ● CPU ? ● RAM ? ● I/O ?
  3. 3. Xen – aspects techniques ● Hyperviseur en version 3.2 (packaging Debian/Ubuntu) ● Noyaux : ● dom0 – léger lag, mais bon support hw ● domU – peut utiliser le kernel mainstream ● Performances : ● disque : natif ● CPU/mémoire : 90 à 98% natif ● réseau : limitations (relatives)
  4. 4. Pourquoi Xen ? Raisons objectives ● Besoin de performances Exclut les solutions full HVM (qemu, kqemu, parallels, VMWare ...) ● Sécurité et isolation Exclut les solutions à namespace (Virtuozzo, OpenVZ, VServer ...) ● Utilisation d'outils Open Source Pour créer des outils in-house (Scripts de déploiement, supervision ...)
  5. 5. Pourquoi Xen ? Raisons subjectives ● Forte culture Debian GNU/Linux ● Utilisation d'outils standard Interconnexion réseau : bridges Configuration : flatfiles en Python Disques : gérés par le dom0 ou le domU (DRBD, AOE, iSCSI, device-mapper, LVM, softraid, ...)
  6. 6. Pourquoi Xen ? Raisons économiques Open Source réel : La version libre est fonctionnelle Nombreux contributeurs (individus + entreprises) Segmentation (presque) claire entre - les versions gratuites (Shell!) - les versions payantes (IHM!) Pouvoir passer de smallscale à largescale ... sans remettre en question le socle
  7. 7. Le futur de Xen ● Hyperviseur 3.3 déjà disponible (améliorations sur le HVM, la migration ...) ● Xen 4/3.4 : mini-domaines spécialisés I/O (devrait lever les limitations évoquées) ● En revanche ... ... Adoption mitigée par les distributions ● Fusion avec KVM ?
  8. 8. IBM BladeCenter : aspects techniques ● Châssis 7U / 14 lames ● Double connectivité gigabit par lame ● Gestion des lames et des switches via l'AMM (Advanced Management Module) Prise de contrôle (clavier+écran) à distance ● Chaque lame embarque ● 2 CPU quad-core ● 24 Go de RAM ● 2 disques 2 pouces
  9. 9. IBM BladeCenter : mise en œuvre podp : Power-On-Demand Platform ● Démarrage avec 2 lames ● Ajout de lames avec +/- de CPU/RAM ● Disques locaux (si besoins faibles), ou SAN (si besoins plus élevés)
  10. 10. IBM BladeCenter : avantages ● Intégration des éléments vitaux : ● console déportée, ● switches administrables + redondants, ● alimentations administrables + redondantes ● Évolution modulaire (ajout de lames, RAM, CPU, disques) ● Déploiement physique plus simple et rapide
  11. 11. IBM BladeCenter : intégration et évolution ● Un chassis BladeCenter = une machine (presque) comme les autres ● Utiliser la virtualisation comme abstraction ● L'AMM intègre KVM-IP + NPDU, avec une forte valeur ajoutée ● IBM n'est pas seul sur le marché des blades
  12. 12. Résultats ● Infrastructure matérielle plus saine ● Virtualisation des machines obsolètes ● Réutilisation des machines homogènes ● Infrastructure logicielle inchangée ● kernel-image-2.6.24-xen ● Procédures ad hoc de déploiement, migration, sauvegarde, clonage ... ● Deux fois plus de serveurs virtuels, dans deux fois moins de serveurs physiques
  13. 13. Conclusions ● Xen : une brique logicielle de virtualisation, riche en fonctionalités, puissante, ... Et toutefois interchangeable ● IBM BladeCenter : une plateforme matérielle, riche en fonctionalités, puissante, évolutive ... Et toutefois interchangeable (aussi!) ● podp : grâce à Xen et IBM, le « métal » devient un consommable ! (principe du cloud computing)

×