Your SlideShare is downloading. ×
0
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
V12N avec Xen et IBM BladeCenter
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

V12N avec Xen et IBM BladeCenter

904

Published on

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

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
904
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. V12N avec Xen et IBM BladeCenter ● Cas d'étude : Plateforme d'hébergement Plone/Zope ● Pourquoi Xen ? ● Pourquoi BladeCenter ? ● Conclusions
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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)

×