Debian Cluster Replaces Supercomputer For Weather Forecasting

wazza brings us a story about the Philippine government's weather service (PAGASA), which has recently used an eight-PC Debian cluster to replace an SGI supercomputer. The system processes data from local sources and the Global Telecommunication System, and it has reduced monthly operational costs by a factor of 20. Quoting: "'We tried several Linux flavours, including Red Hat, Mandrake, Fedora etc,' said Alan Pineda, head of ICT and flood forecasting at PAGASA. 'It doesn't make a dent in our budget; it's very negligible.' Pineda said PAGASA also wanted to implement a system which is very scalable. All of the equipment used for PICWIN's data gathering comes off-the-shelf, including laptops and mobile phones to transmit weather data such as temperature, humidity, rainfall, cloud formation and atmospheric pressure from field stations via SMS into PAGASA's central database."

I don't understand the difference

[pembo13 (770295)]

How different can Debian really be compared to RedHat in terms of stability? They both use the Linux kernel, and GNU tools, and follow the LSB, no?

Re:I don't understand the difference

[elysium-os (998821)]

Many distro's add kernel patches and add different drivers to the initrd.
Also the core os ( most minimal installation ) has many different tools and libs.

Also at time of release they can pick from many different versions of a single package.
That in combination with what version of GCC and compile flags can and does make a huge differance.

And at least with Debian you really do know how the systems was build, with RedHat I still wonder...

Marcel

Re:I don't understand the difference

[prefect42 (141309)]

You don't have to wonder with RedHat. Just look at the SRPMs and see what patches they've applied.

Re:I don't understand the difference

[Zantetsuken (935350)]

Because each major distro, while they use the same base kernel, GNU command line tools, and same GNOME/KDE environment, can have radically different kernel extensions and drivers implemented by one distro doing development but not another. If you're using whatever GUI tools a distro provides, they can each configure the same backend very differently, which depending on how the tool writes the config file can also effect stability, security, and other functions. Also Fedora/RHEL and tends to use tools created or modified by Red Hat specifically while those aren't easily available for Debian or SuSe, which have their own tools in the same manner.

Re:I don't understand the difference

[Xero_One (803051)]

Debian will run multiple services reliably under heavy load. From my limited experience, it's one of those distros where you "Set It And Forget It" and that's that.

Once you got it configured the way you want it, there's little intervention involved to maintaining it. It'll just keep chugging along. The keyword there is "correctly". Follow the readmes, howtos, and best practices, and you're golden.

It's also one of the oldest distributions which always kept to the spirit of GNU/Linux in general: community development and enrichment. Debian developers pride themselves on that spirit. To make the best software for humans. (At least that's what I gather from hanging out with Debian folk) These people are not only passionate in the software that they write, they do it without wanting anything in return, being humble in the way they do it, and wanting no reward for doing it. To them, their reward is in other people using their software and loving it! In my opinion they're not recognized enough.

But what do I know? I just use the software.

Re:

[asuffield (111848)]

The data is submitted by the owners

So what you have is a list of the 500 biggest operations who think it is important to brag about what platform you are running. That's quite different from the 500 biggest operations (I'd be surprised if the two lists overlap at all).

I know that if I were running one of the largest, most sophisticated computer systems in the world, I wouldn't be going around telling my competitors how I did it.

Re:I don't understand the difference

[emag (4640)]

Well, one of the things I'm running into, having walked into a RHEL-heavy shop, is that every single RH box has what I've come to derisively refer to as /usr/local/hell. Every. Single. One. Basically, because of the extreme pain of upgrading (or others' laziness, though my limited experience in the distant past says it's mostly the former), we have RHEL3, RHEL4, and RHEL5 servers, all at whatever the then-current patchlevel was (AS, ES, WS, BS, XYZS, ASS...Taroon, Macaroon, Buffoon...you get the idea), that have almost everything important duplicated in /usr/local, built from tarballs. Can't remove the system-supplied stuff, since what's left that expects it will balk, but can't use it either, since users or security concerns dictate significantly newer releases of everything from Apache to perl to php to mysql to...

This is, of course, a nightmare. Worse, the kernels on all of these have the notorious RH patchsets, so as far as anyone knows, each and every one has a mish-mash of backported "features" from newer kernels, but few of the bugs fixed that those newer ones have. In fact, several are still at 2.4.x kernels that, even years later, suffer from a kswapd problem that makes the machines unusable after a while. And we're getting in newer hardware that the 2.6 kernels that ARE supplied don't support. Everyone here has given up trying to build a plain vanilla kernel from the latest sources, because there are so many RH-applied patches to their kernels that may or may not even be applicable or available for the vanilla Linus kernels, that no one can say with any degree of certainty that the system will even boot. With Debian, I gave up on vanilla kernels because I was just tired of sitting through recompiles for the "advantage" of just removing a few things that were modules that I knew I would never use, customized to each of a half-dozen machines.

With Debian, which I've run for years without a "reinstall", updates are significantly simpler to perform, and if you want to throw backports.org into your sources.list (which may or may not be a fair thing to do), even *stable* has 2.6.22, or 2.6.18 withouth bpo in the mix. Remote updates? No problem, Debian was *designed* to be updatable like that from the start. The dpkg/apt* tools are still worlds ahead of the RH (and SUSE) equivalents. Dependencies are easier to deal with, as are conflicts, and security.d.o seems to be a lot more on the ball about patches than anyone else.

In fact, I'm often telling our security guys about updates that fix vulnerabilities that their higher-up counterparts haven't started riding them about yet, so they can get a head start on going through the major hassle of begging/cajoling/threatening the RH admins to grab the latest sources, rebuild, and re-install so we don't get slammed on the next security scan for having vulnerable servers. Not that it's ever "the latest", but always "the least amount of upgrade needed to avoid being flagged", which means that next month we go through this all again. With Debian, "aptitude update ; aptitude upgrade" (or just "aptitude"/whatever and then manually select packages, though in stable, it's only going to be fixes anyway most of the time), and the handful of systems I've gotten in under the radar are up-to-date security-wise with significantly less effort.

Even the "you get what you pay for in terms of support" canard has been proven to be false. We had a couple brand-new freshly-patched RHEL5 systems that just would not stay up. First thing RH Support has us do is run some custom tool of theirs before they'll even attempt to help us. A tool that, I should add, is rather difficult to run on a machine that goes down within minutes of coming up. Finally we re-installed and didn't apply the RH-sanctioned updates. Machine...stays up. Same thing with some RH-specific clustering software. Another RH-approved release resulted in...no clustering at all. For whatever reason, re-installing the prior RPM wasn't possible, but the

One thing always missing from such stories...

[dhavleak (912889)]

What was the age and the specs of the SGI being replaced?

Going by Moore's law, a factor of 20 performance improvement takes about 6 to 8 years. If the SGI was at least that old, this isn't news -- it's just the state of the art these days. In other words, small clusters capable of weather forcasting are relatively run-of-the-mill.

Of course, props to linux for being the enabler in this case.

Re:One thing always missing from such stories...

[JK_the_Slacker (1175625)]

6 to 8 years, you say? Well, then, they'll be ready to upgrade about the time the next version of Debian is released.

Re:One thing always missing from such stories...

[IkeTo (27776)]

This is inaccurate, as a long time Debian user I really cannot resist in correcting them.

> Debian "unstable" Sid is upgraded every day, or at least several times per week.

True.

> Debian "testing" is upgraded several times a month.

Wrong. Debian testing is updated automatically from packages in Debian unstable. The difference is simply that a package has to sit in Debian unstable for a few days, and no significant bugs can be introduced by the new package, before it is updated. Since the process is automatic, Debian testing is updated just slightly less continuously as unstable (it depends on the robot to check the package dependencies and bug reports rather than the maintainer to upload a new version).

The only time when the update rate is seen as low as less than that is when testing is in deep freeze, i.e., a new stable is about to be created.

> Debian "stable" is upgraded every one or two years.

It usually takes slightly longer than two years.

> The only one I have avoided is "Debian experimental"... :)

You cannot have a pure "Debian experimental" system. Debian experimental are subsystems that could have profound effect on the rest of the system, and so is provided for trial in isolation. E.g., back in the Gnome 1 to Gnome 2 transition days, or XFree 3 to XFree 4 days, these subsystems are tested in experimental before moving to unstable. These packages are supposed to be used on top of or to replace some unstable packages. Since they affects one particular subsystem, experienced testers can try one particular one based on their needs.

Re:

[Respect_my_Authority (967217)]

> Debian "testing" is upgraded several times a month.

Wrong. Debian testing is updated automatically from packages in Debian unstable. The difference is simply that a package has to sit in Debian unstable for a few days, and no significant bugs can be introduced by the new package, before it is updated. Since the process is automatic, Debian testing is updated just slightly less continuously as unstable (it depends on the robot to check the package dependencies and bug reports rather than the maintaine

Re:

[fm6 (162816)]

It's not news that an old system was replaced by a new system. It is interesting that an old supercomputer wasn't replaced by a new supercomputer; a cluster of cheap commodity systems does the job just as well when you don't need real-time performance. This sort of creative use of PCs is what drove SGI into bankruptcy and irrelevance [sgi.com].

This Philipine newspaper story [manilatimes.net] fills in some important details missing from the Australian PC News article: the age of the SGI system (10 years) and the reason it was costing s

This isn't anything new...

[toby34a (944439)]

Most weather prediction centers have adapted their weather forecast models to use Linux clusters. By running an operational forecast model on a cluster, it's easy for forecasters to scale the models so that they can be run (albeit slowly) on desktop machines, and are easily worked on by real meteorologists (versus IT professionals). At my university, we use a large cluster of machines on a RedHat enterprise system, and then able to scale the models and run them on multiple processors using MPICH compilers and batch jobs. Really, using a Debian cluster is no different then using a RedHat cluster. My colleague has access to the NOAA machine, which has more processors then you can shake a stick at... he talks about some code that takes 3 days to run on his personal workstation that takes 2 minutes on 40 processors. With the relatively low cost of a linux cluster, weather forecasting models can be run quickly and efficiently on numerous processors at a local level. With the ease of use of a Linux machine versus some of the supercomputers, it puts the power in the meteorologists to make those changes to the model so that it can improve forecasts.

Obligatory

[Nefarious Wheel (628136)]

Imagine a Beowulf cluster of ...

oh, wait...

Where is...

[darekana (205478)]

I tried:
apt-get -f -y install gweather
But it failed with something about "ldconfig: /lib/libearthquake-2.3.so.0 is not a symbolic link"

Is libearthquake in unstable?

Re:Where is...

[palegray.net (1195047)]

You've got it all wrong; you should be using built-in tools like these:

more weather - For when you need a new update.

less weather - Got too much weather? Reduce it!

vi weather - When you want to change the weather.

emacs weather - When you want to change the weather on 15 separate planets at once.

cat weather - It's raining... oh, never mind.

Re:

[Stormwatch (703920)]

Microsoft Weather - seems to be a very fine weather, but all of a sudden it may turn into a hailstorm.

Re:Where is...

[gbobeck (926553)]

Did you enable the "Universe" repository?

Re:hmm

[Lehk228 (705449)]

that would be HURD

Re:

[FudRucker (866063)]

since it is a cluster that would be correct, a herd of hurd...

Re:hmm

[JohnBailey (1092697)]

More importantly, is it Vista capable?

Yes, but only home basic.

Re:Debian?

[ketamine-bp (586203)]

i would suppose that debian is quite a versatile distro for any purpose...

-- from a debian user... who actually started quite late with potato....

Re:Debian?

[rucs_hack (784150)]

Actually I don't like Debian much as a desktop machine, but I love it as a number cruncher OS. I've had a 10 machine openmosix cluster going for several years now, problem free.

Stability is a major thing with Debian, and my experience has been that this is quite true.

Re:Debian?

[jonaskoelker (922170)]

you shouldn't be running anything but compiled source on a performance cluster.

you wouldn't be running anything but source compiles on a performance cluster. :p

Re:Debian?

[Bronster (13157)]

The binary package management really says it all.. you shouldn't be running anything but compiled source on a performance cluster.

Wow - how many performance clusters do you run again?

Not that I run a "performance cluster" as such - but I do run a bunch of machines that are very busy, all on Debian.

You know what? We compile the couple of programs where CPU is the bottleneck from source. We also compile Cyrus IMAP from source because we apply a pile of patches, but if someone else was packaging up all those patches in upstream, I'd be happy for them to be compiled there. Disk IO is the issue with Cyrus, and a custom compile won't help with that.

Yeah, we build our own kernels as well - that's another point that's worth the effort to customise. /bin/ls though? I don't think it matters to anyone on a high performance cluster. Just so long as the cluster apps are optimised then the rest is just noise - better to have a system that's less work for your administrators so they can concentrate on what's important.

Re:Debian?

[SuperQ (431)]

Exactly, My job is running high performance computing clusters. You don't need to put much effort into your cluster distribution at all. As long as it's stable, and gets the job done, why mess with it.

The things I (and my co-workers) put a lot of optimization effort into is the kernel and our apps. You're exactly right.. 99.9% of our CPU cycles go into getting work done, and that 0.1% used by /bin/ls don't matter a bit.

Re:

[street struttin' (1249972)]

I agree. I used to run some clusters for the UCLA Chemistry department and the only real customizations we did was to install a custom kernel in Redhat 9 to handle the huge amount of memory we had installed. And even that wasn't in all the clusters. But yeah, the code the clusters was actually running was pretty much always compiled by hand.

Re:Debian?

[AvitarX (172628)]

the code the clusters was actually running was pretty much always compiled by hand.

You really oughta use a compiler for that.

Re:

[Apro+im (241275)]

Hmmm... 0 to Gentoo/Slack fanboyism in like... 4 comments.

I know people who know a fair amount about running clusters. None of them want the headache of dealing with the random-ass unexpected conflicts that arise out of having the explosion of possibilities for custom compiling for each server. Also, nobody wants to use their precious "performance cluster" cycles compiling every update. If you really need to compile tweaks (for the important stuff only), you do it offline, once, and then build a *binary*

Re:Debian?

[indifferent children (842621)]

Give the guy a break. He just wanted to see Gentoo compile in less than 2 weeks; he had a cluster handy...

Re:Debian?

[TheWanderingHermit (513872)]

Actually, Debian is intended for servers and runs on more architectures than any other distro. The whole reason for the long testing cycle on Debian is to make sure it's as stable as possible so it can sit on a server and need little or no attention for days, weeks, or even months at a time.

I hated Debian at first because it wasn't friendly, but I looked into it more and realized it was the best choice I could make for my production servers. I can set them up and check once a week or so and they're still chugging along without need of intervention.

I wouldn't use Debian on my desktop (I use Kubuntu), but it can't be beat for servers.

It's NOT a desktop distro. Especially compared to Mandr* or Ubuntu or many others out there.

Re:Debian?

[Thijssss (655388)]

Debian works out just fine for these kind of tasks. Here in the Netherlands the national compute cluster Lisa runs on Debian (http://www.sara.nl/userinfo/lisa/description/index.html) with 800~ to a 1000 nodes (I think the page needs updating by now).

Re:

[chthon (580889)]

Every time I want to install Ubuntu on some random machine, it fails. I always have to go back to Debian.

I have Debian currently installed for my father and my sister. Spares me the headaches of Windows problems. The only support I need to deliver to them is giving information about performing tasks.

Re:Debian?

[gd2shoe (747932)]

Debian, like most distros, is what you want it to be. Debian is used regularly as a server OS.

I doubt they have X installed on these machines.

Re:Debian?

[gullevek (174152)]

Debian is sure not a desktop distribution. Ubuntu would be one. I run Debian on all my servers.

Re:Debian?

[wellingj (1030460)]

I don't get why every one is saying it's not for desktop. It runs great on my T60. Everything works fine: sleep, mouse, red nub, wireless, sound, screen brightness, Blue-tooth. I guess I have never used the media buttons...

Re:

[GigaplexNZ (1233886)]

They never said it can't be used for desktop. They are just saying that it isn't primarily aiming for desktop use and works very well on servers, debating the original posters claim.

Re:

[gullevek (174152)]

I never said it doesn't work on a desktop. I use it here on mine right now. It's just not as easy to setup as Ubunutu I think.

Re:

[EvilIdler (21087)]

Nope, it's one big, happy family :)

Re:Debian?

[mortonda (5175)]

Why Debian? A desktop distro? That's got to be one of the least scalable and cluster-friendly distros..

Keep going, I was expecting to hear you claim Windows XP was a server OS next...

Not sure why you call Debian a desktop distro, it's much more useful as a server.

Re:Debian?

[rolfc (842110)]

You obviously doesn't have a clue about Debian. Debian has been a fine server since 1995, and I still choose it before RHEL anyday. I have always found it strange that everyone went for RedHat, when they could have Debian. Mark S. saw the advantages of Debian and based Ubuntu on it, Ubuntu is a server and a desktop distro, based on Debian. It has made more people realize the strength of the Debian approach.

Re:Why debian when you can have Slackware?

[rolfc (842110)]

You customise absolutely everything yourself in Debain too, but when you have more than 50 servers running, thats not what you want. In that situation you want something dependable, stable that let you do other things. In Debian you don't ever have to reinstall, you just upgrade. I started out with Slackware, if I remember right, but since I started using Debian in 1995, I have not seen a better server,and during that time I have used quite a few. No one has served me better than Debian.

Re:Debian?

[Simon Brooke (45012)]

Why Debian? A desktop distro? That's got to be one of the least scalable and cluster-friendly distros. If they would invest a little to set things up properly they could get a lot more performance out of their machines.

Debian isn't - and never has been - a desktop distro. If you want a desktop distro built on Debian architecture, you get Ubuntu, or Knoppix, or one of a dozen others. Debian's unique selling proposition is a combination of stability, which is very important to production servers, and a rigorous commitment to free software. Packages don't make it into Debian Stable until they have been thoroughly tested. Debian also has the best package management system in the industry.

Frankly, I wouldn't run a server with anything else.

Re:

[427_ci_505 (1009677)]

While Ubuntu might be friendlier, and be more polished, I'd like to say that Debian is perfectly workable as a desktop os. (Started with a base install that didn't even appear to come with less, moved onto fluxbox when I wanted a gui, moved back to kde because I missed it).

It just takes a little more effort if you do something pointless like start out with just the min install.

Re:dent in the budget

[TheWanderingHermit (513872)]

Sure. Add in paying for tech support or the cost in man-hours it takes to keep it running. Both can make a serious dent where nobody expected to see one.

Re:

[by Anonymous Coward]

I'm sure that if they can manage an ancient SGI supercomputer, they can easily manage Debian. I've been using it since woody, and I must say, compared to many other distros, Debian is easy to manage. Not only that, its reliability is second to none on the Linux platform. I have a machine that's been running the same Debian install since the days of woody, all up-to-date with Etch. Not a single problem with it, runs a lot better than an XP desktop I have, which has needed 2 reinstalls in the past year, o

Re:

[SgtChaireBourne (457691)]

Sure. Add in paying for tech support or the cost in man-hours it takes to keep it running. Both can make a serious dent where nobody expected to see one.

That's the big attraction for Debian. For a production system, support tasks drop to almost nothing. It's there. It runs. If and when a patch is needed, it is just that - a patch - and not any weird licensing changes or mutations in functionality.

Of the linux distros, it's an excellent choice for servers, perhaps the best. Given the rock-solid nature, it can be good for enterprise desktops, if you are willing to plan. However, Kubuntu LTS meets that need.

Re:

[darthflo (1095225)]

I guess he isn't referring to licensing costs for the various distributions not putting dents in his budget but rather the operating costs of their new cluster as a whole. The SGI machine seems to have dented the budget pretty badly while replacing it with a Linux (beowulf?) cluster polished those dents out to the extent of them being able to test various setups in addition to their cluster and still have a smoother budget.

Also, their supercomputer may just be outdated, not necessarily because of bloated

Re:

[dwater (72834)]

Also, their supercomputer may just be outdated, not necessarily because of bloated software. I don't know how well SGI's products and support survived their recent bankrupcy, but I'd imagine not too well (though they seem to have built the Xeon-based #3 from the Top 500 recently).

AFAIK, SGI still supports IRIX computers, but it doesn't do new ones - hasn't for several years. They do Linix of course - looks [sgi.com] like you can have SuSe or RedHat - and they also do some Microsoft thing too. I'm sure SGI could have serviced this customer, but they clearly didn't want to pay for support. You get what you pay for, and SGI still have very smart/clever people....

Re:

[onebuttonmouse (733011)]

Perhaps they mean it is scalable in the sense that one could simply add more machines to the cluster, rather than adding more cores to the machines already in place.