Windows hardware challenge draws on resources
Things get heavy
Project Watch: Microsoft 2008 Here's a question for you: what hardware does it take to run an entirely new, pre-release Windows operating system and 1TB-worth of SQL Server 2008 community technology preview?
This question seems simple to answer, but the challenge comes in locating the requisite hardware. One problem that always arises when using any beta operating system is: no hardware manufacturer will certify kit to run the new operating system before that operating system has reached its release code form, because last minute changes may interfere with the certification process.
But, while full certification is often a problem, behind the scenes, the hardware manufacturers are working closely with the operating system provider and often know what servers are going to be certified when the time comes.
How willing they are to impart this information varies between companies. The trick comes in tapping the right OEM: I didn't find IBM particularly obliging but Dell, on the other hand, was extremely helpful. So, we have a Dell.
The big question in these scenarios then usually becomes one of whether to go with a 32-bit or 64-bit architecture. Given the size of our data files the only answer was the latter. So we settled on a 64-bit Dell PowerEdge R900 with four, quad-core Intel Xeon processors running at 2.93GHz. That is essentially 16 64 bit processors. For RAM we settled on 32Gb and the disk space. To quote Rolls-Royce on the power output of its motor vehicles, our output was "sufficient".
The PowerEdge is a ferociously noisy beast with multiple fans. It's also a heavy one. Having shifted the machine around the building several times I was moved to bring in a set of bathroom scales and on discovering that it weighed six and a half stone I decided it wasn't shifting again.
We haven't done any benchmarking for speed as yet but it's very quick. At tick-over Windows 2008 Server uses 2Gb RAM and it's coping admirably with the load put upon it.
The setup has been running for about ten weeks as I write. It has shown the fabulous reliability that any modern server should. As I said in the last Project Watch about the software stack, short of making up some drama, there's nothing to report.
You know, Mark is quite right on this one.
In small organisations, which may be where Marmite Toast, AC and b shubin all work, the security for public facing websites may be handled by the database geeks. In more professional organisations the jobs are separate – the database geeks do the database stuff and the security team handle security.
So, the database geeks will never be handling the security anyway. In a pure development environment, behind closed doors, they just want security off; particularly when using CTP code for early development. As the application moves closer to production, then is the time to involve the security guys and start to worry about security.
It all depends how bright your people are. A big security switch is only a problem if it is misused. Dumb people can misuse anything, so does that mean we should remove all options from all software in case stupid people use it? I don’t think it’s a problem giving people a big switch, any more than its a problem giving them a DROP TABLE command. Some people will screw up with either. But the more tools you give an intelligent person, the more productive they are.
Mother is watching
The BRSSITS (The Big Red Security Switch In The Sky)
It is excellent that Microsoft has provided all this security stuff. In a production system it should be very carefully used. All of this is true.
But think about what happens in practice during development if we don’t have a BRSSITS. Nothing will work out of the box. The development guys simply want to test the spatial data types, not the security. So people dig deep, find all of the switches and set them all, individually, to the “Completely Unsafe” setting in order to get the thing working. Time passes, development takes place and the system moves into production.
Now, what should happen at this stage is that an entirely new production system is created – complete within a fully tested, secure environment. But suppose the development system is somehow, sneakly, moved from development to production status? (Whilst it shouldn’t happen, it does in practice as pressure is applied from the business side.) At that point, someone has to go through the system, finding all of the switches and resetting them. And this is the dangerous part. If one is missed you have a potential security issue.
You can probably see where this is going. If you use the BRSSITS, then all you have to do is to switch it off. Of course, everything stops working, but that’s OK because it forces you, at this point, to set up the security properly – in the correct way, by switching on only the bits you need.
Is it possible to forget to switch the BRSSITS to the ‘Safe’ position before going into production? Of course it is. The next question is “Which is more likely? To forget one HUGE RED SWITCH or to overlook an obscure setting, buried deep in the bowels of the UI?”
And remember, you did have to have that note from your mother before you invoked it. She’ll be patiently watching from the sidelines, making sure that you don’t forget. After all, that’s what Mothers do best.
Databases should not run on Windows...