Planning and Placement
While the bulk of functionality built into Workload Optimizer is focused on acting in real time to continuously optimize, there are two additional modules: one that supports future-looking planning and another that supports workload placement.
Since the entire foundation of Workload Optimizer’s decision engine is its market abstraction governed by the economic laws of supply and demand, it is a straightforward exercise to ask what-if questions of the engine in the planning module.
The planning function enables users to virtually change either the supply side (by adding or removing providers such as hosts or storage arrays) or the demand side (by adding or removing consumers such as VMs or containers) or both and then simulate the effect of the proposed change(s) on the live environment. Under the hood, this is a simple task for Workload Optimizer because it merely needs to run an extra market cycle with the new (simulated) input parameters. Just as in a live environment, the results of a plan (as shown in Figure 9-9) are actions.
Figure 9-9 Results of an added workload plan
Plans answer questions such as:
If four hosts were decommissioned, what actions would need to be taken to handle the workloads that they are currently running?
Does capacity exist elsewhere to handle the load, and if so, where should workloads be moved?
If there is not enough spare capacity, how much more and of what type will need to be bought/provisioned?
The planning in Workload Optimizer takes the concept of traditional capacity planning, which can be a relatively crude exercise in projecting historical trend lines into the future, to a new level: Workload Optimizer does its planning and tells you exactly what actions will need to be taken in response to a given set of changes to maintain the desired state. One of the most frequently used planning types is the Migrate to Cloud simulation, which is addressed in greater detail later in this chapter, in the section “The Public Cloud.”
The placement module in Workload Optimizer is a variation on the planning theme but with real-world consequences. Placement reservations (see Figure 9-10) allow an administrator who knows that new workloads are coming into the environment soon to alter the demand side of all future market cycles, taking the yet-to-be-deployed workloads into account.
Figure 9-10 Creating a placement reservation
Such reservations force the economic engine to behave as if those workloads already exist, and the engine generates real actions accordingly. Reservations may therefore result in real changes to the environment if automation policies are active and/or real recommended pending actions such as VM movements and server or storage provisioning (to accommodate the proposed new workloads) are undertaken.
Using placement reservations is a great way to both plan for new workloads and to ensure that resources are available when those workloads are deployed. A handy feature of any placement reservation is the ability to delay making the reservation active until a point in the future, including the option of an end date for the reservation. This delays the effect of the reservation until a time closer to the actual deployment of the new workloads.