Storage device, and rebooting method of storage device

Abstract

To provide a storage device capable of continuing processing IO requests from a host device even when one of the multiple controllers stops due to a restart process associated with an operating system update, while duplicating data received from the host device.SOLUTION: A storage control program is configured to execute the reboot process to restart the updated operating system without initializing a first given area on hardware used by the operating system, and after the reboot process is complete, to reallocate virtual addresses for the first given area, and resume I / O processing by a first processor.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a storage device and a method for restarting a storage device, and is suitable for application to a storage device relating to a technology in which a processor controls a host interface and performs input / output processing of data in response to input / output requests from a host device, for example. [Background technology]

[0002] A storage device has multiple storage controllers (hereafter simply called controllers) that control the storage device, and even if one of the controllers fails and stops operating, the remaining controllers can continue operating, ensuring reliability. The typical number of such controllers is two.

[0003] In storage devices, the controller may be equipped with an OS (operating system) controlled by a processor (see Patent Document 1), and in addition to the failures described above, the processor function of one of the controllers may be temporarily stopped when a restart process for the OS (for example, a restart process associated with an update process for the OS) is executed at any time. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2024-060523 A Summary of the Invention [Problem to be solved by the invention]

[0005] During an OS restart process at any time (in the above-described storage device, this is a restart process associated with an OS update process or the like in one of the controllers), it is possible to automatically reconnect I / O requests from a host device to another controller having a processor that is not stopped during the restart process. However, because the processing of I / O requests is suspended in one of the controllers that is the target of the OS restart process at any time (in the above-described storage device, this is the one controller that is the target of the OS update process), the host device must resend the I / O requests to the other controller that is not the target of the OS restart process (in the above-described storage device, the other controller that is not the target of the OS update process). In other words, during an OS restart process at any time (in the above-described storage device, this is a restart process associated with an OS update process or the like in the above-described storage device), there is a risk that the continuation of I / O processing may be temporarily difficult in the storage device. Furthermore, while one of the controllers is executing an OS restart process at any time (a restart process associated with an OS update process or the like in one of the controllers of the above-described storage device), data received from the host device is not duplicated, which creates a data redundancy issue.

[0006] The present invention has been made in consideration of the above points, and aims to propose a storage device and a method for restarting a storage device that can continue to process input / output requests from a host device and can reliably duplicate data received from the host device, even when one of multiple controllers is stopped due to an operating system restart process (for example, a restart process accompanying an operating system update process). [Means for solving the problem]

[0007] In order to solve the above problem, the present invention provides a storage device comprising: a first controller including a first processor that controls input / output processing of data in response to a request from a host device via a host interface that controls a protocol for communication with the host device, and a first memory having a storage area used by the first processor; at least one second controller that includes a second processor that controls input / output processing of data in response to a request from the host device via a host interface that controls a protocol for communication with the host device, and a second memory having a storage area used by the second processor; and an inter-controller link that connects the first controller and the second controller, wherein the first processor executes an operating system and a storage control program that controls input / output processing of data in response to a request from the host device, The storage control program includes: a placement unit that assigns a virtual address to a first predetermined area in the first memory to which the operating system does not assign a virtual address, and places a first control queue in the first predetermined area in which data of input / output processing via a host interface is temporarily stored; a takeover unit that, during a restart process to restart the operating system, hands over the input / output processing from the first processor to the second processor and releases the allocation of the virtual address to the first predetermined area; a restart unit that executes a restart process to restart the operating system without initializing the first predetermined area on hardware used by the operating system; and a processing resumption unit that, after the restart process is completed, reassigns a virtual address to the first predetermined area and resumes input / output processing by the first processor.

[0008] Also, in the present invention, there is provided a method for restarting a storage device comprising: a first controller including a first processor that controls input / output processing of data in response to a request from a host device via a host interface that controls a protocol for communication with the host device, and a first memory having a storage area used by the first processor; at least one second controller including a second processor that controls input / output processing of data in response to a request from the host device via a host interface that controls a protocol for communication with the host device, and a second memory having a storage area used by the second processor; and an inter-controller link connecting the first controller and the second controller, wherein the first processor executes an operating system and a storage control program that controls input / output processing of data in response to a request from the host device, and the storage control program The system is configured to execute an arrangement step of allocating a virtual address to a first predetermined area in the first memory to which the operating system does not allocate a virtual address, and locating a first control queue in the first predetermined area, in which data of input / output processing via a host interface is temporarily stored; a takeover step of handing over the input / output processing from the first processor to the second processor and releasing the allocation of the virtual address to the first predetermined area during a restart process of restarting the operating system; a restart step of executing a restart process of restarting the operating system without initializing the first predetermined area (area outside OS management 204) on hardware used by the operating system; and a process restart step of re-allocating a virtual address to the first predetermined area and restarting the input / output processing by the first processor after the restart process is completed. [Effects of the Invention]

[0009] According to the present invention, even if one of multiple controllers stops due to an operating system restart process (for example, a restart process accompanying an operating system update process), it is possible to continue processing IO requests from a host device and to duplicate data received from the host device. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a system configuration diagram showing an example of the configuration of a storage device according to a first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a memory space. [Figure 3] 10 is a flowchart illustrating an example of a procedure for updating and restarting an OS. [Figure 4] FIG. 1 is a diagram illustrating an example of the configuration of OQ and IQ. [Figure 5] FIG. 10 is a diagram illustrating a data transfer path related to host IO processing before host IO takeover. [Figure 6] FIG. 10 is a diagram illustrating a data transfer sequence related to host IO processing before host IO takeover. [Figure 7] FIG. 10 is a diagram illustrating an example of a P2P data transfer path. [Figure 8] 10 is a flowchart illustrating an example of a host IO takeover processing procedure. [Figure 9] FIG. 10 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover. [Figure 10] FIG. 10 is a diagram illustrating a data transfer sequence related to host IO processing after host IO takeover. [Figure 11] 10 is a flowchart illustrating an example of a host IO resume processing procedure. [Figure 12] 10 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover in a storage device according to a second embodiment. FIG. [Figure 13] FIG. 10 is a diagram illustrating a data transfer sequence related to host IO processing after host IO takeover. [Figure 14] 10 is a flowchart illustrating an example of a host IO takeover processing procedure. [Figure 15] 10 is a flowchart illustrating an example of a host IO resume processing procedure. [Figure 16] FIG. 11 is a diagram illustrating a data transfer path related to host IO processing before host IO takeover in a storage device according to a third embodiment. [Figure 17] FIG. 10 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover. DETAILED DESCRIPTION OF THE INVENTION

[0011] An embodiment of the present invention will be described in detail below with reference to the drawings. It should be noted that throughout all embodiments, components with the same reference numerals are essentially the same. Furthermore, since the processing executed by the processor is performed using storage resources (e.g., memory) and communication interface devices (e.g., communication ports) as appropriate, the subject of the processing may be the processor. The processor may have dedicated hardware in addition to a CPU (Central Processing Unit).

[0012] In the following description, "memory" refers to a main storage device in a typical computer system, and may be one or more storage devices. For example, the memory may be at least a main storage device among a main storage device (typically a volatile storage device) and an auxiliary storage device (typically a non-volatile storage device).

[0013] Furthermore, in the following explanation, "PDEV" refers to a physical storage device, and may typically be a non-volatile storage device (for example, an auxiliary storage device). A PDEV may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0014] (1) First embodiment A storage device according to the first embodiment will be described with reference to Fig. 1 to Fig. 11. Fig. 1 is a system configuration diagram showing an example of the configuration of a storage device 100 according to the first embodiment. In the illustrated configuration example, for the sake of simplicity, some of the connections between the elements are omitted (the same applies to other drawings besides Fig. 1).

[0015] The storage device 100 according to this embodiment includes a first controller (hereinafter also abbreviated as "controller") 121 including a CPU 123 as an example of a first processor that controls input / output processing of data in response to a request from a host device via a host IF that controls a protocol for communication with the host device, and a first memory (hereinafter also abbreviated as "memory") 124 having a storage area used by the CPU 123, at least one second controller (hereinafter also abbreviated as "controller") 101 including a CPU 103 as an example of a second processor that controls input / output processing of data in response to a request from the host device via a host IF that controls a protocol for communication with the host device, and a second memory (hereinafter also abbreviated as "memory") 104 having a storage area used by the CPU 103, and an inter-controller link 111 that connects the controller 121 and the controller 101. Note that since both controllers 121 and 101 have substantially the same configuration and function, when there is no need to particularly mention both, only one controller side may be mentioned. The number of controllers in the storage device 100 is not limited to two, and may be more than two. This embodiment will be described taking as an example a process of restarting the OS in association with an update process of the controller's OS as a process of restarting the OS at any timing as a process of restarting the OS in the controller, but the present invention is not limited to this. For example, the OS of the controller in the storage device 100 may be restarted when the administrator of the storage device 100 determines it is necessary. This will be described in more detail below.

[0016] The storage device 100 includes controllers 101 and 121, and a PDEV BOX 140 having a plurality of PDEVs including PDEVs 142 and 162.

[0017] The storage device 100 has logical volumes configured on a plurality of drive devices that can store data, and the controllers 101 and 121 execute data input / output processing.

[0018] The controller 101 has a host IF (Interface) 102, a CPU 103, a memory 104, and an NTB 108. The host IF 102, the CPU 103, and the NTB 108 are interconnected, for example, by a PCIe (Peripheral Component Interconnect Express) link. Similarly, the controller 121 has a host IF 122, a CPU 123, a memory 124, and an NTB 128. The host IF 122, the CPU 123, and the NTB 128 are interconnected, for example, by a PCIe link. The CPU 103 and the memory 104, and the CPU 123 and the memory 124 are each connected by a memory bus.

[0019] Furthermore, the controllers 101, 121 each include a management terminal IF 171, 172 for connecting to a management terminal 174 via a management terminal network 173. The administrator of the storage device 100 can operate the management terminal 174 to change the settings of the storage device 100, update and restart the controller OS (hereinafter also abbreviated as "OS"), and so on.

[0020] CPU 103 includes multiple cores 105 and an uncore 106, which is the remaining part of CPU 103. Uncore 106 includes a DMA (Direct Memory Access) 107. Similarly, CPU 123 includes multiple cores 125 and an uncore 126, which is the remaining part of CPU 103. Uncore 126 includes a DMA 127.

[0021] The host devices 150, 600 that access the storage device 100 are connected to the storage device 100 via the host IFs 102, 122, respectively. The host devices 150, 600 and the host IFs 102, 122 are connected by transmission lines such as Fibre Channel cables or Ethernet cables. Alternatively, the host devices 150, 600 and the host IFs 102, 122 may be connected via a storage area network (not shown) made up of multiple transmission lines and multiple switches.

[0022] The host IFs 102 and 122 convert the data transfer protocol between the host devices 150 and 600 and the storage device 100 and the data transfer protocol within the controllers 101 and 121 .

[0023] The PDEV BOX 140 is connected to the controllers 101 and 121 via links 131, 132, 151, and 152. The PDEV BOX 140 includes PDEV switches 141 and 161 that connect PDEVs 142 and 162 via links 143, 144, 163, and 164. In this embodiment, the links 131, 132, 143, 144, 151, 152, 163, and 164 are PCIe links. The PDEV switches 141 and 161 are PCIe switches, and the PDEVs 142 and 162 are NVMe drives with dual ports. While the PDEV BOX 140 in FIG. 1 shows an example in which only two PDEVs are installed, any number of PDEVs can be installed in the PDEV BOX 140. The CPUs 103 and 123 control data transfer between the host devices 150 and 600 connected via the host IFs 102 and 122 and the PDEVs 142 and 162 connected via the PDEV switches 141 and 161. Furthermore, the CPUs 103 and 123 control data transfer between the controllers.

[0024] The memories 104 and 124 are main storage devices for the CPUs 103 and 123, respectively, and store programs (OS, storage control programs, etc.) executed by the CPUs 103 and 123, management tables referenced by the CPUs 103 and 123, etc. The memories 104 and 124 are also used as cache memories for the controllers 101 and 121, respectively.

[0025] The NTB 108 and the NTB 128 are connected via an inter-controller link 111, which is a PCIe link. The CPU 103 and the CPU 123 can communicate with each other via the inter-controller link 111. In this way, the storage device 100 configures a dual controller with the two controllers 101 and 121. The CPUs 103 and 123 transfer data received from the host that is duplicated between the two controllers and metadata used for controller control over the inter-controller link 111.

[0026] Memories 104 and 124 have OQs (Outbound Queues) and IQs (Inbound Queues) that are queues for controlling message transfer between CPUs 103 and 123 and host IFs 102 and 122. The OQs are queues that control message transfer from the host IFs to the CPUs, and the IQs are queues that control message transfer from the CPUs to the host IFs. Memory 104 has OQs 109 and IQs 110 that are queues for controlling message transfer between CPU 103 and host IF 102. Memory 124 also has OQs 129 and IQs 130 that are queues for controlling message transfer between CPU 123 and host IF 122.

[0027] In Figure 1, OQ109 is also displayed as "OQ01", IQ110 as "IQ01", OQ129 as "OQ11", and IQ130 as "IQ11".

[0028] The process in which the host IF 102, 122 stores data received from the host device 150, 600 in the memory 104, 124, or the process in which the host IF 102, 122 sends data stored in the memory 104, 124 to the host device 150, 600, and related processes will be referred to as host IO processing (hereinafter also referred to as "input / output processing").

[0029] Furthermore, the process of writing data stored in the memories 104 and 124 to the PDEVs 142 and 162, or the process of reading data stored in the PDEVs 142 and 162 to the memories 104 and 124, and related processes will be referred to as back-end processes.

[0030] Furthermore, the process of duplicating data received from the host devices 150 and 600 between the memory 104 and the memory 124 using the DMAs 107 and 127, and the processes related thereto, will be referred to as host data duplication processing.

[0031] 2 is a diagram showing an example of a memory space used by, for example, the CPU 123. A physical address space 201 includes an OS recognition area 202, which is a memory address area recognizable by the OS. Note that the memory space used by the CPU 103 has a similar configuration, and therefore a description thereof will be omitted.

[0032] The OS recognized area 202 includes an OS managed area 203, an area not managed by the OS 204 as an example of a first predetermined area, and an IO area 205. The OS managed area 203 is a memory area to which the OS allocates virtual addresses and uses it. The OS not managed area 204 is a memory area to which the OS does not allocate virtual addresses and is not used by the OS itself. The IO area 205 is a memory area that can be accessed by IO devices by reading and writing memory.

[0033] The CPU 123 executes the OS and a storage control program that controls data input / output processing in response to requests from the host device. The OS management area 203 includes an OS available area 206. The OS available area 206 stores the OS and processes of the storage control program.

[0034] The area not managed by the OS 204 includes a storage control program information storage area 207. The storage control program information storage area 207 contains the cache memory of the storage device 100, storage control program management information, a control queue for the host IF, management information for the host IF, a buffer area, a working area, and the like. The storage control program assigns a virtual address to a predetermined area, which is at least a part of the storage area of ​​the area not managed by the OS 204, and uses the predetermined area as the storage control program information storage area 207. The area not managed by the OS 204 is not normally used by, for example, the OS assigning a virtual address to it.

[0035] The storage control program information storage area 207 is used as, for example, a storage cache memory, a buffer area, or a working area, and includes management information for the storage control program, and control queues and management information for the host IF. The control queues of the host IF referred to here correspond to OQ129 and IQ130 as an example of a first control queue in the case of CPU123 as an example of a first processor, and correspond to OQ109 and IQ110 as an example of a second control queue in the case of CPU103.

[0036] The IO area 205 includes access areas for IO devices including the host IF 102, an access area for the NTB 108, etc. The CPU 123 can access the memory 104 and the host IF 102 of the other controller 101 via the access area for the NTB 108.

[0037] The storage control program assigns a virtual address to an area outside the OS management 204 as an example of a first predetermined area in memory 124 (first memory) to which the operating system does not assign a virtual address, and places OQ109 and IQ110 as examples of a first control queue in which data for input / output processing via the host interface is temporarily stored in the area outside the OS management 204 (placement unit).

[0038] The storage control program executes the following process during the restart process to restart the operating system. Here, this restart process is, for example, a process to restart the updated operating system following an operating system update process. First, the storage control program transfers input / output processing from CPU 123 (first processor) to CPU 103 (second processor), and releases the allocation of virtual addresses to the area outside OS management 204 (handover unit).

[0039] The storage control program executes a restart process to restart the updated operating system without initializing the area outside the OS management 204 on the hardware used by the operating system (restart unit). Next, after the restart process described above is completed, the storage control program reassigns a virtual address to the area outside the OS management 204 and resumes input / output processing by the first processor (e.g., CPU 123) (processing restart unit).

[0040] The CPU 103 is an example of a second processor, and accesses the host interface via a data transfer path that passes through the inter-controller link 111. The data transfer path includes a data transfer path that passes between two ports provided in the CPU 123 (first processor). The CPU 103 accesses the OQ 109 and the IQ 110, which are examples of a first control queue, via the data transfer path that passes through the inter-controller link 111.

[0041] CPU 123 includes a DMA 127, and CPU 103 includes a DMA 107. Before input / output processing is handed over from CPU 123 to CPU 103, data received from the host device is duplicated by data transfer from memory 124 (first memory) to memory 104 (second memory) by DMA 107 of CPU 123, and after input / output processing is handed over from CPU 123 to CPU 103, data received from the host device is duplicated by data transfer from memory 124 (first memory) to memory 104 by DMA 107 of CPU 103.

[0042] When the operating system is restarted, the storage control program stops the process of writing data received from the host device and stored in the memory 124 (first memory) to a storage medium by the CPU 123.

[0043] 3 is a flowchart showing an example of the procedure for OS update processing and the associated restart processing of a controller in the storage apparatus 100. This flowchart is executed by an OS update processing program 300 under the control of the CPU 123 of the controller that has received an instruction to update the OS of the controller 121 from the management terminal 174. In this embodiment, a case where the OS running on the CPU 123 of the controller 121 is updated will be described as an example.

[0044] First, the administrator of the storage device 100 instructs the controller 121 to update the OS via the management terminal 174. The CPU 123 of the controller 121 that receives the instruction executes the OS update processing program 300.

[0045] The OS update processing program 300 transfers the host IO processing that was being executed by the controller 121 to the controller 101 (step S301). Details of this host IO transfer processing will be described later. This processing allows the storage device 100 to continue host IO processing even during restart processing associated with OS update processing, etc., thereby maintaining availability. Furthermore, by continuing host IO processing during OS restart processing, it is not necessary to resend I / O requests from the host device during OS restart processing, and therefore it is possible to reduce the power consumption required to resend I / O requests.

[0046] Next, the OS update processing program 300 stops the storage control program that has been running on the CPU 123 of the controller 121 (step S302). The OS update processing program 300 may be included in the storage control program. In that case, in step S302, the parts of the storage control program other than the OS update processing program 300 are stopped. For example, the storage control program and the OS update processing program 300 are executed as separate processes, and the storage control program process is stopped.

[0047] Next, the OS update processing program 300 makes the storage control program information storage area (207 in FIG. 2) inaccessible via a virtual address in the memory 124 having a storage area used by the CPU 123 (step S303). In other words, the allocation of a virtual address to the storage control program information storage area 207 is cancelled by executing a munmap command or the like of the OS.

[0048] Next, the OS update processing program 300 executes OS update processing and reboot processing in the CPU 123 of the controller 121 (step S304). Here, the OS reboot processing employs a mechanism that does not involve hardware initialization, for example, a mechanism that enables live boot of a new kernel on the currently running kernel. For example, if the OS is Linux (registered trademark), kexec can be employed as such a mechanism. As a result, even if the OS is rebooted, the CPU, memory, and host IF are not initialized, so data stored in the memory area outside the OS's management is retained and the host IF can continue to operate.

[0049] After the OS is restarted, the OS update processing program 300 makes the storage control program information storage area 207 accessible again by a virtual address in the CPU 123 of the controller 121 (step S305). In other words, a virtual address is assigned to the storage control program information storage area 207 by executing an mmap command or the like of the OS.

[0050] Next, the OS update processing program 300 resumes the storage control program using data such as storage control program management information held in the storage control program information storage area 207 (step S306).

[0051] Next, the OS update processing program 300 resumes the host IO processing that was handed over to the controller 101 in step S301 in the controller 121 (step S307). Details of this host IO resumption processing will be described later.

[0052] As a result, the controller 121 can quickly resume operation of the storage control program while continuing host IO processing, compared to when performing OS restart processing that involves initializing hardware that cannot continue host IO processing.

[0053] 4 is a diagram illustrating an example of the configuration of OQ and IQ in the storage device 100. As an example, OQ 129 and IQ 130 will be described, but the same applies to the configuration of other OQs and IQs such as OQ 109 and IQ 110.

[0054] Both OQ129 and IQ130 store entries in a total of N elements numbered from 0 to N-1. In OQ129, the contents of an entry are, for example, a host IO command received from a host device. In IQ130, the contents of an entry are, for example, a response corresponding to a completed host IO command or a data transfer list instructed by the CPU to the host IF. Each entry also includes exchange identification information (i.e., exchange ID) that indicates which exchange in the host IO the entry relates to. An exchange refers to a series of operations related to read operations, write operations, etc. between the host and storage.

[0055] In the OQ129 of Figure 4, for example, entries are stored in the (i-1)th to (i+4)th elements. The other elements of OQ129 are empty. OQPI (Producer Index) 401 indicates the location of the element where the host IF will store the next entry. OQCI (Consumer Index) 402 indicates the location of the element where the entry to be read next by the CPU is stored. When OQPI401 and OQCI402 indicate the same element, this indicates that no unprocessed entries are stored in OQ129 and that the element is empty. In addition, the (i-1)th element stores the most recent entry that has been processed. By checking the exchange ID of this entry, the CPU can determine which exchange-related entry processing has been completed.

[0056] In the IQ130 of Figure 4, for example, entries are stored in the j-1st to i+3rd elements. The other elements of IQ130 are empty. IQPI411 indicates the location of the element where the CPU will store the next entry. IQCI412 indicates the location of the element where the entry to be read next by the host IF is stored. When IQPI411 and IQCI412 indicate the same element, this indicates that no unprocessed entries are stored in IQ130 and that the IQ130 is empty. In addition, the j-1st element stores the most recent entry that has been processed. By checking the exchange ID of this entry, the CPU can determine which exchange-related entry processing has been completed.

[0057] The queue indexes OQPI, OQCI, IQPI, and IQCI are stored at predetermined addresses in memory, or in registers of the host IF, or both, as necessary.

[0058] 5 is a diagram illustrating a data transfer path related to host IO processing before host IO takeover in the storage apparatus 100. In the illustrated example, the management terminal 174 and the like shown in FIG. 1 are omitted (the same applies to the following explanations). As an example, a data transfer path will be described for the case where the core 500 of the CPU 123 controls the host IF 122 in the controller 121.

[0059] The host IF 122 that receives the host IO from the host device 600 accesses the OQ 129 and IQ 130 in the memory 124 and their queue indexes OQPI and IQCI via a data transfer path 501 that passes through the CPU 123 .

[0060] Furthermore, the host IF 122 stores data received from the host device 600 in the memory 124 via the data transfer path 501 , or transmits data stored in the memory 124 to the host device 600 .

[0061] The core 500 accesses the OQ 129 in the memory 124 , its queue index OQPI, and the IQ 130 via a data transfer path 502 .

[0062] Furthermore, the core 500 accesses OQCI, which is the queue index of OQ 129, and IQPI, which is the queue index of IQ 130, in the host IF 122, via a data transfer path 503. Furthermore, the core 500 uses the DMA 127 to transfer data received from the host device 600 and stored in the memory 124 from the memory 124 to the memory 104 of the controller 101 via a data transfer path 504 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of the controller 101 and the memory 124 of the controller 121 (the host data duplication process described above).

[0063] FIG. 6 is a diagram illustrating a data transfer sequence related to host IO processing before host IO takeover.

[0064] Here, as an example, a case will be described in which the host IF 122 and the core 500 of the CPU 123 use the OQ 129 and IQ 130 stored in the memory 124. In Fig. 6, OQ 129 is represented as "OQ11" and IQ 130 is represented as "IQ11".

[0065] First, the host device 600 sends a host IO command 601 to the host IF 122 .

[0066] The host IF 122 that receives the host I / O command 601 enqueues an entry 602 including the command content to the OQ 129 (step S603).

[0067] Next, the host IF 122 updates the OQPI of the OQ 129 in the memory 124 to notify the core 500 that the entry 602 has been enqueued in the OQ 129 (step S604).

[0068] The core 500 checks whether there is an unprocessed entry in the OQ 129 by polling the OQPI of the OQ 129 (step S605). If there is an unprocessed entry, the core 500 reads the entry that stores the contents of the host IO command from the OQ 129 (step S606). Furthermore, the core 500 updates the OQCI of the OQ 129 in the host IF 122 (step S607).

[0069] Next, the core 500 enqueues an entry including a data transfer list corresponding to the host IO command 601 to the IQ 130 (step S608). Furthermore, the core 500 updates the IQPI of the IQ 130 in the host IF 122 (step S609).

[0070] The host IF 122, whose IQPI has been updated, reads an entry including the data transfer list from the IQ 130 (step S610).

[0071] Next, the host IF 122 transfers data between the host device 600 and the memory 124 in accordance with the data transfer list included in the entry read from the IQ 130 (step S611).

[0072] When the data transfer is complete, the host IF 122 updates the IQCI of the IQ 130 in the memory 124 (step S612).

[0073] In this way, the core 500 can process the host IO command 601 received by the host IF 122 .

[0074] FIG. 7 is a diagram illustrating an example of a P2P (peer-to-peer) data transfer path in the CPU 123. As shown in FIG.

[0075] The uncore 126 of the CPU 123 includes a PCIe root complex 701. The root complex 701 further includes multiple root ports, including root ports 702 and 703. The root port 702 is connected to the host IF 122, and the root port 703 is connected to the NTB 128. As shown in FIG. 1, the NTB 128 is connected to another controller 101 via the inter-controller link 111. Data transfer performed over a path 704 that passes through the root port 702, root complex 701, and root port 703 is called a P2P data transfer.

[0076] 8 is a flowchart showing an example of a host IO takeover processing procedure between controllers in the storage apparatus 100. This processing flow is executed in step S301 of the OS update processing program 300 in FIG. 3. Alternatively, this processing flow is executed by the CPU 103 or CPU 123 of the controller that has received a host IO takeover instruction from the management terminal 174. Hereinafter, this processing flow will be referred to as the host IO takeover processing program 800. As an example, a case will be described in which the controller 101 takes over host IO processing from the controller 121.

[0077] First, the host IO takeover processing program 800 stops the host IF 122 driver currently running on the CPU 123 of the controller 121 (step S801). Stopping the host IF driver here means stopping processing of the host IF control queue. Therefore, even if the host IF driver is stopped, the host IF is not initialized, so host link down or the like does not occur.

[0078] Next, the host IO takeover processing program 800 executes the host IF 122 driver in the CPU 103 of the controller 101 (step S802). Execution of the host IF driver here means the start of processing for the control queue of the host IF. Therefore, even if the host IF driver is executed, the host IF is not initialized, so host link down or the like does not occur. The host IF 122 driver running in the CPU 103 can take over the host IO processing of the host IF 122 driver that was running in the CPU 123 by checking the queue indexes of the OQ 129 and IQ 130. In other words, the host IF can continue to operate even if the entity operating the host IF control queue changes.

[0079] Next, the host IO takeover processing program 800 stops the backend processing being executed by CPU 123 of controller 121 (step S803). Since the data received from the host device is duplicated in memory 104 and memory 124, even if the backend processing of CPU 123 is stopped, as long as CPU 103 is executing the backend processing, the operation of the storage device 100 can continue. As a result, the host IO processing is taken over from controller 121 to controller 101.

[0080] 9 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover in the storage apparatus 100. As an example, a data transfer path when the core 900 of the CPU 103 belonging to the controller 101 controls the host IF 122 of the controller 121 will be described.

[0081] The host IF 122 that receives the host IO from the host device 600 accesses the OQ 129 and IQ 130 in the memory 124 and their queue indexes OQPI and IQCI via a data transfer path 901 that passes through the CPU 123 .

[0082] Furthermore, the host IF 122 stores data received from the host device 600 in the memory 124 via the data transfer path 901 , or transmits data stored in the memory 124 to the host device 600 .

[0083] The core 900 accesses the OQ 129 in the memory 124 , its queue index OQPI, and the IQ 130 via a data transfer path 902 that passes through the inter-controller link 111 and the CPU 123 .

[0084] Furthermore, the core 900 accesses OQCI, which is the queue index of the OQ 129, and IQPI, which is the queue index of the IQ 130, in the host IF 122, via a data transfer path 903 that passes through the inter-controller link 111 and the CPU 123. The data transfer path 903 includes a P2P data transfer path in the CPU 123.

[0085] Furthermore, the core 900 uses the DMA 107 to transfer data received from the host device 600 and stored in the memory 124 from the memory 124 to the memory 104 of the controller 101 via a data transfer path 904 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of the controller 101 and the memory 124 of the controller 121 (the host data duplication process described above).

[0086] FIG. 10 is a diagram illustrating a data transfer sequence related to host IO processing after host IO takeover in the storage apparatus 100.

[0087] Here, as an example, a case will be described in which the host IF 122 and the core 900 of the CPU 103 use the OQ 129 and IQ 130 stored in the memory 124. In Fig. 10, OQ 129 is represented as "OQ11" and IQ 130 is represented as "IQ11".

[0088] First, the host device 600 transmits a host IO command 1001 to the host IF 122. Upon receiving the host IO command 1001, the host IF 122 enqueues an entry 1002 including the command content to the OQ 129 (step S1003).

[0089] Next, the host IF 122 updates the OQPI of the OQ 129 in the memory 124 to notify the core 900 that the entry 1002 has been enqueued in the OQ 129 (step S1004).

[0090] The core 900 checks whether there are any unprocessed entries in the OQ 129 by polling the OQPI of the OQ 129 (step S1005). If there are any unprocessed entries, the core 900 reads the entry that stores the contents of the host I / O command from the OQ 129 (step S1006). Furthermore, the core 900 updates the OQCI of the OQ 129 in the host IF 122 (step S1007).

[0091] Next, the core 900 enqueues an entry including a data transfer list corresponding to the host IO command 1001 to the IQ 130 (step S1008). Furthermore, the core 900 updates the IQPI of the IQ 130 in the host IF 122 (step S1009).

[0092] The host IF 122, whose IQPI has been updated, reads an entry including the data transfer list from the IQ 130 (step S1010).

[0093] Next, the host IF 122 transfers data between the host device 600 and the memory 124 in accordance with the data transfer list included in the entry read from the IQ 130 (step S1011).

[0094] When the data transfer is complete, the host IF 122 updates the IQCI of the IQ 130 in the memory 124 (step S1012). In this way, the core 900 can process the host IO command 1001 received by the host IF 122.

[0095] 11 is a flowchart showing an example of a procedure for resuming host IO processing in a controller in the storage apparatus 100 that has handed over host IO processing to another controller due to controller OS update and restart processing. This processing flow is executed in step S307 of the OS update processing program 300 in FIG. 3. Alternatively, this processing flow is executed by the CPU 103 or CPU 123 of the controller that has received an instruction for host IO resume processing from the management terminal 174. Hereinafter, this processing flow will be referred to as the host IO resume processing program 1100. As an example, a case will be described in which the controller 121 resumes host IO processing after the controller 101 has taken over host IO processing from the controller 121.

[0096] First, the host IO resume processing program 1100 stops the host IF 122 driver currently running on the CPU 103 of the controller 101 (step S1101). Stopping the host IF driver here means stopping processing of the host IF control queue. Therefore, even if the host IF driver is stopped, the host IF is not initialized, so host link down or the like does not occur.

[0097] Next, the host IO resume processing program 1100 resumes the host IF 122 driver in the CPU 123 of the controller 121 (step S1102). Resuming the host IF driver here means resuming processing for the control queue of the host IF. Therefore, even if the host IF driver is resumed, the host IF is not initialized, so host link down and the like do not occur. The host IF 122 driver running on the CPU 123 can take over the host IO processing of the host IF 122 driver that was running on the CPU 103 by checking the queue indexes of the OQ 129 and IQ 130. In other words, the host IF can continue to operate even if the entity operating the host IF control queue changes.

[0098] Next, the host IO resume processing program 1100 resumes the back-end processing in the CPU 123 of the controller 121 (step S1103). As a result, the host IO processing is taken over from the controller 101 to the controller 121.

[0099] The OS update procedure in this embodiment described above can be summarized as follows. As an example, assume that in a dual-controller storage apparatus 100, controller 121 is the target of the OS update and controller 101 is not the target of the OS update. In addition, the storage control program information storage area 207, which includes the control queue and management information of the host IF, is located in the area outside the OS management 204.

[0100] First, the OS update processing program 300 of the storage apparatus 100 transfers the host IO processing of the controller 121 from the core 500 of the CPU 123 of the controller 121 to the core 900 of the CPU 103 of the controller 101. The CPU 103 of the controller 101 accesses the host IF 122 of the controller 121 via the inter-controller link 111 and the P2P data transfer path of the CPU 123, and controls the host IO processing.

[0101] Furthermore, the OS update processing program 300 causes the back-end processing in the controller 121 to be performed by the CPU 103 of the controller 101, rather than by the CPU 123 of the controller 121.

[0102] Next, the OS update processing program 300 makes the storage control program information storage area 207 inaccessible using a virtual address.

[0103] Then, the CPU 123 of the controller 121, which is no longer performing host IO processing and backend processing, performs OS update processing and restart processing that does not involve initialization of hardware including the CPU 123, host IF 122, and memory 124. During this processing, the CPU 103 of the controller 101 continues host IO processing of the host IF 122 of the controller 121. Furthermore, the CPU 103 of the controller 101 performs host data duplication processing, which duplicates data received from the host device 600 between the memory 104 of the controller 101 and the memory 124 of the controller 121.

[0104] After the OS is restarted, the OS update processing program 300 makes the storage control program information storage area 207 accessible by virtual address.

[0105] Then, the OS update processing program 300 causes the core 500 of the CPU 123 of the controller 121 to resume the host IO processing of the host IF 122 that had been taken over by the core 900 of the CPU 103 of the controller 101 .

[0106] As a result, the storage apparatus 100 according to this embodiment can execute OS update processing and reboot processing while maintaining the availability of the dual controllers and data redundancy.

[0107] Furthermore, if controller 101 is the target of the OS update and controller 121 is not the target of the OS update, the OS update processing program 300 can be controlled to transfer the host IO processing of controller 101 from core 900 of CPU 103 of controller 101 to core 500 of CPU 123 of controller 121.

[0108] The storage device 100 according to this embodiment includes a controller 121 (first controller) including a CPU 123 (first processor) that controls input / output processing of data in response to a request from a host device via a host interface that controls a protocol for communication with the host device, and a memory 124 (first memory) having a storage area used by the CPU 123, at least one controller 101 (second controller) that includes a CPU 103 (second processor) that controls input / output processing of data in response to a request from the host device via a host interface that controls a protocol for communication with the host device, and a memory 104 (second memory) having a storage area used by the CPU 103, and an inter-controller link 111 that connects the controller 121 and the controller 101. At least the CPU 123 executes an operating system and a storage control program that controls input / output processing of data in response to a request from the host device. The storage control program executes the following steps: assigning a virtual address to an area outside the OS management 204 (first predetermined area) in the memory 124 to which the operating system does not assign a virtual address, and arranging a first control queue in the area outside the OS management 204 in which data of input / output processing via the host interface is temporarily stored; a handover step in which, during a restart process to restart the operating system, the input / output processing is handed over from the CPU 123 to the CPU 103 and the allocation of the virtual address to the area outside the OS management 204 is released; a restart step in which the restart process to restart the operating system is executed without initializing the area outside the OS management 204 on the hardware used by the operating system; and a process restart step in which, after the restart process is completed, the virtual address is reassigned to the area outside the OS management 204 and the input / output processing by the CPU 123 is resumed.

[0109] In this way, even if one of the multiple controllers 101, 121 stops due to a restart process accompanying an operating system update process, it is possible to continue processing IO requests from the host device by handing over from the CPU 123 of one controller 121 to the CPU 103 of the other controller 101. Furthermore, in this way, data received from the host device can be duplicated to ensure reliability.

[0110] The CPU 103 is an example of a second processor, and accesses the host interface via a data transfer path that passes through the inter-controller link 111. The data transfer path includes a data transfer path that passes between two ports provided in the CPU 123 (first processor). The CPU 103 accesses the OQ 109 and the IQ 110, which are examples of a first control queue, via the data transfer path that passes through the inter-controller link 111.

[0111] The CPU 123 includes a DMA 127, and the CPU 103 includes a DMA 107. Before the I / O processing is handed over from the CPU 123 to the CPU 103, the data received from the host device is duplicated by a data transfer from the memory 124 (first memory) to the memory 104 (second memory) by the DMA 107 of the CPU 123, and after the I / O processing is handed over from the CPU 123 to the CPU 103, the data received from the host device is duplicated by a data transfer from the memory 124 (first memory) to the memory 104 by the DMA 107 of the CPU 103. In this way, it is possible to continuously process I / O requests from the host device before and after the above-mentioned handover, and reliability can be improved.

[0112] When the operating system is restarted, the storage control program stops the process of writing data received from the host device and stored in memory 124 (first memory) to a storage medium by CPU 123. In this way, reliability can be ensured.

[0113] (2) Second embodiment A storage device according to the second embodiment will be described with reference to Figures 12 to 15. The configuration of the storage device according to the second embodiment is the same as that of the storage device according to the first embodiment shown in Figures 1 to 11, except for the differences described below, and therefore a description of the similarities will be omitted. In this embodiment, too, the process of restarting the OS of the controller of the storage device at any timing will be described taking as an example a process of restarting the OS in conjunction with an update process of the OS of the controller, but the process is not limited to this. For example, the OS of the controller of the storage device may be restarted when the administrator of the storage device determines it is necessary.

[0114] 12 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover in the storage apparatus 1200. Here, similar to the storage apparatus 100 according to the first embodiment, it is assumed that the host IO received by the host IF 1222 is taken over from the controller 1221 to the controller 1201.

[0115] The storage device 1200 has the same configuration as the storage device 100, except for the controllers 1201 and 1221. The controllers 1201 and 1221 have the same configuration as the controllers 101 and 121, except for the host IFs 1202 and 1222.

[0116] Host IFs 1202 and 1222 differ from host IFs 102 and 122 in that a different OQ and IQ pair can be assigned to each core of the CPU that controls them. For example, when core 500 of CPU 123 controls host IF 1222, it uses OQ 1229 and IQ 1230 in memory 124. On the other hand, when core 900 of CPU 103 controls host IF 1222, it uses OQ 1209 and IQ 1210 in memory 104. Then, an instruction from CPU 103 or CPU 123 to host IF 1222 determines which OQ and IQ pair host IF 1222 will access.

[0117] As an example, a data transfer path when the core 900 of the CPU 103 belonging to the controller 1201 controls the host IF 1222 of the controller 1221 will be described.

[0118] The host IF 1222, which receives host IO from the host device 600, accesses the OQ 1209, IQ 1210 and their queue indexes OQPI and IQCI in the memory 104 via a data transfer path 1211 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. The data transfer path 1211 includes a P2P data transfer path in the CPU 123.

[0119] The host IF 1222 also stores data received from the host device 600 in the memory 124 or transmits data stored in the memory 124 to the host device 600 via the data transfer path 1212 .

[0120] The core 900 accesses the OQ 1209 in the memory 104 , its queue index OQPI, and the IQ 1210 via a data transfer path 1213 .

[0121] Furthermore, the core 900 accesses OQCI, which is the queue index of the OQ 1209, and IQPI, which is the queue index of the IQ 1210, in the host IF 1222, via a data transfer path 1214 that passes through the inter-controller link 111 and the CPU 123. The data transfer path 1214 includes a P2P data transfer path in the CPU 123.

[0122] Furthermore, the core 900 uses the DMA 107 to transfer data received from the host device 600 and stored in the memory 124 from the memory 124 to the memory 104 of the controller 101 via a data transfer path 1215 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of the controller 1201 and the memory 124 of the controller 1221 (the host data duplication process described above).

[0123] The data transfer path when the core 500 of the CPU 123 belonging to the controller 1221 controls the host IF 1222 of the controller 1221 is the same as that shown in FIG. 5, and therefore the description thereof will be omitted.

[0124] FIG. 13 is a diagram illustrating a data transfer sequence related to host IO processing after host IO takeover in the storage apparatus 1200.

[0125] Here, as an example, a case will be described in which the host IF 1222 and the core 900 of the CPU 103 use the OQ 1209 and IQ 1210 stored in the memory 104. In Fig. 13, the OQ 1209 is represented as "OQ02" and the IQ 1210 is represented as "IQ02".

[0126] First, the host device 600 transmits a host IO command 1301 to the host IF 1222. Upon receiving the host IO command 1301, the host IF 1222 enqueues an entry 1302 including the command content to the OQ 1209 (step S1303).

[0127] Next, the host IF 1222 updates the OQPI of the OQ 1209 in the memory 104 to notify the core 900 that the entry 1302 has been enqueued in the OQ 1209 (step S1304).

[0128] The core 900 checks whether there are any unprocessed entries in the OQ1209 by polling the OQPI of the OQ1209 (step S1305). If there are any unprocessed entries, the core 900 reads the entry that stores the contents of the host I / O command from the OQ1209 (step S1306). Furthermore, the core 900 updates the OQCI of the OQ1209 in the host IF 1222 (step S1307).

[0129] Next, the core 900 enqueues an entry including a data transfer list corresponding to the host IO command 1301 to the IQ 1210 (step S1308). Furthermore, the core 900 updates the IQPI of the IQ 1210 in the host IF 1222 (step S1309).

[0130] The host IF 1222, whose IQPI has been updated, reads an entry including the data transfer list from the IQ 1210 (step S1310).

[0131] Next, the host IF 1222 transfers data between the host device 600 and the memory 124 in accordance with the data transfer list included in the entry read from the IQ 1210 (step S1311).

[0132] When the data transfer is complete, the host IF 1222 updates the IQCI of the IQ 1210 in the memory 104 (step S1312). In this way, the core 900 of the CPU 103 can process the host IO command 1301 received by the host IF 1222.

[0133] 14 is a flowchart showing an example of a host IO takeover processing procedure between controllers in the storage device 1200. This processing flow is executed in step S301 of the OS update processing program 300 in FIG. 3. Alternatively, this processing flow is executed by the CPU 103 or CPU 123 of the controller that has received a host IO takeover instruction from the management terminal. Hereinafter, this processing flow will be referred to as the host IO takeover processing program 1400. As an example, a case will be described in which the controller 1201 takes over host IO processing from the controller 1221.

[0134] First, the host IO takeover processing program 1400 executes the host IF 1222 driver on the CPU 103 of the controller 1201 (step S1401). At this time, the OQ 1209 and IQ 1210 are empty, and host IO processing using them has not yet been performed. Execution of the host IF driver here means the start of processing for the control queue of the host IF. Therefore, even if the host IF driver is executed, the host IF is not initialized, so host link down, etc. does not occur.

[0135] Next, the host IO takeover processing program 1400 instructs the host IF 1222 to switch queues (step S1402). Before receiving the queue switch instruction, the host IF 1222 enqueues entries related to the host IO commands received from the host device into OQ 1229. After receiving the queue switch instruction, the host IF 1222 enqueues entries related to host IO commands with new exchange IDs received thereafter into OQ 1209. While uncompleted entries remain in OQ 1229, host IO processing related to OQ 1229 and IQ 1230 and host IO processing related to OQ 1209 and IQ 1210 are executed in parallel. After the queue switch instruction, no new entries are enqueued into OQ 1229, so eventually there will be no uncompleted entries in OQ 1229 and IQ 1230.

[0136] Next, the host IO takeover processing program 1400 waits until OQ1229 and IQ1230 become empty (step S1403: No). If OQ1229 and IQ1230 become empty (step S1403: Yes), the host IO takeover processing program 1400 proceeds to step S1404.

[0137] Next, the host IO takeover processing program 1400 stops the host IF 1222 driver currently running on the CPU 123 of the controller 1221 (step S1404). Stopping the host IF driver here means stopping processing of the host IF control queue. Therefore, even if the host IF driver is stopped, the host IF is not initialized, so host link down, etc., does not occur.

[0138] Next, the host IO takeover processing program 1400 stops the backend processing being executed by the CPU 123 of the controller 1221 (step S1405). Since the data received from the host device is duplicated in the memories 104 and 124, even if the backend processing of the CPU 123 is stopped, the operation of the storage device 1200 can continue as long as the CPU 103 is executing the backend processing. As a result, the host IO processing is taken over from the controller 1221 to the controller 1201.

[0139] 15 is a flowchart showing an example of a procedure for resuming host IO processing in a controller in the storage apparatus 1200 that has handed over host IO processing to another controller. This processing flow is executed in step S307 of the OS update processing program 300 in FIG. 3. Alternatively, it is executed by the CPU 103 or CPU 123 of the controller that has received an instruction for host IO resumption processing from the management terminal. Hereinafter, this processing flow will be referred to as the host IO resumption processing program 1500. As an example, a case will be described in which controller 1221 resumes host IO processing after controller 1201 has taken over the host IO processing of controller 1221.

[0140] First, the host IO resume processing program 1500 resumes the host IF 1222 driver in the CPU 123 of the controller 1221 (step S1501). At this time, the OQ 1229 and IQ 1230 are empty, and host IO processing using them has not yet been performed. Resuming the host IF driver here means resuming processing for the control queue of the host IF. Therefore, even if the host IF driver is resumed, the host IF is not initialized, so host link down, etc. does not occur.

[0141] Next, the host IO resume processing program 1500 resumes the back-end processing in the CPU 123 of the controller 1221 (step S1502).

[0142] Next, the host IO resume processing program 1500 instructs the host IF 1222 to switch queues (step S1503). Before receiving the queue switch instruction, the host IF 1222 enqueues entries related to the host IO commands received from the host machine into OQ 1209. After receiving the queue switch instruction, the host IF 1222 enqueues entries related to host IO commands with new exchange IDs received thereafter into OQ 1229. While uncompleted entries remain in OQ 1209, host IO processing related to OQ 1209 and IQ 1210 and host IO processing related to OQ 1229 and IQ 1230 are executed in parallel. After the queue switch instruction, no new entries are enqueued into OQ 1209, so eventually there will be no uncompleted entries in OQ 1209 and IQ 1210.

[0143] Next, the host IO resume processing program 1500 waits until OQ 1209 and IQ 1210 become empty (step S1504: No). If OQ 1209 and IQ 1210 become empty (step S1504: Yes), the host IO resume processing program 1500 proceeds to step S1505.

[0144] Next, the host IO resume processing program 1500 stops the host IF 1222 driver currently running on the CPU 103 of the controller 1201 (step S1505). Stopping the host IF driver here means stopping processing for the control queue of the host IF. Therefore, even if the host IF driver is stopped, the host IF is not initialized, so host link down or the like does not occur. As a result, host IO processing is taken over from the controller 1201 to the controller 1221.

[0145] According to this embodiment, similar to the storage device 100 according to the first embodiment, it is possible to execute OS update processing and reboot processing while maintaining the availability of the dual controllers and data redundancy. Furthermore, by continuing host IO processing during OS reboot processing, it is possible to reduce the power consumption required to retransmit I / O requests from the host device during OS reboot processing.

[0146] As described above, the storage device 1200 according to the second embodiment is characterized by including a host IF to which multiple OQ and IQ pairs can be assigned. As a result, the core 900 of the CPU 103 accesses the OQ 1209 and IQ 1210 stored in the memory 104 directly connected to the CPU 103 to control the host IF 1222. Furthermore, the core 500 of the CPU 123 accesses the OQ 1229 and IQ 1230 stored in the memory 124 directly connected to the CPU 123 to control the host IF 1222. Therefore, the time required to access the OQ, IQ, and their queue indexes can be reduced compared to the case where the OQ and IQ stored in the memory of the other controller are accessed, as in the storage device 100 according to the first embodiment. As a result, the storage device 1200 can reduce the wait time of the cores involved in host IO processing, thereby improving performance compared to the storage device according to the first embodiment.

[0147] In this embodiment, the memory 104 (second memory) has OQ109 and IQ110 as examples of second control queues for the host interface, and the host interface receives a switching instruction specifying either the first control queue (OQ129 and IQ130) or the second control queue (OQ109 and IQ110) as the enqueue destination for a request received from the host device, and then switches the enqueue destination control queue for a request received from the host device that is assigned an identifier for a series of operations related to the new request received from the host device. In this way, it is possible to achieve the same effects as in the first embodiment, and by switching the control queue as described above reliably, it is possible to continuously process IO requests from the host device before and after the above-mentioned handover, and it is possible to ensure reliability by duplicating the data received from the host device.

[0148] During the operating system restart process, the storage control program receives a switch instruction from the host interface to switch the enqueue destination of requests received from the host device from the first control queue (OQ129 and IQ130) to the second control queue (OQ109 and IQ110), and then executes a restart process without initializing the OS non-management area 204 (first predetermined area) on the hardware used by the operating system after the first control queue (OQ129 and IQ130) becomes empty. In this way, it is possible to achieve the same effects as the first embodiment, and by switching the control queue while confirming that one of the control queues has become empty as described above, it is possible to reliably continue processing I / O requests from the host device before and after the above-mentioned handover, and it is possible to ensure reliability by duplicating the data received from the host device.

[0149] During the restart process of the operating system, the storage control program receives a switch instruction from the host interface to switch the enqueue destination of requests received from the host device from the second control queue (OQ109 and IQ110) to the first control queue (OQ129 and IQ130), and then stops input / output processing with the host device by CPU103 (second processor) after the second control queue becomes empty. In this way, it is possible to achieve the same effects as in the first embodiment, and it is also possible to reliably continue processing IO requests from the host device before and after the above-mentioned takeover, and it is also possible to ensure reliability by duplicating data received from the host device.

[0150] (3) Third embodiment A storage device according to the third embodiment will be described with reference to Figures 16 and 17. The configuration of the storage device according to the third embodiment is the same as that of the storage device according to the first embodiment shown in Figures 1 to 11, except for the differences described below, and therefore a description of the similarities will be omitted. In this embodiment, too, the process of restarting the OS of the controller of the storage device at any timing will be described taking as an example a process of restarting the OS in conjunction with an update process of the OS of the controller, but the process is not limited to this. For example, the OS of the controller of the storage device may be restarted when the administrator of the storage device determines it is necessary.

[0151] 16 is a diagram illustrating a data transfer path related to host IO processing before host IO takeover in the storage apparatus 1600. Here, similar to the storage apparatus 100 according to the first embodiment, it is assumed that the host IO received by the host IF 122 is taken over from the controller 1621 to the controller 1611.

[0152] The storage apparatus 1600 has the same configuration as the storage apparatus 100, except for the controllers 1611 and 1621. The controller 1611 connects the host IF 102 to the CPU 103 via the PCIe switch 1612. Similarly, the controller 1621 connects the host IF 122 to the CPU 123 via the PCIe switch 1622. The PCIe switches 1612 and 1622 respectively include NTB ports 1613 and 1623, which are switch ports equipped with an NTB function. Furthermore, the NTB port 1613 of the PCIe switch 1612 and the NTB port 1623 of the PCIe switch 1622 are connected by an inter-controller link 1631. The CPU 103 can access the host IF 122 via the PCIe switch 1612, the inter-controller link 1631, and the PCIe switch 1622.

[0153] The CPU 123 can access the host IF 102 via the PCIe switch 1622, the inter-controller link 1631, and the PCIe switch 1612. Except for these points, the controllers 1611 and 1621 have the same configuration as the controllers 101 and 121. Note that the PCIe switch 1612 can connect multiple host IFs to the CPU 103, but only one host IF 102 is shown in Fig. 16. Similarly, the PCIe switch 1622 can connect multiple host IFs to the CPU 123, but only one host IF 122 is shown in Fig. 16.

[0154] Here, as an example, a data transfer path when the core 500 of the CPU 123 controls the host IF 122 in the controller 1621 will be described.

[0155] The host IF 122 that receives the host IO from the host device 600 accesses the OQ 129 and IQ 130 and their queue indexes OQPI and IQCI in the memory 124 via the PCIe switch 1622 and the data transfer path 1601 that passes through the CPU 123 .

[0156] Furthermore, the host IF 122 stores data received from the host device 600 in the memory 124 or transmits data stored in the memory 124 to the host device 600 via the data transfer path 1601 .

[0157] The core 500 accesses the OQ 129 in the memory 124 , its queue index OQPI, and the IQ 130 via the data transfer path 1602 .

[0158] Furthermore, the core 500 accesses OQCI, which is the queue index of the OQ 129 , and IQPI, which is the queue index of the IQ 130 , in the host IF 122 via a data transfer path 1603 that passes through the PCIe switch 1622 .

[0159] Furthermore, the core 500 uses the DMA 127 to transfer data received from the host device 600 and stored in the memory 124 from the memory 124 to the memory 104 of the controller 1611 via a data transfer path 1604 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of the controller 1611 and the memory 124 of the controller 1621 (the host data duplication process described above).

[0160] 17 is a diagram illustrating a data transfer path related to host IO processing after host IO takeover in the storage device 1600. As an example, the data transfer path when the core 900 of the CPU 103 belonging to the controller 1611 controls the host IF 122 of the controller 1621 will be described.

[0161] The host IF 122 that receives the host IO from the host device 600 accesses the OQ 129 and IQ 130 in the memory 124 and their queue indexes OQPI and IQCI via a data transfer path 1701 that passes through the CPU 123 .

[0162] Furthermore, the host IF 122 stores data received from the host device 600 in the memory 124 or transmits data stored in the memory 124 to the host device 600 via the data transfer path 1701 .

[0163] The core 900 accesses the OQ 129 in the memory 124 , its queue index OQPI, and the IQ 130 via a data transfer path 1702 that passes through the inter-controller link 111 and the CPU 123 .

[0164] Furthermore, the core 900 accesses OQCI, which is the queue index of the OQ 129 in the host IF 122, and IQPI, which is the queue index of the IQ 130, via a data transfer path 1703 that passes through the PCIe switch 1612, the inter-controller link 1631, and the PCIe switch 1622.

[0165] Furthermore, the core 900 uses the DMA 107 to transfer data received from the host device 600 and stored in the memory 124 from the memory 124 to the memory 104 of the controller 101 via a data transfer path 1704 that passes through the CPU 123, the inter-controller link 111, and the CPU 103. This allows the data received from the host device 600 to be duplicated in the memory 104 of the controller 1611 and the memory 124 of the controller 1621 (the host data duplication process described above).

[0166] Other operations of the storage device 1600 are the same as those of the storage device 100 according to the first embodiment, and therefore a description thereof will be omitted.

[0167] As described above, the storage apparatus 1600 according to the third embodiment is characterized in that the CPU 103 of the controller 1611 accesses the host IF 122 of the controller 1621 via the inter-controller link 1631 to control host IO processing. According to this embodiment, it is possible to execute OS update processing and reboot processing while maintaining dual controller availability and data redundancy, without using a CPU P2P data transfer path as in the storage apparatus 100 according to the first embodiment. Furthermore, by continuing host IO processing during OS reboot processing, it is possible to reduce the power consumption required to resend an I / O request from the host apparatus during OS reboot processing.

[0168] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to facilitate a better understanding of the present invention, and are not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations. Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be implemented in hardware, in part or in whole, by, for example, designing an integrated circuit. Furthermore, the above-described configurations, functions, etc. may be implemented in software by a processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored in storage devices such as nonvolatile semiconductor memory, hard disk drives, and SSDs, or in computer-readable non-transitory data storage media such as IC cards, SD cards, and DVDs. Furthermore, the control lines and information lines shown are those considered necessary for explanation, and not all control lines and information lines are necessarily shown in the product. In reality, it can be assumed that almost all components are interconnected. Furthermore, the elements described in parallel in this embodiment may be configured such that at least one of the elements is connected in series to the other elements. [Industrial Applicability]

[0169] The present invention can be applied to a storage device related to a technology in which a processor controls a host interface and performs input / output processing of data in response to an IO request from a host device. [Explanation of symbols]

[0170] 100, 1200, 1600...storage device, 101, 121, 1201, 1221, 1611, 1621...controller, 102, 122, 1202, 1222...host interface, 103, 123...CPU, 104, 124...memory, 105, 125...multiple cores, 111, 1211, 1631...inter-controller link, 141, 161, 1612, 1622...PCIe switch, 140...drive box, 108, 128...non-transparent bridge, 109, 129, 1209, 1229...outbound queue, 110, 130, 1210, 1230...inbound queue, 500, 900...core

Claims

1. a first controller including a first processor that controls input / output processing of data in response to a request from a host device via a host interface that controls a protocol for communication with the host device, and a first memory having a storage area used by the first processor; at least one second controller including a second processor that controls input / output processing of data in response to a request from the host device via a host interface that controls a protocol for communication with the host device, and a second memory having a storage area used by the second processor; an inter-controller link connecting the first controller and the second controller; A storage device comprising: the first processor executes an operating system and a storage control program that controls input / output processing of data in response to requests from the host device; The storage control program an allocation unit that allocates a virtual address to a first predetermined area in the first memory to which the operating system does not allocate a virtual address, and allocates a first control queue in the first predetermined area, in which data of input / output processing via a host interface is temporarily stored; During the reboot process of rebooting the operating system, a takeover unit that takes over the input / output processing from the first processor to the second processor and releases the allocation of a virtual address to the first predetermined area; a restart unit that executes a restart process to restart the operating system without initializing the first predetermined area on the hardware used by the operating system; a processing restart unit that, after the restart processing is completed, reassigns a virtual address to the first predetermined area and restarts input / output processing by the first processor; A storage device comprising:

2. The second processor accessing the host interface via a data transfer path passing through the inter-controller link; The storage device according to claim 1 .

3. The data transfer path is a data transfer path passing between two ports of the first processor; 3. The storage device according to claim 2.

4. The second processor accessing the first control queue via a data transfer path passing through the inter-controller link; The storage device according to claim 1 .

5. the first processor and the second processor each include a DMA (Direct Memory Access); before the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by data transfer from the first memory to the second memory by DMA of the first processor; after the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by data transfer from the first memory to the second memory by DMA of the second processor; The storage device according to claim 1 .

6. The storage control program When restarting the operating system, a process of writing the data received from the host device and stored in the first memory to a storage medium by the first processor is stopped. The storage device according to claim 1 .

7. The second memory includes: a second control queue for the host interface; The host interface receiving a switching instruction specifying either the first control queue or the second control queue as an enqueue destination for a request received from the host device; Next, switching the control queue to which the request received from the host device is enqueued based on the identifier of a series of operations associated with the new request received from the host device; The storage device according to claim 1 .

8. The storage control program During the reboot process of the operating system, after the host interface receives the switching instruction to switch the enqueue destination of the request received from the host device from the first control queue to the second control queue and after the first control queue becomes empty, it executes a reboot process that does not involve initialization of the first predetermined area on the hardware used by the operating system; 8. The storage device according to claim 7.

9. The storage control program During the reboot process of the operating system, After the host interface receives the switch instruction to switch the enqueue destination of the request received from the host device from the second control queue to the first control queue, and after the second control queue becomes empty, stopping input / output processing with the host device by the second processor; 9. The storage device according to claim 8.

10. The restart process is A process of rebooting the operating system after updating the operating system in accordance with the update process. The storage device according to claim 1 .

11. a first controller including a first processor that controls input / output processing of data in response to a request from a host device via a host interface that controls a protocol for communication with the host device, and a first memory having a storage area used by the first processor; at least one second controller including a second processor that controls input / output processing of data in response to a request from the host device via a host interface that controls a protocol for communication with the host device, and a second memory having a storage area used by the second processor; an inter-controller link connecting the first controller and the second controller; A method for restarting a storage device, comprising: the first processor executes an operating system and a storage control program that controls input / output processing of data in response to requests from the host device; The storage control program an allocation step of allocating a virtual address to a first predetermined area in the first memory to which the operating system does not allocate a virtual address, and allocating a first control queue in the first predetermined area, in which data of input / output processing via a host interface is temporarily stored; During the reboot process of rebooting the operating system, a takeover step of taking over the input / output processing from the first processor to the second processor and deallocating the virtual address for the first predetermined area; a restart step of executing a restart process for restarting the operating system without initializing the first predetermined area on the hardware used by the operating system; a processing restart step of reassigning a virtual address to the first predetermined area and restarting input / output processing by the first processor after the restart processing is completed; A method for restarting a storage device, comprising:

12. the first processor and the second processor each include a DMA (Direct Memory Access); before the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by data transfer from the first memory to the second memory by DMA of the first processor; after the input / output processing is handed over from the first processor to the second processor, the data received from the host device is duplicated by data transfer from the first memory to the second memory by DMA of the second processor; 12. The method for restarting a storage device according to claim 11.

13. The storage control program When restarting the operating system, the first processor stops writing the data received from the host device and stored in the first memory to a storage medium.

12. The method for restarting a storage device according to claim 11.

14. The second memory includes: a second control queue for the host interface; The host interface receiving a switching instruction specifying either the first control queue or the second control queue as an enqueue destination for a request received from the host device; Next, switching the control queue to which the request received from the host device is enqueued based on the identifier of a series of operations associated with the new request received from the host device; 12. The method for restarting a storage device according to claim 11.

15. The storage control program During the reboot process of the operating system, after the host interface receives the switching instruction to switch the enqueue destination of the request received from the host device from the first control queue to the second control queue and after the first control queue becomes empty, it executes a reboot process that does not involve initialization of the first predetermined area on the hardware used by the operating system; 15. The method for restarting a storage device according to claim 14.

16. During the reboot process of the operating system, After the host interface receives the switch instruction to switch the enqueue destination of the request received from the host device from the second control queue to the first control queue, and after the second control queue becomes empty, stopping input / output processing with the host device by the second processor; 16. The method for restarting a storage device according to claim 15.

17. The restart process is A reboot of the operating system after updating in accordance with the update process of the operating system.

12. The method for restarting a storage device according to claim 11.

Images