JP6212972B2 - Information processing system, software update method, and program - Google Patents

Description

  The present invention relates to software update, and more particularly to an information processing system, software update method, and program for performing software update.

  Conventionally, RIP processing is executed in parallel on a plurality of computing nodes (including a processor and a memory), and printing is performed at high speed from a printer based on the processing results processed in parallel. The system is known. As such a printing system, a master-slave system configured to include a master node that performs overall control of a plurality of slave nodes and each slave node that executes various processes in response to instructions from the master node Things are known.

  In recent years, software such as application programs and firmware has become complicated with the demand for multi-functionality of software and devices, and software updates such as defect correction and addition of new functions are frequently performed (Patent Document 1). : Japanese Patent No. 5080318). Even in a printing system that performs parallel processing as described above, software such as firmware is updated. In such a case, it is necessary to appropriately apply the update to a plurality of nodes while maintaining consistency.

  Conventionally, various techniques are known for software update of an information processing system. For example, Japanese Patent No. 4054802 (Patent Document 2) discloses a program update method in an information processing system having a multi-CPU configuration. In the prior art of Patent Document 2, the data processing device receives program update data, decodes and authenticates the header of the received program update data, identifies the CPU to which the program is supplied, and identifies the specified CPU To provide the encrypted program. The controller CPU takes the lead in providing the program update file to each sub CPU and instructing to start the program update. A CPU number for identifying each sub CPU is statically set in advance for the controller CPU as a setting at the time of activation.

  However, in the above-described conventional technology, the system is resumed after completion of the program update of all the sub CPUs. In other words, since the restart of the system is based on the premise that all the sub CPUs have been updated, if any sub CPU fails during the program update, the system cannot be recovered automatically and the system cannot be restarted. It was not enough. In this case, the restart of the system is delayed until the administrator manually replaces the sub CPU in which an unrecoverable failure has occurred.

  The present invention has been made in view of the insufficiency in the above-described prior art, and the present invention provides an information processing system including a plurality of arithmetic processing devices while updating software for the plurality of arithmetic processing devices. An object of the present invention is to provide an information processing system, a software update method, and a program capable of restarting the system by excluding an arithmetic processing device that is not restored even if a failure occurs in any of the arithmetic processing devices.

  In order to solve the above-described problem, the present invention provides an information processing system including a plurality of arithmetic processing devices and one or more output devices that perform output processing based on processing results performed by the plurality of arithmetic processing devices. An information processing system having the following characteristics is provided. In the information processing system, the plurality of arithmetic processing units include an update command unit that commands software update to a plurality of process execution units, and a management unit that manages the process execution units that have requested registration as management targets. And a parallel processing control means for controlling parallel processing using the processing execution device registered as a management target. The plurality of arithmetic processing devices further include an update processing unit that executes software update in response to a command from the management device, and a registration request unit that requests the management device to register as a management target. And a plurality of processing execution devices each including processing means for executing processing for output processing.

  According to the above configuration, in an information processing system including a plurality of arithmetic processing devices, even if a failure occurs in any of the arithmetic processing devices during software update for the plurality of arithmetic processing devices, the arithmetic processing device that is not recovered Can be removed and the system can be restarted.

1 is an overall configuration diagram of a continuous form printing system according to an embodiment. FIG. The functional block diagram of the continuous form printing system by this embodiment. The figure which illustrates the data structure of the version management table which manages the version information of each slave node in this embodiment. 6 is a flowchart showing overall firmware update control executed by the head node according to the embodiment. 6 is a flowchart showing firmware update processing on each slave node side, which is executed by the slave node according to the present embodiment. In this embodiment, the sequence diagram which shows operation | movement of a head node and a slave node when no problem arises at the time of updating in a slave node. The sequence diagram which shows operation | movement of the head node of a RIP server, and a slave node when a failure arises in the slave node 2 in this embodiment. FIG. 6 is a sequence diagram showing operations of a head node and a slave node of a RIP server when a power interruption occurs before completion of updating of the slave node 2 in the present embodiment. The hardware block diagram of the RIP server by this embodiment.

  Hereinafter, although embodiment of this invention is described, this embodiment is not limited to embodiment described below. Hereinafter, an information processing system including a plurality of arithmetic processing devices (including a management device and a processing execution device (including an image processing device and a termination processing device)) and one or more output devices will be described. A continuous form printing system including a printing node (including a head node and a slave node (including a calculation node and a terminal node)) and a plurality of printers will be described as an example.

  FIG. 1 is a diagram showing an overall configuration of a continuous form printing system 100 according to the present embodiment. A continuous form printing system 100 shown in FIG. 1 includes a RIP (Raster Image Processer) server 104 connected to a network 102, and two printers 190-1 and 190-2 connected to the RIP server 104. Is done. The RIP server 104 is a server that executes RIP processing and printer control, and the two printers 190-1 and 190-2 each execute print output based on the processing results performed by the RIP server 104. .

  The network 102 is not particularly limited, but is a LAN (Local Area Network) such as Ethernet (registered trademark), and transmits a job from a user terminal connected to the network 102 to the RIP server 104.

  The RIP server 104 receives a job from the user terminal via the network 102, performs RIP processing based on the received job, controls the two printers 190-1 and 190-2, and prints them out. As described above, the RIP server 104 is connected to the two printers 190-1 and 190-2 and the network 102. Hereinafter, the job will be described as being transmitted to the RIP server 104 via the network 102, but is not particularly limited. For example, it may be read from a flash memory connected to the RIP server 104 or a storage provided in the RIP server 104.

  Each of the two printers 190-1 and 190-2 shown in FIG. 1 is configured as a continuous form printer that executes print output on a transfer member such as roll paper. Each of the printers 190 includes a printer head of a printing method such as an ink jet method or an electrophotographic method. Although not particularly limited, in the embodiment to be described, one printer 190-1 is responsible for print output on the front surface of the transfer member, and the other printer 190-2 is responsible for print output on the back surface. Yes. The transfer members used in the two printers 190-1 and 190-2 are connected. After the front surface is printed by the first printer 190-1, the back surface is printed by the second printer 190-2. Thereby, a printed matter on which images are formed on both sides is obtained. The printer 190-1 and the printer 190-2 do not perform printing control by themselves, but are controlled by the RIP server 104.

  The RIP server 104 shown in FIG. 1 includes a plurality of computing nodes. More specifically, the RIP server 104 includes a head node 110, a plurality of calculation nodes 150-1 to 150-12, and two terminal nodes 170-1 and 170-2. In FIG. 1, twelve calculation nodes are shown, but the number of calculation nodes that can be incorporated into the system is not particularly limited. FIG. 1 shows a dual engine duplex configuration, and shows two end nodes corresponding to two printers. However, the number of printers and the number of terminal nodes are not particularly limited, and the number of terminal nodes can typically be equal to the number of printers.

  The head node 110 can be configured as a general-purpose computer including a processor, memory, and storage. Similarly, the computing node 150 and the terminal node 170 can be configured as general-purpose computers including a processor and a memory. Typically, the head node 110, the computation node 150, and the terminal node 170 are each configured by a server blade, and these server blades are mounted in a blade bay of an enclosure (housing) so that the RIP server 104 is It is configured. The head node 110, the computation node 150, and the termination node 170 are connected by, for example, an Ethernet (registered trademark) crossbar switch.

  The head node 110 is a master node that controls the computation node 150 and the termination node 170, whereas the computation node 150 and the termination node 170 are slave nodes that operate under the control of the master head node 110.

  The head node 110 divides the received job and assigns the divided job chunk to the calculation node 150. In the embodiment to be described, a job is divided into pages, and a job chunk refers to a job in units of pages that constitute an entire job. Each of the computation nodes 150 executes RIP for each page in parallel based on the assigned job chunk, and generates RIP-completed image data. After the RIP, the calculation node 150 transmits the RIP-completed image data to the end node 170 under the control of the head node 110.

  In the embodiment to be described, the RIP is described as being performed in parallel for each page by the plurality of calculation nodes 150, but the division method of the RIP calculation is not particularly limited. In another embodiment, for each page, the interpretation, rendering, screening, various correction processes, and the like constituting the RIP calculation may be further processed in parallel by different calculation nodes.

  The end node 170 receives the RIPed image data from the calculation node 150 under the control of the head node 110. Each terminal node 170 is connected to a corresponding printer 190 via a fiber channel or the like, and further transfers the RIP-finished image data to the corresponding printer 190 under the control of the head node 110. In the described embodiment, end node 170 aggregates connections with associated printers 190.

  The printers 190-1 and 190-2 receive the RIP-finished image data from the corresponding terminal nodes 170-1 and 170-2, respectively, and perform printout based on the received data. In the embodiment to be described, the printers 190-1 and 190-2 do not have a dependency relationship with the computation nodes 150-1 to 150-12, and any of the computation nodes 150-1 to 150-12 is used. Even if an abnormality occurs, it is configured not to be affected.

  Hereinafter, the functional configuration of the continuous form printing system 100 according to the present embodiment will be described with reference to FIG. FIG. 2 is a functional block diagram of the continuous form printing system 100 according to the present embodiment. FIG. 2 shows functional means on the head node 110, functional means on the calculation node 150, and functional means on the terminal node 170. Each of these functional means is realized on each node by the processor reading a program such as firmware and developing it on the memory. In the embodiment to be described, this firmware program is to be updated later.

  First, before describing the firmware update process, an outline of the print output process based on the parallel RIP in the continuous form printing system 100 will be described.

  As shown in FIG. 2, the head node 110 includes a transmission unit 112, a reception unit 114, a node management unit 122, and a parallel RIP control unit 124. The calculation node 150 includes a transmission unit 152, a reception unit 154, a registration request issue unit 158, and a RIP processing unit 160. The terminal node 170 includes a transmission unit 172, a reception unit 174, a registration request issue unit 178, and a transfer processing unit 180.

  The transmission units 112, 152, and 172 and the reception units 114, 154, and 174 described above perform network communication with other devices such as other nodes and user terminals on the network 102 on the respective nodes 110, 150, and 170. Is a functional means.

  The parallel RIP control unit 124 of the head node 110 is a parallel processing control unit that controls print output processing based on the parallel RIP calculation in which the plurality of slave nodes 150-1 to 150-12, 170-1, and 170-2 described above are incorporated. It is. The RIP processing unit 160 of each computation node 150 is an image processing unit for print output processing that executes RIP calculation based on the allocated job chunk under the control of the parallel RIP control unit 124 of the head node 110. The transfer processing unit 180 of each terminal node 170 performs transfer processing for print output processing that transfers the received RIP-completed image data to the associated printer 190 under the control of the parallel RIP control unit 124 of the head node 110. Means.

  The node management unit 122 manages the slave nodes 150 and 170 that the parallel RIP control unit 124 incorporates in the parallel RIP calculation. Node identifiers are allocated to the slave nodes 150 and 170, and the node management unit 122 manages the node identifiers that identify the slave nodes as a list. In the embodiment to be described, the slave node to be incorporated in the parallel RIP calculation is not statically managed on the head node 110 side, but is a request for registration as a management target from the slave node side (hereinafter referred to as a management target). In response to the registration request, the head node 110 dynamically manages the request. The registration request issuing units 158 and 178 of the calculation node 150 and the terminal node 170 issue a management target registration request with its own node identifier to the head node 110 at a timing such as after activation.

  As shown in FIG. 2, the parallel RIP control unit 124, more specifically, the division unit 126, the imposition unit 128, the allocation unit 130, the page order control unit 132, the calculation node control unit 134, and the termination A node control unit 136 and a printer control unit 138 are included.

  The parallel RIP control unit 124 receives a page description language (PDL) job from the user terminal via the network 102 and starts processing. The dividing unit 126 determines whether or not the received job is divided in units of pages. If the divided job is not divided, the job is divided into job chunks for each page and prepared. The dividing unit 126 is not particularly limited, but may be provided for each corresponding page description language. The job is typically described in a format such as PDF (Portable Document Format), PostScript, IPDS (Intelligent Printer Data Stream).

  The imposition unit 128 determines whether the image of the job chunk divided into pages based on the imposition setting information set for the job is placed in the output cell on the front surface or the back surface of the output transfer member. Determine the date. In the allocation unit 130, the page order control unit 132 receives the imposition result and determines the processing order of job chunks. The allocating unit 130 allocates a computation node that performs a RIP operation of a predetermined job chunk from among the computation nodes 150-1 to 150-12 according to the determined processing order.

  The calculation node control unit 134 is a control unit that controls the calculation node 150. The calculation node control unit 134 issues a RIP start instruction to the calculation nodes 150-1 to 150-12, and sends a RIP end notification from the calculation nodes 150-1 to 150-12. Accept. The RIP processing unit 160 of the computing node 150 receives the job chunk from the head node 110, performs a RIP operation based on the allocated job chunk in response to the RIP start command, and notifies the RIP end after the RIP is completed. Reply. A raster image is generated by RIP calculation.

  The computation node control unit 134 further requests the computation nodes 150-1 to 150-12 that have completed the RIP operation to start transmission of RIP-completed image data to the appropriate termination node 170-1 or termination node 170-2. Is issued. The parallel RIP control unit 124 transmits the RIP progress status of the computation nodes 150-1 to 150-12 and the RIP-completed image data from the end nodes 170-1 and 170-2 to the corresponding printers 190-1 and 190-2, respectively. Manages transmission progress. These situations are determined when the transmission start request is issued. The computation node control unit 134 receives a notification of completion of transmission of RIP-completed image data from the computation nodes 150-1 to 150-12. In response to the transmission start request command, the RIP processing unit 160 of the calculation node 150 sends the RIP-completed image data to a predetermined terminal node 170, and returns a transmission completion notification after the transmission is completed.

  The transfer processing unit 180 of the end node 170 receives the RIP-completed image data from the calculation node 150 and transfers it to the corresponding printer 190. The terminal node control unit 136 is a control unit that controls the terminal node 170, and receives image transmission completion notifications from the terminal nodes 170-1 and 170-2 to the printers 190-1 and 190-2, respectively. The end node control unit 136 receives a print completion notification from the end nodes 170-1 and 170-2. When the corresponding printer 190 completes the print output, the end node 170 receives the print completion notification and notifies the head node 110 of the print completion.

  The printer control unit 138 is a control unit that controls the printer 190, and controls the operation of the printer 190 based on the RIP progress status of the calculation node 150, the data transfer progress status of the terminal node 170, and the like. The printer control unit 138 manages errors such as JAM of the printer 190.

  Next, firmware update processing in the RIP server 104 according to the present embodiment will be described. Referring to FIG. 2, the head node 110 serving as a master further includes a firmware storage unit 116, an update control unit 118, and an update processing unit 120. The computation node 150 and the end node 170 that are slaves are further configured to include update processing units 156 and 176.

  The firmware storage unit 116 of the head node 110 stores a firmware update file for the entire RIP server 104. The firmware update file is provided to the head node 110 via the network 102, for example. Alternatively, it may be provided to the head node via an optical medium such as a CD-ROM (Compact Disk Read Only Memory) or DVD, or a removable medium such as a flash memory. The firmware storage unit 116 is provided by a non-volatile storage area that can maintain the memory even when the power of the head node 110 is turned off. The firmware update file managed here includes update files for the head node 110, the calculation nodes 150-1 to 150-12, the terminal node 170-1, and the terminal node 170-2. .

  The update control unit 118 transmits a firmware update file for each of the calculation nodes 150-1 to 150-12 and the end nodes 170-1 and 170-2 and instructs the start of the firmware update process. The update control unit 118 instructs the update processing unit 120 to start the firmware update process for all of the computation nodes 150-1 to 150-12 and the end nodes 170-1 and 170-2. Command to start the firmware update process.

  The update processing units 120, 156, and 176 of each node described above are processing means for executing update processing of its own firmware on the respective nodes 110, 150, and 170. The update processing unit 120 reads the firmware update file for the head node, and executes its own firmware update process. The update processing units 156 and 176 of the calculation node 150 and the terminal node 170 receive a firmware update process start command from the head node 110 and receive a firmware update file for itself. In response to a command from the head node 110, the update processing units 156 and 176 individually execute firmware update processing in each of the slave nodes 150-1 to 150-12, 170-1, and 170-2.

  In the update process of each node 110, 150, 170, typically, each node is restarted once in the process. At this time, the node identifier of the managed slave node managed by the node management unit 122 of the head node 110 is once cleared.

  The registration request issuing units 158 and 178 of the calculation node 150 and the termination node 170 complete the firmware update process and restart normally, and then register the management target by adding their own node identifiers to the head node 110. Issue a request. In a preferred embodiment, the management target registration request can be issued with its own firmware version information (version, time stamp, etc.). Registration request issuing units 158 and 178 are realized by firmware. Therefore, the firmware for the calculation node 150 and the end node 170 is coded to make a management object registration request to the head node 110 after being activated, and includes code for causing the RIP processing unit 160 or the transfer processing unit 180 to function. I can say that.

  The node management unit 122 receives a management target registration request for a predetermined time limit after the update of its own firmware is completed and the system is restarted normally. The node management unit 122 dynamically manages only the calculation node 150 and the terminal node 170 that have transmitted the management target registration request within the predetermined time limit as the management target of the head node 110. After the time limit has elapsed, the node management unit 122 restarts the system only with the slave node that has received the management target registration request so far. Accordingly, the parallel RIP control unit 124 can execute print output processing based on the parallel RIP. The time limit described above can be set as a system setting or the like in advance.

  In a preferred embodiment, the update control unit 118 manages the version information of the firmware update file of the slave nodes 150 and 170 that issued the update command. FIG. 3 is a diagram illustrating a data structure of a version management table for managing version information of each slave node. As shown in FIG. 3, the version management table associates the node identifier for identifying the slave node that has issued the update command, the type of the slave node, and the version information of the firmware when the update command has been issued. .

  When the management target registration request is received, the update control unit 118 sends the version information associated with the corresponding node identifier in the management table and the management target registration request before the node management unit 122 registers the request source node. Compare the attached version information and confirm whether it is consistent. Here, if there is a difference between the version information of the slave node managed by the update control unit 118 and the received version information, it is determined that the version is inconsistent. In that case, the update control unit 118 preferably re-sends the latest firmware update file to the slave node in which inconsistency occurs, and instructs the firmware update to be retried. The update control unit 118 constitutes update command means, confirmation means, and retry means in this embodiment.

  Hereinafter, the processing executed by the head node 110 and the slave nodes 150 and 170 in the firmware update of the RIP server 104 will be described in more detail with reference to FIGS. FIG. 4 is a flowchart showing overall firmware update control executed by the head node 110 according to the present embodiment.

  The control shown in FIG. 4 is started from step S100 in response to the occurrence of an event that triggers the update process, such as an update instruction from the administrator. In step S <b> 101, the head node 110 receives from the network 102 or reads from the medium, and prepares a firmware update file in the firmware storage unit 116. In step S102, the head node 110 issues a firmware update start command to all the slave nodes 150 and 170 listed as management targets.

  In step S103, the head node 110 starts its own firmware update process. When the update process is completed in step S104 (YES), control branches to step S105. The head node 110 shuts itself down in step S105 and restarts in step S106.

  After restarting, the head node 110 determines whether or not a predefined time limit has elapsed in step S107. If it is determined in step S107 that the time limit has not yet elapsed (NO), the control proceeds to step S108. In step S108, the head node 110 determines whether or not a management target registration request from any slave node has been received. If it is determined in step S108 that no request has been received from any of them (NO), control is looped to step S107, and a management target registration request is awaited.

  On the other hand, if it is determined in step S108 that a management target registration request has been received from either (YES), control branches to step S109. In step S109, the head node 110 acquires the node identifier and version information attached to the management target registration request, compares the version information in the version management table corresponding to the acquired node identifier with the acquired version information, Determine if the versions are consistent.

  If it is determined in step S109 that the versions match (YES), control branches to step S110. In step S110, the head node 110 registers the node identifier of the requesting node attached to the management target registration request in the management target list. In step S111, the head node 110 makes a positive response to the management target registration request to the requesting slave node, and loops the control to step S107. On the other hand, if it is determined in step S109 that the versions are inconsistent (NO), the control branches to step S112. In step S112, the head node 110 instructs the requesting slave node to retry the firmware update together with a negative response, and loops the control to step S107. Thereafter, the processes shown in steps S107 to S112 are repeated until the time limit elapses.

  Referring to step S107 again, if it is determined in step S107 that the time limit has elapsed (YES), control branches to step S113. In step S113, the head node 110 restarts the system only with the slave nodes registered at the present time. As a result, the head node 110 becomes ready for print output processing based on parallel RIP.

  FIG. 5 is a flowchart showing the firmware update process on each slave node executed by the slave node according to the present embodiment. The process shown in FIG. 5 is a process that can be executed by both the calculation node 150 and the terminal node 170.

  The process shown in FIG. 5 is started from step S200 in response to receiving the update command from the head node 110. In step S201, the slave nodes 150 and 170 obtain their own firmware update file from the head node 110 or the storage location designated by the head node 110 (for example, designated by a URL), and prepare for the update. Do. In step S202, the slave nodes 150 and 170 start their own firmware update processing. When the update process is completed in step S203 (YES), the process branches to step S204. The head node 110 is shut down in step S204 and restarted in step S205.

  After rebooting, the slave nodes 150 and 170 initialize themselves in step S206, and issue a management target registration request to the head node 110 in step S207. In step S208, the slave nodes 150 and 170 wait for a response to the management target registration request. If there is a response in step S208, the process branches to step S209.

  In step S209, the slave nodes 150 and 170 determine whether a firmware update retry is requested. If it is determined in step S209 that the response is affirmative and no retry is required (NO), the process branches to step S210. In step S210, the slave nodes 150 and 170 are in a state in which processing (RIP or transfer processing) that they are in charge of in the print output based on the parallel RIP can be executed under the control of the head node 110. Thereafter, when a new job is taken out from the queue, the calculation node 150 executes the RIP operation based on the job chunk assigned from the head node 110. The end node 170 executes processing for transferring the RIP-completed data to the associated printer 190.

  On the other hand, if it is determined in step S209 that a negative response has been received and it is determined that a firmware update retry is required (YES), the process loops again to step S201 and the firmware update is repeated again. If it is determined in step S208 that there is no response to the management target registration request (NO), the process branches to step S211. In step S211, the slave nodes 150 and 170 determine whether or not the response has timed out.

  If it is determined in step S211 that the timeout has not occurred (NO), the process loops to step S207. This corresponds to a case where the restart of the head node 110 is delayed from the restart of the slave nodes 150 and 170. On the other hand, if it is determined in step S211 that the timeout has occurred (YES), there is a possibility that some kind of failure has occurred, and therefore, in step S212, for example, a transition is made to a standby state or shutdown is performed.

  Hereinafter, the operation of each node in the firmware update of the RIP server 104 will be described with reference to specific cases illustrated in FIGS. FIG. 6 is a sequence diagram showing operations of the head node and the slave node when no problem occurs during the update of the slave node. In FIG. 6, the slave node 1 and the slave node 2 are shown as representatives, but the number of slave nodes is not particularly limited, and these are either the calculation node 150 or the termination node 170. May be. Also, assume that the firmware version at the start of the head node 110 is version 1.0 (ver.1.0-mb), and the slave node version is also version 1.0 (ver.1.0-sb).

  The process shown in FIG. 6 is started from step S301 in response to the occurrence of an event that triggers the update. In step S302, the head node 110 prepares for firmware update and stores version information of firmware update files of all nodes. Here, it is assumed that both the master and the slave are updated to version 2.0 (ver.2.0-sb, ver.2.0-sb). In steps S303 and S304, the head node 110 takes out the managed node identifier, and issues an update start command to the slave nodes 1 and 2 using the node identifier. At the same time, a firmware update file (ver.2.0-sb) of version 2.0 is transmitted to slave node 1 and slave node 2.

  In step S305, the head node 110 executes its own update process. When the own firmware update process is completed, the head node 110 clears the node identifier of the managed node from the list. In step S306, the head node 110 shuts down without waiting for the result for the update start command transmitted to all slave nodes.

  In parallel with the update process on the head node 110 side, the slave node 1 executes its own update process using the received version 2.0 firmware update file (ver.2.0-sb) in step S307, In step S308, shutdown is performed. Similarly, the slave node 2 executes its own update process in step S309 and shuts down in step S310.

  Here, it is assumed that in step S311, the slave node 1 is started up in a state updated to the new version 2.0 (ver.2.0-sb) after the shutdown in step S308. In step S312, the slave node 1 adds a node identifier for identifying itself and firmware version information (ver. 2.00-sb) to register itself as a management target of the head node 110, A management target registration request is transmitted to the node 110. However, since the head node 110 has not been activated yet, no response is returned here. The slave node 1 periodically issues a management target registration request until a response to the management target registration request is returned. In step S313, the slave node 1 further transmits a management target registration request to the head node 110. But no response is returned.

  In step S314, the slave node 2 starts up in the state updated to the new version 2.0 (ver.2.0-sb) after the shutdown in step S310. In step S315, the slave node 2 transmits a management target registration request in the same manner as the slave node 1. Again, no response is returned because the head node 110 has not yet been activated.

  Assume that the time has elapsed, and in step S316, the head node 110 has started up in a new version 2.0 (ver. 2.0-mb) state after the shutdown in step S306. After startup, the head node 110 is ready to accept a management target registration request. The head node 110 holds a certain time limit for accepting the management target registration request, and starts measuring the passage of time after activation.

  When the slave node 1 transmits a management target registration request to the head node 110 in step S317, the head node 110 verifies version consistency in step S318. Here, the firmware version of the slave node 1 (ver.2.00-sb) sent with the management target registration request from the slave node 1 is compared with the version information managed (ver.2.00-sb). Here, it is determined that the versions are consistent. In step S319, the head node 110 records the node identifier of the slave node 1 received together with the management target registration request in the management target list of the node management unit 122, and transmits a positive management target registration response to the slave node 1. In step S320, the slave node 1 receives the positive management target registration response from the head node 110, and shifts to a state in which processing can be performed.

  The same applies to the slave node 2. When the slave node 2 transmits a management target registration request to the head node 110 in step S321, in step S322, the head node 110 verifies version consistency. Here, it is assumed that it is matched. In step S323, the head node 110 records the node identifier of the slave node 2 in the management target list, and transmits a positive management target registration response to the slave node 2. In step S324, the slave node 2 receives an affirmative response from the head node 110, and shifts to a state in which processing can be performed.

  When the head node 110 detects that the time limit has elapsed in step S325, the head node 110 starts the system in step S326. As a result, a print output process based on the parallel RIP is enabled. The head node 110 rejects the request even if it receives a management target registration request from the slave node after the system restarts.

  Through the above-described sequence, the firmware of the entire RIP server 104 is updated to a new one, the system is maintained in the latest state, and only the slave node that has requested registration is incorporated, and print output processing based on parallel RIP is executed. It becomes possible.

  FIG. 7 is a sequence diagram illustrating operations of the head node and the slave node of the RIP server 104 when a failure occurs in the slave node 2. Note that the same sequence is performed when the slave node 1 fails. The process shown in FIG. 7 is started from step S401 in response to the occurrence of an event that triggers the update. In addition, since the process from step S402 to step S413 is the same as the process from step S302 to step S313 shown in FIG. 6, hereinafter, step S414 and subsequent steps will be described.

  Here, in step S414, it is assumed that a failure that cannot be recovered occurs for some reason when the slave node 2 is activated. The head node 110 is activated in step S415, and registers the slave node 1 as a management target by the processing shown in steps S416 to S419. However, since the slave node 2 has not recovered and cannot issue the management target registration request, it is detected in step S420 that the time limit has elapsed.

  When it is detected that the time limit has elapsed, the head node 110 starts the system in step S421 without registering the slave node 2 that has not been restored as a management target. The head node 110 rejects the request even if it receives a management object registration request from other slave nodes including the slave node 2 after the system restarts.

  In the above sequence, since the management registration request for the slave node 2 has not been received when the time limit has elapsed, the slave node 2 is not a management target. However, even in this case, a special sequence does not occur, and the system itself is restarted in a fault tolerant manner. Then, the print output process based on the parallel RIP in which the slave node is incorporated in a state where the slave node 2 is removed can be executed.

  FIG. 8 is a sequence diagram showing operations of the head node and the slave node of the RIP server 104 when the power interruption occurs before the completion of the update of the slave node 2. The process shown in FIG. 8 is started from step S501 in response to the occurrence of an event that triggers the update. Note that the processing from step S502 to step S508 is the same as the processing from step S302 to step S308 shown in FIG. 6, and therefore, step S509 and subsequent steps will be described below.

  Here, in step S509, after the update process of the head node 110 and the slave node 1 is successfully completed and before the slave node 2 completes the update process, the entire system is disconnected for some reason. To do. The head node 110 is activated in step S510, and the slave node 1 is also activated in step S511. The head node 110 registers the slave node 1 as a management target by the processing shown in steps S512 to S515, and the slave node 1 shifts to a state in which processing can be performed.

  In step S516, the slave node 2 is activated. In this case, since the power is cut off without completing the update process, the slave node 2 is activated in the state of the previous version 1.0 (ver.1.0-sb). . In step S517, the slave node 2 transmits a management target registration request to the head node 110, and in step S518, the head node 110 verifies version consistency. In this case, since the slave node 2 is activated in the previous version, the firmware version (ver.1.00-sb) of the slave node 2 sent together with the management target registration request and the version information managed ( It does not match ver.2.00-sb). In step S519, the head node 110 transmits a negative response to the slave node 2 and instructs the firmware update to be retried.

  In response to the retry instruction, the slave node 2 executes the update process again in step S520, and shuts down in step S521. In step S522, the slave node 2 is activated in a state updated to the new version 2.0 (ver.2.0-sb). In step S523, the slave node 2 sends a management target registration request with new version information, and the head node 110 registers the slave node 2 as a management target by the processing shown in steps S524 and S526. As a result, the slave node 2 shifts to a state where processing can be executed. Thereafter, when it is detected in step S527 that the time limit has elapsed, the head node 110 starts the system.

  In the above-described sequence, the version information of the slave node is always verified at the time of management target registration. This prevents the system from being restarted with a slave node with an inconsistent version installed even if the slave node is turned off before completing its update process. It becomes possible.

  Hereinafter, the hardware configuration of the RIP server 104 will be described with reference to FIG. The RIP server 104 shown in FIG. 9 is configured as a so-called blade server. In the enclosure 200, a plurality of server blades 210-1 to 210-n are mounted in blade bays provided in the enclosure 200 via connectors corresponding to hot plugs. The enclosure 200 includes an input / output port 202 such as Ethernet (registered trademark) or Fiber Channel, a switch module 204, and a power supply unit 206.

  Each of the server blades 210 includes one or more processors 212, a memory 214, an HDD 216 as necessary, an expansion board 218 such as a fiber channel as necessary, and a network interface 220. Note that the configuration of each blade is not necessarily the same. The server blades 210 may be connected to each other via an Ethernet (registered trademark) switch of the switch module 204 or the like.

  The nodes (including the head node 110, the calculation node 150, and the termination node 170) operating on each server blade 210 read the firmware from its own HDD 216 or a shared HDD and deploy it on the memory 214, thereby expanding the above-mentioned. Each functional means is realized. The server blade 210 illustrated in FIG. 9 exemplifies a two-node configuration.

  In the embodiment described above, the slave nodes 150 and 170 take the lead, and the management target in the head node is determined. When the slave node becomes unrecoverable, the management target registration request is not issued from the slave node, and therefore it is not set as a management target. For this reason, even if the number of slave nodes that can operate after the firmware update changes, the head node 110 can restart the system using only the operable nodes.

  Furthermore, in the above-described embodiment, the slave nodes are classified into the calculation node 150 that does not depend on the printer 190 and the terminal node 170 that aggregates connections with the printer 190. When a compute node is connected to a printer, the software update of the compute node can affect the connection to the printer. On the other hand, in the above-described embodiment, the connection with the printer 190 is integrated into the terminal node 170, the dependency between the calculation node 150 and the printer 190 is reduced, and the printer 190 during software update of the calculation node 150 is updated. The impact on is reduced. Therefore, the system can be restarted regardless of the failure of the computation node 150 while suppressing the influence range in such a manner that it is not affected by the failure of all the slave nodes but only affected by the failure of the terminal node. become.

  In the preferred embodiment, the firmware version is verified when the slave node is registered as a management target. In this verification, if a difference occurs, the firmware update of the slave node is retried under the initiative of the head node 110. For this reason, even if there is a difference in the firmware version in the slave node due to a power failure or the like, it is possible to restart the system after eliminating the difference in the version.

  With the above-described configuration, the continuous form printing system 100 can restart the system in a fault tolerant manner without intervention of the user when a failure of a blade or the like in the RIP server 104 during firmware update occurs. Further, in the preferred embodiment, even when a difference occurs in the firmware version of the slave node due to the power interruption during the firmware update, the version difference can be resolved and the system can be restarted without user intervention.

  As described above, according to the present embodiment, in an information processing system including a plurality of arithmetic processing devices, even if a failure occurs in any of the arithmetic processing devices during software update for the plurality of arithmetic processing devices. It is possible to provide an information processing system, a software update method, and a program capable of restarting the system by excluding an arithmetic processing unit that is not restored.

  The functional unit can be realized by a computer-executable program written in a legacy programming language such as an assembler, C, C ++, C #, Java (registered trademark), an object-oriented programming language, or the like. ROM, EEPROM, EPROM , Stored in a device-readable recording medium such as a flash memory, a flexible disk, a CD-ROM, a CD-RW, a DVD-ROM, a DVD-RAM, a DVD-RW, a Blu-ray disc, an SD card, an MO, or through an electric communication line Can be distributed.

  Although the embodiments of the present invention have been described so far, the embodiments of the present invention are not limited to the above-described embodiments, and those skilled in the art may conceive other embodiments, additions, modifications, deletions, and the like. It can be changed within the range that can be done, and any embodiment is included in the scope of the present invention as long as the effects of the present invention are exhibited.

DESCRIPTION OF SYMBOLS 100 ... Continuous form printing system, 102 ... Network, 104 ... RIP server, 110 ... Head node, 112 ... Transmission part, 114 ... Reception part, 116 ... Firmware storage part, 118 ... Update control part, 120 ... Update process part, 122 ... Node management unit, 124 ... Parallel RIP control unit, 126 ... Dividing unit, 128 ... Imposition unit, 130 ... Allocation unit, 132 ... Page order control unit, 134 ... Calculation node control unit, 136 ... Terminal node control unit, 138 DESCRIPTION OF SYMBOLS ... Printer control part 150 ... Computation node 152 ... Transmission part 154 ... Reception part 156 ... Update processing part 158 ... Registration request issuing part 160 ... RIP processing part 170 ... Termination node 172 ... Transmission part 174 ... Receiving unit, 176 ... Update processing unit, 178 ... Registration request issuing unit, 180 ... Transfer processing unit, 190 ... Printer, 200 ... En Closures, 202 ... output port, 204 ... switch module 206 ... power supply unit, 210 ... server blades 212 ... processor, 214 ... memory, 216 ... HDD, 218 ... expansion board, 220 ... network interface

Japanese Patent No. 5080318 Japanese Patent No. 4054802

Claims (9)

An information processing system including a plurality of arithmetic processing devices and one or more output devices that perform output processing based on processing results performed by the plurality of arithmetic processing devices,
The plurality of arithmetic processing units are:
Parallel using an update command means for instructing a plurality of process execution devices to update software, a management means for managing a process execution device that has requested registration as a management target, and a process execution device registered as a management target A management apparatus including parallel processing control means for controlling processing;
Update processing means for executing software update in response to a command from the management apparatus, registration request means for requesting the management apparatus to register as a management target, and processing for output processing respectively and processing means viewing including a plurality of processing execution unit included in the management means managing a request to be registered as the management target, the processing execution unit that has been sent to predefined within the time limit An information processing system registered as a target, wherein the parallel processing control unit is capable of executing parallel processing after the time limit has elapsed . The plurality of processing execution devices are:
Each of the plurality of image processing devices includes an image processing unit that does not have a dependency relationship with any of the one or more output devices, and that performs image processing based on data allocated from the management device as the processing unit. When,
One or more termination processing devices each of which aggregates connections with associated output devices, and includes, as the processing means, transfer processing means for executing transfer processing of image processed data to the associated output device The information processing system according to claim 1, including:   The update command means commands to update the software in response to an event that triggers an update process, and the management means responds to the request sent from the process execution device The information processing system according to claim 1, wherein the requesting process execution device is registered as a management target.   The management device, when the management unit registers the request source processing execution device before confirming the version information of the software of the request source processing execution device, if there is a mismatch in the version, The information processing system according to claim 3, further comprising retry means for instructing the requesting process execution apparatus to update software again. The parallel processing control means of the management device comprises means for preparing a plurality of job chunks constituting the requested job;
Means for determining imposition on the transfer member according to the contents of the job;
Means for assigning each of the plurality of job chunks to each of the plurality of image processing devices;
Each of the image processing means of the image processing device executes a process of generating a raster image based on the assigned job chunk,
Each of the transfer processing means of the termination processing device receives a raster image to be output by the corresponding output device, and executes processing for transmitting to the corresponding output device,
The information processing system according to claim 2, wherein the output device prints out based on the received raster image. A software update method in an information processing system including a plurality of arithmetic processing devices and one or more output devices that perform output processing based on processing results performed by the plurality of arithmetic processing devices,
A management device of the plurality of arithmetic processing devices instructing a process execution device of the plurality of arithmetic processing devices to update software;
The process execution device executing a software update in response to a command from the management device;
A process execution device that has completed software update makes a request to register the management device as a management target; and
The management device registers as a management target the requesting process execution device that has sent a request for registration as a management target within a predefined time limit ;
And a step of allowing the management device to execute parallel processing using the processing execution device registered as the management target after the time limit has elapsed . After the step of enabling the parallel processing,
An image processing device having no dependency relationship with any of the one or more output devices among the processing execution devices, executing image processing based on data assigned from the management device;
A termination processing device that aggregates connections with the associated output device of the processing execution devices, and executes a process of transferring image processed data to the associated output device. 6. The software update method according to 6 . An arithmetic processing device that operates as a management device is realized in an information processing system including a plurality of arithmetic processing devices and one or more output devices that perform output processing based on processing results performed by the plurality of arithmetic processing devices. A program for the computer,
Update command means for commanding software update to a plurality of processing execution devices,
A program for functioning as a management means for managing a processing execution device that has requested to be registered as a management target, and a parallel processing control means for controlling the execution of parallel processing using the processing execution device registered as a management target. The software is coded to make a request for registration as a management target to the management device after the processing execution device is started, and the management means sends a request for registration as the management target, A program for registering a processing execution device sent within a predefined time limit as a management target, and enabling the parallel processing control means to execute parallel processing after the time limit has elapsed . The software is
An image processing unit that operates on the processing execution device and performs image processing based on assigned data in response to a command from the management device, or an associated output device 9. The program according to claim 8 , comprising a code for causing a function as transfer processing means for executing transfer processing of image processed data.