Scenarios
 
|
|||
 | |||
|
|
|
|||
| |||
|
In our research on how to characterize different real-world storage applications, we found that storage scenarios vary in three regards: the relative percentage of storage requests that are reads vs. writes; whether disk access is random or sequential; and the typical file size. Based on this information, we developed five scenarios for this comparative testing.
In our first file-server scenario, we designed the server to imitate an application server, such as an e-mail or file server, that conducts many, typically small, reads and writes continuously. This scenario is characterized by 80% reads, 20% writes. File size is fixed at 4K bytes, and disk access is random in all cases. This scenario tests how well small files can be served across a Gigabit Ethernet network vs. a Fibre Channel SAN.
File server scenarios (graphics)
Back to the review
The cumulative data-transfer rates achieved in this scenario are relatively scant - less than 1M byte/sec. This is the impact of moving fairly small files, running a mix of reads and writes and using random disk access, all of which tend to slow things down. In this scenario, data-transfer performance for all three storage environments is fairly comparable. It is only when five or more servers are collectively accessing the disk storage that the SAN environment provides slightly greater aggregate throughput. A SAN might be a slightly better choice in this type of scenario, but only if you expect to have multiple servers concurrently accessing the same disk storage.
Our second file-server scenario was similar to the first with one exception. Rather than fixing all the file sizes at 4K bytes, we also included larger file sizes as 10% were 8K bytes and another 10% were 16K bytes. This scenario tested how the storage alternatives compared with some larger file sizes added in.
Our tests with this scenario showed that, as file sizes increased, data-transfer throughput also increased. As with the first file-server scenario, though, there was no clear winner between NAS, SAN or local SCSI disk. It's noteworthy that, even with five servers collectively accessing the same disk storage, only 1% to 2% of the Gigabit Ethernet or Fibre Channel bandwidth was used. This means the transport capacity of Fibre Channel and Gigabit Ethernet is huge.
In our third scenario, one, two and then five Web servers were serving the same set of Web pages and files. All disk operations are reads; all disk access is random. File sizes were variable, ranging from 20% very small (512 bytes) to 10% fairly large (128K bytes). This scenario showed how well Web pages can be served over the different storage/transport options.
We were surprised with the results of our testing with this scenario. Given random-access retrieval of a range of file sizes, data-transfer rates achieved in the NAS environment clearly outperformed the SAN. Indeed, the NAS throughput was roughly double the SAN throughput in all cases. And despite the hype concerning the throughput speed offered by SANs, it was surprising to see Gigabit Ethernet perform so much better than Fibre Channel SANs in any situation.
In our fourth scenario, one, two and five video servers delivered streaming video. As with the previous scenario all disk operations were reads. However, all disk access here is sequential. The same 64K-byte file size was used in all cases. This scenario tested the relative performance of serving streaming video over the different storage/transport options.
When comparing the video server scenario with the results of the Web server scenario, we saw the opposite result. With sequential disk access to large files, and consistent, fairly sizable files, the SAN environment outperformed the NAS alternative by a considerable margin - from more than double for a single video server, to nearly four times the throughput when five video servers were reading the same disk files across the SAN or NAS. In the case of five video servers, the cumulative SAN throughput, 47M byte/sec, tapped roughly half the Fibre Channel SAN's bandwidth. These tests indicated that if you are going to serve large amounts of video from a shared-storage node, your best bet is a SAN deployment.
In our final scenario, one, two and five application servers were writing folders and directories to the storage target in large, 1M-byte files. All disk operations were writes, and disk acces
was 100% sequential. This scenario tests how well large files are transported and written sequentially to a back-up storage disk, emulating server backup to tape.
In this scenario applications servers were writing massive amounts of sequential data to a storage target's disk. In the NAS and SAN environments, it seemed the maximum disk-write-throughput point might have been reached because the storage data-transfer rate did not increase with two or more servers, compared with a single-server initiator. With the Hitachi 5800 disk array in the SAN environment, the peak we reached was about 30M byte/sec; with the Compaq NAS server the write capacity to a single disk peaked at about 5M byte/sec. The specialized SAN storage node clearly outperformed the off-the-shelf server acting as a NAS node in our test bed. We don't know how well a specialized NAS device would have fared by comparison, but given these two storage nodes, the SAN alternative delivers much better performance.
The SCSI option did well here, for backing up a single server. Indeed, performance was comparable to doing backup over a SAN. However, a key motivation to doing a backup in the first place was to create and maintain a copy of a server's data in a location where it would be safe if something took out the server. Local SCSI doesn't accomplish that end.
