The Splunk reference architecture is a good place to start -- http://docs.splunk.com/Documentation/Splunk/latest/Installation/CapacityPlanningforaLargerSplunkDepl.... Except, there's no real mention of SAN storage there. Remember, Splunk is very highly I/O intensive - like an enterprise OLTP database. Splunk recommends RAID-10 for storage because of the higher IOPS available there, compared to RAID4/5/6. The typical Splunk indexer "building block" does not use SAN storage, but rather has a number of fast local disk in RAID10. If one indexer "block" cannot meet your performance, add more -- each with its own local storage. ( http://blogs.splunk.com/2009/10/27/add-a-server-or-two/ ) In everything but the largest deployments, this is far more cost effective than using SAN storage with Splunk.
But if you already have the NetApp storage on the floor, then there is no reason NOT to use it -- that is, as long as it has the available IOPS capacity to meet the needs of your indexing workload. (And, you'll need to make sure that providing that IOPS capacity does not negatively impact other systems using the shared storage.)
In terms of simple partition/filesystem layout - what you're discussing makes reasonable sense. We give Splunk two filesystems - one for the product (code) and the other for the indexes.
