Patent Publication Number: US-11663087-B2

Title: Validating metering of a disaster recovery service used in clouds

Description:
PRIORITY CLAIM 
     The instant patent application is related to and claims priority from the co-pending India provisional patent application entitled, “VALIDATING METERING OF A CONSUMPTION BASED DISASTER RECOVERY SERVICE USED BY CLOUDS”, Serial No.: 202041007046, Filed: 19 Feb. 2020, which is incorporated in its entirety herewith. 
     BACKGROUND OF THE DISCLOSURE 
     Cloud refers to a virtual infrastructure provided on a collection of processing systems, connectivity infrastructure, data storages, etc. The virtual infrastructure contains computing resources (e.g., virtual machines, operating systems) and storage resources (e.g., database servers, file systems). A customer/owner (also known as tenant) of a cloud may deploy desired user applications/data services on the resources provided as a part of their cloud(s), with the services capable of processing user requests received from end user systems. 
     Disaster recovery (DR) generally entails backing up of pertinent data at various time instances, and upon occurrence of a disaster, making pertinent applications and data operative based on the backed-up data within acceptable time frames and acceptable data loss. Thus, databases storing pertinent data in a storage node may be backed up to a backup node and applications may also be made operative in the backup node upon occurrence of a disaster in the storage node. 
     Disaster recovery is often provided as a service (such as Disaster-Recovery-as-a-Service or DRaaS) to one or more customers. Each customer may be billed for usage of the service. Metering implies measurement of such usage for each customer for purposes such as billing and planning. 
     There is a general need to validate metering of a disaster recovery service at least to ensure that the measurements captured by the metering for each cloud/customer are accurate. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Example embodiments of the present disclosure will be described with reference to the accompanying drawings briefly described below. 
         FIG.  1    is a block diagram illustrating an example environment (computing system) in which several aspects of the present invention can be implemented. 
         FIG.  2 A  illustrates an example execution state within a node of a computing infrastructure. 
         FIG.  2 B  illustrates the manner in which clouds are hosted in computing infrastructures in one embodiment. 
         FIG.  2 C  illustrates the manner in which disaster recovery as a service is provided for multiple clouds/customers in one embodiment. 
         FIG.  3    is a flow chart illustrating the manner in which validating metering of a disaster recovery service use in clouds is performed according to an aspect of the present disclosure. 
         FIGS.  4 A- 4 D  depicts user interfaces used for specifying the setup of a disaster recovery service in a cloud in one embodiment. 
         FIG.  5 A  depicts portions of category data specifying details of cloud resources (VMs) deployed in a cloud in one embodiment. 
         FIG.  5 B  depicts portions of policy data specifying details of disaster recovery policies setup in a cloud in one embodiment. 
         FIG.  6 A  illustrates the manner in which a test/second cloud is provisioned in a cloud infrastructure in one embodiment. 
         FIG.  6 B  illustrates the manner in which disaster recovery as a service is provided for test cloud in one embodiment. 
         FIG.  7    is a timeline according to which the usage of a disaster recovery service in clouds is monitored in one embodiment. 
         FIG.  8 A  depicts portions of DRS usage information collected for a cloud in one embodiment. 
         FIG.  8 B  depicts the manner in which the DRS usage in a cloud is metered in one embodiment. 
         FIG.  8 C  depicts the manner in which the DRS usage in a cloud is billed in one embodiment. 
         FIG.  8 D  depicts a rate card according to which a customer/tenant is billed in one embodiment. 
         FIG.  8 E  depicts the manner in which the DRS usage in a cloud is billed in one embodiment. 
         FIG.  9 A  depicts portions of expected (metering) values representing expected usage of DRS in a cloud in one embodiment. 
         FIG.  9 B  depicts portions of DRS usage information collected for a cloud in one embodiment. 
         FIG.  9 C  depicts the manner in which expected values for a cloud is collated based on metering tiers in one embodiment. 
         FIG.  9 D  depicts the manner in which expected values are compared with measured values to validate metering of usage of DRS in a cloud in one embodiment. 
         FIG.  9 E  depicts the manner in which expected values are compared with measured values to validate billing of usage of DRS in a cloud in one embodiment. 
         FIG.  10    is a block diagram illustrating the details of digital processing system in which various aspects of the present disclosure are operative by execution of appropriate executable modules. 
     
    
    
     In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number. 
     DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE DISCLOSURE 
     1. Overview 
     An aspect of the present disclosure facilitates validating metering of a disaster recovery service used in clouds. In one embodiment, a system receives a request to validate metering of usage of a disaster recovery service (DRS) in a first cloud. The system collects from a metering service of the DRS, measured values representing the actual usage of the DRS in a second cloud and then compares the measured values with corresponding expected values representing expected usage of the DRS in the second cloud. The system sends a response to the request based on a result of the comparing. In one embodiment, the request is received from a tenant (customer/owner) owning the first cloud. 
     According to yet another aspect of the present disclosure, the DRS in the first cloud is setup to operate according to a first configuration specifying respective disaster recovery policies applicable to corresponding cloud resources in the first cloud. The DRS in the second cloud is also setup with the disaster recovery policies specified in the first configuration. As such, the operation of the second cloud is similar to the first cloud (of the tenant) with respect to the usage of the DRS. 
     According to one more aspect of the present disclosure, the expected values (noted above) correspond to prior values representing actual usage of the DRS in the first cloud in a past duration when the first cloud was operating based on the first configuration, the measured values corresponding to a first duration after receipt of the request, where the first duration equals the past duration. 
     According to yet another aspect of the present disclosure, the first configuration is received along with the request. The system (noted above) then examines prior configurations setup for the DRS in the first cloud to identify a prior duration having a corresponding prior configuration matching the first configuration, as the past duration. 
     According to an aspect of the present disclosure, the system (noted above) provides a user interface to enable a user (customer/owner, administrator, etc.) to specify a first set of disaster recovery policies and submit the first set of disaster recovery policies as the first configuration of the first cloud. The request (noted above) and the first configuration are received in response to the user submission using the user interface. 
     According to another aspect of the present disclosure, the system (noted above) selects the past duration and identifies a prior configuration applicable to the selected past duration as the first configuration. 
     According to one more aspect of the present disclosure, the first cloud is provided based on a first cloud infrastructure. Accordingly, the system (noted above) in response to the request, prepares the second cloud in a second cloud infrastructure and configures the DRS in the second cloud according to the first configuration. The second cloud is separate and distinct from the first cloud (of the tenant) whose metering is sought to be validated. 
     According to yet another aspect of the present disclosure, the first cloud contains a first primary site and a first secondary site, wherein the DRS in the first cloud is setup to backup cloud resources from the first primary site to the first secondary site according to the first configuration. In one embodiment, the cloud resources are virtual machines provisioned as part of the first cloud. 
     According to an aspect of the present disclosure, the first cloud is a hybrid cloud in which the first primary site is hosted in a on-premises infrastructure and the first secondary site is hosted in the first cloud infrastructure, while the second cloud is a multi-cloud cloud comprising a second primary site and a second secondary site, both being hosted in the second cloud infrastructure. 
     According to another aspect of the present disclosure, the system (noted above) performs collecting from a first time instance to a second time instance, where the first time instance is after receipt of the request. Upon receiving at a third time instance (between the first time instance and a second time instance) an indication that the DRS in the first cloud has been changed to operate according to a second configuration, the system modifies the second cloud to also operate according to the second configuration and continues collecting the measured values from the modified second cloud in a duration between the third time instance and the second time instance. 
     According to an aspect of the present disclosure, a customer/owner of a cloud is facilitated to validate metering of a disaster recovery service (DRS) used in his/her first cloud. The customer (using a user system) sends a request to validate metering of usage of a disaster recovery service (DRS) in the first cloud and receives a response to the request based on a result of a comparison of measured values representing the actual usage of the DRS in a second cloud and corresponding expected values representing expected usage of the DRS in the second cloud. 
     Several aspects of the present disclosure are described below with reference to examples for illustration. However, one skilled in the relevant art will recognize that the disclosure can be practiced without one or more of the specific details or with other methods, components, materials and so forth. In other instances, well-known structures, materials, or operations are not shown in detail to avoid obscuring the features of the disclosure. Furthermore, the features/aspects described can be practiced in various combinations, though only some of the combinations are described herein for conciseness. 
     2. Example Environment 
       FIG.  1    is a block diagram illustrating an example environment (computing system) in which several aspects of the present invention can be implemented. The block diagram is shown containing user systems  110 - 1  through  110 -Z (Z representing any natural number), Internet  115 , disaster recovery as a service (DRaaS) system  120 , testing server  150 , and computing infrastructures  130 ,  160  and  180 . Computing infrastructure  130  in turn is shown containing nodes  140 - 1  through  140 -P (P representing any natural number). Computing infrastructure  160  in turn is shown containing nodes  170 - 1  through  170 -Q (Q representing any natural number). Computing infrastructure  180  in turn is shown containing nodes  190 - 1  through  190 -R (R representing any natural number). The user systems and nodes are collectively referred to by  110 ,  140 ,  170  and  190  respectively. 
     Merely for illustration, only representative number/type of systems is shown in  FIG.  1   . Many environments often contain many more systems, both in number and type, depending on the purpose for which the environment is designed. Each block of  FIG.  1    is described below in further detail. 
     Each of computing infrastructures  130 ,  160  and  180  is a collection of physical processing nodes ( 140 ,  170  and  190 ), connectivity infrastructure, data storages, administration systems, etc., which are engineered to together provide a virtual computing infrastructure for various customers, with the scale of such virtual computing being specified often on demand. Computing infrastructure  130 / 160 / 180  may correspond to a public cloud infrastructure such as Amazon Web Services (AWS) Cloud available from Amazon.com, Inc., Google Cloud Platform (GCP) available from Google LLC, Azure cloud available from Microsoft, Inc., Xi cloud available from Nutanix etc. Computing infrastructure  130 / 160 / 180  may also correspond to one of the On-Premises (On-Prem) enterprise systems owned by corresponding customers. Alternatively, computing infrastructure  130 / 160 / 180  may correspond to a third-party data center provided by a cloud service provider. 
     In one embodiment, computing infrastructures  130  and  160  are On-Prem (on premises) enterprise systems owned by corresponding customers, while computing infrastructure  180  is a public cloud infrastructure such as AWS Cloud noted above. Accordingly, in the following description, the terms on-prem system  130 / 160  and cloud infrastructure  180  are used interchangeably with computing infrastructures  130 / 160 / 180 . However, aspects of the present disclosure can be implemented in other environments as well such as when  130 / 160 / 180  are all public cloud infrastructures or when  130 / 160 / 180  are third party data centers, as will be apparent to one skilled in the relevant arts by reading the disclosure herein. 
     All the systems of each computing infrastructure  130 / 160 / 180  are assumed to be connected via an intranet. Internet  115  extends the connectivity of these (and other systems of the computing infrastructures) with external systems such as user systems  110  and testing server  150 . Each of intranet and Internet  115  may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP), well known in the relevant arts. 
     In general, in TCP/IP environments, a TCP/IP packet is used as a basic unit of transport, with the source address being set to the TCP/IP address assigned to the source system from which the packet originates and the destination address set to the TCP/IP address of the target system to which the packet is to be eventually delivered. An IP packet is said to be directed to a target system when the destination IP address of the packet is set to the IP address of the target system, such that the packet is eventually delivered to the target system by Internet  115  and intranets. When the packet contains content such as port numbers, which specifies a target application, the packet may be said to be directed to such application as well. 
     Each of user systems  110  represents a system such as a personal computer, workstation, mobile device, computing tablet etc., used by users to generate (user) requests directed to enterprise/user applications executing in computing infrastructures  130 / 160 / 180 . The user requests may be generated using appropriate user interfaces (e.g., web pages provided by a user application executing in a node, a native user interface provided by a portion of a user application downloaded from a node, etc.). 
     In general, a user system requests a user application for performing desired tasks and receives the corresponding responses (e.g., web pages) containing the results of performance of the requested tasks. The web pages/responses may then be presented to the user by local applications such as the browser. Each user request is sent in the form of an IP packet directed to the desired system or user application, with the IP packet including data identifying the desired tasks in the payload portion. 
     Some of nodes  140 / 170 / 190  may be implemented as corresponding data stores. Each data store represents a non-volatile (persistent) storage facilitating storage and retrieval of data by applications executing in the other systems/nodes of computing infrastructures  130 / 160 / 180 . Each data store may be implemented as a corresponding database server using relational database technologies and accordingly provide storage and retrieval of data using structured queries such as SQL (Structured Query Language). Alternatively, each data store may be implemented as a corresponding file server providing storage and retrieval of data in the form of files organized as one or more directories, as is well known in the relevant arts. 
     Some of the nodes  140 / 170 / 190  may be implemented as corresponding server systems. Each server system represents a server, such as a web/application server, executing enterprise applications (examples of user applications) capable of performing tasks requested by users using user systems  110 . A server system receives a user request from a user system and performs the tasks requested in the user request. A server system may use data stored internally (for example, in a non-volatile storage/hard disk within the server system), external data (e.g., maintained in a data store/node) and/or data received from external sources (e.g., from the user) in performing the requested tasks. The server system then sends the result of performance of the tasks to the requesting user system (one of  110 ) as a corresponding response to the user request. The results may be accompanied by specific user interfaces (e.g., web pages) for displaying the results to the requesting user. 
     In one embodiment, each customer is provided with a corresponding virtual computing infrastructure (referred to as a “cloud”) provisioned on the nodes of computing infrastructures  130 ,  160  and  180 . The manner in which clouds may be provisioned in computing infrastructures is described below with examples. 
     3. Hosting Clouds in Computing Infrastructures 
     In one embodiment, virtual machines (VMs) form the basis for deployment of various user/enterprise applications in the nodes of computing infrastructures  130 / 160 / 180 . As is well known, a virtual machine may be viewed as a container in which other execution entities are executed. A node/server system can typically host multiple virtual machines, and the virtual machines provide a view of a complete machine (computer system) to the user applications executing in the virtual machine. In the disclosure here, any resource, such as the VM, that is to be backed-up (and later restored) is referred to as a cloud resource. Such cloud resources are in contrast to infrastructure resources (e.g., CPU, memory, storage) that are consumed/used by VMs. 
       FIG.  2 A  illustrates an example execution state within a node of a computing infrastructure. Node  140 - 1  is shown provisioned with, and accordingly hosting VMs  211 ,  212 ,  213 , with the resources of the node shown allocated among the three VMs and some resources shown as still remaining ‘unused’ (i.e., not provisioned for any execution entity within node  140 - 1 ). Some of VMs  211 - 213  is shown hosting guest (modules)  221  and  222 . Guest modules  221 / 222  may correspond to one of an application service or infrastructure component provided as part of a user application. 
     Each of VMs  211 - 213  is associated with a corresponding resource definition which specifies the infrastructure resources required for/used by the VM during its operation. The resource definition typically is in the form of a triplet &lt;C, M, S&gt;, where C is the number of (virtual) CPU cycles (e.g. 1×, 2×, 4×), M is the amount of memory (RAM) in gigabytes (e.g. 1 GB, 2 GB, 4 GB) and S is the amount of persistent storage in gigabytes (e.g. 50 GB, 100 GB, 200 GB). 
     In one embodiment, a cloud for a customer/tenant is provisioned (created) by allocating a desired number of VMs hosted on nodes  140 / 170 / 190  in cloud infrastructures  130 / 160 / 18 . Each VM in the cloud may have a corresponding resource definition. Multiple VMs may also have the same resource definition. The manner in which multiple clouds are provisioned in cloud infrastructures  130 / 160 / 180  is described below with examples. 
       FIG.  2 B  illustrates the manner in which clouds are hosted in computing infrastructures in one embodiment. Specifically, the Figure illustrates the manner in which clouds  220 ,  240  and  260  are deployed in the nodes of computing infrastructures  130 / 160 / 180  using VMs. Only a sample set of clouds is shown in  FIG.  2 B  for illustration, though many environments often host a large number (100+) clouds across multiple computing infrastructures. 
     Cloud  230  is shown containing VMs  230 - 1  through  230 -M (M representing any natural number) that may be provisioned on nodes  140  of on-prem system  130  and nodes  190  of cloud infrastructure  180 . As is well known, a cloud containing a mixture of VMs provisioned in an on-prem system and VMs provisioned in a cloud infrastructure are referred to as “hybrid” cloud. Hybrid clouds are distinguished from other clouds that operate based on VMs provisioned on one or more cloud infrastructures. Cloud  230  is accordingly a hybrid cloud provisioned across the nodes of multiple computing infrastructures ( 130  and  190 ). Specifically, groups  230 A and  230 B respectively represents the set of VMs provisioned in on-prem system  130  and cloud infrastructure  180 . 
     Similarly, cloud  240  is another hybrid cloud containing VMs  240 - 1  through  240 -N(N representing any natural number) that may be provisioned on nodes  170  of on-prem system  160  and nodes  190  of cloud infrastructure  180 . Specifically, groups  240 A and  240 B respectively represents the set of VMs provisioned in on-prem system  160  and cloud infrastructure  180 . For illustration, it is assumed that each cloud ( 230  and  240 ) is owned by a corresponding customer/tenant. 
     A customer owning a cloud (e.g.,  230 ) typically specifies the desired number of VMs to be part of the cloud. The customer/tenant may then deploy desired user applications for execution in his/her cloud. The desired user application may be designed to be operative based on corresponding customer-specified configurations. In addition, data gets accrued in an application over time and includes the user interaction driven changes that have happened in the user application. For example, data entered by users using the user interfaces provided by the user application are accrued over time. 
     It may accordingly be desirable that such user application data (configuration and accrual data) be preserved even in the occurrence of natural or man-made disasters such as a power outage, hardware failure, file corruption, human error, earthquake, flood, hurricane/tornado, thunderstorm, wildfire, winter weather, etc. As such, the customer/tenant may employ disaster recovery wherein the pertinent applications and data are backed up at various time instances, and upon occurrence of a disaster, the pertinent applications and data are made operative based on the backed-up data within acceptable time frames and acceptable data loss. 
     For example, the customer owning cloud  230  may identify that group  230 A is a primary site and that group  230 B is a secondary site, and then setup to regularly backup cloud resources from the primary site ( 230 A) to the secondary site ( 230 B). In one embodiment, the cloud resources are virtual machines (VMs  230 - 1  through  230 -M) provisioned as part of cloud  230 . The manner in which disaster recovery may be provided in clouds is described below with examples. 
     4. Disaster Recovery in Clouds 
     Referring again to  FIG.  1   , DRaaS system  120  provides disaster recovery as a service to one or more customers. As is well known, a DRaaS system ( 120 ) provides for replication of physical servers (nodes) or virtual servers (VMs) to provide failover in the event of a man made or natural disaster. DRaaS can be especially useful to customers that lack the necessary expertise to provision, configure, and test an effective disaster recovery plan. 
     DRaaS system  120  facilitates backing up of pertinent data stored at a primary site at various time instances, and upon occurrence of a disaster, making pertinent applications and data operative in a secondary site based on the backed-up data within acceptable time frames (commonly referred to as Recovery Time Objective or RTO) and acceptable data loss (commonly referred to as Recovery Point Objective or RPO). 
     In one embodiment, a customer (e.g., owner of cloud  230 ) uses the nodes on his/her on-prem infrastructure (group  230 A) as the primary site for deployment of user applications, while using the nodes on cloud infrastructure (group  230 B) as the secondary site for disaster recovery. By adopting such hybrid cloud architecture, customers can failover to cloud infrastructure ( 180 ) at the time of disaster. In one embodiment, each customer is billed/charged only for the usage of the DRaaS, that is the DRaaS is a consumption-based disaster recovery service. 
     In addition, a customer may wish to migrate (partial if not full) their workload from pure On-Prem systems to cloud infrastructure, especially when the cloud infrastructure supports consumption-based charging model. The customer may wish to protect their On-Prem workload and data via DRaaS but does not wish to invest heavily on duplicating the On-Prem systems (data centers). Again, the customer desire is for low-costing DR along with the flexibility to opt the payment model (i.e., consumption-based model). 
       FIG.  2 C  illustrates the manner in which disaster recovery as a service is provided for multiple clouds/customers in one embodiment. DRaaS  120  is shown containing event collector  250 , data store  160 , metering service  270  and billing service  280 . Each of the blocks is described in detail below. 
     DRaaS  120  is shown facilitating the backup/replication of data at various time instances (referred to as snapshots) from primary sites to corresponding secondary sites for different clouds. In particular, for cloud  230 , the backup is shown occurring from group  230 A (primary site) to group  230 B (secondary site) as indicated by arrow  235 , while for cloud  240  (owned by the same or a different customer), the backup is shown occurring from group  240 A (primary site) to group  240 B (secondary site) as indicated by arrow  245 . It may be observed that the primary sites are located on On-Prem systems/infrastructures, while the secondary sites are hosted on cloud infrastructure  180 . 
     In one embodiment, each cloud (including the primary and second sites) is associated with a unique identifier referred to as “tenant_ID”, to facilitate DRaaS  120  to distinguish between the various clouds using the disaster recovery service. In the following disclosure, it is assumed that the tenant_ID associated with cloud  230  (and by extension  230 A and  230 B) is “TE1”, while the tenant_ID associated with cloud  240  ( 240 A and  240 B) is “TE2”. 
     Event collector  250  collects information from nodes  140 / 170 , in particular, in relation to the backups performed for VMs executing in those nodes. The information may include the number and/or frequency of backups of each VM performed for the purpose of disaster recovery, the size of the backup, etc. The collected information also includes the tenant_ID to enable event collector  250  to determine the specific cloud for which the information has been collected. The event collection may be performed at regular intervals (typically, every 1 minute, hereinafter referred to as “collection interval”) to capture the dynamic replication of VMs for different customers (indicated by arrows  238  and  248 ). Event collector  250  then stores the collected information in a persistent storage such as data store  260 . 
     Metering service  270  measures the DR backups performed for each cloud ( 230 ,  240 ) during corresponding durations. Metering service  270  retrieves the information stored in data store  260 , determines the backups performed in each cloud (based on tenant_ID) and aggregates the usage (number and/or frequency of backups) for larger intervals (e.g., 15 minutes, hereinafter referred to as “metering intervals”). Metering service  270  may maintain the measured resource usage data in a persistent storage (data store  260 ). Metering service  270  also forwards the measured values to billing service  280 . 
     In one embodiment, metering service  270  calculates the resource consumption units at the defined granularity level. For disaster-recovery service in hybrid clouds, the Units-of-Measurement (UoM) are DR RPO per-MINUTE level, DR RPO per-HOUR level, DR RPO per-DAY level. Customers configure or select desired RPO levels and send this information to a central database (hosted on any public cloud), with metering service  270  retrieving the data from this central database and computing the consumption usage for past durations min/hour/day and post these computations to billing service  280  in a periodic way (which is configurable). 
     Billing service  280  bills customers/tenants based on the DR usage of their cloud (again identified based on the tenant_ID). Billing service  280  receives the measured values from metering service  270 , and aggregates the received values for larger intervals (e.g., hourly, daily, etc. hereinafter referred to as “billing intervals”), and then bills the customer/tenant based on a rate/cost associated with such usage. Billing service  280  processes the data coming from metering service  270  and converts them into invoices by applying the rate cards, discounting, offers etc. as is well known in the arts. 
     Thus, a customer/tenant is billed according to the dynamic DR usage by their cloud ( 230 ,  240 ). However, in some scenarios, a customer/tenant may wish to validate whether the metering (in turn, the billing) of the DR usage of their cloud is accurate. 
     For example, with the consumption-based charging model, it may be important to correctly validate the consumption of the DR service commonly associated with different tiers like daily, hourly, minute level data snapshots with corresponding pricing models. Validating the correctness of metering and billing in real-time for multi-pricing model DR-features may accordingly be challenging. While dealing with customer incidents regarding metering and billing correctness, it is really tough to validate the behavior in real-time. 
     Customer may change the metering consumption model (e.g., from daily to hourly) at any desired time, and checking whether such changes have been reflected in the metering of the DR service is also challenging. Furthermore, in hybrid clouds, testing the DR Service is quite challenging as the test is for the live stream of data from end to end (path  238 ) as per the customer workflow. 
     Testing server  150 , provided according to several aspects of the present disclosure, facilitates validating of metering (service  270 ) of a consumption-based disaster-recovery service ( 120 ) in hybrid clouds ( 230  and  240 ). Though shown external to cloud infrastructure  180 , in alternative embodiments, testing server  150  may be implemented internal to cloud infrastructure  180 , for example, in one of nodes  190 . The manner in which testing server  150  facilitate validating metering of a disaster recovery service is described below with examples. 
     5. Validating Metering of a Disaster Recovery Service 
       FIG.  3    is a flow chart illustrating the manner in which validating metering of a disaster recovery service use in clouds is performed according to an aspect of the present disclosure. The flowchart is described with respect to the systems of  FIGS.  1  and  2   , in particular testing server  150 , merely for illustration. However, many of the features can be implemented in other environments also without departing from the scope and spirit of several aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. 
     In addition, some of the steps may be performed in a different sequence than that depicted below, as suited to the specific environment, as will be apparent to one skilled in the relevant arts. Many of such implementations are contemplated to be covered by several aspects of the present invention. The flow chart begins in step  301 , in which control immediately passes to step  310 . 
     In step  310 , testing server  150  receives a request to validate metering of usage of a DRS in a first cloud (assumed to be cloud  230  for illustration). The request may include details of the first cloud such as the VMs in the cloud, the resource definition of each VM, etc. The request may be received from a customer/tenant owning the first cloud ( 230 ) using one of user systems  110 . 
     In step  320 , testing server  150  prepare a second cloud setup with the disaster recovery policies specified in the first cloud. Preparing a second cloud may entail providing one or more nodes in a cloud infrastructure (assumed to be 180), provisioning multiple VMs in line with their corresponding resource definitions specified in the received request, and configuring the disaster recovery service to operation according to the disaster recovery policies specified in the first cloud. It should be noted that the second cloud is separate and distinct from the first cloud ( 230 ) whose metering is sought to be validated. In the following disclosure, it is assumed that the tenant_ID associated with the second cloud is “TE3”. 
     In one embodiment, the received request includes a first configuration specifying the manner in which DRS in the first cloud (of the tenant) is setup to operate. In particular, the first configuration specifies respective disaster recovery policies applicable to corresponding resources in the first cloud. The second cloud is according setup to operate with the disaster recovery policies specified by the first configuration. 
     In step  340 , testing server  150  collects measured values for the DRS from the second cloud. In particular, testing server  150  collects from a metering service ( 270 ) of the cloud infrastructure using the tenant_ID “TE3” of the second cloud, measured values representing the actual resources consumed by the second cloud provisioned in cloud infrastructure  180  in corresponding durations. The collecting may entail sending requests at regular intervals to metering service  270 , and receiving the measured values as responses to the request. Alternatively, metering service  270  may be configured to push/send the measured values to testing server  150  at regular intervals. 
     In step  360 , testing server  150  compares the measured values with corresponding expected/reference values representing expected usage of the DRS in the second cloud. The expected values may be pre-determined based on the DRS configuration of the second cloud. In one embodiment, the expected values are computed based on the first configuration received in the request. 
     In step  380 , testing server  150  sends a response to the request (received in step  310 ) based on comparison result. Specifically, the response indicates whether the metering of the DRs used in the first cloud is accurate or not. In one embodiment, the comparison result specifies whether the measured values match the respective expected values in corresponding durations. Accordingly, the response indicates that the metering of the DRS used in the first cloud is accurate if the result specifies a match, and inaccurate otherwise. The flowchart ends in step  399 . 
     It may be appreciated that match (with an acceptable margin of error) of the measured values and the expected values for the second cloud indicates the accuracy of the metering service  270  in general. By extension, metering of the specific cloud  230  is also deemed to be accurate as the same metering service is being used for metering/billing of specific cloud  230 . 
     Thus, a customer/tenant of a cloud ( 230 ) is facilitated to validate whether the metering (in turn, the billing) of the resource usage of their cloud is accurate. It may be appreciated that the operation of  FIG.  3    facilitates to validate the metering service ( 270 ) of a disaster recovery service provider ( 120 ) as well. The manner in which testing server  150  operates in accordance with the steps of  FIG.  3    to provide several aspects of the present disclosure is described below with examples. 
     6. Illustrative Example 
       FIGS.  4 A- 4 D,  5 A- 5 B,  6 A- 6 B,  7 ,  8 A- 8 E and  9 A- 9 D  together illustrate the manner in which validation of metering of a consumption-based disaster recovery service used in clouds is performed in one embodiment. Each of the Figures is described in detail below. 
     Some of the steps performed by an administrator/owner of a hybrid cloud are described in detail below. As the first step, the administrator sets up a DR environment and a hardware/software configuration in a first cloud (assumed to be cloud  230  for illustration). Such setup may entail configuring the On-Prem nodes/VMs to operate as a primary site and also nodes/VMs on a public cloud infrastructure to operate as a secondary site on which the On-Prem workload will failover during disaster recovery. 
     The administrator then defines a DR workload that is the set of nodes/VMs that are part of disaster recovery and accordingly have to be backed up from the primary site to the secondary site. In one embodiment described below, disaster recovery workload includes identifying the VMs and categorizing them into one or more categories such as HR, Finance, Engineering, IT, etc., and then configuring these categories with desired protection plans/policies (disaster recovery policies). Each protection plan/policy specifies the frequency of the snapshot cycles (RPO) like per minute/hour/day level. Each of these RPO (recovery point objectives) variations is associated with different pricing levels and accordingly the choice of the RPO for different categories is an important factor for metering and billing. The manner in which the administrator may specify categories and associated policies to the categories is described below with examples. 
       FIGS.  4 A- 4 D  depicts (sample) user interfaces used for specifying the setup of a disaster recovery service in a cloud in one embodiment. Display area  400  (of  FIGS.  4 A- 4 D ) represents a portion of a user interface displayed on a display unit (not shown) associated with one of user systems  110 . In one embodiment, display area  400  corresponds to a web page rendered by a browser executing on a user system. The web pages may be provided by testing server  150  in response to a user (such as a customer/tenant, administrator, etc.) sending appropriate requests (for example, by specifying corresponding Uniform Resource Locator (URL) in the address bar) using the browser. 
     Referring to  FIG.  4 A , display area  410  depicts a list of categories specified by an administrator. Each category is shown containing one or more VMs (resources) and associated protection/disaster recovery policies. For example, display area (rows)  415  indicates that the category “Ormed” is associated with 5 VMs and has been assigned  1  protection policy and 1 recovery action. Similarly, the other rows of the list specify the details of corresponding categories specified by the administrator. The administrator may select a desired category (such as  415 ) and may update the details of the category, as described in detail below. 
     Referring to  FIG.  4 B , display area  420  depicts the manner in which an administrator is facilitated to update a category (assumed to be “Ormed” of  415 , for illustration). Display area  420  enables the administrator to add/remove VMs and also to add/remove protection policies associated with the VMs. Though not shown, a user interface similar to  FIG.  4 B  may be provided for adding new categories. 
     Referring to  FIG.  4 C , display area  430  depicts a list of protection policies specified by an administrator. Each protection policy is shown having a primary location, recovery (backup) location, a RPO (recovery point objective), a remote retention (period) and a local retention (period). For example, display area/row  435  specifies a protection policy named “ORMED” whose primary location is “Local AZ”, recovery/backup location is “US-EAST-1B”, RPO is “12 hours”, remote retention is “2 day(s)” and local retention is “1 day(s)”. Similarly, the other rows of the list specify the details of corresponding protection/disaster recovery policies specified by the administrator. The administrator may select a desired policy (such as  435 ) and may update the details of the policy, as described in detail below. 
     Referring to  FIG.  4 D , display area  450  depicts the manner in which an administrator is facilitated to update a protection policy (assumed to be “ORMED” of  435 , for illustration). Display area  460  enables the administrator to add/change the RPO for the policy. The RPO is specified by first selecting a unit of duration (“minutes”, “hours” or “days”) and then specifying a period of activation (e.g., 12 shown there). Display area  460  thus indicates that the protection policy is to be activated every 12 hours. 
     Display area  470  indicates the pricing level (metering tier) corresponding to the user specified values in display area  460 . Each pricing level/metering tier specifies a cost associated with one or more RPOs, typically specified as a range of RPO (e.g., greater than a lowest RPO and less than a highest RPO). In the description below, it is assumed that the disaster recovery service operates with 3 pricing levels/metering tiers—“Premium” when RPO is less than or equal to 4 hours, “Advanced” when RPO is greater than 4 hours but less than or equal to 1 day and “Basic” when RPO is greater than 1 day. Display area  470  is accordingly shown displaying “Advanced” corresponding to the RPO “12 hours” selected in display area  460 . It may be appreciated that in alternative embodiments, different pricing levels/metering tiers may be provided by the DRS, with display area  470  then displaying the appropriate pricing level. 
     Display area  480  facilitates the administrator to associated various categories with the protection policy being updated (here “ORMED”). Display area  480  indicates that the protection policy “ORMED” is associated with the category “Ormed” thereby indicating that the VMs of the category “Ormed” are to be backed up every 12 hours. After making the desired changes, the administrator may click/select “Save” button  490  to cause the updated protection policy to be active. 
     Thus, display area  450  enables the administrator to update protection policies and also to add/remove categories associated with the protection policies. Though not shown, a user interface similar to  FIG.  4 D  may be provided for adding new protection/disaster recovery policies. 
     During normal operation, DRaaS system  120  (or corresponding agents deployed in nodes of first cloud  230 ) causes backups/snapshots of the VMs (specified using the user interfaces of  FIGS.  4 A- 4 B ) executing in cloud  230  to be created and sent to the secondary site for storage. The frequency of creation and storage of the snapshots is indicated by the RPO associated with the categories using the user interfaces of  FIGS.  4 C- 4 D . However, the administrator after specifying the desired categories, and protection policies and then associating the protection policies with the categories, may wish to validate whether the protection policies specified are being metered accurately. 
     Accordingly, the administrator may select the protection policies of interest (to be testing for accurate metering) and click/select “Validate Protection Policies” button  440  in  FIG.  4 C  to cause a request to be sent to testing server  150  for validating the metering of the disaster recovery setup in cloud  230  (hereinafter “validation request”). The validation request includes the tenantID (“TE1”), details of the categories, VMs, etc. and also the selected protection policies as a first configuration of the DRS setup in cloud  230 . 
     Testing server  150  then stores the received information in a non-volatile storage (not shown). The manner in which the information received as part of requests to validate metering of a DRS used in clouds is maintained is described below with examples. 
     7. Sample Data 
       FIG.  5 A  depicts portions of category data specifying details of cloud resources (VMs) deployed in a cloud in one embodiment. Though shown in the form of tables, the category data (and other data portions shown in  FIGS.  5 B,  8 A- 8 C and  9 A- 9 D ) may be collected/maintained according to other data formats (such as extensible markup language (XML), etc.) and/or using other data structures (such as lists, trees, etc.), as will be apparent to one skilled in the relevant arts by reading the disclosure herein. 
     Table  500  depicts a portion of the category data maintained by testing server  150  for cloud  230  (as indicated by the tenant_ID “TE1”). The category data may be received as part of a validation request to validate metering of DRaaS  120  in first cloud  230 , and specifies the details of the resources (VMs) deployed in the first cloud ( 230 ). In particular, column “Category” specifies the name of a category, “VM List” specifies the list of VMs (in the form of VM name&lt;VM resource definition&gt;) in the category. The column “VM Total” specifies the total amount of infrastructure resources (in the form of a resource definition) corresponding to the category, and is the sum of the all the VM resource definitions specified in “VM List”. 
     Thus, row  511  indicates that the category named “Ormed” includes the VMs—VM1&lt;2×, 4 GB, 70 GB&gt;, VM2&lt;1×, 2 GB, 150 GB&gt; and VM3&lt;4×, 8 GB, 200 GB&gt;, and that the total amount of infrastructure resources for the category is &lt;7×, 14 GB, 420 GB&gt;. Similarly, the other rows specify the details of other categories received in the validation request. The categories specified in table  500  may be associated with protection/disaster recovery policies as described below with examples. 
       FIG.  5 B  depicts portions of policy data specifying details of disaster recovery policies setup in a cloud in one embodiment. Table  550  depicts portions of policy data maintained by testing server  150  for cloud  230  (as indicated by the tenant_ID “TE1”). In particular, column “Policy ID” specifies a unique identifier of a policy, column “Policy Name” specifies the name of the policy, column “Category” specifies the category for which the policy is applicable, column “RPO” specifies the RPO of the policy, columns “Start Date Time” and “End Date Time” respectively specifies the start date and time (in 24 hour format) from which the policy is in effect and the end date and time (in 24 hour format) until which the policy is in effect and column “Metering Tier” specifies the metering tier/pricing level of the policy. 
     The policy data may be received as part of a validation request to validate metering of DRaaS  120  in first cloud  230 , and specifies the details of the protection/disaster recovery policies setup in the first cloud ( 230 ). The validation request is received when a user/administrator clicks/selects “Validate Protection Policies” button  440  in  FIG.  4 C . Some of the policy data may be received when a user updates/change a policy and/or changes categories associated with a policy, for example, upon a user clicking/selecting “Save” button  490  in  FIG.  4 D . 
     For illustration it is assumed that a user/administrator first setup two protection policies on 5 Nov. 2020, added two more protection policies on 18 Dec. 2020 and then clicked/selected the “Validate Protection Policies” button  440  in  FIG.  4 C . Rows  561 - 564  capture the details of the four protection policies specified by the user/administrator. On 28 Jan. 2021, the administrator removed the association of a first policy (P100) from the corresponding category, updated a second policy (P300) by changing only the RPO and added a third policy (P500). The removal of the association of the first policy is captured by the change in the end date time in row  561  to 28 Jan. 2021 (to indicate the end of policy P100). The update of second policy is captured by the change in the end date time in row  563  to 28 Jan. 2021 (to indicate the end of policy P300) and addition of a new row  565  capturing the details of the updated policy (P301). It may be observed that row  565  reflects the new RPO updated by the administrator. The addition of third policy (P500) is captured in row  566  of table  550 . 
     Thus, testing server  150  (receives and) maintains the category data and policy data required for validating the metering of DRaaS  120  in first cloud  230 . Though not shown, testing server  150  may similarly maintain data corresponding to other clouds (such as cloud  240 ) based on their tenant_IDs (“TE2” for cloud  240 ). Testing server  150  then prepares a test/second cloud for executing the DR workload similar to the first cloud, as described below with examples. 
     8. Test Cloud 
       FIG.  6 A  illustrates the manner in which a test/second cloud is provisioned in a cloud infrastructure in one embodiment. Test cloud  650  represents a test/second cloud provisioned by testing server  150 . Test cloud  650  is shown containing VMs  650 - 1  through  650 -H (H representing any natural number) that may be provisioned on nodes  190  of cloud infrastructure  180 . Groups  650 A and  650 B respectively represent the set of VMs contained in the primary site and secondary site in test cloud  650 . 
     According to an aspect of the present disclosure, testing server  150  prepares and configures test cloud  650  in response to receiving the validation request noted above. Testing server  150  may accordingly provide/select one or more nodes  190  in cloud infrastructure  180 , provision multiple VMs ( 650 - 1  through  650 -H) in line with their corresponding resource definitions specified in table  500 , and configure the disaster recovery service to operate according to the disaster recovery policies specified in table  550 . In other words, the configuration of test cloud  650  is the same as the configuration of the first cloud  230  sought to be validated. 
     It may be appreciated that the first cloud  230  is a hybrid cloud in which the first primary site ( 230 A) is hosted in a on-premises infrastructure ( 130 ) and the first secondary site ( 230 B) is hosted in a first cloud infrastructure ( 180 ), while the test/second cloud  650  is a multi-cloud cloud comprising a second primary site ( 650 A) and a second secondary site ( 650 B), both being hosted in the second cloud infrastructure ( 180 ). It may be readily observed that test cloud  650  is separate and distinct from cloud ( 230 ) whose metering of the usage of DRS is sought to be validated. 
       FIG.  6 B  illustrates the manner in which disaster recovery as a service is provided for test cloud ( 650 ) in one embodiment.  FIG.  6 B  contains blocks similar to those in  FIG.  2 C , and accordingly the description of the similar blocks is not repeated here for conciseness. 
     During normal operation, DRaaS  120  facilitates the backup/replication of data at various time instances from primary site  650 A to secondary site  650 B as indicated by arrow  655 . Event collector  250  collects and stores information on the backups performed for test cloud  650  (as indicated by arrow  658 ), with metering service  270  then processing the collected information to determine the number/frequency of backups performed for test cloud  650 . 
     Accordingly, testing server  150  periodically collects from metering service  270  of DRaaS system  120 , measured values representing the actual usage of the DRS/DRaaS by test cloud  650  and then compares the measured values (metering consumption numbers) with corresponding reference values expected during the operation of the test cloud. Testing server  150  then sends a response to the validation request based on a result of the comparing. 
     As described later with respect to  FIGS.  9 D / 9 E, metering of DRaaS  120  for test cloud  650  is validated, as a basis for validating the metering of the usage of DRS in requested first cloud  230 . It is accordingly helpful to understand the nature of metering of DRS usage in clouds. Accordingly,  FIGS.  7  through  8 E  are used to establish the manner in which usage of DRS in clouds can be metered and billed in an embodiment. 
     9. Metering and Billing DRS Usage in Clouds 
       FIG.  7    is a timeline ( 700 ) according to which the usage of a disaster recovery service in clouds is monitored in one embodiment. In particular, timeline  700  is shown in weeks, with the Monday of each week marked on the timeline (e.g., 14 Dec. 2020, 4 Jan. 2021, etc.). Time instance  705  represents the time at which the validation request (to validate the metering of usage of DRS in cloud  230 ) was received and is assumed to be 23 Jan. 2021. Time interval  710  (from 25 Jan. 2021 to 31 Jan. 2021) represents the time interval/duration during which testing server  150  collects the measured values from test cloud  650 . Time interval  710  is shown in more detail as timeline  710  below timeline  700 . 
     Timeline  710  is shown in days (e.g., 25 Jan. 2021, 26 Jan. 2021, etc.). Time instance  715  represents the time (28 Jan. 2021 16:45) at which testing server  150  receives an indication that the setup of the DRS in cloud  230  has been changed to operate according to a second configuration (different from the first configuration received along with the validation request). Time interval  720  represents a portion of timeline  710  which is shown in more detail as timeline  720  below timeline  710 . 
     In the following description, it is assumed that event collector  250  collects DRS usage information from nodes  190  every 1 minute (collection interval), and accordingly timeline  720  is shown in minutes (with time instances “8:15”, “8:30” etc. shown according to 24-hour format). 
     Time interval  730  represents a metering interval (assumed to be 15 minutes for illustration) according to which DRS usage is measured. Thus, metering service  270  measures DRS usage in a sequence of metering intervals such as 9:00-9:15, 9:15-9:30, 9:30-9:45, etc. It should be noted that the metering intervals are non-overlapping durations, with 9:00-9:15 representing the time instances in the duration 9:00:01 (:01 representing the seconds) to 9:15:00, and 9:15-9:30 representing the time instances in the duration 9:15:01 to 9:30:00. It may be further appreciated that the billing of the DRS usage may be performed at a more general level. 
     Time interval  735  represents a billing interval (assumed to be 1 hour for illustration) according to which DRS usage is billed for each cloud and/or tenant. Thus, billing service  280  bills customers/tenants based on the usage of DRS by their cloud in each billing interval such as 9:00-10:00 (more specifically 9:00:01 to 10:00:00), 10:00-11:00, 11:00-12:00, etc. Each billing interval ( 735 ) contains multiple (here 4) metering intervals. 
     According to an aspect of the present disclosure, when a request to validate metering of cloud  230  is received at a time instance, testing server  150  performs the collecting of measured values for corresponding durations starting from a next metering interval following the time instance such that each of the corresponding durations aligns with a respective metering interval of the sequence of metering intervals. In timeline  720 , if the request is received at time instance  740  (e.g., 8:20), testing server  150  waits for duration 550 (10 minutes) and then starts the collecting of the measured values from metering server  270  at the next metering interval of 8:30-8:45. 
     The manner in which DRS usage information is collected and processed by testing server  150  with respect to timeline  700  is described below with examples. 
     10. Collecting DRS Usage Information 
       FIG.  8 A  depicts portions of DRS usage information collected for a cloud in one embodiment. Table  800  depicts a portion of the DRS usage information collected by event collector  250  from various nodes  190  in test cloud  650 . Though event collector  250  collects the usage information every minute, for conciseness, only the relevant time instances at which at least one disaster recovery policy/protection policy has been activated is shown in table  800 . 
     Column  801  indicates a corresponding time instance at which at least one policy has been activated, column  802  indicates the cloud (here “TE3” for all rows) in which the policy has been activated, and column  803  indicates the list of policies activates at that time instance. Thus, each of the rows of table  800  specifies the details of corresponding policies activated as part of DRS. It may be readily observed that policy P200 is shown activated every 15 minutes (rows  811 ,  812 ,  816 , etc.) as per the RPO of P200. Similarly, policy P300 is shown activated every 1 hour (rows  812 ,  813 ,  818 , etc.), policy P100 is shown activated every 12 hours (rows  814 ,  815 ,  817 , etc.) and policy P400 is shown activated every day (rows  815 ,  821 ,  823 , etc.). Policies P301 and P500 are shown activated only after 28 Jan. 2021, after receiving the indication of change in configuration at time instance  715 . 
     Rows  819  and  820  indicate that policy P300 was activated at the corresponding time instances 28 Jan. 2021 17:00 and 28 Jan. 2021 18:00, though the end date time of policy P300 is 28 Jan. 2021 16:45 (as per row  563  in policy data  550  of  FIG.  5 B ). Furthermore, rows  816 A and  816 B corresponding to activation of policy P200 at time instances 27 Jan. 2021 10:15 and 27 Jan. 2021 11:00 indicate that policy P200 was not activated at time instances 27 Jan. 2021 10:30 and 27 Jan. 2021 10:45 as per the RPO of P200. Rows  822  and  823  indicate the last two time instances in time interval  710  at which the DRS usage information was collected by event collector  250 . 
     Thus, event collector  250  collects the DRS usage information from nodes  190  hosting test cloud  650 . Metering service  270  measures the resources used by test cloud  650  based on the collected usage information (table  800 ) as described in detail below. 
     11. Metering DRS Usage 
       FIG.  8 B  depicts the manner in which the DRS usage in a cloud is metered in one embodiment. In particular, table  830  depicts the manner in which the DRS usage in test cloud  650  (as indicated by the tenant_ID “TE3”) is metered by metering service  270 . The various disaster recovery policies applicable in test cloud  650  is shown as corresponding columns in table  830  and are the same policies specified in table  550  for first cloud  230 . The dates in time interval  710  are shown as rows in table  830 . 
     Thus, each cell at the intersection of a column/policy and a row/date indicates the number of times the corresponding policy has been activated in the corresponding date. The values for the cells of table  830  is obtained based on the information in table  800 , where the value for a cell is determined by determining the number of times the corresponding policy is present in the DRS usage information of table  800  for the corresponding day. For example, for day 25 Jan. 2021 and policy P100, the value in the cell is shown as 2 corresponding to the activation of policy P100 in rows  814  and  815  of table  800 . The values for the other cells of table  830  may similarly be calculated based on the information in table  800 . 
     Row  841  depicts number of times each policy has been on day 25 Jan. 2021. In one embodiment, metering service  270  also captures the amount of infrastructure resources that were backed up as part of backing up the cloud resources (VMs). In one embodiment, the infrastructure resources are “vcpu”—the number of (virtual) CPU cycles (e.g., 1×, 2×, 4×), “memory”—the amount of memory (RAM) in gigabytes (e.g., 1 GB, 2 GB, 4 GB) and “storage”—the amount of persistent storage in gigabytes (e.g., 50 GB, 100 GB, 200 GB). Alternative embodiments may have more or less infrastructure resources as will be apparent to one skilled in the relevant arts. 
     Thus, rows  842 - 844  (shown as sub-rows of row  841 ) depicts the numbers corresponding to vcpu, memory and storage captured for different polices on 25 Jan. 2021. Similarly, the sub-rows of other rows capture the amount infrastructure resources that were backed up on the corresponding other days. 
     It may be observed that row  845  indicates that policy P200 has been activated only 94 times (in view of absence of rows between  816 A and  816 B in table  800 ) and row  846  indicates that policy P300 has been invoked 18 times (in view of rows  819  and  820  in table  800 ). Row  843  indicates the total number of times a policy was invoked in time interval  710  (25 Jan. 2021 to 31 Jan. 2021). 
     Thus, metering service  270  measures the DRS usage in test cloud  650 . In one embodiment, metering service  270  collates the DRS usage based on metering tiers, as described below with examples. 
       FIG.  8 C  depicts the manner in which the DRS usage in a cloud is collated based on metering tiers in one embodiment. In particular, table  850  depicts the manner in which the DRS usage in test cloud  650  (as indicated by the tenant_ID “TE3”) is collated based on metering tiers by metering service  270 . The dates in time interval  710  are shown as columns in table  850 , while the metering tiers/pricing levels are shown as rows  861 ,  862  and  866  in table  850 . Column  851  depicts the totals for the time interval  710 . 
     Each cell at the intersection of a column/date and a row/billing tier in rows  861 ,  862  and  866  indicates the number of times a policy falling in the corresponding metering tier has been activated in the corresponding date. The values in rows  861 ,  862  and  866  for the cells of table  850  is obtained based on the information in table  830 , where the value for a cell is determined by adding all the values in table  830  for policies falling in the corresponding metering tier for the corresponding day. For example, for day 25 Jan. 2021 and metering tier “Advanced”, the value in the cell is shown as 3 which is the sum of the values (2, 0, 1) for P100, P301 and P400 (falling in the metering tier “Advanced”) for the day 25 Jan. 2021. Similarly, the values in rows  866  (“Premium”) is obtained by adding the values for P200, P300 and P500 in table  830  for the corresponding day. The values in row  861  is shown as 0 since there are no policies that fall in the metering tier “Basic” in table  830 . 
     Rows  863 - 865  (shown as sub-rows of row  862 ) specify the details of the infrastructure resources backed up as part of backing up of the cloud resources (VMs). The values in each of sub-rows (e.g.,  863  for “vcpu”) is determined by adding all the values in table  830  for the infrastructure resource (“vcpu”) metered for all the policies (P100, P301 and P400) falling in the corresponding metering tier (“Advanced”) for the corresponding day. Similarly, the values in rows  867 - 869  are determined based on the infrastructure resources metered for the policies P200, P300 and P500 falling in the metering tier “Premium”. 
     It may be appreciated that such collation may be required to handle various billing scenarios. For example, in the above noted embodiment, it is assumed that each instance of activation of a policy is to be billed, and accordingly collation is merely performed based on metering tiers. However, in an alternative embodiment, billing may be performed based the whether a policy/metering tier is activated or not in each billing interval (1 hour), irrespective of the actual number of times the policy/metering tier is activated in the billing interval. Thus, for the metering tier “Premium” on day “25 Jan. 2028” the total number of activations to be billed would be 48 (24 times P200+24 times P300) instead of 120 (96 times P200+24 times P300). The other values in table  850  may similarly be collated to reflect the alternative billing scenario. 
     Metering service  270  then forwards the portions of table  830  and table  850  to billing service  280 , which in turn computes and bills the customers/tenants based on the metering of their DRS usage. The manner in which billing service  280  bills customers/tenants is described below with examples. 
     12. Billing DRS Usage 
     Billing server  280  receives the information of tables  830  and  850  and computes the billing of the customer/tenant. In one embodiment, the totals in the last column  851  of table  850  may be multiplied by appropriate prices to arrive at the billing to be done to the customer/tenant for the DRS usage in time interval  710  (25 Jan. 2021 to 31 Jan. 2021). 
       FIG.  8 D  depicts a rate card according to which a customer/tenant is billed in one embodiment. In particular, table  870  depicts the rate card (prices) for test cloud  650  (as indicated by the tenant_ID “TE3”). The metering tiers (“Basic”, “Advanced”, “Premium”) are shown as rows in table  870 , while the infrastructure resources (vcpu, memory, storage) are shown as columns in table  870 . Each cell at the intersection of a row/metering tier and a column/infrastructure resource indicates the price for the infrastructure resource (per x, per GB, etc.) used by the corresponding metering tier. 
     It may be appreciated that the prices shown in rate card of table  870  are typically in terms of a monetary unit/currency (e.g., US Dollars). However, for conciseness, the prices in table  870  (and also in the other tables depicting prices described below), the monetary unit/currency is not shown in the drawings. In one embodiment, the rate card of table  870  is the same as the rate card of the requesting tenant (“TE1”). 
       FIG.  8 E  depicts the manner in which the DRS usage in a cloud is billed in one embodiment. In particular, table  880  depicts the manner in which the DRS usage in test cloud  650  (as indicated by the tenant_ID “TE3”) is billed by billing service  280 . The metering tiers (“Basic”, “Advanced”, “Premium”) are shown as rows in table  880 , while the infrastructure resources (vcpu, memory, storage) are shown as columns in table  880 . 
     Each cell at the intersection of a row/metering tier and a column/infrastructure resource indicates the total price for the infrastructure resource used by the corresponding metering tier in time interval  710  (25 Jan. 2021 to 31 Jan. 2021). The value in each cell of rows  891 - 893  is computed by multiplying the totals in the last column  851  of table  850  with the corresponding rate/price specified in the rate card of table  870 . For example, the value “204.60” for “vcpu” for “Advanced” metering tier is computed by multiplying the total for “Advanced vcpu” in column  851  (that is, 93×) with the rate/price for the combination of “Advanced” and “vcpu” in table  870  (that is, 2.2). 
     Each of the rows between rows  894  and  895  (shown as sub-rows of row  893 ) indicate the total price for the infrastructure resource used by the corresponding metering tier in a corresponding day (“25 Jan. 2021”, “26 Jan. 2021”, etc.) in time interval  710 . The values of the sub-rows are also computed similar to the computation of rows  891 - 893 . Row  896  specifies the total price to be billed to the customer/tenant for each of the infrastructure resources and is determined by adding the values in rows  891 - 893 . 
     Thus, the DRS usage of different clouds ( 230 ,  240 , etc.) is metered and billed to the corresponding owners/tenants. As noted above, customer/tenant (TE1) may wish to validate whether the metering (and in turn, the billing) of the DRS usage of their cloud  230  is accurate. 
     In response to a request to validate metering of DRS usage in (a first) cloud  230 , testing server  150  provisions test cloud  650  similar to the first cloud (table  500  of  FIG.  5 A ) and configures the test cloud to operate with the same disaster recovery policies/protection policies (table  550  of  FIG.  5 B ) as that of the first cloud  230 . 
     Testing server  150  then retrieves the collected DRS usage information of  FIG.  8 A  by interfacing with event collector  250 . Testing server  150  then builds the metering table of  FIG.  8 B  and the collated table of  FIG.  8 C  based on the retrieved/collected DRS usage information. Testing server  150  also computes the billing table of  FIG.  8 E  based on the rate card of  FIG.  8 D . It should be appreciated that as test cloud  650  is the same as the first cloud  230 , the information of  FIGS.  8 A,  8 B,  8 C and  8 E  reflect the manner in which the customer/tenant of first cloud  230  would be metered and billed for the time interval  710 . 
     Testing server  150  then determines expected values representing expected usage of the DRS in test cloud  650  and then compares the expected values with the measured values to determine the accuracy of metering service  270 . The manner in which testing server  150  determines the expected values with the corresponding measured values is described below with examples. 
     13. Determining Expected Values 
       FIG.  9 A  depicts portions of expected (metering) values representing expected usage of DRS in a cloud in one embodiment. In particular, table  900  depicts portions of the expected values representing the expected usage of DRaaS  120  in test cloud  650  (as indicated by the tenant_ID “TE3”). 
     Table  900  is similar to table  830  of  FIG.  8 B  and shows the disaster recovery policies applicable in test cloud  650  as corresponding columns and dates in time interval  710  as corresponding rows. Each cell in table  900  at the intersection of a column/policy and a row/date indicates the number of times the corresponding policy is expected to be activated in the corresponding date. For example, for day 25 Jan. 2021 and policy P100, the value in the cell is shown as 2 indicating that policy P100 is expected to be activated 2 times on day 25 Jan. 2021. 
     It may be observed that row  911  indicates that policy P200 is expected to be activated 96 times and row  912  indicates that policy P300 is expected to be invoked 16 times. Row  913  indicates the total number of times a policy is expected to be invoked in time interval  710  (25 Jan. 2021 to 31 Jan. 2021). 
     The values in the cells of table  900  may be calculated using the below: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 EV(p, d) = 
               
               
                   
                  when p is type day: 
               
               
                   
                   if DateDiff(d, StartDate(p) modulo RPO(p) = 0 then 1 else 0 
               
               
                   
                  when p is type hours: 
               
               
                   
                   ceil((EndHour(p, d)-StartElour(p, d))/RPO(p)) 
               
               
                   
                  when p is type minutes: 
               
               
                   
                   (EndHour(p, d)-StartHour(p, d))*ciel(60/RPO(p)) 
               
               
                   
               
            
           
         
       
     
     Where, 
     EV(p, d) is the expected value for activation of a policy p on day d; 
     DateDiff calculates the difference between two dates provided as parameters; 
     StartDate(p) is the start date of the policy p (based on column “Start Date Time” in table  550  of  FIG.  5 B ); 
     StartHour(p, d) is the start hour of the policy p on day d in 24-hour format (based on column “Start Date Time” in table  550  of  FIG.  5 B ); 
     EndHour(p, d) is the end hour of the policy p on day d in 24-hour format (based on column “End Date Time” in table  550  of  FIG.  5 B ); 
     RPO(p) is the RPO of policy p (as specified in column “RPO” in table  550  of  FIG.  5 B ); 
     modulo and ceil are mathematical functions. 
     Some example computations are shown below: 
     
       
         
           
             EV 
             ⁡ 
             ( 
             
               
                 “ 
                 
                   P 
                   ⁢ 
                   300 
                 
                 ” 
               
               , 
               
                 “ 
                 
                   25 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   Jan 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   2021 
                 
                 ” 
               
             
             ) 
           
         
       
       
         
           
             
               
                 
                   
                     
                       
                         = 
                         
                           ceil 
                           ( 
                           
                             ( 
                             
                               
                                 EndHour 
                                 ⁡ 
                                 ( 
                                 
                                   
                                     “ 
                                     
                                       P 
                                       ⁢ 
                                       300 
                                     
                                     ” 
                                   
                                   , 
                                   
                                     “ 
                                     
                                       25 
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       Jan 
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       2021 
                                     
                                     ” 
                                   
                                 
                                 ) 
                               
                               ⁢ 
                               ‐ 
                               ⁢ 
                               
                                 StartHour 
                                 ( 
                                 
                                   
                                     “ 
                                     
                                       P 
                                       ⁢ 
                                       300 
                                     
                                     ” 
                                   
                                   , 
                                 
                               
                             
                           
                         
                       
                     
                   
                   
                     
                       
                         
                           
                             
                               
                                 “ 
                                 
                                   25 
                                   ⁢ 
                                   ‐ 
                                   ⁢ 
                                   Jan 
                                   ⁢ 
                                   ‐ 
                                   ⁢ 
                                   2021 
                                 
                                 ” 
                               
                               ) 
                             
                             ) 
                           
                           / 
                           
                             RPO 
                             ⁡ 
                             ( 
                             
                               “ 
                               
                                 P 
                                 ⁢ 
                                 300 
                               
                               ” 
                             
                             ) 
                           
                         
                         ) 
                       
                     
                   
                 
               
             
             
               
                 
                   = 
                   
                     ceil 
                     ⁡ 
                     ( 
                     
                       
                         ( 
                         
                           24 
                           ⁢ 
                           ‐ 
                           ⁢ 
                           0 
                         
                         ) 
                       
                       / 
                       1 
                     
                     ) 
                   
                 
               
             
             
               
                 
                   = 
                   24 
                 
               
             
           
         
       
       
         
           
             EV 
             ⁡ 
             ( 
             
               
                 “ 
                 
                   P 
                   ⁢ 
                   200 
                 
                 ” 
               
               , 
               
                 “ 
                 
                   26 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   Jan 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   2021 
                 
                 ” 
               
             
             ) 
           
         
       
       
         
           
             
               
                 
                   
                     
                       
                         
                           
                             
                               = 
                                 
                               
                                 ( 
                                 
                                   E 
                                   ⁢ 
                                   n 
                                   ⁢ 
                                   d 
                                   ⁢ 
                                   H 
                                   ⁢ 
                                   
                                     our 
                                     ( 
                                     
                                       
                                         “ 
                                         
                                           P 
                                           ⁢ 
                                           200 
                                         
                                         ” 
                                       
                                       , 
                                       
                                         “ 
                                         26 
                                       
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       Jan 
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       2021 
                                     
                                   
                                 
                               
                             
                             ” 
                           
                           ) 
                         
                         ⁢ 
                         ‐ 
                         ⁢ 
                         
                           StartHour 
                           ( 
                           
                             
                               “ 
                               
                                 P 
                                 ⁢ 
                                 200 
                               
                               ” 
                             
                             , 
                           
                         
                       
                     
                   
                   
                     
                       
                         
                           
                             
                               
                                 
                                   “ 
                                   26 
                                 
                                 ⁢ 
                                 ‐ 
                                 ⁢ 
                                 Jan 
                                 ⁢ 
                                 ‐ 
                                 ⁢ 
                                 2021 
                               
                               ” 
                             
                             ) 
                           
                           ) 
                         
                         * 
                         
                           ceil 
                           ⁡ 
                           ( 
                           
                             60 
                             / 
                             
                               RPO 
                               ⁡ 
                               ( 
                               
                                 “ 
                                 
                                   P 
                                   ⁢ 
                                   200 
                                 
                                 ” 
                               
                               ) 
                             
                           
                           ) 
                         
                       
                     
                   
                 
               
             
             
               
                 
                   = 
                     
                   
                     
                       ( 
                       
                         24 
                         ⁢ 
                         ‐ 
                         ⁢ 
                         0 
                       
                       ) 
                     
                     ⋆ 
                     
                       ceil 
                       ⁡ 
                       ( 
                       
                         60 
                         / 
                         15 
                       
                       ) 
                     
                   
                 
               
             
             
               
                 
                   = 
                     
                   96 
                 
               
             
           
         
       
       
         
           
             EV 
             ⁡ 
             ( 
             
               
                 “ 
                 
                   P 
                   ⁢ 
                   500 
                 
                 ” 
               
               , 
               
                 “ 
                 
                   28 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   Jan 
                   ⁢ 
                   ‐ 
                   ⁢ 
                   2021 
                 
                 ” 
               
             
             ) 
           
         
       
       
         
           
             
               
                 
                   
                     
                       
                         = 
                           
                         
                           ceil 
                           ( 
                           
                             ( 
                             
                               
                                 EndHour 
                                 ⁡ 
                                 ( 
                                 
                                   
                                     “ 
                                     
                                       P 
                                       ⁢ 
                                       500 
                                     
                                     ” 
                                   
                                   , 
                                   
                                     “ 
                                     
                                       28 
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       Jan 
                                       ⁢ 
                                       ‐ 
                                       ⁢ 
                                       2021 
                                     
                                     ” 
                                   
                                 
                                 ) 
                               
                               ⁢ 
                               ‐ 
                               ⁢ 
                               
                                 StartHour 
                                 ( 
                                 
                                   
                                     “ 
                                     
                                       P 
                                       ⁢ 
                                       500 
                                     
                                     ” 
                                   
                                   , 
                                 
                               
                             
                           
                         
                       
                     
                   
                   
                     
                       
                         
                           
                             
                               
                                 “ 
                                 
                                   28 
                                   ⁢ 
                                   ‐ 
                                   ⁢ 
                                   Jan 
                                   ⁢ 
                                   ‐ 
                                   ⁢ 
                                   2021 
                                 
                                 ” 
                               
                               ) 
                             
                             ) 
                           
                           / 
                           
                             RPO 
                             ⁡ 
                             ( 
                             
                               “ 
                               
                                 P 
                                 ⁢ 
                                 500 
                               
                               ” 
                             
                             ) 
                           
                         
                         ) 
                       
                     
                   
                 
               
             
             
               
                 
                   = 
                   
                     ceil 
                       
                     ( 
                     
                       
                         ( 
                         
                           24 
                           ⁢ 
                           ‐ 
                           ⁢ 
                           17 
                         
                         ) 
                       
                       / 
                       3 
                     
                     ) 
                   
                 
               
             
             
               
                 
                   = 
                     
                   3 
                 
               
             
           
         
       
     
     Similarly, the expected values for each combination of policy and day may be calculated and table  900  generated by testing server  150 . The values in the sub-rows of each row correspond to infrastructure resources and may also be compute based on the expected values calculated for a policy and day and the definition of the VMs backed up as part of the policy. For example, the value (“384×”) in a sub-row (e.g., vcpu) for a policy (e.g., P200) is calculated as the product of the total amount of infrastructure resource (here, 4× for “vcpu”) defined for the VMs in the category (“Tier1-Minute”) for the policy (values in column “VM Total” of table  500  of  FIG.  5 A ) and the number of times the policy is expected to be activated on that day, that is, EV(policy, day) (here, EV(“P200”, “25 Jan. 2021”)=96). 
     According to an aspect of the present disclosure, testing server  150  determines the expected values of table  900  as being prior values representing actual usage of the DRS in the first cloud  230  in a past duration when the first cloud  230  was operating based on the first configuration. Testing server  150  also collects the measured values for a first duration after receipt of the validation request, the first duration equaling the past duration. 
     For example, in timeline  700 , the past duration may be time interval  770  (21 Dec. 2020 to 27 Dec. 2020) during which cloud  230  was operating based on the policy data of  FIG.  5 B . The measured values are collected for time interval  710  having the same duration (7 days) as that of the past time interval  770 . Accordingly, testing server  150  retrieves/collects from event collector  250  the DRS usage information for cloud  230  for time interval  770 . 
       FIG.  9 B  depicts portions of DRS usage information collected for a cloud in one embodiment. In particular, table  920  depicts a portion of the DRS usage information collected by event collector  250  (in turn by testing server  150 ) from various nodes  140 / 190  in cloud  230 . Similar to  FIG.  8 A , table  920  depicts only the relevant time instances at which at least one disaster recovery policy/protection policy has been activated. It may be observed that column  921  indicates corresponding time instances in the time interval  770  (instead of time interval  710  in table  800 ), and column  922  indicates that the cloud for which the policies have been activated is cloud  230  (“TE1” for all rows). 
     It may be appreciated that rows  932  and  933  indicate that policy P300 was not activated (as expected) in view of its end date time as noted above. Furthermore, the rows from  931 A and  931 B indicate that policy P200 was activated as per the as per the RPO of P200 (as expected). 
     After retrieving the usage information of table  920 , testing server  150  determines the metering of cloud  230  for time interval  770  based on the usage information. The determination may be performed similar to the determination of metering table  830  from the usage information of table  800  as noted above, and accordingly the description is not repeated here for conciseness. Testing server  150  may then populate the expected values of table  900  from the metering table determined based on the DRS usage information of table  920  for cloud  230  in time interval  770 . 
     According to an aspect of the present disclosure, when the first configuration is received along with the (validation) request, testing server  150  examines prior configurations setup for the DRS in the first cloud ( 230 ) to identify a prior duration having a corresponding prior configuration matching the first configuration, as the past duration. For example, testing server  150  may review the various prior durations (e.g., 14 Dec. 2020 to 20 Dec. 2020, 21 Dec. 2020 to 27 Dec. 2020, 11 Jan. 2021 to 17 Jan. 2021, etc.) prior to time interval  710  and then identify that time interval  770  is the prior duration having a prior configuration matching the first configuration (table  550  of  FIG.  5 B ). 
     In one embodiment when test cloud  650  is operating along with first cloud  230 , testing server  150 , prior to deployment/preparing of test cloud  650 , first fetches the metering and billing consumption numbers for the customer (using tenant_ID “TE1”) for a past metering/billing cycle and stores the fetched numbers in a persistent storage (e.g., database). Testing server  150  then builds the expected values for the DR/test workload taking into consideration existing metering/billing numbers and all the RPOs (Recovery Point Objective) sought to be validated like minute, hour, day, etc. The expected values are stored the persistent storage. 
     After execution of the test workload (that is after performance of the backups according to the configuration of test cloud  650 ), testing server  150  collects the measured values representing the actual usage of the DRS/DRaaS by test cloud  650  and then compares the measured values with the expected values retrieved from the persistent storage. A match of the metered values with the expected values indicates that the metering (and by extension the billing) service of the disaster recovery service is working perfectly, and accordingly the metering of the usage of the DRS is accurate. 
     According to another aspect of the present disclosure, testing server  150  selects the past duration and identifies a prior configuration applicable to the selected past duration as the first configuration. For example, assuming that the validation request received by testing server  150  does not include the policy data of table  550  of  FIG.  5 B , testing server  150  may select a past duration (time interval  770 ) and then identify the prior configuration specified for the past duration as the configuration to be used in test cloud  650 . 
     After determining the expected (metering) values of table  900 , testing server  150  collates the metered values based on metering tiers. The collation may be performed similar to the collation of collated table  850  from metering table  830  as noted above, and accordingly the description is not repeated here for conciseness. 
       FIG.  9 C  depicts the manner in which expected values for a cloud is collated based on metering tiers in one embodiment. In particular, table  950  depicts the manner in which the DRS usage in test cloud  650  (as indicated by the tenant_ID “TE3”) is collated based on metering tiers by metering service  270 . The dates in time interval  710  are shown as columns in table  950 , while the metering tiers/pricing levels and infrastructure resources are shown respectively as rows/sub-rows in table  950 . Column  951  depicts the totals for the time interval  710 . 
     After determining the expected metering/collated values, testing server  150  compares the expected values with the measured values to determine the accuracy of metering service  270 . The manner in which such comparison may be performed is described below with examples. 
     14. Comparing Measured and Expected Values 
       FIG.  9 D  depicts the manner in which expected values are compared with measured values to validate metering of usage of DRS in a cloud in one embodiment. Table  960  depicts the comparison of the measured metered values (column  961 ) and expected metered values (column  962 ). The values in column  961  correspond to the total metered values in “Total” column  851  in table  850 , while the values in column  962  correspond to the total expected values in “Total” column  951  in table  950 . 
     Testing server  150  compares the measured values in column  961  with the corresponding expected values in column  962  to determine whether metering service  270  is accurate. In one embodiment, metering service  270  is determined to be accurate only if the measured values in column  961  match the expected values in column  962  for corresponding metering tiers. As noted above, a match may be determined even if the measured value differs from the expected value by an acceptable margin of error (e.g., ±2% of the expected value). 
     Rows  971  and  972  indicate that there is no difference between the measured and expected values for the “Basic” and “Advanced” billing tiers. Row  973  indicates that there is a match between the measured and expected values for “Premium” billing tier. However, the values for the usage of the infrastructures (rows  974 - 976 ) indicate that there may potentially be an issue with the “Premier” billing tier. 
     In one embodiment, metering service  270  is determined to be accurate only if the measured values match the expected values for all billing tiers (and also corresponding infrastructure usage), that is all the rows in table  960 . In alternative embodiments, the metering service may be determined to be accurate based on the match of measured value and expected values for only a subset of billing tiers (e.g., only “Advanced” billing tier). 
     It may be appreciated that in the above embodiment, the validation of the metering service is performed based on comparison of the expected and measured metering values. However, in alternative embodiments, the validation may be performed based on the billing values and/or any other formula applied on the metering and/or billing values as will be apparent to one skilled in the relevant arts by reading the disclosure herein. 
       FIG.  9 E  depicts the manner in which expected values are compared with measured values to validate billing of usage of DRS in a cloud in one embodiment. Table  980  depicts the comparison of the measured and expected billed values for different infrastructure resources (columns  981 - 983 ). The values in the “Measured” sub-column in each of columns  981 - 983  correspond to the billed values in corresponding infrastructure columns in table  880  of  FIG.  8 E , while the values in the “Expected” sub-column in each of columns  981 - 983  is computed by multiplying the totals in the last column  951  of table  950  in  FIG.  9 C  with the corresponding rate/price specified in the rate card of table  870  in  FIG.  8 D . 
     It may be observed that rows  991  and  992  indicate that there is no difference between the measured and expected billing values for the “Basic” and “Advanced” billing tiers, while row  993  indicates that there is a mismatch (no match) between the measured and expected billing values for “Premium” billing tier. Rows  994 - 995  (sub-rows of row  993 ) indicate the specific dates where there is a mismatch in the billing values, while row  996  indicates a mismatch in the total billing values (between the measured totals and the expected totals). 
     Thus, testing server  150 , provided according to several aspects of the present disclosure, validates metering of usage of DRS in a cloud at least to ensure that the measurements captured by the metering service for the cloud/tenant are accurate. 
     It should be appreciated that the features described above can be implemented in various embodiments as a desired combination of one or more of hardware, software, and firmware. The description is continued with respect to an embodiment in which various features are operative when the software instructions described above are executed. 
     15. Digital Processing System 
       FIG.  10    is a block diagram illustrating the details of digital processing system  1000  in which various aspects of the present disclosure are operative by execution of appropriate executable modules. Digital processing system  1000  may correspond to testing server  150 . 
     Digital processing system  1000  may contain one or more processors such as a central processing unit (CPU)  1010 , random access memory (RAM)  1020 , secondary memory  1030 , graphics controller  1060 , display unit  1070 , network interface  1080 , and input interface  1090 . All the components except display unit  1070  may communicate with each other over communication path  1050 , which may contain several buses as is well known in the relevant arts. The components of  FIG.  10    are described below in further detail. 
     CPU  1010  may execute instructions stored in RAM  1020  to provide several features of the present disclosure. CPU  1010  may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU  1010  may contain only a single general-purpose processing unit. 
     RAM  1020  may receive instructions from secondary memory  1030  using communication path  1050 . RAM  1020  is shown currently containing software instructions constituting shared environment  1025  and/or other user programs  1026  (such as other applications, DBMS, etc.). In addition to shared environment  1025 , RAM  1020  may contain other software programs such as device drivers, virtual machines, etc., which provide a (common) run time environment for execution of other/user programs. 
     Graphics controller  1060  generates display signals (e.g., in RGB format) to display unit  1070  based on data/instructions received from CPU  1010 . Display unit  1070  contains a display screen to display the images defined by the display signals (for example, portions of the user interface shown in  FIGS.  4 A- 4 D ). Input interface  1090  may correspond to a keyboard and a pointing device (e.g., touch-pad, mouse) and may be used to provide inputs (for example, in the portions of the user interface shown in  FIGS.  4 A- 4 D ). Network interface  1080  provides connectivity to a network (e.g., using Internet Protocol), and may be used to communicate with other systems (of  FIG.  1   ) connected to the networks ( 120 ). 
     Secondary memory  1030  may contain hard drive  1035 , flash memory  1036 , and removable storage drive  1037 . Secondary memory  1030  may store the data (for example, data portions shown in  FIGS.  5 A- 5 B,  8 A- 8 C and  9 A- 9 D ) and software instructions (for example, for implementing the various features of the present disclosure as shown in  FIG.  3   , etc.), which enable digital processing system  1000  to provide several features in accordance with the present disclosure. The code/instructions stored in secondary memory  1030  may either be copied to RAM  1020  prior to execution by CPU  1010  for higher execution speeds, or may be directly executed by CPU  1010 . 
     Some or all of the data and instructions may be provided on removable storage unit  1040 , and the data and instructions may be read and provided by removable storage drive  1037  to CPU  1010 . Removable storage unit  1040  may be implemented using medium and storage format compatible with removable storage drive  1037  such that removable storage drive  1037  can read the data and instructions. Thus, removable storage unit  1040  includes a computer readable (storage) medium having stored therein computer software and/or data. However, the computer (or machine, in general) readable medium can be in other forms (e.g., non-removable, random access, etc.). 
     In this document, the term “computer program product” is used to generally refer to removable storage unit  1040  or hard disk installed in hard drive  1035 . These computer program products are means for providing software to digital processing system  1000 . CPU  1010  may retrieve the software instructions, and execute the instructions to provide various features of the present disclosure described above. 
     The term “storage media/medium” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage memory  1030 . Volatile media includes dynamic memory, such as RAM  1020 . Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge. 
     Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus  1050 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. 
     Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. 
     Furthermore, the described features, structures, or characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. In the above description, numerous specific details are provided such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the disclosure. 
     16. Conclusion 
     While various embodiments of the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. 
     It should be understood that the figures and/or screen shots illustrated in the attachments highlighting the functionality and advantages of the present disclosure are presented for example purposes only. The present disclosure is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown in the accompanying figures. 
     Further, the purpose of the following Abstract is to enable the Patent Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present disclosure in any way.