Arno Radermacher gave a quick overview of the situation at the bank before the arrival of the HPC cluster. The Sal. Oppenheim bank offers roughly ten thousand financial instruments to its customers. The complexity of these financial products was steadily increasing. The regulatory requirements for the trading of shares and the requirements for trading with credits were getting more stringent. The infrastructure for risk management consisted of several midsize and large SMP based UNIX systems. The Monte Carlo simulation for risk exposure calculation was only needed for scenario simulation.

In the past, the existing computer systems at the bank could be used to repeatedly sample the pricing values using the Black Scholes algorithm and the x-00 iterations for bi-and tri-nomialtrees. If they were coupled with consideration of the underlying correlations, the results were showing a realistic "Value at Risk", as the speaker explained.

In the fall of 2005, Sal. Oppenheim will offer new, highly complex financial products. These products will depend on a large number of underlying products. The new products will be highly complex assets which will have multiple layers and will need to be simulated with enough stochastic stability in order to achieve enough quality in the probability of the price prediction, according to Arno Radermacher.

The aim of the bank is to start simple and grow towards a full Grid. Sal. Oppenheim has been discussing the Grid solution since spring 2003. The idea was to build a Linux cluster out of homogeneous commodity computers in order to transform later into a heterogeneous Grid.

Arno Radermacher explained to the audience that the Monte Carlo Simulation scaled well without the necessity of shared memory or process interconnection. The experience out of the current Monte Carlo based risk controlling application on SMP systems gave the bank a basis to understand the Monte Carlo complexity and it also showed the need for a highly reliable management environment. On-line pricing for derivatives would however demand systems in the order of 2.5 to 5 million euro if based on large SMP systems. This offers much place for project risks with a LINUX-PC-based installation.

The HPC cluster is designed to be isolated, fault-tolerant, resilient, and mission critical for the trading business at Sal. Oppenheim. The Linux cluster was designed as a layered solution. Intel has been chosen as the compiler and processor architecture. SuSE is required by Tivoli, CSM and Symphony, Mr. Radermacher stated. This cluster is operated by Sal. Oppenheim's outsourcing partner EDS. To ensure a resilient operating of the mission critical pricing engine the operating environment was brought up to the same quality of services like all other core bank applications.

To this end IBM and EDS configured a complete versioning system on Cluster Systems Management (CSM) for the installation of different major releases and patch levels with roll back capability. EDS built a "mini distribution" based on SLES 8.1 with an automated IBM Tivoli Storage Manager (TSM) restore procedure. The speaker explained that the normal cluster operating is done with the IBM CSM Software. Remote access to all server function (KVM) is possible through Remote Service Adapter (RSA) cards.

Some requirements still have to be solved by Altreia, EDS, IBM, Morse and Sal. Oppenheim. These include the definition and proof of a security and operating concept with the QoS like all other core bank applications of Sal. Oppenheim. There is also the set-up of hardware (Dual hall) and the management of the software and Grid middleware to be attended to. Mr. Radermacher also mentioned the adoption and hardening of SLES 8 to the very new hardware as well as the design of the CSM configuration and programming with the IBM labs in Poughkeepsie, New York. In addition the TIVOLI Enterprise Console has to be integrated.

In answer to the question whether cluster technology is a commodity, Mr. Radermacher stated that the idea to build a compute cluster out of commodity elements per se is valid. The problem is the complexity by adding a lot of elements in a cluster such as the hardware, the network operating system, the cluster systems management and the Grid middleware. The dependency and configuration network is multi-dimensional and in any case leads to a one of a kind solution. Most of the well known vendors have been asked by Sal. Oppenheim to provide a fix price service offering for integrating and operating the cluster with all elements.

In the short term, as the application is continuously developed on the side of the algorithms and implementations, there will be a demand for large scale tests with a lot more CPUs than available inhouse. If extraordinary market situations demand a higher capacity or large back testing, calculations have to be done in order to figure out whether remote capacity can be made available as virtual expansions of the current Grid HPC cluster are necessary and will be used, the speaker explained. This will be established by IBM Montpellier which will arrange deep computing capacity on demand.

The current implemetation looks like a straight forward cluster implementation. From the presentation it was not clear why this has really been so difficult.