The reason is that the cluster is built as an active/active cluster and so each controller must have a root volume, thus each needs a trad vol or 1 aggregate. So the "active/passive" config isn't truly active/passive, it's just functionally so.

There is no way currently to automatically float a spare. You could manually change ownership of a spare disk, but it doesn't do this automatically. ONTAP will whine in the messages file if there are no spares, and you will probably want to up the raid.timeout option to give you more time to move the spare over.

-- Adam Fox Systems Engineer adamfox@netapp.com

-----Original Message----- From: Ray Van Dolson [mailto:rvandolson@esri.com] Sent: Tuesday, June 02, 2009 12:59 PM To: Steve Francis Cc: Page, Jeremy; Fox, Adam; toasters@mathworks.com Subject: Re: FAS2050C questions (clustering)

On Tue, Jun 02, 2009 at 09:26:17AM -0700, Steve Francis wrote:

You can get a performance boost by splitting it up. Which is why I don't like to do that, in general, for performance sensitive workloads. :-)

Otherwise, in the event of a head failure, the surviving head may not have the CPU/cache to deal with the extra work - even if both heads are normally under 50% load. Most workloads grow linearly - until they hit an elbow an don't grow

linearly.

The only true way to be sure you have failover capacity is to run that way all the time.

Your mileage/budget/workload/performance requirements may vary.

Thanks all. Great advice. So, my question is: if the second head can take over the personality of the failed head, why do I need to allocate any disks at all to the second head to begin with? Just a design thing?

I'll probably do the even split thing.... and look into ordering additional NIC's.

Can I have a "spare" that is available to either aggregate on either filer? This way I could do two RAID-DP's on each head with one common "spare" disk and rely on 4hr support to get me replacement disks quickly.

Ray

Be careful about runnning without a spare on each head. If the filer panic's you will not get the core dump unless you enable the 'wait until core dump writes to the file system before failing over' option. which then make failover take a long time and probably cause other problems.

I am not sure about the 2050 series but assume this is the same as the 3000 series.

Jack

Ray Van Dolson wrote:

On Tue, Jun 02, 2009 at 09:26:17AM -0700, Steve Francis wrote:

...

You can get a performance boost by splitting it up. Which is why I don't like to do that, in general, for performance sensitive workloads. :-)

Otherwise, in the event of a head failure, the surviving head may not have the CPU/cache to deal with the extra work - even if both heads are normally under 50% load. Most workloads grow linearly - until they hit an elbow an don't grow linearly. The only true way to be sure you have failover capacity is to run that way all the time.

Your mileage/budget/workload/performance requirements may vary.

Thanks all. Great advice. So, my question is: if the second head can take over the personality of the failed head, why do I need to allocate any disks at all to the second head to begin with? Just a design thing?

I'll probably do the even split thing.... and look into ordering additional NIC's.

Can I have a "spare" that is available to either aggregate on either filer? This way I could do two RAID-DP's on each head with one common "spare" disk and rely on 4hr support to get me replacement disks quickly.

Ray