-pause/resume would control the relocation action without reseting the tiering analysis data.

The built-in scheduler only supports one relocation window per day and it’s array wide.

With naviseccli, you can use the “…autotiering -relocation -start….” command and specify the poolid, how long you want it to run, and the rate (low/med/high). You would use CRON or Task Scheduler in a server/PC to issue the commands and build whatever schedule you want. Since the command is pool specific you can offset the relocations of multiple pools, or adjust each pool to it’s own quiet period, etc.

-opstatus for checking the current status of relocation

-stop can be used to stop it before the timer runs out if necessary.

Using this method you can have multiple schedules per day for each pool.

I looked into altering the relocation schedule with the CLI earlier and I could only find an option to turn it on or off, not to actually change the times or scheduled days for the job. Can you share the command you are referencing? I suppose I could set the job to run 24×7 and use a batch script to simply pause it when I don’t want it to run, if that’s viable.

I’ll definitely open an SR for a more detailed analysis, but I appreciate your comments. Your blog is great, I’ve read lots of useful information already. Thanks again for the reply!

I discussed this briefly with one of my local VCE peeps, and he informed me that for vBlocks, the rule is to make a single vBlock fully redundanct, so they use a minimum of two chassis per block. Cost no object, put two chassis in each block and only install the blades you need to meet the compute/memory requirements.

Of course, cost is usually a big issue in most environments, so throwing two mostly empty chassis into each block is probably a non-starter. In the 150VM example, I had a total of 6 servers across the 3 blocks. You *could* install just one chassis, add 6 blades, then connect each pair to a different storage array through a fabric, or directly from the fabric interconnects in the blade chassis. The problem here is that you lose the benefits of fault isolation since a chassis problem (rare I know) would affect all 3 blocks.

The least cost option that maintains fault isolation would be to use two chassis, install 3 servers in each, and treat each chassis like a fabric. Connect one server from each chassis to each array. Loss of a chassis affects 50% of the environment, loss of a storage array affects two servers (33% in this example). Over time you can grow by adding arrays and inserting additional blades. Cost effectiveness probably dictates a slighty different approach though. I’d probably play with the calculations to get the number of arrays down and increase the number of servers per building block.

Cisco UCS blades add a further wrinkle since UCS is designed for multiple chassis to share the same fabric interconnects. Further, UCS doesn’t really have good support for Direct Attached storage so you end up needing a fabric. Two Chassis and Two fabric interconnects would create a fully redundant environment. Then you need a fabric between the interconnects and the storage. Depending on long term growth projections, deploying two or more blade environments up front and growing into the chassis later may be just fine.

HP and Cisco offer chassis with only 8 slots which could help make small building blocks more cost effective. Last I checked, Dell and IBM still only have the 15/16 slot chassis but I’ll admit that I haven’t paid much attention.

Unfortunately, as much as I love blades, they may not be the most cost effective solution at small scale.

Hope that helps.

As far as per-LUN settings, if you set the policy on the LUN to “no movement”, the current distribution at that time will be maintained. The LUN will remain tiered, but will not be relocated during the daily relocation. Taking a look at which LUNs really need FASTVP tiering would be a good idea. If you have any LUNs that could sit in the lowest tier (ie: don’t need any higher performance than the lowest tier provides), then you could set them to Lowest Tier and they will move down and mostly stay there. This will free up space in the higher tiers for other LUNs as well as reduce the amount of data to be relocated over time.

It *may* help to run the relocation more than once a day, break it up into chunks. This can be done with a CLI based script and an external scheduler.

Also, there are some more recent recommendations related to data migration and other batch style activities that may cause unnecessary movement, FASTVP can be effectively paused for periods of time if you have such batch jobs.

You can open an SR about performance and note that your relocations are not finishing.

I’m curious how you would handle small environments if there’s a desire to use blade servers.

Take your 150 VM example, you’d have to get to 4+ blocks before you’d fill most vendors’ blade chassis:

If you were using a blade solution would you:
- Spread hosts in each block across all available chassis, ignoring the physical boundary of the chassis and basically treating them as a fabric connection.
- Isolate a given building block to a single chassis, spreading full blocks across available chassis. In this case, would you consider it acceptable for two blocks to share a chassis (assuming there were additional blocks in other chassis), i.e. two 4-host blocks sharing a single UCS chassis?