Turbonomic Blog

Disaster Recovery Failover and Host Removal

Posted by Anson McCook on Feb 23, 2017 10:30:29 AM
Anson McCook
Find me on:

How to Run Every Capacity Planning Scenario in Seconds Part 3

In this post we will continue our examination of common scenarios you might need to plan for in your datacenter. If you are not already using Turbonomic, pull down the 30-day trial here and follow along! Click here to read Part 1 and here to read Part 2!

Ok, round 3! We’ve covered demand-based plans like adding VMs and projection, we’ve covered supply modification like hardware refreshes and upgrades – now let’s tackle workload migration (failover) and accommodating for business policies like reserving resources in case of hardware failure or maintenance. These scenarios can be particularly helpful for organizations to run periodically to ensure the business is resilient when fewer physical resources are available. As the previous posts have discussed, the simplicity, accuracy, and speed at which these plans are executed takes quite a bit of pressure off the administrators of these environments.

Scenario 6: Workload Migration (Failover) - Add Hardware

[wistia]csvc7ighso[/wistia]
[more]

Script:

Okay, so the plan we’re about to run is useful not only for simulating failover but also simulating any type of workload migration. Like a legacy environment being decommissioned and workloads need to be transferred somewhere else. Let’s setup the scenario. Click on the green plus button to open up the Plan Wizard. Select the last option, “Workload Migration.” Now we’re asked “which cluster will everything be moved to?” – “the destination cluster”. Select your destination cluster and then click Next. Now we need to select the workloads that will be migrated over. Select the group of workloads that will be migrated over, then drag and drop the group over to the “Plan Inventory” window. Click Finish. Before clicking run, make sure “Ignore constraints” is checked. This tells Turbonomic to ignore cluster boundaries – which is required in a scenario like this. Now click “Run”

Based on the additional workload that has migrated into this cluster, Turbonomic had suggested to add more hardware to meet the demand and keep the cluster in a desired state. The todo list highlights how existing workload will be distributed to accommodate the migrated workloads.

[/more]

 

Scenario 7: Workload Migration (Failover) – Do Not Add Hardware

[wistia]ptk3nrw1up[/wistia]

[more]

Script:

In this failover scenario, let’s tell Turbonomic that it shouldn’t suggest to add more hardware. I would like to simulate what the environment will look like if I had to run all these workloads on the hardware that exists today. Let’s setup the scenario.

Click on the green plus button to open up the Plan Wizard. Select the last option, “Workload Migration.” Now we’re asked “which cluster will everything be moved to?” – “the destination cluster”. Select your destination cluster and then click Next. Select the group of workloads that will be migrated over, then drag and drop the group over to the “Plan Inventory” window. Click Finish.

Before clicking “Run”, go to Advanced Settings and click “Edit”. Select the tab, “Action Settings.” Now uncheck “Allow Host Provisioning” and click Apply. This tells Turbo to not suggest adding more hardware. Close the dialog box. Finally, make sure “Ignore constraints” is checked. This tells Turbonomic to ignore cluster boundaries – which is required in a scenario like this. Now click “Run”

Based on the additional workload that has migrated into this cluster, Turbonomic has rearranged the workloads to run on the existing hardware today. We may see an undesirable state here – but that’s because we’ve told Turbonomic to not add any hardware if resources are constrained – so that’s expected. The todo list highlights how existing workload will be distributed to accommodate the migrated workloads.

[/more]

Scenario 8: “Is my cluster N+1?” – Host Removal

In a similar vein, we can also plan for failures within our clusters. Can my cluster support the loss of a host? Two hosts? If I put this host in maintenance mode for patching, can I still support the workloads with the remaining hardware? Let’s use VMTurbo to simulate the effect of removing some of our hosts from the cluster.

[wistia]v3fddkajc7[/wistia]

[more]
Script:

In this scenario we’ll simulate the effect of removing hosts from a cluster. Click on the green plus button to open up the Plan Wizard. Select “Decomissioned Hosts”. Now choose which cluster you would like to remove hosts from. Expand PM Groups, expand Physical Machines by PM Cluster and select your desired cluster. Now we’ll select the host or hosts we’d like to remove. Expand PM Groups, expand Physical Machines by PM Cluster, expand the cluster you selected. Now select the host or hosts you’d like to remove. You can multi-select by holding down the control or shift keys while clicking. Once selected, click “Remove”. Now click “Next”. Finally, uncheck “Allow Host Provision”. This tells Turbonomic to not suggest adding more hardware back into the cluster. We want to see what will happen if we have to use the remaining hardware to support the workloads. Click Finish. Now click Run.

Not surprisingly, utilization in my cluster has risen as I am now running on fewer hosts. Turbonomic has confirmed I can in fact support the removal of these hosts without compromising the performance of the cluster. The todo list at the bottom highlights how Turbonomic has rearranged workloads to accomplish this. If you need to perform maintenance on the hosts you just simulated removing, you could create a workload placement policy to have Turbonomic evacuate those hosts for you automatically.

[/more]

Stay Tuned

Overall, we’ve reviewed eight different, seemingly complex capacity planning scenarios that can all be completed in a matter of seconds.

If you missed Part 1 or Part 2, give those a read here and here. Stay tuned for Part 4 where we’ll check out advanced configuration settings.

Topics: How To...

Subscribe Here!

Recent Posts