« June 2005 | Main | August 2005 »
July 27, 2005
How much does that power really cost?
In an earlier blog Ade questions the need to spend fast sums of money on equipment that may be far more powerful than you actually need.
Thinking about cost savings further, what about the equipment you already own? I've recently read in PC Pro Magazine about a campaign they've started called Switch IT Off. The articles reveal some quite startling facts and figures regarding how much electricity is needlessly consumed every day.
For example a PC that spends most of its time idle will draw between 100W and 200W of power and could cost around £100 per year to run. If that same PC is running SETI@home or dare I say it the MARC21 conversion screen saver currently doing the rounds at Talis, the cost suddenly leaps to nearer £200.
The argument for staff turning their PCs off before they leave the office at night suddenly becomes quite compelling.
And it's not just PCs. Think about all those peripherals, the printers, the scanners, and the monitors all of which consuming needless electricity.
According to PC Pro an average 50-person business could shave £5,000 off its annual electricity bill by implementing a 'Switch IT Off' policy. I wonder how many Universities and County Councils have these policies in place?
At Talis nearly all staff now have laptops so that they are able to work flexibly at home, in the office or at customer sites. Laptops while being less powerful have the added advantage that they also draw less power.
I strongly recommend you read the articles for yourself, by implementing such a policy not only will you be saving money but you'll be helping the environment as well.
Visit the Switch IT Off website for more details.
Posted by jimprince at 06:12 PM | Comments (0) | TrackBack
How much ‘power’ do you really need?
A while back I had a play around with the smallest of the Apple desktops the Mac Mini. On paper this looks like quite a weak machine with a 1.25Ghz processor, 256Mb Ram, and only a 40Gb disk. Still I gave it a go and after using it for a couple of days, I have to say despite the low spec it really didn’t hold me back at all, and for a typical days usage it did do the tick.
After the ‘Mac mini experience’ i started to explore some of the other options to see if I could build my own small server as an alterative to the mini. For the project I had specific media streaming role in mind, and it needed to small quiet and be pretty cheap to make it worthwhile doing.
A short investigation revealed a number of low power options that are emerging in the market place, a couple of interesting platforms that I thought were worth noting are the CE/Xpe/linux based HP thin clients over at (http://www.hp.ca/products/static/thinclients/), and the Linux or Solaris based Jbox from Via/Sun (http://www.igojava.com/products.htm) it’s orange! not purple :-). Also a mention has to go to the ‘build you own’ custom pc’s over at http://www.mini-itx.com/ if you’ve got 5 take a look.
The various platforms all had there merits and worked out vastly cheaper than a typical ‘server’, offering a solution that would suit users that didn’t need all the bells and whistles, but in the end they offered a similar spec to the mini for a similar price.
That’s when I came across another option based on the open source project unslung (http://www.nslu2-linux.org/wiki/Unslung/HomePage). The base for the server is a Linksys NSLU2 box, this is sold to be a small NAS server, but using the unslung firmware is transformed into a self-contained mini Linux server with a 133Mhz cpu, 32Mb of memory, and twin usb for expansion.
I ordered the ‘Slug’ and as soon a it arrived set about upgrading it with the unslung linux distribution, unlocked the cpu to 266Mhz, added a couple of 256Mb thumb drives for storage, installed Gcc, Perl, SSH and the Slimserver (http://www.slimdevices.com/) media steaming software I wanted to use.
I have ended up with a tiny spec server, much smaller than the original Mac mini I had in mind, yet still capable of steaming mp3’s, various radio stations and pod casts around my home. It’s ¼ of physical the size of the mini, a fraction of the cost, completely silent and meets all the requirements I started out with perfectly. It servers as a good example of how little you can get away with, if you spend a little time to remove unnecessary services and configure a small server for a dedicated task.
So how much power do you really need? Obviously that depends on what you want to do, but if the majority of your day is spent with emails, web based applications and few basic office apps, you can probably get away with a lot less than you think.
I guess what I’m saying is, if you are ready for an upgrade don’t just opt for latest 3Ghz+ monster, have a look at the alternatives out there and make sure what your buying meets your actual needs, not just what you think you need.
If you only need to run one or two services for a small work group have a look to see what can be configured to make them more efficient and take a look at some of the lower power server options you could run them on.
Configured correctly you should be able to make a cost saving not only on the purchase costs, but the backup costs, maintenance costs, and even the electricity costs to run the things. It really is worth looking into.
So next time your out looking for new kit, just think how much ‘power’ do I really need.
Posted by Adrian Mackey at 01:03 PM | Comments (1) | TrackBack
July 22, 2005
Disaster Recovery and Business Continuity
Last week Ateeq blogged about his involvement in a recent business continuity exercise in which he posed several questions "I wonder how many of your institutes have a full disaster recovery plan in place? How many are working on one? Does it include your Library servers, PCs and terminals, etc?" Recognising that business continuity and in particular security is key to most IT strategies this made me wonder if the people who are looking at this area of IT strategy have had the same experience as ourselves.
When we moved to this building 324 days ago one of the first things we started was a complete review of our Business Continuity and Emergency Preparedness Procedures. This soon expanded to be a full review of all our business risks and procedures.
We followed the classical business continuity model of analyse your business, assess the risks, develop your strategy, develop your plan, rehearse your plan.
So armed with this model we started the process of scenario based risk assessments the “what happens ifs”. At each phase we found that there were many things that could be improved to eliminate risks from being realised and applying the “fix as we find” approach seamed like a good start. Little did I know about how much work both physical and mental this would involve and once you find a problem how much it plays on your mind until it is solved.
We started from the outside of the building and worked our way back to the core IT infrastructure. Whether this approach was right I am not sure, maybe starting at each end and meeting in the middle would have been better. But we are where we are and after introducing a whole new Health and Safety policy, the associated emergency procedures, safe systems of work, a planned preventative maintenance programme, a whole new IT policy framework, increasing the resilience of our servers, introducing service monitoring with preventative alerting, full physical perimeter security and surveillance, secure offsite storage of key paper based information (I could go on) we find ourselves far better equipped now than when we started. But we are not there yet and our next course of action will be to start collocating some of our core services in partnership with some market leading hosting companies (but that experience is for another blog entry).
However to get back to the point my experience has been that this process doesn’t and shouldn’t finish, Business Continuity might be the label but it probes in to all areas of the business and every physical nook and cranny contained within it. There are always things that can be done better and we can truly learn from every incident and investigation. But one of my strongest observations has been that unless you actually take the time to look, you never actually see the problems and can walk past, under or over them without even realising and the most common, harmless object can become an incident waiting to happen.
And finally be warned, as you start to look in detail at the risks, as if by magic those risks are woken from their slumber to be realised just before the work begins to remove then. In some cases I’m talking hours, they know you know!!! So plan for the expected and the un-expected.
Posted by Kevin Worth at 03:57 PM | Comments (0) | TrackBack
July 15, 2005
Disaster Recovery
Disaster Recovery is a topic that's slowly creeping up the awareness scale in our community. Recently one of our academic customers had a test-run with their supplier and I was there for the Sybase part of recovering their Library Management Server. I arrived on site thinking "server room" so at first walked right past the trailers parked just outside the library.
I was quite impressed that between the supplier and their IT department they'd done an excellent job of recovering the Operating System configuration, file systems and raw disk slices for Sybase to use. A minor hiccup showed the importance of updating the disaster recovery information after database expansions, fortunately this was easily corrected as there was free space present on the disks. Next was the Sybase recovery, which started with putting back the master database. Fortunately save_master was running in the cron of this system so a quick recovery from /scratch/master was done, followed by patching up of broken devices and databases before a load. This turned out to be an interesting exercise as when you're at the system console, you don't have the luxury of being able to copy and paste, something I have got very used to lately. A better approach would be to have most of the recovery scripted and the script(s) placed in one of the areas of the system that will be recovered very early on.
I wonder how many of your institutes have a full disaster recovery plan in place? How many are working on one? Does it include your Library servers, PCs and terminals, etc?
Why not share your experiences in the Infrastructure Forums.
Posted by Ateeq Altaf at 04:27 PM | Comments (0) | TrackBack
July 06, 2005
Why wireless won't kill the Ethernet cable
Reading some of the articles in the computer press you'd think that wireless networking will kill off the Ethernet cable altogether. Indeed our Wireless implementation has been very successful, I'm connected via wireless as I type this, but in no way will it replace our existing Ethernet LAN.
Even with the advances in the 802.11 standard there is still a long way to go. There are a number of technical problems that need to be overcome, limited bandwidth, transmit power and interference to name but a few, not to mention the security implications.
The original Ethernet specification is more than 30 years old and people are still finding new and innovative ways to exploit the technology. Power Over Ethernet (PoE) is a technology that transmits electrical power as well as data over standard CAT 5 LAN cabling and is a good example of this. PoE currently has a limit of around 15 watts but it's more than enough for powering all the VoIP handsets in our offices.
As work continues on increasing the power provided, we could soon see the limit raised enough to power a laptop. The ability to power and recharge your laptop through an Ethernet cable is very appealing. Wouldn't it be nice to ditch that heavy power pack and universal travel adapter?
As far as I'm concerned both technologies have their merits and are both here to stay.
Posted by jimprince at 11:31 AM | Comments (1) | TrackBack
