From a virtualization perspective, it doesnot matter (much) whther you have a single pool or several. Definately do not need a pool per requestor, that causes isolated pools, less flexibility, lower performance per requestor (you can't share the performance potential of a larger pool) and gains you nothing form the virtualization perspective. You are right - the oversubscription is at the pool level. With Virtual LUNs, you give a notional LUN size, and the sum of those notional sizes can be reported to yuor client who wants 30 TB for example. The actual storage in realtion to that can be much smaller.  So, what should determine the pool count? Basically, use of advanced features and failure domains.  Some advanced features will be activated at the pool level. A current example is FAST Cache - it's on for all LUNs in a pool. But not all LUNs will benefit from FAST Cache - your TC can ask for an analysis to tell you which ones those are. So you'd want a pool for FCache-hostile LUNs (your archives, backup targets etc) and another for your FC-friendly LUNs  Failure domains: This is behind the best practices guide's recommendation for max disks/pool - those are rough guidelines to keep your storage split into at least a couple domains. For instance, DBAs may demand that their logs are not on the same disk pool as their tables. Pools are very robust, but there is a small possibility that you'll see an outage in the lifetime of your storage due to multiple disks/components failing, but if you do, a failure domain strategy will really pay off. In a small system like the '120, two pools. In a larger system like the '960, 4 or 6 make sense.  A for Celerra, it does not yet support a Tiered pool.
Hello, I will try to keep this brief as possible. I am having a hard time finding doncumentation addressing some of the changes in regards to the latest Flare 30 along with Unisphere. While some things I stagger in the dark until I just finally figure out where things are now. There are two issues that I am needing clarificaiton on still.  1. I was having a discussion as to which is better to have in our environment, either one huge volume pool consisting of mixed disk speeds and types (FC, SATAII). Or multiple volume pools based on clients needs. My way of thinking has me wanting to create multiple volume pools in order to better leverage the storage virtualization aspect. For instance, one client claims that they need 20TB of storage. I'm inclined to create a volume pool of 20TB for them with multiple thin LUNs and let them see that they have their 20TB when in fact they don't of course. They will utilize what they need and it will continue to add raw storage from available disks not used yet. The same goes for other clients as well. Well, my colluegue's argument is that we should have on one giant volume pool (minus the RAID Group0 for the Vault) and just carve 500GB LUN chunks as needed from that pool to clients. Both of these methods we'll include storage groups to isolate clients. He says this is better because if we have one client that request 20TB of space and we create them a volume pool of 20TB, and then another asks for let's say 30TB and we only have a total disk capacity of 40TB on the array, then this is not going to work because we don't have enough storage to create that additional 30TB. The part that I fail to see is how having one huge pool would be more beneficial than having multiple ones. Is it not the Volume pools that have the ability to be over subscribed anyway and when additional storage is needed it will automatically extend from unused raw space? I understand that the client doesn't see the volume size but only what LUNs we present to their hosts. So I don't know, maybe it doesn't matter because regardless I'll be creating several LUN's to make up what storage they need, placing it into a storage group and presenting it to the ESXi 4.1 hosts. It is the VMware admin that will present it as one big datastore to the client anyway i guess. I'm just trying to figure out the "NEW" best practices since a lot of rules and restrictions have changed with this Unified approach.  2. This leads me to my next issue I ran into. My collegue tried to present a LUN created from the giant mixed volume pool and no matter what he couldn't get the Celerra to see the volume. When I looked into it I noticed that the LUN had mixed tapes and because it was carved out of the mixed volume pool there was no option to see the disks types. So I created a new volume pool consisting of only one disk type (SATAII in this case) and once I rescanned in Unisphere the Celerra saw it right away. Is this still a limitation for the Celerra even in the Unified approach? Does the volumes presented still have to consists of the same disk type?  Here's a quick run down of what our little test environment consists of. (and yes, this is a lab to play in so aside from blowing data away we can make any necessary changes).  1. CLARiiON CX4-120 - Flare 04.30.000.5.005 2. Celerra NAS NS-G8 - DART 6.0.36-4 in access gateway mode with only 2 blades. 3. Unisphere, ThinProvisioning, SnapView, SANCopy, AccessLogix 4. FC and SATA disks 5. Two DCX-4S's 6. IBM H Chassis Blades with Brocade BIM's running access gateway 7. ESXi 4.1 Environment 8. PowerPath/VE  We are not using FAST technology. Unfortunately that's a budget issue for us. [IMAGE]  We are not currently booting from SAN however... I was just informed recently that our VMware guy wants to test it out to see how it will work in our environment. So, I don't know if you see any pitfalls going forward should we try doing boot from SAN. It's a test environment so this is the place to break everything! LOL. Any help or advise is greatly appreciated. Thanks.  **Please forgive the run-ons and mispellings. Busy, busy, busy so I didn't proof read.  Rashid
Two questions in regards to our SAN approach