| IBM's storage challenge | |
| 17 August 2007 Last week, I decided my antique Pentium IV desktop PC was getting just a little too aged. Strangely, I only realised quite how old it was after I had used a friend’s machine for a couple of days. The difference in speed between his machine and mine was stunning. I realised that it was time to climb back up the performance hill and equip myself with a machine more representative of a man of my needs. In the past, I have always tended to buy new computers from fairly safe sources (IBM, Dell or Acer, mostly), but this time I decided to don my propeller head and build my own system. I don’t play computer games, but I do indulge in software development tinkering (I am playing about with Python at the moment, but that’s a different story), so I wanted something with a bit of wellie behind it. After reading about 4kg of incredibly boring magazines to bone up on the latest PC fads, I shelled out for an Asus motherboard with an AMD AM2 processor socket, an AMD Athlon 64 X2 dual core processor, 2GB of RAM and three 250GB SATA hard drives, all of which I installed in my existing PC case. The motherboard is really pretty sophisticated and offers a built-in RAID controller and hardware anti-virus protection. I installed the three drives as a RAID 5 set giving me effectively 500GB of RAID-protected very high speed storage. The whole lot came in at less than £400, including a reasonably fast nVidia graphics card. Quiet runningSo now as I type, I no longer have to wait while word auto saves my work and, on top of that, the machine is now several decibels quieter which is an added bonus. In my home office I also have an old Pentium III machine with two RAID 1-protected 500GB drives in it. The machine runs FreeNAS, which is a Linux-based headless operating system that turns any old PC (Pentium I or better) into a very effective network-attached storage device. FreeNAS implements Samba, which allows it to operate as though it were a Windows file server and my Windows XP desktop connects to it as though it were running Windows Server. I think it cost me about two hundred and fifty quid for the drives in the FreeNAS box, which basically gives me a local back-up server (it is also a print server) that reduces my exposure to system failures. ‘So what?’ I hear you all ask. Well, it occurs that I could just as easily have installed three 750GB drives (costing roughly £150 each) to give myself more than a terabyte of RAID-protected storage – in a desktop. What’s moot is that in my home office I handle enough electronic data to demand and even justify half a terabyte of secure storage. Ten years ago, that would have supported the needs of British Gas’s entire billing system. I am not alone. Companies nowadays generally have much more laid back archiving policies simply because hard disk space is relatively cheap. Many more companies warehouse their data to become rich mines that can add serious value to the business. The upshot of all this domestic industry is that for less than a grand I have availed myself of something like two terabytes of reasonably safe storage and from where I sit a price of £500 per terabyte could be a benchmark that suppliers should try and aim for, or could it? I have demonstrated that storage is not complicated. Nor is it particularly expensive, but, as with all things, you get what you pay for. My freebie NAS server is exactly that; a server that hangs off a 10/100 network connection and deploys a lamentably slow application level storage management protocol (CIFS). It is perfect for backing things up to and for storing files on, but you couldn’t deploy a remote access database over it (well, you could, but it would be as slow as molasses in winter), so perhaps storage is just a bit complicated after all. In the past, we haven’t had to worry about storage in the System i world. We phone up our friendly System i supplier and order all the DASD we need and i5/OS just adds it all to the common pool seamlessly and pretty well as much as we want. But times have changed. Few System i users operate only System i technology. Most of us also operate some Microsoft server technology and possibly some flavour of Unix as well (and if you don’t think you do, then I presume you have no firewalls or routers). Managing data can become a massive headache and only the System i seems to do it right. You see, whereas my NAS server handles data at the file level, the System i manages data at the block level, which is much, much faster. By the time my NAS server has found the file I’m looking for, the System i will have delivered the contents of the file ten times over. Enter the SAN. SANs serve a single purpose: fast, secure storage. From a design philosophy their raison d’être is to eliminate direct attached storage. Instead of each server having internal hard drives, the server looks to the SAN for all its storage needs (including a bootable operating system). By providing high-speed direct access storage, a number of things become possible. First, the whole back-up operation becomes simpler; instead of each server being backed up at night, the whole SAN is backed up continuously, so from a data maintenance perspective there should seldom be problems with the quality of working data. If you are managing a lot of servers, the cost of protecting your data can become prohibitive, so the attraction of a single centralised back-up scheme can be quite powerful. Moreover, by moving data from servers on to a common storage pool, the data can be made much more accessible. From a disaster recovery point of view, if you operate a heterogeneous complement of server technologies, SANs are the proverbial mutt’s nuts. It is a fairly simple matter to establish ‘business continuity volumes’ over a SAN infrastructure that effectively establishes a high-availability framework that can be built over remote redundant systems (fibre channel, the networking topology used by SANs, can commonly handle up to 400MB/sec over large distances – anything up to 300 miles). Distributing data around a network can be difficult to achieve satisfactorily. In a typical LAN, each server will support its own dedicated storage devices. This, of course, means that if the storage on the server gets filled up it will be necessary to either replace or exchange the server’s hard drives. This is of itself not a problem, but it is inefficient. It makes sense that for every server full of data there will be other servers that have very low data utilisations. Clearly, if we can arrange a common pool of data then the purchasing of storage can be rationalised on the basis of an efficiency model. Another drawback with locally attached storage is exactly that – it is locally attached and if a client (PC/laptop or other server) needs access to any given data, it must go through the server that controls it and on larger more complex systems this can become an issue. It is almost always the case that access performance will be inconsistent, particularly if there is high demand for access to the device. Most office 10/100 networks operate at 100MB/sec. This might seem like a veritable torrent of streaming data, but actual throughput can be much lower when traffic becomes an issue (add more than one conversation to the network and traffic becomes an issue). In lab tests conducted by the University of Aberdeen some definitive network performance figures were obtained and their results showed data throughput on a busy 10/100 network can drop to as little as 3MB/sec. You see, Ethernet is designed to be a shared medium, so it cannot be guaranteed that a client will have exclusive access to the connection. As more clients access an Ethernet network, data collisions start to occur and when that happens network controllers tend to head for the hills by introducing random access latency to avoid the collisions. In a SAN, there is no server sitting between the storage devices and the network. Instead, the storage devices and servers are linked directly to the network via a switched fabric that guarantees consistent performance. Fibre channel vs iSCSIAll this wonderful technology comes at a cost, but as with all things IT, Moore’s Law consistently prevails and the cost of SAN technology is now approaching tolerable levels. Many pundits have argued that if you want to move your data off the server, but still maintain high-access performance (crucial for data-intensive transactional systems), fibre channel (FC) is the way to go. Up until a couple of years ago I would have agreed with this argument, but not now. With FC’s high performance comes a correspondingly high cost. Fibre channel is expensive to buy, implement and maintain but, fortunately, there are real credible alternative technologies and with recent improvements in the performance of iSCSI and Ethernet, the commercial viability of FC (based on its current high costs) must be questioned. Critics of iSCSI have traditionally gloated when iSCSI-based SAN systems demonstrated drastically slower performance than FC. The difference in performance has been down to two issues. Firstly, iSCSI is a TCP/IP Ethernet-based offering and the overhead added by the TCP/IP protocol to the communication between client and storage can be significant. Secondly, the performance of the connecting fabric (Ethernet) has been an issue, but things are changing quickly and to the point that many people in the know believe the days of FC are numbered. More remarkable is the fact that Ethernet can now be made to offer higher native speed than FC (10 gigabit Ethernet is close to being widely launched). If we take all this change in the context of the System i, things start to look exciting. The release of iSCSI host adapters for System i last year opens a new world that allows a System i operator to consolidate data from all resources on to the System i and, in return, with the availability of virtual data pooling, the System i should be well positioned to access offsite data as quickly and effectively as any other server. Making ConnectionsIf a System i was connected via iSCSI or FC to a SAN, then things like the Virtual Tape offering introduced in V5R4 would start to deliver handsomely. Smart observers will realise that within a year from now the System i will be available as a part of a POWER6 BladeCenter offering which will deliver the most ‘SAN-ready’ System i to date and, given that BladeCenter can support FC as well as Ethernet/iSCSI, it seems likely that IBM is re-positioning the System i to become a part of a heterogeneous data pool system that will be capable of coalescing with Windows and Unix/Linux technology. The degree to which IBM allows the System i iSCSI capability to grow will become an important area to observe closely – if IBM tries to emasculate the technology by introducing all sorts of proprietary restrictions or conditions it will be neither use nor ornament. ISCSI-based SAN infrastructure will be the next big market opportunity in the midrange market space. The opportunity to harden systems against fault and failure, reduce data ownership costs and simplify the technical issues surrounding data management will be too appealing for many to stay loyal to an un-cooperative platform. Mark my words, IBM must get this right. The System i must be made capable of operating either in or on a SAN infrastructure without introducing restrictions or costs that are purely profit-based. Today I can buy low cost, low tech network attached storage for £500 per terabyte. Personally, I would be prepared to pay more than perhaps five times that for high-speed, highly reliable, highly accessible common storage. Moore’s Law tells us that my £500/Tb benchmark will drop to roughly £250 by this time next year and so it will be in the commercial world – while a 2Tb SAN might have cost £50k five years ago, it’ll set you back perhaps £10k today (look at Microsoft and Hitachi’s ‘Simple SAN’ offerings). IBM is on the cusp of some serious changes – let us pray that it doesn’t get it wrong. | |
