In days gone by, there were only two ways of us scaling up on storage performance, both of which were reliant on – and directly affected by – the number of disks. Adding more disks to an existing pair of controllers, and adding more controllers [with their own sets of disks]. The second option is/was suitable on the assumption that your dataset which requires the performance, is able to be divided between separate physical devices (unless you use LVM-style tools to stitch volumes together, however these approaches don’t really allow you to drive linear performance).
518 total views
The funny thing here is that achieving certain levels of storage array performance (be it IOPS, throughput, latency or a combination) can be relatively trivial if you put your mind to it (expect a future post re array performance benchmark testing); chuck a load of things together, smooth off some of the rough edges, step back and marvel at the wonders of your creation. However, what happens if you then decide you want a bit more…?
514 total views
IQN Spoofing for unauthorised access to iSCSI storage volumes
In the world of iSCSI, we connect to storage volumes over Ethernet networks using SCSI commands wrapped up in TCP/IP headers. Conceptually, this is fantastic and simplifies life dramatically.
In order to connect to these storage volumes, we need to implement some form of LUN/volume masking. Typically, this is done using IQNs (iSCSI Qualified Names) as a unique identifier. However, this introduces a rather large security flaw as IQNs are not a unique identifier (in the same way WWNs, MAC or IP addresses are).
654 total views