So, if both filers in a partner pair retain their identities, does this suggest that in performance sensitive environments you would be better off with many small filer pairs than a few large filer pairs? I'm concerned with hotspots and the like.
Also, how are disks handled? Can you have asymmetrix configurations with one filer seeing some disks that the other filer doesn't see? For instance filer A would see disks 1-10, and filer B would see disks 6-15?
And if this is possible how does one compute the complete disk capacity for a cluster? Can you use the NodeWWN from sysconfig? How could a unique sum of all disks based on the output of sysconfig be done?
And thanks again for all your help. I've tried to read the documentation, but it doesn't step through the output of the commands or how to calculate certain things.
So, if both filers in a partner pair retain their identities, does this suggest that in performance sensitive environments you would be better off with many small filer pairs than a few large filer pairs?
That'd be ideal if you were concerned mostly about failure condition hotspots, but keep in mind that the more filers you have things spread out across, the more normal production hotspots you get (unless of course you have a way to uniformly distribute all production traffic....).
Also, how are disks handled? Can you have asymmetrix configurations with one filer seeing some disks that the other filer doesn't see? For instance filer A would see disks 1-10, and filer B would see disks 6-15?
You're thinking about this too hard. Design as if each were entirely independent -- even in a cluster, each filer has it's "own" disks.. There is an addition FC-AL adapter in each head that connects to the secondary loop of its partner's disk to provide access in a failure mode. The disks partner's can always be 'seen', but they are not available for use. ie:
Volume vol0 (root, zoned checksums)
RAID group 0
RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- parity 4.8 4 1 0 FC:A 17000/34816000 17366/35566480 data 4.9 4 1 1 FC:A 17000/34816000 17366/35566480
RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- spare 4.20 4 2 4 FC:A 0 17366/35566480 spare 4.19 4 2 3 FC:A 0 17366/35566480 spare 4.18 4 2 2 FC:A 0 17366/35566480 spare 4.17 4 2 1 FC:A 0 17366/35566480
Partner disks
RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- partner 3.0 3 0 0 FC:B 0 17366/35566480 partner 3.1 3 0 1 FC:B 0 17366/35566480 partner 3.2 3 0 2 FC:B 0 17366/35566480 partner 3.3 3 0 3 FC:B 0 17366/35566480
[...output abbreviated, so pardon any gaps you may see in numbering...]
Here, I have a loop to my partner's disks on HA #3, and my own disks on HA #4. If I were to need a spare, it would have to come from HA #4 -- even though the _may_ be a spare on the partner, its not available for my use.
(..and keep in mind that when the partner has failed over, that its still presented as a "virtual" independent filer, so while the disks would be available to the 'partner' side of the surviving member, the normal side of it still couldn't touch it)
How could a unique sum of all disks based on the output of sysconfig be done?
..you can derive it from the 'partner disks' section of sysconfig -r, but the simplest answer is to do it as if you were for two separate filers.
And thanks again for all your help. I've tried to read the documentation, but it doesn't step through the output of the commands or how to calculate certain things.
If you're seriously looking at this, talk to your sales rep. NetApp has labs with all this stuff setup that you can play with and break to get to understand it, and the SE's can answer most any question you throw at them.
..kg..