Management server system, system, method of system, and storage medium

API hostnames and HTML hostnames are separately defined, and DNS switching for HTML is performed after a time lag from completion of DNS switching for APIs. APIs of old version are thereby prevented from being called from HTML screens of new version.

BACKGROUND OF THE INVENTION

Field of the Invention

The aspect of the embodiments relates to a management server system, a system, a method of a system, and a storage medium for managing a server including a web application service.

Description of the Related Art

Services provided by servers on the Internet have been becoming prevalent in recent years. Those services may be operated in a mode in which the services are used by users from all over the world. In such a mode of operation, it is difficult to stop a system for service maintenance during a specific period of time. Thus, there is a growing demand for a technique of doing maintenance work without stopping a service. Japanese Patent No. 4083049 and Japanese Patent Application Laid-Open No. 2004-295605 discuss conventional techniques for performing server maintenance or server switching without stopping a service, by controlling distribution of requests from clients to servers.

As web application technology advances, a conventional configuration in which a server generates and transmits a screen of Hypertext Markup Language (HTML) format to a client is shifting to techniques such as representational state transfer (REST)-ful model-view-controller (MVC) and client-side MVC. According to such techniques, a server executes processing via a REST interface (I/F) and returns only data to a client. A screen is generated on the client side.

SUMMARY OF THE INVENTION

According to an aspect of the embodiments, a management server system for communicating with one or more domain name system (DNS) servers, which return an Internet Protocol (IP) address corresponding to a hostname received with a request for name resolution, and a distribution server, which transmits a processing request for an HTML request and an application programming interface (API) request from a client to a system corresponding to the IP address returned from the DNS server(s), includes a construction unit configured to deploy a program for constructing a system environment in an information processing apparatus to construct a system, and a setting unit configured to set an IP address of the system for each of a hostname corresponding to an HTML request and a hostname corresponding to an API request, the hostnames being registered in the DNS server(s), wherein, after a new system is constructed by the construction unit, the setting unit starts to rewrite the current IP address set for the hostname corresponding to the API request to an IP address of the new system, and, in response to confirmation that rewriting of all of the DNS server(s) corresponding to the request for name resolution from the distribution server is completed, starts to rewrite the IP address set for the hostname corresponding to the HTML request to the IP address of the new system.

Further features of the aspect of the disclosure will become apparent from the following description of exemplary embodiments with reference to the attached drawings.

DESCRIPTION OF THE EMBODIMENTS

As one technique for switching systems without stopping a service there is a method called blue-green deployment. The blue-green deployment is a technique for constructing a new system while maintaining the currently-running system in operation, and then switching the connections of clients to the new system. The system switching using the blue-green deployment can switch the systems by changing IP address settings of hostnames registered in a DNS.

However, there occurs a program. If there is a plurality of DNS servers used for name resolution, a requestor of the name resolution may be able to obtain both the IP address of the old system and that of the new system because there is a time difference in the synchronization of the IP address settings between the DNS servers. Even if the IP address of the hostname registered in the DNS is switched, not all access is immediately made to the new system. Which of the systems, new or old, is accessed is therefore not clear.

The aspect of the embodiments is directed to providing a system that prevents the occurrence of an API call to the old system via an HTML screen provided by the new system.

According to the aspect of the embodiments, an API call to the old system via an HTML screen provided by the new system can be prevented.

A mode for carrying out the aspect of the embodiments will be described below with reference to the drawings.

In a first exemplary embodiment, applications are deployed in servers on the Internet. The applications provide various functions in cooperation with client terminals. The applications providing such functions will be referred to as services. The provision of a function to a client terminal will be referred as the provision of a service.

FIG. 1illustrates a system configuration according to the present exemplary embodiment. An upgrade system according to the exemplary embodiment includes a management server140, a DNS180, and a distribution server130. Application servers110and120provide services. InFIG. 1, the servers are illustrated to include one information processing apparatus each. It should be noted, however, that the number of information processing apparatuses constituting each server is not limited in particular. Client terminals150use the services.

In the present exemplary embodiment, a wide area network (WAN)100is constructed as a World Wide Web (WWW) system. Local area networks (LANs)101connect the components. A LAN102is similar to the LANs101, but is often configured as an internal network not accessible via the WAN100. Like the LANs101, the LAN102may be configured to be directly connected to and accessible from the WAN100.

The application servers110and120each include one or a plurality of information processing apparatuses. The application servers110and120are implemented on a network having a configuration as illustrated inFIG. 1. The application server110is one that is currently providing services. The application server120is the next system to provide the services. System switching between the application servers110and120does not necessarily be performed only for the purpose of upgrading.

The distribution server130typically includes a plurality of information processing apparatuses, but may be constituted by a single information processing apparatus. The distribution server130has a function of distributing access from the client terminals150to appropriate ones of the application servers110and120. The management server140typically includes a plurality of information processing apparatuses, but may be constituted by a single information processing apparatus. The management server140manages programs constituting the application servers110and120, and performs construction and switching processing of the application servers110and120.

The client terminals150are information processing apparatuses on which a web browser is installed. Examples of the client terminals150include a personal computer and a mobile terminal such as a smartphone. The DNS180is a system that resolves hostnames of the servers on the network and returns IP addresses of access destinations. An information processing apparatus or apparatuses of the DNS180may be referred to simply as a DNS, and may be referred to as a DNS server. In either case, the DNS180is a system having the function of returning an IP address to a requestor in response to a name resolution request. With the blue-green deployment, service switching is achieved by rewriting an IP address corresponding to a hostname registered in the DNS180from that of the application server110to that of the application server120. The distribution server130transmits requests from the client terminals150to an application server. More specifically, the distribution server130transmits data corresponding to the requests from the client terminal150to either one of the application servers110and120that is name-resolved by the DNS180. This means that the distribution server130obtains the IP address of the application server corresponding to a set transfer destination hostname from the DNS180, and is connected to either one of the application servers110and120in operation.

The above is the description of the apparatuses included in the present upgrade system. As describe above, the servers may be configured to include one or a plurality of information processing apparatuses each. As employed herein, the servers may therefore be referred to as server systems, so that both the configurations are covered. For example, if the management server140is referred to as a management server system, the management server140is intended to include either a single information processing apparatus or a server group including a plurality of information processing apparatus.

FIG. 2illustrates a typical hardware configuration of the information processing apparatuses including the application servers110and120, the distribution server130, the management server140, the client terminals150, and the DNS180. A central processing unit (CPU)231executes programs that are stored in a program read-only memory (ROM) of a ROM233or loaded from an external memory241, such as a hard disk (HD), into a random access memory (RAM)232. Examples of the programs include an operating system (OS) running on a computer, and applications. The CPU231also controls blocks connected to a system bus234. Processing of sequences to be described below is implemented by executing the OS. The RAM232functions as a main memory and a work area of the CPU231. An operation unit I/F235controls input from an operation unit239. A cathode-ray tube (CRT) controller (CRTC)236controls display of a CRT display240. A disk controller (DKC)237controls data access to the external memory241, such as an HD, which stores various types of data. A network controller (NC)238performs communication control processing with server computers and other devices connected via the WAN100and/or the LAN(s)101and/or102.

Throughout the following description, hardware agents that execute software are the CPUs231, and software agents are application programs installed on the external memories241, unless otherwise specified. The application programs are installed and deployed in the information processing apparatuses, and the CPUs231execute the deployed application programs to implement a system environment having a software configuration illustrated inFIG. 3.

FIG. 3is a diagram illustrating the respective software configurations of the application servers110and120, the distribution server130, the management server140, the client terminals150, and the DNS180.

The application servers110and120include an application service319. The application service319includes a web server module310and an API module311. The web server module310typically uses Jetty or Apache Tomcat to distribute HTML data and JavaScript (registered trademark) and/or provide an execution environment for the API module311. The application servers110and120execute the web server module310to implement HTTP-related processing. Examples include the generation of a display screen in an HTML format and the provision of the generated display screen to the client terminals150. The application servers110and120further execute the API module311to implement API processing. Both the web server module310and the API module311perform various types of processing in response to reception of a processing request for a request from a client.

The distribution server130includes a distribution service330. The distribution service330includes a distribution module331and distribution settings332. The distribution module331determines access from the client terminals150to the application server110or120according to the distribution settings332, based on Universal Resource Locators (URLs) that the client terminals150use in accessing the distribution server130. Details of the distribution settings332will be described below.

The management server140includes a management service349. The management service349includes a program management module340, a build module341, and a deployment module342. The program management module340manages programs for constructing the system environment of the application servers110and120. The build module341builds the programs managed by the program management module340into executable modules. The deployment module342deploys the executable modules generated by the build module341to the information processing apparatuses and constructs the system configuration of the application servers110and120to perform upgrade processing of the application service319.

The DNS180includes a DNS service380. The DNS service380responds to a request for name resolution with an IP address based on IP address settings381. Details of the IP address settings381will be described below. The client terminals150include a web browser350for accessing the application servers110and120.

FIG. 4is a diagram schematically illustrating communication paths for a client terminal150to access the application server110according to the present exemplary embodiment. As an exemplary embodiment, the application server110includes application servers401,402, and403that provide respective different services. InFIG. 4, behavior of the distribution server (distribution server system)130will be described.

Two types of hostnames “app1.local” and “appapi1.local” are assigned to the application server401. Similarly, the application server402has hostnames “app2.local” and “appapi2.local”. The application server403has hostnames “app3.local” and “appapi3.local”. The reason why two types of hostnames are assigned is to separate HTML requests from AP requests. Details of such processing will be described below. The distribution server130has a hostname “www.example.com”.

The user inputs the hostname assigned to the distribution server130and an access path into the web browser350of a client terminal150. An example of the URL is “https://www.example.com/app1/login”. The web browser350of the client terminal150issues a request to the distribution server130.

The distribution server130receiving the request refers to the distribution settings332and determines the server to distribute the request to (distribution destination). A specific example of the distribution settings332will be described with reference to Table 1. In the following settings, access to paths starting with “/app1” is set to be transferred to an “https://app1.local” server, and is thus transferred to the application server401. Access to paths starting with “appapi1” is set to be transferred to an “https://appapi1.local” server, and is thus also transferred to the application server401.

FIG. 5is a sequence diagram illustrating a flow of processing in which the web browser350of a client terminal150according to the present exemplary embodiment obtains a screen from the application server110and executes an application.

In step S501, the web browser350of the client terminal150issues an HTML request. In step S502, the distribution server130receiving the HTML request determines the application server110to be the distribution destination based on the requested URL and the distribution settings332. If the client terminal150accesses the distribution server130with a URL including a path starting with “/app1”, the application server110of “https://app1.local” is determined to be the distribution destination. In step S503, to issue a request to “https://app1.local”, the distribution server130transmits a request for name resolution to the DNS180. The DNS180manages hostnames and IP addresses as illustrated in Table 2. In step S504, the DNS180returns an IP address based on such setting information. If the hostname is “app1.local”, the DNS180returns “192.168.0.1”. The method for specifying a hostname is not limited to that of the present exemplary embodiment. Part of the hostname included in the URL may be transmitted to the DNS180. A hostname does not necessarily include a domain name.

In step S505, the distribution server130obtaining the IP address issues a processing request for the HTML request to the server having the IP address. In step S506, the distribution server130obtains HTML data. In step S507, the distribution server130returns the obtained HTML data to the web browser350. In displaying the returned HTML data, in step S511, the web browser350calls an API by JavaScript (registered trademark) written in the HTML data. The web browser350makes the API call to a URL different from that of the screen, such as “https://www.example.com/appapi1/v1/function1”. In step S512, the distribution server130receiving the API call that is an API request determines the distribution destination to be the application server110of “http://appapi1.local” as with the HTML request. In step S513, to transmit a processing request for the API request to “https://appapi1.local”, the distribution server130makes a request for name resolution to the DNS180. In the example of Table 2, “app1.local” and “appapi1.local” correspond to the same IP address. In step S514, the DNS180thus returns the same value as in step S504. Note that the setting values can be changed to make the server to be accessed for the HTML request different from that for the API call. In a series of processes of steps S515to S517, the distribution server130returns a processing result of the API to the web browser350. In step S520, the web browser350displays a screen based on the processing result of the API of step S517.

Next, a method by which the deployment module342of the management server140switches from the application server110to the application server120in the upgrade system of the present exemplary embodiment will be described with reference toFIGS. 6, 7A, 7B, 7C, 7D, and 7E.FIGS. 6, 7A, 7B, 7C, 7D, and 7Eillustrate a method for upgrading the application service319of the application server110to a new version of the application service319deployed in the application server120.FIG. 6illustrates a flow of the upgrade processing performed by the deployment module342.FIGS. 7A, 7B, 7C, 7D, and 7Eeach illustrate the system configurations during the upgrade processing.

When the upgrade processing is started by the management server140, the deployment module342performs the series of processes illustrated inFIG. 6. In step S601, to construct an application server701illustrated inFIGS. 7A, 7B, 7C, 7D, and 7E, the deployment module342initially configures an information processing apparatus or apparatuses. The blue-green deployment is usually implemented by configuring virtual information processing apparatuses. Virtual information processing apparatuses are a technique for generating a plurality of virtual information processing apparatuses on the hardware of an information processing apparatus. The generation and deletion of the virtual information processing apparatuses can be controlled by a program. For example, as many virtual information apparatuses as needed for deployment can be generated and modules for constituting the application service319can be deployed on the virtual information processing apparatuses to construct the application server701. Virtual information processing apparatuses that are no longer needed can be immediately deleted. This enables quick and easy implementation of the blue-green deployment. The aspect of the embodiments is not limited to virtual information processing apparatuses, and the application server701may be constituted by a physical information processing apparatus or apparatuses. In such a case, the processing of step S601is not performed, but the information processing apparatus(es) intended for the application server701is/are to be constructed in advance. Transition processing is then performed on such an information processing apparatus(es).

In step S602, the deployment module342performs module deployment. The deployment module342deploys a web server module310and an API module311on the information processing apparatuses generated in step S601. If upgrade is intended, a new HTML screen or screens is/are added to the web server module310. A new API or APIs is/are added to the API module311. The new HTML screen(s) can call the new API(s). The construction of the application server701illustrated inFIG. 7Ais thus completed. At this stage, the upgraded application server701is simply added to the upgrade system. The distribution server130does not transmit any processing request to the application server701.

In the present exemplary embodiment, the DNS180includes two DNSs, a primary DNS702and a secondary DNS703. The DNS180typically includes a plurality of DNSs, not a single DNS, for reasons such as availability and performance. The primary DNS702is a main DNS. The secondary DNS703is a sub DNS which is synchronized to the settings of the primary DNS702. For name resolution, the distribution server130may use either of the primary and secondary DNSs702and703to resolve names. At this stage, the IP address settings381of the primary DNS702include “192.168.0.1”, the IP address of the application server401, both as an HTML host setting and an API host setting. Since the synchronization between the primary DNS702and the secondary DNS703is completed, the IP address settings381of the secondary DNS702also include “192.168.0.1” for both. At this stage, like before the upgrading, the distribution server130transmits processing requests for requests to the application server401through paths711and712.

In step S603, the deployment module342performs DNS switching processing for API hostnames. More specifically, the deployment module342rewrites the current IP address set for the hostname “appapi1.local” corresponding to API requests in the primary DNS702to the value of the IP address of the application server701, “192.168.0.2”.FIG. 7Bis a block diagram illustrating a state in which the processing up to step S603is completed. In obtaining HTML data, the distribution server130transmits a processing request for the request to the application server401through the path711or712. In calling an API, if the primary DNS702is used to perform name resolution in step S513, the distribution server130transmits a processing request for the request to the application server701through a path713or714. If the secondary DNS703is used to perform name resolution in step S513, the distribution server130transmits the processing request for the request to the application server401through the path711or712. At this stage, an API call is transmitted to either one of the application servers401and701. Which API is called varies request by request.

Since the application server701includes the same APIs as those of the application server401, API calls specified in the HTML data provided by the application server401can be processed without problem. The reason is that as far as the switching of the HTML hosts is concerned, the primary DNS702and the secondary DNS703both refer to the IP address of the blue application server401. The display screen displayed on the client terminal150is one not supporting the new APIs. The APIs added to only the application server701are not used because the new HTML data added to the application server701is not provided to the client terminal150.

In step S604, the deployment module342checks whether the primary and secondary DNSs702and703are synchronized for API hostnames. More specifically, the deployment module342performs the name resolution of “appapi1.local” with the primary DNS702and the secondary DNS703, and determines whether the value “192.168.0.2” set in step S604is obtained from both the primary and secondary DNSs702and703. If either of the obtained values is “192.168.0.1” which is the IP address of the application server401(NO in step S604), step S604is repeated. If the obtained values are “192.168.0.2” which is the IP address of the application server701(YES in step S604), the processing proceeds to step S605. If the DNS180includes three or more DNSs, the deployment module342checks the IP addresses in all of the DNSs except the one in which the IP address is rewritten.FIG. 7Cis a block diagram in the stage after the processing of step S604and before a start of the processing of step S605. The IP address settings381of the secondary DNS703are synchronized with the IP address settings381of the primary DNS702. In obtaining HTML data, the distribution server130transfers requests to the application server401through the paths711and712. In calling APIs, the distribution server130transmits all requests to the application server701through the paths713and714.

In step S605, the deployment module342performs DNS switching processing for HTML hostnames. More specifically, the deployment module342rewrites the IP address for the hostname “app1.local” corresponding to HTML requests in the primary DNS702to the value of the IP address of the application server701, “192.168.0.2”.FIG. 7Dis a block diagram illustrating a state in which the processing up to step S605is completed. In obtaining HTML data, if the primary DNS702is used to perform name resolution in step S503, the distribution server130transfers the request to the application server701through the path713or714. If the secondary DNS703is used to perform name resolution in step S503, the distribution server130transfers the request to the application server401through the path711or712. At this stage, which of the application servers401and701a request is transmitted to in obtaining HTML data varies request by request. Since all API calls are transferred to the application server701, API calls specified in the new HTML data obtained from the application server701can be processed without problem.

The processing of the deployment module342is thus completed. After a lapse of a certain time, the IP address settings381of the secondary DNS703are synchronized with those of the primary DNS702, and the IP address for the HTML hostname is set to “192.168.0.2”.FIG. 7Eillustrates the final configuration. At this stage, the distribution server130transfers all requests to the application server701through the paths713and714.

The upgrade processing of the application service319is thus completed. API hostnames and HTML hostnames are separately defined, and the DNS switching for the API hostnames is completed before the DNS switching for the HTML hostnames is performed with a time lag. This can prevent the APIs of the old system from being used from HTML screens of the new system. As an example of the effect, the following situation can be avoided. Suppose that a screen in HTML format provided by the upgraded new system is displayed on a client terminal150. An API of the old system yet to be upgraded is called from the screen. In other words, the request for the acquisition of the screen is distributed to the new system by the DNS name resolution, and the request for the use of the API via the screen is distributed to the old system by the DNS name resolution. In such a case, the old system does not include new APIs for new functions provided by the new system, and the request from the client terminal150fails to be properly processed, and a desired result fails to be returned to the user.

In the first exemplary embodiment, the distribution server130is described to perform steps S503and S515for the name resolution processing of a hostname by the DNS180each time. In such a case, high load is incurred because a lot of requests for name resolution processing are transmitted to the DNS180. There may be also a situation that performing name resolution each time reduces the throughput of the entire system accordingly. The distribution server130then may be set to store the IP addresses obtained in steps S504and S514for a certain period of time and, if accessed with the same hostnames, reuse the previously-obtained IP addresses without performing the processing of step S503or S513.

In such a case, there is a period in which the distribution server130does not transmit a request for name resolution to the DNS180and performs name resolution by using the previously-obtained IP addresses although the DNS synchronization for API hostnames is completed in step S604. This can cause a situation in which the distribution server130does not immediately switch the IP address of the access destination to that of the new system, while the DNS180has been switched to the new system about display screens. As a result, one distribution server130can distribute requests for display screens to the new system according to the name resolution by the DNS180while another distribution server130distributes requests for APIs to the old system by using the cached IP address of the old system. The reason is that the group of servers constituting the distribution server130store IP addresses at respective different timings, and there is a time lag until the new setting values are reflected on all of the distribution servers130. There is thus a situation that the use of the APIs of the old system from an HTML screen of the new system is unable to be prevented. The second exemplary embodiment is similar to the first exemplary embodiment unless otherwise described below.

FIG. 8is a flowchart illustrating upgrade processing performed by the deployment module342according to the present exemplary embodiment. Steps S601to S605are similar to those of the processing described with reference toFIG. 6. In step S801, the deployment module342performs wait processing for a predetermined wait time. For example, if the cache time for the DNS name resolution of the distribution server130is set to 60 seconds, then in step S801, the deployment module342waits idly for 60 second or more. In the present exemplary embodiment, the wait processing is assumed to be performed for a certain time in addition to the cache time of 60 seconds. This ensures that the caches of the distribution servers130are updated. While the management server140is waiting, the caches for DNS name resolution in all of the distribution servers130expire. With the caches expired, the distribution servers130issue a request for name resolution in step S513, whereby the IP address of the application server701is obtained. The wait time may be set by the user in advance or by the management server140communicating with the distribution servers130to check the setting of the cache time. However, this is not restrictive. One feature of an exemplary embodiment of the disclosure is to wait until the caches in all of the distribution servers130of the upgrade system expire and the distribution servers130become ready to issue a request for name resolution to the DNS180.

As described above, a predetermined wait time can be provided to prevent the APIs of the old system from being used from an HTML screen of the new system even if the distribution servers130include caches for name resolution.

The third exemplary embodiment is similar to the first exemplary embodiment unless otherwise described below.FIG. 9is a flowchart illustrating upgrade processing performed by the deployment module342according to the present exemplary embodiment. Steps S601to S605are similar to those of the processing described with reference toFIG. 6. In step S901, the deployment module342performs access log analysis processing. The application server401typically outputs a log of all of HTML requests and API requests from the client terminals150, about which URL path is accessed when. The deployment module342analyzes such a log and confirms, for example, that HTML screens starting with a path “/app1*” have been accessed but no API call stating with a path “/appapi1*” has been made for a certain period of time. If the log includes no such API call made by an API request for a certain period of time, the distribution servers130are confirmed to be transmitting processing requests for API requests to the application server701.

As described above, the access log can be analyzed to prevent the APIs of the old system from being used from an HTML screen of the new system although the distribution servers130include caches for name resolution.

Other Embodiments

This application claims the benefit of Japanese Patent Application No. 2016-020050, filed Feb. 4, 2016, which is hereby incorporated by reference herein in its entirety.