Linux on parade
- Posted:
- 16:35 10 Mar 2004
- Topics:
- Operating Systems | Open Source Software | Linux
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
