Hi,

J’ai suivi, il y a quelques temps, des tests RAC sous SAP (Netweaver 2004s). Ou plutôt… Je devrais dire des tests de sécurisation de l’ABAP System Central Service (ASCS) par le Clusterware Oracle et le replication Server SAP (ENR).

Ca fait déjà plusieurs années que la technologie Real Application Clusters apporte à de nombreux systèmes, y compris SAP, la haute-disponibilité, la capacité de monter en charge sur plusieurs machines et une meilleure utilisation des ressources disponibles. En particulier, RAC facilite l’administration des systèmes : Il n’est plus nécessaire de gérer des bascules des verrouillages des baies, des systèmes de fichiers, des bases de données…

Avec Oracle10g Release 2, la technologie Real Application Clusters et le Clusterware Oracle permettent d’envisager des modèles de coûts différents : Vous pouvez construire un système à partir de briques matérielles standard ; vous pouvez limiter le nombres de logiciels de l’écosystème (par exemple, le clusterware Oracle permet de sécuriser des applications tiers. Oracle Cluster Filesystem permet, sous Linux ou Windows, de partager les binaires SAP sur plusieurs machines) ; l’administrateur Oracle peut assurer seul le support et la production d’un ensemble complet de fonctions, là où habituellement, il faut faire intervenir plusieurs spécialistes. D’ailleurs, en réduisant le nombre d’intervenants et donc d’interactions et de limites, ce type d’approche permet également d’améliorer la qualité de service.

L’ensemble des documents nécessaires à la mise en oeuvre du clusterware Oracle avec l’ASCS sont disponibles aux urls ci-dessous :

• La page dédiée à SAP sur OTN et le white-paper sur la mise en place de SAPCTL Providing High Availability for SAP Resources
• Notion d’architecture et Clustering SAP (documentation SAP)
• Standalone Enqueue Server et Replication Server (documentation SAP)
  

Sans entrer dans les détails décrits dans les documents, on peut dire que la mise en oeuvre est assez simple ; il n’y a pas de piège particulier et tous les tests de validation (arrêts brutals des serveurs, kill des processus, arrêt du réseau…) ont été effectués avec succès !

Quelques remarques (malgré tout) :

• Il faut une bonne connaissance du paramétrage des profils SAP. L’intégration entre le clusterware et SAP est un travail d’administrateur SAP plus que d’un administrateur Oracle (J’imagine que c’est bien dans l’esprit de SAP ne pas avoir besoin d’un administrateur Oracle, même pour sécuriser l’ASCS avec Oracle clusterware !)
• Récupérer le logiciel SAPCTL est la partie la plus compliquée du travail, même si vous avez de bon contacts chez Oracle. Il faut dire que le logiciel n’est pas « General Availability » avant Q4 CY2006. C’est d’autant plus étonnant que nous n’avons pas eu de problème !
• SAPCTL ne sécurise pas encore l’Enqueue Server Java (SCS). Il n’est disponible pour l’instant que pour Linux. Plusieurs évolutions sont prévues et en particulier le support de l’Enqueue Server Java avec la version GA d’ici la fin de l’année 2006 !
• Il faut que les N° d’instances ASCS et ENR soient identiques… Quand j’ai dit que nous n’avions pas eu de problème… J’ai menti ! D’après nos correspondants à Walldorf, il semble que ce soit _OBLIGATOIRE_. La documentation SAP ne semble pas aussi explicite : Fallait-il qu’on tombe dans ce piège ?

Alors, faites vos architectures et vos calculs (Ca peut-être très rentable !) et faites comme d’autres…

GarK!