Server consolidation

How consolidation helped BSE

Consolidating its servers did away with BSE's computing woes

BSE’s server problems had roots in the organisation’s rapid growth over the years. As the organisation grew, server count also went up. Each department had its own server which led to a situation where server management and resource utilisation became major concerns.

According to Patankar, Director, IS, Bombay Stock Exchange, “One application needed higher power at a specific time during the day, while the other required more power at a different point of time (e.g. trading operated during the day while settlement processes ran at the end of the day after trading). This led to hardware not being utilised efficiently.”

Identifying Bottlenecks

This was the time when BSE started identifying critical applications that had to be operated from its disaster recovery site. Consolidation of applications and servers was diagnosed as the cure for BSE’s IT ills.

To begin with, server consolidation was undertaken. However, BSE had to sort out some tangles to get its consolidation right. “To cite an example, derivatives run through the day and we need lot of compute power for that. At the end of the day, the settlement system requires more power. This is the time when trading does not happen. So if we keep more CPU power for derivatives, it is going to waste,” Patankar explains.

The Right Stuff

Today the stock exchange uses HP rp8400 servers based on the PA-RISC 8900 CPU (upgraded from the PA-RISC 8700 CPU used at the initial stage of consolidation) to resolve the issues that they faced. Two rp8400 servers in cluster mode were used.

Patankar points out that the benefit of this configuration includes availability of a local failover and increased uptime of applications. The VPAR tool that came with the servers was used to create virtual partitions allowing BSE to allocate CPUs, memory and I/O according to the different application requirements.

Visible Savings

At present, BSE has consolidated from 14 to just 2 servers with a fail over. If a server goes down, the applications fail over to the second server. The applications were distributed across the two servers.

BSE uses dynamic partitioning so that trading is given the maximum CPU power during the day. At the end of day, the settlement system gets more power. “The same CPUs that were lying idle earlier are now utilised for various applications at different points of time. Thus the system is more responsive, hardware costs are reduced and the hardware is utilised efficiently,” Patankar adds. According to him, the ROI calculation for the servers has been simple. Earlier, BSE used to have three-year AMCs for its 14 servers. The new rp8400 servers with three-year warranty were purchased for the cost which was marginally higher of that AMC. Apart from this, BSE also saved on administration costs because of the changeover. “The new servers are cheaper and easier to manage. In addition, we almost doubled the power available for each of the applications,” Patankar affirms.

BSE also saved in terms of DR because they did not need to buy 14 servers for a secondary site. Just two servers similar to those deployed at primary site had to be purchased. Since the organisation was able to reduce the number of servers at the main site to two, all that was required was replicate the set-up at the DR site.

“Some of our applications required additional capacity and the same was acquired from HP by using their capacity-on-demand (COD) policy i.e, additional CPUs are in the system and you pay as you use them. This gives instant capacity upgrade with little upfront financial outflow,” says Patankar.

—With updates from VG