WO2020189002A1 - サーバシステムおよびプロセスの冗長化方法 - Google Patents

サーバシステムおよびプロセスの冗長化方法 Download PDF

Info

Publication number
WO2020189002A1
WO2020189002A1 PCT/JP2020/002323 JP2020002323W WO2020189002A1 WO 2020189002 A1 WO2020189002 A1 WO 2020189002A1 JP 2020002323 W JP2020002323 W JP 2020002323W WO 2020189002 A1 WO2020189002 A1 WO 2020189002A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
mode
call control
processes
operating
Prior art date
Application number
PCT/JP2020/002323
Other languages
English (en)
French (fr)
Inventor
中野　晃
克明 宮越
Original Assignee
アイコム株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アイコム株式会社 filed Critical アイコム株式会社
Priority to CN202080018456.4A priority Critical patent/CN113557695B/zh
Priority to US17/438,450 priority patent/US20220166806A1/en
Priority to EP20774807.0A priority patent/EP3941001A4/en
Publication of WO2020189002A1 publication Critical patent/WO2020189002A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating

Definitions

  • the present invention relates to server system redundancy.
  • a server system is made redundant by installing an active server and a standby server and synchronizing between the active server and the standby server.
  • communication with the terminal device is performed by, for example, a virtual IP using a protocol such as VRRP (see Patent Document 1).
  • the operating server sends an advertisement to the standby server at regular intervals in order to notify that it is operating normally.
  • the opposite direction that is, the advertisement from the standby server to the active server is not transmitted, so that the active server cannot know the status of other servers in the system.
  • An object of the present invention is to make a server redundant for each process so that a process can easily know the operating status of another process when communicating between processes.
  • the present invention includes a first server and a second server installed on a communication network.
  • the first server executes a plurality of processes
  • the second server executes at least a part of the plurality of processes executed by the first server in parallel.
  • one process operates in the operating mode that actually provides the service (operating process)
  • the other process is the process in the operating mode.
  • standby mode which is the operating mode instead (standby process).
  • the active process periodically sends an operation notification, which is a message notifying that it is operating normally, to the standby process.
  • the standby process continues the standby mode while periodically receiving the operation notification from the operating process, but when it stops receiving the operation notification from the operating process, it switches its operation mode from the standby mode to the operating mode. Start providing services for this process.
  • processes are executed in parallel on the first server and the second server, one is a running process and the other is a standby process.
  • some processes go down due to a failure, instead of switching the entire server, it switches in units of the process in which the failure occurred. This simplifies the redundant configuration switching process, and even if some processes are down on both the first and second servers, the system is as long as the processes are running normally on the other server. It is more robust because it can operate as a whole.
  • the first network and the second network which are networks of different mobile phone carriers, may be used
  • the first server may be provided on the first network
  • the second server may be provided on the second network.
  • the first server and the second server are connected by a VPN or the like via a dedicated line.
  • a management server equipped with a management table for storing the operating status of each process may be further provided on the communication network.
  • Each process executed on the first and second servers periodically sends an operation notification to the management server. Further, when the operation mode of the process is switched from the standby mode to the operation mode, the process sends a mode switching notification to the management server.
  • the management server stores the operation status of each process acquired by the operation notification and the mode switching notification in the management table.
  • the process can know the operating status of other processes without sending a notification to itself, and it operates on a process-by-process basis. Even if the standby (main / sub) is switched, the interprocess communication can be maintained following it.
  • the management server is inquired about the operating status of each process and acquired.
  • the process running in the running mode is determined based on the operating status of each process, and this running second process is interprocessed. Use as a communication partner for communication.
  • the first network and the second network which are networks of different mobile phone carriers, are used, the first server and the first management server are provided on the first network, and the second server and the second management server are provided. It may be provided on the second network.
  • the first server system (first server, first management server) and the first server system (second server, second management server) are connected by a VPN or the like by a dedicated line.
  • Each process executed on the first and second servers sends an operation notification and a mode switching notification to both the first management server and the second management server. This makes it possible to make the management server redundant.
  • a process may inquire about the operating status of each process from the management server on the same network as itself.
  • the process executed by the first server and the second server may be a call control process that relays voice signals transmitted from a plurality of communication terminals.
  • the communication terminal in which the SIM of the first network is set accesses the server via the first network.
  • the communication terminal in which the SIM of the second network is set accesses the server via the second network.
  • the VPN is used to connect the servers.
  • a redundant configuration can be constructed for each process, facilitating server (process) switching and achieving higher robustness. be able to.
  • FIG. 1 is a configuration diagram of a voice communication system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram of a server of a voice communication system.
  • FIG. 3 is a block diagram of a communication terminal.
  • FIG. 4 is a diagram showing partitions of a call control server and a provisioning server, and a process (virtual server) executed in each partition.
  • FIG. 5 is a diagram showing a connection mode of each process and a communication terminal when all the processes are operating normally.
  • FIG. 6A is a diagram showing a connection mode of each process and a communication terminal when each process is operating normally.
  • FIG. 6B is a diagram showing a connection mode of each process and a communication terminal when some processes are down.
  • FIG. 1 is a configuration diagram of a voice communication system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram of a server of a voice communication system.
  • FIG. 3 is a block diagram of a communication terminal.
  • FIG. 6C is a diagram showing a connection mode of each process and a communication terminal when some processes are down.
  • FIG. 7A is a diagram showing a status table provided in the main process.
  • FIG. 7B is a diagram showing a status table provided in the subprocess.
  • FIG. 8A is a flowchart showing the operation of the call control server.
  • FIG. 8B is a flowchart showing the operation of the call control server.
  • FIG. 8C is a flowchart showing the operation of the call control server.
  • FIG. 8D is a flowchart showing the operation of the call control server.
  • FIG. 9 is a diagram showing a management table 31 provided in the management server.
  • FIG. 10A is a flowchart showing the operation of the management server.
  • FIG. 10A is a flowchart showing the operation of the management server.
  • FIG. 10B is a flowchart showing the operation of the management server.
  • FIG. 10C is a flowchart showing the operation of the management server.
  • FIG. 10D is a flowchart showing the operation of the management server.
  • FIG. 10E is a flowchart showing the operation of the management server.
  • FIG. 11A is a diagram showing the stored contents of the management table when some processes go down.
  • FIG. 11B is a diagram showing the stored contents of the management table when some processes go down.
  • FIG. 12 is a diagram showing an example of provisioning data set in the communication terminal.
  • FIG. 13A is a flowchart showing the operation of the communication terminal.
  • FIG. 13B is a flowchart showing the operation of the communication terminal.
  • FIG. 13C is a flowchart showing the operation of the communication terminal.
  • FIG. 13A is a flowchart showing the operation of the communication terminal.
  • FIG. 14 is a diagram showing a connection mode between the call control process and the terminal device when the VPN connecting the server systems goes down.
  • FIG. 15A is a diagram showing the stored contents of the first management table when the VPN connecting the server systems goes down.
  • FIG. 15B is a diagram showing the stored contents of the second management table when the VPN connecting the server systems goes down.
  • FIG. 1 is a diagram showing a configuration of a voice communication system 1 according to an embodiment of the present invention.
  • the voice communication system 1 has a plurality of (two in this embodiment) server systems 2 (2-1, 2-2) and a plurality of communication terminals 4.
  • the server system 2 and the communication terminal 4 are connected to each other by a plurality of (two in this embodiment) LTE networks 3 (3-1, 3-2).
  • the two LTE networks 3-1 and 3-2 are communication networks provided by different communication carriers (mobile phone companies).
  • a server system 2-1 is installed as a cloud server on the LTE network 3-1 (first communication carrier), and a server system 2-2 is installed as a cloud server on the LTE network 3-2 (second communication carrier). ..
  • the server systems 2-1 and 2-2 are connected by VPN6 using a dedicated line provided by a communication carrier.
  • the communication terminal that accesses the server system 2 via the LTE network 3-1 is equipped with the SIM card of the first communication carrier.
  • the communication terminal that accesses the server system 2 via the LTE network 3-2 is equipped with the SIM card of the second communication carrier.
  • the server system 2-1 has a call control server 21-1, a provisioning server 22-1, and a management server 20-1.
  • the server system 2-2 has a call control server 21-2, a provisioning server 22-2, and a management server 20-2.
  • the call control server 21-1, provisioning server 22-1, management server 20-1, and LTE network 3-1 are connected to each other by a LAN (local area network) 5-1.
  • the call control server 21-2, the provisioning server 22-2, the management server 20-2, and the LTE network 3-2 are connected to each other by LAN5-2.
  • LAN5-1 and LAN5-2 are connected to each other by VPN6.
  • VIPN6 corresponds to the communication line of the present invention.
  • server system 2-1 and the server system 2-2 are located in the clouds of different communication carriers and can be installed in geographically separated locations, a robust voice communication system that is resistant to failures is constructed. be able to. Since the server system 2-1 and the server system 2-2 are connected by a dedicated line VPN6, flexible process redundancy as described below is possible as in the case of being on the same network. Is.
  • the call control server 21-1 and the provisioning server 22-1 of the server system 2-1 act as the main server to execute provisioning and call control for the communication terminal 4.
  • the call control server 21-2 and the provisioning server 22-2 of the server system 2-2 are on standby as sub-servers in case the main server goes down. It should be noted that the main / sub switching is performed not in units of hardware but in units of a plurality of processes started internally.
  • the plurality of processes have, for example, the configuration shown in FIG. 4, and each of them functions as a virtual server.
  • the management server 20 (20-1, 20-2) is a process executed by the call control servers 21-1, 21-2 and the provisioning servers 22-1, 22-2 of the server systems 2-1 and 2-2. It manages the operating status of the server and provides the information to the server or the communication terminal 4 as requested.
  • the management server 20 includes a management table 31 as shown in FIG.
  • the calling terminal When a certain communication terminal 4 (calling terminal) communicates with another communication terminal 4 (calling terminal), the calling terminal transmits a voice signal including the identification information of the calling terminal as control information to the call control server 21. To do.
  • the call control server 21 transfers this voice signal to the incoming call terminal via the LTE network 3. This enables voice communication between the calling terminal and the incoming call terminal via the network without prior calling procedures such as SIP procedures (by operating like a general wireless transceiver). This communication method is described in detail in the pamphlet of International Publication WO2015 / 068663.
  • FIG. 2 is a block diagram of the management server 20 (20-1, 20-2), the call control server 21 (21-1, 21-2), and the provisioning server 22 (22-1, 22-2). ..
  • the server has a control unit 30, a storage unit 31, and a network communication unit 32.
  • the storage unit 31 is composed of, for example, a hard disk or RAM.
  • the management table 31 as shown in FIG. 9 is stored in the storage unit 31.
  • the storage unit 31 is provided with a status table as shown in FIG. 7.
  • the network communication unit 32 communicates with the communication terminal 4 and other servers via the LAN 5 and the LTE network 3.
  • the control unit 30 controls the operation of each server.
  • FIG. 3 is a block diagram of the communication terminal 4.
  • the communication terminal 4 has the appearance of a handy transceiver, but is functionally a wireless network device that transmits and receives audio signals via the LTE network 3.
  • the control unit 40 that controls the operation of the device is composed of a microprocessor.
  • the control unit 40 has a storage unit 41 in which various data are stored.
  • the storage unit 41 has a provisioning data storage area 41A.
  • the provisioning data storage area 41A stores provisioning data as shown in FIG.
  • An operation unit 42, a display unit 43, an audio circuit 44, an LTE communication unit 45, and a card slot 46 are connected to the control unit 40.
  • the operation unit 42 includes a key switch such as a PTT switch 220, receives a user's operation, and inputs the operation signal to the control unit 40.
  • the display unit 43 includes a liquid crystal display. On the liquid crystal display, the identification number of the communication partner selected by the user's operation, the identification number of the incoming communication partner, and the like are displayed.
  • the audio circuit 44 has a microphone 240 and a speaker 241.
  • the control unit 40 decodes the received audio signal and inputs it to the audio circuit 44.
  • the audio circuit 44 converts the decoded audio signal into an analog signal and outputs it from the speaker 241.
  • the audio circuit 44 also converts the audio signal input from the microphone 240 into a digital signal and inputs it to the control unit 40.
  • the control unit 40 converts the digital audio signal into a voice packet and inputs it to the LTE communication unit 45.
  • the LTE communication unit 45 has a circuit that performs wireless communication by the LTE communication method.
  • the LTE communication unit 45 transmits the packet input from the control unit 40 to the LTE network 3, and inputs the packet received from the LTE network 3 to the control unit 40.
  • the audio circuit 44 is provided with an earphone connector 242.
  • an earphone microphone (not shown) is connected to the earphone connector 242, the audio circuit 44 stops the functions of the microphone 240 and the speaker 241 provided in the communication terminal 4 main body, and the microphone and speaker (earphone) of the earphone microphone are stopped.
  • An IC card (SIM card) 47 in which terminal identification information is stored is set in the card slot 46.
  • the SIM card 47 of the first communication carrier is set in the communication terminal 4 used in the LTE network 3-1 and the SIM card 47 of the second communication carrier is set in the communication terminal 4 used in the LTE network 3-2. Will be done.
  • the terminal identification information (ICCID) stored in the SIM card 47 is used as the identification information of each communication terminal 4.
  • the communication terminal 4 when the user inputs voice to the microphone 240 while pressing the PTT switch 220, the communication terminal 4 writes this voice signal with preset identification information of the incoming call terminal. It is edited into a voice packet, and this voice packet is transmitted to the call control server 21 via the LTE network 3.
  • FIG. 4 and 5 are diagrams showing a redundant configuration of the call control server 21 and the provisioning server 22.
  • FIG. 4 is a diagram showing duplication by the call control server 21 and the provisioning server 22 and a partition configuration in the control unit 30 of the call control server 21, and
  • FIG. 5 is a diagram showing the functions of each process executed by the call control server 21. is there.
  • the call control server 21 executes a plurality of processes (virtual servers) that are independent of each other so that independent communication services can be provided to the plurality of clients.
  • the client is, for example, a business operator who uses the voice communication system 1.
  • the call control server 21 is divided into 6 partitions, and each partition executes a different process.
  • the provisioning server 22 is common to a plurality of clients, but executes different provisioning processes based on the unique identification number of the communication terminal 4 of each client.
  • the processes executed in each partition of the call control server 21-1 are the call control processes A, B, and C for controlling the voice communication of the clients A, B, and C.
  • the processes executed in each partition of the call control server 21-2 are the call control processes A and B for controlling the voice communication of the clients A and B. That is, the call control processes A and B of the clients A and B are made redundant, but the call control process C of the client C is not made redundant.
  • the call control process A is a process of relaying voice communication between the communication terminals 4 of the client A.
  • the call control process C is a process of relaying voice communication between the communication terminals 4 of the client C.
  • One call control process can accommodate up to a predetermined number (eg, 100) of communication terminals 4.
  • accommodating the communication terminal 4" means registering the communication terminal 4 in the memory, relaying voice communication and transmitting provisioning data to the communication terminal 4.
  • the call control server 21 executes a plurality of call control processes and inter-site connection processes. Each call control process accommodates up to 100 communication terminals 4, and the inter-site connection process connects each call control process to enable voice communication between the communication terminals 4 accommodated in each call control process.
  • the client B executes two call control processes B1 and B2, and further executes the inter-site connection process Br to make a call.
  • the control processes B1 and B2 are connected. As a result, voice communication between all the communication terminals 4 belonging to the client B is realized.
  • the call control processes A and B of the clients A and B are made redundant, but the call control process C of the client C is not made redundant.
  • the call control process executed by the call control server 21, which is redundant hardware, can set the presence or absence of redundancy for each process. Whether or not to make each process redundant may be determined based on the hardware resources and the importance of the process.
  • the provisioning server 22 is a server for transmitting provisioning data as shown in FIG. 12 to the communication terminal 4.
  • the communication terminal 4 accesses the provisioning server 22 when the power is turned on, and receives the provisioning data shown in FIG.
  • the communication terminal 4 sets up its own operation with the received provisioning data, and can access the call control process of the client to which the communication terminal 4 belongs. Provisioning is described in detail in the International Publication WO2017 / 086416 Pamphlet.
  • the call control server 21-1 and provisioning server 22-1 and the call control server 21-2 and provisioning server 22-2 do not necessarily have the same performance, and the number of configurable partitions must also be the same. Absent.
  • the process executed by the call control server 21-1 communicates as an operating process.
  • the call control process for relaying voice communication between the terminals 4 is actually performed.
  • Each process running on the call control server 21-2 is waiting as a standby process to be replaced if the corresponding operating process (the same process running on the call control server 21-1) goes down. ..
  • the operation mode (operating process / standby process) of each process is stored in the management table 31 (see FIG. 9) of the management server 20.
  • Both the provisioning server 22-1 and the provisioning server 22-2 are set to the operation mode and respond to the provisioning request from the communication terminal 4.
  • FIG. 5 shows the connection relationship between each call control process and the communication terminal 4 during normal operation, that is, when all processes are normally executed.
  • the SIM of the first communication carrier is set in the communication terminal 4 possessed by each client, and the communication terminal 4 that accesses the server system 2 via the LTE network 3-1 and the SIM of the second communication carrier are set.
  • the call control processes A, B1, B2, and C of the call control server 21-1 which is the main server, are operating to perform call control processing. Connected to one process.
  • the communication terminal 4 connected to the LTE network 3-2 is the call control server 21- from the LTE network 3-2 via the VPN6.
  • Access 1 A multi-carrier communication terminal in which both the SIM of the first communication carrier and the SIM of the second communication carrier are set, and the server system 2 can be accessed via either the LTE network 3-1 or the LTE network 3-2. 4 may be provided.
  • FIG. 6 describes switching from the operating process to the standby process in the call control process B (call control processes B1 and B2 and the inter-site connection process Br) of the client B.
  • FIG. 6A shows the connection form of each process and the communication terminal 4 when each process of the client B is normally executed.
  • This connection form is the same as that shown in FIG.
  • the call control processes B1-1 and B2-1 and the inter-site connection process Br-1 are running, and the communication terminal 4 accesses the call control processes B1-1 and B2-1.
  • the communication terminal 4-1 accesses the call control process B1-1 via the LTE network 3-1
  • the communication terminal 4-3 accesses the call control process B1 via the LTE network 3-2 and the VPNN6.
  • the communication terminal 4-2 accesses the call control process B2-1 via the LTE network 3-1
  • the communication terminal 4-4 accesses the call control process B2-1 via the LTE network 3-2 and the VPNN6. To do.
  • FIG. 6B shows the connection form when the call control process B2-1 goes down. Since the call control process B2-1 which was the operating process went down, the corresponding standby process call control process B2-2 becomes the operating process. Then, the communication terminals 4-2 and 4-2 change the access destination from the call control process B2-1 to the call control process B2-2. Specifically, the communication terminal 4-2 accesses the call control process B2-2 via the LTE network 3-1 and VPN6, and the communication terminal 4-4 accesses the call control process B2 via the LTE network 3-2. Access -2. Further, the inter-base connection process Br-1 switches the connection base so as to connect the main call control process B1-1 and the sub call control process B2-2.
  • FIG. 6C shows the connection form when the inter-site connection process Br-1 goes down. Since the inter-site connection process Br-1, which was an operating process, went down, the inter-site connection process Br-2, which is a standby process, becomes an operating process. Since the call control processes B1-1 and B2-1 of the call control server 21-1 are operating normally, the inter-site connection process Br-2 is the call control process of the call control server 21-1 via the VPN6. Connect B1-1 and B2-1. Since the call control processes B1-1 and B2-1 are operating normally as in the normal operation, there is no change in the access destinations of the communication terminals 4-1 to 4.
  • Each process has a status table as shown in FIG. 7 in the storage unit 31 in order to store the status of the process being executed by itself and the corresponding partner process.
  • the status table has a storage area for the name of the process it is executing, operation settings, operation mode (operation mode / standby mode), its own operation notification expiration date, and operation notification expiration date of the operating system. ing.
  • operation setting column setting information of any one of main process (main) / sub process (sub) / independent process (alone) is stored.
  • the process executed by the call control server 21-1 which is the main server is set to the main process
  • the process executed by the call control server 21-2 which is the sub server is set to the sub process.
  • the main process is in active mode to perform the actual processing and the subprocess is in standby mode. If the main process goes down, the subprocess goes into working mode.
  • the operation mode column whether the operation mode of this process is the operation mode or the standby mode is stored.
  • the operation notification sent by each process to the management server 20 and the corresponding standby process includes the name of the process being executed by itself, the operation setting, the operation mode, and the expiration date of this operation notification.
  • FIG. 7A is a diagram showing an example of the stored contents of the status table of the main process.
  • this process is executing the call control process B2-1, the operation setting is main, and the operation mode is operation mode.
  • the operation notification expiration date the expiration date of the operation notification sent by itself to the management server 20 and the subprocess of the other party is stored.
  • the operation notification is a message that itself notifies the management server 20 and the standby process that it is operating normally.
  • the standby process and the management server 20 confirm that the operating process is operating normally by sending an operation notification with a new expiration date before the expiration date of the operation notification has elapsed.
  • the expiration date of the operation notification received from the corresponding operation process is stored when the user is waiting. Since FIG. 7A is a status table of the operating process, the operating process operation notification expiration date received from the operating process is blank.
  • FIG. 7B is a diagram showing an example of the stored contents of the status table of the subprocess.
  • this process is executing the call control process B2-2, the operation setting is a subprocess, and the operation mode is the standby mode.
  • the operation notification expiration date the expiration date of the operation notification sent by itself to the management server 20 is stored.
  • the expiration date of the operation notification sent from the corresponding operation process (call control process B2-1) is stored. If an operation notification of a new expiration date is sent before the expiration date has passed, the table is updated with the new expiration date and the standby mode is continued.
  • this subprocess determines that the main process, which is the operating process, is down, and it itself.
  • the operation mode of is switched to the operation mode, and the relay of voice communication of the communication terminal 4 is started.
  • FIG. 8 is a flowchart showing the operation of the call control process executed by the call control server 21.
  • FIG. 8A shows the operation notification process of the operation process.
  • the operating process periodically (for example, every minute) sends an operation notification to the management servers 20-1 and 20-2 on both sides (S11), and also sends an operation notification to the corresponding standby process. Transmit (S12).
  • the expiration date of the transmitted operation notification is set longer than the next scheduled transmission time.
  • the operation process updates the expiration date of the operation notification of its own status table with this expiration date (S13).
  • FIG. 8B shows the operation status confirmation process executed by the operating process and the standby process. This process is also executed periodically.
  • Some production processes have connections with other processes.
  • the connection with other processes is, for example, a state in which the call control process B1 and the inter-site connection process Br shown in FIGS. 5 and 6 and the call control process B2 and the inter-site connection process Br are connected, respectively.
  • this process performs processing such as switching its own connection destination according to the operating status of the other process.
  • the process inquires the management server 20 about the operating status of each process at predetermined time intervals (S16).
  • the process When the operation status of each process is returned from the management server 20 in response to this inquiry (S17), the process is connected to the connection destination, such as the connection destination process is down and the standby process is switched to the operating process. It is determined whether there is a change in the operation status of (S18). If there is a change in the operating status of the connection destination (YES in S18), the process switches the connection destination according to the current operating status (S19) and ends the process. If there is no connection with another process, or if there is no change in the connection destination (NO in S18), the process ends the operation status confirmation process.
  • the call control process B2-1 goes down when the inter-site connection process Br-1 inquires about the operation status of the management server 20-1. It knows that it is doing and that the call control process B2-2, which was the standby process, has started operation. Therefore, the operation of the call control process B is maintained by starting the interprocess communication for the call control process B2-2.
  • the inquiry to the management server 20 in FIG. 8B is made to the management server 20 on the same side, that is, the management server installed in the same server system 2-1 and 2-2 as the call control server 21 on which this process is executed. It is done for 20. If the management server 20 does not respond to the inquiry, the process queries the opposite management server 20 again.
  • the management server 20 on the opposite side is a management server 20 installed in a server system 2-1 or 2-2 different from the call control server 21 on which this process is executed.
  • Inquiries to the management server 20 may be made at regular intervals, but each time the interprocess communication is changed or the operation mode of the standby process is switched (see FIG. 8D), the management server 20 is contacted for each process. You may inquire about the operating status (communication partner).
  • FIG. 8C shows the operation notification process of the standby process.
  • the standby process periodically (for example, every minute) sends an operation notification to the management servers 20-1 and 20-2 on both sides (S21).
  • the expiration date of the transmitted operation notification is set longer than the next scheduled transmission time. With this expiration date, the expiration date of the operation notification of the own status table is updated (S22).
  • FIG. 8D shows the operation status confirmation process of the standby process. This process is also executed periodically.
  • the standby process refers to the status table and determines whether the operation notification of the operating process is valid (S24). When the operation notification from the operating process has expired (NO in S24), the standby process determines that the operating process is down.
  • the standby process sets the connection destination, etc. according to the operating status of each process acquired in the process of FIG. 8B, and starts operation with itself as the operating process in place of the downed operating process (main process) ( S25).
  • the new operation process rewrites the operation mode of the status table to the operation mode (S26). For example, as shown in FIG. 6C, when the inter-site connection process Br-1 goes down, the inter-site connection process Br-2 operates to perform interprocess communication with the operating call control processes B1-1 and B2-1. To start.
  • the new operation process starts operation as an operation process, and then notifies the management server 20 that the operation mode has been changed (S27).
  • This operation mode change notification also serves as an operation notification.
  • S24 when the operating process is operating normally, that is, when the operation notification has not expired (YES in S24), the standby process ends the operation status confirmation process.
  • FIG. 9 is a diagram showing an example of the management table 31 set in the management server 20. In FIG. 9, only the part related to the process of the call control servers 21-1 and 21-2 in the management table 31 is shown. Similar tables are provided for each process of provisioning servers 22-1 and 22-2.
  • the management table 31 stores information on all processes executed by the main server (first) call control server 21-1 and the sub-server (second) call control server 21-2. There is.
  • the operation notification expiration date, operation setting, and operation mode are stored in the management table 31 for each process.
  • the operation notification expiration date column the expiration date described in the operation notification sent from the process is stored. If the management server 20 receives a new operation notification from the process within this expiration date, the expiration date is updated to the expiration date described in the new operation notification.
  • the setting information of either the main process or the sub process is stored in the operation setting column. Either the operation mode or the standby mode is stored in the operation mode column.
  • the management server 20 If a new operation notification is not sent from each process within the operation notification expiration date, the management server 20 considers that the process is down (the function of sending the operation notification is lost). , Rewrite the operation mode to down. Since there are periodic inquiries about the operating status of all processes from the processes that are operating normally, the management server 20 responds to these inquiries about the processes that are operating normally, the processes that are waiting normally, and so on. And, the information such as the down process is returned. Each process switches the connection destination according to this operating condition. Further, when the management server 20 receives a notification to the effect that the operation has started from the process that started the operation in response to the down of the operation process, the management server 20 rewrites the operation mode of this process in the management table 31 to the operation mode.
  • management table 31 may be provided with an area for storing the connection destination process that is the communication partner for the processes that perform interprocess communication (for example, call control processes B1-1, B1-2, Br-1, etc.).
  • FIG. 10 is a flowchart showing the operation of the management server 20.
  • FIG. 10A is a flowchart showing the expiration date update operation.
  • S31 When an operation notification is received from any process (S31), the operation notification expiration date of that process in the management table 31 is updated (S32).
  • S32 When the process is started and the operation notification is transmitted for the first time, the management server 20 registers this process in the management table 31 and writes the operation notification expiration date.
  • FIG. 10B is a flowchart showing the operation when the operation start notification is received from the process.
  • the management server 20 Upon receiving a notification from the standby process that it has started operation (instead of a down operation process) (S35: see S27 in FIG. 8D), the management server 20 sets the operation mode of that process in management table 31 to operation mode. Change (S36). Since this operation start notification also serves as an operation notification, the management server 20 updates the operation notification expiration date of this process (S37). The management server 20 sends an alert to the terminal (personal computer) of the system administrator by e-mail or the like to the effect that the operating process has changed (S38).
  • FIG. 10C is a flowchart showing a table maintenance operation.
  • the following processes are periodically executed for all the processes stored in the management table 31.
  • the management server 20 reads the expiration date of the process operation notification (S41). This expiration date is compared with the current time, and if the expiration date has expired (YES in S42), the management server 20 rewrites the operation mode to down (S44).
  • the management server 20 executes this operation for all the processes stored in the management table 31. In S44, even if the down state continues and the operation mode is already rewritten to down, the operation mode is rewritten to down, but if it is already in the down mode, it may not be rewritten. ..
  • the management server 20 determines whether the current operation mode is down (S45). When the operation mode is down (YES in S45), the management server 20 rewrites the operation mode to the standby mode (S46). If the operation notification has not expired (NO in S42) and the operation mode is not down (NO in S45), the management server 20 ends the maintenance process for this process. The management server 20 sequentially executes the maintenance processing of S41-S46 for all the processes stored in the management table 31.
  • this process when a process that has been down is restored, this process operates as a standby process in preparation for the down of the currently running process.
  • this main process may be restored to the operating process, and the subprocess operating as the operating process up to that time may be switched to the standby mode.
  • FIG. 11A is a diagram showing the stored contents of the management table 31 when the call control process of the client B is in the state of FIG. 6B.
  • FIG. 11B is a diagram showing the stored contents of the management table 31 when the call control process of the client B is in the state of FIG. 6C.
  • the call control process B2-1 is down, and the call control process B2-2 is in operation instead.
  • the operation mode of the call control process B2-1 is rewritten to down, and instead, the operation mode of the call control process B2-2 is set to the operation mode.
  • the inter-site connection process Br-1 of the call control server 21-1 is down, and instead, the inter-site connection process Br-2 of the call control server 21-2 is running.
  • the operation mode of the inter-site connection process Br-1 is rewritten to down, and instead, the operation mode of the inter-site connection process Br-2 is set to the operation mode. ..
  • the management server 20 updates the management table 31 in response to the change in the operation mode of each process, and transmits the contents of this table in response to inquiries from other processes or the communication terminal 4.
  • the process can know the state of another process, and it becomes easy to change the connection destination of the interprocess communication and to change the call control process accessed by the communication terminal 4.
  • the management server 20 also functions as a web server.
  • the contents of the management table 31 and its update history can be displayed on the administrator's personal computer via the LAN 5 or the LTE network 3.
  • FIG. 10D is a flowchart showing a process corresponding to an inquiry from the process of the management server 20.
  • the management server 20 responds to the inquired process with the operation status of each process (contents of the management table 31). Is transmitted (S51). This allows a process to know the operating status of other processes.
  • FIG. 10E is a flowchart showing a process corresponding to an inquiry from the communication terminal 4 of the management server 20.
  • the management server 20 When there is an inquiry from the communication terminal 4 for the call control process in operation (S54), the management server 20 notifies the call control process on the operating side of the call control processes of the client to which the communication terminal 4 belongs. (S55). As a result, when the running call control process goes down and the running call control process is switched, the communication terminal 4 can access the switched call control process.
  • FIG. 12 is a diagram showing an example of provisioning data 41 stored in the memory of the communication terminal 4.
  • the provisioning data 41 includes a main provisioning server address, a sub-provisioning server address, a main call control server address, a sub-call control server address, and various setting information.
  • the main provisioning server address includes the IP address and port number of the provisioning server 22-1.
  • the sub-provisioning server address includes the IP address and port number of the provisioning server 22-2. These addresses may be given by the provisioning server 22 or may be stored in the communication terminal 4 in advance.
  • the main call control server address includes the IP address of the call control server 21-1 and the port number of the process of the client to which the communication terminal 4 belongs.
  • the sub-call control server address includes the IP address of the provisioning server 22-2 and the port number of the process of the client to which the communication terminal 4 belongs.
  • the main provisioning server address / sub-provisioning server address and the main call control server address / sub-call control server address are provided with an running flag indicating which process is running. By default, the running flags for the main provisioning server address and the main call control server address are set.
  • the various setting information includes, for example, the call ID of the communication terminal 4, the notification sound setting (selection information of the notification sound when receiving a call), and the earphone setting (setting whether to perform full duplex communication when the earphone microphone is connected). Information), address book (call ID list of callable communication terminal 4), volume setting (volume setting information of call sound), and the like.
  • FIG. 13A-C is a flowchart showing the operation of the communication terminal 4.
  • FIG. 13A is a flowchart showing the provisioning operation. This operation is executed when the power of the communication terminal 4 is turned on.
  • the control unit 40 of the communication terminal 4 accesses the provisioning server 22-1 which is the main server and requests the transmission of provisioning data (S61). If there is a response from the provisioning server 22-1 within a certain period of time (YES in S62), the communication terminal 4 receives the provisioning data from this server (S65) and executes provisioning (S66). If there is no response from the provisioning server 22-1 within a certain period of time (NO in S62), the communication terminal 4 accesses the sub-server provisioning server 22-2 and requests the transmission of provisioning data (S63).
  • the operating flag is switched to the sub-provisioning server 22-2 side (S64). Then, the communication terminal 4 receives the provisioning data from the sub-provisioning server 22-2 (S65). If the two provisioning servers 22-1 and 22-2 go down at the same time, the communication terminal 4 may try to connect using the previously acquired provisioning data.
  • FIG. 13B is a flowchart showing the operation of the communication terminal 4 during voice communication. This operation is started when the PTT switch 220 is pressed.
  • the control unit 40 of the communication terminal 4 transmits a voice signal to the call control process (virtual server) assigned to the communication terminal 4 of the main call control server 21-1 (S71). If there is a response from the process of the call control server 21-1 within a certain period of time (YES in S72), the communication terminal 4 starts voice communication. If there is no response from the process of the call control server 21-1 within a certain period of time (NO in S72), the communication terminal 4 stops the operation by displaying that communication is not possible.
  • This communication down state is a state that can occur when the call control process that has been operating up to that point is down and communication is started before the operation process confirmation in FIG. 13C.
  • FIG. 13C is a flowchart showing an operation in which the communication terminal 4 inquires about the operating call control process. Although this process is performed periodically, it may be temporarily executed when there is no response from the call control process that was running in S72 of FIG. 13B.
  • the control unit 40 of the communication terminal 4 inquires the management server 20 of the operating call control process accommodating the communication terminal 4 (S73). In response to this, the management server 20 sends information on the operating process.
  • the communication terminal 4 receives this information (S74: see S55 in FIG. 10E), and determines whether the operating process has been switched (S75). When switched (YES in S75), the communication terminal 4 switches the operating flag of the call control server to the operating process side (sub-call control server side) (S76). After that, when voice communication occurs, the communication terminal 4 accesses the call control process switched to the operating process.
  • the communication terminal 4 transmits a message requesting registration (registration message) to the call control server 21 in the operation mode at the start of operation, periodically, and at every opportunity such as area movement.
  • the call control server 21 in the operation mode can grasp the communication terminal in operation and register the communication terminal 4 in the terminal table. If the communication terminal 4 does not respond even if it sends this registration message to the call control server 21-1 / 2, which is the operation mode, it is assumed that the call control server 21-1 / 2 is down, and the opposite side.
  • a registration message is sent again to the call control server 21-2 / 1.
  • the communication terminal 4 periodically inquires of the management server 20 about the operation mode call control process, but the operation mode is called depending on whether or not there is a response to the above registration message. You may resolve which control process you have.
  • the call control process operating in standby mode When the call control process operating in standby mode receives a registration message from the communication terminal, it responds that the destination of the registration message should be switched to the call control process on the opposite side (in operation mode) and retransmitted. You may reply to the communication terminal.
  • the call control server 21 in the operation mode is determined based on the presence or absence of a response to the registration message, even if the number of communication terminals 4 is large, inquiries to the management server 20 will not occur frequently, and the load on the management server 20 will be increased. It can be mitigated. However, since the resist interval is generally longer than the inquiry interval shown in FIG. 13C or the like, it takes a long time for the communication terminal 4 to know the change of the call control process in the operation mode.
  • FIG. 14 shows a connection mode between processes when VPN6 goes down in the call control process of client B.
  • Management servers 20-1, 20-2, call control servers 21-1, 21-2, provisioning servers 22-1, 22-2 are operating normally, and call control processes B1-1, B2-1, B1 -2, B2-2, and the inter-site connection processes Br-1 and Br-2 are also operating normally.
  • VPN6 goes down, communication between server systems 2-1 and 2-2 becomes impossible. Even in this case, since the management server 20-1 of the server system 2-1, the call control server 21-1, and the provisioning server 22-1 are operating normally, the server system 2-1 via the LTE network 3-1. It is possible to continue services such as the call control process B for the communication terminal 4 (4-1, 4-2) that accesses the.
  • the management server 20-2, the call control server 21-2, and the provisioning server 22-2 are operating normally, and the operation notification from each process of the server system 2-1. Will not reach.
  • the management server 20-2, the call control server 21-2, and the provisioning server 22-2 determine that all the processes on the server system 2-1 side are down, and the call control server 21-2 and the provisioning server 22 Each process of -2 switches from the standby mode to the operating mode to operate the call control process for the client B. Then, the call control process launched by the call control server 21-2 provides a service to the communication terminals 4 (4-3, 4-4) that access the server system 2 via the LTE network 3-2. To do.
  • This degenerate operation corresponds to the interruption of the operation notification from the other process due to the down of the VPN6, and the operation of each process of the call control servers 21-1 and 21-2 shown in FIG. This can be achieved by the operations of the management servers 20-1 and 20-2 shown in 10.
  • the call control server 21-1 is set as the main server
  • the call control server 21-2 is used as the sub server
  • each process executed by the call control server 21-1 is set as the main process.
  • the process whose operation is set as a process may be distributed to the call control servers 21-1 and 21-2.
  • the configuration in which two server systems 2 and two networks 3 are provided has been described, but the configuration may include the third, fourth, ... Server systems and networks. By doing so, further redundancy is possible.
  • Voice communication system 2 (2-1, 2-2) Server system 20 (20-1, 20-2) Management server 21 (21-1, 21-2) Call control server 22 (22-1, 22-2) ) Provisioning server 3 (3-1, 3-2) LTE network 4 (4-1-4) Communication terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】複数のサーバを有するサーバシステムで、プロセス単位の冗長化を実現する。 【解決手段】第１サーバ、第２サーバは並行して複数のプロセスを実行する。第１サーバのプロセス（Ｂ１－１、Ｂ２－１、Ｂｒ－１）が稼働プロセス、第２サーバのプロセス（Ｂ１－２、Ｂ２－２、Ｂｒ－２）が待機プロセスとなる。稼働プロセスは、正常動作を知らせる動作通知を定期的に待機プロセスに送信する。待機プロセスは、稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、このプロセスのサービスの提供を開始する。このプロセスの切り換えがサーバ単位でなくプロセス単位で行われる。

Description

サーバシステムおよびプロセスの冗長化方法
　この発明は、サーバシステムの冗長化に関する。
　稼働サーバと待機サーバを設置し、稼働サーバと待機サーバとの間で同期をとることでサーバシステムを冗長化することは従来より知られている。冗長構成のサーバシステムを構成した場合、端末装置との通信は、例えば、ＶＲＲＰなどのプロトコルを用いた仮想ＩＰで行われる（特許文献１参照）。
特開２０１３－０７７９８３号公報
　ＶＲＲＰを用いるためには、同一ネットワークセグメント上に稼働サーバ、待機サーバの両方を設置する必要がある。この形態で冗長化されたサーバシステムは、サーバで複数のプロセスが実行されている場合、一部のプロセスに障害が発生した場合でも、全てのプロセスを稼働サーバから待機サーバへ切り換える必要があった。
　ＶＲＲＰでは、稼働サーバは、自身が正常に動作していることを通知するため、待機サーバに向けて一定時間毎にアドバタイズメントを送信する。一方、逆方向すなわち、待機サーバから稼働サーバに向けてのアドバタイズメントは送信されないため、稼働サーバが、システム内の他のサーバの状態を知ることができなかった。
　この発明の目的は、プロセス単位でサーバを冗長化でき、プロセス間通信を行う場合等に、プロセスが他のプロセスの動作状況を容易に知ることができるようにすることにある。
　本発明は、通信ネットワーク上に設置された第１サーバおよび第２サーバを備えている。第１サーバは複数のプロセスを実行し、第２サーバは、第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行する。第１サーバおよび第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し（稼働プロセス）、他方のプロセスが、稼働モードのプロセスがダウンしたとき、これに代わって稼働モードとなる待機モードで動作する（待機プロセス）。稼働プロセスは、自身が正常に動作していることを通知するメッセージである動作通知を、定期的に待機プロセスに送信する。待機プロセスは、稼働プロセスから定期的に動作通知を受信している間待機モードを継続するが、稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、このプロセスのサービスの提供を開始する。
　この発明では、第１サーバ、第２サーバでプロセスが並行して実行され、一方が稼働プロセス、他方が待機プロセスとされる。一部のプロセスが障害でダウンした場合に、サーバ全体を切り換えるのでなく、その障害が発生したプロセスの単位で切り換える。これにより、冗長構成の切り換え処理が簡略化されるとともに、第１、第２サーバの双方で一部のプロセスがダウンしていても、相手方のサーバでそのプロセスが正常に稼働していればシステム全体として動作可能であるため、より堅牢性が増す。
　通信ネットワークとして、例えばそれぞれ別の携帯電話キャリアのネットワークである第１ネットワーク、第２ネットワークを用い、第１サーバを第１ネットワーク上に設け、第２サーバを第２ネットワーク上に設けてもよい。この場合、第１サーバと第２サーバとは、専用線によるＶＰＮなどで接続される。このように、第１サーバおよび第２サーバを別々のネットワーク上に設置することで、ネットワーク障害に対して強いシステムを構成することが可能になる。
　通信ネットワーク上に、各プロセスの動作状況を記憶する管理テーブルを備えた管理サーバをさらに設けてもよい。第１、第２サーバで実行される各プロセスは、管理サーバに対して定期的に動作通知を送信する。また、プロセスの動作モードが待機モードから稼働モードに切り換わったとき、そのプロセスはモード切換通知を管理サーバに送信する。管理サーバは、動作通知およびモード切換通知によって取得した各プロセスの動作状況を管理テーブルに記憶する。
　プロセスが、この管理テーブルの内容、すなわち、各プロセスの動作状況を参照することで、自身に通知が送られてこなくても、他のプロセスの動作状況を知ることができ、プロセス単位で稼働／待機（メイン／サブ）が切り換わっても、それに追従してプロセス間通信を維持することができる。
　例えば、第１プロセスが、第１サーバおよび第２サーバで並行して実行されているプロセス（第２プロセス）とプロセス間通信を実行する場合に、管理サーバに各プロセスの動作状況を問い合わせ、取得した各プロセスの動作状況に基づいて、２つのサーバで並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定し、この稼働している第２プロセスをプロセス間通信の通信相手とする。
　通信ネットワークとして、例えばそれぞれ別の携帯電話キャリアのネットワークである第１ネットワーク、第２ネットワークを用い、第１サーバおよび第１管理サーバを第１ネットワーク上に設け、第２サーバおよび第２管理サーバを第２ネットワーク上に設けてもよい。この場合、第１サーバシステム（第１サーバ、第１管理サーバ）と第１サーバシステム（第２サーバ、第２管理サーバ）とは、専用線によるＶＰＮなどで接続される。
　第１、第２サーバで実行される各プロセスは、第１管理サーバ、第２管理サーバの両方に対して動作通知およびモード切換通知を送信する。これにより、管理サーバの冗長化が可能になる。プロセスは、自身と同じ側のネットワーク上にある管理サーバに各プロセスの動作状況を問い合わせればよい。
　第１サーバおよび第２サーバで実行されるプロセスは、複数の通信端末から送信された音声信号を中継する呼制御プロセスであってよい。複数の通信端末のうち、第１ネットワークのＳＩＭがセットされた通信端末は、第１ネットワークを介してサーバにアクセスする。第２ネットワークのＳＩＭがセットされた通信端末は、第２ネットワークを介してサーバにアクセスする。第１ネットワークから第２サーバにアクセスする場合は、サーバ間をつなぐＶＰＮを介する。
　この発明によれば、第１および第２サーバで複数のプロセスを実行する場合に、プロセス単位で冗長構成を構築することができ、サーバ（プロセス）切り換えの容易化およびより高い堅牢化を実現することができる。
図１は、この発明の実施形態である音声通信システムの構成図である。 図２は、音声通信システムのサーバのブロック図である。 図３は、通信端末のブロック図である。 図４は、呼制御サーバ、プロビジョニングサーバのパーテーションおよび各パーテーションで実行されるプロセス（仮想サーバ）を示す図である。 図５は、全てのプロセスが正常に動作している場合の各プロセスおよび通信端末の接続形態を示す図である。 図６Ａは、各プロセスが正常に動作している場合の各プロセスおよび通信端末の接続形態を示す図である。 図６Ｂは、一部のプロセスがダウンした場合の各プロセスおよび通信端末の接続形態を示す図である。 図６Ｃは、一部のプロセスがダウンした場合の各プロセスおよび通信端末の接続形態を示す図である。 図７Ａは、メインプロセスに設けられるステータステーブルを示す図である。 図７Ｂは、サブプロセスに設けられるステータステーブルを示す図である。 図８Ａは、呼制御サーバの動作を示すフローチャートである。 図８Ｂは、呼制御サーバの動作を示すフローチャートである。 図８Ｃは、呼制御サーバの動作を示すフローチャートである。 図８Ｄは、呼制御サーバの動作を示すフローチャートである。 図９は、管理サーバに設けられる管理テーブル３１を示す図である。 図１０Ａは、管理サーバの動作を示すフローチャートである。 図１０Ｂは、管理サーバの動作を示すフローチャートである。 図１０Ｃは、管理サーバの動作を示すフローチャートである。 図１０Ｄは、管理サーバの動作を示すフローチャートである。 図１０Ｅは、管理サーバの動作を示すフローチャートである。 図１１Ａは、一部のプロセスがダウンした場合の管理テーブルの記憶内容を示す図である。 図１１Ｂは、一部のプロセスがダウンした場合の管理テーブルの記憶内容を示す図である。 図１２は、通信端末に設定されるプロビジョニングデータの例を示す図である。 図１３Ａは、通信端末の動作を示すフローチャートである。 図１３Ｂは、通信端末の動作を示すフローチャートである。 図１３Ｃは、通信端末の動作を示すフローチャートである。 図１４は、サーバシステム間をつなぐＶＰＮがダウンした場合の呼制御プロセスと端末装置との接続形態を示す図である。 図１５Ａは、サーバシステム間をつなぐＶＰＮがダウンした場合の第１管理テーブルの記憶内容を示す図である。 図１５Ｂは、サーバシステム間をつなぐＶＰＮがダウンした場合の第２管理テーブルの記憶内容を示す図である。
　図１は、この発明の実施形態である音声通信システム１の構成を示す図である。音声通信システム１は、複数（この実施形態では２つ）のサーバシステム２（２－１,２－２）および複数の通信端末４を有している。サーバシステム２と通信端末４とは、複数（この実施形態では２つ）のＬＴＥネットワーク３（３－１,３－２）で相互に接続されている。２つのＬＴＥネットワーク３－１，３－２は、それぞれ異なる通信キャリア（携帯電話会社）が提供する通信ネットワークである。
　ＬＴＥネットワーク３－１（第１通信キャリア）上にクラウドサーバとしてサーバシステム２－１が設置され、ＬＴＥネットワーク３－２（第２通信キャリア）上にクラウドサーバとしてサーバシステム２－２が設置される。サーバシステム２－１、２－２間は通信キャリアによって提供される専用回線を用いたＶＰＮ６で接続されている。
　通信端末４のうち、ＬＴＥネットワーク３－１を介してサーバシステム２にアクセスする通信端末は、第１通信キャリアのＳＩＭカードを装着している。ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末は、第２通信キャリアのＳＩＭカードを装着している。
　サーバシステム２－１は、呼制御サーバ２１－１、プロビジョニングサーバ２２－１および管理サーバ２０－１を有している。サーバシステム２－２も同様に、呼制御サーバ２１－２、プロビジョニングサーバ２２－２および管理サーバ２０－２を有している。呼制御サーバ２１－１、プロビジョニングサーバ２２－１、管理サーバ２０－１およびＬＴＥネットワーク３－１は、ＬＡＮ（ローカル・エリア・ネットワーク）５－１で相互に接続されている。呼制御サーバ２１－２、プロビジョニングサーバ２２－２、管理サーバ２０－２およびＬＴＥネットワーク３－２は、ＬＡＮ５－２で相互に接続されている。ＬＡＮ５－１およびＬＡＮ５－２は、ＶＰＮ６で相互に接続されている。ＶＰＮ６が本発明の通信線に対応する。
　サーバシステム２－１とサーバシステム２－２は、それぞれ異なる通信キャリアのクラウド上にあり、地理的に離れた場所に設置することが可能であるため、障害に強い堅牢な音声通信システムを構築することができる。サーバシステム２－１とサーバシステム２－２とは、専用線のＶＰＮ６で接続されているため、同一のネットワーク上にある場合と同様に、以下に説明するような柔軟なプロセスの冗長化が可能である。
　通常動作時は、サーバシステム２－１の呼制御サーバ２１－１およびプロビジョニングサーバ２２－１がメインサーバとして、通信端末４に対するプロビジョニングおよび呼制御を実行する。サーバシステム２－２の呼制御サーバ２１－２およびプロビジョニングサーバ２２－２は、メインサーバのダウンに備えたサブサーバとしてスタンバイしている。なお、メイン／サブの切り換えは、ハードウェア単位ではなく、内部で起動される複数のプロセス単位で行われる。複数のプロセスは、例えば図４に示す構成であり、それぞれが仮想サーバとして機能する。
　管理サーバ２０（２０－１、２０－２）は、サーバシステム２－１、２－２の呼制御サーバ２１－１、２１－２およびプロビジョニングサーバ２２－１、２２－２で実行される各プロセスの動作状況を管理し、要求に応じてサーバや通信端末４にその情報を提供する。管理サーバ２０は、図９に示すような管理テーブル３１を備えている。
　ある通信端末４（発呼端末）が他の通信端末４（着呼端末）と通信する場合、発呼端末が、着呼端末の識別情報を制御情報として含む音声信号を呼制御サーバ２１に送信する。呼制御サーバ２１は、この音声信号をＬＴＥネットワーク３を介して着呼端末に転送する。これによって、ＳＩＰ手順などの事前の呼出手続なしで（一般の無線トランシーバのような操作で）、ネットワークを介した発呼端末－着呼端末間の音声通信が可能になる。この通信方式は、国際公開ＷＯ２０１５／０６８６６３号パンフレットに詳細に記載されている。
　図２は、管理サーバ２０（２０－１，２０－２）、呼制御サーバ２１（２１－１、２１－２）、および、プロビジョニングサーバ２２（２２－１、２２－２）のブロック図である。サーバは、制御部３０、記憶部３１およびネットワーク通信部３２を有している。記憶部３１は、たとえばハードディスクやＲＡＭなどで構成される。管理サーバ２０の場合、記憶部３１には、図９に示すような管理テーブル３１が記憶される。呼制御サーバ２１の場合、記憶部３１には、図７に示すようなステータステーブルが設けられる。ネットワーク通信部３２は、ＬＡＮ５およびＬＴＥネットワーク３を介して通信端末４や他のサーバと通信する。制御部３０は、各サーバの動作を制御する。
　図３は、通信端末４のブロック図である。通信端末４は、図１に示したように、ハンディトランシーバの外観を有しているが、機能的にはＬＴＥネットワーク３を介して音声信号を送受信する無線ネットワーク機器である。装置の動作を制御する制御部４０はマイクロプロセッサで構成される。制御部４０は、各種のデータが記憶される記憶部４１を有している。記憶部４１は、プロビジョニングデータ記憶エリア４１Ａを有する。プロビジョニングデータ記憶エリア４１Ａには、図１２に示すようなプロビジョニングデータが記憶される。制御部４０には、操作部４２、表示部４３、オーディオ回路４４、ＬＴＥ通信部４５およびカードスロット４６が接続されている。操作部４２は、ＰＴＴスイッチ２２０などのキースイッチを含み、ユーザの操作を受け付けてその操作信号を制御部４０に入力する。表示部４３は液晶ディスプレイを含む。液晶ディスプレイには、ユーザの操作によって選択された通信相手の識別番号や着信した通信相手の識別番号などが表示される。
　オーディオ回路４４は、マイク２４０およびスピーカ２４１を有している。制御部４０は、受信した音声信号をデコードしてオーディオ回路４４に入力する。オーディオ回路４４は、このデコードされたオーディオ信号をアナログ信号に変換してスピーカ２４１から出力する。オーディオ回路４４は、また、マイク２４０から入力された音声信号をデジタル信号に変換して制御部４０に入力する。制御部４０は、このデジタルオーディオ信号を音声パケット化してＬＴＥ通信部４５に入力する。ＬＴＥ通信部４５は、ＬＴＥ通信方式で無線通信を行う回路を有する。ＬＴＥ通信部４５は、制御部４０から入力されたパケットをＬＴＥネットワーク３に向けて送信し、ＬＴＥネットワーク３から受信したパケットを制御部４０に入力する。オーディオ回路４４にはイヤホンコネクタ２４２が設けられている。イヤホンコネクタ２４２にイヤホンマイク（不図示）が接続されると、オーディオ回路４４は、通信端末４本体に設けられているマイク２４０およびスピーカ２４１の機能を停止し、イヤホンマイクのマイクおよびスピーカ（イヤホン）を有効にする。カードスロット４６には、端末識別情報が記憶されたＩＣカード（ＳＩＭカード）４７がセットされる。ＬＴＥネットワーク３－１で使用される通信端末４には第１通信キャリアのＳＩＭカード４７がセットされ、ＬＴＥネットワーク３－２で使用される通信端末４には第２通信キャリアのＳＩＭカード４７がセットされる。このＳＩＭカード４７に記憶されている端末識別情報（ＩＣＣＩＤ）が各通信端末４の識別情報として用いられる。
　以上の構成の通信端末４において、ユーザがＰＴＴスイッチ２２０を押しながらマイク２４０に向けて音声を入力すると、通信端末４は、この音声信号を、予め設定された着呼端末の識別情報が書き込まれた音声パケットに編集し、この音声パケットをＬＴＥネットワーク３を介して呼制御サーバ２１に送信する。
　図４、図５は、呼制御サーバ２１、プロビジョニングサーバ２２の冗長化構成を示す図である。図４は、呼制御サーバ２１，プロビジョニングサーバ２２による二重化と呼制御サーバ２１の制御部３０におけるパーテーション構成を示す図、図５は、呼制御サーバ２１で実行される各プロセスの機能を示す図である。呼制御サーバ２１は、複数のクライアントに対して独立した通信サービスを提供できるように、相互に独立した複数のプロセス（仮想サーバ）を実行する。クライアントとは、例えば、音声通信システム１を利用する事業者である。図４に示すように、呼制御サーバ２１は、６のパーテーションに分割され、各パーテーションでそれぞれ別のプロセスを実行する。プロビジョニングサーバ２２は、複数のクライアントに対して共通であるが、各クライアントの通信端末４の固有識別番号に基づいて、それぞれ別のプロビジョニング処理を実行する。
　呼制御サーバ２１－１の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂ，Ｃの音声通信を制御するための呼制御プロセスＡ，Ｂ，Ｃである。呼制御サーバ２１－２の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂの音声通信を制御するための呼制御プロセスＡ，Ｂである。すなわち、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。
　呼制御プロセスＡは、クライアントＡの通信端末４相互間の音声通信を中継するプロセスである。呼制御プロセスＣは、クライアントＣの通信端末４相互間の音声通信を中継するプロセスである。一つの呼制御プロセスは、所定の台数（例えば１００台）までの通信端末４を収容することができる。なお、「通信端末４を収容する」とは、通信端末４をメモリに登録して、その通信端末４に対して音声通信の中継やプロビジョニングデータの送信を行うことである。所定台数以上の通信端末４を収容する場合、呼制御サーバ２１は、複数の呼制御プロセスおよび拠点間接続プロセスを実行する。各呼制御プロセスが１００台以内の通信端末４を収容し、拠点間接続プロセスが各呼制御プロセスを接続して、各呼制御プロセスに収容されている通信端末４相互間の音声通信を可能にする。クライアントＢは、所有する（収容すべき）通信端末４の台数が多い（１００台を超える）ため、２つの呼制御プロセスＢ１、Ｂ２が実行され、さらに、拠点間接続プロセスＢｒが実行されて呼制御プロセスＢ１、Ｂ２をつないでいる。これにより、クライアントＢに属する全ての通信端末４相互間の音声通信が実現される。
　図４に示すように、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。冗長化されたハードウェアである呼制御サーバ２１で実行される呼制御プロセスは、プロセス単位で冗長化の有無を設定することができる。ハードウェア資源やプロセスの重要度などに基づいて、各プロセスの冗長化の有無を決定すればよい。
　プロビジョニングサーバ２２は、通信端末４に図１２に示すようなプロビジョニングデータを送信するためのサーバである。通信端末４は、電源オン時にプロビジョニングサーバ２２にアクセスし、図１２に示すプロビジョニングデータを受信する。通信端末４は、受信したプロビジョニングデータで自身の動作をセットアップし、その通信端末４が所属するクライアントの呼制御プロセスにアクセスできるようになる。プロビジョニングについては、国際公開ＷＯ２０１７／０８６４１６号パンフレットに詳細に記載されている。
　呼制御サーバ２１－１およびプロビジョニングサーバ２２－１と呼制御サーバ２１－２およびプロビジョニングサーバ２２－２が、必ずしも同じ性能のものである必要はなく、設定可能なパーテーションの数も同数である必要はない。
　冗長化され呼制御サーバ２１－１、呼制御サーバ２１－２の両方で実行されている呼制御プロセスＡ，Ｂのうち、呼制御サーバ２１－１で実行されているプロセスが、稼働プロセスとして通信端末４相互間の音声通信を中継する呼制御処理を実際に行う。呼制御サーバ２１－２で実行されている各プロセスは、待機プロセスとして、対応する稼働プロセス（呼制御サーバ２１－１で実行されている同じプロセス）がダウンした場合に交替するべく待機している。各プロセスの動作モード（稼働プロセス／待機プロセス）は、管理サーバ２０の管理テーブル３１（図９参照）に記憶される。
　なお、プロビジョニングサーバ２２－１、プロビジョニングサーバ２２－２は、両方とも稼働モードに設定され、通信端末４からのプロビジョニング要求に応答する。
　図５は、通常運用時、すなわち、全てのプロセスが正常に実行されているときの各呼制御プロセスと通信端末４との接続関係を示している。各クライアントが所持する通信端末４には、第１通信キャリアのＳＩＭがセットされ、ＬＴＥネットワーク３－１を介してサーバシステム２にアクセスする通信端末４、および、第２通信キャリアのＳＩＭがセットされ、ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末４がある。通常運用時は、メインサーバである呼制御サーバ２１－１の呼制御プロセスＡ，Ｂ１，Ｂ２，Ｃが稼働して、呼制御処理を行っているため、通信端末４は全て呼制御サーバ２１－１のプロセスに接続される。呼制御サーバ２１－１はＬＴＥネットワーク３－１側に接続されているため、ＬＴＥネットワーク３－２に接続される通信端末４は、ＬＴＥネットワーク３－２からＶＰＮ６を経由して呼制御サーバ２１－１にアクセスする。なお、第１通信キャリアのＳＩＭおよび第２通信キャリアのＳＩＭの両方がセットされ、ＬＴＥネットワーク３－１、ＬＴＥネットワーク３－２のどうちらを介してでもサーバシステム２にアクセス可能なマルチキャリア通信端末４を設けてもよい。
　通常運用中に呼制御サーバ２１－１のいずれかのプロセスがダウンした場合、ダウンしたプロセスが、図６Ｂ，図６Ｃに示すような形態で、呼制御サーバ２１－２の待機プロセスに切り換えられる。図６では、クライアントＢの呼制御プロセスＢ（呼制御プロセスＢ１，Ｂ２および拠点間接続プロセスＢｒ）における稼働プロセスから待機プロセスへの切り換えについて説明する。
　図６ＡはクライアントＢの各プロセスが正常に実行されている場合の各プロセスおよび通信端末４の接続形態を示している。この接続形態は、図５に示したものと同じである。ここでは、呼制御プロセスＢ１－１，Ｂ２－１および拠点間接続プロセスＢｒ－１が稼働しており、通信端末４は、呼制御プロセスＢ１－１，Ｂ２－１にアクセスする。詳細には、通信端末４－１は、ＬＴＥネットワーク３－１を介して呼制御プロセスＢ１－１にアクセスし、通信端末４－３は、ＬＴＥネットワーク３－２およびＶＰＮ６を介して呼制御プロセスＢ１－１にアクセスする。通信端末４－２は、ＬＴＥネットワーク３－１を介して呼制御プロセスＢ２－１にアクセスし、通信端末４－４は、ＬＴＥネットワーク３－２およびＶＰＮ６を介して呼制御プロセスＢ２－１にアクセスする。
　図６Ｂは、呼制御プロセスＢ２－１がダウンした場合の接続形態を示している。稼働プロセスであった呼制御プロセスＢ２－１がダウンしたため、対応する待機プロセスである呼制御プロセスＢ２－２が稼働プロセスとなる。そうすると、通信端末４－２、４－４は、呼制御プロセスＢ２－１から呼制御プロセスＢ２－２にアクセス先を変更する。詳細には、通信端末４－２は、ＬＴＥネットワーク３－１およびＶＰＮ６を介して呼制御プロセスＢ２－２にアクセスし、通信端末４－４は、ＬＴＥネットワーク３－２を介して呼制御プロセスＢ２－２にアクセスする。また、拠点間接続プロセスＢｒ－１は、メインの呼制御プロセスＢ１－１とサブの呼制御プロセスＢ２－２とを接続するよう接続拠点を切り換える。
　図６Ｃは、拠点間接続プロセスＢｒ－１がダウンした場合の接続形態を示している。稼働プロセスであった拠点間接続プロセスＢｒ－１がダウンしたため、待機プロセスである拠点間接続プロセスＢｒ－２が稼働プロセスとなる。呼制御サーバ２１－１の呼制御プロセスＢ１－１、Ｂ２－１が正常に稼働しているため、拠点間接続プロセスＢｒ－２は、ＶＰＮ６を介して、呼制御サーバ２１－１の呼制御プロセスＢ１－１およびＢ２－１を接続する。なお、通常動作時と同様に呼制御プロセスＢ１－１およびＢ２－１は正常に稼働しているため、通信端末４－１～４のアクセス先に変更はない。
　このように、ハードウェアの呼制御サーバ２１－１、２１－２で複数のプロセス（仮想サーバ）が稼働しており、そのいずれかがダウンした場合、プロセス単位で呼制御サーバ２１－１のプロセスから呼制御サーバ２１－２のプロセスに切り換えられる。
　各プロセスは、自身が実行しているプロセスおよび対応する相手プロセスの状態を記憶するため、記憶部３１に図７に示すようなステータステーブルを有している。ステータステーブルは、自身が実行しているプロセスの名称、動作設定、動作モード（稼働モード／待機モード）、および、自身の動作通知有効期限、稼働中システムの動作通知有効期限の記憶エリアを有している。動作設定の欄には、メインプロセス（main）／サブプロセス（sub）／単独プロセス（alone）のいずれかの設定情報が記憶される。呼制御サーバ２１－１および呼制御サーバ２１－２で、同じプロセスが実行される場合、そのうちの一方がメインプロセスに設定され、他方がサブプロセスに設定される。一般的に、メインサーバである呼制御サーバ２１－１で実行されるプロセスがメインプロセスに設定され、サブサーバである呼制御サーバ２１－２で実行されるプロセスがサブプロセスに設定される。両プロセスが正常に動作しているときは、メインプロセスが実際の処理を実行する稼働モードになり、サブプロセスが待機モードになる。メインプロセスがダウンした場合、サブプロセスが稼働モードになる。動作モードの欄には、このプロセスの動作モードが稼働モードであるか、待機モードであるかが記憶される。
　呼制御プロセスＣは、呼制御サーバ２１－１のみで実行されているため、動作設定の欄には、単独プロセスが記憶される。
　各プロセスが管理サーバ２０および対応する待機プロセスに送信する動作通知は、自身が実行しているプロセスの名称、動作設定、動作モード、および、この動作通知の有効期限を含んでいる。
　図７Ａは、メインプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセスは、呼制御プロセスＢ２－１を実行しており、動作設定はメイン、動作モードは稼働モードである。動作通知有効期限は、自身が管理サーバ２０および相手のサブプロセスに対して送った動作通知の有効期限が記憶される。動作通知は、自身が管理サーバ２０および待機プロセスに対して、自身が正常に動作していることを通知するメッセージである。待機プロセスおよび管理サーバ２０は、この動作通知の有効期限が経過する前に新たな有効期限の動作通知が送られてくることで稼働プロセスが正常に動作していることを確認する。稼働プロセス動作通知有効期限は、自身が待機中の場合に、対応する稼働プロセスから受信した動作通知の有効期限が記憶される。図７Ａは、稼働プロセスのステータステーブルであるため、稼働プロセスから受信する稼働プロセス動作通知有効期限は空欄である。
　図７Ｂは、サブプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセスは、呼制御プロセスＢ２－２を実行しており、動作設定はサブプロセス、動作モードは待機モードである。動作通知有効期限は、自身が管理サーバ２０に対して送った動作通知の有効期限が記憶される。稼働システム動作通知有効期限には、対応する稼働プロセス（呼制御プロセスＢ２－１）から送られてきた動作通知の有効期限が記憶される。有効期限が経過する前に新たな有効期限の動作通知が送られてくると、その新たな有効期限でテーブルを更新し、待機モードを継続する。
　この有効期限を過ぎても稼働プロセスから動作通知が送られて来ない場合、同図右欄に示すように、このサブプロセスは、稼働プロセスであるメインプロセスがダウンしていると判断し、自身の動作モードを稼働モードに切り換えて、通信端末４の音声通信の中継を開始する。
　図８は呼制御サーバ２１で実行される呼制御プロセスの動作を示すフローチャートである。図８Ａは、稼働プロセスの動作通知処理を示している。稼働プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０－１、２０－２に対して動作通知を送信し（Ｓ１１）、且つ、対応する待機プロセスに対しても動作通知を送信する（Ｓ１２）。送信された動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。稼働プロセスは、この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ１３）。
　図８Ｂは、稼働プロセスおよび待機プロセスが実行する動作状況確認処理を示している。この処理も定期的に実行される。稼働プロセスには、他のプロセスと接続があるものがある。他のプロセスとの接続とは、例えば、図５、図６に示した呼制御プロセスＢ１と拠点間接続プロセスＢｒ、呼制御プロセスＢ２と拠点間接続プロセスＢｒがそれぞれ接続された状態である。プロセスがこのような形態で他のプロセスで接続されている場合、このプロセスは、他のプロセスの動作状況に合わせて自身の接続先を切り換える等の処理を行う。プロセスは、所定の時間ごとに管理サーバ２０に各プロセスの動作状況を問い合わせる（Ｓ１６）。この問い合わせに応答して管理サーバ２０から各プロセスの動作状況が返信されてくると（Ｓ１７）、プロセスは、接続先のプロセスがダウンして待機プロセスが稼働プロセスに切り換わっているなど、接続先の動作状況に変更があるかを判断する（Ｓ１８）。接続先の動作状況に変更があった場合には（Ｓ１８でＹＥＳ）、プロセスは、現在の動作状況に合わせて接続先を切り換えて（Ｓ１９）、処理を終了する。他のプロセスと接続がない場合、または、接続先の変更がない場合（Ｓ１８でＮＯ）には、プロセスは、動作状況確認処理を終了する。
 
　例えば、図６Ｂのように、呼制御プロセスＢ２－１がダウンした場合、拠点間接続プロセスＢｒ－１は、管理サーバ２０－１に動作状況を問い合わせたときに、呼制御プロセスＢ２－１がダウンしていること、および、その待機プロセスであった呼制御プロセスＢ２－２が稼働を開始していることを知る。そこで、呼制御プロセスＢ２－２に対するプロセス間通信を開始することにより、呼制御プロセスＢの稼働を維持する。
　図８Ｂにおける管理サーバ２０への問い合わせは、同じ側の管理サーバ２０、すなわち、このプロセスが実行されている呼制御サーバ２１と同じサーバシステム２－１、２－２内に設置されている管理サーバ２０に対して行われる。問い合わせに対して、この管理サーバ２０が応答しなかった場合、プロセスは、反対側の管理サーバ２０に再度問い合わせる。反対側の管理サーバ２０とは、このプロセスが実行されている呼制御サーバ２１と異なるサーバシステム２－１、２－２内に設置されている管理サーバ２０である。
　管理サーバ２０への問い合わせは、一定時間毎に行ってもよいが、プロセス間通信の変更や待機プロセスの動作モードの切り換え（図８Ｄ参照）が発生するごとに管理サーバ２０に対して各プロセスの動作状況（通信相手）を問い合わせるようにしてもよい。
　図８Ｃは、待機プロセスの動作通知処理を示している。待機プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０－１、２０－２に対して動作通知を送信する（Ｓ２１）。送信した動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ２２）。
　図８Ｄは、待機プロセスの動作状況確認処理を示している。この処理も定期的に実行される。待機プロセスは、ステータステーブルを参照して稼働プロセスの動作通知が有効であるかを判断する（Ｓ２４）。稼働プロセスからの動作通知の有効期限が切れている場合（Ｓ２４でＮＯ）、待機プロセスは、稼働プロセスがダウンしていると判断する。待機プロセスは、図８Ｂの処理で取得していた各プロセスの動作状況に合わせて接続先等を設定して、ダウンした稼働プロセス（メインプロセス）に代わって自身を稼働プロセスとして動作を開始する（Ｓ２５）。新たな稼働プロセスは、ステータステーブルの動作モードを稼働モードに書き換える（Ｓ２６）。例えば、図６Ｃのように、拠点間接続プロセスＢｒ－１がダウンした場合、拠点間接続プロセスＢｒ－２が、稼働している呼制御プロセスＢ１－１、Ｂ２－１とプロセス間通信を行う稼働を開始する。
　新たな稼働プロセスは、稼働プロセスとして動作を開始したのち、管理サーバ２０に対して、動作モードを変更した旨を通知する（Ｓ２７）。この動作モード変更通知は、動作通知を兼ねている。一方、Ｓ２４において、稼働プロセスが正常に動作している場合、すなわち、動作通知の有効期限が切れていない場合（Ｓ２４でＹＥＳ）、待機プロセスは、動作状況確認処理を終了する。
　図９は、管理サーバ２０に設定される管理テーブル３１の例を示す図である。図９には、管理テーブル３１のうち、呼制御サーバ２１－１、２１－２のプロセスに関する部分のみ記載する。プロビジョニングサーバ２２－１、２２－２の各プロセスについても同様のテーブルが設けられている。
　管理テーブル３１には、メインサーバである（第一）呼制御サーバ２１－１、および、サブサーバである（第二）呼制御サーバ２１－２で実行される全てのプロセスの情報が記憶されている。管理テーブル３１には、プロセスごとに、動作通知有効期限、動作設定、動作モードが記憶される。動作通知有効期限の欄には、プロセスから送られてきた動作通知に記載されていた有効期限が記憶される。管理サーバ２０が、この有効期限以内にプロセスから新たな動作通知を受信した場合、この有効期限は、その新たな動作通知に記載されている有効期限に更新される。動作設定の欄には、メインプロセス／サブプロセスのいずれかの設定情報が記憶される。動作モードの欄には、稼働モード／待機モードのいずれかが記憶される。
　各プロセスから、動作通知有効期限内に新たな動作通知が送られてこなかった場合には、そのプロセスがダウンしている（動作通知を送信する機能が失われている）として、管理サーバ２０は、動作モードをダウンに書き換える。正常に動作しているプロセスから定期的に全プロセスの動作状況の問い合わせがあるため、管理サーバ２０は、この問い合わせに応答して、正常に稼働しているプロセス、正常に待機しているプロセス、および、ダウンしているプロセス等の情報を返信する。各プロセスは、この動作状況に応じて接続先の切り換えなどを行う。また、管理サーバ２０は、稼働プロセスのダウンに対応して稼働を開始したプロセスから、稼働を開始した旨の通知を受信した場合、管理テーブル３１のこのプロセスの動作モードを稼働モードに書き換える。
　なお、管理テーブル３１に、プロセス間通信を行うプロセス（例えば呼制御プロセスＢ１－１、Ｂ１－２、Ｂｒ－１など）について、通信相手である接続先プロセスを記憶するエリアを設けてもよい。
　図１０は管理サーバ２０の動作を表すフローチャートである。図１０Ａは、有効期限更新動作を示すフローチャートである。いずれかのプロセスから動作通知を受信すると（Ｓ３１）、管理テーブル３１のそのプロセスの動作通知有効期限を更新する（Ｓ３２）。なお、プロセスが起動し、初めて動作通知を送信した場合、管理サーバ２０は、このプロセスを管理テーブル３１に登録して動作通知有効期限を書き込む。
　図１０Ｂは、プロセスから稼働開始通知を受信した場合の動作を示すフローチャートである。待機プロセスから（ダウンした稼働プロセスに代わって）稼働を開始した旨の通知を受信すると（Ｓ３５：図８ＤのＳ２７参照）、管理サーバ２０は、管理テーブル３１のそのプロセスの動作モードを稼働モードに変更する（Ｓ３６）。この稼働開始通知は動作通知を兼ねているので、管理サーバ２０は、このプロセスの動作通知有効期限を更新する（Ｓ３７）。管理サーバ２０は、稼働プロセスが変更になった旨をシステム管理者の端末（パーソナルコンピュータ）に対してメール等でアラートを送信する（Ｓ３８）。
　図１０Ｃは、テーブルメンテナンス動作を示すフローチャートである。定期的に管理テーブル３１に記憶されている全てのプロセスについて以下の処理が実行される。管理サーバ２０は、プロセスの動作通知の有効期限を読み出す（Ｓ４１）。この有効期限を現在時刻と比較し、有効期限切れになっている場合には（Ｓ４２でＹＥＳ）、管理サーバ２０は、動作モードをダウンに書き換える（Ｓ４４）。管理サーバ２０は、この動作を管理テーブル３１に記憶されている全てのプロセスについて実行する。なお、Ｓ４４において、ダウン状態が継続していて既に動作モードがダウンに書き換えられている場合でも、動作モードのダウンへの書き換えが行われるが、既にダウンモードの場合は書き換えないようにしてもよい。
　動作通知の有効期限が切れていなければ（Ｓ４２でＮＯ）、管理サーバ２０は、現在の動作モードがダウンであるかを判断する（Ｓ４５）。動作モードがダウンである場合には（Ｓ４５でＹＥＳ）、管理サーバ２０は、動作モードを待機モードに書き換える（Ｓ４６）。動作通知の有効期限が切れておらず（Ｓ４２でＮＯ）且つ動作モードがダウンでない場合には（Ｓ４５でＮＯ）、管理サーバ２０は、このプロセスに対するメンテナンス処理を終了する。管理サーバ２０は、Ｓ４１－Ｓ４６のメンテナンス処理を管理テーブル３１に記憶されている全てのプロセスについて順次実行する。
　Ｓ４６に示すように、一度ダウンしたプロセスが復旧した場合、このプロセスは、現在稼働中のプロセスのダウンに備えた待機プロセスとして動作する。動作設定がメインプロセスとされているプロセスが復旧した場合には、このメインプロセスが稼働プロセスに復帰し、そのときまで稼働プロセスとして動作していたサブプロセスが待機モードに切り換わってもよい。
　図１１Ａは、クライアントＢの呼制御プロセスが、図６Ｂの状態になった場合の管理テーブル３１の記憶内容を示す図である。図１１Ｂは、クライアントＢの呼制御プロセスが、図６Ｃの状態になった場合の管理テーブル３１の記憶内容を示す図である。この図では、各プロセスの動作モードの欄のみを表示している。図６Ｂの状態では、呼制御プロセスＢ２－１がダウンし、これに代えて呼制御プロセスＢ２－２が稼働している。この場合、図１１Ａに示す管理テーブル３１においても、呼制御プロセスＢ２－１の動作モードがダウンに書き換えられ、これに代えて呼制御プロセスＢ２－２の動作モードが稼働モードになっている。
　図６Ｃの状態では、呼制御サーバ２１－１の拠点間接続プロセスＢｒ－１がダウンし、これに代えて呼制御サーバ２１－２の拠点間接続プロセスＢｒ－２が稼働している。この場合、図１１Ｂに示す管理テーブル３１においても、拠点間接続プロセスＢｒ－１の動作モードがダウンに書き換えられ、これに代えて拠点間接続プロセスＢｒ－２の動作モードが稼働モードになっている。
　このように、管理サーバ２０は、各プロセスの動作モードの変更に対応して管理テーブル３１を更新し、他のプロセスや通信端末４からの問い合わせに対しては、このテーブルの内容を送信する。これにより、プロセスが他のプロセスの状態を知ることができるようになり、プロセス間通信の接続先を変更することや、通信端末４が、アクセスする呼制御プロセスを変更することが容易になる。
　管理サーバ２０は、ウェブサーバとしても機能する。管理テーブル３１の内容やその更新履歴等をＬＡＮ５またはＬＴＥネットワーク３経由で管理者のパーソナルコンピュータに映すことができる。
　図１０Ｄは、管理サーバ２０のプロセスからの問い合わせに対応する処理を示すフローチャートである。プロセスから動作状況の問い合わせがあると（Ｓ５０：図８ＢのＳ１６、図８ＤのＳ２５参照）、管理サーバ２０は、問い合わせのあったプロセスに対して、各プロセスの動作状況（管理テーブル３１の内容）を送信する（Ｓ５１）。これにより、プロセスは他のプロセスの動作状況を知ることができる。
　図１０Ｅは、管理サーバ２０の通信端末４からの問い合わせに対応する処理を示すフローチャートである。通信端末４から稼働中の呼制御プロセスの問い合わせがあると（Ｓ５４）、管理サーバ２０は、その通信端末４が所属するクライアントの呼制御プロセスのうち稼働している側の呼制御プロセスを通知する（Ｓ５５）。これにより、稼働していた呼制御プロセスがダウンして稼働中呼制御プロセスが切り換わった場合、通信端末４がその切り換わった呼制御プロセスにアクセスすることが可能になる。
　図１２は、通信端末４のメモリに記憶されるプロビジョニングデータ４１の一例を示す図である。プロビジョニングデータ４１は、メインプロビジョニングサーバアドレス、サブプロビジョニングサーバアドレス、メイン呼制御サーバアドレス、サブ呼制御サーバアドレス、および、各種設定情報を含んでいる。
　メインプロビジョニングサーバアドレスは、プロビジョニングサーバ２２－１のＩＰアドレスおよびポート番号を含んでいる。サブプロビジョニングサーバアドレスは、プロビジョニングサーバ２２－２のＩＰアドレスおよびポート番号を含んでいる。これらのアドレスは、プロビジョニングサーバ２２から与えられてもよく、事前に通信端末４に記憶されていてもよい。
　メイン呼制御サーバアドレスは、呼制御サーバ２１－１のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。サブ呼制御サーバアドレスは、プロビジョニングサーバ２２－２のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。メインプロビジョニングサーバアドレス／サブプロビジョニングサーバアドレス、および、メイン呼制御サーバアドレス／サブ呼制御サーバアドレスには、どのアドレスのプロセスが稼働中であるかを示す稼働中フラグが設けられている。デフォルトでは、メインプロビジョニングサーバアドレスおよびメイン呼制御サーバアドレスの稼働中フラグがセットされる。
　各種設定情報は、たとえば、通信端末４の呼出ＩＤ、通知音設定（着信時の通知音の選択情報）、イヤホン設定（イヤホンマイクが接続された場合にフル・デュプレックス通信を行うか否かの設定情報）、アドレス帳（呼出可能な通信端末４の呼出ＩＤリスト）、音量設定（通話音の音量設定情報）などである。
　図１３Ａ－Ｃは、通信端末４の動作を示すフローチャートである。図１３Ａは、プロビジョニング動作を示すフローチャートである。この動作は通信端末４の電源オン時などに実行される。通信端末４の制御部４０が、メインサーバであるプロビジョニングサーバ２２－１にアクセスして、プロビジョニングデータの送信を要求する（Ｓ６１）。一定時間以内にプロビジョニングサーバ２２－１から応答があった場合には（Ｓ６２でＹＥＳ）、通信端末４は、このサーバからプロビジョニングデータを受信して（Ｓ６５）、プロビジョニングを実行する（Ｓ６６）。一定時間以内にプロビジョニングサーバ２２－１から応答がなかった場合（Ｓ６２でＮＯ）、通信端末４は、サブサーバであるプロビジョニングサーバ２２－２にアクセスして、プロビジョニングデータの送信を要求し（Ｓ６３）、稼働中フラグをサブプロビジョニングサーバ２２－２側に切り換える（Ｓ６４）。そして、通信端末４は、サブプロビジョニングサーバ２２－２からプロビジョニングデータを受信する（Ｓ６５）。２つのプロビジョニングサーバ２２－１、２２－２が同時にダウンした場合、通信端末４は、以前に取得したプロビジョニングデータを用いて接続を試みるようにすればよい。
　図１３Ｂは、通信端末４の音声通信時の動作を示すフローチャートである。ＰＴＴスイッチ２２０が押されるとこの動作が開始される。通信端末４の制御部４０が、メインの呼制御サーバ２１－１のこの通信端末４に割り当てられた呼制御プロセス（仮想サーバ）に音声信号を送信する（Ｓ７１）。一定時間以内に呼制御サーバ２１－１のプロセスから応答があった場合には（Ｓ７２でＹＥＳ）、通信端末４は音声通信を開始する。一定時間以内に呼制御サーバ２１－１のプロセスから応答がなかった場合には（Ｓ７２でＮＯ）、通信端末４は、通信不可である旨の表示を行う等して動作を停止する。この通信ダウンの状態は、それまで稼働していた呼制御プロセスがダウンしたのち、図１３Ｃの稼働プロセス確認前に通信が開始された場合に発生し得る状態である。
　図１３Ｃは、通信端末４が、稼働している呼制御プロセスを問い合わせる動作を示すフローチャートである。この処理は定期的に行われるが、図１３ＢのＳ７２で稼働中としていた呼制御プロセスから応答がなかったときに臨時に実行されるようにしてもよい。通信端末４の制御部４０は、管理サーバ２０に、この通信端末４を収容している稼働中の呼制御プロセスを問い合わせる（Ｓ７３）。これに応答して管理サーバ２０から稼働プロセスの情報が送られてくる。通信端末４は、この情報を受信し（Ｓ７４：図１０ＥのＳ５５参照）、稼働プロセスが切り換えられたかを判断する（Ｓ７５）。切り換えられた場合（Ｓ７５でＹＥＳ）、通信端末４は、呼制御サーバの稼働中フラグを稼働プロセス側（サブ呼制御サーバ側）に切り換える（Ｓ７６）。これ以後、通信端末４は、音声通信が発生した場合に、稼働プロセスに切り換わった呼制御プロセスに対してアクセスする。
　通信端末４は、運用開始時および定期的に、さらにはエリア移動などの機会ごとに、稼働モードの呼制御サーバ２１に対して、登録を要求するメッセージ（レジストメッセージ）を送信する。稼働モードの呼制御サーバ２１は、このメッセージを受信することにより、運用中の通信端末を把握し、この通信端末４を端末テーブルに登録することができる。通信端末４は、このレジストメッセージを稼働モードとされる呼制御サーバ２１－１／２に送信しても応答がない場合、この呼制御サーバ２１－１／２はダウンしているとして、反対側の呼制御サーバ２１－２／１に、改めてレジストメッセージを送信する。
　図１０、図１３に示すフローチャートでは、通信端末４は、定期的に管理サーバ２０に対して、稼働モードの呼制御プロセスを問い合わせているが、上記のレジストメッセージに対する応答の有無によって稼働モードの呼制御プロセスがどちらであるかを解決してもよい。
　待機モードで動作している呼制御プロセスが、通信端末からレジストメッセージを受信した場合、レジストメッセージの送信先を反対側の（稼働モードの）呼制御プロセスに切り換えて再送信すべき旨の応答を通信端末に返信するようにしてもよい。
　レジストメッセージに対する応答の有無で稼働モードの呼制御サーバ２１を判断するようにすれば、通信端末４の台数が多い場合でも、管理サーバ２０に対する問い合わせが頻発することがなくなり、管理サーバ２０の負荷を軽減することができる。ただし、一般的にレジストの間隔は、図１３Ｃ等に示した問い合わせの間隔よりも長いため、通信端末４が稼働モードの呼制御プロセスの交代を知るまでの時間が長くなる。
　以上は、呼制御サーバ２１－１、２１－２のプロセスがダウンした場合の呼制御動作の切り換えについて説明した。プロセスがダウンしていない場合でも、サーバシステム２－１とサーバシステム２－２とをつなぐＶＰＮ６がダウンする場合がある。図１４、図１５を参照して、ＶＰＮ６がダウンした場合の縮退動作について説明する。
　図１４は、クライアントＢの呼制御プロセスにおいて、ＶＰＮ６がダウンした場合のプロセス間の接続形態を示している。管理サーバ２０－１、２０－２、呼制御サーバ２１－１、２１－２、プロビジョニングサーバ２２－１、２２－２は正常に動作しており、呼制御プロセスＢ１－１、Ｂ２－１、Ｂ１－２、Ｂ２－２、および、拠点間接続プロセスＢｒ－１、Ｂｒ－２もそれぞれ正常に動作している。
　ＶＰＮ６がダウンすると、サーバシステム２－１、２－２間の通信が不可能になる。この場合でも、サーバシステム２－１の管理サーバ２０－１、呼制御サーバ２１－１、プロビジョニングサーバ２２－１は正常に動作しているため、ＬＴＥネットワーク３－１を介してサーバシステム２－１にアクセスする通信端末４（４－１、４－２）に対して呼制御プロセスＢなどのサービスを継続することが可能である。
　一方、サーバシステム２－２においても、管理サーバ２０－２、呼制御サーバ２１－２、プロビジョニングサーバ２２－２は正常に動作しており、且つ、サーバシステム２－１の各プロセスからの動作通知が届かなくなる。管理サーバ２０－２および呼制御サーバ２１－２、プロビジョニングサーバ２２－２の各プロセスは、サーバシステム２－１側の各プロセスが全てダウンしたと判断し、呼制御サーバ２１－２、プロビジョニングサーバ２２－２の各プロセスは、待機モードから稼働モードに切り換わってクライアントＢに対する呼制御プロセスを稼働させる。そして、呼制御サーバ２１－２で立ち上げられた呼制御プロセスは、ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末４（４－３、４－４）に対してサービスを提供する。
　このように、ＶＰＮ６がダウンすると、ＬＴＥネットワーク３－１、３－２をつなぐ通信は不可能になるが、各ＬＴＥネットワーク３－１、３－２で呼制御プロセスＢが稼働モードとなり、それぞれの範囲でサービスを提供できるようになる。
　このとき、サーバシステム２－１内の管理サーバ２０－１の管理テーブル３１は、図１５Ａに示すように、呼制御サーバ２１－１の各プロセスが全て稼働モードになっており、呼制御サーバ２１－２の各プロセスの動作モードが全てダウンになっている。一方、サーバシステム２－２内の管理サーバ２０－２の管理テーブル３１は、図１５Ｂに示すように、呼制御サーバ２１－１の各プロセスの動作モードが全てダウンになっており、呼制御サーバ２１－２の各プロセスが全て稼働モードになっている。呼制御プロセスＣは、冗長化されておらず、呼制御サーバ２１－１のみで実行される。このため、ＶＰＮ６がダウンした場合、ＬＴＥネットワーク３－２のエリアにクライアントＣの通信端末４があった場合には、この通信端末４は通信することができなくなる。
　この縮退動作は、ＶＰＮ６のダウンによって相手側プロセスからの動作通知が途絶えたことに対応する動作として、図８に示した呼制御サーバ２１－１、２１－２の各プロセスの動作、および、図１０に示した管理サーバ２０－１、２０－２の動作によって実現可能である。
　この実施形態では、呼制御サーバ２１－１をメインサーバ、呼制御サーバ２１－２をサブサーバとして、呼制御サーバ２１－１で実行される各プロセスをメインプロセスとして動作設定しているが、メインプロセスとして動作設定されるプロセスを呼制御サーバ２１－１、２１－２に分散させてもよい。
　以上の実施形態では、サーバシステム２、ネットワーク３がそれぞれ２つずつ設けられている構成について説明したが、第３、第４、・・・のサーバシステム、ネットワークを有する構成であってもよい。そのようにすることにより、さらなる冗長化が可能になる。
　以上のように、この実施形態によれば、障害を起こしてダウンしたプロセスがあっても、このダウンしたプロセスのためにサーバ全体を交代させる必要がないため、他のプロセスに対する影響を最小限にすることができる。また、専用の管理サーバ２０を設置して各プロセスの動作状況を管理および問い合わせに答えることができるようにしたことにより、プロセスに障害が発生してもその障害を他のプロセスが知り、プロセス間の通信先を切り換えるなどの対応が可能になり、プロセス間通信を維持することができるようになる。
１　音声通信システム
２（２－１、２－２）　サーバシステム
２０（２０－１、２０－２）　管理サーバ
２１（２１－１、２１－２）　呼制御サーバ
２２（２２－１、２２－２）　プロビジョニングサーバ
３（３－１、３－２）　ＬＴＥネットワーク
４（４－１～４）　通信端末

Claims (7)

  1. 　通信ネットワーク上に設置された第１サーバおよび第２サーバを備えたシステムであって、
    　前記第１サーバは複数のプロセスを実行し、前記第２サーバは、前記第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行し、
    　前記第１サーバおよび前記第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し、他方のプロセスが、前記稼働モードのプロセスがダウンしたとき、該ダウンしたプロセスに代わって稼働モードとなる待機モードで動作し、
    　稼働モードのプロセスである稼働プロセスは、待機モードのプロセスである待機プロセスに対して、自身が正常に動作していることを通知するメッセージである動作通知を定期的に送信し、
    　前記待機プロセスは、前記稼働プロセスから定期的に動作通知を受信している間、待機モードを継続し、
    　前記待機プロセスは、前記稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、前記サービスの提供を開始する
    　サーバシステム。
  2. 　前記通信ネットワークは、第１ネットワークおよび第２ネットワークを有し、
    　前記第１サーバは、前記第１ネットワーク上に設けられ、前記第２サーバは、前記第２ネットワーク上に設けられ、
    　前記第１サーバと第２サーバとは、前記通信ネットワークとは別の通信線で接続されている
    　請求項１に記載のサーバシステム。
  3. 　前記通信ネットワーク上に、各プロセスの動作状況を記憶する管理テーブルを備えた管理サーバをさらに設け、
    　各プロセスは、前記管理サーバに対して、定期的に前記動作通知を送信し、
    　各プロセスは、自身の動作モードが待機モードから稼働モードに切り換わったとき、その旨を通知するメッセージであるモード切換通知を前記管理サーバに送信し、
    　前記管理サーバは、前記動作通知および前記モード切換通知によって取得した各プロセスの動作状況を前記管理テーブルに記憶し、
    　前記複数のプロセスのうちの所定の第１プロセスおよび第２プロセスは相互にプロセス間通信を実行し、且つ、前記第２プロセスは、前記第１サーバおよび前記第２サーバで並行して実行されており、
    　前記第１プロセスは、前記管理サーバに各プロセスの動作状況を問い合わせ、
    　前記管理サーバは、前記問い合わせに応じて前記各プロセスの動作状況を、前記第１プロセスに対して送信し、
    　前記第１プロセスは、受信した各プロセスの動作状況に基づいて、前記並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定して、該稼働している第２プロセスを前記プロセス間通信の通信相手とする
    　請求項１に記載のサーバシステム。
  4. 　前記通信ネットワークは、異なるセグメントの第１ネットワークおよび第２ネットワークを有し、
    　前記第１サーバは前記第１ネットワーク上に設けられ、前記第２サーバは前記第２ネットワーク上に設けられ、
    　前記管理サーバは、前記第１ネットワーク上に設けられた第１管理サーバ、および、前記第２ネットワーク上に設けられた第２管理サーバを有し、
    　前記第１サーバ、第１管理サーバと、第２サーバ、第２管理サーバとの間は、前記ネットワークとは別の通信線で接続されており、
    　各プロセスは、前記動作通知およびモード切換通知を、前記第１管理サーバおよび第２管理サーバの両方に送信し、
    　前記第１プロセスは、自身と同じ側のネットワーク上にある管理サーバに各プロセスの動作状況を問い合わせる
    　請求項３に記載のサーバシステム。
  5. 　前記第１サーバおよび第２サーバで実行されるプロセスは、複数の通信端末から送信された音声信号を中継する呼制御プロセスであり、
    　前記複数の通信端末は、前記第１ネットワーク、第２ネットワークのいずれかを介して前記第１サーバまたは第２サーバにアクセスする
    　請求項２または請求項４に記載のサーバシステム。
  6. 　通信ネットワーク上に設置された第１サーバが、複数のプロセスを実行し、
    　前記通信ネットワーク上に設置された第２サーバが、前記第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行し、
    　前記第１サーバおよび前記第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し、他方のプロセスが、前記稼働モードのプロセスがダウンしたとき、該ダウンしたプロセスに代わって稼働モードとなる待機モードで動作し、
    　稼働モードのプロセスである稼働プロセスは、待機モードのプロセスである待機プロセスに対して、自身が正常に動作していることを通知するメッセージである動作通知を定期的に送信し、
    　前記待機プロセスは、前記稼働プロセスから定期的に動作通知を受信している間、待機モードを継続し、
    　前記待機プロセスは、前記稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、前記サービスの提供を開始する
    　プロセスの冗長化方法。
  7. 　各プロセスは、前記通信ネットワーク上に設けられた管理サーバに対して、定期的に前記動作通知を送信し、
    　各プロセスは、自身の動作モードが待機モードから稼働モードに切り換わったとき、その旨を通知するメッセージであるモード切換通知を前記管理サーバに送信し、
    　前記管理サーバは、前記動作通知および前記モード切換通知によって取得した各プロセスの動作状況を管理テーブルに記憶し、
    　前記第１サーバおよび前記第２サーバで並行して実行されているプロセスである第２プロセスとのプロセス間通信を実行する第１プロセスが、前記管理サーバに各プロセスの動作状況を問い合わせ、取得した各プロセスの動作状況に基づいて、前記並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定して、該稼働している第２プロセスを前記プロセス間通信の通信相手とする
    　請求項６に記載のプロセスの冗長化方法。
     
PCT/JP2020/002323 2019-03-15 2020-01-23 サーバシステムおよびプロセスの冗長化方法 WO2020189002A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080018456.4A CN113557695B (zh) 2019-03-15 2020-01-23 服务器***以及进程的冗余化方法
US17/438,450 US20220166806A1 (en) 2019-03-15 2020-01-23 Server system and redundancy method for processes
EP20774807.0A EP3941001A4 (en) 2019-03-15 2020-01-23 SERVER SYSTEM AND REDUNDANCY METHOD FOR PROCESSES

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019048649A JP7421052B2 (ja) 2019-03-15 2019-03-15 サーバシステムおよびプロセスの冗長化方法
JP2019-048649 2019-03-15

Publications (1)

Publication Number Publication Date
WO2020189002A1 true WO2020189002A1 (ja) 2020-09-24

Family

ID=72432100

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/002323 WO2020189002A1 (ja) 2019-03-15 2020-01-23 サーバシステムおよびプロセスの冗長化方法

Country Status (5)

Country Link
US (1) US20220166806A1 (ja)
EP (1) EP3941001A4 (ja)
JP (1) JP7421052B2 (ja)
CN (1) CN113557695B (ja)
WO (1) WO2020189002A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006172050A (ja) * 2004-12-15 2006-06-29 Yaskawa Information Systems Co Ltd ホットスタンバイ式２重化システム
JP2013077983A (ja) 2011-09-30 2013-04-25 Fujitsu Telecom Networks Ltd サーバ冗長化システム、仮想ルータおよびサーバ
JP2017027110A (ja) * 2015-07-15 2017-02-02 富士通株式会社 情報処理装置、優先度算出プログラムおよびデータセンタシステム
WO2017086416A1 (ja) 2015-11-18 2017-05-26 アイコム株式会社 データ設定システム、データ更新システムおよびデータ設定方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09190399A (ja) * 1996-01-09 1997-07-22 Nippon Telegr & Teleph Corp <Ntt> 統合ワークフロー管理方法及びシステム
US5978933A (en) * 1996-01-11 1999-11-02 Hewlett-Packard Company Generic fault tolerant platform
US5852724A (en) * 1996-06-18 1998-12-22 Veritas Software Corp. System and method for "N" primary servers to fail over to "1" secondary server
US5974114A (en) * 1997-09-25 1999-10-26 At&T Corp Method and apparatus for fault tolerant call processing
KR100411978B1 (ko) * 2001-01-22 2003-12-24 (주) 로커스네트웍스 내 고장성 시스템 및 이중화 방법
US7912075B1 (en) * 2006-05-26 2011-03-22 Avaya Inc. Mechanisms and algorithms for arbitrating between and synchronizing state of duplicated media processing components
JP4625473B2 (ja) * 2007-01-15 2011-02-02 株式会社日立製作所 冗長切り替え方法
US8700760B2 (en) * 2008-08-18 2014-04-15 Ge Fanuc Intelligent Platforms, Inc. Method and systems for redundant server automatic failover
JP5509564B2 (ja) 2008-09-30 2014-06-04 富士通株式会社 メッセージ送信方法及びプログラム
CN101610188A (zh) * 2009-07-30 2009-12-23 迈普通信技术股份有限公司 Sip服务器服务进程故障恢复方法及sip服务器
US20110075654A1 (en) * 2009-09-29 2011-03-31 Sonus Networks, Inc. Method and System for Implementing Redundancy at Signaling Gateway Using Dynamic SIGTRAN Architecture
JP5880010B2 (ja) * 2011-12-20 2016-03-08 株式会社バッファロー 通信システム、ネットワークストレージ、サーバ装置及びプログラム
JP5798056B2 (ja) * 2012-02-06 2015-10-21 日本電信電話株式会社 呼処理情報の冗長化制御システムおよびこれに利用する予備保守サーバ
CN103931139B (zh) * 2013-03-19 2017-02-15 华为技术有限公司 一种冗余保护方法、装置、设备及***
CN103384212A (zh) * 2013-07-24 2013-11-06 佳都新太科技股份有限公司 一种通信应用***双机高可用方案及其实现
JP6317974B2 (ja) * 2014-03-28 2018-04-25 アズビル株式会社 データ収集システム
CN105357057B (zh) * 2015-12-06 2019-03-08 浙江宇视科技有限公司 一种无中心的监控管理节点异地冗余方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006172050A (ja) * 2004-12-15 2006-06-29 Yaskawa Information Systems Co Ltd ホットスタンバイ式２重化システム
JP2013077983A (ja) 2011-09-30 2013-04-25 Fujitsu Telecom Networks Ltd サーバ冗長化システム、仮想ルータおよびサーバ
JP2017027110A (ja) * 2015-07-15 2017-02-02 富士通株式会社 情報処理装置、優先度算出プログラムおよびデータセンタシステム
WO2017086416A1 (ja) 2015-11-18 2017-05-26 アイコム株式会社 データ設定システム、データ更新システムおよびデータ設定方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3941001A4

Also Published As

Publication number Publication date
CN113557695B (zh) 2023-10-27
US20220166806A1 (en) 2022-05-26
JP2020149580A (ja) 2020-09-17
CN113557695A (zh) 2021-10-26
EP3941001A1 (en) 2022-01-19
EP3941001A4 (en) 2022-12-14
JP7421052B2 (ja) 2024-01-24

Similar Documents

Publication Publication Date Title
US20190306114A1 (en) Systems and methods for dynamically registering endpoints in a network
US10027531B1 (en) Failover system and method for IP telephony
US5572528A (en) Mobile networking method and apparatus
JP3883452B2 (ja) 通信システム
JP4236032B2 (ja) インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ
CN101316236B (zh) Vrrp备份组负载分担方法及路由器
CA2778567C (en) Providing resilient digital telephony services for wireless devices
CN103716281B (zh) 控制方法、电子设备和服务器
EP2077024B1 (en) Communication system
WO2002015030A1 (en) Distributed multimedia software-based call center
WO2020189003A1 (ja) 音声通信システムおよび呼制御サーバの冗長化方法
CN108075971A (zh) 一种主备切换方法及装置
WO2020189002A1 (ja) サーバシステムおよびプロセスの冗長化方法
US6931103B1 (en) Failover mechanisms for remote networked phones
JPH1155326A (ja) 移動ｉｐ通信システム、移動ｉｐ通信方法、ルータ、端末管理サーバ
JP2001257726A (ja) 情報通信システム
US8023407B2 (en) Redundancy in a communication network
JP2017017465A (ja) アドレス変換システム、アドレス変換の二重化方法及びプログラム
US20050207366A1 (en) Method of sending a paging announcement over a roaming telephone network
JPH1049457A (ja) 宛先切替可能なネットワークシステム、宛先切替方法お よび宛先切替用プログラムを記憶した記憶媒体
JP2018036953A (ja) 通信システム、通信方法、メディア中継サーバおよびメディア中継プログラム
JP2004297672A (ja) 交換機、遠隔回線終端装置および遠隔制御方法
KR20170122637A (ko) Vrrp 라우터 및 그의 제어 방법
CA2581202A1 (en) Information distribution system, method and network devices
JPH06334689A (ja) バックアップ回線切替方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20774807

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2020774807

Country of ref document: EP