WO2010010633A1 - 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム - Google Patents

機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム Download PDF

Info

Publication number
WO2010010633A1
WO2010010633A1 PCT/JP2008/063432 JP2008063432W WO2010010633A1 WO 2010010633 A1 WO2010010633 A1 WO 2010010633A1 JP 2008063432 W JP2008063432 W JP 2008063432W WO 2010010633 A1 WO2010010633 A1 WO 2010010633A1
Authority
WO
WIPO (PCT)
Prior art keywords
fiber channel
rom
channel card
parameter data
interface
Prior art date
Application number
PCT/JP2008/063432
Other languages
English (en)
French (fr)
Inventor
宮内　啓次
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to EP08791676.3A priority Critical patent/EP2320324B1/en
Priority to PCT/JP2008/063432 priority patent/WO2010010633A1/ja
Priority to JP2010521574A priority patent/JP5163744B2/ja
Publication of WO2010010633A1 publication Critical patent/WO2010010633A1/ja
Priority to US12/929,429 priority patent/US8429392B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16—Constructional details or arrangements
    • G06F1/1613—Constructional details or arrangements for portable computers
    • G06F1/1632—External expansion units, e.g. docking stations

Definitions

  • the present invention relates to a function expansion device, an information processing device, an information processing system, a control method, and a program.
  • SAN Storage Area Network
  • RAID Redundant Arrays of Independent Disks
  • OS indicates Operating System.
  • the SAN boot in the above SAN environment will be described.
  • the SAN boot is a function for starting up the OS on the server from the RAID device connected via the fiber channel (that is, boot, the same applies hereinafter), not the internal disk of the server.
  • a fiber channel card in a system environment having a SAN boot function is equipped with a boot code for enabling an OS boot from a connected RAID device.
  • the operator sets information related to the RAID device to be connected using the boot code in advance along with the boot code on the fiber channel card from the firmware.
  • the information related to the RAID device includes, for example, a WWN (World Wide Name) of the RAID device, Target ID information, topology information, Link Speed information, and the like of the disk.
  • the boot code means a program for reading OS data from a storage device such as a RAID device connected to the outside of the server and starting it.
  • the driver means a program for controlling the Fiber Channel card that runs on the OS of the server.
  • the fiber channel is one of data transfer methods for connecting computers and peripheral devices, and is mainly used for transferring a serial SCSI (Small Computer System Interface) protocol.
  • Link Speed means the transfer speed of the fiber channel.
  • PCI-Express means a server bus for connecting an interface card used for connecting a peripheral device.
  • RAID means a device that controls and manages a plurality of disks and provides storage resources.
  • the SN means a network for connecting storage devices such as RAID and tape library.
  • Topology means the connection form of Fiber Channel (AL_PA loop connection, N_Port switch connection, etc.).
  • WWN means a unique 8-byte address code used in Fiber Channel communication, and is assigned to a device connected to the Fiber Channel.
  • the system monitoring mechanism means a system that monitors and controls the server status.
  • the built-in disk means a basic disk for storing OS data in the server device.
  • Target ID is a logical ID for identifying a disk.
  • the function expansion device includes a first storage unit that stores first setting information when the information processing device and the external storage device are connected via the first interface.
  • the function expansion device operates based on the first setting information, and has a connection module unit that connects the information processing device and the external storage device via the first interface.
  • the second storage unit stores second setting information when the connection module unit is connected to the first interface, and can be exchanged for the function expansion device with the connection module.
  • the function expansion device is connected to the first storage unit and the connection module unit or the second storage unit, and sets the second setting information stored in the second storage unit in the first storage unit.
  • a control unit is connected to the first storage unit and the connection module unit or the second storage unit, and sets the second setting information stored in the second storage unit in the first storage unit.
  • the connection module of the function expansion device after replacement is replaced with the second storage unit.
  • the control unit of the function expansion device after the replacement obtains the second setting information from the second storage unit and sets it in the first storage unit of the function expansion device.
  • the function live extension device can connect the information processing device and the external storage device via the first interface.
  • FIG. 3 is a diagram (part 1) for describing a configuration of a control program in the server shown in FIG. 2;
  • FIG. 3 is a diagram (No. 2) for explaining a configuration of a control program in the server shown in FIG. 2;
  • 1 is a block diagram for explaining a configuration of a fiber channel card according to Embodiment 1.
  • FIG. FIG. 3 is a block diagram (No. 1) for explaining the function and effect of the fiber channel card according to the first embodiment.
  • FIG. 6 is a block diagram (No. 2) for explaining the function and effect of the fiber channel card according to the first embodiment.
  • FIG. 3 is a flowchart (part 1) for explaining the function and effect of the fiber channel card according to the first embodiment.
  • 6 is a flowchart (No. 2) for explaining the function and effect of the fiber channel card according to the first embodiment.
  • FIG. 6 is a block diagram for explaining a configuration of a fiber channel card according to a second embodiment. It is a block diagram for demonstrating the effect of the fiber channel card by Example 2.
  • FIG. 6 is a flowchart (No. 1) for explaining the operation and effect of the fiber channel card according to the second embodiment.
  • 12 is a flowchart (No. 2) for explaining the function and effect of the fiber channel card according to the second embodiment.
  • FIG. 10 is a block diagram for explaining a configuration of a fiber channel card according to a third embodiment.
  • FIG. 12 is a flowchart (No. 1) for explaining the operation and effect of the fiber channel card according to the third embodiment. 12 is a flowchart (No. 2) for describing the function and effect of the fiber channel card according to the third embodiment.
  • FIG. 10 is a block diagram for explaining a configuration of a fiber channel card according to a fourth embodiment. It is a block diagram for demonstrating the effect of the fiber channel card by Example 4.
  • FIG. 10 is a flowchart (No. 1) for describing the function and effect of the fiber channel card according to the fourth embodiment.
  • 12 is a flowchart (No. 2) for explaining the function and effect of the fiber channel card according to the fourth embodiment.
  • FIG. 10 is a block diagram (No. 1) for explaining the configuration and operational effects of a fiber channel card according to a fifth embodiment.
  • FIG. 10 is a block diagram (No. 2) for explaining the configuration and the function and effect of the fiber channel card according to the fifth embodiment.
  • FIG. 10 is a block diagram (No. 3) for explaining the configuration and the function and effect of the fiber channel card according to the fifth embodiment.
  • FIG. 10 is a block diagram (No. 4) for explaining the configuration and operational effects of a fiber channel card according to Embodiment 5.
  • FIG. 10 is a block diagram (No. 5) for explaining the configuration and operational effects of a fiber channel card according to Embodiment 5.
  • FIG. 10 is a flowchart (No. 1) for explaining the configuration and operational effects of a fiber channel card according to a fifth embodiment.
  • FIG. 10 is a block diagram (No. 2) for explaining the configuration and the function and effect of the fiber channel card according to the fifth embodiment.
  • FIG. 10 is a block diagram (No.
  • FIG. 10 is a flowchart (No. 2) for explaining the configuration and operational effects of a fiber channel card according to Embodiment 5.
  • FIG. FIG. 12 is a block diagram (No. 6) for explaining the configuration and the function and effect of the fiber channel card according to the fifth embodiment.
  • FIG. 10 is a flowchart (No. 3) for explaining the configuration and operational effects of a fiber channel card according to Embodiment 5.
  • a ROM module replaceable with the SFP optical module (hereinafter simply referred to as an optical module) of the card is used.
  • SFP means Small Form Factor Pluggable (that is, removable)
  • ROM Read Only Memory.
  • Parameter data required for SAN boot stored in the ROM on the fiber channel card is stored in the ROM module. As a result, the parameter data can be automatically restored after the failure replacement of the fiber channel card.
  • a server system firmware and a well-known I2C (Inter-Integrated Circuit) bus are used in a SAN boot system from a RAID device connected to a fiber channel card.
  • I2C bus provided together with a PCI (Peripheral Component Interconnect, hereinafter the same) bus or a PCI-Express bus is used.
  • PCI Peripheral Component Interconnect, hereinafter the same
  • PCI-Express PCI-Express
  • a ROM built in the optical module of the fiber channel card is used.
  • the parameter data necessary for SAN boot in the ROM on the fiber channel card is stored in the ROM built in the optical module, and automation of parameter data restoration after failure replacement of the fiber channel card is realized.
  • the parameter data required for the SAN boot in the ROM on the fiber channel card is stored and the parameter data is restored after the failure of the fiber channel card is replaced. Automate the generation of instructions for.
  • the parameter data of all the fiber channel cards in the system are stored in the ROM on one fiber channel card.
  • parameter data restoration of a plurality of Fiber Channel cards can be automatically executed only by restoration operation of one Fiber Channel card.
  • ROM means, for example, the well-known FLASH-ROM, EEPROM, etc. that can be read, written, and erased.
  • FIG. 1 is a block diagram for explaining a configuration of an information processing system according to each embodiment.
  • This information processing system has a SAN environment using a fiber channel as an interface.
  • the server 10 is connected to the RAID device 100 via the fiber channel switch 200.
  • the server 10 also includes a fiber channel card 20 having a configuration for connecting to the fiber channel switch 200.
  • This information processing system has a SAN boot function. For this reason, the fiber channel card 20 is loaded with a boot code for enabling the OS boot from the RAID device 100. That is, information related to the RAID device 100 connected from the server 10 using a boot code (hereinafter referred to as “setting information necessary for SAN boot”) is set in advance in the Fiber Channel card 20 together with the boot code.
  • This setting can be performed by the operator using the server firmware, for example.
  • the setting information necessary for the SAN boot includes, for example, WWN (World Wide Name) of the RAID device, Target ID information of the disk, topology information, Link Speed information, and the like.
  • the WWN is information unique to a device that identifies a RAID device as an external storage device
  • the Target ID information is identification information that individually identifies a drive device included in the RAID device.
  • the topology information is information indicating a connection form of a fiber channel as an interface.
  • Link Speed information is speed information indicating the speed of the fiber channel as an interface.
  • FIG. 2 is a block diagram showing the internal configuration of the server 10.
  • the server 10 has a CPU 11, a FROM 12, a system controller 13, a memory access controller 14, a main storage device 15, a monitoring bus controller 16, an I / O controller 17, and a crossbar switch 18.
  • FROM indicates flash ROM.
  • the system controller 13 controls communication between the CPU 11 and various controllers 14, 16, 17, memory 12, and the like.
  • the FROM 12 is loaded with OBP (which means Open Boot Programmable ROM, hereinafter referred to as system firmware) as system firmware.
  • OBP Open Boot Programmable ROM
  • the memory access controller 14 controls access to the main storage device 15.
  • the monitoring bus controller 16 provides a bus state monitoring function via a service processor (hereinafter simply referred to as SVP) 50 as a system controller.
  • SVP service processor
  • the I / O controller 17 provides an interface with the PCI bus.
  • 3A and 3B show the flow of starting the control program in the server 10 and its configuration.
  • the CPU 11 reads the system firmware from the FROM 12 and develops it in the main storage device 15.
  • this system firmware reads a boot code from a FROM 21 (hereinafter simply referred to as a ROM 21) which is a ROM in the fiber channel card 20, and develops it in the main storage device 15.
  • the system firmware controls the controller 22 of the fiber channel card 20 based on this boot code.
  • the server 10 accesses the RAID device 100 via the fiber channel switch 200 and reads OS data from the RAID device 100. This OS data is expanded in the main storage device 15. Thereafter, the CPU 11 starts up the OS using the OS data.
  • the server 10 enters the control of the activated OS.
  • the OS is started in this way, a driver operating on the OS controls the controller 22 of the fiber channel card 20 as shown in FIG. 3B.
  • the server 10 can access the RAID device 100 via the fiber channel switch 200.
  • Example 1 will be described with reference to FIGS.
  • FIG. 4 is a block diagram illustrating the configuration of the fiber channel card 20 according to the first embodiment.
  • the fiber channel card 20 of the first embodiment has a controller 22 and a ROM 21.
  • the fiber channel card 20 can have the same configuration as a well-known fiber channel card, and detailed description thereof will be omitted.
  • setting information necessary for the SAN boot is recorded in the ROM 21.
  • the fiber channel controller 22 has an optical module 31 for connecting a fiber channel cable 80 that connects the fiber channel switch 200.
  • the optical module 31 is a detachable optical module as described above, and has a configuration that can be inserted into and removed from the fiber channel card 20.
  • a path of I2C hereinafter, sometimes referred to as SFP I2C
  • SFP I2C path of I2C
  • a read / write command for reading / writing the ROM 20 via the fiber channel controller 22 can be used.
  • parameter data can be set in the ROM 21 and parameter data can be read out from the ROM 21.
  • the parameter data of the setting information necessary for the SAN boot is written into the built-in ROM 32a (see FIG. 5A, etc.) of the ROM module 32 using the I2C path 24.
  • This operation is performed by the system firmware of the server 10 using an I2C write command for SFP.
  • the ROM module 32 has the built-in ROM 32a, has a structure replaceable with the optical module 31, and has an I2C interface.
  • the writing operation is performed with the optical module 31 replaced with the ROM module 32.
  • the ROM module 32 is also a detachable module similar to the optical module 31 and can be inserted into and removed from the fiber channel card 20. That is, the ROM module 32 and the optical module 31 are interchangeable with each other with respect to the fiber channel card 20.
  • parameter data such as the WWN of the connection destination RAID device 100, the Target ID of the RAID device 100, the Link Speed, and the like, which are setting information necessary for the SAN boot stored in the ROM 21, are extracted.
  • the extracted parameter data is stored in the built-in ROM 32a of the ROM module 32.
  • the ROM module 32 is mounted on the fiber channel card 20, and the system firmware of the server 10 uses the I2C read command based on the boot code.
  • parameter data can be read from the built-in ROM 32 a of the ROM module 32 and written to the ROM 21.
  • This read / write operation is automatically executed by the fiber channel controller 22 in accordance with an instruction from the system firmware.
  • parameter data as setting information necessary for SAN boot can be saved in the built-in ROM 32a of the ROM module 32, and can be restored from the built-in ROM 32a of the ROM module 32 to the ROM 21.
  • the ROM module 32 is mounted on the new fiber channel card.
  • the system firmware of the server 10 reads the parameter data from the built-in ROM 32a of the ROM module 32 and writes it into the ROM 21 of the new fiber channel card.
  • This read / write operation is realized by the system firmware instructing the fiber channel controller 22 of the new fiber channel card.
  • the parameter data can be restored.
  • the setting information necessary for the SAN boot can be held outside the Fiber Channel card 20, and can be restored in the replaced Fiber Channel card by using the setting information.
  • This information transfer operation is automatically performed when the system firmware of the server 10 instructs the fiber channel controller 22. For this reason, it is possible to effectively prevent information setting errors that may occur when information is handed over artificially.
  • parameter data as setting information necessary for SAN boot is transferred to another location (specifically, the built-in ROM 32a of the ROM module 32) via a general interface (specifically, I2C). Evacuate to. After the replacement of the fiber channel card 20, the environment is taken over by reading the saved parameter data from another location.
  • the ROM module 32 corresponding to the I2C interface is connected to the I2C interface 24 used for confirming information about the optical module 31 provided separately from the fiber channel communication signal.
  • the optical module 31 mounted on the fiber channel card 20 is removed and replaced with the ROM module 32.
  • the parameter data stored in the ROM 21 is stored in the built-in ROM 32a of the connected ROM module 32. That is, the parameter data read from the ROM 21 by using the I2C write command is written to the ROM 32a built in the ROM module 32 related to the exchange.
  • the optical module 31 of the new fiber channel card 20 ′ is temporarily replaced with the ROM module 32 (FIG. 5B).
  • the parameter data written in the built-in ROM 32a is read from the ROM module 32 as described above.
  • the read parameter data is written in the ROM 21 of the new fiber channel card 20 ′.
  • the parameter data stored in the ROM 21 of the fiber channel card 20 before replacement can be taken over to the ROM 21 of the new fiber channel card 20 ′ after replacement.
  • the ROM module 32 is removed from the new Fiber Channel card 20 ′.
  • the optical module 31 originally mounted on the fiber channel card 20 ′ is mounted on the fiber channel card 20 ′ as it is.
  • the new fiber channel card 20 ′ can execute the SAN boot of the server 10 by using the parameter data written in the ROM 21 as in the case of the fiber channel card 20 before replacement.
  • FIGS. 6 and 7 together with FIGS. 5A and 5B, the function and effect of the first embodiment will be described in more detail.
  • the administrator confirms the connected RAID device 100 to which the server 10 is connected (step S31 in FIG. 6). Thereafter, the administrator mounts the Fiber Channel card 20 on the server (step S32). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S33). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, related to the RAID device 100 of the connection destination in the Fiber Channel card 20 (step S34).
  • the administrator replaces the optical module 31 mounted on the fiber channel card 20 of the server 10 with the ROM module 32 (step S35). Thereafter, the administrator instructs the boot code in the ROM 21 of the fiber channel card 20 from the management terminal 60 using the system firmware. Based on the instructed boot code, parameter data is read into the server 10 from the ROM 21 of the fiber channel card 20 using the ROM read command of the fiber channel controller 21 and the read command of PCI or PCI-Express. The read parameter data is written to the fiber channel controller 22 using a PCI or PCI-Express write command.
  • the written parameter data is transferred to the Fiber Channel controller 22 and the I2C path of the Fiber Channel card using the I2C write command based on the boot code according to the above instruction. And is written into the built-in ROM 32a of the ROM module 32 related to the exchange (step S36).
  • the administrator After writing the parameter data to the built-in ROM 32a of the ROM module 32, the administrator replaces the ROM module 32 mounted on the fiber channel card 10 mounted on the server 10 with the original optical module 31 (step S37). Thereafter, the ROM module 32 is stored.
  • step S38 the administrator operates the management terminal 60 to start the OS on the server 10 by SAN boot.
  • parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • step S41 when the fiber channel card 20 fails (step S41), the administrator replaces the fiber channel card 20 mounted on the server 10 with a new fiber channel card 20 ′ (step S42). Thereafter, the administrator operates the management terminal 60 to activate the system firmware of the server 10 (step S43).
  • the administrator further replaces the optical module 31 of the new fiber channel card 20 ′ after the replacement with the ROM module 32 related to the storage (step S44).
  • the administrator instructs the boot code in the ROM 21 of the fiber channel card 20 ′ from the management terminal 60 using the system firmware.
  • the instructed boot code performs the following operation using an I2C read command. That is, parameter data is read from the built-in ROM 32a of the replaced ROM module 32 into the fiber channel controller 22 of the new fiber channel card 20 ′ after the replacement via the SFP I2C.
  • the parameter data is read from the fiber channel controller 22 to the server 10 using a PCI or PCI-Express read command.
  • the parameter data is written into the ROM 21 of the new fiber channel card 20 ′ using the ROM write command of the fiber channel controller 22 and the PCI or PCI-Express write command (step S45).
  • the ROM module 32 mounted on the new fiber channel card 20 ′ is replaced with the optical module 31 and restored (step S46).
  • the ROM module 32 is stored again.
  • step S47 the administrator operates the management terminal 60 and starts the OS on the server 10 by SAN boot (step S47).
  • the SAN boot parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20 ′.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • the ROM module 32 including the ROM 32a that is replaceable with the optical module 31 and can be connected to the I2C interface is used. That is, a ROM module 32 as an element capable of storing parameter data is connected.
  • the I2C interface for connection between the fiber channel controller 22 and the optical module 31 is originally used for checking the status and information of the optical module 31.
  • This I2C interface is used for reading / writing parameter data from / to the ROM module 32 after replacement.
  • the boot code has a function to read / write parameter data in the ROM 21.
  • parameter data can be automatically read from and written to the built-in ROM 32a of the ROM module 32 using an I2C read / write command.
  • the parameter data read / write instruction is manually performed from the server 10 using a boot code control command.
  • the following operation is performed by exchanging the ROM module 32 and operating a control command on the system firmware. That is, for the SAN boot, the parameter data as setting information is backed up and the parameter data is recovered to the ROM 21 after the fiber channel card is replaced. As a result, it is not necessary for the administrator to check configuration information or input parameter data when replacing the fiber channel card, and the work can be shortened.
  • the parameter data of the Fiber Channel card 20 mounted on the server 10 is retained in the built-in ROM 32a of the ROM module 32, so that the setting information is accurately retained even after a failure replacement of the Fiber Channel card. Work mistakes can be avoided.
  • the I2C interface between the fiber channel controller 20 and the optical module 31 originally used for confirming the information of the optical module 31 is used.
  • the ROM module 32 is used for storing parameter data as setting information necessary for SAN boot by connecting to the optical module 31 and a ROM module 32 that can be connected to I2C. Note that reading and writing of data between the fiber channel controller 22 and the optical module 31 is automatically executed by a boot code executed on the system firmware. In this case, an I2C read / write command is used.
  • Example 2 will be described with reference to FIGS.
  • the configuration of the second embodiment is the same as the configuration of the first embodiment, and different parts will be mainly described.
  • setting information necessary for SAN boot is recorded in the ROM 21 of the fiber channel card 20.
  • the server 10 has an I2C path 42 used to confirm information of the Fiber Channel controller 22 on the Fiber Channel card 20.
  • parameter data can be set or read from the SVP 50 of the server 10 to the ROM 21 using the ROM read / write command of the fiber channel controller 22.
  • the parameter data stored in the ROM 21 is read into the server SVP 50 via the I2C path by the SVP 50 of the server 10 using an I2C read command related to the PCI and PCI-Express buses.
  • each parameter data such as WWN of the connection destination RAID device, Target ID information of the RAID device, Link Speed, etc., which is setting information necessary for the SAN boot stored in the ROM 21 is extracted and stored in the server 10.
  • parameter data is written from the server 10 to the ROM 21 of the fiber channel card 20 via the I2C path using an I2C write command executed on the SVP 50.
  • parameter data as setting information necessary for SAN boot is stored in the server 10, and the data is restored from the server 10 to the ROM 21 of the fiber channel card 20 using the parameter data related to the storage. .
  • an operation for writing parameter data from the server 10 to the ROM 21 on the SVP 50 is instructed from the SVP 50.
  • the parameter data can be restored.
  • setting information necessary for the SAN boot is held and restored. As a result, it is possible to easily carry out information transfer when the fiber channel card 20 fails. Further, it is possible to reliably prevent setting mistakes during information transfer.
  • an I2C interface used for information confirmation of the fiber channel card 20 is used separately from the interface of the PCI and PCI-Express signals. Then, using this I2C interface, the parameter data in the ROM 21 on the fiber channel card 20 is read and stored in the server 10. That is, the parameter data is read from the ROM 21 to the server 10 using the I2C read command and the fiber channel controller 22 ROM read command. After the replacement of the fiber channel card 20, parameter data is written from the server 10 to the fiber channel controller 22 of the new fiber channel card 20 ′ after the replacement by using an I2C write command. Then, by using the ROM write command of the fiber channel controller, the parameter data is written to the ROM 21 of the new fiber channel card 20 ′. By performing this operation, the parameter data of the fiber channel card 20 before replacement can be taken over on the new fiber channel card 20 ′ that has been replaced.
  • the administrator confirms the connection destination RAID apparatus 100 to which the server 10 is connected (step S51 in FIG. 10). Thereafter, the administrator mounts the Fiber Channel card 20 on the server 10 (step S52). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S53). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, related to the RAID device 100 of the connection destination in the Fiber Channel card 20 (step S54).
  • the administrator instructs the ROM read command and the I2C read command of the Fiber Channel controller 20 on the Fiber Channel card 20 from the management terminal 60 using the SVP 50 of the server 10.
  • parameter data is read into the server 10 from the ROM 21 on the Fiber Channel card 20 via the I2C between the server 10 and the Fiber Channel card 20, and is under system firmware management in the server 20 or The data is stored in the ROM under the management of the SVP 50 (step S55).
  • step S56 the administrator operates the management terminal 60 and starts the OS on the server 10 by SAN boot (step S56).
  • the SAN boot parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • step S61 when the fiber channel card 20 fails (step S61), the administrator replaces the fiber channel card 20 mounted on the server 10 with a new fiber channel card 20 ′ (step S62). Thereafter, the administrator operates the management terminal 60 to activate the system firmware of the server 10 (step S63).
  • the administrator instructs the I2C write command and the ROM write command of the fiber channel controller 22 from the management terminal 60 using the SVP 50.
  • the SVP 50 reads the parameter data related to the storage and writes it into the ROM 21 of the new fiber channel card 20 ′ via the I2C (step S64).
  • the parameter data related to the storage is parameter data stored in the ROM under the management of the system firmware or the SVP 50 by the operation described above with reference to FIG.
  • the administrator operates the management terminal 60 to start the OS on the server 10 by SAN boot (step S65).
  • the I2C path 42 between the server 10 and the fiber channel controller 22 of the new fiber channel card 20 ′ is originally used for monitoring the status of the fiber channel controller 22.
  • the I2C path 42 is used to read / write parameter data in the ROM 21 of the fiber channel card.
  • the SVP 50 of the server 10 automatically reads / writes parameter data from / to the ROM 21 using I2C read / write commands. In this way, parameter data can be saved and restored. It is possible to automatically issue an instruction to read / write parameter data. That is, the SVP 50 uses a function of detecting that the Fiber Channel card 20 has been replaced and setting information. With these functions, it is possible to automatically issue an instruction to read / write parameter data when the Fiber Channel card 20 is detected to be replaced and the setting information is detected. It is.
  • the following operation can be executed by operating the control command on the SVP 50 of the server 10. . That is, parameter data as setting information necessary for SAN boot is backed up, and after replacement of the fiber channel card 20, recovery to the ROM 21 of a new fiber channel card 20 ′ is performed. As a result, it is not necessary to confirm configuration information or input parameter data when replacing the Fiber Channel card 20, and the work can be shortened. Further, the parameter data of the fiber channel card 20 mounted on the server 10 is held in the server 10 (actually, the ROM under the management of the system firmware or the SVP 50 as described above).
  • the I2C interface on the PCI-Express bus is used for reading and writing parameter data.
  • the parameter data as the setting information necessary for the SAN boot is stored in the server 10 and the parameter data is restored on the new Fiber Channel card 20 ′.
  • Data read / write between the server 10 and the fiber channel controller is performed by the SVP 50 of the server 10 using an I2C read / write command.
  • the SVP 50 has a function of automatically detecting the replacement of the fiber channel card 20 and the presence of parameter data.
  • the SVP 50 detects that the Fiber Channel card 20 mounted on the server 10 has been replaced with a new Fiber Channel card 20 ′, and parameter data is stored in a ROM under system firmware management or SVP 50 management. Detect that. When these detections are triggered, the SVP 50 reads the parameter data from the ROM under the management of the system firmware or the management of the SVP 50, and writes this into the ROM 21 of the fiber channel card 20 ′ related to the replacement. That is, in the second embodiment, the operation of restoring parameter data as setting information necessary for SAN boot is fully automated.
  • parameter data storage is further automated. That is, the first Fiber Channel card mounted on the server 10 is replaced with the second Fiber Channel card, and parameters are already set in the ROM 21 of the second Fiber Channel card.
  • the SVP 50 detects the replacement of the fiber channel card and also detects that parameter data is stored in the ROM 21 on the second fibre-channel card. Using these detections as triggers, the SVP 50 reads parameter data from the ROM 21 on the second Fiber Channel card. The SVP 50 writes the read parameter data in the ROM under the management of the system firmware or the SVP 50. That is, in the second embodiment, the operation of saving parameter data as setting information necessary for SAN boot is fully automated.
  • Example 3 will be described with reference to FIGS.
  • the configuration of the third embodiment is the same as the configuration of the first embodiment, and different parts will be mainly described.
  • setting information necessary for SAN boot is recorded in the ROM 21 of the fiber channel card 20.
  • an I2C path used for confirming the information of the optical module 31 between the fiber channel controller 22 of the fiber channel card 20 and the optical module 31.
  • the ROM 31a in the optical module 31 stores type information (namely, manufacturer name and manufacturer model number) and status information of the optical module 31.
  • parameter data can be set or read from the system firmware of the server 10 to the ROM 21 using the ROM read / write command of the fiber channel controller 22.
  • parameter data is written to the ROM 31a in the optical module 31 by using an I2C write command for SFP using a boot code executed by the system firmware in the ROM 21 of the fiber channel card 20. That is, each parameter data as setting information necessary for SAN boot stored in the ROM 21 is extracted. The extracted parameter data is stored in the ROM 31a in the optical module 31.
  • the parameter data includes, for example, the WWN of the connection destination RAID device, the Target ID information of the RAID device, Link Speed, and the like.
  • the parameter data is read from the ROM 31a in the optical module 31 by using an I2C read command for SFP by a boot code executed on the system firmware.
  • the read parameter data is written to the ROM 21 on the fiber channel card 20.
  • the parameter data is stored in the built-in ROM 31a of the optical module 31.
  • the parameter data is restored from the built-in ROM 31a to the ROM 21 of the fiber channel card 20.
  • the parameter data is read from the ROM 31a of the optical module 31 using the system firmware of the server 10 after the failure replacement of the fiber channel card 20.
  • the read parameter data is written into the ROM 21 of the new fiber channel card 20 ′ after replacement.
  • This read / write operation can be executed by an administrator instructing using the system firmware of the server 10. As a result, the parameter data can be easily restored even when the fiber channel card 20 is replaced.
  • the setting information of the Fiber Channel card 20 storing the setting information necessary for the SAN boot is held and restored, and the information can be easily taken over when the Fiber Channel card 20 fails.
  • the ROM 31a in the optical module 31 connected to the I2C interface used for confirming information of the optical module, which is separate from the fiber channel communication interface, is used.
  • the parameter data stored in the ROM 21 of the fiber channel card 20 is stored in the ROM 31a. That is, by using an I2C write command, the parameter data read from the ROM 21 is written to the ROM 31 a in the optical module 31. After the replacement of the fiber channel card 20, the following operation is performed.
  • the parameter data of the fiber channel card before replacement is read from the ROM 31a of the optical module 31 mounted on the fiber channel card 20 before replacement.
  • the read parameter data is written to the ROM 21 of the new fiber channel card 20 ′ after replacement.
  • the parameter data of the fiber channel card 20 before replacement is transferred to the new fiber channel card 20 ′ after replacement.
  • the administrator checks the connected RAID device 100 to which the server 10 is connected (step S71 in FIG. 14). Thereafter, the administrator mounts the Fiber Channel card 20 on the server 10 (step S72). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S73). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, related to the RAID device 100 of the connection destination in the Fiber Channel card 20 (step S74).
  • the administrator uses the system firmware of the server 10 from the management terminal 60 to instruct the boot code stored in the ROM 21 of the fiber channel card 20.
  • the parameter data is read into the server 10 from the ROM 21 of the fiber channel card 20 by the instructed boot code.
  • the ROM read command of the fiber channel controller 22 and the PCI or PCI-Express read command are used.
  • the read parameter data is written to the fiber channel controller 22 using a PCI or PCI-Express write command.
  • the read parameter data is written to the fiber channel controller 22, the read parameter data is written to the ROM 31a in the optical module 31 mounted on the fiber channel card 20 by using the I2C write command by the boot code. .
  • This write operation is performed via the fiber channel controller 22 and the SFP I2C of the fiber channel card 20 (step S75).
  • step S76 the administrator operates the management terminal 60 and starts the OS on the server 10 by SAN boot.
  • parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • step S81 when the fiber channel card 20 fails (step S81), the administrator replaces the fiber channel card 20 installed in the server 10 with a new fiber channel card 20 ′ (step S82).
  • step S82 when replacing the fiber channel card 20, the administrator removes the optical module 31 from the original fiber channel card 20 and attaches it to the new fiber channel card 20 ′. Thereafter, the administrator operates the management terminal 60 to activate the system firmware of the server 10 (step S83).
  • the administrator instructs the boot code stored in the ROM 21 of the fiber channel card 20 ′ from the management terminal 60 using the system firmware.
  • parameter data is read from the ROM 31a of the optical module 31 to the fiber channel controller 22 via the I2C for SFP using the I2C read command.
  • the optical module 31 in this case is an optical module 31 that is removed from the original fiber channel card 20 and attached to the new fiber channel card 20 ′.
  • the parameter data is read from the fiber channel controller 22 to the server 10 by using a PCI, PCI-Express read command.
  • the read parameter data is written to the ROM 21 of the new fiber channel card 20 ′ after the replacement.
  • the ROM write command of the fiber channel controller 22 and the PCI or PCI-Express write command are used (step S84).
  • step S85 the administrator operates the management terminal 60 and starts the OS on the server 10 by SAN boot (step S85).
  • the SAN boot parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20 ′.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • the ROM 31a in the optical module 31 is used as an element capable of storing parameter data.
  • the I2C interface connected between the fiber channel controller 22 and the optical module 31 is originally used for checking the status and information of the optical module.
  • this I2C interface is used for reading and writing parameter data.
  • the boot code has the function of reading and writing parameter data in the ROM 21. Further, a function for reading / writing parameter data from / to the ROM 31a of the optical module 31 via the controller 22 and SFP I2C is provided in the boot code. As a result, automatic reading and writing of parameter data in the ROM 31a of the optical module 31 using the I2C read / write command by the boot code is realized.
  • the instruction to read / write the parameter data is manually issued from the server using a boot code control command.
  • the parameter data as the setting information necessary for the SAN boot is automatically backed up by the operation of the control command using the system firmware. Further, after the replacement of the fiber channel card 20, the parameter data is automatically recovered to the ROM 21 of the new fiber channel card 20 ′. As a result, it is not necessary to confirm the configuration information and input parameter data when replacing the fiber channel card 20, and the work can be shortened.
  • the parameter data of the fiber channel card 20 mounted on the server 10 is held in the ROM 31a of the optical module 31.
  • the I2C interface between the fiber channel controller 22 and the optical module 31 originally used for confirming the information of the optical module is used for parameter data transfer. That is, this I2C interface is used for storing and restoring parameter data as setting information necessary for SAN boot using the ROM 31a of the optical module 31. Note that reading / writing of data between the fiber channel controller 22 and the optical module 31 is executed by a boot code executed by the system firmware of the server 10 using an I2C read / write command.
  • Example 4 will be described with reference to FIGS.
  • the configuration of the fourth embodiment is the same as the configuration of the first embodiment, and different parts will be mainly described.
  • setting information necessary for SAN boot is recorded in the ROM 21 of the fiber channel card 20.
  • an I2C path 24 used to check the information of the optical module 31 between the fiber channel controller 22 and the optical module 31.
  • the following operations can be performed from the system firmware of the server 10 using the ROM read / write command of the fiber channel controller 22 of the fiber channel card 20. That is, parameter data is set in the ROM 21 on the fiber channel card 20 or parameter data is read from the ROM 21.
  • a detection signal path 25 is provided between the fiber channel controller 22 and the optical module 31. By confirming the voltage level of the detection signal, the system firmware can confirm the insertion / removal state of the optical module 31 with respect to the Fiber Channel card 20.
  • the parameter data is written to the built-in ROM 32a of the ROM module 32 by using the I2C write command for SFP using the boot code executed by the system firmware in the ROM 21. That is, each parameter data such as WWN of the connection destination RAID device, Target ID information of the RAID device, Link Speed, etc., which is setting information necessary for SAN boot stored in the ROM 21 is extracted from the ROM 21. The extracted parameter data is stored in the built-in ROM 32a of the ROM module 32 that can be connected to an I2C interface exchangeable with the optical module 31.
  • the ROM module 32 is mounted on the replaced Fiber Channel card 20 ′, parameter data is read from the built-in ROM 32a of the ROM module 32 using an I2C read command for SFP, and the parameter data is read from the Fiber Channel card.
  • each of the optical module 31 and the ROM module 32 exchangeable with the optical module 31 is provided with a detection signal path 25 and connected to the ground.
  • a change in the insertion / extraction state of the optical module 31 or the ROM module 32 can be confirmed from the fiber channel card.
  • an instruction from the manager from the management operation terminal 60 becomes unnecessary.
  • the parameter data is saved from the fiber channel card 20 to the built-in ROM 32a of the ROM module 32 and the parameter data is restored to the fiber channel card 20 ′ after replacement by automatic control by the system firmware of the server 10.
  • the parameter data can be stored in the built-in ROM 32a of the ROM module 32, and the parameter data can be restored from the built-in ROM 32a of the ROM module 32 to the ROM 21 of the fiber channel card 20 ′ after replacement.
  • the parameter data is read from the built-in ROM 32a of the ROM module 32 by the system firmware, and written to the ROM 21 of the new Fiber Channel card 20 ′ after replacement.
  • This read / write operation is realized by the system firmware automatically instructing the change of the detection signal as a trigger. In this way, the parameter data can be restored in the new fiber channel card 20 ′.
  • the setting information of the fiber channel fiber channel card 20 storing the setting information necessary for the SAN boot can be easily retained and restored, and information can be easily taken over when the fiber channel card 20 fails.
  • the ROM module 32 corresponding to the I2C interface is connected to the I2C interface used for checking the information of the optical module 31, which is separate from the fiber channel communication interface. Then, the parameter data in the ROM 21 in the fiber channel card 20 is stored in the built-in ROM 32a of the connected ROM module 32. In this case, by using the I2C write command, the parameter data read from the ROM 21 is written into the built-in ROM 32a of the ROM module 32 exchanged with the optical module 31. After the replacement of the fiber channel card 20, the parameter data is read from the built-in ROM 32a of the ROM module 32 by using an I2C read command.
  • the parameter data is written into the ROM 21 in the new fiber channel card 20 ′ after replacement.
  • the parameter data of the fiber channel card 20 before replacement is transferred to the new fiber channel card 20 ′ after replacement.
  • the above operation can be executed by automatic control by the system firmware of the server 10 by using the detection signal path 25 of the optical module 31 or the ROM module 32.
  • the system firmware uses as a trigger the state change of the detection signal when the detection signal of the path 25 of the detection signal is changed from the open level (that is, unconnected state) to the ground level (that is, connected state). That is, when the optical module 31 is removed from the fiber channel card 20 and the ROM module 32 is installed instead, the ROM module 32 after installation is in a connected state. As a result, the path 25 of the detection signal becomes the ground level, and the system firmware detects that the ROM module 32 has been replaced in this way.
  • the system firmware when saving the parameter data, the system firmware detects that the optical module 31 has been replaced with the ROM module 32 on the fiber channel card 20 based on the level of the detection signal. Further, the system firmware confirms that the parameter data is stored in the ROM 21 of the fiber channel card 20. At the time of detection and confirmation, these are used as triggers, and the system firmware automatically reads the parameter data from the ROM 21 and writes it into the built-in ROM 32a of the ROM module 32. That is, the parameter data is automatically saved.
  • the system firmware detects that the optical module 31 has been replaced with the ROM module 32 on the fiber channel card 20 ′ based on the level of the detection signal. Further, the system firmware confirms that the parameter data is stored in the built-in ROM 32a of the ROM module 32 related to the replacement. At the time of detection and confirmation, these are used as triggers, and the system firmware automatically reads the parameter data from the built-in ROM 32a of the ROM module 32 and writes it into the ROM 21 of the fibre-channel card 20 ′. That is, the parameter data is automatically restored.
  • the administrator confirms the connected RAID device 100 to which the server 10 is connected (step S91 in FIG. 18). Thereafter, the administrator mounts the Fiber Channel card 20 on the server 10 (step S92). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S93). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, related to the RAID device 100 of the connection destination in the Fiber Channel card 20 (step S94).
  • the administrator replaces the optical module 31 of the fiber channel card 20 mounted on the server 10 with the ROM module 32 (step S95).
  • the system firmware of the server 10 confirms the state of the detection signal. As a result, when it is confirmed that the detection signal is changed from the unconnected state (open level) to the connected state (ground level), an operation of reading data from the built-in ROM 32a of the ROM module 32 is performed. In the read operation, the system firmware uses an I2C read command. Here, the internal ROM 32a of the ROM module 32 is in an empty state in which no data is written. This empty state is confirmed by the system firmware. Further, the system firmware confirms that the parameters are written in the ROM 21 using the ROM read command of the fiber channel controller 22.
  • the system firmware reads the parameter data from the ROM 21 of the fiber channel card 20 into the server 10.
  • the ROM read command of the fiber channel controller 22 and the read command of PCI or PCI-Express are used.
  • the read parameter data is written to the fiber channel controller 22 using a PCI or PCI-Express write command.
  • the system firmware performs the following operation using the I2C write command.
  • the written parameter data is written into the built-in ROM 32a of the ROM module 32 related to the exchange via the fiber channel controller 22 and the SFP I2C of the fiber channel card 20.
  • the administrator replaces the ROM module 32 of the fiber channel card 20 mounted on the server 10 with the original optical module 31 (step S96).
  • the administrator then stores the ROM module 32.
  • step S97 the administrator operates the management terminal 60 to start the OS on the server 10 by SAN boot.
  • parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • the administrator first confirms the connected RAID device 100 to which the server 10 is connected (step S91 in FIG. 18). Thereafter, the administrator mounts the Fiber Channel card 20 on the server 10 (step S92). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S93). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, related to the RAID device 100 of the connection destination in the Fiber Channel card 20 (step S94).
  • the administrator replaces the optical module 31 of the fiber channel card 20 mounted on the server 10 with the ROM module 32.
  • the system firmware checks the status of the detection signal. When it is confirmed that the detection signal has changed from the unconnected state (open level) to the connected state (ground level), the system firmware reads the data in the built-in ROM 32a of the ROM module 32 into the server 10 using an I2C read command. At the same time, it is confirmed that the built-in ROM 32a of the ROM module 32 is not empty. Next, the system firmware reads the parameter data in the ROM 21 into the server 10 using the ROM read command of the fiber channel controller 22 of the fiber channel card 20. Then, it is compared with the data read from the built-in ROM 32a of the ROM module 32. If it is confirmed that the two contents are different, the following operation is performed.
  • the system firmware reads parameter data from the ROM 21 of the fiber channel card 20 into the server 10.
  • the ROM read command of the fiber channel controller 22 and the PCI or PCI-Express read command are used.
  • the read parameter data is written to the fiber channel controller 22 using a PCI or PCI-Express write command.
  • the system firmware performs the following operation using the I2C write command. That is, the written parameter data is written into the ROM module 32 related to the exchange via the fiber channel controller 22 and the SFP I2C of the fiber channel card 20.
  • the administrator replaces the ROM module 32 of the fiber channel card 20 with the original optical module.
  • the ROM module 32 is stored.
  • step S101 when the fiber channel card 20 mounted on the server 10 fails (step S101), the administrator replaces the fiber channel card 20 with a new fiber channel card 20 ′ (step S102). Thereafter, the administrator operates the management terminal 60 to activate the system firmware of the server 10 (step S103).
  • the administrator further replaces the optical module 31 of the new fiber channel card 20 ′ after the replacement with the ROM module 32 related to the storage (step S104).
  • the system firmware confirms the state of the detection signal. When it is confirmed that the detection signal is changed from the unconnected state (open level) to the connected state (ground level) by replacement with the ROM module, the following operation is performed.
  • the system firmware since the system firmware reads the parameter data of the built-in ROM 32a of the ROM module 32 using the I2C read command, it is confirmed that the parameter data is written in the ROM 32a. Further, the ROM read command of the fiber channel controller 22 is used to confirm that the ROM 21 on the fiber channel card 20 ′ is empty. Then, the parameter data is read from the built-in ROM 32a of the ROM module 32, and the parameter data is written to the ROM 21 of the new fiber channel card 20 ′. The write operation is performed by the system firmware using the ROM write command of the fiber channel controller 22. Thereafter, the manager replaces the ROM module 32 mounted on the new fiber channel card 20 ′ with the original optical module 31 (step S105). Thereafter, the administrator stores the ROM module 32 again.
  • step S106 the administrator operates the management terminal 60 and starts the OS on the server 10 by SAN boot.
  • parameter data as setting information necessary for the SAN boot is read from the ROM 21 of the fiber channel card 20 ′.
  • a SAN boot is executed by reading OS data from the connected RAID device 100 based on the read parameter data.
  • the fiber channel controller 22 of the fiber channel card 20 can be controlled by an instruction from the system firmware by an operation by the administrator.
  • the system firmware automatically controls the Fiber Channel controller 22 on the Fiber Channel card 20 using the change in state of the detection signal as a trigger.
  • the system firmware automatically instructs the boot code and driver to save and restore parameter data in the ROM 21.
  • the system firmware automatically confirms the state of stored data in each of the ROM 21 and the ROM module 32 and executes data writing to and reading from the ROM module 32.
  • the fourth embodiment has a configuration in which the boot code and the driver automatically check the stored data states of the ROM 21 and the ROM module 32 using the change in the state of the detection signal as a trigger.
  • the system firmware when the administrator replaces the ROM module 32, the system firmware performs the following operation. That is, the parameter data as setting information necessary for the SAN boot is automatically backed up and the parameter data is automatically recovered to the ROM 21 after the replacement of the fiber channel card 20. Therefore, it is not necessary to confirm configuration information or input parameter data when replacing the Fiber Channel card 20, and the work can be shortened. Further, by separately storing the parameter data of the Fiber Channel card 20 mounted on the server 10 in the ROM module 32, the setting information is accurately retained after the failure replacement of the Fiber Channel card 20, and work errors can be avoided. it can.
  • the path 25 for the detection signal flowing between the fiber channel controller 22 and the ROM module 32 which is used for confirming the insertion / extraction state of the optical module 31, is used.
  • the system firmware automatically controls the fiber channel controller on the fiber channel card 20. That is, the system firmware instructs the boot code and driver to save and restore parameter data in the ROM 21 on the fiber channel card.
  • a confirmation function using the voltage level of the detection signal is used to confirm the insertion / extraction state of the optical module 31 or the ROM module 32 with respect to the fiber channel card.
  • the fiber channel controller 22 has this confirmation function.
  • or 4 were each demonstrated as an individual Example, the one Example which has all the structure and all the effects of Example 1 thru
  • one embodiment that combines the configuration and operational effects of any one of the first to fourth embodiments is also possible. That is, in one embodiment, a plurality of external storage locations for storing parameter data stored in the ROM 21 of the fiber channel card can be selected. The plurality are the built-in ROM 32a of the ROM module 32 of the first embodiment, the SVP 50 of the server 10 of the second embodiment, and the built-in ROM 31a of the optical module 31 of the third embodiment.
  • the configuration of the fourth embodiment can be combined with the first embodiment, the third embodiment, or the first embodiment, which is a combination of the first and third embodiments.
  • the configuration of the fourth embodiment is a configuration in which the insertion / extraction state of the optical module 31 or the ROM module 32 is detected by using the detection signal path 25 to automatically start the saving or restoring operation of the parameter data.
  • Example 5 will be described with reference to FIGS.
  • a plurality of fiber channel cards 20-A, 20-B, and 20-C are connected to the RAID devices 100-A, 100-B, and 100-C.
  • each element that is, the server 10, the fiber channel cards 20-A, 20-B, and 20-C, the optical module, and the like are respectively the server 10 and the fiber in any of the first to fourth embodiments. It has the same configuration as the channel card 20, the optical module 31 and the like. Therefore, different parts will be mainly described.
  • operation of the Fiber Channel cards 20-A, 20-B, and 20-C is changed according to the time zone, and the OS is switched for each Fiber Channel card 20-A, 20-B, and 20-C.
  • parameter data as setting information necessary for the SAN boot having different contents can be set for each of the fiber channel cards 20-A, 20-B, and 20-C.
  • the parameter data of all the fiber channel cards mounted on the server 10 is written to each one of the fiber channel cards.
  • the saving and restoring of the parameter data of all the fiber channel cards by the operation of saving and restoring the parameter data for each one fiber channel card.
  • the fifth embodiment it is possible to easily save the parameter data of the fiber channel card that stores a plurality of parameter data as setting information necessary for the SAN boot, and to easily take over the information when the fiber channel card fails. You can get none.
  • FIG. 20 shows a case where a plurality of fiber channel cards 20-A, 20-B, and 20-C mounted on the server 10 have all failed.
  • all the fiber channel cards 20-A, 20-B and 20-C are exchanged.
  • parameter data as setting information necessary for SA boot having different contents is set for each of the fiber channel cards 20-A, 20-B, and 20-C as described above.
  • all the three types of parameter data for all the fiber channel cards 20-A, 20-B, and 20-C are written in the respective fiber channels.
  • the fiber channel card 20-A stores a total of three types of parameter data for all of the fiber channel cards 20-A, 20-B, and 20-C.
  • the fiber channel card 20-B also stores a total of three types of parameter data for all of the fiber channel cards 20-A, 20-B, and 20-C.
  • the fiber channel card 20-C also stores a total of three types of parameter data for all of the fiber channel cards 20-A, 20-B, and 20-C.
  • each parameter data initially stored individually for each fiber channel card is all written in one predetermined fiber channel card.
  • the Fiber Channel card 20-A initially stores only its own parameter data.
  • the fiber channel card 20-B also stores only its own parameter data.
  • the fiber channel card 20-C also stores only its own parameter data.
  • the fiber channel card 20-D stores only its own parameter data. Thereafter, all the four types of parameter data are written in one Fiber Channel card, for example, 20-A.
  • the system firmware boots the OS from the Fiber Channel card in which all types of parameter data are set. Then, the fiber channel card is activated using a driver, and all types of parameter data are read from the ROM 21 of the fiber channel card. Thereafter, all types of parameter data read are also written in the ROMs 21 of the other Fiber Channel cards.
  • the OS is started by SAN boot using the fiber channel card 20-A. Then, the activated OS reads the four types of parameter data from the ROM 21 of the fiber channel card 20-A, and writes them in the ROMs 21 of the other fiber channel cards 20-B, 20-C, and 20-D.
  • all the four types of parameter data are similarly stored in the ROM 21 of each of the fiber channel cards 20-A, 20-B, 20-C, and 20-D. That is, all of the four types of parameter data are copied to each fiber channel card, resulting in a state as shown in FIG. That is, the fiber channel card 20-A stores a total of four types of parameter data for all of the fiber channel cards 20-A, 20-B, 20-C, and 20-D. Similarly, the fiber channel card 20-B stores a total of four types of parameter data for all of the fiber channel cards 20-A, 20-B, 20-C, and 20-D.
  • the fiber channel card 20-C stores a total of four types of parameter data for all of the fiber channel cards 20-A, 20-B, 20-C, and 20-D.
  • the fiber channel card 20-D stores a total of four types of parameter data for all of the fiber channel cards 20-A, 20-B, 20-C, and 20-D.
  • the server 10 After the completion of this copying operation, the server 10 is put in an operating state. Thereafter, after the failure replacement of all the fiber channel cards as described above, the four types of parameter data are first restored to a predetermined one fiber channel card by the method according to any of the first to fourth embodiments. Then, the OS is started from the fiber channel card in which the parameter data is restored. Thereafter, the parameter data of the fiber channel card activated by the driver is read and written to another fiber channel card. In this way, the parameter data of each Fiber Channel card mounted on the server 10 is restored.
  • FIGS. 25 and 26 show a case where parameter data is stored and restored using the method according to the first embodiment.
  • the administrator checks the connected RAID device 100 to which the server 10 is connected (step S111 in FIG. 25). Thereafter, the administrator mounts each Fiber Channel card on the server (step S112). Thereafter, the administrator activates the system firmware using the management terminal 60 (step S113). After startup, the administrator uses the management terminal 60 to perform operation for setting parameter data, which is setting information necessary for SAN boot, for each Fiber Channel card related to the connected RAID device 100 (step S114).
  • the administrator uses each fiber channel card to the ROM 21 of a predetermined one fiber channel card (in the case of FIG. 23, 20-A) mounted on the server 10 using the system firmware from the management terminal 60. And the corresponding parameter data are written. The situation at that time is shown in FIG. Then, as shown in FIG. 23, the slot information of each Fiber Channel card stored in the ROM 21 and the corresponding parameter information are transferred to the outside by the method according to any one of the first to fourth embodiments. Saved.
  • the administrator replaces the optical module 31 of the one Fiber Channel card (20-A in the case of FIG. 23) mounted on the server 10 with the ROM module 32 (step S115). .
  • the slot information of each Fiber Channel card and the corresponding parameter data are stored in the built-in ROM 32a of the ROM module 32. Thereafter, the ROM module 32 is replaced with the original optical module, and the ROM module is stored (step S116).
  • the administrator uses the system firmware from the management terminal 60 to start the OS from the one Fiber Channel card (in the case of FIG. 23, 20-A).
  • the boot code of the Fiber Channel card reads slot information indicating the slot in the server 10 in which the Fiber Channel card is installed from the server 10.
  • the slot information is compared with the slot information stored in the ROM 21 of the Fiber Channel card to find slot information indicating the slot in which the Fiber Channel card is installed.
  • the OS is started by SAN boot using the parameter data corresponding to the slot information (step S117).
  • the administrator instructs the driver from the management terminal 60.
  • the instructed driver performs the following operation using the ROM read command of the fiber channel controller 22 in the fiber channel card (20-A in the example of FIG. 23). That is, as shown in FIG. 24, the slot information and the corresponding parameter data in the ROM 21 of the fiber channel card (20-A in the case of FIG. 23) are read into the server 10.
  • the instructed driver uses the ROM write command of the fiber channel controller 22 in each of the other fiber channel cards (in the case of FIG. 23, 20-B, C, D), and responds to the slot information. Parameter data to be written is written into the ROM 21 of each of the other fiber channel cards (step S118).
  • the server 10 After completion of writing the slot information to the other fiber channel cards and the corresponding parameter data, the server 10 starts operation.
  • step S121 when a fiber channel card mounted on the server 10 fails (step S121), the administrator replaces all fiber channel cards with new fiber channel cards (step S122). Thereafter, the administrator operates the management terminal 60 to activate the system firmware of the server 10 (step S123).
  • the slot information and the corresponding parameter data are restored to the ROM 21 of a certain fiber channel card among the new fiber channel cards after replacement mounted in the server 10.
  • the method according to any one of the first to fourth embodiments is used.
  • the slot information and the corresponding parameter data are read from the ROM module 32 in which the slot information and the corresponding parameter data are written and stored, and the above-described method is performed.
  • the data is written in the ROM 21 of a certain fiber channel card (step S124).
  • This read / write operation is performed with the optical module 31 of the Fiber Channel card replaced with the stored ROM module 32.
  • the ROM module 32 of the Fiber Channel card is replaced with the optical module 31 as it was (step S125).
  • the slot information and the corresponding parameter data are restored in the fibre-channel card.
  • the administrator uses the system firmware from the management terminal 60 and starts up the OS from the fiber channel card (step S126). That is, the administrator designates the Fiber Channel card, and the boot code of the Fiber Channel card reads slot information of the slot in which the Fiber Channel card is installed from the server 10. Then, the slot in which the Fiber Channel card is installed is confirmed by comparing with the restored slot information. Then, the OS is started using the parameter data corresponding to the corresponding slot information.
  • the administrator instructs the driver from the management terminal 60.
  • the instructed driver performs the following operation using the ROM read command of the fiber channel controller 22 in the fiber channel card. That is, as shown in FIG. 24, the slot information and the corresponding parameter data in the ROM 21 of the Fiber Channel card are read into the server 10.
  • the instructed driver uses the ROM write command of the fiber channel controller 22 in each other fiber channel card, and sends the slot information and the corresponding parameter data to the ROM 21 of each other fiber channel card. Writing is performed (step S127).
  • the server 10 After completion of writing slot information and corresponding parameter data to each of the other fiber channel cards, the server 10 enters operation.
  • all the parameter data of a plurality of Fiber Channel cards are stored on one Fiber Channel card.
  • the parameter data of a plurality of Fiber Channel cards can be saved and restored only by operating the parameter data of one Fiber Channel card. That is, according to the fifth embodiment, it is possible to save and restore parameter data as setting information necessary for SAN boot of each Fiber Channel card only by an operation on one Fiber Channel card. As a result, it is not necessary to confirm the configuration information or manually input parameter data when replacing the fiber channel card, and the work can be shortened.
  • the setting information is accurately maintained even after a faulty replacement of the fiber channel card, and a setting error can be avoided.
  • the server 10-A having the same configuration is provided for the existing server 10.
  • the administrator first confirms the RAID device 100-A or 100-B to which the server 10-A is connected (step S131 in FIG. 28). Thereafter, the administrator mounts the fiber channel cards 20-C and 20-D on the server 10-A (step S132). Thereafter, the administrator uses the management terminal 60 to activate the system firmware of the server 10-A (step S133). After startup, the slot information and the corresponding parameters are stored in the fiber channel card mounted on the server 10-A, for example, the 20-C ROM 21 by the method according to any one of the first to fourth embodiments. Write data and. This write operation is the same as the restore operation in the above embodiments.
  • the optical module 31 of the fiber channel card 20-C mounted on the server 10-A is replaced with a ROM module 32 for storage (step S134).
  • the slot information stored in the ROM 21 of the fiber channel card 20-A or 20-B mounted in the server 10 and the corresponding parameter data are stored in the built-in ROM 32a of the ROM module 32 related to the storage for backup purposes.
  • the storage is performed by the method described above with reference to FIG.
  • the slot information and the corresponding parameter data are read from the built-in ROM 32a of the ROM module 32 and written to the ROM 21 of the fiber channel card 20-C mounted on the server 10-A.
  • the ROM module 32 of the fiber channel card 20-C is replaced with the optical module as before (step S135).
  • the administrator uses the system firmware of the server 10-A from the management terminal 60 and starts up the OS from the fiber channel card 20-C (step S136). That is, the administrator designates the Fiber Channel card 20-C, and the boot code of the Fiber Channel card 20-C reads the slot information of the slot in which the Fiber Channel card is installed from the server 10-A. Then, the slot information written in the ROM 21 of the fiber channel card 20-C as described above is compared with the slot information in the corresponding parameter information. Through the comparison operation, the slot in which the Fiber Channel card is installed is confirmed. Then, the OS is started using the parameter data corresponding to the corresponding slot information.
  • the administrator instructs the driver of the server 10-A from the management terminal 60.
  • the instructed driver performs the following operation using the ROM read command of the fiber channel controller 22 in the fiber channel card 20-C. That is, the slot information and the corresponding parameter data in the ROM 21 of the fiber channel card 20-C are read into the server 10-A.
  • the instructed driver uses the ROM write command of the fiber channel controller 22 in the other fiber channel card 20-D, and uses the read slot information and the corresponding parameter data as the other fiber channel card. Writing to the ROM 21 of the card 20-D (step S137).
  • the server 10-A After completion of the writing of the slot information to the other Fiber Channel card 20-D and the corresponding parameter data, the server 10-A enters operation.
  • the parameters of all the Fiber Channel cards installed in the server are stored in one Fiber Channel card.
  • the parameter data of all the Fiber Channel cards mounted on the server can be automatically saved and restored only by operating on one Fiber Channel card.

Abstract

　機能拡張装置が情報処理装置と外部記憶装置に接続するための設定情報を機能拡張装置が有する場合に機能拡張装置が交換された後に交換後の機能拡張装置に設定情報を容易に復元することを目的とする。機能拡張装置の第１の記憶部に格納されている設定情報を接続モジュールと交換可能な第２の記憶部にも格納しておき、機能拡張装置の交換後は交換後の機能拡張装置の接続モジュールを第２の記憶部に交換して設定情報を得るようにした。

Description

機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム
　本発明は機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラムに関する。
　近年サーバのディスクレス化やディザスタリカバリ化によりサーバにおいてファイバチャネルカードを利用してＳＡＮ環境にあるＲＡＩＤ装置からＯＳを起動するシステムの構築に対する要求が拡大している。ここで本明細書を通じ、ＳＡＮはＳｔｏｒａｇｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋを示し、ＲＡＩＤはＲｅｄｕｎｄａｎｔ　Ａｒｒａｙｓ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ　Ｄｉｓｋｓを示し、ＯＳはＯｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍを示す。
　上記ＳＡＮ環境におけるＳＡＮブートについて説明する。ＳＡＮブートはサーバの内蔵ディスクではなく、ファイバチャネル経由で接続されたＲＡＩＤ装置からサーバ上でＯＳを起動（すなわちブート、以下同様）する機能である。ＳＡＮブートの機能を有するシステム環境におけるファイバチャネルカードは、接続されたＲＡＩＤ装置からのＯＳブートを可能にするためのブートコードを搭載している。この場合、サーバにおいてＲＡＩＤ装置からのＯＳブートを可能にするためには、操作者がファームウェア上から、ブートコードを使って接続するＲＡＩＤ装置に関する情報を予めファイバチャネルカードにブートコードとともに設定しておく。ここで上記ＲＡＩＤ装置に関する情報とは、例えばＲＡＩＤ装置のＷＷＮ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｎａｍｅ）、そのディスクのＴａｒｇｅｔ　ＩＤ情報、トポロジー情報、Ｌｉｎｋ　Ｓｐｅｅｄ情報等である。
　ここで明細書を通じ、ブートコードとはサーバの外部に接続しているＲＡＩＤ装置等のストレージ装置からＯＳデータを読み込み、これを起動させるためのプログラムを意味する。またドライバとはサーバのＯＳ上で動作するファイバチャネルカード制御用のプログラムを意味する。またファイバチャネルとはコンピュータと周辺機器を結ぶためのデータ転送方式の一つであり、主にシリアルＳＣＳＩ(Ｓｍａｌｌ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ)プロトコルを転送することに用いられる。またＬｉｎｋ　Ｓｐｅｅｄとはファイバチャネルの転送スピードを意味する。ＰＣＩ－Ｅｘｐｒｅｓｓとは周辺装置接続に用いるインターフェースカードを接続するためのサーバのバスを意味する。ＲＡＩＤとは複数台のディスクを制御管理し、ストレージリソースを提供する装置を意味する。ＳＮとはＲＡＩＤ やテープライブラリといったストレージ装置を接続するためのネットワークを意味する。Ｔｏｐｏｌｏｇｙはファイバチャネルの接続形態 (ＡＬ＿ＰＡループ接続、Ｎ＿Ｐｏｒｔスイッチ接続等)を意味する。ＷＷＮはファイバチャネル通信で用いるユニークな８バイトのアドレスコードを意味し、ファイバチャネルに接続する装置に付与される。システム監視機構とはサーバの状態監視や制御を行うシステムを意味する。内蔵ディスクとはサーバ装置内にあるＯＳデータを格納するための基本ディスクを意味する。Ｔａｒｇｅｔ　ＩＤとはディスクを識別するための論理ＩＤを言う。
特開２００７－６６２１６号公報 特開２００７－１６４３０５号公報 http://primeserver.fujitsu.com/sparcenterprise/technology/virtual/sanboot/ http://storage-system.fujitsu.com/jp/event/smw2006/exhibition4/ http://primeserver.fujitsu.com/unix/download/driver/pfca-4/pdf/sesanboot-ja.pdf
　外部記憶装置と情報処理装置とを接続することにより情報処理装置の機能を拡張する機能拡張装置が、当該情報処理装置と外部記憶装置との間を第１のインタフェースを介して接続する場合の設定情報を格納した第１の記憶装置を有する。この機能拡張装置が交換された際、交換後の機能拡張装置による当該情報処理装置と外部記憶装置との間の第１のインタフェースを介した接続を可能にするための構成を提供することが課題である。
　機能拡張装置は情報処理装置と外部記憶装置との間を第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と有する。また機能拡張装置は第１の設定情報に基づいて動作し、情報処理装置と外部記憶装置との間を第１のインタフェースを介して接続する接続モジュール部を有する。また第２の記憶部は第１のインタフェースに接続モジュール部を接続する場合の第２の設定情報を格納するとともに、機能拡張装置に対し、前記接続モジュールと交換可能である。また機能拡張装置は第１の記憶部と接続モジュール部または第２の記憶部とに接続され、前記第２の記憶部が格納する前記第２の設定情報を、前記第１の記憶部に設定する制御部を有する。
　機能拡張装置が交換された際、交換後の機能拡張装置の接続モジュールを第２の記憶部に交換する。そして当該交換後の機能拡張装置の制御部が前記第２の記憶部から前記第２の設定情報を得て当該機能拡張装置が有する第１の記憶部に設定する。第１の記憶部に設定された第２の設定情報を用いることで当該機能生拡張装置は情報処理装置と外部記憶装置との間を第１のインタフェースを介して接続することができる。
　情報処理装置と外部記憶装置との間を接続する場合の設定情報を格納した機能拡張装置が交換された際にも、交換後の機能拡張装置による当該情報処理装置と外部記憶装置との間の第１のインタフェースを介した接続が容易となる。
実施例のシステム全体の構成を説明するためのブロック図である。 図１に示されるサーバの内部構成を説明するためのブロック図である。 図２に示されるサーバにおける制御プログラムの構成を説明するための図（その１）である。 図２に示されるサーバにおける制御プログラムの構成を説明するための図（その２）である。 実施例１によるファイバチャネルカードの構成を説明するためのブロック図である。 実施例１によるファイバチャネルカードの作用効果を説明するためのブロック図（その１）である。 実施例１によるファイバチャネルカードの作用効果を説明するためのブロック図（その２）である。 実施例１によるファイバチャネルカードの作用効果を説明するためのフローチャート（その１）である。 実施例１によるファイバチャネルカードの作用効果を説明するためのフローチャート（その２）である。 実施例２によるファイバチャネルカードの構成を説明するためのブロック図である。 実施例２によるファイバチャネルカードの作用効果を説明するためのブロック図である。 実施例２によるファイバチャネルカードの作用効果を説明するためのフローチャート（その１）である。 実施例２によるファイバチャネルカードの作用効果を説明するためのフローチャート（その２）である。 実施例３によるファイバチャネルカードの構成を説明するためのブロック図である。 実施例３によるファイバチャネルカードの作用効果を説明するためのブロック図である。 実施例３によるファイバチャネルカードの作用効果を説明するためのフローチャート（その１）である。 実施例３によるファイバチャネルカードの作用効果を説明するためのフローチャート（その２）である。 実施例４によるファイバチャネルカードの構成を説明するためのブロック図である。 実施例４によるファイバチャネルカードの作用効果を説明するためのブロック図である。 実施例４によるファイバチャネルカードの作用効果を説明するためのフローチャート（その１）である。 実施例４によるファイバチャネルカードの作用効果を説明するためのフローチャート（その２）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その１）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その２）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その３）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その４）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その５）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのフローチャート（その１）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのフローチャート（その２）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのブロック図（その６）である。 実施例５によるファイバチャネルカードの構成および作用効果を説明するためのフローチャート（その３）である。
符号の説明
　１０　サーバ
　２０、２０'　ファイバチャネルカード
　２１　ＲＯＭ
　２２　フィイバチャネルコントローラ
　３１　光モジュール
　３１ａ　ＲＯＭ
　３２　ＲＯＭモジュール
　３２ａ　ＲＯＭ
　６０　管理用端末
　１００　ＲＡＩＤ装置
　２００　フィイバチャネルスイッチ
　実施例ではファイバチャネルカードに接続しているＲＡＩＤ装置からＳＡＮブートを行うシステムにおいて、同カードのＳＦＰ光モジュール(以下単に光モジュールと称する)と交換可能なＲＯＭモジュールを使用する。ここで本明細書を通じ、ＳＦＰはＳｍａｌｌ　Ｆｏｒｍ　Ｆａｃｔｏｒ Ｐｌｕｇｇａｂｌｅ（すなわち脱着式）を意味し、ＲＯＭはＲｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙを意味する。前記ファイバチャネルカード上のＲＯＭに格納された、ＳＡＮブートに必要なパラメータデータをＲＯＭモジュールに保存しておく。その結果、同ファイバチャネルカードの故障交換後、パラメータデータの復元を自動的に行い得るようにする。
　また他の実施例によれば、ファイバチャネルカードに接続しているＲＡＩＤ装置からＳＡＮブートするシステムにおいて、サーバのシステムファームウェアと周知のＩ２Ｃ（Ｉｎｔｅｒ－Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）バスとを使用する。ここではＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔ、以下同様）バスあるいはＰＣＩ－Ｅｘｐｒｅｓｓバスとともに設けられているＩ２Ｃバスを使用する。ファイバチャネルカード上のＲＯＭにあるＳＡＮブートに必要なパラメータデータを、このＩ２Ｃバスを利用してサーバ内に保存し、同ファイバチャネルカードの故障交換後のパラメータデータの復元を全自動化する。
　更に他の実施例によれば、ファイバチャネルカードに接続しているＲＡＩＤ装置からＳＡＮブートするシステムにおいて、同ファイバチャネルカードの光モジュールに内蔵されたＲＯＭを使用する。ファイバチャネルカード上のＲＯＭにあるＳＡＮブートに必要なパラメータデータを上記光モジュールに内蔵されたＲＯＭに保存し、同ファイバチャネルカードの故障交換後のパラメータデータ復元の自動化を実現する。
　更に他の実施例によれば、光モジュールの検出信号を使うことによって、ファイバチャネルカード上のＲＯＭにあるＳＡＮブートに必要なパラメータデータの保存とファイバチャネルカードの故障交換後のパラメータデータ復元の実行のための指示の生成を自動化する。
　更に他の実施例によれば、一枚のファイバチャネルカード上のＲＯＭに、システム内にある全てのファイバチャネルカードのパラメータデータを格納する。その結果一枚のファイバチャネルカードの復元操作だけで複数のファイバチャネルカードのパラメータデータ復元を自動的に実行し得るようにする。
　なお本明細書を通じ、ＲＯＭとは、例えばリード、ライト、消去が可能な周知のＦＬＡＳＨ－ＲＯＭ、ＥＥＰＲＯＭ等を意味する。
　以下に各実施例につき、図とともに詳細に説明する。
　図１は各実施例による情報処理システムの構成を説明するためのブロック図である。この情報処理システムはインタフェースとしてファイバチャネルを使用したSAN環境を有する。サーバ１０はファイバチャネルスイッチ２００を介してＲＡＩＤ装置１００に接続される。またサーバ１０はファイバチャネルスイッチ２００との接続を行うための構成を有するファイバチャネルカード２０を搭載する。
　この情報処理システムはＳＡＮブートの機能を有する。このためファイバチャネルカード２０はＲＡＩＤ装置１００からのＯＳブートを可能にするためのブートコードを搭載している。すなわち、サーバ１０からブートコードを使って接続するＲＡＩＤ装置１００に関する情報(以下「ＳＡＮブートに必要な設定情報」と称する)を予めファイバチャネルカード２０に、上記ブートコードとともに設定しておく。この設定は例えば操作者がサーバのファームウェアを使用して行うことが可能である。ここでＳＡＮブートに必要な設定情報は、例えばＲＡＩＤ装置のＷＷＮ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｎａｍｅ）、そのディスクのＴａｒｇｅｔ　ＩＤ情報、トポロジー情報、Ｌｉｎｋ　Ｓｐｅｅｄ情報等を含む。ここで上記ＷＷＮは外部記憶装置としてのＲＡＩＤ装置を特定する装置固有の情報であり、上記Ｔａｒｇｅｔ　ＩＤ情報はＲＡＩＤ装置が有するドライブ装置を個別に特定する識別情報である。またトポロジー情報はインタフェースとしてのファイバチャネルの接続形態を示す情報である。またＬｉｎｋ Ｓｐｅｅｄ情報は、インタフェースとしてのファイバチャネルの速度を示す速度情報である。
　図２はサーバ１０の内部構成を示すブロック図である。
　図２に示される如くサーバ１０はＣＰＵ１１、ＦＲＯＭ１２，システムコントローラ１３，メモリアクセスコントローラ１４，主記憶装置１５，モニタリングバスコントローラ１６，Ｉ／Ｏコントローラ１７、クロスバスイッチ１８を有する。なお本明細書を通じＦＲＯＭはフラッシュＲＯＭを示す。
　上記システムコントローラ１３はＣＰＵ１１と各種コントローラ１４，１６，１７，メモリ１２等との間の通信を制御する。ＦＲＯＭ１２にはシステムファームウェアとしてのＯＢＰ（Ｏｐｅｎ　Ｂｏｏｔ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭを意味し、以下システムファームウェアと称する）を搭載する。メモリアクセスコントローラ１４は主記憶装置１５へのアクセスを制御する。モニタリングバスコントローラ１６はシステム制御装置としてのサービスプロセッサ（以下単にＳＶＰと称する）５０を介したバス状態監視機能を提供する。Ｉ／Ｏコントローラ１７はＰＣＩバスとのインタフェースを提供する。
　図３A、図3Bはサーバ１０内の制御プログラムの起動の流れとその構成を示す。　サーバ１０においてＣＰＵ１１がFＲＯＭ１２からシステムファームウェアを読み込み主記憶装置１５に展開する。図３Aに示す如く、このシステムファームウェアがファイバチャネルカード２０内のＲＯＭであるＦＲＯＭ２１(以下単にＲＯＭ２１と称する)からブートコードを読み込み主記憶装置１５に展開する。次にこのブートコードに基づいてシステムファームウェアがファイバチャネルカード２０のコントローラ２２を制御する。その結果サーバ１０は上記ファイバチャネルスイッチ２００を介してＲＡＩＤ装置１００にアクセスし、ＲＡＩＤ装置１００からOSデータを読み込む。このＯＳデータは主記憶装置１５に展開される。その後ＣＰＵ１１はこのＯＳデータを使用してＯＳを起動する。以後サーバ１０は起動されたＯＳの制御下に入る。このようにしてＯＳが起動された後は、図３Ｂに示される如く、ＯＳ上で動作するドライバがファイバチャネルカード２０のコントローラ２２を制御する。その結果サーバ１０はファイバチャネルスイッチ２００を介しＲＡＩＤ装置１００にアクセスし得る。
　次に図４乃至図７とともに実施例１について説明する。
　図４は実施例１に係るファイバチャネルカード２０の構成を示すブロック図である。
　図４に示される如く、実施例１のファイバチャネルカード２０はコントローラ２２およびＲＯＭ２１を有する。なおファイバチャネルカード２０は周知技術のファイバチャネルカードと同様の構成を有することが可能であり、詳細な説明を省略する。ここでＳＡＮブートに必要な設定情報がＲＯＭ２１に記録されている。
　ファイバチャネルコントローラ２２はファイバチャネルスイッチ２００との間を接続するファイバチャネルケーブル８０を接続するための光モジュール３１を有する。光モジュール３１は上記の如く脱着式の光モジュールであり、ファイバチャネルカード２０から挿抜可能な構成を有する。この光モジュール３１との間にはファイバチャネル信号を伝送する信号パス２３とは別に、光モジュール３１に関する情報を確認するために使用するＩ２Ｃ(以下、ＳＦＰ用のＩ２Ｃと称する場合がある)のパス２４が設けられる。またサーバ１０のシステムファームウェアを使用して、ファイバチャネルコントローラ２２を介したＲＯＭ２０に対するリード・ライトのためのリード・ライトコマンドを使用することができる。これらのコマンドを使用することでＲＯＭ２１へのパラメータデータの設定、ＲＯＭ２１からのパラメータデータの読み出しが可能となる。
　実施例１ではＲＯＭ２１に格納された上記ブートコードに基づき、上記Ｉ２Ｃのパス２４を使用してＳＡＮブートに必要な設定情報のパラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａ(図５Ａ等参照)へ書き込む。この動作はサーバ１０のシステムファームウェアがＳＦＰ用のＩ２Ｃのライトコマンドを使用して行う。ここでＲＯＭモジュール３２とは上記内蔵ＲＯＭ３２ａを有し、光モジュール３１と交換可能な構造を有し、Ｉ２Ｃのインタフェースを有する。上記書き込み動作は光モジュール３１をＲＯＭモジュール３２に交換した状態で行う。ＲＯＭモジュール３２も光モジュール３１同様の脱着式のモジュールであり、ファイバチャネルカード２０から挿抜可能な構成とされる。すなわちファイバチャネルカード２０に対しＲＯＭモジュール３２と光モジュール３１とは相互に交換可能である。
　すなわち実施例１ではＲＯＭ２１に保存されているＳＡＮブートに必要な設定情報たる、接続先ＲＡＩＤ装置１００のＷＷＮ、ＲＡＩＤ装置１００のＴａｒｇｅｔ　ＩＤ、Ｌｉｎｋ　Ｓｐｅｅｄ等の各パラメータデータを取り出す。そして取り出したパラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存する。上記保存されたパラメータデータを読み出す際には、ファイバチャネルカード２０にＲＯＭモジュール３２を装着し、ブートコードに基づいてサーバ１０のシステムファームウェアがＩ２Ｃのリードコマンドを使用して行う。このようにしてＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、ＲＯＭ２１へ書き込むことができる。この読み出し・書き込み動作はシステムファームウェアからの指示によりファイバチャネルコントローラ２２が自動的に実行する。
　このように実施例１によればＳＡＮブートに必要な設定情報たるパラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存することができ、ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからＲＯＭ２１へ復元できる。その結果ファイバチャネルカード２０が故障し、新たなファイバチャネルカードに交換されたような場合、当該新たなファイバチャネルカードに上記ＲＯＭモジュール３２を装着する。その状態でサーバ１０のシステムファームウェアがＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、当該新たなファイバチャネルカードのＲＯＭ２１へ書き込む。この読み込み・書き込み動作はシステムファームウェアが当該新たなファイバチャネルカードのファイバチャネルコントローラ２２に指示することで実現される。その結果パラメータデータを復元することができる。このように実施例１によれば、ＳＡＮブートに必要な設定情報をファイバチャネルカード２０の外に保持し、これを使用して交換後のファイバチャネルカードにおいて復元することが可能となる。その結果ファイバチャネルカード２０の故障時の情報の引継ぎを容易に実現し得る。またこの情報の引き継ぎの動作はサーバ１０のシステムファームウェアがファイバチャネルコントローラ２２に指示することで自動的になされる。このため情報の引継ぎを人為的に行う場合に生じ得る情報の設定ミスを効果的に防止可能である。
　すなわち実施例１によれば、ＳＡＮブートに必要な設定情報たるパラメータデータを一般的なインタフェース（具体的には上記Ｉ２Ｃ）を経由して別の箇所（具体的にはＲＯＭモジュール３２の内蔵ＲＯＭ３２ａ）へ退避しておく。ファイバチャネルカード２０の交換後は当該別の箇所から、前記退避したパラメータデータを読み込むことにより環境を引き継がせる。
　すなわち実施例１によれば、ファイバチャネルによる通信用信号とは別に設けられた、光モジュール３１に関する情報の確認のために使われるＩ２Ｃインタフェース２４に、Ｉ２Ｃインタフェースに対応したＲＯＭモジュール３２を接続する。具体的には図５Ａに示す如く、ファイバチャネルカード２０に装着されている光モジュール３１を取り外し、ＲＯＭモジュール３２に交換する。その状態でＲＯＭ２１にあるパラメータデータを、当該接続したＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存する。すなわちＩ２Ｃのライトコマンドを使用することによりＲＯＭ２１から読み込んだパラメータデータを、上記交換に係るＲＯＭモジュール３２が内蔵するＲＯＭ３２ａへ書き込む。
　サーバ１０のファイバチャネルカード２０が新たなファイバチャネルカード２０'に交換された後は、当該新たなファイバチャネルカード２０'の光モジュール３１を一旦上記ＲＯＭモジュール３２に交換する(図５Ｂ)。その状態でＩ２Ｃリードコマンドを使うことにより当該ＲＯＭモジュール３２から上記の如く内蔵するＲＯＭ３２ａに書き込まれたパラメータデータを読み出す。読み出されたパラメータデータは上記新たなファイバチャネルカード２０'のＲＯＭ２１に書き込まれる。この動作により、前記交換後の新たなファイバチャネルカード２０'のＲＯＭ２１へ、前記交換前のファイバチャネルカード２０のＲＯＭ２１に格納されていたパラメータデータを引き継がせることができる。上記パラメータデータの新たなファイバチャネルカード２０'のＲＯＭ２１への書き込みの終了後、前記ＲＯＭモジュール３２を当該新たなファイバチャネルカード２０'から取り外す。そして当該ファイバチャンネルカード２０'に元々装着されていた光モジュール３１を同ファイバチャネルカード２０'に元通りに装着する。その結果当該新たなファイバチャネルカード２０'は、そのＲＯＭ２１に書き込まれたパラメータデータを使用することにより、前記交換前のファイバチャネルカード２０の場合同様、サーバ１０のＳＡＮブートを実行し得る。
　以下図６，７を上記図５Ａ，５Ｂとともに参照し、実施例１の作用効果を更に詳細に説明する。
　まずファイバチャネルカード２０のパラメータデータのバックアップ動作につき説明する。
　最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図６中、ステップＳ３１）。その後管理者は当該ファイバチャネルカード２０をサーバに搭載する（ステップＳ３２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ３３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカード２０に設定する操作を行う(ステップＳ３４)。
　次に管理者はサーバ１０のファイバチャネルカード２０に搭載された光モジュール３１をＲＯＭモジュール３２へ交換する(ステップＳ３５)。その後管理者が管理用端末６０からシステムファームウェアでファイバチャネルカード２０のＲＯＭ２１内のブートコードを指示する。指示されたブートコードに基づき、ファイバチャネルコントローラ２１のＲＯＭリードコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドを使い、ファイバチャネルカード２０のＲＯＭ２１からパラメータデータがサーバ１０へ読み込まれる。ＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドを使って、当該読み込まれたパラメータデータがファイバチャネルコントローラ２２へ書き込まれる。ファイバチャネルコントローラ２２にパラメータデータが書き込まれた後、上記指示に係るブートコードに基づき、Ｉ２Ｃのライトコマンドを使って、前記書き込まれたパラメータデータがファイバチャネルコントローラ２２とファイバチャネルカードのＩ２Ｃのパスを経由し、前記交換に係るＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込まれる(以上ステップＳ３６)。
　パラメータデータのＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込み後、管理者はサーバ１０に搭載されたファイバチャネルカード１０に装着されたＲＯＭモジュール３２を元の光モジュール３１へ交換する（ステップＳ３７）。その後ＲＯＭモジュール３２は保管される。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ３８）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　次に、ファイバチャネルカード交換後のパラメータデータのリカバリ動作内容について説明する。
　図７においてファイバチャネルカード２０の故障時(ステップＳ４１)、管理者はサーバ１０に搭載された同ファイバチャネルカード２０を新たなファイバチャネルカード２０'に交換する（ステップＳ４２）。その後管理者は管理用端末６０を操作し、サーバ１０のシステムファームウェアを起動する（ステップＳ４３）。
　管理者は更に、交換後の新たなファイバチャネルカード２０'の光モジュール３１を、上記保管に係るＲＯＭモジュール３２に交換する（ステップＳ４４）。
　その後管理者は管理用端末６０からシステムファームウェアでファイバチャネルカード２０'のＲＯＭ２１内のブートコードを指示する。指示されたブートコードはＩ２Ｃのリードコマンドを使って以下の動作を行う。すなわち前記交換されたＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからＳＦＰ用のＩ２Ｃを経由して前記交換後の新たなファイバチャネルカード２０'のファイバチャネルコントローラ２２へパラメータデータを読み込む。 次にＰＣＩ、あるいはＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドを使ってファイバチャネルコントローラ２２からサーバ１０へ当該パラメータデータが読み込まれる。そしてファイバチャネルコントローラ２２のＲＯＭライトコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドを使って、当該パラメータデータが、前記新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込まれる(以上ステップＳ４５)。
　その後新たなファイバチャネルカード２０'に装着されたＲＯＭモジュール３２を光モジュール３１へ交換して元通りにする(ステップＳ４６)。当該ＲＯＭモジュール３２は再び保管しておく。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ４７）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０'のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　このように実施例１では、光モジュール３１と交換可能でＩ２Ｃインタフェースに接続できるＲＯＭ３２ａを内蔵したＲＯＭモジュール３２を用いる。すなわちパラメータデータを格納できる素子としてのＲＯＭモジュール３２を接続する。
　またファイバチャネルコントローラ２２と光モジュール３１の間に接続用のＩ２Ｃインタフェースは本来光モジュール３１の状態や情報確認に用いる。このＩ２Ｃインタフェースを、交換後のＲＯＭモジュール３２に対するパラメータデータの読み書きに使用する。
　又ＲＯＭ２１のパラメータデータを読み書きできる機能はブートコードが有する。このブートコードによる、Ｉ２Ｃのリード・ライトコマンドを使用してＲＯＭモジュール３２の内蔵ＲＯＭ３２ａに対するパラメータデータの読み書きの自動実行が可能となる。なお、パラメータデータの読み書き指示は、ブートコードの制御コマンドを使用してサーバ１０から手動で行う。
　実施例１によれば、ＲＯＭモジュール３２の交換とシステムファームウェア上での制御コマンド操作により、以下の動作を実施する。すなわちＳＡＮブートに必要は設定情報としてのパラメータデータのバックアップおよびファイバチャネルカード交換後にＲＯＭ２１への同パラメータデータのリカバリを行う。その結果ファイバチャネルカードの交換時に管理者自身が構成情報の確認を行ったりパラメータデータを入力する必要がなくなり、作業が短縮できる。実施例１ではサーバ１０に搭載されているファイバチャネルカード２０のパラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａに保持しておくことにより、ファイバチャネルカードの故障交換後においても設定情報が正確に保持され、作業ミスの回避ができる。
　すなわち実施例１では、本来光モジュール３１の情報確認に用いていたファイバチャネルコントローラ２０と光モジュール３１との間のＩ２Ｃインタフェースを利用する。光モジュール３１と交換可能なＩ２Ｃ接続できるＲＯＭモジュール３２と接続することにより、ＲＯＭモジュール３２を、ＳＡＮブートに必要な設定情報としてのパラメータデータの保存に用いる。なお、ファイバチャネルコントローラ２２と光モジュール３１との間のデータの読み書きは、システムファームウェア上で実行されるブートコードにより自動的に実行される。この場合Ｉ２Ｃのリード・ライトコマンドが使用される。
　次に図８乃至１１とともに実施例２について説明する。
　実施例２の構成は上記実施例１の構成と同様であり、主に異なる部分について説明する。
　上記の如く、ファイバチャネルカード２０のＲＯＭ２１に、ＳＡＮブートに必要な設定情報を記録しておく。サーバ１０にはＰＣＩ、ＰＣＩ－Ｅｘｐｒｅｓｓのデータ信号のパス４１とは別に、ファイバチャネルカード２０上のファイバチャネルコントローラ２２の情報を確認するために使用するＩ２Ｃのパス４２がある。またサーバ１０のＳＶＰ５０から、ファイバチャネルコントローラ２２のＲＯＭリード・ライトコマンドを使用してＲＯＭ２１へパラメータデータを設定したり、読み出したりすることができる。
　実施例２ではＲＯＭ２１にあるパラメータデータを、サーバ１０のＳＶＰ５０がＰＣＩ、ＰＣＩ－Ｅｘｐｒｅｓｓバスに係るＩ２Ｃのリードコマンドを使用してＩ２Ｃパス経由でサーバのＳＶＰ５０に読み込む。このようにしてＲＯＭ２１に保存されているＳＡＮブートに必要な設定情報たる接続先ＲＡＩＤ装置のＷＷＮ、ＲＡＩＤ装置のＴａｒｇｅｔ　ＩＤ情報、Ｌｉｎｋ　Ｓｐｅｅｄ等の各パラメータデータを取り出し、サーバ１０内へ保存する。又必要な場合、ＳＶＰ５０上で実行するＩ２Ｃのライトコマンドを使用してサーバ１０からＩ２Ｃパスを経由してパラメータデータをファイバチャネルカード２０のＲＯＭ２１へ書き込む。
　すなわち実施例２では、ＳＡＮブートに必要な設定情報たるパラメータデータをサーバ１０へ保存しておき、同保存に係るパラメータデータを使用し、サーバ１０からファイバチャネルカード２０のＲＯＭ２１へ同データを復元する。このため、ファイバチャネルカード２０故障交換後はＳＶＰ５０上でサーバ１０からパラメータデータをＲＯＭ２１へ書き込む操作をＳＶＰ５０上から指示する。その結果パラメータデータを復元できる。このように実施例２ではＳＡＮブートに必要な設定情報を保持し復元する。その結果ファイバチャネルカード２０故障時の情報引継ぎを容易に実施し得る。また、情報引継ぎ時の設定ミスを確実に防ぎ得る。
　すなわち実施例２では、ＰＣＩ、ＰＣＩ－Ｅｘｐｒｅｓｓ信号のインタフェースとは別にある、ファイバチャネルカード２０の情報確認等で使われるＩ２Ｃインタフェースを使う。そしてこのＩ２Ｃインタフェースを使用し、ファイバチャネルカード２０上のＲＯＭ２１にあるパラメータデータを読み込み、これをサーバ１０へ保存する。すなわちＩ２Ｃのリードコマンドとファイバチャネルコントローラ２２のＲＯＭリードコマンドを使ってＲＯＭ２１からパラメータデータをサーバ１０へ読み込む。ファイバチャネルカード２０交換後はＩ２Ｃのライトコマンドを使うことによりサーバ１０から当該交換後の新たなファイバチャネルカード２０'のファイバチャネルコントローラ２２へとパラメータデータを書き込む。そしてファイバチャネルコントローラのＲＯＭライトコマンドを使うことにより、当該新たなファイバチャネルカード２０'のＲＯＭ２１へパラメータデータを書き込む。この動作を行うことで、交換した新たなファイバチャネルカード２０'上へ、交換前のファイバチャネルカード２０のパラメータデータを引き継がせる。
　図８乃至１１とともに、実施例２に係る動作につき、詳細に説明する。
　まずファイバチャネルカード２０のパラメータデータのバックアップ動作を説明する。
　最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図１０中、ステップＳ５１）。その後管理者は当該ファイバチャネルカード２０をサーバ１０に搭載する（ステップＳ５２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ５３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカード２０に設定する操作を行う(ステップＳ５４)。
　次に管理者が管理用端末６０からサーバ１０のＳＶＰ５０でファイバチャネルカード２０上のファイバチャネルコントローラ２０のＲＯＭリードコマンドとＩ２Ｃのリードコマンドを指示する。指示されたコマンドにしたがって、サーバ１０とファイバチャネルカード２０との間のＩ２Ｃを経由し、ファイバチャネルカード２０上のＲＯＭ２１からパラメータデータがサーバ１０へ読み込まれ、サーバ２０にある、システムファームウェア管理下又はＳＶＰ５０管理下のＲＯＭへ保存される(以上ステップＳ５５)。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ５６）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　次にファイバチャネルカード２０交換後のパラメータデータのリカバリ動作を説明する。
　図１１においてファイバチャネルカード２０の故障時(ステップＳ６１)、管理者はサーバ１０に装着された同ファイバチャネルカード２０を新たなファイバチャネルカード２０'に交換する（ステップＳ６２）。その後管理者は管理用端末６０を操作し、サーバ１０のシステムファームウェアを起動する（ステップＳ６３）。
　その後管理者が管理用端末６０からＳＶＰ５０でＩ２Ｃのライトコマンドとファイバチャネルコントローラ２２のＲＯＭライトコマンドを指示する。指示されたコマンドにしたがって、ＳＶＰ５０は、上記保存に係るパラメータデータを読み込み、これをＩ２Ｃ経由で新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込む（ステップＳ６４）。上記保存に係るパラメータデータとは、図１０とともに上記した動作により、システムファームウェア管理下又はＳＶＰ５０管理下のＲＯＭに保存されたパラメータデータである。その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ６５）。
　サーバ１０と新たなファイバチャネルカード２０'のファイバチャネルコントローラ２２との間にあるＩ２Ｃパス４２は本来ファイバチャネルコントローラ２２の状態監視に用いる。しかしながらこの場合、このＩ２Ｃパス４２を使用して、ファイバチャネルカードのＲＯＭ２１のパラメータデータの読み書きを行う。そのためにはサーバ１０がＩ２Ｃを経由してファイバチャネルカードのＲＯＭ２１に対しパラメータデータを読み書きできるようにする必要がある。そのため、サーバ１０のＳＶＰ５０が、ＲＯＭ２１に対するパラメータデータの読み書きをＩ２Ｃのリード・ライトコマンドを使って自動的に行うようにする。このようにしてパラメータデータの保存と復元を実現する。なお、パラメータデータの読み書きを実行する旨の指示が自動的に出されるようにすることが可能である。すなわちＳＶＰ５０による、ファイバチャネルカード２０が交換されたことの検出、および設定情報の検出を行う機能を用いる。これらの機能により、ファイバチャネルカード２０が交換されたことの検出、および設定情報の検出がなされた際に、自動的にパラメータデータの読み書きを実行する旨の指示が出されるようにすることが可能である。
　実施例２によれば、ＳＡＮブートに必要な設定情報を格納したファイバチャネルカード２０が故障した場合、サーバ１０のＳＶＰ５０上で制御コマンドを操作することで以下の動作を実行させることが可能である。すなわちＳＡＮブートに必要な設定情報たるパラメータデータのバックアップを行い、ファイバチャネルカード２０の交換後に新たなファイバチャネルカード２０'のＲＯＭ２１へのリカバリを行う。その結果、ファイバチャネルカード２０交換時に構成情報の確認や、パラメータデータを入力する必要がなくなり、作業が短縮できる。またサーバ１０に搭載されているファイバチャネルカード２０のパラメータデータを、サーバ１０(実際には上記の如く、システムファームウェア管理下又はＳＶＰ５０管理下のＲＯＭ)で保持する。その結果、ファイバチャネルカード２０の故障交換後においても設定情報が正確に保持され、作業ミスの回避ができる
　実施例２では、ファイバチャネルカード２０のファイバチャネルコントローラ２２が情報確認に用いているＰＣＩ、ＰＣＩ－ＥｘｐｒｅｓｓバスにあるＩ２Ｃインタフェースを、パラメータデータの読み書きに使う。このようにしてＳＡＮブートに必要な設定情報たるパラメータデータのサーバ１０への保存と、同パラメータデータの新たなファイバチャネルカード２０'上への復元を行う。サーバ１０とファイバチャネルコントローラとの間のデータの読み書きは、サーバ１０のＳＶＰ５０がＩ２Ｃのリード・ライトコマンドを使用して行う。なお、ＳＶＰ５０はファイバチャネルカード２０の交換とパラメータデータの存在とを自動的に検出する機能を有している。
　したがってＳＶＰ５０は、サーバ１０に搭載されたファイバチャネルカード２０が新たなファイバチャネルカード２０'に交換されたことを検出し、またシステムファームウェア管理下又はＳＶＰ５０管理下のＲＯＭにパラメータデータが保存されていることを検出する。これらの検出がトリガとされ、ＳＶＰ５０は、前記パラメータデータをシステムファームウェアの管理下又はＳＶＰ５０管理下のＲＯＭから読み出し、これを前記交換に係るファイバチャネルカード２０'のＲＯＭ２１に書き込む。すなわち実施例２では、ＳＡＮブートに必要な設定情報たるパラメータデータの復元の動作を全自動化する。
　また実施例２では更に、パラメータデータの保存の自動化も行っている。すなわちサーバ１０に搭載された第１のファイバチャネルカードが第２のファイバチャネルカードに交換された場合であって、第２のファイバチャネルカードのＲＯＭ２１には既にパラメータが設定されていた場合である。この場合、ＳＶＰ５０は当該ファイバチャネルカードの交換を検出するとともに、第２のフィアバチャネルカード上のＲＯＭ２１にパラメータデータが格納されていることを検出する。これらの検出がトリガとされ、ＳＶＰ５０は、第２のファイバチャネルカード上のＲＯＭ２１からパラメータデータを読み出す。ＳＶＰ５０は上記読み出したパラメータデータをシステムファームウェアの管理下又はＳＶＰ５０管理下のＲＯＭに書き込む。すなわち実施例２では、ＳＡＮブートに必要な設定情報たるパラメータデータの保存の動作を全自動化する。
　以下に図１２乃至１５とともに実施例３につき説明を行う。
　実施例３の構成は上記実施例１の構成と同様であり、主に異なる部分について説明する。
　上記の如く、ファイバチャネルカード２０のROM２１に、ＳＡＮブートに必要な設定情報を記録しておく。ファイバチャネルカード２０のファイバチャネルコントローラ２２と光モジュール３１との間にはファイバチャネル信号を伝送する信号パスとは別に、光モジュール３１の情報を確認するために使用するＩ２Ｃのパスがある。光モジュール３１の中にあるＲＯＭ３１ａには、光モジュール３１の型格情報(すなわちメーカ名およびメーカ型番)と状態情報とが格納されている。またサーバ１０のシステムファームウェアから、ファイバチャネルコントローラ２２のＲＯＭリード・ライトコマンドを使用してＲＯＭ２１へパラメータデータを設定したり、読み出したりすることができる。
　実施例３ではファイバチャネルカード２０のＲＯＭ２１にある、システムファームウェアで実行するブートコードにより、ＳＦＰ用のＩ２Ｃのライトコマンドを使用してパラメータデータを光モジュール３１内のＲＯＭ３１ａへ書き込む。すなわちＲＯＭ２１に保存されているＳＡＮブートに必要な設定情報たる各パラメータデータを取り出す。そして取り出されたパラメータデータは光モジュール３１内のＲＯＭ３１ａへ保存される。なお上記パラメータデータは例えば接続先ＲＡＩＤ装置のＷＷＮ、ＲＡＩＤ装置のＴａｒｇｅｔ　ＩＤ情報、Ｌｉｎｋ　Ｓｐｅｅｄ等を有する。
　あるいはシステムファームウェア上で実行するブートコードにより、ＳＦＰ用のＩ２Ｃのリードコマンドを使用して光モジュール３１内のＲＯＭ３１ａからパラメータデータが読み込まれる。読み込まれたパラメータデータはファイバチャネルカード２０上のＲＯＭ２１に書き込まれる。
　実施例３によれば、パラメータデータを光モジュール３１の内蔵ＲＯＭ３１ａへ保存する。当該パラメータデータを、内蔵ＲＯＭ３１ａからファイバチャネルカード２０のＲＯＭ２１へ復元する。このため、ファイバチャネルカード２０の故障交換後は、サーバ１０のシステムファームウェアを使用して、光モジュール３１のＲＯＭ３１ａからパラメータデータを読み込む。そして読み込まれたパラメータデータを交換後の新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込む。この読み込み・書き込み動作は、管理者がサーバ１０のシステムファームウェアを使用して指示することにより実行させることができる。その結果ファイバチャネルカード２０の交換時にも容易にパラメータデータを復元できる。したがって実施例３によれば、ＳＡＮブートに必要な設定情報を格納したファイバチャネルカード２０の設定情報が保持及び復元され、ファイバチャネルカード２０の故障時の情報引継ぎを容易になし得る。また、情報引継ぎ時の設定ミスを効果的に防ぎ得る。
　すなわち実施例３では、ファイバチャネル通信用のインタフェースとは別にある光モジュールの情報確認で使われるＩ２Ｃインタフェースと接続している光モジュール３１内のＲＯＭ３１ａを使用する。当該ＲＯＭ３１ａにファイバチャネルカード２０のＲＯＭ２１にあるパラメータデータを保存する。すなわちＩ２Ｃのライトコマンドを使用することにより、ＲＯＭ２１から読み込んだパラメータデータを光モジュール３１内のＲＯＭ３１ａへ書き込む。ファイバチャネルカード２０の交換後は以下の動作を行う。Ｉ２Ｃのリードコマンドを使い、交換前のファイバチャネルカード２０に装着されていた光モジュール３１のＲＯＭ３１ａから、当該交換前のファイバチャネルカードのパラメータデータを読み込む。読み込まれたパラメータデータは交換後の新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込まれる。この動作により、交換後の新たなファイバチャネルカード２０'へ、交換前のファイバチャネルカード２０のパラメータデータを引き継がせる。
　以下実施例３の動作につき、図１２乃至１５とともに、詳細に説明する。
　まずファイバチャネルカード２０のパラメータデータのバックアップ動作につき説明する。
　最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図１４中、ステップＳ７１）。その後管理者は当該ファイバチャネルカード２０をサーバ１０に搭載する（ステップＳ７２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ７３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカード２０に設定する操作を行う(ステップＳ７４)。
　次に管理者が管理用端末６０からサーバ１０のシステムファームウェアを使用してファイバチャネルカード２０のＲＯＭ２１に格納されたブートコードを指示する。指示されたブートコードによりファイバチャネルカード２０のＲＯＭ２１からパラメータデータがサーバ１０へ読み込まれる。この場合ファイバチャネルコントローラ２２のＲＯＭリードコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドが使われる。ＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドを使って、上記読み込まれたパラメータデータがファイバチャネルコントローラ２２へ書き込まれる。ファイバチャネルコントローラ２２にパラメータデータが書き込まれると、前記ブートコードにより、Ｉ２Ｃのライトコマンドを使って、前記読み込まれたパラメータデータがファイバチャネルカード２０に装着されている光モジュール３１内のＲＯＭ３１ａへ書き込まれる。この書き込み動作はファイバチャネルコントローラ２２とファイバチャネルカード２０のＳＦＰ用のＩ２Ｃを経由してなされる(以上ステップＳ７５)。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ７６）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　次にファイバチャネルカードへのパラメータデータの復元動作を説明する。
　図１５においてファイバチャネルカード２０の故障時(ステップＳ８１)、管理者はサーバ１０に装着されている同ファイバチャネルカード２０を新たなファイバチャネルカード２０'に交換する（ステップＳ８２）。ここで管理者は同ファイバチャネルカード２０の交換の際、当該元のファイバチャネルカード２０から光モジュール３１を取り外し、これを新たなファイバチャネルカード２０'に装着する。その後管理者は管理用端末６０を操作し、サーバ１０のシステムファームウェアを起動する（ステップＳ８３）。
　次に管理者が管理用端末６０からシステムファームウェアを使用してファイバチャネルカード２０'のＲＯＭ２１に格納されたブートコードを指示する。指示されたブートコードにより、Ｉ２Ｃリードコマンドを使って、光モジュール３１のＲＯＭ３１ａから、ＳＦＰ用のＩ２Ｃを経由してファイバチャネルコントローラ２２へパラメータデータが読み込まれる。この場合の光モジュール３１は、上記元のファイバチャネルカード２０から取り外され、当該新たなファイバチャネルカード２０'に装着された光モジュール３１である。次にＰＣＩ, ＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドを使って、ファイバチャネルコントローラ２２からサーバ１０へ上記パラメータデータが読み込まれる。読み込まれたパラメータデータは、当該交換後の新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込まれる。この書き込み動作には、ファイバチャネルコントローラ２２のＲＯＭライトコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドが使われる(以上ステップＳ８４)。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ８５）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０'のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　実施例３によれば、パラメータデータを格納できる素子として、光モジュール３１内のＲＯＭ３１ａを用いる。
　またファイバチャネルコントローラ２２と光モジュール３１との間に接続されているＩ２Ｃインタフェースは本来光モジュールの状態や情報確認に用いられる。実施例３ではこのＩ２Ｃインタフェースをパラメータデータの読み書きに使用する。
　ここでＲＯＭ２１のパラメータデータを読み書きできる機能はブートコードが有する。更にコントローラ２２とＳＦＰ用のＩ２Ｃを経由して光モジュール３１のＲＯＭ３１ａにパラメータデータを読み書きする機能をブートコードに設ける。その結果ブートコードによる、Ｉ２Ｃのリード・ライトコマンドを使用した、光モジュール３１のＲＯＭ３１ａにあるパラメータデータの読み書きの自動化が実現される。なお、パラメータデータの読み書きを実行する旨の指示は、ブートコードの制御コマンドを使用してサーバから手動でなされる。
　実施例３によれば、システムファームウェアを使用した制御コマンドの操作により、ＳＡＮブートに必要な設定情報たるパラメータデータのバックアップを自動で行う。またファイバチャネルカード２０交換後に、新たなファイバチャネルカード２０'のＲＯＭ２１への上記パラメータデータのリカバリを自動で行う。その結果ファイバチャネルカード２０交換時に構成情報の確認や、パラメータデータを入力する必要がなくなり、作業短縮ができる。
　実施例３ではサーバ１０に搭載されているファイバチャネルカード２０のパラメータデータを光モジュール３１のＲＯＭ３１ａに保持しておく。その結果、ファイバチャネルカード２０の故障交換後においても、設定情報が新たなファイバチャネルカード２０'に正確に引き継がれ、作業ミスの回避ができる。
　実施例３では、本来光モジュールの情報確認に用いていたファイバチャネルコントローラ２２と光モジュール３１との間にあるＩ２Ｃインタフェースを、パラメータデータの転送に使用する。すなわちこのＩ２Ｃインタフェースを、光モジュール３１のＲＯＭ３１ａを使った、ＳＡＮブートに必要な設定情報たるパラメータデータの保存、復元に用いる。なお、ファイバチャネルコントローラ２２と光モジュール３１との間のデータの読み書きは、サーバ１０のシステムファームウェアによって実行されるブートコードが、Ｉ２Ｃのリード・ライトコマンドを使って実行する。
　次に図１６乃至１９とともに実施例４につき説明を行う。
　実施例４の構成は上記実施例１の構成と同様であり、主に異なる部分について説明する。
　上記の如くファイバチャネルカード２０のＲＯＭ２１にＳＡＮブートに必要な設定情報を記録しておく。ファイバチャネルコントローラ２２と光モジュール３１との間にはファイバチャネル信号を伝送する信号パス２３とは別に、光モジュール３１の情報を確認するために使用するＩ２Ｃのパス２４がある。サーバ１０のシステムファームウェアから、ファイバチャネルカード２０のファイバチャネルコントローラ２２のＲＯＭリード・ライトコマンドを使用して以下の動作を行い得る。すなわちファイバチャネルカード２０上のＲＯＭ２１へパラメータデータを設定したり、ＲＯＭ２１からパラメータデータを読み出したりする。また、実施例４では、ファイバチャネルコントローラ２２と光モジュール３１との間に検知信号のパス２５が設けられる。この検知信号の電圧レベルを確認することによって、システムファームウェアは光モジュール３１のファイバチャネルカード２０に対する抜き差し状態を確認し得る。
　実施例４では、ＲＯＭ２１にある、システムファームウェアで実行するブートコードにより、ＳＦＰ用のＩ２Ｃのライトコマンドを使用してパラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込む。すなわちＲＯＭ２１に保存されているＳＡＮブートに必要な設定情報たる接続先ＲＡＩＤ装置のＷＷＮ、ＲＡＩＤ装置のＴａｒｇｅｔ　ＩＤ情報、Ｌｉｎｋ　Ｓｐｅｅｄ等の各パラメータデータをＲＯＭ２１から取り出す。そして取り出されたパラメータデータは、光モジュール３１と交換可能なＩ２Ｃインタフェースに接続できるＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存する。
　あるいはこのＲＯＭモジュール３２を交換後のファイバチャネルカード２０'に装着し、ＳＦＰ用のＩ２Ｃのリードコマンドを使用してＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、そして同パラメータデータを同ファイバチャネルカード２０'のＲＯＭ２１へ書き込む。この読み込み・書き込み動作は、システムファームウェア上で実行すされるブートコードにより実行される。
　また上記光モジュール３１およびこれと交換可能なＲＯＭモジュール３２の各々に検知信号のパス２５を設け、同パスを接地に接続しておく。その結果、ファイバチャネルカードから、光モジュール３１あるいはＲＯＭモジュール３２の挿抜状態の変化が確認できる。この挿抜状態の変化の確認とＲＯＭモジュール３２の内蔵ＲＯＭ３２ａの格納データ状態を確認することによって、管理用操作端末６０からの管理者による指示が必要なくなる。すなわちサーバ１０のシステムファームウェアによる自動制御により、ファイバチャネルカード２０からＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへのパラメータデータの保存、及び交換後のファイバチャネルカード２０'へのパラメータデータの復元がなされる。実施例４によれば、パラメータデータをＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存することができ、ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａから交換後のファイバチャネルカード２０'のＲＯＭ２１へパラメータデータを復元できる。このため、ファイバチャネルカード２０の故障交換後は、システムファームウェアによりＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、交換後の新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込む。この読み込み・書き込み動作は、システムファームウェアが、上記検知信号の変化をトリガとして自動的に指示することで実現される。このようにして新たなファイバチャネルカード２０'においてパラメータデータを復元できる。その結果ＳＡＮブートに必要な設定情報を格納したファイバチャネルファイバチャネルカード２０の設定情報を容易に保持及び復元することができ、ファイバチャネルカード２０の故障時の情報引継ぎを容易になし得る。また情報引継ぎ時の設定ミスを効果的に防ぎ得る。
　すなわち実施例４では、ファイバチャネル通信用のインタフェースとは別にある、光モジュール３１の情報確認で使われるＩ２ＣインタフェースにＩ２Ｃインタフェースに対応したＲＯＭモジュール３２を接続する。そしてファイバチャネルカード２０内のＲＯＭ２１にあるパラメータデータを、当該接続したＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ保存する。この場合、Ｉ２Ｃライトコマンドを使用することにより、ＲＯＭ２１から読み込んだパラメータデータを、光モジュール３１と交換したＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込む。そしてファイバチャネルカード２０の交換後は、Ｉ２Ｃリードコマンドを使うことにより、上記ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込む。そして交換後の新たなファイバチャネルカード２０'内のＲＯＭ２１へ、上記パラメータデータを書き込む。この動作により、交換後の新たなファイバチャネルカード２０'上へ、交換前のファイバチャネルカード２０のパラメータデータを引き継がせる。また、上記の動作を、上記光モジュール３１あるいはＲＯＭモジュール３２の検知信号のパス２５を使うことで、サーバ１０のシステムファームウェアによる自動制御で実行させることができる。
　すなわち上記検知信号のパス２５の検知信号が開放レベル(すなわち未接続状態)から接地レベル(すなわち接続状態)になった場合の検知信号の状態変化をシステムファームウェアがトリガとして使用する。すなわちファイバチャネルカード２０から光モジュール３１が取り外され、その代わりにＲＯＭモジュール３２が装着された場合、装着後のＲＯＭモジュール３２が接続状態となる。その結果前記検知信号のパス２５が接地レベルとなり、システムファームウェアはこのようにしてＲＯＭモジュール３２に交換されたことを検知する。
　すなわちパラメータデータの保存時には、システムファームウェアは前記検知信号のレベルにより、ファイバチャネルカード２０上で光モジュール３１がＲＯＭモジュール３２に交換されたことを検出する。更にシステムファームウェアはファイバチャネルカード２０のＲＯＭ２１にパラメータデータが格納されていることを確認する。それら検出および確認時、これらがトリガとされ、システムファームウェアは自動的にＲＯＭ２１からパラメータデータを読み込み、ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａにこれを書き込む。すなわちパラメータデータの保存が自動的になされる。
　又パラメータデータの復元時、システムファームウェアは前記検知信号のレベルにより、ファイバチャネルカード２０'上で光モジュール３１がＲＯＭモジュール３２に交換されたことを検出する。更にシステムファームウェアは当該交換に係るＲＯＭモジュール３２の内蔵ＲＯＭ３２ａにパラメータデータが格納されていることを確認する。それら検出および確認時、これらがトリガとされ、システムファームウェアは自動的にＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、フィアバチャネルカード２０'のＲＯＭ２１にこれを書き込む。すなわちパラメータデータの復元が自動的になされる。
　以下図１６乃至１９とともに、実施例４の動作を更に詳細に説明する。
　まずファイバチャネルカード２０のパラメータデータのバックアップ動作につき説明する。
　最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図１８中、ステップＳ９１）。その後管理者は当該ファイバチャネルカード２０をサーバ１０に搭載する（ステップＳ９２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ９３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカード２０に設定する操作を行う(ステップＳ９４)。
　次に管理者はサーバ１０に搭載されたファイバチャネルカード２０の光モジュール３１をＲＯＭモジュール３２へ交換する(ステップＳ９５)。サーバ１０のシステムファームウェアが前記検知信号の状態を確認する。その結果検知信号が上記未接続状態(開放レベル)から接続状態(接地レベル)になったことを確認すると、ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからデータを読み込む動作を行う。同読み込み動作で、システムファームウェアはＩ２Ｃのリードコマンドを使う。ここで、ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａには何らデータは書き込まれていない空状態である。この空状態がシステムファームウェアにより確認される。またシステムファームウェアは、ファイバチャネルコントローラ２２のＲＯＭリードコマンドを使って、ＲＯＭ２１にパラメータが書かれていることを確認する。次にシステムファームウェアがファイバチャネルカード２０のＲＯＭ２１からパラメータデータをサーバ１０へ読み込む。同読み込み動作ではファイバチャネルコントローラ２２のＲＯＭリードコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドを使う。そしてＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドを使って、読み込んだパラメータデータをファイバチャネルコントローラ２２へ書き込む。このようにしてファイバチャネルコントローラ２２にパラメータデータを書き込んだ後、システムファームウェアはＩ２Ｃのライトコマンドを使って以下の動作を行う。
　すなわち当該書き込まれたパラメータデータをファイバチャネルコントローラ２２とファイバチャネルカード２０のＳＦＰ用のＩ２Ｃを経由し、前記交換に係るＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込む。このようにしてパラメータデータがＲＯＭモジュール３２の内蔵ＲＯＭ３２ａへ書き込まれた後、管理者はサーバ１０に搭載されたファイバチャネルカード２０のＲＯＭモジュール３２を元の光モジュール３１へ交換する(ステップＳ９６)。
　管理者はその後当該ＲＯＭモジュール３２を保管する。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ９７）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　次に、ファイバチャネルカード２０のパラメータデータが変更された場合のバックアップ動作につき説明する。
　上記同様、最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図１８中、ステップＳ９１）。その後管理者は当該ファイバチャネルカード２０をサーバ１０に搭載する（ステップＳ９２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ９３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカード２０に設定する操作を行う(ステップＳ９４)。
　管理者はサーバ１０に搭載されたファイバチャネルカード２０の光モジュール３１をＲＯＭモジュール３２へ交換する。システムファームウェアが検知信号の状態を確認する。検知信号が未接続状態(開放レベル)から接続状態(接地レベル)になったことを確認した場合、システムファームウェアがＩ２Ｃのリードコマンドを使ってＲＯＭモジュール３２の内蔵ＲＯＭ３２ａのデータをサーバ１０へ読み込む。同時にＲＯＭモジュール３２の内蔵ＲＯＭ３２ａが空状態でないことを確認する。システムファームウェアは次にファイバチャネルカード２０のファイバチャネルコントローラ２２のＲＯＭリードコマンドを使ってＲＯＭ２１にあるパラメータデータをサーバ１０へ読み込む。そして前記ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａから読み込んだデータと比較する。両者が異なる内容であることを確認すると以下の動作を行う。
　すなわち、システムファームウェアがファイバチャネルカード２０のＲＯＭ２１からパラメータデータをサーバ１０へ読み込む。同読み込み動作でファイバチャネルコントローラ２２のＲＯＭリードコマンドとＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのリードコマンドが使われる。そしてＰＣＩもしくはＰＣＩ－Ｅｘｐｒｅｓｓのライトコマンドを使って、読み込んだパラメータデータをファイバチャネルコントローラ２２へ書き込む。このようにしてファイバチャネルコントローラ２２にパラメータデータを書き込んだ後、システムファームウェアはＩ２Ｃのライトコマンドを使って以下の動作を行う。すなわち当該書き込まれたパラメータデータをファイバチャネルコントローラ２２とファイバチャネルカード２０のＳＦＰ用のＩ２Ｃを経由し、前記交換に係るＲＯＭモジュール３２へ書き込む。
　その後管理者はファイバチャネルカード２０のＲＯＭモジュール３２を元の光モジュールに交換する。そしてこのＲＯＭモジュール３２を保管する。
　次に、ファイバチャネルカード交換後のパラメータデータのリカバリ動作内容について説明する。
　図１９においてサーバ１０に搭載されているファイバチャネルカード２０の故障時(ステップＳ１０１)、管理者は同ファイバチャネルカード２０を新たなファイバチャネルカード２０'に交換する（ステップＳ１０２）。その後管理者は管理用端末６０を操作し、サーバ１０のシステムファームウェアを起動する（ステップＳ１０３）。
　管理者は更に、交換後の新たなファイバチャネルカード２０'の光モジュール３１を、上記保管に係るＲＯＭモジュール３２に交換する（ステップＳ１０４）。その結果システムファームウェアが前記検知信号の状態を確認する。前記ＲＯＭモジュールへの交換により検知信号が前記未接続状態(開放レベル)から接続状態(接地レベル)になったことを確認すると、以下の動作を行う。
　すなわちシステムファームウェアがＩ２Ｃのリードコマンドを使ってＲＯＭモジュール３２の内蔵ＲＯＭ３２ａのパラメータデータを読み込むため、同ＲＯＭ３２ａにパラメータデータが書かれていることを確認する。また、ファイバチャネルコントローラ２２のＲＯＭリードコマンドを使ってファイバチャネルカード２０'上のＲＯＭ２１が空状態であることを確認する。そしてＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからパラメータデータを読み込み、同パラメータデータを上記新たなファイバチャネルカード２０'のＲＯＭ２１へ書き込む。同書き込み動作はシステムファームウェアがファイバチャネルコントローラ２２のＲＯＭライトコマンドを使って行う。その後管理者は当該新たなファイバチャネルカード２０'に装着されているＲＯＭモジュール３２を元の光モジュール３１へ交換する(ステップＳ１０５)。その後管理者は当該ＲＯＭモジュール３２を再び保管する。
　その後管理者は管理用端末６０を操作し、ＳＡＮブートにてサーバ１０上でＯＳを起動する（ステップＳ１０６）。当該ＳＡＮブートでは上記ＳＡＮブートに必要な設定情報たるパラメータデータがファイバチャネルカード２０'のＲＯＭ２１から読み込まれる。読み込まれたパラメータデータに基づいて前記接続先のＲＡＩＤ装置１００からＯＳデータを読み出すことによりＳＡＮブートが実行される。
　管理者が操作を行うことによってシステムファームウェアから指示することでファイバチャネルカード２０のファイバチャネルコントローラ２２を制御することもできる。実施例４によれば、前記検知信号のパス２５を使用し、同検知信号の電圧レベルの変化をトリガとして使用することにより、管理者の操作による指示を不要にする。実施例４によれば、前記検知信号の状態変化をトリガとし、システムファームウェアが自動的にファイバチャネルカード２０上のファイバチャネルコントローラ２２を制御する。そしてシステムファームウェアが自動的にブートコードやドライバにＲＯＭ２１のパラメータデータの保存と復元の動作を指示する。
　また実施例４では、システムファームウェアが自動的にＲＯＭ２１およびＲＯＭモジュール３２の各々における格納データの状態を確認し、ＲＯＭモジュール３２に対するデータ書き込みや読み込みを実行する。その目的のため実施例４では、ブートコードやドライバが前記検知信号の状態変化をトリガとして、ＲＯＭ２１およびＲＯＭモジュール３２の格納データ状態を自動的に確認する構成を有する。
　このように実施例４では、管理者がＲＯＭモジュール３２の交換を行うと、システムファームウェアが以下の動作を行う。すなわちＳＡＮブートに必要な設定情報たるパラメータデータのバックアップ、およびファイバチャネルカード２０の交換後に同パラメータデータのＲＯＭ２１へのリカバリを自動的に行う。したがってファイバチャネルカード２０の交換時に構成情報の確認や、パラメータデータ入力する必要がなくなり、作業が短縮できる。またサーバ１０に搭載されているファイバチャネルカード２０のパラメータデータを別途ＲＯＭモジュール３２に保持しておくことにより、ファイバチャネルカード２０の故障交換後において設定情報が正確に保持され、作業ミスの回避ができる。
　このように実施例４では、光モジュール３１の挿抜状態の確認に用いる、ファイバチャネルコントローラ２２とＲＯＭモジュール３２との間に流れる検知信号のためのパス２５を利用する。同検知信号の状態変化をトリガとすることで、管理者による操作を不要とし、システムファームウェアが自動的にファイバチャネルカード２０上のファイバチャネルコントローラの制御を行う。すなわちシステムファームウェアが、ブートコードやドライバに、ファイバチャネルカード上のＲＯＭ２１のパラメータデータの保存と復元の実行の指示を行う。なお、光モジュール３１或いはＲＯＭモジュール３２のファイバチャネルカードに対する挿抜状態の確認には、前記検知信号の電圧レベルを使用した確認機能を使用する。この確認機能はファイバチャネルコントローラ２２が有する。
　なお上記実施例１乃至４はそれぞれ個別の実施例として説明したが、実施例１乃至４の全ての構成および作用効果を全て兼ね備えた一の実施例も可能である。あるいは実施例１乃至４のうちの何れか複数の実施例の構成および作用効果を兼ね備えた一の実施例も可能である。すなわち一の実施例において、ファイバチャネルカードのＲＯＭ２１に格納されたパラメータデータを保存する外部の保存場所として複数のものから選択可能とすることができる。前記複数のものは、実施例１のＲＯＭモジュール３２の内蔵ＲＯＭ３２ａ、実施例２のサーバ１０のＳＶＰ５０および実施例３の光モジュール３１の内蔵ＲＯＭ３１ａである。更に、実施例４の構成は、実施例１，実施例３或いは実施例１、３を組み合わせた実施例に対し組み合わせ可能である。ここで実施例４の構成とは、検出信号のパス２５を利用して光モジュール３１或いはＲＯＭモジュール３２の挿抜状態を検出して自動的にパラメータデータの保存或いは復元動作を起動させる構成である。
　次に、図２０乃至２８とともに実施例５につき説明を行う。
　実施例５では図２０，２１に示す如く、複数のファイバチャネルカード２０－Ａ，２０－Ｂ，２０－ＣとＲＡＩＤ装置１００―Ａ，１００―Ｂ，１００―Ｃとを接続している。ここで各要素、すなわちサーバ１０，ファイバチャネルカード２０－Ａ，２０－Ｂ，２０－Ｃ、光モジュール等は、各々、上記実施例１乃至４のうちの何れかの実施例におけるサーバ１０，ファイバチャネルカード２０、光モジュール３１等と同様の構成を有する。したがって主として異なる部分を説明する。
　実施例５では、時間帯によって起動するファイバチャネルカード２０－Ａ，２０－Ｂ，２０－Ｃの指定を変え、ファイバチャネルカード２０－Ａ，２０－Ｂ，２０－ＣごとにＯＳを切り換えて運用する。したがってファイバチャネルカード２０－Ａ，２０－Ｂ，２０－Ｃのそれぞれに対し、相異なる内容の、上記ＳＡＮブートに必要な設定情報たるパラメータデータを設定し得る。
　このような構成の情報処理システムにおいて、実施例５では、サーバ１０に搭載されている全てのファイバチャネルカードのパラメータデータが、ファイバチャネルカードの各一枚に書き込まれる。その結果、当該各一枚のファイバチャネルカードについてのパラメータデータの保存及び復元の動作により、全てのファイバチャネルカードのパラメータデータの保存と復元を実現することができる。このように実施例５では、複数の、ＳＡＮブートに必要な設定情報たるパラメータデータを格納したファイバチャネルカードのパラメータデータを保存する動作を容易にし、ファイバチャネルカードの故障時の情報引継ぎを容易になし得る。
　図２０はサーバ１０に搭載されている複数のファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃが全て故障した場合を示す。その場合図２１に示す如く、全ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃを交換する。ここで上記の如く、各ファイバチャネルカード２０－Ａ，２０－Ｂ，２０－Ｃのそれぞれにつき、相異なる内容の、ＳＡブートに必要な設定情報たるパラメータデータが設定されていた場合を想定する。図２０，２１の例ではファイバチャネルカードは全３枚であるため、計３種類のパラメータデータが存在する。実施例５では上記の如く、全ファイバチャネルカード２０－Ａ，２０－Ｂ，２０－Ｃについての、前記３種類のパラメータデータを、各ファイバチャネルに全て書き込む。例えばファイバチャネルカード２０－Ａにはファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃの全てについての計３種類のパラメータデータを格納する。同様にファイバチャネルカード２０－Ｂにも、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃの全てについての計３種類のパラメータデータを格納する。同様にファイバチャネルカード２０－Ｃにも、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃの全てについての計３種類のパラメータデータを格納する。
　すなわち実施例５によれば、図２２に示される如く、サーバ１０のシステムファームウェアの起動後、システムファームウェアにより以下の動作がなされる。すなわち当初各ファイバチャネルカードごとに個別に格納されていた各々のパラメータデータが、所定の一枚のファイバチャネルカードに全て書き込まれる。図２２の例の場合、当初はファイバチャネルカード２０―Ａは自己のパラメータデータのみを格納している。同様にファイバチャネルカード２０―Ｂも自己のパラメータデータのみを格納している。同様にファイバチャネルカード２０―Ｃも自己のパラメータデータのみを格納している。同様にファイバチャネルカード２０―Ｄも自己のパラメータデータのみを格納している。その後、これら計４種類のパラメータデータを、１枚のファイバチャネルカード、例えば２０－Ａに全て書き込む。
　その後図２３に示される如く、当該全種類のパラメータデータ(上記例では４種類のパラメータデータ)が書き込まれたファイバチャネルカード(上記例では２０－Ａ)のＲＯＭ２１に格納された当該全種類のパラメータデータを別の箇所に保存する。この保存動作は、上記実施例１乃至４のうちの何れかの実施例による方法を使用して行う。例えば実施例１の方法によれば上記の如く、全種類のパラメータデータが、別途ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａに保存される。
　当該保存終了後、システムファームウェアは、全種類のパラメータデータを設定したファイバチャネルカードからＯＳを起動する。そしてドライバを使って当該ファイバチャネルカードを起動し、当該ファイバチャネルカードのＲＯＭ２１から前記全種類のパラメータデータを読み込む。その後読み込まれた全種類のパラメータデータが、他のファイバチャネルカードの各々のＲＯＭ２１にも書き込まれる。図２３の場合、ファイバチャネルカード２０―Ａを使用したＳＡＮブートでＯＳが起動される。そして起動されたＯＳがファイバチャネルカード２０―ＡのＲＯＭ２１から前記４種類のパラメータデータを読み出し、これを他のファイバチャネルカード２０―Ｂ，２０－Ｃ、２０－Ｄの各々のＲＯＭ２１に全て書き込む。その結果上記の如く、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃ、２０－Ｄの各々のＲＯＭ２１には、４種類のパラメータデータの全てが同様に格納される。すなわち、４種類のパラメータデータの全てが各ファイバチャネルカードにコピーされ、その結果図２４に示される如くの状態となる。すなわちファイバチャネルカード２０－Ａにはファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃ、２０－Ｄの全てについての計４種類のパラメータデータが格納される。同様にファイバチャネルカード２０－Ｂにも、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃ、２０－Ｄの全てについての計４種類のパラメータデータが格納される。同様にファイバチャネルカード２０－Ｃにも、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃ、２０―Ｄの全てについての計４種類のパラメータデータが格納される。同様にファイバチャネルカード２０－Ｄにも、ファイバチャネルカード２０―Ａ，２０－Ｂ，２０－Ｃ、２０―Ｄの全てについての計４種類のパラメータデータが格納される。
　このコピー動作の終了後、サーバ１０は運用状態に置かれる。その後上記の如く全ファイバチャネルカードの故障交換後は、実施例１乃至４のうちの何れかによる方法で、まず所定の一枚のファイバチャネルカードに対して前記４種類のパラメータデータを復元する。そして同パラメータデータが復元されたファイバチャネルカードからＯＳが起動される。その後、ドライバで起動されたファイバチャネルカードのパラメータデータが読み込まれ、他のファイバチャネルカードへ書き込まれる。このようにして、サーバ１０が搭載する各ファイバチャネルカードのパラメータデータの復元が行われる。
　以下図２５，２６とともに参照し、実施例５の動作を更に詳細に説明する。なお図２５，２６では説明の便宜上、実施例１による方法を使用してパラメータデータの保存および復元を行う場合について示す。
　まずファイバチャネルカードのパラメータデータのバックアップ動作につき説明する。
　最初に管理者はサーバ１０が接続する接続先のＲＡＩＤ装置１００を確認する（図２５中、ステップＳ１１１）。その後管理者は各ファイバチャネルカードをサーバに搭載する（ステップＳ１１２）。その後管理者は管理用端末６０を使用してシステムファームウェアを起動する（ステップＳ１１３）。起動後、管理用端末６０を使用して管理者は当該接続先のＲＡＩＤ装置１００に係る、ＳＡＮブートに必要な設定情報たるパラメータデータをファイバチャネルカードごとに設定する操作を行う(ステップＳ１１４)。
　その後管理者が管理用端末６０からシステムファームウェアを使用してサーバ１０に搭載された、所定の一枚のファイバチャネルカード(図２３の例の場合、２０－Ａ)のＲＯＭ２１へ、各ファイバチャネルカードのスロット情報と、対応するパラメータデータとを書き込む。その際の様子が図２２に示される。そして図２３に示される如く、上記ＲＯＭ２１に格納された各ファイバチャネルカードのスロット情報と、対応するパラメータ情報とが、実施例１乃至４のうちの何れか一の実施例による方法により、外部に保存される。実施例１の場合、管理者はサーバ１０に搭載されている前記一枚のファイバチャネルカード(図２３の例の場合、２０－Ａ)の光モジュール３１をＲＯＭモジュール３２に交換する(ステップＳ１１５)。そして上記各ファイバチャネルカードのスロット情報と、対応するパラメータデータとが当該ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａに保存される。その後当該ＲＯＭモジュール３２が元の光モジュールに交換され、当該ＲＯＭモジュールが保存される（ステップＳ１１６）。
　次に図２４に示される如く、管理者が管理用端末６０からシステムファームウェアを使用して、前記一枚のファイバチャネルカード(図２３の例の場合、２０－Ａ)からＯＳを起動する。この場合、まず当該ファイバチャネルカードが有するブートコードはサーバ１０から、当該ファイバチャネルカードが装着されたサーバ１０内のスロットを示すスロット情報を読み込む。そして同スロット情報を当該ファイバチャネルカードのＲＯＭ２１に格納された前記スロット情報と比較することにより当該ファイバチャネルカードが装着されたスロットを示すスロット情報を見出す。そして同スロット情報に対応したパラメータデータを使いＳＡＮブートによりＯＳを起動する(ステップＳ１１７)。
　ＯＳの起動後、管理者が管理用端末６０からドライバを指示する。指示されたドライバは当該ファイバチャネルカード(図２３の例の場合、２０－Ａ)にあるファイバチャネルコントローラ２２のＲＯＭリードコマンドを使い、以下の動作を行う。すなわち図２４に示される如く、当該ファイバチャネルカード(図２３の例の場合、２０－Ａ)のＲＯＭ２１にある、スロット情報と、対応するパラメータデータとをサーバ１０へ読み込む。次に上記指示されたドライバは、他の各ファイバチャネルカード(図２３の例の場合、２０－Ｂ，Ｃ，Ｄ)にあるファイバチャネルコントローラ２２のＲＯＭライトコマンドを使い、上記スロット情報と、対応するパラメータデータとを、上記他の各ファイバチャネルカードのＲＯＭ２１へ書き込む(ステップＳ１１８)。
　上記他の各ファイバチャネルカードへのスロット情報と、対応するパラメータデータとの書き込みの終了後、サーバ１０が運用に入る。
　次に、ファイバチャネルカード交換後のパラメータデータのリカバリ動作内容について説明する。
　図２６においてサーバ１０に搭載されているファイバチャネルカードの故障時(ステップＳ１２１)、管理者は全ファイバチャネルカードを新たなファイバチャネルカードに交換する（ステップＳ１２２）。その後管理者は管理用端末６０を操作し、サーバ１０のシステムファームウェアを起動する（ステップＳ１２３）。
　その後サーバ１０に搭載された前記交換後の新たなファイバチャネルカードのうちの、ある一枚のファイバチャネルカードのＲＯＭ２１に対し、上記スロット情報と、対応するパラメータデータとを復元する。ここでは実施例１乃至４のうちの何れか一の実施例による方法を使用する。例えば実施例１による方法を使用した場合、上記の如く、スロット情報と、対応するパラメータデータとが書き込まれて保存されたＲＯＭモジュール３２から同スロット情報と、対応するパラメータデータとを読み出して上記したある一枚のファイバチャネルカードのＲＯＭ２１に書き込む(ステップＳ１２４)。この読み出し・書き込み動作は、当該ファイバチャネルカードの光モジュール３１を前記保存されたＲＯＭモジュール３２交換した状態で行う。読み出し・書き込み動作後、当該ファイバチャネルカードのＲＯＭモジュール３２を元通りに光モジュール３１に交換する（ステップＳ１２５）。上記読み出し・書き込み動作により、前記スロット情報と、対応するパラメータデータとが当該フィアバチャネルカードにおいて復元される。
　その後管理者が管理用端末６０からシステムファームウェアを使用し、当該ファイバチャネルカードからＯＳを起動する（ステップＳ１２６）。すなわち管理者が当該ファイバチャネルカードを指定し、当該ファイバチャネルカードのブートコードはサーバ１０から当該ファイバチャネルカードが装着されたスロットのスロット情報を読み込む。そして前記復元されたスロット情報と比較することにより、当該ファイバチャネルカードが装着されたスロットを確認する。そして該当するスロット情報に対応したパラメータデータを使ってＯＳを起動する。
　ＯＳの起動後、管理者が管理用端末６０からドライバを指示する。指示されたドライバは当該ファイバチャネルカードにあるファイバチャネルコントローラ２２のＲＯＭリードコマンドを使い、以下の動作を行う。すなわち図２４に示される如く、当該ファイバチャネルカードのＲＯＭ２１にある、スロット情報と、対応するパラメータデータとをサーバ１０へ読み込む。次に上記指示されたドライバは、他の各ファイバチャネルカードにあるファイバチャネルコントローラ２２のＲＯＭライトコマンドを使い、上記スロット情報と、対応するパラメータデータとを、上記他の各ファイバチャネルカードのＲＯＭ２１へ書き込む(ステップＳ１２７)。
　上記他の各ファイバチャネルカードへのスロット情報と、対応するパラメータデータとの書き込み終了後、サーバ１０が運用に入る。
　実施例５によれば、一枚のファイバチャネルカード上に複数枚のファイバチャネルカードのパラメータデータを全て格納する。その結果、一枚のファイバチャネルカードのパラメータデータに対する操作のみで、複数のファイバチャネルカードのパラメータデータの保存と復元がなされる。すなわち実施例５によれば、一枚のファイバチャネルカードに対する操作のみで各ファイバチャネルカードのＳＡＮブートに必要な設定情報たるパラメータデータの保存と復元を実施し得る。その結果、ファイバチャネルカードの交換時に構成情報の確認や、パラメータデータを手入力する必要がなくなり、作業短縮ができる。またサーバ１０に搭載されているファイバチャネルカードのパラメータデータを別途保持することにより、ファイバチャネルカードの故障交換後においても設定情報が正確に保持され設定ミスの回避ができる。
　又実施例５によれば、さらに、クラスタなどの、同一システムの増設が必要な際、パラメータの人手による入力作業を不要とし、自動的に設定情報をコピーすることができる。図２７、２８はその場合の例を示す。
　図２７の例では、既存のサーバ１０に対し、同一構成のサーバ１０－Ａを設ける。この場合最初に管理者はサーバ１０－Ａが接続する接続先のＲＡＩＤ装置１００―Ａ或いは１００－Ｂを確認する（図２８中、ステップＳ１３１）。その後管理者はファイバチャネルカード２０－Ｃ，２０－Ｄをサーバ１０－Ａに搭載する（ステップＳ１３２）。その後管理者は管理用端末６０を使用してサーバ１０－Ａのシステムファームウェアを起動する（ステップＳ１３３）。起動後、サーバ１０－Ａに搭載されたファイバチャネルカード、例えば２０－ＣのＲＯＭ２１に対し、実施例１乃至４のうちの何れか一の実施例による方法により、上記スロット情報と、対応するパラメータデータとを書き込む。この書き込み動作は、上記各実施例における復元動作と同様の動作である。例えば実施例１による方法を使用した場合、サーバ１０－Ａに搭載されたファイバチャネルカード２０－Ｃの光モジュール３１を、保存に係るＲＯＭモジュール３２に交換する(ステップＳ１３４)。当該保存に係るＲＯＭモジュール３２の内蔵ＲＯＭ３２ａには、サーバ１０に搭載されたファイバチャネルカード２０－Ａ或いは２０－ＢのＲＯＭ２１に格納されたスロット情報と、対応するパラメータデータとがバックアップの目的で保存されている。当該保存は、例えば図２５とともに上記した方法にて行われる。当該ＲＯＭモジュール３２の内蔵ＲＯＭ３２ａからスロット情報と、対応するパラメータデータとを読み出してサーバ１０－Ａに搭載されたファイバチャネルカード２０―ＣのＲＯＭ２１に書き込む。その後ファイバチャネルカード２０―ＣのＲＯＭモジュール３２を、元通りに光モジュールに交換する（ステップＳ１３５）。
　その後管理者が管理用端末６０からサーバ１０－Ａのシステムファームウェアを使用し、上記ファイバチャネルカード２０－ＣからＯＳを起動する（ステップＳ１３６）。すなわち管理者が当該ファイバチャネルカード２０－Ｃを指定し、当該ファイバチャネルカード２０－Ｃのブートコードはサーバ１０－Ａから当該ファイバチャネルカードが装着されたスロットのスロット情報を読み込む。そして上記の如くファイバチャネルカード２０―ＣのＲＯＭ２１に書き込まれたスロット情報と、対応するパラメータ情報のうちのスロット情報と比較する。同比較動作により、当該ファイバチャネルカードが装着されたスロットを確認する。そして該当するスロット情報に対応したパラメータデータを使ってＯＳを起動する。
　ＯＳの起動後、管理者が管理用端末６０からサーバ１０－Ａが有するドライバを指示する。指示されたドライバは当該ファイバチャネルカード２０－Ｃにあるファイバチャネルコントローラ２２のＲＯＭリードコマンドを使い、以下の動作を行う。すなわち当該ファイバチャネルカード２０－ＣのＲＯＭ２１にある、スロット情報と、対応するパラメータデータとをサーバ１０－Ａへ読み込む。次に上記指示されたドライバは、他のファイバチャネルカード２０－Ｄにあるファイバチャネルコントローラ２２のＲＯＭライトコマンドを使い、上記読み込まれたスロット情報と、対応するパラメータデータとを、上記他のファイバチャネルカード２０－ＤのＲＯＭ２１へ書き込む(ステップＳ１３７)。
　上記他のファイバチャネルカード２０－Ｄへのスロット情報と、対応するパラメータデータとの書き込み終了後、サーバ１０－Ａが運用に入る。
　実施例５によれば、一枚のファイバチャネルカードに、サーバに搭載された全ファイバチャネルカードのパラメータを格納する。その結果、一枚のファイバチャネルカードへの操作のみで、サーバに搭載された全ファイバチャネルカードのパラメータデータの保存と復元を自動実行させることができる。

Claims (10)

  1. 　外部記憶装置と情報処理装置を接続することにより、前記情報処理装置の機能を拡張する機能拡張装置において、
    　前記情報処理装置と前記外部記憶装置との間を第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と、
    　前記第１の設定情報に基づいて動作し、前記情報処理装置と前記外部記憶装置との間を前記第１のインタフェースを介して接続する接続モジュール部と、
    　前記第１の記憶部と前記接続モジュール部または第２の記憶部とに接続され、第２の記憶部が格納する第２の設定情報を、前記第１の記憶部に設定する制御部とを有し、
    　前記第２の記憶部は前記接続モジュールと交換可能とされ、前記第１のインタフェースに前記接続モジュール部を接続する場合の前記第２の設定情報を格納することを特徴とする機能拡張装置。
  2. 　前記接続モジュール部は、他の接続モジュールとも交換可能であることを特徴とする請求項１記載の機能拡張装置。
  3. 　前記外部記憶装置には、前記情報処理装置を起動するオペレーティングシステムが格納されることを特徴とする請求項１記載の機能拡張装置。
  4. 　前記接続モジュール部と前記制御部とは、前記第１のインタフェースとは異なる第２のインタフェースを介して接続され、
    　前記制御部は、前記第２の記憶部に格納された第２の設定情報を、前記第２のインタフェースを介して前記第１の記憶部に格納することを特徴とする請求項１記載の機能拡張装置。
  5. 　前記第１及び第２の設定情報は、
    　前記第１のインタフェースにおいて前記外部記憶装置を特定するユニーク情報、前記外部記憶装置が有するドライブ装置を特定する識別情報、前記第１のインタフェースの接続形態を示す情報、または前記第１のインタフェースの速度情報のうち、いずれか一つを有することを特徴とする請求項１記載の機能拡張装置。
  6. 　オペレーティングシステムを格納する外部記憶装置を接続する情報処理装置において、
    　前記外部記憶装置との間を第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と、
    　前記第１の設定情報に基づいて動作し、前記情報処理装置と前記外部記憶装置との間を前記第１のインタフェースを介して接続する接続モジュール部と、
    　前記第１のインタフェースに前記接続モジュール部を接続する場合の第２の設定情報を格納する第２の記憶部と、
    　前記第２の記憶部が格納する前記第２の設定情報を、前記第１の記憶部に設定する制御部と、
    　前記外部記憶装置に格納されるオペレーティングシステムを、前記第１のインタフェースと前記接続モジュール部と前記制御部とを介して読み込んで保持する記憶装置と、
    　前記記憶装置が格納するオペレーティングシステムに基づいて動作する演算処理装置と
    を有することを特徴とする情報処理装置。
  7. 　情報処理装置と、前記情報処理装置を起動するオペレーティングシステムを格納し、前記情報処理装置に接続される外部記憶装置とを有する情報処理システムにおいて、
    　前記外部記憶装置との間を第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と、
    　前記第１の設定情報に基づいて動作し、前記情報処理装置と前記外部記憶装置との間を前記第１のインタフェースを介して接続する接続モジュール部と、
    　前記第１のインタフェースに前記接続モジュール部を接続する場合の第２の設定情報を格納する第２の記憶部と、
    　前記第２の記憶部が格納する前記第２の設定情報を、前記第１の記憶部に設定する制御部と、
    　前記外部記憶装置に格納されるオペレーティングシステムを、前記第１のインタフェースと前記接続モジュール部と前記制御部を介して読み込んで保持する記憶装置と、
    　前記記憶装置が格納するオペレーティングシステムに基づいて動作する演算処理装置とを有し、
    　前記外部記憶装置は、前記情報処理装置の起動に使用するオペレーティングシステムを格納するドライブ装置を有することを特徴とする情報処理システム。
  8. 　外部記憶装置と情報処理装置とを第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と、前記第１の設定情報に基づいて動作し、前記情報処理装置と前記外部記憶装置との間を前記第１のインタフェースを介して接続する接続モジュール部とを有する接続装置の制御方法において、
    　第２の記憶部に、前記第１のインタフェースに前記接続モジュール部を接続する場合の第２の設定情報を格納するステップと、
    　前記第１の記憶部と前記接続モジュールとに接続された制御部が、前記第２の記憶部が格納する前記第２の設定情報を、第１の記憶部に設定するステップと
    を有することを特徴とする制御方法。
  9. 　前記第２の記憶部は前記接続モジュールと交換可能な構成を有することを特徴とする請求項８に記載の制御方法。
  10. 　外部記憶装置と情報処理装置とを第１のインタフェースを介して接続する場合の第１の設定情報を格納する第１の記憶部と、前記第１の設定情報に基づいて動作し、前記情報処理装置と前記外部記憶装置との間を前記第１のインタフェースを介して接続する接続モジュール部とを有する接続装置を使用して前記外部記憶装置と接続する前記情報処理装置を制御するためのプログラムであって、
    　コンピュータを
    　第２の記憶部に、前記第１のインタフェースに前記接続モジュール部を接続する場合の第２の設定情報を格納する手段と、
    　前記第１の記憶部と前記接続モジュールとに接続された制御部に、前記第２の記憶部が格納する前記第２の設定情報を、第１の記憶部に設定させる手段と
    して機能させるためのプログラム。
PCT/JP2008/063432 2008-07-25 2008-07-25 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム WO2010010633A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP08791676.3A EP2320324B1 (en) 2008-07-25 2008-07-25 Function expansion device, information processing device, information processing system, control method, and program
PCT/JP2008/063432 WO2010010633A1 (ja) 2008-07-25 2008-07-25 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム
JP2010521574A JP5163744B2 (ja) 2008-07-25 2008-07-25 機能拡張装置、情報処理装置および制御方法
US12/929,429 US8429392B2 (en) 2008-07-25 2011-01-24 Function expansion apparatus for connecting an information processing apparatus to an external storage apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/063432 WO2010010633A1 (ja) 2008-07-25 2008-07-25 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/929,429 Continuation US8429392B2 (en) 2008-07-25 2011-01-24 Function expansion apparatus for connecting an information processing apparatus to an external storage apparatus

Publications (1)

Publication Number Publication Date
WO2010010633A1 true WO2010010633A1 (ja) 2010-01-28

Family

ID=41570112

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/063432 WO2010010633A1 (ja) 2008-07-25 2008-07-25 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム

Country Status (4)

Country Link
US (1) US8429392B2 (ja)
EP (1) EP2320324B1 (ja)
JP (1) JP5163744B2 (ja)
WO (1) WO2010010633A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010010633A1 (ja) * 2008-07-25 2010-01-28 富士通株式会社 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム
US10198388B2 (en) * 2013-09-20 2019-02-05 Seagate Technology Llc Data storage system with pre-boot interface
US20150089102A1 (en) * 2013-09-23 2015-03-26 Lsi Corporation Solid state drives that cache boot data
CN104063337B (zh) * 2014-01-16 2016-11-02 广东奎创科技发展有限公司 一种基于无线切换执行相应操作的装置组合及其方法
US10521387B2 (en) 2014-02-07 2019-12-31 Toshiba Memory Corporation NAND switch
US10554580B2 (en) 2016-11-30 2020-02-04 Hewlett Packard Enterprise Development Lp Fabric cable emulation
US11226880B2 (en) 2018-12-07 2022-01-18 International Business Machines Corporation Communication of diagnostic parameters of a data mirroring configuration from a storage controller to a host
US11157375B2 (en) 2018-12-07 2021-10-26 International Business Machines Corporation Generation of host requests to a storage controller for read diagnostic parameters for a data mirroring configuration

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001356913A (ja) * 2000-06-13 2001-12-26 Nec Corp Ｂｉｏｓプリブート環境を利用したユーザ認証型ネットワークｏｓブート方法及びシステム
JP2002099390A (ja) * 2000-09-22 2002-04-05 Toshiba Corp ディスク制御装置
JP2004252977A (ja) * 2003-02-18 2004-09-09 Agilent Technol Inc 通信モジュールにおいて隠しアドレスを実装するシステムおよび方法
JP2007066216A (ja) 2005-09-02 2007-03-15 Hitachi Ltd ブート構成変更方法
JP2007164305A (ja) 2005-12-12 2007-06-28 Hitachi Ltd ブート制御方法および計算機システム並びにその処理プログラム

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3889922B2 (ja) * 2000-11-14 2007-03-07 株式会社日立製作所 共用ストレージを備えた計算機システム
US7079775B2 (en) * 2001-02-05 2006-07-18 Finisar Corporation Integrated memory mapped controller circuit for fiber optics transceiver
GB2375847B (en) * 2001-05-22 2005-03-16 Hewlett Packard Co Protection and restoration of RAID configuration information in disaster recovery process
US6874100B2 (en) * 2001-07-12 2005-03-29 Digi-Data Corporation Raid system with multiple controllers and proof against any single point of failure
JP3617632B2 (ja) * 2001-07-19 2005-02-09 富士通株式会社 Ｒａｉｄ制御装置及びその制御方法
US7551850B2 (en) * 2003-05-15 2009-06-23 International Business Machines Corporation Highly available redundant optical modules using single network connection
JP2005071242A (ja) * 2003-08-27 2005-03-17 Toshiba Corp 計算機システム及び動的ブートイメージ切替プログラム
JP4033175B2 (ja) * 2004-06-18 2008-01-16 住友電気工業株式会社 光データリンクモジュール
JP2006101435A (ja) * 2004-09-30 2006-04-13 Mitsubishi Electric Corp 光通信モジュール
US7631219B2 (en) * 2004-10-22 2009-12-08 Broadcom Corporation Method and computer program product for marking errors in BIOS on a RAID controller
US7532820B2 (en) * 2004-10-29 2009-05-12 Finisar Corporation Systems and methods for providing diagnostic information using EDC transceivers
US7310704B1 (en) * 2004-11-02 2007-12-18 Symantec Operating Corporation System and method for performing online backup and restore of volume configuration information
JP4710518B2 (ja) * 2005-09-28 2011-06-29 株式会社日立製作所 計算機システムとそのブート制御方法
JP2009075759A (ja) * 2007-09-19 2009-04-09 Hitachi Ltd ストレージ装置及びストレージ装置におけるデータの管理方法
WO2010010633A1 (ja) * 2008-07-25 2010-01-28 富士通株式会社 機能拡張装置、情報処理装置、情報処理システム、制御方法およびプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001356913A (ja) * 2000-06-13 2001-12-26 Nec Corp Ｂｉｏｓプリブート環境を利用したユーザ認証型ネットワークｏｓブート方法及びシステム
JP2002099390A (ja) * 2000-09-22 2002-04-05 Toshiba Corp ディスク制御装置
JP2004252977A (ja) * 2003-02-18 2004-09-09 Agilent Technol Inc 通信モジュールにおいて隠しアドレスを実装するシステムおよび方法
JP2007066216A (ja) 2005-09-02 2007-03-15 Hitachi Ltd ブート構成変更方法
JP2007164305A (ja) 2005-12-12 2007-06-28 Hitachi Ltd ブート制御方法および計算機システム並びにその処理プログラム

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
JPWO2010010633A1 (ja) 2012-01-05
EP2320324A1 (en) 2011-05-11
EP2320324B1 (en) 2015-08-12
EP2320324A4 (en) 2014-08-20
JP5163744B2 (ja) 2013-03-13
US20110125939A1 (en) 2011-05-26
US8429392B2 (en) 2013-04-23

Similar Documents

Publication Publication Date Title
JP5163744B2 (ja) 機能拡張装置、情報処理装置および制御方法
JP4870915B2 (ja) ストレージ装置
JP4448878B2 (ja) 障害回復環境の設定方法
US8812913B2 (en) Method and apparatus for isolating storage devices to facilitate reliable communication
US8788636B2 (en) Boot controlling method of managed computer
US10241868B2 (en) Server control method and server control device
US20140101653A1 (en) System and method for providing out-of-band software or firmware upgrades for a switching device
JP5216336B2 (ja) 計算機システム、管理サーバ、および、不一致接続構成検知方法
CN107980119B (zh) 一种服务器管理方法和服务器
US20160299767A1 (en) Host bus adapter with built-in storage for local boot-up
JP2005228308A (ja) サーバ・シャーシ内のブレード・サービス・プロセッサのフラッシュの失敗を回復するための方法およびシステム
JP2005071196A (ja) ディスクアレイ装置、及びその障害情報の制御方法
WO2012120565A1 (en) Storage apparatus and method of comparing an expected communication rate between a storage controller and an expander with an operational connection rate
WO2015074235A1 (zh) 一种内存数据的迁移方法、计算机和装置
JP2007025933A (ja) ストレージシステム及びそのファームウェア自動更新方法
EP2590072A1 (en) System control device, information processing system, and data migration and restoration method for information processing system
US7861112B2 (en) Storage apparatus and method for controlling the same
US8074018B2 (en) Disk array apparatus, and control method and control program recording medium
US20160294609A1 (en) Storage system upgrade
US20210019221A1 (en) Recovering local storage in computing systems
US8738829B2 (en) Information system for replacing failed I/O board with standby I/O board
JP5360311B2 (ja) ディスクアレイ装置
WO2008121572A1 (en) Detecting port configurations
WO2008121574A2 (en) Managing storage system modules
KR20070107884A (ko) 하드디스크 퀵 리커버리

Legal Events

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

Ref document number: 08791676

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010521574

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2008791676

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE