Abstract: Techniques for performing a recovery drill for an application stack using a recovery protection group are provided. In one technique, a first plurality of cloud resources, that reside in a first computing region, to include in a recovery protection group are identified. Each cloud resource of the first plurality of cloud resources is automatically analyzed to identify its characteristics. Based on the characteristics, a drill plan is automatically generated that comprises a plurality of actions for allocating a second plurality of cloud resources in a second computing region that is different than the first computing region. The drill plan is executed, which comprises performing the plurality of actions, which comprises allocating the second plurality of cloud resources that correspond to the first plurality of cloud resources.

Abstract: Techniques for recovering an application stack from a primary region to a standby region using a recovery protection group are provided. In one technique, a first plurality of cloud resources, that reside in a first computing region, are identified to include in a recovery protection group. Each cloud resource of the first plurality of cloud resources is automatically analyzed to identify its characteristics. Based on the characteristics, a recovery plan is automatically generated that comprises multiple actions that includes two or more actions that are to be performed in a particular sequence relative to two or more types of cloud resources in the first plurality. The recovery plan is executed, which comprises performing the multiple actions, which results in allocation, in a second computing region that is different than the first computing region, of a second plurality of cloud resources that correspond to the first plurality of cloud resources.

Abstract: Techniques for estimating a time to recover an application stack from a primary region to a standby region. In one technique, a recovery plan that comprises a plurality of actions to perform relative to a plurality of cloud resources in a recovery protection group is selected. Historical data that indicates actual times to perform one or more actions pertaining to recovering cloud resources is stored. Based on the historical data, a total time to execute the recovery plan is estimated. The total time is stored in association with the recovery plan.

Abstract: The disclosed embodiments provide a system for processing data. During operation, the system obtains a set of rules for filtering job recommendations, wherein the rules are selected to maximize a reduction in negative outcomes associated with the job recommendations. Next, the system generates a label for a set of candidate-job pairs that match one or more of the rules and inputs the label with a set of candidate-job features for the set of candidate-job pairs as training data for a filtering model. The system then applies the filtering model to additional candidate-job features associated with a candidate and a set of jobs to produce a set of scores, wherein each score represents a likelihood that the candidate perceives a corresponding job as an undesirable recommendation. Finally, the system outputs a subset of the jobs as recommendations to the candidate based on the set of scores.

Abstract: An apparatus comprising a transmit path, a plurality of local oscillators and a control unit. The control unit may be configured to: receive an upcoming resource block (RB) allocation; determine whether the upcoming RB allocation is the same as the current RB allocation; in response to determining that the upcoming RB allocation is different than the current RB allocation: select an unused LO of the plurality of LOs; determine whether a number of allocated RBs associated with the upcoming RB allocation is greater than a threshold; and in response to determining that the number of allocated RBs associated with the upcoming RB allocation is not greater than the threshold, tune the selected LO to a frequency corresponding to the upcoming RB allocation.

Abstract: An apparatus comprising a transmit path, a plurality of local oscillators and a control unit. The control unit may be configured to: receive an upcoming resource block (RB) allocation; determine whether the upcoming RB allocation is the same as the current RB allocation; in response to determining that the upcoming RB allocation is different than the current RB allocation: select an unused LO of the plurality of LOs; determine whether a number of allocated RBs associated with the upcoming RB allocation is greater than a threshold; and in response to determining that the number of allocated RBs associated with the upcoming RB allocation is not greater than the threshold, tune the selected LO to a frequency corresponding to the upcoming RB allocation.

Abstract: Techniques are described for dynamically generating a disaster recovery plan. In an embodiment, a set of topology metadata is determined for a first site on which a multi-tier application is deployed and a second site where the multi-tier application will be activated in the event of switchover/failover. The topology metadata may include metadata that identifies a set of targets associated with a plurality of tiers on the first site on which the multi-tier application is deployed and also on the second site where the multi-tier application would be activated in the event of disaster recovery operation like switchover or failover. Based, at least in part, on the topology metadata for the first site and second site, a disaster recovery plan is generated. The disaster recovery plan includes an ordered set of instructions for deactivating the multi-tier application at the first site and activating the multi-tier application at a second site.

Abstract: Techniques are described for validating a disaster recovery plan. In an embodiment, a request is received to perform a validation of a disaster recovery operation plan that includes a set of instructions for performing a disaster recovery operation with respect to a first site and a second site. In response to receiving the request to perform the validation of the disaster recovery operation plan, a set of one or more validation operations is performed with respect to the disaster recovery operation plan. Based on the set of one or more validation operations, a report is generated that identifies one or more issues that may prevent the disaster recovery operation plan from executing properly.

Abstract: Techniques are described for providing error management capabilities for disaster recovery operations. In an embodiment, first user input is received that identifies a first error mode to assign to a particular step of a disaster recovery plan that includes a set of steps for performing a disaster recovery operation. In response to receiving the first user input, the particular step is associated with the first error mode. In response to determining that an error occurred while processing the particular step of the disaster recovery plan, the error mode that is associated with the particular step is determined. Error handling is performed for the particular step based, at least in part, on the error mode that is associated with the particular step of the disaster recovery plan.

Abstract: Techniques are described for validating a disaster recovery plan. In an embodiment, a request is received to perform a validation of a disaster recovery operation plan that includes a set of instructions for performing a disaster recovery operation with respect to a first site and a second site. In response to receiving the request to perform the validation of the disaster recovery operation plan, a set of one or more validation operations is performed with respect to the disaster recovery operation plan. Based on the set of one or more validation operations, a report is generated that identifies one or more issues that may prevent the disaster recovery operation plan from executing properly.

Abstract: Techniques are described for providing error management capabilities for disaster recovery operations. In an embodiment, first user input is received that identifies a first error mode to assign to a particular step of a disaster recovery plan that includes a set of steps for performing a disaster recovery operation. In response to receiving the first user input, the particular step is associated with the first error mode. In response to determining that an error occurred while processing the particular step of the disaster recovery plan, the error mode that is associated with the particular step is determined. Error handling is performed for the particular step based, at least in part, on the error mode that is associated with the particular step of the disaster recovery plan.

Abstract: Techniques are described for dynamically generating a disaster recovery plan. In an embodiment, a set of topology metadata is determined for a first site on which a multi-tier application is deployed and a second site where the multi-tier application will be activated in the event of switchover/failover. The topology metadata may include metadata that identifies a set of targets associated with a plurality of tiers on the first site on which the multi-tier application is deployed and also on the second site where the multi-tier application would be activated in the event of disaster recovery operation like switchover or failover. Based, at least in part, on the topology metadata for the first site and second site, a disaster recovery plan is generated. The disaster recovery plan includes an ordered set of instructions for deactivating the multi-tier application at the first site and activating the multi-tier application at a second site.