The answer to IO problems is usually not disk but memory. How much memory do you have and what is database size ?

Disks are also important for writes and for databases which are too large to well fit in memory. In this case I think SAS is best solution. If you need more than like 6 disks you easily get directly attached you may think about having data partitioned into multiple servers as MySQL may not be able to load a lot of drives efficiently.

The databases are not large, under 1GB. A large portion of the traffic is consumed by Cacti poller output on a five minute interval. This data is dumped in, then pulled out to generate rrd files actually used by cacti. I have considered migrating this MyISAM table to a memory table as I believe this would help greatly, however I have been leary of doing so as it includes a text column that I would have to migrate to some other type to do so and I need to ensure that I will not be truncating or otherwise mangling the data in that field.

Also this is not a dedicated server so I have to be careful how much RAM I am consuming with MySQL.

Also, I am running replication so there are the binary log writes to consider as well.

I am trying to size and choose appropriate hardware for a new dedicated MySQL server to handle this current load (with a projected double to triple current levels) and hopefully have the capacity to handle Alvaristar (Alvarion NMS system - recommened to run on Solaris w/ Oracle) at least initially. We will continue to use replication.

Capacity isn't the greatest concern as I don't foresee this growing beyond 30-50GB at any point in the near future, however HA and io performance are.

Well. For your current load you do not really need much of the IO bandwidth.

Regarding 30-50GB database size It surely depends on the load but generally I'd be looking at server with 16GB of memory and some 6 hard drives as a good one from price/performance standpoint these days.