JP6516875B2 - 統合プラットフォーム、サーバ、及び、フェイルオーバ方法 - Google Patents
統合プラットフォーム、サーバ、及び、フェイルオーバ方法 Download PDFInfo
- Publication number
- JP6516875B2 JP6516875B2 JP2017560003A JP2017560003A JP6516875B2 JP 6516875 B2 JP6516875 B2 JP 6516875B2 JP 2017560003 A JP2017560003 A JP 2017560003A JP 2017560003 A JP2017560003 A JP 2017560003A JP 6516875 B2 JP6516875 B2 JP 6516875B2
- Authority
- JP
- Japan
- Prior art keywords
- boot
- efi
- server
- unit
- storage
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2033—Failover techniques switching over of hardware resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0617—Improving the reliability of storage systems in relation to availability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
- G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
Description
本発明は、概して、計算機制御に関し、特に、計算機の冗長化に関する。
ストレージネットワークにおいては、LU(Logical Unit)へのアクセスを特定のサーバに限定することが望ましい。サーバが、アクセス(I/O(Input/Output))してはいけないLU(例えば論理ボリューム(論理VOL))に誤ってアクセスし、そのLUのデータを誤って更新してしまうおそれがあるからである。
LUへのアクセスを特定のサーバに限定する技術として、LUマスキング機能が知られている。このLUマスキング機能は、ストレージ装置が有するポート毎に、LUについてのアクセス制御リストを作成する。アクセス制御リストは、ストレージ装置内でLUへのアクセスを許可されたFC−HBA(Fibre Channel−Host Bus Adapter)の物理ポートのWWN(World Wide Name)を含む。
また、ストレージ装置のI/Oポート(ストレージポートという)は、従来、1から2ポート程度と少なく、FCスイッチを用いて、複数のサーバからのアクセスを可能とする。しかし、近年、ストレージポートは、10以上のポートを搭載していることも多く、高額なFCスイッチを用いずとも、複数のサーバと直結して接続できるようになってきている。
特許文献1では、FC−HBAとストレージ装置のFC(Fibre Channel)ポートとが、FCスイッチを介して接続されることが前提となっている。このため、FCスイッチの機能により、現用サーバから予備サーバへの切り替えの前後において、切り替え前の現用サーバが発行するI/O要求と、切り換え後の予備サーバが発行するI/O要求とは、同じストレージポートで受領される。LUについてのアクセス制御リストは、ストレージポート単位で適用される(例えばストレージポートにアクセス制御リストが割り当てられる)が、上記のように、同一LUを指定したI/O要求を受けるストレージポートは、現用サーバから予備サーバへの切り替えの前後で同じなので、切り替え前のサーバは、その同じLUにアクセスできてしまう。
一方、ストレージポートとサーバの物理ポートとがFCケーブル又はPCIe(Peripheral Component Interconnect Express)バス等によって直結されている場合(言い換えれば、ストレージポートとサーバの物理ポートとが1対1で対応している場合)、現用サーバから予備サーバへの切り替えの前後において、切り替え前の現用サーバが発行するI/O要求と、切り換え後の予備サーバが発行するI/O要求とは、異なるストレージポートで受領される。切り換え後の予備サーバは、I/O要求の送出先のストレージポートのWWNを元に、LUの検索指示を送出するが、I/O要求を受けるストレージポートのWWNは変わってしまっているため、LUを見つけることができない。そのため、切換え後の予備サーバは、LUへアクセスすることができない。
また、特許文献2では、仮想化したLPAR(Logical PARtition)の構成が条件となっているため、仮想化を行っていない計算機システムにおいて上述の課題を解決することができない。
そこで、本発明の目的は、フェイルオーバが実行された際に、予備サーバが正常にブートできるようにすることにある。
一実施例に係る統合プラットフォームは、現用及び予備サーバと、ストレージ装置とを有する。
ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、World Wide Name(WWN)が付与されている。
ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なLogical Unit ID(LUID)が付与されている。
現用及び予備サーバは、それぞれ、ストレージポートと1対1で接続されている。
現用サーバは、接続先のストレージポートのWWNと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのLogical Unit Number(LUN)と、当該ブート論理ボリュームのLUIDと、を関連付けるブート検索情報、を有する。
フェイルオーバが実行される際、現用サーバが有するブート検索情報は、予備サーバへコピーされる。
ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、World Wide Name(WWN)が付与されている。
ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なLogical Unit ID(LUID)が付与されている。
現用及び予備サーバは、それぞれ、ストレージポートと1対1で接続されている。
現用サーバは、接続先のストレージポートのWWNと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのLogical Unit Number(LUN)と、当該ブート論理ボリュームのLUIDと、を関連付けるブート検索情報、を有する。
フェイルオーバが実行される際、現用サーバが有するブート検索情報は、予備サーバへコピーされる。
本発明によれば、フェイルオーバが実行された際に、予備サーバが正常にブートすることができる。
以下、図面を参照して、実施例を説明する。なお、以下の説明で、は「aaa表」、及び「aaaリスト」等の表現にて実施例の情報を説明するが、これらは表及びリスト等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために、「aaa表」及び「aaaリスト」等を「aaa情報」と呼ぶことができる。
また、以下の説明では、各情報の要素の識別情報の一例として、「名前」及び「ID」の少なくとも1つを用いることがあるが、これらについては互いに置換が可能である。
また、下記の説明では、仮想化の環境でも実現可能であり、その場合、「Boot Priority」をLPAR上の仮想FC−HBA所有する「仮想Boot Priority」として、「Boot Order」をLPAR上のゲストEFIが所有する「仮想Boot Order」として置換が可能である。
また、以下の説明では、同種の要素を区別しないで説明する場合には名称及び参照符号を使用し(例えばサーバ100)、同種の要素を区別して説明する場合にはその要素に割り振られた識別情報を使用する(例えばサーバ100A、100B)を使用することがある。
また、以下の説明では、「プログラム」を主語として処理の説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート(通信制御装置)を用いながら行うため、当該処理の説明は、プロセッサを主語とした処理の説明としてもよい。また、プログラムを主語として開示された処理は、そのプログラムを実行するプロセッサを有する装置(例えば、管理システム又はストレージ装置)が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
図1は、本実施例に係る統合プラットフォームの構成例を示す。
統合プラットフォーム1は、ストレージ装置200と、複数のサーバ100とを有する。ストレージ装置200と複数のサーバ100とは、PCIeバス46を介して双方向通信可能に接続されている。複数のサーバ100が、サーバシャーシ15に搭載されている。ストレージ装置200と複数のサーバ100とは、管理ネットワーク45を介して、管理サーバ300と双方向通信可能に接続されている。管理ネットワーク45には、管理サーバ300の管理クライアント350と、サーバシャーシ15に搭載されているサービスプロセッサ(SVP)17とが接続されてよい。管理ネットワーク45は、例えばLAN(Local Area Network)などの通信ネットワークであってよい。
サーバ100は、例えば、図示しないクライアントコンピュータからファイルのI/O要求を受信すると、その受信したI/O要求に基づいて、ストレージ装置200にアクセスしてよい。ストレージ装置200へのアクセスとは、サーバ100がストレージ装置200にI/O要求を送信することであってよい。サーバシャーシ15の内部には、内部ネットワーク(例えばLAN)47が存在してよい。
SVP17は、コントローラの一例であり、内部ネットワーク47を介して、各サーバ100を管理する。SVP16は、切り替え元のサーバ100及び切り替え先のサーバ100の少なくとも一方に、フェイルオーバの指示を出すことができてよい。SVP17は、サーバシャーシ15の内部の保守ポート16と、内部バス等の回路を介して、双方向通信可能に接続されてよい。管理者は、保守ポート16に保守用の端末を直接接続し、その保守用の端末を用いることにより、管理ネットワーク45を介することなく、SVP17を操作することができてよい。
管理サーバ300は、管理システムの一例であり、管理ネットワーク45を介して、計算機システムを管理する。管理サーバ300も、切り替え元のサーバ100及び切り替え先のサーバ100の少なくとも一方に、フェイルオーバの指示を出すことができてよい。言い換えれば、各サーバ100が、SVP17及び管理サーバ30000の少なくとも一方からフェイルオーバの指示を受けることができてよい。これにより、SVP17は、サーバシャーシ15内において、所定のイベントを検出し、管理サーバ300からの指示無しに、自動的にフェイルオーバを行うこともできるし、管理サーバ300からの指示を受けて(例えば、管理クライアント350の操作者(管理者)によるマニュアル操作に応答して)、フェイルオーバを行うこともできる。
管理クライアント350は、管理ネットワーク45を介して、管理サーバ300のGUI表示処理モジュール32300(図4参照)と通信し、WEBブラウザ上に各種情報を表示する計算機である。管理者は管理クライアント上のWEBブラウザに表示された情報を参照することで、計算機システム内の装置を管理することができる。管理サーバ300と管理クライアント350とは、1台のサーバから構成されてもよい。
図2は、サーバ100の構成例を示す。
サーバ100は、管理ネットワーク45に接続される管理ポート11100と、内部ネットワーク47に接続されるポート11000と、1以上のI/Oポート14000と、PCIeバスを介してストレージ装置200に接続されるFC−HBA120と、メモリ13000と、プロセッサ12000と、EFI190とを有する。これらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。
プロセッサ12000は、1以上のプロセッサで構成されてよい。メモリ13000は、1以上のメモリで構成されてよく、また、補助記憶デバイスのような記憶デバイスを含んでよい。EFI190は、Boot Order180を有し、Boot Order180は、ストレージ装置200の論理VOLへアクセスするために使用される。
サーバ100は、FC−HBA120を介して、ストレージ装置200へアクセスする。FC−HBA120は、サーバ100が、論理VOLにアクセスするために使用するBoot Priority150を有する。また、FC−HBA120は、当該FC−HBA120の初期化やストレージ装置200へのアクセスを行うためのEFIドライバ170を有する。
メモリ13000には、OS13100と、LPAR管理プログラム13200と、I/Oポート管理表13300と、LPAR管理表13400と、LPAR稼動スケジュール管理表13500と、が格納されてよい。
LPAR管理プログラム13200は、オペレーティングシステム13100から提供されたプロセッサ12000及びメモリ13000のような物理資源(コンピュータリソース)を論理的に分割し、LPARを作成する。LPARは、管理計算機と呼ぶこともできる。LPAR管理プログラム13200が作成したLPARは、PCIeバス46000を介して、サーバ100に接続されたストレージ装置200上の論理VOLを、記憶領域として認識する。
なお、図2では、LPAR管理プログラム13200がメモリ13000に存在しているが、LPAR管理プログラムが存在せず、オペレーティングシステム13100から提供された記憶領域を使用し、当該記憶領域に対してI/Oを行う業務アプリケーションが代わりに存在しても良い。つまり、LPARを構築できない(実行できない)サーバ100が存在してよい。
また、図2では、LPAR管理プログラム13200がメモリ13000に存在しているが、LPAR管理プログラムの代わりに仮想化制御プログラムが存在し、仮想化制御プログラムが、プロセッサ12000及びメモリ13000のような物理資源を抽象化及び標準化して、仮想マシンに仮想的なハードウェアを提供してもよい。その場合、以下の説明において、LPARが仮想マシンに、仮想化制御プログラムがLPAR管理プログラムに相当する。
図3は、ストレージ装置200の構成例を示す。
ストレージ装置200は、ストレージシステムの一例であり、複数のストレージポート21000と、管理ポート21100と、メモリ23000と、RAID(Redundant Arrays of Inexpensive (or Independent) Disks)グループ24010と、コントローラ25000とを有する。それらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。
ストレージポート21000は、PCIeバス46を介してサーバ100に接続してよい。
管理ポート21100は、管理ネットワーク45を介して管理サーバ300に接続してよい。
メモリ23000には、プログラムや管理情報などが格納されてよい。メモリ23000は、1以上のメモリで構成されてよく、また、補助記憶デバイスのような記憶デバイスを含んでよい。
RAIDグループ24010には、様々なデータが格納されてよい。
コントローラ25000は、データやメモリ内の管理情報を制御してよい。
メモリ23000には、ディスク管理プログラム23100と、ポート管理表23200と、ホストグループ管理表23300と、RAIDグループ管理表23400と、ボリューム管理表23500と、ホストグループ−ボリューム関連管理表23600と、テーブルサイズ上限管理表23700と、が格納される。
ディスク管理プログラム23100は、管理ポート21100を経由して管理サーバ300と通信し、管理サーバ300に対して、ポート管理表23200と、ホストグループ管理表23300と、RAIDグループ管理表23400と、ボリューム管理表23500と、ホストグループ−ボリューム関連管理表23600と、テーブルサイズ上限管理表23700と、のうちの少なくとも1つの表が有する情報を、ストレージ装置200へ提供する。
RAIDグループ24010は、複数の不揮発記憶デバイス24220によって構成されている。RAIDグループ24010に代えて1つの不揮発記憶デバイス24220が採用されてもよい。RAIDグループ24010のような1以上の不揮発記憶デバイス24220を基に、論理VOL24110が提供される。少なくとも1つの論理VOL24110は、Thin Provisioningに従う仮想ボリュームのような仮想的な論理VOLであってよい。
コントローラ25000は、内部に、ストレージ装置200内の制御を行うプロセッサや、サーバ100との間でやりとりするデータを一時的に記憶するキャッシュメモリを有してよい。そして、それぞれのコントローラ25000は、ストレージポート21000とRAIDグループ24010との間に介在し、両者の間におけるデータの受け渡しを制御してよい。
なお、ストレージ装置200は、サーバ100に提供した論理VOL24110を指定したアクセス要求(I/O要求を指す)を受信し、その論理VOL24110(例えば、その論理VOL24110の基になっている記憶デバイス)への読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図3及び前述以外の構成であってもよい。例えば、ストレージコントローラと記憶領域とを提供する記憶デバイスが別な筐体に格納されていてもよい。例えば、メモリ23000とコントローラ25000とがストレージコントローラであってもよい。ストレージコントローラと記憶デバイスとが同じ筐体に存在する場合及び別な筐体に存在する場合の両方を含む表現として、ストレージ装置を、ストレージシステムと呼び変えても良い。ストレージシステムは、複数のストレージ装置であってもよい。
図4は、管理サーバ300の構成例を示す。
管理サーバ300は、管理システムの一例であり、管理ネットワーク45に接続するための管理ポート31000と、プロセッサ31100と、記憶資源33000と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス31200と、管理者が指示を入力するためのキーボード等の入力デバイス31300とを有してよい。これらの要素は、内部バス等の回路を介して双方向通信可能に接続されている。記憶資源33000は、1以上のメモリ(例えば半導体メモリ)でもよいし、不揮発記憶デバイスが混在してよい。
記憶資源33000には、管理プログラム32000が格納されている。管理プログラム32000は、装置管理モジュール32100と、装置通信モジュール32200と、GUI表示処理モジュール32300と、を含んでよい。各モジュールは、記憶資源33000のプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されてもよい。管理プログラム32000は、各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。すなわち、以下の説明における各モジュールについての説明は、管理プログラム32000に関する説明に置き換えられてもよい。
記憶資源33000には、さらに、装置管理表33200と、ホスト−ストレージパス管理表33300と、構成表93400とが格納されてよい。構成表93400には、構成情報が格納されてよい。構成情報は、例えば、装置通信モジュール32200が管理対象の各サーバ100から収集してきたI/Oポート管理表13300の各項目と、LPAR管理表13400の各項目と、LPAR稼動スケジュール管理表13500の各項目と、管理対象の各ストレージから収集してきたポート管理表23200の各項目と、ホストグループ管理表23300の各項目と、RAIDグループ管理表23400の各項目と、ボリューム管理表23500の各項目と、ホストグループ−ボリューム関連管理表23600の各項目と、テーブルサイズ上限管理表23700の各項目とを含んでよい。構成表93400には、必ずしも、管理対象装置の全ての表、又は、表中の全ての項目が格納されなくてもよい。構成表93400に格納される各項目のデータ表現形式及びデータ構造は、管理対象装置と同じでなくてもよい。管理プログラム32000は、管理対象装置からこれら各項目を受信する場合、管理対象装置のデータ構造やデータ表現形式でこれら各項目を受信してもよい。
装置通信モジュール32200は、管理下の管理対象装置に定期的又は繰り返しアクセスし、管理対象装置内の各コンポーネントの構成情報を取得する。なお、当該実行指示の繰り返しは、厳密に一定期間毎である必要は無く、どのようなタイミングであってもよい。装置通信モジュール32200は、管理者からの要求に応じて、管理下の管理対象装置に対して構成変更を指示してよい。装置通信モジュール32200は、管理対象装置に対して構成変更を指示した後、管理対象装置内の各コンポーネントの構成情報を再取得し、構成表93400に格納された構成情報を最新の状態に保ってよい。
GUI表示処理モジュール32300は、入力デバイス31300を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス31200を介して表示する。入力デバイスと出力デバイスとは別々なデバイスでもよいし、一つ以上のまとまったデバイスであってもよい。
管理サーバ(管理計算機)は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有してもよいし、これ以外の装置を有してもよい。入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースに、ディスプレイ、キーボード及び/又はポインタデバイスを有する表示用計算機(例えば、管理クライアント35000)が接続されてもよい。そして、管理サーバは、当該インターフェースを介して、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信して表示用計算機に表示したり、入力を受け付けたりすることで、入出力デバイスでの入力及び表示を代替してもよい。
本明細書では、計算機システム(情報処理システム)を管理し、表示用情報を表示する1つ以上の計算機の集合を「管理システム」と呼ぶことができる。表示デバイス又は遠隔の表示用計算機に表示用情報を表示する管理計算機を管理システムと呼ぶことができ、管理計算機と表示用計算機(例えば図1の管理クライアント35000)の組み合わせも管理システムと呼ぶことができる。また、処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は複数の計算機(表示用計算機を含んでよい)を管理システムと呼ぶことができる。
図5は、Boot Orderの参考例を示す。
Boot Orderは、サーバが使用するDevice Pathの優先順位を管理するためのテーブルである。Boot Orderは、ユーザが任意の表現で記述するDescriptionと、ブートするデバイスの場所を示すDevice Pathとで構成されてよい。Device Pathの記述は、UEFIの仕様で規定されており、EFIやEFIドライバによって生成されてよい。Boot Orderは、ブート順序情報と呼ばれてよい。Boot Orderの各エントリは、Boot Optionと呼ばれてよい。
図5は、Boot OrderのDevice Pathが、Fibre Channelに割り当てられているWWNをキーとして構成されている例である。
図6は、本実施例に係るBoot Order1800の一例を示す。
本実施例に係るBoot Order1800のDevice Pathは、図5のようなFibre Channelに割り当てられるWWNに代えて、ベンダーが任意の番号を割り当てるGUIDと、LU(例えば論理VOL)に割り当てられたLUIDとによって構成される。
なお、本実施例において、図6の「VenMsg(Vender GUID,LUID#C)」を、「LUID#C」と表記する。また、本実施例において、図6のDevice Pathの「HD(1,MBR,0xA06A915F,0x800,0xAF000)」を、「LUN#z」と表記する。
Device Pathは、EFIドライバ170がデバイスを検索するときに使用され、EFIドライバ170毎に異なる記述であってよい。
図6のBoot Order1800は、優先順位の高い順に、「FC1」、「FC2」、「FC3」であることを示す。図6のBoot Orderを参照したシステムは、エントリ「1」の「FC1」のDevice Pathから起動を試み、失敗した場合、次に、エントリ「2」の「FC2」のDevice Pathから起動を試みる、ということを繰り返す。
図5及び図6のBoot Orderは、共にUEFIの仕様を満たした記述であり、典型的には、図5の表記で使用されることが多い。しかし、本実施例では、図6の表記を使用する。
図7及び図8は、FC−HBA120が有するBoot Priority1500の構成例を示す。
Boot Priority1500は、項目値として、ストレージ装置のI/OポートのWWNと、ストレージ装置のLUNと、ストレージ装置の論理VOLに割り当てられているLUIDとを有してよい。LUIDは、複数のストレージ装置に存在する複数の論理VOLに対してもユニークなIDである。例えば、図9において、現用サーバと予備サーバとに、それぞれ、別々のストレージ装置の論理VOLが割り当てられた場合であっても、それぞれの論理VOLのLUIDは重複しない。
Boot Priority1500は、ブート検索情報と呼ばれてもよい。Boot Priority1500の項目値は、ユーザによって設定されてよい。Boot Priority1500の項目値を設定及び変更するためのインターフェースは、EFIドライバ170が提供してよい。Boot Priority1500は、EFIドライバ170が、EFI190から受領したデバイスの検索指示に対して、優先順位を応答するために使用される。
典型的には、LUIDは、EFIドライバ170が、Device Identification VPD Pageを要求するInquiryコマンドをストレージ装置に発行し、返答してきたIdentification Descriptionリストの情報からDentifier TypeがName Address Authority、若しくは、Identifier Typeが、T10 Vendor IdentificationのIdentification Descriptorの値を示す。
図9は、冗長化システムにおいて障害が発生し、現用サーバから予備サーバに切り替える動作の一例を示す。
現用サーバ100Aに障害が発生した場合、SVPは、フェイルオーバ処理として、その現用サーバ100のEFI190が有するBoot Order1800Cを、予備サーバ100BのEFI190Bにコピーする(コピー後をBoot Order1800Dとする)。また、SVPは、現用FC−HBA120Aが有するBoot Priority1500Cも、予備FC―HBA120Bにコピーする(コピー後をBoot Priority1500Dとする)。
次に、図10に現用サーバ100Aのブート動作例を、図11にフェイルオーバ後における待機サーバ100Cのブート動作の例を示す。
図10は、図9において、現用サーバ100Aのブート動作例を示すシーケンスチャートである。
ここで、現用サーバ100AのBoot Order1800Cのエントリ「1」には、LUID#Cを含むDevice Pathが設定されているとする。また、EFIドライバ170AのBoot Priority1500Cのエントリ「1」には、WWN#1、LUN#z、LUID#Cが設定されているとする。
現用サーバ100Aに電源が投入されたとき、EFI190AとEFIドライバ170Aとは、連携しつつ起動する。
EFI190Aは、最初に、Boot Order1800Cのエントリ「1」のDevice Pathを読み込み(S40100)、EFIドライバ170Aに対して実行指示を行う(S40300)。この実行指示には、読み込んだDevice Pathに記述されているLUID#Cが含まれてよい。そして、EFI190Aは、EFIドライバ170Aの実行完了を待つ(S40400)。
一方、EFIドライバ170Aは、Boot Priority1500Cのエントリ「1」に、WWN#1、LUN#z、LUID#Cが設定されていることを確認し(S40200)、EFI190Aに呼び出されるのを待つ(S40500)。
EFIドライバ190Aは、EFI190Aから実行指示を受けると、Boot Priority1500Cから、その実行指示に含まれるLUID#Cに対応するWWN#1及びLUN#zを特定する。そして、EFIドライバ190Aは、その特定したWWN#1をキーとして、LUN#zの論理VOLを検索する(S40600)。
FC―HBA120Aは、ストレージ装置200のWWN#1に接続されているので、EFIドライバ170Aは、そのWWN#1をキーとして、LUN#zの論理VOLを発見できる。
そこで、EFIドライバ170Aは、その発見した論理VOLのLUID#Cを用いて記述したDevice Pathを、EFI190Aに送信する(S40700)。
EFI190Aは、EFIドライバ170Aから送信されたDevice Pathと、S40300で実行指示を行ったDevice Pathと、を比較する(S40800)。
この比較の結果、何れのDevice PathもLUID#Cに対する記述で一致するので、EFI190Aは、エントリ「1」のDevice Pathからブートする(S40900)。
図11は、図9において、フェイルオーバ後の予備サーバ100Bのブート動作例を示すシーケンスチャートである。
予備サーバ100Bに電源が投入されたとき、EFI190BとEFIドライバ170Bとは、連携しつつ起動する。
EFI190BのBoot Order1800Dは、EFI190AのBoot Order1800Cのコピーである。
また、FC−HBA120BのBoot Priority1500Dは、FC−HBA120AのBoot Priority1500Cのコピーである。
EFI190Bは、最初に、Boot Order1800Dのエントリ「1」のDevice Pathを読み込み(S50100)、EFIドライバ170Bに対して実行指示を行う(S50300)。この実行指示には、Device Pathに記述されているLUID#Cが含まれてよい。そして、EFI190Bは、EFIドライバ170Bの実行完了を待つ(S50400)。
一方、EFIドライバ170Bは、Boot Priority1500Dのエントリ「1」に、WWN#1、LUN#z、LUID#Cが設定されていることを確認し(S50200)、EFI190Bに呼び出されるのを待つ(S50500)。
EFIドライバ170Bは、EFI190Bから実行指示を受けると、Boot Priority1500Dから、その実行指示に含まれるLUID#Cに対応するWWN#1及びLUN#zを特定する。そして、EFIドライバ170Bは、その特定したWWN#1及びLUN#zの論理VOLを検索する(S50600)。
しかし、FC―HBA120Bは、ストレージ装置200のWWN#2に接続されているので、EFIドライバ170Bは、そのWWN#1をキーとして、LUN#zの論理VOLを発見できない(S50700)。
そこで、EFIドライバ170Bは、次に、LUID#Cをキーとして、LUN#zの論理VOLを検索する(S50800)。
LUID#Cの論理VOLは、WWN#2に接続されているストレージ装置200に存在するので、EFIドライバ170Bは、LUID#Cをキーとして、LUN#zの論理VOLを発見できる。そして、EFIドライバ170Bは、そのLUN#zの論理VOLへの経路はWWN#2であることを認識する(S50900)。
そこで、EFIドライバ170Bは、Boot Priority1500Dのエントリ「1」のWWN#1をWWN#2に書き換える(S51000)。この書き換えにより、次回からは、図10と同様、LUID#Cに対応するWWN#2をキーとして、LUN#zの論理VOLを直ちに発見できる。
EFIドライバ170Bは、その発見した論理VOLのLUID#Cを用いて記述したDevice Pathを、EFI190Bに送信する(S51100)。
EFI190Bは、EFIドライバ170Bから送信されたDevice Pathと、S40300で実行指示を行ったDevice Pathとを比較する(S51200)。
この比較の結果、何れのDevice PathもLUID#Cに対する記述で一致するので、EFI190Bは、エントリ「1」のDevice Pathからブートする(S51300)。
図12は、本実施例に係るEFIドライバ170の処理例を示すフローチャートである。
現用FC−HBA120AのEFIドライバ170Aは、図10のS40600で、予備FC―HBA120BのEFIドライバ170Bは、図11のS50600、S50700、S50800、S50900で、この図12の処理を行ってよい。
EFIドライバ170は、Boot Priority1500の最大エントリ数(例えば「8」)を管理するための変数n(nは整数)を「1」に初期化する(S70100)。
EFIドライバ170は、Boot Priority1500のn番目のエントリを確認する(S70200)。
EFIドライバ170は、そのn番目のエントリに設定が存在しない場合(S70300:NO)、nを1つインクリメントし(S71000)、S71200へ進む。
EFIドライバ170は、そのn番目のエントリに設定が存在する場合(S70300:YES)、そのn番目のエントリに設定されているWWN及びLUNが一致する論理VOLを検索する(S70400)。そしてS70500へ進む。
S70400の検索において、WWN及びLUNが一致する論理VOLが見つかった場合(S70500:YES)、EFIドライバ170は、その見つかった論理VOLのLUIDを、そのn番目のエントリに格納する(S70600)。
そして、EFIドライバ170は、その見つかった論理VOLのLUIDを用いて記述したDevice Pathを、Boot Order1800に格納する(S71100)。そして、EFIドライバ170は、変数nを1つインクリメントし(S71000)、S71200へ進む。
S70400の検索において、WWN及びLUNが一致する論理VOLが見つからなかった場合(S70500:NO)、EFIドライバ170は、そのn番目のエントリに設定されているLUIDが一致する論理VOLを検索する(S70700)。そして、S70800へ進む。
S70700の検索において、LUIDが一致する論理VOLが見つかった場合(S70800:YES)、EFIドライバ170は、その見つかった論理VOLのWWN及びLUNを、そのn番目のエントリに上書きする(S70900)。
そして、EFIドライバ170は、その見つかった論理VOLのLUIDを用いて記述したDevice Pathを、Boot Order1800に格納する(S71100)。そして、EFIドライバ170は、変数nを1つインクリメントし(S71000)、S71200へ進む。
S70700の検索において、LUIDが一致する論理VOLが見つからなかった場合(S70800:NO)、EFIドライバ170は、変数nを1つインクリメントし(S71000)、S71200へ進む。
S71200において、EFIドライバ170は、nが8よりも大きい場合(n≦8:NO)、論理VOLの検索を終了し、nが8以下の場合(n≦8:YES)、S70200に戻り、論理VOLの検索を続ける。
図10のS40600は、当該図12の処理において、S70500でWWN及びLUNが一致する論理VOLが見つかった場合の処理に相当する。
図11のS50600、S50700、S50800、S50900は、当該図12の処理において、S70500でWWN及びLUNが一致する論理ボリュームが見つからず、S70800でLUIDが一致する論理VOLが見つかった場合の処理に相当する。
本実施例によれば、図11、図12の例に示すように、現用サーバ100Aから予備サーバ100Bにフェイルオーバが行われても、予備サーバ100Bが、正常に起動することができる。仮に、Boot Orderが図5の例のように記述されている場合、予備サーバは、S50700で論理VOLを見つけることができず、起動に失敗してしまう。
図10乃至図12において、まず、WWNをキーとして論理VOLを検索し、その検索で見つからなかった場合にLUIDをキーとして論理VOLを検索しているのは、WWNをキーとする方が、LUIDをキーとするよりも、高速に検索できる(つまりブート時間が短くなる)からである。故に、本実施例では、図7及び図8に示すように、LUIDをキーとして論理VOLを見つけた場合に、Boot Priority1500のWWNを、その見つけた論理VOLへのパス上のWWNに更新し、次回のブート時間が短くなるようにしている。
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
1:統合プラットフォーム 100:サーバ 120:FC−HBA 200:ストレージ装置 190:EFI 170:EFIドライバ 1500:Boot Priority 1800:Boot Order
Claims (9)
- 現用及び予備サーバと、ストレージ装置とを有する統合プラットフォームであって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、World Wide Name(WWN)が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なLogical Unit ID(LUID)が付与されており、
前記現用及び予備サーバは、それぞれ、ストレージポートと1対1で接続されており、
前記現用サーバは、接続先のストレージポートのWWNと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのLogical Unit Number(LUN)と、当該ブート論理ボリュームのLUIDと、を関連付けるブート検索情報、を有し、
フェイルオーバが実行される際、前記現用サーバが有するブート検索情報は、前記予備サーバへコピーされる
統合プラットフォーム。 - 前記現用及び予備サーバは、それぞれ、Extensible Firmware Interface(EFI)部と、EFIドライバ部とを含み、
前記EFI部は、EFIの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、LUIDを用いて記述されており、
前記EFIドライバ部は、前記ブート検索情報を有し、
フェイルオーバが実行される際、前記現用サーバのEFI部が有するブート検索情報は、前記予備サーバのEFI部へコピーされ、前記現用サーバのEFIドライバ部が有する前記ブート順序情報は、前記予備サーバのEFIドライバ部へコピーされる
請求項1に記載の統合プラットフォーム。 - 前記EFI部は、前記ブート順序情報のデバイスバス情報に含まれるLUIDを、前記EFIドライバ部へ発行し、
前記EFIドライバ部は、
前記ブート検索情報において、前記EFIから発行されたLUIDと関連付けられているWWNを用いて、前記ブート論理ボリュームを検索し、
その検索の結果、前記ブート論理ボリュームを発見できない場合、当該ブート検索情報において、前記EFIから発行されたLUIDを用いて、前記ブート論理ボリュームを検索する
請求項2に記載の統合プラットフォーム。 - 前記EFIドライバ部は、
前記EFIから発行されたLUIDを用いた前記ブート論理ボリュームの検索の結果、前記ブート論理ボリュームを発見できた場合、前記ブート検索情報において、前記LUIDと関連付けられているWWNを、そのブート論理ボリュームを発見できた経路上のストレージポートのWWNに変更する
請求項3に記載の統合プラットフォーム。 - 前記EFIドライバ部は、
前記ブート論理ボリュームを発見できた場合、そのブート論理ボリュームへのLUIDを含むデバイスパス情報を、前記EFI部へ返し、
前記EFI部は、
前記EFIドライバ部へ発行したLUIDを含むデバイスパス情報と、前記EFIドライバ部から返されたLUIDを含むデバイスパス情報が一致する場合、当該デバイスパス情報の示すブート論理ボリュームからブートを開始する
請求項4に記載の統合プラットフォーム。 - ストレージ装置と接続されているサーバであって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、World Wide Name(WWN)が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なLogical Unit ID(LUID)が付与されており、
前記サーバは、ストレージポートと1対1で接続されており、
前記サーバは、接続先のストレージポートのWWNと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのLogical Unit Number(LUN)と、当該ブート論理ボリュームのLUIDと、を関連付けるブート検索情報、を有し、
フェイルオーバが実行される際、前記サーバが有するブート検索情報は、他のサーバへコピーされる
サーバ。 - 前記サーバは、Extensible Firmware Interface(EFI)部と、EFIドライバ部とを含み、
前記EFI部は、EFIの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、LUIDを用いて記述されており、
前記EFIドライバ部は、前記ブート検索情報を有し、
フェイルオーバが実行される際、前記サーバのEFI部が有するブート検索情報は、前記他のサーバのEFI部へコピーされ、前記サーバのEFIドライバ部が有する前記ブート順序情報は、前記他のサーバのEFIドライバ部へコピーされる
請求項6に記載のサーバ。 - ストレージ装置に接続されている現用サーバ及び予備サーバ間におけるフェイルオーバ方法であって、
前記ストレージ装置は、複数のストレージポートを有し、当該複数のストレージポートには、それぞれ、World Wide Name(WWN)が付与されており、
前記ストレージ装置が提供する複数の論理ボリュームには、それぞれ、一意に識別可能なLogical Unit ID(LUID)が付与されており、
前記現用及び予備サーバは、それぞれ、ストレージポートと1対1で接続されており、
前記現用サーバは、接続先のストレージポートのWWNと、ブート時にアクセスする論理ボリュームであるブート論理ボリュームのLogical Unit Number(LUN)と、当該ブート論理ボリュームのLUIDと、を関連付けるブート検索情報、を有し、
前記現用サーバから前記予備サーバに対してフェイルオーバを実行する際、前記現用サーバが有するブート検索情報を、前記予備サーバにコピーする
フェイルオーバ方法。 - 前記現用及び予備サーバは、それぞれ、Extensible Firmware Interface(EFI)部と、EFIドライバ部とを含み、
前記EFI部は、EFIの仕様に準拠し、前記ブート論理ボリュームへのデバイスパス情報を含むブート順序情報を有し、前記デバイスパス情報は、LUIDを用いて記述されており、
前記EFIドライバ部は、前記ブート検索情報を有し、
前記フェイルオーバを実行する際、前記現用サーバのEFI部が有するブート検索情報を、前記予備サーバのEFI部にコピーし、前記現用サーバのEFIドライバ部が有する前記ブート順序情報を、前記予備サーバのEFIドライバ部にコピーする
請求項8に記載のフェイルオーバ方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2016/050475 WO2017119116A1 (ja) | 2016-01-08 | 2016-01-08 | 統合プラットフォーム、サーバ、及び、フェイルオーバ方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2017119116A1 JPWO2017119116A1 (ja) | 2018-05-31 |
JP6516875B2 true JP6516875B2 (ja) | 2019-05-22 |
Family
ID=59273390
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017560003A Active JP6516875B2 (ja) | 2016-01-08 | 2016-01-08 | 統合プラットフォーム、サーバ、及び、フェイルオーバ方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US10579486B2 (ja) |
JP (1) | JP6516875B2 (ja) |
WO (1) | WO2017119116A1 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11150911B2 (en) * | 2018-06-15 | 2021-10-19 | Dell Products, L.P. | System and method for managing UEFI boot device path based on custom selection |
CN116661688B (zh) * | 2023-05-23 | 2023-12-12 | 无锡众星微系统技术有限公司 | 一种sas存储系统的业务响应方法和装置 |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5146568A (en) * | 1988-09-06 | 1992-09-08 | Digital Equipment Corporation | Remote bootstrapping a node over communication link by initially requesting remote storage access program which emulates local disk to load other programs |
US6343324B1 (en) * | 1999-09-13 | 2002-01-29 | International Business Machines Corporation | Method and system for controlling access share storage devices in a network environment by configuring host-to-volume mapping data structures in the controller memory for granting and denying access to the devices |
JP3967509B2 (ja) * | 1999-12-22 | 2007-08-29 | 株式会社東芝 | 最後に処理を行っていたサーバ計算機を判定するプログラムを記録した記録媒体、及び高可用性計算機システム |
US6931519B1 (en) * | 2000-08-25 | 2005-08-16 | Sun Microsystems, Inc. | Method and apparatus for reliable booting device |
US7421478B1 (en) * | 2002-03-07 | 2008-09-02 | Cisco Technology, Inc. | Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration |
US7039829B2 (en) * | 2002-11-07 | 2006-05-02 | Lsi Logic Corporation | Apparatus and method for enhancing data availability by implementing inter-storage-unit communication |
US7340638B2 (en) * | 2003-01-30 | 2008-03-04 | Microsoft Corporation | Operating system update and boot failure recovery |
US7320083B2 (en) * | 2003-04-23 | 2008-01-15 | Dot Hill Systems Corporation | Apparatus and method for storage controller to deterministically kill one of redundant servers integrated within the storage controller chassis |
JP4462024B2 (ja) * | 2004-12-09 | 2010-05-12 | 株式会社日立製作所 | ディスク引き継ぎによるフェイルオーバ方法 |
US8924499B2 (en) * | 2004-12-14 | 2014-12-30 | International Business Machines Corporation | Operating system migration with minimal storage area network reconfiguration |
US7721138B1 (en) * | 2004-12-28 | 2010-05-18 | Acronis Inc. | System and method for on-the-fly migration of server from backup |
US8006125B1 (en) * | 2005-04-29 | 2011-08-23 | Microsoft Corporation | Automatic detection and recovery of corrupt disk metadata |
JP4710518B2 (ja) | 2005-09-28 | 2011-06-29 | 株式会社日立製作所 | 計算機システムとそのブート制御方法 |
JP4544146B2 (ja) * | 2005-11-29 | 2010-09-15 | 株式会社日立製作所 | 障害回復方法 |
US7627584B2 (en) * | 2005-11-30 | 2009-12-01 | Oracle International Corporation | Database system configured for automatic failover with no data loss |
US8705344B2 (en) * | 2006-11-14 | 2014-04-22 | Cisco Technology, Inc. | Graceful failover of a principal link in a fiber-channel fabric |
US7945773B2 (en) * | 2007-09-18 | 2011-05-17 | International Business Machines Corporation | Failover of blade servers in a data center |
US8774052B2 (en) * | 2011-02-24 | 2014-07-08 | Brocade Communications Systems, Inc. | Virtual port world wide names |
US8707085B2 (en) * | 2011-06-30 | 2014-04-22 | International Business Machines Corporation | High availability data storage systems and methods |
JP5509176B2 (ja) * | 2011-10-21 | 2014-06-04 | 株式会社日立製作所 | 計算機システムおよび計算機システムにおけるモジュール引き継ぎ方法 |
US8626967B1 (en) * | 2012-06-29 | 2014-01-07 | Emc Corporation | Virtualization of a storage processor for port failover |
JP5856925B2 (ja) | 2012-08-21 | 2016-02-10 | 株式会社日立製作所 | 計算機システム |
WO2014120136A1 (en) * | 2013-01-30 | 2014-08-07 | Hewlett-Packard Development Company, L.P. | Failover in response to failure of a port |
JP6273732B2 (ja) * | 2013-09-20 | 2018-02-07 | 日本電気株式会社 | 情報処理引き継ぎ制御装置、情報処理引き継ぎ制御方法、及び、情報処理引き継ぎ制御プログラム |
US9747180B1 (en) * | 2015-03-31 | 2017-08-29 | EMC IP Holding Company LLC | Controlling virtual endpoint failover during administrative SCSI target port disable/enable |
-
2016
- 2016-01-08 JP JP2017560003A patent/JP6516875B2/ja active Active
- 2016-01-08 WO PCT/JP2016/050475 patent/WO2017119116A1/ja active Application Filing
- 2016-01-08 US US15/761,116 patent/US10579486B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US10579486B2 (en) | 2020-03-03 |
JPWO2017119116A1 (ja) | 2018-05-31 |
WO2017119116A1 (ja) | 2017-07-13 |
US20180260289A1 (en) | 2018-09-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7516353B2 (en) | Fall over method through disk take over and computer system having failover function | |
US10148758B2 (en) | Converged infrastructure and associated methods thereof | |
KR100644011B1 (ko) | 저장 도메인 관리 시스템 | |
JP6273353B2 (ja) | 計算機システム | |
US9229645B2 (en) | Storage management method and storage system in virtual volume having data arranged astride storage devices | |
JP6286542B2 (ja) | 計算機システム | |
EP1636696B1 (en) | Os agnostic resource sharing across multiple computing platforms | |
US9542249B2 (en) | System redundancy verification method and computer system | |
WO2013157072A1 (ja) | 計算機システム、リソース管理方法及び管理計算機 | |
US20130346584A1 (en) | Control method for virtual computer, and virtual computer system | |
JP2010257274A (ja) | 仮想化環境におけるストレージ管理システム及びストレージ管理方法 | |
US20150234907A1 (en) | Test environment management apparatus and test environment construction method | |
JP5316616B2 (ja) | 業務引き継ぎ方法、計算機システム、及び管理サーバ | |
JP6516875B2 (ja) | 統合プラットフォーム、サーバ、及び、フェイルオーバ方法 | |
JP5750169B2 (ja) | 計算機システム、プログラム連携方法、及びプログラム | |
JP5267544B2 (ja) | ディスク引き継ぎによるフェイルオーバ方法 | |
JP2018101440A (ja) | 計算機システム | |
JP4877368B2 (ja) | ディスク引き継ぎによるフェイルオーバ方法 | |
WO2016056050A1 (ja) | 計算機システム及びそれの管理システム | |
Guide | VMware, Inc. | |
US20140189129A1 (en) | Information processing system and storage apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180202 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190402 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190416 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6516875 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |