Product Documentation
- Section I. Overview and planning
- Introduction to Resiliency Platform
- About Resiliency Platform features and components
- Replication in a Resiliency Platform deployment
- About Veritas Resiliency Platform Data Mover
- Recovery options using Resiliency Platform
- Deployment checklist
- System requirements
- Manage licenses
- Using the Web Console
- Introduction to Resiliency Platform
- Section II. Deploying and configuring the virtual appliances
- Deploy and configure
- Deploying the virtual appliances in AWS through AWS Marketplace
- Deploying the virtual appliances in AWS using OVA files
- Deploying the Data Gateway in AWS
- Deploying the virtual appliances in Azure using PowerShell script
- Deploying the virtual appliances in Azure through Azure Marketplace
- Deploying the virtual appliances in vCloud
- Deploying the virtual appliances in HUAWEI CLOUD
- Deploying the virtual appliances in Orange Recovery Engine
- About configuring the Resiliency Platform components
- Virtual appliance security features
- About hotfixes
- Apply Updates
- About applying updates to Resiliency Platform
- Setting up the YUM server
- Deploy and configure
- Section III. Setting up and managing the resiliency domain
- Managing the resiliency domain
- Getting started with a new Resiliency Platform configuration
- Managing Resiliency Managers
- Managing Infrastructure Management Servers
- Managing on-premises data centers
- Managing cloud configurations
- Managing private cloud configurations
- Integrating with NetBackup
- Integrating with InfoScale Operations Manager
- Managing the resiliency domain
- Section IV. Adding the asset infrastructure
- Manage Resiliency Platform host assets
- Prerequisites for adding hosts
- Removing hosts
- Preparing host for replication
- Manage VMware assets
- Managing VMware virtualization servers
- Prerequisites for adding VMware virtualization servers
- Prerequisites for adding VMware virtualization servers
- Managing VMware virtualization servers
- Manage Veritas Replication VIB
- Manage Hyper-V assets
- Manage Gateways
- About Replication Gateway pair
- Managing Data Gateway
- Manage enclosure assets
- Adding a discovery host
- Configuration prerequisites for adding storage enclosures to an IMS
- Adding storage enclosures
- Adding RecoverPoint appliance for replication
- Manage Resiliency Platform host assets
- Section V. Managing networks
- Manage networks
- About network objects
- Manage settings
- Managing user authentication and permissions
- Configuring authentication domains
- Managing user authentication and permissions
- Manage networks
- Section VI. Working with resiliency groups
- Organize assets
- Viewing resiliency group details
- Manage virtual business services
- Organize applications
- Managing custom applications
- Managing service objectives
- Organize assets
- Section VII. Configuring for disaster recovery
- Configure using Resiliency Platform Data Mover
- Managing virtual machines for remote recovery (DR) in Amazon Web Services
- Prerequisites for configuring VMware virtual machines for recovery to AWS
- AWS Customization options panel
- Managing virtual machines for remote recovery (DR) to Azure
- Managing virtual machines for remote recovery (DR) to OpenStack
- Managing virtual machines for remote recovery (DR) to HUAWEI CLOUD
- Managing virtual machines for remote recovery (DR) to Orange Recovery Engine
- Managing virtual machines for remote recovery (DR) in vCloud Director
- Managing virtual machines for remote recovery (DR) using Resiliency Platform Data Mover
- Managing physical machines for remote recovery (DR) using Resiliency Platform Data Mover
- Configure using NetBackup
- Configure using 3rd party replication technology
- Preparing VMware virtual machines for using array-based replication
- Preparing Hyper-V virtual machines for using array-based replication
- Managing virtual machines for remote recovery (DR) using 3rd party replication technology
- Managing applications for remote recovery (DR)
- Preparing VMware virtual machines for using array-based replication
- Configure using Resiliency Platform Data Mover
- Section VIII. Managing disaster recovery
- Perform DR operations for virtual machines
- Performing the rehearsal operation for virtual machines
- Perform DR operations on a VBS
- Perform DR operations for applications
- Evacuate assets
- Manage Resiliency Plans
- About custom script
- Perform DR operations for virtual machines
- Section IX. Product settings
- View activities
- Manage reports
- View logs
- Manage Risk Notifications
- Managing settings for alerts and notifications and miscellaneous product settings
- Section X. Using Resiliency Platform APIs
- Section XI. Troubleshooting and Using command line interface
- Troubleshoot
- Recovery of Resiliency Platform components from disaster scenarios
- Resolving the Admin Wait state
- Use klish menu
- Use Application Enablement SDK
- Troubleshoot
Define an application
This category consists of the new API which is the starting point of any application module script. It also contains the APIs that let you define the discovery level of the application, define the operations that can be performed on the application and so on.
Description: This API conveys the application type, for example MSSQL, Oracle, SAP, to the Resiliency Platform. This interface is the starting point of any application module script and is mandatory. This initiates the application along with the logger. The logging level is set to Info by default.
To change the log level, use the reset_log API.
See Logging.
Note:
This interface returns an un-defined object if user specified application type has anything other than the characters A-Z,a-z,0-9,dash(-), or underscore(_).
Is mandatory: Yes
Input parameter: String : Application type.
Return value: Application object, else undefined.
Syntax:
new VRTS::AppSDK::AppEnablementSDK::Application("<Application Type>");
Example:
my $appObj = new VRTS::AppSDK::AppEnablementSDK::Application("TestApp");
Description: Use this interface to declare the types of discoveries that your application script supports. For the Resiliency Platform to discover the applications, you need to define the discovery types such as deep and probe. Use comma as a delimiter to define more than one discovery level.
Deep and probe discovery types are mandatory.
DEEP: discovers the entire application and its components including files.
PROBE: only checks the status of the application instances. For example whether the application is online or offline.
Is mandatory: Yes
Input parameter: String : Discovery level type, value must be "DEEP" and "PROBE".
Return value: 0 if successful, else any positive number.
Example:
my $appObj = new VRTS::AppSDK::AppEnablementSDK::Application("TestApp"); $appObj->set_discovery_types("DEEP", "PROBE");
Description: Use this interface to provide a list of operations that a particular application module script supports. For example, start an application and stop an application. Use comma as a delimiter to define more than one operation type. This interface is mandatory for the Resiliency Platform to execute the discovery script and perform operations on the applications.
Start and stop operations are mandatory.
Is mandatory: Yes
Input parameter: String: Operations types, value must be "START" and "STOP".
Return value: 0 if successful, else any positive number.
Example:
my $appObj = new VRTS::AppSDK::AppEnablementSDK::Application("TestApp"); $appObj->set_operation_types("START", "STOP");
Description: Use this interface to register the discovery operation callback function against the discovery operation type defined using the set_discovery_types API. The registered callback function is invoked only when the application module script is invoked with said discovery operation. This is a mandatory interface that conveys the Resiliency Platform the sub-routine which is capable of executing the operation and returning an appropriate return code and return message.
Ensure that the discovery script continues to discover the application in offline mode. Else, when the application is offline it is not discovered, and hence the instance is removed from the Resiliency Platform console. The resiliency group created using the instance becomes invalid.
The callback function is a sub-routine which is defined in the application module script and is capable of executing a said discovery operation successfully. The callback function returns 0 if the said operation is executed successfully else returns any positive number to indicate failure. Along with the return code you can also return a string containing either the success or the failure message. Providing a return code is mandatory otherwise the operation is considered as failed. Providing a return message is optional.
Is mandatory: Yes
Input parameter: String: Discovery operation - the discovery operation name which is previously set using the set_discovery_types API.
Input parameter: Callback function reference - the reference of the sub-routine which is defined in the application module script.
Return value: 0 if successful, else any positive number.
Example:
my $appObj = new VRTS::AppSDK::AppEnablementSDK::Application("TestApp"); if(defined $appObj) { $appObj->set_discovery_types("DEEP, PROBE"); $ret=$appObj->register_discovery_callback("PROBE",\&probe); $ret=$appObj->register_discovery_callback("DEEP",\&deep); } sub probe { # Write the code here to discover all application instances my $inst_name = "app_inst"; $appObj->log(LOGLEVEL_DEBUG,"Application instance name: [$inst_name]"); # Write the code here to discover state of each application instance # Report the state of the discovered application instance # on the Resiliency Platform. my $inst = $appObj->add_application_inst($inst_name); if (defined $inst) { # The state must be reported either 'online' or 'offline' $inst->set_property(APP_INST_STATE, "Online"); } # return 0 for successful and 1 for failure return 0,"probe is successful"; }
Note:
The second parameter in the above example, "\&probe" and "\&deep", is the reference of the callback function i.e the sub-routine reference defined in the application module script.
Description: Use this interface to register the callback function against the operation type defined using the set_operation_types API. The registered callback function is invoked only when the application module script is invoked with said operation. This is a mandatory interface that conveys the Resiliency Platform the sub-routine which is capable of executing the operation and returning an appropriate return code and return message.
The callback function is a sub-routine which is defined in the application module script and is capable of executing a said operation successfully. The callback function returns 0 if the said operation is executed successfully else returns any positive number to indicate failure. Along with the return code you can also enter a string containing either the success or the failure message. Providing a return code is mandatory otherwise the operation is considered as failed. Providing a return message is optional.
The callback function when registered with AppEnablementSDK using any of the above APIs receives an hashref as a parameter. The hashref parameter contains INSTANCE_NAME
as a key and application instance name as a value.
Is mandatory: Yes
Input parameter: String : Operation - The operation name which is previously defined using set_operation_types API.
Callback function reference - the reference of the sub-routine which is defined in the application module script.
Return value: 0 if successful, else any positive number.
Example:
my $appObj=new VRTS::AppSDK::AppEnablementSDK::Application("TestApp"); if(defined $appObj) { $appObj->set_operation_types("START,STOP"); $ret = $appObj->register_operation_callback("START",\&start); $ret = $appObj->register_operation_callback("STOP",\&stop); } sub start { my ($arg) = @_; my $FuncName = ( caller 0 )[3]; $appObj->log(LOGLEVEL_DEBUG,"Inside $FuncName"); my $inst_name = $arg->{INSTANCE_NAME}; $appObj->log(LOGLEVEL_DEBUG,"Application instance name: [$inst_name]"); # Write the code here to start an application instance # and return appropriate status code and message. # Return 0 for successful and 1 for failure return 0, "Start is successful"; }
Note:
The second parameter in the above example, "\&start" and "\&stop", is the reference of the callback function i.e the sub-routine reference defined in the application module script.