Conclusion

en consolidant
au niveau plus granulaire. Les
clients pourraient initialement placer
les applications base de données dans
des partitions séparées, par exemple,
pour éviter les conflits dûs aux noms
de bibliothèques en double. Ensuite,
une fois que tout aura été consolidé
sur une machine, ils pourront mettre
en oeuvre des pools de stockage auxiliaires
indépendants pour permettre
aux bases de données de résider dans
une partition sur une couche unique
de l’application.
Cela ne signifie pas que les iASP
remplaceront les partitions séparées. Il
est vrai que les clients commencent à 
les utiliser pour la consolidation et
qu’ils le feront probablement davantage
au fur et à  mesure que la technologie
s’améliorera. Mais, d’après
VanBenschoten, ces clients gardent les
LPAR pour des applications qui nécessitent
la protection pare-feu, qui bénéficient
du mouvement dynamique des
ressources, ou qui fonctionnent dans
un environnement d’exploitation différent
». Je ne pense pas que l’un remplace
l’autre », déclare-t-il. « Il y a de
bonnes raisons économiques d’utiliser
chacun d’eux ».
On voit donc que le partitionnement
logique devrait voir son champ
se rétrécir au fur et à  mesure que les
clients comprendront mieux son
potentiel et que de nouvelles technologies
émergeront. Mais, en même
temps, le déploiement de LPAR
augmentera dans d’autres contextes :
les grands comptes continuent à  appliquer
des stratégies de consolidation de
masse et les sites plus petits commencent
à  jouer avec Linux.
« LPAR a gagné beaucoup de terrain
et, avec le nouveau Power5, attendezvous
à  plus », déclare Kimball. « Je ne
serais pas étonné de voir chaque boîte
unique installée avec des partitions
multiples. Ce sera la culture du futur ».