orchestrator

Abstract

An orchestrator (80) instructs data migration to a server group (2B) when a domain controller (40A) of a server group (2A) fails, sets a short TTL for an authoritative DNS server (50A) of the server group (2A), stops the authoritative DNS server (50A) of the server group (2A) after the completion of the data migration, and at the same time sets the TTL of an authoritative DNS server (50B) of the server group (2B) to the TTL set in advance for the authoritative DNS server (50A) of the server group (2A).

Description

Orchestrator

[0001] The present invention relates to a technique for managing a group of servers that provide network services to terminal devices.

[0002] By connecting a Cloud Direct gateway (GW) point and a group of servers in a corporate data center with an access point name (APN), high-speed, low-latency connections are achieved. In this case, migration in a geographically distributed environment with different management domains is expected (see Non-Patent Document 1). In addition, a cloud controller is installed in the group of servers to centrally manage and operate multiple clouds that require communication service control.

[0003] Furthermore, the transport layers up to L3 in the connections between multiple server groups have been realized through research and development of middleware technology for communication functions that utilizes SONiC (see Non-Patent Document 2).

[0004] To provide practical communication services, in addition to increasing the speed of transmission and IP layer transfer technology, it is necessary to address higher layer technologies, such as DNS (Domain Name System).

[0005] Auto-healing is a function that can be used to provide more stable network services. Auto-healing is a method for quickly recovering from an error (physical failure) that occurs in a physical server (e.g., a server in one server group) by transferring that server's functions to another physical server (e.g., a server in another server group).

[0006] DNS effectively utilizes cache data to reduce load, but this effective utilization is the reason why DNS switching takes time. When a DNS server (DNS cache server) rewrites a domain's zone information (DNS information), it takes a certain period of time (generally about three days) for the rewritten DNS information to spread across the Internet and the settings to be reflected, i.e., the DNS penetration period. Until the DNS penetration period has passed, the old DNS information before the rewrite may be referenced. Because DNS information spreads gradually across the Internet, it is unclear whether the new or old DNS information will be referenced depending on the connection route. Therefore, when changing the server linked to a domain, it is necessary to use both the old and new servers for a while.

[0007] An A record, which is a type of DNS information, is a record that indicates the IP address (IPv4) of a host. In order to shorten the time it takes for an A record on a DNS authoritative server to be updated, the TTL (Time To Live) of the A record is shortened before the change is made (see Non-Patent Document 3).

[0008] The NS record, a type of DNS information, is a record that indicates the DNS server name for a domain. It is held by both the upper and lower DNS servers in a hierarchical structure and indicates the state of delegation of authority. Because such NS records are used in iterative searches, changes must be made not only to the lower DNS servers but also to the upper DNS servers.

[0009] National Institute of Informatics, “Network Function Virtualization and Its Utilization,” Academic Information Infrastructure Open Forum 2017, [online], [Retrieved February 1, 2024], Internet <URL: https: / / www.nii.ac.jp / csi / openforum2017 / track / pdf / 20170608PM_S_01_nfv.pdf>, “Why does DNS switching take so long?” Site Shokunin Staff Blog, [online], [Retrieved February 1, 2024], Internet <URL: https: / / www.site-shokunin.com / blog / other / 4412.html>, “Why is DNS penetration a problem? (4),” Geek Page, [online], [Retrieved February 1, 2024], Internet <URL: https: / / www.geekpage.jp / blog / ?id=2011-10-27 / 1&p=4> “Why is ‘DNS penetration’ a problem? (5),” Geek Page, [online], [Retrieved February 1, 2024], Internet <URL: https: / / www.geekpage.jp / blog / ?id=2011-10-27 / 1&p=5>

[0010] Multiple server groups operated by different companies have different domains and each has a domain controller. Furthermore, the DNS authoritative servers of the multiple server groups operated by different companies each manage different addresses. When autohealing is performed between such domain controllers, it is necessary to switch the DNS authoritative server from the autohealing source to the autohealing destination.

[0011] If the domain controller switchover by autohealing is completed but the DNS authoritative server switchover is not completed (for example, when the TTL of the NS record is set to a normal value), there is a problem that it takes a long time to respond to a name query from a terminal device that is trying to receive network services. Also, if a name query is sent to the DNS authoritative server on the failed server group, there is a problem that the DNS authoritative server cannot respond to the name query.

[0012] The present invention was created in consideration of the above circumstances, and its objective is to provide an orchestrator that can optimally provide network services to terminal devices when data migration is performed.

[0013] In order to solve the above problem, the orchestrator of the present invention is an orchestrator that manages multiple server groups each comprising an authoritative DNS server, a cache DNS server, a domain controller, and a web server, and when the domain controller of one of the server groups fails, it instructs data migration from the authoritative DNS server and the domain controller of one of the server groups to the authoritative DNS server and the domain controller of another of the server groups, and sets the TTL of the authoritative DNS server of one of the server groups for which data migration is instructed to be shorter than the TTL that was previously set, and after data migration is complete, it stops the authoritative DNS server of one of the server groups and sets the TTL of the authoritative DNS servers of the other of the server groups to the TTL that was previously set for the authoritative DNS server of one of the server groups.

[0014] According to the present invention, when data migration (for example, autohealing) is performed, network services can be suitably provided to terminal devices.

[0015] 1 is a block diagram schematically illustrating a service providing system according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a router database. FIG. 1 is a diagram illustrating an example of a load balancer database. FIG. 1 is a diagram illustrating an example of an A record database. FIG. 1 is a diagram illustrating an example of an NS record database. FIG. 1 is a diagram illustrating an example of a TTL information database. FIG. 2 is a sequence diagram illustrating a first operation example of the service providing system according to an embodiment of the present invention. FIG. 2 is a sequence diagram illustrating a first operation example of the service providing system according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating an operation example of an authoritative DNS server on a failed side in the first operation example. FIG. 3 is a sequence diagram illustrating a second operation example of the service providing system according to an embodiment of the present invention. FIG. 4 is a sequence diagram illustrating a fourth operation example of the service providing system according to an embodiment of the present invention. FIG. 4 is a sequence diagram illustrating a fourth operation example of the service providing system according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating an operation example of a router on a failed side in the fourth operation example. FIG. 6 is a flowchart illustrating an operation example of a router on a failed side in the fourth operation example. FIG. 7 is a flowchart illustrating an operation example of a load balancer that is a migration destination of autohealing in the fourth operation example. Fig. 10 is a sequence diagram for explaining a fifth operation example of the service providing system according to the embodiment of the present invention. Fig. 11 is a sequence diagram for explaining a fifth operation example of the service providing system according to the embodiment of the present invention. Fig. 12 is a flowchart for explaining an operation example of the router on the failed side in the fifth operation example. Fig. 13 is a flowchart for explaining an operation example of the load balancer to which auto-healing is migrated in the fifth operation example.

[0016] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] The present invention will be described in detail with reference to the accompanying drawings. In the following description, the same elements are designated by the same reference numerals, and redundant description will be omitted.

[0017] As shown in FIG. 1, a service providing system 1 according to an embodiment of the present invention is a system for providing a network service to a terminal device 10 .

[0018] <Terminal Device> The terminal device 10 is a client terminal (such as a personal computer or smartphone) owned and used by a user. The terminal device 10 includes an operation unit (such as a keyboard or touch panel) operated by the user and a notification unit (such as a monitor or speaker) that presents web services to the user. The terminal device 10 also includes a control unit that controls the operation unit and notification unit and is capable of communicating with other devices (such as a server group 2 described below) via a network (such as the Internet). The control unit is composed of a central processing unit (CPU), read-only memory (ROM), random access memory (RAM), input / output circuits, etc. The control unit acquires the operation result of the operation unit and outputs a signal corresponding to the operation result to the notification unit or transmits it to another device via the network. The control unit also receives a signal via the network and provides the user with a network service corresponding to the signal via the notification unit (such as image display or audio output).

[0019] <Service Providing System> The service providing system 1 includes a plurality of server groups 2 (2A, 2B) that provide network services to terminal devices 10, and an orchestrator 80 that manages the server groups 2. The plurality of server groups 2 are connected to each other so as to be able to communicate with each other via a network (such as the Internet) NW. The orchestrator 80 is connected to the plurality of server groups 2 so as to be able to communicate with each other.

[0020] In this embodiment, the orchestrator 80 performs auto-healing when the domain controller 40A of the server group 2A fails. Here, auto-healing refers to transferring the functions of the domain controller 40A and the authoritative DNS server 50A of the server group 2A to the domain controller 40B and the authoritative DNS server 50B of the server group 2B. After auto-healing is completed, the terminal device 10 becomes able to receive, from the web server 70B of the server group 2B, the network services that were provided by the web server 70A of the server group 2A before auto-healing.

[0021] <Server Group> Server group 2A is constructed in Company A's data center, and server group 2B is constructed in Company B's data center. Server group 2 is installed in a DMZ (DeMilitarized Zone). A DMZ is a network segment created between an external network (such as the Internet) and each company's internal network. The DMZ is isolated from both the external network and the internal network by a firewall or the like, thereby enhancing security within the DMZ.

[0022] The server group 2 includes a router 20, a load balancer 30, a domain controller 40, an authoritative DNS server 50, a cache DNS server 60, and a web server 70 as servers that can communicate with each other. The router 20, the load balancer 30, the domain controller 40, the authoritative DNS server 50, the cache DNS server 60, and the web server 70 may each be a mechanically different server device, or may be a virtual machine within one or more mechanical server devices. The mechanical server device is composed of a CPU, ROM, RAM, input / output circuits, etc.

[0023] <Router> The router 20 is a server for communicatively connecting devices (external devices) outside the server group 2 with devices (servers) within the server group 2. The router 20 includes a routing unit 21 and a fault flag unit 22 as functional units used during autohealing.

[0024] The routing unit 21 has a table 21a (see FIG. 2 ) in which destination IP addresses and forwarding destination IP addresses are stored in association with each other, and manages this table 21a. When the failure flag set by the failure flag unit 22 is ON, the routing unit 21 can convert the destination IP address included in the service request signal from the terminal device 10 into the corresponding forwarding destination IP address by referring to the table 21a. Furthermore, when the failure flag is ON, the routing unit 21 can generate a virtual link for transmitting the service request signal to the load balancer 30B of the server group 3B that is the data migration destination, and transmit (forward) the service request signal to the load balancer 30B via the virtual link. When the failure flag is OFF, the routing unit 21 forwards the service request signal as usual without using the table 21a.

[0025] The fault flag unit 22 sets a fault flag indicating whether or not the domain controller 40 is faulty.

[0026] <Load Balancer> The load balancer 30 aggregates communications (traffic) from devices (external devices) outside the server group 2, selects a server and / or communication network within the server group 2 that has spare resources, and forwards the aggregated communications to the selected destination. The load balancer 30 includes a NAT (Network Address Translation) unit 31 as a functional unit used during autohealing. The NAT unit 31 includes a table 31a (see FIG. 3 ) that stores destination IP addresses and forwarding destination IP addresses in association with each other, and manages the table 31a. By referring to the table 31a, the NAT unit 31 can convert the destination IP address included in a service request signal from the terminal device 10 into the corresponding forwarding destination IP address.

[0027] <Domain Controller> The domain controller 40 is a server that provides domain functions to the servers in the server group 2. The domain functions provided by the domain controller 40 include a directory database, authentication and authorization functions, and control based on group policies.

[0028] <Authoritative DNS Server> The authoritative DNS (Domain Name System) server 50 stores and manages domain names and IP addresses in association with each other, and converts domain names into IP addresses. Examples of the authoritative DNS server 50 include DNS servers 50A1 and 50B1 that provide the root zone at the lower level of the DNS hierarchical structure, and root DNS servers 50A2 and 50B2 that provide the root zone at the upper level (apex) of the DNS hierarchical structure (see FIG. 7). The authoritative DNS server 50 includes a memory unit 51, a transmission / reception unit 52, a time measurement unit 53, a management unit 54, and a syntax creation unit 55 as functional units for autohealing.

[0029] The storage unit 51 includes an A record database 51a and an NS record database 51b.

[0030] The A record database 51a stores a domain (URL, server name), an IP address, a TTL (Time To Live), and an update date and time in association with each other (see FIG. 4).

[0031] The NS record database 51b stores a domain (URL, server name), the server name of the authoritative DNS server 50 of the server group to which the server of the domain belongs, the TTL, and the update date and time in association with each other (see Figure 5).

[0032] Here, the TTL is the period for which the data corresponding to the TTL is stored in the cache DNS server 60 .

[0033] The transmitter / receiver 52 transmits and receives data to and from other devices. The time measurement unit 53 measures the TTL time. The management unit 54 manages (adds, deletes, updates, etc.) the data in the storage unit 51. The syntax creation unit 55 creates instruction signals for other devices.

[0034] <Cache DNS Server> The cache DNS server 60 is a server that receives a name resolution request from the terminal device 10 and returns the result to the terminal device 10. The cache DNS server 60 transmits (transfers) the name resolution request received from the terminal device 10 to the authoritative DNS server 50, and transmits the result (IP address) returned from the authoritative DNS server 50 to the terminal device 10. The cache DNS server 60 also associates the requested name (domain name) with the IP address corresponding to that name, and stores the associated name and IP address in the memory unit of the cache DNS server 60 for a predetermined period of time. If the cache DNS server 60 receives a request for the same name within that predetermined period of time, it references the data in its own memory and transmits the IP address to the terminal device 10.

[0035] <Web Server> The Web server 70 provides a network service to the terminal device 10 .

[0036] <Orchestrator> The orchestrator 80 is a server (command device) that manages a plurality of server groups 2 and commands each server in the server group 2. The orchestrator 80 may be a mechanical server device or a virtual machine in the mechanical server device. The orchestrator 80 includes, as functional units, a transmission / reception unit 81, a setting change unit 82, and a command unit 83.

[0037] The transmitting / receiving unit 81 transmits and receives data to and from other devices.

[0038] The setting change unit 82 changes the TTL setting of the server group 2. The setting change unit 82 includes a storage unit 82a, a management unit 82b, and a syntax creation unit 82c.

[0039] The storage unit 82a includes a TTL information database 82a1. The TTL information database 82a1 stores TTL pattern names (default, switchover) and the TTL for each pattern name in association with each other (see FIG. 6). The switchover TTL is set in the failed authoritative DNS server 50A during data migration, and is shorter than the default TTL that is preset in the authoritative DNS server 50A. Note that the TTL may be configured to be set and stored according to the type of authoritative DNS server 50 (DNS server 50A1, root DNS server 50A2, etc.) in addition to the pattern name.

[0040] The management unit 82b manages (adds, modifies, deletes, etc.) the data in the TTL information database 81a1 based on operations by an administrator on an operation unit (not shown), etc. The syntax creation unit 82c creates an instruction signal.

[0041] The command unit 83 commands the servers of the server group 2 to perform operations such as data migration. In this embodiment, when a failure is detected in the domain controller 40A of the server group 2A, the command unit 83 determines a migration destination for data from the server group 2A from among the other servers of the server group 2. The command unit 83 also instructs the domain controllers 40A and 40B to perform data migration (autohealing) from the domain controller 40A to the domain controller 40B of the server group 2B, which is the data migration destination. The command unit 83 also instructs the authoritative DNS servers 50A and 50B to perform data migration from the authoritative DNS server 50A of the server group 2A to the authoritative DNS server 50B of the server group 2B, which is the data migration destination. The command unit 83 may also instruct the web servers 70A and 70B to perform data migration from the web server 70A of the server group 2A to the web server 70B of the server group 2B, which is the data migration destination.

[0042] The command unit 83 changes (overwrites) the address (IP address) of the Web server 70A of the server group 2A stored in the cache DNS server 60A of the server group 2A for which data migration has been instructed to the address of the server group 2B for which data migration has been instructed (for example, the IP address of the Web server 70B).

[0043] The orchestrator 80 may be communicatively connected to the domain controller 40 of each server group 2 via a dedicated line or the like. The orchestrator 80 may also be communicatively connected to each server including the domain controller 40 of each server group 2 via a network NW.

[0044] <Example of Operation of Service Providing System> Next, an example of operation of the service providing system 1 according to the embodiment of the present invention will be described with reference to a sequence diagram.

[0045] First Operation Example First, a first operation example of the service providing system 1 according to an embodiment of the present invention will be described with reference to the sequence diagrams of Figures 7 and 8. In the first operation example, the TLL set in the authoritative DNS server 50A on the failed side is set shorter than normal. This allows the client terminal 10 to receive network services from the auto-healing migration destination web server 70B even before auto-healing is completed.

[0046] 7, when a failure occurs in the domain controller 40A of the server group 2A, the domain controller 40A detects the failure (step S121). Then, the domain controller 40A transmits a signal (failure notification signal) to notify the orchestrator 80 of the failure (step S122).

[0047] When the orchestrator 80 (command unit 83) receives the failure notification signal sent in step S122, it sends a signal instructing auto-healing (auto-healing instruction signal) to the domain controllers 40A and 40B (steps S151 and S152). Here, the auto-healing instruction signal sent to the domain controller 40A in step S151 is a signal instructing the domain controller 40A to prepare to stop a pod. Also, the auto-healing instruction signal sent to the domain controller 40B in step S152 is a signal instructing the domain controller 40B to create a pod. The order of steps S151 and S152 does not matter, either one may be performed first or either one may be performed later.

[0048] Next, the orchestrator 80 (setting change unit 82) sends a signal (TTL setting change instruction signal) instructing a TTL setting change to the DNS server 50A1 of the authoritative DNS server 50A and the root DNS server 50A2 (steps S161 and S162). The order of steps S161 and S162 does not matter. Next, the orchestrator 80 sends a migration destination notification signal to notify the DNS server 50A1 and the root DNS server 50A2 of the migration destination (DNS server 50B1) of the DNS record (steps S153 and S154).

[0049] The TTL setting change instruction signal includes a TTL at the time of switchover, which is set to be shorter than the default TTL (e.g., 36000 seconds) (e.g., 0 seconds).

[0050] Upon receiving the TTL setting change instruction signal transmitted in step S161, DNS server 50A1 sets the TTL to the minimum value based on the TTL setting change instruction signal (step S131). Subsequently, upon receiving the migration destination notification signal transmitted in step S153, DNS server 50A1 transmits DNS record information (A records, NS records, etc. stored in storage unit 51 of DNS server 50A1) to DNS server 50B1 based on the migration destination notification signal (step S132).

[0051] Similarly, upon receiving the TTL setting change instruction signal transmitted in step S162, root DNS server 50A2 sets the TTL to the minimum value based on the TTL setting change instruction signal (step S141). Subsequently, upon receiving the migration destination notification signal transmitted in step S154, root DNS server 50A2 transmits DNS record information (A records, NS records, etc. stored in storage unit 51 of root DNS server 50A2) to root DNS server 50B2 based on the migration destination notification signal (step S142).

[0052] Upon receiving the DNS record information transmitted in step S132, DNS server 50B1 stores the DNS record in its own storage unit 51.

[0053] Similarly, upon receiving the DNS record information transmitted in step S142, root DNS server 50B2 stores the DNS record in its own storage unit 51.

[0054] Here, within the TTL period set to the minimum value, the terminal device 10 transmits a name query signal to the DNS server 50A1 to inquire about the name (IP address) of the web server 70A in the server group 2A in order to receive network services (step S111). Because the TTL is set to zero, the name query signal is transmitted to the DNS server 50A1 via the cache DNS server 60A. Upon receiving the name query signal, the DNS server 50A1 transmits (forwards) the name query signal to the root DNS server 50A2 (step S133). The root DNS server 50A2 searches for a record (the IP address of the DNS server 50B1) (step S143). Based on the search results, the root DNS server 50A2 transmits a name query signal to the DNS server 50B1 to inquire about the URL of the web server 70B in the server group 2B (step S144).

[0055] Upon receiving the name query signal, DNS server 50B1 searches for the record (the IP address of Web server 70B) (step S181). Subsequently, DNS server 50B1 transmits a query response signal including the IP address of Web server 70B of server group 2B to terminal device 10 (step S182). This allows terminal device 10 to receive, from Web server 70B of server group 2B, the network services that were previously provided by Web server 70A of server group 2A before autohealing.

[0056] 8, on the other hand, upon receiving the auto-healing instruction signal, the domain controller 40B creates a pod based on the auto-healing instruction signal (step S171). Subsequently, the domain controller 40B transmits a pod creation completion notification signal to the orchestrator 80 to notify the orchestrator 80 that the pod creation is complete (step S172).

[0057] When the orchestrator 80 (command unit 83) receives the pod creation completion notification signal sent in step S172, it sends a pod activation instruction signal to the domain controller to instruct activation of the pod (step S155).

[0058] Upon receiving the pod activation instruction signal transmitted in step S155, the domain controller 40B activates the pod based on the pod activation instruction signal (step S173). Subsequently, the domain controller 40B transmits a pod activation completion notification signal to the orchestrator 80 to notify that the pod activation has been completed (step S174).

[0059] When the orchestrator 80 (command unit 83) receives the pod startup completion notification signal sent in step S174, it sends a data migration instruction signal to the domain controller 40A to instruct data migration (autohealing) (step S156).

[0060] When the domain controller 40A receives the data transfer instruction signal transmitted in step S156, it transmits data to the domain controller 40B based on the data transfer instruction signal (auto-healing) (step S123).

[0061] Note that data migration (autohealing) from domain controller 40A to domain controller 40B is not limited to the above-described automatic method (dynamic setting), and may be performed by an administrator operating an operation unit (not shown) to input data into domain controller 40B (static setting). In the case of static setting, steps S156 and S123 are omitted.

[0062] DNS server 50A1 expires the TTL after the setting change (step S134). Similarly, root DNS server 50A2 expires the TTL after the setting change (step S145). Steps S134 and S145 occur a predetermined time after steps S131 and S141, and the temporal relationship between steps S134 and S145 and other steps is not limited to that shown in the figure.

[0063] In this way, data migration from the authoritative DNS server 50A to the authoritative DNS server 50B is completed, data migration (autohealing) from the domain controller 40A to the domain controller 40B is completed, and the TTL set in the authoritative DNS server 50A expires. At least one of the authoritative DNS servers 50A and 50B may be configured to send a migration completion signal to the orchestrator 80 notifying that the data migration has been completed. At least one of the domain controllers 40A and 40B may be configured to send a migration completion notification to the orchestrator 80 notifying that the data migration has been completed. The management unit 82b of the setting change unit 82 may be configured to measure time and determine whether the TTL has expired when the TTL of the authoritative DNS server 50A is set to the switchover value. The orchestrator 80 may be configured to receive input indicating that the data migration has been completed by an administrator operating an operation unit (not shown), for example.

[0064] Next, if these conditions are met, the orchestrator 80 (setting change unit 82) sends a TTL setting change signal to the DNS server 50B1 and the root DNS server 50B2 to change the TTL setting (steps S163 and S164). Similarly, the orchestrator 80 (setting change unit 82) sends a TTL setting change signal to the DNS server 50A1 and the root DNS server 50A2 to change the TTL setting (steps S165 and S166). The TTL setting change instruction signal includes the default TTL.

[0065] Upon receiving the TTL setting change instruction signal transmitted in step S163, DNS server 50B1 sets the TTL to the default value based on the TTL setting change instruction signal (step S183). Similarly, upon receiving the TTL setting change instruction signal transmitted in step S164, root DNS server 50B2 sets the TTL to the default value based on the TTL setting change instruction signal (step S191).

[0066] When the DNS server 50A1 receives the TTL setting change instruction signal transmitted in step S165, it sets the TTL to the default value based on the TTL setting change instruction signal (step S135). Similarly, when the root DNS server 50A2 receives the TTL setting change instruction signal transmitted in step S166, it sets the TTL to the default value based on the TTL setting change instruction signal (step S146). By returning the TTLs of the DNS server 50A1 and the root DNS server 50A2 to their default values ​​before the pod is stopped, it is possible to prepare for the future restart of the DNS server 50A1 and the root DNS server 50A2.

[0067] It should be noted that steps S165, S166, S135, and S146 can be omitted.

[0068] After transmitting the TTL setting change signal, the orchestrator 80 (command unit 83) transmits a pod stop instruction signal to the domain controller 40A to instruct the domain controller 40A to stop the pod (step S157).

[0069] When the domain controller 40A receives the pod stop instruction signal transmitted in step S157, it stops the pod based on the pod stop instruction signal (step S124).

[0070] In addition, the first operation example may be configured to include steps S366, S334, S367, and S341 in the third operation example described below after data migration between authoritative DNS servers 50A and 50B is completed (for example, after execution of steps S135 and S146) (the same applies to the second operation example).

[0071] <<Operation Example of the Authoritative DNS Server on the Failed Side>> Next, the operation of the authoritative DNS server 50A in a first operation example will be described. As shown in FIG. 9 , when a failure occurs in the domain controller 40A (step S11), the authoritative DNS server 50A receives a TTL setting change instruction signal from the setting change unit 82 of the orchestrator 80 (step S12). Next, the authoritative DNS server 50A changes the TTL setting to the minimum value (switchover value) based on the TTL setting change instruction signal (step S13). Next, the authoritative DNS server 50A (time measurement unit 53) measures the time until the TTL expires based on the changed TTL setting (step S14). Next, the authoritative DNS server 50A transmits DNS record information to the authoritative DNS server 50B (step S15). Next, the authoritative DNS server 50A receives a TTL setting change instruction signal from the setting change unit 82 of the orchestrator 80 (step S16). Next, after the TTL has elapsed (step S17), the authoritative DNS server 50A changes the TTL setting to the default value based on the TTL setting change instruction signal (step S18).

[0072] <Second Operation Example> Next, a second operation example of the service providing system 1 according to an embodiment of the present invention will be described with reference to the sequence diagrams of Figures 10 and 11, focusing on the differences from the first operation example. Note that the steps included in the sequence diagram of Figure 10 have already been described in the first operation example, so their description will be omitted. In the second operation example, in the same case as the first operation example, the TTL of the auto-healing destination authoritative DNS server 50B is set to the same TTL as that previously set in the failed authoritative DNS server 50A. This allows the client terminal 10 to receive network services from the auto-healing destination web server 70B after auto-healing is completed.

[0073] In the second operation example, steps S211, S231, S241, S242, S271, S272, S291, S292, S212, S292, and S293 in FIG. 11 are executed instead of steps S111, S133, S143, S144, S181, and S182 in FIG.

[0074] 11 , after the pod of domain controller 40A is stopped, terminal device 10 transmits a name query signal to DNS server 50A1 to inquire about the URL of web server 70A in server group 2A in order to receive network services (step S211). Upon receiving the name query signal, DNS server 50A1 transmits (transfers) the name query signal to root DNS server 50A2 (step S231). Upon receiving the name query signal, root DNS server 50A2 searches for a record (the IP address of DNS server 60B1) (step S241). Based on the search results, root DNS server 50A2 transmits a name query signal to DNS server 50B1 to inquire about the URL of web server 70B in server group 2B (step S242).

[0075] When the DNS server 50B1 receives the name query signal, it searches for the record (the IP address of the Web server 70B) (step S281). Then, based on the search result, the DNS server 50B1 transmits a query response signal including the IP address of the Web server 70B of the server group 2B to the cache DNS server 60A (step S282).

[0076] When the cache DNS server 60A receives the inquiry response signal, it associates the IP address of the web server 70B included in the inquiry response signal with the domain of the web server 70A and stores the IP address in its own memory (record update, step S291). Also, when the cache DNS server 60A receives the inquiry response signal, it transmits the inquiry response signal to the terminal device 10 (step S292). Either step S291 or S292 may be performed first, or either may be performed later.

[0077] Also, after the IP address of the Web server 70B is stored in the cache DNS server 60A, the terminal device 10 sends a name query signal to the cache DNS server 60A to inquire about the URL of the Web server 70A of the server group 2A in order to receive network services (step S212).

[0078] Upon receiving the name query signal, cache DNS server 60A searches for the record (the IP address of Web server 70A) (step S293). Based on the search results, cache DNS server 60A then transmits a query response signal including the IP address of Web server 70B of server group 2B to terminal device 10 (step S294). This allows terminal device 10 to receive network services from Web server 70B.

[0079] The second operation example may include steps S165, S166, S135, and S146.

[0080] <Third Operation Example> Next, a third operation example of the service providing system 1 according to an embodiment of the present invention will be described with reference to the sequence diagrams of Figures 12 and 13. The third operation example can be combined with the first operation example or the second operation example. In the third operation example, the cache DNS server 60A on the failed side notifies the terminal device 10 of the IP address of the load balancer 30B to which autohealing is to be migrated, so that the terminal device 10 receives network services from the web server 70B to which autohealing is to be migrated.

[0081] 12, when a failure occurs in the domain controller 40A of the server group 2A, the domain controller 40A detects the failure (step S321). Subsequently, the domain controller 40A transmits a signal (failure notification signal) to notify the orchestrator 80 of the failure (step S322).

[0082] Upon receiving the failure notification signal transmitted in step S322, the orchestrator 80 generates an overwrite instruction signal including the address of the load balancer 30B (the IP address of the NAT) based on the failure notification signal, and transmits the generated overwrite instruction signal to the cache DNS server 60A (step S361). Note that, as a preliminary operation of step S361, the orchestrator 80 may obtain the IP address of the load balancer 30B by inquiring about the IP address of the load balancer 30B that is the auto-healing destination, or the configuration may be such that the IP address of the load balancer 30B is input by an administrator operating an operation unit (not shown).

[0083] Upon receiving the overwrite instruction signal sent in step S361, cache DNS server 60A overwrites the address of Web server 70A with the IP address of the NAT (step S331).

[0084] Furthermore, upon receiving the failure notification signal transmitted in step S322, the orchestrator 80 transmits a signal instructing auto-healing (auto-healing instruction signal) to the domain controllers 40A and 40B (steps S362 and S363). Here, the auto-healing instruction signal transmitted to the domain controller 40A in step S362 is a signal instructing the domain controller 40A to prepare for pod shutdown. Furthermore, the auto-healing instruction signal transmitted to the domain controller 40B in step S363 is a signal instructing the domain controller 40B to create a pod. The order of steps S362 and S363 does not matter, either one may be performed first or either one may be performed later.

[0085] Thereafter, as in the first and second operation examples, the domain controllers 40A and 40B execute autohealing (see steps S171, S172, S155, S173, S174, S156, S123, S157, S124, etc. in FIG. 8 ), and the authoritative DNS servers 50A and 50B execute data migration (see steps S153, S154, S132, S142, etc. in FIG. 7 ).

[0086] In order to receive a network service, the terminal device 10 transmits a name query signal to the cache DNS server 60A to inquire about the URL of the web server 70A in the server group 2A (step S311). Upon receiving the name query signal, the cache DNS server 60A transmits (replies) a query response signal including the NAT address to the terminal device 10 (step S332).

[0087] Upon receiving the NAT address, the terminal device 10 transmits (transfers) a service request signal including the IP address of the NAT as the destination to the load balancer 30B (step S312).

[0088] When the load balancer 30B receives the service request signal transmitted in step S312, it converts the destination of the service request signal from the NAT IP address to the address of the Web server 70B (step S371), and transmits (transfers) the converted service request signal to the Web server 70B (step S372). This allows the terminal device 10 to receive network services provided by the Web server 70B.

[0089] On the other hand, when the domain controller 40B completes the activation of the pod (step S381), it transmits a activation completion notification signal to the orchestrator 80 to notify the orchestrator 80 of the completion of the activation (step S382).

[0090] As shown in FIG. 13, upon receiving the startup completion notification signal sent in step S382, the orchestrator 80 sends an overwrite instruction signal to the cache DNS server 60A (step S364).

[0091] Upon receiving the overwrite instruction signal sent in step S364, cache DNS server 60A overwrites the NAT IP address with the address of Web server 70A (step S333).

[0092] The orchestrator 80 also transmits a stop instruction signal to the domain controller 40A, the cache DNS server 60A, and the authoritative DNS server 50A to instruct them to stop (steps S365, S366, S367).

[0093] When the domain controller 40A receives the stop instruction signal transmitted in step S365, it stops based on the stop instruction signal (step S322). Similarly, when the cache DNS server 60A receives the stop instruction signal transmitted in step S366, it stops based on the stop instruction signal (step S334). Similarly, when the authoritative DNS server 50A receives the stop instruction signal transmitted in step S367, it stops based on the stop instruction signal (step S341).

[0094] <Fourth Operation Example> Next, a fourth operation example of the service providing system 1 according to an embodiment of the present invention will be described with reference to the sequence diagrams of Figures 14 and 15, focusing on the differences from the third operation example. The fourth operation example can be combined with the first operation example or the second operation example. In the fourth operation example, the router 20A on the failed side notifies the terminal device 10 of the IP address of the load balancer 30B to which auto-healing is to be migrated, so that the terminal device 10 receives network services from the web server 70B to which auto-healing is to be migrated.

[0095] As shown in FIG. 14, after step S322, the orchestrator 80 transmits a failure flag change instruction signal to the router 20A to instruct it to change the failure flag (step S461).

[0096] When the router 20A receives the failure flag change instruction signal transmitted in step S461, it switches the failure flag from OFF to ON (step S451).

[0097] When the orchestrator 80 receives the failure notification signal sent in step S322, it creates an overwrite instruction signal including the address of the load balancer 30B (the NAT IP address) based on the failure notification signal, and sends the created overwrite instruction signal to the router 20A (step S361).

[0098] When the router 20A receives the overwrite instruction signal sent in step S361, it temporarily overwrites the address of the Web server 70A with the IP address of the NAT (step S331).

[0099] After step S332, the terminal device 10 transmits (transfers) a service request signal including the IP address of the Web server 70A as the destination to the router 20A (step S411).

[0100] Upon receiving the service request signal transmitted in step S411, the router 20A converts the destination from the IP address of the Web server 70A to the NAT IP address of the load balancer 30B using the table 21a (step S452). The router 20A then transmits the converted service request signal to the load balancer 30B (step S453). As a preliminary operation of step S452, the cache DNS server 60A may associate the NAT IP address of the load balancer 30B with the IP address of the Web server 70A, transmit the associated IP address to the router 20A, and store the associated IP address in the router 20A. As another example of the preliminary operation of step S452, the router 20A may be configured to receive the IP addresses of the load balancer 30B and the Web server 70A through an operation by an administrator via an operation unit (not shown), and associate and store the IP addresses in its own memory.

[0101] When the load balancer 30B receives the service request signal transmitted in step S453, it converts the destination of the service request signal from the NAT IP address of the load balancer 30B to the IP address of the Web server 70B using the table 31a (step S471). Then, the load balancer 30B transmits the converted service request signal to the Web server 70B (step S472). This allows the terminal device 10 to receive network services from the Web server 70B.

[0102] Furthermore, as shown in FIG. 15, upon receiving the startup completion notification signal transmitted in step S382, the orchestrator 80 transmits a failure flag change instruction signal to the router 20A (step S463).

[0103] When the router 20A receives the failure flag indication signal transmitted in step S463, it switches the failure flag from ON to OFF (step S453).

[0104] <<Operation Example of Router on Fault Side>> Next, the operation of the router 20A in a third operation example will be described. As shown in Fig. 16, when a fault occurs in the domain controller 40A (step S21), the router 20A receives a fault flag change instruction signal from the setting change unit 82 of the orchestrator 80 (step S22). If the fault flag is set to OFF (No in step S23), the router 20A changes the fault flag from OFF to ON (step S24).

[0105] <<Example of Operation of the Faulty Router (Continued)>> As shown in Figure 17, when the fault flag is set to ON, the router 20A receives a packet addressed to the web server 70A (step S31). The router 20A then searches the table 21a using the IP address (destination IP address) of the web server 70A included in the packet (step S32). If the IP address used in the search matches (Yes in step S33), the router 20A forwards the packet to the load balancer 30B using the NAT IP address (destination IP address) of the load balancer 30B corresponding to the IP address (step S34X). If the IP address used in the search does not match (No in step S33), the router 20A forwards the packet using the IP address (step S35).

[0106] <<Operation Example of Load Balancer Destination for Auto Healing Migration>> Next, the operation of the load balancer 30B in a third operation example will be described. As shown in FIG. 18, the load balancer 30B receives a packet (step S41X). Next, the load balancer 30B searches the table 31a using the IP address (destination IP address) included in the packet (step S42X). If the IP address used in the search matches (Yes in step S43), the load balancer 30B forwards the packet to the web server 70B using the IP address (destination IP address) of the web server 70B corresponding to the IP address (NAT IP address) (step S44). If the NAT IP address used in the search does not match (No in step S43), the load balancer 30B forwards the packet using the IP address specified in the packet (step S45).

[0107] <Fifth Operation Example> Next, a fifth operation example of the service providing system 1 according to an embodiment of the present invention will be described with reference to the sequence diagrams of Figures 19 and 20, focusing on the differences from the fourth operation example. The fifth operation example can be combined with the first operation example or the second operation example. Note that the steps included in the sequence diagram of Figure 20 have already been described in the fourth operation example, so their description will be omitted. In the fifth operation example, a virtual link is generated between the failed router 20A and the load balancer 30B that is the destination of auto-healing, so that the terminal device 10 receives network services from the web server 70B that is the destination of auto-healing.

[0108] 19, when the router 20A receives the service request signal transmitted in step S411, the failure flag is set to ON, so the router 20A transmits (transfers) the service request signal to the load balancer 30B via the virtual link (steps S551 and S552). As a preliminary operation of step S551, the cache DNS server 60A may associate the NAT IP address of the load balancer 30B with the IP address of the Web server 70A and transmit the associated IP address to the router 20A, causing the router 20A to store the associated IP address. As another example of the preliminary operation of step S551, the router 20A may be configured such that the administrator operates an operation unit (not shown) to input the IP address of the load balancer 30B and the IP address of the Web server 70A, and associates and stores the IP address in its own memory.

[0109] When the load balancer 30B receives the converted service request signal transmitted in step S552, it uses the table 31a to convert the destination of the service request signal from the IP address of the Web server 70A to the IP address of the Web server 70B (step S571). Note that, as a preliminary operation of step S571, the cache DNS server 60A may be configured to associate the NAT IP address of the load balancer 30B with the IP address of the Web server 70A, transmit the associated IP address to the load balancer 30B, and store the associated IP address in the load balancer 30B. As another example of the preliminary operation of step S571, the load balancer 30B may be configured to receive the IP address of the load balancer 30B and the IP address of the Web server 70A input by an administrator operating an operation unit (not shown), and associate and store the associated IP addresses in its own memory unit.

[0110] <<Operation Example of Router on Faulty Side>> Next, an operation example of the router 20A will be described, focusing on differences from the operation example of the router 20A in the fourth operation example.

[0111] As shown in FIG. 21, if the IP address used in the search matches (Yes in step S33), the router 20A transfers the packet to the load balancer 30B using the virtual link (step S34Y).

[0112] <<Operation Example of Load Balancer as Destination of Auto Healing Migration>> Next, an operation example of the load balancer 30B will be described, focusing on differences from the operation example of the load balancer in the fourth operation example.

[0113] 22, the load balancer 30B receives the packet (step S41Y). Subsequently, the load balancer 30B searches the table 31a using the IP address (destination IP address) included in the packet (step S42Y). If the IP address used in the search matches (Yes in step S43), the load balancer 30B forwards the packet to the web server 70B using the IP address (destination IP address) of the web server 70B that corresponds to the IP address (IP address of the web server 70A) (step S44).

[0114] <Effects> The orchestrator 80 according to an embodiment of the present invention is a device that manages a plurality of server groups 2, each of which includes an authoritative DNS server 50, a cache DNS server 60, a domain controller 40, and a Web server 70. When the domain controller 40A of one of the server groups 2A fails, the orchestrator 80 instructs data migration from the authoritative DNS server 50A and the domain controller 40A of one of the server groups 2A to the authoritative DNS server 50B and the domain controller 40B of another of the server groups 2B, and sets the TTL of the authoritative DNS server 50A of the one of the server groups 2A that has been instructed to migrate data to a shorter TTL than the TTL that was previously set, and after data migration is completed, stops the authoritative DNS server 50A of the one of the server groups 2A, and sets the TTL of the authoritative DNS server 50B of the other of the server groups 2B to the TTL that was previously set in the authoritative DNS server 50A of the one of the server groups 2A. Therefore, after the data migration (autohealing) is completed, the orchestrator 80 can quickly provide the terminal device 10 with network services from the Web server 70B that is the data migration destination (autohealing migration destination).

[0115] In addition, the orchestrator 80 according to an embodiment of the present invention is a device for managing a plurality of server groups 2 each comprising an authoritative DNS server 50, a cache DNS server 60, a domain controller 40, and a web server 70, and is characterized in that, when the domain controller 40A of one of the server groups 2A fails, the orchestrator 80 instructs data migration from the DNS server 50A and the domain controller 40A of one of the server groups 2A to the authoritative DNS server 50B and the domain controller 40B of another of the server groups 2B, and changes the address of the web server 70A of one of the server groups 2A stored in the cache DNS server 60A of the one of the server groups 2A for which data migration has been instructed to the address of the other of the server groups 2B for which data migration has been instructed. Therefore, after the authoritative DNS server 50A on the failed side stops, the orchestrator 80 can provide network services from the Web server 70B, the data migration destination (autohealing migration destination), to the terminal device 10 that requested the provision of network services from the Web server 70A on the failed side.

[0116] Although the embodiments of the present invention have been described above, the present invention is not limited to the above embodiments and can be modified as appropriate without departing from the spirit of the present invention. For example, the present invention can be embodied as a program that causes a computer to function as the orchestrator 80.

[0117] REFERENCE SIGNS LIST 1 Service providing system 2 (2A, 2B) Server group 10 Terminal device 40 (40A, 40B) Domain controller 50 (50A, 50B) Authoritative DNS server 60 (60A, 60B) Cache DNS server 70 (70A, 70B) Web server 80 Orchestrator

Claims

1. An orchestrator that manages multiple server groups each comprising an authoritative DNS server, a cache DNS server, a domain controller, and a web server, wherein, when the domain controller of one of the server groups fails, the orchestrator instructs data migration from the authoritative DNS server and domain controller of one of the server groups to the authoritative DNS server and domain controller of another of the server groups, and sets the TTL of the authoritative DNS server of the one of the server groups instructed to migrate data to a shorter TTL than the TTL that was previously set, and after data migration is complete, stops the authoritative DNS server of one of the server groups and sets the TTL of the authoritative DNS servers of the other of the server groups to the TTL that was previously set for the authoritative DNS server of one of the server groups.

2. The orchestrator described in claim 1, characterized in that it changes the address of the web server of one of the server groups stored in the cache DNS server of one of the server groups for which data migration has been instructed to the address of another of the server groups for which data migration has been instructed.

3. An orchestrator that manages multiple server groups each comprising an authoritative DNS server, a cache DNS server, a domain controller, and a web server, wherein, when the domain controller of one of the server groups fails, the orchestrator instructs data migration from the authoritative DNS server and domain controller of one of the server groups to the authoritative DNS server and domain controller of another of the server groups, and changes the address of the web server of one of the server groups stored in the cache DNS server of the one of the server groups for which data migration has been instructed to the address of the other of the server groups for which data migration has been instructed.

Images