WO2017185706A1 - 系统升级方法和系统升级装置 - Google Patents

系统升级方法和系统升级装置 Download PDF

Info

Publication number
WO2017185706A1
WO2017185706A1 PCT/CN2016/104446 CN2016104446W WO2017185706A1 WO 2017185706 A1 WO2017185706 A1 WO 2017185706A1 CN 2016104446 W CN2016104446 W CN 2016104446W WO 2017185706 A1 WO2017185706 A1 WO 2017185706A1
Authority
WO
WIPO (PCT)
Prior art keywords
target state
upgrade
accessory
desired target
state
Prior art date
Application number
PCT/CN2016/104446
Other languages
English (en)
French (fr)
Inventor
梁永贵
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2017185706A1 publication Critical patent/WO2017185706A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44578—Preparing or optimising for loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44573—Execute-in-place [XIP]

Definitions

  • the present invention relates to the field of storage systems, and in particular, to a system upgrade method and a system upgrade apparatus.
  • a storage system usually consists of storage devices such as storage servers. It has its own interface and protocol. It is connected to the host computer through coaxial cable, network cable, or optical fiber. It serves as a data storage center and provides storage services for the computer host.
  • the storage system undertakes data of various business systems and needs to provide 7x24 hours of uninterrupted service.
  • the upgrade of the version adds difficulty. For example, in order to reduce the impact on the business, the upgrade window of the storage system is usually arranged at night, and requires the cooperation of multiple application departments.
  • the micro-code version upgrade mode that is commonly used is a “one-click” upgrade.
  • the storage system operates according to a preset process, for example, a dual control (two controllers), for example, “one-click” "Upgrade to: first use the first controller to handle dual services, upgrade the microcode version of the second controller, and wait for the second controller to complete the upgrade, the second controller to undertake the business, upgrade
  • the microcode version of a controller after both controllers are upgraded, equalize the services on both controllers.
  • the system upgrade method and the system upgrade device provided by the application are in the process of upgrading the microcode version.
  • Human intervention can be used to eliminate hardware failures or trigger software interruptions caused by software bugs, and the micro-code version upgrade of the entire system can be upgraded into multiple stages to avoid the hardware failure or the software bug caused by the upgrade process.
  • the microcode version is rolled back or the service is interrupted to improve the success rate of the microcode version upgrade.
  • the application provides a system upgrade method, where the system upgrade method includes: the main controller updates all the attachments involved in the system upgrade, that is, the upgrade target status of the first attachment to the first desired target state, that is, Updating the upgrade target status of the first accessory to the desired target state that the first accessory upgrade is expected to be achieved during the upgrade phase of the system; after updating the upgrade target of the first accessory to the first desired target state, the primary controller determines The attachment of the first attachment in the first attachment is different from the first desired target state, that is, the second attachment; and instructing to upgrade the second attachment from the controller to determine whether the status of the upgraded second attachment reaches the first expectation a target state; when the state of the upgraded second accessory does not reach the first desired target state, the main controller instructs the slave controller to suspend the upgrade, and prompts the second accessory not to successfully upgrade to the first desired target state of the obstacle information, In order to facilitate the system upgrade staff to use the obstacle information as the basis for manual intervention.
  • the system upgrade method provided by the present application is performed by dividing the entire system upgrade into multiple stages, and setting a desired target state for each stage of the upgrade, and determining the accessories to be upgraded and upgrading by comparing the status of each accessory with the desired target state.
  • the system automatically suspends the upgrade and prompts that the fault information of the target state is not upgraded, so that the staff of the system upgrade can manually intervene according to the obstacle information and release the report.
  • the barrier and manual triggering continue to perform the upgrade, which improves the success rate of the system's microcode version upgrade.
  • the system upgrade method before the main controller updates the upgrade target status of the first accessory to the first desired target state, the system upgrade method further includes:
  • the main controller generates a desired target state of the multiple upgrade phases according to the device configuration information (including the relationship of each accessory in the first accessory) and the target version information of the first accessory, and the desired target state of the multiple upgrade phases includes the system completing each upgrade phase. Status and version information of the first attachment.
  • system upgrade method further includes:
  • the main controller determines whether the upgrade target state of the first accessory has a second desired target state, that is, determines whether the upgrade target state of the first accessory exists. a next desired target state of the first desired target state in the upgrade phase, or a version desired target state that needs to be updated or upgraded to the next phase of the first desired target state upgrade phase in each upgrade phase of the system;
  • the primary controller updates the upgrade target state of the first accessory to the second desired target state, and implements multiple phases of the system upgrade separately.
  • system upgrade method further includes:
  • the main controller determines whether the second accessory reaches the first desired target state
  • the primary controller updates the upgrade target state of the second accessory to the third desired target state; before the upgrade phase of the first desired target state of the system upgrade device is upgraded in stages, When there is an upgrade phase of the third desired target state, the upgrade target state of the second accessory is updated to the first desired target state; in order to make the system phased upgrade, each phase is separately executed as the upgrade sub-process, and each phase of the system upgrade is implemented.
  • the small-scale back-off retry (the attachment status is restored to the state of the previous upgrade phase, and the upgrade is re-executed), the fault retry range is shortened, the retry efficiency is improved, and the upgrade time window is shortened.
  • system upgrade method further includes:
  • the main controller determines whether the upgrade target state of the first accessory has a next desired target state of the first desired target state in the system upgrade phase, or It is said that the next desired phase of the first desired target state upgrade phase in each upgrade phase of the system upgrade device needs to be updated or upgraded to a version desired target state, that is, a second desired target state.
  • the main controller updates the upgrade target state of the first attachment to the second desired target state.
  • the upgrading method further includes:
  • the main controller determines whether the second accessory belongs to an accessory in the main controller; when the second accessory is an accessory in the main controller in the system upgrade device, the main controller performs mutual function with one of the slave controllers
  • the second accessory is upgraded by one or more slave controllers of all slave controllers by the main controller after the function interchange.
  • the application provides a system upgrade apparatus, where the system upgrade apparatus includes:
  • An update unit configured to update all the attachments involved in the system upgrade, that is, the upgrade target status of the first attachment to a desired target state that is expected to be reached by the first accessory in the upgrade phase during the system phased upgrade process, that is, the first desired target state .
  • a determining unit configured to determine, according to a state of the first accessory and the first desired target state, an accessory that is different from the first desired target state in the first accessory, that is, the second accessory, and indicates the The controller upgrades the second accessory to determine whether the state of the upgraded second accessory reaches the first desired target state;
  • a prompting unit configured to: when the status of the upgraded second accessory does not reach the first desired target state, instructing to suspend the upgrade from the controller, and prompting the second accessory to successfully upgrade to the first desired target state
  • the staff who performed the system upgrade used the obstacle information as the basis for manual intervention.
  • the entire microcode version upgrade process of the system is divided into multi-stage upgrades, and the desired target state after the completion of each phase upgrade execution is set, and the state of each accessory is compared with the desired target state.
  • the attachments to be upgraded and the upgrade result information When the attachment upgrade fails to reach the desired target state, the system automatically suspends the upgrade and prompts that the obstacle information is not upgraded to the desired target state, so as to be used for manual intervention according to the obstacle information. The problem is lifted, and the upgrade is manually triggered to improve the success rate of the system's microcode version upgrade.
  • the system upgrade apparatus further includes a generating unit for configuring the device according to the device And the target version information of the first attachment generates a desired target state of the multiple upgrade phases, wherein the device configuration information includes a relationship of each accessory in the first attachment, and the desired target state of the multiple upgrade phases includes the system completing each upgrade phase Status and version information for the first attachment.
  • the determining unit is further configured to: when the state of the upgraded second accessory reaches the first desired target state, determine whether the upgrade target state of the first accessory exists under the first desired target state in the system upgrade phase A desired target state, that is, a second desired target state.
  • the update unit is further configured to update the upgrade target state of the first attachment to the second desired target state when the upgrade target state of the first attachment has a second desired target state.
  • the determining unit is further used,
  • the primary controller Determining whether there is a last desired target state of the first desired target state in the system phased upgrade, a third desired target state when the second accessory fails to reach the first desired target state; when there is a third desired target state, the primary controller
  • the upgrade target status of the second attachment is updated to the third desired target state, so that in the system phased upgrade, the upgrade of the accessory can be retried and retried within a small range of each phase, shortening the retry range of the fault, and improving the retry efficiency. , shorten the time window of the upgrade.
  • the determining unit is further configured to: after the manual intervention is performed, when the state of the second accessory reaches the first desired target state, determining whether the upgrade target state of the first accessory has the first expectation in the system upgrade phase a next desired target state of the target state (second desired target state);
  • the main controller updates the upgrade target state of the first attachment to the second desired target state.
  • the main controller further includes: an interchange unit;
  • the determining unit is further configured to determine whether the first accessory belongs to an accessory in the main controller
  • the interchange unit is configured to switch the function exchange between the main controller and one of the slave controllers when the second accessory is an accessory in the main controller in the system upgrade device, and after the function is interchanged
  • the primary controller controls the upgrade of the second accessory from one or more of the slave controllers.
  • a system upgrade apparatus in a third aspect, includes a processor and The processor is coupled to the memory and communication interface.
  • the processor is coupled to the memory and communication interface.
  • the memory is for storing instructions for the processor to execute, and the communication interface is for communicating with other network elements under the control of the processor.
  • the processor executes the instructions stored by the memory, the execution causes the processor to perform a system upgrade method in any of the possible aspects of the first aspect or the first aspect, or to perform a system upgrade method in any possible design of the first aspect.
  • a fourth aspect a computer readable medium for storing a computer program, the computer program comprising instructions for performing the system upgrade method of the first aspect or any possible design of the first aspect, or for performing the An instruction on a system upgrade method in any possible design on the one hand.
  • the system upgrade is divided into multiple phases, and the desired target state is set for each phase of the upgrade, and the upgrade of each accessory is determined by comparing the state of each accessory with the desired target state.
  • the attachment and the upgrade result information when the attachment upgrade does not reach the desired target state, the system automatically suspends the upgrade and prompts the obstacle reporting information, so as to be used for manual intervention processing according to the obstacle information, lifting the obstacle reporting, and improving the system upgrade. Success rate.
  • FIG. 1 is a schematic structural diagram of a storage system according to an embodiment of the present invention.
  • FIG. 2 is a schematic structural diagram of another storage system according to an embodiment of the present invention.
  • FIG. 3 is a schematic structural diagram of another storage system according to an embodiment of the present invention.
  • FIG. 4 is a schematic flowchart of a system upgrade method according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of a desired target state of an upgrade phase according to an embodiment of the present invention.
  • FIG. 6 is a schematic flowchart diagram of another system upgrade method according to an embodiment of the present disclosure.
  • FIG. 7 is a schematic structural diagram of a system upgrade apparatus according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of another system upgrade apparatus according to an embodiment of the present disclosure.
  • FIG. 9 is a schematic structural diagram of another system upgrade apparatus according to an embodiment of the present invention.
  • the storage system can be abbreviated as a system
  • the microcode version upgrade of the storage system is abbreviated as a system upgrade.
  • the system upgrade method and system upgrade apparatus can be applied to a microcode version upgrade of a multi-component (or component) product, such as a storage system.
  • a microcode version upgrade of a multi-component (or component) product such as a storage system.
  • the difference is identified by comparing the state of the component (including the version information and the working state information of the component).
  • the components that need to be upgraded and the upgraded results.
  • the system automatically suspends and prompts for the obstacle information.
  • the upgrade is continued, which avoids the upgrade process.
  • the microcode version rollback or service interruption directly caused by hardware failure or software bug is triggered to improve the upgrade success rate of the microcode version.
  • FIG. 1 is a schematic structural diagram of a storage system according to an embodiment of the present invention.
  • the storage system 100 can include a plurality of controllers 110, each of which can include one or more accessories 111 that are various components or components in a storage system.
  • the storage system 200 shown in FIG. 2 includes four controllers, and the controller numbers are 0A, 0B, 1A, and 1B, respectively.
  • Each accessory includes 4 accessories.
  • the upgrade package is imported into the storage system, and the state map of the microcode version upgrade is generated according to the target version information of the upgrade package and the device configuration information of the storage system, and the state map may include the microcode.
  • the expected target state for each upgrade phase during a version upgrade that is, a system upgrade).
  • the upgrade target state of each accessory is updated to the next desired target state (the second desired target state), and the state follow-up is performed, that is, the current state of each accessory is Upgrade the target status comparison, and upgrade some or all of the accessories with different version information to ensure that the status of each attachment of the storage system is consistent with the updated upgrade target status.
  • the storage system determines whether the status of each upgraded accessory reaches the updated upgrade target status. If the updated upgrade target status is not reached, the storage system can suspend the upgrade and prompt the obstacle information to facilitate the upgrade. Manual intervention is performed to troubleshoot according to the obstacle information.
  • the storage system can be triggered to continue the upgrade by using a preset touch key or button, and the upgrade target state of each accessory that is upgraded is updated to the previous desired target state (there is a previous desired target state, in the case of This is also referred to herein as the third desired target state), and performs a state rollback, which compares the current state of the upgraded attachment with the upgrade target state (the first desired target state), and has some or all of the version information.
  • the version information of the attachment is rolled back (reverting to the upgrade target version information, that is, the previous desired target state).
  • the storage system is a multi-control system (a storage system with multiple controllers), one of the multiple controllers is set as the master (primary controller), and the other controller is the slave (slave controller), the master
  • the controller boots the upgrade, prioritizes the upgrade from the controller, and synchronizes the progress of the upgrade to each slave controller in real time.
  • the storage system automatically switches the authority of the main controller with the authority of one controller in the controller, and is executed by the slave controller after the switching.
  • the upgrade means that the primary controller is switched to the secondary controller, and one controller in the secondary controller is switched to the primary controller, and the switched primary controller controls the other secondary controllers to continue upgrading according to the upgrade schedule of the previous real-time synchronization.
  • the upgrade is performed by itself.
  • the expected target state of each stage and the progress information during the upgrade process are first recorded to a specific location of the coffer disk.
  • the expected target state of each stage and the progress information during the upgrade process are read from the safe. Perform an upgrade.
  • FIG. 3 is a schematic structural diagram of a storage system according to an embodiment of the present invention.
  • the The storage system 300 includes a communication interface 310, a main controller 320, at least one slave controller 330, and a communication bus 340.
  • the main controller 320 includes a memory 321 and a processor 322, and each of the slave controllers 330 includes a memory 331.
  • the processor 332; the communication interface 310, the main controller 320, and the slave controller 330 are connected via the communication bus 340, and complete communication with each other.
  • the communication interface 310 is configured to receive a signal input by an external device or send a corresponding instruction to an external device.
  • the memory 321 is used to store instructions and data.
  • the processor 322 is configured to invoke instructions in the memory 321 such that the main controller 320 controls each of the components to be upgraded and performs corresponding operations.
  • the processor 322/332 may be a central processing unit (CPU), and the processor 330 may also be other general-purpose processors, a digital signal processor (DSP), and a dedicated processor.
  • DSP digital signal processor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the communication bus 340 may include a power bus, a control bus, a status signal bus, and the like in addition to the data bus. However, for clarity of description, various buses are labeled as communication bus 340 in the figure.
  • the memory 321/311 can include read only memory and random access memory and provides instructions and data to the processor 321/232.
  • a portion of the memory may also include a non-volatile random access memory.
  • the memory can also store information of the device type.
  • the storage system is connected to the host computer via the communication bus 340, and serves as a storage center for data to provide storage services for the host computer.
  • FIG. 4 is a schematic flowchart diagram of a system upgrade method according to an embodiment of the present invention.
  • the executor of the system upgrade method 400 may be the storage system 100 shown in FIG. 1 or the storage system 300 shown in FIG. 3.
  • the system upgrade method 400 may specifically include the following steps:
  • the primary controller updates the upgrade target state of the first accessory to a first desired target state, and the first accessory is all the accessories involved in performing a system upgrade on the storage system, and the first desired target state is the upgrade in the system phased upgrade process.
  • the main controller determines the second accessory according to the state of the first accessory and the first desired target state, where the second accessory is an accessory that is different from the first desired target state in the first accessory;
  • the main controller instructs to upgrade the second accessory from the controller, and determines whether the state of the upgraded second accessory reaches the first desired target state;
  • the main controller instructs the slave controller to suspend the upgrade, and prompts the second accessory to fail to upgrade to the first desired target state.
  • Barrier information is used as a basis for manual intervention.
  • the accessory is a component or component in the storage system.
  • the upgrade target status is the version status to which the microcode version of the system is expected to be upgraded.
  • the target state is expected to be upgraded in stages for the microcode version of the storage system, and the target state reached after the upgrade of each phase is set.
  • the status of the attachment and the desired target status may include version information.
  • the upgrade target states that each accessory of the system needs to reach may be different.
  • the upgrade target status of all the attachments (ie, the first attachment) in the system is updated to the first desired target state
  • the first desired target state may be the upgrade phase during the system upgrade process.
  • the desired target state that the first accessory is expected to achieve that is, the expected target state of the first phase when the system starts to upgrade, or the desired target state of other upgrade phases during the upgrade process.
  • the system before updating the upgrade target status of all the attachments in the system to the first desired target state, the system automatically generates a system upgrade according to the dependency relationship of each accessory in the system, the number of controllers, and the upgrade target version information.
  • the desired target state for each upgrade phase in the process is not limited to the dependency relationship of each accessory in the system, the number of controllers, and the upgrade target version information.
  • one storage system may include one or more controllers, and each controller may include multiple accessories.
  • the state follow-up is performed on each accessory of the system, where the state follow-up refers to comparing the version information in the current state of each accessory with the version information in the first desired target state (the upgrade target state in the upgrade phase). , determine the attachment that is different from the upgrade target status version information, that is, the first Second attachment.
  • the specific process is: comparing the version information in the upgraded state information with the version information of the first desired target state, and determining whether the state of the second accessory reaches the first desired target state.
  • FIG. 5 is a schematic diagram of a desired target state in a certain upgrade phase according to an embodiment of the present invention.
  • the state information may be “normal”, and the version information is version information that each accessory needs to reach at this stage. .
  • the state of the second accessory is similar to the schematic diagram shown in FIG. 5.
  • the state of the second accessory may also include state information and version information, but the state information of the second accessory may include working state information, for example: Status information such as normal operation, upgrade, and fault.
  • the version information in the state of the second attachment is compared with the version information in the first desired target state, and it is determined whether the version information of the upgraded second attachment has reached the version information of the first desired target.
  • one or more attachments in the second attachment fail to reach the version that needs to be reached in this stage.
  • the possible reasons are: hardware failure during the upgrade process, or software bugs.
  • the working status of the second accessory may display: fault, and prompting for the obstacle information, so that the upgraded staff can upgrade the system. Manual intervention for troubleshooting.
  • the system upgrade method provided by the embodiment of the present invention is performed by dividing the system upgrade into multiple phases, and setting a desired target state for each phase of the upgrade, and determining the accessory to be upgraded by comparing the state of each accessory with the expected target state.
  • the system automatically suspends the upgrade and prompts the obstacle detection information, so as to be used for manual intervention processing according to the obstacle information, and the barrier is released.
  • system upgrade method 400 may further include:
  • the main controller generates a desired target state of the multiple upgrade phases according to the device configuration information and the target version information.
  • the expected target state of the multiple upgrade phases may include version information and status information of each accessory after the system completes each upgrade phase.
  • the device configuration information may include information about the relationship of each accessory in the system, the number of controllers, and the target version information is the target version information that needs to be achieved for each accessory upgrade. According to the relationship of each accessory in the device, the number of controllers, the target version information to be achieved by each accessory upgrade, and the desired target state template, the system upgrade is divided into multiple upgrade phases, and the desired target state of each upgrade phase is set.
  • the desired target state of multiple upgrade phases is automatically generated in the main control (primary controller) memory, and synchronized to other slave (slave controller) memory devices. .
  • each accessory upgrade with dependencies needs to use two state diagrams to control the timing.
  • the attachments 1 and 2 are upgraded from version A to version B respectively, and the A and B versions of the attachment 1 are compatible with the attachments.
  • the A and B versions of 2 the A version of Annex 2 can be compatible with the A and B versions of Annex 1, but the B version of Annex 2 can only be compatible with the A version of Annex 1, so that in the upgrade process, it can only be Attachment 2 upgrades from version A to version B, then upgrades attachment 1 and upgrades from version A to version B; this requires generating two state diagrams to control attachment 1 and attachment 2 to upgrade from version A to version B during the upgrade process.
  • Attachments without dependencies can be upgraded in parallel, using a state diagram. You can upgrade multiple attachment versions at a time during the upgrade process.
  • system upgrade method 400 may further include:
  • the main controller does Determining whether the upgrade target state of the first accessory has a second desired target state, and the second desired target state is a next desired target state of the first desired target state in the system upgrade phase;
  • the primary controller updates the upgrade target state of the first accessory to a second desired target state.
  • determining whether the status of the upgraded second accessory reaches the first desired target state and determining the upgraded second additional by comparing the version information of the second accessory with the version information in the first desired target state. Whether the version information reaches the version information of the first desired target state.
  • the version information of each attachment of the second attachment is the same as the version information of the first desired target state, it is determined whether all the attachments in the system have the next desired target state of the first desired target state, that is, the second desired target state.
  • executing S470 or executing S410 updating the upgrade target state of all attachments of the system to the second desired target state.
  • the second desired target state is a next desired target state that is higher than the first expected target state upgrade version during the system phased upgrade process
  • the phased upgrade of the system may be divided into three phases for upgrading, each
  • the target expected states of the phase upgrades are A, B, and C, respectively, and the version numbers of A, B, and C are sequentially increased, or the version of B is updated to the version of A, and the version of C is updated to the version of B.
  • the version of B is the first desired target state
  • the version of C can be considered to be the next desired target state in the upgrade process.
  • system upgrade method 400 may further include:
  • the main controller determines whether the second accessory reaches the first desired target state
  • the troubleshooting process is performed, and after the manual troubleshooting is completed, Whether the second accessory after the manual troubleshooting reaches the first desired target state, the specific process may be the same as the execution process of S430 or S460, and is not described here for brevity.
  • the phased upgrade of the system can be divided into three phases for upgrading.
  • the target expected states of each phase upgrade are A, B, and C respectively.
  • the version of B is updated in version A
  • the version of C is updated in version B.
  • the version of B is the first desired target state
  • the version of A can be considered to be the last desired target state of the first desired target state.
  • system upgrade method 400 may further include:
  • the primary controller updates the upgrade target state of the second accessory to a third desired target state.
  • each of the upgraded accessory version information in the second accessory is rolled back to the third desired target state, so that the system can re-upgrade the second accessory.
  • system upgrade method 400 may further include:
  • the system restores the upgrade target state of the second accessory to the initial state before the upgrade.
  • system upgrade method 400 may further include:
  • the main controller determines whether the upgrade target state of the first accessory has a second desired target state.
  • the system before the system is upgraded, the system further needs to receive the imported system upgrade package, and decompress the system upgrade package to obtain the target version information, so that the system is configured according to the device configuration in the system, including The relationship between the attachments, the number of controllers, the version information of each attachment, and the target version information generate the desired target state for each upgrade phase.
  • the system upgrade method 400 is determined after determining the second accessory according to the state of the first accessory and the first desired target state. It can also include:
  • the main controller performs a function interchange with one of the slave controllers, and
  • the functionally swapped master controller controls the upgrade of the second accessory from one or more of the slave controllers.
  • the system when the system is a dual-controller or multi-controller system, the system needs one of the multiple controllers as the primary controller to guide other controllers, which is called the slave controller.
  • the primary controller preferentially upgrades the secondary controller, and synchronizes the execution progress to other secondary controllers for backup in real time.
  • the upgrade process after determining the second accessory, it is necessary to determine whether the second accessory is an accessory in the main controller to complete the upgrade of each accessory of the system.
  • the main controller is functionally converted from one controller in the slave controller, that is, one controller in the slave controller is used as the master controller to guide other controllers. upgrade.
  • the system upgrade method provided by the embodiment of the present invention is performed by dividing the system upgrade into multiple phases, and setting a desired target state for each phase of the upgrade, and determining the accessory to be upgraded by comparing the state of each accessory with the expected target state.
  • the system automatically suspends the upgrade and prompts the obstacle detection information, so as to be used for manual intervention processing according to the obstacle information, and the barrier is released.
  • the upgrade is fully automatic when there is no abnormality. Once an abnormality is encountered, the abnormal range can be quickly locked, and the manual intervention mode is automatically entered. After the fault is repaired, the system automatically detects the repair result and continues to execute, avoiding the minor fault and causing the upgrade to fail and improve. The success rate of the upgrade.
  • the method/step of method 400 described in FIGS. 4 and 6 may be implemented by communication interface 310, processor 330, and controller 340 of FIG.
  • the size of the sequence numbers of the above processes does not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic.
  • the implementation of the embodiments of the present invention should not be construed as limiting.
  • FIG. 7 is a schematic structural diagram of a system upgrading apparatus according to an embodiment of the present invention.
  • the system upgrading apparatus 700 may include an updating unit 710, a determining unit 720, and a switching prompting unit 730.
  • the updating unit 710 is configured to update the upgrade target state of the first accessory to a first desired target state, where the first accessory is all the accessories involved in the system upgrade, and the first desired target state is expected to be achieved in the upgrade phase of the system during the phased upgrade process. Expected target state;
  • a determining unit 720 configured to determine a second accessory according to a state of the first accessory and a first desired target state, where the second accessory is an accessory that is different from the first desired target state in the first accessory;
  • the determining unit 720 is further configured to: instruct to upgrade the second accessory from the controller, and determine whether the state of the upgraded second accessory reaches the first desired target state;
  • the prompting unit 730 is configured to: when the status of the upgraded second accessory does not reach the first desired target state, indicate that the upgrade is suspended from the controller, and the second accessory is not successfully upgraded to the first desired target state. Reporting information is used as a basis for manual intervention.
  • the system divides the entire upgrade process into multiple upgrade phases according to the device configuration information and the target version information, and sets a desired target state that needs to be reached in each upgrade phase.
  • the update unit 710 updates the upgrade target status of all attachments (first attachments) in the system to the first desired target state.
  • the upgrade target state is an upgrade process.
  • the target state that each accessory of the system needs to reach; the first desired target state is the desired target state expected by the first accessory in the upgrade phase during the system upgrade process.
  • the attachment status and the desired target status may include the working status of the accessory, for example, information such as normal operation, upgrade or failure, and version information of the attachment.
  • the determining unit 720 performs state follow-up, compares the version information in the current state of each accessory with the version information in the first desired target state, and determines a second attachment of the version information difference, wherein the second accessory may be an attachment Part of the attachment.
  • the determining unit 720 indicates that the second accessory is upgraded from the controller, and the upgraded second additional version information is compared with the version information of the first desired target state, and determining whether the upgraded second accessory is upgraded to the upgrade phase needs to be reached. version of.
  • the system automatically suspends the upgrade and prompts for the obstacle reporting information, so that the upgraded staff can manually intervene and perform troubleshooting.
  • one or more attachments in the second attachment do not reach the version that needs to be reached in this stage.
  • the possible reasons are: hardware failure during the upgrade process, or software bug. Waiting for the situation.
  • the working status of the second accessory may display: fault, and prompting for the obstacle information, so as to perform manual troubleshooting according to the obstacle information.
  • the system upgrade method provided by the embodiment of the present invention is performed by dividing the system upgrade into multiple phases, and setting a desired target state for each phase of the upgrade, and determining the accessory to be upgraded by comparing the state of each accessory with the expected target state.
  • the system automatically suspends the upgrade and prompts the report of the fault, so that it can be used for manual intervention according to the fault information, and the fault is reported, which improves the success rate of the system upgrade.
  • the system upgrading apparatus 700 may further include a generating unit 740, configured to generate multiple upgrade stages according to the device configuration information and the target version information.
  • the desired target state of the segment, and the desired target state of the plurality of upgrade phases includes the state and version information of the first accessory after the system upgrade device completes each upgrade phase.
  • the device configuration includes information such as a dependency relationship between each accessory, a number of controllers, and a desired bit state template.
  • the target version information can be obtained by extracting the imported upgrade package.
  • the generating unit 740 generates a state map, or a bitmap, according to information such as the dependency relationship between the respective attachments, the number of controllers, the desired bit state template, and the target version information.
  • the bitmap may include a desired target state that divides the entire upgrade of the system into multiple upgrade phases.
  • system upgrading apparatus 700 may further include an obtaining unit 750, which acquires target version information from the upgrade package.
  • system upgrading apparatus 700 may further include an interchange unit 760.
  • the determining unit 720 determines whether the first accessory belongs to an accessory in the main controller; when the second accessory belongs to the main controller, the interchange unit 760 exchanges the master controller with one of the slave controllers
  • the function is to control the upgrade of the second accessory by one or more of the slave controllers by the master controller after the function interchange.
  • the system needs a controller as a main controller to guide the slave controller to upgrade preferentially, and synchronize the real-time progress of the upgrade to each slave controller.
  • the determining unit 720 determines that the second accessory is an accessory of the main controller, that is, the main controller needs to be upgraded, the system needs to exchange the functions of the main controller and one of the slave controllers through the interchange unit 760. Change, let one controller in the slave controller as the master controller guide other controllers to continue the upgrade based on the synchronized progress before the swap.
  • the determining unit 720 is further configured to: when the version information of the upgraded second accessory reaches the first desired target state, determine whether each upgrade phase of each accessory in the system has a first The next desired target state of the target state is desired; if present, the update unit 710 updates the upgrade target state of each accessory in the system to the next desired target state of the first desired target state.
  • the determining unit 720 is further configured to determine the second attachment after the troubleshooting Whether the piece version information reaches the first desired target state; when the first desired target state is not reached, the determining unit 720 determines whether there is a last desired target state of the first desired target state; when there is a previous expectation of the first desired target state In the target state, the update state updates the upgrade target state of the second attachment to the last desired target state of the first desired target state; if the last desired target state of the first desired target state does not exist, returns to the start of the upgrade Initial state.
  • the system upgrade method provided by the embodiment of the present invention is performed by dividing the system upgrade into multiple phases, and setting a desired target state for each phase of the upgrade, and determining the accessory to be upgraded by comparing the state of each accessory with the expected target state.
  • the system automatically suspends the upgrade and prompts the obstacle detection information, so as to be used for manual intervention processing according to the obstacle information, and the barrier is released.
  • the upgrade is fully automatic when there is no abnormality. Once an abnormality is encountered, the abnormal range can be quickly locked, and the manual intervention mode is automatically entered to quickly locate the fault after the fault is repaired, and the system upgrade is continued to avoid the failure of the minor fault and the system upgrade success. rate.
  • each unit in the system upgrading apparatus 700 provided by the embodiment of the present invention may implement the methods/steps shown in FIG. 4 and FIG. 6 for brevity description, and details are not described herein again.
  • the steps of a method or algorithm described in connection with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both.
  • the software module can be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, Compact Disc Read-Only Memory (CD-ROM), or any known in the technical field Any other form of storage medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

一种系统升级方法和系统升级装置。该升级方法由主控制器执行，包括：更新第一附件的升级目标状态为第一期望目标状态；根据第一附件的状态和第一期望目标状态确定第二附件；指示从控制器升级第二附件，并确定升级后的第二附件的状态是否达到第一期望目标状态；当升级后的第二附件的状态未达到第一期望目标状态时，指示从控制器暂停升级，并提示第二附件未成功升级到第一期望目标状态的报障信息。通过将系统升级分成多个阶段进行，各升级阶段对各个附件的状态与期望目标状态对比，当附件升级未达到期望目标状态时，系统暂停升级，并提示报障信息，以便于根据报障信息进行人工干预处理，解除报障，提高了系统升级的成功率。

Description

系统升级方法和系统升级装置 技术领域
本发明涉及存储系统领域，尤其涉及一种系统升级方法和系统升级装置。
背景技术
随着计算机技术以及网络技术的高速发展，计算机自带的存储器逐渐难以满足存取速度快、存储容量大和成本低等诸多要求，于是发展出相对独立的存储系统。存储系统通常由存储服务器等存储设备组成，具有自己的接口和协议，通过同轴电缆、网线、光纤等方式与计算机主机连接，作为数据的存储中心，为计算机主机提供存储服务。
存储系统作为存储的核心系统，承接多种业务系统的数据，需要提供7x24小时的不中断服务，要在保证不影响业务的情况下，对存储系统的微码版本进行升级，这就为微码版本的升级增加了难度，例如：为了减小对业务的影响，存储系统的升级时间窗通常安排在晚上，且需要多个应用部门的配合。
现有技术中，通常使用的微码版本升级模式为“一键式”升级，启动升级之后，存储系统按照预设流程运行，例如以双控(两个控制器)为例，“一键式”升级为：先用第一个控制器来承接处理双份业务，升级第二个控制器的微码版本，待第二个控制器升级完成后，由第二个控制器承接业务，升级第一个控制器的微码版本，两个控制器均升级完成后再均衡两个控制器上的业务。
现有的微码版本升级中，如果遇见硬件故障或者触发软件bug的情况下，会产生升级失败，导致微码版本回退(恢复到升级之前的版本)，甚至业务中断，造成微码版本升级的成功率低。
发明内容
本申请提供的一种系统升级方法和系统升级装置，在微码版本升级过程中 可以通过人为干预进行排除硬件故障或触发软件bug导致的业务中断，且将整个系统的微码版本升级分成多个阶段进行升级，以避免升级过程中遇到硬件故障或者触发软件bug时直接导致的微码版本回退或者业务中断，以提高微码版本升级的成功率。
第一方面，本申请提供了一种系统升级方法，该系统升级方法包括：主控制器将系统升级涉及到的所有附件，即第一附件的升级目标状态更新为第一期望目标状态，也就是将第一附件的升级目标状态更新为系统分阶段升级过程中本升级阶段第一附件升级期望达到的期望目标状态；将第一附件的升级目标更新为第一期望目标状态后，主控制器确定第一附件中第一附件的状态与第一期望目标状态有差别的附件，也就是第二附件；并指示从控制器升级第二附件，确定升级后的第二附件的状态是否达到第一期望目标状态；当升级后的第二附件的状态未达到第一期望目标状态时，主控制器指示从控制器暂停升级，并提示第二附件未成功升级到第一期望目标状态的报障信息，以便于系统升级工作人员将报障信息作为人工干预排障的依据。
本申请提供的系统升级方法，通过将整个系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示未升级到期望目标状态的报障信息，以便于系统升级的工作人员根据报障信息进行人工干预处理，解除报障，并人工触发继续执行升级，提高了系统的微码版本升级的成功率。
在一个设计方案中，在主控制器将第一附件的升级目标状态更新为第一期望目标状态之前，系统升级方法还包括：
主控制器根据设备配置信息(包括第一附件中各附件的关系)和第一附件的目标版本信息生成多个升级阶段的期望目标状态，多个升级阶段的期望目标状态包括系统完成各个升级阶段后第一附件的状态和版本信息。
在一个设计方案中，系统升级方法还包括：
当升级后的第二附件的状态达到第一期望目标状态时，主控制器确定第一附件的升级目标状态是否存在第二期望目标状态，也就是，确定第一附件的升级目标状态是否存在系统升级阶段中第一期望目标状态的下一期望目标状态，或者说系统各个升级阶段中第一期望目标状态升级阶段的下一个阶段需要更新或者升级到的版本期望目标状态；
当第一附件的升级目标状态存在第二期望目标状态时，主控制器更新第一附件的升级目标状态为第二期望目标状态，实现了系统升级的多阶段单独执行。
在另一个设计方案中，系统升级方法还包括：
人工干预排障后，主控制器确定第二附件是否达到第一期望目标状态；
当第二附件未达到第一期望目标状态时，确定系统分阶段升级中是否包括第一期望目标状态的上一期望目标状态，或者说在系统各个升级阶段中，第一期望目标状态升级阶段的前一阶段需要更新的版本期望目标状态，即第三期望目标状态。
当系统分阶段升级中存在第三期望目标状态时，主控制器更新第二附件的升级目标状态为第三期望目标状态；当系统升级装置分阶段升级的第一期望目标状态的升级阶段之前不存在第三期望目标状态的升级阶段时，将第二附件的升级目标状态更新为第一期望目标状态；以使系统分阶段升级中，各个阶段作为升级子流程的单独执行，实现系统升级各个阶段的小范围回退重试(附件状态恢复到前一升级阶段的状态，并重新进行升级)，缩短故障重试范围，提高重试效率，缩短升级的时间窗。
在另一个设计方案中，系统升级方法还包括：
人工干预排障后，当第二附件的状态达到第一期望目标状态时，主控制器确定第一附件的升级目标状态是否存在系统升级阶段中第一期望目标状态的下一期望目标状态，或者说系统升级装置各个升级阶段中第一期望目标状态升级阶段的下一个阶段的需要更新或者升级到的版本期望目标状态，即第二期望目标状态。
当第一附件的升级目标状态存在第二期望目标状态时，主控制器更新第一附件的升级目标状态为第二期望目标状态。
在又一个设计方案中，在根据第一附件的状态和第一期望目标状态确定第二附件之后，升级方法还包括：
主控制器确定第二附件是否属于主控制器中的附件；当第二附件为系统升级装置中主控制器内的附件时，主控制器与所有从控制器中的一个从控制器进行功能互换，并由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行第二附件的升级。
第二方面，本申请提供一种系统升级装置，该系统升级装置包括：
更新单元，用于将系统升级所涉及到的所有附件，即第一附件的升级目标状态更新为系统分阶段升级过程中本升级阶段第一附件期望达到的期望目标状态，即第一期望目标状态。
确定单元，用于根据第一附件的状态和第一期望目标状态进行对比，确定第一附件中第一附件的状态与第一期望目标状态有差别的附件，也就是第二附件，并指示从控制器升级第二附件，确定升级后的第二附件的状态是否达到第一期望目标状态；
提示单元，用于当升级后的第二附件的状态未达到第一期望目标状态时，指示从控制器暂停升级，并提示第二附件未成功升级到第一期望目标状态的报障信息，以便于进行系统升级的工作人员将报障信息作为人工干预排障的依据。
通过本申请提供的系统升级装置，将系统的整个微码版本升级过程分成多阶段升级，并设定每个阶段升级执行完成后的期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示未升级到期望目标状态的报障信息，以便于用于根据报障信息进行人工干预处理，解除报障，并人工触发继续执行升级，提高了系统的微码版本升级的成功率。
在一个设计方案中，系统升级装置还包括生成单元，用于根据设备配置信 息和第一附件的目标版本信息生成多个升级阶段的期望目标状态，其中，设备配置信息中包括第一附件中各附件的关系，多个升级阶段的期望目标状态包括系统完成各个升级阶段后第一附件的状态和版本信息。
在一个设计方案中，确定单元还用于，当升级后的第二附件的状态达到第一期望目标状态时，确定第一附件的升级目标状态是否存在系统升级阶段中第一期望目标状态的下一期望目标状态，也就是第二期望目标状态。
更新单元还用于，当第一附件的升级目标状态存在第二期望目标状态时，更新第一附件的升级目标状态为第二期望目标状态。
在另一个设计方案中，确定单元还用于，
人工干预排障后，确定第二附件是否达到第一期望目标状态；
当第二附件未达到第一期望目标状态时，确定系统分阶段升级中是否存在第一期望目标状态的上一期望目标状态第三期望目标状态；当存在第三期望目标状态时，主控制器更新第二附件的升级目标状态为第三期望目标状态，以实现系统分阶段升级中，附件的升级可以在各个阶段的小范围内进行回退重试，缩短故障重试范围，提高重试效率，缩短升级的时间窗。
在另一个设计方案中，确定单元还用于，人工干预排障后，当第二附件的状态达到第一期望目标状态时，确定第一附件的升级目标状态是否存在系统升级阶段中第一期望目标状态的下一期望目标状态(第二期望目标状态)；
当第一附件的升级目标状态存在第二期望目标状态时，主控制器更新第一附件的升级目标状态为第二期望目标状态。
在有一个设计方案中，主控制器还包括：互换单元；
确定单元还用于，确定第一附件是否属于主控制器中的附件；
互换单元，用于当第二附件为系统升级装置中主控制器内的附件时，切换主控制器与所有从控制器中的一个从控制器进行的功能互换，并由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行第二附件的升级。
第三方面，提供了一种系统升级装置。该系统升级装置包括处理器和与处 理器耦合连接的存储器、通信接口。处理器与存储器和通信接口连接。存储器用于存储指令，处理器用于执行该指令，通信接口用于在处理器的控制下与其他网元进行通信。该处理器执行该存储器存储的指令时，该执行使得该处理器执行第一方面或第一方面的任意可能设计中的系统升级方法，或执行第一方面的任意可能设计中的系统升级方法。
第四方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能设计中的系统升级方法的指令，或用于执行第一方面的任意可能设计中的系统升级方法的指令。
基于本申请提供的系统升级方法和系统升级装置，通过将系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示报障信息，以便于用于根据报障信息进行人工干预处理，解除报障，提高系统升级的成功率。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种存储系统结构示意图；
图2为本发明实施例提供的另一种存储系统的结构示意图；
图3为本发明实施例提供的另一种存储系统的结构示意图；
图4为本发明实施提供的一种系统升级方法的流程示意图；
图5为本发明实施例提供的某一升级阶段的期望目标状态示意图；
图6为本发明实施例提供的另一种系统升级方法的流程示意图；
图7为本发明实施例提供的一种系统升级装置结构示意图；
图8为本发明实施例提供的另一种系统升级装置结构示意图；
图9为本发明实施例提供的另一种系统升级装置结构示意图。
具体实施方式
需要说明的是，在本发明实施中，为描述简洁，可以将存储系统简写为系统，存储系统的微码版本升级简写为系统升级。
本发明实施例提供的系统升级方法和系统升级装置，可以应用在多组件(或部件)产品的微码版本升级中，例如存储系统。通过将整个微码版本的升级过程分成多阶段升级，并设定每个阶段升级执行完成后的期望目标状态，通过对部件的状态(包括版本信息和部件的工作状态信息)差异比对识别出需要升级的部件以及升级后的结果，当部件升级后未达到各阶段的期望目标状态时，系统自动暂停，并提示报障信息，进行人工干预排障后继续执行升级，可以避免升级过程中遇到硬件故障或者触发软件bug时直接导致的微码版本回退或者业务中断，以提高微码版本的升级成功率。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。
图1为本发明实施例提供的一种存储系统的结构示意图。
如图1所示，该存储系统100可以包括多个控制器110，每个控制器中可以包括一个或多个附件111，该附件111为存储系统中的各个部件或组件。
如图2所示的存储系统200包括4个控制器，控制器的编号分别为0A、0B、1A和1B。每个控制器中包括4个附件。
当存储系统的微码版本需要升级时，将升级包导入存储系统，并根据升级包的目标版本信息和存储系统的设备配置信息，生成微码版本升级的状态图，状态图中可以包括微码版本升级(即系统升级)过程中各个升级阶段的期望目标状态。
在开始升级时，更新存储系统中各个附件的升级目标状态为各个升级阶段 中的第一升级阶段的目标状态，或者升级过程中，将各个附件的升级目标状态更新为下一期望目标状态(第二期望目标状态)，并执行状态跟进，即将各附件的当前状态与升级目标状态比对，将版本信息具有差别的部分或者全部附件进行系统升级，以实现存储系统各附件的状态与更新后的升级目标状态一致。
存储系统确定升级后的各附件的状态是否达到更新后的升级目标状态，如果未达到更新后的升级目标状态时，存储系统可以暂停执行升级，并提示报障信息，以便于进行升级的工作人员进行人工干预，根据报障信息进行排障处理。
人工排障处理之后，可以通过预设的触控键或者按钮触发存储系统继续执行升级，更新进行升级的各附件的升级目标状态为前一期望目标状态(存在前一期望目标状态的情况，在本文中也称为第三期望目标状态)，并执行状态回退，即将升级后的附件的当前状态与升级目标状态(第一期望目标状态)进行比对，将版本信息具有差别的部分或者全部附件的版本信息进行回退(恢复到升级目标版本信息，即前一期望目标状态)。
当存储系统为多控系统(具有多个控制器的存储系统)时，设置多控制器中的一个控制器为主控(主控制器)，其他控制器为从控(从控制器)，主控制器引导执行升级，优先升级从控制器进行升级，并将升级的进度实时同步给各个从控制器。当检测到需要升级的控制器为主控制器中的附件时，存储系统自动将主控制器的权限与从控制器中的一个控制器的权限进行切换，并由切换后的从控制器引导执行升级，即将主控制器切换为从控制器，将从控制器中的一个控制器切换为主控制器，切换后的主控制器根据先前实时同步的升级进度控制其他从控制器继续升级。
当存储系统为单控制器系统(具有一个控制器的存储系统)时，由自身引导执行升级。在复位时，先将各阶段的期望目标状态和升级过程中的进度信息记录到保险箱盘特定的位置，存储系统启动后，再从保险箱中读取各个阶段期望目标状态和升级过程中的进度信息执行升级。
图3为本发明实施例提供的一种存储系统的结构示意图。如图3所示，该 存储系统300，包括通信接口310、主控制器320、至少一个从控制器330和通信总线340，其中，主控制器320中包括存储器321和处理器322，每个从控制器330中包括存储器331和处理器332；通信接口310、主控制器320和从控制器330通过通信总线340连接，并完成相互之间的通信。通信接口310用于接收外部设备输入的信号或者向外部设备发送相应的指令。存储器321用来存储指令和数据。处理器322用于调用存储器321中的指令，使得主控制器320对各个需升级的部件进行控制并执行相应的操作。
在本发明实施例中，处理器322/332可以是中央处理单元(Central Processing Unit，CPU)，该处理器330还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
通信总线340除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为通信总线340。
存储器321/331可以包括只读存储器和随机存取存储器，并向处理器322/332提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。
该存储系统通过通信总线340与计算机主机连接，作为数据的存储中心为计算机主机提供存储服务。
图4为本发明实施例提供的一种系统升级方法的流程示意图。如图4所示，该系统升级方法400的执行主体可以为图1或所示的存储系统100或图3所示的存储系统300，该系统升级方法400可以具体包括以下步骤：
S410，主控制器更新第一附件的升级目标状态为第一期望目标状态，第一附件为对存储系统进行系统升级所涉及的所有附件，第一期望目标状态为系统分阶段升级过程中本升级阶段第一附件期望达到的期望目标状态；
S420，主控制器根据第一附件的状态和第一期望目标状态确定第二附件，第二附件为在第一附件中第一附件的状态与第一期望目标状态有差别的附件；
S430，主控制器指示从控制器升级第二附件，并确定升级后的第二附件的状态是否达到第一期望目标状态；
S440，当升级后的第二附件的状态未达到第一期望目标状态时，主控制器指示从控制器暂停升级，并提示第二附件未成功升级到第一期望目标状态的报障信息，报障信息作为进行人工干预排障的依据。
具体的，在本发明实施例中，附件为存储系统中的部件或者组件。升级目标状态为本阶段期望系统的微码版本升级到的版本状态。期望目标状态是为存储系统的微码版本分阶段进行升级，设定的各个阶段升级后达到的目标状态。附件的状态和期望目标状态可以包括版本信息。
还需要说明的是，在本发明实施例中，系统各附件需要达到的升级目标状态可以不相同。
在S410中，即系统进行升级过程中，将系统中所有的附件(即第一附件)的升级目标状态更新为第一期望目标状态，该第一期望目标状态可以为系统升级过程中本升级阶段第一附件期望达到的期望目标状态，也就是说，可以为系统开始升级时，第一阶段的期望目标状态，也可以为升级过程中的其他升级阶段的期望目标状态。
在本发明实施例中，将系统中的所有附件的升级目标状态更新为第一期望目标状态之前，系统预先根据系统中各附件的依赖关系，控制器的数量以及升级目标版本信息自动生成系统升级过程中各个升级阶段的期望目标状态。
其中，一个存储系统中可以包括一个或多个控制器，每个控制器中可以包括多个附件。
S420，对系统的各个附件进行状态跟进，这里的状态跟进是指将各个附件的当前状态中的版本信息与第一期望目标状态(本升级阶段的升级目标状态)中的版本信息进行对比，确定出与升级目标状态版本信息有差别的附件，即第 二附件。
S430中，升级第二附件。确定升级后的第二附件的状态是否达到升级目标状态，也就是第一期望目标状态。
其具体过程为：将升级后的状态信息中的版本信息与第一期望目标状态的版本信息进行对比，确定第二附件的状态是否达到了第一期望目标状态。
如图5所示，图5为本发明实施例提供的某一升级阶段的期望目标状态的示意图，其中，状态信息可以为运行“正常”，版本信息为各个附件在该阶段需要达到的版本信息。
在本发明实施例中，第二附件的状态类似于图5所示的示意图，第二附件的状态也可以包括状态信息和版本信息，但第二附件的状态信息可以包括工作状态信息，例如：运行正常、升级中、故障等状态信息。
根据第二附件的状态中的版本信息与第一期望目标状态中的版本信息进行比对，确定升级后的第二附件的版本信息是否达到了第一期望目标的版本信息。
S440，当升级后的第二附件中的一个或者多个的版本信息未达到第一期望目标状态的版本信息时，系统暂停执行升级，提示未达到第一期望目标状态的第二附件的报障信息。
在本发明实施例中，第二附件中的一个或者多个附件没有达到该阶段需要达到的版本可能原因有：升级过程中遇到硬件故障，或者触发软件的漏洞(bug)等情况。如果由于遇见硬件故障导致第二附件为升级到设定需要达到的版本时，第二附件的工作状态可能会显示：故障，并提示报障信息，以便于对系统进行升级的工作人员对升级进行人工干预排障处理。
通过本发明实施例提供的系统升级方法，通过将系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示报障信息，以便于用于根据报障信息进行人工干预处理，解除报障。
可选地，作为本发明另一实施例，如图6所示，在主控制器更新第一附件的升级目标状态为第一期望目标状态之前，该系统升级方法400还可以包括：
S450，主控制器根据设备配置信息和目标版本信息生成多个升级阶段的期望目标状态。
具体的，多个升级阶段的期望目标状态可以包括系统完成各个升级阶段后各个附件的版本信息和状态信息。
设备配置信息中可以包括系统中各个附件的关系，控制器的数量等信息；目标版本信息为各个附件升级需要达到的目标版本信息。根据设备中各个附件的关系、控制器的数量，各个附件升级所要达到的目标版本信息，以及期望目标状态模板将系统的升级分成多个升级阶段，并设定各个升级阶段的期望目标状态。
在本发明实施例中，如果该系统为多控系统，在主控(主控制器)内存中自动生成多个升级阶段的期望目标状态，并同步到其他从控(从控制器)内存设备中。
在本发明实施例中，有依赖关系的各附件升级需要使用两个状态图来控制时序，例如：附件1与附件2分别从版本A升级为版本B，附件1的A、B版本可以兼容附件2的A、B版本，附件2的A版本可以兼容附件1的A、B版本，但是附件2的B版本只能兼容附件1的A版本，这样的话，在升级过程中，就只能先将附件2从版本A升级到版本B，再升级附件1,从版本A升级到版本B；这样就需要生成两个状态图来控制附件1和附件2从版本A升级到版本B，在升级过程中先执行升级附件2的状态图，再执行升级附件1的状态图。
无依赖关系的附件可以并行升级，使用一个状态图。在升级过程中一次可以升级多个附件的版本。
可选地，作为本发明另一实施例，如图6所示，该系统升级方法400还可以包括：
S460，当升级后的第二附件的状态达到第一期望目标状态时，主控制器确 定第一附件的升级目标状态是否存在第二期望目标状态，第二期望目标状态为系统升级阶段中第一期望目标状态的下一期望目标状态；
S470，当第一附件的升级目标状态存在第二期望目标状态时，主控制器更新第一附件的升级目标状态为第二期望目标状态。
具体的，判断升级后的第二附件的状态是否达到了第一期望目标状态，可以通过将第二附件的版本信息与第一期望目标状态中的版本信息比对，确定升级后的第二附加的版本信息是否达到第一期望目标状态的版本信息。当第二附件的各个附件的版本信息均与第一期望目标状态的版本信息相同时，判断系统中所有附件是否存在第一期望目标状态的下一期望目标状态，也就是第二期望目标状态。当系统生成的状态图中存在第一期望目标状态的下一期望目标状态时，执行S470或者说执行S410，将系统所有附件的升级目标状态更新为第二期望目标状态。
需要说明的是，第二期望目标状态为系统分阶段升级过程中，比第一期望目标状态升级版本高的下一个期望目标状态，例如系统的分阶段升级可以分为3个阶段进行升级，每个阶段升级的目标期望状态分别为A、B和C，A、B和C的版本号依次增加，或者说B的版本更新于A的版本，C的版本更新于B的版本。假设B的版本为第一期望目标状态，可以认为C的版本为升级过程中的下一期望目标状态。
可选地，作为本发明另一实施例，如图6所示，该系统升级方法400还可以包括：
S480，人工干预排障后，主控制器确定第二附件是否达到第一期望目标状态；
S490，当第二附件未达到第一期望目标状态时，确定系统的升级阶段中是否存在第三期望目标状态，第三期望目标状态为第一期望目标状态的上一期望目标状态。
具体的，根据系统提示的报障信息进行排障处理，人工排障完成之后，确 定人工排障后的第二附件是否达到第一期望目标状态，其具体过程可以与S430或S460的执行过程相同，为简洁描述，在这里不再赘述。
当升级后的第二附件中的一个或者多个附件的版本信息与第一期望目标状态中相应附件的版本信息不相同时，确定是否存在第一期望目标状态的上一期望目标状态，即第三期望目标状态。
例如系统的分阶段升级可以分为3个阶段进行升级，每个阶段升级的目标期望状态分别为A、B和C，B的版本更新于A版本，C的版本更新于B的版本。假设B的版本为第一期望目标状态，可以认为A的版本为第一期望目标状态的上一期望目标状态。
可选地，在本发明实施例中，该系统升级方法400还可以包括：
S491，当系统的升级阶段中存在第三期望目标状态时，主控制器更新第二附件的升级目标状态为第三期望目标状态。
当存在第三期望目标状态时，将第二附件中已将升级的各附件版本信息回退到第三期望目标状态，以便于系统可以重新升级第二附件。
可选地，在本发明实施例中，该系统升级方法400还可以包括：
S492，当系统分阶段升级的第一期望目标状态之前不存在第三期望目标状态时，主控制器更新第二附件的升级目标状态为第一期望目标状态。
当系统升级阶段中的第一期望目标状态之前不存在第三期望目标状态时，系统将第二附件的升级目标状态还原到升级之前的初始状态。
可选地，作为本发明另一实施例，如图6所示，该系统升级方法400还可以包括：
S493，人工干预排障后，当第二附件的状态达到第一期望目标状态时，主控制器确定第一附件的升级目标状态是否存在第二期望目标状态。
在S480中，当确定第二附件中各附件的版本信息均与第一期望目标状态时，执行S493，主控制器确定系统中所有附件的升级目标状态是否存在第二期望目标状态。
可选的，在本发明实施例中，在系统进行升级之前，系统还需要接收导入的系统升级包，并解压缩系统升级包，获取目标版本信息，以便于系统根据系统中的设备配置，包括各附件间的关系、控制器的数量、各附件的版本信息以及目标版本信息生成各升级阶段的期望目标状态。
可选地，作为本发明另一实施例，当系统为双控制器系统或者多控制器系统时，在根据第一附件的状态和第一期望目标状态确定第二附件之后，该系统升级方法400还可以包括：
确定第二附件是否属于主控制器中的附件；当升级后的第二附件为主控制器内的附件时，主控制器与所有从控制器中的一个从控制器进行功能互换，并由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行第二附件的升级。
具体的，系统为双控制器或多控制器系统时，系统需要多控制器中的一个控制器作为主控制器，引导其他控制器，称为从控制器进行升级。在本发明实施例中，主控制器优先升级从控制器，并将执行进度实时同步给其他从控制器进行备份。在升级过程中，确定第二附件之后，需要确定第二附件是否为主控制器内的附件，以完成系统各个附件的升级。当第二附件为主控制器中的附件时，将主控制器与从控制器中的一个控制器进行功能转换，也就是将从控制器中的一个控制器作为主控制器引导其他控制器进行升级。
通过本发明实施例提供的系统升级方法，通过将系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示报障信息，以便于用于根据报障信息进行人工干预处理，解除报障。同时，升级无异常时全自动进行，一旦遇到异常可以快速锁定异常范围，且自动进入人工干预模式快速定位在故障修复后，系统自动检测修复结果，继续执行，避免小故障导致升级失败，提高升级的成功率。
应理解，在本发明实施例中，图4和图6中描述的方法400的方法/步骤可以通过图3中的通信接口310、处理器330和控制器340来实现。
还需理解，需要说明的是，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
上文中结合图4至和图6，详细描述了根据本发明实施例的系统升级方法，下面将结合图7至图9，详细描述根据本发明实施例的系统升级装置。
图7为本发明实施例提供的一种系统升级装置的结构示意图。如图7所示，该系统升级装置700可以包括：更新单元710、确定单元720和切换提示单元730。
更新单元710，用于更新第一附件的升级目标状态为第一期望目标状态，第一附件为系统升级涉及的所有附件，第一期望目标状态为系统分阶段升级过程中本升级阶段期望达到的期望目标状态；
确定单元720，用于根据第一附件的状态和第一期望目标状态确定第二附件，第二附件为在第一附件中第一附件的状态与第一期望目标状态有差别的附件；
确定单元720还用于，指示从控制器升级第二附件，并确定升级后的第二附件的状态是否达到第一期望目标状态；
提示单元730，用于当升级后的第二附件的状态未达到第一期望目标状态时，指示从控制器暂停升级，并提示第二附件未成功升级到第一期望目标状态的报障信息，报障信息作为人工干预排障的依据。
具体的，在升级之前，系统预先根据设备配置信息和目标版本信息将整个升级过程分成多个升级阶段，并设定每个升级阶段需要达到的期望目标状态。
在升级过程中，更新单元710将系统中所有附件(第一附件)的升级目标状态更新为第一期望目标状态。在本发明实施例中，升级目标状态为升级过程 中系统各附件需要达到的目标状态；第一期望目标状态为系统升级过程中本升级阶段第一附件期望达到的期望目标状态。
需要说明的是，在本发明实施例中，附件状态和期望目标状态中均可以包括附件的工作状态，例如：运行正常，升级中或故障等信息，以及附件的版本信息。
确定单元720进行状态跟进，将各附件的当前状态中的版本信息与第一期望目标状态中的版本信息进行比对，确定版本信息差异的第二附件，其中，第二附件可能是附件中的部分附件。
确定单元720指示从控制器升级第二附件，将升级后的第二附加的版本信息与第一期望目标状态的版本信息进行比对，确定升级后的第二附件是否升级到该升级阶段需要达到的版本。
当第二附件中的一个或者多个附件没有达到该升级阶段需要达到的版本时，系统会自动暂停执行升级，并提示报障信息，以便于进行升级的工作人员进行人工干预，进行排障处理。
需要说明的是，在本发明实施例中，第二附件中的一个或者多个附件没有达到该阶段需要达到的版本可能原因有：升级过程中遇到硬件故障，或者触发软件的漏洞(bug)等情况。如果由于遇见硬件故障导致第二附件为升级到设定需要达到的版本时，第二附件的工作状态可能会显示：故障，并提示报障信息，以便于根据报障信息进行人工排障处理。
通过本发明实施例提供的系统升级方法，通过将系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示报障信息，以便于用于根据报障信息进行人工干预处理，解除报障，提高了系统升级的成功率。
可选地，作为本发明另一实施例，如图8所示，该系统升级装置700还可以包括生成到单元740，用于根据设备配置信息和目标版本信息生成多个升级阶 段的期望目标状态，多个升级阶段的期望目标状态包括系统升级装置完成各个升级阶段后第一附件的状态和版本信息。
具体的，设备配置包括各个附件间的依赖关系，控制器的数量、期望位状态模板等信息。目标版本信息可以通过接收导入的升级包，解压获取。
生成单元740根据各个附件间的依赖关系，控制器的数量、期望位状态模板以及目标版本信息等信息，生成状态图，或者叫做位图。位图中可以包括将系统整个升级分成多个升级阶段的期望目标状态。
可选地，作为本发明另一实施例，如图9所示，该系统升级装置700还可以包括获取单元750，从升级包中获取目标版本信息。
可选地，作为本发明另一实施例，如图9所示，该系统升级装置700还可以包括互换单元760。
确定单元720确定所述第一附件是否属于主控制器中的附件；当第二附件属于主控制器时，互换单元760互换所述主控制器与所有从控制器中的一个从控制器的功能，由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行所述第二附件的升级。
具体的，当系统为双控制器系统或者多控制器系统时，系统需要一个控制器作为主控制器引导从控制器优先升级，并将升级的实时进度同步到各个从控制器中。当确定单元720确定第二附件为主控制器的附件时，即，需要升级的是主控制器，系统需要通过互换单元760将主控制器与从控制器中的一个控制器的功能进行互换，让从控制器中的一个控制器作为主控制器引导其他的控制器基于互换前已同步的进度继续升级。
可选地，作为本发明另一实施例，确定单元720，还用于当升级后的第二附件的版本信息达到第一期望目标状态时，确定系统中各附件的各升级阶段有没有第一期望目标状态的下一期望目标状态；如果存在时，更新单元710将系统中各附件的升级目标状态更新为第一期望目标状态的下一期望目标状态。
当人工干预排障处理完成之后，确定单元720还用于确定排障后的第二附 件版本信息是否达到第一期望目标状态；当未达到第一期望目标状态时，确定单元720确定是否存在第一期望目标状态的上一期望目标状态；当存在第一期望目标状态的上一期望目标状态时，更新状态将第二附件的升级目标状态更新为第一期望目标状态的上一期望目标状态；如果不存在第一期望目标状态的上一期望目标状态时，返回到升级开始时的初始状态。
通过本发明实施例提供的系统升级方法，通过将系统升级分成多个阶段进行，并为每个阶段的升级设定期望目标状态，通过对各个附件的状态与期望目标状态对比确定需升级的附件以及升级结果信息，当附件升级未达到期望目标状态时，系统自动暂停执行升级，并提示报障信息，以便于用于根据报障信息进行人工干预处理，解除报障。同时，升级无异常时全自动进行，一旦遇到异常可以快速锁定异常范围，且自动进入人工干预模式快速定位在故障修复后，继续执行系统升级，避免小故障导致升级失败，提高系统升级的成功率。
需要说明的是，本发明实施例提供的系统升级装置700中的各个单元可以实现图4和图6所示的方法/步骤，为简洁描述，在这里不再赘述。
专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(Random Access Memory，RAM)、内存、只读存储器(Read-Only Memory，ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、只读光盘驱动器(Compact Disc Read-Only Memory，CD-ROM)、或技术领域内所公知的任 意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

  1. 一种系统升级方法，其特征在于，所述系统升级方法包括：
    主控制器更新第一附件的升级目标状态为第一期望目标状态，所述第一附件为系统升级涉及的所有附件，所述第一期望目标状态为所述系统分阶段升级过程中本升级阶段期望达到的期望目标状态；
    所述主控制器根据所述第一附件的状态和所述第一期望目标状态确定第二附件，所述第二附件为在所述第一附件中所述第一附件的状态与所述第一期望目标状态有差别的附件；
    所述主控制器指示从控制器升级所述第二附件，并确定升级后的第二附件的状态是否达到所述第一期望目标状态；
    当升级后的第二附件的状态未达到所述第一期望目标状态时，所述主控制器指示所述从控制器暂停升级，并提示所述第二附件未成功升级到所述第一期望目标状态的报障信息，所述报障信息作为人工干预排障的依据。
  2. 根据权利要求1所述的系统升级方法，其特征在于，在所述主控制器更新第一附件的升级目标状态为第一期望目标状态之前，所述系统升级方法还包括：
    所述主控制器根据设备配置信息和目标版本信息生成多个升级阶段的期望目标状态，所述多个升级阶段的期望目标状态包括所述系统完成各个升级阶段后所述第一附件的状态和版本信息；
    其中，所述设备配置信息中包括所述第一附件中各附件的关系；所述目标版本信息为所述第一附件的目标版本信息。
  3. 根据权利要求1或2所述的系统升级方法，其特征在于，所述系统升级方法还包括：
    当升级后的第二附件的状态达到所述第一期望目标状态时，所述主控制器确定所述第一附件的升级目标状态是否存在第二期望目标状态，所述第二期望目标状态为所述系统升级阶段中所述第一期望目标状态的下一期望目标状态；
    当所述第一附件的升级目标状态存在所述第二期望目标状态时，所述主控制器更新所述第一附件的升级目标状态为所述第二期望目标状态。
  4. 根据权利要求1所述的系统升级方法，其特征在于，所述系统升级方法还包括：
    人工干预排障后，所述主控制器确定所述第二附件是否达到所述第一期望目标状态；
    当所述第二附件未达到所述第一期望目标状态、且所述系统升级阶段中存在第三期望目标状态时，所述主控制器更新所述第二附件的升级目标状态为所述第三期望目标状态，所述第三期望目标状态为所述第一期望目标状态的上一期望目标状态。
  5. 根据权利要求4所述的系统升级方法，其特征在于，所述系统升级方法还包括：
    人工干预排障后，当所述第二附件的状态达到所述第一期望目标状态时，所述主控制器确定所述第一附件的升级目标状态是否存在所述第二期望目标状态，所述第二期望目标状态为所述系统升级阶段中所述第一期望目标状态的下一期望目标状态；
    当所述第一附件的升级目标状态存在所述第二期望目标状态时，所述主控制器更新所述第一附件的升级目标状态为所述第二期望目标状态。
  6. 根据权利要求1-5任一项所述的系统升级方法，其特征在于，在根据所述第一附件的状态和所述第一期望目标状态确定第二附件之后，所述系统升级方法还包括：
    所述主控制器确定所述第二附件是否属于主控制器中的附件；
    当所述第二附件为主控制器内的附件时，所述主控制器与所有从控制器中的一个从控制器进行功能互换，并由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行所述第二附件的升级。
  7. 一种系统升级装置，其特征在于，所述系统升级装置包括：
    更新单元，用于更新第一附件的升级目标状态为第一期望目标状态，所述第一附件为所述系统升级涉及的所有附件，所述第一期望目标状态为所述系统分阶段升级过程中本升级阶段期望达到的期望目标状态；
    确定单元，用于根据所述第一附件的状态和所述第一期望目标状态确定第二附件，所述第二附件为在所述第一附件中所述第一附件的状态与所述第一期望目标状态有差别的附件；
    所述确定单元还用于，指示从控制器升级所述第二附件，并确定升级后的第二附件的状态是否达到所述第一期望目标状态；
    提示单元，用于当升级后的第二附件的状态未达到所述第一期望目标状态时，指示所述从控制器暂停升级，并提示所述第二附件未成功升级到所述第一期望目标状态的报障信息，所述报障信息作为人工干预排障的依据。
  8. 根据权利要求7所述的系统升级装置，其特征在于，所述系统升级装置还包括生成单元，用于根据设备配置信息和目标版本信息生成多个升级阶段的期望目标状态，所述多个升级阶段的期望目标状态包括所述系统完成各个升级阶段后所述第一附件的状态和版本信息；
    其中，所述设备配置信息中包括所述第一附件中各附件的关系；所述目标版本信息为所述第一附件的目标版本信息。
  9. 根据权利要求7或8所述的系统升级装置，其特征在于，所述确定单元还用于，当升级后的第二附件的状态达到所述第一期望目标状态时，确定所述第一附件的升级目标状态是否存在第二期望目标状态，所述第二期望目标状态为所述系统升级阶段中所述第一期望目标状态的下一期望目标状态；
    所述更新单元还用于，当所述第一附件的升级目标状态存在所述第二期望目标状态时，更新所述第一附件的升级目标状态为所述第二期望目标状态。
  10. 根据权利要求7所述的系统升级装置，其特征在于，所述确定单元还用于，
    人工干预排障后，确定所述第二附件是否达到所述第一期望目标状态；
    当所述第二附件未达到所述第一期望目标状态、且所述系统分阶段升级中存在第三期望目标状态时，所述主控制器更新所述第二附件的升级目标状态为所述第三期望目标状态，所述第三期望目标状态为所述第一期望目标状态的上一期望目标状态。
  11. 根据权利要求10所述的系统升级装置，其特征在于，所述确定单元还用于，人工干预排障后，当所述第二附件的状态达到所述第一期望目标状态时，确定所述第一附件的升级目标状态是否存在所述第二期望目标状态，所述第二期望目标状态为所述系统升级阶段中所述第一期望目标状态的下一期望目标状态；
    当所述第一附件的升级目标状态存在所述第二期望目标状态时，所述主控制器更新所述第一附件的升级目标状态为所述第二期望目标状态。
  12. 根据权利要求7-11任一项所述的系统升级装置，其特征在于，所述主控制器还包括：互换单元；
    所述确定单元还用于，确定所述第一附件是否属于主控制器中的附件；
    所述互换单元，用于当所述第二附件为所述系统升级装置所属的主控制器内的附件时，所述主控制器与所有从控制器中的一个从控制器进行功能互换，并由功能互换后的主控制器控制所有从控制器中的一个或多个从控制器进行所述第二附件的升级。
  13. 一种系统升级装置，其特征在于，所述系统升级装置包括处理器和与所述处理器耦合连接的存储器；
    所述存储器存储计算机指令；
    所述处理器读取并执行所述存储器存储的计算机指令，使得所述系统升级装置执行权利要求1至6任一项所述的系统升级方法。
PCT/CN2016/104446 2016-04-28 2016-11-03 系统升级方法和系统升级装置 WO2017185706A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610277792.6A CN107341024B (zh) 2016-04-28 2016-04-28 系统升级方法和系统升级装置
CN201610277792.6 2016-04-28

Publications (1)

Publication Number Publication Date
WO2017185706A1 true WO2017185706A1 (zh) 2017-11-02

Family

ID=60161866

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/104446 WO2017185706A1 (zh) 2016-04-28 2016-11-03 系统升级方法和系统升级装置

Country Status (2)

Country Link
CN (1) CN107341024B (zh)
WO (1) WO2017185706A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110609707B (zh) * 2018-06-14 2021-11-02 北京嘀嘀无限科技发展有限公司 在线数据处理系统生成方法、装置及设备
CN111625254B (zh) * 2020-05-06 2023-09-08 Oppo（重庆）智能科技有限公司 文件处理方法、装置、终端及存储介质
CN113485729A (zh) * 2021-06-16 2021-10-08 义乌吉利自动变速器有限公司 控制器升级方法、装置及计算机存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159605A (zh) * 2007-10-25 2008-04-09 中兴通讯股份有限公司 一种可实现状态记忆和恢复的流程控制方法
CN102830984A (zh) * 2011-06-14 2012-12-19 联想(北京)有限公司 固件更新的方法、芯片以及通信终端
CN103123586A (zh) * 2011-11-17 2013-05-29 英业达股份有限公司 基于Linux嵌入式操作系统的升级装置及方法
CN103713925A (zh) * 2013-12-26 2014-04-09 北海创新科存储技术有限公司 避免存储阵列在升级过程的业务中断方法和装置
CN103778026A (zh) * 2012-10-24 2014-05-07 阿里巴巴集团控股有限公司 对象调用方法和装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030005426A1 (en) * 2001-06-08 2003-01-02 Scholtens Dale A. Methods and apparatus for upgrading software without affecting system service
US7739680B1 (en) * 2005-07-21 2010-06-15 Sprint Communications Company L.P. Application server production software upgrading with high availability staging software
US7675638B2 (en) * 2006-01-13 2010-03-09 Infoprint Solutions Company, Llc Notification escalation in printing systems using dynamically determined timeout values
US7818740B2 (en) * 2006-05-05 2010-10-19 Microsoft Corporation Techniques to perform gradual upgrades
CN100536415C (zh) * 2006-09-26 2009-09-02 腾讯科技（深圳）有限公司 一种Web服务系统升级方法及系统
US20090265699A1 (en) * 2008-04-18 2009-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for embedding upgrade steps for layered architectures
TWI479505B (zh) * 2010-12-16 2015-04-01 Phison Electronics Corp 資料管理方法、記憶體控制器與記憶體儲存裝置
CN103605552B (zh) * 2013-11-29 2017-12-29 Tcl通力电子（惠州）有限公司 Mcu的升级方法和装置
CN105094875A (zh) * 2014-05-19 2015-11-25 中兴通讯股份有限公司 一种软件升级方法及装置
CN104166577B (zh) * 2014-08-26 2019-04-05 努比亚技术有限公司 一种移动终端系统升级的方法和装置
CN104965736B (zh) * 2015-06-19 2018-04-27 青岛海信移动通信技术股份有限公司 一种连续升级的方法及装置
CN105068834B (zh) * 2015-08-04 2018-02-09 广东欧珀移动通信有限公司 系统升级方法及装置
CN105259806B (zh) * 2015-10-16 2018-01-23 珠海格力电器股份有限公司 控制器升级方法和系统及主控制器和从控制器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159605A (zh) * 2007-10-25 2008-04-09 中兴通讯股份有限公司 一种可实现状态记忆和恢复的流程控制方法
CN102830984A (zh) * 2011-06-14 2012-12-19 联想(北京)有限公司 固件更新的方法、芯片以及通信终端
CN103123586A (zh) * 2011-11-17 2013-05-29 英业达股份有限公司 基于Linux嵌入式操作系统的升级装置及方法
CN103778026A (zh) * 2012-10-24 2014-05-07 阿里巴巴集团控股有限公司 对象调用方法和装置
CN103713925A (zh) * 2013-12-26 2014-04-09 北海创新科存储技术有限公司 避免存储阵列在升级过程的业务中断方法和装置

Also Published As

Publication number Publication date
CN107341024B (zh) 2020-02-14
CN107341024A (zh) 2017-11-10

Similar Documents

Publication Publication Date Title
TWI633487B (zh) 自動回復基本輸入輸出系統映像檔的方法及電腦系統
US20240113989A1 (en) Automated network change system
US9207929B2 (en) Integrated system and firmware update method
CN105974879B (zh) 数字仪控系统中的冗余控制设备、系统及控制方法
US9329959B2 (en) Device and method for performing regression testing on bios boot information
WO2017185706A1 (zh) 系统升级方法和系统升级装置
CN110874261B (zh) 可用性系统、方法和存储有程序的存储介质
US20070043972A1 (en) Systems and methods for split mode operation of fault-tolerant computer systems
JP2013534664A5 (zh)
CN111488233A (zh) 一种处理PCIe设备掉带宽问题的方法及系统
JP5910444B2 (ja) 情報処理装置、起動プログラム、および起動方法
WO2016045439A1 (zh) 一种vnfm容灾保护的方法、装置和nfvo、存储介质
JP2009140194A (ja) 障害回復環境の設定方法
US11314665B2 (en) Information processing system, information processing device, BIOS updating method for information processing device, and BIOS updating program for information processing device
TW202034176A (zh) 伺服器系統、集中式快閃記憶體模組以及更新快閃韌體映像檔的方法
CN104579802A (zh) 一种多路服务器快速故障恢复的方法
TWI786871B (zh) 電腦和系統啓動方法
EP3502875A1 (en) Seamless and safe upgrade of software intensive systems during operation
JP2016200981A (ja) 運用管理プログラム、運用管理方法、および運用管理装置
WO2016177127A1 (zh) 单板升级方法及装置
TWI528287B (zh) 伺服器系統
US9430013B2 (en) Electrical installation having an uninterruptible power supply
US9953293B2 (en) Method for controlling changes of replication directions in a multi-site disaster recovery environment for high available application
US20130111454A1 (en) Technique for updating program being executed
TWI547873B (zh) 端點伺服器的控制模組及其韌體更新方法

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 16900214

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16900214

Country of ref document: EP

Kind code of ref document: A1