SG CIB mise sur le grid pour la gestion des risques
Pour exploiter un progiciel de simulation des risques de contrepartie, la Société Générale avait besoin pour sa branche CIB d'un calculateur évolutif et économique. Elle a choisi une grille de serveurs-lames sous Linux.
Du fait du fort développement que connaissent ses activités de marché, la branche CIB (Corporate & Investment Banking) du groupe Société Générale se retrouvait face à des besoins croissants en matière de calcul des risques de
contrepartie sur les opérations boursières. Il lui fallait donc se doter d'une nouvelle plate-forme de simulation tout autant évolutive que fiable.
Les besoins : paralléliser les traitements
' Nos calculs ont gagné en volumétrie et en complexité, explique Renée Barsacq, responsable des systèmes risques au sein de la DI. Les modélisateurs de la direction des risques conçoivent des modèles toujours plus sophistiqués afin d'affiner les calculs. C'est pourquoi nous avons déployé une solution grid sur ce périmètre de la gestion des risques de contrepartie. ' Le défi : miser sur une plus grande parallélisation des traitements, en tenant compte de contraintes temporelles (les calculs étant exécutés la nuit) et en maîtrisant les dépenses informatiques. Choisir le grid coulait de source, d'autant que ce n'était pas terra incognita pour SG CIB : plusieurs grilles de calcul fonctionnant sous l'ordonnanceur LSF de Platform Computing étaient déjà utilisés par le système de trading de l'établissement. Mais à la différence de ces premières grappes de serveurs, qui servent des applications maisons .Net sous Windows, le nouveau grid d'évaluation des risques fonctionne avec Linux, et n'exploite pas des développements spécifiques, mais une solution de type progicielle adaptée au grid computing. ' Pour nos calculs de risque, nous nous appuyons sur la plate-forme progicielle Algo Suite et le calculateur Riskwatch d'Algorithmics de façon à consolider l'ensemble des traitements réalisés à travers le monde ', souligne Marc Blanot, qui fut le chef de ce projet grid.Les écueils : s'assurer de la compatibilité grid
Jusqu'en 2005, SG CIB exploitait la version Solaris de ce progiciel sur un serveur SMP haut de gamme Sun Fire 15K. Toutefois ce dernier arrivait en limite de capacité. Fallait-il le mettre à jour ou passer à une solution de type grid, plus économique ? La seconde solution fut choisie, car ' Algorithmics avait déjà commencé à travailler avec d'autres clients sur ces technologies. Nous n'avions donc aucun besoin de refondre quoi que ce soit, juste de redéployer l'application d'Algorithmics sur une infrastructure parallélisée '. De fait, la solution Algo se prêtait bien au grid computing, puisque, depuis sa version 4.5 sortie en 2004, elle existe en version distribuée pour Linux. Dans sa version grid, Algo est ainsi en mesure de distribuer les processus de simulation, de multiples scénarios pouvant être testés en parallèle sur autant de n?"uds de calcul. Toutefois, Algorithmics avait pour partenaire grid Datasynapse et non Platform Computing dont SG CIB utilisait déjà l'ordonnanceur. Une évaluation fut conduite en 2005 pour s'assurer qu'Algo donnerait satisfaction sur un grid Platform Computing et tester les solutions de Platform et Datasynapse sur le plan de l'évolutivité, de la résistance aux pannes et de l'intégration fonctionnelle. ' Concernant nos attentes, les deux solutions n'ont pas montré de grosses différences fonctionnelles. La solution Platform apparaissait cependant un peu plus mûre que la solution concurrente sur le plan de la stabilité et de la fiabilité. Ses options de paramétrage semblaient plus nombreuses. 'Mise en ?"uvre : des serveurs haute densité
A l'issue de cette phase de test, la solution Symphony de Platform Computing, un paquetage grid fondé sur le logiciel Load Sharing Facilities de l'éditeur, et adapté aux métiers financiers, a alors été retenue. Coté matériel, l'équipe projet a opté pour les technologies de serveurs-lames et s'est équipé de châssis Bladecenter d'origine IBM. Restait à dimensionner correctement la plate-forme originelle. Le processus de simulation n'exige pas d'être traité en temps réel, souligne Renée Barsacq. ' La solution est essentiellement employée pour faire du traitement par lots ; évaluer sa charge en fonction d'un nombre d'utilisateurs amenés à l'exploiter n'aurait donc pas été pertinent. ' Dans ce mode de fonctionnement, le grid Symphony n'a montré aucune défaillance pour allouer les ressources aux travaux qui lui étaient soumis.Les évolutions : coller à la montée en charge
Vu les contraintes temporelles d'exécution des calculs, l'équipe d'exploitation supervise en permanence la performance de la ferme, de façon à la redimensionner si besoin est. Très vite, cette plate-forme a dû démontrer ses capacités d'évolution : alors que le calculateur avait démarré en 2006 avec environ 70 lames, il est passé à l'automne 2007 à 370 lames et regroupe aujourd'hui, sur l'ensemble de l'infrastructure (production, certification, développement), un millier de processeurs Xeon bi et quadric?"urs. Reste que la puissance de traitement n'est pas le seul point sensible à surveiller par l'équipe d'exploitation. La performance des accès aux données est un sujet constant de préoccupation.Pour l'heure, le grid de calcul s'appuie sur des serveurs de fichiers NFS. Les données archivées, une centaine de gigaoctets, ne sont pas très volumineuses car elles concernent les indicateurs de risques et non le détail des résultats de calculs générés par le progiciel. Il n'en demeure pas moins, conclut Marc Blanot, ' que nous aurons à faire évoluer les systèmes de stockage et accès pour répondre à des traitements applicatifs de plus en plus complexes. Cela nous amène à regarder des solutions innovantes de systèmes de fichier en cluster '.Contenus sponsorisés
Votre opinion