Linux on parade

Scalability and cost are two of the reasons the police force opted for Linux on its video-based identity parade system. Julia...

Novell Special Report  

Scalability and cost are two of the reasons the police force opted for Linux on its video-based identity parade system. Julia Vowler reports.

Linux has been edging further and further forward into the central space of corporate IT, but what is it really like to implement for a bus-iness-critical application? West Yorkshire Police became caught in the spotlight when its prototype video-based identity parade system was selected to be developed into a full production system for police forces via a central service run out of the Video Identity Parade Electronically Recorded (Viper) National Bureau.

The idea was to replace costly and time-consuming live identity parades with video-based ones, whereby a mix of suspect and volunteer images would be shown to witnesses at local police stations.

With Viper, parades cost as little as £150 each, instead of up to £1,250 for a live parade, and preparation time is cut from 10 weeks to 15 minutes. The system is estimated to save £7m in its first year.

Viper project manager Tony King says the prototype system was "a couple of oversized PCs, two edit stations, one server and five people connected to seven sites. We had to turn it into a production system."

Failure of the system would cause grave displeasure at Whitehall, but because of that, King was able to lever a lot of clout on the project, and senior members of the police force were able to summon attention from senior supplier managers.

"I wrote a functional spec in 10 days," says King. Among two or three ideas from suppliers was a Linux option -a six-node IBM general parallel file system (GPFS) Intel-based cluster running Red Hat 7.1 Linux with 1.4Tbytes of storage and a 1gbps Cisco-switched network.

It needed to be powerful enough to store more than 100,000 video images of suspects and volunteers and transmit 100Mbytes of video files up to 100 times a day to 32 editing stations. "When I looked at the quotes I found Linux cheaper - a lot cheaper," says King. "Compared with the proposal for an NT-based Compaq system, I found that the total cost of ownership of Linux was less."

King also needed the system to be able to scale. "We knew it would have to serve 70 sites, and it could be up to 200 sites - all on a fixed sum of money - so the cluster would have to be able to grow. Linux appeared to be more powerful and scaleable and we could build in resilience and reliability at a sensible price."

Before opting for Linux, King did formal and informal research into its viability for his needs. Although he had done large Unix projects before, King had no experience of Linux. "I knew Linux was becoming increasingly acceptable and there was a design match between Linux and our application - GPFS had worked elsewhere as a Linux cluster for edit stations at the BBC and MTV, so it had been done before. I also asked my colleagues at the Telecoms Managers Association to get word of mouth feedback on using Linux. Some said they would like to try it, but if it went wrong, they would be out of a job."

Because of his lack of experience, the risk factor attached to Linux and the attention from Whitehall, King says, "I got the system design underwritten by IBM. It was signed off so that the proposed solution would meet the specification." He also contracted out development to take advantage of Linux skills elsewhere. "I am a great believer that if it is not your core business, you should outsource it," he says.

Although West Yorkshire police retain the intellectual property rights to the system, its IT department was not directly involved with the Viper project, so King hired two technical staff with Linux experience and a testing and installation manager. King insisted that the system be intensively tested by IBM and his prime contractor, IBM-spin out Sagitta.

"From placing the order, the system had to work within 12 weeks," he says. "There was a lot of tuning to do in the factory test - the system had slowed down. Our users were despondent, but the faults were expected."

In fact, many of the problems came from non-core aspects of the system. "Linux was the least of our problems," says King. "We had more trouble with the network and that it was taking too long to burn the DVDs."

When all the kinks had been ironed out, "The tested kit was delivered on Friday and we did the first parade on Monday," says King. "There are far fewer people around who understand Linux, and we would have been pushed to find our own support staff and would have had to pay more."

He also believes that, once in production, systems should not be changed and tinkered with, although this might be more tempting for in-house staff. He finds that "technical support for Linux is easier than for Unix, and staff ratios are lower. We have three [Sagitta] tecchies doing back-ups and a list of checks."

King says that Viper has proved reliable. "We had only one serious fault and we were 'off-air' once. Our real fear was that the GPFS would not scale, but it is so efficient we have not needed to upgrade."

Nor has Linux made its presence felt in any negative fashion so far. "We have not found any googlies in the way we are using it," says King. "Our kit may be simple, but the way we are using it is not - everything is backed up."

Within Viper, Linux is very low-profile. "The technical side is completely hidden," says King. "The only training anyone needed was how to use the system. The end-users do not care if it is Linux, and even the police forces' IT people are not asking about it. It is almost invisible."

Linux lessons learned

  • Check that the application you want has already been suitably matched for Linux in implementations elsewhere

  • Get word-of-mouth feedback on Linux experiences from your peers

  • Reduce the risk by getting the proposed system signed off against your functional specification by your supplier

  • Test copiously. Allow time for and insist on factory testing carried out by the supplier and your in-house staff. You may need a lot of tuning to get the performance you want

  • Do not over-fixate on the Linux element of the system - other parts can go wrong too

  • Linux skills and experience are probably more available, and less costly, if purchased via development and support contracts with third-party service companies. However, turning to third parties may engender "not invented here" resistance among internal staff

  • Beware of indifference or even resistance to Linux by in-house tecchies. Not everyone is keen on it (including some Unix die-hards

  • The more critical the system, the more important to get your senior business managers to lean on your supplier's senior managers

  • Linux is new, which makes it even more important to resist continuing development when the system is in production. Freeze the design and stick to it

  • Linux clusters are high-performance. Ensure the rest of the system design matches, such as network speeds.

This article is part of Computer Weekly's Special Report on Linux produced in association with Novell

Read more on Operating systems software