Redundancy determination system and redundancy determination method

Abstract

To provide a redundancy determination system capable of cloud bursting without incurring unnecessary costs.SOLUTION: The redundancy determination system is a system capable of extending a system on an on-premises data center to the public cloud by using a computer with a processor and memory. The processor is configured so as to, if the target system recovery time is shorter than the system build time calculated based on the operating status of the system, perform a series of first processing to deploy the system to multiple sites that the public cloud has, and if the target system recovery time is not shorter than the build time, perform a series of second processing to deploy the system to one of the sites that the public cloud has.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to techniques for determining system redundancy in cloud bursting. [Background technology]

[0002] In a large-scale IT environment, it may be cheaper to run systems that continue to operate for a long time in an on-premise data centre than in a public cloud, and it may be cheaper to run systems that operate temporarily in a public cloud. In data analysis processing with large load fluctuations, costs may be reduced by cloud bursting, which processes steady loads in an on-premise data centre and processes temporarily large loads in the cloud. A public cloud is made up of multiple sites so that processing can continue even in the event of a failure. For this reason, in cloud bursting, it is necessary to deploy a system to multiple sites based on the system requirements. To solve such problems, for example, a technique disclosed in Patent Literature 1 is known. In the technique disclosed in Patent Literature 1, a system is deployed to multiple sites. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] US2019 / 0138287 Summary of the Invention [Problem to be solved by the invention]

[0004] In Patent Document 1, the software is deployed to multiple sites regardless of whether it is necessary to deploy to multiple sites, which may result in unnecessary costs. Therefore, determining whether it is necessary to deploy to multiple sites is an issue.

[0005] An object of the present invention is to provide a technique that enables cloud bursting without incurring unnecessary costs. [Means for solving the problem]

[0006] The redundancy determination system according to the present invention is a redundancy determination system that extends a system on an on-premise data centre to a public cloud using a computer having a processor and a memory, and the processor determines whether or not a site in the public cloud is to be upgraded if a target recovery time for the system is shorter than a construction time for the system calculated based on an operational status of the system. Multiple a first process of deploying the system to a site, and if a target recovery time of the system is not shorter than the construction time, deploying the system to a site among the sites of the public cloud; First and a second process of deploying the system at a site. Effect of the Invention

[0007] According to the present invention, cloud bursting can be achieved without incurring unnecessary costs. [Brief description of the drawings]

[0008] [Figure 1] 1 illustrates an example of a system configuration according to a first embodiment. [Diagram 2] 13 shows an example of information held by a deployment destination site determination function. [Diagram 3] An example of SDS VM information is shown. [Figure 4] An example of DB VM information is shown below. [Diagram 5] 13 shows an example of root volume size information. [Figure 6] 11 shows an example of connection line information. [Figure 7] An example of VM fee information is shown. [Figure 8] 13 shows an example of capacity fee information. [Figure 9] An example of DB information is shown below. [Figure 10] 13 illustrates an example of VM count information. [Figure 11] An example of DB operation information is shown below. [Figure 12] 13 shows an example of secondary site advance preparation information. [Figure 13] 13 shows an example of secondary site preparation cost information. [Figure 14] 13 shows an example of a redundancy confirmation screen. [Figure 15] An example of the flow for determining the advance preparation content based on the RTO is shown below. [Figure 16] An example of a flow for determining whether to perform cloud bursting will be shown below. [Figure 17] 1 shows an example of a computer schematic diagram. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS EXAMPLES

[0009] The embodiments will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and are omitted and simplified as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0010] In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0011] In the following explanation, various information may be described using expressions such as "database," "table," and "list," but the various information may be expressed in other data structures. To indicate independence of data structure, "XX table," "XX list," and the like may be referred to as "XX information." When describing identification information, when expressions such as "identification information," "identifier," "name," "ID," and "number" are used, these are interchangeable.

[0012] When there are multiple components having the same or similar functions, they may be described by using the same reference numerals with different subscripts, but when there is no need to distinguish between these multiple components, the subscripts may be omitted.

[0013] In addition, in the following description, processing performed by executing a program may be described, but the program is executed by a processor (e.g., a CPU (Central Processing Unit), a GPU (Graphics Processing Unit)) to perform a defined process using storage resources (e.g., a memory) and / or an interface device (e.g., a communication port) as appropriate, so the subject of the processing may be the processor. Similarly, the subject of the processing performed by executing a program may be a controller, device, system, computer, or node having a processor. The subject of the processing performed by executing a program may be a calculation unit, and may include a dedicated circuit that performs specific processing (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).

[0014] A program may be installed in a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource for storing a program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In the following description, two or more programs may be realized as one program, and one program may be realized as two or more programs.

[0015] As will be described in detail later with reference to Figure 5, the terminals and servers used in this system can be realized, for example, by a general computer 1600 as shown in Figure 17 (schematic computer diagram), which has a CPU 1601, memory 1602, an external storage device 1603 such as an HDD (Hard Disk Drive), a reading / writing device 1607 for reading and writing information from a portable storage medium 1608 such as a CD (Compact Disk) or USB memory, an input device 1606 such as a keyboard or mouse, an output device 1605 such as a display, a communication device 1604 such as a NIC (Network Interface Card) for connecting to a communication network, and an internal communication line (called a system bus) 1609 such as a system bus that connects these together.

[0016] Moreover, various data stored in each terminal or server or used for processing can be realized by the CPU 1601 reading and using it from the memory 1602 or the external storage device 1603. Moreover, each functional unit possessed by each terminal or server (for example, the deployment destination site determination function 17 and the deployment function 18 of the management server 16) can be realized by the CPU 1601 loading a predetermined program stored in the external storage device 1603 into the memory 1602 and executing it.

[0017] The above-mentioned predetermined program may be stored (downloaded) in the external storage device 1603 from the storage medium 1608 via the reading / writing device 1607 or from the network via the communication device 1604, and then loaded onto the memory 1602 and executed by the CPU 1601. Alternatively, the program may be directly loaded onto the memory 1602 from the storage medium 1608 via the reading / writing device 1607 or from the network via the communication device 1604, and executed by the CPU 1601.

[0018] In the following, an example is given in which the system is configured by one computer, but similar functions may be realized by distributing all or part of these functions to one or more computers, such as a cloud, and communicating with each other via a network. Also, as will be specifically explained below, for example, if the RTO (Recovery Time Objective) of the system in the on-premise data centre is shorter than the construction time for the part that extends the system in the on-premise data centre to the public cloud, it is deployed to two or more sites, and otherwise it is deployed to one site.

[0019] FIG. 1 shows an example of a system configuration. The system 1 includes an on-premise data centre 2, a public cloud A 3a, a public cloud B 3b, a connection line 4a, a connection line 4b, and a connection line 4c. The on-premise data centre is a data centre owned by a company that owns an IT system. The on-premise data centre may be a data centre of a data centre operator that provides colocation services. The public cloud is a cloud used by an unspecified number of companies and organisations. The public cloud A 3a includes a site A 5a and a site B 5b. The public cloud B 3c includes a site C 5c. A site is a data centre that executes services provided in the public cloud. The public cloud is made up of multiple sites. Therefore, even if one site is damaged and cannot provide services, the other sites can provide services. The connection line 4a is a line that connects the on-premise data centre 2 and the site A 5a. The connection line 4b is a line that connects the on-premise data centre 2 and the site B 5b. The connection line 4c is a line that connects the on-premise data center 2 and the site C 5c.

[0020] The on-premise data center 2 includes an AP VM (Virtual Machine) 11, a master DB VM 12, a worker DB VM 13, a shared storage 14, and a management server 16. The AP VM 11 is a VM that executes a business application and reads necessary data from the master DB VM 12. The master DB VM 12 is a VM that reads and writes data in the shared storage 14 in response to a request from the AP VM 11 and returns the result to the AP VM 11. The master DB VM 12 requests processing from the worker DB VM 13 or a worker DB VM running on a public cloud in response to a load situation. The worker DB VM 13 is a VM that reads and writes data in the shared storage 14 in response to a request from the master DB VM 12 and returns the result to the master DB VM 12. The shared storage 14 includes data 15. The shared storage 14 reads and writes the data 15 in response to a request from the master DB VM 12 and the worker DB VM 13 and returns the result to the master DB VM 12 and the worker DB VM 13. The management server 16 includes a deployment destination site determination function 17 and a deployment function 18. The deployment destination site determination function 17 is a function that determines which site to use, which VM to deploy, and whether to prepare data when it is predicted that the master DB VM 12 and worker DB VM 13 alone will not be able to process a request from the AP VM 11 within the processing time specified by the system user. The deployment function 18 is a function that builds a system with the configuration determined by the deployment destination site determination function 17.

[0021] Site A 5a includes a worker DB VM 21a, a worker DB VM 21b, and a software-defined storage (SDS) 22a. The worker DB VM 21a is a VM that reads and writes data in the SDS 22a in response to a request from the master DB VM 12 and returns the result to the master DB VM 12. The worker DB VM 21b is similar to the worker DB VM 21a. The SDS 22a includes data 23a. The SDS 22a reads and writes the data 23a in response to a request from the worker DB VM 21a and returns the result to the worker DB VM 21a. Site B 5b and Site C 5c are similar to Site A 5a and include a worker DB VM and an SDS.

[0022] 2 shows an example of information held by the deployment destination site determination function 17. The deployment destination site determination function 17 includes SDS VM information 31, DB VM information 32, root volume size information 33, connection line information 34, VM ​​fee information 35, capacity fee information 36, DB information 37, VM count information 38, DB operation information 39, secondary site advance preparation information 40, secondary site advance preparation cost information 41, and a redundancy confirmation screen 42.

[0023] 3 shows an example of SDS VM information 31. The SDS VM information indicates the deployment time, start time, and stop time of an SDS VM for each public cloud, each site, and each instance type. The SDS VM information 31 includes a public cloud 311, a site 312, an instance type 313, an SDS deployment time 314, an SDS start time 315, and an SDS stop time 316.

[0024] Public cloud 311 indicates the public cloud where the SDS is deployed. Site 312 indicates the site where the SDS is deployed. Instance type 313 indicates the instance type that configures the SDS. SDS deployment time 314 indicates the time it takes to deploy the SDS. SDS start time 315 indicates the time it takes to start the SDS. SDS stop time 316 indicates the time it takes to stop the SDS.

[0025] Figure 4 shows the D B 2 shows an example of VM information 32. The DB VM information indicates the deployment time, start time, and stop time of the DB VM for each public cloud, each site, and each instance type. The DB VM information 32 includes a public cloud 321, a site 322, an instance type 323, a DB deployment time 324, a DB start time 325, and a DB stop time 326.

[0026] Public cloud 321 indicates a public cloud in which the DB VM is deployed. Site 322 indicates a site in which the DB VM is deployed. Instance type 323 indicates an instance type that configures the DB VM. DB deployment time 324 indicates the time it takes to deploy the DB VM. DB startup time 325 indicates the time it takes to start the DB VM. DB shutdown time 326 indicates the time it takes to stop the DB VM.

[0027] 5 shows an example of the root volume size information 33. The root volume size information 33 indicates the required size of the root volume of a VM for each purpose such as DB use, SDS use, etc. The root volume size information 33 includes a purpose 331 and a root volume size 332.

[0028] The usage 331 indicates the usage of the VM. The root volume size 332 indicates the required size of the root volume of the VM.

[0029] 6 shows an example of the connection line information 34. The connection line information 34 shows the bandwidth of the line connecting the on-premise data center and the public cloud site, and the bandwidth used at the time of data acquisition. The connection line information 34 includes a destination public cloud 341, a destination site 342, a line bandwidth 343, and a bandwidth used 344.

[0030] Destination public cloud 341 indicates the public cloud to which the line is connected. Destination site 342 indicates the site to which the line is connected. Line bandwidth 343 indicates the upper limit of the bandwidth that can be used on the line. Used bandwidth 344 indicates the bandwidth used at the time of data acquisition.

[0031] 7 shows an example of the VM fee information 35. The VM fee information 35 shows the usage fee per unit time of a VM for each public cloud, each site, and each instance type. The VM fee information 35 includes a public cloud 351, a site 352, an instance type 353, and a fee 354.

[0032] Public cloud 351 indicates a public cloud in which a VM is deployed. Site 352 indicates a site in which a VM is deployed. Instance type 353 indicates an instance type to be deployed. Fee 354 indicates a usage fee per unit time of the deployed VM.

[0033] 8 shows an example of capacity fee information 36. The capacity fee information 36 indicates the volume capacity and the usage fee per unit time for each public cloud, each site, and each volume type. The capacity fee information 36 is referenced to calculate the fee for the capacity to store the root volume of a VM and the data of SDS. The capacity fee information 36 includes a public cloud 361, a site 362, a volume type 363, and a fee 364.

[0034] Public cloud 361 indicates the public cloud in which the VM is deployed. Site 362 indicates the site in which the VM is deployed. Volume type 363 indicates the volume type of the volume that stores data. Fee 364 indicates the volume capacity and the usage fee per unit time.

[0035] 9 shows an example of DB information 37. The DB information 37 indicates DB requirements determined by the system user and the DB capacity at the time of data acquisition. The DB information 37 includes a DB 371, an RTO 372, a query target execution time 373, a steady-state query multiplicity 374, a maximum-state query multiplicity 375, a capacity 376, a CPU usage threshold 377, an operation rate threshold 378, and a NW usage rate threshold 379.

[0036] DB 371 indicates a DB. RTO 372 indicates the RTO of the DB. The RTO is the time it takes from the occurrence of a failure until a query can be processed within the query target execution time. Query target execution time 373 indicates a target value for the time it takes to execute a query. Normal state query multiplicity 374 indicates the number of queries executed simultaneously under normal conditions. Maximum state query multiplicity 375 indicates the maximum value of queries executed simultaneously when the load increases. Capacity 376 indicates the capacity of the DB at the time of data acquisition. CPU utilization threshold 377 indicates the threshold for the CPU utilization of the DB VM. Availability threshold 378 indicates the threshold for the availability of the DB VM. NW utilization threshold 379 indicates the threshold for the NW utilization of the DB VM.

[0037] 10 shows an example of the VM count information 38. The VM count information 38 shows the number of DB VMs and the number of SDS VMs at normal and maximum times for each DB and each instance type. The VM count information 38 includes a DB 381, a public cloud 382, ​​a DB VM instance type 383, a number of DB VMs at normal times 384, a number of DB VMs at maximum times 385, an SDS VM instance type 386, and a number of SDS VMs at maximum times 387.

[0038] DB 381 indicates a DB. Public cloud 382 indicates a public cloud on which a VM runs. DB VM instance type 383 indicates an instance type of a DB VM. DB steady state DB VM count 384 is the number of DB VMs required at steady state, and indicates the number of DB VMs that run steadily in an on-premise data centre. DB VM count at peak 385 is the number of DB VMs required at peak, and indicates the number of DB VMs that run steadily in an on-premise data centre plus the number of DB VMs that run in a public cloud during cloud bursting. SDS VM instance type 386 indicates an instance type of an SDS VM. SDS VM count at peak 387 is the number of SDS VMs required at peak, and indicates the number of SDS VMs that run in a public cloud during cloud bursting.

[0039] 11 shows an example of the DB performance information 39. The DB performance information 39 includes a DB 391, a number of arriving queries 392, a number of executed queries 393, a query execution time 394, a CPU usage rate 395, and a network usage rate 396.

[0040] DB 391 indicates a DB. Query arrival count 392 indicates the number of queries arriving at the DB per unit time. Query execution count 393 indicates the number of queries executed at the DB per unit time. Query execution time 394 indicates the average time taken to execute queries per unit time. CPU usage 395 indicates the average CPU usage of the DB VM, and NW usage 396 indicates the average NW usage of the DB VM.

[0041] 12 shows an example of secondary site preparation information 40. The secondary site preparation information 40 indicates the preparations required at the secondary site when multiple sites are used (for example, one of the sites when two sites are used) and the recovery process in the event of a site failure. The secondary site preparation information 40 includes items 501, time 502, and preparation pattern 503. The secondary site preparation information 40 is preparation information for using one site when cloud bursting to multiple sites owned by a public cloud.

[0042] The items 501 indicate items shown in the secondary site advance preparation information 40. The items 501 include a process 504, a recovery time 505, an SDS preparation state 506, a DB preparation state 507, and a preparation cost 508.

[0043] Process 504 indicates a process required for advance preparation. In item 501, SDS deploy indicates deploying SDS to a site. Data copy indicates copying data in a shared storage in an on-premise data center to an SDS in a site. The speed of data copy processing varies depending on the communication situation, so time 502, which will be described later, is calculated at the timing of performing cloud bursting. SDS stop indicates stopping the SDS VM and starting the SDS VM after a site failure occurs. This can prevent the SDS VM usage fee from being charged, but it takes time to start query execution after a site failure occurs. DB deploy indicates deploying a DB to a site. DB stop indicates stopping the DB VM and starting the DB VM after a site failure occurs. This can prevent the DB VM usage fee from being charged, but it takes time to start query execution after a site failure occurs.

[0044] Time 502 indicates the time required for processing step 504. Preparation pattern 503 indicates whether the processing shown in step 504 is performed in advance or after a site failure occurs. If the processing is performed after a site failure, the time required for the processing is indicated.

[0045] Recovery time 505 indicates the sum of the processing time performed after the occurrence of a site failure. SDS preparation status 506 indicates the state of the SDS after advance preparation. In advance preparation, the case where the SDS is deployed and the SDS VM is not stopped is referred to as "Started". In advance preparation, the case where the SDS is deployed and the SDS VM is stopped is referred to as "Stopped". In advance preparation, the case where the SDS is not deployed is referred to as "Not yet". DB preparation status 507 indicates the state of the DB after advance preparation. In advance preparation, the case where the DB is deployed and the DB VM is not stopped is referred to as "Started". In advance preparation, the case where the DB is deployed and the DB VM is stopped is referred to as "Stopped". In advance preparation, the case where the DB is not deployed is referred to as "Not yet". Preparation cost 508 indicates the monthly cost of the SDS VM and DB VM incurred due to advance preparation. This is the cost incurred when the VM is started and a volume is used to store data.

[0046] 13 shows an example of secondary site preparation cost information 41. The secondary site preparation cost information 41 indicates the cost required when making preparations for the secondary site. The secondary site preparation cost information 41 includes a preparation pattern 511, a recovery time 512, and a preparation cost 513.

[0047] Preparation pattern 511 indicates the advance preparation shown in preparation pattern 503. Recovery time 512 indicates the time required for recovery. Preparation cost 513 indicates the cost required for advance preparation. It can be seen from Fig. 13 that the preparation patterns are sorted in ascending order of recovery time and descending order of preparation cost.

[0048] 14 shows an example of the redundancy confirmation screen 42. The redundancy confirmation screen 42 is a screen for a system user to confirm redundancy. The redundancy confirmation screen 42 shows a DB 521, an RTO 522, an estimated recovery time 523, a preparation cost 524, a primary site 525, and a secondary site 526.

[0049] DB 521 indicates a DB. RTO 522 indicates the RTO of the DB input by a user of the system. Estimated recovery time 523 indicates the time required for recovery estimated using the secondary site advance preparation information 40. Preparation cost 524 was estimated using the secondary site advance preparation information 40. Primary site 525 indicates the site that runs the DB during cloud bursting. If the DB is run at multiple sites, multiple sites are displayed. Secondary site 526 indicates the site that runs the DB if a site failure occurs during cloud bursting.

[0050] Fig. 15 shows an example of a flow for determining the advance preparation contents based on the RTO. The deployment destination site determination function 17 executes this flow periodically or when cloud bursting.

[0051] In step 601 , the deployment destination site decision function 17 acquires the DB capacity from the master DB VM 12 and updates the capacity 376 of the DB information 37 .

[0052] In step 602, the deployment destination site decision function 17 acquires the bandwidth used for the connection line from the site, and updates the bandwidth used 344 in the connection line information .

[0053] In step 603, the deployment destination site decision function 17 acquires the instance type of the DB VM from the DB VM instance type 383 of the DB VM number information 38. The deployment destination site decision function 17 acquires the instance type of the SDS VM from the SDS VM instance type 386 of the DB VM number information 38. The deployment destination site decision function 17 acquires the SDS deployment time from the SDS deployment time 314 of the SDS VM information 31, and updates the time 502 of the secondary site advance preparation information 40. The deployment destination site decision function 17 acquires the SDS startup time from the SDS startup time 315 of the SDS VM information 31, and updates the time 502 of the secondary site advance preparation information 40. The deployment destination site decision function 17 acquires the DB deployment time from the DB deployment time 324 of the DB VM information 32, and updates the time 502 of the secondary site advance preparation information 40. The deployment destination site decision function 17 acquires the DB startup time from the DB startup time 325 of the DB VM information 32, and updates the time 502 of the secondary site advance preparation information 40. The deployment destination site decision function 17 updates the preparation pattern 503 based on the time 502 of the secondary site advance preparation information 40 , and updates the recovery time 505 .

[0054] In step 604, the deployment destination site determination function 17 calculates the usage fee based on the SDS preparation status 506 and DB preparation status 507 of the secondary site advance preparation information 40, the VM fee information 35, the capacity fee information 36, and the DB VM count information 38, and updates the preparation cost 508. The number of SDS VMs is the maximum SDS VM number 387 of the DB VM count information 38. If the SDS preparation status 506 is "running", the monthly SDS usage fee is calculated based on the VM fee information 35 and the capacity fee information 36. If the SDS preparation status 506 is "stopped", the monthly SDS usage fee is calculated based on the capacity fee information 36. If the SDS preparation status 506 is "not yet", the monthly SDS usage fee is 0. The number of DB VMs is the maximum DB VM number 385 of the DB VM count information 38. andThis is the difference in the number of DB VMs in a steady state 384. If DB preparation state 507 is “running”, the monthly fee is calculated based on VM fee information 35 and capacity fee information 36. If DB preparation state 507 is “stopped”, the monthly fee is calculated based on capacity fee information 36. If DB preparation state 507 is “not yet”, the preparation cost is 0.

[0055] In step 605, the deployment destination site decision function 17 creates secondary site advance cost information 41 based on the secondary site advance preparation information 40, and rearranges the columns so that recovery time 512 is in ascending order. Each column is compared, and any column in which recovery time 512 is longer than a predetermined time and preparation cost 513 is higher than a predetermined amount is deleted.

[0056] In step 606, the deployment destination site decision function 17 selects a preparation pattern in which the recovery time 512 of the secondary site advance cost information 41 is equal to or less than the RTO 372 of the DB information 37 as the cloud bursting configuration.

[0057] Fig. 16 shows an example of a flow for determining whether to perform cloud bursting. The deployment destination site determination function 17 executes this flow periodically, for example, every minute.

[0058] In step 611 , the deployment destination site determination function 17 acquires information from the master DB VM 12 , the worker DB VM 13 , and the worker DB VM 21 , and updates the DB operation information 39 .

[0059] In step 612, the deployment destination site decision function 17 calculates the operation rate of each DB based on the DB operation information 39. The calculation formula is as follows. Availability = number of queries arriving / number of queries executed

[0060] In decision 613, if the CPU utilization rate 395 is higher than the CPU utilization rate threshold 377 and the operation rate calculated in step 612 is higher than the operation rate threshold 378, the deployment destination site decision function 17 proceeds to step 615. If not, the deployment destination site decision function 17 proceeds to decision 614. Note that the decision may be made based only on the CPU utilization rate.

[0061] In the judgment 614, if the NW utilization rate 396 is higher than the NW utilization rate threshold 379, the deployment destination site decision function 17 proceeds to step 615. If not, the process ends.

[0062] In step 615, the deployment destination site determination function 17 instructs the deployment function 18 to start cloud bursting. The deployment function 18 performs deployment based on the preparation pattern determined in step 606 and the SDS preparation state 506 and the DB preparation state 507 of the secondary site advance preparation information 40.

[0063] In this way, according to this system, when cloud bursting, if the RTO is shorter than the system construction time of the bursting destination, it is deployed to multiple sites, otherwise it is deployed to one site. For example, if the RTO of the system is shorter than the construction time of the extension part of the public cloud, it is deployed to two or more sites, otherwise it is deployed to one site. The system construction time includes the time to copy data from the on-premise data center to the public cloud. In addition, the data copy time takes into account the data capacity and the communication bandwidth used. And when deploying to multiple sites, it is judged based on the RTO how much of the system components should be deployed and how much preparation should be done in advance, including startup and shutdown.

[0064] That is, in a redundancy determination system that uses a computer having a processor and a memory to extend a system on an on-premise data centre (e.g., on-premise data centre 2) to a public cloud (e.g., public cloud 3), the processor determines whether or not a site in the public cloud is to be extended if the recovery time objective (RTO) of the system is shorter than the construction time of the system calculated based on the operation status of the system. Multiple a first process of deploying the system to a site, and if a target recovery time of the system is not shorter than the construction time, deploying the system to a site among the sites of the public cloud; First and a second process of deploying the system on the site, allowing cloud bursting to meet RTOs and without unnecessary costs.

[0065] The public cloud has a software-defined storage (SDS) and a data base (DB), and the processor calculates the construction time of the system including each of the items of deploying the SDS, copying data from the on-premise data center to the public cloud, starting and stopping the SDS, deploying the DB, and starting and stopping the DB, as shown in item 501 of Fig. 12, for example, and determines whether to perform the first process or the second process. This makes it possible to perform cloud bursting in consideration of the preparation time required for each of these items for constructing a system.

[0066] Furthermore, the processor generates a preparation pattern combining the items based on the operation status of the system at the time of performing the first process or the second process, and calculates the construction time of the system for each of the generated preparation patterns. This makes it possible to calculate each item for each preparation pattern in consideration of the operation status of the system at the time of performing cloud bursting, and to calculate the preparation time for each preparation pattern.

[0067] The processor determines the operating status of the system based on the capacity of the DB and the amount of communication between the on-premise data center and the public cloud, thereby making it possible to calculate the preparation time for each of the preparation patterns, taking into account the database and the amount of communication in particular.

[0068] The processor sorts the system construction times calculated for each of the preparation patterns in order of cost and presents them to the user, thereby enabling the user to easily select a cost-effective pattern and perform cloud bursting. [Explanation of symbols]

[0069] 1 System 2 On-Premises Data Centers 3. Public Cloud 4 Connection Line 11 AP VM (Virtual Machine) 12 Master DB VMs 13 Worker DB VMs 14 Shared Storage 15 Data 16 Management Server 17 Deployment site determination function 18 Deployment Function

Claims

1. A redundancy determination system for extending a system on an on-premise data centre to a public cloud using a computer having a processor and a memory, comprising: The processor, a first process of deploying the system to a plurality of sites of the public cloud when a target recovery time of the system is shorter than a construction time of the system calculated based on an operation status of the system; a second process of deploying the system to one of the sites of the public cloud when the target recovery time of the system is not shorter than the construction time; A redundancy determination system comprising:

2. The public cloud has a software-defined storage (SDS) and a data base (DB), The processor, Calculating a construction time of the system including each of the items of deploying the SDS, copying data from the on-premise data center to the public cloud, starting and stopping the SDS, deploying the DB, and starting and stopping the DB, and determining whether to perform the first process or the second process; 2. The redundancy determination system according to claim 1 .

3. The processor, generating a preparation pattern combining the items based on an operating state of the system at the time when the first process or the second process is performed, and calculating a construction time of the system for each of the generated preparation patterns; 3. The redundancy determination system according to claim 2.

4. The processor, determining an operating status of the system based on a capacity of the DB and a communication volume between the on-premise data center and the public cloud; 4. The redundancy determination system according to claim 3.

5. The processor, sorting the system construction times calculated for each of the preparation patterns in order of cost and presenting the results to a user; 4. The redundancy determination system according to claim 3.

6. A redundancy determination method performed in a redundancy determination system that extends a system on an on-premise data centre to a public cloud using a computer having a processor and a memory, comprising: a first process of deploying the system to a plurality of sites of the public cloud when a target recovery time of the system is shorter than a construction time of the system calculated based on an operation status of the system; a second process of deploying the system to one of the sites of the public cloud when the target recovery time of the system is not shorter than the construction time; A redundancy determination method comprising the steps of:

7. The public cloud has a software-defined storage (SDS) and a data base (DB), Calculating a construction time of the system including each of the items of deploying the SDS, copying data from the on-premise data center to the public cloud, starting and stopping the SDS, deploying the DB, and starting and stopping the DB, and determining whether to perform the first process or the second process; 7. The method of claim 6, wherein the redundancy determination method is

8. generating a preparation pattern combining the items based on an operating state of the system at the time when the first process or the second process is performed, and calculating a construction time of the system for each of the generated preparation patterns; 8. The method of claim 7, wherein the redundancy determination method is

9. determining an operating status of the system based on a capacity of the DB and a communication volume between the on-premise data center and the public cloud; 9. The method of claim 8, wherein the redundancy determination method is

10. sorting the system construction times calculated for each of the preparation patterns in order of cost and presenting the results to a user; 9. The method of claim 8, wherein the redundancy determination method is

Images