I’ve been off on holiday for a week (Spain as it happens), now I’m back. I’m pleased to say I didn’t think of storage once. Not true actually; the cars we’d hired didn’t have enough storage space for the luggage – why does that always happen?
So back to work and continuing on virtualisation. For those who haven’t read the previous posts, I’m presenting AMS storage through a USP. I finished the presentation of the storage; the USP can see the AMS disks. These are all about 400GB each, to ensure I can present all the data I need.
Now, I’m presenting three AMS systems through one USP. A big issue is how cache should be managed. Imagine the write process; a write operation is received by the USP first and confirmed to the host after writing to USP cache. The USP then destages the write afterwards down to the AMS – which also has cache – and then to physical disk. Aside from the obvious question of “where is my data?” if there is ever a hardware or component failure, my current concern is managing cache correctly. The AMS has only 16GB of cache, that’s a total of 48GB in all three systems. The USP has 128GB of cache, over twice the total of the AMS systems. It’s therefore possible for the USP to accept a significant amount of data – especially if it is the target of TrueCopy, ShadowImage or HUR operations. When this is destaged, the AMS systems run the risk of being overwhelmed.
This is a significant concern. I will be using Tuning Manager to keep on top of the performance stats. In the meantime, I will configure some test LUNs and see what performance is like. The USP also has a single array group (co-incidentally also about 400GB) which I will use to perform a comparison test.
This is starting to get interesting…