asterisk users - May 2009 - New system for recording - SCSI, SAS or SATA?

I'm in the process of specifying the hardware for some new Asterisk
systems which will be running a substantial number of conferences
with recording.

I was wondering what there is to choose between SCSI, SAS and SATA
disks, in terms of performance for this kind of application.

I will be using dual drives with kernel-based software RAID1.

Any advice from experience would be appreciated!

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

On 1 May 2009, at 09:30, Tony Mountifield wrote:
> I was wondering what there is to choose between SCSI, SAS and SATA
> disks, in terms of performance for this kind of application.
SAS
> I will be using dual drives with kernel-based software RAID1.
Why not go hardware?

On Fri, 1 May 2009, Tony Mountifield wrote:
> I'm in the process of specifying the hardware for some new Asterisk
> systems which will be running a substantial number of conferences
> with recording.
>
> I was wondering what there is to choose between SCSI, SAS and SATA
> disks, in terms of performance for this kind of application.
>
> I will be using dual drives with kernel-based software RAID1.
>
> Any advice from experience would be appreciated!
How much is the client willing to pay ;-)

And how many concurrent streams are you recording.

RAID-1 won't give you any performance increase over a single drive, but at 
the same time has less performance impact than RAID-5 or 6, so pick drives 
that are fast - fastest are obviously 15K RPM ones, but they're also the 
most expensive. The transport to the drives is the next thing to look at - 
SATA is well established now and motherboard chipsets work very well with 
a moden linux kernel. SCSI's been round forever, but SCSI drives are 
expensive, SAS is relatively new and expensive, but should be as fast as 
SCSI.

Now I've not built servers with a view to mass recording myself, but I 
have built servers for other purposes that have needed similar 
specifications - taking multiple streams of data and putting them to disk 
(and getting them back again) - the biggest issue will be then number of 
streams - that'll result in head thrashing and increase the overall 
latency.

The other option is write to RAM disk, then spool to physical disk later. 
You'd need to arrange some mechanism to let the RAM to Disk process know 
that the file has finished writing - possibly by renaming it after the 
call ends or something... (same mechanism as .call files) then you can 
have many processes writing to RAM and just one process taking RAM to 
Disk.

A 1GB ramdisk will store over 36 hours of recordings at G711 rates. (Or 
one hour of 36 concurrent calls!) My puny Atom workstation can stream 1GB 
to disk in 25 seconds, so you're OK there.

Your maximum write rate is going to be goverend by the maximum number of 
channels you're taking - I work on 10 channels per Mb, so 100 channels is 
10Mb/sec and that's trivially do-able to a ramdisk. (a 1GB ramdisk will 
fill-up in 20 miuntes) 1000 channels - 100Mb/sec (or 10MB/sec) and I 
suspect asterisk will fall-over before the ram/disk subsystem does!

The fastest disk system I built could stream to disk at 280MB/sec and read 
slightly faster - Linux s/w RAID-6 to 15 drives on 2 SAS controllers (8 on 
one controler, 7 on the other) This was Dell kit and cost at the time just 
under ?14K. The processor was mostly idle all the time, given that the 
dual Gb ethernets on-board were barely used to capacity, in-theory it 
sould have supported both links going flat-out, but I never got a change 
to try it.

Personally, I'd probably stick to SATA and if you're recording a
smallish
number of streams (< 10?) then write to disk, but more, consider an 
interim RAM disk solution.

Gordon

In article <D4BC241D-78F9-41CB-B1A5-24D54B274BB1 at geekinter.net>,
Steve Howes <steve at geekinter.net> wrote:
> 
> On 1 May 2009, at 09:30, Tony Mountifield wrote:
> > I was wondering what there is to choose between SCSI, SAS and SATA
> > disks, in terms of performance for this kind of application.
> 
> SAS
Cool - thanks for the recommendation.
> > I will be using dual drives with kernel-based software RAID1.
> 
> Why not go hardware?
Familiarity, I suppose. Just using RAID1 for disk redundancy.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

tony at softins.clara.co.uk (Tony Mountifield) writes:
> I'm in the process of specifying the hardware for some new Asterisk
> systems which will be running a substantial number of conferences
> with recording.
>
> I was wondering what there is to choose between SCSI, SAS and SATA
> disks, in terms of performance for this kind of application.
Modern SCSI, SAS, or SATA drives don't perform differently because of
the interface type. You can't get 15kRPM SATA drives because the market
for those is too small though.

If you record 1 channel in Alaw, you need 2 x 64kbps disk bandwidth, or
16kB/s. If you record 1000 channels, you need 16MB/s from your disks,
which should be easily achievable with even the cheapest disks. However,
that depends on doing sequential writes. You can only do (best case) 120
random writes pr second on a 7200RPM disk without write cache, and you
can reach that limit with just 2 channels, if you have to do a seek pr
packet. The solution there is write cache; 1 second gives you 120
channels and 5 seconds bring you up to 600 channels.

If you are unlucky and the files are placed widely spaced on the drives,
the performance will be lower than those numbers.

So, to get decent performance from many streams, you need a lot of disk
write cache, either on the disk itself (with the risk that a power failure
destroys data), on the controller, or in memory. You can gain a factor
of 2 by going to 15kRPM disks, and another factor of two by doubling the
number of spindles (if you get the layout right). The Linux write cache
can be tweaked for this purpose, but again you risk that a power failure
destroys data.


/Benny

On 1 May 2009, at 12:16, Tony Mountifield wrote:
>>> I will be using dual drives with kernel-based software RAID1.
>> Why not go hardware?
> Familiarity, I suppose. Just using RAID1 for disk redundancy.
Software RAID does add a bit of overhead, however guessing at the  
specs of the rest of the machine I guess it will be fairly minimal.