La tendance à la mutualisation des ressources logicielles et matérielles s'accroît, notamment grâce aux évolutions matérielles et aux technologies de virtualisation qui permettent d'optimiser l'utilisation de ces différentes ressources.
Le "Cloud" se dessine et se décline au rythme des annonces marketing, mais devient une réalité dans le paysage de l'IT.
Les environnements ERP, plus qu'ailleurs, sont également impactés, et le monde SAP tout particulièrement.
La virtualisation est un liant « logiciel » entre les couches matérielles et applicatives, c'est le cœur de l'infrastructure. Les technologies de virtualisation sont multiples : cloisonnement hardware, logique, isolation software, virtualisation matérielle, et même para-virtualisation. Les niveaux d'implication sont différents et l'imbrication de certains fonctionnements rendent toutes ces solutions complexes.
La virtualisation de serveurs n'est pas une technologie récente. L'idée simple et un peu folle à l'époque de faire tourner plusieurs machines sur une seule remonte au début des années 70. IBM, en pionnier, dispose déjà au début des années 80 sur ses serveurs mainframe, de solutions permettant de virtualiser ses propres systèmes (PR/SM, VM).
Les 3 principales familles de technologies qui composent le paysage de la virtualisation
Le "Cloud" se dessine et se décline au rythme des annonces marketing, mais devient une réalité dans le paysage de l'IT.
Les environnements ERP, plus qu'ailleurs, sont également impactés, et le monde SAP tout particulièrement.
La virtualisation est un liant « logiciel » entre les couches matérielles et applicatives, c'est le cœur de l'infrastructure. Les technologies de virtualisation sont multiples : cloisonnement hardware, logique, isolation software, virtualisation matérielle, et même para-virtualisation. Les niveaux d'implication sont différents et l'imbrication de certains fonctionnements rendent toutes ces solutions complexes.
La virtualisation de serveurs n'est pas une technologie récente. L'idée simple et un peu folle à l'époque de faire tourner plusieurs machines sur une seule remonte au début des années 70. IBM, en pionnier, dispose déjà au début des années 80 sur ses serveurs mainframe, de solutions permettant de virtualiser ses propres systèmes (PR/SM, VM).
Les 3 principales familles de technologies qui composent le paysage de la virtualisation
L'isolation consiste à isoler les applications au sein d'une « zone » dédiée
On ne peut pas vraiment parler de virtualisation proprement dit, mais cette technique permet de multiplier les instances d'une même application dans un contexte cloisonné, avec des performances proches de l'exécution native. L'environnement ainsi « virtualisé » se retrouve confiné mais pas isolé à 100% du système hôte, notamment au niveau des ressources physiques (et du noyau).
SUN dispose, par exemple, sur son système Solaris de ce type de technologies - SUN Zone / Containers.
Les isolateurs sont principalement réservés aux serveurs Linux et sont fortement utilisés pour l'isolation de serveurs LAMP par les fournisseurs de serveurs Web.
La Full Virtualisation permet de simuler une architecture matérielle complète afin d'héberger un OS non modifié
Les performances ne sont pas toujours au rendez vous puisque la couche d'accès au matériel est intégralement simulée.
La para-virtualisation permet au système d'exploitation virtualisé d'accéder aux ressources matérielles, via une couche logicielle dédiée à cet effet
C'est l'Hyperviseur (KVM, VMWARE, XEN) qui virtualise les ressources et dialogue avec les pilotes des machines virtuelles.
Ajoutons à cela le support de la virtualisation au niveau des processeurs, et nos machines hôtes se retrouvent alors capables d'adresser directement leurs propres blocs mémoires, tout en préservant la stabilité de l'hyperviseur. Les performances deviennent alors redoutables au fur et à mesure que les goulets d'étranglements s'amenuisent. Nous approchons désormais des performances natives.
Les performances SAP atteignent 95 % des performances natives
Depuis, fin 2010, SAP supporte les installations sur des serveurs virtualisés à l'aide de Xen Server de Citrix. La para-virtualisation de Xen Server permet un overhead de moins de 5% ([I]). L'overhead représente le coût de la virtualisation par rapport à des performances natives.
KVM, l'hyperviseur intégré par RHEV (Red Hat Enterprise Virtualization) également supporté par SAP, baisse la barre pour atteindre 1% ([II]).
De plus, la croissance des performances en fonction des machines virtuelles est linéaire. Autrement dit, les performances obtenues avec une machine virtuelle de 2vCPU, seront doublées avec une deuxième machine virtuelle de 2vCPU ([III]).
Depuis 2010, Red Hat a misé sur l'hyperviseur KVM (abandonnant alors XEN), nativement intégré au noyau Linux. Il obtient alors haut la main, les meilleurs benchmark SPECvirt sur une architecture Intel Xeon.
Les promesses de l'éditeur ne s'arrêtent pas là. La version 3 de RHEV attendue dans l'année, fait tomber les barrières : un hyperviseur pourra gérer jusqu'à 2000 machines virtuelles, 64 TB de RAM et 64 vCPU par machine virtuelle !
Ces « nouvelles » technologies d'infrastructure, notamment avec les hyperviseurs, bousculent l'IT et le monde classique de l'Operating System et permettent de rationnaliser les licences et l'utilisation des ressources.
Nos systèmes d'information gagnent en agilité et en flexibilité
Un nouveau bac à sable pour un projet devient presque simple à mettre place. Les investissements matériels sont faibles, voire nuls, ce qui accélère encore la mise en production.
Le socle matériel s'est également adapté, et jusqu'au milieu des années 2000, les technologies développées pour les serveurs d'entreprises gardaient plusieurs longueurs d'avance comparativement aux technologies grand public.
Les plateformes multiprocesseurs intégrant la gestion du cloisonnement et de la virtualisation étaient réservées aux grandes entreprises et aux environnements critiques tels que les ERP.
Depuis les mainframes IBM, dont les ressources étaient pilotées par les premiers hyperviseurs VM/CMS, en passant par les serveurs Unix propriétaires IBM, HP ou SUN, les installations SAP se cantonnaient à utiliser les technologies propriétaires qui n'avaient d??? « Open » que le nom.
Pendant de longues années c'était la seule possibilité de dépasser quelques milliers de SAPS ([IV]) et quelques giga de mémoire RAM. La faible puissance des processeurs de l'époque était compensée par l'agrégation de plusieurs dizaines d'entre eux dans des partitions physiques ou virtuelles. Les faibles débits des systèmes de gestion des disques étaient compensés par la gestion fine des « axes » sur lesquels étaient déposées les bases de données.
Depuis une petite dizaine d'années, les processeurs basés sur l'architecture x86, issue du monde grand public, ont fait des pas de géant. Non seulement ces processeurs ont rattrapé leurs grands frères en termes de puissance de calcul, mais ils les ont surpassés avec la gestion de l'adressage 64 bits. Ils ont vu leur taille de cache se démultiplier et des instructions de virtualisation (Intel VT-x et AMD-V) faire leur apparition sur leurs plaques de silicium.
En parallèle, les technologies d'entrée/sortie internes aux serveurs et dans les prolongements stockage ont suivi cette course effrénée. Des baies de stockage avec des grappes de disques par centaines et des dizaines d'attachements fibres ont fait place à des systèmes disques virtualisés de plus en plus intelligents, permettant de gérer de grosses capacités.
Sur le marché des processeurs X86, des Intel Xeon ou AMD Opteron dépassent les 10 000 SAPS par puce, et font jeu égal avec les derniers nés du monde UNIX : les IBM Power7 et Intel Itanium Tukwila.
Cette puissance est délivrée tout en utilisant des composantes telles les barrettes mémoire presque compatibles avec nos PC bureautiques et des architectures d'entrées/sorties complètement maîtrisées.
Optimisation des ressources et de la puissance à un coût très compétitif
Les coûts de production diminuent grâce à l'industrialisation et au volume. De par leur production en grandes séries, les processeurs x86 permettent d'obtenir le meilleur rapport performance/prix tout en garantissant une fiabilité et une haute tolérance aux pannes.
Leur capacité de gérer nativement la virtualisation de leur propres ressources, des accès mémoire, et via leur chipset, des accès aux périphériques, ont fait des processeurs x86 les moteurs préférés des architectures virtualisées. Ceci sans compter sur la différence de prix considérable en leur faveur.
Mais comme « la puissance sans maîtrise n'est rien », ces bêtes de courses que sont devenues les serveurs x86 ont trouvé leurs jockeys dans les OS de dernière génération comme MS Windows, les distributions Linux Red Hat ou Suse (pour ne citer que les plus importantes distributions supportées par SAP).
En parallèle les technologies de virtualisation ESX de VMWare, Xen de Citrix, ou KVM de Red Hat ont apporté souplesse et optimisation de l'utilisation des ressources et de la puissance.
2011 : de la virtualisation au cloud privé pour les infrastructures SAP
Bien évidemment SAP a suivi le mouvement pour rendre tous ses produits compatibles et supportés sur ces nouvelles plateformes hyper puissantes et considérablement moins coûteuses. Mises à part quelques configurations spécifiques, les produits SAP se comportent très bien en environnement x86.
En 2011 le palier virtualisation est pleinement opérationnel pour les infrastructures SAP.
L'étape suivante en cours de franchissement, aussi bien par l'éditeur que par ses clients, repose sur le Cloud Privé. Par ailleurs, les systèmes SAP sont des applications critiques qui ne tolèrent pas la moindre indisponibilité, car les impacts sont majeurs en cas de défaillance. La maturité récente de ces solutions technologiques (virtualisation et HW) conforte cette mutation.
Le manque de solution de HA (haute disponibilité) fiables sur les systèmes d'exploitation x86 (Linux et Windows) est en passe d'être comblé.
Les « clusters traditionnels » comme MC Service Guard, HACMP ou Veritas Cluster sont plus que challengés, car des alternatives sérieuses existent maintenant sur les plateformes Linux et Windows. En effet les outils de clustering HA disposent désormais d'une maturité reconnue et éprouvée.
De nouvelles alternatives architecturales en point de mire
Plus surprenant, la virtualisation ouvre de nouvelles possibilités architecturales via une mutation au niveau de la mécanique même « de disponibilité ».
Il est techniquement possible de déplacer des "serveurs virtuels" dans « leur ensemble » au lieu de focaliser sur les services applicatifs à contrario des méthodes traditionnelles. En effet les technologies de virtualisation apportent de nouvelles possibilités comme les snapshots et autres migrations à chaud.
Vmotion (VMWare), Xen Motion (Citrix Xen) et plus récemment KVM Live migration (Red Hat) se démarquent très nettement dans ce domaine et sont même parfois des alternatives à des solutions haute disponibilité plus classiques.
Ces alternatives architecturales permettent également la mise en œuvre de plan de reprise d'activité (PRA/DRP) de plus en plus facilement, en fonction des objectifs de RTO/RPO fixés pour le SI. Elles simplifient considérablement les plans de tests qu'il faut maintenir et valider continuellement afin de garantir leur efficacité en cas de sinistre.
Ces évolutions apportent de formidables possibilités qui accompagnent ce besoin de flexibilité/agilité de l'IT et permettent également d'optimiser les coûts d'implémentation et d'exploitation et les ressources.
Le nuage s'approche à grand pas, et commence son chemin par le « Cloud privé »...
C'est grâce à l'évolution matérielle des gammes de serveurs x86, accélérée par le 64bit et des routines processeurs dédiées à la virtualisation, que cette montée en puissance vient concurrencer très largement les anciens leaders Unix (HP-UX, AIX, SUN).
Mais, ces transformations apportent aussi de nouvelles problématiques, même si elles offrent par ailleurs de nouvelles possibilités en terme de continuité de services, et viennent bousculer les classiques de la haute disponibilité et du clustering :
- Des limites de supportabilité dans certains cas : comme par exemple la virtualisation Oracle.
- L'analyse des performances est rendue plus complexe, les « coûts de traitement de l'hypervision » et la gestion des pools de ressources (ressources partagées par les socles de virtualisation) sont des éléments clés.
Coté coûts, les enjeux sont atteints. Les retours sur investissement sont plus rapides (CAPEX réduits), et la souplesse apportée sur la maintenance vient réduire les coûts opérationnels récurrents, ou à défaut, permet plus de possibilité à coût équivalent (OPEX).
De plus les Unix historiques sont mis en danger par les stratégies de certains ISV (comme Oracle pour HP-UX [V]), ce qui pourrait encore accélérer cette vague de transformation.
Le nuage s'approche à grand pas, et commence son chemin par le « Cloud privé »...
Il est capital de faire les bons choix à la mise en place de telles solutions, et de suivre les retours d'expériences dans ce domaine.
Grâce à la maturité de ces technologies, l'ERP sera bientôt transformé en SaaS (Software as a Service), au même titre qu'une messagerie électronique.
[I] Sapnote n°1519590
[II] SPECvirt_sc®2010 , engage.redhat.com/forms/rhel6-specvirt
[III] Sous réserve de disponibilité de vCPU, 1vCPU = 1 Hyper Thread
[IV] SAPS - The SAP Application Performance Standard (SAPS)
Unité de mesure des performances des serveurs SAP indépendant de tout constructeur.
Cette unité a été construite par SAP AG base sur le traitement des documents du domaine Ventes et Logistique (SD). A titre d'exemple 100 SAPS représentent 2000 lignes de commandes traitées en une heure. Techniquement cela représente le traitement de 6000 changements d'écran SAP (dialog steps) ou 2400 transactions SAP.
Source : SAP AG www.sap.com/solutions/benchmark/glossary.epx
[V] oracle.com/us/corporate/press/346696
Avis d'expert coécrit par Jérôme Mollier-Pierret, Brian Passante et Ivan Ivanov, consultants chez KPF, société de conseil et de services informatiques spécialisée sur SAP.
Jérôme Mollier-Pierret - Consultant expert en opération d'infogérance, Jérôme intervient sur des projets SAP pour de grands comptes depuis plus de 5 ans et dans le domaine de l'IT depuis près de 13 ans. Il est titulaire d'un Master en génie informatique et réseau.
Brian Passante - Consultant expert en architecture Open Source, Brian participe à la définition et à la mise en œuvre d'architectures Open Source chez l'ensemble des grands comptes depuis environ 10 ans. Il est titulaire d'un diplôme d'ingénieur de l'école des Mines de Douai.
Ivan Ivanov - Responsable de l'équipe consulting technique, Ivan a commencé sa carrière au sein du Groupe KPF en tant que consultant SAP Basis avant d'occuper successivement des postes d'architecte technique SAP, de consultant en infrastructure, de chef de projets SAP auprès de grands comptes du monde industriel, et de la grande distribution. Depuis 2008, Ivan a pris la responsabilité opérationnelle de l'équipe consulting technique KPF. Ivan est diplôme du Master 2 "Systèmes d'Information et d'Aide à la Décision" de l'université de Lille 1.
On ne peut pas vraiment parler de virtualisation proprement dit, mais cette technique permet de multiplier les instances d'une même application dans un contexte cloisonné, avec des performances proches de l'exécution native. L'environnement ainsi « virtualisé » se retrouve confiné mais pas isolé à 100% du système hôte, notamment au niveau des ressources physiques (et du noyau).
SUN dispose, par exemple, sur son système Solaris de ce type de technologies - SUN Zone / Containers.
Les isolateurs sont principalement réservés aux serveurs Linux et sont fortement utilisés pour l'isolation de serveurs LAMP par les fournisseurs de serveurs Web.
La Full Virtualisation permet de simuler une architecture matérielle complète afin d'héberger un OS non modifié
Les performances ne sont pas toujours au rendez vous puisque la couche d'accès au matériel est intégralement simulée.
La para-virtualisation permet au système d'exploitation virtualisé d'accéder aux ressources matérielles, via une couche logicielle dédiée à cet effet
C'est l'Hyperviseur (KVM, VMWARE, XEN) qui virtualise les ressources et dialogue avec les pilotes des machines virtuelles.
Ajoutons à cela le support de la virtualisation au niveau des processeurs, et nos machines hôtes se retrouvent alors capables d'adresser directement leurs propres blocs mémoires, tout en préservant la stabilité de l'hyperviseur. Les performances deviennent alors redoutables au fur et à mesure que les goulets d'étranglements s'amenuisent. Nous approchons désormais des performances natives.
Les performances SAP atteignent 95 % des performances natives
Depuis, fin 2010, SAP supporte les installations sur des serveurs virtualisés à l'aide de Xen Server de Citrix. La para-virtualisation de Xen Server permet un overhead de moins de 5% ([I]). L'overhead représente le coût de la virtualisation par rapport à des performances natives.
KVM, l'hyperviseur intégré par RHEV (Red Hat Enterprise Virtualization) également supporté par SAP, baisse la barre pour atteindre 1% ([II]).
De plus, la croissance des performances en fonction des machines virtuelles est linéaire. Autrement dit, les performances obtenues avec une machine virtuelle de 2vCPU, seront doublées avec une deuxième machine virtuelle de 2vCPU ([III]).
Depuis 2010, Red Hat a misé sur l'hyperviseur KVM (abandonnant alors XEN), nativement intégré au noyau Linux. Il obtient alors haut la main, les meilleurs benchmark SPECvirt sur une architecture Intel Xeon.
Les promesses de l'éditeur ne s'arrêtent pas là. La version 3 de RHEV attendue dans l'année, fait tomber les barrières : un hyperviseur pourra gérer jusqu'à 2000 machines virtuelles, 64 TB de RAM et 64 vCPU par machine virtuelle !
Ces « nouvelles » technologies d'infrastructure, notamment avec les hyperviseurs, bousculent l'IT et le monde classique de l'Operating System et permettent de rationnaliser les licences et l'utilisation des ressources.
Nos systèmes d'information gagnent en agilité et en flexibilité
Un nouveau bac à sable pour un projet devient presque simple à mettre place. Les investissements matériels sont faibles, voire nuls, ce qui accélère encore la mise en production.
Le socle matériel s'est également adapté, et jusqu'au milieu des années 2000, les technologies développées pour les serveurs d'entreprises gardaient plusieurs longueurs d'avance comparativement aux technologies grand public.
Les plateformes multiprocesseurs intégrant la gestion du cloisonnement et de la virtualisation étaient réservées aux grandes entreprises et aux environnements critiques tels que les ERP.
Depuis les mainframes IBM, dont les ressources étaient pilotées par les premiers hyperviseurs VM/CMS, en passant par les serveurs Unix propriétaires IBM, HP ou SUN, les installations SAP se cantonnaient à utiliser les technologies propriétaires qui n'avaient d??? « Open » que le nom.
Pendant de longues années c'était la seule possibilité de dépasser quelques milliers de SAPS ([IV]) et quelques giga de mémoire RAM. La faible puissance des processeurs de l'époque était compensée par l'agrégation de plusieurs dizaines d'entre eux dans des partitions physiques ou virtuelles. Les faibles débits des systèmes de gestion des disques étaient compensés par la gestion fine des « axes » sur lesquels étaient déposées les bases de données.
Depuis une petite dizaine d'années, les processeurs basés sur l'architecture x86, issue du monde grand public, ont fait des pas de géant. Non seulement ces processeurs ont rattrapé leurs grands frères en termes de puissance de calcul, mais ils les ont surpassés avec la gestion de l'adressage 64 bits. Ils ont vu leur taille de cache se démultiplier et des instructions de virtualisation (Intel VT-x et AMD-V) faire leur apparition sur leurs plaques de silicium.
En parallèle, les technologies d'entrée/sortie internes aux serveurs et dans les prolongements stockage ont suivi cette course effrénée. Des baies de stockage avec des grappes de disques par centaines et des dizaines d'attachements fibres ont fait place à des systèmes disques virtualisés de plus en plus intelligents, permettant de gérer de grosses capacités.
Sur le marché des processeurs X86, des Intel Xeon ou AMD Opteron dépassent les 10 000 SAPS par puce, et font jeu égal avec les derniers nés du monde UNIX : les IBM Power7 et Intel Itanium Tukwila.
Cette puissance est délivrée tout en utilisant des composantes telles les barrettes mémoire presque compatibles avec nos PC bureautiques et des architectures d'entrées/sorties complètement maîtrisées.
Optimisation des ressources et de la puissance à un coût très compétitif
Les coûts de production diminuent grâce à l'industrialisation et au volume. De par leur production en grandes séries, les processeurs x86 permettent d'obtenir le meilleur rapport performance/prix tout en garantissant une fiabilité et une haute tolérance aux pannes.
Leur capacité de gérer nativement la virtualisation de leur propres ressources, des accès mémoire, et via leur chipset, des accès aux périphériques, ont fait des processeurs x86 les moteurs préférés des architectures virtualisées. Ceci sans compter sur la différence de prix considérable en leur faveur.
Mais comme « la puissance sans maîtrise n'est rien », ces bêtes de courses que sont devenues les serveurs x86 ont trouvé leurs jockeys dans les OS de dernière génération comme MS Windows, les distributions Linux Red Hat ou Suse (pour ne citer que les plus importantes distributions supportées par SAP).
En parallèle les technologies de virtualisation ESX de VMWare, Xen de Citrix, ou KVM de Red Hat ont apporté souplesse et optimisation de l'utilisation des ressources et de la puissance.
2011 : de la virtualisation au cloud privé pour les infrastructures SAP
Bien évidemment SAP a suivi le mouvement pour rendre tous ses produits compatibles et supportés sur ces nouvelles plateformes hyper puissantes et considérablement moins coûteuses. Mises à part quelques configurations spécifiques, les produits SAP se comportent très bien en environnement x86.
En 2011 le palier virtualisation est pleinement opérationnel pour les infrastructures SAP.
L'étape suivante en cours de franchissement, aussi bien par l'éditeur que par ses clients, repose sur le Cloud Privé. Par ailleurs, les systèmes SAP sont des applications critiques qui ne tolèrent pas la moindre indisponibilité, car les impacts sont majeurs en cas de défaillance. La maturité récente de ces solutions technologiques (virtualisation et HW) conforte cette mutation.
Le manque de solution de HA (haute disponibilité) fiables sur les systèmes d'exploitation x86 (Linux et Windows) est en passe d'être comblé.
Les « clusters traditionnels » comme MC Service Guard, HACMP ou Veritas Cluster sont plus que challengés, car des alternatives sérieuses existent maintenant sur les plateformes Linux et Windows. En effet les outils de clustering HA disposent désormais d'une maturité reconnue et éprouvée.
De nouvelles alternatives architecturales en point de mire
Plus surprenant, la virtualisation ouvre de nouvelles possibilités architecturales via une mutation au niveau de la mécanique même « de disponibilité ».
Il est techniquement possible de déplacer des "serveurs virtuels" dans « leur ensemble » au lieu de focaliser sur les services applicatifs à contrario des méthodes traditionnelles. En effet les technologies de virtualisation apportent de nouvelles possibilités comme les snapshots et autres migrations à chaud.
Vmotion (VMWare), Xen Motion (Citrix Xen) et plus récemment KVM Live migration (Red Hat) se démarquent très nettement dans ce domaine et sont même parfois des alternatives à des solutions haute disponibilité plus classiques.
Ces alternatives architecturales permettent également la mise en œuvre de plan de reprise d'activité (PRA/DRP) de plus en plus facilement, en fonction des objectifs de RTO/RPO fixés pour le SI. Elles simplifient considérablement les plans de tests qu'il faut maintenir et valider continuellement afin de garantir leur efficacité en cas de sinistre.
Ces évolutions apportent de formidables possibilités qui accompagnent ce besoin de flexibilité/agilité de l'IT et permettent également d'optimiser les coûts d'implémentation et d'exploitation et les ressources.
Le nuage s'approche à grand pas, et commence son chemin par le « Cloud privé »...
C'est grâce à l'évolution matérielle des gammes de serveurs x86, accélérée par le 64bit et des routines processeurs dédiées à la virtualisation, que cette montée en puissance vient concurrencer très largement les anciens leaders Unix (HP-UX, AIX, SUN).
Mais, ces transformations apportent aussi de nouvelles problématiques, même si elles offrent par ailleurs de nouvelles possibilités en terme de continuité de services, et viennent bousculer les classiques de la haute disponibilité et du clustering :
- Des limites de supportabilité dans certains cas : comme par exemple la virtualisation Oracle.
- L'analyse des performances est rendue plus complexe, les « coûts de traitement de l'hypervision » et la gestion des pools de ressources (ressources partagées par les socles de virtualisation) sont des éléments clés.
Coté coûts, les enjeux sont atteints. Les retours sur investissement sont plus rapides (CAPEX réduits), et la souplesse apportée sur la maintenance vient réduire les coûts opérationnels récurrents, ou à défaut, permet plus de possibilité à coût équivalent (OPEX).
De plus les Unix historiques sont mis en danger par les stratégies de certains ISV (comme Oracle pour HP-UX [V]), ce qui pourrait encore accélérer cette vague de transformation.
Le nuage s'approche à grand pas, et commence son chemin par le « Cloud privé »...
Il est capital de faire les bons choix à la mise en place de telles solutions, et de suivre les retours d'expériences dans ce domaine.
Grâce à la maturité de ces technologies, l'ERP sera bientôt transformé en SaaS (Software as a Service), au même titre qu'une messagerie électronique.
[I] Sapnote n°1519590
[II] SPECvirt_sc®2010 , engage.redhat.com/forms/rhel6-specvirt
[III] Sous réserve de disponibilité de vCPU, 1vCPU = 1 Hyper Thread
[IV] SAPS - The SAP Application Performance Standard (SAPS)
Unité de mesure des performances des serveurs SAP indépendant de tout constructeur.
Cette unité a été construite par SAP AG base sur le traitement des documents du domaine Ventes et Logistique (SD). A titre d'exemple 100 SAPS représentent 2000 lignes de commandes traitées en une heure. Techniquement cela représente le traitement de 6000 changements d'écran SAP (dialog steps) ou 2400 transactions SAP.
Source : SAP AG www.sap.com/solutions/benchmark/glossary.epx
[V] oracle.com/us/corporate/press/346696
Avis d'expert coécrit par Jérôme Mollier-Pierret, Brian Passante et Ivan Ivanov, consultants chez KPF, société de conseil et de services informatiques spécialisée sur SAP.
Jérôme Mollier-Pierret - Consultant expert en opération d'infogérance, Jérôme intervient sur des projets SAP pour de grands comptes depuis plus de 5 ans et dans le domaine de l'IT depuis près de 13 ans. Il est titulaire d'un Master en génie informatique et réseau.
Brian Passante - Consultant expert en architecture Open Source, Brian participe à la définition et à la mise en œuvre d'architectures Open Source chez l'ensemble des grands comptes depuis environ 10 ans. Il est titulaire d'un diplôme d'ingénieur de l'école des Mines de Douai.
Ivan Ivanov - Responsable de l'équipe consulting technique, Ivan a commencé sa carrière au sein du Groupe KPF en tant que consultant SAP Basis avant d'occuper successivement des postes d'architecte technique SAP, de consultant en infrastructure, de chef de projets SAP auprès de grands comptes du monde industriel, et de la grande distribution. Depuis 2008, Ivan a pris la responsabilité opérationnelle de l'équipe consulting technique KPF. Ivan est diplôme du Master 2 "Systèmes d'Information et d'Aide à la Décision" de l'université de Lille 1.
Imprimer
Partager